从事大模型相关工作的人迟早都会撞上同一个瓶颈模型结构能讲得头头是道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到vLLM2.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 CachevLLM通过Copy-on-Write机制让这些序列共享前缀Block只有产生分叉时才复制。这个前缀共享特性在RAG场景下特别有用因为大量请求共享同一段上下文。第二个是连续批处理。传统的静态Batching要求一个Batch里的所有序列同进同退等最慢的序列生成完才整体释放这会卡住大量GPU算力。vLLM的Continuous Batching是序列级调度一个序列完成或者达到最大长度就把它从Batch中移除立刻加入一个新请求。这样GPU在每个Step里始终在处理活跃的请求吞吐量提升非常明显。我在实际测试里用同样一张A100 80G跑Llama-7BvLLM对比静态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 高频问题速查表在部署和复现这些论文方案的整个过程里我积累了一份问题速查表这里分享给大家。它不是标准手册但能解决大多数第一次搞不定的困境。问题现象可能原因排查方法和解决思路显存直接OOMKV Cache预留过大或Block分配过细调低gpu_memory_utilization检查并发数和max-model-len的乘积推理吞吐低但GPU利用率不高数据加载或Tokenization成了瓶颈增加预处理并行度用AsyncTokenization或把Prompt预处理放到独立进程多卡训练Loss掉得厉害通信因子未优化梯度同步过于频繁检查梯度累积步数确认All-Reduce是否走NVLink而非PCIe量化后模型输出明显变差校准数据集与业务数据分布差异大改用业务真实数据重新做Calibration考虑使用AWQ保护敏感权重长上下文请求被截断max-model-len设太小或者Truncate策略激进统计线上P99序列长度在接入层做超长文本的分段摘要显存碎片化严重运行时间越久越卡长期运行未做Block Defragmentation定期滚动重启服务审慎使用vLLM的swap尽量靠调度质量避免Swap这里还想特别提醒一点遇到性能诡异下降的问题第一步永远是监控不是改参数。把GPU利用率、显存分配曲线、请求排队长度、P99延迟这几个指标先拉出来看看到底是哪一层出了问题再决定动谁的配置。跳过监控直接调参大概率会把问题搞得更复杂。5.2 如何把论文变成团队可复用的知识资产单篇论文读完很容易忘真正有价值的做法是把论文沉淀成团队的知识库。受LLM Wiki知识库这类概念的启发我最近在团队内部搭了一个论文阅读知识库这个做法值得分享。知识库的结构很简单每篇论文一个目录里面包含三个文件一篇1000字左右的精华笔记、一份代码复现记录、一组实验数据对比表。精华笔记按照背景、问题、方案、取舍、启示这个模板来写代码复现记录则记录所有踩过的坑和环境依赖实验数据对比表专门放那些关键的Benchmark数字。这样新同学进来不需要从头读十几篇论文看一遍知识库就能对团队的技术积累有整体认知。另外我还推荐一个小组共读机制。每周挑一篇论文每个人先自己精读然后小组讨论时各选一个角度来说训练的看并行策略部署的看推理性能做数据的看它对RAG和长上下文的影响。视角不同碰撞出来的东西往往比一个人闷头读有价值得多。这个方法已经帮我们团队避免了好几次拿新方案去重造旧轮子的尴尬。6. 最后说几个我自己实际操作的体会做LLM Infra方向的论文阅读和技术落地最大的感受就是这些系统优化的论文不像模型论文那样靠灵感和实验巧合取胜它们更像是一套严密的工程思维训练。每读一篇你都会看到一个具体问题被拆解、被约束、被解决的过程。这种思维模式对做任何系统级工作都有帮助。如果现在让我给刚入门的朋友一个具体的启动路径我会建议先读FlashAttention它帮助你建立IO感知的底层思维然后读PagedAttention和vLLM它是把优秀思路工程化的绝佳案例再读一篇GPTQ或AWQ感受一下模型压缩的取舍艺术最后读一两篇调度或并行策略的论文理解资源编排层面的问题。按这个顺序走一遍你心里大概就有了一张LLM Infra的完整地图。还有一个小经验读论文的时候顺手追踪一下作者团队的后续工作。比如FlashAttention作者后来做的Flash-DecodingvLLM团队的连续批处理优化DeepSpeed团队后来的各类加速模块。一个团队的工作往往有一条完整的演化脉络顺着脉络读比孤立地读单篇论文要高效得多。我自己就是靠着这条顺着作者线读的习惯把很多零散知识串成了体系。在实际操作中我还发现真正让一个人快速成长的不单是读了多少篇论文而是能不能在读完以后亲手把它复现出来、改造一下、应用到自己场景里。哪怕只是把一个开源推理引擎的Block大小调了一倍然后观察P99延迟的变化这个动手闭环都能让论文里的知识沉淀到你的肌肉记忆里。希望这篇整理能给你的LLM Infra学习之路提供一些参考咱们在各自的GPU集群上见真章。