NVIDIAが出資する米Reflectionは10月5日、コード作成やツール操作に向けたAIモデル「Beam」を発表した。全体では5010億パラメータを持ち、1トークンを処理する際には230億パラメータを使う設計で、10,500基のGB300 GPUを使った4週間の強化学習を行ったという。

同社は、競合するGLM 5.2に近い推論能力を、より少ない計算量で実現できると説明しており、モデルの重みは10月中に公開する予定だ。

大規模な学習投資を、実運用で使いやすいモデルへつなげられるのか。判断するには、どのような学習基盤を使ったのかに加え、演算量、メモリ使用量、利用時の上限を分けて見る必要がある。

AD

4週間続けたのは、強化学習の大規模な試行

Beamの事前学習には23兆8000億トークンが使われた。Reflectionによると、ウェブやライセンスを取得したデータなどから学ぶ事前学習を、6144基のGB300 NVL72 GPUを使って4週間未満で終えた。

その後、長い文書や複雑な課題を扱う中間学習を行い、さらに大規模な強化学習へ進んでいる。公式発表にある「10,500基で4週間」という数字は、この強化学習の工程を指す。モデルの開発全体が4週間で終わったわけではない。

事前学習がコードや技術文書などを読み、幅広い知識を身につける工程だとすれば、強化学習は実際に課題へ取り組み、その結果をもとに解き方を鍛える工程である。

たとえばソフトウェアの不具合を修正する場合、モデルはファイルを調べ、コードを書き換え、テスト結果を見てさらに修正する。回答文がもっともらしいかだけでなく、実際に課題を完了できたかどうかが学習材料になる。

Reflectionが示した規模は、何を数えている数字なのかを分けて見ると理解しやすい。

公表した数字 数えている対象
約100万の課題環境 プログラミングや科学技術などの課題と、その実行条件
1億回超の試行 モデルが課題に取り組んだ一連の推論や操作
約13億のサンドボックス 学習や採点に使った、処理を隔離して動かす実行環境
最大17万の同時サンドボックス ある時点で並行して動かせた実行環境

出典：ReflectionのBeam発表。課題環境、試行、サンドボックスはそれぞれ異なる単位で集計されている。

約13億を4週間、つまり28日で割ると、1日当たり約4640万となる。

ただし、これは公表値から単純計算した期間平均であり、日ごとの実測値ではない。また、13億種類の問題を作ったという意味でも、13億個の実行環境を同時に動かしたという意味でもない。

試行と採点でサンドボックスをどのように使い分けたのか、その詳しい内訳までは公表されていない。

課題の数以上に重要なのが、何を学ばせるかである。

約100万の課題環境は主に合成データを使って作り、外部業者から得たデータや公開資料も組み合わせたという。

モデルがほぼ確実に解ける課題や、どのように取り組んでも解けない課題は除外する。指示が曖昧な課題や、採点の抜け道を使えば正解したように見せかけられる課題も取り除いた。

同社は、課題の品質を下げると能力の伸びが止まり、学習にも問題が生じたと説明している。

大量のGPUを用意しても、適切な難度の課題と正しい採点がそろわなければ、投入した計算資源は狙った能力の向上につながらない。

Beamの学習規模は、課題を作り、試し、選別し直す工程と合わせて見る必要がある。

長い試行の終了を待たずに学習を進める

強化学習中には、平均11万件の試行が同時に進んでいたという。

一部の長い試行が終わるまで全体を待つ仕組みでは、その間にGPUや学習処理が待機する時間が増える。

そこでReflectionは、モデルが課題へ取り組む処理と、その結果から重みを更新する処理を非同期で動かした。ツール実行や採点についても、すべての処理が互いの完了を待つ構造から切り離している。

ただし、待ち時間を減らすと別の問題が生じる。

あるモデルが試行を始めてから結果を返すまでの間に、学習側のモデルは何度も更新されている可能性がある。長い試行の途中で、生成に使われる重みのバージョンが変わる場合もある。

古いモデルが出した行動を、現在のモデルが出した行動と同じように学習へ使えば、学習が不安定になる可能性がある。

Beamの学習基盤では、生成した各トークンに、その時点で使ったモデルのバージョンを記録する。

生成時と学習時のモデルのずれを、学習アルゴリズム側で扱うためだ。

同社は、約1日、重み107バージョン分の遅れがある経験を学習に取り込んでも、数値的に安定していたと報告している。

このずれを扱う新しいアルゴリズムの詳細は、今後公開される技術報告で確認すべき点になる。

更新した重みを、多数の推論用モデルへ届ける仕組みも見直した。

ラック間の転送にはRoCE、ラック内ではNVLinkを使い、まず階層ごとに配布してから、近くにあるモデルへ共有する。

この方法により、各モデルが個別に重みを取得する場合と比べて、ラック間の通信量を75％減らし、全体への反映を2.2倍高速化したという。

新しい重みが推論側へ届くまでの中央値は約12秒だった。

大規模な実験環境を止めずに運転し続けるための工夫もある。

サンドボックスの90％は10秒未満で準備でき、学習中に推論系で71件の障害が起きても、学習ジョブ自体は停止しなかった。

推論に使う処理能力は、中央値8分で回復したとしている。

さらに、課題への正解が採点の抜け道を使ったものではないかを、独立した判定器で再確認する仕組みも設けた。

MoEそのものにも、学習を安定させる工夫が加えられている。

MoEは、複数の専門処理の中から、トークンごとに使う部分を選ぶ方式である。選択が一部に偏ると、学習負荷や処理負荷も偏ってしまう。

ReflectionはDeepSeek-V3の技術報告で使われた、補助損失を使わない負荷分散を土台にした。

そのうえで、学習終盤には専門処理の割り当てを補正する仕組みを弱める工夫も加えている。

さらに、層が深くなっても内部の値が過度に大きくならないよう調整し、小さな更新を加える計算にはFP32を使って丸め誤差を抑えたという。

既存のMoE技術を取り入れたモデル設計と、大量の試行を止めずに学習へ流し続ける基盤を組み合わせた形だ。

GPUの台数だけでは能力は決まらない。試行を生成し、採点し、更新した重みをすばやく配る仕組みが機能して初めて、大規模な計算資源を学習へ生かせる。

AD

「3〜4倍効率的」は、何を比べた数字なのか

Reflectionは、高度な推論を評価する指標でGLM 5.2に近い成績を出しながら、推論時の計算量をおよそ3分の1〜4分の1に抑えたと説明している。

ただし、この比較は実際の利用料金や、GPU上での処理時間を測ったものではない。

発表資料では、回答生成に必要な計算量を次の式で推定している。

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

FLOPsは、計算に必要な浮動小数点演算の回数を表す。

ここでは積和演算を2回として数え、生成トークンには回答前の推論と最終回答の両方を含めている。

MoEでは、モデル全体のパラメータ数ではなく、そのトークンの処理で実際に使うパラメータ数を掛ける。

この式を見ると、同程度の課題を解けるのであれば、1トークンで使うパラメータ数を減らすことと、不要な生成を減らすことの両方が計算量の削減につながる。

Beamは生成の長さに応じたペナルティーを使い、課題に成功すれば報酬を与えながら、余分なトークンを減らすよう学習した。

同社によると、学習の初期には生成が短くなる一方で成績が上がり、その後は必要に応じて長い推論を使うことで、さらに能力が伸びた。

単純に短い回答だけを目指したのではなく、難しい問題では長く考えられる余地を残した設計だ。

一方、この計算量の推定には、入力を最初に処理する計算が含まれていない。

文脈の長さに応じて増える注意機構の計算や、モデルをサービスとして動かすための各種処理も除外されている。

長いコードを読み込ませる作業と、短い質問に対して長い回答を生成する作業とでは、除外された部分の比重が異なる。

そのため、「計算量が3〜4分の1」という数字を、そのまま「料金も3〜4分の1」「処理時間も3〜4分の1」と読み替えることはできない。

能力の比較も、評価項目によって差がある。

Reflectionが公表した表から、コード作業に関係する指標を抜き出すと次のようになる。

評価 Beam GLM 5.2 Qwen 3.8-Max
DeepSWE v1.1 44.4 44.0 51.0
SWE Bench Pro v1 65.5 62.1 67.7
Terminal Bench v2.1 80.1 81.0 86.6

出典：Reflectionの発表表。競合モデルの値にはArtificial AnalysisとDataCurveの評価を使用。高いほど良い。各モデルでハードウェアや実行条件が統一されているかは、この表だけでは確認できない。

GLM 5.2とは評価によって上回ったり下回ったりしており、Qwen 3.8-Maxにはこの3項目すべてで及んでいない。

Beamが狙っているのは、最高得点だけを競うことよりも、一定の能力をより少ない生成計算で得ることにある。

ただし、その利点が実際の仕事でどこまで現れるかは、モデルの重みが公開された後の検証が重要になる。

230億だけ使っても、5010億の重みは保存する必要がある

1トークン当たり230億という稼働パラメータ数は、モデル全体を保存するために必要な容量を表す数字ではない。

MoEでは、トークンごとに使う専門処理が変わるため、その瞬間に使わない重みも含めてモデル全体を保存しておく必要がある。

Hugging FaceのMoE解説でも、すべてのパラメータを毎回使う同規模のモデルと比べて演算量を減らせる一方、全体の重みを保持するためのメモリは大きくなることが説明されている。

Reflectionが10月5日に公表した全パラメータ数を使えば、重みだけに必要な容量を単純計算できる。

5010億パラメータすべてを保存すると仮定した場合、8ビットなら約501GB、4ビットでも約250.5GBとなる。

計算は「5010億 × 1パラメータ当たりのビット数 ÷ 8」でバイト数を求め、10億で割ってGBへ換算した。

ここでは、すべての重みを一律に8ビットまたは4ビットで保存すると仮定している。

量子化に必要な追加情報、処理済みの文脈を保持するKVキャッシュ、実行中の作業領域などは含まれていない。

Beamを実際に動かす際の必要メモリを測った数字でもなく、公開予定の重みがどの形式になるのかを示すものでもない。

したがって、「稼働230億パラメータ」という数字だけを見て、小型モデルと同程度のメモリで動かせると判断することはできない。

全5010億パラメータの重みをどこへ置き、選ばれた専門処理へデータをどのように運ぶかも、配備時の重要な条件になる。

演算量を減らせる設計であっても、メモリや通信の負担まで同じ割合で減るわけではない。

重みが公開される意味は、こうした条件を自社の設備やデータに合わせて実測できるようになる点にある。

計算量のグラフだけでは分からない応答時間や、同時に処理できる仕事の数を、実際の用途に合わせて測れるようになる。

AD

公開後の焦点は、自分の仕事をいくらで終えられるか

開発者向けに案内されている「Beam-501B-A23B」のAPIには、256Kトークンのコンテキスト枠と、128Kトークンの最大出力枠が設定されている。

モデルの仕様では、コンテキスト枠は入力と生成される出力を合わせた上限を意味する。

発表資料にある「中間学習で100万トークンまで拡張した」という説明とは、示している段階が異なる。

学習時に扱った長さを、そのまま現在のAPIで入力できる長さだと考えると、大規模なコードベースを読み込ませる設計を誤る可能性がある。

生成についても、最終回答だけが出力枠を消費するわけではない。

推論の仕様によると、推論量はlowからmaxまで5段階あり、標準設定はmediumとなっている。

推論は常に有効で、推論中に使ったトークンも出力上限に含まれる。

上限が不足すると、推論の途中で使い切ってしまい、最終回答が空になる場合もある。

長く考えさせれば、その分だけ難しい仕事を確実に解けるとは限らない。推論量を増やせば、待ち時間と生成トークンも増える。

実運用では、課題の成功率と合わせて、推論量を変えた場合の所要時間も測る必要がある。

短い回答1回の料金だけを比べても、ツールを何度も呼び出しながら仕事を完了するまでの費用は分かりにくい。

提供は待機リストから段階的に開放されるベータで、発表時点では限定プレビューとなっている。

Reflectionは10月中にApache 2.0ライセンスで重みを公開し、技術報告や開発関連の資料も公開する予定だ。

安全性の最終検証も続いており、安全評価の結果は技術報告で公表するとしている。

同社は、能力向上を目的とする学習と、安全性や振る舞いを整える学習を分けて行い、複数の教師モデルから蒸留して統合したと説明している。

その設計が、実際のツール操作や長時間のタスクでどのように振る舞うのかも、今後の検証項目になる。

Reflectionは以前から、事前学習と強化学習の基盤を自社で構築し、オープンモデルを育てる方針を示してきた。

Beamはその方針を具体的なモデルとして形にしたものであり、推論時の計算量を抑えるために、学習段階で大規模な計算資源を先に投入する構造が見える。

重みの公開後に重要になるのは、自社で使うコードやツールを用意し、求める成功率で課題を完了するまでの時間と費用を測れるかどうかだ。

そこまで確認できれば、Beamは企業がAIを自社設備で動かし、計算量と作業品質のバランスを自分たちで調整するための選択肢になり得る。