在华为全联接大会2026上，华为发布了号称全球首个采用NPO技术的超节点——昇腾960超节点，目标是加速十万亿规模大模型的训练与推理。这一发布传递出的重点，不只是增加单颗芯片的计算能力，而是把计算、互联、内存、调度和软件栈作为一个完整系统交付。
目前公开摘要没有披露NPO的完整技术定义、互联规格、内存容量或实测数据，因此不宜仅凭名称推断其实现方式。对准备评估这类基础设施的团队来说，更有价值的问题是：超节点能否让大规模任务稳定扩展，并把硬件能力转化为可持续的模型吞吐量？
为什么“大模型算力”开始以超节点为单位
模型规模持续上升后，单个加速器很难独立容纳参数、优化器状态、KV Cache和中间激活值。工程团队通常需要在多个设备之间切分任务，包括：
- 张量并行：拆分单层中的矩阵计算；
- 流水线并行：把不同网络层放到不同设备；
- 数据并行：在多个副本间同步梯度；
- 专家并行：让混合专家模型的专家分布到不同设备；
- 推理分离：根据系统设计拆分预填充与解码阶段。
这时，峰值算力只是上限。互联通信、内存容量、集合通信效率、任务调度和故障恢复都会决定实际性能。超节点的价值，正是在硬件边界内统一设计这些环节，减少跨设备扩展时的损耗。
对于“十万亿规模”模型，还需要特别区分参数总量与单次推理激活的参数量。混合专家模型可以拥有非常大的总参数量，但每个Token可能只激活其中一部分。采购和容量规划时，应同时确认总参数、激活参数、精度格式、上下文长度以及并发目标，不能只比较一个模型规模数字。
NPO值得关注，但不能跳过可验证指标
来源摘要明确指出昇腾960超节点采用NPO技术，但没有提供足够细节来解释该缩写、拓扑或协议。因此，现阶段更稳妥的做法是把NPO视为待验证的系统能力，而不是自行补全技术定义。
评估时可以要求供应方或集成团队给出以下数据：
- 单节点有效吞吐量：训练用每秒Token数，推理用每秒输出Token数；
- 扩展效率：从一个超节点扩展到多个超节点后，吞吐量增长是否接近线性；
- 通信占比：计算、集合通信和数据等待分别消耗多少时间；
- 长时间稳定性：连续运行数天后是否出现设备错误、性能衰减或任务中断；
- 故障恢复时间：设备或链路异常后，任务能否从检查点恢复；
- 软件兼容性：现有模型、算子、容器镜像和训练框架需要改造多少；
- 单位成本：以每百万Token训练成本或每百万输出Token推理成本衡量，而非只看硬件数量。
一个常用的扩展效率计算方式是：
扩展效率 = N个节点的实际吞吐量 /（单节点吞吐量 × N）
例如，单节点吞吐量为每秒10万Token，8个节点实际达到每秒68万Token，则扩展效率为85%。这个数字需要和模型结构、批大小、精度以及网络配置一起记录，否则不同测试之间无法公平比较。
可以这样实践：建立可重复的推理验收任务
如果昇腾960超节点最终通过Kubernetes或类似平台交付，可以先建立一个与厂商资源名称解耦的测试模板。下面的YAML是通用示例，并不代表昇腾960的实际设备插件名称。运行前需要修改三处内容：镜像地址、模型挂载方式，以及集群真实的加速器资源键。
apiVersion: batch/v1
kind: Job
metadata:
name: llm-supernode-benchmark
spec:
backoffLimit: 0
template:
metadata:
labels:
app: llm-supernode-benchmark
spec:
restartPolicy: Never
containers:
- name: benchmark
image: registry.example.com/ai/llm-benchmark:latest
imagePullPolicy: IfNotPresent
env:
- name: MODEL_PATH
value: /models/target-model
- name: INPUT_TOKENS
value: "2048"
- name: OUTPUT_TOKENS
value: "512"
- name: CONCURRENCY
value: "32"
- name: WARMUP_REQUESTS
value: "20"
- name: TEST_REQUESTS
value: "200"
resources:
requests:
cpu: "16"
memory: 64Gi
example.com/accelerator: "8"
limits:
cpu: "16"
memory: 64Gi
example.com/accelerator: "8"
volumeMounts:
- name: models
mountPath: /models
readOnly: true
volumes:
- name: models
persistentVolumeClaim:
claimName: llm-models-pvc
修改完成后执行：
kubectl apply -f benchmark-job.yaml
kubectl wait --for=condition=complete job/llm-supernode-benchmark --timeout=2h
kubectl logs job/llm-supernode-benchmark | tee benchmark-result.log
镜像中的基准程序至少应输出以下指标：
{
"model": "target-model",
"input_tokens": 2048,
"output_tokens": 512,
"concurrency": 32,
"requests": 200,
"tokens_per_second": 0,
"time_to_first_token_ms_p50": 0,
"time_to_first_token_ms_p99": 0,
"inter_token_latency_ms_p99": 0,
"failed_requests": 0
}
其中，预填充密集型任务更关注首Token时间和输入吞吐量，长文本生成则更关注逐Token延迟。只报告平均延迟容易掩盖尾部抖动，因此至少应记录P50、P95和P99。
从“能运行”到“值得迁移”
昇腾960超节点是否适合现有业务，不能只靠厂商峰值指标判断。建议先选择一个具有代表性的模型和流量分布，完成以下验收闭环：
- 固定模型版本、数据集、输入长度、输出长度与精度；
- 在现有平台和候选平台运行同一套测试；
- 分别记录冷启动、稳态吞吐量、尾延迟和错误率；
- 做一次设备故障或进程退出演练，测量恢复时间；
- 验证检查点、模型格式、自定义算子和监控工具的迁移成本；
- 用实际Token产量计算能耗、设备、机房和运维综合成本。
这次发布反映了AI基础设施竞争正在从单芯片参数转向系统级能力。昇腾960超节点及其NPO技术的真实价值，最终仍要由模型吞吐量、扩展效率、稳定性和迁移成本共同证明。在完整规格与独立测试出现之前，把宣传指标转化为可复现的验收任务，是工程团队更可靠的决策方式。