Gemini Decision 1 対 Kev：1回の呼び出しで千の質問を投げるか、再トレーニングできるレシピか

Jared PalmerのKevファミリーは、Modal上のH100時間で学習に約95ドル、評価データ用のAPI呼び出しに約3セントかかり、レシピ全体はリポジトリにあります。Gemini Decision 1は、フロンティアラボが説明しないモデルに費やす金額次第で、その金額で得られるものはリクエストスキーマです。1つのエンドポイント、単一の262,144トークン入力に対する最大1,000件の型付き質問、較正済み確率の返却、出力トークンはゼロ、入力トークン100万あたり0.10ドル。Kevを隣に置くと、比較は実際には2つのモデル間のものではありません。それは、バッチスコアリング用アプライアンスと、分解できる小さな機械との比較です。

どちらのプロジェクトも、相手を採点する基準となる数値を公開していない。まず正直に言うべきはそこだ。GoogleはGemini Decision 1とともにベンチマーク表を公開しなかった。本稿の性能数値はすべてArtificial Analysisによるもので、同社はこのモデルをDecision Index v2.1で66と評価している。Kevはそのボードにまったく載っていない。代わりにKevが公開しているのは、ハーネス、固定されたテストセット、そして自社のエラー率であり、それらは何からも差し引くことはできない。

Gemini Decision 1がKevにはできないこと

能力の差から始めましょう。なぜなら、それはスコアではなくアーキテクチャを決めるものだからです。Gemini Decision 1は、単一のフォワードパスで、1つの共有入力に対して最大1,000個の独立した質問を評価します。質問同士は互いを参照できず、1つを追加または削除しても他の質問は変化しません。また、共有入力の課金は1回だけです。

その最後の条項こそが製品だ。サポートチケットを40のポリシールールに照らしてチェックするのは、1つのリクエスト、チケットの1回の読み取り、40の調整済み回答だ。質問ごとのモデルでは——Kevはそのようなもので、ヘッドが1行で各選択肢を質問に対してスコアリングするという意味で——同じ40のチェックは、バッチ処理するかどうかに関係なく、状態に対する40回のパスになる。Kev自身のサービング数値がコストを具体的に示している。H100上で短い状態に対する6つの質問で18.1ミリ秒、キャッシュ時で12.9ミリ秒、常駐14.3 GB。6つの質問であって、1000ではない。

入力サーフェスも同じように異なります：

• モダリティ — Gemini Decision 1はテキスト、画像、動画、音声、PDFを読み取りますが、Kevはテキストのみです。通話録音やスキャンした帳票は、Kevにとっては前処理が必要な問題であり、Gemini Decision 1にとってはネイティブな入力です。

• コンテキスト — Gemini Decision 1 では入力と質問全体で 262,144 トークン。Kev は最大 65,536 を提供し、各質問につき少なくとも 8,192 を割り当てますが、検証するのは最大 8,192 までで、そのカードにもそう記載されています。

• 回答拒否 — Gemini Decision 1 は 0.01～0.99 の範囲に収まる確率と confidence フィールドを返すため、低信頼度の回答も別途オプションを用意することなく可視化されます。Kev は指定したオプションに対するソフトマックスを返すため、回答拒否とは、指定した任意のオプションと設定したしきい値によって決まります。

• 重み — Gemini Decision 1 には重みなし。Gemini Developer API の v1beta にあるホスト型エンドポイントで、無料枠は毎分 200 リクエスト、1 日あたり 10,000 リクエストです。Kev は Apache-2.0 で、凍結された Qwen3.5 ベースにランク 16 の LoRA アダプターとポインターヘッドを備え、0.8B、4B、9B のサイズで提供されます。

Kevが行う、Gemini Decision 1にはできないこと

{{1}}Kev{{/1}}ではモデルを変更できます。プロンプトを変えるのではなく、独自のラベルで意思決定の振る舞いを再トレーニングできます。しかも、経費精算に載せられる程度の金額で。

この構成は意図的に控えめだ。凍結されたQwen3.5ベース、約3,380万の学習可能パラメータを持つランク16のアダプター、そして各選択肢の終端トークンを質問の最終トークンと照合してスコアを付ける小さなポインタヘッドで成り立っている。ベースは凍結されたままなので、新しい意思決定ドメインを追加する際の追加コストは基盤モデル規模ではなくアダプター規模で済む。1つのベースをメモリに保持し、ドメインごとにアダプターを差し替えられる。これはホスト型エンドポイントでは表現できないデプロイ形態だ。

Kevが自身について公開している内容は、反論できるほど具体的であり、それは本来あるべき以上に珍しい：

• Transfer-v4、ドメイン外ロック済み — 精度 0.838、Brier 0.224、ECE 0.017。

• Breadth-v1、14個のホールドアウトデータセット、3,089問 — 精度0.690、ECE 0.029。

• Documents-v1 — 0.903。Hard-v1 — 0.803。10個の選択肢を持つMMLU-Pro — 0.565。

• 日付演算 — 日単位精度で0.65、著者が最も弱い領域と名指ししており、部分的な修正としてプリプロセッサフラグが提示されているが、再測定は主張されていない。

それらは著者自身の評価ハーネスによる著者自身の測定値であり、カードにはキャリブレーションは単一の分布内温度だと書かれている。そのため分布外ではカバレッジが低下し、選択肢の順序によって回答が反転しうる。これは信頼できる自己評価ではあるが、監査済みの結果ではない。それでも今夜再現を試せる尺度ではあり、このカテゴリのほとんどのベンダー数値についてはそう言えないことを考えれば、それだけでもましだ。

なぜ表の上の2つの数字は決して交わらないのか

Kevの0.838という転移精度をGemini Decision 1の66の横に並べて勝者を宣言したくなる誘惑がある。それに抗え、理由は3つある。

これらの指標はそれぞれ異なるものを測っている。Decision Indexは、回答に付された信頼度に対するBrierペナルティを正確さから差し引き、6つの評価にわたって集計したスコアであり、その45%は非公開データに基づいている。Kevのtransfer-v4の数値は、著者が構築した固定セット上での単純な正確さであり、BrierとECEは主要な数値に組み込まず、その横に併記されている。

タスクの構成は同じではない。インデックスの最大構成要素であるAA-Paperclip（30%）は、文書ごとに15問の全か無かの回答だ。Kevのdocuments-v1テストはその形に近いが、再現はしていない。

そして分母が異なる。指数スコアは棄権が報われる重み付きの複合指標であり、精度の数値は、最も確率が高い選択肢が正解だった質問の割合である。一方の指標でモデルが別のモデルを上回り、もう一方では劣ることがあっても、どちらも間違いではない。

擁護可能な主張は限定的だ。Gemini Decision 1はホスト型意思決定モデルの中でスコア66で中位、18モデル中9位であり、知識コンポーネントでは首位、文書の全か無かの合格率は33%だ。Kevは4Bクラスのアダプターで、作者はドメイン内キャリブレーションが強く、日付演算が弱いと報告している。どちらかが優れていると言う人は外挿しているだけだ。

それぞれを実際に運用するのにかかるコスト

Gemini Decision 1の経済性は計算するのは簡単だが、大量処理では到底受け入れられない。入力トークン100万あたり$0.10でありながら、Artificial Analysisの測定では100万タスクあたり$345——ボード上半分の中で最も高価なモデルであり、コンテキストキャッシュもBatch APIも、Flex推論やPriority推論も備えていない。繰り返し共有される入力は、リクエストのたびに毎回すべてカウントされる。100万件のチケットを毎晩一括処理すれば、ポリシー文書は100万回読み直されることになる。

Kevの経済性は逆の形をしている。GPUの費用を回収してしまえば呼び出しあたりはほぼ無料で、実際のコストはラベルの構築、アダプターの学習、そしてそれらの検証に費やす時間にある。Palmerの約95ドルという数字は学習実行の費用をカバーしているのであって、ラベリングの費用ではない。あなたのルーティングルールが汎用のジャッジのものと異なるなら——そして実際に異なる——そのラベリングコストで買っているのは、ホスト型の意思決定モデルが決して売らないものだ。つまり、あなたのポリシーを近似するのではなく、それをエンコードするスコアラーである。

プロジェクトの採否を価格以上に左右する第三のコストがある。それはイテレーション速度だ。Gemini Decision 1の制限は文書化され固定されているため、挙動の変更はプロンプトの書き直しと評価セットの再実行で済む。Kev'sの場合はアダプターの再トレーニングであり、計算コストは安いがプロセスコストは安くない。単一ドメインで大量処理するチームには再トレーニングは元が取れる。12のドメインを抱えMLエンジニアがいないチームでは、100万タスクあたり345ドルでもホスト型エンドポイントの方がエンジニア工数で優位に立つ。

意思決定を取り巻くパイプラインこそが、実際にあなたが時間を費やす場所であるなら

OrcaRouter はどちらのモデルも取り扱っていません。{{1}}Kev{{/1}} は自分で実行する Apache-2.0 の重みで、{{2}}Gemini Decision 1{{/2}} は Google 自身の API 上にある確率のみのエンドポイントです — どちらもチャット補完の対象ではなく、そうでないふりはしません。当社のカタログにおける意思決定モデルは TypeSafe の typesafe/jev-1.14 で、同じボードで 66.23、ほかすべてと同じキーでスコアリング呼び出しを行いたいチーム向けです。

私たちが作られているパイプラインの半分は、意思決定の上流側です。候補となる回答の生成、ルーブリックの作成、採点される前のチケットの要約。モデルを最も頻繁に切り替えるのがこの判断であり、2社目のベンダー契約が最も高くつくのもここです。そして、200以上のモデルを載せた単一のエンドポイントで動くのもこの部分です。プロバイダーの定価を0%のマークアップでそのまま適用、さらにプロバイダーが劣化した際の自動フェイルオーバー。Kevをホスト型の採点ツールと比較検討しているなら、下書き部分は私たちを通して実行し、採点の判断は可逆なままにしておいてください。そうすれば、今日$95のアダプターについて下す選択が、後々の移行になることはありません。

二つの決定の間での決定

意思決定が「1つの入力と多数のルール」である場合、入力が音声・動画・PDFである場合、1回の課金パスで千件のチェックを行うことがコストモデルを変える場合、そして自分で適合させていないキャリブレーションを信頼して差し支えない場合には、Gemini Decision 1を選んでください。フロンティアラボの入力価格で、バッチ割引なしにブラックボックスを購入していることを受け入れてください。

判断が単一の入力と少数の型付き質問である場合、テキストが 8,192 トークン以内で検証できるほど短い場合、ポリシーが十分に具体的で汎用的なジャッジではうまく近似できない場合、そしてエンドポイントを所有することよりも成果物を所有することのほうが重要である場合は、Kev を選んでください。カードが警告しているキャリブレーション、日付演算、オプション順序への感度について、あなたが責任を負うことになることを受け入れてください。

この比較でやってはいけない唯一のことは、順位表を作ることだ。共通の評価手段も、共有のタスクセットも、第三者がどちらかの数値を再現した結果も存在しない。今週できるのは、自分でラベル付けした200件の項目を両方に通し、合格率と信頼度曲線を比較することだ——次回のリーダーボード改訂よりも多くのことを教えてくれる、午前中で終わる作業である。