Reflection Beam 技术笔记：501B MoE 如何把「大容量」和「可部署」拧在一起

> 写给想自托管前沿级开源模型、又关心显存与 KV Cache 的工程师。基于 Reflection / Hugging Face 公开材料整理，不涉及未公开评测。

2026 年 10 月中旬，Reflection 在 Apache 2.0 下放出了 **Beam 1.0**（Hugging Face 上记作 `reflection/Beam-1.0-501B-A23B`）：总参约 **501B**，每 token 约 **23B** 激活，上下文 **1M**，定位编码、推理与长程 Agent。同一周还有 Meta Muse Spark Open、NVIDIA Nemotron 3.5 等开放权重发布；Beam 的特殊之处在于：许可证宽松、结构细节写得很开，并且 day-0 就接到了 transformers / vLLM / SGLang。

下面按「结构 → 长上下文代价 → 推理与后训练」三条线记笔记，方便对照自家集群选型。

## 1. 稀疏 MoE：大容量，按 token 只跑一小撮专家

Beam 是稀疏 Mixture-of-Experts：

- 共 **52** 层，隐藏维 **5120**
- 前 **3** 层仍是稠密 SwiGLU MLP；其余 **49** 层换成 MoE
- 每层 **256** 个专家，每个专家约 **39M** 参（中间维 2560）；专家占模型参数约 **98.4%**
- 路由沿 DeepSeek-V3 的 **group-limited** 思路：sigmoid 打分 → 8 组 × 32 专家 → 保留最好的 4 组 → 组内再选 top-8；**无 shared expert**
- 专家输出按归一化路由权重融合，再乘缩放系数 **2.5**

结果是：权重体积仍按 501B 计（BF16 safetensors 约 **1 TB**），但前向按约 **23B** 激活量走。部署时「显存按大模型备、算力按小模型估」——这是选型时最容易低估的一点。

## 2. 混合注意力：多数层只看 512，少数层看满上下文

长上下文成本往往卡在 KV Cache，而不是参数量本身。Beam 的做法是：

- 多数层用 **sliding-window**，窗口 **512**，位置编码用 RoPE
- 每隔 6 层以及最后一层做 **全局注意力**；全局层不用 RoPE，而是对 query 做随可见长度缓慢增大的缩放：`(1 + (pos + 1) / 2048) ** 0.1`（实现里叫 scalable-softmax query scaling）
- 统计上约 **43** 层滑窗 + **9** 层全局
- Attention 为 GQA：**48** query heads / **8** KV heads，并对 Q/K 做 RMSNorm；还有一层从输入算出的 sigmoid gate，在输出投影前按通道缩放

公开材料给出的 BF16、transformers 动态 cache、**单序列** KV 粗算对比很直观：

| 上下文 | 若 52 层全全局 | Beam（混合注意力） |
| --- | --- | --- |
| 32K | ~6.5 GiB | ~1.2 GiB |
| 128K | ~26 GiB | ~4.6 GiB |
| 1M | ~208 GiB | ~36 GiB |

量级大约是「全全局」的 **1/6**。做 Agent、仓库级问答、长日志回放时，这比单纯堆更大 context 窗口更有工程意义。

## 3. 残差流尺度：按深度做「方差守恒」式加权

标准 Transformer 每层残差权重为 1，流的尺度会随深度漂。Beam 把输入 embedding 算作第 1 步，在第 `k` 步：

- 新子层输出权重：`1/sqrt(k)`
- 已有流权重：`sqrt((k-1)/k)`

两者平方和为 1，整网约 **104** 次加法后，各子层与 embedding 在最终隐状态里权重相当。此外还有前后归一化，以及 logits 在 FP32 下的 tanh softcap（约 ±30）。实现里明确把 router、SwiGLU 乘积、norm、RoPE、query scaling、softcap 等放在 FP32 路径上——这对数值稳定和跨精度复现都有帮助。

## 4. 推理侧：精度档位、投机解码与「推理力度」旋钮

权重提供 **BF16 / FP8 / NVFP4**；并配有 **DFlash2** 投机解码 draft 模型。公开建议大致是：

- **Blackwell**：优先 NVFP4（约把 ~1 TB BF16 压到 ~280 GB 量级），例如 4×B200/B300 起跳仍偏紧，长上下文与并发要留余量
- **Hopper / Ampere**：用 FP8；常见配方是 8×H200 一类配置
- vLLM / SGLang 均有 day-0 示例；SGLang 侧需打开 Beam 专用的 tool-call / reasoning parser

Tokenizer / chat template 侧值得单独记：

- `reasoning_effort`：`low` / `medium`（默认）/ `high` / `xhigh` / `max`
- `preserve_thinking`：多轮可把思考轨迹留在上下文
- `parse_response`：按 tokenizer 自带的 response template 拆出 reasoning、答案与 tool calls，避免手写正则
- Tool calling 用专用语法；解析时把 `tools` schema 一并传入，便于参数类型转换

对云上 Agent 编排来说，「可解析的结构化输出 + 可调推理预算」比裸生成更省对接成本。

## 5. 后训练路径：LoRA SFT 与全参 / LoRA GRPO

公开配方包括：

- **TRL + PEFT LoRA SFT**：例如在 Multilingual-Thinking 上做语言遵从；8×B300 单节点量级可跑到约 19k tokens/s（官方示例口径）
- **Miles 上的 GRPO**：Megatron 训练 + SGLang rollout；全参 BF16 参考配置可到数十枚 H200 量级，LoRA GRPO 可显著降规模
- 自蒸馏（self-distillation）配方也在推进：用任务轨迹训 LoRA，再迭代提成功率与 token 效率

若团队目标是「领域 Agent / 内网工具调用」，优先 LoRA + 清晰评测集，通常比一上来全参 RL 更可控。

## 6. 和同期开放权重的对照（选型用）

同一时段还有：

- **Meta Muse Spark Open**：816B 总参 / 42B 激活、原生多模态、1M 上下文，偏桌面与 Agent；许可证为 Muse Model License（商用条款需单独核对）
- **NVIDIA Nemotron 3.5**：Super（120B-A12B，多模态）与 Lightning（30B-A3B）等，强调蒸馏、长上下文与原生投机解码，并提供 cookbooks
- **Meta Muse Glimmer 30B**：面向消费级本地 Agent，约 4-bit、Apache 2.0

Beam 的差异化可以概括成三句话：**Apache 2.0**、**混合注意力把 1M KV 压到可谈的量级**、**推理栈与后训练菜谱在发布日就齐**。它并不「小」，但把「大模型容量」和「可落地推理」之间的缝缝得很紧。

## 7. 落地建议（华为云场景可直接套）

1. **先 API / 托管端点验证任务**，再谈自托管；权重下载与多机并行都是重活。
2. **自托管先选 FP8 或 NVFP4**，并按目标上下文长度单独算 KV，不要只看参数量。
3. **Agent 场景**：固定 tool schema，打开专用 parser；用 `reasoning_effort` 做延迟–质量旋钮。
4. **定制**：先 LoRA SFT / 自蒸馏，评测稳定后再考虑更大的 RL。
5. **合规**：Apache 2.0 对二次分发友好，但仍需按业务做安全评测与内容过滤；开放权重不等于免审。

## 参考（外链以纯文本给出，避免编辑器白名单拦截）

- Reflection 发布说明：`https://reflection.ai/blog/beam-is-available`
- Hugging Face 技术博文（结构与配方最全）：`https://huggingface.co/blog/reflection-beam`
- 模型页：`https://huggingface.co/reflection/Beam-1.0-501B-A23B`
- Meta Muse Spark Open：`https://research.meta.ai/blog/muse-spark-open`
- NVIDIA Nemotron 3.5：`https://research.nvidia.com/labs/nemotron/Nemotron-3.5-Super-and-Lightning/`

---

*本文为学习笔记，数据与配置以官方页面为准；部署前请按实际 GPU 代际与驱动复测吞吐与精度。*