Reflection 放出 501B 的 Beam 权重：四套精度、滑动窗口和一场榜单落差

这次放出来的到底是什么#

官方模型卡的硬口径：

• 总参 501.3B、激活 23.4B，稀疏 MoE，52 层 = 3 层 dense + 49 层 MoE，每层 256 个专家、每 token 取 8 个
• 注意力是 Gated GQA + 滑动窗口，KV head 只有 8 个，head_dim 128
• 上下文 1M token，词表 152k（config.json 里是 151936）
• 只支持文本，主要面向英文；知识截止 2026 年 6 月 30 日
• 许可证 Apache 2.0。模型卡里明确写着不禁蒸馏、不禁用输出训别的模型、不禁微调/量化/合并

还有几条只在第三方报道里出现、模型卡没写的：预训练 23.8T token、RL 阶段在 10500 张 GB300 上跑了四周、产出超过 1 亿条 rollout、40 多家合作方做「agent 开放操作系统」（Transformers / vLLM / SGLang / Unsloth / Dynamo 首日支持，AWS、Azure、GCP、Baseten、CoreWeave、Together、OpenRouter 有托管端点）。这些我标注为第三方口径——如果你要引用，请回官方博客核。

顺带说个容易踩的时间线：第三方摘要把这次发布写成「周五（10 月 16 日）放权重、预览 11 天后」，但 HF API 的 createdAt 是分批发出来的：

所以「哪天发布」取决于你数哪一天：权重文件夹上周就摆上去了，正式对外吆喝是这周。

四套权重的账，自己算一遍#

?blobs=true 这个接口会给出每个文件的字节数和整个仓库的参数精度分布，不用下载就能核账。把下面这段存成 beam_calc.py 直接跑：

import json, subprocess

def curl(url, out):
    subprocess.run(["curl", "-sL", "--max-time", "90", url, "-o", out], check=True)
    return json.load(open(out))

repos = ["reflection/Beam-1.0-501B-A23B", "reflection/Beam-1.0-501B-A23B-FP8",
         "reflection/Beam-1.0-501B-A23B-NVFP4", "reflection/Beam-1.0-501B-A23B-DFlash2"]

for i, repo in enumerate(repos):
    d = curl(f"https://hf-mirror.com/api/models/{repo}?blobs=true", f"/tmp/{i}.json")
    files = [s for s in d["siblings"] if s["rfilename"].endswith(".safetensors")]
    total = sum((s.get("size") or 0) for s in files)
    print(f"{repo:48s} 分片 {len(files):4d}  磁盘 {total/1e9:8.2f} GB = {total/1024**3:8.2f} GiB")
    print("   参数精度分布:", json.dumps(d.get("safetensors")))

本机输出（HF 原站被墙，huggingface.co 换 hf-mirror.com 即可，元数据一致）：

reflection/Beam-1.0-501B-A23B         分片  188  磁盘  1002.67 GB =   933.81 GiB
   参数精度分布: {"parameters": {"BF16": 501203374528, "F32": 64237824}, "total": 501267612352}
reflection/Beam-1.0-501B-A23B-FP8     分片  188  磁盘   503.29 GB =   468.72 GiB
   F8_E4M3: 499646464000  BF16: 1556910528  F32: 64237824
reflection/Beam-1.0-501B-A23B-NVFP4   分片   53  磁盘   293.63 GB =   273.47 GiB
   U8: 246625075200  BF16: 7953224128  F32: 64237824
reflection/Beam-1.0-501B-A23B-DFlash2 分片    1  磁盘     3.85 GB =     3.59 GiB
   BF16: 1927484672

三件事值得单独拎出来：

第一，501.3B 是真的。 元数据里 BF16 501203374528 + F32 64237824 = 501267612352 个参数，和官方口径 501.3B 对得上，误差在小数点后。这种「宣传数字能被文件元数据验算」的开放权重，比只发评测表的可信度高一档。

第二，FP8 那份几乎没省参数、只省了字节。 参数总量还是 501267612352，只是其中 499646464000 个换成了 F8_E4M3，忽略列表只有 lm_head、model.embed_tokens 和 re:.*mlp\.gate$。磁盘从 933.81 GiB 掉到 468.72 GiB，正好对半——说明这就是一次干净的动态 FP8 量化，没动结构。

第三，NVFP4 的「约 280 GB」是 GiB 口径。 磁盘实测 293.63 GB = 273.47 GiB。元数据里 U8: 246625075200 是打包后的字节数（一个字节装两个 fp4 值，所以真实元素数约 4930 亿），另有 79.5 亿参数留在 BF16——对应忽略列表里的 model.layers.0*、model.layers.1.* 以及一部分层的 gate 和 attention。把前两层和门控留在高精度，是 MoE 量化里最经典的保精度手法，这份忽略列表可以直接拿来抄。

1M 上下文为什么没把显存吃光#

config.json 里有两条信息比参数数字更值钱：

{ "sliding_window": 512, "num_hidden_layers": 52, "num_key_value_heads": 8, "head_dim": 128,
  "layer_types": ["sliding_attention", "sliding_attention", ...] }

52 层里只有 9 层是 full attention（索引 5、11、17、23、29、35、41、47、51，也就是每 6 层一个全局层），剩下 43 层是窗口只有 512 token 的滑动注意力。这是 1M 上下文敢开门的原因：绝大多数层根本不存长 KV。

顺手把这笔账算出来（KV 按 bf16，单序列，不含实现开销）：

kv_heads, head_dim, win, ctx = 8, 128, 512, 1_048_576
per_tok_per_layer = 2 * kv_heads * head_dim * 2      # K+V，2 字节
full, sliding = 9, 43
kv_full = full * ctx * per_tok_per_layer
kv_slid = sliding * win * per_tok_per_layer
print(f"1M 上下文 KV: 全局层 {kv_full/1024**3:.2f} GiB + 滑动层 {kv_slid/1024**3:.2f} GiB")
for n in (8192, 131072, 262144, 1048576):
    tot = full * n * per_tok_per_layer + sliding * min(n, win) * per_tok_per_layer
    print(f"  ctx={n:>8}: {tot/1024**3:7.3f} GiB")

输出：

1M 上下文 KV: 全局层 36.00 GiB + 滑动层 0.08 GiB
  ctx=    8192:   0.365 GiB
  ctx=  131072:   4.584 GiB
  ctx=  262144:   9.084 GiB
  ctx= 1048576:  36.084 GiB

结论很清楚：滑动窗口那 43 层加起来只花 80 MB，1M 上下文的全部代价压在 9 个全局层的 36 GiB 上。这 36 GiB 是单条序列的 KV，跟权重是分开的——NVFP4 权重 273 GiB 之后，你还要为每条长上下文序列再留这么多。真正做长上下文服务时，并发数是被这部分吃掉的，不是被权重吃掉的。

再算部署门槛：BF16 那套 933.81 GiB，按单卡 141 GiB 的 H200 算，光权重就要 8 张卡（1128 GiB），KV 和激活几乎没有余量；NVFP4 的 273 GiB 在 4 张 180 GB 的 B200 上落得比较舒服。所以「便宜的那套」不是省钱的锦上添花，是能不能跑的分水岭。

config.json 里还有六处能直接抄的细节#

把整份配置摊开，除了滑动窗口，这几处对做部署和微调的人比榜单有用：

• 48 个 query 头对 8 个 KV 头，6 个查询头共享一组 KV。这个比例直接决定长上下文显存：同规模模型里常见的是 4:1 甚至 2:1，6:1 更省，代价是注意力表达更粗——这也是它敢开 1M 的原因之一。
• 路由是分组 top-k：n_group: 8、topk_group: 4、norm_topk_prob: true、routed_scaling_factor: 2.5。先按组挑、再在组内选专家，是 DeepSeek 系那一套；norm_topk_prob 打开意味着 8 个专家的权重会被归一化——微调时如果自己改专家数，这两项必须一起改，否则输出尺度会漂。
• final_logit_softcapping: 30.0：对最终 logits 做 tanh 软上限。这是 Gemma 系传下来的技巧，稳住训练后期的极端 logit。值得抄进自己的训练配置，但它会让 logit 分布变平——如果你的流程依赖 logit 绝对值（比如自己算置信度），记得这层压过。
• rope_parameters 里只有滑动层写了 rope_theta: 10000.0，全局层是 null（走默认值）。这一条最有信息量：1M 上下文不是靠 RoPE 外推换来的，它没有为长上下文改 RoPE 基频或插值策略，位置能力靠的是「43 层只看 512 token」这套结构。所以别指望它在超出训练长度的位置上有外推红利——要测长上下文，用真实文档跑，别用 max_position_embeddings 这个声明值当结论。
• mlp_layer_types 把前 3 层显式标成 dense，官方口径「3 层 dense + 49 层 MoE」在配置层可核（索引 0、1、2）。这个「前几层不走 MoE」的设计是为了让底层特征更稳，做 LoRA 微调时通常优先挂这些 dense 层。
• bos_token_id、eos_token_id、pad_token_id 全是 null。这是最容易踩的一个：直接 tokenizer.encode() 拿到的序列没有它期望的边界符，停止位置会错。必须走 chat template——下面这几行指向你本地的权重目录（要装 transformers，权重没下完跑不了）：

from transformers import AutoTokenizer
tok = AutoTokenizer.from_pretrained("/models/beam-nvfp4")
print(tok.vocab_size, tok.bos_token, tok.eos_token)      # 151936 None None
print(tok.chat_template[:200])                            # 自定义 Harmony 模板
msgs = [{"role": "user", "content": "列出这个仓库的构建命令"}]
text = tok.apply_chat_template(msgs, tokenize=False, add_generation_prompt=True)
print(repr(text[-80:]))                                   # 结束处应出现 <|return|>

那个 19.3 亿参数的草稿模型#

四套仓库里最小的一份是 Beam-1.0-501B-A23B-DFlash2：单分片、磁盘 3.85 GB、BF16 共 1927484672 个参数，官方口径是走投机解码的草稿模型。它的意义在长上下文服务里最明显：1M 上下文的下一个 token 生成是带宽瓶颈，每步都要把 9 个全局层的长 KV 读一遍；用一个 19 亿参数的小模型先猜几步、再由 501B 批量验证，能把这部分墙钟时间压下来。

有一个从元数据能读出来的细节：它的词表是 151936，和 Beam 自己完全一致，而 151936 正是 Qwen3 系的词表大小，所以这份草稿大概率是拿 Qwen3 血统的模型接着训出来的（这是我的推断，模型卡只写了「草稿模型」）。投机解码要求草稿和目标模型共享分词器，否则每个候选 token 都得重映射一遍，收益会被吃掉——选草稿模型时先比词表，再比跑分，这条比参数大小重要。

想自己核一遍？四个接口就够#

这套核查法不依赖任何榜单，全是公开元数据，写开放权重评测时可以直接复用：

# 1) 仓库什么时候建的、有没有被打分（createdAt/downloads/likes）
curl -sL "https://hf-mirror.com/api/models/reflection/Beam-1.0-501B-A23B" | head -c 600
# 2) 每个文件多大、参数精度分布（自己算体积和「参数花在哪」）
curl -sL "https://hf-mirror.com/api/models/reflection/Beam-1.0-501B-A23B-NVFP4?blobs=true" \
  | /opt/data/workspace/venv/bin/python -c "import json,sys; d=json.load(sys.stdin); print(d['safetensors'])"
# 3) 层结构：窗口/全注意力各几层、专家数、RoPE 设置
curl -sL "https://hf-mirror.com/reflection/Beam-1.0-501B-A23B/raw/main/config.json" -o beam_config.json
# 4) 榜单表是「单调下降」还是有来有回——只有单调项才承载量化损失信号

前三个接口我在本机都跑通了（hf-mirror 与 HF 原站元数据一致）；第四个是读法，不是接口——同一张表里出现「BF16 比 NVFP4 低」的方向反转，就说明那一项的差值在噪声里，别拿它当结论。

起来大概长这样（模型名与参数请以 vLLM 官方文档为准，这里只是形状示意）：

# 先只拉一份 NVFP4，53 个分片约 294 GB
hf download reflection/Beam-1.0-501B-A23B-NVFP4 --local-dir /models/beam-nvfp4

vllm serve /models/beam-nvfp4 \
  --served-model-name beam \
  --tensor-parallel-size 4 \
  --max-model-len 262144 \
  --enable-prefix-caching

三套精度打同一套榜，这份表才是重点#

开放权重文章里最缺的，就是「量化掉多少分」。Beam 的模型卡直接给了 BF16 / FP8 / NVFP4 三列：

读法有两层。

量化损失整体小于 2 分，而且方向不一致：SWE Bench Pro v2-Hard 上 BF16 反而比 NVFP4 低 2.1 分，AIME 上 FP8（98.0%）比 BF16（97.7%）高。评测条件写得很清楚——temp=0.7、top_p=0.99，这个温度下同模型跑两遍的差本来就能到一两个点。所以「量化掉分」这件事在这张表里的信号强度，弱于噪声强度。

真正的信号是那些三列一致的项：Terminal Bench 80.1 / 78.9 / 78.4 是单调往下走，GPQA Diamond 90.6 / 90.3 / 89.3 也是。要判断该用哪套，别盯着一张表整体比，看单调下降的那几项。

自报分数和独立榜单的落差#

另一条要单独标注来源的：第三方报道称，同一天独立评测把 Beam 打在 Artificial Analysis 智能指数 30 分，落后 GLM-5.3（45）、Kimi K3（44）、Mistral Large 4（38）。

我没法在这台机器上复核这个分数——AA 的榜单页是前端渲染的，抓 HTML 检索不到不等于没上榜（这类榜单的正确做法是去它自己的接口或看榜单截图印在哪，别用「我搜不到」当结论）。所以把这条当第三方口径看。

但落差本身值得理解，因为两边可能都对：厂商自报的是 SWE-bench、Terminal Bench、GPQA、AIME 这类「能不能把活干完」的项，而综合智能指数里塞了大量知识问答和长尾推理。Beam 的定位写得很直白——「用约三分之一推理 token 达到同级质量」，也就是拿 token 效率换绝对分数。对一个要塞进 agent 循环、每轮都烧 token 的模型来说，这个交易是理性的；对刷榜来说不是。看到「自家表全绿、独立榜单掉 15 分」时，先问两个榜测的是不是同一件事。

上手前的五个坑#

1. chat template 是改过的 Harmony 格式，只有 analysis 和 final 两个 channel，没有 commentary channel，结束符是 <|return|>。你的 agent harness 如果按 OpenAI 那套解析，工具调用会解析不出来——要先读它的 chat_template_jinja 再改解析层。
2. NVFP4 是 Blackwell 的菜。它走 modelopt 打包，靠的是四代 tensor core 的 fp4 路径；在 Hopper 上老老实实用 FP8 那套。
3. 只支持英文。模型卡 language: [en]，中文任务别期待。
4. 知识截止 2026-06-30，比权重发布时间早三个多月，时效性要求高的场景要自备检索。
5. 下载成本是真的：BF16 一套 933.81 GiB，就算只拿 NVFP4 也是 273 GiB，先确认磁盘和带宽再动手；unsloth 那份 GGUF 有 98 个文件、合计约 3.8 TB（覆盖多个量化档，别整仓拉）。
6. 仓库里没有自写建模文件：除了权重，仓库只有 config.json、chat_template.jinja、generation_config.json、tokenizer.json 四件套，没有 modeling_*.py；分词器也只有 fast 格式的 tokenizer.json（没有老式的 vocab.json/merges.txt）。也就是说这套「混合注意力 + 分组路由」是走 transformers 原生实现的（这是从文件清单做的推断，不是官方声明），推理框架得是新版本才认——上线前先在测试机上确认你那份 vLLM/SGLang/transformers 能不能加载，别等灰度当天才发现。

总结#

Beam 这次值得记的不是分数，是账目透明度：501.3B 这个数字能被文件元数据验算，三套精度各自打了同一套榜，NVFP4 的忽略列表公开，连草稿模型都放出来（DFlash2 是 Qwen3 架构的 19.3 亿参数模型，走投机解码加速）。这类东西对做部署决策的人比多 5 分有用得多。

至于那场「自家表漂亮、独立榜单掉队」的争议，我的建议是别急着站边：把这两张表放一起看，它们其实在描述两件不同的事——一个模型能不能把工程任务做完，和一个模型在综合知识测试里排第几。前者决定你 agent 的成功率，后者决定它在排行榜上的名字。你自己要哪一样，先想清楚。

如果你只从这篇里带走一件事：看到一份「开放权重」公告，先去 HF 兼容 API 拿一次 ?blobs=true，把每个仓库的字节数与精度分布抄下来，再回头读媒体稿。那几行数字比任何测评截图都硬——它能立刻告诉你参数都花在哪、哪套精度是真能装进你的卡、以及发布方有没有在吞吐量上贴着红线做人情。这套查法对别的开源权重同样适用，换成任何一家都行。

参考与致谢#

• Reflection 官方模型卡与权重：https://huggingface.co/reflection/Beam-1.0-501B-A23B
• Reflection 发布博客：https://reflection.ai/blog/introducing-beam
• 模型卡基准表的第三方转述（含 10500 张 GB300、23.8T token 等未在模型卡出现的信息）：https://dev.to/hiroki-ii-ai/ai-daily-digest-october-18-2026-reflection-opens-beam-501b-anthropic-replaces-git-tsmc-rides-4d7l

文中体积、参数量、层结构与 KV cache 数字均由本机脚本现场计算，脚本已附在正文中。