近日,一个“DeepSeek大单”,瞬间引起了圈内人士的热议。

这是来自于临汾市人民医院的政府采购意向,标的是“基于DeepSeek的智慧医疗项目”,预算金额达到1569.264万元。

看到这么大的单子,大家都很兴奋。

毕竟,只有真金白银的项目和采购,才算大模型真正落地。这种千万级大单的出现,自然格外引人注目。

那么,这1500万,都采购了些啥?

1.基于大模型的患者服务应用系统:基于大模型的患者服务应用系统包含智能导诊与分诊系统、诊前病史采集系统。
2.基于大模型的医疗质量管理相关系统:建立基于大模型的医疗质量管理体系相关应用系统包含病历辅助生成系统、AI病历内涵质控系统。
3.人工智能信息系统的配套硬件设备:基于医院软件的实际需求量,硬件部分采用70B模型相对应匹配,处理速度达到3300 token/s(70B模型);整体方案硬件适配包含超融合应用管理节点、AI数据算力区(AI算力服务器和AI数据分析机)、存储、以及相对应配套网络设备。
4.安全防护:部署入侵防御和防病毒功能的防火墙、部署运维管控堡垒机、引入零信任综合安全网关、部署日志审计系统、部署数据库审计系统。

这其中,大家讨论比较多的是第3部分,模型的尺寸和性能需求:

大家的争论焦点在于70B的模型能不能行?3300TPS的吞吐能力够不够用?

针对这两项,我们的观点是这样的(仅供参考)。

一、模型尺寸和性能建议

一、模型尺寸和性能建议

模型能力和吞吐的选择,离不开应用场景,看采购意向,主要是两大类智能体:

①面向患者服务的智能导诊、分诊、诊前病史采集。

②面向医护人员的病历辅助生成、病历内涵质控

第一,导诊、分诊、问卷采集这类短消息任务,上下文长度低,但对推理延迟敏感。

DeepSeek 70B模型足够应付,甚至可以选用更小尺寸模型(7B、34B),节省算力,降低延迟,提升患者交互体验。

第二,针对病历生成、尤其是内涵质控,需要长上下文、多轮逻辑、深度推理能力,70B可能会比较吃力,如能满血版最好。(当然可以通过70B微调、知识库进行弥补)。

第三,模型吞吐3300TBS是否够用?这需要按照并发来反推。

根据临汾市人民医院官网介绍,门诊量约98.88万人次,在职员工2932人(2022年数据)。

个人感觉,按照这个并发规模,3300TPS的吞吐难以同时应对患者和医护人员的高频使用。

比较理想的架构模型分层↓

前端小尺寸模型处理面向海量患者的导诊、分诊、问卷等即问即答型业务。

后端大尺寸模型处理面向专业医护人员的病历生成、批量质控等任务。

总之,小模型保体验,大模型保深度,并用路由策略按需调用,可大幅降低算力峰值。

二、安全产品选择建议

二、安全产品选择建议

在安全需求上,医院选择了本地化部署,否了云上部署和API调研,既合规又合理。医院数据的隐私性要求,大家都懂的。

不过,具体到安全产品选择,什么IPS、防火墙、堡垒机、零信任,这一大堆,还是以传统场景的安全防护为主,完全没和大模型场景与时俱进。

传统网安“三件套”只能护外壳,要让大模型在医院“可上线、可审计、可追责”,就需要考虑“模型推理层+内容护栏层”的双重防线,并纳入现有零信任与SIEM体系统一运营。

好了,就说这么多吧。

期待这个项目能成为大模型在医疗行业落地的样板。