NV-Reason-CT 対 Gemini 3.1 Pro：最も広い入力サーフェス、それでもCTリーダーではない

94パーセント。これは、Gemini 3.1 Proを提供するある1つのルートについて現在記録されているエラー率——93.93%であり、そこには初回トークンまでの中央値が10秒の上限と読める値や、毎秒978トークンというスループットの数値も並んでいる。これをモデルについての記述として読めば、まったく誤った結論を導くことになる。負荷がかかったプレビュー階層についての記述として読めば、それはこのページで最も有用な情報になる。なぜなら、本番トラフィック向けにプロビジョニングされていないルートに依存したときに、臨床パイプラインが実際に経験するのはまさにこれだからだ。

この比較の反対側にあるモデルには、そのような問題も、そのような測定値も存在しない。NV-Reason-CTは、NVIDIAの46.9億パラメータのネイティブ3D CT推論モデルで、OpenMDW-1.1の下でダウンロード可能だが、スループットの数値は一切公表されておらず、どこにもホスティングされていない。つまり、この対決の一方は、業界で最も広い入力サーフェスを提供する代わりに、自分で設計して対応しなければならない可用性プロファイルを伴い、もう一方は、狭い単一の能力を提供する代わりに、自分で測定しなければならないレイテンシを伴う。どちらも初日から信頼できる監視ダッシュボードなど備わっておらず、しかもその理由は正反対だ。

2つのモデル、2つの「マルチモーダル」の定義

その単語はどちらの製品説明でも大きな働きをしているが、その働きのほとんどは共通していない。

• 受け付ける入力 — Gemini 3.1 Pro はテキスト、画像、音声、動画、ファイルを入力として受け付けます。一方、NV-Reason-CT はハンスフィールド単位の単一チャンネル NIfTI ボリュームのみを受け付け、それ以外は受け付けません

• 「3D」とは何を意味するのか — NV-Reason-CT は、384 ミリメートルの立方体にわたって 2 mm 等方にリサンプリングし、それを 24 x 24 x 24 グリッド用の 8 x 8 x 8 パッチに切り分ける。Gemini 3.1 Pro の動画入力は、タイムラインを伴う二次元フレームのシーケンスである。

• コンテキスト — Gemini 3.1 Pro では入力1,048,576トークン、出力65,536トークン。NV-Reason-CT では1ボリュームが13,824ビジュアルトークンで、ダウンサンプリングもマージ層もなく、その周囲にチャットウィンドウも存在しない

• リリース — 2026年2月19日、Gemini 3.1 Pro向け、プレビュースラッグ上；NV-Reason-CT向けの未告知の研究ドロップで、リポジトリの活動日は2026年9月2日から25日

• 価格 — 100万トークンあたり$2と$12（200,000トークンまで）、その後は$4と$18、キャッシュ読み取りは$0.20、キャッシュ書き込みは$0.375。レートカードのないセルフホスト型ウェイトと比較

• 機能 — Gemini 3.1 Pro は視覚、音声、ツール使用、JSON 出力、推論に対応。NV-Reason-CT は解剖学的領域ごとに構造化された所見を出力し、ツールは使用しません

• ライセンスとステータス — ホスト型のプレビューAPI。OpenMDW-1.1の重みを使用しており、そのモデルカードには研究・教育目的のみと記載され、医療機器ではないと明記されています

動画入力とボリュメトリックCT入力は、遠くから見れば隣り合って見えるが、間近で見ればこれ以上なくかけ離れている。動画は時間に沿ったフレームの連なりだ。CT検査は、3つの空間軸、ミリメートル単位の物理スケール、校正済みの密度単位を備えた単一の静的ボリュームであり、測定対象となるのは、大きさが重要になる構造の密度である。Gemini 3.1 Proは手術の記録映像を視聴し、何が起きたかを説明する。結節を測定することはない。それはGoogleが対処しそこねた限界ではない。汎用モデルでは誰も解決していない、別の問題なのだ。

2つのベンチマーク記録が対象とするものと、除外するもの

Gemini 3.1 Proには独自の記録があり、それが測定する軸においては優れた記録です。

• GPQA Diamond — 94.1、この一連の記事全体の中で最高の数値

• Humanity's Last Exam — 47、長文コンテキスト想起スコア82で、この比較でも再び最高

• IFBench と SciCode — 77.14 と 58.7

• τ²-Bench — 95.61、tau_banking が 21.44、Terminal-Bench Hard が 53.79

• Artificial Analysis インテリジェンス／コーディング — 29.7 および 68.8

• 実測レイテンシ — 最初のトークンまでの中央値は10秒で、これは真の中央値ではなく上限と考えられる。毎秒978トークン、エラー率93.93%

その形に注目してほしい。比較の一番上に知識と長コンテキストのプロファイル、中ほど下に知能指数、そして使い物にならない可用性測定がある。3つとも同じルート上の同じモデルを説明している。GPQA Diamondが高いということは、非常に多くのことを知っていることを意味する。29.7という総合スコアは、すべてにおいて首位というわけではないことを意味する。93.93%のエラー率は、この特定の経路では、あなたのリクエストの大半が完了しないことを意味しており、それはほぼ確実に、重みの性質ではなくプレビューエンドポイントに関する容量とプロビジョニング上の事実だ。外部からどちらであるかを証明することはできない。言えるのは、それら3つの数値のどれも打ち間違いではないということ、そして最初の1つだけを読むアーキテクチャはひどい一週間を過ごすことになるということだ。

NV-Reason-CTの記録はより限定的で、異なる注意点を伴う。CT-RATEにおけるその0.614 F1と0.871 AUROCは、固定された一律のしきい値、直接的なyes/noプロンプト、分類ヘッドやタスク固有の適応なしで、18個のラベルにわたって得られたものであり、NVIDIA自身の論文によるNVIDIA自身の数値である。その背後にある比較対象——VoxelFMが0.581、Pillar-0が0.544、ClinFusion-8Bが0.442、CT-CLIPが0.398、Merlinが0.358、MedGemma 1.5が0.303——には、画像モデルしか含まれていない。汎用マルチモーダルモデルは一つも登場しない。つまり、「Gemini 3.1 ProはCT-RATEでどうなるのか」という問いは、答えられるどころか、まだ問われてもいない。

プレビュー層の問題を正確に述べると

これは、CTとは全く関係がなく、臨床業務の運営そのものに関わる比較の部分です。

93.93%のエラー率は、微妙な劣化ではない。それは、圧倒的多数の呼び出しが失敗するルートだ。自然な反応は、そのモデルは使えないと宣言することだが、その反応は2つの理由で間違っている。第一に、プレビューエンドポイントで測定されたエラー率は、モデルの能力ではなく、容量、クォータ、地域ルーティングを反映している。Googleのプレビューティアは、本番環境ではなく評価用にプロビジョニングされていることでよく知られており、プレビューにちなんで名付けられたスラッグは、予告なしにスロットリングされ得るスラッグだ。第二に、その測定は、ある瞬間のある経路のスナップショットにすぎない。それは変わるだろう。変わらないのは、教訓だ。プレビュールートへの依存は、他の誰かが下す容量判断への依存である。

緩和策は地味で、まさにそのことが、ルーティングが便利な仕組みではなく一つの専門分野として存在する理由のすべてだ。

• プレビュー用スラッグを本番パスにハードコードしないこと — その機能はインターフェースの背後に置き、デプロイすることなくその背後のモデルを差し替えられるようにする

• 別のプロバイダーまたは別のモデルで再試行してフォールバックする — バッチ抽出ジョブでは、失敗率94%は、その失敗が別の場所にルーティングされれば耐えられるが、そうでなければ致命的である

• エラー率は他から引き継ぐのではなく、自分自身で計測しましょう — 93.93%という数値は当社カタログにおける1つのルートのものであり、お客様の数値はリージョン、ボリューム、ワークロードの特性によって変わります

• 臨床のタイムラインに乗るものには、第二のモデルを常に温めておく — あなたが防ごうとしている故障モードは、悪い回答ではなく、回答が返ってこないことだ

同じ規律は、ルートがまったく存在しない CT 側では、逆方向にも当てはまる。セルフホスト型モデルにはプロバイダのエラー率はない。あるのはハードウェアのエラー率、保守負担、そして購入した GPU の数によって決まる容量の上限だ。障害モードはキューであり、緩和策はフェイルオーバーではなくスケジューリングだ。問題は違っても、ルールは同じである。自分が実際に依存している数値がどれなのかを把握すること。

長いコンテキストが本当に役立つ場合と、そうでない場合

Gemini 3.1 Proの1,048,576トークンのウィンドウと82点という長文脈リコールスコアは紛れもない強みであり、偶然に頼るのではなく意図的に活用する価値がある。

CTプログラムでそれらが効果を発揮するのは、スキャンではない。その周辺のすべてだ。長い手術記録とその関連レポートに対する1回の抽出パスで、文書全体をコンテキストに保持し、フィールド間の整合性を保つ。数百の患者ナラティブを一度に保持し、それら全体からパターンを見つけ出す必要があるコホート要約。スキーマ、100件のサンプルレコード、エラーログのすべてを同じ呼び出し内で参照できる必要がある変換ジョブ。これらは、長いウィンドウが単に便利になるだけでなく、答えを変えるジョブだ。

それが役に立たないのはスキャン自体であり、その理由は、この組み合わせが招く誤りだからこそ、正確に述べておく価値がある。胸部CTをNV-Reason-CTが表現するやり方で表現すると、13,824トークンを要する。Gemini 3.1 Proはそのような検査を70件、ウィンドウ内に余裕をもって収められる。制約は容量ではない。Gemini 3.1 Proの視覚経路は、画像をピクセルスケールを持つ絵として扱うので、そのように提示された検査は、最初のトークンが出力される前にスライス間隔と密度校正を失っている。ボリュームに100万トークンを使っても、依然としてボリュームにはならないのだ。論文自身の比較が、そのコストを具体的に示している。MedGemma 1.5は最大85枚の軸位スライスを入力した場合0.303 F1であるのに対し、ネイティブなボリュームモデルは0.614で、その差はおよそ2倍だ。

私たちがどこに収まるのか、そして私たちが決して言わない一つのこと

Gemini 3.1 ProはOrcaRouterを通じてgoogle/gemini-3.1-pro-previewとして、プロバイダーのリスト料金のままマークアップゼロで提供されています。200以上のモデルをカバーする単一のAPIの中で。現在プレビュー段階にあるモデルにとって、この組み合わせは見た目以上に有用です。マークアップゼロとは、ベンダーの料金変更が古い数値を抱えた中間層に吸収されるのではなく、その日のうちにこちら側へ反映されることを意味します。自動フェイルオーバーとは、障害が発生し始めたルートがバッチ全体を巻き込んで停止させることがないという意味です — ある経路で測定されたエラー率が90%台だったことを踏まえると、これは仮定の話ではありません。そして、個々のリクエストを処理すべきモデルへ送るためのルーティングDSLを使えば、2つの統合を維持することなく、長いコンテキストを扱う処理を一方のモデルに、安価で大量の処理をもう一方のモデルに任せることができます。

NV-Reason-CTは当社のプラットフォーム上にはありません。NVIDIAのモデルも同様です。これは自分でダウンロードして実行する重みであり、正直に言えば、このアーキテクチャの二つの半分はまったく異なる場所に存在します。一方は料金表とプレビュー段階のリスクを伴うAPIの背後に、もう一方はOpenMDW-1.1ライセンスの下であなた自身のハードウェア上にあり、スループットの数値は自分で出す必要があります。

本番環境との接触に耐える決断

長いコンテキストでのテキスト、音声、動画、文書の理解が課題なら、Gemini 3.1 Pro は知識と想起において分野の最高水準にあると独立に測定されており、それが本番パイプラインに乗ることを妨げている唯一のものはルーティングの信頼性です。これはモデルの問題ではなく、解決可能なエンジニアリングの問題です。フェイルオーバーの背後に置き、プレビューのスラッグをハードコードせず、誰のエラー率も——私たちのものも含めて——信用するのではなく、自分自身のエラー率を測定してください。

あなたの問題が胸部または腹部のCTボリュームであるなら、この比較の中でそれに対処できるオープンモデルはちょうど1つだけで、それは100万トークンのウィンドウを持つものではなく、あなたの計画を左右すべき数値はそのF1スコアではありません。それは、誰も公表していない検査あたりのレイテンシです。スループットの数値を誰かに約束する前に、それを測定してください。

この比較は行う価値がある。なぜなら、常に混同される2つのもの——入力の広さと表現の深さ——を切り分けるからだ。Gemini 3.1 Pro はこれまで誰かが出荷した中で最も広い入力面を持ち、このセットでは最も優れた長文コンテキスト想起を備えているが、それでもCT検査をCT検査として読影することはできない。NV-Reason-CT はそれを読影できるが、それ以外は何もできない。パイプラインには両方が必要であり、それらを異なるインフラストラクチャ上に置く必要があり、そして両側の2つの数値のうち、午前3時に自分を呼び出すのはどちらなのかを知る必要がある。