双卡定制互连推理性能评测与解读

一、评测概述

本文评测的核心问题是：在单机双卡消费级图形处理器（GPU）环境中，为两张卡增加定制高速点对点互连后，语言模型推理服务在单发与高并发场景下会发生什么变化。为避免具体硬件型号、框架版本和模型名称干扰判断，本文对相关专有名称做中立化表达，聚焦“卡间互连能力是否值得投入、在什么场景下更有价值、如何验证收益与风险”这一通用技术评测问题。

这类评测适合开发者、推理服务架构师、运维人员、技术负责人和企业技术团队阅读。它要回答的不是简单的“开启互连是否一定更好”，而是：在给定模型规模、输入输出长度、并发压力和服务等级目标下，互连改造能否带来可感知的吞吐、首Token延迟和尾部延迟改善，以及这些改善是否足以覆盖硬件改造、稳定性验证和长期维护成本。

二、评测目标与评测对象

本次评测对象是“双卡定制高速互连方案”对推理服务的影响。互连能力主要影响卡间通信效率，包括张量并行中的同步、分层计算中的中间结果交换、键值缓存分片访问以及高负载下的调度等待。评测目标可拆为四类：

1. 吞吐能力：单位时间内输出Token数、总Token数和请求完成数是否提升；
2. 交互体验：首Token延迟（TTFT）是否下降，用户从提交请求到看到首个输出是否更快；
3. 稳态与尾部延迟：每输出Token耗时（TPOT）、间Token延迟（ITL）以及P99尾部延迟是否改善；
4. 工程可用性：定制互连开启后，错误率、重试、温度功耗、兼容性和长期稳定性是否可接受。

需要强调，互连只是推理系统性能的一个变量。批处理策略、调度队列、显存容量、模型并行方式、输入输出长度和请求分布，都可能对结果产生更大影响。因此，评测结论必须带条件，不能外推为所有模型、所有并发和所有硬件拓扑下的通用结论。

三、评测维度设计

评测类型文章不能只写“性能提升明显”，而应把能力拆成可观察、可验证的指标。建议从以下维度建立评测框架：

评测维度	重点观察	结果解读方式
功能完整性	互连开启后推理链路是否完整，是否支持目标并行策略	功能不通时，性能数据无意义
吞吐性能	输出Token吞吐、总Token吞吐、请求吞吐	看固定输入输出长度下的稳定值
首Token延迟	TTFT均值、中位数、P99	交互式场景重点看P99而非只看均值
每Token耗时	TPOT均值、P99	长输出场景关注持续生成速度
间Token延迟	ITL分布、P99	观察卡顿和排队抖动
稳定性	长时间运行、异常输入、资源紧张、重试与错误率	小样本短时结果不能替代长稳验证
兼容性	运行环境、驱动、固件、框架配置、模型格式	定制改造需重点验证升级与回滚
可观测性	日志、指标、告警、链路定位	能否定位互连异常和调度瓶颈
成本结构	硬件改造成本、验证人力、运维成本、故障风险	不只看峰值吞吐，要看收益成本比
场景适配度	低并发交互、高并发在线服务、长输出批处理	不同场景关注指标不同

四、评测环境与前提

为保证结论可解释，测试应控制变量。本文参考材料给出的测试条件可概括为：单机双卡消费级GPU，使用同一通用推理服务框架，部署约数十亿参数级语言模型；对比“互连开启”和“互连关闭”两种模式；在单并发和4并发下执行固定工作负载；每轮记录约10个请求，总输入约1.08万Token、总输出约1.02万Token；记录吞吐、TTFT、TPOT、ITL和P99等指标。

评测前需要明确以下边界：

• 同一模型权重、同一精度策略、同一显存配置和同一运行环境；
• 互连开启与关闭仅改变卡间通信路径，其他配置尽量保持一致；
• 固定输入长度和输出长度，避免长短请求混合导致均值失真；
• 测试前进行预热，避免首次加载和缓存冷启动污染结果；
• 至少重复多轮，报告中位数、均值、P99及异常情况；
• 记录错误率、超时、重试、温度、功耗和是否发生降频；
• 小样本短时测试只能作为方向性参考，生产选型需补充长稳和灰度验证。

五、评测方法与流程

建议采用“基线—对比—分场景—长稳”的流程。先关闭互连建立基线，再开启互连重复相同工作负载；分别测试单并发和4并发；最后补充长输出、短输出、异常输入和高负载持续运行测试。

示意性流程如下：

for mode in ["互连开启", "互连关闭"]:
    for concurrency in [1, 4]:
        warmup()
        for round in range(3):
            result = run_fixed_workload(
                concurrency=concurrency,
                input_length=fixed,
                output_length=fixed,
                mode=mode
            )
            record(result)
        compare_median_mean_p99()

验证清单应包括：

1. 功能验证：互连开启后模型能否正常加载、正常生成、正常结束；
2. 性能验证：记录吞吐、TTFT、TPOT、ITL的均值、中位数和P99；
3. 稳定性验证：连续运行、重复请求、异常输入、资源紧张时是否报错；
4. 兼容性验证：运行环境升级、配置变更、回滚路径是否清晰；
5. 可观测性验证：日志和指标能否区分排队慢、计算慢还是通信慢；
6. 成本验证：改造投入、验证人力、运维复杂度和故障风险是否可控。

六、结果解读

材料给出的无互连基线中，单发场景输出Token吞吐约40.41 tok/s，平均TTFT约1224.62 ms，平均TPOT约23.57 ms，P99 ITL约46.98 ms；4并发场景输出Token吞吐约104.87 tok/s，平均TTFT约3510.60 ms，P99 TTFT约4853.63 ms，平均TPOT约29.15 ms，P99 TPOT约32.53 ms。材料同时给出互连开启后的汇总收益：单发吞吐收益约8%～10%，4并发吞吐收益约13%～15%；4并发下TTFT降低约23%，P99尾部延迟降低约50%。由于材料未展开互连开启后的完整明细表，本文只引用其汇总结论，不补造绝对值。

观察场景	汇总结果	解读
单发	吞吐收益约8%～10%	单发时计算和单卡访存占主导，互连收益有限但并非无效
4并发	吞吐收益约13%～15%	高并发下卡间同步和排队更突出，互连价值上升
4并发TTFT	降低约23%	首Token等待改善，交互式服务更有意义
4并发尾部延迟	P99约降低50%	高负载排队抖动改善，但需长稳复核
并发1到4	吞吐提升约160%～170%	批处理和调度是第一功臣，互连是稳态优化
并发代价	每Token生成延迟增加约15%～25%	吞吐提升伴随单请求延迟上升，需按SLO权衡

结果解读应避免绝对化。单发收益小，不代表互连没有价值；如果业务对首Token延迟和尾部抖动敏感，高并发下的改善可能更有意义。反过来，如果业务以低并发、短请求为主，互连改造的收益可能不如模型量化、显存优化、调度策略和缓存命中优化直接。并发从1提升到4带来的吞吐增长远高于互连收益，说明批处理与调度策略是吞吐提升的主要来源，互连更多是降低高负载下的同步等待和排队时延。

七、技术原因与适用场景

从技术上看，单发推理主要受单卡计算、显存带宽和单请求串行链路限制，卡间通信占比不高，因此互连收益有限。高并发时，多请求批处理会增加卡间同步频次、键值缓存分片访问和队列等待，互连效率对TTFT和P99更敏感，因此收益更明显。定制互连改造还可能带来温度、功耗、驱动兼容和长期可靠性问题，必须纳入评测。

适用场景可这样判断：低并发开发测试和个人实验，应优先关注模型可用性、显存容量和易用性；在线交互服务应重点关注TTFT、P99和错误率；高并发推理服务应关注吞吐、排队时延和长稳；长输出批处理应同时看TPOT和总成本。对稳定性要求高的生产系统，定制改造应先小规模灰度，建立回滚方案和监控告警，再评估是否扩大范围。

八、风险、限制与选型建议

本次评测的主要限制包括：样本请求数较少、单机双卡、单一模型规模、固定输入输出长度、短时测试，不能直接外推到多机多卡、其他模型结构或复杂请求分布；材料未展开互连开启后的完整明细，结论以汇总收益为主；定制硬件改造可能影响保修、散热、供电、固件兼容和故障恢复。

选型建议是：先建立关闭互连的基线，再分单发和4并发对比；不要只看平均吞吐，要同时看TTFT、TPOT、P99和错误率；用多轮重复和长稳测试确认收益是否稳定；计算改造成本、验证成本和运维风险；在生产前做小流量灰度，保留快速回滚路径。只有当业务SLO明确需要更低首Token延迟、更高并发吞吐或更低尾部抖动，且改造后的稳定性与成本可接受时，定制互连才更具投入价值。

九、总结

本文围绕双卡定制高速互连对推理服务的影响，建立了从功能、吞吐、延迟、稳定性、兼容性到成本结构的评测框架。结合材料结果可概括为：互连在单发下收益有限，在高并发下对吞吐、TTFT和P99尾部延迟改善更明显；并发与调度是吞吐提升的主要来源，但会增加每Token生成延迟。读者在选型时应坚持控制变量、分场景压测、看尾部指标、验证长稳与回滚，避免用单一峰值数据替代业务场景判断。