一句话简介：省级"检查在基层、识别在云端、审核在省级"的影像云AI，真正难点不在模型，而在算力怎么在云边端分级调度。这篇讲讲我复盘的3个坑。最近在帮一家省级医疗健康AI平台搭"检查在基层、识别在云端、审核在省级"的数智影像底座，遇到了一个典型问题：模型精度早够了，可片子从县医院传到云端AI初筛，再送省级专家复核，整条链路一跑就暴露一堆工程问题——不是算法不行，是算力分级和协同架构没想清楚。作为医疗

影像AI的Pod一到门诊高峰就被OOM Kill，不是K8s的问题，是资源模型没设计好。这篇复盘怎么把内存/GPU/弹性伸缩一起调对。最近在做某三甲医院影像AI推理集群的资源治理，遇到一个挺典型的坑：AI辅助诊断的Pods白天能跑，一到早高峰，dmesg里全是OOM Killer，Pod被反复重建，患者等片的延迟从"秒级"掉到"十几分钟"。

一、先分清"数据长什么样"，再谈"数据放哪" 坑在第一步：医院的数据从来不是一块铁板。教训：先做"数据形态体检"，把关系型、文档、向量、时序分开规划，别追求一个大库装下所有。二、别把"能读出来"当成"能对齐" 坑在联调：影像、病历、结算来自不同系统，同一个患者在不同库里ID都对不上，更别说"主诉"和"诊断"这种字段语义。三、AI检索的"幻觉"源头，一半是数据没治理 坑在最后：模型明明接了库，答出来

一句话简介：医疗AI医疗云首个行业评估标准9月1日实施，我复盘了把一个"测试集99%准确率"的影像AI产品改造成"能过新行标验收、在科室持续用起来"的一整套工程取舍。最近在陪一家AI医疗云厂商做三甲医院项目的验收复盘，正赶上中国信通院牵头的《医疗云计算评估方法 第7部分：人工智能医疗云应用》（YD/T 4405.7-2026）在9月1日正式实施。作为医疗云原生架构师，这轮给我的最大触动是：医疗影像

医疗影像平台冲到千万级影像、7万工作站在线时，稳定性不再是"加机器"的事。这篇复盘讲清上传链路、质控、计费三道坎。

适配：应用SQL改写、字符集、时区、驱动版本，逐系统建立"专项适配+专项沟通群"。调优：用新一代真实数据和SQL做压测，建立性能基线。割接：增量数据同步+实时回退通道+秒级预案。保障：前端响应+后端驻场，上线后持续SQL监测与优化闭环。 亮点/结论 资产规模大不是借口：只要"评估-分层-同步回退"做扎实，1900万行、260TB影像照样可以2小时平稳割接。真

当前系统采用微服务架构进行开发，该架构带来了系统可扩展性提升、服务间耦合度降低等优势。本文档旨在提供一份微服务架构设计模板，总结常见问题与应对策略，供团队在后续架构设计、问题复盘时参考。：本文档弱化了具体产品、项目、医院名称，聚焦于通用的微服务架构设计原则和常见问题处理思路。：东西向流量（服务间调用）不建议走网关和鉴权，直接服务发现调用，可显著降低延迟。分类管理配置（研发配置/常量配置/业务差异配

一句话简介：门诊影像15年、住院30年留存，RTO≤4h、RPO≤1h红线——医疗影像云容灾不是堆设备，而是围绕"即备即用"做的一次架构取舍复盘。本文从一名医疗云原生架构师的信创迁移一线视角，讲清楚容灾到底该怎么落地。

最近在做某家医疗云平台的信创迁移与智能运维改造，遇到一个很典型的场景：三甲医院每天上万条影像报告依赖底层集群，一旦告警多、根因定位慢，运维团队就陷入"救火"状态。这篇文章是我对"用 AI 辅助医疗系统排障"的一次行业复盘，供同行参考。

最近在做某家医疗云平台的信创迁移与智能运维改造，遇到一个很典型的场景：三甲医院每天上万条影像报告依赖底层集群，一旦告警多、根因定位慢，运维团队就陷入"救火"状态。这篇文章是我对"用 AI 辅助医疗系统排障"的一次行业复盘，供同行参考。