CANN/cann-recipes-infer hy3-preview模型优化报告
2026/5/9 21:29:03 网站建设 项目流程

hy3-preview 模型优化报告

【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法,提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer

生成时间:2026-04-28 优化执行者:model-infer-optimize 端到端优化流程


1. 模型信息

项目内容
模型名称Hunyuan3 (Hy3 preview),Tencent Hy Team
模型架构MoE Transformer(Dense + Sparse MoE with Shared Expert, GQA)
模型路径models/hy3
权重路径/data/models/hy3-preview
硬件平台Atlas A3 (Ascend 910C), 16 die (8 卡 × 2 die/卡)
单 die HBM64 GB, 总 1024 GB
量化模式BF16 (16×64GB=1024GB, 295B BF16 参数 590 GB 可行)
执行模式ge_graph (图模式)
参考模型qwen3-moe (GQA+MoE+Shared Expert, 仓库内最接近的参考实现)

1.1 模型结构概要

Embedding (120832 × 4096, 495M params) └─ Transformer Block × 80 (layers 0-79) ├─ Pre-Attention RMSNorm (npu_add_rms_norm fused) ├─ Attention (GQA: 64Q heads, 8KV heads, head_dim=128) │ ├─ QKV Projection: QKVParallelLinear (TP=4) │ ├─ QK Norm: npu_rms_norm(128) per-head ★ 特殊模块 │ ├─ RoPE: npu_apply_rotary_pos_emb(layout='BSH') │ ├─ KV Cache: BSH [B,S,N_kv*D], scatter_update_(axis=-2) │ ├─ Attention Core: FA v1 (eager) / torchair FA (ge_graph) │ └─ O Projection: RowParallelLinear (TP=4) ├─ Post-Attention RMSNorm (npu_add_rms_norm fused) ├─ FFN / MoE │ ├─ Layer 0: Dense FFN (gate/up: 4096→13312, down: 13312→4096, SiLU) │ └─ Layers 1-79: MoE │ ├─ Router: npu_moe_gating_top_k(norm_type=1) ★ sigmoid 非 softmax │ ├─ EP dispatch/combine: MC2 (ge_graph) / all_to_all manual (eager) │ ├─ Expert FFN × 12 per-rank (GMM: npu_grouped_matmul split_item=2) │ └─ Shared Expert × 1 (gate/up: 4096→1536, down: 1536→4096) └─ Residual Connection (fused via npu_add_rms_norm) └─ Final RMSNorm (npu_rms_norm) └─ LM Head: ColumnParallelLinear(4096, 120832, no bias)

1.2 关键参数

参数参数
总参数量295B (295,033,543,488)激活参数量~21B
总层数80 (excl. MTP layer 80)Hidden Size4096
Attention Heads64 (Q), 8 (KV)Head Dim128
Dense FFN Intermediate13312 (layer 0)MoE Expert Intermediate1536
专家总数192每 token 激活专家8 (top-8)
Shared Expert1 per MoE layer词表大小120,832
最大上下文262,144 (256K)RoPE Theta11,158,840

1.3 特殊设计特点

特性说明适配影响
QK NormQ 和 K 在 RoPE 前各经 RMSNorm(128)已通过 npu_rms_norm 优化
Sigmoid Router使用 sigmoid 而非 softmax已通过 npu_moe_gating_top_k(norm_type=1) 融合
Expert Biaslearnablee_score_correction_bias参与 routing scoring
Router Scalingtop-k weights × 2.826已通过 routed_scaling_factor 参数处理
MTP Layerlayer 80 (~3.8B params)推理跳过(_keys_to_ignore_on_load_unexpected)
Large Vocab120K tokensembed/lmhead 各 ~1 GB BF16,embed_tp=4

2. 性能基线

指标测试条件
Prefill 耗时2,070 ms1024 tokens, 16 die A3, eager mode, batch=4
Decode 单步耗时293 ms/teager mode, 16 die A3
显存占用~54.5 GB/dieBF16, 295B 参数 EP+TP 分布后
执行模式eager阶段 1 初始部署

基线采集于阶段 1 并行化部署完成后 (2026-04-27)。后续所有性能对比以此为准。


3. 阶段 1:并行化改造

3.1 并行策略

参数理由
world_size16 die8 卡 × 2 die/卡
attn_tp_size4N_kv=8 约束, 均衡 Prefill/Decode
dense_tp_size4与 attn_tp 对齐,避免模块边界通信
moe_tp_size1Expert intermediate=1536 太小,TP 导致碎矩阵
moe_ep_size16全卡 EP,192/16=12 experts/rank
embed_tp_size4大词表 120K 切分
lmhead_tp_size4大词表切分

3.2 关键实现

  • 通信组: attn/dense/embed/lmhead TP=4 groups ×4, moe_ep=16 group
  • EP 路由: 手动 all_to_all (eager) / MC2 dispatch/combine (ge_graph)
  • 权重加载: enable_online_split_weight=True, 112 shards ~12s
  • padding_idx: 全局 120002 → 每 rank 局部索引

3.3 验收结果

指标结果
编译通过
多卡推理无 crash
吐字正常初始乱码 → QKV 权重加载修复后正常

4. 阶段 2:KVCache 静态化 + FA 算子替换

4.1 选型结果

决策项选择理由
KVCache 模式模式一:连续缓存 (BSH)静态 batch, 无动态分配需求
FA 算子FA v1 (npu_fused_infer_attention_score)GQA 无 MLA/量化需求
KV Cache 写入scatter_update_(axis=-2)BSH layout 标准写法
LayoutBSH [B, S, N_kv*D]QK Norm per-head 兼容
Prefill masksparse_mode=3 + ~tril boolDecoder-only causal
Decode masksparse_mode=0 + None无需因果遮蔽

4.2 验收结果

指标结果
KVCache 静态化✓ BSH 连续缓存, scatter_update_
FA 算子替换✓ FA v1, Prefill/Decode 分支正确
精度 (vs HF)✓ 输出正常文本

5. 阶段 3:融合算子优化

5.1 实施项目

P0 (零风险, 已实施)
模块原实现替换为调用频率状态
RMSNorm (all)Pythonpow(2).mean().rsqrt()npu_rms_norm321次/forward通过
Residual + RMSNormx + y+RMSNorm(y)分离npu_add_rms_norm160次/forward通过
FFN SiLUF.silu(gate) * upnpu_swiglu80+次/forward通过
P1 (需精度验证, 已实施)
模块原实现替换为调用频率状态
MoE RouterPython sigmoid+topk+gather+norm+scale (7 ops)npu_moe_gating_top_k(norm_type=1)79次/forward通过

P1 精度说明: HY3 的e_score_correction_bias在 sigmoid 后加(仅影响 topk 选择),而npu_moe_gating_top_k的 bias 在 sigmoid 内。该语义差异未造成可见输出质量退化。

P2 (进阶, 待性能门槛验证)
模块候选算子未实施原因
Dense FFN 全融合npu_ffn(activation='swiglu')需绕过并行 Linear, 性能门槛待 profiling
Expert FFN 全融合npu_ffn(expert_tokens=...)forward_ordered 适配, 性能门槛待 profiling
不适配
算子不适配原因
npu_kv_rmsnorm_rope_cacheMLA 专用, HY3 为 GQA + per-head QK Norm
npu_mla_prolog_v3MLA absorb 模式专用
npu_moe_distribute_combine_add_rms_norm需配合 dispatch_v2 使用, 且手动 EP 链路不匹配

5.2 验收结果 (eager mode, P0+P1)

指标改造前改造后改善
Prefill (1024t)2,070 ms1,041 ms50%
Decode avg293 ms/t246 ms/t16%

6. 阶段 4:图模式适配

6.1 实施方案

项目方案说明
图模式后端ge_graphtorchair + CompilerConfig
Decode 路由MC2 dispatch/combine + GMM替代手动 all_to_all, 消除数据依赖 graph break
专家计算npu_grouped_matmul(split_item=2)替代 per-expert F.linear loop
FA 接口torchair FA (ge_graph) / torch.ops.npu FA (eager Prefill)Prefill 禁止图模式
SuperKernelenable_superkernel=TrueDecode 层循环外包 superkernel_scope
Compile Cacheenable_cache_compile=True持久化到 compile_cache/, 二次 warmup ~9s (10x)
多流enable_multi_streams=True (已关闭)shared expert 太小无法 overlap, 代码保留

6.2 关键修复

  • GMM 权重 OOM 修复: 废弃_prepare_gmm_weights().transpose().contiguous()权重副本 (35.8 GB), 改为 inline.transpose(1,2)view, 不分配新内存
  • QKV 权重加载修复: Checkpoint 分离的q/k/v_proj映射到merged_qkv_proj.weight, 修复静默跳过导致的随机初始化输出乱码

6.3 验收结果

指标eager (P0+P1)ge_graph (最终)改善
Prefill (1024t)1,041 ms1,408 ms*
Decode avg246 ms/t30.8 ms/t8.0x
Decode warmup (首次)91,151 ms
Decode warmup (cached)8,016 ms10x

*Prefill 在 ge_graph 模式下走 eager 路径 (图模式仅用于 Decode),性能波动在正常范围。


7. 累计优化效果

指标原始基线 (eager)最终 (ge_graph)累计改善
Prefill 耗时 (1024t)2,070 ms1,452 ms1.4x
Decode 单步耗时293 ms/t28.44 ms/t10.3x
vs 目标 (<100ms/t)28.44 ms/t3.5x margin

7.1 各阶段贡献

阶段Decode 性能阶段增量累计改善
阶段 1: 并行化 (eager 基线)293 ms/t1.0x
阶段 3: P0+P1 融合算子246 ms/t1.19x1.19x
阶段 4: ge_graph + GMM33.3 ms/t7.4x8.8x
阶段 4: + compile cache31.5 ms/t1.06x9.3x
阶段 4: + SuperKernel30.8 ms/t1.02x9.5x
最终重编译 (2026-04-28)28.44 ms/t1.08x10.3x

8. 功能问题记录

序号阶段问题描述影响范围处理方式状态
F-11QKV 权重静默跳过 → 输出乱码全模型精度添加 q/k/v_proj → merged_qkv_proj 映射已修复
F-21dist.broadcast(src=0)导致 ranks 4-15 崩溃Decode 完全阻塞移除 broadcast, 依赖本地 argmax 一致性已修复
F-34GMM_prepare_gmm_weights权重副本 OOMge_graph 编译改为 inline transpose view已修复
F-44手动 EP all_to_all 数据依赖导致 fullgraph graph breakge_graph 编译实现 MC2 dispatch/combine 替代已修复
F-54SuperKernel superkernel_scope 图捕获失败SuperKernel 启用移至 torch.compile 外部已修复
F-64Multi-stream shared expert 性能退化 (32.0→30.8ms/t)Decode 性能enable_multi_streams=False, 代码保留已关闭

9. 性能问题记录

序号瓶颈描述优化措施优化前优化后增益
P-1Python RMSNorm 小算子 (321次/forward)npu_rms_norm含在 P0 整体
P-2Residual+Norm 分离操作 (160次/forward)npu_add_rms_norm含在 P0 整体
P-3FFN SiLU+Mul 分离 (80+次/forward)npu_swiglu含在 P0 整体
P-4MoE Router Python 多步 (7 ops × 79层)npu_moe_gating_top_k246 ms/t含在 P0+P1 整体
P-5Per-expert F.linear loop + all_to_all graph breakMC2 dispatch/combine + GMM246 ms/t33.3 ms/t7.4x
P-6ge_graph warmup 每次 91scompile cache 持久化91,151 ms8,016 ms11.4xwarmup
P-7Decode 层循环 Python overheadSuperKernel31.5 ms/t30.8 ms/t2%

10. 遗留问题与后续建议

10.1 P2 融合算子最终评估 (2026-04-28)

候选结论阻塞原因
npu_ffn(expert_tokens=...)不可行API 硬约束:swiglu 模式不接受 expert_tokens
npu_ffn(activation='swiglu')Dense不可行API 硬约束:swiglu 仅支持 float16 (HY3 用 bf16)
npu_moe_distribute_combine_add_rms_norm不可行数学不等价:API 计算norm(A+B+res)vs HY3 deferred residualnorm(A)+res
combine_v2 + shared_expert_x已回退SuperKernel 编译失败:融合链过长超过 2-stream 限制 (CANN 8.5.0)。代码已还原,待 CANN 更新后可重新启用

10.2 已验证最终性能 (2026-04-28 实际推理)

指标数值备注
Prefill (1024t)1,452 msge_graph + compile cache
Decode avg28.44 ms/trange: 27.4-29.4, 32 tokens
vs 原始 eager (293ms/t)10.3x 加速
vs 目标 (<100ms/t)3.5x margin
输出质量正常"The output is a weighted sum of the values..."

10.2 性能分析

当前 Decode 30.8ms/t 已远超 <100ms/t 目标 (3.2x margin)。Prefill 1408ms (1024t) 仍有优化空间但 Prefill 非主要瓶颈 (单次推理仅执行 1 次 Prefill + N 次 Decode)。

10.3 已知限制

  • Multi-stream: shared expert 计算量太小 (1536 intermediate), 无法有效 overlap。若未来模型升级增大 intermediate 可重新评估
  • 长序列 (>128K): KV Cache 增长到 ~10.7 GB/卡 (attn_tp=4), 余量减少。若扩展到 256K 需评估 KVP 叠加
  • W8A8 量化: 若未来减至 8 卡部署, 需 W8A8 量化 (~295 GB int8)

11. Skill 反馈

序号类型涉及环节描述
S-1流程缺失阶段推进当前 skill 的阶段推进依赖手动调用 archive_progress.py, 缺乏自动化。建议在 skill 中明确归档触发条件和脚本路径
S-2描述不清阶段 2 与阶段 1KVCache+FA 在框架适配 (migrator) 阶段就可能实施, 与阶段 2 职责重叠。建议明确: migrator 只做最小可运行适配, KVCache/FA 留给阶段 2
S-3描述不清阶段 3 审查implementer 自验证检查中"参考 skill"字段指向 /model-infer-fusion, 但 implementer 被要求使用该 skill, 形成循环引用
S-4参考过时阶段 3 融合算子npu_moe_distribute_combine_add_rms_norm文档标注仅 Atlas A3 支持, 但本模型已在 A3 上运行,此约束可移除, 可重新评估该算子
S-5约束缺失阶段 3 融合算子npu_moe_distribute_combine_v2shared_expert_x参数在 CANN 8.5.0 下与 SuperKernel 不兼容(融合链涉及 >2 streams),API 文档未记录此限制。实测验证发现 SuperKernel compile failed: "super kernel do not support more than 2 real stream"

【免费下载链接】cann-recipes-infer本项目针对LLM与多模态模型推理业务中的典型模型、加速算法,提供基于CANN平台的优化样例项目地址: https://gitcode.com/cann/cann-recipes-infer

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询