LLM大规模分布式推理系统这个词听起来很唬人但它要解决的实际问题却很朴素模型参数越涨越大单张加速卡既装不下也跑不快那就把模型切到多张卡上并行算再把大量并发请求有序调度起来。我近几年搭过好几套推理服务从单卡硬扛到多机多卡支撑线上流量都经历过这篇文章就围绕并行切分、KV Cache管理、连续批处理、集群通信和压测调优把这些真正要紧的东西摊开讲。适合想把推理服务从玩具变成生产系统的同学也适合正在为扩容和P99飙高头疼的同行参考。1. 单卡推理的瓶颈比想象中来得更早1.1 显存墙模型权重和KV Cache的双重挤压很多人以为分布式推理只是把参数切开让模型能被装进多张卡。实际上在并发场景下KV Cache占用的显存往往比模型权重更夸张。以大几十B参数的模型为例FP16精度下权重大约是参数量的两倍比如70B模型就要140GB单卡80GB根本放不下。更麻烦的是KV Cache注意力计算需要把历史token的Key和Value缓存下来每个token的缓存量约等于 2×层数×KV头数×头维度×字节数。假设层数80、KV头8个、头维度128、FP16存储每个token大约要吃掉320KB。一段2048 token的上下文单个请求就是640MB。同一时刻32个并发单单KV Cache就要20GB这已经逼近模型权重的一半而且它还会随请求数线性增长。所以判断一个分布式推理系统的好坏不能只看能不能把模型跑起来还要看它把KV Cache管理得多好、能把并发扩到多高。显存墙不是单卡时代的专利分布式方案只是把问题从一张卡装不下变成了一组卡的显存池够不够用显存规划依然是最先要算的账。1.2 自回归解码的串行特性让算力利用率天然偏低再说算力利用率。LLM解码是自回归的每生成一个新token都要把之前所有token再attention一遍。这个过程天生是个串行循环一次只吐一个token。单请求下加速卡的算力大部分时间在闲着真正的瓶颈是访存带宽和kernel启动开销。打个比方厨师切菜很快但一次只上一道菜灶台全空着。要把算力喂饱就得同时做很多道菜也就是多请求并发。可并发又受显存限制。分布式推理的价值就在这里通过并行切分扩大显存池通过批处理调度把并发做上去两条腿一起走才算把硬件资源真正用起来。这也是为什么单纯堆单卡性能解决不了大规模服务问题。1.3 分布式推理要解决的四个核心问题把问题收敛一下一个生产级系统要解决四个层面的东西模型放不下用张量并行、流水并行、专家并行做模型切分把权重摊到多张卡上。显存不够用做KV Cache分页管理提高单位显存承载的并发数。算力喂不饱用连续批处理和合理的调度策略提升GPU利用率和整体吞吐。机器协同难处理好卡间和节点间的通信拓扑避免P99被网络拖垮。后面的章节基本就对应这四件事。先把切分策略讲清楚再说推理引擎内部的显存与调度然后聊集群部署与通信最后用压测和复盘把整个链路串起来。2. 模型切分策略TP、PP与EP怎么选2.1 张量并行把一层切开塞到多张卡里张量并行TP的思路很直接把Transformer里每个算子的矩阵按维度切开分到不同卡上。比如一个线性层YXWW是[Hin, Hout]的矩阵可以按输出维度切成P份每份是[Hin, Hout/P]各卡算完自己的部分再用一次all-reduce把结果合并。多头注意力也类似把注意力头分配到不同卡上并行算。TP的好处是通信模型简单每层做完一部分就要同步一次。坏处也明显同步次数频繁消息体量大。以hidden size为8192、序列长度2048、FP16为例一次all-reduce要传输的数据大约是8192×2048×2字节超过30MB。在机内高速互联带宽数百GB/s时这个开销可能只有零点几毫秒一旦跨节点走普通网络带宽降一个量级延迟变成几毫秒甚至更高每层累积下来整请求的延迟和吞吐都会崩。所以实践里TP并行度一般不超过单机内的卡数8卡机做TP8很常见TP16以上除非卡间互联极强否则通信会吃掉大部分收益。2.2 流水并行把层切成连续段让数据接力跑流水并行PP是把模型按层切成连续段每张卡负责其中一段。数据在段与段之间传递传输量只有中间激活远小于TP的all-reduce量频率也低。但朴素流水会让后面的卡空等解决办法是引入micro-batch把一个较大的batch拆成多个小micro-batch逐个灌进流水线。推理场景下核心思想一致让各卡在任意时刻都有活干而不是一段算完、其他段干等。流水线气泡占比有个粗略公式(PP-1)/(PPMB-1)。比如PP8、micro-batch数16气泡大约30%micro-batch提到32能降到18%。不过推理时micro-batch数量受KV Cache显存约束不能无限提。PP很适合跨节点部署因为它通信量小对节点间网络带宽要求相对宽松这也是多机推理普遍选PP而不是硬上大TP的根本原因。2.3 专家并行MoE模型下绕不开的特殊切法如果模型是MoE结构就得聊专家并行EP。MoE层里有一堆专家子网络每个token由路由网络选到top-k个专家上计算。专家并行把不同专家放到不同卡上token通过all-to-all通信转发到对应卡。好处是专家总数可以做得很大单卡只激活部分专家显存和算力都省坏处是通信模式变成all-to-all流量和token路由分布强相关。负载均衡很关键路由如果总偏向某些专家会出现个别卡算到冒烟、其他卡闲着的尴尬。工程上通常加一个容量因子比如1.25意思是每个专家最多接收理论均值的1.25倍超出部分直接丢弃或重路由同时让路由模块的loss惩罚不均衡。推理时还要额外关注token在不同专家之间的转发延迟因为它直接吃进TPOT里。MoE模型上了规模之后EP不是可选题是必选题。2.4 组合配置参考不同规模模型的并行方案实际项目很少只用一种并行常见做法是单机内先上TP把机内高速互联吃满跨机用PP因为PP通信少MoE再叠加EP。这里给一张我常用的配置参考表具体数值会随硬件变化但选型思路通用模型规模总卡数参考推荐切分备注7B~13B1张单卡量化显存够用就别折腾并行30B~70B8~16TP8 PP2~4单机放不下时用PP跨机100B~175B32~64TP8 PP4~8 EP若MoE需要3D并行通信规划先行选型原则很简单先看单卡量化后能不能装下装不下先加TP后加PP通信压不住就减TP加PPMoE再叠加EP。注意每次调整都要重跑压测不能拍脑袋。3. 推理引擎的关键显存管理与请求调度3.1 KV Cache为什么会成为显存黑洞前面已经算过KV Cache的量级这里再强调一个特点它的大小跟序列长度正相关而且请求之间的长度差异非常大。短请求几百token长请求可能上万token。如果用最朴素的方式给每个请求在显存里分配一块连续空间放KV Cache两个问题立刻出现一是预留空间必须按最大可能长度来分大量浪费二是请求释放后留下的空洞难以复用碎片化严重。很多推理框架后来都改成按token按需分配就是为了解决这两个问题。显存黑洞的本质并不是KV Cache本身大而是分配方式太粗糙。就像一个仓库如果每个租户都必须包一整层哪怕只用一小块仓库利用率永远上不去。调度器要做的是把仓库改成格子柜按需租格子。3.2 分页式KV Cache用管理内存的方式管理显存分页式KV Cache的思路和操作系统里的虚拟内存如出一辙把KV Cache切成固定大小的块每个请求维护一张块表逻辑上连续物理上可以散落在显存各处。分配时按块粒度动态分配用完的块立刻还给显存池。这样做碎片率趋近于零还能支持前缀共享多个请求共用同一段系统提示词的缓存块显存直接省下一大截。我见过同样的显存从朴素连续分配换成分页管理后最大并发几乎翻倍。这里尤其建议把最大并发和最大序列长度分开配置。很多系统OOM不是因为权重太大而是因为默认给每个请求预留了过大的KV Cache空间。分页模式下长度只影响实际用到的块数系统能够在不预知长度的情况下接住更多请求这是推理引擎走向生产环境的关键一步。3.3 连续批处理把调度粒度从批次降到序列比KV Cache管理更影响吞吐的优化是连续批处理。传统batch方式要攒够N个请求组成一个batch一起算等batch里最慢的请求结束后才释放全部资源。问题是请求长度参差短请求早就生成了终止符还得陪着长请求干等。连续批处理把调度粒度缩小到序列级每个decode step时调度器重新决定哪些序列进入本轮计算已经结束的序列立即下线空出的位置马上进新请求。这样短请求不会被长请求拖后腿整体吞吐能提高好几倍代价是调度器本身要足够快判断一个序列能否参与本轮计算不能花太多时间。实现时要注意不能为了吞吐无限塞序列序列太多会导致单轮decode时间变长TPOT涨上去交互体验变差。吞吐和延迟之间需要找到平衡点通常用SLO来约束。3.4 并发上限的估算与SLO调度并发不是越高越好显存有上限极端并发下每个请求的排队时间也会涨。可以先估算再压测可承载请求数约等于单卡可用显存减去模型权重占卡里的部分再减去激活和通信buffer除以每请求KV Cache量再乘以总卡数并考虑切分后的分布。实际操作中按公式求出上限再留20%余量基本不会出大错。调度策略建议区分场景。交互式应用优先保证TTFT也就是首token时延P99最好压在1.5秒以内离线批量任务更看重整体吞吐。简单的先来先服务在长序列请求多的时候会让短请求体验很差可以考虑按预计长度优先调度。如果长请求占用太多资源宁可做抢占把部分请求的KV Cache换出到内存或直接排队保证SLO不崩。线上真实流量往往长短混杂调度策略不做精细化P99一定会教做人。4. 集群部署与通信优化决定P99的关键4.1 三种网络角色各管一摊事分布式推理对网络的要求是分层的。最靠近卡的是卡间互联承载TP的高频小消息需要极低延迟和极高带宽。再往上是节点间网络承载PP的激活和EP的all-to-all消息频率低但对稳定性要求高。最外面是管理网络跑控制面、监控、日志要求不高但别和前两类混在一起。网络角色承载流量关键指标常见病灶卡间互联TP all-reduce延迟、带宽TP规模受限节点间网络PP激活、EP路由稳定性、带宽P99抖动、丢包管理网络心跳、日志、指标可靠性资源争抢我见过最典型的失误是把节点间流量和控制面日志放在同一张物理网络上压测时日志同步和推理流量互相打架P99直接抬高一倍。网络规划在系统设计阶段就要做后期调整成本极高。4.2 通信优化融合算子、拓扑感知和消息大小集合通信不是简单把数据从一处搬到另一处。优化手段大体有三类一是融合消息把多个小消息合并成一个大消息再发减少内核启动和同步次数二是选拓扑消息小、延迟敏感时用树状结构消息大、追求带宽时用环形结构三是拓扑感知部署把TP的rank尽量安排在同一个交换机域内避免流量绕远。判断网络有没有问题的第一招是用一个最小集合通信测试脚本先测节点间实际带宽。先看理论值再看实测值差得远就要查交换机、驱动和物理链路。很多TPOT突然飙高的现象最后都落在网络而不是算力上。通信库本身也在不断演进新版本对多卡all-reduce的调度常有明显改善升级前记得先做A/B压测。4.3 量化是怎么同时帮到显存和通信的分布式推理里量化有两个收益显存缩小通信字节也缩小。FP16换FP8权重和KV Cache各自减半一次all-reduce的数据量也从30MB级别降到15MB级别网络压力小很多。实操建议是先把模型量化再切分部署这样通信从头到尾都跑在低精度上。但量化不是无脑全压。输出层和注意力相关关键路径上我习惯保留更高精度否则会看到明显的质量劣化。KV Cache量化也需要单独验证它和权重量化在不同任务上的表现差异很大。每次量化调整都要配一组质量评测用例不要只看显存数字变好看了就上线。精度和性能的权衡在这个场景里几乎是日常。5. 压测、监控与故障排查实录5.1 一套可复用的推理压测方法压测不要只报一个吞吐数字。我压测时固定记录四个指标TTFT、TPOT、端到端时延和整系统吞吐再配合不同并发档位。输入长度要覆盖典型业务短文本512、常规2048、长文本4096分别压。每个并发档位至少压3分钟让系统进入稳态再统计只看前1分钟的峰值数据没有参考价值。记录P50、P95、P99尤其P99线上用户对尾巴延迟的感觉远比对平均值敏感。并发吞吐(tokens/s)TTFT P99(ms)TPOT P95(ms)备注1基线值基线值基线值单请求参考8正常档正常档正常档看线性度32目标档目标档目标档核对SLO64压力档压力档压力档找天花板压测时还要同时录GPU利用率、显存占用和网络流量。只看业务指标排查问题很难定位三层数据一起看才能在出问题时快速缩小范围。5.2 OOM排查别一上来就怪模型太大推理服务OOM先别急着下结论。按顺序查权重占了多少KV Cache占了多少激活占了多少通信buffer占了多少以及是不是显存碎片。最笨但有效的办法先把并发调成1确认模型能起来然后逐步加并发直到OOM这一步能反推KV Cache的真实容量。如果并发1都起不来那是权重或加载方式问题能起但并发一高就挂多半是KV Cache分配策略的问题。降OOM的常规手段包括开启分页管理、缩短max-model-len、对超长请求做截断或排队、调低并发上限、做量化。按这个顺序走一遍八成能定位。不要一上来就减并发那是牺牲业务换稳定治标不治本。5.3 P99抖动与通信异常的排查顺序P99抖动是分布式推理最常见的线上问题。我的排查顺序是先看网络再看调度最后看宿主机。网络看重传和丢包节点间链路有没有被打满调度看是不是某个长请求霸占了GPU让短请求排队宿主机看网卡中断是不是都打在同一个CPU核上内存分配是不是跨了架构边界。有一次TPOT从40ms直接飙到120ms查了半天发现是网卡中断集中在一个核上把中断分散到多核后问题消失。这类问题单请求测试永远暴露不了只有压测才能看到P99的尾巴。排查P99不建议靠猜要把监控指标打全最好精确到每卡每网络端口。监控体系从第一天就建好否则事后补数据会非常痛苦。6. 一次70B模型推理集群的落地复盘6.1 项目背景与目标用一个脱敏后的项目来把这些内容串起来。某公司一个文本生成产品模型约70B准备上线时单机8卡勉强能跑但并发一上去就卡死。项目目标很明确并发32路TTFT小于1.5秒TPOT小于50毫秒。最初方案是单机朴素批处理实测8并发时TTFT已经超过2秒必须重构。接手后重新设计了架构2台8卡节点TP8、PP2切分FP8量化KV Cache分页管理连续批处理调度策略按TTFT优先。整个改造大概花了两周其中压测和调优占了大头。6.2 选型配置与实测数据最终配置跑出来的数据大致如下表取多次压测后的中位数和尾值并发TTFT P99(ms)TPOT P95(ms)吞吐(tokens/s)备注878034260正常1695039430正常32128046620达标64215074760接近显存上限结论很清楚32路完全达标64路P99已经超过目标说明当前规模的天花板在显存和节点间通信。下一步扩容应该加节点或加PP深度而不是继续硬调参数。这个结论靠压测数据说话省去了很多无意义的争论。6.3 三个真实踩过的坑坑一是量化质量。FP8全量量化后摘要任务里明显出现更多事实性错误。后来把输出层和注意力QKV部分回退到FP16质量恢复显存只多占一两个GB完全可以接受。这件事的教训是量化收益再大也得先过质量关。坑二是OOM。并发从32提到64时直接显存溢出一开始以为是模型太大排查后发现是KV Cache预留策略太保守。改成按需分配加分页管理后64路勉强能跑但P99已经超标最后把并发限到48路。用profiler数据替代直觉判断省了很多弯路。坑三是P99抖动。最初压测16路时TPOT P95只有39毫秒但P99偶尔到110毫秒。抓网络发现节点间偶发重传最后定位是控制面日志同步占用了网络中断。做了网络隔离后P99稳定在70毫秒以内。这类问题只有压测长时间跑才能复现短时间压测容易漏掉。几套系统做下来我对分布式推理最深的感受是把模型并行跑起来只是起点真正花时间的都是显存、调度和网络稳定性这些细节。如果你正准备搭自己的推理服务我的建议是先从单机把推理引擎的能力摸清楚分页、连续批处理这些先玩明白再上多机。每次调参只动一个变量压测脚本和监控面板从第一天就建好省得后期返工。上面这些数据来自脱敏后的项目复盘不同模型和框架会有差异但排查思路是通用的。