企业官网建设流程全解析

LLM Infra 这个大方向，最近两年在业界和学界的热度一直居高不下。你要是参加过几次技术大会，或者在公司里负责过大模型的部署上线，就会明显感觉到，模型结构本身已经不是最大的瓶颈，真正让人头疼的是训练跑不起来、推理太慢、显存不够、GPU利用率上不去这一堆基础设施层面的问题。我自己最开始接触这个方向的时候也是一头雾水，论文一大堆，但不知道从哪下手，看了半天感觉都懂，结果自己一搭环境就翻车。这篇文章就把我实打实读过的、跟 LLM Infrastructure 强相关的论文和工程实践做一个总结梳理，重点讲清楚每条线解决什么问题、原理是什么、工程上怎么落地，希望对正在做推理优化、训练加速或者准备入坑 LLM Infra 的工程师和研究生有帮助。

这个方向最适合三类人看：一是正在做大模型推理服务，经常被 OOM、高延迟、低吞吐折磨的；二是搞训练框架或者分布式并行策略的；三是准备转岗做 AI Infra、想系统建立知识体系的。文章会按照训练、推理、服务、调度几个维度去拆，每一块我都会尽量给出可以直接落地的结论和参数，而不是停在概念层面。

1. 先把 LLM Infra 的论文地图铺开

1.1 为什么大家都在刷 LLM Infra 的论文

先说一个我的观察：现在去看各大厂的招聘 JD，AI Infra 工程师的薪资基本是算法岗里偏高的，而且缺口很大。原因很简单，大模型从实验到产品，中间隔着“工程化”这道坎。模型结构可以靠开源社区抄，但把训练跑满 GPU、把推理延迟压到百毫秒级、把千卡集群的稳定性做到不掉点，这些全是硬功夫。

所以 LLM Infra 本质上研究的是两件事：第一，怎么样让模型训练得更快、更省；第二，怎么样让模型推理服务更便宜、更稳定。对应到论文上，一条线是训练框架和并行策略，另一条线是推理优化和 serving 系统。

1.2 我眼中的五个核心子方向

为了避免大家像我一开始那样瞎读，我通常会把 LLM Infra 论文分成五类，这样选读的时候思路会很清晰：

• 训练并行与分布式：代表方向是 Megatron-LM、ZeRO、FSDP 这类工作，核心是解决“单卡放不下、多卡怎么并行”的问题。
• 推理优化：代表方向是 KV Cache、PagedAttention、量化、投机解码，核心是降低显存占用、提高解码速度。
• Serving 系统与调度：代表方向是 Continuous Batching、PD 分离、GPU 调度器，核心是提高集群吞吐和资源利用率。
• 存储与数据管道：包括 checkpoint 保存恢复、数据加载优化、长上下文缓存等。
• 性能分析与可观测性：包括 Profiling 工具、trace 分析、GPU 利用率的归因分析。

这么分完以后，你会发现每一类论文关注的问题域很集中，读起来效率会高很多，而且工程落地的时候也容易按模块去选型。

1.3 一定要避开的阅读误区

我刚入行的时候犯过一个错，就是直接去刷最新论文，结果看十篇有一半看不懂，为什么？因为 LLM Infra 的系统性很强，很多新工作是在老思想上做增量。比如再新的推理优化论文，底层还是在跟 KV Cache 和显存管理较劲。建议先读 2020 到 2022 年之间的经典论文，把 Megatron、ZeRO、GPT 系列里的工程细节吃透，再去看 2023 年以后的 PagedAttention、Speculative Decoding、PD 分离这些，就会顺很多。

另外，论文里看到的理想数字，很可能在真实集群上打六折甚至更低。这不是论文造假，而是硬件互联、拓扑、IO 竞争这些因素论文一般都不会展开。所以读论文的时候心里要有个预期：这篇工作解决的是什么约束下的什么问题，而不是追求“最好的方案”。

2. 推理优化：从 KV Cache 到 PagedAttention

2.1 先算一笔 KV Cache 的显存账

推理优化绕不开的第一个概念就是 KV Cache。很多人一开始不知道它到底为什么这么吃显存，我用一个例子算给你看。

假设你有一个 7B 参数的模型，层数是 32，注意力头数是 32，每个头的维度是 128，所以模型的 hidden size 就是 4096。推理的时候，如果当前序列长度是 2048，batch size 是 8，那么 KV Cache 的显存大概是这样算：

KV Cache 大小 = 2（K 和 V 两份） × 层数 × 序列长度 × batch size × hidden size × 每个元素字节数。

套进去就是：2 × 32 × 2048 × 8 × 4096 × 2（FP16）约等于 8.6 GB。这只是单条序列场景下的估算，如果上下文长度拉到 32K，batch 再大点，KV Cache 轻松突破几十 GB，比模型权重本身还占地方。

这也是为什么长上下文推理成本高得吓人的原因之一。之前我看到一些团队用 vLLM 跑 32K 上下文，稍微并发大一点直接 OOM，排查了半天才发现是 KV Cache 把显存吃光了，模型权重反而没占多少。

2.2 PagedAttention 到底解决了什么问题

PagedAttention 是 2023 年非常有代表性的一篇论文，vLLM 的核心算法。它的灵感来自操作系统的虚拟内存分页。传统做法是给每个请求的 KV Cache 预先分配一块连续显存，大小按最大可能长度预留。问题是大部分请求实际用不了这么长，碎片和浪费极其严重，显存利用率有时候不到一半。

PagedAttention 的思路是把 KV Cache 切分成固定大小的块，按需分配，不要求物理连续。这样就能像操作系统一样按页管理显存，利用率大幅提升。配合 vLLM 的 Continuous Batching 机制，吞吐相对于 HuggingFace 原生实现可以提升数倍。

工程上的建议是，如果公司内部推理服务重度使用长上下文，vLLM 这类基于 PagedAttention 的方案基本是首选。但要注意，PagedAttention 对某些算子融合有要求，如果模型代码比较魔改，可能需要额外适配，这块要提前评估。

2.3 连续批处理为什么是推理吞吐的救星

连续批处理（Continuous Batching）这个概念我单独拿出来说，是因为它解决了静态批处理最大的痛点。静态批处理的逻辑很简单：攒够一批请求，一起跑，等这批全部结束才处理下一批。但是 LLM 推理是自回归解码，每个请求的生成长度差很多。有的请求 100 个 token 就完事了，有的要 1000 个，短的只能干等长的跑完，GPU 就这么被白白耗着。

连续批处理的思路是，在请求粒度上动态调度。某一个请求提前生成完了，立刻把它从批里移出去，把新请求塞进来。这样 GPU 始终在处理活跃请求，不会因为少数长尾请求拖累整体吞吐。vLLM 和 TGI 都能做到这一点，实测下来，长尾请求越多，提升越明显。

2.4 量化和投机解码是另外两条捷径

除了显存和调度，推理速度还深受解码步数的限制。解码是逐 token 进行的，每一步都跑一次完整前向，延迟高。量化是把权重甚至激活值从 FP16 压到 INT8 或者 INT4，显存和带宽压力降低，速度自然提升。常用的方案有 GPTQ、AWQ，工程上跑 FP8 或者 W4A16 的也很多。

投机解码的思路更取巧：先用一个小模型快速生成若干个候选 token，再用大模型一次并行验证。验证通过就一次性接受多个 token，相当于把多个解码步合并了。论文里最经典的是 DeepMind 的 Speculative Decoding。我实际测试中，在选择合适的 draft model 之后，吞吐提升可以达到 1.5 到 2 倍，但 draft model 的接受率很关键，接受率低的话反而浪费算力。

3. 训练侧的硬核问题：并行策略、通信与调度

3.1 一张表看懂 DP、TP、PP、ZeRO 的区别

训练侧第一个绕不开的问题就是并行策略。我见过不少人在 8 卡机器上跑大模型，一上来就想着张量并行，结果性能反而不如纯数据并行。原因是没有搞清楚不同并行方式的通信开销和适用场景。

数据并行是最简单的思路，每张卡放完整的模型副本，各处理一部分 batch，最后梯度做一下 all-reduce。问题是模型一大，单卡放不下完整模型了，数据并行就失效了。

张量并行是把 transformer 某一层的权重切成多份，分别放在不同的 GPU 上，计算的时候通过 all-reduce 汇总。通信量很大，所以只在单机 8 卡这种 NVLink 高速互联的环境下效果好。

流水线并行是模型按层切成若干段，每个 GPU 负责一段。通信很少，但是流水线启动和排空会有气泡，理想情况下也只能把利用率做到接近 90% 左右，跟具体切分方式关系很大。

ZeRO 是微软提出的一套思路，核心是把优化器状态、梯度、模型参数分片存到不同 GPU 上，需要用的时候再收集。它不像 TP 那样需要频繁的 all-reduce，更像“用时拉取”，扩展性比 TP 好。

实际训练 30B 以上模型时，我一般建议组合使用：节点内做 TP，节点间做 PP，再加 ZeRO 做显存卸载，这就是典型的 3D 并行。

3.2 混合并行背后的通信成本模型

选并行策略不能靠拍脑袋，要理解通信成本和集群拓扑。TP 的通信量是最恐怖的，因为每一层 transformer 都需要多次 all-reduce。假设模型 hidden size 是 8192，TP=8，则每一次 all-reduce 传输的数据量级是 2 × 8192 × batch × seq × 2 字节，一次前向就有几十次这样的操作。如果跨节点做 TP，走千兆以太网，几乎必崩。

所以好的策略是：能在一个节点内用 NVLink 解决的尽量不跨节点，跨节点的通信交给 PP 和 ZeRO 这种通信频率低的方式。之前我们组有一次训练效率奇差，查到最后发现 grouping 没配置好，TP 跨了节点，结果 NCCL 每次通信都要走 TCP，性能掉了好几倍。改完网络拓扑分组之后，吞吐稳定上升。

3.3 Checkpoint、弹性训练和调度器

训练侧的另一个大坑是容错和调度。千卡集群上单卡故障是常态，如果 checkpoint 频率太低，故障恢复重来，时间成本大到怀疑人生。业界常规做法是配置异步 checkpoint，把全量状态定期持久化到高性能存储，避免阻塞训练主循环。

调度器方面，Kubernetes + 排队系统已经是标配。调度器负责回答几个问题：哪个 job 先跑、跑在哪批机器上、有没有抢占机制。这里比较关键的一点是 bin-packing，尽量把需要高带宽通信的 job 分配到同一个交换机域内，否则训练性能直接被打折扣。

从论文上看，微软的 Singularity、Google 的论文关于集群调度都有很多值得借鉴的设计，包括任务的分层调度、弹性伸缩、容错重跑。工程落地的时候，你不需要从头造轮子，但至少要能看懂调度日志，知道 job 为什么排队、为什么被抢占。

4. 从论文到工程：框架选型与落地实操

4.1 开源推理框架怎么选

论文读多了，最终还是要落地。目前主流的开源推理框架有这么几个：vLLM、TensorRT-LLM、TGI、SGLang，各有优劣，我直接给选型建议。

我做过的项目里，80% 的情况我会推荐 vLLM。一是吞吐好，二是社区更新快，遇到问题很容易搜到解决方案。但如果是低延迟硬要求，TensorRT-LLM 确实能比 vLLM 再快一些，代价是你得花不少时间去优化、调试图编译问题。

4.2 关键性能指标与压测方法

框架选完以后，一定要建立一套可量化的评估标准。我看过很多人调优推理服务，最后只盯着 GPU 利用率这一个指标，这是很片面的。

核心指标我建议至少看这五个：

• TTFT（Time To First Token）：首 token 延迟，直接影响用户体验。
• ITL（Inter-Token Latency）：生成过程中 token 之间的间隔，可以理解成“打字速度”。
• 吞吐（Tokens per Second）：整机整卡单位时间生成的 token 数。
• 并发能力：在保持 SLO 的前提下能支撑的最大并发数。
• 显存占用：KV Cache 和模型权重的占比，调度是否合理。

压测的时候不要只看一个 batch 的跑分，要模拟真实场景，比如混合长度请求、随机并发、突发流量。我习惯先用 Locust 或自写脚本压一轮静态数据，再做一次真实流量的回放测试。很多系统静态压测一切正常，一上生产就被长尾请求搞崩，就是因为没压出碎片化场景。

4.3 我踩过的一些工程坑，提前给你排掉

最后分享几个实战中遇到的坑，每一个都花了不少时间去定位。

第一个坑是显存碎片化。早期用非 PagedAttention 方案时，明明显存总量够，但跑几个长上下文请求就 OOM，后来发现是碎片化问题。解决办法要么换成 vLLM，要么调低 gpu_memory_utilization 留出缓冲，给 KV Cache 预留足够空间。

第二个坑是 Continuous Batching 下 prefill 和 decode 竞争资源。prefill 阶段计算密集，decode 阶段访存密集，两者混跑时可能出现 prefill 卡住 decode、token 输出延迟飙升的情况。解决方案是考虑 PD 分离部署，或者设置两个阶段的配额限制。

第三个坑是量化后精度退化。量化模型上线前一定要挑一批跟业务强相关的 prompt 做质量回归，不要只看跑分和延迟。我遇到过一个小规模的 4bit 量化模型，自动化评测指标只降了 1%，但业务方反馈回答明显变差，最后还是退回了 FP16，实在不行就做 KV Cache 量化而不是权重量化。

第四个坑是并发超时和排队堆积。很多团队只压了单实例性能，没有做负载均衡和限流。生产环境一旦流量突增，下游请求排队时间会迅速超过 SLO，前端表现就是“网络错误”。引入合理的限流、快速失败和重试策略以后，整体稳定性会好很多。

我在实际落地过程中还有一个体会：LLM Infra 不是一个“读几篇论文就能搞定”的方向，它非常依赖对硬件、框架和业务的综合理解。论文给你的是上限和方向，工程细节决定你能达到多少。遇到问题别慌，先量化、再定位、最后优化，这个顺序永远比凭感觉调参靠谱。如果你正准备入坑，文章里提到的这些方向足够撑起一条相对完整的路线，剩下的就是去线上环境里摸爬滚打，踩几次坑比读十篇论文都管用。