万亿参数模型跑出1000t/s？小米这波工程优化有点东西

这个数据确实让人眼前一亮，但冷静下来想，有几个点挺值得掰扯的。

你说MoE加动态稀疏激活，我完全同意，但这块儿还有个隐藏的坑——专家的负载均衡。万亿参数模型里，如果某些专家被频繁激活，其他专家闲着，那动态稀疏的优势就大打折扣。小米能跑到这个速度，我猜他们可能用了类似“在线专家重组”或者“自适应路由”的策略，把热点专家的计算压力分散到多个物理节点上。否则光靠静态的路由分配，很难在8卡上做到这么低的延迟。

另外，你提到通信瓶颈，我觉得NVLink的带宽只是表象。真正要命的是跨节点的同步机制。8卡A100下，如果用的是传统的all-reduce同步，哪怕单卡计算再快，通信的等待时间也会吃掉大部分性能。小米很可能用了异步通信加梯度压缩，甚至可能把部分参数层的更新做成了“延迟同步”，这样就能让计算和通信完全重叠。去年我试过一个百亿参数的模型，把同步改成异步后，吞吐直接翻了1.5倍，但代价是收敛稳定性变差，需要额外的优化器调参。小米要是能把这个平衡做好，那确实有点东西。

最后，FP8量化这块儿，我有点好奇他们怎么处理激活值的异常大值。万亿参数模型里，有些层输出值范围特别大，直接砍成FP8，精度损失可能会让模型在某些任务上拉跨。除非他们用了混合精度，只对非关键层做FP8，或者加上了动态scale的校准策略。

反正，这数据要是真的，那小米在工程层面的积累，至少在这个细分领域，已经甩开不少团队了。期待他们出个技术报告，把细节讲透。

这速度确实猛，我跑百亿参数MoE时，跨节点路由的通信延迟就够头疼了，他们能把万亿参数的全连接层分层切割做到这个程度，估计在稀疏激活和量化上下了狠功夫。不过好奇他们具体怎么压NVLink带宽的，是改了AlltoAll的调度还是搞了梯度压缩？要是能公开点路由优化的细节就好了。

看到这个1000t/s的数据我也愣了一下，感觉像是把推理延迟压到了物理极限附近。你提到的MoE加动态稀疏激活应该是核心，但我在想另一个问题：万亿参数级别的模型，哪怕激活率只有10%，那也有1000亿参数在前向传播中参与计算，光这部分的显存带宽和计算量，8卡A100/H100真的能喂得饱吗？

我比较好奇的是他们具体用了什么量化策略。FP8现在虽然成熟，但万亿参数模型里如果混合了不同精度的层（比如某些关键专家保持高精度），那通信和计算之间的调度策略就非常关键了。你提到的跨节点路由问题，我去年在调一个300亿的模型时也深有体会，MoE的all-to-all通信在节点数一多的时候，延迟会指数级增长。小米这个如果是单机8卡跑出来的，那NVLink的利用率得接近理论峰值才行，他们是不是在专家分配上做了类似哈希路由或者局部性优先的优化？

另外，你提到“近似O(n)”，这个思路很有意思。如果专家路由真的能逼近线性复杂度，那意味着他们可能跳过了传统的Top-K softmax排序，直接用了某种基于特征哈希的硬路由？不过这样会不会影响专家的负载均衡，导致某些专家过载而其他闲置？很想听听你对这个方向的具体见解。

看到这个数据，我第一反应也是先算了一笔账。万亿参数，8卡GPU，1000 tokens/s，如果按常规Transformer架构，哪怕用FP8，单卡显存也得至少1TB往上，8卡A100 80G才640G，物理上就不够存。所以这肯定不是传统dense模型，必然是MoE，而且是极度激进的MoE——总参数万亿，但每个token激活的参数量可能只有几十B到一百B出头。这样显存才装得下，推理延迟才能压下来。

聊点实操经验吧。去年我带团队做过一个千亿参数级别的MoE模型，16卡A100，目标是做到500 tokens/s，结果实际跑出来只有150左右，中间踩了无数坑。最大的问题恰恰是楼主提到的通信开销。MoE的all-to-all通信是噩梦，尤其当专家数量多、每个token需要路由到top-2甚至top-4专家时，跨节点的数据搬移量会直接让NVLink带宽打满。我们当时试过各种方案：把专家尽量放在同一节点内，用NVIDIA的NCCL调优参数，甚至手写异步通信来重叠计算和传输。最终效果最好的反而是最土的办法——把专家数量减半，同时降低每个token路由的专家数，从top-4降到top-2，牺牲一点模型容量换吞吐。但即使这样，离500还差得远。

小米这个1000 t/s，如果真是8卡GPU跑出来的，那他们大概率做了几件事。第一，专家路由不再是传统的softmax+gating network，而是某种哈希路由或者基于输入特征的预计算索引。我们内部试过用LSH（局部敏感哈希）来近似路由，把O(N)的匹配变成O(1)的查找，确实能省几十毫秒，但精度会掉，尤其是在长尾类别上。第二，他们可能用了FP4甚至更低的量化。FP8现在已经比较成熟了，但FP4的精度损失在MoE的稀疏激活下会被放大，因为每个专家看到的样本更少，量化误差更容易累积。我们测过FP4下模型的困惑度，比FP8高了将近5%，这在很多业务场景（比如金融风控）是不可接受的。第三，自定义CUDA kernel几乎是必须的。PyTorch的torch.compile或者CUDA图优化只能解决一部分调度问题，真正的瓶颈在kernel launch overhead和内存带宽利用率。我们当时写了一个fused MoE kernel，把gate计算、top-k选择、专家计算和combine输出全部融合到一个kernel里，减少了4次显存读写，延迟直接降了30%。但写这种kernel非常痛苦，要手动管理shared memory和warp-level通信，光调试就花了两周。

至于输出质量折损，这个得分开看。如果他们的应用场景是实时风控、智能客服这类对延迟极度敏感但对单token精度容忍度较高的任务，那粗粒度聚类和低精度量化是可以接受的。比如风控场景，你只需要模型判断“是/否欺诈”，哪怕top-5 token的排序有偏差，只要最终二分类准确率不掉，就OK。但如果是内容生成或者代码辅助，长尾分布中的稀有词被误判，用户感知会非常明显。我们之前在对话系统里测试过，把MoE的top-2路由改成top-1，生成结果的多样性下降了，用户反馈“回答越来越模板化”。所以如果小米这个模型是面向通用场景，他们肯定在精度和速度之间做了折中，具体折了多少，只有内部数据才知道。

另一个值得讨论的点是6.6万人排队这个现象。这说明企业端对实时推理的需求已经从不切实际的幻想变成了真金白银的预算。我们服务过几家银行和保险公司，他们现在要求风控模型的推理延迟必须控制在10ms以内，否则交易确认环节会超时。以前他们用几百亿参数的dense模型跑FP16，单卡延迟20-30ms，勉强能用，但遇到双十一这种流量尖峰就扛不住。MoE的稀疏激活天然适合这种场景——你可以把总参数做到很大，但每个请求只激活一小部分，延迟稳定。小米这个速度如果能在生产环境复现，那意味着企业可以用更少的GPU支撑更高的QPS，ROI一下就上来了。

但这里有个隐藏的坑：MoE的显存占用并不是简单的“激活参数量*2（FP8）”，因为专家参数、路由参数、缓存、KV cache都要算进去。万亿参数如果每个token激活100B，那KV cache的显存消耗会非常夸张。我们算过，一个1024长度的序列，用FP8存储KV cache，单层就需要约1GB，几十层下来就是几十GB。如果8卡分摊，每卡也要10GB以上。所以他们的1000 t/s很可能是在短序列（比如64-128 token）下测的，长序列下速度会急剧下降。楼主可以关注一下他们公布测试条件时的序列长度和batch size，这直接决定了数据的可信度。

长远来看，这个趋势会推动两件事。一是推理框架的变革。现在主流框架如vLLM、TensorRT-LLM都在优化MoE，但核心瓶颈是跨节点通信。如果小米的哈希路由方案真的把跨节点通信降到了接近零，那整个推理框架的设计逻辑都要变——从“尽量把数据放在本地”变成“尽量把计算放在数据所在的地方”。二是硬件厂商的路线选择。NVIDIA的H100和B200都在堆显存带宽和NVLink速度，但如果软件层面能把通信优化到这种程度，那硬件厂商可能得重新考虑是否还要在单卡显存上疯狂加码。毕竟，你买8张80G卡，如果通信瓶颈导致利用率只有30%，那还不如买4张200G卡但通信延迟减半。

最后说点负面的。我对这种“超速”版本一向持谨慎态度，因为见过太多case是benchmark好看但实际一跑就崩。比如某些厂商把模型剪枝+蒸馏后宣称速度提升10倍，但业务方上线后发现准确率掉了8个点，又灰溜溜回滚。小米这个如果真能达到1000 t/s且保持万亿参数级别的有效容量（即激活参数量的质量不输同等规模的dense模型），那确实是大突破。但按我的经验，这种级别的优化往往依赖于特定硬件（比如他们可能用了定制版GPU或者特殊互联拓扑）或者特定任务（比如只优化了某个领域的路由策略）。如果通用性不足，其他厂商想复制就难。

总之，这个数据让我既兴奋又怀疑。兴奋的是MoE在工程落地上确实还有很大潜力可挖，怀疑的是1000 t/s这个数字过于完美，完美到让我觉得可能隐藏了某些关键约束条件。建议楼主继续关注他们后续的论文或技术博客，如果能公开关键实现细节，那才是真正推动行业进步。如果只是PR层面的宣传，那就当个行业风向标看看，别急着跟风。

那个路由优化的思路我特别有同感。去年我搞了个300B的MoE，8卡H100上死活卡在350t/s瓶颈，最后发现是跨节点all-to-all通信把NVLink带宽吃满了，后来改成分层top-2路由加局部注意力裁剪，才勉强提到500t/s。小米这个直接干到1000t/s，我猜他们肯定用了类似动态稀疏激活加异步通信重叠的手法——把专家选择的计算和梯度同步流水线化，不然单卡推理延迟不可能压到毫秒级。

有个细节想请教：这个速度是在什么batch size下测的？如果batch size很小，那通信开销占比会更大，能跑出这个数说明他们可能把专家容量做成了动态可调，甚至用了类似“预测性专家缓存”的机制，避免每次推理都做全量路由。另外，FP8量化下万亿参数模型的精度损失怎么控制的？我试过int8量化后，部分专家输出会漂移，得做细粒度校准，不知道他们是不是用了逐层敏感度分析来动态调整量化位宽。

还有，这个“标准8卡GPU”是A100还是H100？如果是A100，那通信延迟优化就更逆天了——得把NVLink带宽利用率推到90%以上，同时用sharded MoE把每个专家的参数量控制在单卡显存能装下的范围。如果是H100，那FP8的Tensor Core优势倒是能用上，但通信瓶颈依然在。真心求教他们的路由算法细节，或者有没有开源的部分，想对比下我们自己的方案。

这个速度确实让人有点怀疑人生，我第一反应也是“这怕不是把prompt长度和输出tokens的单位搞混了”。不过仔细想想，如果真是万亿参数，那MoE基本是板上钉钉的事，而且专家数量可能远超常规的64或者128。他们这个“近似O”的后半句是啥？我猜是近似O(1)的路由？那确实有点夸张，传统MoE的跨节点通信瓶颈主要就在all-to-all这一步，要是真能把路由延迟压到近乎常量级别，那8卡NVLink的带宽利用率就能拉满。

不过有个地方我比较困惑——万亿参数级别的模型，就算用FP8，单卡显存也装不下全部参数吧？那必然要做模型并行或者pipeline并行。8卡的话，每张卡要承载至少1250亿参数的存储和计算，哪怕是MoE激活部分参数，通信模式也会极其复杂。他们怎么解决专家间的负载不均衡问题的？如果某个专家被频繁调用，那张卡就是短板。另外，1000t/s如果是输出速度，那prompt processing阶段的速度呢？长序列下KV cache的显存占用也是大头。

你之前调百亿参数能到200t/s已经很不错了，我甚至怀疑小米这个数据是不是在某种特殊benchmark下跑出来的，比如输入极短、输出极长的场景，或者干脆是batch size=1的纯推理。工程优化这东西，有时候宣传的峰值速度和实际生产环境下的稳定吞吐完全是两码事。要是能公开一下他们用的具体精度、专家数、以及路由算法的细节，那才有说服力。

你这分析很到位，MoE+动态稀疏+FP8这套组合拳基本是明牌了。不过千t/s这个数字，我怀疑他们是不是在专家路由上做了类似哈希映射的近似O(1)调度，或者把跨节点通信用RDMA跑成了异步流水线。去年我调百亿模型时，光NVLink的AllReduce就占了三成延迟，小米要是能把万亿参数的通信开销压到这程度，那他们的梯度压缩和拓扑感知调度肯定有独到设计。