简介这套资源是一个面向医疗影像AI领域的深度学习示例工程围绕肝癌影像诊断流程提供数据预处理、数据集加载、模型定义与训练等核心模块适合具备Python基础、希望入门医学影像分析与TensorFlow应用的开发者。压缩包共7个文件以Python脚本4个py为主配合标签与资源说明文件及README文档整体仅8KB结构精简便于快速阅读源码与复现流程适用于课程设计、毕业设计或线下AI赛事快速上手场景。作者给出了完整的环境配置建议基于Anaconda安装TensorFlow 1.8并针对CPU/GPU做相应选择同时列出SimpleITK、OpenCV、scikit-image等影像处理库可有效减少复现时的踩坑成本。目前已有36人学习从数据预处理到模型训练的分工能让读者直观看到一个医学影像AI项目的基本骨架对理解数据标注、模型设计、文件组织具有实际参考价值。1. 肝癌影像AI诊断核心不在模型而在于数据拿到大数据医疗-肝癌影像AI诊断.zip这个压缩包第一反应不应该是解压跑 demo。医疗影像 AI 项目真正值钱的部分往往不在代码文件里而在数据管线、标注策略和部署方式上。这个标题背后是一整套工程链路从医院 PACS 系统导出的 DICOM 原始影像经过数据清洗、病灶标注、模型训练、推理优化最后压缩成一个可交付、可复现、可审计的 zip 包。对刚入行的工程师来说难点不在 PyTorch 怎么训练而是拿到一批没有标注的 CT 序列后怎么下手对做了多年的人来说难点在省内存的分布式训练、模型可解释性和交付物的哈希校验。这篇博文按我自己做医疗影像落地的路径来讲从数据预处理到模型训练再到打包交付每个环节给出能跑的命令和参数。2. DICOM 数据管线从医院原始影像到可训练的张量2.1 用 pydicom 批量解析 DICOM 序列与元数据筛选肝癌诊断最常用的是腹部增强 CT一个病例通常会扫出动脉期、门脉期、延迟期等多个序列。医院给的 DICOM 文件按检查打包每个序列散落在不同目录里文件名可能是乱码也可能是一家医院一套命名规则。我一般不会一上来就训练而是先把 DICOM 的元数据拉出来看一眼确认每个序列是什么、层厚多少、像素间距是否一致。import pydicom from pathlib import Path dicom_dir Path(/data/liver_ct/patient_001) for dcm_path in sorted(dicom_dir.glob(*.dcm))[:5]: ds pydicom.dcmread(dcm_path, stop_before_pixelsTrue) print( ds.PatientID, ds.SeriesDescription, ds.SliceThickness, ds.PixelSpacing, ds.SeriesInstanceUID, )stop_before_pixelsTrue是读取元数据的关键参数只加载 DICOM 头不加载像素矩阵批量扫描几百个文件时速度快得多内存占用可以忽略。拿到这些字段之后按SeriesInstanceUID分组同一组内的 DICOM 文件就是一个完整的 3D 体数据。PixelSpacing如果同一个序列里出现不同值说明扫描过程发生位移或重建口径不一致这种序列直接剔除否则后面重采样会引入形变。不同医院的扫描协议差异很大层厚从 0.5 mm 到 5 mm 都有可能。为了后续模型输入尺寸统一需要把所有序列重采样到同一个体素间距常见做法是重采样到 1.0 × 1.0 × 1.0 mm 或 1.5 × 1.5 × 2.0 mm。层厚太粗的序列小的病灶可能只有两三层的信号重采样以后边界会模糊这种数据宁可不用。2.2 批次效应对齐窗宽窗位与 HU 值截断CT 影像的像素值是亨氏单位HU肝脏实质大约在 40 到 60 HU肿瘤在增强扫描的动脉期会明显高出这个范围门脉期又可能低下来。直接做归一化时如果不做 HU 截断空气、骨骼、金属伪影会拉大数值分布模型学到的对比度会偏掉。注意肝脏 CT 的三期序列必须分开处理不要把动脉期和延迟期混在一个通道里做归一化。很多入门项目翻车就翻在这里。我一般会把每个体数据的 HU 值截断到[-200, 200]然后线性映射到[0, 1]。这个窗口能保留肝实质、肿瘤增强和周围血管的信息同时去掉骨骼和金属伪影的极端值。肿瘤负荷评估时有些团队会额外加一个[-50, 150]的窗口作为第二个输入通道相当于给模型提供“窄窗”视角。import numpy as np def normalize_ct(volume, low-200, high200): volume np.clip(volume, low, high) volume (volume - low) / (high - low) return volume.astype(np.float32)np.clip直接截断极端值归一化之后用astype(np.float32)把数据转成单精度浮点既能喂给 PyTorch又不会把显存撑爆。一个 512 × 512 × 300 的 CT 序列float32 大约 300 MB如果用 float64 会直接翻倍到 600 MB多序列加载时内存很容易不够。2.3 标注数据不足弱监督与预训练两个现实路线肝癌影像公开数据集不少但真正带像素级标注的非常少而且标注标准不一致有的标注肿瘤主体有的连子灶、血管侵犯都画进去。从医院拿到的数据能有个几十例完整标注就烧高香了。数据量少的时候两个路线比较现实。第一是自监督预训练。用无标注的 CT 数据做重建任务让模型先学解剖结构再用少量标注数据微调。nnU-Net 官方自监督方案或者简单的 masked autoencoder 都可以预训练阶段不需要标注计算量也可控。第二是半监督交叉监督。两个结构相同但初始化不同的模型分别对无标注数据预测把分歧小的区域当成伪标签加入训练。这个策略在肝脏肿瘤分割的公开评测里效果很稳尤其是门脉期和延迟期的肿瘤边界对比度低交叉监督能明显减少边界抖动。方案所需标注量显存开销效果备注直接训练 nnU-Net100 例以上单卡 16 GB 可行数据质量高时效果最好自监督预训练 微调3050 例预训练需多卡单卡微调性价比高交叉伪标签半监督30 例左右两张同规格显卡对边界模糊病灶提升明显如果标注只有十几例我的建议是先做自监督预训练再用交叉伪标签做第二轮扩充。标注少的情况下硬上大模型过拟合很快——训练集 Dice 能到 0.9验证集直接跌回 0.6。3. 病灶分割与多卡训练nnU-Net 与 PyTorch DDP 实战3.1 选 nnU-Net 而不是自研网络的理由医学图像分割领域nnU-Net 是一个绕不开的基线模型。它的核心思想是“根据数据集自动配置网络结构、训练策略和数据增强”不用人为调参就有不错的表现。对于肝脏和肿瘤分割这个任务nnU-Net 的 3D full resolution 配置是默认选择输出结果稳定出问题也好排查。Swin UNETR 这类 Transformer 结构虽然在一些公开基准上有好看的涨点但对训练数据量的要求更高容易在中小规模数据集上跑不过 nnU-Net。我自己的团队做项目时第一版永远是 nnU-Net先拿到一个可信的基线再考虑换结构。如果换了 Transformer 结构一定要在同一个数据划分下跟 nnU-Net 对比否则没法判断涨点是网络带来的还是调参碰运气。nnU-Net 训练结束后会自动保存最有价值的模型检查点还会输出推理后的概率图。拿到概率图之后可以做不确定性分析这是自研网络通常没有的便利。对肝癌的术前规划场景医生其实很需要看到模型对病灶边界哪里没把握概率图比一个孤零零的分割掩码有用得多。3.2 用 PyTorch DDP 把单卡脚本改造成多卡训练当训练数据从几十例扩展到几百例单卡训练的时长会变得不可接受。一个典型的 nnU-Net 3D full resolution 配置在 80 GB 显存的 A100 上训练一个 epoch 需要几分钟到十几分钟几百个 epoch 跑下来就是十几个小时。这个时候要用多卡并行。PyTorch DistributedDataParallel 是当前最稳妥的多卡训练方案PyTorch 官方推荐优先使用 DDP 而不是 DataParallel因为 DDP 每张卡持有独立模型副本梯度同步效率高。启动多卡训练的常用方式是通过torchrun命令它负责设置环境变量、拉起每个进程并保持进程间通信。对我来说日常最稳定的是在单机多卡环境里使用torchrun --nproc_per_node多机场景需要额外设置--master_addr和--master_port工作量会增加不少。torchrun --nnodes1 --nproc_per_node4 --master_port29500 \ train_ddp.py --config config/liver_ct.yaml--nproc_per_node4表示当前节点使用 4 张 GPU--master_port29500是通信端口同一台机器上同时跑多个训练任务时记得改掉否则会报端口冲突。train_ddp.py内部需要做的关键事情是init_process_group初始化通信后端然后通过torch.cuda.set_device(local_rank)把当前进程绑定到对应 GPU最后用DistributedDataParallel包装模型。local_rank不是从命令行直接传的而是通过torchrun注入的环境变量LOCAL_RANK获取。import torch import torch.distributed as dist from torch.nn.parallel import DistributedDataParallel as DDP dist.init_process_group(backendnccl) local_rank int(os.environ[LOCAL_RANK]) torch.cuda.set_device(local_rank) model UNet3D() model DDP(model, device_ids[local_rank], output_devicelocal_rank)backendnccl是 GPU 通信最常用的后端通信速度最快。CPU 训练或调试时可以用gloo但正式训练不要用。device_ids[local_rank]必须与当前进程绑定的 GPU 一致否则运行时会报设备不匹配的错误。多卡训练时 batch size 的调整要特别小心。DDP 里每张卡独立处理各自的 batch全局 batch size 等于单卡 batch size 乘以显卡数。如果单卡 batch size 是 24 卡就相当于 8。学习率要不要跟着放大取决于优化器和学习率调度策略。使用 Adam 类优化器时我一般不改学习率使用 SGD 的 momentum 方法时会调大一点具体是乘以sqrt(num_gpus)还是直接乘以num_gpus要按验证集的损失变化来定没有放之四海皆准的规则。分布式训练里最容易忽略的是数据加载的 sharding。每个进程必须只读数据集的 1/44 卡时否则同一个 batch 的数据会被多个卡重复读取相当于多卡并行白做。在Dataset里通过torch.utils.data.distributed.DistributedSampler做切分它会根据当前进程的rank自动分配不同的样本子集。每个 epoch 还需要调用sampler.set_epoch(epoch)确保每个 epoch 数据打乱顺序不一样。3.3 混合精度训练与显存不足时的应急策略训练 3D 分割模型显存是最容易卡的瓶颈。输入尺寸 512 × 512 × 128单卡 batch size 设为 1 就已经吃满 24 GB 显存。混合精度训练是个有效的办法PyTorch 的torch.cuda.amp提供自动混合精度前向传播用 FP16反向传播时梯度用 FP32 更新显存占用大约能降 30% 到 40%。from torch.cuda.amp import GradScaler, autocast scaler GradScaler() for batch in dataloader: optimizer.zero_grad() with autocast(): outputs model(batch[image]) loss criterion(outputs, batch[label]) scaler.scale(loss).backward() scaler.step(optimizer) scaler.update()GradScaler的作用是防止 FP16 下的梯度下溢scaler.scale(loss)会让损失乘以一个缩放因子反向传播后再还原梯度。使用混合精度时不能用optimizer.step()直接更新参数必须走scaler.step(optimizer)直到scaler.update()才会更新缩放因子。FP16 训练中如果 loss 变成 NaN优先检查是不是学习率过大其次检查数据里有没有异常的 NaN 体素。医疗影像里金属伪影有时会产生极端值归一化之前做一个np.nan_to_num能规避不少问题。显存实在不够时还有几个应急手段。第一是减小 patch size比如从 192 × 192 × 128 降到 128 × 128 × 96这是最直接有效的办法。第二是启用 gradient checkpointing用 PyTorch 的torch.utils.checkpoint包装模型的某些层前向传播时不保存中间激活反向传播时重新计算。第三是把 batch size 减小到 1然后做梯度累积每 4 个 step 做一次优化器更新等价于 batch size 4 的训练效果。这三个手段我按顺序试能解决 90% 以上的显存不足问题。提示数据集只有几十例时不要盲目增大输入 patch size。patch 越大网络越容易把背景学进去小肿瘤的召回率反而可能下降。4. 推理优化与 zip 包交付从 PyTorch 模型到可复现产物4.1 导出 ONNX 时的动态轴与算子兼容检查训练完成后PyTorch 模型要部署到推理环境最常见的方式是转成 ONNX 格式。ONNX 是跨框架的中间表示转换成 ONNX 后可以进一步用 TensorRT、OpenVINO 或 ONNX Runtime 加速。导出过程看起来简单实际有细节需要留意不指定dynamic_axes输出的 ONNX 模型输入尺寸是固定的换了 batch size 或图像尺寸就不兼容。医疗影像推理时 slice 数量不确定必须把深度方向设为动态轴。torch.onnx.export( model, dummy_input, liver_seg.onnx, input_names[input], output_names[output], dynamic_axes{input: {0: batch, 2: depth, 3: height, 4: width}, output: {0: batch, 2: depth, 3: height, 4: width}}, opset_version17, )opset_version17适合较新版本的 PyTorch也兼容目前主流的推理引擎。导出之后用onnxruntime跑一次推理对比 PyTorch 输出误差在 1e-3 量级属于正常。如果误差偏大检查模型里有没有自定义算子比如某个特殊的上采样方式ONNX 导出时可能被拆成多个基础算子导致精度漂移。dynamic_axes里的depth、height、width三个维度全部设置为动态意味着任意尺寸的输入都能跑但 TensorRT 优化时会因为动态尺寸而放弃部分层融合推理速度会比静态尺寸慢一些。4.2 用 TensorRT 做 FP16 推理加速ONNX 直接跑在 CPU 或普通 GPU 上速度可能已经够用但如果要做实时辅助诊断每个病例的推理时间要控制在几秒内。先用 ONNX Runtime 做基线性能测试看瓶颈在哪个环节通常的耗时大头是 softmax 和最后的 argmax 层。trtexec是 TensorRT 自带的命令行工具不需要写代码就能完成模型转换和性能测试。转换时指定 FP16 精度可以显著提升速度。但 FP16 在某些算子下可能出现精度损失分割任务建议先跑一遍验证集对比 FP16 和 FP32 输出的 Dice 差异如果下降超过 0.5%就换回 FP32 或做 INT8 量化。trtexec --onnxliver_seg.onnx \ --saveEngineliver_seg_fp16.engine \ --fp16 \ --minShapesinput:1x1x96x96x96 \ --optShapesinput:1x1x128x128x128 \ --maxShapesinput:1x1x192x192x192 \ --workspace4096--minShapes、--optShapes、--maxShapes对应动态尺寸的范围TensorRT 会在这个区间内做优化。--workspace4096是 TensorRT 优化时允许使用的显存上限单位 MB。如果构建时显存不够会报 workspace 不足的错误。转换成功后运行时用同样的三个 shapes 创建 execution context输入尺寸超出maxShapes会直接报错。实际部署时我习惯先把输入影像自动 padding 到 16 的倍数避免因尺寸对齐问题触发额外开销。4.3 压缩包里的依赖锁定和权重可复现说到大数据医疗-肝癌影像AI诊断.zip这个压缩包本身我的理解是交付方把代码、模型权重、配置文件、说明文档打包在一起接收方拿过去解压就能复现。这个场景很常见但很多交付物存在两个致命问题。第一是代码里没有依赖锁定。pip install torch看起来没问题但训练时的 PyTorch 版本和接收方环境不一致会出现推理结果完全不同的情况。常见做法是用pip freeze生成requirements.txt但这只锁了版本号没锁传递依赖。更可靠的是用 Poetry 或 uv 这类工具生成poetry.lock或uv.lock精确到每个子依赖的版本。第二是模型权重文件没有校验信息。AI 模型权重是二进制文件压缩包传输过程中如果出现损坏或篡改模型推理结果会产生细微偏差。我一般在模型目录放一个checksums.txt记录每个权重文件的 SHA256 校验值解压之后先跑一遍校验再干活。sha256sum liver_seg.onnx liver_seg_fp16.engine checksums.txt cat checksums.txtsha256sum是 Linux 和 macOS 自带的命令输出格式是“哈希值 文件名”。接收方拿到压缩包后在解压目录里执行sha256sum -c checksums.txt看到每个文件后面跟OK说明文件完整。这一步成本极低但能避免大量因为权重文件损坏导致的“模型效果不对”排查。5. 验证交付压缩包不是终点模型回归与数字签名才是收尾5.1 用留出集建立推理回归基线从 checkpoint 到交付能用的模型中间还差一个验证环节。我见过不少项目模型在训练集上跑得飞起交付给临床团队之后完全不是那么回事。问题出在两个地方一是训练时代码里用了一些在线数据增强推理时忘了关掉二是模型输出的概率图和最终分割掩码之间阈值设置不对。交付前我会固定一个验证流程。先用一个完全没参与训练的留出集大小在 10 到 20 例左右跑一次逐例推理保存每个病例的 Dice、HD95、肿瘤召回率作为回归基线。下次换模型结构或训练参数时在相同留出集上重新推理对比基线。如果新模型某项指标掉了马上回滚不用主观判断。import onnxruntime as ort import numpy as np sess ort.InferenceSession(liver_seg_fp16.engine, providers[CUDAExecutionProvider]) input_name sess.get_inputs()[0].name prob sess.run(None, {input_name: volume.astype(np.float32)})[0] mask (prob 0.5).astype(np.uint8)这段代码说明了一件容易被忽略的事ONNX Runtime 的providers参数默认顺序是[CUDAExecutionProvider, CPUExecutionProvider]如果 CUDA 可用就用 GPU否则回退到 CPU。做批量推理时这个配置可以在不回退的情况下稳定跑 GPU。分割阈值 0.5 是默认值实际项目中我会在留出集上扫一遍[0.3, 0.4, 0.5, 0.6]这几个阈值画一个简单的 DICE-阈值曲线选在平台期中间的数值。如果肿瘤比较小往往 0.3 到 0.4 的阈值能在保持较少假阳性的同时获得更高召回。5.2 用 cosign 对压缩包做签名保证交付链路可信校验和只能证明文件没损坏不能证明文件是交付方本人给的。在医院和第三方数据合作场景里交付链路的可信度越来越受重视。常见的做法是用 cosign 对压缩包做数字签名接收方验签通过后才确认这个包确实来自交付方且内容未被篡改。这个流程在合规审查里经常被问起代码里签一个名比口头解释“我们保证了完整性”有说服力得多。如果团队还没有完善的签名基础设施用 gpg 对 zip 包做签名是更轻量的替代方案。一次签名生成的.sig文件会随压缩包一起交付接收方导入公钥后运行gpg --verify就能完成校验。整个流程的核心是传递公钥的过程——建议直接交给对接方的安全负责人而不是通过普通的网盘链接传递否则签名的意义会打折扣。gpg --detach-sign --armor liver_dataset_v1.0.zip gpg --verify liver_dataset_v1.0.zip.asc liver_dataset_v1.0.zip--detach-sign生成独立的签名文件不修改原压缩包。--armor把签名转成 ASCII 文本格式方便在邮件或工单里直接传输和存档。整个流程的完整链路是压缩、签名、发布校验文档、接收方验签、解压后跑sha256sum -c确认完整性最后做模型推理回归测试。这个打包和验证的流程比单纯提供一个 zip 包多花十分钟换来的是“这个包是谁给的、里面的东西有没有被动过、模型跑了效果对不对”三个问题的明确答案。对于要进入医院或第三方机构做试点评估的影像 AI 项目这些答案就是交付的基本要求也是后续故障排查的第一份依据。本文还有配套的精品资源点击获取