医疗影像AI里的DICOM影像分割任务，通常需要把医院PACS系统出来的CT、MR等序列文件做像素级病灶勾画。这类模型多为3D U-Net或Swin UNETR，参数量大且输入张量维度高，在普通CPU机器上单例推理要几分钟，根本无法满足门诊实时辅助的需求。把推理环节搬到带GPU的云服务器上，是当下多数第三方影像AI公司的标准做法。
一、云服务器实例与GPU选型
做DICOM分割不能只看显卡型号，还要看显存带宽和云服务器的磁盘吞吐。一次胸部CT增强扫描往往是300到600张512乘512的单通道切片，按batch size为1的3D推理，仅存放输入和中间特征图就可能占用10GB以上显存。因此最低建议从24GB显存的显卡起步，例如云厂商的A10、RTX 4090实例；若是多序列并发，则直接选用A100 40GB或80GB规格更稳妥。
除了GPU，云服务器的系统盘和数据盘也要用SSD云盘，并且最好挂载独立的高速数据盘专门放DICOM源文件和缓存的NIfTI格式。因为DICOM序列读取时大量小文件随机访问，机械盘或低IOPS云盘会让预处理成为瓶颈，GPU利用率掉到百分之二十以下。网络方面，如果推理服务要对接院内网络，选支持专线或VPN接入的可用区，避免公网传输患者数据带来的合规风险。
二、DICOM解析与预处理流程
原始DICOM不只是图像，还带有很多元数据，比如层厚、像素间距、窗宽窗位。直接把PixelData丢进模型会出错，必须先做正规化处理。常用方式是借助pydicom读取序列，按ImagePositionPatient排序，再转成ITK或SimpleITK的体数据，统一重采样到模型训练的体素间距，例如1乘1乘1毫米。
窗宽窗位截断也很关键。肺窗、脑窗、骨窗对应的HU值范围不同，如果推理模型是在特定窗位下训练的，云端服务就要在预处理阶段把原始HU映射到零一区间。下面给出常见模态的窗设置参考：
| 模态 | 窗宽 | 窗位 | 典型分割目标 |
|---|---|---|---|
| 胸部CT | 1500 | -600 | 肺结节、肺炎浸润 |
| 头颅CT | 80 | 40 | 脑出血、梗死核心 |
| 腹部MR T2 | 不适用 | 不适用 | 肝脏肿瘤、胰腺 |
预处理最好放在CPU线程池里做，不要占GPU资源。很多团队用Python的concurrent.futures把解码和重采样并行化，处理完再传显存，这样GPU几乎一直在算前向，效率提升明显。
三、推理框架与服务架构
模型训练多用PyTorch，但云端推理不一定非要原框架。可以用TorchScript或ONNX导出，再用TensorRT做图优化和显存复用，延迟能降三到五成。对于DICOM分割这种动态形状输入，TensorRT要开动态batch配置，并设好最优的profile范围，否则会频繁重新构建引擎。
服务侧建议用FastAPI包一层HTTP接口，后端起一个常驻的推理进程池。每个GPU卡对应一个worker，前面用Nginx或云负载均衡做请求分发。请求体里带上DICOM路径或已编码的实例UID，服务拉取后走预处理、推理、后处理，后处理包含连通域过滤和轮廓提取，最终返回NIfTI或JSON轮廓坐标。这样的结构方便水平扩容，哪台卡闲就派给哪台。
四、显存与并发调优
显存碎片是DICOM分割服务跑久了的隐形杀手。PyTorch默认缓存分配器不会及时释放，长序列推理后显存看着够用却报分配失败。可在服务里周期性调torch.cuda.empty_cache，或者把不同尺寸的输入做分桶，固定几种分辨率走不同队列，减少算子重选带来的临时占用。
并发数不是越多越好。单卡同时塞四个序列，显存可能爆，但只跑一个又浪费。经验值是按显存除以单例峰值再乘零点七做并发上限，留余量给后处理。配合云监控把GPU利用率、显存、接口耗时都打点，哪天突然变慢，先查是不是某家设备出的DICOM带私有标签导致解析变慢，而不是盲目升配置。
五、合规与落地注意事项
患者影像属于敏感个人健康信息，云服务器要选通过等保或HIPAA类认证的地域，磁盘加密开启，快照不跨区乱存。如果模型是用于辅助诊断，还要留推理日志和原始输入哈希，方便溯源。实际落地时，先拿历史脱敏数据做一轮端到端压测，确认单例时延和日处理量符合科室要求，再切真实流量。
整体来看，云服务器上配GPU推理服务做DICOM分割，核心不在模型本身，而在工程链路的每一环都贴着医学图像特点去设计。把解析、显存、并发和合规这四件事理顺，影像AI才真正从实验室走到阅片台边。