LLM Infra 这个大方向最近两年在业界和学界的热度一直居高不下。你要是参加过几次技术大会或者在公司里负责过大模型的部署上线就会明显感觉到模型结构本身已经不是最大的瓶颈真正让人头疼的是训练跑不起来、推理太慢、显存不够、GPU利用率上不去这一堆基础设施层面的问题。我自己最开始接触这个方向的时候也是一头雾水论文一大堆但不知道从哪下手看了半天感觉都懂结果自己一搭环境就翻车。这篇文章就把我实打实读过的、跟 LLM Infrastructure 强相关的论文和工程实践做一个总结梳理重点讲清楚每条线解决什么问题、原理是什么、工程上怎么落地希望对正在做推理优化、训练加速或者准备入坑 LLM Infra 的工程师和研究生有帮助。这个方向最适合三类人看一是正在做大模型推理服务经常被 OOM、高延迟、低吞吐折磨的二是搞训练框架或者分布式并行策略的三是准备转岗做 AI Infra、想系统建立知识体系的。文章会按照训练、推理、服务、调度几个维度去拆每一块我都会尽量给出可以直接落地的结论和参数而不是停在概念层面。1. 先把 LLM Infra 的论文地图铺开1.1 为什么大家都在刷 LLM Infra 的论文先说一个我的观察现在去看各大厂的招聘 JDAI 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 到 PagedAttention2.1 先算一笔 KV Cache 的显存账推理优化绕不开的第一个概念就是 KV Cache。很多人一开始不知道它到底为什么这么吃显存我用一个例子算给你看。假设你有一个 7B 参数的模型层数是 32注意力头数是 32每个头的维度是 128所以模型的 hidden size 就是 4096。推理的时候如果当前序列长度是 2048batch size 是 8那么 KV Cache 的显存大概是这样算KV Cache 大小 2K 和 V 两份 × 层数 × 序列长度 × batch size × hidden size × 每个元素字节数。套进去就是2 × 32 × 2048 × 8 × 4096 × 2FP16约等于 8.6 GB。这只是单条序列场景下的估算如果上下文长度拉到 32Kbatch 再大点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 卡机器上跑大模型一上来就想着张量并行结果性能反而不如纯数据并行。原因是没有搞清楚不同并行方式的通信开销和适用场景。并行方式切分维度通信开销适用规模数据并行 DP按 batch 切分每步梯度 all-reduce通信量随模型尺寸增长单机多卡或小规模集群张量并行 TP按层内权重切分每层多次 all-reduce通信非常密集单机内部适合 NVLink 互联流水线并行 PP按层切分仅相邻 stage 间通信通信量小但存在气泡跨机场景适合千卡以上ZeRO / FSDP把优化器状态、梯度、参数分片通信量相对可控便于水平扩展大规模训练避免 TP 的通信瓶颈数据并行是最简单的思路每张卡放完整的模型副本各处理一部分 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 是 8192TP8则每一次 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各有优劣我直接给选型建议。框架核心优势适合场景注意事项vLLMPagedAttention吞吐高社区活跃公司内部标准推理服务需要匹配模型算子少数模型需适配TensorRT-LLM算子优化极致延迟低对延迟要求极高的场景导出 TensorRT 引擎耗时调试难度高TGIHuggingFace 生态好部署简单快速上线的场景性能上限略低于 vLLM 和 TensorRT-LLMSGLang结构化生成多模态支持好Agent 场景的复杂调用生态还在快速变化接口不稳定我做过的项目里80% 的情况我会推荐 vLLM。一是吞吐好二是社区更新快遇到问题很容易搜到解决方案。但如果是低延迟硬要求TensorRT-LLM 确实能比 vLLM 再快一些代价是你得花不少时间去优化、调试图编译问题。4.2 关键性能指标与压测方法框架选完以后一定要建立一套可量化的评估标准。我看过很多人调优推理服务最后只盯着 GPU 利用率这一个指标这是很片面的。核心指标我建议至少看这五个TTFTTime To First Token首 token 延迟直接影响用户体验。ITLInter-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 不是一个“读几篇论文就能搞定”的方向它非常依赖对硬件、框架和业务的综合理解。论文给你的是上限和方向工程细节决定你能达到多少。遇到问题别慌先量化、再定位、最后优化这个顺序永远比凭感觉调参靠谱。如果你正准备入坑文章里提到的这些方向足够撑起一条相对完整的路线剩下的就是去线上环境里摸爬滚打踩几次坑比读十篇论文都管用。
LLM Infra 这个大方向最近两年在业界和学界的热度一直居高不下。你要是参加过几次技术大会或者在公司里负责过大模型的部署上线就会明显感觉到模型结构本身已经不是最大的瓶颈真正让人头疼的是训练跑不起来、推理太慢、显存不够、GPU利用率上不去这一堆基础设施层面的问题。我自己最开始接触这个方向的时候也是一头雾水论文一大堆但不知道从哪下手看了半天感觉都懂结果自己一搭环境就翻车。这篇文章就把我实打实读过的、跟 LLM Infrastructure 强相关的论文和工程实践做一个总结梳理重点讲清楚每条线解决什么问题、原理是什么、工程上怎么落地希望对正在做推理优化、训练加速或者准备入坑 LLM Infra 的工程师和研究生有帮助。这个方向最适合三类人看一是正在做大模型推理服务经常被 OOM、高延迟、低吞吐折磨的二是搞训练框架或者分布式并行策略的三是准备转岗做 AI Infra、想系统建立知识体系的。文章会按照训练、推理、服务、调度几个维度去拆每一块我都会尽量给出可以直接落地的结论和参数而不是停在概念层面。1. 先把 LLM Infra 的论文地图铺开1.1 为什么大家都在刷 LLM Infra 的论文先说一个我的观察现在去看各大厂的招聘 JDAI 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 到 PagedAttention2.1 先算一笔 KV Cache 的显存账推理优化绕不开的第一个概念就是 KV Cache。很多人一开始不知道它到底为什么这么吃显存我用一个例子算给你看。假设你有一个 7B 参数的模型层数是 32注意力头数是 32每个头的维度是 128所以模型的 hidden size 就是 4096。推理的时候如果当前序列长度是 2048batch size 是 8那么 KV Cache 的显存大概是这样算KV Cache 大小 2K 和 V 两份 × 层数 × 序列长度 × batch size × hidden size × 每个元素字节数。套进去就是2 × 32 × 2048 × 8 × 4096 × 2FP16约等于 8.6 GB。这只是单条序列场景下的估算如果上下文长度拉到 32Kbatch 再大点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 卡机器上跑大模型一上来就想着张量并行结果性能反而不如纯数据并行。原因是没有搞清楚不同并行方式的通信开销和适用场景。并行方式切分维度通信开销适用规模数据并行 DP按 batch 切分每步梯度 all-reduce通信量随模型尺寸增长单机多卡或小规模集群张量并行 TP按层内权重切分每层多次 all-reduce通信非常密集单机内部适合 NVLink 互联流水线并行 PP按层切分仅相邻 stage 间通信通信量小但存在气泡跨机场景适合千卡以上ZeRO / FSDP把优化器状态、梯度、参数分片通信量相对可控便于水平扩展大规模训练避免 TP 的通信瓶颈数据并行是最简单的思路每张卡放完整的模型副本各处理一部分 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 是 8192TP8则每一次 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各有优劣我直接给选型建议。框架核心优势适合场景注意事项vLLMPagedAttention吞吐高社区活跃公司内部标准推理服务需要匹配模型算子少数模型需适配TensorRT-LLM算子优化极致延迟低对延迟要求极高的场景导出 TensorRT 引擎耗时调试难度高TGIHuggingFace 生态好部署简单快速上线的场景性能上限略低于 vLLM 和 TensorRT-LLMSGLang结构化生成多模态支持好Agent 场景的复杂调用生态还在快速变化接口不稳定我做过的项目里80% 的情况我会推荐 vLLM。一是吞吐好二是社区更新快遇到问题很容易搜到解决方案。但如果是低延迟硬要求TensorRT-LLM 确实能比 vLLM 再快一些代价是你得花不少时间去优化、调试图编译问题。4.2 关键性能指标与压测方法框架选完以后一定要建立一套可量化的评估标准。我看过很多人调优推理服务最后只盯着 GPU 利用率这一个指标这是很片面的。核心指标我建议至少看这五个TTFTTime To First Token首 token 延迟直接影响用户体验。ITLInter-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 不是一个“读几篇论文就能搞定”的方向它非常依赖对硬件、框架和业务的综合理解。论文给你的是上限和方向工程细节决定你能达到多少。遇到问题别慌先量化、再定位、最后优化这个顺序永远比凭感觉调参靠谱。如果你正准备入坑文章里提到的这些方向足够撑起一条相对完整的路线剩下的就是去线上环境里摸爬滚打踩几次坑比读十篇论文都管用。
