华为云联合瑞金医院发布瑞智病理大模型 RuiPath 2.0这标志着病理 AI 正式从“单点工具”进入“系统化平台”阶段。很多人以为病理大模型的难点只是算法但临床病理科的实际情况要复杂得多一张全切片病理图像的分辨率往往达到亿级像素单文件可能超过 1GB标注依赖资深医生不同医院的染色条件和扫描设备也不一致。发布一个模型只是第一步真正决定系统能否长期运转的是数据管理、算力调度、推理服务、评估回滚、隐私安全和科室工作流之间的配合。这篇文章从工程视角拆解病理大模型落地链路并以华为云 CCE 和华为云 Stack 场景为例给出一套可复现的推理服务搭建思路。适合医疗 AI 平台工程师、病理信息化团队和数据科学家阅读学完后能围绕模型文件设计出完整的部署、验证和运维体系。1. 病理大模型解决的不是“识别一张图”而是“重建一条诊断链路”1.1 从单任务模型到大模型病理 AI 的边界发生了变化早期病理 AI 以单癌种单任务为主比如只识别某个淋巴结区域是否发生转移或者只分割某一种腺体。实现方式通常是把 WSI 切成小块再用分类网络逐个预测。这种方案门槛低但问题很突出一个模型只解决一个问题染色条件不同、扫描仪不同、医院不同性能就可能下降。因为模型从切块中学到的大多是颜色和纹理统计特征而不是病理学意义上的结构上下文。大模型路线则不同。RuiPath 2.0 所属的病理大模型一般会在大规模病理图像上先做预训练让模型学习通用的病理视觉表示再通过少量标注数据适配癌种识别、组织分割、突变预测等具体任务。这个逻辑与自然语言处理大模型相似先用海量数据学会通用规律再在具体任务上微调。对技术团队来说这种转变意味着两件事第一模型参数量和计算量变大不能再指望单机脚本扛住全部推理第二模型不再是静态产物它需要根据新数据、新任务和医生反馈持续更新所以后端必须配套模型版本管理、数据版本管理和可回滚的推理服务。理解这一点很重要。病理医生最终看到的不是模型内部的高维向量而是“某个坐标区域为什么被判为阳性”“周围腺体结构是否支持这个结论”“需不需要考虑罕见亚型”。如果系统只返回一个概率价值非常有限。常见做法是把模型输出与切片坐标、形态学特征和结构化报告结合形成辅助诊断链路。不同模型具体怎么实现不一定相同但“重建诊断链路”是所有病理大模型应用都要面对的方向。1.2 数据、模型、平台和应用四个层次缺一不可病理大模型落地时至少涉及四个技术层次。数据层包括病理切片文件、诊断报告、随访结果和标注数据。它是整个系统的基础。病理切片格式多样常见有 .svs、.ndpi、.mrx 等必须统一为平台可读的格式。报告中还包含自然语言诊断结论可以用来训练多模态模型或建立知识检索。表示层指模型本身包括视觉编码器、多模态对齐层和下游任务头。预训练模型权重通常很大推理时需要 GPU 和专门的推理框架。这个层次要解决的问题是模型的输入输出格式是什么推理时间是毫秒级还是秒级单卡能承载多少并发。平台层解决调度问题。模型推理服务需要以容器方式运行在 Kubernetes 集群上由 CCE 或华为云 Stack 提供 GPU 调度、弹性伸缩和日志采集。平台层还要负责权限控制、限流和审计保证医院内网环境下的安全合规。应用层是最终面向医生的界面包括切片浏览、结果叠加、报告生成和人工修正。应用层设计要符合病理医生阅片习惯不能把内部接口结果直接暴露给医生。四层缺一不可。传统项目容易只做第二层把模型文件发给信息科却忽略数据规范、容器平台和医生工作流最终上线后无法维护。1.3 工程团队要承担什么职责病理大模型的落地需要多角色协作。数据工程师负责把历史 WSI 处理成训练和测试数据集同时做好患者隐私脱敏。算法工程师负责预训练、微调、评估和模型导出。平台工程师负责构建镜像、编写部署清单、配置监控告警。病理医生负责定义临床问题、标注金标准和审核模型输出。只有把这几类工作放到同一条流水线里才能形成数据回流和模型迭代闭环。2. 部署前先想清楚你需要的是一套推理平台不是一个模型文件2.1 病理大模型部署的典型架构一个可用的病理大模型推理平台调用链通常是切片存储、预处理服务、GPU 推理服务、应用网关、医生工作台、审计系统。切片存放在分布式存储或对象存储中预处理服务负责把 WSI 切成 tile推理服务接收 tile 并返回结构化结果医生工作台负责展示并记录人工修改。在学习和单机验证阶段可以把链路简化为一个 Python 脚本。但进入医院环境后容器化几乎是必选方案。原因有四GPU 资源需要统一调度不能绑定某台物理机。多个模型版本需要并行灰度不能停机替换。医院白天门诊存在并发峰值推理服务需要弹性扩容。日志、监控、权限和审计需要统一平台管理。华为云 CCE 正好覆盖这些需求。它提供了容器集群、GPU 节点池、负载均衡和监控能力适合承载模型推理服务。2.2 学习环境与生产环境的差异要提前拉开很多团队先用开发机跑通模型然后直接去生产环境部署结果在镜像、依赖、存储和权限上反复踩坑。下面是两类环境的典型差异项目学习验证环境医院生产环境数据规模几十张 WSI本地磁盘全院多年切片TB 到 PB 级GPU 资源单卡即可多节点 GPU 集群预留峰值部署方式单机 Docker 或脚本华为云 CCE 或华为云 Stack 容器平台模型更新手动替换文件灰度发布、版本回滚权限控制开发人员可访问按角色细粒度审计监控基本日志延迟、成功率、队列深度、资源告警隐私合规脱敏数据院内私有化数据不出域如果选择华为云 Stack 做私有化部署要提前查阅对应版本的部署文档确认 Kubernetes 版本、GPU 驱动、容器网络和存储类型是否一致。开发机上验证过的 CUDA 版本并不能直接等同于生产镜像版本很多容器启动失败都源于基础镜像与驱动不匹配。2.3 最小工程目录设计建议按下面的目录组织代码和部署文件pathology-inference/ ├── docker/ │ ├── Dockerfile │ └── requirements.txt ├── kubernetes/ │ ├── deployment.yaml │ └── service.yaml ├── src/ │ ├── api.py │ ├── preprocess.py │ └── model_loader.py ├── models/ │ └── mock_model.pt └── tests/ ├── test_api.py └── test_preprocess.pydocker目录放置镜像构建文件kubernetes目录放置部署清单src目录放推理服务源码models目录只放用于验证的 demo 权重真实环境建议把权重放到对象存储或模型仓库通过挂载方式加载避免每次发布重新打镜像。3. 在华为云 CCE 上部署病理模型推理服务示例3.1 准备模型文件与容器镜像下面示例使用一个 mock 模型演示完整流程真实项目需要替换为训练好的权重。Dockerfile 编写如下FROM nvcr.io/nvidia/pytorch:23.10-py3 WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY src/ ./src/ COPY models/ ./models/ ENV MODEL_PATH/app/models/mock_model.pt ENV DEVICEcuda EXPOSE 8000 CMD [uvicorn, src.api:app, --host, 0.0.0.0, --port, 8000]requirements.txt 可以这样写fastapi0.111.0 uvicorn[standard]0.30.1 openslide-python1.3.1 pydantic2.7.1示例里把模型文件复制进镜像是为了快速演示。生产环境建议让镜像保持“代码不可变”模型文件通过 ConfigMap 之外的持久卷或模型仓库加载这样更新权重时不需要重新构建整个镜像。3.2 病理推理 HTTP 服务接口使用 FastAPI 实现一个最小推理接口包含健康检查和推理两个端点# src/api.py from typing import List from fastapi import FastAPI from pydantic import BaseModel app FastAPI(titlepathology-inference) class TileItem(BaseModel): tile_id: str image_base64: str class InferRequest(BaseModel): items: List[TileItem] threshold: float 0.5 class InferResponse(BaseModel): results: List[dict] model_version: str class MockPathologyModel: def predict_batch(self, tiles): results [] for t in tiles: results.append({ tile_id: t.tile_id, pred_class: tumor, confidence: 0.82, }) return results model MockPathologyModel() app.get(/health) def health(): return {status: ok} app.post(/v1/infer, response_modelInferResponse) def infer(req: InferRequest): # 真实项目中这里需要完成 base64 解码、归一化、模型推理和后处理 results model.predict_batch(req.items) return InferResponse(resultsresults, model_versionmock-1.0)接口设计需要关注三点。第一输入使用tile_id而不是完整切片路径因为病理切片文件不应直接暴露给外部调用方。第二图片传输采用 base64 字符串适合内部服务间小批量传输但要注意请求体大小限制。第三模型加载要在进程启动时完成不能每次请求都重新加载权重。3.3 编写 Kubernetes 部署清单创建 Deployment 和 ServiceapiVersion: apps/v1 kind: Deployment metadata: name: ruipath-inference namespace: medical-ai spec: replicas: 1 selector: matchLabels: app: ruipath-inference template: metadata: labels: app: ruipath-inference spec: containers: - name: inference image: registry.example.com/pathology/ruipath-inference:latest ports: - containerPort: 8000 name: http env: - name: MODEL_PATH value: /app/models/mock_model.pt - name: DEVICE value: cuda resources: limits: nvidia.com/gpu: 1 requests: cpu: 2 memory: 8Gi readinessProbe: httpGet: path: /health port: http initialDelaySeconds: 10 periodSeconds: 5apiVersion: v1 kind: Service metadata: name: ruipath-inference namespace: medical-ai spec: selector: app: ruipath-inference ports: - port: 80 targetPort: 8000配置里有两个关键点resources.limits声明了需要一张 GPU调度器会把 Pod 调度到有 GPU 的节点readinessProbe用/health做就绪检查避免流量打到尚未加载完模型的 Pod 上。3.4 执行部署并验证先创建命名空间再应用清单kubectl create namespace medical-ai kubectl apply -f kubernetes/deployment.yaml kubectl apply -f kubernetes/service.yaml kubectl rollout status deployment/ruipath-inference -n medical-ai kubectl get pods -n medical-ai -o wide查看 Service 地址kubectl get svc -n medical-ai然后发送推理请求curl -X POST http://service-ip/v1/infer \ -H Content-Type: application/json \ -d { items: [ { tile_id: case_001_tile_0_0, image_base64: base64字符串 } ], threshold: 0.5 }正常返回结果如下{ results: [ { tile_id: case_001_tile_0_0, pred_class: tumor, confidence: 0.82 } ], model_version: mock-1.0 }这里的部署流程只是验证服务链路真实病理业务还需要接入切片读取和预处理模块。4. 病理切片预处理和推理接口不能照搬通用图像接口4.1 WSI 不是普通图像普通图像识别任务通常把整张图缩放到固定尺寸但病理 WSI 无法这样做。一张 40 倍物镜下的 WSI 可能包含几十亿像素直接缩放到 224×224 会丢失几乎所有细胞结构信息。因此推理前必须把 WSI 切成合适大小的 tile再分批送入模型。读取 WSI 推荐使用 OpenSlide它支持多种格式并能按不同分辨率层级读取import openslide wsi_path case_001.svs slide openslide.OpenSlide(wsi_path) level_count slide.level_count level_dimensions slide.level_dimensions print(level_count, level_dimensions) tile_size 512 overlap 64 for x in range(0, slide.dimensions[0], tile_size - overlap): for y in range(0, slide.dimensions[1], tile_size - overlap): tile slide.read_region((x, y), 0, (tile_size, tile_size)).convert(RGB) # 这里将 tile 交给预处理或直接送入模型read_region在切片边缘会返回黑色背景需要根据坐标判断是否为有效区域。不要使用PIL.Image.open直接读取 WSI那会内存溢出或超时。4.2 tile 切块参数不是越大越好切块参数直接影响显存占用和推理质量。常见参数如下参数含义建议初始值影响tile_size切块边长256-1024太小上下文不足太大显存压力大overlap相邻切块重叠像素0-128减少边缘遗漏但增加计算量level分辨率层级0 或 10 细节最多但速度慢1 速度快但细节少batch_size每次推理数量8-64影响吞吐和显存占用建议先在小数据集上做压测找到一个“显存不溢出、速度可接受、医生认可”的组合。不要照搬公开论文里的参数因为不同医院的切片大小和设备差异很大。4.3 推理结果要结构化病理推理服务不能只返回一个类别名。建议输出包含坐标、类别、置信度和版本信息{ results: [ { tile_id: case_001_level0_x0_y0, coord: {x: 0, y: 0}, pred_class: tumor, confidence: 0.87 } ], model_version: ruipath-2.0-mock }后处理阶段还需要考虑置信度阈值和区域合并。低置信度区域不要直接丢弃可以选择标记为“待医生确认”。这样模型结果才不会给病理医生造成“机器已经下了结论”的错觉。5. 模型评估与临床验证技术指标不等于临床价值5.1 离线评估指标要围绕临床场景选择模型评估不能只看整体准确率。病理任务经常面临类别不均衡例如绝大多数 tile 是正常组织只有少量 tile 是病变区域。如果只看准确率模型可以“全部预测正常”也得到很高分数。推荐使用以下指标指标说明适用场景AUC区分正负样本的能力初步筛选模型F1-score精确率和召回率的调和平均不均衡分类敏感度阳性样本查全率肿瘤筛查特异度阴性样本查全率控制假阳性平均精确率不均衡场景下的查准表现可疑区域排序敏感度和特异度一定要一起看。病理辅助系统如果漏检后果严重如果假阳性过多医生会被大量无效告警干扰最终放弃使用。5.2 数据划分必须按患者维度切分训练集、验证集和测试集必须按患者划分不能按 tile 随机划分。同一患者的多个切片之间高度相关如果同一个患者的切片既出现在训练集又出现在测试集模型效果会被严重高估。一个简单的按患者划分示例patients sorted(set(annotations[patient_id])) train_patients patients[: int(len(patients) * 0.7)] valid_patients patients[int(len(patients) * 0.7): int(len(patients) * 0.85)] test_patients patients[int(len(patients) * 0.85):]真实项目还要考虑医院和扫描仪维度。最好使用多中心数据验证至少要有外部验证集否则模型换一个环境后很容易性能崩塌。5.3 从技术验证到临床试点要分步走模型在测试集上表现好不代表能在科室直接使用。建议按以下顺序推进离线回放用历史切片跑一遍对比模型结果与原始报告。双盲自评让病理医生在不看模型结果的情况下重新判读再对比。人机协同医生先看模型结果再给出最终诊断。试点运行选择少量病种记录医生使用反馈和修改次数。注意不要用训练集样本做验证按患者划分后再进入多中心验证。整个过程要保留完整记录包括模型版本、切片标识、医生修改结果和耗时。这些数据是后续模型迭代的重要依据。6. 病理大模型上线后的运维与安全6.1 模型版本管理不能靠文件名区分模型文件一多靠文件名区分必然出错。推荐在模型仓库中记录以下信息字段示例说明模型名称ruipath-2.0业务模型名版本号v2.0.1语义化版本权重哈希sha256:abc123...确保文件完整性训练数据范围2020-2024 多中心数据来源评估结果AUC 0.95关键指标发布时间2025-06-01可追溯推理服务启动时应该打印加载的模型版本并在响应中返回model_version字段。这样医生或前端发现异常时能快速定位是哪个版本产生的输出。6.2 监控与告警要覆盖业务和技术指标GPU 推理服务的监控不能只看 CPU 和内存还要关注推理延迟、队列长度和 GPU 利用率。建议采集以下指标指标告警建议说明推理成功率低于 99% 告警服务是否可用P95 推理延迟超过 5 秒告警医生等待体验GPU 利用率持续低于 20% 提示资源是否浪费队列深度超过 100 告警是否要扩容显存占用超过 90% 告警是否可能 OOM日志中要记录每次请求的tile_id、耗时、模型版本和返回码。不要只在异常时打日志正常的慢请求也需要记录因为异常往往从耗时突增开始。6.3 数据隐私与访问控制病理切片包含患者隐私生产环境必须控制访问边界。切片文件不应该挂在所有人都能访问的共享目录上建议通过对象存储的签名 URL 或后端服务做代理访问。私有化部署场景下华为云 Stack 可以保证数据不出院但应用层权限设计仍然要做细。医生、技术人员、管理员应具有不同角色重要操作例如导出结果、修改模型配置必须审计。推理服务也应限制来源 IP只允许内网医生工作台和预处理服务访问。注意不要在日志中输出患者姓名、住院号等明文隐私信息日志里只保留脱敏后的样本编号。7. 常见问题排查从镜像启动到推理超时7.1 容器启动后立即退出现象常见原因检查方式处理建议Pod 一直 CrashLoopBackOff模型路径不存在kubectl logs确认MODEL_PATH与镜像内文件一致启动时缺依赖requirements 未安装全kubectl logs进入容器检查 pip list端口未监听启动命令错误kubectl exec内执行 curl检查 CMD 参数和 uvicorn 配置镜像启动失败十有八九是文件路径和启动命令问题。建议先本地用docker run验证再推到集群。7.2 GPU 不可用或 CUDA 报错现象是推理请求返回CUDA error: no kernel image is available。常见原因是容器没有挂载 GPU或基础镜像的 CUDA 版本与宿主机驱动不兼容。在容器里执行nvidia-smi如果命令不存在或报错先检查宿主机驱动是否正常再确认集群是否安装了 NVIDIA Device Plugin。然后检查 Deployment 的resources.limits是否包含nvidia.com/gpu不要只写limits.memory。7.3 推理超时和显存溢出常见场景是多个医生同时打开切片预处理线程把大量 tile 一次性送入模型GPU 显存不够直接 OOM。解决方案有三个方向降低 batch_size。对 tile 队列做限流。推理服务副本数扩容。如果单张 WSI 预处理时间过长可以增加缓存层把已经切好的 tile 缓存在对象存储中避免同一张切片反复预处理。7.4 模型输出和医生预期不一致先不要怀疑模型“精度不行”按这个顺序排查检查推理服务加载的模型版本是否是预期版本。对比训练和推理时的预处理参数颜色归一化、tile_size、overlap 是否一致。检查 WSI 读取层级和坐标换算是否有误。检查结果后处理阈值是否被改过。找 5-10 例医生不认可的输出看错误是否有规律。注意不要只验证程序能启动还要验证输入、输出、异常分支和日志是否符合预期。8. 最佳实践与下一步扩展8.1 病理大模型上线前检查清单检查项是否必须说明模型权重备份和哈希是确保可回滚推理服务健康检查是/health必须可用数据脱敏和访问审计是患者信息不出域GPU 驱动和容器插件是否则推理服务无法使用 GPU并发压测和超时配置是避免医生使用时白屏与病理系统或 PACS 的接口联调是数据流要完整模型输出的人工复核流程是辅助而非自动决策8.2 值得长期坚持的工程原则配置外置化。模型路径、GPU 卡数、batch_size、阈值都应该通过环境变量或配置中心管理不要写死在代码里。模型和代码分离。不要每次更新模型都重新构建镜像用挂载或模型仓库方式加载权重。日志结构化。每条推理日志应包含版本号、耗时、切片标识和坐标方便回溯。灰度发布。新模型先在副本数为 1 的 Deployment 中运行对比旧模型输出确认无误后再切全量流量。8.3 从 RuiPath 2.0 看医疗大模型的扩展方向病理大模型一旦接入科室流程后续扩展方向通常包括从单张切片识别扩展到多模态报告生成把切片图像与病理报告文本对齐用知识检索辅助医生查找相似病例在科研场景中用模型自动筛选入组病例在质控场景中复核初诊医生书写是否规范。这些方向都建立在同一套工程底座上稳定的数据管道、可扩展的推理平台和可追溯的评估机制。RuiPath 2.0 的发布让更多团队意识到医疗大模型的竞争不只是模型训练更是从数据到服务、从指标到临床价值的全链路工程能力。技术团队如果能把部署、评估和运维这层底座做扎实后续无论模型如何迭代都能快速接住变化。
