一体机是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就会发布,届时再下手也不迟。
大模型的前方是星辰大海,但我们,才刚刚上路呢。
领取专属 10元无门槛券
私享最新 技术干货