静态
固定大小的批次，要等装满才发。适合离线任务，但不适合交互式流量，因为所有人都得等这一批。
AI推理指南
服务优化
决定一组 GPU 能服务多少请求、以多快速度服务的系统级技术：批处理、KV 缓存的显存管理、decode 加速、阶段分离、并行与路由。延迟、吞吐量和成本相互拉扯；究竟偏向哪一头，由工作负载决定。
批处理：第一个吞吐杠杆
单个请求会让 GPU 大部分算力闲置；把请求聚在一起，可以让每次权重读取被许多 token 分摊。怎么聚很关键：
动态
批次按时间窗口或大小上限关闭，等待时间因此有了上界。这更好，但一批仍然要等它最慢的成员跑完。
连续
调度器以 token 为粒度工作：已完成的序列中途离开，排队的请求立刻加入。这是当前主流的默认方式（vLLM、SGLang、TensorRT-LLM），也是单项收益最大的利用率改进。
chunked prefill 进一步细化了它：长提示词被切成小块，与 decode 步骤交错执行，于是一个超长提示词不会再卡住其他所有人的 token 流。批处理策略就是延迟策略；请测量 TTFT 和 token 间延迟，而不只是每秒 token 数。
KV 缓存显存：分页、复用与卸载
PagedAttention
朴素的服务实现会按每个请求可能的最大长度预留连续的 KV 显存，其中大部分以碎片的形式被浪费。PagedAttention 借用了虚拟内存的思路：缓存存放在按需分配的定长块中，并用一张块表把每个序列的逻辑位置映射到物理块。浪费因此降到大约最后一个不满的块，相同前缀可以共享物理块，回收出的显存则转化为更大的有效批次。它由 vLLM 提出，如今已是各服务引擎的标准做法；这是显存管理上的胜利，而不是更快的内核。
prefix caching
如果两个请求以字节完全相同的 token 前缀开头（相同的系统提示词、相同的示例、相同的对话历史），这段前缀的 prefill 计算就可以只做一次并复用，每命中一次都能降低 TTFT 和 prefill 算力。它要求 token 精确匹配，这正是提示词纪律重要的原因：静态内容放前面，易变取值（时间戳、用户数据、请求 ID）尽量靠后，序列化保持确定性。请跟踪命中率；命中率低通常意味着提示词模板把变化泄漏到了开头。
KV 缓存卸载
缓存随上下文长度和并发线性增长，而 GPU 的 HBM 会最先耗尽。卸载会把较冷的缓存转存到 CPU 内存、本地 SSD 或远端存储，需要时再取回，于是空闲的会话和长期共享的上下文不再占着 HBM 不放（LMCache 是最常见的开源实现，已与 vLLM 集成）。它在长上下文和可恢复会话场景下值得采用；权衡在于传输时间与重新计算之间，因此请在你自己的存储层级上把两条路径都测一遍。
投机解码：更快的 token，相同的分布
decode 受内存限制，因此每一步都有富余算力。一个廉价的草稿模型提出若干 token；目标模型用一次前向把它们一起校验，接受其中最长的正确片段。被接受的 token 只花了很小的代价；被拒绝的草稿则退回常规解码，而严格的校验方案能保持目标模型的输出分布不变。
- 草稿模型的选择：可以是一个独立的小模型、挂在目标模型上的额外解码头（Medusa 一类）、特征级草稿（EAGLE 系列），或者直接从提示词里做 n-gram 查找。实现上常常一次起草多条候选续写，并在一次批量前向中校验整棵树。
- 起决定作用的变量是接受率：在可预测的文本（代码、结构化输出）上，一个对齐良好的草稿模型帮助很大；而不匹配的草稿模型反而会让服务变慢。
- 与其他因素的相互作用：草稿模型会占用显存并增加调度复杂度，而且在批次非常大、算力富余消失时收益会缩水。相关研究方向见高级优化。
横向扩展：分离、并行与路由
prefill/decode 分离
prefill 受算力限制且呈突发状；decode 受带宽限制且相对平稳。二者混在一起会互相干扰：一次长 prefill 会卡住所有人的 token 流。分离部署把两个阶段放到各自的工作节点池上，独立扩缩容和调优，由 prefill 节点通过高速网络把 KV 缓存发送给 decode 节点。传输就是要付的税，所以它在机群规模下才划算，在小规模或短提示词场景下反而吃亏；支持的框架包括 vLLM、SGLang 和 NVIDIA Dynamo。
并行策略
数据并行复制模型并分摊流量。张量并行把单层切分到多张 GPU 上，让过大的模型放得下，代价是每一步都要通信（它需要 NVLink 级别的互联）。流水线并行把层区间分配给各个阶段，并用微批次填补流水线气泡。专家并行把 MoE 的专家分散到不同设备上。真实部署会把这些组合起来，而最佳配比只能靠实测：张量并行会加大带宽压力，复制则会压缩每张 GPU 的 KV 余量，所以请对具体配置做基准测试，而不要凭第一性原理推演。
推理路由
当副本很多时，路由器本身就成了一个优化面。轮询忽略了 LLM 场景里所有真正重要的因素；更好的信号是当前负载、显存余量，尤其是缓存局部性：前缀感知或会话粘滞的路由会把请求送到它的 KV 状态已经存在的地方（对提示词前缀做一致性哈希是常见做法，llm-d 等项目就在用）。分离部署的机群按阶段路由，优先级或 SLA 分级以及适配器的所在位置也可以纳入同一套打分。这与在不同档位模型之间做选择的路由是两回事，后者见智能体模式。
离线批量推理
并非所有工作负载都是交互式的。语料嵌入、分类回填、批量摘要和评测运行都能容忍数小时的延迟，这会彻底改变优化目标：把硬件跑满，使用闲置或非高峰时段的算力（服务商正是为此提供打折的批量档位），并在结果被使用之前加上后处理和质量检查。把批量任务挡在交互式机群之外，同时也保护了你的延迟 SLO。
先测量，再相信
- 测量 TTFT、token 间延迟、端到端延迟（中位数和 P99）、固定并发下的吞吐量，以及单请求成本；只给一个数字的结果会掩盖各种取舍。
- 使用你自己的流量形态：提示词与输出的长度分布、并发模式、缓存命中的可能性。均匀的合成负载会让任何优化都显得更好看。
- 为 LLM 服务设计的压测工具（GenAI-Perf、LLMPerf，或 k6/Locust 脚本）会报告通用 HTTP 工具看不到的 token 级指标。
- 每条结果都记录模型、量化方式、硬件、引擎版本和配置；没有标注的基准测试既无法比较也无法复现。
- 质量基准（MMLU 之类的评测套件）和性能基准回答的是不同问题；一次服务侧改动应当同时用延迟目标和准确率评测来验证。