为啥#xff1f;

只因DeepSeek这个模型有点特殊#xff0c;它是个高稀疏度的MoE模型。

MoE这种混合专家模型#xff0c;设计的初衷是通过“激活一堆专…一体机是DeepSeek交付的最佳方式吗

恰恰相反一体机是阻碍DeepSeek提升推理性能的最大绊脚石。

只因DeepSeek这个模型有点特殊它是个高稀疏度的MoE模型。

MoE这种混合专家模型设计的初衷是通过“激活一堆专家中的少量专家”来达到减少计算量、提升推理效率的目标。

举个例子MoE模型好比是一个超级大饭店的后厨这个后厨里有几百个大厨每个大厨擅长做不同菜系川菜厨子、鲁菜厨子、湘菜厨子…

其中有个人是厨师长厨师长不负责炒菜他清楚地知道每个厨师擅长做什么菜。

每次顾客点菜的时候厨师长门控网络会根据顾客点菜的需求以及自己对厨师能力的了解安排擅长做这些菜的厨子炒菜。

这样酒店的后厨就不必为每位厨师安排灶眼只需少量灶眼比如8个供那些需要上岗炒菜被激活的厨师使用就可以了。

是不是看起来很不错但是有一点很重要不参与炒菜的厨子们虽然不占用灶眼但是还是要挤在后厨随时等待召唤。

也就是说MoE模型里那些未激活专家虽然不消耗算力但它们的参数量仍然要占用显存/内存带来巨大的存储开销和调度复杂性。

回过头来我们再来看DeepSeek-R1/V3是稀疏度极高的MoE模型总参数量6710亿激活量370亿。

按照DeepSeek官方的最新披露模型每层256个专家只有8个被激活V3的Transformer

层数设置为

好比你的饭店有60多个后厨房间每个屋里放256个厨师同时只有8个厨师干活其他待命。

这就意味着你需要配置超高的一体机大显存、大内存才能够运行满血版DeepSeek。

事实证明目前的状况也的确如此市面上的“真·满血DeepSeek一体机”价格都是100万起甚至要大几百万。

然而这种一体机部署模式算力是我买断的难道不应该让他们尽量都干活从而让算力最大化使用吗

我的显存/内存/硬盘都是为了装下6710亿参数但实际干活只有370亿参数…

一体机其实是运行DeepSeek这种MoE模型的最差选择更适合运行那些非MoE的全参数激活模型。

这一点大家如果仔细看上周DeepSeek官方在知乎披露的推理优化架构就明白了。

人家说的很清楚要想获得“更大的吞吐、更低的延迟”核心就是要使用「大规模跨节点专家并行」。

按照DeepSeek给出的官方参考推理架构专家并行、数据并行、PD分离

Prefill阶段部署单元4节点32张H80032路专家并行和数据并行。

Decode阶段部署单元18节点144张H800144路专家并行和数据并行。

这就意味着一个22节点的集群176张卡才能发挥出最优的推理吞吐和延迟。

让每个专家获得足够的输入都忙活起来而不是“占着茅坑不拉屎”

正因为这种采用这种大规模并行架构DeepSeek官方给出的单服务器平均推理性能才高得离谱输入73.7k

tokens/s输出14.8k

当然我们并不是要否定大模型一体机只是一体机不适合部署MoE模型让它跑个稠密模型不需要大规模并行的还是很好的。

眼下DeepSeek一体机满天飞更多的还是满足客户的情绪价值本地化、开箱即用、专属性……

尤其在数据隐私方面一体机有着无与伦比的优势不只是合规更能切实有效的保护数据不出域。

比如很多通过API、WEB或APP提供DeepSeek服务的供应商在他们的用户协议里可能赫然写着“…我们可能会将服务所收集的输入及对应输出用于本协议下服务的优化…”。

这对于大部分企业级客户来说这都是无法接受的所以本地化部署肯定是刚需这也是目前DeepSeek一体机火爆的原因即便性能不佳。

其实很多企业过去两年自己囤过算力此时参考DeepSeek的大规模并行架构部署起来相信会有不错的效果。

第一蒸馏版体积小性能好效果差点不耽误练手

第三相信不久的将来下一代DeepSeek就会发布届时再下手也不迟。