把昇腾910C和NVIDIA H200放到推荐系统里比较，最容易犯的错误，是用几组芯片参数直接推导训练吞吐和线上延迟。
现有公开资料能说明硬件差距，却没有提供统一模型、统一集群配置和统一软件版本下的推荐系统测试。因此，原稿中DLRM吞吐、P99延迟、迁移成本和三年TCO等数字，无法从所列来源得到验证。能确定的，是两款芯片的纸面能力不同，而这部分差距会在推荐业务的访存和通信环节被放大或缩小。
公开参数先说明了什么
据网易订阅转述的进步研究所报告，昇腾910C的“总算力”为12032，H200为15840；内存带宽分别为3.2TB/s和4.8TB/s。按照这一口径，H200在计算能力和数据搬运速度上都占优。
腾讯云开发者社区给出的另一组数据则显示，昇腾910C的FP16算力为800 TFLOPS，HBM容量为96GB，显存带宽为1.8TB/s，HCCS互联带宽为400GB/s。该文还给出了约30%的MFU，以及DeepSeek-R1推理场景下6688 tok/s/NPU的数据。
两组资料中的带宽数据并不一致，说明其产品配置或统计口径可能不同。没有完整测试条件时，不宜把这些数字拼成一张所谓“实测榜单”。但方向很清楚：与H200相比，910C的主要压力不只来自峰值算力，内存带宽同样是需要面对的短板。
推荐系统更在意数据搬运
推荐模型包含大量Embedding查表、稀疏特征交互和跨卡通信。很多时候，计算单元并没有持续满载，时间消耗在读取参数、交换数据和等待算子执行上。
这也是内存带宽值得单独看的原因。进步研究所采用的口径中，910C为3.2TB/s，H200为4.8TB/s。对于频繁访问Embedding表的训练任务，这一差距可能直接影响吞吐；到了多卡环境，还要继续考察HCCS、NVLink以及All-to-All通信的实际效率。
不过，公开素材没有给出两款芯片运行同一推荐模型的结果，无法据此断言H200快多少，也不能直接写出某个P99延迟。模型规模、批次大小、特征分片方式和算子版本改变后，结果都可能不同。
迁移难点落在CANN上
腾讯云开发者社区的文章把比较范围从芯片延伸到了CANN和CUDA软件栈，这比单看参数更接近工程现场。
推荐系统并不是把模型代码换个设备就能运行。Embedding分片、稀疏梯度聚合、算子融合和跨卡通信都需要重新适配。CUDA已有较完整的工具和算子积累，昇腾则依赖CANN完成图编译、算子调度与集群通信。硬件能够执行，不等于业务可以低成本迁移。
约30%的MFU也提供了一个观察角度：如果计算单元利用率不高，继续增加纸面算力未必能等比例提高吞吐。对使用910C的团队来说，算子覆盖、通信调优和任务调度可能比追逐单卡峰值更实际。
哪些环节更适合先迁
推荐链路通常包括召回、粗排、精排和重排。它们对延迟、算力和软件适配的要求并不相同，因此没有必要一次性更换整条链路。
召回和轻量粗排通常模型较小，更适合作为国产算力的试点。团队可以先验证向量检索、Embedding查询和小模型推理，观察吞吐、尾延迟及多卡扩展效率。离线任务没有线上请求那样严格的延迟约束，也能为算子适配和调度积累经验。
核心精排更谨慎。这里往往模型更复杂，直接影响用户看到的内容顺序。只要P99延迟、稳定性或故障恢复没有通过业务验证，就不适合仅凭参数表决定迁移。
更可行的做法是按链路分级：先把风险较低、可回滚的任务放到910C，延迟敏感的核心环节继续使用成熟平台。是否扩大范围，再看真实业务中的利用率、稳定性和维护成本。
现在还不能下“全面替代”的结论
从公开参数看，H200仍有明确优势；从供应和产业选择看，910C又是国内高端AI芯片中无法绕开的产品。两件事可以同时成立。
真正需要补齐的，不是一组更漂亮的对比数字，而是可复现的推荐系统测试：同一模型、同一精度、相近集群规模，公开训练吞吐、P99延迟、功耗、利用率和迁移工作量。缺少这些条件，所谓“实测差距”只是把不同来源的数据硬凑在一起。
对准备迁移的企业而言，问题也不该停留在“哪张卡更强”。更有价值的判断是：哪些任务已经能稳定运行，哪些算子仍需重写，哪些链路值得承担迁移成本。910C能否进入推荐系统腹地，最终取决于这些工程账，而不只是一张参数表。
参考来源：
