🧾论文版本与定位

Miao、Oliaro、Zhang、Cheng、Jin、Chen、Jia 的 Towards Efficient Generative Large Language Model Serving: A Survey from Algorithms to Systems 投稿于 2023 年 12 月 23 日，2025 年 7 月 16 日被 ACM Computing Surveys 接收（DOI 10.1145/3754448），arXiv v2 更新于 2026 年 7 月 23 日。本文以 arXiv PDF 全文为依据，按原文 §1–§7 的结构重建。这是一篇综述（survey），它的价值不在提出新技术，而在给出一个到 2025 年为止仍然覆盖最全的 LLM 推理效率分类法（taxonomy）——今天广泛部署的 speculative decoding、PagedAttention、continuous batching 等技术都能在这个骨架里找到位置。

🎯服务效率为什么是瓶颈

原文 §2.4 把挑战归为五条，每条都对应后文的一类解法：

延迟与响应时间自回归解码逐 token 生成，聊天机器人等实时场景要求低延迟。每个新 token 都要对全部已生成内容做一遍条件计算，延迟随序列变长而累积。
显存占用与模型体积模型参数量大，KV cache 随序列动态增长。显存受限设备部署困难，需要压缩技术与系统优化。
可扩展性与吞吐生产环境请求负载波动大。多请求并发需要并行计算、请求调度等系统级手段分摊算力。
硬件兼容与加速模型要落到 CPU、GPU、TPU、FPGA 等异构硬件上，需要硬件感知的算法设计与优化。
精度与效率的权衡量化、剪枝等手段可能损失精度。实时对话可以容忍轻微精度损失换取速度，医疗诊断则不能——原文强调权衡必须按应用场景校准。

其中最结构性的一条是自回归解码本身：原文用 Algorithm 1 给出形式化描述——每步 argmax 采样下一个 token、拼回输入序列、循环直到 EOS。这个串行依赖是后面所有解码类算法创新的靶子。

🗺️分类总览：算法 × 系统

原文 Figure 1 的分类法把已有工作分成两大类。判断标准是是否修改 LLM 的计算语义：

1
算法创新（§3.1）：改变生成过程本身——解码算法、架构设计、模型压缩。输出可能改变（如非自回归、早退），追求速度与精度的再平衡。
2
系统优化（§3.2）：不改模型语义——低比特量化、并行计算、内存管理、请求调度、内核优化。输出分布保持不变，优化的是资源利用率。
这个二分法是全文的组织原则。同一条延迟-吞吐曲线，算法侧从生成过程下手（少算几步、算得更快），系统侧从资源利用率下手（同样算力塞进更多请求）。部署时两者互补而非二选一——原文 §3.2 末尾明确举例：实时对话可用低比特量化换响应速度，医疗诊断则必须保住精度。

🧮算法创新：解码、架构、压缩

解码算法（§3.1.1）——打破串行依赖

四条路线，全部瞄准自回归的逐步串行：

路线核心思路代表工作主要代价
非自回归解码打破输出 token 间依赖，并行生成Mask-Predict、blockwise parallel decoding、Jacobi 迭代并行解码质量通常低于自回归；需重训或改造模型
投机解码（speculative decoding）小 draft 模型先猜多步，LLM 并行验证；验证保证输出分布不变SpecInfer（树形投机推理）、Medusa、EAGLE、Sequoia、Triforcedraft 模型要轻量且足够准；并行验证的系统实现有难度
早退（early exiting）浅层内部分类器置信时提前输出，不做完整前向Kangaroo（自草稿投机解码）内部表征信息不足，预测可能不可靠
级联推理（cascade inference）按请求难度在大小模型间分派CascadeBERT、Tabi、FrugalGPT、Mixture-of-Thought分派机制若不准会伤质量
投机解码是当前事实标准。原文指出其关键优势：验证步骤保证输出与原 LLM 完全一致（预测错误时回退），因此"增加并行度而不改变输出"。SpecInfer 的树形投机设计被 Medusa、EAGLE 等大量后续工作直接采用，2022–2025 年该方向持续高产（原文 Figure 3 时间线）。

架构设计（§3.1.2）——换掉 Transformer 的低效部件

五个子方向：

模型压缩（§3.1.3）

⚙️系统优化：量化、并行、内存、调度、内核

低比特量化（§3.2.1）

PTQ（训练后量化）把权重/激活降到 INT8/INT4：W8A16（weight-only）、GPTQ 的 W4A16、SmoothQuant 的 W8A8、W4A4。QAT（量化感知训练）在训练中集成量化以减少精度损失。硬件在跟进：Hopper 架构弃 INT4 换 FP8 张量核（H100 的 FP8 吞吐相对 FP32 可达 60×）。原文同时提醒：由于系统实现层面的困难，低精度方法可能反而比 FP16 更慢——量化不自动等于加速。

并行计算（§3.2.2）

并行方式切分维度特点
张量并行（TP）层内切（head/hidden 维度）降低延迟；适合同机多卡高速 NVLink；PaLM 用 2D TP 降到大规模集群
流水线并行（PP）层间切（连续层为 stage）提高吞吐但不降单请求延迟
序列并行（SP）沿序列长度切长上下文场景；ring attention / all-gather 通信；LoongServe 弹性伸缩
云上弹性抢占式实例 / serverlessSpotServe 动态调并行配置抗抢占；ServerlessLLM 多层 checkpoint 加载降冷启动
去中心化地理分布异构资源Petals 众包 GPU 服务 BLOOM-176B；Helix 用最大流做放置与调度

自动并行（Alpa、FlexFlow、Galvatron 的搜索算法换成推理代价模型）延伸出 AlpaServe、FlexFlow-Serve、SpotServe 等服务系统。

内存管理（§3.2.3）

增量解码时 KV cache 动态涨落，朴素做法（FasterTransformer）按最大序列长度预分配连续显存，严重浪费。这条线的关键节点：

1
vLLM / PagedAttention：把 KV cache 切成非连续内存块，显著提高 batch size 与吞吐——已成为行业事实标准。
2
vAttention：用 CUDA 虚拟内存管理解耦虚拟/物理分配，减少碎片并按需分配。
3
LightLLM：更细的 token 级内存管理。
原文的平衡观点：细粒度内存管理有开销——当其他优化已把 batch size 推高后，这些机制可能只带来边际吞吐收益，却放大推理延迟。内存优化与其他算法/系统优化可能互相抵消，不能默认叠加有效。

请求调度（§3.2.4）

LLM serving 相对传统 ML serving 的独特之处：模型大、自回归迭代解码、输出长度未知、上下文状态管理。Orca 首先指出请求级调度的缺口，引入迭代级调度（iteration-level scheduling）与选择性 batching——这一策略被 vLLM/RayLLM 的 continuous batching、TensorRT-LLM 的 in-flight batching 继承。后续：FastServe 用抢占按剩余长度优先缩短平均完成时间（JCT）；Sarathi-Serve 处理 prefill 长度不一造成的流水线气泡；Llumnix 动态调度；DistServe 把 prefill 与 decode 分离（disaggregation）做 goodput 优化。

内核优化（§3.2.5）

🧰开源服务系统对比

原文 Table 2 对比了十个代表性开源 GPU 服务系统（FasterTransformer、FlexFlow-Serve、vLLM、FlexGen、TGI、DeepSpeed-Inference、ZeRO-Inference、LightLLM、MLC-LLM、TensorRT-LLM），维度覆盖：TP/PP、offload、迭代级调度、prefill 与 decode 的注意力内核、主要特性。几个横向观察：

原文同时排除了两类系统：专用硬件方案（PopTransformer、CTranslate2、llama.cpp/ggml）和上层封装（OpenLLM、Xinference、LMDeploy、gpt-fast、DeepSpeed-MII、RayLLM）。

📏基准测试的现状与困境

原文 §5 的判断：社区至今没有像 MLPerf 那样公认可复现的 LLM serving 基准。困难来自四个方面：

设置组合爆炸模型配置 × 硬件 × 请求负载，少量组合测不出可信结论——某优化可能只在高低负载的一种下有优势，另一种下反而有害。
延迟口径调度开销、网络延迟等非 GPU 开销如何从推理延迟中剥离，各系统设计不同，难以对齐。
输出对齐公平的基准需要严格对齐模型输出内容，这一点常被测试忽略。
权衡校准吞吐、延迟、成本之间的权衡需要仔细设计，压缩为单一指标会失真。

现有替代品（LLM-Perf Leaderboard 比模型而非系统、LLM-Inference-Bench 比硬件、BurstGPT/Azure 生产 trace 提供请求模式）各覆盖一角。这个空档本身就是领域不成熟度的信号。

🔭六个未来方向

  1. 硬件加速器的算法-硬件协同设计：内存靠近计算单元、按 LLM 数据流塑形芯片架构；Hopper 的 HBM/SRAM/带宽增强已是先例。
  2. 高效解码算法：广义投机推理（draft 不限于小模型——检索器、用户自定义函数皆可）；投机思想已外溢到 RAG、长序列、扩散模型。
  3. 长上下文优化：模型侧有 length generalization 失败与 "lost in the middle"；系统侧 KV cache 内存与访问压力、注意力二次复杂度双重挑战。
  4. 替代架构：attention-free、纯 MLP 架构的探索；新架构反过来要求新的推理引擎与 KV cache 管理机制。
  5. 复杂环境部署：边缘、云边混合、去中心化、抢占式实例——各自带来隐私、容错、异构性等新约束。
  6. 按应用需求自动适配：PEFT 共服务（FlexLLM、Punica、S-LoRA）、多轮对话、结构化生成（XGrammar、SGLang）、多智能体链式调用——优化空间要扩展到 LLM 全生命周期。

🔍适用范围与局限

  1. 综述的时间截面：分类法覆盖到 2025 年初（接受于 2025-07）。此后出现的深推理场景调度（如 reasoning-aware batching）、更长上下文方案不在其列。
  2. GPU 中心：原文明确以 GPU 研究为主轴，TPU/FPGA/ASIC/边缘方案只在硬件一节带过。
  3. 不覆盖训练：专注 serving/inference；分布式训练的综述被列为背景参考。
  4. 精度-效率权衡无定量结论：原文指出量化可能伤精度也可能更慢，但未给出统一的决策框架——这仍是工程上需要逐案实测的问题。
  5. 基准缺失被如实承认：综述自己也提不出公认基准，系统选型目前只能靠各系统论文的实验设置（硬件、负载、指标均不一致）。
  6. 发表载体：ACM Computing Surveys 正式接收并发表，不属于预印本——但其引用的大量系统论文（vLLM、Orca、SpecInfer 等）的数字是各自论文报告值，未由综述作者统一复测。

这篇综述的持久价值在于骨架而非结论：具体系统会被超越（原文自己的 Table 2 中已有系统被后续工作替代），但"算法创新 vs 系统优化"的二分、"是否修改计算语义"的判据、以及从解码算法到内核优化的完整技术谱系，仍然是理解和组织这个领域最快的方式。对工程团队的直接启示：优先采用不改语义的系统优化（continuous batching、PagedAttention 类内存管理）作为底座，再按精度预算叠加算法创新（投机解码最安全，量化需实测）。

🔗原始来源