1T参数的稀疏MoE模型放TPU上跑，单换一层内核就快了三成？LMSYS团队这回真把推理工程的瓶颈算明白了。SGLang-JAX刚上线的Ling-2.6-1T——63B激活参数、256路由专家、top-8路由加共享专家的稀疏架构——在TPU v7x上跑出了让GPU阵营坐不住的成绩：16块TPU v7x的解码吞吐达到16块H200的1.29到1.77倍。这背后真正值钱的不是跑分数字，是他们怎么用成本模型把MoE推理里最贵的那段路径揪出来，然后一斧子劈开。
MoE推理的隐形成本：数据搬运才是真凶
你以为的瓶颈不是瓶颈
MoE推理的性能分析有个老毛病——大家盯着FLOPs算账，觉得专家FFN的计算量决定一切。LMSYS的工程师们一开始也这么想。但当他们把Ling-2.6-1T的工作负载拆成计算时间、数据搬运时间、调度开销三块来衡量时，结论直接反转：MoE层的预填充阶段，数据搬运占总延迟的67%，专家FFN本身的计算只占21%。换句话说，跑到TPU上的token在等数据搬家，而不是在等矩阵乘法。
路由+FFN+收集，三段式开销被同时引爆
传统MoE实现把这三步拆成独立kernel：先把token按路由表scatter到对应专家的输入缓冲，跑完FFN再gather回来。每一步都要把数据从高带宽内存搬到片上SRAM，搬运完了计算，等着下一步再搬回HBM。在1T这种参数规模下，256个专家的路由表本身就是一张大网——token批次小的时候，路由开销能把延迟天花板顶穿。
把"搬家"藏进"算账"里
他们的解法粗暴但有效：Fused MoE V2，一个Pallas内核把scatter、专家FFN、gather三件事焊在一起。关键技巧是双缓冲——上一批token在做FFN计算时，下一批token的路由scatter已经在后台跑了；FFN算完的瞬间，gather和下一轮的专家分配同步启动。计算和数据搬运在时间轴上重叠，谁也不等谁。
实测数字：53%延迟降幅是怎么来的
预填充：从5.16ms到2.42ms
Fused MoE V2上线后，MoE预填充的单token延迟从5.16ms砸到2.42ms，降幅53%。这个数字的含金量在于——只动了MoE核这一个组件，整条推理链路没有任何其他改动。如果用更传统的优化手段（比如换调度器、改batch策略），想拿到同样的延迟压缩幅度，往往要改三四个模块。
解码：被忽略的15%也别浪费
解码阶段（decode）单token延迟从0.249ms降到0.211ms，降幅约15%。看着不如预填充那么炸裂，但解码是逐token进行的，15%的延迟累积到长序列生成时，用户的等待时间会被显著拉长。LMSYS没有因为这个数字不够"性感"就略过不表，而是把它和预填充的53%并列展示——这种诚实在工程复盘里其实挺稀罕的。
端到端吞吐：单点优化的杠杆效应
更狠的是端到端表现。只替换MoE核这一个动作，预填充吞吐量提升了24.8%，解码吞吐量提升18.5%到35.3%——后者在max-context配置下达到上限。杠杆率超过5倍：优化了一个组件，整条链路吃到了远超该组件耗时占比的收益。道理很简单，MoE层通常是长上下文推理的临界路径，卡住它，整个pipeline的并发度就上不去。
TPU v7x对阵H200：架构差异如何被吃干抹净
1.29到1.77倍：不是单点胜利
在SGLang的解码基准测试里，16块TPU v7x对比16块H200，输出吞吐量（output throughput）领先幅度在1.29倍（mc=128）到1.77倍（mc=512）之间。max-context（mc）越大，领先优势越明显。这说明TPU在长序列场景下的优势是结构性的——大batch、大context是TPU的高带宽片上互联和高容量HBM的主场，GPU的显存墙在这个区间会先撞上。
硬件特性决定优化上限
TPU v7x的SparseCore（也叫SparseCores）是专为稀疏计算设计的硬件模块，处理embedding查找、专家路由这类不规则访存模式有天然优势。256专家的路由表在GPU上是软件层用通用CUDA核模拟的，在TPU上可以直接落到专用硬件上。这一层硬件红利，加上Fused MoE V2的软件层融合，形成了从下到上的优化栈。
不只是MoE：完整工程栈的支撑
这次上线不是单点突破。SGLang-JAX同时还发布了混合KV/循环内存池（Hybrid KV / Recurrent Memory Pool）——把显式KV缓存和循环神经网络的隐状态统一管理，对支持Mamba类架构的混合推理很关键；GLA（Gated Linear Attention）线性注意力支持则补齐了长上下文低内存占用的推理路径；单控制器数据并行（Single-Controller Data Parallel）让多TPU Pod的调度像单机一样简单。每一块都不是噱头。
工程哲学：成本模型驱动优化决策
先算账，后动手
整篇复盘最值得借鉴的方法论，是LMSYS团队对"用成本模型指导优化"这件事的坚持。他们没有一上来就堆优化技巧，而是先把延迟拆成计算、搬运、调度三类，再去量化每一类的占比。这种做法在AI工程圈其实不够普遍——太多团队还在凭直觉调参，凭"我觉得这里应该再快一点"做决策。
内核融合不是银弹
Fused MoE V2的成功有个前提：Pallas（TPU的低级编程抽象）给了足够的控制粒度，让双缓冲、手动调度成为可能。如果换成更高层的框架，编译器可能自动fusion出更保守的结果，反而吃不到这个红利。这也说明，在TPU这种专用硬件上，框架层和内核层的边界感很重要——什么时候放手让编译器干，什么时候必须自己写核，需要清晰的判断标准。
开源生态的真实分水岭
从Llama、Mistral时代开始，GPU一直是开源大模型推理的事实标准平台。SGLang-JAX + TPU v7x的这次落地，让MoE大模型在非GPU硬件上的工程化路径第一次有了可复制的样板。对于手握TPU资源但苦于缺乏成熟推理栈的团队来说，这是一份迟到的入场券；对于GPU阵营，则是一个值得警惕的信号——专用硬件的生态护城河，正在以肉眼可见的速度被填平。
