I
IAI 编辑部 · 官方 Official
IAI 编辑部 · 新闻解读 / News analysis
10 月 16 日，Reflection 发布首个开放权重模型 Beam（Beam-1.0-501B-A23B），Apache 2.0 许可，Hugging Face 同日发布技术博客。本帖重点看它对推理部署最有参考价值的部分：KV Cache 设计。
一、基本信息（来自 HF 博客）
- 501B 总参数，每 token 激活约 23B；52 层，每个 MoE 层 256 个专家、路由 8 个（路由方案沿用 DeepSeek-V3 的分组限制方式，但不设共享专家）。
- 纯文本输入输出，上下文 1M tokens；checkpoint 提供 BF16、FP8、NVFP4。
- 许可：Apache 2.0。
二、混合注意力如何省 KV Cache
- 52 层中 43 层是滑动窗口注意力（只看前 512 个 token），9 层是全局注意力（每第 6 层及最后一层）。
- 每层每 token 缓存 2 × 8 个 KV 头 × 128 维 = 2048 个值。如果 52 层全是全局层，BF16 下每 token 约 208 KiB；实际上只有 9 个全局层随序列增长，约 36 KiB/token，约为原来的 1/6。
- 官方表格（每条序列、BF16）：32K 上下文 6.5 GiB → 1.2 GiB；128K 26 GiB → 4.6 GiB；1M 208 GiB → 约 36 GiB。
三、部署参考（来自 HF 博客）
- NVFP4 权重约 280 GB（BF16 约 1 TB）；NVFP4 需要 Blackwell 原生支持，Hopper/Ampere 建议用 FP8。
- 2 张 B200（共 360 GB）勉强装下权重，官方建议按 4 张 B200 规划，给 KV Cache 和并发留空间。
- 提供 DFlash2 投机解码草稿模型，每步最多提议 15 个 token，由主模型一次前向验证。
四、编辑部解读
1. 长上下文的瓶颈越来越在 KV Cache，而不是权重。“少数全局层 + 多数局部层”是用架构换显存的典型思路，代价是长距离信息只能靠少数层传递，具体效果需要在自己的长文档任务上实测。
2. 估算显存时把“每 token KV 大小 × 上下文 × 并发数”单列出来，可配合本站显存估算帖：https://www.iaiforum.com/t/5
3. Apache 2.0 对商用最友好，但 501B 的体量决定了它主要面向有多卡集群的团队。
English summary: Beam (501B total / 23B active, Apache 2.0, 1M context) mixes 43 sliding-window layers (512-token window) with 9 global layers, cutting KV cache growth from ~208 KiB to ~36 KiB per token in BF16.
来源 Sources：
- Hugging Face 技术博客：https://huggingface.co/blog/reflection-beam
- Reflection 官方博客：https://reflection.ai/blog/beam-is-available
讨论：你们线上长上下文服务的显存，大头是权重还是 KV Cache？用过哪些手段（量化 KV、prefix cache、分页、滑动窗口）？
——
IAI 编辑部（iaiforum.com 官方编辑账号 · Official editorial account of IAI Forum）
10 月 16 日，Reflection 发布首个开放权重模型 Beam（Beam-1.0-501B-A23B），Apache 2.0 许可，Hugging Face 同日发布技术博客。本帖重点看它对推理部署最有参考价值的部分：KV Cache 设计。
一、基本信息（来自 HF 博客）
- 501B 总参数，每 token 激活约 23B；52 层，每个 MoE 层 256 个专家、路由 8 个（路由方案沿用 DeepSeek-V3 的分组限制方式，但不设共享专家）。
- 纯文本输入输出，上下文 1M tokens；checkpoint 提供 BF16、FP8、NVFP4。
- 许可：Apache 2.0。
二、混合注意力如何省 KV Cache
- 52 层中 43 层是滑动窗口注意力（只看前 512 个 token），9 层是全局注意力（每第 6 层及最后一层）。
- 每层每 token 缓存 2 × 8 个 KV 头 × 128 维 = 2048 个值。如果 52 层全是全局层，BF16 下每 token 约 208 KiB；实际上只有 9 个全局层随序列增长，约 36 KiB/token，约为原来的 1/6。
- 官方表格（每条序列、BF16）：32K 上下文 6.5 GiB → 1.2 GiB；128K 26 GiB → 4.6 GiB；1M 208 GiB → 约 36 GiB。
三、部署参考（来自 HF 博客）
- NVFP4 权重约 280 GB（BF16 约 1 TB）；NVFP4 需要 Blackwell 原生支持，Hopper/Ampere 建议用 FP8。
- 2 张 B200（共 360 GB）勉强装下权重，官方建议按 4 张 B200 规划，给 KV Cache 和并发留空间。
- 提供 DFlash2 投机解码草稿模型，每步最多提议 15 个 token，由主模型一次前向验证。
四、编辑部解读
1. 长上下文的瓶颈越来越在 KV Cache，而不是权重。“少数全局层 + 多数局部层”是用架构换显存的典型思路，代价是长距离信息只能靠少数层传递，具体效果需要在自己的长文档任务上实测。
2. 估算显存时把“每 token KV 大小 × 上下文 × 并发数”单列出来，可配合本站显存估算帖：https://www.iaiforum.com/t/5
3. Apache 2.0 对商用最友好，但 501B 的体量决定了它主要面向有多卡集群的团队。
English summary: Beam (501B total / 23B active, Apache 2.0, 1M context) mixes 43 sliding-window layers (512-token window) with 9 global layers, cutting KV cache growth from ~208 KiB to ~36 KiB per token in BF16.
来源 Sources：
- Hugging Face 技术博客：https://huggingface.co/blog/reflection-beam
- Reflection 官方博客：https://reflection.ai/blog/beam-is-available
讨论：你们线上长上下文服务的显存，大头是权重还是 KV Cache？用过哪些手段（量化 KV、prefix cache、分页、滑动窗口）？
——
IAI 编辑部（iaiforum.com 官方编辑账号 · Official editorial account of IAI Forum）