LLM Infra实战指南：从PagedAttention到量化部署的完整地图

从事大模型相关工作的人，迟早都会撞上同一个瓶颈：模型结构能讲得头头是道，Loss曲线也会调，但一到线上部署就卡壳——显存不够、吞吐上不去、首字延迟高得离谱。这时候你才会意识到，模型本身的进展固然重要，但真正决定一个团队能把模型用得多好的，往往是底层那层不显山不露水的Infra。LLM Infra这条线，这几年成了顶会里的热门方向，也是各路大厂和开源社区疯狂投入的战场。

这篇博文我想把这些年读过的LLM Infra相关论文、做过的一些复现实验和线上部署经验整理出来。不是什么论文综述，更像是一份踩坑记录和阅读地图。无论你是刚接触大模型工程化的新手，还是已经在做推理优化、训练加速的开发者，这篇文章的目标都是帮你把散落在各个论文里的关键思路串成一条线，同时给一些可以直接用的实操建议和排查方法。

1. LLM Infra论文图谱：先建立一个整体认知框架

1.1 什么是LLM Infra，为什么大家突然都在读论文

Infra是Infrastructure的缩写，LLM Infra指的就是让大模型能够训练起来、部署下去、跑得够快够省的那一层系统能力。它不直接研究模型参数怎么更新，而是研究这些计算任务怎么被高效地安排、调度和执行。你可以把模型比作一台高性能跑车，那Infra就是赛道、维修站、燃油供应系统和调度中心——跑车性能再猛，没有好的赛道和维护团队，实际跑起来照样拉胯。

前几年大家关注的重点还在模型架构本身，Transformer、Attention、MoE这些词满天飞。但随着模型规模到了百亿、千亿参数，训练集群动不动几百上千张卡，推理服务要求高并发低延迟，大家发现瓶颈开始转移了：显存带宽不够、卡间通信开销大、GPU利用率上不去、任务排队严重。于是，研究者和工程师开始系统性地把操作系统、分布式系统、编译优化这些经典领域的方法论，搬到大模型场景里重新做一遍，这就催生了大量LLM Infra方向的论文。

我自己感受最明显的一个变化是，以前看系统类论文会觉得离模型太远，现在再看，像PagedAttention、FlashAttention这类工作，直接决定了线上一个服务能扛多少并发、每秒钟能处理多少请求。读这些论文的收益，比读十篇调参指南来得都实在。

1.2 基础设施层论文的五大方向与代表工作

LLM Infra的论文虽然看起来散，但拆开来看，基本都能归到下面这几个方向上。我按自己在实际工作中的关注度排了个序，不一定就是学术上的权威分类，但用来建立认知框架很实用。

第一是训练框架与并行策略，核心解决"大模型怎么在多卡、多机环境下把训练跑起来"的问题。代表工作有Megatron-LM、DeepSpeed ZeRO、FSDP，它们分别从张量并行、流水线并行、数据并行和参数分片这些角度切入，解决显存装不下、计算跑不满的矛盾。读这一类论文，重点不是记住某个API，而是理解并行度切分背后的通信开销模型。

第二是推理引擎与调度优化，这是目前产业界离钱最近的方向。vLLM的PagedAttention、NVIDIA的FasterTransformer、TensorRT-LLM，以及Orion、Splitwise这类把预填充和解码阶段拆开调度的系统，都在想尽办法提高GPU利用率、降低单Token成本。核心矛盾是KV Cache的动态显存管理和请求之间的资源隔离。

第三是注意力机制的系统级优化，代表工作是FlashAttention系列和PagedAttention的底层算子优化。这类工作看似是算法优化，实质上是充分利用了GPU的SRAM层级结构，用IO感知的视角重写了Attention计算流程。

第四是量化与模型压缩，像GPTQ、AWQ、SmoothQuant，以及各种KV Cache量化方法。它们解决的是"显存不够、带宽不够"最直接的手段，把FP16变成INT8甚至INT4，用精度换吞吐。

第五是集群调度与资源管理，类似Ray、KServe这类平台层工作，解决的是GPU资源怎么按需分配、任务怎么排队、弹性伸缩怎么做。这个方向在论文里不如前几个热门，但对于生产环境的稳定性，重要性一点不低。

把这五个方向理解透了，你再看新出的论文，基本一眼就能判断它属于哪一类，解决的是训练还是推理、是单卡还是分布式、是显存瓶颈还是通信瓶颈，这对后续深读非常有帮助。

2. 推理引擎方向的经典论文拆解：从PagedAttention到vLLM

2.1 KV Cache的痛点与PagedAttention的核心思想

在推理场景里，Transformer模型自回归生成时每步都要把历史Token的Key和Value缓存下来，这就是KV Cache。它的大小和序列长度、Batch大小、层数、注意力头数直接相关，模型稍微大一点，KV Cache占的显存就非常可观。比如一个7B模型跑FP16，只算权重就要14GB显存，如果并发10个请求、上下文一长，KV Cache很容易再吃掉十几GB。更头疼的问题是，它的大小是动态变化的，不好预先分配固定空间。

传统推理框架处理KV Cache的方式是先预留一块连续显存，按最大序列长度分配。这会导致显存碎片化，内部碎片和外部碎片都很严重。做过服务端开发的人看到这个场景应该很眼熟：这不就是操作系统里的内存碎片问题吗？PagedAttention这篇论文的高明之处，就是把它当作虚拟内存分页问题来处理。

PagedAttention的核心思想是把KV Cache切分成固定大小的Block，每个Block存固定数量Token的Key和Value向量。这样逻辑上连续的KV Cache，在物理显存上可以不连续，通过Block Table来做映射。这就相当于给KV Cache做了一个"分页机制"。请求结束或者长度变化时，Block可以按需分配和释放，碎片问题大大缓解。

我读这篇论文最大的收获不是它用了什么高级算法，而是它那种"把已有系统的成熟思想迁移到新场景"的思路。操作系统里的虚拟内存管理，早就证明了对动态内存最有效的方案就是分页加页表，PagedAttention只是把这个原理重新用在了GPU显存管理上。这提醒我们，做系统优化很多时候不需要发明全新的机制，找到一个好的"参照系"就能打开思路。

2.2 vLLM的系统设计：调度、连续批处理与显存管理

vLLM是把PagedAttention落地的开源框架，它的系统设计里有几个关键模块值得展开说。

第一个是Block管理器。vLLM把KV Cache显存全部预分配成Block池，每个Block固定大小（通常按16个Token的KV大小来算）。每个序列有一个BlockTable，记录它占用了哪些Block以及对应的Token偏移。生成过程中，如果一个Block写满了就申请下一个空闲Block。当多个序列按相同Prompt前缀开始时，旧有实践里每个序列都要独立存一份前缀的KV Cache，vLLM通过Copy-on-Write机制让这些序列共享前缀Block，只有产生分叉时才复制。这个前缀共享特性在RAG场景下特别有用，因为大量请求共享同一段上下文。

第二个是连续批处理。传统的静态Batching要求一个Batch里的所有序列同进同退，等最慢的序列生成完才整体释放，这会卡住大量GPU算力。vLLM的Continuous Batching是序列级调度：一个序列完成或者达到最大长度，就把它从Batch中移除，立刻加入一个新请求。这样GPU在每个Step里始终在处理活跃的请求，吞吐量提升非常明显。我在实际测试里，用同样一张A100 80G，跑Llama-7B，vLLM对比静态Batching的Naive实现，吞吐大概有2到3倍的提升，而且越长的序列、越大的并发，差距越明显。

第三个是显存的Watermark机制。vLLM不会把全部显存都分配给KV Cache，而是留出一部分作为Watermark，防止某些极端情况下显存耗尽。控制这个比例的是gpu_memory_utilization参数，默认0.9。调成0.95可以多腾出一些KV Cache，但也会让显存更紧张，加大OOM风险。这个参数值得根据实际负载细调。

2.3 我复现vLLM推理时踩过的坑

vLLM跑起来很容易，但跑好真不容易。我分享三个比较典型的坑。

第一个是max-model-len设置不合理。它直接影响Block的数量计算。如果设得太小，长文本请求会被截断，甚至直接报错；设得太大，KV Cache预留空间变大，反而压缩了能并发处理的请求数。我的经验是先用一个探测脚本统计线上请求的P99长度，再把这个值作为max-model-len，而不是拍脑袋瞎填。

第二个是FP16和BF16的显存占用差异。有些卡比如A100原生支持BF16，精度更高而且数值范围大。vLLM里swapping、前缀缓存这些机制在BF16下的行为略有不同，实测下来推理结果一致性和显存碎片情况都有些差异。如果追求极致的吞吐指标，最好明确自己测试用的精度，不然对比数据没有说服力。

第三个是调度粒度的选择。vLLM新版支持chunked prefill，就是把一个长Prompt的预填充拆成多个小块，穿插在Decode Step之间执行。好处是延迟更平滑，坏处是吞吐会稍微下降。如果你服务的场景是长文档问答，强烈建议开启chunked prefill，不然第一个Token耗时会让用户等得崩溃；如果是短Prompt高并发，保持默认配置反而更稳。

3. 训练与调度方向的关键论文：并行策略与GPU集群编排

3.1 分布式训练的并行范式：Megatron-LM与ZeRO的核心思路

训练方向的Infra论文，核心始终围绕一个问题：参数变大了，单卡装不下，怎么拆到多卡上还能高效协作。Megatron-LM这篇论文提出的张量并行，是把一个Transformer层的参数矩阵按行或按列切开，分别放在不同GPU上，计算完再用All-Reduce通信合并结果。这种做法的好处是单卡显存压力小，但通信量大，一般只适合单机多卡这种NVLink高速互联的场景。

DeepSpeed ZeRO系列则是另一条路线。它不切计算，而是把优化器状态、梯度、参数这些"数据"切分到多卡上，每卡只持有切片。ZeRO-1切优化器状态、ZeRO-2切梯度、ZeRO-3连参数都切了。通信量比数据并行大不少，但显存节省效果非常惊人。训练一个70B模型，用ZeRO-3在单个8卡节点上勉强能跑起来，这在以前是不可想象的。

读这类论文我建议关注一个具体指标：通信量。张量并行每个Transformer层前向反向各需要2次All-Reduce；流水线并行在切分边界需要Point-to-Point通信，通信频率低但延迟敏感；ZeRO-3每个参数在每一步都要做一次Gather和Scatter。理解了这些通信模式，遇到训练效率上不去的时候，你就能快速判断瓶颈是网络带宽还是同步等待。

3.2 GPU集群调度的资源视角：异构算力与弹性伸缩

训练框架解决的是单任务怎么并行，而集群调度解决的是多任务之间怎么抢资源。LLM的到来让这个老问题有了新复杂度：任务不是单一的，有训练任务、有微调任务、有推理任务，它们的资源特征完全不同。训练要长期占用大批量GPU，推理则呈现潮汐式波动。如果还像以前那样简单按整卡分配，GPU碎片化会非常严重。

微软的论文和开源项目Ray都在这个方向上做了不少探索。它们把GPU资源抽象成可动态组合的算力池，通过调度器统一分配。推理服务可以申请1卡或半卡，训练任务可以弹性伸缩节点数，任务结束资源立刻回收到池子里。这个思路和我们做微服务时的容器编排很像，只是资源单位从CPU换成了GPU，调度维度从核数变成了显存和算力配额。

实操中还有一个经常被忽视的问题：Quota的可见性。调度系统再智能，如果业务方不知道集群还剩多少可用的GPU资源，依然会盲目排队或超卖。我们的做法是给业务方提供一个简单的资源看板，实时展示每个资源池的利用率、排队任务数、预估等待时间。这个"透明化"比任何高级调度算法都更能提升整体效率。

3.3 论文阅读方法：我的一套三遍过滤法

聊到读论文，很多朋友问我怎么才能在有限时间里把一篇系统类论文读透。我自己用的是三遍过滤法，第一遍纯看标题、摘要和图表，回答三个问题：它解决了什么问题、核心手段是什么、效果数据是什么。这一遍花15分钟，决定这篇论文值不值得精读。

第二遍才进入正文，主要看系统设计的章节和实验设置。重点关注它做了哪些取舍、基线是怎么选的、消融实验证明了哪个模块的贡献。系统论文里最值钱的部分往往是"为什么不采用另一种方案"这种讨论，作者通常会在Related Work和讨论段落里隐含地讲清楚。

第三遍是复现和转化为可执行知识。对我来说，一篇Infra论文如果没有让我产生"这个改动可以直接用到我的服务里"的冲动，我基本不会做第三遍。有些论文值得把核心代码跑一遍，比如vLLM的源码我通读过Block管理那一块；有些只需要记录核心思路，在之后做设计时能想到"这里有个方案可以参考"就够了。

4. 量化与压缩方向的论文应用：算力不够，精度来凑

4.1 GPTQ、AWQ与SmoothQuant到底在解决什么问题

量化是把模型权重从FP16压缩到INT8或者INT4，目标是减少显存占用和计算量。但直接做量化会带来精度损失，所以一系列论文都在研究"怎么压得狠还不怎么掉点"。

GPTQ的核心思路来自Optimal Brain Quantization框架。它逐层逐列地对权重做量化，每量化一列就更新剩余未量化列的值，来补偿量化误差。这个过程有点像一个拼图游戏，拿掉一块就用周围的碎块补上，尽量让整体画面不变。它的优点是量化速度快，可以在单张A100上用几十分钟完成一个7B模型的量化。

AWQ则是另一个思路，它发现不是所有权重都同等重要，少数显著权重对模型输出影响极大。AWQ的做法是根据激活值的分布来识别这些"敏感权重"，只对它们做缩放保护，其余权重正常量化。这个策略和人类学习中的"二八法则"异曲同工：保护关键的20%，就能保住80%的精度。

SmoothQuant解决的则是激活值分布不均的问题。LLM的激活值普遍存在一些Outlier，它们会放大量化误差。SmoothQuant的巧妙之处是把这个误差从激活侧"转移"到权重侧，因为权重是可以静态离线处理的，能做更精细的量化。这三篇论文代表了三类不同思路：误差补偿、敏感度识别、误差迁移。读完会很受启发，因为它们解决的是同一个问题，但切入点完全不同。

4.2 量化落地时怎么权衡效果与效率

量化不是模型大小减半那么简单。INT8的推理，在支持FP16和INT8混合计算的GPU上，Tensor Core吞吐确实可以翻倍，但前提是你的算子库已经做了良好的INT8 Kernel适配。如果只是把权重压成INT8，但Kernel仍然是FP16，那速度不会有提升，甚至因为反量化开销变得更慢。

KV Cache量化是另一个容易被忽视的收益点。长上下文场景下，KV Cache的显存占用常常超过权重，把KV Cache从FP16压缩到INT8，可以显著提高可容纳的序列长度和并发数。但KV Cache是动态产生的，它的量化不能离线做，需要在线Quantize和Dequantize，这会带来额外的计算延迟。实际项目中需要实测对比一下，比如同一个70B模型，KV Cache量化后支持的最大并发数翻了一倍，但每Token延迟增加了8%，这个交换值不值得，取决于你的业务优先级。

精度评估也是一个常说常新的话题。不要只看Perplexity，那太宏观了。最好准备一套任务级的评测集，包含代码生成、数学推理、中文问答这些真实场景，量化前后分别跑一遍对比。我在实践中的经验是：4-bit量化在绝大多数任务上的表现都够用，但某些对数值敏感的任务（比如长尾数学推理）会有明显下降，这种情况建议保留一个FP16的精裁版本给关键业务使用。

5. 论文复现与线上落地中的典型问题实录

5.1 高频问题速查表

在部署和复现这些论文方案的整个过程里，我积累了一份问题速查表，这里分享给大家。它不是标准手册，但能解决大多数"第一次搞不定"的困境。

这里还想特别提醒一点：遇到"性能诡异下降"的问题，第一步永远是监控，不是改参数。把GPU利用率、显存分配曲线、请求排队长度、P99延迟这几个指标先拉出来，看看到底是哪一层出了问题，再决定动谁的配置。跳过监控直接调参，大概率会把问题搞得更复杂。

5.2 如何把论文变成团队可复用的知识资产

单篇论文读完很容易忘，真正有价值的做法是把论文沉淀成团队的知识库。受"LLM Wiki知识库"这类概念的启发，我最近在团队内部搭了一个论文阅读知识库，这个做法值得分享。

知识库的结构很简单，每篇论文一个目录，里面包含三个文件：一篇1000字左右的精华笔记、一份代码复现记录、一组实验数据对比表。精华笔记按照"背景、问题、方案、取舍、启示"这个模板来写，代码复现记录则记录所有踩过的坑和环境依赖，实验数据对比表专门放那些关键的Benchmark数字。这样新同学进来不需要从头读十几篇论文，看一遍知识库就能对团队的技术积累有整体认知。

另外我还推荐一个小组共读机制。每周挑一篇论文，每个人先自己精读，然后小组讨论时各选一个角度来说：训练的看并行策略，部署的看推理性能，做数据的看它对RAG和长上下文的影响。视角不同，碰撞出来的东西往往比一个人闷头读有价值得多。这个方法已经帮我们团队避免了好几次"拿新方案去重造旧轮子"的尴尬。

6. 最后说几个我自己实际操作的体会

做LLM Infra方向的论文阅读和技术落地，最大的感受就是：这些系统优化的论文，不像模型论文那样靠灵感和实验巧合取胜，它们更像是一套严密的工程思维训练。每读一篇，你都会看到一个具体问题被拆解、被约束、被解决的过程。这种思维模式对做任何系统级工作都有帮助。

如果现在让我给刚入门的朋友一个具体的启动路径，我会建议先读FlashAttention，它帮助你建立"IO感知"的底层思维；然后读PagedAttention和vLLM，它是把优秀思路工程化的绝佳案例；再读一篇GPTQ或AWQ，感受一下模型压缩的取舍艺术；最后读一两篇调度或并行策略的论文，理解资源编排层面的问题。按这个顺序走一遍，你心里大概就有了一张LLM Infra的完整地图。

还有一个小经验：读论文的时候顺手追踪一下作者团队的后续工作。比如FlashAttention作者后来做的Flash-Decoding，vLLM团队的连续批处理优化，DeepSpeed团队后来的各类加速模块。一个团队的工作往往有一条完整的演化脉络，顺着脉络读，比孤立地读单篇论文要高效得多。我自己就是靠着这条"顺着作者线读"的习惯，把很多零散知识串成了体系。

在实际操作中我还发现，真正让一个人快速成长的，不单是读了多少篇论文，而是能不能在读完以后，亲手把它复现出来、改造一下、应用到自己场景里。哪怕只是把一个开源推理引擎的Block大小调了一倍，然后观察P99延迟的变化，这个"动手闭环"都能让论文里的知识沉淀到你的肌肉记忆里。希望这篇整理能给你的LLM Infra学习之路提供一些参考，咱们在各自的GPU集群上见真章。