你有没有经历过这种事算法同事把一个开源大模型的权重文件丢过来说“跑个推理服务接上线上流量”。你打开目录一看权重好几个文件加起来几百个G再看手头的GPU服务器单机8卡、每卡80G显存好像也装得下。可真上线一压测单机8卡并发稍微一起来不是超时就是显存溢出GPU利用率却低得可怜百分之十几是常态。你会发现推理这玩意儿跟训练完全是两码事显存要管、带宽要算、批次要盯、排队要控。这篇文章就聊聊我这些年搭建大规模分布式推理系统的实操经验模型太大怎么切并发太高怎么扛延迟怎么压下来出问题怎么查。适合那些正在或准备把大模型推上线的工程同学参考。1. 大规模分布式推理到底在解决什么问题1.1 一张卡装不下的现实先算一笔最简单的账。一个700亿参数的稠密模型如果用FP16存储权重单份权重就是140GB左右。市面上单卡显存最大也就80G一张卡根本装不下。就算用INT8量化70GB权重依然顶到单卡上限KV Cache、激活值这些东西还没地方放。所以第一个分布式理由非常朴素显存不够必须把模型切到多张卡上。但显存问题不只是权重。Transformer在生成长文本时每一步都要把历史上所有token的Key和Value缓存下来这部分叫KV Cache。它的特点是随请求数量线性增长并发越高、上下文越长KV Cache占用越大。很多团队上线后第一次OOM不是权重放不下而是并发一起来KV Cache把显存冲爆了。所以构建分布式推理系统第一步不是选框架而是把显存账算清楚权重占多少、激活占多少、KV Cache峰值会到多少、多卡均摊之后每卡剩多少。这笔账算明白了后面的方案选型才不会跑偏。1.2 比显存更隐蔽的瓶颈算力、带宽、调度显存是硬约束但单纯把模型塞进显存不代表系统能扛住流量。推理是自回归过程一个token一个token地生成每一步都有一堆矩阵乘法在等。GPU算力再强也架不住批大小上不去、GPU空转。带宽是第二个容易被忽视的瓶颈。模型一旦切到多卡每层前向计算都可能涉及卡间通信。单机内的高性能总线很快但跨机器的网卡带宽通常差一个数量级。很多团队把TP张量并行跨机器做结果推理速度直接腰斩就是因为通信把计算时间全吃掉了。调度问题则更隐蔽。推理请求长短不一有人问一句“你好”有人甩一篇几千字的文档。如果调度器不聪明短请求会被长请求堵在队列里P99延迟瞬间爆表。显存预留策略、批处理策略、排队策略每一样都直接影响用户体验。可以说分布式推理系统本质上是在显存、算力、带宽、调度四条约束下求最优解。1.3 先定指标再动手做架构之前一定要先定指标否则无从谈“够用”。推理服务最核心的指标有三个TTFT首个token延迟用户发出请求到收到第一个字的时间。在线交互场景要求严格一般要控制在1秒内。TPOT每token生成延迟后续每个字生成的间隔直接决定用户感觉“流畅”还是“卡顿”。吞吐量TPS单位时间能处理多少请求或生成多少token。离线批处理场景更看重这个。不同场景的优化目标完全不一样。做机器人客服TTFT是命根子做批量离线分析吞吐量才是关键做流式生成内容TPOT必须稳定。我见过不少团队一上来就追求大并发结果TTFT冲到3秒以上线上用户疯狂投诉。正确做法是先根据业务场景定目标再反推需要的显存、带宽和批大小最后才是选框架和服务器。2. 并行策略选型的核心逻辑2.1 张量并行算力的平面切割张量并行TP是把一层网络的矩阵运算切成几块分到多张卡上并行算算完再汇总。比如一个矩阵乘法权重矩阵按行切开、按列切开分别计算最后通过一次通信把结果合并。它的好处是单卡显存压力小且GPU利用率高坏处是通信极其频繁——每层都要做两次全规约AllReduce通信量跟隐藏层维度成正比。TP通信量可以粗略估算假设隐藏层维度是8192批内token总数是2048FP16类型那么单层一次AllReduce传输的数据量约为4×8192×2048×2字节即128MB左右。一次前向里Attention和MLP各要做一次AllReduce传输量就是256MB。70B模型大概80层一次前向光通信就是20GB以上。这个数据量放在有高速互联的节点内还能接受但放到跨机器的普通网卡上基本就是灾难。所以我的原则很明确TP只在单机内部做不跨节点。先通过卡间通信拓扑工具确认哪些卡在同一高速互联域内TP就限制在这个范围内。否则你优化了半天算子最后全耗在等网络上了。2.2 流水线并行模型的纵向分段流水线并行PP是把Transformer按层切成多段每张卡负责其中一段。前一段算完把中间结果传给下一段像工厂流水线一样。相比TPPP的通信量小得多——每台机器只需在段边界传一次中间激活值不需要频繁的AllReduce。PP的短板是气泡bubble。一个批次的数据从第一段流到最后一段后面的卡在开始时是空闲的前面的卡在收尾时也是空闲的。如果不做微批次切分GPU利用率会很低。工程上一般会引入多个微批次交错执行让流水线尽量填满但气泡不可能完全消除只是缩小。PP的典型应用场景是模型大到单机8卡放不下必须扩展到两台以上机器时。这时节点内仍然用TP节点之间用PP把跨机器通信降到最低。千万别反过来——跨机器用TP那会把自己坑死。2.3 数据并行与多副本对吞吐的最终补充TP和PP解决的是“一个模型装不下”的问题而数据并行DP解决的是“一个模型副本扛不住并发”的问题。数据并行就是复制整套模型组到更多机器上每台机器处理不同的请求前端用负载均衡把流量分散开。数据并行是提升吞吐量最直接的方式没有之一。你的并发需求翻倍最省事的路就是再加一组副本。但它的缺点也直白——烧钱。每组副本都要一整套显存和算力资源成本线性增长。在实际系统中DP并不是一个独立选项而是与TP、PP叠加使用。先决定一个“计算组”内怎么切分TPPP然后把计算组复制成N份形成多副本。副本之间完全独立还能顺带提升可用性——某个副本出故障流量自动切到别的副本这对在线服务来说非常宝贵。2.4 一个可落地的组合方案以常见的70B稠密模型、8卡80G节点、两台节点为例我会这样规划节点内TP88张卡通过高性能总线互联共同负责模型的一段或全部层。跨节点PP2两个节点各负责一半层数节点间只传中间激活。如果需要更高吞吐把TPPP的这套组合完整复制成两个甚至更多副本放在网关后面做负载均衡。这套组合的优点是TP的性能红利吃满PP把跨节点通信量降到极低DP把吞吐量横向拉满。它不是最炫的方案但它是稳定性最高、踩坑最少的方案。很多框架默认走的也是这个路子只是把细节藏在了配置项里。3. 推理引擎里的关键机制显存与批处理3.1 KV Cache被忽略的显存大头很多人以为推理时显存占用 ≈ 权重大小这是大错特错的。KV Cache才是真正会“呼吸”的显存占用者。KV Cache的计算公式很简单每个token的KV占用 2 × 层数 × KV头数 × 头维度 × 字节数。以70B模型为例80层、KV头数8、头维度128、FP16每个token要占2×80×8×128×2约0.33MB。如果平均上下文加生成长度是2048 token单个请求的KV Cache就是约670MB。32个并发请求同时在线仅KV Cache就要占用约21GB显存。这个数字会随着并发和序列长度飙升。上下文长度翻倍KV Cache翻倍并发翻倍KV Cache也翻倍。很多团队压测到一半爆显存就是因为只算了权重完全没算KV Cache。所以现代的推理框架普遍把KV Cache做成独立管理模块而不是随请求随意malloc。批大小、并发上限、KV Cache占用率这几个参数必须联动调整否则系统不稳。3.2 从静态批处理到连续批处理推理服务的批处理策略是决定GPU利用率的核心。早期的推理服务用静态批处理凑够一批固定数量的请求开始计算这批全部生成完再放下一批。问题在于请求长短不一短请求早早结束却要等长请求一起收工GPU资源空转延迟也难看。当时我问过自己一个问题餐厅翻桌为什么不等到所有客人吃完一起收拾明显不合理。连续批处理Continuous Batching解决的就是这个问题。它把批处理粒度从“请求级”降到了“迭代级”每个生成步结束后已经结束的请求立刻退出新请求立刻补位。长请求不会堵住短请求GPU始终在处理活跃请求吞吐量和时延同时得到改善。这个机制现在已经是主流推理框架的标配。如果你用的框架还不支持连续批处理说实话那基本不用费力调参了直接换方案。它对在线服务的提升不是百分之几而是好几倍。3.3 显存管理器动态分配与换出连续批处理带来了一个副作用KV Cache空间是动态变化的上一秒腾出8GB下一秒来了个长文档吃掉12GB。如果显存管理不到位系统会出现大量碎片或者在该分配的时候拿不到内存。现代推理框架普遍借鉴了操作系统的分页思想把KV Cache切成固定大小的块按需分配不再使用的块立刻回收。调度器每次决定插入新请求前会先算剩余显存够不够不够就让请求排队等待而不是强行塞进去导致OOM。这块我的经验是别把显存预留上限设得太满。框架配置里一般有KV Cache占用上限我曾图省事设到90%结果压测时偶发OOM排查了半天最后发现是CUDA context、中间结果、临时张量也有额外开销。留出至少20%的余量系统稳定性会好很多。4. 实操路径从零搭建一套分布式推理系统4.1 第一步硬件选型与网络拓扑构建分布式推理系统第一步不是装软件而是看硬件。首先是节点内GPU拓扑。多张卡之间的高速互联不是均匀的有的卡对之间带宽高有的走PCIe很慢。用厂商自带的拓扑检查工具看一眼确认哪些卡在同一个高速互联域里。TP就放在这个域内效果最好。其次是节点间网络。多机互联首选支持RDMA的高性能网络方案带宽高、延迟低。没有条件的时候用高性能以太网加RoCE也能凑合。如果两者都没有那就老老实实减少跨节点切分多走数据并行副本路线。最后是CPU和内存。推理服务除了GPU计算还要做tokenizer、采样、调度、网络传输。CPU核数太少请求解析和处理会成为瓶颈。我见过GPU利用率只有30%但CPU跑满的情况最后是前端预处理逻辑太重把GPU饿死了。4.2 第二步手算一遍显存与带宽动手部署前我强烈建议手算一遍资源账。拿一个具体例子来走一遍计算流程。假设要跑70B FP16模型单机8卡每卡80G。权重每卡占140GB÷817.5GB。KV Cache按32并发、平均2048 token算共约21GB均摊每卡约2.7GB。激活和中间变量峰值按5-10GB估。把这些加在一起17.52.71030.2GB再加上CUDA context和框架缓冲35GB左右。这意味着32并发在80G单卡上有充足余量但如果要把并发推到128KV Cache会涨到80GB以上整卡基本就要被塞满了。带宽账也要算。假设TP8跨两台4卡机器中间走25Gb/s网卡。一次AllReduce传128MB数据光等网络就要40毫秒以上而GPU算一层只要几毫秒。算完这笔账你就知道为什么TP跨节点是自杀式设计。这笔账一定要在买机器、做方案之前算。算完你会发现很多时候瓶颈根本不在GPU算力而在网络带宽和显存容量。顺着账去配资源才不会花冤枉钱。4.3 第三步确定框架与部署参数当前主流的开源推理框架在核心思路上高度一致支持张量并行和流水线并行、内置连续批处理、用分页方式管理KV Cache、提供流式输出接口。选框架时我建议重点看三个维度是否支持你的并行需求、显存管理是否成熟、社区的装机量够不够大。装机量大的框架踩坑经验多遇到问题搜一搜往往就有答案。部署参数方面一个典型的配置长这样model: path: /models/70b_fp16 dtype: float16 parallel: tensor_parallel_size: 8 # 节点内8卡TP pipeline_parallel_size: 2 # 两节点PP engine: max_num_batched_tokens: 8192 # 单次迭代最多处理的token数 max_num_seqs: 64 # 同时活跃的最大序列数 gpu_memory_utilization: 0.80 # KV Cache显存上限留20%余量 enable_streaming: true # 开启流式输出 queue: max_queue_size: 256 # 队列最大长度 timeout_ms: 30000 # 排队超时30秒这些参数之间是联动的。max_num_seqs和gpu_memory_utilization共同决定KV Cache上限max_num_batched_tokens决定每步GPU处理的token总量。新手最容易犯错的是同时把三个参数都调大结果显存爆了或者延迟飙了。正确做法是先固定模型和并行配置再根据压测结果慢慢动批处理参数。4.4 第四步负载均衡与多副本管理模型组部署好之后前面还需要一层网关做负载均衡。由于推理请求本身是无状态的每次请求独立负载均衡策略用轮询或最小连接数都可以关键在于健康检查必须做对。最忌讳的健康检查方式是“看进程还在就认为服务正常”。推理服务可能进程活着但显存不足、卡在死锁、或者排队积压。健康检查要直接探测真实的推理接口并且设置较短的超时。只有能正常返回的副本才配接流量。我还会在网关层做熔断如果某个副本的请求超时比例连续超过阈值自动把它摘除一段时间。这个机制救过我好几次——某副本因为显存碎片化开始频繁超时网关及时把它隔离线上用户的P99没有受到太大影响。多副本的另一大好处就是可以放心摘除、重启、升级不用心惊胆战。5. 常见故障与排查技巧实录5.1 一上多机性能反而下降这是我见过最多的翻车现场模型在单机8卡上跑TPOT是80毫秒扩展到两台机器后速度不仅没变快反而变成150毫秒。查了半天发现TP被配置成跨节点运行8卡TP里4卡在节点A、4卡在节点B每层都要走两次跨机通信性能直接崩掉。遇到这种情况第一步就是用性能分析工具看通信耗时占比。如果通信耗时超过计算耗时问题几乎都出在并行策略与硬件拓扑不匹配上。把TP收敛到节点内跨节点部分改成PP或多副本性能通常立刻好转。记住分布式并不总是更快切分不合理时它只会更慢。5.2 显存明明够却OOM按手算的结果80G卡跑32并发只用了35G应该很宽裕但压测就是OOM。这种问题多半出在三个地方一是CUDA context和运行时缓冲占了几个G二是激活值和临时张量的峰值比你预估的高三是框架显存管理器分配的KV池遇到碎片化明明有空间但申请不到连续的块。解决办法是给显存占用留足余量gpu_memory_utilization不要超过0.85。另外把框架的日志级别调高观察KV Cache分配失败时剩余显存还有多少。我曾经遇到一次OOM剩余显存还有12G但因为一个大请求要一次性申请6GB的KV块池里没有连续空间分配失败。后来换了块级管理更精细的框架版本同样并发下再也不OOM。5.3 输出质量劣化有时候分布式推理上线后用户反馈回答变差了出现重复、乱码、前后矛盾。除了模型本身的prompt问题技术层面有两个常见原因。第一个是精度问题。FP16在超大矩阵乘法里累积误差比FP32明显TP切分会改变矩阵乘法顺序导致结果与单卡推断略有偏差。这个问题一般不影响大多数场景但对精度敏感的识别、批处理任务容易暴露。解决方式是关键部分用更高精度计算或开启框架的精度补偿选项。第二个是采样状态不一致。分布式推理中模型被切到多卡但采样逻辑和随机种子如果没在多进程间同步每个副本生成结果会不一致。这会导致在负载均衡后同一个请求两次调用返回完全不同的质量。解决方法很简单固定随机种子确保采样操作只在一个进程上执行然后广播给其他进程。5.4 排队延迟与超时平均吞吐量看起来正常但P99延迟爆表这种问题最让人头疼。大多数情况下根因在排队策略而不是算力。请求队列设计不合理时一个长请求可能占住计算资源几十秒后面的短请求全部被堵住。我在实际项目中做了三件事把P99拉回来第一开启连续批处理让短请求快速插队第二设置排队超时超过30秒直接拒绝并返回“系统繁忙”而不是让用户无限等待第三给长请求和短请求设置不同的最大批token预算避免某个大请求吃满整步计算。这套组合拳之后P99从原来的8秒降到1.5秒以内效果立竿见影。6. 一些实操心得与建议6.1 从负载需求反推架构我见过不少团队一上来就规划“全套分布式方案”结果模型只有13B单卡就能跑白白多花好几倍的机器成本。正确的思路永远是从负载需求反推。一个简单的决策框架模型能单卡放下且吞吐满足就不做任何分布式模型单卡放不下但单机8卡能放下上TP单机8卡也放不下或吞吐不够再加PP和多副本。分布式不是越多越好而是够用就好。每一步都先用估算确认瓶颈在哪再决定上不上、上哪种并行策略。6.2 显存、带宽、成本之间的取舍推理系统的资源规划本质是在算力、带宽和成本之间找平衡。GPU算力再强如果权重加载和KV Cache管理拖后腿利用率永远上不去。带宽再高如果模型切分不合理也只会白白浪费。最不划算的做法是花大价钱买一大堆卡却因为内存管理粗糙实际只能跑规划并发的一半。我见过一个项目规划的并发是64压测时发现只能稳定跑到40一问发现KV Cache预留只有30%大量请求在排队。把预留调到合理值之后稳定并发直接涨到70。有时候系统瓶颈不在硬件而在软件配置的保守程度。6.3 监控与复盘分布式推理系统一定要有指标监控至少包括GPU利用率、显存占用、KV Cache占用率、当前批大小、排队长度、TTFT、TPOT、吞吐量、超时比例。这些指标分开看各有意义放在一起看才能定位问题。例如“GPU利用率低排队长度高”说明调度有问题而“GPU利用率高TTFT飙高”说明批处理策略导致长请求堵塞。升级框架版本或修改并行参数前一定要先在测试副本上做压测对比。推理框架的版本迭代很快有时一个参数在新版本里语义变了直接上生产就是事故。我在一次升级后没有重测并发参数结果KV分配策略变了压测直接OOM多亏有监控快速回滚才没影响线上用户。最后分享一点个人体会构建大规模分布式推理系统最核心的不是会用某个框架而是把显存、带宽、延迟这笔账算明白把并行策略和硬件拓扑对齐把KV Cache和连续批处理这两个机制吃透。框架会迭代、会更换但底层原理就这些。你把原理理解透了换什么工具都能快速上手。希望这篇文章能帮你在搭建系统的路上少踩几个坑。
