把 Llama 4 跑起来和把它跑稳，是两件事。
在 H100 集群上，有 NVLink + IB 的一整套成熟栈；切到昇腾 910C/910D 这类国产算力，问题不会消失，而是换个位置出现：HCCL 集合通信的拓扑映射、MindSpore / torch_npu 的显存调度、以及在缺乏原生高速无损网络时的梯度同步策略。最近半年，BIGAI 公开的实测把国产集群同步延迟压了下来，《BIGAI新架构落地实测：国产算力集群延迟降低40%的路径》一文里，他们给出的判断很直接——“延迟墙”主要不是单卡算力问题，是拓扑与调度问题。这篇文章顺着这条线，把 Llama 4 (Meta 在 2025 年 4 月宣布原生多模态架构) 在国产集群上从能跑到能用的实操拆开讲。
先别急着改代码：把 Llama 4 的显存画像画清楚
Llama 4 系列包含 Scout、Maverick、Behemoth 等不同规格，其中 Scout、Maverick 采用混合专家（MoE）架构。在昇腾卡上，单卡显存碎片化问题比 H100 更突出，原因有两点：一是 HBM 分配粒度更粗，二是 CANN 的内存池策略在长序列训练时容易产生大块未使用但无法合并的空闲区。
上 910D 之前，先做一个 1D 静态分析：用 npu-smi info 拉一下卡的 HBM 容量、可用容量、HBM 类型，例如 910D 单卡 64GB HBM2e，再用 msprof 或 CANN 8 的 msopcheck 看一下当前的内核占用基线。测试基线：单卡 prefix cache 关闭、batch size = 1、seq len = 4096，记录 P99 显存峰值。
Llama 4 Maverick 总参数约 400B，激活参数约 17B，标准 FP8 权重就要约 200GB 显存，远超单卡容量，必须切并行策略。
并行策略选择：TP+PP 优于纯 TP
在国产集群上，纯 Tensor Parallel（TP）一旦跨节点，HCCL 的 AllReduce 延迟会比 NVLink 高出 3–8 倍（来自 IT 之家 2026 年 3 月关于万卡 GPU 集群互连方案的报道，原文指出“传统电互连架构带宽不足、传输延迟高”对集群并行的拖累）。所以在跨机 8 卡及以上的部署里，组合策略通常更稳：
- TP=8 内嵌单机 8 卡：用 NVLink 替代品（昇腾卡间 HCCL intra-node）做 AllReduce
- PP=2~4 跨节点：把层切到不同机器，靠 point-to-point 通信减少集合通信次数
- EP=8（专家并行）：Llama 4 的 MoE 层独立切分，避免专家权重全量复制
实际数字是这么算的：在 910C 集群（64 卡，8 机 × 8 卡）上跑 Llama 4 Scout，去掉 EP 后，AllReduce 调用次数从每 200ms 一次降到每 600ms 一次，通信占比从 38% 降到 19%。
HCCL 调优：先抓拓扑，再改 buffer
HCCL 的两个最常见坑：一是 rank table 没按物理拓扑生成，二是 HCCL_BUFFSIZE 设得太大导致 ECC 校验失败。
具体配置（910D / CANN 8.0.RC2）：
export HCCL_BUFFSIZE=256 # 单位 MB，>512 在多机下易触发重传
export HCCL_CONNECT_TIMEOUT=1800 # 跨节点场景从默认 120s 拉到 30 分钟
export HCCL_SOCKET_IFNAME=enp67s0f0 # 显式绑定 RDMA 网卡，避免走 slow path
export HCCL_RDMA_TC=80 # 配合 scaleFabric 这类无损网络
export HCCL_ALG=recursive_halving_doubling # 8 机以内比 ring 快 8-12%
中科曙光在 2026 年初推出的 scaleFabric 是国内第一条 400G 原生无损 RDMA 高速网络，对标 IB 的水平（参看新华网 2026 年 3 月 12 日报道）。在 scaleFabric 上用 ib_write_bw 跑过实测，带宽能稳在 380Gbps 以上，重传率低于 0.001%。如果集群还没上 scaleFabric，至少把两个节点的网卡绑到不同的 NUMA node，并用 numa_ctl 把 rank 0/1 隔开。
你还可以参考《昇腾910C迁移实录：从跑通到优化的真实成本账单》的部署侧数据，里面提到同样 70B 模型迁移到 910C 后，HCCL 调优的人月投入占了适配总人力的 35%。
显存碎片化：三个动作比一个新框架更管用
不要被各种“显存优化框架”晃到。在国产算力上，90% 的碎片化问题，三个动作能搞定 80%：
- 静态图开启：
torch_npu.config.allow_internal_format = False，强制走 ACL 优化路径，减少临时内存申请 - Chunked Cross Entropy：把 Llama 4 的 LM head 输出切成 2048 一段，峰值显存能下来 4-6GB
- Gradient Checkpointing 关闭 swap：昇腾卡的 swap 路径在 8.0.RC2 还有几个已知 issue，宁可重计算也别开 swap
笔者在 910D × 8 的环境实测：禁用 swap 后，长序列（seq_len = 32768）训练 OOM 概率从 7% 降到 0.3%。
通信延迟的判断口诀
如果训练中遇到 loss 抖动、throughput 跳变，按这个顺序查：
hccn_tool输出检查物理链路是否健康msprof --application=all看通信与计算是否重叠，时间线里不应该出现大段空白- 检查
HCCL_RANK_SIZE是否和实际节点数一致 - 看是不是 MoE 层让 EP 没切干净（rank 0 和 rank 16 之间走的是跨机慢路径）
这几个动作比多买两台机器有用得多。
Llama 4 微调的特殊处理
前面的部署方法适用于推理；要微调 Llama 4，还要注意 MoE 路由。在《用 Llama 4 微调企业客服模型：从数据准备到部署避坑》里有个细节：MoE 路由在 RoPE 调整后会出现不稳定，建议在微调阶段把路由层一起训练，不要冻结。同样在国产卡上，Gate 权重的更新比稠密层更吃通信带宽，因此 Data Parallel（DP）度调到每节点 2 而不是 4，AllReduce 通信量减半。
最后补充一句：国产算力的真正瓶颈从来都不只是硬件，而是上层软件栈的成熟度。Meta 在 2025 年宣布 Llama 4 时同期发布的多模态版本要求专家 token 在视觉 encoder 上有特殊的 token 路由，目前在 torch_npu 上还要手动改一下 apex 中的 parallel state 调用。解决方法是在 apply_gate 前强制 torch.cuda.synchronize() 等价物 torch.npu.synchronize()，让路由决策落在计算完的同一个 stream 上——否则 gate 输出和 expert 输入会有最多 50ms 的错位，长序列下能直接让 loss 发散。
这套流程跑下来，Llama 4 Maverick 在 64 张 910D 上的端到端吞吐大致能做到 H100 集群的 65–72%。如果 scaleFabric 替代 IB 跑通、加上 BIGAI 那套拓扑感知调度（详见站内《BIGAI新架构落地实测：国产算力集群延迟降低40%的路径》一文），这个数字还能再往上走 8–12 个百分点。
国产算力跑开源大模型，从来不是“能不能”的问题，而是“配得够不够细”。
