「多卡一定比单卡快」错在哪？看完就会判断

大模型部署里，「多卡一定比单卡快」的说法流传很广。一个人搬不完的砖叫八个人来搬，一定更快——但八个人抬一台钢琴，光协调站位就把时间耗光了。「多卡一定比单卡快」的误区，错在把所有任务都想成了搬砖。多卡要靠通信协作，通信本身要花时间；任务切不开或切得不划算时，多卡比单卡更慢。正确说法是：多卡快不快，取决于任务能不能有效拆分，拆得开才值得上。

错在哪：忽略了协作成本

多卡并行有两条路：一是把一个大模型切开放，各卡各管一层，层与层之间要来回传数据；二是各卡处理不同请求，互不干扰。第一条路的每一步都伴随着卡间通信，这条隐形税随着卡数增加越收越重；第二条路虽不切模型，但每张卡都得装下一份完整模型，显存立刻吃紧，账要按参数量除以二就是显存的误区里说的动态口径算，而不是只看权重。

通信开销是隐形税

两张卡切一个模型，每生成一段都要同步一次中间结果，同步走的是卡间通道，速度远慢于卡内计算。任务越大、切分越细，通信占比越高。极端情形下，八张卡跑一个本来单卡就能装下的模型，速度可能还不如单卡——因为大部分时间花在了互相等。卡间通道的规格差距很大，同一台机器内的卡和跨机器的卡，通信速度能差出一个量级，跨机切分要格外谨慎。判断标准很朴素：通信时间和计算时间之比，比例越低多卡越划算。

批大小决定最终效果

推理吞吐和请求批大小关系极大。单卡一次能并行的请求数没吃满时，加卡的意义是承接更多并发；吃满了再加卡，吞吐确实能涨，但延迟未必降。反过来，只有零星几个用户的内部系统，多卡就是浪费——算力闲置，电费照付。多卡方案上线前务必做一轮混合批量的实测，压测脚本设计参考「压测流量和真实流量」一篇的做法。观察批处理的排队深度就能判断瓶颈在哪：排队深说明算力不足，排队浅说明加卡暂时没用。把排队曲线贴给 Kimi 解读，拐点会比报表更直白。

什么任务该拆、什么不该拆

• 该拆：模型大到单卡装不下、并发量高到单卡吞吐顶不住、需要长上下文超大批处理；
• 不该拆：小模型低并发、对延迟极敏感的单请求、预算有限还想压成本；
• 两可：中等规模高并发，先测单卡极限再加卡，别一步到位。

把三类任务摊开对照，拆与不拆的分界就清楚了：

选卡前的判断顺序

第一步，按真实业务算显存总账，确认单卡装不装得下，余量口径见显存够就能跑的误区；第二步，测单卡吞吐能不能扛住高峰并发；第三步，两问都过关就直接单卡，过不了再加卡并做切分实测；第四步，若为省显存上了量化，记得验证精度代价，见量化部署零损失的误区。多卡上线后还要盯卡间链路的健康度，监控思路见上了监控就稳了的误区。

自查清单

• 单卡显存：装得下 → 优先单卡
• 单卡吞吐：扛得住高峰 → 不加卡
• 切分实测：通信占比超过三成 → 重新规划
• 批量形态：并发低 → 多卡纯属浪费

划重点：多卡是扩容手段，提速要看任务给不给机会。

聊聊多卡推理的常见疑问

• 四张小卡和一张大卡怎么选？：单卡装得下就选大卡，省掉通信税；装不下才拼卡，并把切分方案的实测数据摆出来比较。
• 多卡能提高单个请求的速度吗？：能，但增益远低于线性，切分粒度越细损耗越大，长文档场景例外，可实测对比。小请求多时瓶颈常在调度层，不在卡数。
• 小用量团队有必要研究多卡吗？：没必要，直接调API更省心，成本对比的误区见API 一定比本地贵的误区，编排实验可以借助扣子快速搭。

搬砖可以堆人，抬琴得看默契。多卡快不快，测过通信占比再下结论，别让直觉替你付电费。