自学建百度首页网站百度快速排名优化服务
一体机是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就会发布，届时再下手也不迟。
大模型的前方是星辰大海，但我们，才刚刚上路呢。
文章参考：一体机，阻碍DeepSeek性能的最大绊脚石！