做 LLM 应用开发和底层训练的人，最近应该都绕不开一个词：Infra。我最初接触 LLM 相关论文时也有点懵，标题里既有模型结构，又有分布式训练、推理优化，完全不知道从哪里下手。后来花了小半年时间，把训练、推理、调度这条线上一批关键论文啃了一遍，才发现所谓 LLM Infra，其实就是一套针对“模型大、数据多、算力贵”这三件事的工程解决方案。
这篇文章不是论文导读，更像一份从实战角度看 LLM Infra 论文的复盘笔记。我会从核心问题拆解、关键技术解读、复现实验流程、踩坑记录四个方面，把我在跟踪这些论文时积累的经验整理出来。适合正在做 LLM 工程化、想系统学习 infra 方向知识，或者准备大模型岗位面试的同学参考，至少能省下不少筛选文献的时间。
1. 整体视角：LLM Infra 论文到底在解决什么问题
1.1 规模变大后，工程侧的三座大山
先明确一个观点：LLM Infra 论文不是研究模型怎么变聪明的，而是研究怎么把已经很聪明的模型跑得更快、更省、更稳。三座大山分别是：显存放不下、通信来不及、算力闲不住。
显存放不下很好理解。一张 H100 是 80GB HBM，但一个 70B 模型光是参数就要占 140GB 左右，再加上训练时的梯度、优化器状态、中间激活值，显存轻松爆掉。推理侧同样头疼，虽然不需要梯度，但每生成一个 token 都要维护 KV cache，请求一多显存就像漏了底的水桶。于是你会看到 FlashAttention、ZeRO、PagedAttention 这类论文，本质上都是在跟显存做斗争。
通信来不及是所有分布式训练都要面对的问题。模型被切到多张卡之后，每一轮 iteration 里都要做梯度同步或先验通信，卡与卡之间的带宽就成了硬边界。跨节点跑的时候，就算用 NVLink 和 RDMA 网络，通信开销依然很扎眼。所以我读论文时最关注每个方案把通信量削减了多少、在什么带宽条件下具备优势，而不是只看它把显存省了多少。
算力闲不住是个老问题。GPU 的算力密度越来越高，但如果喂不进数据、算子没有高效融合、显存访问又慢，实际算力利用率会低得可怕。OpenAI 新推出的 o1 系列，据说训练主要成本大量花在推理端，这也让 AI Infra 离线训练与在线推理的占比发生变化。相关论文里干的事情，就是让 GPU 尽量满负荷干活，少等数据、少等通信、少等调度。
1.2 一个比较推荐的论文阅读路径
我不建议一上来就啃底层的并行通讯论文，很容易劝退。对于刚开始接触 LLM Infra 的人，我建议按“弹性调度 → 训练优化 → 推理优化 → 端到端系统”四个步骤读。
第一步先看 Ray 和 Kubernetes 在 AI 场景里的调度实践，理解大模型任务为什么需要专门的资源管理和任务编排。第二步看 Megatron-LM、DeepSpeed ZeRO 这一派，搞懂模型并行、数据并行、流水线并行到底是怎么把模型塞进多卡。第三步看 FlashAttention、vLLM 这一派，理解推理阶段为什么也有那么多坑。最后一步挑一两篇系统论文，比如 FastServe、DistServe，站在整个集群视角看请求调度、吞吐量和延迟的取舍。
这个顺序就像盖房子，先打地基，再砌墙，然后装修，最后考虑整屋的动线。一边读一边配合小规模实验，效果会比只看不动好很多。
2. 训练侧与推理侧的几张关键图纸
2.1 训练侧：Megatron、ZeRO 与 FlashAttention 的三重组合
训练大型语言模型时，我见过的最常见的分工是：用 DeepSpeed ZeRO-3 管模型状态（参数、梯度、优化器状态）的显存切分，配合 Megatron-LM 的张量并行（Tensor Parallelism，TP）切分模型算子，再用 FlashAttention 优化注意力计算的访存效率。
Megatron-LM 的核心是把一个 Transformer 层的矩阵乘法按行或按列切到不同 GPU 上。比如把 QKV 权重按列切开，让每张卡只算一部分，最后再通过 Allreduce 汇总结果。这个做法很直觉：模型大了塞不进单卡，就把一层的计算也拆开。但代价是通信特别密集，每一层前向反向前后都要做多次 Allreduce，所以 TP 的并行度一般不超过 8，因为超过了会严重影响扩展比。
ZeRO-3 则换了个思路，不像 Megatron 那样把计算切了，而是把参数、梯度和优化器状态分区保存，计算的时候再通过 Allgather 把参数收集到当前设备上。这样显存占用大幅降低，但同样引入了每层一次的 Allgather 通信。所以业界经常把 ZeRO-3 和 Megatron-TP 搭配使用，用 TP 减少通信量，用 ZeRO 处理塞不下的模型状态。
FlashAttention 则是从访存量下手的。它的思路非常有意思：传统 attention 为了算反向传播会保存 N×N 的注意力矩阵，显存开销是 O(N²)，FlashAttention 直接不存这个矩阵，前向时在 SRAM 里按分块计算 softmax，反向时再重算一次。牺牲了一些计算量，换来了显存占用和访存时间的大幅下降。我个人在训练 7B 模型时，加上 FlashAttention 后，训练吞吐整体提升了 10% 到 20%，效果相当可观。
2.2 推理侧：PagedAttention、Continuous Batching 与服务化
推理优化跟训练是两个世界。训练是一次性把数据喂进去，推理却是串行生成 token，每一步都依赖上一步的输出。这种特性带来了几个新问题：KV cache 怎么管理、请求怎么排队、GPU 利用率怎么提升。
vLLM 的 PagedAttention 论文是这几年推理侧最重要的思想之一。它把 KV cache 分成固定大小的 block，用类似操作系统虚拟内存的分页方式管理。这样不同请求的 KV cache 就可以不连续存储，也避免了预分配一个最长序列长度导致的大量显存浪费。我在测试中，光是把 KV cache 改成 PagedAttention，配合投机解码，QPS 就能涨好几倍。
Continuous Batching 是另一个关键概念。传统做法是等一个 batch 全部生成完再回收资源，但 LLM 生成速度不均匀，短的请求很快结束，长的请求还在慢慢跑，于是会有 GPU 空转。Continuous Batching 的思路是动态地向正在执行的 batch 里塞新的请求，只要有空出来的计算槽位就立刻补上。这套思想在 NVIDIA Triton、TensorRT-LLM 和 vLLM 里都有实现，线上推理服务基本离不开它。
服务化层的论文则更偏系统工程，比如 FastServe 尝试用预生成的 prefix 缓存降低重复前缀的推理成本，DistServe 关注把 prefill 和 decode 分开部署，避免互相拖慢。它们对生产环境的价值很直接：写代码的人不用整天盯着 QPS 曲线祈祷不掉点。这些论文里描述的虽然是一个个系统，但核心思想完全能在小项目里落地，比如用 vLLM 的 prefix caching 接口就能轻松复用公共 prompt。
2.3 补充一张表：我常拿来做方案的参考依据
| 关键论文/工具 | 解决的问题 | 核心机制 | 落地场景 | 我的使用建议 |
|---|---|---|---|---|
| Megatron-LM | 单层模型过大 | 张量并行 | 大规模训练，TP 不超过 8 | 8 卡以上才考虑，还要看 GPU 互联带宽 |
| DeepSpeed ZeRO | 模型状态显存爆炸 | 参数/梯度/优化器状态分区 | 超大模型训练，数据并行扩展 | 配合 Offload 时注意 CPU RAM 和磁盘带宽 |
| FlashAttention | 注意力显存和访存开销大 | 分块计算、重算激活 | 训练和推理都适用 | 所有新训练任务我都默认开启 |
| PagedAttention | KV cache 碎片化 | 分页管理 KV cache | 推理服务高并发 | vLLM 直接可用，长上下文场景收益更大 |
| Ray | 分布式任务调度 | Actor + 任务图 | 数据/训练/推理统一调度 | 适合做多层级的资源编排 |
| Triton Inference Server | 服务化多模型部署 | 动态 batch、并发管理 | 在线推理 | 和 vLLM 搭配，统一入口和监控 |
3. 从论文到实战：复现一个最小 LLM Infra 实验
3.1 环境准备和实验设计
读论文不等于会做工程。我建议任何人在看完训练优化类论文后，手头至少要跑一个最小实验：在一台 4×A100（40GB）机器上，微调一个 7B 模型，分别用普通 HuggingFace Trainer 和 DeepSpeed ZeRO-3 各跑一次，记录显存占用和吞吐量。这样一个实验能让你直观感受到 ZeRO 到底省了多少显存，也能顺便验证 FlashAttention 是否真的有效。
具体环境上，我推荐直接用 NVIDIA PyTorch 容器，能省去大量驱动和 CUDA 版本匹配的麻烦。代码层面用 HuggingFace Transformers 加 DeepSpeed 的配置文件，训练一个自己造的小指令微调数据集，不需要太大，一两百条就够，只要能让模型真的跑完几步就行。然后记录每秒处理的 token 数以及每 GPU 显存峰值，画个表。
我这里建议先把 batch size 设成 1 跑通，再逐步调大。原因很直接：如果 batch size=1 都会 OOM，那说明显存管理确实有问题，需要先看模型加载方式和梯度累积设置；如果 batch size=1 的显存占用还低于单卡可用的 50%，说明可以放心加 TP 或加大 batch。
3.2 关键决策与效果对比
我在做这个实验时踩过不少坑，但最有价值的几个决策值得分享。
第一个决策是用 CPU Offload 还是纯 GPU 显存切分？当时我在 4 卡机上试 7B，发现 ZeRO-3 + Offload 虽然能跑更大的 batch，但速度慢得让人抓狂，因为优化器状态在 CPU 和 GPU 之间来回搬运，每一步都要等。后来我关掉 Offload，只保留 ZeRO-3 的显存分区，batch size 小一点，吞吐反而提升了近一倍。所以 Offload 的定位是“为了跑通你本来跑不动的模型”，而不是“优化速度”的银弹。
第二个决策是启发式的把 TP 设置为 4，结果发现 7B 参数规模下 TP 带来的通信开销远大于收益。后来改回纯数据并行 + ZeRO-3，训练稳定性和速度都好了很多。这也验证了论文里的观点：模型不到一定规模，就别上张量并行，除非你的机器用的是 NVLink 全互连。
第三个决策是开启 FlashAttention。我用的是 PyTorch 官方实现的 scaled_dot_product_attention，它内部就选了 FlashAttention 内核，改动很小，但训练吞吐提升相当明显。复现实验时如果用的是 4 卡机器，还能顺手测一下序列长度从 512 提到 2048 时 FlashAttention 的优势如何扩大，因为它节省的显存和访存是跟序列长度强相关的。
3.3 推理侧复现：vLLM 部署一个服务
训练侧跑通之后，我强烈建议再复现一个推理服务。直接用 vLLM 起一个 Qwen-7B 的 OpenAI 兼容接口，然后写脚本并发请求，观察 TTFT、TPOT 和吞吐量。
以前我们用 transformers 的 generate 函数做推理，并发稍一上去就报 OOM。换成 vLLM 后，显存占用稳定了很多，因为 KV cache 是按需分配的。你可以通过环境变量控制显存使用比例，我一般留出 20% 显存给模型权重和 CUDA context，其余全给 vLLM 做 KV cache，并发请求数提升比较明显。
里面比较关键的操作是开启 prefix caching 和 stream 输出。不过要注意，stream 输出的首 token 延迟会受 PagedAttention 分页影响，实际调参时需要反复压测。我自己一般用 Locust 或者简单的 asyncio 脚本做压测，重点关注 p99 TTFT 和吞吐量，而不是只看平均值。
4. 常见问题排查与实操避坑
4.1 显存暴涨：先分清是模型、梯度还是激活值
我在复现和调优过程中最常碰见的问题就是 OOM，但 OOM 的根源可能完全不同。如果是训练刚开始就报 OOM，多半是模型状态太大，优先检查是否启用了 ZeRO 或梯度检查点；如果是训练跑到一半才 OOM，大概率是激活值突然涨了，这时候要关注序列长度和 batch size，或者开启梯度检查点降低激活缓存。
推理侧的 OOM 又不一样。很多人在 vLLM 里设了过大的 KV cache 比例，模型加载完后再申请 KV cache 时直接爆掉。建议先打印模型权重占用的显存，再动态计算剩余可用的 80% 作为 KV cache 上限。经验值是在单卡 80GB 上部署 7B 量化模型时，KV cache 别超过 50GB，否则并发高一点就会触顶。
我习惯每次实验前先用 nvidia-smi 和 torch.cuda.memory_summary 记录显存基线，这样 OOM 时能快速判断是谁吃掉了显存。论文里的显存公式可以当作预估工具，但不能完全替代实测，因为框架版本不同，同样操作的显存开销会差不少。
4.2 通信瓶颈：Allreduce 卡住怎么办
分布式训练里另一个高频问题是训练跑着跑着卡住不动，Loss 也一直不更新。这种情况一半以上是 NCCL 通信问题，尤其在使用多节点时。最常见的诱发原因是网络超时或者网卡不在同一个 subnet，NCCL 的初始化或通信都会卡死。
排查时我会先看进程日志里有没有 NCCL 相关的 error 或 timeout，然后缩小到单机内跑一个 all_reduce 的朴素 benchmark。如果单机正常、多机不行，基本可以判断是跨机网络问题，需要检查 VPC、路由、防火墙以及 RDMA 是否真的走通。这里一个小技巧是设环境变量 NCCL_DEBUG=INFO，它能打印每个 tensor 的通信路径，是谁在等谁一目了然。
通信优化不能只靠调 timeout。更实际的做法是从算法层面减少通信次数，比如把 Allgather 的次数降低，或者 ZeRO-3 改成 ZeRO-2。有些论文里讲的梯度压缩、梯度累积，在小型实验里也能见到效果，但要注意压缩带来的精度损失，最好先在验证集上多测几步。
4.3 调度混乱：Ray 和 K8s 到底怎么选
最后聊聊任务编排。很多同学用 Kubernetes 跑 LLM 训练时，会觉得 Pod 启停、挂载、环境变量管理很繁琐。我之前也在 K8s 和 Ray 之间摇摆，后来总结了一个相对清晰的选型逻辑：如果是强依赖 GPU 的推理服务，用 Kubernetes 管理生命周期更合适，因为 deployment、service、HPA 都是现成的；如果每天要跑大量不同规模的训练任务、数据任务，并且有复杂的依赖关系，用 Ray 任务提交会更顺手，因为它把资源和任务解耦得更好。
Ray 论文里的核心是分布式调度器和对象存储。实操中最让我省心的是 Ray 能直接在这些 GPU 节点上跑多机多卡的任务，不用手动改 hostfile。但它也不是没有坑，比如 Ray 默认会用零拷贝共享内存传大对象，一旦对象很大而且节点内存不够，会把 worker 整个拉死。所以我在 Ray 里跑大模型前，先设置 object_store_memory 和 memory 限制，防止临时大对象把节点内存打爆。
把训练、推理和调度串起来看，这些论文更像是基础设施领域的“拼图”：调度负责把任务摆在合适的位置，训练和推理负责把算力和显存用到极致，可观测性则负责发现问题。真正落地时，你不会只靠一篇论文的单点技术，而是需要一套工程组合拳。
最后分享一个我自己的习惯：每读完一篇 LLM Infra 相关论文，我都会写一个十分钟内能跑通的最小复现脚本，并记录下显存、吞吐、延迟三个可以直接引用的数字。这样下次再选型的时候，不需要重看论文正文，直接查自己这份运维记录就能决定用哪个方案。你如果刚开始接触这个方向，不妨也从最小实验入手，不需要一次性搞定全栈，先把一层跑通，再往上叠加。这块领域变化很快，论文只是参考权重之一，真正值得信任的还是你自己在设备上量出来的真实数据。
