双卡高速互联方案对大模型推理性能的评测

一、评测概述

在多卡部署大模型推理服务的场景中，一个常被讨论的问题是：为两张加速卡启用卡间高速互联（下称”高速互联方案”），究竟能为推理带来多大收益？很多团队凭直觉认为”互联越快越好”，但也有团队认为在单卡显存足够承载模型时互联意义有限。本文以双卡某类消费级加速卡为测试载体，在某推理服务框架下运行某27B级中等规模开源大语言模型，通过”启用高速互联”与”不启用高速互联”两种配置的对比压测，量化回答这一问题。

本文面向自建推理服务的开发者、负责容量规划的架构师、关注稳定性的运维人员，以及需要为硬件投入做决策的技术负责人。评测的核心不是简单判断”互联好不好”，而是帮助读者理解：在什么负载、什么并发、什么延迟目标下，高速互联才值得投入。

二、评测目标

本次评测重点验证以下几个问题：

1. 收益是否显著：高速互联在单请求、低并发与高并发场景下，分别能带来多大的吞吐与延迟改善？
2. 延迟结构如何变化：不仅看平均吞吐，还要看首Token延迟（TTFT）、每Token生成延迟（TPOT）以及尾延迟（P99）的变化。
3. 并发的作用：在评估互联价值之前，必须先厘清”提升并发”本身对性能的贡献，避免把并发的收益错误归因于互联。
4. 适用边界：明确高速互联在哪些负载特征下才真正划算，避免为低负载场景过度投入。

三、评测对象说明

被评测的核心变量是双卡之间是否启用高速互联通道。所谓高速互联，是指通过专用高速链路让多张加速卡之间直接、低延迟地交换数据，从而在张量并行或模型并行时减少跨卡通信开销。与之相对的是”不启用高速互联”，即卡间通信走通用总线路径。

• 方案A（启用高速互联）：模型在多卡间切分时，关键通信走专用高速链路，理论上可降低跨卡同步的等待时间。
• 方案B（不启用高速互联）：跨卡通信依赖通用通道，延迟与带宽相对受限。

被承载的工作负载是一个中等规模（约27B参数级）的开源大语言模型，部署在某类推理服务框架下，属于典型的”张量并行/多卡切分推理”场景。模型规模与部署方式决定了跨卡通信是否频繁，这是判断互联价值的前提。

四、评测维度设计

要从多角度评估高速互联的真实影响，需建立如下可观察、可验证的指标框架：

评测维度	关键指标	说明
吞吐能力	输出Token吞吐（tok/s）、总Token吞吐	反映单位时间内系统处理Token的能力
首Token延迟	TTFT（Mean/Median/P99）	用户感知的”响应快慢”，高负载下尤为关键
生成延迟	TPOT、ITL（Mean/Median/P99）	每个Token的生成耗时，决定流式输出的流畅度
尾延迟稳定性	P99延迟	高负载排队时尾部表现，反映服务稳定性
并发扩展性	不同并发下的吞吐曲线	从单发到多并发的性能增长关系
资源与稳定性	请求成功率、失败请求数	压测期间是否稳定无异常

选择这些维度，是因为推理服务的用户体验由”快慢（吞吐）+ 首字速度（TTFT）+ 流畅度（TPOT）+ 稳定尾部（P99）”共同决定，只看单一平均值容易得出片面结论。

五、评测环境与前提

为保证结论可信，评测必须在明确且受控的前提下进行：

• 硬件配置：双卡消费级加速卡，对比”启用/不启用高速互联”两种互连方式，其余硬件条件保持一致。
• 软件栈：同一版本的推理服务框架、同一模型权重、同一并行切分策略、同一精度设置。
• 工作负载：固定输入长度分布与固定总生成Token数，确保两组测试的”总工作量”一致，才具备可比性。
• 变量控制：仅改变”是否启用高速互联”这一变量，其余（并发数、输入输出规模、批处理策略）全部锁定。
• 测试边界：明确并发数（如单发与4并发）、压测时长、样本请求数，避免样本过小导致的偶然波动。

示意性的对比压测流程（伪代码，非任何专有工具）：

for 配置 in [方案B_无高速互联, 方案A_启用高速互联]:
    for 并发 in [1, 4]:
        启动推理服务(配置, 模型, 并行策略)
        预热()                         # 排除冷启动影响
        for 轮次 in [1, 2, 3]:         # 多轮取稳定值
            results = 压测(并发, 固定输入集, 固定输出长度)
            记录(吞吐, TTFT, TPOT, P99, 成功率)
        取中位数作为该配置该并发的代表值

六、评测结果与解读

基于受控对比，可归纳出如下条件化结论（数据为本次测试环境下的观测值，不代表所有配置）：

方案B（不启用高速互联）基线观测：

• 单发场景：输出Token吞吐约40.41 tok/s，平均TTFT约1224.62ms，平均TPOT约23.57ms，请求成功率100%。
• 4并发场景：输出Token吞吐约104.87 tok/s，平均TTFT约3510.60ms，平均TPOT约29.15ms。

核心量化结论：

1. 高速互联在单发场景收益有限（约8%~10%）。原因很直观：单请求时系统瓶颈往往在模型前向计算本身，跨卡通信占比不高，因此专用高速链路带来的边际改善有限。若负载长期停留在低并发，为高速互联付出的额外成本难以被充分利用。

2. 高速互联在高并发（4并发）场景收益更明显（约13%~15%）。高负载下请求排队、批处理增大、跨卡同步更频繁，通信开销占比上升，此时高速链路能显著缩短同步等待，并明显降低TTFT，改善高负载下的排队时延。

3. 高速互联的综合收益：在4并发高负载下，吞吐提升约13%，P99尾延迟降低约50%，TTFT降低约23%。尾部延迟的大幅改善对服务稳定性尤其有价值，因为它直接影响高负载时的用户体感与SLA达成。

4. 并发的贡献远大于互联：无论是否启用高速互联，从单发提升到4并发，吞吐提升约160%~170%（约2.6倍），这是性能提升的第一功臣。其代价是每个Token的生成延迟（TPOT）增加约15%~25%——这是并发调度与批处理带来的固有取舍。

如何正确解读这些结果： 首先应认识到，并发是最有效的性能杠杆，优先通过合理的并发与批处理调优来榨取吞吐；其次，高速互联并非”锦上添花无用论”，而是在高并发、对尾部延迟和TTFT敏感的生产场景中体现出结构性价值；最后，所有结论都绑定”该硬件、该模型规模、该并行切分策略”，换配置需重新验证。

七、适用场景分析

• 低并发/交互式单请求场景：优先保证TPOT与TTFT稳定，高速互联收益有限，可将预算投向更充分的显存与计算资源。
• 高并发在线服务场景：吞吐、TTFT与P99是核心指标，高速互联的综合价值更容易体现，值得重点评估。
• 对尾部延迟敏感的场景（如带SLA约束的生产系统）：高速互联对P99的改善可能带来直接的稳定性收益。
• 模型规模较小、单卡可承载场景：跨卡通信需求低，互联意义进一步下降。
• 模型规模大、必须多卡切分场景：跨卡通信频繁，高速互联的价值上限更高，但仍需通过实测确认。

八、风险与限制

• 样本偏差：本次样本请求数与轮次有限，绝对值可能随输入分布、随机性波动，结论应理解为趋势而非精确承诺。
• 环境差异：不同显卡、不同总线、不同框架版本、不同并行策略都会改变通信开销占比，直接套用他处数据存在风险。
• 模型与负载绑定：结论针对约27B级模型与特定切分方式，更换模型或精度需重新压测。
• 长期运行不确定性：短时长压测无法完全覆盖内存碎片、显存泄漏、长时间高负载下的性能衰减，需辅以长稳测试。
• 归因复杂性：TPOT上升可能来自并发调度而非互联本身，分析时须严格区分变量。

九、选型与使用建议

1. 先做基线，再谈优化：在任何互联投入前，先建立单发与多并发的基线，明确瓶颈在通信、计算还是显存带宽。
2. 优先压榨并发与批处理：这是性价比最高的性能杠杆，但需通过压测找到吞吐与单Token延迟的平衡点。
3. 按场景决定互联投入：高并发、尾部延迟敏感的生产场景值得评估高速互联；低负载场景谨慎投入。
4. 以实测为准，拒绝想当然：不同硬件与模型组合差异巨大，务必在自有环境按受控变量重新验证。
5. 关注可观测性：部署后应持续采集吞吐、TTFT、TPOT、P99与失败率，为容量规划与优化提供数据支撑。

十、总结

本次评测围绕”双卡高速互联对推理性能的影响”展开，通过受控对比压测得出条件化结论：高速互联在单发场景收益有限（约8%~10%），在高并发场景价值更明显（吞吐约+13%、P99约-50%、TTFT约-23%）；而提升并发本身才是吞吐增长的首要因素（约2.6倍），代价是单Token延迟上升约15%~25%。对读者的实践启示是：先厘清瓶颈、优先优化并发与批处理，再依据负载特征与延迟目标理性评估高速互联投入，并以自有环境的实测数据作为最终决策依据。