想象你是一家米其林中餐厅的大厨。后厨的燃气灶、平底锅、烤箱全是进口的，你闭着眼睛都能颠勺。突然有一天，老板把整个厨房换成了国产新厨具：柴火灶、中式铁锅、竹蒸笼。你说：行，照样能做菜！结果发现——锅底受热不均，有的菜谱步骤找不到对应工具（算子不支持），几个厨师的传菜动线完全变了（通信库差异），火候忽大忽小，同样的菜今天咸了明天淡了（精度不一致）。而这时候，外面还坐着 100 桌客人等着吃国宴（百亿参数模型）。这就是国产芯片训练大模型的真实处境。这篇文章不聊虚的，只讲三件事：怎么摸清新灶台的脾气（适配挑战）、怎么改菜谱（框架适配和通信优化）、怎么控火候（混合精度调校），最后带你看一场真正的国宴是如何在后厨统筹完成的。

岗位关联

学会国产芯片上的训练适配与调优，意味着你将掌握“算力无国界”时代的核心工程能力——让同样的模型在任何芯片上都跑得起来、跑得快。

目录
  1. 可视化演示
  2. 芯片适配挑战
  3. 框架适配策略
  4. 通信优化方法
  5. 混合精度调校
  6. 百亿模型实战
  7. 性能调优工具
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

国产芯片训练大模型面临算子支持不全、通信库差异和精度一致性等独特挑战，需要针对性的适配与优化策略。文章围绕框架... 切换模式查看不同维度。

本节配有交互动效（进入视口后自动加载，约 3KB）。

国产芯片训练：核心原理 动态展示关键流程与数据流动 交互控件调节参数实时渲染 f(x) = transform(x) 核心概念的可视化呈现

芯片适配挑战

继续大厨的视角。你发现新灶台的问题不是“不能烧菜”，而是“每一道工序都需要重新确认”：想做蒸鱼，厨房里连蒸笼都没有；想用烤箱烤鸭，国产烤箱的温度曲线跟进口的不一样；更麻烦的是，同一个配方，今天做出来咸了，明天做出来淡了。用行业的话说，这就是算子支持不全、通信库差异、精度一致性和生态碎片化四大挑战。

这些挑战背后的本质是生态的成熟度差异：英伟达 GPU 有十几年积累的 CUDA 生态，上千个算子开箱即用；而国产芯片（昇腾、寒武纪、海光等）的算子库仍在快速补课阶段。模型从 CUDA 世界迁移过来，就像把西餐菜谱直接拿到中餐后厨——第一步先要盘点“哪些步骤做不了”。

具体来说，算子支持不全意味着 PyTorch 代码里常见的 flash_attention、gelu 等算子可能直接报“未实现”；通信库差异意味着原本用 NCCL 完成的 AllReduce 多卡同步无法直接使用，需要换成昇腾的 HCCL 或寒武纪的 CNCL，它们的性能和调优参数各不相同；精度一致性是最隐蔽的难题——不同芯片的矩阵乘累加顺序不同、中间精度不同，同样的随机种子下 loss 曲线也可能分叉甚至发散。

就像大厨拿到新灶后的第一件事是列一份“能用/不能用”的工具清单，算子覆盖率就是这份清单的百分比。做完这一步，你才知道哪些菜能照着原谱做，哪些菜必须改谱。

算子覆盖率=NsupportedNtotal×100%\text{算子覆盖率} = \frac{N_{\text{supported}}}{N_{\text{total}}} \times 100\%
通俗说明：覆盖率就是“新厨房里能直接用的厨具占这道菜所有工序的比例”。比例越高，适配成本越低。
  1. 统计模型算子总量 $N_{\text{total}}$把模型计算图里的所有算子类型去重汇总，比如矩阵乘、LayerNorm、softmax 各算一种，得到分母。
    Ntotal=∣{op1,op2,…,opk}∣N_{\text{total}} = \left| \{ \text{op}_1, \text{op}_2, \dots, \text{op}_k \} \right|
  2. 统计芯片已支持算子数 $N_{\text{supported}}$查阅芯片工具链的算子支持清单，统计其中能直接使用的算子类型数量，得到分子。
    Nsupported=∣{op∈模型∣op∈芯片算子库}∣N_{\text{supported}} = \left| \{ \text{op} \in \text{模型} \mid \text{op} \in \text{芯片算子库} \} \right|
  3. 相除并转化为百分比占比越高越能开箱即用，剩下的 $1 - \text{覆盖率}$ 就是需要适配的工作量。
    需要适配的算子占比=1−NsupportedNtotal\text{需要适配的算子占比} = 1 - \frac{N_{\text{supported}}}{N_{\text{total}}}

框架适配策略

清单列完了，大厨开始“改谱”。原版菜谱写“大火爆炒 30 秒”，柴火灶火力不够，那就拆成“中火焖 2 分钟再转猛火收汁 10 秒”。改谱不是降低标准，而是让同一道菜在新厨具上做出来依然好吃。这就是框架适配。

在工程上，“菜谱”就是深度学习框架里的计算图。PyTorch 是当下最流行的“通用菜谱”，国产芯片厂商则提供自己的“方言版本”：昇腾有 torch_npu 和 MindSpore，寒武纪有 torch_mlu。选哪个框架，决定了后面的适配工作量。实践中最稳妥的策略是优先选择使用最广的 PyTorch 分支，因为社区案例多、踩坑记录全，遇到问题更容易找到答案。

框架适配有四个层次。第一是框架选型，选择生态成熟的分支作为基线。第二是算子映射，把芯片不支持的算子改写为若干原生算子的组合，例如 flash attention 拆成 matmul + softmax + matmul。第三是图编译优化，用 torch.fx 或厂商的图编译器做算子融合、常量折叠，减少 kernel 启动次数。第四是自定义算子，当映射和融合都解决不了时，用 TBE 或 CAMBRICON 自定义算子等方式手写高性能实现。

改谱改得越多，越要反复试菜。替换率就是“试菜工作量”的预告牌——它告诉你还有多少道工序是新厨具没验证过的，需要安排专门测试。

算子替换率=NreplacedNtotal×100%\text{算子替换率} = \frac{N_{\text{replaced}}}{N_{\text{total}}} \times 100\%
通俗说明：替换率就是“为了适配新灶台而改写的工序比例”。替换率越高，说明原菜谱被改得越多，验证风险也越高。
  1. 统计被替换的算子数 $N_{\text{replaced}}$统计因芯片不支持或性能差而做了映射、融合或自定义的算子数量，三部分累加。
    Nreplaced=Nmapped+Nfused+NcustomN_{\text{replaced}} = N_{\text{mapped}} + N_{\text{fused}} + N_{\text{custom}}
  2. 与模型算子总量相除用替换数除以模型算子总量，得到被改动工序的占比。
    NreplacedNtotal\frac{N_{\text{replaced}}}{N_{\text{total}}}
  3. 转化为百分比乘上 100% 得到替换率，便于横向比较不同模型在国产芯片上的适配成本。
    算子替换率=NreplacedNtotal×100%\text{算子替换率} = \frac{N_{\text{replaced}}}{N_{\text{total}}} \times 100\%

通信优化方法

国宴不是一个大厨做完所有菜。后厨有八个厨师，有的切配、有的掌勺、有的摆盘，菜品原料必须在他们之间高效流转。如果传菜走廊只够一个人走，再快的炒菜速度也会被堵在走廊里。多卡训练里的“走廊”，就是芯片之间的通信链路。

百亿参数模型通常需要几十甚至上百张卡协同训练。每训练一步，所有卡都要通过 AllReduce 把彼此的梯度汇总并广播回去。通信耗时一旦占比过高，芯片算得再快也只能干等着。在国产芯片上，这条“走廊”的脾气和英伟达的 NCCL 完全不同，必须单独优化。

通信优化可以从四个方向入手。拓扑感知是第一步：了解服务器内部和跨服务器的网络拓扑（如华为超节点内部的环形/全连接组网），让通信流量走最短路径、避免跨交换机绕路。梯度压缩是第二步：对梯度做 TopK 稀疏化或量化，只传最重要的部分，通信量可减少 60%-90%。集合通信调优是第三步：针对 HCCL/CNCL 调整消息切分大小、ring 顺序等参数，性能往往能翻倍。流水并行是第四步：把模型的不同层放到不同卡上，让各卡的前向/反向计算与通信交错执行，把通信时间“藏”进计算时间里。

后厨动线设计好了，传菜就不再堵。当通信时间被“藏”进计算时间里，八个灶台才能真正同时开火，国宴才能按时上桌。

Tstep=Tcompute+TcommT_{\text{step}} = T_{\text{compute}} + T_{\text{comm}}
通俗说明：一步训练的总时间等于“做菜时间”加“传菜时间”。传菜越慢，整体越慢；传菜时间若能藏进做菜时间里，整体就接近做菜时间。
  1. 计算时间 $T_{\text{compute}}$单卡完成前向传播和反向传播所需的纯计算时间，是狭义的“做菜”时间。
    Tcompute=Tforward+TbackwardT_{\text{compute}} = T_{\text{forward}} + T_{\text{backward}}
  2. 通信时间 $T_{\text{comm}}$多卡之间同步梯度、广播参数的花费，包含等待和时间片两部分。
    Tcomm=Twait+TtransferT_{\text{comm}} = T_{\text{wait}} + T_{\text{transfer}}
  3. 相加得到单步总时长优化目标就是缩小 $T_{\text{comm}}$，或通过流水并行让两者重叠，使实际单步时间小于两者之和。
    Tstep=Tcompute+TcommT_{\text{step}} = T_{\text{compute}} + T_{\text{comm}}

混合精度调校

火候是中式烹饪的灵魂。大火爆炒，菜脆但容易糊；小火慢炖，不会糊但费时。聪明的厨师会分料处理：容易熟的用大火，需要入味的用小火。混合精度训练也一样——不是一刀切全用 FP16 或全用 FP32，而是让两者在正确的岗位上各司其职。

FP16（半精度）的好处是计算密度高、显存占用只有 FP32 的一半，但它的数值范围很小（最大只有 65504），训练时梯度动辄小到 $10^{-8}$，在 FP16 里会直接变成 0，导致模型“学不动”；大数值反过来又容易溢出成 inf。这就是为什么不能“全锅大火”。

混合精度训练的标准做法是：主权重保持 FP32，前向和反向用 FP16 计算，优化器更新回到 FP32 完成；同时在反向传播前把 loss 放大一个因子 $s$（比如 1024），让小的梯度在 FP16 范围内不至于下溢，等梯度算完再除以 $s$ 还原。动态损失缩放会持续监控训练：连续多步没有溢出就把 $s$ 调大，检测到溢出就调小并跳过当前步。精度监控还包括逐层检查激活值和梯度分布，定位是哪一层哪个算子的中间精度导致 loss 不收敛。

火候的把握从来不是固定的：菜炒过了就收火，火小了就添柴。动态损失缩放就是训练过程中的“自动控火”，让模型在新灶台上既烧得旺，又不糊锅。

lossscaled=loss×s\text{loss}_{\text{scaled}} = \text{loss} \times s
通俗说明：把整道菜的调味料“预先放大”一个倍数，做完再“缩回来”。这样小调料（小梯度）在烹饪过程中不会被忽略。
  1. 原始损失 $\text{loss}$模型当前的损失值，是反向传播的起点，通常是一个批次样本损失的平均。
    loss=1N∑i=1NL(yi,y^i)\text{loss} = \frac{1}{N} \sum_{i=1}^{N} \mathcal{L}(y_i, \hat{y}_i)
  2. 缩放因子 $s$一个较大的数（常见 1024 或 8192），由动态调整策略维护，溢出时调小、稳定时调大。
    s∈{28,210,212,… }s \in \{ 2^8, 2^{10}, 2^{12}, \dots \}
  3. 乘积得到缩放损失缩放后的损失进入反向传播，梯度随之放大，避免 FP16 数值范围下溢，更新参数时再除以 $s$ 还原。
    lossscaled=loss×s\text{loss}_{\text{scaled}} = \text{loss} \times s

百亿模型实战

真正到了国宴当晚，大厨要做的不是炒好一道菜，而是让几十道菜在几小时内按顺序端上每一桌。后厨有 32 个灶台，大多菜品需要多个灶台配合完成：有人切墩，有人掌勺，有人摆盘。百亿参数模型的训练，就是这个统筹过程。

100B 参数的模型，光权重就要占 400GB 显存（FP32 计），加上梯度和优化器状态轻松超过 1TB，单张国产训练卡（如昇腾 910B 的 64GB）绝对放不下。必须通过并行策略把模型“切”到多张卡上。

并行策略有三板斧：数据并行让每张卡持有完整模型、喂不同批次的数据，训练时 AllReduce 同步梯度；张量并行把单个 Transformer 层的权重切到多张卡上，适合单卡放不下单层的情况；流水并行把不同层分到不同卡，卡间只传递层间激活和梯度。显存规划要精确预算：参数、梯度、Adam 优化器状态、激活值四类分别算清楚，再决定每类放在哪张卡或卸载到 CPU。数据加载要用 DataLoader 多进程预取，避免芯片等数据。最后是断点续训：要训练 10 天的大任务，中途断电或单卡故障，必须能从最近的 checkpoint 恢复，否则前功尽弃。

国宴的统筹说到底是一门“资源分配”的学问：哪个灶台炒哪道菜、备料区放多少食材、万一停电了怎么接着做。显存规划把每一寸空间都算计到位，几十道热菜才可能同时开火。

Mtotal=Mparams+Mgrads+Moptim+MactM_{\text{total}} = M_{\text{params}} + M_{\text{grads}} + M_{\text{optim}} + M_{\text{act}}
通俗说明：显存总账 = 食材本身 + 备料 + 调料 + 临时占用的案板。哪一项超了，后厨就摆不下。
  1. 权重显存 $M_{\text{params}}$模型参数占用的显存，100B 参数按 FP32 存储需要 400GB。
    Mparams=Nparams×4 bytesM_{\text{params}} = N_{\text{params}} \times 4 \text{ bytes}
  2. 梯度显存 $M_{\text{grads}}$反向传播计算出的梯度，与参数等量级，同样占 400GB 量级。
    Mgrads=Nparams×4 bytesM_{\text{grads}} = N_{\text{params}} \times 4 \text{ bytes}
  3. 优化器状态 $M_{\text{optim}}$Adam 需要保存 FP32 主权重副本、一阶动量和二阶动量，合计约为参数的 3 倍。
    Moptim≈3×Nparams×4 bytesM_{\text{optim}} \approx 3 \times N_{\text{params}} \times 4 \text{ bytes}
  4. 激活值显存 $M_{\text{act}}$前向过程保存的中间激活，与 batch size、序列长度和隐藏维度正相关，常是最大的变量项。
    Mact∝B×L×HhiddenM_{\text{act}} \propto B \times L \times H_{\text{hidden}}

性能调优工具

宴席结束，大厨不会马上休息，而是开复盘会：今晚哪道菜出菜慢了？是备料不够还是灶台火力不足？传菜走廊有没有堵？把这些问题记进工作手册，下次宴席才有进步。性能调优工具，就是这本工作手册。

在没有数据的情况下谈优化都是拍脑袋。训练框架和芯片厂商提供了性能剖析（profiling）工具：PyTorch Profiler、昇腾 msprof、寒武纪 NeuProfile，能记录每个算子耗时、通信耗时、芯片利用率、内存峰值等指标。拿到数据后，瓶颈往往一目了然。

调优流程遵循“先测再调、一次只改一个变量”的原则。首先用 profiler 抓取一轮训练数据，按耗时排序找到 Top 瓶颈：可能是一个 CPU 算子频繁同步、梯度 AllReduce 次数太多、算子 kernel 启动开销过大。然后针对瓶颈做参数寻优：调整 batch size、流水阶段数、并行维度、集合通信缓冲区大小等，每组参数做 A/B 测试。最后把成功的配置和失败的反例沉淀成调优 checklist，供下次复用。整个过程的收益用加速比量化，而不是凭感觉说“好像快了点”。

每一次复盘例会，都是后厨整体水平的一次跃升。性能调优没有玄学，只有一次次量化对比后的积累——而这份积累，正是国产芯片生态最稀缺的工程经验。

S=TbaselineToptimizedS = \frac{T_{\text{baseline}}}{T_{\text{optimized}}}
通俗说明：加速比就是“优化前的单步耗时 ÷ 优化后的单步耗时”。2 倍加速比意味着同样的训练任务只需一半时间跑完。
  1. 基准时间 $T_{\text{baseline}}$做任何优化之前，模型训练一个 step（或一个 epoch）的平均耗时，是调优的锚点。
    Tbaseline=1K∑k=1KtkT_{\text{baseline}} = \frac{1}{K} \sum_{k=1}^{K} t_k
  2. 优化后时间 $T_{\text{optimized}}$应用某组调优参数后的平均单步耗时，注意保持其他变量不变。
    Toptimized=1K∑k=1Ktk′T_{\text{optimized}} = \frac{1}{K} \sum_{k=1}^{K} t_k'
  3. 相除得到加速比比值大于 1 说明优化有效，等于 1 说明没有变化，小于 1 说明反而变慢了。
    S=TbaselineToptimizedS = \frac{T_{\text{baseline}}}{T_{\text{optimized}}}

AI 应用场景

法务大模型从 A100 迁移到昇腾集群

阶段：模型训练前的框架适配与精度调校

解决的问题：某金融科技公司原有的 130 亿参数法务问答模型在 A100 上训练稳定，迁移到昇腾 910B 后频繁报算子不支持、loss 发散，训练速度下降 45%。传统做法是退回 A100 继续训练，但信创合规要求必须跑在国产芯片上。通过算子映射、自定义算子与混合精度调校，最终恢复训练稳定，吞吐恢复到 A100 的 90%。

具体案例：团队先跑算子预检脚本，盘点出 18 个不支持的算子；将 flash attention 改写为 matmul + softmax + matmul 的分解组合，并用 TBE 手写 3 个高频自定义算子；开启动态损失缩放后 loss 曲线恢复平滑。3 名工程师投入约 4 周，让法务模型在国产芯片上顺利完成了剩余 1200 亿 token 的训练。

国产 DCU 集群上的 700 亿参数模型训练调优

阶段：大规模分布式训练阶段

解决的问题：某大模型公司在海光 DCU 集群上训练 700 亿参数模型，通信耗时占单步时间的 65%，芯片利用率不足 50%。传统 NCCL 调优经验在国产通信库上不奏效，需要重新设计通信方案。

具体案例：profiler 数据显示 AllReduce 是主要瓶颈；按机框内拓扑将通信组内网段分组，对梯度做 TopK 压缩（保留 Top 30% 梯度），配合 2 路流水并行把通信和计算重叠。调整后单 step 从 4.8 秒降到 2.7 秒，千亿 token 的训练周期从 42 天缩短到 24 天。

Python 演示

python54 行
import random OP_LIB = {    "add": True,    "matmul": True,    "layer_norm": True,    "gelu": False,    "softmax": True,    "flash_attention": False,} OP_MAP = {    "gelu": "relu + matmul",    "flash_attention": "matmul + softmax + matmul",} def check_ops(model_ops, lib):    return [op for op in model_ops if not lib.get(op, False)] def adapt_ops(model_ops, lib, mapping):    plan = {}    for op in model_ops:        if lib.get(op, False):            plan[op] = op        elif op in mapping:            plan[op] = mapping[op]        else:            plan[op] = "custom_op:" + op    return plan def train_step(loss, lr, scale):    scaled_grad = loss * scale * random.uniform(0.05, 0.12)    new_loss = loss - lr * scaled_grad / scale    return max(new_loss, 0.01) def main():    random.seed(123)    model_ops = ["matmul", "layer_norm", "gelu", "softmax", "flash_attention", "add"]    missing = check_ops(model_ops, OP_LIB)    plan = adapt_ops(model_ops, OP_LIB, OP_MAP)     print("=== 国产芯片算子适配清单 ===")    for op in model_ops:        print(f"  {op:16s} -> {plan[op]}")     print("\n=== 混合精度模拟训练(带损失缩放) ===")    loss = 4.5    scale = 1024.0    for step in range(1, 11):        loss = train_step(loss, lr=0.08, scale=scale)        print(f"step {step:2d}: loss = {loss:.4f}") if __name__ == "__main__":    main()
目的：模拟国产芯片算子适配检查（找出不支持的算子并生成映射方案），随后用带损失缩放的混合精度方式模拟训练损失下降，演示了文章中算子映射与混合精度调校两个核心环节。
  1. return [op for op in model_ops if not lib.get(op, False)]遍历模型所有算子，筛出芯片算子库中不存在的算子，相当于“盘点新厨房缺哪些工具”。
  2. plan[op] = "custom_op:" + op当算子既不在算子库中、也没有等价映射时，标记为需要手写自定义算子，对应框架适配的第四层手段。
  3. scaled_grad = loss * scale * random.uniform(0.05, 0.12)模拟“先放大 loss 再算梯度”的过程，放大后的梯度在 FP16 范围内不会下溢。
  4. new_loss = loss - lr * scaled_grad / scale更新参数前把放大后的梯度除以缩放因子还原，对应混合精度中“算完再缩回来”的关键一步。
  5. random.seed(123)固定随机种子，让训练模拟结果可复现，实际训练中这也是精度对齐的第一步。

常见误区

误区我听说国产芯片算子不全、生态不成熟，所以 100 亿参数以上的模型根本不可能在昇腾上训练。训练还得靠英伟达，国产芯片最多做做推理。

正解实际上，百亿乃至千亿参数模型已在多家国产芯片上成功训练。关键在于做好框架适配、通信优化和混合精度调校——这些是工程问题，不是“能不能”问题。就像新铁锅虽然不如进口锅顺手，但大厨摸透脾气后照样能炒出国宴。

为何常见：早期国产芯片的应用场景确实以推理为主，训练案例少、公开报道有限，给人留下“只能推理”的刻板印象。

误区PyTorch 不是跨平台的吗？把 `import torch` 改成 `import torch_npu`，再改一两个配置，代码就能在国产芯片上跑起来了。

正解这只是起点。算子不兼容、通信库差异、精度不一致都需要逐个排查。一个 100B 模型的完整迁移通常需要数周，包含算子映射、图编译调整、精度对齐、通信调优四步，每一步都可能让训练崩溃。

为何常见：PyTorch 的跨平台抽象让人误以为硬件差异是透明的，实际上底层算子、集合通信、内存管理完全不同。

误区混合精度嘛，就是把模型权重、梯度、激活全存成 FP16，省一半显存，速度翻倍，何乐而不为？

正解混合精度的标准做法是“主权重 FP32 + 计算用 FP16 + 损失缩放”。只有前向/反向计算和部分激活走 FP16，主权重和优化器状态必须保持 FP32，否则模型极易不收敛。就像爆炒的菜出锅前要调味，但不是整道菜都只用大火。

为何常见：看到“混合精度”名字里有 FP16，就想当然地以为全部用 FP16，忽略了 FP32 副本是收敛的压舱石。

误区通信是瓶颈，梯度压缩能减少通信量，那我干脆把 99% 的梯度都剪掉，训练速度肯定大幅提升！

正解梯度压缩（如 TopK 稀疏化）会丢失信息，压缩率过高会导致收敛变慢甚至发散。实践中需要为压缩率设置合理阈值，必要时配合 error feedback 机制补偿被丢弃的梯度。这就像传菜时把菜量减半端上去，客人会投诉的。

为何常见：通信瓶颈是真实痛点，看到压缩有效就希望“压得更狠”，忽略了信息损失的下限。

误区国产芯片训练不收敛，是因为芯片的浮点运算能力不行，硬件问题，软件工程师无能为力。

正解精度不一致往往是算子实现细节（中间精度、累加顺序、融合策略）导致的，完全可以通过软件缓解：把敏感算子强制用 FP32 计算、逐层对比激活值找出差异源、调整损失缩放策略。这就像铁锅受热不均是物理特性，但大厨可以通过调整翻炒节奏来弥补。

为何常见：硬件差异是显性因素，而算子实现的中间精度是隐性因素，初学者容易把结论直接归因到“芯片不行”。

面试题

Q1. 国产芯片迁移训练时最常见的障碍是什么？

单选题 · easy

  • A.算子库不完整← 正确答案
  • B.芯片功耗过高
  • C.显存容量太小
  • D.散热效果太差

答案：A。国产芯片算子库相对于 CUDA 生态不完整，许多 PyTorch 算子无法直接运行，这是迁移时最常见的障碍。功耗、显存、散热属于硬件规格问题，不是迁移的典型障碍。

Q2. 英伟达多卡通信的标准库是哪一个？

单选题 · easy

  • A.HCCL 集合通信
  • B.CNCL 集合通信
  • C.NCCL 集合通信← 正确答案
  • D.RCCL 集合通信

答案：C。NCCL 是英伟达的集合通信库。HCCL 是昇腾的、CNCL 是寒武纪的、RCCL 是 AMD 的对应物。多卡训练时通信库必须与芯片匹配，否则 AllReduce 无法工作。

Q3. FP16 在混合精度训练中最典型的问题是什么？

单选题 · easy

  • A.数值范围小易溢出← 正确答案
  • B.计算速度大幅变慢
  • C.显存占用成倍增加
  • D.反向传播无法完成

答案：A。FP16 最大只能表示 65504，梯度小到一定程度会下溢为 0，大数又容易溢出为 inf。所以需要损失缩放把梯度“放大”后再训练。其他选项与 FP16 的实际特性相反。

Q4. 损失缩放（loss scaling）的核心思想是什么？

单选题 · mid

  • A.把学习率调大一些
  • B.放大梯度避免下溢← 正确答案
  • C.减少训练总步数
  • D.缩小模型参数量

答案：B。损失缩放把 loss 乘以一个缩放因子 s，使反向传播得到的梯度在 FP16 范围内不会下溢为 0，更新参数时再除以 s 还原。学习率、训练步数、参数量都与缩放机制无关。

Q5. 把模型的不同层分配到不同卡上，属于哪种并行策略？

单选题 · mid

  • A.张量并行切分权重
  • B.流水并行分层放置← 正确答案
  • C.数据并行相同副本
  • D.混合并行组合策略

答案：B。流水并行按层切割模型，前一张卡算完一层的激活后传给下一张卡，同时反向传播与前向交错执行。张量并行是在层内切分权重，数据并行是每卡持有完整副本。

Q6. 训练 100B 参数模型时，Adam 优化器状态大约放大参数量多少倍？

单选题 · mid

  • A.放大到参数量的 1 倍
  • B.放大到参数量的 3 倍← 正确答案
  • C.放大到参数量的 16 倍
  • D.放大到参数量的 100 倍

答案：B。Adam 需要保存 FP32 主权重 + 一阶动量 + 二阶动量，每参数合计 12 字节，而原本只需 4 字节，所以大约是 3 倍。这就是显存规划里优化器状态不能忽略的原因。

Q7. A100 上收敛正常的代码迁移到国产芯片后 loss 不降，最可能的原因是什么？

单选题 · hard

  • A.芯片温度过高导致降频
  • B.算子精度不一致所致← 正确答案
  • C.数据集加载顺序差异
  • D.服务器内存容量太小

答案：B。不同芯片的算子中间精度、矩阵乘累加顺序不同，导致同样的代码数值行为不同，这是 loss 不收敛最常见的隐藏原因。温度、数据顺序、内存容量不是迁移场景下的典型差异点。

Q8. 梯度压缩（如 TopK 稀疏化）的主要副作用是什么？

单选题 · hard

  • A.通信总量反而变大
  • B.模型精度可能下降← 正确答案
  • C.显存占用同步增加
  • D.训练速度大幅变慢

答案：B。被丢弃的小梯度携带了信息，压缩率过高会让梯度失去精度，导致收敛变慢或精度下降，必要时需要 error feedback 补偿。通信量下降是收益，显存和速度不会因此恶化。

Q9. 以下哪些方法能有效提升国产芯片多卡训练吞吐？

多选题 · mid

  • A.对梯度做稀疏压缩← 正确答案
  • B.按拓扑安排通信← 正确答案
  • C.流水并行隐藏延迟← 正确答案
  • D.关闭数据预取加载

答案：ABC。梯度压缩减少通信量、拓扑感知让通信走最短路径、流水并行把通信藏进计算里，三者都是有效手段。关闭数据预取会让芯片等待数据，反而降低吞吐。

Q10. 导致国产芯片与英伟达之间精度一致性问题的因素包括哪些？

多选题 · extreme

  • A.算子中间精度不同← 正确答案
  • B.矩阵累加顺序差异← 正确答案
  • C.损失缩放策略不同← 正确答案
  • D.随机种子保持相同

答案：ABC。算子中间精度（如是否用 FP32 累加）、矩阵乘法的累加顺序、损失缩放策略的差异都会导致数值行为不同。随机种子相同反而有助于复现，它不是导致不一致的因素。