LLM 推理服务的批处理、流式输出与成本控制

在线模型服务同时受 GPU 显存、计算吞吐、首 token 延迟和输出 token 速度限制。只看平均 QPS 会掩盖长上下文和长输出请求造成的排队。

把延迟拆开

首 token 延迟由排队、预填充和网络返回决定；后续 token 延迟由解码、KV Cache 和并发请求共同决定。SLO 应分别定义 TTFT、TPOT、完整响应 P95 和超时率。

连续批处理让新请求在旧请求生成过程中加入批次，提高 GPU 利用率。但批次不能无限扩大，长请求会拖住短请求。调度器应设置最大 batch token、最大等待时间和优先级。

请求 -> 令牌化 -> 等待队列
       -> 预填充批次 -> KV Cache
       -> 解码批次 -> 流式输出
       -> 完成/取消 -> 释放显存

上下文越长、并发越高，KV Cache 占用越大。服务端要限制最大上下文、单用户并发和总缓存 token，超限时返回可解释错误或排队，而不是让 GPU 直接 OOM。

相同系统提示可以做前缀缓存，但要按模型版本、租户和权限隔离，命中率和缓存占用都要监控。

客户端断开后要取消生成并释放 GPU 资源。中间代理需要正确转发 SSE 或 WebSocket 心跳，避免缓冲导致用户看不到实时 token。流式响应要有最终 usage 和 trace_id。

按模型、租户、输入 token、输出 token、GPU 时间和缓存命中统计成本。低风险摘要可路由到小模型，复杂任务才使用大模型。峰值时可启用排队、降级或限制长上下文。

推理服务的容量单位不是简单的请求数，而是每秒输入 token、输出 token、上下文长度和 GPU 显存的组合。压测必须使用真实长度分布。

参考资料：vLLM 官方文档。