AI 纪元 追踪人工智能最新进展,深度解读前沿技术

昇腾910C扩到万卡之前,先把运保账算清

据公开通报,昇腾910C集群已完成1.6万亿参数DeepSeek-V4-Pro全参数后训练,但通报未披露卡数、PUE、故障率和运保成本。准备扩到万卡时,能耗边界、备件粒度、版本适配与服务响应,都应写进验收和合同。

0 次阅读 约 2331 字 5 分钟 AI 生成

据新浪科技援引“深圳发布”的6月5日通报,深圳河套学院AI训练平台项目团队联合哈尔滨工业大学(深圳)、深圳市大数据研究院和华为有关团队,协同深智城AI算力平台,依托昇腾910C集群完成了1.6万亿参数DeepSeek-V4-Pro全参数后训练。

这条消息先回答了最受关注的问题:在昇腾910C上,特定的大模型后训练任务能不能做完。现在已经有了公开案例。

通报没有同步给出集群卡数、持续运行时长、PUE、故障记录、备件消耗和运保投入。用这次训练结果直接估算万卡集群的总拥有成本,证据还不够。

在此之前,昇腾910C已经出现供货和服务方面的公开进展。控制网的一则资讯称,昇腾910C于2025年5月开启大规模供货;据证券时报网转引21世纪经济报道,6月20日的华为开发者大会上,华为云计算CEO张平安宣布新一代昇腾AI云服务全面上线。采购方接触到的对象,已经从芯片扩展到云服务和交付支持。接下来要核对的,是每个月究竟能交付多少有效算力。

训练完成,只回答了第一道题

一次训练任务有明确的模型、并行策略、软件版本和运行窗口。生产集群则会不断换模型、换负载、升级版本,还要处理节点退出、通信异常和任务重启。单次任务完成与长期可用之间,缺的是可重复的运行记录。

来源页未标明发布机构的一份《探索昇腾910C十万卡集群》将讨论范围推到了十万卡。其摘要回顾了2019年首代昇腾910的“1+1+4”结构,包括计算带、I/O带和4个HBM2模块。这类资料可以帮助理解加速器的组成,却不能据此推断910C的现场故障率,更不能直接算出备件比例。

规模扩大后,验收需要按故障域来做。单卡、节点、机柜、网络和机房分别出现异常时,任务能否隔离、重新调度并从检查点恢复,都要留下记录。峰值算力仍然重要,但它只是验收表中的一项。

电费要和有效训练时长放在一起

PUE是数据中心总能耗与IT设备能耗的比值。它能描述机房整体效率,一个平均值却看不出具体训练任务花了多少电,也看不出功率和制冷约束是否拖慢了任务。

训练负载并非一条平线。数据准备、矩阵计算、集合通信和检查点保存,对计算、网络和存储的压力并不相同。模型和并行策略一换,负载曲线也会跟着变。

现有公开资料没有提供昇腾910C万卡集群可核实的PUE阈值、实测值或能源违约金额。违约金是否存在,取决于具体合同。没有合同条款和现场曲线,不宜把它写成已经发生的损失。

采购和验收时,更值得索取以下记录:

  • 空载、典型训练任务和通信高负载场景下的用电曲线;
  • IT设备用电与制冷、配电等机房用电的分项数据;
  • 因供电或散热限制发生的降频、暂停及其任务影响;
  • 如果合同涉及PUE考核、最大需量或峰谷结算,相应的统计周期与责任边界。

电费总额还要对应有效训练时长。低电费若来自限频或任务停摆,就很难算作成本优化。

备件库里,最怕“N+1”含糊

采购合同中写一句N+1并不够。需要先说清楚,备用对象究竟是整机、节点、加速板卡、电源,还是网络与液冷部件。

整机备份容易执行,资金占用也高;按模块储备更灵活,但依赖准确诊断和版本匹配。对于板卡、HCCS互联、网卡或光模块等不同故障点,定位责任和更换边界也可能不同。

一份能执行的备件方案,至少要回答几件事:

  • 厂商认可的现场可更换单元有哪些;
  • 备件放在本地机房,还是厂商区域仓库;
  • 更换后的硬件是否兼容现有固件、驱动和CANN版本;
  • 备件领用后如何补库,故障件如何返修;
  • 无法现场修复时,由谁承担调货、迁移和任务恢复工作。

现有材料没有可核实的备件交期和预算增幅,也不足以给出统一囤货比例。更稳妥的办法,是根据可更换单元清单和恢复目标倒推库存,而不是照搬传统服务器的整机备份方式。

运保成本,往往写在版本矩阵里

昇腾集群的运行涉及CANN、训练框架、通信组件、固件、驱动和集群管理工具。任意一层升级,都可能带来兼容性验证和回退工作。运保服务如果只承诺“快速响应”,采购方很难据此核算人力投入和停机损失。

华为在2025年全联接大会的公开演讲中提到,为承接DeepSeek快速增长的用户和流量,华为云及AI研发团队从春节开始协同工作,到4月30日才使Ascend 910B/910C的推理能力达到客户的基本需求。

这段经历针对推理服务,不能拿来估算训练集群的工单量。不过它说明,从芯片交付到客户可用,中间还有版本适配和跨团队协作。

运保合同至少应写清:

  • 支持的CANN、框架、模型和算子版本范围;
  • 升级前的验证流程,以及升级失败后的回退方式;
  • 不同级别故障的响应、恢复和升级通道;
  • 重复故障是否需要根因分析和知识库沉淀;
  • 驻场、远程支持与非工作时间服务的边界。

只统计工单数量没有太大意义。更值得跟踪的是故障影响了哪些任务、多久恢复、是否重复发生,以及最后由哪一方完成闭环。

验收时,留四张能持续更新的表

台账 至少记录什么 合同里要问清什么
有效算力 任务完成情况、有效训练时长、中断原因、恢复时长 验收以峰值性能、任务完成还是持续可用为准
能耗 IT用电、机房用电、负载峰值、限频与停机记录 PUE、需量和能源约束由谁承担
备件 可更换单元、库存位置、版本、补货与返修状态 更换时限、兼容性和故障件归属
运保 软件版本、工单原因、恢复过程、根因分析 响应与恢复承诺、升级回退、驻场边界

1.6万亿参数后训练证明了特定任务可以完成,总拥有成本仍需要另一套证据。准备扩到万卡之前,建设方应先用代表性负载做试运行,再把能耗、备件、版本和服务责任写进合同。

芯片采购价只是总账中的一行。这四张表不够热闹,却决定集群上线后有多少时间真正在训练,又有多少时间花在等电、等件和等人上。

相关阅读