从2块到40块算力卡：一家肿瘤医院的AI网关手记

来源：HIT专家网 作者：孟振

2013年，我还是临床医生，在HIT专家网发表了第一篇文章《一周搞定一个微信公众账号手记》，也算是正式“出道”了。无独有偶，今年8月，HIT专家网发表了江门市中心医院同行韩春春老师的一篇《不懂代码的护士，如何在一周内“造”出科室都爱用的系统》，引起了同行热议。同样是“一周”，古法编程与AI编程，相望了13个年头。

从基层医院信息科，到带领省级肿瘤专科医院的信息团队，如今我的工作难度和复杂度指数级上升。曾经的人设——“一个会写点代码的医生”，已经离我越来越远。日常的管理动作占满了日程表，即使有想法、有点子，团队也难有时间和精力去落地。

近半年来，AI Coding出现了，管理和技术似乎又可以走到一起，相辅相成。

从2块卡到40块卡

我如今所在的浙江省肿瘤医院，在2024年采购了2块算力卡。那时应用和模型直连，最方便直接，也能快速上手测试。随着AI应用的需求井喷，2026年上半年医院落地了40块算力卡，既用于训练，也用于推理。这时算力、模型和应用的管理，就遇到了瓶颈。

问题一：病历生成、制度搜索、并发症查询，这些应用有的来自厂商，有的是团队自研，调用的可能是同一个模型，用的也是同一把密钥。谁用得多、谁用得少，不清楚。

问题二：不止一次出现模型被高并发调用“打爆”的问题，整个模型服务瘫痪，影响一线临床使用。但我们不清楚到底是哪个应用引起的，只能重启模型解决。大模型的权重加载又要一段时间，AI服务就这样中断了。

问题三：40块算力卡，有的放在外网服务区，有的放在内网区域。不同的应用调用同一个开源模型，要在两套算力里部署两遍，资源浪费。有没有办法模型只部署一次，不管在哪个位置都能方便调用？

AI应用层出不穷，模型也在迅速迭代，这些都是日常工程实践中冒出来的新问题。我们作为信息部门，用什么方法来解决？又怎么和科室的日常管理结合起来？

答案不难想到：在AI模型和应用之间，需要一个对应用透明的中枢关口，把权限管理、流量控制、调用审计、健康自检等核心能力放在一处。这一类产品在互联网行业已经比较成熟。但医院的场景有自己的特点：算力分在两个区，应用来自厂商和自研两边，还要和信息科的日常管理结合起来。我们需要的是一个能适应这些特点的协同层。

于是我们用开源组件，在国产化服务器上搭建了一套团队自研的AI网关。工作台放在钉钉H5里，通过身份鉴权，科室的硬件工程师、应用对接人以及医院科研团队，可以各自访问特定模块。

截至目前，该网关已经稳定运行3个多月。调用量为单周十亿量级，每天都有几万到十几万条的调用留痕，应用负责人每天早上8点准时收到日报，半年度的总结报告呈报院领导。做“AI网关”这件事，我们既没有新增采购，也没有新增人手，就明明白白地回答了四个问题：谁在调、调了什么、花了多少、出没出错。

我是医疗岗位出身，容易从精细化的应用角度看问题。今年出去交流，有同行前辈提醒过：格局和架构，比“雕花”更要紧。有了网关这样的基础设施，让我在纷繁复杂的AI应用面前，多了一点淡定的底气。

一本账：从开源项目Langfuse说起

这点底气，来源于一本账。AI网关首先是流量入口，更要紧的是“账本”。我们用到了开源项目Langfuse。

不同的调用方，哪怕调用同一个模型，也要分配不同的密钥，这样账就能记清。内外网的调用，都记到同一个Langfuse里：语音调用按秒计，文档解析按页计，日报、审计都从这个账本里出。

有了账本和限额，就不怕应用高并发“打爆”模型。一旦出问题，我们能查到是哪个应用、当时多少并发、上下文多长，调用方也好据此优化。

应用后面跑的是开源权重的大模型，部署挂在同一个网关上。只要使用的是相同的开源模型，内外网就不用重复部署，都从同一个入口调用，最大程度地节约资源。2026年6月，浙江省印发了推进开源体系建设的相关文件，把智慧医疗也写了进去。我们医院正走在这条路上，用开源组件把AI底座搭了起来。

回头一望，2013年我开发的公众号，是自学PHP写的。后来在医院的那几年，我又用开源框架和微信开发包，做了全套企业微信和小程序应用。对当时的我来说，开源是“拿来就用”。现在，我们把AI网关建在开源组件上，算力上跑的是开源权重的国产大模型。和2013年相比，变的是规模，没变的是“先拿来用起来”。

AI Coding：一扇窗口

网关从技术上看，是一个关口；从管理上看，是一套共识。

在做AI网关的过程中，模型探活、限流、账本口径这些细碎的活，要花不少时间和精力。但如果没有“谁在调用、花了多少、有没有出错”这样的管理诉求，技术执行也会失去方向。

此前，我们也制定了AI管理的相关制度，但“不得共用密钥”“患者数据不出院”这些要求，写在纸上容易，真要落地，得有可靠的技术支撑：既让业务快速创新，又能守住安全。

我们这个AI网关，本身就是用AI Coding做出来的。这种方式做出来的产品，可以让管理和技术之间走得很近。举一个8月的例子：有家厂商的模型上线跑批量任务，在一天7400多次成功调用之外，还有1900多次报错。我们用账本一查，95%的报错是被网关的配额闸拦下的，请求根本没到模型。再整体查询一看，这个模型全天平均只用了配额的15%，根本没到限额，问题出在用户在傍晚两个小时集中投喂超长上下文，峰值一分钟达到92万token，是配额的2.3倍；而算力那头当天零错误，还有余量。可见报错不是模型或算力的问题，而是配额这道闸设得不够准。

所以，接下来要做的就是管理上的取舍：我们把配额上调到峰值再加三成余量，但不放到无限，配额仍是保护算力的闸门；同时请厂商合理安排批量任务的时段，错峰跑任务。改配额的事交给科员独立完成，然后用日报来校验效果。通过这个案例课件，技术给的是数据，管理做的是取舍，两者之间有一扇互通的窗口。

三个问题答完了。这些回答，是在实践中一点一滴得来的。新的问题还在路上，一下子可能没有标准答案。但技术和管理一起走的这条路，大方向不会错，答案也在路上。

【作者简介】

孟振，浙江省肿瘤医院信息工程部主任。

【责任编辑：陈曦 版式：明超】