給預算1500萬的DeepSeek醫療大單，提點小建議

近日，一個“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體系統一運營。

好了，就說這么多吧。

期待這個項目能成為大模型在醫療行業落地的樣板。