核心结论
大模型推理系统的本质，是在 延迟、吞吐、显存、成本、公平性 之间做连续权衡。模型侧优化解决“单次计算和缓存占用太贵”，系统侧优化解决“真实请求又长又短、早到晚到、阶段不同、租户不同”的动态调度问题。
原文以 vLLM 代表的技术路线为主线，把推理系统拆成两条线：一条是模型内部的计算和内存优化，例如 KV Cache、PagedAttention、FlashAttention、MoE；另一条是服务系统的执行和调度优化，例如 continuous batching、prefill/decode 调度、prefix caching、speculative decoding、admission control 与 fairness。
技术地图
把正文和参考资料合在一起看，现代 LLM 推理系统可以粗略拆成五层。每一层解决的问题不同，但最终都会反馈到用户看到的 TTFT、TPOT、吞吐和尾延迟。
什么是推理
推理是在模型参数固定后，接收输入并生成输出。与训练相比，它不做反向传播和参数更新，更关注服务体验、资源利用和稳定性。
生成式模型通常采用 Decoder-only 架构，每一步基于已有上下文预测下一个 token。因此推理不是一次性函数调用，而是一个持续推进的生成过程。
- TTFT：从请求进入系统到首 token 输出的时间。
- TPOT：后续每个输出 token 的平均生成时间。
- Throughput：单位时间处理的 token 或请求数。
- P95/P99：尾部请求的延迟表现，决定线上服务的坏体验。
- Memory Efficiency：尤其关注 KV Cache 的显存利用率。
Prefill 与 Decode 的根本矛盾
Prefill 和 Decode 的计算形态不同，是推理系统调度复杂性的根源之一。
| 阶段 | 特征 | 优化目标 |
|---|---|---|
| Prefill | 一次处理完整输入，计算密集，容易占住 GPU。 | 降低首 token 等待，避免长 prompt 阻塞 decode。 |
| Decode | 逐 token 迭代，单步轻但频繁，对流式体验敏感。 | 稳定输出节奏，控制 TPOT 和尾延迟。 |
模型侧优化
1. KV Cache 与 PagedAttention
自回归生成时，如果每生成一个 token 都重算全部历史上下文，成本会非常高。KV Cache 把历史 key/value 状态保留下来，换取更快的后续 decode。但它也会随着上下文长度和并发数增长，成为显存瓶颈。
PagedAttention 借鉴操作系统分页思想，把一条请求的 KV Cache 拆成固定大小块，通过映射表管理，而不是要求连续大块显存。它减少碎片、降低浪费，也让复杂解码策略和高并发更可控。
2. Attention IO 优化
FlashAttention 的关键不是改变 Attention 数学定义，而是减少中间矩阵在 HBM 和片上 SRAM 之间来回搬运。FlashAttention-2 进一步改进线程块与 warp 的工作划分，提高并行性和实际硬件利用率。
3. MoE 与稀疏激活
MoE 把部分 MLP 替换为专家集合，并用路由器为每个 token 选择少量专家。它的好处是参数规模可以很大，但每个 token 只激活一部分计算；代价是专家路由、负载均衡、token 重排、跨卡通信和显存占用都变复杂。
分布式并行
当模型或流量规模超过单卡能力，就需要把计算、参数或请求拆到多卡/多机。
| 方式 | 拆什么 | 适合解决 |
|---|---|---|
| TP | 同一层张量/算子 | 单层太大或算力不足。 |
| PP | 模型层 | 整模型放不进单卡。 |
| DP | 模型副本 | 模型能放下，但请求流量大。 |
| EP | MoE 专家 | 专家数量多，专家参数放不下或通信需优化。 |
参考资料里的 Megatron Core 和 DeepSpeed MoE 都强调：MoE 的推理/训练不只是“多放几个专家”，真正难点是专家并行、token dispatch、通信重叠、负载均衡和专家切分。
Batching 演进
推理系统做 batching 是为了喂满 GPU，但拼批也会引入等待和互相拖累。
- Static Batching：攒够固定数量再跑，实现简单，对波动流量不友好。
- Dynamic Batching：在短时间窗里收集请求，兼顾一点灵活性。
- Continuous Batching：运行中的 batch 可持续加入新请求，适合输出长度高度不确定的生成任务。
- Selective Batching：按长度、阶段、缓存命中等特征分桶，减少互相干扰。
Orca 和 vLLM 相关资料共同指向一个结论：LLM 服务不是传统固定 batch 推理，调度器必须在生成过程中持续重组 batch。
系统侧优化
Chunked Prefill
Sarathi-Serve 的思路是把大块 prefill 切成更均匀的小块，使 decode 请求能在 prefill 片段之间穿插执行。它并不减少 prefill 总工作量，但降低了 prefill 长时间独占 GPU 造成的阻塞。
Prefill/Decode 解耦
DistServe 和 P/D-Serve 都强调 prefill 与 decode 的资源需求不同。把二者放在不同实例或资源池上，可以让 prefill 追求吞吐，让 decode 追求稳定延迟；代价是 KV Cache 转移、网络、路由和全局调度更复杂。
Prefix Caching 与缓存感知调度
很多请求共享系统提示词、模板、长文档前缀或 few-shot 示例。Prefix caching 复用已计算的 KV blocks，避免重复 prefill。Preble 进一步把“缓存能否复用”变成分布式调度决策的一部分，在缓存命中与负载均衡之间联合优化。
Speculative Decoding
Speculative decoding 先由便宜的 draft 路径生成多个候选 token，再让目标模型批量验证。它的目标是减少逐 token 等待。Self-speculative decoding 则不依赖外部小模型，而是通过跳过部分中间层生成草稿，再由原模型验证。
Admission Control 与 Fairness
当请求长度、输出长度和租户行为不可预测时，系统不能只优化平均吞吐。Fairness in Serving LLMs 把公平性定义到 token 成本层面；Llumnix 则强调运行时重调度和请求状态迁移，用于缓解负载不均、碎片和 SLO 违约。
参考资料精读索引
下面是对文章中参考链接的二次阅读整理。每条不是简单列名，而是标出它在技术地图里的位置。
| 资料 | 主题 | 读后定位 |
|---|---|---|
| ai-infra-learning | AI Infra 学习材料 | 系统化学习入口，适合补齐工程基础与实践脉络。 |
| Attention Is All You Need | Transformer | 现代大模型架构起点，解释为什么 Decoder-only 自回归生成成为主流。 |
| Inside vLLM | vLLM 系统剖析 | 把引擎、调度器、KV cache manager、continuous batching、prefix/spec decoding 串起来。 |
| Orca | Continuous batching | 早期代表性系统，核心是面向生成式模型的迭代级调度。 |
| PagedAttention / vLLM paper | KV Cache 内存管理 | 用分页思想降低 KV Cache 碎片和重复，提升吞吐。 |
| FlashAttention | IO-aware Attention | 关注 HBM/SRAM 之间的数据搬运，是 exact attention 的工程优化。 |
| FlashAttention-2 | Attention 并行优化 | 通过更好的 work partitioning 提升硬件利用率。 |
| Hugging Face MoE 详解 | MoE 入门 | 讲清专家、路由、稀疏激活、训练/推理挑战和显存压力。 |
| Switch Transformers | 稀疏专家扩展 | 用更简单路由和稀疏激活扩展到超大参数模型。 |
| DeepSpeed MoE Inference | MoE 推理并行 | 强调 expert parallelism、expert slicing、通信调度与 MoE 推理优化。 |
| Megatron Parallelism Guide | TP/PP/DP/CP/EP | 多维并行策略参考，适合理解大模型如何跨 GPU 拆分。 |
| Megatron Core MoE | MoE 工程实现 | 覆盖专家并行、router、load balancing、token dispatch 与 grouped GEMM。 |
| TensorRT-LLM In-Flight Batching | 在线拼批 | 说明工业推理引擎如何把动态请求纳入执行过程。 |
| Sarathi-Serve | Chunked prefill | 把 prefill 切块，缓解吞吐和延迟冲突。 |
| DistServe | P/D 解耦 | 将 prefill 与 decode 拆到不同资源，追求 goodput 和 SLO。 |
| P/D-Serve | 大规模 P/D 服务 | 面向多 xPU 集群，关注细粒度组织、动态 P/D 比例和 RDMA KV 传输。 |
| vLLM Prefix Caching | 前缀缓存 | 复用 KV cache blocks，减少重复 prompt 计算。 |
| Preble | 缓存感知分布式调度 | 联合优化 KV 复用与负载均衡，面向共享前缀请求。 |
| Speculative Sampling | 投机解码 | 用 draft 模型生成候选，再由目标模型验证。 |
| Draft & Verify | 自投机解码 | 跳过部分层生成草稿，无需额外小模型，目标是无损加速。 |
| Fairness in Serving LLMs | 公平调度 | 用 token 成本定义公平性，而不是只做请求级限流。 |
| Llumnix | 动态重调度 | 通过请求和状态迁移缓解负载不均、碎片和 SLO 问题。 |
最值得记住的系统原则
- 显存比 FLOPs 更早成为瓶颈：长上下文和高并发下，KV Cache 管理决定系统上限。
- 平均吞吐不能代表线上体验：P95/P99、TTFT、TPOT 才能反映用户体感。
- 调度器是推理系统核心组件：它不是外围队列，而是决定 GPU 利用率和服务质量的控制面。
- 缓存应该进入路由决策：prefix caching 命中会改变请求真实成本，调度不能只看队列长度。
- MoE 把计算问题变成通信和负载均衡问题：稀疏激活降低每 token 计算，但专家路由会带来新系统复杂度。
实践落地清单
- 为服务分别监控 TTFT、TPOT、throughput、P95/P99、KV Cache 命中率和显存碎片。
- 先引入 continuous batching，再评估 chunked prefill 和 prefix caching。
- 长上下文、RAG、Agent 场景优先考虑 prefix caching 和缓存感知路由。
- MoE 服务要单独评估专家分布、token dispatch、all-to-all 通信和热点专家。
- 线上多租户必须设计 admission control，不要让超长请求拖垮公共队列。
- 当 prefill 和 decode 互相干扰明显时，再考虑 P/D 解耦；它收益高，但系统复杂度也高。
读后重构：一套推理请求的生命周期
把所有资料合并后，一个请求在现代推理系统中的路径可以这样理解：
这条链路里每一步都可能成为瓶颈。早期系统常把优化焦点放在 kernel 和单模型吞吐上；新一代系统则越来越重视全局调度、缓存复用、跨实例迁移、公平性和 SLO。
风险与疑点
- 很多优化在论文或单场景 benchmark 中有效，但真实业务请求长度、并发和 prompt 复用模式会显著改变收益。
- P/D 解耦依赖高效 KV 传输；如果网络或序列化成本过高，收益可能被抵消。
- Speculative decoding 的收益依赖 draft 命中率；任务越复杂、采样越开放，接受率可能越不稳定。
- Fairness 不是免费午餐。更公平通常意味着牺牲部分吞吐峰值或引入更复杂的队列策略。
- MoE 推理的显存压力容易被低估，因为未激活专家也常需要常驻内存。
适合继续深挖的顺序
- 先读 vLLM anatomy，建立引擎、scheduler、KV manager 的整体模型。
- 再读 PagedAttention 与 FlashAttention，理解显存和 IO 为什么重要。
- 接着读 Orca、Sarathi、DistServe，理解 batching 与 P/D 调度演进。
- 做长上下文/RAG 时读 prefix caching 和 Preble。
- 做多租户平台时读 Fairness 和 Llumnix。
- 服务 MoE 模型时读 Hugging Face MoE、DeepSpeed MoE 和 Megatron Core MoE。
来源
原文：《大模型推理系统入门：从模型优化到调度优化》，公众号作者显示为“一起推理吧”。
正文提取时间：2026-05-08T09:49:02Z。参考资料通过 arXiv API 与网页正文提取工具读取。本文为阅读笔记与综合分析，不复制原文完整内容。