LLM 推理服务：预填充、解码与请求调度

推理服务需要处理不断到来的请求，而不只是运行一次模型。本文根据推理框架阅读记录整理，把性能指标、请求阶段和调度选择放在一起理解。

请求的两个阶段

预填充处理输入提示并建立缓存；解码利用已有上下文继续生成。两阶段的计算形态和资源需求不同，具体瓶颈取决于模型、输入长度、批次和硬件。

指标	含义
首 token 延迟	请求进入到首个输出 token 的等待
后续 token 间隔	流式生成时相邻输出的等待
吞吐量	单位时间完成的工作量，需明确按请求还是 token 计
端到端延迟	从请求进入到完整输出的时间

一个方案可能提高吞吐量，却增加单个用户等待。平均值也可能掩盖尾部请求，需要同时检查延迟分布。

动态批处理

请求输出长度不同，如果批次必须等所有请求结束，已经完成的请求会留下空位。持续或迭代级批处理在调度边界移除完成请求、加入新请求，提高资源利用率。

它需要与 KV cache 管理配合：新请求是否装得下、旧请求如何释放缓存，以及活动序列是否会超过资源预算。

长短请求与公平性

优先处理短请求可能改善某些平均延迟指标，但输出长度通常未知，预测也有误差。若总是选择短请求，长请求可能持续被延后。

因此需要明确目标：降低平均完成时间、满足每个请求的期限，还是保障不同用户的公平份额。长度预测和优先级只能作为目标下的手段。

预填充分块与解耦

长提示的一次预填充可能影响已有请求的流式输出。分块预填充让调度器更细粒度地安排工作，但块大小过小也会增加开销。

将预填充与解码部署在不同资源上，可以分别调度两个阶段，却引入缓存传输和资源配比问题。多一层架构并不必然带来更低延迟。

从单机扩展到集群

集群还要处理异构设备、请求分发、模型副本和跨节点带宽。即使总显存足够，也不代表每个节点都能按计划完成任务。

相关方向可沿 Taming the Titans 综述继续阅读。本文仅保留系统层的问题框架，不复述原笔记中尚未验证的设备框架列表或研究设想。

评估前先固定负载：到达率、输入长度、输出长度和延迟要求，再观察调度、缓存与计算如何相互影响。