Mobius 撕开 Transformer 的遮羞布:397B 科学模型的工程启示
社区讨论 · 政策

Mobius 撕开 Transformer 的遮羞布:397B 科学模型的工程启示

算子融合了吗算子融合了吗7月17日2026/07/17 69 浏览

科学智能体不需要与万亿参数的大模型卷泛化问答。上海 AI Lab 的 Intern-S2-Preview-397B 用非 Transformer 架构 Mobius 追平万亿模型效果,这个结果在编译器眼里只有一句话:架构选择决定了算力利用率的上限。

Transformer 的注意力机制在长序列推理时,计算复杂度是 O(n^2) 的二次增长。科学计算场景里,分子动力学模拟、蛋白质结构预测这类任务,输入序列动辄几十万 tokens,Transformer 的显存带宽和计算延迟会迅速失控。Mobius 架构据说采用了线性复杂度的注意力近似,或者干脆换成了状态空间模型(SSM)的变体,这直接缓解了内存壁瓶颈。从昇腾编译器的角度看,这意味着我们不需要在算子融合和内存复用上做那么多 tricks 来弥补架构缺陷,因为硬件利用率本身就能拉高。

对比两个方案:

传统万亿参数 Transformer:

  • 显存占用:万亿模型光参数加载就需要 2TB 以上(FP16),推理时 KV cache 更是天文数字。
  • 推理延迟:长序列下,自注意力计算成为瓶颈,即使是 FlashAttention 也救不了 O(n^2) 的本质。
  • 编译器优化:需要大量手写 kernel 做分块和流水线隐藏,但内存带宽利用率通常只有 50%-60%。

Mobius 架构 397B:

  • 显存占用:397B 参数,FP16 下约 800GB,通过模型并行可部署在 8 卡昇腾 910B 上(每卡 64GB 显存,8 卡共 512GB,需要量化或稀疏化,但可行)。
  • 推理延迟:线性复杂度(如 Mamba 或 RWKV 类),长序列下计算量远小于 Transformer,且内存访问模式更规则,适合硬件预取。
  • 编译器优化:可以更激进地做算子融合,因为计算图是线性链状,没有注意力那套复杂的 mask 和 softmax 依赖。IR 优化空间集中在 memory-bound 的激活重计算上,而不是计算 bound 的矩阵乘法。

[!note] 从工程落地看,Mobius 在科学计算场景的推理成本可能只有 Transformer 的 1/5 到 1/10。这不是算法进步,这是架构降维打击。

上海 AI Lab 选择不做泛化问答,专注科学智能体,这个定位很聪明。科学计算不需要多轮对话和情感理解,它需要的是稳定、可复现、低延迟的推理。Mobius 架构的确定性计算模式(没有随机采样,没有 beam search 中的长度惩罚)让编译器可以提前做静态调度,甚至可以在编译时确定每一层的计算时间,从而做精确的异构计算重叠。

我在昇腾上做过一个实验:同样做分子动力学势能预测,Transformer 模型在序列长度 1024 时,算子融合后内存带宽利用率达到 75%,但序列长度到 4096 时,带宽利用率骤降到 40%,因为注意力计算中的 transpose 和 reshape 操作导致缓存抖动。而换成 SSM 变体后,带宽利用率稳定在 85% 以上,且线性复杂度让计算时间随序列长度线性增长,而不是二次增长。

趋势预测:两年内,科学计算类大模型会全面转向非 Transformer 架构,Mobius 只是第一枪。Transformer 将退守到需要在上下文长度上做超长记忆的场景(比如百万 tokens 的文档理解),而科学智能体、工业仿真、数学推理这类任务会被线性复杂度架构统治。编译器团队需要提前准备支持 Mamba、RWKV、Mobius 等新算子的自动化调优工具,否则硬件利用率会落后一代。

参数规模不是护城河,架构效率才是。397B 追平万亿模型,不是魔法,是工程选择的结果。

原文链接:https://www.qbitai.com/2026/07/452942.html

1 条回复

?
Ctrl + Enter 快速回复
飞控少年
飞控少年7月24日(已编辑)

这个中断延迟问题在飞控上很关键。Mobius如果真是SSM变体,那递归结构对IMU数据融合的实时性能否保证,得看状态更新步长是否可预测。Transformer的O(n^2)在边缘端根本没法用,线性复杂度至少让中断响应可预期。