本地医疗 AI：架构和基础设施指南

你们医院的 IT 团队说「我们不能用云端 AI」。他们是对的。PHI 一旦离开你的网络，就构成一次合规事件。每一次带着患者数据调用 OpenAI 或 Anthropic 的 API，都会带来审计责任、BAA 的复杂度和数据泄露风险。

但有一件事他们可能还不知道：本地 AI 现在既可行又负担得起。一块 NVIDIA T4 GPU 比一台中端工作站还便宜。开源模型跑临床 NLP 任务已经达到生产可用的质量。基础设施的模式也早已成型。

本指南把你需要的东西讲清楚：硬件、网络架构、模型服务、存储、监控、更新和灾难恢复，目标是在医疗环境中把 AI 跑在本地。

硬件要求

第一个决定是用 GPU 还是 CPU 做推理。这取决于你的调用量和延迟要求。

面向医疗调用量的 GPU 与 CPU 对比

对多数中型医院（200 到 500 床）： 从单块 T4 GPU 起步。它能承担临床记录摘要、诊断编码辅助和患者分诊，调用量足以覆盖 3 到 5 个科室。一台完整推理服务器（CPU 加内存加 T4 加存储）的硬件总成本为 8,000 到 12,000 美元。

对较小的诊所（100 床以下）： 纯 CPU 推理是可行的。一台现代 32 核 Xeon 服务器配 64GB 内存，运行量化后的 7B 模型，对于非实时任务（比如夜间批量处理临床记录、每周生成报告）延迟是可以接受的。

服务器最低配置

网络架构

医疗 AI 部署可归为三种网络模式，各自的安全特性不同。

模式一：物理隔离部署

最严格的方案。推理服务器完全不联网。

[Clinical Systems] <---> [Internal API Gateway] <---> [AI Inference Server]
                              |
                         [Audit Log DB]

No external network connection. Model updates via secure media.

何时采用： 安全等级最高的环境。处理军队医疗记录、精神科记录、药物滥用治疗记录（42 CFR Part 2），或受严格 IRB 协议约束的研究数据的机构。

代价： 模型更新必须依靠物理介质（加密 U 盘）或内部专用的制品仓库。无法远程监控，运维负担更高。

模式二：DMZ 部署

推理服务器位于 DMZ 中，仅为更新开放受控的出站访问，不接受任何来自互联网的入站连接。

[Internet] --X-- [Firewall] --- [DMZ: Update Proxy] --- [Firewall] --- [AI Inference Server]
                                                                              |
[Clinical Systems] <-----------------------------------------> [Internal API Gateway]

何时采用： 多数医院部署都适用。它允许通过受控代理自动更新模型，同时把 PHI 的处理完全留在内部。

代价： 防火墙规则需要仔细设计。更新代理必须做加固并接受审计。

模式三：VLAN 隔离

AI 基础设施跑在专用 VLAN 上，与医院的普通网络流量隔离，但对授权的临床系统可访问。

VLAN 100 (Clinical):     [EHR] [PACS] [Clinical Apps]
                              |
                         [L3 Switch / Firewall Rules]
                              |
VLAN 200 (AI Infra):    [API Gateway] [Inference Server] [Audit DB]

何时采用： 需要按科室做访问控制的机构。放射科访问影像模型，病理科访问报告生成模型，急诊科访问分诊辅助。每一条 VLAN 之间的规则都有文档记录且可审计。

模型服务技术栈

医疗 AI 推理的生产技术栈并不复杂。

核心组件

1. 推理引擎： Ollama 或 llama.cpp。Ollama 开箱即带 REST API，llama.cpp 提供更底层的控制和略好的性能。
2. API 网关： 用 Nginx 或 Envoy 作为推理引擎前面的反向代理，负责认证、限流和 TLS 终结。
3. 服务间 mTLS： API 网关、推理引擎和审计数据库之间的每一条连接都使用双向 TLS，没有例外。这是 HIPAA 对传输中 ePHI 的要求。

请求流程

[Clinical App] --> [mTLS] --> [API Gateway (Nginx)]
    --> [Auth check: API key + department ID]
    --> [Rate limit check]
    --> [mTLS] --> [Ollama/llama.cpp]
    --> [Response logged to audit DB]
    --> [mTLS] --> [Clinical App]

API 密钥管理

每个科室拥有自己的 API 密钥，这样才能按科室做用量统计、限流和访问控制。密钥每季度轮换一次，存放在 HashiCorp Vault 或你们现有的密钥管理系统中。

存储需求

医疗 AI 的存储分为三类，各自的容量特征差别很大。

第一年存储总量： 模型和适配器占 30 到 70GB，另加审计日志的增长。一块 1TB NVMe SSD 足以支撑 5 年以上的运行并留有余量。

备份策略： 加密备份到另一处本地站点。除非云服务商已签署 BAA 且你的风险评估明确批准，否则绝不要备份到云存储。

监控与日志

HIPAA 要求任何处理 ePHI 的系统都必须有审计日志。对 AI 推理来说，这意味着每一次请求都要记。

每次推理需要记录什么

关键细节： 记录输入和输出的哈希，而不是原文。这样你既能验证完整性、证明哪个模型版本产出了哪条输出，又不必在审计数据库里多存一份 PHI。

HIPAA 访问日志

除了推理日志，你还需要标准的 HIPAA 访问日志：

• 谁在什么时候访问了 AI 系统
• 认证的成功与失败
• 配置变更（模型更新、适配器切换、参数调整）
• 对推理服务器本身的管理员访问

用你们现有的 SIEM（Splunk、Elastic 等）聚合这些日志。AI 基础设施应当接入与其他临床系统相同的日志管道。

模型更新策略

把新版本模型送上物理隔离或网络隔离的系统，是运维上最大的挑战。

方案一：安全 U 盘传输（物理隔离）

1. 在安全房间内一台联网的工作站上下载模型文件
2. 与官方公布的哈希核对校验和
3. 传输到加密 U 盘（符合 FIPS 140-2）
4. 由授权人员运送，并保留完整的保管链文档
5. 加载到推理服务器，再次核对校验和
6. 在切换生产流量之前运行验证套件

每次更新耗时： 含核对与验证共 2 到 4 小时。

方案二：内部制品仓库（DMZ）

1. 通过 DMZ 代理自动从外部模型仓库（Hugging Face、Ollama registry）拉取
2. 模型文件落到内部制品仓库（Nexus、Artifactory，或一个简单的 Nginx 文件服务器）
3. 推理服务器按计划从内部仓库拉取
4. 切换流量之前自动运行验证套件

每次更新耗时： 30 到 60 分钟，大部分自动完成。

分阶段放量

无论用哪种投递方式，都要分阶段放量：

1. 金丝雀（5% 流量）： 把一小部分非关键请求导向新模型
2. 验证（24 到 48 小时）： 把输出质量指标与上一版本对比
3. 全量切换： 把全部流量切到新版本
4. 回滚窗口： 保持上一版本处于已加载状态，随时可即时回滚，持续 7 天

灾难恢复

临床环境中的 AI 系统故障需要明确的兜底流程。

故障模式与应对

CPU 兜底

每一套 GPU 加速的部署都应当有一条经过测试的 CPU 兜底路径。如果 GPU 故障：

1. Ollama 或 llama.cpp 自动回退到 CPU 推理
2. 吞吐从每秒约 30 token 降到每秒约 5 token
3. 把并发请求上限从 10 降到 2
4. 优先保障实时的临床场景，批处理任务排队

这种降级模式能在硬件更换期间保持 AI 可用。任何临床工作流都不应硬性依赖 AI，AI 应始终是辅助性的，并保留人工兜底。

成本对比：本地部署 vs 云 API

在医疗的调用量级上，这笔账倾向本地部署。

三年总拥有成本

假设条件： 每天 1,000 次推理，平均输入 500 token、输出 200 token。云端定价按每千 token 0.01 到 0.03 美元计算（含 BAA 的档位，通常是标准价的 2 到 3 倍）。DevOps 按每小时 75 美元计，本地每周 4 小时，云端每周 1 小时。

盈亏平衡点通常落在每天 200 到 300 次推理。低于这个量，带 BAA 的云 API 可能更划算；高于这个量，本地部署胜出，而且差距逐月拉大。

团队需要什么人

你不需要一支专门的 ML 团队。你需要的是：

• 1 名 DevOps／基础设施工程师（兼职，每周约 4 小时）： 负责服务器维护、模型更新、监控告警和安全补丁。这个人你们 IT 团队里已经有了。
• 每个科室 1 名临床牵头人： 一位负责该场景的临床医生，负责验证输出并为微调提供反馈。这不是技术岗位。
• 供应商支持（可选）： Ertas 或类似平台，提供微调、适配器管理和部署工具，让你不必具备 ML 专业能力。

最常见的错误是人配得太多。本地 AI 推理在运维上和运行任何其他内部服务差不多。如果你的团队能管好一台内部数据库服务器，他们就能管好一台 AI 推理服务器。

拼到一起

下面是一家中型医院完整部署的架构：

Internet (updates only)
    |
[DMZ: Update Proxy]
    |
[Internal Network - VLAN 200: AI Infrastructure]
    |
[Artifact Registry] --> [Inference Server: T4 GPU + Ollama]
                              |               |
                    [API Gateway (Nginx)]  [Audit DB (PostgreSQL)]
                              |
                    [mTLS + API Key Auth]
                              |
[VLAN 100: Clinical Systems]
    |           |           |
  [EHR]     [PACS]    [Clinical Apps]

第一天的部署： 一台 T4 服务器、一个科室、一个场景（临床记录摘要）。总成本低于 12,000 美元。用现有 IT 人员，2 到 3 周即可上线。

扩展路径： 为新科室增加 LoRA 适配器。为更高吞吐增加第二块 T4。为放射、病理、编码增加专科模型。每一次扩展都是增量式的，不需要重构架构。

基础设施是这件事里简单的部分。模型服务技术栈已经被验证过，网络模式也早已成熟。真正要紧的，是把第一个场景送上生产，并向每天使用它的临床人员证明价值。

延伸阅读

• 2026 年自托管 AI 的 GPU 成本对比：推理负载的详细硬件基准与价格
• 自托管 AI 投资回报计算器：用你自己的调用量数据搭出商业论证
• 符合 HIPAA 的 AI：本地部署 vs 云 API：合规要求与架构取舍的深入分析