近日，一個“DeepSeek大單”，瞬間引起了圈內(nèi)人士的熱議。

這是來自于臨汾市人民醫(yī)院的政府采購意向，標的是“基于DeepSeek的智慧醫(yī)療項目”，預(yù)算金額達到1569.264萬元。

看到這么大的單子，大家都很興奮。

畢竟，只有真金白銀的項目和采購，才算大模型真正落地。這種千萬級大單的出現(xiàn)，自然格外引人注目。

那么，這1500萬，都采購了些啥？

1.基于大模型的患者服務(wù)應(yīng)用系統(tǒng)：基于大模型的患者服務(wù)應(yīng)用系統(tǒng)包含智能導(dǎo)診與分診系統(tǒng)、診前病史采集系統(tǒng)。
2.基于大模型的醫(yī)療質(zhì)量管理相關(guān)系統(tǒng)：建立基于大模型的醫(yī)療質(zhì)量管理體系相關(guān)應(yīng)用系統(tǒng)包含病歷輔助生成系統(tǒng)、AI病歷內(nèi)涵質(zhì)控系統(tǒng)。
3.人工智能信息系統(tǒng)的配套硬件設(shè)備：基于醫(yī)院軟件的實際需求量，硬件部分采用70B模型相對應(yīng)匹配，處理速度達到3300 token/s（70B模型）；整體方案硬件適配包含超融合應(yīng)用管理節(jié)點、AI數(shù)據(jù)算力區(qū)（AI算力服務(wù)器和AI數(shù)據(jù)分析機）、存儲、以及相對應(yīng)配套網(wǎng)絡(luò)設(shè)備。
4.安全防護：部署入侵防御和防病毒功能的防火墻、部署運維管控堡壘機、引入零信任綜合安全網(wǎng)關(guān)、部署日志審計系統(tǒng)、部署數(shù)據(jù)庫審計系統(tǒng)。

這其中，大家討論比較多的是第3部分，模型的尺寸和性能需求：

大家的爭論焦點在于70B的模型能不能行？3300TPS的吞吐能力夠不夠用？

針對這兩項，我們的觀點是這樣的（僅供參考）。

一、模型尺寸和性能建議

模型能力和吞吐的選擇，離不開應(yīng)用場景，看采購意向，主要是兩大類智能體：

①面向患者服務(wù)的智能導(dǎo)診、分診、診前病史采集。

②面向醫(yī)護人員的病歷輔助生成、病歷內(nèi)涵質(zhì)控。

第一，導(dǎo)診、分診、問卷采集這類短消息任務(wù)，上下文長度低，但對推理延遲敏感。

DeepSeek 70B模型足夠應(yīng)付，甚至可以選用更小尺寸模型（7B、34B），節(jié)省算力，降低延遲，提升患者交互體驗。

第二，針對病歷生成、尤其是內(nèi)涵質(zhì)控，需要長上下文、多輪邏輯、深度推理能力，70B可能會比較吃力，如能滿血版最好。（當(dāng)然可以通過70B微調(diào)、知識庫進行彌補）。

第三，模型吞吐3300TBS是否夠用？這需要按照并發(fā)來反推。

根據(jù)臨汾市人民醫(yī)院官網(wǎng)介紹，門診量約98.88萬人次，在職員工2932人（2022年數(shù)據(jù)）。

個人感覺，按照這個并發(fā)規(guī)模，3300TPS的吞吐難以同時應(yīng)對患者和醫(yī)護人員的高頻使用。

比較理想的架構(gòu)模型分層↓

前端小尺寸模型處理面向海量患者的導(dǎo)診、分診、問卷等即問即答型業(yè)務(wù)。

后端大尺寸模型處理面向?qū)I(yè)醫(yī)護人員的病歷生成、批量質(zhì)控等任務(wù)。

總之，小模型保體驗，大模型保深度，并用路由策略按需調(diào)用，可大幅降低算力峰值。

二、安全產(chǎn)品選擇建議

在安全需求上，醫(yī)院選擇了本地化部署，否了云上部署和API調(diào)研，既合規(guī)又合理。醫(yī)院數(shù)據(jù)的隱私性要求，大家都懂的。

不過，具體到安全產(chǎn)品選擇，什么IPS、防火墻、堡壘機、零信任，這一大堆，還是以傳統(tǒng)場景的安全防護為主，完全沒和大模型場景與時俱進。

傳統(tǒng)網(wǎng)安“三件套”只能護外殼，要讓大模型在醫(yī)院“可上線、可審計、可追責(zé)”，就需要考慮“模型推理層+內(nèi)容護欄層”的雙重防線，并納入現(xiàn)有零信任與SIEM體系統(tǒng)一運營。

好了，就說這么多吧。

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