1. 医学影像AI交付工程导论
医学影像AI的研发与落地之间，存在一条常被低估的“最后一公里”。在实验室里，一个分割模型在公开数据集上达到 0.90 的 Dice 系数并不罕见；但当它被部署到某家三甲医院的 PACS 旁、接入真实 DICOM 流、面对不同厂商的 CT 层厚与重建核、并需要在 3 秒内返回结果时，问题会成倍出现。交付工程要解决的，正是从“算法能跑通”到“临床可稳定使用”之间的全部工程问题。
一、全链路视角：算法研发与临床落地之间的鸿沟
把医学影像AI的完整生命周期拆开看，它至少包含六个环节：数据接入、预处理、模型推理、后处理、结果回传、运行监控。研发阶段通常只关注中间三步，且往往在离线环境中用固定格式的 NIfTI 或预处理好的张量进行验证。而临床落地时，输入是 PACS 推送的 DICOM 序列，带有私有标签、非均匀层厚、金属伪影；输出需要转成结构化报告或 DICOM SR，并回写到医生工作站。这条链路上任何一环的格式、时序或性能偏差，都会导致“模型没问题，系统不可用”。
更具体地说，交付工程要面对四类典型挑战。第一是数据异构：同一检查在不同设备上可能产生 512×512 与 768×768 两种矩阵，层厚从 0.625 mm 到 5 mm 不等，窗宽窗位也因扫描协议而异。第二是性能约束：急诊场景下端到端延迟要求常被设定在 5 秒以内，而一个未优化的 3D 分割模型单次推理就可能超过 20 秒。第三是环境漂移：CUDA 驱动、cuDNN 版本、Python 依赖、模型权重文件，任何一项在开发机与生产服务器之间不一致，都可能引发难以复现的推理错误。第四是合规与可追溯：医疗场景要求每一次推理都可审计——谁在什么时间、对哪份检查、用了哪个模型版本、输出了什么结果。
二、云原生交付的核心价值
云原生并非把系统“搬到云上”这么简单，它提供的是一组让交付可复制、可观测、可回滚的工程能力。对医学影像AI而言，最直接的价值体现在四个方面。
容器化封装环境。把推理服务、依赖库、模型权重、预处理脚本一起打包成镜像，镜像一旦构建完成，其内容在任何支持 OCI 标准的运行时中行为一致。开发机上验证通过的镜像，可以直接在医院的边缘服务器或私有云上启动，消除了“在我机器上是好的”这类问题。实践中，一个推理镜像通常基于 nvidia/cuda:12.1.1-cudnn8-runtime-ubuntu22.04 这类基础镜像，再叠加 Python 依赖与模型文件，最终体积控制在 8～15 GB 是常见范围。
编排与弹性。Kubernetes 让推理服务以 Deployment 形式声明副本数、资源请求与限制。当医院白天门诊量上升、DICOM 任务队列积压时，可以通过 HPA 按队列长度或 GPU 利用率自动扩容；夜间则缩容以释放资源。对于多院区部署，同一套 Helm Chart 只需替换 values 中的院区标识、PACS 地址与模型版本，即可完成差异化交付。
可观测性。云原生栈天然提供指标、日志、追踪三条观测路径。推理服务暴露 Prometheus 指标，如 inference_latency_seconds、gpu_memory_used_bytes、dicom_receive_total；日志记录每例检查的 StudyInstanceUID 与模型版本；追踪则串联从 DICOM 接收到结果回写的完整调用链。这三者共同支撑故障定位与性能调优。
持续交付与回滚。模型更新不再靠手工替换文件，而是通过镜像标签与 GitOps 流程推进。新模型先进入灰度环境，用历史数据回放验证输出一致性，再逐步放量。一旦线上指标异常，回滚到上一版本镜像即可，整个过程可在分钟级完成。
三、课程实战项目与工具链总览
本课程以一个贯穿始终的实战项目为载体：肺结节CT筛查AI的云原生交付。项目输入为胸部CT平扫 DICOM 序列，输出为结节位置、尺寸与恶性概率，最终以结构化报告形式回写 PACS。选择这个场景，是因为它同时覆盖了 3D 图像处理、多模型串联、性能敏感和合规审计四类典型问题，具有足够的代表性。
项目将分阶段推进：先完成单例推理服务的容器化，再接入 DICOM 网关与任务队列，随后部署到 Kubernetes 并配置 HPA，最后搭建监控看板与灰度发布流程。每个阶段都有可运行的交付物，而不是停留在架构图层面。
工具链方面，课程使用以下核心组件，它们共同构成一条从开发到生产的完整路径：
| 环节 | 工具 | 在项目中的用途 |
|---|---|---|
| 模型开发 | PyTorch + MONAI | 3D 结节分割与分类模型训练、数据增强 |
| 模型导出 | ONNX Runtime / TorchScript | 将训练模型转为可部署格式，验证数值一致性 |
| 容器化 | Docker + NVIDIA Container Toolkit | 封装推理服务与 GPU 运行时依赖 |
| 编排 | Kubernetes + Helm | 部署推理服务、配置 HPA 与多院区差异化 |
| DICOM 接入 | pynetdicom / Orthanc | 接收 PACS 推送、解析 DICOM 标签、回写结果 |
| 可观测性 | Prometheus + Grafana + Loki | 采集推理延迟、GPU 显存、任务队列长度与日志 |
| 持续交付 | GitLab CI + Argo CD | 镜像构建、灰度发布、版本回滚 |
需要强调的是，云原生交付不是银弹。它解决的是环境一致性、弹性、可观测性和可回滚性，但模型本身的精度、推理速度的算法优化、以及临床工作流的适配，仍然需要算法工程师与交付工程师协作完成。本课程的目标，是让读者具备把算法“送进临床”的工程能力——知道每一步该用什么工具、该看什么指标、该在什么地方设检查点，以及当链路中断时如何快速定位。
接下来的章节将沿着这条链路逐层展开：从容器镜像的构建细节，到 DICOM 网关的配置，再到 Kubernetes 编排与监控告警。每一层都会给出可执行的配置片段、示例参数和结果判读方法，帮助读者在自己的环境中复现并调整。