推理服务怎样处理一个请求
调用模型 API 看似只有一行,背后至少有协议、排队、tokenization、Prefill、Decode、采样和流式传输。排障前必须先知道故障属于哪一层。
请求路径
text
HTTP/API 请求
→ 鉴权、配额与参数校验
→ Chat Template + tokenizer
→ scheduler 组 batch
→ runtime 执行 Prefill/Decode
→ KV Cache 管理
→ sampling / stop
→ detokenize 与流式事件
→ 用量、trace 与最终响应五层责任
| 层 | 负责 | 不负责 |
|---|---|---|
| API/Harness | 身份、参数、超时、事件协议 | 矩阵内核 |
| Scheduler | 排队、batch、抢占、公平性 | 判断回答事实正确 |
| Runtime | 加载权重、执行算子、设备通信 | 用户权限 |
| Model | 给定上下文产生 logits | 外部事实时效 |
| Decoder | logits 处理、采样、停止与文本解码 | 更新训练参数 |
优化分别作用在哪里
- 权重量化:改变权重表示与部分算子;
- continuous batching:在请求到达/完成时动态组合 Decode;
- paged cache:改善变长 KV Cache 的分配与复用;
- speculative decoding:用候选模型提出多个 token,再由目标模型验证;
- 编译/融合内核:减少调度和内存访问开销。
任何优化都要重新验证输出容差、支持的采样方式、显存、延迟和硬件条件。
请求状态必须显式
至少区分 queued、prefill、decoding、completed、cancelled、failed。取消后应释放 cache;超时与模型自然 EOS 不能共用同一个“完成”状态;流式连接断开也不一定表示后端计算已经停止。
常见错误
- 把排队时间算作模型 Decode 慢;
- 客户端断开但服务仍占用 GPU;
- 量化模型与原 tokenizer/template 错配;
- batch 中序列完成后 cache 未释放;
- 重试生成两份副作用或重复计费。
自测
本节自测
先作答,再查看解释。记录只保存在当前浏览器。
完成 0 / 3
打印版答案:1. 请求调度;2. 错;3. 质量、性能、资源和兼容性对照。
下一步
进入延迟、吞吐、显存与成本。