一、项目背景

我们把一个大模型推理服务搬到多卡环境，本以为张量并行切下去就能线性提速，结果卡间通信成了瓶颈，吞吐没上去延迟先炸了。更麻烦的是长会话场景，KV 缓存分块分配，跑着跑着显存看着还有几个 G，真要申请一块连续显存却失败，OOM 偶发，服务半夜被告警叫醒。我们翻了显存快照，碎片率高的时候接近三成，明明总空闲够用，就是凑不出连续块，这种问题最隐蔽，压测时没事，长会话跑久了才暴露。业务方那边只看到响应变慢和偶尔报错，根本不知道是显存碎片在作祟，运维背了很久的黑锅，每次都得登机器翻快照才定位，效率低得离谱。

二、落地场景

我们重做了并行切分和显存管理。张量并行从按层切改成按张量切，通信量明显下降，卡间不再是瓶颈；KV 缓存改用分页管理，像操作系统虚拟内存那样把块拆小、按需分配，碎片被压住。后台加了碎片率监控，实时看每卡的内存分布，超过阈值就触发整理或回收。OOM 兜底是最后一道，申请失败时不直接崩，而是踢掉最久未用的低优会话，保住主业务。我们还把显存占用和调度联动，碎片高时优先把新会话排到碎片少的卡，别往快满的卡上硬塞。此外，显存预测也接进来了，新会话进来前先估算它大概要多少 KV 块，卡上不够就直接排到别的卡，从源头减少申请失败，比等 OOM 再踢会话体面得多。

三、关键技术挑战与解决思路

切分粒度是第一个坑。按层切听起来直观，但每层都要全卡同步，通信频次高，小模型还好，大模型通信占比直接冲到四成，吞吐反而降。我们改成按张量维度切，通信变成一次大块传输，占比砍到一成多，才真正提速。KV 分页的难点在地址映射，分页之后逻辑块要映射到物理块，推理时查表取数，实现复杂但换来碎片可控。碎片整理不能停服务做，我们用了后台增量整理，挑空闲时段把零散块合并，不影响在跑的会话。OOM 兜底要防误杀，踢会话得有优先级，先把超时和闲会话踢了，正在应答的绝不动，我们第一版没区分，踢过一个关键业务会话，被投诉才知道优先级的重要。显存预测也踩过坑，初期按平均长度估，长会话一进来就把卡占满，后来改成按分位数估峰值，预留余量才稳。

案例片段（已脱敏）： 张量并行与分页 KV 配置（示意）： tp.strategy: tensor_dim kv.paged: true kv.block_size: 16 frag.monitor_threshold: 0.15 oom.evict_policy: lru_low_priority kv.estimate: p95_length 某服务切分页 KV 后显存碎片率从约 30% 降到 6%，OOM 次数从每周数次降到近乎为 0，吞吐提升约两成五，新会话调度失败率降到 0.1% 以下。

四、效果数据

我们主要看卡间通信占比、显存碎片率、OOM 次数和吞吐。通信占比从四成降到一成多，多卡终于发挥出该有的并行度；碎片率从三成压到个位数，长会话跑一晚上也不慌；OOM 基本绝迹，半夜告警少了一大半，运维终于能睡安稳。吞吐提升两成五，同样的卡多接了四分之一的流量，成本摊薄明显。文中数据为项目复盘口径，已做脱敏。我们把碎片率和 OOM 接到了容量规划，哪张卡快满了提前预警，扩卡决策不再靠拍脑袋，资源利用率和稳定性一起上来了。显存预测上线后，新会话几乎不再因为申请不到显存而失败，用户体验那块最直观，原来偶发的超时报错基本看不见了。

五、可复用经验总结

多卡推理别想当然按层切，通信占比才是隐藏杀手，我们就是切错粒度被延迟教做人，按张量切之后才顺，动手前先算一遍通信模型最稳。KV 缓存一定分页，长会话场景碎片是迟早的事，不分页就是埋雷，看着有显存却申请不出来最坑人。OOM 兜底必须带优先级，踢会话不能乱踢，踢错关键业务比 OOM 本身还难收场，我们吃过这个亏之后把优先级写进了铁律。显存预测要按分位留余量，平均估会撑爆卡，我们被长会话占满坑过才改。我现在的看法是，显存治理和调度要联动，光把碎片压下去不够，新会话往哪张卡塞也得看碎片分布和预测，把显存当资源池精细调度，多卡环境才真正稳得住。

我们把显存监控接到了告警分级，碎片率过阈只是提醒，OOM 才打电话，值班人不用天天盯图表。运维后来把这套经验推广到训练集群，训练任务的长驻显存也用分页思路管，空闲碎片同样压下去了。

我们也做了显存水位的自动调度，新会话进来前先看哪张卡碎片最少、余量最足，优先往那边排，从源头减少碎片堆积。运维后来把这套指标接到了扩缩容，长期高碎片的卡自动腾挪，整套多卡环境基本不用人工盯了。

KV 分页上线前我们压了三天长会话，确认碎片率稳定在个位数才切生产，没赌运气。

现在半夜基本没有显存相关的告警了，运维终于睡整觉。