核心思路

要解决的问题：前沿模型能力还在涨，但部署成本和推理延迟把可及性卡死了。开源侧主流仍是 dense 架构、激活参数全量打满。

定位：这篇不是刷 SOTA 的论文，是一份工程报告。约束条件是「激活参数尽可能小」，目标是在这个约束下把能力做到与大一档的模型可比——13B 激活对 Qwen3-A22B 的 22B、对自家 Hunyuan-Large 的 52B。

两个真正值得看的设计：

1. 推理深度是一个推理时的标签，不是一个模型选择问题。 对简单 query 也走长 CoT 是纯浪费，但训快慢两个模型又要付维护成本和一致性成本。Dual-Mode CoT 用同一套后训练同时优化两种模式，靠一个 <think> 块的空与非空区分，切换只是一个控制标签。

2. 推理能力和全场景可用性被拆成两个串行相位，各自配不同的 reward 体系。 推理相位的 reward 必须可验证（答案比对、沙箱执行），全场景相位的 reward 必须能处理开放式输出（生成式 reward model + 参考答案当语义锚）。把它们混在一个阶段训，reward 设计会互相打架。

诚实的边界：架构层面没有新机制。细粒度 MoE 来自 DeepSeekMoE，注意力是 GQA，激活函数 SwiGLU，长上下文靠 NTK-aware 扩窗——全是成熟组件的组装。这篇的价值在流水线和数据工程，不在架构创新。

整体实现思路

预训练                        后训练（四阶段串行）
─────────────────────        ──────────────────────────────────────
Foundation  20T tokens        Stage1  推理向 SFT   （数学/代码/逻辑/科学）
  ctx 4096                       ↓
    ↓                         Stage2  推理向 RL    （GRPO + 可验证 reward）
Fast Annealing 300B              ↓
  ctx 8192                    Stage3  全场景 SFT   （8 类通用能力 + 采样回灌推理数据）
    ↓                            ↓
Long-Context                  Stage4  全场景 RL    （GRM + 16 子领域 30+ 打分服务）
  32K → 256K                     ↓
  NTK-aware α=50 / 1000       Dual-Mode CoT（贯穿 Stage1-4，统一格式）

关键点是 Stage3 会把推理数据采样回灌和通用数据混训，而不是纯通用数据——否则 Stage1/2 学到的推理能力会在全场景对齐里被冲掉。

子模块实现（可复现细节）

模块 A — 架构

配置	值
层数	32
Attention heads	32
Key/Value heads	8（GQA）
共享专家	1
细粒度专家	64
激活专家	8（+ 共享专家常驻）
激活函数	SwiGLU
词表	128K（沿用 Hunyuan-Large 的 tokenizer）
Hidden size	4096
FFN hidden size	3072
激活 / 总参数	13B / 80B
原生上下文	256K

共享专家数量的消融结论值得单独记：他们做过 MoE scaling law 实验，发现有 1 个共享专家明显优于 0 个（没有共享专家的模型会系统性欠拟合），但超过 1 个收益递减，甚至出现效果抖动。所以最终就是 1 个。这条对自己设计 MoE 有直接参考价值。

训练时共享专家永远激活，非共享专家每次只激活 8 个。

模块 B — 预训练三阶段

Foundation Training（20T tokens）

• LR schedule 三段：warmup 线性 0 → 3e-4；cosine decay 在 13.5T tokens 内从 3e-4 降到 3e-5；剩余步数保持 3e-5 最小值
• 全程固定 4096 上下文窗口

Fast Annealing（300B tokens）

• 从 3e-5 起做快速 cosine decay 到 8e-6
• 上下文窗口提到 8192

Long-Context（两个串行相位）

• 32K → 256K
• 都用 NTK-aware 位置编码（沿用 Hunyuan-TurboS），alpha 分别设 50（32K）和 1000（256K）

模块 C — 预训练数据

复用 Hunyuan-TurboS 的数据流水线，三个模块：① 预处理（去重、低质过滤、去噪、主题标注）② 模型化抽取（抽纯文本）③ 后处理（低质过滤 + 语义级去重）。

本次针对性优化两处：

• STEM 单独做抽取与清洗优化，最终产出 250B token 高质量 STEM 语料灌进训练
• 设计了精细化知识标注体系 + 多维难度分级框架，用于语料的选择与过滤

模块 D — Stage1：推理向 SFT

四个域，每个域的数据构造方式不同：

域	来源	质量保证
数学	教材、标准化考试、竞赛（从基础算术到奥数）	生成式 reward model + 自动解验证机制迭代筛 CoT，只留严格验证过的
代码	精选开源仓库（GitHub），用成熟 pipeline 把代码片段转成结构化推理对	多阶段验证：critic model + 沙箱执行测试
逻辑	版权及公开谜题集，用 ZebraLogic 式自动合成做规模化扩增	两层验证：标准场景用自动 CoT 评估模型，复杂 case 上人工
科学	物理/化学/生物，从初中到研究生级	LLM 评难度与质量；高难题（大学考试、科学奥赛）过专门的 LLM verifier 查单位换算 / 数值近似 / 化学记号这类细微错误；最后 rejection sampling

模块 E — Stage2：推理向 RL

算法 GRPO。两类 reward：

1. Outcome Reward Model — 轻量 LM verifier，比对生成答案与参考解，输出 0/1 二值。设计上会归一化表层差异（格式、单位换算、同义词）以减少 false negative。用于数学、逻辑、科学。
2. Sandbox Feedback — 支持 36 种编程语言的多语言代码沙箱，部署在分布式 CPU 集群，支持 1000+ 并发执行，有文件与网络隔离。

数据与配置：

• prompt 从 SFT 模型表现不稳定的 case 里采样（不是随机采）
• 150K 样本，数学:代码:逻辑:科学 = 2:2:1:1
• 10% 与 SFT 训练数据重叠，90% 是新 case
• 排除选择题、判断题、证明题——避免奖励瞎猜、保证结果可验证
• 上下文分两相位推进：Phase 1 用 24K、Phase 2 扩到 32K
• 移除 KL 散度约束，让策略更新更灵活
• 其他有效配置：on-policy、大 batch、增加 rollout 数、较低采样温度 0.6–0.8

模块 F — Stage3：全场景 SFT

从专精推理数据集里采样一部分，与通用域样本同时混合训练。八类补充数据：

1. 语言理解 — 理解、翻译、流畅生成；严格筛掉模糊指令；响应用专门的打分模型验证（显式设计以抑制 reward hacking）；再经专家迭代改写
2. 创意写作 — 按体裁/风格/语气/叙事结构多维标注保多样性；判别式 reward 过滤低质与不稳定样本；迭代自改进 + 专家改写
3. 多语言 — 指令进化 + 回译合成；语言专家监督标注与验证
4. 复杂指令 — 合成带各种约束、长上下文整合、agent 驱动要求的数据；规则化验证保证约束被遵守
5. 角色扮演 — 人格特质画像驱动的 persona 一致性对话；按特质准确度、指令遵循、情感共情三维评估
6. 知识问答 — 多层验证 + critic model 过滤无依据信息，抑制幻觉
7. 多轮对话 — 任务型 / 社交型 / 问答型混合；开源 + 采购 + 受控合成 + 伪对话技术
8. Agent — 见下

Agent 数据构造是这一节最值得抄的部分：

• 五角色合成引擎：user / planner / tool / agent / checker，模拟真实多方会话来生成训练数据
• 三种工具响应来源：沙箱工具、MCP（model context protocol）、合成工具——解决真实数据获取成本高与工具种类有限的问题
• 针对数据集里快慢思考的不平衡，优化 prompt 策略并专门训了一个模型来生成思考过程
• 设计 30+ 种 agent system instruction，组合工具/动作/响应的格式变化，造出 20,000 种格式组合做泛化
• 重点强化高频任务：Excel 处理、深度搜索

模块 G — Stage4：全场景 RL

核心是一个通用生成式 reward model（GRM）：把候选答案与参考答案比对，参考答案在开放式任务（创意写作）里当语义锚，在确定性任务（闭卷问答）里就是 ground truth。GRM 可选地吃 CoT 轨迹来提升多步推理上的判断准确度，也可以调用外部工具、报告长度统计、按任务约束核对输出。

在 GRM 之上，每个赛道配独立的 reward service + 偏好数据 + 规则 + 数据构造流水线，共 16 个子领域、30+ 打分服务：

赛道	reward 设计要点
文本理解	两个 reward model：客观问答用一致性模型，主观/开放式用比较式 GRM
翻译	领域专家标注平行语料，GRM 在其上训练
长上下文	额外加幻觉专项 reward model + online RL 提升稳定性
创意写作	成对 GRM 做相对偏好判断抑制 reward hacking；创意 reward 与指令遵循自动检查混合
Agent	沙箱工具 + MCP 提供反馈；规则化 reward 两部分：format reward（特殊标记与顺序正确得 1，否则 0）保证可解析 + correctness reward 评估工具/参数/取值与参考的一致性
多轮对话	对话专用 critic model，通过挖掘不稳定对话来精炼
复杂指令	约束抽取与满足度工具 + 通用 critic
角色扮演	指令理解、角色一致性、共情三维
安全	分类器 + 拒答启发式识别安全响应对，直接集成进偏好数据
知识问答	幻觉检测模型（带/不带参考两种）与用户体验模型联合优化
多语言	GRM 采样并打分 SFT 答案，保留高多样性、高方差、高质量的 prompt
金融/法律/医疗	一致性 reward 从专业考试里识别不稳定项，供给偏好数据

另有对抗性 prompt 过滤与动态采样保证跨域泛化。

模块 H — Dual-Mode CoT

后训练阶段用统一的训练结构同时优化两种模式，两种样本共用同一个结构化格式，只靠 <think> 块的内容区分：

快思考：<think>\n\n<think>          ← 块内故意留空
慢思考：<think> 逐步推理内容 </think>  ← 块内是完整 CoT

用户侧的控制标签：

• /no think → 快思考
• /think → 慢思考
• 不给标签 → 默认慢思考

实验设置与结果

Base 模型（Table 2）

对比 Hunyuan-Large-1116（52B 激活 / 389B 总参）、Qwen2.5-72B（dense）、Qwen3-A22B（22B 激活 / 235B 总参）。Hunyuan-A13B 是 13B 激活 / 80B 总参 / 256K 上下文。

	Hunyuan-Large-1116	Qwen2.5-72B	Qwen3-A22B	Hunyuan-A13B
MMLU	88.40	86.10	87.81	88.17
MMLU-Pro	60.20	58.10	68.18	67.23
MMLU-Redux	87.47	83.90	87.40	87.67
BBH	86.30	85.80	88.87	87.56
SuperGPQA	38.90	36.20	44.06	41.32
EvalPlus	75.69	65.93	77.60	78.64
MultiPL-E	59.13	60.50	65.94	69.33
MBPP	72.60	76.00	81.40	83.86
CRUX-O	60.63	66.20	79.00	77.00
MATH	69.80	62.12	71.84	72.35
GSM8k	92.80	91.50	94.39	91.83
GPQA	25.18	45.90	47.47	49.12

三条对比结论：对自家 Hunyuan-Large 14 个 benchmark 赢 12 个，激活参数只有 1/4、总参约 1/5；对 Qwen2.5-72B 几乎全赢；对总参约 3 倍、激活约 2 倍的 Qwen3-A22B，12 个里赢 7 个。

慢思考模式（Table 3）

对比 OpenAI-o1-1217、DeepSeek-R1-0120、Qwen3-A22B。拿第一的：

• AIME2024 87.3（o1 74.3 / R1 79.8 / Qwen3 85.7）
• ZebraLogic 84.7、BBH 89.1
• BFCL v3 78.3（o1 67.8 / R1 56.9 / Qwen3 70.8）
• ComplexFuncBench 61.2（o1 47.6 / R1 41.1 / Qwen3 40.6）
• C³-Bench 63.5（o1 58.8 / R1 55.3 / Qwen3 51.7）

短板也很明确：AIME2025 76.8 落后 Qwen3-A22B 的 81.5；LiveCodeBench 63.9 vs Qwen3 的 70.7；Word-Task 62.9 落后 R1 的 76.3。

快思考模式（Table 4）

对比 Hunyuan-Large-1116、Qwen2.5-72B-instruct、Qwen3-A22B。ComplexFuncBench 74.0，而三个对手是 25.2 / 40.1 / 38.1——这个 gap 大到需要单独存疑（见下面局限）。τ-Bench 42.6 也是第一。BBH 87.0 第一。数学与代码在快思考下明显弱于 Qwen3-A22B（AIME2024 30.6 vs 40.1、LiveCodeBench 27.4 vs 35.3）。

长上下文（Table 5 / Table 6）

关键 benchmark：PenguinScrolls 87.7、LongBench-v2 55.0、FRAMES 81.1。LongBench-v2 上 55.0 超过 DeepSeek R1 的 53.8 和 Qwen3-A22B 的 48.4，但落后 Gemini 2.5 Pro 的 60.9。

RULER 的 QA 子任务（选 QA 是因为任务捷径少、更接近真实场景）：

Model	Avg.	0-8K	8K-32K	32K-64K	64K-128K
Gemini 2.5 Pro	81.7	83.2	80.0	83.3	80.2
DeepSeek R1	72.0	75.4	72.1	72.1	65.6
Qwen3-A22B	73.0	76.6	72.8	72.9	66.6
Hunyuan-A13B	76.7	78.7	75.3	78.0	73.9

衰减曲线是这张表的重点：64K-128K 段 Hunyuan-A13B 还有 73.9，而 R1 掉到 65.6、Qwen3-A22B 掉到 66.6。衰减平缓程度仅次于 Gemini 2.5 Pro。

推理效率（Table 7）

A16W16C16 精度，输入 2048：

Batch	Output Length	Throughput (tokens/s)
1	14336	190.84
16	14336	1246.54
32	14336	1981.99
32	22528	1725.95

部署侧：vLLM / SGLang / TensorRT-LLM 一键部署 W16A16；支持 Auto Prefix Caching、Chunk Prefill；支持 Weight Only INT8 / W8A8 / KV Cache FP8 无损量化，可配 TP / EP / FusedMoE。

思考与可参考价值

这篇的真正贡献在哪

不在架构。细粒度 MoE、GQA、SwiGLU、NTK-aware 扩窗全是成熟组件。贡献是把「小激活参数 + 强能力」这条路线的完整配方写清楚了，尤其是后训练的四阶段拆分与每个赛道的 reward 工程。

三件事值得单独记：

1. 共享专家的 scaling law 结论：0 个明显差，1 个够用，超过 1 个收益递减甚至抖动。这是少见的把「共享专家该放几个」给出明确答案的公开报告。
2. 推理与全场景必须分相位，reward 体系不能共用。 推理相位的 reward 必须可验证（0/1 校验 + 沙箱执行），全场景相位必须能处理开放输出（GRM + 参考答案当语义锚）。混在一起训，reward 设计会互相打架。Stage3 采样回灌推理数据是为了防止 Stage1/2 的能力在对齐里被冲掉。
3. Agent 能力不是通用能力的副产品。 它唯一大幅超越更大模型的维度是工具调用，而那完全是靠专门的数据工程堆出来的——五角色引擎、三种工具响应源、30+ system instruction × 20000 种格式组合。

局限

• 技术报告性质，关键细节大量缺失：专家的 intermediate dimension 没给、MoE 负载均衡策略只字未提、RL 超参只给了温度和上下文长度、SFT 数据量除了 RL 的 150K 之外全部没有。想复现基本不可能。
• 零消融。 Dual-Mode CoT 对性能有没有代价？四个阶段各自贡献多少？共享专家那条 scaling law 只有结论没有曲线。全都没拆。
• 对比基线的时间点不齐。 慢思考表里的 OpenAI-o1-1217 和 DeepSeek-R1-0120 都是老版本，拿 2026-09 的模型对它们赢了说明不了太多。
• ComplexFuncBench 快思考 74.0 vs 对手 25–40 的 gap 需要存疑。 这种量级的领先在一个公开 benchmark 上出现，而报告对此一句分析都没有，更可能的解释是训练数据分布与该 benchmark 高度对齐（他们确实专门做了 20000 种工具格式组合），而不是能力上的代差。引用这个数字要谨慎。
• Coding 是明确短板但被一句话带过。 LiveCodeBench 慢思考 63.9 落后 Qwen3-A22B 7 个点，报告只说 “slightly lower”。
• 吞吐表没有对比基线，只有自己一个精度档的四行数，无法判断这个数字好不好。

对电商 / 搜推 / Agent 的可借鉴点

1. Dual-Mode 的实现方式极低成本，可以直接抄。 关键不是「有快慢两档」这个想法，而是同一套训练、同一个 checkpoint、靠格式区分——不引入模型选路，不用维护两份权重，线上只是加一个控制标签。任何需要「简单请求走短路径、复杂请求走长路径」的系统（搜索的 query 理解、客服的意图分流、推荐理由生成）都适用。要注意的是默认值选了慢思考，这是个保守选择：宁可多花 token 也不要在该想的时候不想。

2. Agent 数据的五角色合成引擎（user / planner / tool / agent / checker）值得直接照搬。 尤其是 checker 这个角色——多数合成 pipeline 只有 user/agent/tool 三方，加一个 checker 才能在合成阶段就把错误轨迹筛掉。三种工具响应来源（沙箱 / MCP / 合成）的组合也解决了真实工具覆盖不足的老问题。

3. 格式泛化是被低估的一环。 30+ 种 system instruction × 工具/动作/响应的格式变化 = 20000 种组合，目的是让模型不依赖某一种特定的工具调用格式。做 Agent 的人常常只在自己那一套 schema 上训，换个框架就崩——这条是便宜的保险。

4. 多目标 RL 的组织方式给了一个工业答案：一个通用 GRM 做语义锚打底，每个赛道再配专用 reward service + 偏好数据 + 构造流水线，16 子领域 30+ 服务。这比「调一个大 reward model 的权重配比」要可维护得多，因为每个赛道的失效可以独立定位和修复。

5. 长上下文不是只靠扩窗。 他们在 RL 侧单独加了幻觉专项 reward model + online RL。扩到 256K 只是让模型能看见，能不能不编需要单独治——RULER 64K-128K 段的衰减优势可能有这一步的功劳。

6. RL 的 prompt 从「SFT 模型表现不稳定的 case」里采样，而不是随机采。这是个很实际的采样策略：已经稳定答对的没有梯度可挖，完全不会的又学不动，不稳定的那批才是收益最高的。搜推里做难例挖掘是同一个逻辑。

7. 与同 topic 的 DeepSeek-V4 对照读：V4 从注意力架构侧压单 token 成本（混合稀疏注意力 + KV 压缩），Hunyuan-A13B 从激活参数量侧压成本（细粒度 MoE 只激活 13B）。两条正交的效率路线，想理解「开源模型怎么降推理成本」应该一起看。

一句话

Hunyuan-A13B 是一份配方报告而不是方法论文：架构没有新东西，价值全在 20T 语料（含 250B STEM）、四阶段后训练的相位拆分、以及每个赛道独立的 reward 工程；最值得抄的两件事是 Dual-Mode CoT 用空 <think> 块把推理深度降级成一个推理时标签，以及 agent 能力靠五角色合成引擎 + 两万种格式组合单独喂出来——后者也是它唯一真正拉开更大模型的维度，但那个 ComplexFuncBench 74.0 vs 38 的 gap 大得可疑，引用前最好自己复测。