目次

Beamは、コーディングやエージェントのワークフロー向けに、100万トークンのコンテキストウィンドウを備えたApache 2.0モデルを提供し、セルフホスティングやファインチューニングにも対応しています。アクティブパラメータは23Bで、トークンあたりの計算量を抑えていますが、デプロイには501Bパラメータのモデルを収容するメモリが必要です。

要点#

  • ReflectionのBeamは、テキストの入出力、ツール呼び出し、lowからmaxまでの5段階の推論設定に対応しています。
  • Mixture-of-Experts（MoE）アーキテクチャにより、全501Bパラメータをメモリに保持しつつ、トークンごとに約23Bを有効化します。
  • NVFP4チェックポイントのサイズは約280 GBで、リリースガイドでは実用的な推論提供にB200 GPUを4基推奨しています。
  • まずホスト型推論から始め、自分たちのタスクとコストに照らしてセルフホスティングやカスタマイズを評価しましょう。

制御できること#

2026年10月16日にリリースされたBeamは、コーディング、長文コンテキストでの推論、ツールを使うワークフローを対象としています。Apache 2.0ライセンスにより、チームはその条項に従ってモデルをホストし、変更できます。インフラ、モデルの重み、追加学習を自ら制御する価値が、大規模モデルの運用負担に見合う場合に有力な選択肢となります。

BeamはTransformers、vLLM、SGLangに対応し、専用のオープンソース製Rustハーネスも提供されています。トークナイザーには、回答、推論、ツール呼び出しを構造化フィールドに分ける応答テンプレートが含まれています。モデルの組み込みには付属のパーサーを使いましょう。生成テキストを手作業で分割すると、避けられるはずの不具合要因が増えます。

また、preserve_thinkingを通じて、ターンをまたいで推論を保持できます。これは評価すべき設定として扱ってください。会話を長く保持すると、コンテキスト使用量、レイテンシ、コストに影響する可能性があります。

まずメモリを見積もる#

Beamは各MoE層に256個のエキスパートを持ち、トークンごとに8個を選択します。疎な活性化によって計算量は減りますが、使われていないエキスパートもメモリを占有します。密な23Bモデルと同等の速度になるとは限りません。性能はハードウェア、GPU間通信、推論提供の設定に左右されます。

| チェックポイント | 重みの保存容量 | デプロイの目安 | |---|---:|---| | BF16 | 約1 TB | 公開されているvLLMの例ではH200 GPUを16基使用 | | FP8 | BF16より小さい | 公開されているSGLangの例ではH200 GPUを8基使用 | | NVFP4 | 約280 GB | ガイドではB200 GPUを4基推奨 |

B200 GPUを2基使うとメモリは360 GBとなり、NVFP4の重みを収容できますが、実行時のオーバーヘッド、コンテキスト、同時リクエストに使える余裕は少なくなります。4基なら720 GBです。NVFP4のネイティブ実行には対応するBlackwellハードウェアが必要です。H200などのHopperハードウェアでは、対応するFP8構成を使ってください。

ホスト型APIで試す#

リリース情報では、Hugging Face Inference Providers上のBaseten、Fireworks、Togetherを通じてBeamを利用できるとされています。セルフホスティングの必要性がまだ明確でなければ、ホスト型サービスが最も手軽な出発点です。テスト前に、各プロバイダーの現在の提供状況、料金、コンテキスト上限、対応機能を確認しましょう。

リポジトリの修正、文書からの情報抽出、成功条件を明示した一連のツール操作など、実務に基づく小規模な評価を作成してください。デフォルトの推論設定であるmediumとhighを比較し、タスクの完了状況、出力の妥当性、レイテンシ、トークン使用量を記録します。

セルフホスティングでは、使用するチェックポイントとGPUに合った、公開済みのvLLMまたはSGLangのレシピから始めましょう。どちらもDFlash2による投機的デコーディングに対応しており、小型モデルが提案したトークンをBeamが検証します。スループットが向上すると決めつけず、実際のワークロードで効果を測定してください。

長いコンテキストは必要に応じて使う#

Beamはハイブリッドアテンションにより1,048,576トークンに対応しています。52層のうち43層は512トークンのスライディングウィンドウを保持し、9層はシーケンス全体を参照します。

これにより、KVキャッシュの増加を大幅に抑えます。リリース情報では、最大長のシーケンス1件に必要なBF16 KVキャッシュを約36 GiBと見積もっています。全層でグローバルアテンションを使う場合は208 GiBです。これらはTransformersの動的キャッシュの数値で、重みやその他の実行時メモリは含みません。

コンテキストウィンドウが大きくても、あらゆる入力から確実に情報を取り出せるとは限りません。実際に必要な長さで、Beamが適切な根拠を見つけ、指示に従い、有効な出力を生成できるかを試してください。コンテキストを増やすのは、追加コストに見合うほどタスクの完了状況が改善する場合に限りましょう。

失敗を測定してからカスタマイズする#

Reflectionは、BF16でSWE-bench Verifiedが81.6%、Terminal Bench v2.1が80.1%だったと報告しています。これらはベンダーによる結果であり、独立した検証ではありません。リリース時の5件の非公式なタスク評価も、幅広い信頼性を示すには少なすぎます。

追加学習向けに公開されているTRLのレシピは、全パラメータを更新するのではなくLoRAアダプターを使用します。参照構成はB300 GPUを8基搭載した1ノードに収まります。指定言語に従うかを調べた実験では、学習に使わなかった16件のプロンプトでの成功数が、学習前の3件から学習後は16件に改善しましたが、推論の正しさは測定していません。

全パラメータを対象とする強化学習には、はるかに多くのハードウェアが必要です。Milesの参照構成の一例では、H200 GPUを96基使用しています。学習を始める前に、プロンプト、ツールスキーマ、パーサーの組み込みでは解消できない、繰り返し発生する失敗を特定してください。ファインチューニングには測定可能な目標が必要です。

次のステップ#

代表的な20件のタスクをホスト型Beamの推論設定mediumとhighで実行し、成功率、レイテンシ、コストを記録してからデプロイ構成を選びましょう。

出典: https://huggingface.co/blog/reflection-beam

目次