Skip to content

推理服务怎样处理一个请求 ​

调用模型 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外部事实时效
Decoderlogits 处理、采样、停止与文本解码更新训练参数

优化分别作用在哪里 ​

  • 权重量化:改变权重表示与部分算子;
  • 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. 1单选题 continuous batching 主要属于哪一层?
  2. 2判断题 客户端流式连接断开必然表示 GPU 计算已取消。
  3. 3开放题 量化上线前要做哪些对照?
这里的分数只用于本章自测,不代表真实任务能力。

打印版答案:1. 请求调度;2. 错;3. 质量、性能、资源和兼容性对照。

下一步 ​

进入延迟、吞吐、显存与成本。

最近更新