双卡互联对本地大模型推理性能的影响评测

一、评测概述

在本地化大模型推理部署中，多卡并行是突破单卡显存与算力瓶颈的常见手段。而多卡之间的互联方式——是通过主板PCIe通道直连，还是借助专用高速互联桥接——往往被视为“锦上添花”的细节。本文要回答的核心问题是：在双卡推理场景下，高速互联桥接究竟能带来多少实际收益？这种收益在不同并发压力下是否一致？

本文适合以下读者：正在规划本地推理集群的开发者、负责硬件选型与容量规划的架构师、关注推理服务SLA的运维人员，以及需要在成本与性能之间做权衡的技术负责人。需要强调的是，本评测不是简单判断“有桥接一定更好”，而是希望建立一个可复用的评测框架，帮助读者结合自身业务并发特征、延迟敏感度和预算约束做出条件化判断。

二、评测目标

本次评测聚焦以下四个问题：

1. 单发场景下，互联链路对首Token延迟（TTFT）和每Token生成延迟（TPOT）的影响幅度如何；
2. 高并发场景下，互联链路对吞吐能力、排队时延和尾部延迟的改善是否更显著；
3. 并发度本身相对于互联方式，对整体吞吐的贡献有多大；
4. 在什么业务条件下，为高速互联付出的额外成本是值得的。

这四个问题分别对应“链路价值”“压力放大效应”“并发红利”“成本边界”，构成一个完整的决策链条。

三、评测对象说明

评测对象为一套双卡推理环境：两张同型号GPU通过可选的高速互联桥接组件连接，运行主流推理框架，加载中等参数规模的大语言模型。对照组为相同硬件但不启用高速互联桥接、仅通过主板通道通信的配置。

被评测的能力本质上是卡间通信带宽与延迟对推理流水线的影响。在大模型推理中，张量并行需要频繁在卡间同步激活值和梯度切片，通信开销会直接体现在每Token生成时间上；而在高并发下，请求调度、KV缓存管理和批处理又会进一步放大通信链路的压力。因此，互联方式不是孤立指标，而是与并发模型、批处理策略耦合的系统变量。

四、评测维度设计

围绕推理服务的实际关切，建立如下评测维度框架：

维度	关注指标	为什么重要
吞吐能力	输出Token吞吐、请求吞吐	决定单位时间服务能力与资源利用率
首Token延迟	TTFT均值、中位数、P99	直接影响用户对响应速度的感知
生成延迟	TPOT均值、P99	影响长文本生成的流畅度
尾部延迟	P99 ITL、P99 TPOT	高负载下用户体验的一致性
并发扩展性	单发到多并发的吞吐增幅	衡量系统随压力增长的伸缩能力
稳定性	失败请求数、峰值并发	验证长时间运行与突发压力下的可靠性

选择这些维度的逻辑是：推理服务既怕“慢”，也怕“不稳”。平均值好看但尾部抖动大的系统，在生产环境中往往比预期更难用。因此本评测特别强调P99类指标与并发扩展性。

五、评测环境与前提

为保证结论可比，测试需控制以下条件：

• 硬件一致：两组配置使用相同GPU型号、相同数量、相同主板与内存规格，唯一变量为是否启用高速互联桥接；
• 软件一致：推理框架版本、模型权重、量化方式、批处理参数、调度策略保持一致；
• 输入一致：使用相同请求集，输入Token总量与输出Token总量对齐，避免样本偏差；
• 并发设计：分别设置单发（并发度为1）与4并发两组压力档位，观察链路收益随压力的变化；
• 测试边界：每组配置运行足够轮次，记录成功与失败请求数，排除预热阶段数据；
• 环境隔离：关闭无关后台任务，固定功耗与频率策略，减少噪声干扰。

需要说明的是，本文不披露具体硬件型号、框架版本号或工具命令，所有配置均以中性方式描述，读者可依据自身环境复现同类对照实验。

六、评测方法

评测采用“基线对照+分档压测”的方法，流程如下：

1. 建立基线：先在无高速互联的配置下，以单发方式运行固定请求集，记录吞吐、TTFT、TPOT、ITL等指标的均值与分位数；
2. 引入变量：切换至启用高速互联的配置，保持其他条件不变，重复同一请求集；
3. 提升压力：将并发度提升至4，分别在有、无高速互联两种配置下重复测试；
4. 交叉对比：从“链路差异”和“并发差异”两个方向分别计算性能变化，避免把并发红利误归因于互联链路；
5. 记录过程数据：同步记录失败请求数、峰值并发、测试时长，观察是否存在排队堆积或超时；
6. 重复验证：每组配置多次运行，取稳定区间数据，剔除异常波动。

示意性伪代码如下，仅表达测试逻辑：

for link in [disabled, enabled]:
    for concurrency in [1, 4]:
        warmup()
        result = run_benchmark(
            requests = fixed_dataset,
            concurrency = concurrency,
            duration = enough_rounds
        )
        record(result.throughput, result.ttft, result.tpot, result.itl)
compare(results)

七、结果解读

结合原始测试数据（已做中立化概括），可以得到以下判断：

第一，单发场景下互联链路收益有限。 单发时吞吐提升约8%至10%，TTFT与TPOT改善幅度不大。原因在于单发请求的批处理规模小，卡间同步次数与数据量相对可控，主板通道尚未成为明显瓶颈，因此高速互联的价值难以充分释放。

第二，高并发场景下互联链路收益明显放大。 4并发时吞吐提升约13%至15%，P99尾部延迟降低约50%，TTFT降低约23%。这说明并发压力下，请求调度与KV缓存管理带来的卡间通信频率显著上升，互联带宽成为影响排队时延的关键因素。尾部延迟的大幅下降尤其值得关注，它意味着高负载下用户体验的一致性得到改善。

第三，并发度本身是第一性能功臣。 无论是否启用高速互联，从单发到4并发，吞吐提升约160%至170%（约2.6倍），代价是每Token生成延迟增加约15%至25%。这提示我们：在预算有限时，优先提升并发调度能力往往比升级互联链路回报更高；互联链路更适合作为“高并发下的补强项”，而非“单发场景的提速项”。

解读这些结果时需注意：吞吐提升百分比会受请求长度分布、批处理策略和调度算法影响；尾部延迟的改善幅度在请求到达模式更陡峭时可能更显著，也可能因资源饱和而收窄。因此结论应表述为“在该测试条件与压力档位下成立”，而非普适定律。

八、适用场景分析

• 延迟敏感型在线服务：若业务对首Token延迟和尾部抖动敏感，且并发较高，高速互联带来的TTFT与P99改善具有实际价值；
• 离线批量推理：更关注总吞吐与单位成本，单发或低并发为主时，互联链路的边际收益有限，应优先评估并发调度与批处理优化；
• 混合负载生产系统：建议同时观察并发扩展曲线与尾部延迟曲线，若P99在高峰时段明显劣化，互联链路可作为稳定性补强手段；
• 开发测试环境：并发压力低，互联链路收益难以体现，不必作为必选项。

九、风险与限制

本评测存在若干边界：测试样本的输入输出长度分布有限，不能覆盖所有业务形态；硬件频率策略、驱动版本和散热条件可能影响绝对值；并发档位仅覆盖单发与4并发，更高并发下的曲线拐点需另行验证；长期运行下的稳定性、显存碎片与热降频问题未充分展开。此外，互联链路收益与模型并行切分策略强相关，不同切分方式可能得到不同幅度。

十、选型与使用建议

1. 先测并发，再谈互联：在采购互联组件前，先验证现有配置在目标并发下的吞吐与尾部延迟，确认瓶颈是否真的在卡间通信；
2. 以P99为导向做决策：平均值改善有限但P99显著下降时，对生产服务而言价值可能更大；
3. 控制变量做对照：任何互联收益结论都应在相同模型、相同请求集、相同调度参数下得出，避免把并发红利误记为链路红利；
4. 预留扩展验证：在目标并发之上再压一档，观察曲线是否出现拐点，为容量规划留出余量；
5. 关注成本结构：互联组件的成本应与其在高并发下带来的吞吐与稳定性收益做对比，低并发业务不必盲目跟进。

十一、总结

本文围绕双卡推理场景，建立了以吞吐、TTFT、TPOT、尾部延迟和并发扩展性为核心的评测框架，并通过单发与4并发的对照实验说明：高速互联在单发下收益有限，在高并发下对吞吐、首Token延迟和尾部延迟的改善更为显著；而并发度本身是吞吐提升的主要来源，代价是单Token延迟上升。读者在选型时应结合自身并发特征、延迟敏感度与成本约束，用对照实验验证瓶颈所在，再做条件化决策，而非一概而论。