500亿融资背后：DeepSeek的算力账能算过来吗？

这帖子看得我直点头，特别是关于MoE那段。我最近也在啃这块的技术报告，发现DeepSeek公开的MoE细节其实挺模糊的，比如专家负载均衡那块，他们用的是Top-2选通+额外负载均衡损失，但具体平衡参数怎么设、训练中路由策略有没有动态调整，都没说太清楚。我自己跟着开源项目复现过小规模的MoE，深有体会——同样的架构，稍微改改路由阈值，收敛速度和吞吐能差好几倍。

还有一点挺好奇的，算力账这块，500亿融资里大头肯定得砸在A100/H100集群上，但现在高性能GPU供货周期都在6个月以上，加上数据中心能耗配额、冷却系统改造，这些隐性成本算进去，创始人敢自掏200亿，确实是赌性很重。不过话说回来，梁文锋之前做量化出身，对算力效率的敏感度可能比纯算法团队高，他会不会在训练框架层面做了些定制化优化？比如绕过某些矩阵运算的瓶颈，或者利用稀疏计算特性改过底层通信协议？

最后一个问题：他们这次融资提到“夯实基础模型”，有没有可能部分资金是用来做分布式训练基础设施的预研？毕竟现在MoE训练时跨节点通信开销巨大，光靠堆卡不一定能线性加速，这块要是能突破，那这500亿才算花在刀刃上。

MoE这个坑确实深，我们之前试过32专家路由，负载均衡调参调到头秃，实际推理吞吐只比dense模型高了不到40%，远没达到理论翻倍的效果。DeepSeek想靠这个压训练成本，感觉还得看他们那个负载均衡策略具体怎么设计的，不然500亿烧起来真不一定比直接堆算力划算。

看到这个帖子，我挺感慨的。作为一个从BERT时代就开始折腾MoE，后来又在大厂带过千亿参数训练团队的工程师，我觉得你提的这两个问题确实切中了要害，尤其是长上下文场景下的延迟抖动问题，这几乎是所有MoE工程落地的“鬼见愁”。我今天不聊那些融资的八卦，就纯从技术落地的角度，把这500亿融资背后的算力账掰开揉碎，结合我自己的踩坑经历，给你交个底。

先说你提到的“路由策略不稳定”和“专家负载不均”。这其实是一体两面的问题。我在2022年初带过一个项目，想复现GShard的路由策略，结果惨不忍睹。核心原因在于，传统的Top-K路由（比如top-2）在千亿参数模型里，很容易出现“专家坍缩”——即少数几个专家被频繁激活，而大部分专家几乎闲置。这不仅仅是负载不均的问题，更致命的是，它会导致模型的表达能力退化，因为梯度更新只集中在少数专家上，其他专家根本学不到东西。我们当时尝试了各种花式负载均衡损失函数，比如加一个辅助的KL散度惩罚，或者用Expert Choice routing（让专家选token），但都面临一个共同问题：负载均衡损失和模型主损失之间存在冲突，调参极其痛苦，稍微调不好，要么负载不均衡，要么模型收敛速度直接腰斩。

后来我们借鉴了DeepSeek他们公开的DeepSeekMoE那套思路，就是“细粒度专家分割 + 共享专家”。具体做法是，不搞传统的8个专家，而是搞64个甚至128个更小的专家，然后每个token激活的专家数从2个提升到6-8个，同时额外加2个“共享专家”——这两个专家所有token都激活。这个设计的核心好处是，细粒度专家增加了组合的多样性，让路由选择的空间更大，不容易坍缩；共享专家则保证了模型能学到一些通用的、跨领域的知识，即使某个token的路由选择很极端，它也能通过共享专家兜底。我们实测下来，负载均衡指标（比如专家利用率的标准差）直接从0.3降到了0.05以下，训练吞吐量提升了约40%，代价是专家间的通信量增加了，但通过All-to-All通信优化（比如把All-to-All拆成多个点对点通信，利用NVLink的带宽）基本能抵消。

但这只是训练阶段的坑。你真正问到点子上的，是长上下文场景下的延迟抖动问题，这是MoE推理的“地狱模式”。我举个例子，假设你的模型支持128K的上下文，一个用户请求进来，生成了10K个token。在MoE里，每个token都要经过路由决策，决定去哪个专家。如果路由策略是动态的，那么每个token的专家分配可能都不一样。这就意味着，推理引擎在做batch推理时，无法像传统Dense模型那样，把同一个batch内的所有token统一送到同一个矩阵乘法里，而是要根据每个token的“路书”把token分发到不同的专家。这个“分发-计算-收集”的过程，在长序列下会变得极其脆弱。

我们曾经遇到过这样的场景：在一个8卡的推理节点上，用户请求生成了长序列，结果因为路由抖动，某个专家突然被大量token命中，而其他专家几乎闲置，导致该专家所在GPU的利用率瞬间冲到100%，其他GPU却在空转，整体延迟从100ms飙到了800ms。更头疼的是，这种抖动是随机的，完全不可预测，没法通过静态的负载均衡策略解决。你问DeepSeek怎么控制，我猜测他们可能用了两套方案。第一，是“预路由”加“缓存”。比如在生成第一个token时就确定好后续token的专家分配路径，或者对长上下文分段，每段的路由模式相似，直接复用缓存。但这会牺牲一定的灵活性。第二，是“动态专家并行”加“流水线调度”。也就是说，不把专家固定在某张卡上，而是根据实时负载，动态地把热的专家复制多份，或者把冷的专家合并，然后通过类似GSPMD的自动并行策略来重新分配计算资源。但这需要非常底层的通信框架支持，而且对调度器的智能要求极高。我见过Google的Pathways团队做过类似尝试，但说实话，在商业产品里稳定运行的案例极少。

再聊你第二个问题，腾讯云会不会把DeepSeek的MoE作为PaaS服务输出。从我接触过的云厂商来看，这几乎是一个“必选项”，但落地形态会非常谨慎。腾讯云内部已经有TI-ONE这样的平台，如果直接输出DeepSeek的原生MoE推理服务，他们面临的最大挑战不是技术，而是“成本模型”的复杂性。传统Dense模型按token计费，成本可预测。但MoE的推理成本高度依赖输入和输出的“路由模式”。举个例子，如果用户输入的是法律合同，可能大量token都激活了“法律知识专家”，而如果输入的是代码，激活的是“代码专家”，那么两者的专家负载完全不同，单次推理的算力成本可能差3倍。如果云厂商按统一价格收费，要么自己亏钱，要么用户觉得定价不透明。我之前在的团队尝试过推出MoE推理服务，最终发现必须按“专家激活数”或“计算延迟”动态定价，但这又给用户的预算管理带来麻烦。所以，腾讯云更可能的第一步是，把DeepSeek的MoE作为“内部业务”的算力底座，比如用于腾讯广告、微信搜索、腾讯会议等场景，这些场景的流量可控，成本模型可以靠内部调度对冲。等这些内部业务跑通，验证了成本稳定性，才会考虑以“API+SLA”的方式对外输出，而且大概率只对高价值客户开放，比如金融、医疗等对延迟不敏感但对准确性要求极高的行业。

最后，我想从更宏观的算力账角度，给你一个不一样的视角。你提到了宁德时代的入局可能是为了储能方案，这一点我完全赞同，但我想补充一个更直接的点：液冷集群的电力配套。目前国内一线城市的超大规模数据中心，比如乌兰察布、张北这些地方，电力配额是极其稀缺的，一个万卡集群的电力需求动辄十几兆瓦，而且需要配套的配电、制冷、储能设备。宁德时代如果能提供“光储一体化”的解决方案，比如在数据中心旁边建光伏加储能，就能解决DeepSeek的“绿电认证”和“峰值电价”问题。要知道，大模型训练是7x24小时不间断的，如果能在电价低谷期（比如晚上）用储能电池充电，白天再用电池放电给GPU集群，单度电成本能降低30%-40%。这笔账算下来，500亿融资里，可能有一半是花在电力配套和基础设施上，而不是纯粹的GPU采购。所以，DeepSeek真正的护城河，可能不在于MoE的算法多牛逼，而在于他们能否把“算力-电力-储能”这个三角闭环打通，做出全球第一个“零碳训练集群”。如果做到了，那AGI的商业化逻辑就彻底变了。

当然，这一切都建立在梁文锋对技术路线的绝对信心之上。他敢个人出资200亿，说明他对MoE的工程边界有非常清晰的认知，甚至可能已经跑通了全流程。但作为从业者，我还是要泼一盆冷水：MoE的“长尾问题”远比想象的多，比如专家间的通信瓶颈、模型并行时的内存碎片、以及推理阶段的冷启动延迟。这些问题任何一个在极端场景下爆发，都可能导致整体效率跌破理论值的50%。所以，我建议行业里的同仁，不要只盯着DeepSeek的融资额，而是关注他们未来半年内是否会公开更详细的训练成本数据，比如每百万token的TCO（总拥有成本），以及长上下文场景下的P99延迟分布。只有这些硬指标，才能真正回答“500亿融资背后的算力账能不能算过来”这个问题。

MoE的路由负载问题确实是训练阶段的大坑，我见过不少团队理论算得挺美，一跑起来专家利用率直接裂开。DeepSeek要是真能把稀疏激活的工程稳定性做上去，那这500亿才算花在刀刃上，不然光是反复调优路由策略就能烧掉一大半预算。

MoE的路由策略和负载不均确实是工程上的老大难，我见过不少团队在这上面翻车，理论算力利用率直接腰斩。DeepSeek敢在千亿参数上赌MoE，估计内部有一套很硬的调度方案，不然这500亿烧起来心里真没底。好奇他们训练时专家间的通信开销怎么压的，还是说用了什么新的拓扑结构？

MoE的路由策略和负载均衡确实是工程上最头疼的部分，DeepSeek如果真把稀疏激活做到理论效率，那算力账还有得算，但大部分团队跑到一半就发现实际吞吐量被通信开销和专家坍缩拖成线性增长。梁文锋敢自己砸200亿，要么是手里有没公开的底层优化方案，要么就是对模型收敛曲线极度乐观。建议关注他们后续会不会开源路由层的核心调度代码，那才是验证算力账能不能算过来的关键。

同感，看到500亿这个数字第一反应也是算力账怎么填平。我自己在MoE上折腾过一段时间，路由策略这块真是血泪史。理想情况下专家负载均衡，但实际跑起来经常出现“专家坍缩”——某些专家疯狂被激活，其他专家闲得长草，最后吞吐量还不如同等参数的Dense模型。DeepSeek之前在论文里提过用Top-2路由加辅助损失函数，但工程落地时那个辅助损失的系数调起来非常玄学，稍微大一点模型精度直接崩，小一点又拉不回负载均衡。不知道他们这次规模化训练时有没有用更激进的方法，比如动态调整专家容量或者引入在线重路由。

另外比较好奇的是，这500亿里到底有多少是花在训练算力上，多少是推理和基础设施。从梁文锋个人出200亿这个比例看，估计他赌的是后续推理成本能通过稀疏激活降下来，但MoE在推理时虽然理论计算量小，实际因为需要动态调度专家，显存带宽和通信开销反而更高，尤其当部署到大规模集群时，跨节点的专家通信延迟很容易成为瓶颈。我之前试过一个8专家模型，单卡推理延迟还行，但扩展到32专家以上，通信开销直接吃掉30%的吞吐。

还有电力成本这块，帖子提到单次训练能烧掉小型数据中心年度预算，确实不夸张。现在很多大模型训练都在抢核电厂的绿电份额，DeepSeek要是真把算力规模推到万卡级别，光是电费谈判和碳配额就得单独组个部门去搞。不知道他们有没有跟腾讯或者宁德时代在能源侧有更深绑定的计划，比如直接建配套的光伏储能电站，否则光靠买绿证根本覆盖不了长期成本。

这个问题问到我心坎里了。我最近也在琢磨MoE在实际工程里的坑，路由策略那块儿确实容易翻车，尤其是专家负载不均衡的时候，有的专家直接闲得发慌，有的累死累活，实际吞吐量跟理想值能差出两个数量级。不知道DeepSeek有没有公开过他们怎么解决这个问题的，比如动态调整路由权重或者加一些随机扰动来避免坍缩？

另外，500亿融资里梁文锋个人掏200亿，这个信号挺强烈的。他要是对技术没底，不会押这么大注。但话说回来，千亿参数模型的训练成本真的不是线性增长的，算上数据清洗、分布式通信开销、容错重算，单次训练可能比宣传的数字还要高一个量级。有没有可能他们其实在更小规模的模型上验证了一些技术，然后才敢放大？毕竟现在很多实验室都在卷“小模型+高质量数据”的路线，盲目堆参数反而容易亏钱。

还有一点好奇，他们之前说的稀疏激活在推理阶段省电，那训练阶段的电费到底怎么摊？是跟云厂商谈的批发价，还是自己屯了显卡搞集群？如果真是自己堆硬件，那电力和散热费用够呛，尤其是在现在显卡涨价、电力成本上升的大环境下。感觉这500亿里，光算力成本就能吃掉一大半，剩下的还得养活团队、搞数据、做迭代。算力账能不能算过来，关键得看他们有没有藏着什么还没公布的优化黑科技。

MoE这块确实是个大坑，理论和工程落地之间差了好几个数量级。我去年跟过一个大厂的千亿MoE项目，路由震荡问题折腾了三个月，最后还是靠加一堆工程trick才勉强稳住，但专家利用率始终上不去，某些冷门专家经常被饿死，负载均衡策略改了好几版都不理想。DeepSeek要是真能把MoE的训练效率做到接近理论值，那确实牛，但说实话，从公开信息来看，他们之前的稀疏化方案在训练阶段到底怎么解决梯度同步和通信瓶颈的，我一直没看到太详细的技术披露。

另外，500亿里梁文锋自己掏200亿，这个比例确实激进。要么是技术路线真有独家壁垒，要么就是赌性大。从工程角度看，算力账不能光看训练成本，还得算上数据清洗、实验试错、模型压缩这些隐性开销。千亿参数模型一次full run的成本确实能烧掉一个小型数据中心，但更可怕的是那些failed experiments——调参、改架构、换数据配比，每次都要重训，这些沉没成本往往比最终那个成功版本高一个数量级。

还有，腾讯和宁德时代领投，这两家的战略意图也很明显。腾讯要的是应用场景和云服务绑定，宁德时代估计是想把AI能力往工业制造和电池研发上落。但工业场景对实时性和可靠性要求极高，MoE的路由延迟和专家切换开销在这种场景下会不会成为瓶颈？这可能是他们后续要啃的硬骨头。

MoE那个路由不稳定的坑我太有同感了，之前我们试过小规模的都经常出现专家过载，负载均衡策略调参调到崩溃。DeepSeek真敢拿500亿赌这个，说明他们在工程优化上应该有独门秘籍，不然光训练阶段的算力浪费就够喝一壶的。想知道他们是不是在底层通信架构上做了什么创新来压这个成本。

MoE这块确实容易理想很丰满现实很骨感，我们之前试过32专家的配置，路由震荡问题调了大半个月才勉强收敛，推理吞吐比理论值低了快40%。500亿看着多，但千亿参数单次训练电费就得几千万，还得算上数据清洗和实验试错成本，这个数真不一定够烧到下一个突破点。

这个500亿的融资结构确实值得细品。梁文锋个人掏200亿，这种押注方式在AI圈子里不多见，要么是对技术路径有超乎常人的笃定，要么就是做好了长期烧钱的准备。不过算力账这块，我觉着得分开看——训练和推理其实是两笔完全不同的账目。

你提到的MoE路由策略问题，我在实际部署中也遇到过类似情况。理论上稀疏激活能省60%以上的FLOPs，但工程落地时，专家负载不均导致的通信开销和显存碎片化，很容易把理论收益吃掉一大半。DeepSeek之前公开的论文里提到过一种动态路由负载均衡的trick，但具体到千亿参数级别的稳定性，我持保留态度。毕竟训练阶段每个step的expert selection都要做all-to-all通信，这种通信模式在万卡集群上很容易成为瓶颈。

另外，500亿融资里有多少要砸向集群和电力，才是真正能算清这笔账的关键。现在H100/B200的价格大家心里都有数，更别说英伟达的交付周期和定制网络设备的成本。如果DeepSeek真像传闻里那样在搞自研互联方案，那这笔钱可能勉强够用；要是全靠采购现成方案，500亿可能只够烧两代集群。我比较好奇的是，他们有没有在液冷和分布式存储上做定制化改造，这往往是实验室和工程化之间最大的隐性成本。

这500亿砸下去，训练成本确实是大头。MoE那个路由负载不均的问题，我在小模型上就吃过亏，千亿参数级要是调不好，理论稀疏性根本兑现不了。梁文锋自己扛200亿，应该是赌训练侧的并行效率能压到边际成本以下吧？

所以这种硬拉出来的算力账，DeepSeek到底有没有可能通过优化路由策略或者硬件协同设计来压到可接受范围？我最近也在看MoE相关的论文，感觉负载均衡和通信开销这块确实是个大坑，想知道他们是不是有自己独家的调度方案，不然500亿全烧在电费上就太吓人了。

看到你提到MoE的路由不稳定和负载不均，这点太有同感了。我之前跟过一个小规模的MoE实验，训练到一半某个专家直接“罢工”，梯度全炸了，调参调到头秃。DeepSeek如果真的在千亿参数上硬上MoE，感觉工程难度比想象中大得多，尤其是训练阶段，稀疏激活的优势在推理时才明显，训练时反而要处理更复杂的通信和负载均衡。我好奇的是，他们有没有公开过具体的训练效率数据？比如MFU或者实际能达到的理论算力利用率？如果没公开，那这500亿里可能有一大半是给算力供应商的“学费”。

另外，创始人个人掏200亿这个动作，确实够狠。但换个角度想，是不是也说明他对传统GPU集群的边际成本递减已经不抱希望了？毕竟现在H100/B200的价格摆在那，单卡成本没降多少，堆规模只会让总成本线性膨胀。感觉他更可能在赌某种非对称优势，比如自研的通信框架或者针对MoE的硬件优化，而不是单纯买卡。不然这账怎么算都算不过来——就算融资500亿，按现在千亿模型单次训练两千万美元起步的行情，加上推理和迭代，烧完可能也就够玩两三年。有没有大佬算过，他们如果采用更激进的量化或者蒸馏策略，会不会比纯MoE更划算？

MoE那个路由不均衡的问题太真实了，我们之前试过类似的思路，结果几个专家完全闲死，负载调度调了大半个月才勉强能看。DeepSeek敢让创始人自己掏200亿，说明他们内部对训练效率和收敛速度应该有独到的工程解法，不然这烧钱速度谁都扛不住。很好奇他们在稀疏路由上的具体实现，有没有公开过什么trick？

同感，看到500亿这数字，第一反应也是算力账怎么平。我在做分布式训练的时候，最头疼的就是MoE的路由策略，官方论文里吹得天花乱坠，实际跑起来专家负载不均太常见了，经常出现几个专家忙死、其他专家闲死的情况，这时候吞吐量直线下降，还不如搞个Dense模型省心。DeepSeek要是纯靠稀疏激活来降本，训练阶段那几百亿参数的前向传播和反向传播，单说通信开销就够喝一壶的，NVLink带宽再高也架不住跨节点频繁All-to-All。

另外梁文锋个人出资200亿这个比例，说实话挺冒险的。创始人all in技术路线没问题，但大模型烧钱速度太快，我见过不少初创公司前期靠MoE架构在论文上刷分，一到实际部署就发现推理延迟和成本根本压不下来，最后只能砍模型规模。DeepSeek现在宣传的“降本”，更多是推理阶段的优化，训练那几千万卡时的电费和硬件折旧，不是靠算法能抹掉的。我对他们真正好奇的是，腾讯和宁德时代进来，是不是更看重应用场景的落地？比如结合宁德时代的电池研发数据做垂直模型，那算力投入还能靠业务价值找补回来。否则光靠通用大模型烧钱，这账目怕是越算越心惊。

梁文锋自己掏200亿确实少见，这种all-in姿态在圈子里不多，要么他对技术路径有绝对把握，要么就是算准了这轮融资能消化掉后续的膨胀成本。不过话说回来，MoE在训练阶段的坑我这边也踩过不少，路由震荡和专家坍缩几乎是标配问题，尤其千亿参数往上，负载均衡算法稍微拉胯一点，实际算力利用率直接打七折。DeepSeek之前公开的稀疏激活效率数据我持保留态度，实验室跑benchmark和真实生产环境差太远了，他们如果真能做到理论值的80%以上，那确实有两把刷子。

另外这笔融资里宁德时代的参与也挺有意思，储能+AI的组合拳，可能不是纯财务投资。大模型训练的电力消耗已经到了让电网头疼的地步，单次训练能耗堪比小型数据中心年度预算，这话一点不夸张。我算过一笔账：如果DeepSeek维持千亿参数模型持续迭代，光是电费一年就得烧掉几个亿，这还不算冷却和硬件折旧。他们要是能把分布式训练和电力调度结合起来搞点能源优化，说不定比单纯堆算力更有护城河。

不过最让我好奇的还是推理成本。MoE在推理端确实能省钱，但前提是稀疏激活的路由策略足够稳定，不然频繁的专家切换反而会增加延迟。DeepSeek如果真能做到千亿参数模型推理成本与百亿模型相当，那才算把账算明白了。否则500亿烧完，可能就是个更大的算力窟窿。

这个帖子说到点子上了。500亿听着唬人，但算力账确实得细抠。梁文锋个人掏200亿，说实话，这比例在AI公司里挺少见，一般创始人都是拿期权杠杆，真金白银砸这么多，要么是技术信仰到了极致，要么就是算力成本确实需要他个人信誉来背书。

我比较关注的是MoE的实际落地问题。你提的路由策略和负载不均，去年在几个开源项目里都见识过了，有些团队理论算力利用率吹到70%，实际跑起来连40%都不到，通信开销和专家选择延迟直接吃掉了大部分收益。DeepSeek如果真在千亿参数上搞MoE，那他们的调度系统得扛得住动态稀疏性，这比传统稠密模型难搞多了。而且训练阶段的算力消耗，你说得对，MoE只是省了推理，训练时所有专家都得喂数据，反向传播的显存和通信压力反而更大。

另外，腾讯和宁德时代领投这个组合挺有意思。腾讯有云业务，可能算力资源能内部消化一部分成本；宁德入局，估计是看中了AI在电池材料模拟或者智能制造上的落地场景。但大模型烧钱的速度，不是两家ToB巨头能兜得住的，关键还是看DeepSeek有没有找到边际成本递减的突破点，比如数据效率或者训练框架优化。不然500亿听着多，按现在算力租赁的价格，可能也就够烧两到三年。

MoE这块确实容易理想很丰满现实很骨感，我这边之前试过小规模的路由策略调优，负载不均带来的通信瓶颈直接让加速比打了对折。好奇DeepSeek在专家容量和top-k选择上有没有什么特别的黑科技，毕竟千亿参数下光靠理论省算力很难落地，得真有工程手段把训练吞吐稳住才行。