解读

“草案模型”在国内大厂常被称作投机解码（Draft-Model）或小模型投机，其核心思想是用 110 B 参数的轻量模型一次性生成 515 个 token，再由千亿级主模型并行验证；若验证通过率（接受率）≥阈值，则直接采纳，否则回退到主模型逐 token 自回归。
面试官问“<60% 时如何动态切换”，实质考察三点：

1. 线上实时指标采集与滑动窗口统计方案；
2. 低延迟回退决策链路（<2 ms 级别），不能阻塞推理；
3. 与LLMOps 持续监控打通，保证安全、可灰度、可回滚。

知识点

1. 投机解码指标：接受率 = 被主模型采纳的 token 数 / 草案模型产生的 token 数，窗口长度通常取 100 token。
2. 动态阈值控制器：基于 PID 或 EWMA 算法，每 50 ms 更新一次接受率，防止毛刺抖动。
3. 零拷贝回退：在 C++ 推理框架（如 FasterTransformer、lmdeploy）里，把草案模型与主模型放在同一块 GPU 显存，通过共享 KV-Cache 指针实现微秒级切换，避免重新分配显存。
4. 服务化封装：在 Python 侧用异步协程（asyncio）把“指标采集→阈值判断→模式切换”做成非阻塞任务，推理主线程只读原子变量，延迟增加 <0.1 ms。
5. LLMOps 监控：将接受率、回退次数、首 token 延迟、吞吐写入Prometheus + Grafana，并配置告警规则：连续 3 个滑动窗口接受率 <60% 即自动回退，同时触发钉钉/飞书告警，支持一键回滚到上一镜像版本。

答案

线上实现分四层：

1. 指标层：在推理服务（triton-server 自定义 backend）里，每完成一次草案-验证，用无锁环形队列记录采纳/拒绝结果，滑动窗口 128 token，每秒计算一次接受率。
2. 决策层：写一段CUDA kernel 内联函数，把接受率与阈值 0.6 比较，若低于阈值，将全局原子变量 draft_enabled 置 0；主模型推理入口判断该变量，立即走自回归分支。
3. 切换层：草案模型与主模型共享 KV-Cache，回退时复用已计算的 key/value，只需把最后拒绝位置对应的 hidden state 喂给主模型，继续自回归，显存零拷贝。
4. 运维层：把 draft_enabled 变更事件打到Kafka，由 LLMOps 平台消费后写入MySQL 审计表，同时触发灰度策略：若集群内 30% 实例持续 2 分钟接受率 <60%，自动关闭全集群投机解码，并生成回滚工单供值班审批。

通过以上四步，可在1 ms 内完成“检测→决策→回退”，P99 延迟增加 <2%，保证线上业务几乎无感。

拓展思考

1. 阈值自适应：把业务指标（用户留存、对话轮次）也喂给控制器，用强化学习动态调整阈值，而非固定 60%，实现“业务收益最大化”而非单纯追求吞吐。
2. 异构草案：针对中文代码混合场景，可维护多份领域草案模型（法律、医疗、代码），通过路由小模型先判断领域，再选择对应草案，若该领域草案接受率持续低，则回退到通用主模型自回归。
3. 端边云协同：在国产 ARM 边缘盒子部署 1B 草案模型，接受率低时不再回边缘自回归，而是异步流式把请求转回中心云主模型，边缘只缓存用户历史 2k token，减少回云带宽 40%，兼顾成本与体验。