医院内网部署AI大模型：从显存选型到HIS落地的全栈指南

1. 先搞清楚：HIS为什么要接AI大模型，为什么非要在内网部署

1.1 真实场景：临床科室要的到底是什么

上次帮一家三甲医院做HIS系统与AI大模型的本地部署，第一天信息科主任就把话说得很直接：“数据不能出机房，模型必须在内网跑。”这句话基本定调了。一开始临床科室的需求听起来很“魔幻”——要写病历、要查指南、要回患者问题、还要做病历质控，恨不得所有的活都丢给大模型。但拆开来看，真正的核心痛点是这三类：一是辅助文书生成，医生每天花大量时间写入院记录、出院小结，很多是模板套话但还得逐字敲；二是临床知识问答，年轻医生遇到不常见的用药禁忌或检查指标，想快速查到院内的诊疗规范；三是病历内涵质控，出院病案要按规范归档，缺项、前后矛盾、诊断术语不规范都是被退回的重灾区。

这三类需求有个共同特征：它们都需要一个“懂医疗、懂院内规范、响应够快”的智能引擎。云端通用大模型接口倒是方便，但医院信息科一听“数据要传到第三方服务器”基本当场否决。患者姓名、身份证号、主诉、检验结果，这些是受严格保护的个人敏感信息，在绝大多数院内安全制度里根本不允许出网。所以HIS要接AI大模型，不是技术选型问题，而是安全约束下的非本地部署不可。

1.2 内网部署的硬约束：数据不出院

医院内网的特殊性在于它是一个相对封闭、受监管的网络环境。HIS、EMR、LIS、PACS这些核心业务系统通常都跑在内网，与互联网做了物理隔离或逻辑隔离。大模型若要用上真实病历数据，就必须放到这个内网环境里运行。这意味着模型推理完全在本地进行，患者数据只在院内流转，日志也保存在院内服务器上。

很多人会问，既然有公有云，为什么不能采用私有化VPC里的云GPU？这里有两个现实原因：一是部分医院尤其三甲有明确的管理要求，核心业务数据不允许经过第三方平台；二是院内业务系统有大量对端设备、老版本的HIS客户端、医保专线、区域卫生平台接口，牵一发而动全身，把AI服务放到内网最稳妥。另外，AI大模型用在临床场景时，医生往往是基于“它给出的参考”继续修改病历，这个过程本身就涉及大量原始数据交互，放在本地延迟低、可控性强，也更方便做权限审计。

1.3 全栈架构的一个直观分层

我在做这个项目时习惯把整套架构分成六层，每一层都有它的“坑”，缺一层后面都会炸：

这套分层思路的核心价值在于：把大模型推理引擎当成一个“内网基础设施”而不是“一个功能点”。HIS厂商想调用能力时，只需要面向服务层对接即可，不需要关心底层模型是哪个、显存用了多少。反过来，后续模型要升级换代，也只替换模型层和推理层，不影响上层业务。

2. 显存与硬件选型：预算花在刀刃上

2.1 显存到底怎么算，别再凭感觉买卡

医院采购最怕的就是“按感觉来”，要么买贵了被审计问责，要么买小了模型跑不起来。显存估算其实有清晰的账可以算。核心公式是：模型推理占用的显存 ≈ 模型权重显存 + KV Cache显存 + 推理计算额外开销。模型权重大小取决于参数量与量化精度：FP16/FP32每个参数分别占用2字节和4字节，INT8每个参数占1字节，4bit量化每个参数约占0.5字节。所以7B模型FP16权重约14GB，Q4量化后约3.5~4GB；14B模型FP16约28GB，Q4约8GB；32B模型FP16约64GB，Q4约18~20GB；70B模型FP16约140GB，Q4约40GB。

KV Cache是在推理过程中保存“已经算过的注意力层信息”的内存区域，大小和模型结构强相关，难以像权重那样直接估算，但可以记住一个经验参考：7B级别模型在2048上下文、batch size为4时，KV Cache大约占用1~2GB；32B级别的模型可能占到4~8GB。所以选卡时最稳的做法是：权重占用的显存算出来后，再除以0.7~0.8，也就是预留20%~30%的余量给KV Cache和计算缓冲区。举例，想跑32B Q4量化，光权重就要20GB，保险起见单卡至少需要30GB可用显存，那么24G卡就很紧张，48G卡会更从容。

2.2 按参数量级匹配GPU，三档配置建议

根据医院的预算和需求，我给过不少次的配置建议可以归成三档。第一档是入门试点级，12G~16G显存，用RTX A4000或4070 Ti Super，目标跑7B~8B级别的Q4量化模型，适合做病历生成、预问诊这类简单场景，基本能验证“AI值不值得继续投入”。第二档是标准生产级，48G显存，推荐A6000、L20或者RTX 6000 Ada，目标跑32B级模型Q4量化或14B模型FP16，能覆盖绝大部分文书生成与知识问答，这也是三甲医院单病区试点的性价比之选。第三档是高端投入级，80G显存，A100/H100/H800这类卡，目标跑70B级模型量化版或32B模型FP16，面向全院级并发和高准确率要求的场景。

这里多说一句，医院机房往往不是想上什么卡就能上什么卡。2U服务器通常只支持2~4张双宽卡，供电上限可能在2000W左右，散热条件也有限。消费级RTX 4090虽然单卡性价比高，但在24小时不间断运行的院内环境里，寿命、稳定性、售后都不如专业计算卡让人安心。我遇到过医院信息科把4090塞进普通塔式服务器，跑了两周后风扇啸叫、温度报警的案例。预算是要省，但不能省在这种关键设备上。

2.3 低显存与多卡方案的真实取舍

“显存不够硬盘来凑”这种说法很多人提过，本质上是通过CPU内存加载模型、显存只做部分缓存的方式运行大模型，用磁盘或内存换显存。低显存确实能“跑”起更大的模型，但推理速度会指数级下降。实测中，用16G显存加载一个32B Q2量化模型，首token延迟可能从0.5秒拉到5秒甚至更高，完全没法在医生工作站上用。所以如果预算有限，我建议优先考虑把目标模型降一档，而不是强行上大模型。

多卡并行是另一个被忽视的坑。用两到四张卡可以通过张量并行把70B模型切分跑起来，但卡与卡之间的通信带宽同样影响性能。数据中心级显卡比如A100通过NVLink互联，带宽很高，相对顺畅；而消费级显卡走PCIe总线传输，速度差了一个数量级。我之前踩过坑：两台4090组张量并行跑70B模型，实际吞吐反而比一张A6000单卡跑32B模型还低。原因是卡间同步太频繁，PCIe带宽成了瓶颈。医院如果确实需要上多卡，优先确认服务器是否支持NVLink/Infinity Fabric这类高速互联，或者直接用单张高显存专业卡。

3. 模型选型：把对的模型放到对的硬件上

3.1 医疗场景的选型维度

模型选型不是参数越大越好，也不是排行榜越靠前越合适。在医院这种敏感场景，我会重点看四个维度。第一是中文理解能力，病历、指南、诊断术语都是中文，很多英文开源模型的中文能力一眼假，生成出来的句子看着通顺但一细读就跑偏。第二是医学知识覆盖度，通用模型经过RLHF后可能非常“听话”，但对专业术语的把握未必够，所以优先选择在医疗语料上做过继续预训练或指令微调的模型。第三是合规可商用授权，本地部署不等于可以随便商用，尤其涉及患者隐私和三甲医院临床业务，任何许可证不清晰的模型都不能用。第四是生态成熟度，包括是否能轻松量化、是否兼容Ollama/vLLM、是否有健壮的OpenAI兼容接口，这直接决定实施工程师的担子轻重。

还有一点容易被忽略：模型的“性格”要适合医院场景。通用对话模型往往倾向于给一个流畅但自信满满的答案，这在医疗领域非常危险。我会特别关注模型是否支持用提示词约束它“在信息不足时明确说不知道”，以及是否适合做RAG（检索增强生成）——也就是先检索院内知识库，再让模型基于检索内容生成回答。这比裸模型直接回答靠谱得多。

3.2 主流可本地部署模型的横向对比

现在开源模型已经非常成熟，因为我平时接触国内项目较多，这里列几个医院场景实测下来还不错的阵营。Qwen家族是首选之一，Qwen2.5系列从7B到72B都有，中文能力强，指令跟随稳定，量化生态好，Ollama和vLLM都直接支持，我做过多个院内试点都选它。DeepSeek系列的DeepSeek-R1-Distill-Qwen系列在逻辑推理和文本结构化上表现出色，适合病历质控、诊断逻辑校验这类任务。Llama 3.1家族在国际生态和工具调用上更成熟，但中文表现需要花精力微调或外挂词表，而且70B对硬件要求高，医院不差钱的话可以考虑。

GLM家族中文语感不错，ChatGLM3/GLM-4系列在中文对话自然度上口碑可以，对国内医疗语料有一定适配。医疗专项模型方面，国内有基于Qwen/Llama微调的开源医疗模型，比如某些中文医学问答模型，作为垂直底座有一定价值，但更新维护速度不一，引入前需要评估活跃度。我给医院做选型时通常不会只选一个模型，而是部署主模型和备模型两套：日常文书生成用7B/14B轻量模型，成本低响应快；遇到复杂病历分析再用32B/70B强模型。这种“大小模型搭配”比单吊一个大模型灵活得多。

3.3 量化格式怎么选，直接抄作业

模型量化是本地部署绕不开的一环。FP16精度最高但吃显存，FP8精度损失很小但目前对硬件有要求，GPTQ和AWQ是常见的4bit量化格式，GGUF是Ollama这类推理框架常用的格式。我的建议是分场景：如果是快速原型验证，直接下载GGUF格式的Q4_K_M版本，用Ollama跑起来看效果；如果是生产高并发，优先用AWQ量化版或FP8，搭配vLLM跑，吞吐和显存利用率比GGUF更好。

需要说明一点，量化不是越低越好。Q4_K_M我在多个模型上实测，和FP16的答案质量差异在大部分任务里非常轻微，可以接受。但Q2或Q3量化后明显会出现语句重复、常识错误等问题，尤其在医学这种容错率低的场景，不建议为了省显存盲目压到Q3以下。另外，同一个模型的不同量化版本，Ollama和vLLM不一定是同一份文件，部署前要确认推理框架支持的格式类型，别下了一堆GGUF结果vLLM不识别。

4. 部署实操：从Ollama到vLLM再到HIS接口

4.1 离线环境准备

医院内网通常无法直接访问外部网络，所以“怎么把模型和依赖软件送进去”是第一只拦路虎。我的流程是先在一台测试机上把环境完全调好，再打包进内网。操作系统层面推荐Ubuntu Server 22.04 LTS，医院环境如果强制国产化，也可以选麒麟V10或欧拉，但要注意驱动兼容性。NVIDIA驱动和CUDA版本必须和推理框架匹配，例如vLLM对CUDA版本要求较严格，尽量按照官方文档指定的版本装。GPU直通容器前还要安装好NVIDIA Container Toolkit，否则Docker不一定拿到GPU。

传输层面，模型文件通常很大，几GB到几十GB不等，建议用移动硬盘或内部文件服务器中转，传完后校验哈希。我遇到过一个真实事故：某项目把模型文件从外网下载后直接U盘拷入，结果少了一个分片文件，模型加载到一半报错，排查了一下午。所以离线传输时务必对文件做SHA256校验，并保留完整的模型目录结构，不要文件夹套文件夹地反复改名。Docker镜像也建议提前从公共源拉好导出，再导入到院内私有Registry，方便多台服务器分发。

4.2 用Ollama快速跑通原型

内网部署的第一步不是直接上生产框架，而是先用Ollama把业务流程跑通。Ollama对GGUF格式的模型支持很好，安装也简单，几乎就是解压即用。把下载好的模型文件放入Ollama的模型目录后，执行ollama serve启动服务，新开终端执行ollama list确认模型已经识别，再执行ollama run qwen2.5:14b-instruct-q4_K_M测试交互。验证生成是否符合预期后，可以用curl调用REST API接口测试从HIS侧发请求的可行性。

Ollama最大的优势是上手极快，适合给医院信息科演示“这玩意真的能跑”。但它在生产并发场景并不算最优，并发一高时请求排队明显，而且它没有原生的高可用部署方案，不适合做多副本负载均衡。所以Ollama适合承载POC阶段的验证，正式上线建议换vLLM。不过Ollama在另一类场景值得保留：部分院内知识库问答，用低并发、长上下文的方式调用，它表现反而稳定，且运维成本几乎为零。

4.3 用vLLM承载正式生产流量

vLLM是我目前在生产环境用得最多的推理框架，原因有二：一是内存管理效率高，通过PagedAttention技术显著降低KV Cache浪费，同样显存能支撑更高并发；二是原生提供OpenAI兼容的API接口，HIS厂商对接时直接用标准chat/completions方法即可。部署时我通常用Docker方式，核心命令如下：

docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-32B-Instruct-AWQ \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --served-model-name his-ai-qwen

这个命令行几个参数值得掰开讲。--tensor-parallel-size指定张量并行卡数，单卡就固定为1，多卡按实际显卡数设置；--gpu-memory-utilization控制在90%，给系统预留一部分显存余量，防止内存碎片导致OOM；--max-model-len限制最大序列长度，设置过大会显著增加KV Cache显存，实际按院内业务最长上下文来定，通常8192足够。启动后配合nvidia-smi观察GPU利用率与显存占用，确认服务稳定后再往上层接业务。

启动完成后HIS侧不应该直接对接vLLM原生端口，我一般会在中间加一层FastAPI封装，把模型服务的原始报文转换成院内业务需要的数据结构，同时做API Key鉴权、请求日志、敏感词过滤。Nginx反向代理也是一个不错的选项，可以统一入口、配置HTTPS证书，还能把上游多个vLLM节点做负载均衡。这一层虽然增加了开发量，但对后续运维非常关键，尤其是医院的安全审计要求下，没有日志模型的调用就全成了黑盒。

4.4 HIS/EMR/PACS系统的接入方式

模型服务上线后，真正难的是和医院既有系统的对接。HIS系统的HIS厂商五花八门，有基于Java的，有C#.NET的，也有C/S老架构，但对外服务基本都支持HTTP/WebService方式。合理的集成方式是：HIS或集成平台通过后端服务调用模型封装层，先把患者主索引脱敏处理后传入模型，模型返回结果后再由封装层关联回对应病历号。千万不要让前端浏览器直接请求模型服务，否则所有鉴权都形同虚设。

EMR电子病历系统最常见的是文本生成需求，比如根据主诉和现病史自动生成首次病程记录草稿。这种场景建议走FHIR或院内集成平台的标准消息格式，由EMR侧发起请求，模型返回JSON结构化结果，EMR再通过消息映射生成文书。PACS影像系统涉及的是图像数据，本地大模型通常不直接处理DICOM原生文件，更常见的做法是先用文字识别服务提取放射报告文本，再把结构化报告送入模型做审核对比。如果医院有院内集成平台，尽量通过平台统一对接，避免每套系统各拉一条线。

5. 医院落地必须守住的底线：数据安全与医疗合规

5.1 权限、审计与内网隔离

医院内部署AI服务，最关键的不是模型效果，是权限边界和数据流安全。模型服务所在的主机应放在业务内网的安全域，只开放给有调用的应用服务器IP，端口用防火墙收紧。我见过有些项目把模型服务端口直接绑在0.0.0.0上，院内任何一台电脑都能发请求，这个在合规上过不了关。正确的做法是绑内网IP，配合IP白名单，再在封装层加一层API Key验证。

日志审计也必须到位。每次AI调用要记录时间、调用来源、业务系统、输入内容摘要、输出内容摘要，并设置180天以上留存。这不是繁琐，而是出了医疗争议时给医院留后路。试想一下，AI给出的参考建议如果出了问题，没有日志回溯根本讲不清楚是医生采纳了错误建议还是系统本身有缺陷。另外，模型服务所在的容器应避免以root权限运行，容器间用独立网络或VLAN隔离，尽量把AI服务的爆炸半径控制在最小。

5.2 人机协作与提示词约束

再聪明的模型也会产生幻觉，这是大模型的本质缺陷。在医疗场景里，绝对不能让模型直接输出“最终诊断”或“用药决定”。部署时必须把提示词约束写死：模型只能充当辅助角色，输出内容要明确标注“仅供医生参考，不作为最终诊疗依据”。我通常在系统提示词里固定一段话，要求模型在信息不完整时给出“需要进一步询问”而不是硬凑答案，并把温度参数降到0.2以下，减少随机性。

从产品形态上也要做人机协作设计。比如病历生成功能，默认生成的是“草稿”，医生修改并签署后才进入正式病历库。再比如医嘱审核功能，模型发现潜在问题时只推送“预警提示”，由临床药师或医生人工确认。这套机制比单靠提示词稳健得多。实际使用中医生对“辅助”和“决策”的边界非常敏感，产品里只要有一次跳过医生直接自动生成正式文件的场景，整个项目的信任感就会崩塌。

5.3 高可用与容灾方案

医院业务系统对可用性要求极高，AI服务不能成为单点故障。模型服务层面可以部署双副本，前面用Nginx做负载均衡和健康检查，当主节点异常时自动切换到备节点。模型文件本身要存放在共享存储或定期同步到备机的本地磁盘上，保证主备切换后模型还在。推理框架层面建议z做GPU故障监测，比如每半分钟检查一次API健康状态，连续失败三次就触发告警。

容灾演练要在正式上线前跑通，不能等故障发生才摸索。我组织过一次压测演练：人为把主服务进程杀掉，观察Nginx是否自动切流，结果是切换时间花了约30秒，期间HIS侧请求超时。后来我们优化了健康检查的间隔和失败阈值，把切换时间压到5秒内，对医生来说基本无感。这类问题不提前演练，真出事时CT室的医生半天打不开AI辅助界面，信息科会被投诉到崩溃。

6. 常见问题与避坑实录

6.1 显存不足时的排查思路

“模型启动时提示CUDA out of memory”可能是整个部署过程中最频繁的报错。我的排查顺序固定如下：先看是否所有显存都被其他进程占用，用nvidia-smi检查；再看量化精度是否过高，Q8跑不下的可以换Q4；然后看max-model-len是否设得太大；最后检查并发请求数，确认是否因为有多个模型同时加载在同一块GPU上，可以用--gpu-memory-utilization做显存配额。一步步缩小区间，定位远比盲目调参高效。

如果显存确实紧张，几个实用技巧很有效：第一，把上下文长度从8192降到4096，KV Cache占用能降低近一半；第二，换支持PagedAttention的vLLM而不是普通HuggingFace实现；第三，必要时启用CPU offload，允许部分权重放在内存中，但设置offload比例时尽量控制在10%以内，否则性能雪崩。低显存用户还有一个容易被忽略的点：模型服务默认的max_num_seqs过大，会把并发请求一次性全部塞进GPU，导致显存瞬间爆掉，调低这个参数往往立竿见影。

6.2 部署中的高频故障速查表

这个速查表是我根据真实运维记录整理的，概率从高到低排序。医院场景下最怕的不是单个故障，而是故障后信息科不知道从哪下手。所以我在交付时都会把这份表做成运维手册，同时提供一套基础监控脚本，定期检查GPU显存、服务响应时间和模型加载状态。运维手册比技术选型更能体现项目的成熟度。

6.3 几条踩出来的经验

最后分享几个平时不会写进文档里的教训。第一，别一上来就上70B大模型，先用7B甚至4B的小模型在整个数据链路上跑通，确认HIS调用、日志记录、输出回写都没问题，再升级成强模型。小模型发现问题的时间成本远比大模型低。第二，模型和推理框架的版本一定要锁死，不要内网外网混着升级。曾经一次模型版本升级后，同一句主诉生成的病历风格大变，临床主任立刻质疑系统不稳定，后来才发现是新版模型在prompt格式上有细微差异。第三，跟HIS厂商对接时，一定预留充足的联调时间。大模型服务本身的联调还好，卡脖子的往往是HIS侧改造进度，他们排期不定，项目就容易被拖。

做完这个项目后我最大的体会是：三甲医院里的AI大模型部署，本质上不是“显卡够不够”或“模型强不强”的问题，而是一整套围绕数据安全、业务流程和系统稳定性的工程问题。先跑通一条最小的链路，再慢慢把能力做厚，比一开始就贪大求全要可靠得多。如果你正打算在医院场景里落地大模型，希望这份配置指南能帮你少踩几个坑。