一體機是DeepSeek交付的最佳方式嗎？

恰恰相反，一體機是阻礙DeepSeek提升推理性能的最大絆腳石。

為啥？

只因DeepSeek這個模型有點特殊，它是個高稀疏度的MoE模型。

MoE這種混合專家模型，設計的初衷是通過“激活一堆專家中的少量專家”，來達到減少計算量、提升推理效率的目標。

舉個例子，MoE模型好比是一個超級大飯店的后廚，這個后廚里有幾百個大廚，每個大廚擅長做不同菜系川菜廚子、魯菜廚子、湘菜廚子…

這些廚子就相當于不同領域的專家。

其中有個人是廚師長，廚師長不負責炒菜，他清楚地知道每個廚師擅長做什么菜。

這個廚師長就是MoE模型中的門控網絡。

每次顧客點菜的時候，廚師長（門控網絡）會根據顧客點菜的需求以及自己對廚師能力的了解，安排擅長做這些菜的廚子炒菜。

這樣，酒店的后廚就不必為每位廚師安排灶眼，只需少量灶眼（比如8個），供那些需要上崗炒菜（被激活）的廚師使用就可以了。

這就相當于MoE的原理：只激活少量專家，從而大幅降低計算量。

是不是看起來很不錯，但是有一點很重要：不參與炒菜的廚子們雖然不占用灶眼，但是還是要擠在后廚隨時等待召喚。

也就是說，MoE模型里那些未激活專家，雖然不消耗算力，但它們的參數量仍然要占用顯存/內存，帶來巨大的存儲開銷和調度復雜性。

回過頭來，我們再來看DeepSeek-R1/V3，是稀疏度極高的MoE模型（總參數量6710億，激活量370億）。

按照DeepSeek官方的最新披露，模型每層256個專家，只有8個被激活（V3的Transformer 層數設置為 61 層）。

好比你的飯店有60多個后廚房間，每個屋里放256個廚師，同時只有8個廚師干活，其他待命。

你想想，恐怕只有新東方廚師專修學院才這么干吧。

這就意味著，你需要配置超高的一體機（大顯存、大內存），才能夠運行滿血版DeepSeek。

事實證明，目前的狀況也的確如此，市面上的“真·滿血DeepSeek一體機”價格都是100萬起，甚至要大幾百萬。

把MoE模型裝進一體機的不科學之處在于↓

我花了大錢買了一堆不能同時干活的專家，只為他們可以減少計算量。
然而，這種一體機部署模式算力是我買斷的，難道不應該讓他們盡量都干活，從而讓算力最大化使用嗎？
我的顯存/內存/硬盤都是為了裝下6710億參數，但實際干活只有370億參數…

所以，我們的觀點是：

一體機其實是運行DeepSeek這種MoE模型的最差選擇，更適合運行那些非MoE的全參數激活模型。

這一點，大家如果仔細看上周DeepSeek官方在知乎披露的推理優化架構就明白了。

人家說的很清楚，要想獲得“更大的吞吐、更低的延遲”，核心就是要使用「大規模跨節點專家并行」。

你一體機就單個節點、8張卡，勉強裝下所有專家，還并行個毛線啊？

按照DeepSeek給出的官方參考推理架構（專家并行、數據并行、PD分離）：

Prefill階段：部署單元4節點（32張H800），32路專家并行和數據并行。
Decode階段：部署單元18節點（144張H800），144路專家并行和數據并行。

這就意味著，一個22節點的集群（176張卡），才能發揮出最優的推理吞吐和延遲。（讓每個專家獲得足夠的輸入，都忙活起來，而不是“占著茅坑不拉屎

正因為這種采用這種大規模并行架構，DeepSeek官方給出的單服務器平均推理性能才高得離譜（輸入：73.7k tokens/s，輸出14.8k tokens/s）。

而一體機廠商們給出的性能，輸出+輸入的總和最多也不過4k tokens/s。

當然，我們并不是要否定大模型一體機，只是一體機不適合部署MoE模型，讓它跑個稠密模型，不需要大規模并行的，還是很好的。

眼下DeepSeek一體機滿天飛，更多的還是滿足客戶的情緒價值：本地化、開箱即用、專屬性……

尤其在數據隱私方面，一體機有著無與倫比的優勢，不只是合規，更能切實有效的保護數據不出域。

比如，很多通過API、WEB或APP提供DeepSeek服務的供應商，在他們的用戶協議里可能赫然寫著“…我們可能會將服務所收集的輸入及對應輸出，用于本協議下服務的優化…”。

這對于大部分企業級客戶來說，這都是無法接受的，所以本地化部署肯定是剛需，這也是目前DeepSeek一體機火爆的原因（即便性能不佳）。

其實，很多企業過去兩年自己囤過算力，此時參考DeepSeek的大規模并行架構，部署起來，相信會有不錯的效果。

而滿血版的DeepSeek一體機，企業可以量預算而行，不要硬上：

第一，蒸餾版，體積小性能好，效果差點不耽誤練手；
第二，最近新模型層出不窮，可以嘗試下非MoE架構的小體積新模型；
第三，相信不久的將來下一代DeepSeek就會發布，屆時再下手也不遲。

大模型的前方是星辰大海，但我們，才剛剛上路呢。