医院AI“大模型即服务”平台落地探索

过去两年，大模型逐渐成为医院信息化建设中的重要议题。从影像诊断到智能导诊，从病历质控到报告生成，AI应用场景持续扩展。随着相关应用进入落地阶段，医院IT团队需要关注的不只是场景和模型选择，也包括大模型推理所依赖的基础设施。

用户洞察：三家医院的真实现状与诉求

从实际调研和项目需求来看，不同医院在建设阶段、算力基础和治理要求上存在差异，但在模型服务化、算力统一管理、可观测运维等方面有较为一致的诉求。

1.医院A：以国产算力起步，构建模型即服务能力

该医院为二级综合性医院，处于AI大模型探索初期，已完成部分部署和验证。不同于先期围绕单一应用的分散建设模式，该院在起步阶段就希望构建统一的服务中台或云平台，以国产昇腾910B算力为基础，对算力与模型资源进行统一管理，并向上层业务提供模型即服务能力。

当前探索的模型以Qwen系列35B级别模型为主，主要面向临床辅助决策、医疗机构综合运营管理等场景，后续也计划扩展至患者服务和行政管理效率提升。因此，院方关注模型能否快速发布、按需更新，以及从算力资源到模型服务的端到端可视化管理能力。

2.医院B：算力与模型统一交付，大小模型混合承载

该医院为三级甲等综合性医院，已开始进行AI场景探索，院内具备一定GPU资源基础，也接触过由服务商提供AI Agent、模型和应用能力的建设方式。

与只需要统一模型服务的场景不同，该院内部同时存在两类需求：一类是面向大语言模型的统一部署和调用，模型规模覆盖27B到百B级参数量；另一类是面向科研、影像识别等场景的传统机器学习和图像识别小模型，这类场景更关注算力资源本身的交付。因此，院方希望在统一平台上同时管理模型资源和算力资源，既支撑大参数模型运行，也满足小模型按需部署和交付的需求。

3.医院C：从分散部署走向统一治理

该医院为三级甲等综合性医院，已开展较长时间的AI探索，早期主要由ISV提供模型、应用和配套硬件，并直接部署在院内，形成多个分散的一体机和工作站。后续院方开始尝试建设模型服务平台，将模型统一管理后提供给不同科室使用，在一定程度上改善了资源利用率和模型管理问题。

但随着模型来源和类型增加，平台治理要求也随之提高：一方面，院内既有已部署的一体机，也有新部署在算力资源上的模型；另一方面，嵌入、重排序、OCR等小模型参数量较小，如果长期独占H20、4090等整卡资源，会造成算力浪费。因此，院方希望进一步建设面向私有化模型推理场景的统一模型服务平台，通过GPU虚拟化、统一路由、配额管理、调用日志和可观测能力，实现异构算力、多类模型和不同使用方的统一治理。

共性问题：AI落地中的基础设施挑战

随着场景扩展和模型数量增加，医院在AI基础设施层面也面临新的管理压力。多个AI应用分别建设后，底层算力、模型和运维体系容易形成相互独立的烟囱。归纳起来，主要有以下几个问题。

1.模型种类多、规格不一，要求参差不齐

不同AI应用往往来自不同ISV，而各家ISV对模型规格的要求并不一致，常见的从32B到72B参数量不等，也有可能提出八卡H200等高端硬件配置要求。对于部分模型与业务结合度不高的场景，例如随访系统，如果逐一满足高配资源要求，会增加医院的建设成本和管理复杂度。

2.绑定单一厂商模型，暗藏迭代风险

AI模型迭代较快，几个月内就可能出现新的版本。如果医院围绕某个特定模型进行大量定制开发，一旦该模型停止维护或被新版本取代，前期投入可能面临绑定风险，后续迁移成本较高。因此，更适合采用“统一底座+模型接入”的架构：底座保持稳定，上层模型可以灵活替换、按需切换。

3.一体机形态各异，资源利用率偏低

在“烟囱式建设”方式下，每引入一个AI应用，就采购一台配套的AI一体机，直接使用其中封装好的服务。这种“一应用一盒子”的模式部署相对简单，但不同厂商的一体机形态各异、规格不一，彼此之间无法共享算力，容易造成单台设备利用率偏低，同时增加机房空间、电力和预算消耗。

4.算力调度难，叠加信创替换压力

为减少烟囱式建设，一些医院开始尝试自建公共算力池，用十余张GPU卡搭建统一资源池，供院内各科室接入使用。但在实际调度中，如何在不同部门、不同模型之间合理分配算力，如何应对潮汐式使用波动，仍然需要平台能力支撑。

与此同时，信创替换压力也在增加。早期采购的L20等英伟达卡仍在服役，而新的采购越来越强调国产化，国产算力卡逐步进入。异构算力如何统一纳管、平滑过渡，成为基础架构团队需要解决的现实课题。

5.缺乏统一管理，模型难以复用

当模型分散在一台台一体机、一个个项目中时，医院难以形成对AI资源的全局视图。多个应用底层可能使用同一类32B模型，但由于缺乏统一平台，需要重复部署并重复占用算力。缺乏统一管理既会造成资源浪费，也会增加后续优化难度。

6.调用量难以观测，无从精细化控制

除模型复用外，调用量观测也是医院关注的重点。当各厂商的模型分别被调用时，医院很难看清每个模型、科室、应用消耗了多少算力、产生了多少调用量。缺乏统一观测，就难以识别高频刚需和低效占用，也难以开展配额管理、优先级调度和成本分摊。

基于SmartX榫卯AI平台（MaaS）的解决思路

上述问题对应到基础设施层，本质上需要一套能够统一管理算力和模型、支持调度与观测的平台。SmartX基于榫卯企业云平台构建榫卯AI平台，提供面向医院的MaaS（Model as a Service，模型即服务）底座。

从下往上看，整个平台分为四层：最底层是异构GPU服务器（或AI一体机）；其上是榫卯企业云平台，提供容器、vGPU等基础能力；再往上是适配不同硬件的推理引擎；最上层是模型层，通过AI网关对外统一提供私有模型与公有模型服务。

1.异构GPU统一纳管，支持多种资源调度方式

平台底座由榫卯企业云平台承担，把不同品牌、不同代际的GPU统一纳入一个资源池管理。对于正在推进信创替换的医院，新老算力可以共存，并通过统一平台实现平滑过渡。

在资源调度方面，平台支持整卡直通、多卡并行与单GPU卡切分等多种方案：重负载的大模型可以独占整卡甚至多卡；对于轻量场景，则可以通过GPU切分技术把一张物理卡切分给多个应用共享。通过按需分配和潮汐复用，平台可提升整体资源利用率，降低因ISV高配资源要求带来的浪费。

2.多种部署形态，适配不同建设规模

不同医院、不同建设阶段的需求存在差异，平台因此提供两种部署形态：

Docker单机部署：轻量、快速，几张卡即可起步，适合单一科室试点或小规模场景，可减少为单个应用单独采购封闭一体机的情况。

Kubernetes集群部署：面向院级算力池，提供弹性扩展、高可用与统一调度能力，资源可随业务增长平滑扩容。通过统一资源底座，医院可以将分散建设的设备和服务逐步收敛到统一平台。

在推理引擎层，平台适配vLLM、vLLM-Ascend、SGLang等多种引擎，可针对不同硬件、不同模型选择合适的运行方式，降低底层异构环境对上层应用的影响。

3.多模型统一管理与提供，一次部署、多方复用

平台在模型层把私有模型（如本地部署的Qwen系列等）与院内与院外公有模型（如DeepSeek、Minimax等）统一纳管，对上层各类AI应用以标准化服务的形式统一提供。同一个32B模型不再需要被每个应用各自部署一份，而是一次部署、多方调用，从而提升模型复用率并减少重复算力占用。

同时，“统一底座+模型接入”的架构可以降低对单一厂商、单一模型的依赖。当出现新的模型版本时，医院可在平台上接入或切换模型，减少对上层应用的影响，并降低模型迁移成本。

4.AI网关：统一入口，支撑调用治理与可观测

所有对模型的调用，都统一经过模型层之上的AI网关。AI网关对外提供统一的接入入口与标准接口，对内完成鉴权、路由与限流。

在可观测与治理方面，平台可以按模型、科室、应用等多个维度统计调用量，帮助医院识别高频使用场景和低效占用。在此基础上，医院可以进一步开展配额管理、优先级调度与成本分摊，补齐此前调用量难以统计、资源难以精细化控制的问题。

用户价值：算力和模型的集约化建设，精细化管理

对医院A而言，核心诉求是以国产昇腾910B算力起步，为上层业务提供模型即服务能力，并支撑智慧医院转型升级。榫卯AI平台通过“统一底座+模型即服务”承接这一需求：底层基于国产昇腾算力统一纳管，契合信创要求；上层以MaaS方式快速发布模型、按需更新并提供端到端可视化管理，帮助医院在轻量化起步阶段建立可持续扩展的AI能力。

对医院B而言，核心诉求是统一交付算力资源与模型资源，同时承载生成式大模型和传统机器学习小模型。榫卯AI平台把各类大小模型一并纳入统一模型层，对上层应用统一提供服务，一套平台同时承载两类负载，避免为不同模型各自搭建独立环境，也让算力在大小模型之间灵活复用。

对医院C而言，核心问题是ISV各自部署导致架构分散、缺乏监控、运维复杂、模型交付慢。榫卯AI平台的异构纳管与GPU切分能力，可以将原本独占整卡的小模型调整为共享资源，提升资源利用率；统一部署形态可以减少ISV独立建设带来的运维复杂度；模型层可以统一提供自建与已有模型；AI网关可以提供统一路由、配额、调用日志与可观测等能力。由此，信息科能够从故障响应转向统一治理，让AI应用具备更好的可管、可控和可持续运行基础。

进一步看，SmartX榫卯AI平台的价值不只在于解决单个项目中的资源或运维问题，而是用一层MaaS底座将医院大模型推理基础设施统一收敛：向下统一纳管异构算力、通过灵活调度提升利用率，向上统一管理多模型、通过AI网关实现用量可观测与可治理，并以多种部署形态适配不同建设规模。

从“一应用一盒子”的烟囱式建设，到“统一底座+灵活接入”的平台化建设，医院的大模型基础设施建设可以逐步从分散走向集约，从粗放走向精细，为后续AI应用持续扩展提供稳定基础。

（本文由SmartX公司供稿）