服务案例

院内影像AI推理平台实践

某三甲医院 · 影像科AI辅助诊断 · HX668V4双机双活

影像科每天1300例检查压在20位医生身上，夜间急诊CT从扫描到出报告平均42分钟。医院试过厂商的云端AI服务，按例收费，一年下来费用不低，影像出院的合规审核也一直卡着。这个项目的目标很直接：把AI推理搬回院内网，让报告在医生坐下之前就已经有了初步结论。

（应客户要求，案例中隐去医院名称与所在地，硬件配置与运行数据为项目实测。）

一、项目背景

该院为华南地区某三甲综合医院，编制床位1200张，影像科日均检查量约1300例：CT约780例、MR约260例、DR约260例。科内诊断医师20人，另有4家分院与2个区域影像中心接入远程阅片。

医院此前采购过厂商的AI辅助诊断服务，形态是三台小型推理盒子，每台一张16GB推理卡，只覆盖肺结节一个模型；其余病种仍靠人工。院内信息科对这套架构的评价是：模型能用，但吞吐上不去，且影像要送到第三方节点做推理，数据出院的合规说明每季度都要重写一遍。

二、为什么原来的方案跑不动了

项目组在立项前做了两周的现场测量，问题集中在这四处：

· 显存先于算力成为瓶颈。薄层胸部CT 400~600层，单例解压后体积250~350MB；带注意力门的3D U-Net单例推理占8~10GB显存。原来的16GB卡只能开1例并发，按每例90秒算，一台机器一小时最多40例，四个院区合起来远不够用。

· 网络把算力拖住了。PACS走DICOM over TLS，单图平均2.3MB，千兆链路理论125MB/s，但实测被HIS抢占后稳定在65MB/s。图像接收与模型推理串行执行，排队时间比推理时间还长。

· 7×24稳定性不达标。原先用的是消费级显卡，半年内出现2次显存故障。影像科的关键链路不允许单点，医院要求关键部件冗余、整机可在线维护。

· 合规与审计是硬门槛。影像数据不得出院内网；推理结果要写回PACS结构化字段；每次模型版本变更要留痕，便于回溯。

三、方案设计：把「等图」和「算图」拆成两条流水线

最终的架构没有追求「一张大卡搞定所有」，而是把整条路径拆成接收、缓存、推理、回写四段，让接收与推理互不阻塞：

· 轨道一（接收）：专用万兆网卡直连PACS存储，图像接收后立即落本地全闪NVMe缓存，缓存策略设为「预加载未来30分钟预约患者影像」，避免首例等待。

· 轨道二（推理）：GPU节点从NVMe读取图像，多模型并发推理，结果写回PACS元数据字段，医生工作站刷新即可看到标记。

计算节点选用了2台HX668V4（6U 8卡AI服务器），每台实配4张L40S 48GB，合计8卡、384GB显存；双机双活，通过负载均衡按检查类型分流，单机故障时40秒内接管。平台基于Intel Xeon 6处理器，配512GB DDR5-6400内存与PCIe 5.0 x16直连，保证图像解码、预处理与推理三段都在同一台机器内完成，不再有中间落盘等待。

存储上，4TB NVMe做热缓存（近2小时影像），26TB SSD做温缓存（近7天），长期归档仍留在医院原有PACS，不做重复建设。网络侧配25G双口上联影像网核心，划独立VLAN与HIS隔离，避免业务高峰互相挤占带宽。

软件栈采用Orthanc做DICOM网关（负责PACS与推理引擎之间的转换与路由），NVIDIA Triton做多模型并发服务，MONAI Deploy承载分割类模型，pydicom + dcm2niix完成预处理，全部容器化部署，模型版本可按容器镜像回滚。

四、硬件配置

· 计算节点：HX668V4 × 2台，Intel Xeon 6处理器，512GB DDR5-6400 ECC

· 加速卡：L40S 48GB × 4 / 台（合计8卡384GB显存），PCIe 5.0 x16直连

· 本地存储：4TB NVMe（热） + 26TB企业级SSD（温），RAID保护

· 网络：25G双口光口 × 2（业务 + 管理分离），25G交换机冗余上联

· 供电与散热：2200W 1+1冗余电源，机房冷通道送风，进风温度控制22±2℃

五、实施节奏

项目从进场到全量切生产共11周，关键节点如下：

· 第1~2周：机房上架、双路UPS接入、光模块与VLAN调试，与信息科逐条核对防火墙策略。

· 第3~5周：PACS对接联调，重点是DICOM回写字段对齐与检查优先级队列（急诊优先）。

· 第6~9周：回顾性三盲验证，随机抽取近3个月500例，由未参与部署的医师独立判读，统计模型提示采纳率与人工复核耗时，据此调整各病种阈值。

· 第10周：灰度上线，先接2个院区约30%检查量，连续跑两周观察稳定性。

· 第11周：全量切生产，并做两次故障演练（单机断电、单卡掉线），确认切换与恢复流程。

六、运行成效

上线后连续运行180天，主要指标如下：

· 单例端到端响应78秒（中位），原云端SaaS为3~5分钟；4例并发时最长96秒，仍在临床可接受范围内。

· 夜间急诊提速最明显。脑出血提示从「扫描到值班医师看到」的平均42分钟，缩短到6分钟，危重病例被优先推到阅片队列最前面。

· 吞吐：单节点可稳定6例并发，双机合计覆盖日均1300例，全量切换后未出现排队积压。

· GPU利用率：调度策略优化后从41%提升到62%~75%，夜间空闲时段用于批量重建历史影像。

· 可用性：180天无计划外停机；两次演练中单机故障切换耗时38秒，PACS回写无丢失。

· 成本：取消按例计费的云端服务后，按当前检查量测算，硬件投入约14个月收回。

七、这个项目留下的三条经验

第一，影像AI的选型要先看显存，再看算力。3D模型的显存占用是刚性的，卡再快、显存不够就是开不了并发。

第二，把接收和推理拆成两条流水线，比单纯堆卡更有效。这个项目里排队时间一度占端到端时长的六成，拆开之后才真正把GPU喂饱。

第三，冗余与审计不是附加项。医院这类场景，一次计划外停机的代价远高于多买半台机器的钱；而模型版本留痕，是能不能通过院内审核的前提。

（本文所述配置为该项目的实际交付形态，同类需求可按检查量、病种数量与院区规模做等比缩放。）