一體機是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就會發布，屆時再下手也不遲。
大模型的前方是星辰大海，但我們，才剛剛上路呢。
