Day 0 support for Reflection’s Beam on Google Cloud: 5x faster perf with llm-d and NVIDIA Dynamo

Google Cloud 上 Reflection Beam 的 Day-0 支持，性能提升 5 倍 | Google Cloud 博客

人工智能基础设施

Google Cloud 上 Reflection Beam 的 Day 0 支持：使用 llm-d 和 NVIDIA Dynamo 实现 5 倍性能提升

2026 年 10 月 17 日

##### Injae Kwak

人工智能基础设施产品经理

##### Shivaji Dutta

人工智能基础设施解决方案架构师

##### 立即体验 Gemini

职场 AI 的入口

立即体验

今天，Reflection 发布了 Beam，这是其首个开源权重模型，旨在为开发者、研究人员和企业提供对前沿软件工程和长期代理任务的开放控制和定制能力。Beam 在 Apache 2.0 许可证下发布，支持 BF16、FP8 和 NVFP4 检查点，其在 5000 亿参数级别通过 3 到 4 倍的推理计算效率解决了复杂推理和编码问题，重新定义了该参数级别的推理效率标准。

随着 Beam 的发布，Google Cloud 宣布提供 Day 0 支持和即用型部署方案，可在 Google Cloud AI 超级计算机和 NVIDIA AI 基础设施上运行 Beam。

为帮助开发者在生产环境中充分发挥 Beam 的 token 效率优势，我们与 Reflection 合作，通过 Google Cloud 上的 llm-d（集成 vLLM）和 NVIDIA Dynamo（集成 SGLang）对底层服务栈进行性能优化：

"通过在 Google Cloud 部署 Beam 模型，我们实现了高达 5 倍的性能提升和 8 倍的延迟降低，从而优化了代理工作负载的推理服务。" —— Reflection 产品副总裁兼开源负责人 Joe Spisak

通过 Google Cloud 的 Day 0 发布，开发者可获得：

• 复合型模型与系统效率：将 Beam 的 3 到 4 倍推理计算效率与 A4X Max 实例（NVIDIA GB300 NVL72）的系统级优化结合，实现最高 5 倍吞吐量提升和 8 倍延迟降低*，以及 G4 虚拟机（NVIDIA RTX PRO 6000）的最高 2 倍吞吐量提升和 8 倍延迟降低*。

• 高效多轮对话服务：通过 KV 缓存感知路由、预填充/解码分离、推测解码和分层 KV 缓存卸载到主机 DRAM 和本地 SSD，减少长编码会话中的冗余提示重新计算。

• 开箱即用的优化部署：通过 AI-Hypercomputer/gpu-recipes、llm-d 仓库和 Gemini 平台的 Model Garden，只需点击几次即可获取针对代理工作负载优化的 llm-d 和 NVIDIA Dynamo 推荐性能方案。

*基于客户基准测试数据

推理扩展需要系统级优化

在评估代理编码和工具使用模型时，推理效率发生在两个不同的层级：模型推理的效率以及服务系统执行多轮循环的效率。

#### 模型级效率：Reflection 的 Beam

Reflection 专门设计了 Beam（总参数约 5010 亿，每个 token 激活约 230 亿参数，上下文窗口约 100 万 token），用于原生文本软件工程和多步骤工具使用。它可以直接集成到开发者已使用的编码工具中，包括 Reflection 的 Mirror CLI、Claude Code、Hermes、OpenCode 等，用于解决 GitHub 问题、运行 CLI 和 DevOps 工作流，并完成长期任务。

由于 Beam 每个 token 仅激活 230 亿参数，并且使用比其他同类开源权重模型少 3 到 4 倍的推理 token 即可达到解决方案，因此显著降低了每个推理步骤所需的推理时间计算量。

#### 系统级效率：AI超计算机优化服务

一旦开发人员将代理部署到生产环境，服务层可能会出现另一组瓶颈。在代理式编码循环中，单次会话中模型会被调用数十次。每次交互时，编码工具都会将新的文件读取、代码差异、编译器日志和工具输出追加到共享对话历史记录中，这些记录会迅速增长到数万甚至数十万token。

即使模型本身在每次交互中生成的推理token数量减少到原来的1/3到1/4，跨交互累积的上下文窗口仍会带来两个主要的基础设施挑战：

第一，预填充计算成为瓶颈。标准的Kubernetes负载均衡器使用无状态的轮询路由分配请求。当编码工具发送会话的第15次交互时，它通常会被分配到与第14次交互不同的副本上。该副本被迫从头开始重新计算整个历史提示，浪费GPU计算资源并产生漫长的预填充队列，延迟其他用户请求。

第二，解码过程受KV缓存容量限制。为数十个并发代理会话维护长上下文的KV缓存会迅速填满GPU高带宽内存（HBM）。一旦HBM被填满，服务引擎就必须逐出较早的KV块。这些块被逐出后，缓存命中率下降，GPU吞吐量停滞。

为了在集群规模上保持Beam的模型级效率，服务堆栈必须作为分布式系统进行优化。这就是为什么我们的方案将Beam与llm-d（集成vLLM）和NVIDIA Dynamo（集成SGLang）相结合。

AI超计算机推理架构内部解析

为了在Day 0就以最佳效率运行Beam的BF16、FP8和NVFP4检查点，我们在AI超计算机上设计了垂直整合的架构，每一层都负责代理服务生命周期中的特定环节。

面向代理流量的系统优化架构

与将推理容器视为无状态端点不同，堆栈的每一层都围绕多轮代理生命周期协同设计：

• 前缀感知与负载感知路由（GKE + llm-d EPP / Dynamo路由器）：跟踪工作负载容器中缓存的前缀和队列深度，将每个后续交互引导至保存其热KV前缀的副本，同时通过交互优先级流量控制防止队列饱和。

• 解耦计算与推测解码（A4X Max & G4实例）：使用原生Blackwell NVFP4运行vLLM和SGLang，结合专家并行（EP）处理Beam的23B活跃专家，数据并行注意力机制和DFlash2推测解码。将预填充（Prefill）和解码（Decode）池分离，确保大提示突发不会阻塞活跃token生成。

• 分层KV缓存（GPU内存 -> DRAM & 本地SSD）：活跃的KV块保留在高带宽GPU内存（第一层级），而长周期会话中被逐出的热KV块通过vLLM的OffloadingConnector或SGLang的HiCache溢出到主机CPU DRAM和本地NVMe SSD（第二层级），使历史上下文可在毫秒级内获取，而非从头重新计算。

多轮代理工作负载的系统优化

在处理AgentX轨迹数据集等多轮编码和工具使用工作负载时，随着并发量的上升，服务堆栈的每一层都为代理工作负载的多轮、长上下文流量模式带来性能和延迟优化：

关于这些图表的阅读说明。这两种配置方案不具备可比性。NVIDIA Dynamo运行在配备32块NVIDIA GB300 NVL72GPU的A4X Max实例上；llm-d运行在配备8块NVIDIA RTX PRO 6000 GPU的G4虚拟机上。每张图表均显示相同硬件基线上的性能提升幅度。更多副本数量为路由器提供了更多热KV缓存命中机会，也创造了更大空间将预填充与解码过程分离，因此性能提升幅度会随着部署规模扩大而增长。llm-d和NVIDIA Dynamo均可根据底层基础设施进行弹性扩缩容。

NVIDIA Dynamo优化性能 vs Reflection's Beam基准部署

llm-d优化性能 vs Reflection's Beam基准部署

在两个平台中，叠加这些优化措施可将帕累托前沿向更优方向移动，同时实现更高的输出吞吐量和更快的用户交互速度：

• 基准部署（无状态轮询路由）：在标准Kubernetes部署中若不启用前缀感知功能，同一编程会话的连续对话回合会被分配到不同副本上，导致历史上下文的预填充计算需要反复执行，随着并发量增加吞吐量将趋于饱和。

• KV缓存感知与流量控制路由：在NVIDIA Dynamo中启用前缀感知路由，或在llm-d中使用带回合优先级流量控制的 Sticky EPP，可将多回合代理轨迹固定在保存其热KV缓存的副本上，立即降低首令牌生成延迟（TTFT），释放GPU计算资源，显著提升令牌吞吐量。

• 主机DRAM与本地SSD（LSSD）KV卸载：将被驱逐的KV块从GPU内存卸载到主机DRAM和本地NVMe SSD，可防止数十个长上下文编程会话在设备GPU内存容量不足时出现缓存抖动。

• 解耦服务、推测解码与KV池调优：通过混合KV缓存内存分配调优、启用推测解码、解耦预填充与解码工作节点，可将令牌生成与大促发提示分离，同时通过草稿模型提升输出吞吐量，保持每个代理的令牌交互速度。

立即体验并在PyTorchCon和GTC柏林与我们见面

本文探讨了如何通过系统级优化将性能扩展到Reflection's Beam模型系列，以支持智能代理工作负载。本文涉及的所有Kubernetes配置文件、路由器配置和基准测试脚本均为开源，可直接在您自己的GKE集群上运行。

• 部署优化架构：通过AI-Hypercomputer/gpu-recipes仓库中的A4X Max和G4平台、Gemini平台Model Garden的Day 0指南，了解如何使用llm-d和NVIDIA Dynamo运行Reflection's Beam。

• 下载模型权重：在Reflection的Hugging Face页面获取Apache 2.0 BF16、FP8和NVFP4检查点。

• 参加San Jose的llm-d与PyTorch大会：如果您将参加10月在San Jose举办的PyTorch北美大会，请前往llm-d社区会议和Google Cloud展位#，我们将现场演示KV缓存感知路由、P/D解耦和智能代理工作负载的KV缓存分级技术。

• 参观NVIDIA GTC柏林：如果您将参加NVIDIA GTC柏林，请前往我们的展位#3026或Google Cloud Hub（w3.hub），展位距离会场仅需5分钟步行路程。了解更多关于我们的会议内容。

发布分类：

• AI基础设施

• 容器与Kubernetes

• AI超计算机

• 计算

• llm-d