NV-Reason-CT 对比 Gemini 3.1 Pro：输入面最广，却仍不是 CT 阅片器

百分之九十四。这是我们自己的目录目前为一条路由记录到的错误率，该路由服务于Gemini 3.1 Pro——93.93%，外加一个读取为十秒上限的中位首 token 时间，以及每秒 978 个 token 的吞吐量。若把它当作关于该模型的陈述来读，你只会得出完全错误的结论。若把它当作关于一个处于负载之下的预览层级（preview tier）的陈述来读，它就变成了页面上最有用的东西，因为这正是一条临床流水线在依赖一条尚未为生产流量完成配置的路由时实际经历的情况。

这个对比另一侧的模型没有这样的问题，也没有这样的测量。NV-Reason-CT是 NVIDIA 的 46.9 亿参数原生 3D CT 推理器，可按 OpenMDW-1.1 下载，但完全没有公布吞吐量数据，也没有在任何地方提供托管。因此，这场对比中的一方为你提供了该领域最广泛的输入面，其可用性状况却需要你围绕它来设计方案；另一方则只给你一项狭窄的能力，延迟还得你自己去测量。两者都没有一个在第一天就能信任的监控仪表板，而且原因恰恰相反。

两个模型，两种对“多模态”的定义

这个词在两份产品描述中都发挥了很大作用，但几乎没有共通之处。

• 接受的输入 — Gemini 3.1 Pro 可接受文本、图像、音频、视频和文件；NV-Reason-CT 只接受以亨斯菲尔德单位表示的单通道 NIfTI 体数据，除此之外一概不接受

• “3D”意味着什么 —— NV-Reason-CT 会在一个 384 毫米的立方体范围内重采样为 2 毫米各向同性，并将其切成 8 x 8 x 8 的图像块，形成 24 x 24 x 24 的网格；Gemini 3.1 Pro 的视频输入则是带时间轴的二维帧序列

• 上下文 — Gemini 3.1 Pro 为 1,048,576 个输入 token、65,536 个输出 token；对 NV-Reason-CT 而言，一部即为 13,824 个视觉 token，既无降采样也无合并层，且其周围没有聊天窗口

• 发布 — 2026年2月19日，面向 Gemini 3.1 Pro，以预览 slug 形式提供；NV-Reason-CT 的一次未公开研究性发布，仓库活动日期为 2026年9月2日至25日

• 价格 — $2 和 $12 每百万 token，最多 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，是在十八个标签上、采用固定统一阈值、直接的是/否提示，且没有分类头或任务特定适配的情况下取得的，这些是 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% 的错误率不是轻微的降级。这是一条绝大多数调用都会失败的路由。自然的反应是宣布该模型不可用，而这种反应是错的，原因有二。第一，在预览端点上测得的错误率反映的是容量、配额和区域路由，而非模型的能力。Google 的预览层级众所周知是为评估而非生产而配置的，而一个以预览命名的 slug，就是一个可能在没有通知的情况下被限流的 slug。第二，这次测量只是某一时刻某一条路径的快照。它会变化。不会变化的是这个教训：对预览路由的依赖，就是对别人做出的容量决策的依赖。

这些缓解措施并不起眼，但正是它们的存在，才使路由成为一门学科，而非仅仅一种便利手段。

• 切勿将预览 slug 硬编码到生产路径中——把这项能力放到接口之后，这样无需部署即可替换其背后的模型

• 重试并回退到其他提供商或其他模型——对于批量提取任务，如果失败的部分能被路由到别处，94% 的失败率尚可承受；如果不能，那就是致命的

• 测量你自己的错误率，而不是照搬别人的——93.93% 这个数字是我们目录中某一条线路的数据，而你的数字将取决于你所在的地区、你的业务量以及你的工作负载形态

• 对于任何有临床时间要求的事项，都要让第二个模型保持热备状态——你要防范的故障模式并不是答案不好，而是根本没有答案

同样的准则在 CT 侧反过来也适用，而那里根本没有路由。自托管模型没有供应商错误率；它有硬件错误率、维护负担，以及由你购买了多少块 GPU 决定的容量上限。它的故障模式是队列，缓解方式是调度，而不是故障转移。问题不同，规则相同：要清楚你实际依赖的究竟是哪个数字。

长上下文在哪些地方确实有帮助，在哪些地方没有

Gemini 3.1 Pro 的 1,048,576 token 窗口和 82 分长上下文召回得分是真正的优势，值得有意识地加以利用，而不是无意中用到。

在 CT 项目中，它们真正发挥作用的地方不是扫描。而是围绕扫描的一切。对一份冗长的手术记录及其相关报告做单次提取，将整份文档置于上下文中，使各字段彼此一致。一份必须同时容纳数百份患者叙述、以找出其中模式的队列摘要。一项转换任务，其中模式定义、一百条示例记录和错误日志都必须在同一次调用中可见。这些任务中，长窗口改变的是答案，而不仅仅是便利性。

它帮不上忙的地方在于扫描本身，而原因值得精确说明，因为这正是这种对照所招致的错误。一次胸部 CT，若以 NV-Reason-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 能读一份 CT 检查，除此之外什么都读不了。一个流水线两者都需要，需要它们跑在不同的基础设施上，还需要知道两边各自的两个数字中，哪一个才是会在凌晨三点呼叫你的那个。