曙光8000：十万张计算卡如何变成"一台计算机"？
引言：超越"十万卡"的技术叙事
如果把十万张计算卡摆进同一个机房，能不能得到一套十万卡AI超集群？
答案是否定的。
计算卡只是系统中的执行单元。它们可能来自不同批次，承载不同任务，读取不同数据，也可能随时出现通信拥塞、性能波动甚至硬件故障。如果缺少统一的网络、存储和调度体系，十万张卡更像十万个彼此孤立的计算节点，而不是一台完整的计算机。
曙光8000真正要解决的问题，正是如何跨过这道边界。作为中国首个全国产十万卡AI超集群，曙光8000的技术目标并非简单扩大设备数量，而是让海量计算资源在逻辑上形成一个整体：用户提交任务时，不必逐一选择计算卡、服务器和存储节点，系统能够自动拆解任务、分配资源并组织执行。
从这个角度看，曙光8000最值得关注的并不是"十万卡"三个字，而是它试图完成的一项系统工程：把一座计算中心，组织成一台可以统一调度的超级计算机。
第一关：十万张卡如何同时工作？
单机计算的基本逻辑并不复杂：处理器读取数据，完成运算，再把结果写回存储。但大模型训练则完全不同。
一个大模型通常无法放进单张计算卡，需要被拆分到数百、数千乃至数万张卡上。每张卡只负责其中一部分计算，并不断与其他计算卡交换数据。这意味着，大模型训练并不只是计算问题，也是通信问题。
随着卡数增加，通信关系会迅速变得复杂：
- 部分节点稍微变慢，其他节点就可能被迫等待
- 某条网络链路出现拥堵，整个训练任务的效率都会下降
在千卡集群中，这类问题尚能通过局部优化解决。到了十万卡规模，任何微小的等待都可能被系统放大。因此，十万卡集群首先要解决的，不是让单张卡计算得更快，而是让十万张卡之间"说得上话"、联得通畅。
曙光8000通过全国产高速互连网络组织计算节点，目的就是在大规模并行任务中，提高数据交换效率。网络不只是连接设备的通道，而是整个系统的一部分。任务如何拆分、数据从哪里流向哪里、不同节点何时同步，都要与网络架构协同设计。
这也改变了传统集群的建设思路。过去，计算、网络和应用往往分别优化；在十万卡系统中，三者必须协同设计。否则，增加计算卡可能不会带来同比例的性能提升，反而会制造更多通信开销。
十万卡系统最重要的技术指标之一，由此不再是单卡峰值，而是规模扩大之后还能保留多少有效性能。
第二关：一套系统如何同时处理多种计算？
目前大多数AI集群主要围绕大模型训练建设，但现实中的计算需求远比大模型复杂。
| 计算场景 | 典型精度 | 应用领域 |
|---|---|---|
| 大模型训练 | FP16、BF16 | AI训练 |
| 科学计算 | FP64 | 气候模拟、材料计算、航空航天 |
| 推理应用 | INT8 | 大模型推理、产业应用 |
不同任务对计算精度、通信方式、数据吞吐和运行时间的要求并不相同。传统做法往往是分区建设：一部分设备负责科学计算，另一部分设备负责AI训练，彼此拥有不同的软件、网络和管理系统。这种方式边界清晰，但也带来一个问题：不同分区的负载很难完全同步。
- 大模型训练区可能排队，科学计算区却有资源闲置
- 某项科研任务需要同时调用模拟计算和AI能力时，还要跨系统迁移数据
曙光8000采用"超智融合"技术路线，支持从FP64到INT8的多精度计算，试图把科学计算、大模型训练、推理以及AI for Science任务放进同一套系统。
这里的"融合"，并不是把不同设备放进同一个机房，而是让它们接受统一的资源管理。比如，一项创新药研发任务可能：
1. 先进行分子动力学模拟
2. 再用AI模型筛选候选结构
3. 最后对结果进行高精度验证
过去，这几个环节可能分别运行在超算、智算和存储系统上；在超智融合系统中，任务可以在同一套资源环境内连续执行。
这类变化对科学智能尤其重要。AI for Science并不等于用大模型替代科学计算。更常见的模式是：科学模拟产生数据 → AI从中寻找规律 → 高精度计算进行验证。两种计算方式需要频繁交换数据，系统边界越少，任务流转效率越高。
从技术上看，曙光8000解决的不只是算力规模问题，也是多种计算范式如何共同运行的问题。
第三关：十万卡系统如何应对故障？
单台服务器发生故障，影响的可能只是一个节点。但在十万卡系统中，故障则会成为一种常态。
计算卡、网络端口、存储设备、电源模块和冷却单元数量大幅增加后，即使每个部件的可靠性都很高，系统整体仍然会频繁遇到异常。这是一道概率题。假设一个部件平均数年才出现一次问题，当系统拥有数十万个相关部件时，局部故障就可能每天发生。
十万卡系统无法追求"永不出错"，只能追求出现问题后仍然能够继续运行。这要求系统具备更强的可观测和恢复能力：
1. 首先要知道故障发生在哪里
十万卡系统同时存在计算、通信、存储、供电和散热数据，只靠人工巡检很难及时定位问题。管理系统需要持续收集节点状态，识别异常性能和潜在故障。
2. 其次要判断故障影响了哪些任务
一个网络端口异常，可能只影响少数节点，也可能拖慢一项跨越数千张卡的训练作业。系统必须在海量运行信息中找到真正的关联关系。
3. 最后还要恢复任务
对于持续数天甚至数周的大模型训练，系统不能因为一个节点故障就从头开始。它需要通过检查点保存训练进度，并在资源发生变化后重新组织任务。
因此，十万卡集群的可靠性，不再只是硬件质量问题，而是软硬件共同参与的系统能力。系统越大，越不能依赖每个部件都不出错。让故障能够被发现、隔离和恢复，才是超大规模计算长期运行的前提。
第四关：数据能不能跟上计算速度？
AI集群容易出现一种看似矛盾的现象：计算卡很多，但任务依然跑不快。
原因可能不在计算，而在数据。大模型训练需要不断读取训练数据、保存模型参数和生成检查点；科学计算则可能产生海量中间结果。如果存储系统供给数据的速度低于计算卡消耗数据的速度，昂贵的计算资源只能等待。
十万卡规模会把这种矛盾进一步放大：
- 大量节点可能同时读取同一批数据
- 成千上万个训练进程会并发写入结果
传统存储系统很容易在高并发访问中形成堵点。曙光8000需要依靠并行存储体系，把数据分布到多个存储节点，再通过高速网络同时向计算任务供给。其目标不是简单扩大存储容量，而是让数据流动速度与十万卡的计算规模相匹配。
这也解释了为什么，存储在AI基础设施中的地位正在上升。模型规模越大，训练使用的数据越多，产生的检查点也越庞大。一次模型保存可能涉及大量参数，如果写入时间过长，就会直接占用训练窗口。发生故障时，检查点能否被迅速读取，又决定了任务恢复速度。
计算、网络与存储因此形成了一组相互制约的关系：
- 计算卡决定理论运算能力
- 网络决定节点之间的协同速度
- 存储决定数据能否及时进入和离开系统
任何一项能力不足，都会让另外两项投入打折扣。
十万卡最终要面对的，是十万级复杂度
曙光8000已经完成300多项超智融合应用优化，覆盖大模型、机器人、汽车、创新药、新材料、量子计算、天文气象等20多个领域。
这组数据背后，还有一层容易被忽视的技术含义：十万卡系统不能只适配一个模型、一种框架或者一类任务。不同用户使用的软件环境不同，提交的任务规模不同，对计算精度、网络和存储的需求也不同。系统既要承载持续数周的大规模训练，也要处理数量庞大、运行时间较短的中小任务。
曙光8000上线首周即满载，日处理作业峰值突破50万个。
面对这种负载，系统的难题已经不只是"如何运行一个大任务"，而是如何在大量任务之间分配资源。如果调度粒度过粗，小任务可能长时间等待；如果过度追求资源填满，又可能把计算卡切分得过于零散，影响大型任务执行。系统需要在利用率、任务优先级和运行效率之间不断寻找平衡。
这也是曙光8000与单纯硬件集群的本质区别：
- 硬件集群回答的是"有多少资源"
- 调度系统回答的是"这些资源在此刻应该给谁"
当作业数量达到数十万级，后一个问题甚至比前一个问题更加复杂。
结语：内部越来越复杂，外部却要越来越简单
站在机房外看，曙光8000由大量服务器、机柜、交换设备和冷却管路组成。站在用户一侧，它又需要尽可能隐去这些复杂结构。用户不必知道任务具体运行在哪张卡上，也不必手动规划数据经过哪条网络，只需要提交任务并获得结果。
这正是超大规模计算系统的技术目标：内部越来越复杂，外部却要越来越简单。
所以，曙光8000的核心并不是拥有十万张计算卡，而是通过高速互连、多精度计算、并行存储、智能调度和液冷保障，让十万张卡尽可能表现得像一个计算整体。
十万卡决定了它的规模，而能否把十万张卡组织成"一台计算机"，才真正决定了这套系统的技术含量。
本文基于公开材料分析，信息来源：曙光8000:把十万张计算卡变成"一台计算机"