两张计算卡互联后，标称带宽翻倍，不代表任务速度也翻倍。高速卡间互联技术对比应结合实际工作负载，检查数据传输、卡间同步和软件调用是否真的成为瓶颈。可将 NVIDIA H100 SXM 的 NVLink、AMD Instinct MI300X 的 Infinity Fabric 链路作为不同互联方案的具体评估对象，但最终表现还取决于整机拓扑、卡数和软件。
先明确比较条件，再看六项指标
测试前固定卡型、卡数、功耗限制、驱动与软件版本，并记录卡间连接方式。否则，互联差异可能和散热、算子实现或系统配置混在一起。尽量使用目标应用的任务，同时用通信基准测试交叉验证。
1. 有效带宽：测得到多少，而非标称多少
标称带宽通常描述链路理论能力，应用能用到的有效带宽还受协议开销、传输方向、数据大小和并发任务影响。分别测试单向与双向传输，并覆盖小块和大块数据；小消息测不出大流量峰值，大消息也不能代表频繁同步场景。记录持续吞吐，而非只取短时峰值。
2. 通信时延：小消息尤其敏感
分布式训练中的梯度同步、推理中的卡间协调，可能受时延而非带宽限制。测量不同消息大小下的往返时延和高分位时延，并观察负载升高后是否明显恶化。小批量、频繁同步的任务通常更在意时延；连续传输大张量则更关注带宽。
3. 扩展效率：增加卡数后是否仍有收益
比较单卡、双卡及目标部署规模下的吞吐或完成时间。若卡数增加后总吞吐增长有限，原因可能是通信、同步或任务切分，而非互联单项指标不足。要记录扩展效率：多卡性能相对单卡性能的提升，并注明测试任务和卡数，不能把不同负载的结果直接横比。
4. 拓扑与拥塞：卡之间是否都能顺畅通信
检查设备拓扑图，确认卡间是直连、经交换芯片转发，还是经过主机端路径；不同路径可能带来不同带宽和时延。用多对卡同时传输，观察总吞吐是否随并发增加而下降。高速卡间互联技术对比若只测一对设备，容易漏掉多卡争用同一链路的情况。
5. 数据共享能力：传输之外还要看访问方式
有些互联支持设备间直接访问或共享内存语义，有些主要承担数据搬运，编程模型和同步方式并不相同。CXL可用于设备与内存扩展等场景，但不能仅凭名称就视为卡间高速互联的等价替代。应核实处理器、主板、设备和运行时是否共同支持所需功能，再测试数据复制次数与同步开销。
6. 软件、稳定性与部署成本
确认框架能否启用目标互联、是否需要特定通信库，以及故障诊断和监控是否可用。用长时间、持续满载任务检查错误、降速和温度影响，并把交换设备、布线、散热、电力及维护纳入总成本。纸面性能更高但软件路径不匹配，实际收益可能有限。
一套可执行的评估流程
选定真实任务，记录输入规模、精度、批量和目标卡数。
核对设备拓扑、驱动与通信库版本，确认互联功能确实启用。
先测单卡基线，再测双卡及目标规模；分别记录时延、持续带宽和任务完成时间。
增加并发通信与长时间负载，检查拥塞、降速及结果稳定性。
按相同任务和系统条件复测，并将硬件、软件和运维成本一并比较。
最终选择应由工作负载决定：大规模数据交换优先看持续带宽和扩展效率，频繁同步优先看时延与拥塞，涉及共享访问则重点核对内存语义和软件支持。做好这些检查，高速卡间互联技术对比才有实际决策价值。
常见问题
标称带宽越高，任务一定越快吗？
不一定。任务可能受时延、同步、算力或软件实现限制，需以目标应用实测为准。
只测双卡够不够？
不够。双卡能初步比较链路，多卡并发测试才能暴露拓扑差异和共享链路拥塞。
不同厂商的互联可以直接按数字比较吗？
不宜只对照标称值。需统一传输方向、消息大小、设备数量和测试软件，再比较有效性能。
什么时候要把成本纳入评估？
当方案需要额外交换设备、专用布线或更高散热与供电能力时，应比较完整部署和运维成本。
