NV-Reason-CT vs Gemini 3.1 Pro：最寬廣的輸入面，卻仍不是 CT 判讀器

百分之九十四。這是我們自家目錄目前針對某一條服務Gemini 3.1 Pro的路由所記錄的錯誤率——93.93%，同時首次產生 Token 的中位時間看似十秒上限，吞吐量數字則為每秒 978 個 Token。若把這解讀為關於該模型的陳述，你將得出完全錯誤的結論。若把它解讀為關於滿載下預覽層級的陳述，它就成了頁面上最有用的一項資訊，因為這正是臨床管線在依賴一條尚未為生產流量配置好的路由時，實際會經歷到的情況。

這項比較另一側的模型既沒有這類問題，也沒有這類量測。NV-Reason-CT是 NVIDIA 的 46.9 億參數原生 3D CT 推理器，可依 OpenMDW-1.1 下載，完全沒有公布吞吐量數據，也沒有在任何地方提供託管。因此，這場對決的一方為你提供該領域最廣泛的輸入介面，但其可用性狀況是你必須據以設計的；另一方則只給你一項狹窄的能力，其延遲還得由你自己量測。兩者都沒有在第一天就能信任的監控儀表板，而且原因正好相反。

兩個模型，兩種「多模態」的定義

這個詞在兩段產品描述中都承擔了大量工作，而其中幾乎沒有一處是共通的。

• 接受的輸入 — Gemini 3.1 Pro 可接受文字、圖像、音訊、影片與檔案；NV-Reason-CT 只接受以 Hounsfield 單位表示的單通道 NIfTI 體積資料，其他一概不接受

• 「3D」是什麼意思 — NV-Reason-CT 會重新取樣成 2 mm 等向性、範圍涵蓋 384 毫米的立方體，並將其切成 8 x 8 x 8 的區塊，以形成 24 x 24 x 24 的網格；Gemini 3.1 Pro 的影片輸入是一連串帶有時間軸的二維影格

• 上下文 — Gemini 3.1 Pro 的輸入為 1,048,576 個詞元，輸出為 65,536 個詞元；NV-Reason-CT 的一個體積為 13,824 個視覺詞元，沒有降採樣、沒有合併層，而且周圍沒有對話視窗

• 發布 — 2026 年 2 月 19 日，適用於 Gemini 3.1 Pro，位於預覽 slug；NV-Reason-CT 的未公告研究發布，且儲存庫活動日期為 2026 年 9 月 2 日至 25 日

• 價格 — 每百萬個 token 為 $2 與 $12，最多 200,000 個 token，之後為 $4 與 $18；快取讀取為 $0.20，快取寫入為 $0.375；相較於自託管權重且無價目表

• 功能 — Gemini 3.1 Pro 具備視覺、音訊、工具使用、JSON 輸出與推理能力；NV-Reason-CT 則依解剖區域提供結構化發現，且不使用工具

• 授權與狀態 — 一個託管的預覽 API；以 OpenMDW-1.1 權重運行，其模型卡載明僅限研究與教育用途，並明確聲明其並非醫療器材

影片輸入與體積 CT 輸入從遠處看似乎很相近，但近看卻天差地遠。影片是隨時間變化的影格。CT 檢查則是單一靜態體積，具有三個空間軸、以毫米為單位的物理尺度，以及已校準的密度單位；其中被量測的是某個大小至關重要的結構之密度。Gemini 3.1 Pro 會觀看手術錄影並描述發生了什麼事。它不會量測結節。這不是 Google 未能解決的限制；這是一個沒有人用通用模型解決過的不同問題。

這兩個基準紀錄涵蓋了什麼，以及它們遺漏了什麼

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

• 測量延遲 — 首個 token 的中位數為十秒，這似乎是上限而非真正的中位數，速度為每秒 978 個 token，錯誤率達 93.93%

注意一下這個樣貌：比較表最上方是一份知識與長上下文概況，中下方是一項智慧指數，還有一項無法使用的可用性量測。這三者描述的都是同一條路由上的同一個模型。GPQA Diamond 分數高，代表它懂得很多。29.7 的綜合分數代表它並非在所有項目都領先。93.93% 的錯誤率代表，在這條特定路徑上，你的大多數請求都無法完成——而這幾乎肯定是某個預覽端點的容量與佈建事實，而不是權重本身的屬性。我們無法從外部證明是哪一種。我們能說的是，那三個數字沒有一個是打錯的，而任何只讀第一個數字的架構，都會有難熬的一週。

NV-Reason-CT 的紀錄範圍較窄，且附帶一項不同的但書。它在 CT-RATE 上的 0.614 F1 與 0.871 AUROC——涵蓋十八個標籤，採用固定的統一閾值與直接的 yes/no 提示，且沒有分類頭或任務特定調適——是 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% 的錯誤率不是細微的劣化。這是一條絕大多數呼叫都會失敗的路由。自然反應是宣告該模型不堪使用，而那樣的反應是錯的，原因有兩個。首先，在預覽端點上測得的錯誤率，反映的是容量、配額與區域路由，而不是模型的能力。Google 的預覽層級眾所周知是為了評估而非正式生產環境所配置，而一個以預覽命名的 slug，就是一個可能無預警被節流的 slug。其次，這項量測只是某一時刻、某一條路徑的快照。它會改變。不會改變的是這個教訓：依賴預覽路由，就是依賴別人所作的容量決策。

這些緩解措施並不光鮮亮麗，但它們正是路由之所以能作為一門學科、而非僅為一種便利而存在的全部原因。

• 切勿將預覽用 slug 硬編碼到正式環境路徑中 — 將該能力置於介面之後，如此一來，其背後的模型便能在無需部署的情況下替換

• 重試並改以不同的供應商或不同的模型作為備援——對批次擷取作業而言，94% 的失敗率若能將失敗導向其他地方處理便尚可承受，若無法如此則會是致命打擊

• 衡量你自己的錯誤率，而不是沿用別人的數字——93.93% 這個數字是我們目錄中某單一路線的數據，而你的數字將取決於你所在的地區、你的業務量以及你的工作負載形態

• 為任何臨床時程上的事項準備第二個模型——你要防範的失敗是糟糕的答案，那等於沒有答案

同樣的紀律也反向適用於 CT 端；在那裡根本沒有路由可言。自架模型沒有供應商錯誤率，只有硬體錯誤率、維護負擔，以及由你買了多少 GPU 所決定的容量上限。它的失效模式是佇列，而緩解方式是排程，不是容錯移轉。問題不同，規則相同：弄清楚你實際上依賴的是哪個數字。

長上下文真正有幫助的地方，以及沒有的地方

Gemini 3.1 Pro 的 1,048,576 token 視窗與 82 分的長上下文召回分數是實實在在的優勢，值得刻意加以運用，而非無意間湊巧用到。

在 CT 計畫中，它們真正發揮效益的地方不是掃描本身，而是掃描周遭的一切。對一份冗長的手術紀錄及其相關報告進行單次擷取，並將整份文件保留在上下文中，使各欄位彼此一致。一份必須一次容納數百份病患敘述、從中找出跨病患模式的世代摘要。一項轉換作業，其中結構描述、一百筆範例記錄和錯誤日誌全都需要在同一次呼叫中可見。這些都是長視窗會改變答案、而不只是帶來便利的作業。

它幫不上忙的地方在於掃描本身，而箇中原因值得精確說明，因為這正是這種對比容易招致的錯誤。以 NV-Reason-CT 的呈現方式來表示一份胸部 CT，要花費 13,824 個 token。Gemini 3.1 Pro 的視窗可容納七十份這類檢查，還綽綽有餘。限制不在於空間，而在於 Gemini 3.1 Pro 的視覺路徑把影像當成具有像素尺度的圖片，因此以那種方式呈現的檢查，在第一個 token 被輸出之前，就已經失去了切片間距與密度校準。你可以為一個體積花費一百萬個 token，卻仍然沒有得到一個體積。論文本身的比較讓這件事的代價變得具體：MedGemma 1.5 在餵入最多 85 個軸向切片時，F1 為 0.303，而原生體積模型為 0.614，這大約是兩倍的差距。

我們適合的位置，以及我們絕不會說的一件事

Gemini 3.1 Pro 透過 OrcaRouter 提供，google/gemini-3.1-pro-preview以供應商的定價表費率計費、零加成，並納入涵蓋超過 200 款模型的單一 API 之中。對於一個目前仍處於預覽階段的模型來說，這樣的組合比聽起來更實用。零加成意味著供應商的費率變動當天就會反映到我們這邊，而不是被握有舊數字的中間層吸收。自動容錯移轉意味著開始故障的路由不會連帶拖垮整批工作——考量到某一條路徑測得的錯誤率高達九成，這並非假設性情境。而用於將個別請求導向最適合處理它們的模型的路由 DSL，讓你能把長上下文工作交給一個模型、把低成本高流量的工作交給另一個，而不必維護兩套整合。

NV-Reason-CT 不在我們的平台上。NVIDIA 的模型也都不在。它是你自己下載並執行的權重，而誠實的定位是：這套架構的兩半存在於截然不同的地方：一半在 API 後面，附有價目表和預覽版風險；另一半在你自己的硬體上，採用 OpenMDW-1.1 授權，還有一個你得自己產出的吞吐量數字。

經得起生產環境考驗的決策

如果你的問題是在長脈絡下理解文字、音訊、影片或文件，Gemini 3.1 Pro 在知識與召回方面經獨立評測位居該領域頂尖，而它與正式生產管線之間唯一的阻礙就是路由可靠性——這是可解決的工程問題，不是模型問題。把它放在容錯移轉機制後面，不要硬編碼預覽版 slug，並且衡量你自己的錯誤率，而不是相信任何人的數字，包括我們的。

如果你的問題是胸部或腹部 CT 體積，那麼在這個比較中，恰好有一個開放模型可以處理它；它不是那個具有百萬 token 視窗的模型，而應該主導你規劃的數字也不是它的 F1 分數。那個數字是沒有人發表過的每項檢查延遲。在你向任何人承諾吞吐量數字之前，先測量它。

這項比較值得做，因為它把兩種經常被混為一談的東西分開：輸入的廣度與表徵的深度。Gemini 3.1 Pro 擁有目前任何人出貨過最寬廣的輸入面，以及這組當中最強的長上下文召回能力，卻仍然無法把一份 CT 檢查當作 CT 檢查來判讀。NV-Reason-CT 能判讀一份，其他都不行。一條管線兩者都需要，需要把它們放在不同的基礎架構上，還需要知道兩邊各有兩個數字，哪一個才是會在凌晨三點把你叫醒的那個。