LLM Infra论文系统梳理：从训练到推理的工程落地指南

1. 为什么“LLM Infra 相关论文”值得系统梳理

如果你正在做大模型相关的工程落地，不管是推理服务、训练平台、还是上层 Agent 应用，迟早会撞到同一堵墙：模型本身的能力提升越来越依赖论文里的新方法，但真正决定你能不能把模型跑起来、跑得稳、跑得便宜的，往往是 Infra 层面的东西。我刚开始接触这个方向的时候，也走过弯路——一头扎进 Transformer 结构改进的论文里，读了几十篇，结果发现线上服务该 OOM 还是 OOM，该超时还是超时。后来才慢慢意识到，LLM Infra 是一个独立且极其庞杂的知识体系，它和模型算法研究是两条并行但互相咬合的线。

所谓 LLM Infra，说白了就是“让大模型能高效跑起来的一切工程基础设施”。它涵盖的范围非常广：从底层的 GPU 显存管理、算子优化，到中间的分布式训练并行策略、推理调度引擎，再到上层的服务网关、请求路由、可观测性体系。而“LLM Infra 相关论文”这个主题，核心价值在于帮你建立一张地图——知道这个领域有哪些关键问题、每个问题对应哪些经典论文、这些论文的方法论如何转化为实际工程决策。

这篇文章适合几类人看：一是刚转入大模型工程方向的开发者，需要快速建立 Infra 全景认知；二是已经在做推理或训练平台、但想系统补课的中高级工程师；三是技术负责人，需要判断某个 Infra 方案是否值得投入。我会按照“问题域拆解 → 核心论文方法解析 → 工程落地映射 → 踩坑经验”的逻辑来展开，尽量把论文里的公式和工程里的参数对应起来，让你读完能直接拿去用。

2. LLM Infra 的问题域拆解与论文分类框架

2.1 训练侧 Infra 的核心矛盾

训练侧 Infra 要解决的根本矛盾只有一个：模型参数量和训练数据量在指数增长，但单卡显存和单机互联带宽的增长是线性的。这个剪刀差催生了一整套技术栈。最典型的问题就是——一个 70B 参数的模型，用 FP16 存储光权重就要 140GB，而单张主流加速卡的显存通常只有 80GB。你连模型都放不下，更别提优化器状态和梯度了。

围绕这个矛盾，训练侧论文大致分几个方向。第一类是并行策略，包括数据并行、张量并行、流水线并行以及它们的组合。第二类是显存优化，比如激活重计算、ZeRO 系列的分片策略、混合精度训练。第三类是通信优化，因为并行度越高，卡间通信开销越大，如何 overlap 计算和通信是核心课题。第四类是训练稳定性与效率，涉及梯度裁剪、学习率调度、故障恢复等。

我个人的经验是，读训练侧论文不要孤立地看某一篇，而要按“它解决了哪个维度的瓶颈”来归类。比如 Megatron-LM 系列主要解决张量并行下的层内切分问题，DeepSpeed ZeRO 主要解决优化器状态的显存冗余问题，PipeDream 系列主要解决流水线并行的气泡问题。你把它们放在同一个坐标系里，就能看清各自的适用边界。

2.2 推理侧 Infra 的关键挑战

推理侧和训练侧的问题域有重叠但侧重完全不同。训练追求吞吐和收敛，推理追求的是延迟、吞吐、成本三者的平衡。而且推理场景高度分化：有的是离线批量处理，追求极致吞吐；有的是在线对话，要求首 token 延迟极低；有的是长文本场景，KV Cache 会吃掉大量显存。

推理侧论文的核心方向包括：KV Cache 管理（PagedAttention、Prefix Caching）、批处理调度（Continuous Batching、Chunked Prefill）、量化压缩（GPTQ、AWQ、SmoothQuant）、投机解码（Speculative Decoding）、模型并行推理（Tensor Parallelism for Inference）。每一个方向都有若干篇标志性论文，而且这些论文的方法很多已经进入了 vLLM、TensorRT-LLM、SGLang 等主流推理框架。

这里有个很实际的判断标准：一篇推理 Infra 论文值不值得深读，看它有没有回答“在什么负载特征下，这个方法的收益最大、代价是什么”。因为推理优化几乎没有银弹，所有方法都是在特定约束下做权衡。PagedAttention 之所以成为经典，就是因为它把 KV Cache 的内存碎片问题讲透了，而且给出了可落地的分页方案。

2.3 服务与调度层的论文脉络

这一层往上看，就是 LLM 服务化之后产生的系统问题。一个典型的 LLM 服务集群，要处理请求路由、负载均衡、SLA 保障、多模型共存、弹性扩缩容等问题。相关论文涉及请求调度（如 Orca 的 iteration-level scheduling）、SLO 感知的调度（如 AlpaServe）、多租户隔离、成本优化（如 spot 实例上的推理）。

这一层的论文往往容易被忽视，因为很多工程师觉得“调度嘛，不就是负载均衡”。但实际做过线上服务的人都知道，LLM 请求的异构性极强——输入长度从几十 token 到几十万 token 不等，输出长度也不可预测，传统的轮询或最小连接数策略在这里基本失效。Orca 那篇论文提出的 iteration-level scheduling，本质上是把调度粒度从“请求级”细化到“迭代级”，让不同请求可以在同一个 batch 里交错执行，这个思路直接影响了后来 vLLM 的 continuous batching 设计。

2.4 一张分类速查表

为了让你有个整体框架，我把 LLM Infra 论文按问题域、代表论文、核心方法和工程映射整理成下表。这张表不是穷举，而是我实际读过、且认为对工程决策有直接帮助的精选。

3. 训练 Infra 核心论文深度解析与实操映射

3.1 Megatron-LM：张量并行怎么切才不亏

Megatron-LM 是 NVIDIA 的工作，核心贡献是把 Transformer 的层内计算做了张量并行切分。具体来说，它把多头注意力的 QKV 投影按头维度切分到不同卡上，把 FFN 的第一个线性层按列切、第二个线性层按行切。这样每张卡只算一部分，最后通过 All-Reduce 汇总结果。

为什么这么切？因为 Transformer 的主要计算量集中在矩阵乘法上，而矩阵乘法天然可以按行或按列拆分。按列切分时，每张卡得到部分输出，需要拼接；按行切分时，每张卡得到部分和，需要相加。Megatron 的设计让每个 Transformer 层只需要两次 All-Reduce，通信量相对可控。

实操中要注意几个点。第一，张量并行度不是越高越好。因为每增加一个并行度，就多一次通信，而卡间通信带宽是有限的。我实测下来，在单机 8 卡 NVLink 环境下，张量并行度开到 8 还能接受；但跨机走网络的话，并行度超过 2 性能就会明显下降。第二，张量并行要和流水线并行配合使用，前者解决单层放不下的问题，后者解决层数太多放不下的问题。第三，词嵌入层和输出层通常不做张量并行，因为词表维度切分后通信开销大且收益低。

注意：Megatron 的代码实现里，All-Reduce 是同步操作，如果某张卡慢了，整个 batch 都会被拖住。所以训练时尽量保证各卡负载均衡，避免某张卡上放了特别大的层。

3.2 ZeRO 与 FSDP：显存优化的分片哲学

ZeRO 的核心洞察是：数据并行下，每张卡都存了一份完整的模型参数、梯度和优化器状态，这是巨大的冗余。ZeRO 分三个阶段逐步消除冗余：Stage 1 分片优化器状态，Stage 2 再分片梯度，Stage 3 再分片参数。每推进一个阶段，显存占用降低，但通信量增加。

FSDP 可以理解为 PyTorch 原生实现的 ZeRO Stage 3，它把参数分片到各卡，前向传播时按需 All-Gather 参数，用完就释放。这样单卡显存占用大幅降低，代价是通信量增加。

这里有个关键参数需要算清楚：假设模型有 P 个参数，用 Adam 优化器，FP16 混合精度训练。优化器状态包括 FP32 的动量和方差，各占 4 字节，加上 FP32 的主权重 4 字节，总共 12 字节每参数。梯度 FP16 占 2 字节，参数 FP16 占 2 字节。所以每参数总显存约 16 字节。一个 7B 模型就需要约 112GB，单卡根本放不下。用 ZeRO Stage 3 分片到 8 卡，每卡约 14GB，加上激活值和临时缓冲区，勉强能跑。

实操心得：ZeRO Stage 3 虽然省显存，但通信开销大，训练速度会下降。如果显存够用，优先用 Stage 1 或 Stage 2。另外，FSDP 的 sharding strategy 可以选择 FULL_SHARD、SHARD_GRAD_OP、NO_SHARD，分别对应 Stage 3、Stage 2、纯数据并行，按显存压力选。

3.3 激活重计算与混合精度：省显存的经典组合

激活重计算（Activation Checkpointing）的思路很朴素：前向传播时不保存中间激活值，反向传播时重新算一遍。这样显存占用从 O(n) 降到 O(sqrt(n))，代价是计算量增加约 33%。混合精度则是用 FP16 做前向和反向计算，用 FP32 保存主权重，既省显存又加速。

这两个技术几乎是大模型训练标配。但要注意，激活重计算不是所有层都值得重算。通常只对计算量小但激活值大的层做重算，比如注意力层。FFN 层激活值相对小，重算收益不高。混合精度则要注意 loss scaling，因为 FP16 动态范围小，梯度容易下溢。现在主流框架都支持动态 loss scaling，会自动调整缩放因子。

我踩过的一个坑是：混合精度训练时，LayerNorm 和 Softmax 最好用 FP32 计算，否则数值稳定性会出问题。很多框架默认已经处理了，但如果你自己写 kernel，这点必须注意。

4. 推理 Infra 核心论文与工程落地细节

4.1 PagedAttention：把 KV Cache 当虚拟内存管

PagedAttention 是 vLLM 的基石论文，它解决的是 KV Cache 的内存碎片和浪费问题。传统做法是给每个请求预分配一块连续显存来存 KV Cache，但请求的输出长度不可预测，预分配多了浪费，少了不够用。PagedAttention 借鉴操作系统虚拟内存的分页思想，把 KV Cache 切成固定大小的 block，按需分配，逻辑上连续、物理上可以不连续。

这个设计带来的收益非常直接：显存利用率从原来的 20%-40% 提升到 90% 以上，吞吐量提升 2-4 倍。而且它天然支持 Prefix Caching——如果多个请求有相同的前缀，可以共享同一份 KV Cache block，这在 RAG 场景下特别有用，因为很多请求的系统提示词是一样的。

实操中，vLLM 的gpu_memory_utilization参数控制显存使用比例，默认 0.9。如果你的服务还有其他组件占显存，要适当调低。block_size默认 16，一般不用改，除非你有特殊的长文本场景。另外，PagedAttention 对 attention kernel 有要求，需要框架层面支持，不是随便改改就能用的。

4.2 Continuous Batching：让 GPU 不再空转

传统静态批处理的问题是：一个 batch 里所有请求必须等最长的那个生成完才能一起返回，短请求被长请求拖累，GPU 利用率低。Continuous Batching（也叫 iteration-level scheduling）的做法是：每个解码迭代结束后，完成的请求立即退出，新请求立即加入，batch 始终是满的。

Orca 论文最早系统阐述了这个思路，vLLM 把它工程化了。实测下来，在请求长度差异大的场景下，continuous batching 能把吞吐提升 3-5 倍。但要注意，它增加了调度复杂度，而且对显存管理要求更高，因为 batch 里的请求动态变化，KV Cache 也要动态分配和回收。

提示：如果你的服务请求长度比较均匀，continuous batching 的收益没那么明显。它最适合的是请求长度方差大的场景，比如同时有短问答和长文档摘要。

4.3 量化论文：GPTQ、AWQ 怎么选

量化是降低推理成本最直接的手段。GPTQ 是 post-training quantization，用校准数据逐层最小化量化误差，支持 4bit 甚至 3bit。AWQ 则发现权重里有一小部分“显著”通道对精度影响大，对这些通道保留高精度，其余量化，效果比 GPTQ 更好。

选哪个？我的经验是：如果追求极致压缩率且能接受一定精度损失，GPTQ 的 4bit 方案成熟稳定；如果对精度要求高，AWQ 通常表现更好，尤其在指令跟随任务上。SmoothQuant 则是另一条路线，它同时量化权重和激活值，适合 W8A8 场景，但实现复杂度更高。

实操中，量化后的模型要用对应的推理引擎加载。比如 GPTQ 模型用 AutoGPTQ 或 vLLM 的 GPTQ 支持，AWQ 模型用 vLLM 的 AWQ 支持。不要试图用普通加载方式加载量化模型，会报错或精度异常。

4.4 投机解码：用小模型加速大模型

投机解码的思路是：用一个小的草稿模型先快速生成若干 token，然后用大模型一次性验证这些 token 是否正确。如果正确，就接受；如果错误，就从错误位置重新生成。因为大模型验证是并行的，比逐个生成快，所以整体延迟降低。

这篇论文的关键在于草稿模型的选择和验证策略。草稿模型要足够小、足够快，同时和目标任务分布接近。验证时用拒绝采样保证输出分布和大模型一致。实测中，投机解码在延迟敏感场景下能降低 2-3 倍延迟，但吞吐不一定提升，因为草稿模型也占计算资源。

我试过在 70B 模型上用 7B 草稿模型，延迟从每 token 80ms 降到 35ms 左右，效果明显。但如果你用的是 7B 主模型，草稿模型可能只有 1B，收益就没那么大，因为主模型本身就不慢。

5. 服务调度与系统层论文的工程启示

5.1 AlpaServe：模型并行与服务调度的联合优化

AlpaServe 解决的是一个很实际的问题：当你有多个模型要服务，且每个模型可能需要模型并行时，如何分配 GPU 资源、如何调度请求，才能最大化吞吐或满足 SLA。它的核心思想是把模型并行和服务调度放在一起优化，而不是分开做。

论文里有个重要结论：模型并行不一定降低延迟，因为并行带来的通信开销可能抵消计算加速。所以是否用模型并行、用多少并行度，要根据请求负载动态决定。这个结论对工程实践很有指导意义——不要盲目上多卡推理，先算清楚通信和计算的账。

5.2 SLO 感知调度：怎么保证尾延迟

在线服务的核心指标是尾延迟，比如 P99 延迟。LLM 请求的尾延迟特别难控，因为输出长度不可预测，长请求会拖累整个 batch。SLO 感知调度的思路是：根据请求的 SLO 要求，动态调整调度优先级和 batch 组成。

具体做法包括：给短请求更高优先级、限制单个 batch 的最大 token 数、对超长请求单独处理等。这些策略在 vLLM 和 TensorRT-LLM 里都有不同程度的实现。我的经验是，SLO 保障不能只靠调度，还要配合限流和降级。当负载超过容量时，宁可拒绝部分请求，也不要让所有请求都超时。

5.3 多模型共存与显存复用

一个实际的服务集群往往要同时跑多个模型，比如一个通用对话模型、一个代码模型、一个嵌入模型。如果每个模型独占 GPU，资源利用率很低。多模型共存的技术包括：MPS（多进程服务）、MIG（多实例 GPU）、以及框架层面的显存池化。

论文层面，这方面的研究相对分散，更多是系统实现。但有个原则是通用的：显存复用要在保证隔离性的前提下做。比如 vLLM 支持多个模型共享一个 GPU，但每个模型的 KV Cache 是隔离的，避免相互干扰。

6. 常见问题与排查技巧实录

6.1 训练侧常见问题速查

6.2 推理侧常见问题速查

6.3 几个我踩过的坑

第一个坑：盲目追求高并行度。刚开始做多卡推理时，我以为并行度越高越快，结果 4 卡张量并行的延迟比单卡还高，因为通信开销太大。后来才明白，并行度要和模型大小、互联带宽匹配。小模型单卡就够了，大模型才需要并行。

第二个坑：忽视 KV Cache 的显存占用。有一次服务上线后频繁 OOM，查了半天发现是 KV Cache 没限制。长文本请求进来后，KV Cache 迅速膨胀。后来加了最大长度限制和 KV Cache 量化，问题才解决。

第三个坑：量化模型直接替换原模型。量化后的模型输出分布会变，如果下游有严格的格式要求，可能会解析失败。建议量化后做一轮完整的回归测试，不要只看 perplexity。

7. 论文阅读与工程落地的衔接方法

读 LLM Infra 论文，最忌讳的是只读不练。我的做法是：每读一篇论文，就问自己三个问题——它解决什么问题？核心方法是什么？如果我要在工程里用，需要改什么？然后尽量找一个最小可复现的场景去验证。

比如读 PagedAttention，我就在本地用 vLLM 起一个服务，对比开和不开 Prefix Caching 的吞吐差异。读 ZeRO，我就在小模型上对比 Stage 1/2/3 的显存和速度。这种“论文-代码-数据”的闭环，比单纯读论文有效得多。

另外，不要只盯着顶会论文。很多工程细节藏在框架的文档、issue 和源码里。vLLM、DeepSpeed、Megatron-LM 的 GitHub issue 里有很多真实问题的讨论，这些是论文里不会写的。我经常在 issue 里找到比论文更实用的调参经验。

最后分享一个我自己的论文管理方法：用一张表记录每篇论文的核心贡献、适用场景、工程映射和待验证问题。读的时候填表，用的时候查表。这样积累下来，你就有了自己的 LLM Infra 知识库，比任何综述都管用。