米Reflection AIは2026年10月16日、同社初のオープンウェイトAIモデル「Beam」の重みをApache License 2.0で公開した。10月5日の発表では同月中の公開を予告していたが、今回、数値精度の異なる3種類のモデルに加え、推論を高速化する補助モデルもダウンロードできるようになった。これにより、企業や開発者は自社の計算設備でモデルを動かし、性能や運用コストを検証できるようになった。

Beamは総パラメータ数5,013億のMixture of Experts（MoE）モデルで、各トークンの処理では234億パラメータが稼働する。主にプログラミングや複数の工程を伴うエージェント作業を想定しており、特徴は答えに到達するまでに生成するトークン数を抑えていることだ。Reflectionは、推論の効率化によって計算コストを削減できると主張しているが、実際に企業の費用削減につながるかは、モデルの性能と運用条件の両方を検証する必要がある。

AD

「短い推論」を促す強化学習の仕組み

ReflectionはBeamの強化学習において、課題を正しく解決したことへの報酬に加え、不要なトークンの生成を抑える仕組みを導入した。具体的には、学習時の報酬に対して、生成するトークン数に応じた調整可能なペナルティを設けている。10月5日に公開した技術解説によると、強化学習の初期段階では、回答までに必要なトークン数が減少すると同時に、課題の解決能力も向上したという。

ただし、学習が進んで複雑なエージェント作業をこなせるようになると、生成するトークン数は再び増加した。より多くの推論を行うことが、難しい課題の解決に役立つ段階もあったためだ。つまり、Reflectionが目指しているのは、あらゆる問題で推論を短くすることではなく、正しい答えを得るために必要な計算へ資源を集中させることにある。同社によると、この強化学習には10,500基のNVIDIA GB300 GPUを使用し、4週間で1億回を超える試行を行ったという。

推論に費やす計算量は、モデルの利用時にも調整できる。公式APIの説明によると、推論設定は「low」から「max」までの5段階が用意されている。ただし、Beamは回答前に必ず推論を行う設計のため、推論を完全に無効化することはできない。応答の速さを重視する簡単な作業と、時間をかけてでも回答の品質を高めたい複雑な作業で、設定を使い分ける仕組みとなっている。

「推論計算量3〜4分の1」は何を比較した数値なのか

Reflectionは、BeamがGLM-5.2に匹敵する難しい推論課題の成績を、3〜4分の1の推論計算量で達成できると主張している。ただし、この数値を解釈する際には、何を計算量として数えているのかに注意が必要だ。公式の比較図とその説明では、測定対象が生成処理に限定されていることが明らかにされている。

計算量の概算には、次の式が使われている。

生成時の計算量 ≒ 2 × 稼働パラメータ数 × 1試行当たりの平均生成トークン数

生成トークン数には、途中の推論と最終回答の両方が含まれる。また、MoEモデルでは総パラメータ数ではなく、実際の処理で稼働するパラメータ数を使用している。一方、入力された文章を読み込む際の計算量や、文脈が長くなるほど負荷が増える注意機構の処理、モデルを配信するためのシステム負荷は含まれていない。したがって、これは生成処理の計算量を概算した比較であり、実際のGPU運用コストやAPIの請求額が3〜4分の1になることを意味するものではない。

今回のBeamでは、生成するトークン数を減らす学習に加え、重みの量子化や補助モデルによる推論の高速化も採用されている。ただし、それぞれの技術が削減する計算資源や改善する指標は異なる。主な違いを整理すると、以下のようになる。

最適化手法 主な改善対象 別途検証が必要な点
短い推論を促す強化学習 解答までに生成するトークン数 自社の課題でも正答率や成功率を維持できるか
重みの量子化 モデルの保存容量や実行時の負荷 数値精度を下げた場合の回答品質
補助モデルによる候補生成 トークン生成処理の速度 GPU構成や同時利用数によって効果がどう変わるか

企業が導入効果を判断する際に重要なのは、個々の指標だけでなく、一つの仕事を完了するまでにかかる総費用だ。例えば、過去の作業履歴や大量のファイルを繰り返し読み込むエージェントでは、生成トークンを削減しても、入力処理の負担が大きければ全体の費用削減効果は限られる。また、回答品質が低下して再試行や人間による修正が増えれば、生成処理で節約した分が相殺される可能性もある。短い推論が実務上の利点になるかを判断するには、作業の成功率、所要時間、再試行や修正の負担まで含めて比較する必要がある。

AD

量子化モデルの容量と、実際に動かすためのGPU要件

今回公開されたBeamには、BF16、FP8、NVFP4という3種類の数値精度が用意されている。モデルの重みをより少ないビット数で表現する量子化によって保存容量を減らせる一方、精度を下げることで回答品質に影響が出る可能性もある。Reflectionの公開モデルカードと公式ダウンロード案内によると、各形式の容量と主な評価結果は以下のとおりだ。

項目 BF16 FP8 NVFP4
重みのダウンロード容量 933.81 GiB 468.72 GiB 273 GiB
Terminal Bench v2.1 80.1% 78.9% 78.4%
SWE-bench Verified 81.6% 80.2% 80.7%
HLE（ツールなし） 36.0% 36.0% 34.8%

Reflectionが公表した評価結果では、BF16からNVFP4へ変更すると、Terminal Bench v2.1のスコアは80.1％から78.4％に、HLEのツールなし評価は36.0％から34.8％に低下している。一方、SWE-bench VerifiedではNVFP4がFP8をわずかに上回っており、量子化によってすべての評価項目が一律に悪化するわけではない。評価時の共通設定はtemperatureが0.7、top_pが0.99で、表には今回公開された同一モデルの各精度を比較した数値のみを掲載している。ただし、誤差範囲や反復回数の詳細は示されていないため、小さな得点差が統計的に有意かどうかは判断できない。

容量の削減効果は明確で、NVFP4版のダウンロード容量はBF16版の約3割に抑えられている。しかし、273 GiBという数値はあくまで重みのダウンロード容量であり、モデルを動かすために必要なGPUメモリの総量ではない。BeamはMoE方式によって各トークンの処理で稼働するパラメータを234億に絞っているが、モデル全体の重みを保持する必要があることに変わりはない。そのため、稼働パラメータ数が比較的少ないからといって、小型モデルと同じ設備で運用できるわけではない。

実際にReflectionが公開したSGLangによる導入手順では、NVLinkで接続された4基のNVIDIA B300 GPUを搭載するサーバーが使用されている。この構成ではNVFP4版のBeamと推論高速化用の補助モデルを組み合わせる。また、開発・評価向けの設定では、扱う文脈長が262,144トークン、同時リクエスト数が8件に制限されている。Beam自体は最大100万トークンのコンテキストに対応するとされるが、これは公式手順どおりに起動した場合の設定上限とは異なる。262,144トークンと同時8件という制限も、あくまでこの導入例の設定であり、Beamのすべての構成に共通する上限ではない。

19.3億パラメータの補助モデルで生成速度を最大3倍に

ReflectionはBeam本体に加え、19.3億パラメータの補助モデル「DFlash2」も公開した。DFlash2は、生成されるトークンの候補列を先回りして作成し、Beam本体がまとめて検証する「推測デコード（Speculative Decoding）」に使用する。公開されたモデルカードによると、棄却サンプリングを使ってBeam本体の出力分布を維持する仕組みとなっている。DFlash2は単独で利用するための独立した言語モデルではなく、Beamの生成処理を高速化する補助モデルだ。

この技術は、強化学習によって回答までのトークン数を減らす手法とは異なり、トークンを生成する処理そのものを速めるものだ。Reflectionの公式速度評価では、4基のB300 GPUでNVFP4版Beamを動かし、DFlash2が8トークンずつ候補を生成する設定で、補助モデルを使わない場合の1.72〜3.03倍の生成速度を記録したという。

最も高い3.03倍という結果が得られたのは、数学ベンチマーク「GSM8K」を同時リクエスト数1で処理した場合だ。生成速度は毎秒288トークンから874トークンへ向上した。一方、MT-Benchを同時リクエスト数16で処理した場合の改善幅は1.72倍にとどまった。いずれも、各段階で最も確率の高いトークンを選ぶ生成方式を使い、生成処理の速度を測定した結果である。

したがって、DFlash2による高速化倍率と、強化学習による推論トークン数の削減倍率を単純に掛け合わせて、業務全体の処理が何倍速くなると計算することはできない。推測デコードの効果は、補助モデルが作った候補をBeam本体がどれだけ採用できるかによって変わり、課題の種類や同時利用数にも左右される。さらに、入力の読み込みやツールの実行に時間がかかる作業では、トークン生成だけを高速化しても、作業全体の所要時間が同じ割合で短くなるとは限らない。

AD

Apache 2.0での重み公開と、企業導入に残る課題

Beamの重みがApache License 2.0で公開されたことにより、企業や開発者は自社の環境でモデルを運用し、用途に合わせて追加学習するための選択肢を得た。モデルカードでは、微調整や量子化に加え、蒸留やBeamの出力を利用した別モデルの学習も禁止していないと明記されている。こうしたライセンス条件は、モデルを自社の業務に合わせて改変したい企業にとって重要な利点となる。ただし、Beamの学習には商用契約に基づくデータも使用されているため、重みが公開されたからといって、同じデータを使って学習過程全体を再現できるわけではない。

Reflectionは、Beamの学習にコード開発用のエージェントツール「Mirror CLI」を組み合わせたと説明している。公開時の発表によると、Mirror CLIは接続するモデルやサーバーを切り替えられ、開発者が操作内容を確認しながら利用できる。また、Beam Verifierという検証ツールも用意されており、APIやツール呼び出しが正しく動作するかを調べる検査と、GPQAやAIMEなどを使った性能評価を分けて実行できる。モデルの起動確認にとどまらず、期待する動作や性能を検証するための仕組みも整備されている。

ただし、既存のアプリケーションにBeamを組み込む際には、会話履歴の扱いにも注意が必要だ。公式APIでは複数ターンの会話において、過去の推論内容を会話履歴にそのまま保持することが求められている。このため、最終回答だけを履歴として保存しているシステムでは、単純にモデルを差し替えるだけでなく、推論履歴の保存方法や次のリクエストへの引き渡し方を確認する必要がある。モデルの能力だけでなく、周辺システムとの互換性も導入時の検証項目となる。

追加学習についても、サポート対象として挙げられている機能と、実際に利用できる手順を区別する必要がある。公式のカスタマイズ文書には、LoRAによる微調整や強化学習に対応する基盤が掲載されているが、それぞれの基盤を使った具体的な実行手順は近日公開と記されている。また、自己蒸留についても、10月16日の発表時点では、今後数日以内に手順を公開する予定とされていた。対応予定の機能が紹介されていることと、必要なツールや手順がすべて公開されていることは同じではない。

さらに、Beamは英語を中心に開発されたテキストモデルである点にも留意したい。日本語の社内文書を扱う業務や、日本語での指示に基づくコードレビューなどに導入する場合は、実際の業務データを使って回答品質を検証する必要がある。そのうえで、量子化による精度の違いや推論設定、再試行の回数を含め、仕事を完了するまでの費用を比較することが重要になる。今回の重み公開によって、Reflectionが掲げる「短い推論による効率化」が実際の業務でも有効かどうかを、企業や開発者が自らの設備と評価条件で確かめられるようになった。