开源模型医疗落地：SWE-bench 80.6% 成绩与离线部署架构

过去三年的大部分时间里，"AI 在医疗领域"在架构上意味着同一件事：向别人家的模型发起一个出站 HTTPS 调用，配上一份签署的 BAA（商业伙伴协议）来充当真正的数据控制。这不再是唯一的选择——2026 年，这种替代方案已不再是理论上的可能。

两件事独立地发生了变化，合在一起产生了真正的差异：开源权重模型在能力上与封闭前沿模型的差距已经大幅缩小，而支持完全离线（air-gapped）运行的工具链——包括生产级路由、可观测性和治理——已经成熟为一种易于理解的模式。本文同时覆盖两个方面：模型如今的现状，以及在网络内部完全运行这些模型的详细参考架构。

能力差距已近乎弥合

开源权重模型在长达一年多的时间里，一直与封闭前沿实验室保持着大抵一致的三至六个月差距——并非持续扩大差距，而是一个稳定的落后幅度。DeepSeek 的 V4 Pro 模型在 SWE-bench Verified 上达到了 80.6%，与 GPT-5.5 级别的 agent 性能处于同一区间，而更轻量的 V4 Flash 变体以极低的算力成本提供了几乎相同的结果。

对医疗领域更具参考价值的是：这不仅仅是通用能力，而是领域适配能力。在 ArchEHR-QA 2026 基准测试中，使用开源权重 MedGemma 3 27B 模型的团队在临床问答上取得了与专有系统高度竞争力的结果，并在证据引用对齐上排名第一。慕尼黑工业大学的一个团队在 MedGemma-27B 上构建了完全本地化的流程，专门用于从病例报告表中提取结构化数据——原因正是商业 API 无法保证患者数据留在机构内部。

硬件需求也下降到了不再是数据中心专属问题的程度。OpenAI 的 gpt-oss-120B 可以运行在单张 80GB GPU 上，同时实现接近 o4-mini 的推理性能。在中国，数据主权压力推动本地化部署比美国更早——截至 2025 年初，已有超过 300 家医院采用私有化、现场部署的 DeepSeek，直接集成到医院信息系统中，用于出院小结和临床决策支持。

简而言之："我们需要自己的模型，但效果肯定不够好"这一异议在很大程度上已经消失。剩下的问题在于架构层面。

医疗 AI 离线部署参考架构

这是大多数"开源权重 vs 封闭"帖子会跳过的那部分。在笔记本上跑 ollama pull 并不是医院级的平台。你真正需要的是一个分层系统——模型切换、GPU 变更和审计要求不会影响到每一个消费该平台的应用。

一个行之有效的模式——也是我推荐给任何正在评估此方案的医疗平台团队的起点——将关注点分离到五个层次，而不是将任何一个单一工具视为"那个"AI 平台：

核心原则：每一层回答不同的问题，它们之间不应该相互竞争。

为什么网关层对医疗领域尤为关键。 LiteLLM 位于一切之前，向应用提供逻辑模型名称——比如 clinical-summarization——而不是对物理模型（如 MedGemma-3-27B）的硬依赖。这种解耦使得合规批准的模型切换无需触及应用代码，同时也是认证、分应用限速和使用量核算的所在地——这些正是审计委员会会首先问到的控制措施。

为什么不能只跑一个工具。 vLLM 是你的主要临床聊天/推理模型的高吞吐 GPU 服务正确选择。llama.cpp 在商品级或异构硬件上运行量化模型时才有意义——适用于不值得配备 GPU 集群的部门或边缘部署场景。LocalAI 覆盖多模态表面（影像相关工作流中的视觉、听写中的语音转文字、临床文档 RAG 的 embedding 和重排序），用一套 API 而不是五个定制集成。Ollama 保持可选——它是开发者便利工具，不是生产依赖。

真正实现"离线"的那部分

网络边界是必要条件，但不是充分条件。一个真正的离线平台将所有制品——容器镜像、模型权重、Python 包、操作系统包——视为必须在工作负载使用前经过暂存、扫描、签名和导入的实体：

生产容器从不针对公共互联网运行 pip install、docker pull 或 git clone。一切——LiteLLM、LocalAI、vLLM、llama.cpp、以 GGUF 或 safetensors 格式存放的模型权重——都预先暂存到内部容器注册表和模型注册表中。这也是模型治理真正落地的地方：一个模型不经过扫描和签名流水线就无法到达面向临床的端点——这给你提供了合规审查会要求的审计追踪。

网络分段遵循同样的逻辑：客户端流量先到达内部入口，进行身份认证，然后才能到达网关；网关是唯一允许与服务层通信的组件；东西向流量默认禁止。这是个小细节，但正是"模型运行在我们大楼内的服务器上"与"我们实际上能够证明数据从未离开过批准边界"之间的区别。

"本地化"仍然无法解决的那些问题

在本地运行这个技术栈消除了最大的异议（数据离开机构），但并不能消除一切：

本地不等于默认安全。 流经 LiteLLM 和 LocalAI 的聊天历史、prompt 和日志，本身成为内部数据资产。它们需要与任何其他 PHI 相邻系统相同的访问控制和保留策略——网关需要自己的审计日志（Prometheus/Loki/OpenTelemetry 风格的可观测性，而不是事后补救），就像网络边界需要防火墙规则一样。

你继承了你可能意想不到的监管分类。 在 EU AI Act 下，运行自己 LLM 部署的医院可能被归类为"模型部署者"，带来与人们通常首先考虑的数据驻留问题分开的光照和义务。这是一个治理决策，不仅仅是能力决策——这正是离线供应链中"扫描、签名、晋升"步骤的用途。

安全性和能力在开源权重世界正在解耦。 SaferAI 近期的一项评估发现，GLM-5.2——可用的最强开源权重模型之一——对其收到的攻击性网络或生物安全任务几乎没有拒绝，相比之下封闭模型的拒绝率要高得多。模型进入注册表的筛选是治理决策，不仅仅是能力决策。

来源和许可仍需真正的尽职调查。 并非每一个开源权重发布都携带真正适合商业医疗用途的许可，而且几个目前最强的模型来自其管辖范围会带来自身供应商风险问题的实验室——你的合规委员会在上线前有理由提出质疑。

实用评估清单

如果你的组织在未来两个季度内正在做这个项目的规划，以下是我实际会按此顺序推进的步骤：

先做任务匹配。 文档摘要、结构化提取（CRF 风格）和基于证据的问答，是领域适配开源模型（如 MedGemma 系列）已经验证的适用场景。开放式诊断推理的门槛要高得多——单独规划，放在后面。

先设计网关，再选模型。 在确定具体模型之前，先决定你的逻辑模型名称、路由和降级策略（LiteLLM 风格）。这保证了模型升级不会变成全应用迁移。

根据实际而非假设来确定硬件规模。 单张 80GB 级 GPU 现在已经能覆盖聊天和推理工作负载的相当大一部分；llama.cpp 在商品硬件上覆盖部门或边缘场景。在假设需要集群之前，先建模你实际的 GPU 预算。

尽早构建离线供应链。 制品的暂存、扫描、签名和晋升，是让其余一切可审计的繁琐工作。这也是通常最费时的部分——在模型选择定案之前就开始，而不是之后。

进入之前就要了解你的监管分类。 EU AI Act 等框架下的"模型部署者"义务同样适用于完全内部部署——在架构审查之前让合规团队介入，而不是之后。

把可观测性当作一等公民，而不是后期追加的仪表板。 网关和服务层的指标、日志和追踪，是你回答"谁在何时用什么模型查询了什么"的工具——这是每次审计最终都会问到的问题。

趋势展望

三条趋势线正在汇聚：开源权重模型持续缩小与封闭前沿的能力差距，支撑它们所需的硬件持续缩小，而将它们作为可治理的离线平台运行（而非研究演示）的工具链已经成熟为具有易于理解组件的可重复模式。两年前，这三点同时成立的情况还不存在。

在这波浪潮中走在前面的组织，不会是那些等待单一供应商推出"医院级"黑盒的公司。它们是那些现在就开始构建平台层的组织——一个将应用与模型解耦的网关、一个让每个制品都可审计的离线供应链、以及让合规对话变成数据查询而非专项项目的可观测性——这样当下一个 MedGemma 级别的模型出现时，采纳它是一个配置变更，而非六个月的项目。

我在 LinkedIn 上写了更简短的版本——本文是包含架构和清单的完整版。