Beam vs Beam 1.0：バージョン番号ではないバージョン番号

製品とその前身のように見える2つのモデル名——Beam と Beam 1.0——を検索すれば、存在しない比較が見つかる。先行する Beam を置き換えた Beam 1.0 は存在せず、その背後で待つ Beam 1.1 もなく、読者がまだ実行している可能性のある古いチェックポイントも存在しない。Reflection は2026年10月に1つのオープンウェイトモデルをリリースし、自社の文章ではそれを Beam と呼び、リポジトリとホスト型エンドポイントを識別子 Beam-1.0-501B-A23B の下に登録している。どちらのラベルも、同じ5013億パラメータのスパース混合エキスパートを指している。バージョン番号は配布タグであり、世代ではない。

それは脚注のように聞こえる。しかし脚注ではない。なぜなら、バージョン接尾辞は伝播する部分だからだ。それはモデルIDに入り、ルーター設定に入り、コストダッシュボードに入り、誰かがベンダーの選択肢を比較していて、Beam とラベル付けされた行と Beam 1.0 とラベル付けされた行が2つの選択肢なのか、不正なインポートで重複した1つなのか判別できないスプレッドシートに入り込む。同一性を正しく把握することが比較の内容そのものであり、それは仕様書よりも役に立つことがわかる。つまり、そのものがカタログでどう振る舞うか、そして何かに組み込む前に何を確認すべきかを教えてくれるのだ。

各ラベルが実際どこから来ているのか

この分け方は恣意的ではない。それぞれの形式には由来があり、どちらがどちらかを知ることで、同じモデルが二つの名前で現れているのを見分けられるようになる：

•「Beam」——ベンダーが文章で用いる名称。ローンチ記事のタイトルは「Introducing Beam: Reflectionの501Bオープンウェイトモデル」、10月16日の提供開始記事のタイトルは「Beamが利用可能になりました」で、Hugging Faceのコレクションはbeam-10。これはフレームワークのエコシステムが採用した名称でもある。SGLangのクックブックではベンダーの見出しの下に「Beam 1.0 — New」として掲載されており、これを本番環境で提供しているプロジェクトアカウントも「Beam」と述べている。

• 「Beam-1.0-501B-A23B」 — マシン識別子です。これはReflection自身のOpenAI互換エンドポイント上のモデルIDであり、ビルダーが必要とする3つの事実を同じように表しています。1つのモデル、最初のリリース、総パラメータ数5010億、アクティブ230億。ハイフンは省略できません。これは検索する名前ではなく、貼り付ける文字列です。

• 「Beam 1.0」— その識別子を人間が読める形にしたもので、カタログの一覧、モデルディレクトリのページ、サードパーティの要約に表示される形式です。識別子をドロップダウン用に見栄えよく整えると、これが得られます。

つまり、この2つの検索語は2つのモデルではない。一方はベンダーの言葉であり、もう一方は1つのリポジトリ名をカタログが表記したものだ。

実際に効いてくる結果：名前によるマッチング

その下流にあるものすべて——ルーティングルール、許可リスト、請求エクスポート、評価ハーネス——はその文字列に照合しますが、その文字列は、貼り付ける場所によって安定しません。続いて3つの実践的な落とし穴がありますが、いずれも仮定の話ではありません。

• 「Beam」向けに書かれたルールは「beam-1.0-501b-a23b」に一致せず、識別子向けに書かれたルールは表示名を保存したカタログに一致しません。大文字小文字や句読点はプラットフォームごとに異なり、それらをあなたに代わって整合してくれるものは何もありません。

• 表示名でグループ化するコストダッシュボードでは、プロバイダーが表示方法を変更した瞬間に、1つのモデルが2つの明細行として表示され、合計が請求書の金額と一致しなくなります。

• 両方の用語を検索して作成した比較スプレッドシートは、そのモデルを二重計上することになります。これはまさに、この記事が防ぐために存在する失敗です。Beam の行と Beam 1.0 の行があれば、モデルは 1 つなのに 2 行あることになります。

修正は地味だ。識別子を固定し、表示名はラベルとして扱い、価格やベンチマークの比較は、ドロップダウンに表示されていた内容ではなく識別子を基準にする。これは料金の問いについても同じことが言える。Beam 1.0 には、エンドポイントにも発表にも、100万トークンあたりの料金レートが一切公開されていない。そのため、どちらの行にもまだ入れる数字がない。

本当に実際の違いがあるバージョン

このリリースには確かな違いがいくつもあり、そのどれもがモデル名に宿っているわけではない。それらはあなたが手に取る成果物の中にあり、「Beam vs Beam 1.0」という問いが本当に指し示しているのはこの点だ：

• BF16 vs FP8 vs NVFP4 — 188個のsafetensorsシャードにまたがる933.81 GiB、E4M3で468.72 GiB、またはパック済み4ビットビルドで273 GiB。3つすべてで合計501.3B、アクティブ23.4Bは同じ。異なるのは、それぞれが要求するハードウェアの下限で、16基のGPUからNVLink接続のB300 4基にまで下がる。

• ベースモデルとドラフター — DFlash2 は、独自のリポジトリとして公開された、19.3億パラメータの独立した投機的デコーディングモデルであり、Beam の変種ではありません。それなしのデプロイは「アップデートなしの Beam 1.0」ではなく、同じモデルを異なる方法でデコードしたものです。

• ホスト型とダウンロード可能型 — 1 つの識別子、2 つの提供経路: Apache 2.0 ライセンス下のチェックポイントと、必須の推論を備え、エフォートは low から max まで（デフォルトは max）、組織全体の制限がすべてのキーで共有される OpenAI 互換エンドポイント。

2つのチームが「自分たちが動かしているのはどのBeam 1.0なのか」で意見が食い違う場合、その食い違いはほとんどの場合、バージョン番号ではなく、これら3つの軸のいずれかに関するものです。

正しい日付でベンダーの数値を読む

ラベル間で変わるものはもう一つあり、それは命名上の産物というより、実際の混乱の原因になっている。Reflectionはベンチマーク表を一度ならず公開しており、ページのバージョン間で数値が動いている。10月5日の発表ではある数値セットが示され、同じ投稿の注記には10月8日の更新が記録されており、現時点のモデルカードは現在の数値を反映している。差異は小さく、主に3桁目の有効数字にある——SWE Bench Pro v2-Hardのある構成は、以前の表では77.2、現在のカードでは78.6と表示されている——しかし、その差は、「ベンダーの数値」を引用する2つの記事が、どちらもそれぞれの日付時点では正確でありながら食い違うことがあり得るほどには大きい。

変わっていないのは、結果の形だ。以下の数値はすべてベンダー報告によるもので、私たちによる再現はされていない。temperature 0.7 と top_p 0.99 で測定されており、3 つの精度がすべて記載されている。それらの間の差が話の一部を成しているからだ：

• SWE Bench Verified — 81.6 BF16、80.2 FP8、80.7 NVFP4。看板となるコーディング指標であり、精度がほとんど影響を与えない唯一のものです。

• Terminal Bench v2.1 — 80.1 BF16、78.9 FP8、78.4 NVFP4。エージェント型ターミナル作業では、FP8ビルドが約1.5ポイントを犠牲にしている。

• AIME 2026 — 97.7 BF16、98.0 FP8、97.5 NVFP4。あらゆる精度で事実上飽和しており、そのため精度間を区別する指標としては弱い。

• GPQA Diamond — 90.6 BF16、90.3 FP8、89.3 NVFP4。NVFP4ビルドが後れを取っていることを示す最も明確な例で、約1.3ポイントの差です。

一貫したパターンは、量子化がコーディングと推論のベンチマークではほとんどコストにならず、知識重視のベンチマークではややコストが増えるというもので、FP8がBF16を明確に上回ることもある——これは、リーダーボード上の根拠ではなくハードウェア上の根拠で精度を選ぶべき理由になる。また、どの表を引用したかを書き留めておくべき理由でもある。"Beam" とラベル付けされた行と "Beam 1.0" とラベル付けされた行は、どちらも間違いであることなく、本当に異なる数値を保持しうる。そして、両者を区別するのはバージョン接尾辞ではない。日付なのだ。

それらのどちらかを選ぶ場合に、これが意味するもの

Beam と Beam 1.0 の間で選ぶべき決定はありません。モデルは 1 つだけだからです。実際に目の前にある決定には 3 つの部分があり、それぞれに答えがあります：

• 自分のハードウェア上でオープンなチェックポイントが必要なら — 選択肢は1つ、精度は3つ、そのどれを選ぶかはハードウェアの問題です。NVFP4ならB300を4台、FP8ならH200を8台、BF16ならデバイスを16台。デバイス数は256エキスパートを割り切れる必要があります。

• ホスト型エンドポイントが必要な場合——ファーストパーティAPIだけが文書化された契約を備えた唯一の選択肢であり、現時点では公開価格が存在しないため、コストに基づく調達比較はまだ完了できません。

• すでに利用しているモデルの隣でそれを必要とする場合 — Beam 1.0 は当社のルートの一つではないため、お客様に提供することはできず、ここに記載されている内容は当社からの可用性に関する主張として読まれるべきものではありません。当社にできるのは、その周辺の意思決定を低コストに保つことです。OrcaRouter は、1つの OpenAI 互換キーで200以上のモデルを利用でき、プロバイダーの定価をそのまま適用して上乗せは一切なく、プロバイダー間の自動フェイルオーバーを備えていますそのため、Beam 1.0 のパイロットは本番トラフィックを置き換えるのではなく、それと並んで稼働し、フォールバック経路は移行ではなくルーティングルールになります。

フォールバック先として最も可能性が高いモデルは、当社自身のカタログと各モデルの公開料金表に基づくと、次のとおりです：

• GLM-5.2 — 入力100万トークンあたり$1.40、出力100万トークンあたり$4.40、コンテキストウィンドウは1,000,000トークン。 Reflectionが自身の効率性の主張を比較する基準となるモデル。

• Kimi K3 — 入力100万トークンあたり$3.00、キャッシュ$0.30、出力$15.00、1,048,576トークンのウィンドウ。Reflectionのローンチ投稿は、K3が生の能力で依然として先行していることを認めている。

• Qwen3.8-Max — 1,000,000トークンのウィンドウで、入力100万トークンあたり$2.00、出力$6.00。Blackwellのキャパシティを購入する代わりとなる独自のフラッグシップ。

Beam 2.0の代わりに何を観るべきか

この比較を本当に意味のあるものにするには3つの要素が必要だが、そのどれも新しいバージョン番号とは関係ない。

最初は料金表です。Reflection がエンドポイント上で100万トークンあたりの価格を公表するまで、ホスト型とセルフホスト型の比較は、資本の数値を何もないものと比べているにすぎず、どれだけ命名規則を徹底してもそれは解決しません。

2つ目は独立した測定です。Artificial AnalysisはこのモデルをIntelligence Index 30として掲載していますが、速度の数値も価格も示しておらず、公開されているAPIも記録していません——ホストされたサーフェスは、こうしたものを測定する組織にはまだ見えていません。唯一の独立した効率データポイントである、Intelligence Index全体で生成された7900万出力トークン（中央値は1億3000万）は、その背後のスループットを確認することなく、ベンダーの「推論トークンがより少ない」という主張を裏付けています。

第三の点は、そのラベルがいつか乖離するかどうかだ。別のチェックポイントである「Beam 2.0」なら、バージョン接尾辞にようやく意味が生まれるし、それが現実のものになった日には、このようなクエリは命名の衛生に関するものではなくなり、2つのモデル間の違いに関するものになる。今日では、それは前者の種類の問いだ。Beam を Beam 1.0 と比較している人は、モデルをそれ自身のリポジトリ名と比較していることになる — そして、その比較から得られる有用な出力は、設定のキーを Beam-1.0-501B-A23B に合わせ、両方の綴りを探すのをやめるようにという注意書きだ。

そうした話は決して仮定ではない。このようなリリースの背景にある、記録に残されたAIの障害やエージェントのインシデントはOrcaRouter AIインシデントアーカイブに集められており、各項目には独自の情報源、深刻度、信頼度グレード、係争中フラグが付されています。