Transformer上限与Mobius：下一代模型架构的挑战与评估

过去五年，AI模型的架构格局几乎可以用一个词概括：Transformer。无论研究自然语言、图像分类还是多模态理解，最终都会落到QKV、注意力分数、层归一化、位置编码这些核心术语上。最近一段时间，“Transformer上限”的讨论频率明显高于以往，Mobius这个新名字也开始进入架构方向的视野。它能否接过Transformer的旗帜，成为下一代模型架构的候选者，是一个值得认真拆解的技术问题。这篇文章不会直接给出“能”或“不能”的结论，而是围绕Transformer为什么强、瓶颈在哪里、Mobius在挑战什么，以及工程上如何评估一个架构候选来展开分析。

Mobius的讨论热度之所以上升，本质上是因为Transformer已经不是万能解。它在语言建模、图像理解、多模态任务上都取得了里程碑式的结果，但同时也把计算成本、推理延迟、长期记忆和模态对齐这些老问题推到了显眼位置。任何一个方向想要成为“下一代”，都必须先在Transformer已经解决的问题上给出不弱的效果，再在它力不从心的地方给出可验证的改进。下面先回到起点，看清楚Transformer的统治力到底建立在什么之上。

1. 先厘清：Transformer为什么能统治这一轮AI浪潮

1.1 注意力机制解决了什么问题

注意力机制解决的是序列建模中最核心的矛盾：一个位置的表示，如何高效获取整个序列的信息。

在RNN里，信息需要沿着时间步逐个传递，距离越远，梯度越容易消失，长距离依赖很难学好。在CNN里，每个位置只能看到局部窗口，要扩大感受野就得加深网络或者增大卷积核，代价明显。注意力机制的思路完全不同：每个输出位置直接计算与所有输入位置的相似度，再用这个相似度对所有输入表示做加权求和。输入和输出的距离被压缩成一步，长距离依赖变成一个直接的线性组合。

技术定义上，最常用的是缩放点积注意力：

import torch import torch.nn.functional as F def scaled_dot_product_attention(q, k, v): # q, k, v shape: (batch, seq_len, head_dim) d_k = q.size(-1) scores = torch.matmul(q, k.transpose(-2, -1)) / (d_k ** 0.5) probs = F.softmax(scores, dim=-1) return torch.matmul(probs, v)

除以根号d_k是为了防止点积结果随维度增大而过大，导致softmax进入饱和区、梯度变小。这里的Q是“我要找什么”，K是“我有什么可被找到”，V是“找到之后我要取出什么”。三个角色分开之后，模型可以对同一段输入从多个角度并行建模，这也为后续的Multi-Head机制铺了路。

Transformer真正有突破意义的地方，不是发明了注意力，而是完全去掉了循环结构，用“序列到序列的注意力堆叠”完成了建模。这个改变让训练可以并行，让梯度路径变短，也让网络可以堆到几十层甚至上百层。

1.2 Transformer相比RNN和CNN的优势

把三类架构放在同一张表里，差异会很清楚：

这里的“硬件利用效率”很关键。GPU擅长大规模矩阵乘法，而RNN的串行依赖会把计算切成很多小步骤，每一步都难以填满显存带宽。Transformer把整个序列的交互变成了矩阵乘，能在GPU上高效并行，因此同样的算力可以喂更多数据，模型也可以训练得更大。

1.3 规模化能力让Transformer成为基座

Transformer能成为这轮AI浪潮的基座，还有一个容易被忽略的原因：它的“可规模化”程度非常高。

结构上，Transformer由大量同质的Self-Attention和前馈网络堆叠而成，没有复杂的跨层控制流，非常适合张量并行、流水线并行和数据并行。训练时，损失通常能随数据量和参数量的增加而平稳下降，这种稳定的收益让“扩大规模”成为最务实的方法。过去几年的模型发展基本遵循这条路径：参数从亿级到千亿级，数据从几十GB到几十TB，效果也在同步提升。

但这不等于Transformer没有上限。它的上限不是某一个分数，而是在计算成本、推理占用、表示能力、生态依赖共同约束下形成的边界。新的架构如果能突破其中两三个约束，才有资格谈“革命”。

2. 所谓“上限触顶”，到底指Transformer的哪些瓶颈

2.1 序列长度与计算成本呈二次增长

Self-Attention的复杂度是O(n²)，其中n是序列长度。这个复杂度体现在时间和空间两方面。时间上，每个token要计算与所有token的相似度；空间上，注意力分数矩阵的大小是n乘n。

用一组数字来看更直观。假设一个模型有32层、32个头、每头维度128，单层单头在纯fp32下计算注意力分数矩阵，不同序列长度对应的显存压力如下：

注意这只是“单层单头”。真实模型要把这个数字再乘以层数和头数。当输入从几千token涨到几十万token时，attention矩阵的体积会迅速超出单卡显存，所以长上下文研究一直在与“二次复杂度”斗争。稀疏注意力、线性注意力、滑动窗口注意力都是为了把这个成本压到O(n)或者O(n log n)级别，但每一种都要在表达能力上做出取舍。

这也是讨论Transformer上限时最容易提到的点：不是模型“学不会”长依赖，而是“算不动”长序列。

2.2 推理阶段KV Cache占用严重

训练阶段是计算密集，推理阶段则多了一个显存杀手：KV Cache。

解码生成时，每生成一个token，都需要重新利用之前所有token的K和V向量。如果每次都重新计算，成本会更高，所以推理引擎会把历史K、V缓存起来。缓存越大，能同时处理的并发请求越少。

KV Cache的显存占用可以粗略估算：

KV_cache_bytes = batch_size * seq_len * num_layers * 2 * num_heads * head_dim * precision_bytes

以一个7B规模的模型为例，假设32层、32头、head_dim为128、fp16保存，单个token每层的KV参数是2乘32乘128，即8192个浮点数，32层一共262144个浮点数，fp16下约512KB。如果输入序列是4096，单条请求就要占用约2GB。高并发场景下，KV Cache会成为比模型权重更占显存的部分。

为了缓解这个问题，业界普遍使用GQA（分组查询注意力）或MLA（多头潜在注意力），把KV参数压缩之后再缓存。但这也说明Transformer的瓶颈是结构性的，不是靠增大显存就能彻底解决。

2.3 Token化与离散表示限制了感知能力

另一个容易被忽视的上限是“表示粒度”。

文本模型使用BPE等分词器把连续语义切成离散token，图像模型把图片切成固定大小的patch，音频模型则需要把连续波形先离散化。这个步骤有三个问题：

• 离散token的粒度很难统一。同一个语义在不同语言、不同领域里会被切成不同数量的token。
• 离散化会丢失细粒度信息。图片的高频细节、音频的音调变化、连续感知中的微小位移，切成patch或token之后都可能被磨平。
• 离散token对模态对齐不友好。文本“猫”、图像中的猫、音频中的猫鸣，在语义上一致但在表示空间里相差很远。

Transformer本身是一个对token序列做变换的工具，它不负责决定token应该是什么。所以如果表示层本身不够好，无论注意力机制多强，模型的天花板也会被“输入表示”卡住。

2.4 模态融合仍然停留在拼接层面

多模态模型是Transformer的重要应用场景，但多数实现仍然是“各模态编码器负责各自输入，再把特征拼接到一起交给Transformer”。这种融合本质上只是特征拼接，而不是真正共享一个语义空间。

理想的跨模态架构，应该让模型在表示层面自动发现图里的猫和文本里的猫是同一类概念，并能根据任务需要随时切换感知重心。Transformer的注意力可以做到一定程度的对齐，但它缺少一个天然的机制来统一不同模态的分布差异。这也是为什么很多多模态模型在细粒度对齐任务上仍然吃力。

2.5 Transformer的“上限”不是单一维度的

把以上几条合在一起，可以得出一个准确的结论：Transformer的上限是“多样性”的天花板，不是一个精度数字。

• 计算维度上，O(n²)的注意力在面对超长序列时成本失控。
• 部署维度上，KV Cache限制推理吞吐和并发。
• 表示维度上，离散token和patch限制了模型对连续世界的理解。
• 架构维度上，层间串行流动限制了信息在高层和低层之间的即时交互。

一个新的架构如果要替代Transformer，至少要在这四个维度中的两到三个给出一致的、可验证的改进，而不是只在某一个benchmark上好看。

3. Mobius在挑战什么：从信息流动方式重新设计架构

3.1 Mobius的命名思路：连续、无起点无终点的信息流动

“Mobius”这个名字借用了莫比乌斯环的拓扑结构：只有一个面，一条边界，没有绝对的起点和终点。

在拓扑学里，一个普通的纸环有内外两面，从一面出发不跨越边界永远走不到另一面。莫比乌斯环则不同，如果有一只蚂蚁沿着带面一直爬，它会不经过边界就爬遍整个带面。映射到模型架构上，这个隐喻很直接：是否存在一种信息流动方式，让模型内部不再有严格的“第一层到最后一层”的单向传递，也不再有“前一个token到后一个token”的线性顺序约束，而是让信息在结构中以更连续、更整体化的方式流动？

严格说，Mobius目前并不是一个像Transformer那样有稳定技术栈的成熟架构。围绕它的讨论更多指向一种设计主张：摆脱“输入是离散token序列、层内只做加权求和、信息从下往上单向流动”的固定范式，引入更连续、可回环、可跨跳的建模方式。下面的分析都基于这个方向性理解，而不是对某个具体实现的断言。

3.2 如果重新设计“注意力”，突破口在哪里

要降低Transformer的二次复杂度，目前有几条已经比较成熟的技术路径。Mobius这一类新架构如果要落地，大概率也要从其中某条路径切入：

• 线性注意力：用核函数把QKᵀ拆成两个小矩阵乘法，避免显式构造n乘n矩阵。
• 稀疏注意力：让每个token只和固定窗口或固定步长内的token交互，配合局部窗口和全局归纳token。
• 状态空间模型：用递归或卷积的方式把历史信息压缩成固定维度的状态，每个位置只依赖状态而不是所有历史。
• 潜在token压缩：把n个token先压缩成m个全局向量，在全局向量上做注意力，再映射回n个位置，m远小于n。

以线性注意力为例，核心思路是这样：

def feature_map(x): # 用 ELU 加 1 作为核函数，保证输出非负 return F.elu(x) + 1.0 def linear_attention(q, k, v): phi_q = feature_map(q) # (batch, seq, d) phi_k = feature_map(k) # (batch, seq, d) kv = torch.matmul(phi_k.transpose(-2, -1), v) # (d, v_dim) numerator = torch.matmul(phi_q, kv) # (seq, v_dim) denominator = torch.matmul(phi_q, phi_k.sum(dim=-2, keepdim=True)) return numerator / (denominator + 1e-6)

这段代码省去了严格的softmax归一化，也避免构造n乘n的分数矩阵，代价是表达能力比标准注意力弱。Mobius如果真的要在注意力层面创新，至少要充分回答一个工程问题：丢失的这种表达能力，如何通过新表示或新结构补回来。

3.3 建模粒度：从离散token到连续函数

Mobius方向更值得关注的一点，是它可能不再局限于“把输入切成token再建模”，而是把输入当作连续函数或连续状态来处理。

文本本质上是一段离散符号序列，但语义是连续的。图像是连续信号在像素网格上的采样。音频是连续波形在时间轴上的采样。Transformer用一个固定顺序的token列表表示所有这些信号，必然存在表示效率问题：同一个概念，在不同模态里对应的token数量差异极大。

如果新的架构能直接在连续表示上建模，不再依赖离散token，理论上可以统一文本、图像、音频的底层表示。但这条路也有巨大挑战：连续表示的优化比离散token困难得多，梯度如何穿过连续映射传播、如何保证不同模态在同一个连续空间中语义对齐，都还没有普适方案。

3.4 混合架构可能是更务实的中间路线

架构革命很少是“全盘替换”，更多是“逐步渗透”。最务实的路线，是在Transformer的外部框架上保留稳定的工程优势，把注意力模块、位置编码模块、归一化模块替换成新设计。

一套常见的过渡策略是这样：

1. 保留Transformer的输入输出接口和整体堆叠方式。
2. 将内部标准Attention替换为线性或稀疏变体，先降低长序列成本。
3. 将位置编码替换为不受序列长度限制的连续编码方式。
4. 在模型深层加入跨层、跨模态的直接连接，打破单向流动。
5. 用蒸馏或渐进式训练，把成熟Transformer模型的知识迁移到新架构上。

这种方式不会立刻引发“革命”，但能降低新架构的落地风险。Mobius如果具备真正的架构潜力，它的价值很可能会先以混合形态出现在已有的训练框架中，而不是以一个全新训练范式的姿态一步到位。

4. 用五张滤网评估下一代架构：给Mobius做一次“压力测试”

4.1 第一张滤网：表达能力

任何新架构都必须回答：你的表达能力是否不弱于Transformer？

表达力评估不能只看语言困惑度，还要在合成任务上测试长距离依赖、多跳检索、坐标推理和结构泛化。一个相对完整的评估脚本，应该把以下任务纳入检查范围：

def evaluate_architecture(candidate, dataloaders, budget): report = {} report["long_range_retrieval"] = run_task(candidate, dataloaders["retrieval"]) report["multi_hop_reasoning"] = run_task(candidate, dataloaders["reasoning"]) report["coordinate_localization"] = run_task(candidate, dataloaders["coordinate"]) report["language_modeling"] = run_task(candidate, dataloaders["lm"]) report["train_cost"] = measure_train_flops(candidate, budget["gpu_hours"]) report["decode_cost"] = measure_decode_latency(candidate, budget["tokens"]) return serialize_report(report)

这套脚本的意义在于：新架构不能只在“标准语言模型”任务上接近Transformer，还必须在长序列、多跳、结构约束这些维度上证明自己的表达能力。如果连最简单的“给定两个位置，判断谁先出现”都做不好，那它的任何效率优势都难以抵消能力损失。

4.2 第二张滤网：计算效率

计算效率要同时看训练和解码两个阶段。很多架构在训练时看起来FLOPS很低，但解码时无法充分利用GPU并行，实际延迟反而更高。一个合理的对比维度如下：

这里容易踩的坑是只比较“单序列训练成本”。真正决定系统可用性的是“同等请求量下服务多少个并发”，这由解码吞吐和状态内存共同决定。如果一个新架构训练成本降低20%，但解码吞吐降低50%，那么在线服务场景下它是退步而不是进步。

4.3 第三张滤网：可训练性

一个架构如果在数学上漂亮但很难训练，那它在工业场景里基本无法落地。可训练性评估需要关注几个问题：

• 深层堆叠时梯度是否稳定。Transformer的一大贡献是残差连接和LayerNorm让100层以上的训练成为可能。
• 初始化是否敏感。新架构如果对初始化参数极其敏感，换一个随机种子就损失爆炸，那么距离可用还很远。
• loss曲线是否平滑。好的架构应该让训练在大部分超参数下都能稳定下降，而不是只在作者调好的那组参数下有效。
• 是否支持大规模并行。如果新的数据流存在强依赖，训练时的流水线并行效率会显著下降。

Mobius如果引入跨层回环或跨层直连，首先要回答的就是梯度如何在这些回环中稳定传播。这是所有非DAG结构架构都要面对的核心难题。

4.4 第四张滤网：软硬件生态适配

架构能否落地，一半取决于技术，一半取决于生态。围绕Transformer已经建立了极其庞大的软件栈：PyTorch算子、CUDA kernel、FlashAttention、TensorRT、vLLM、TGI、分布式并行框架、量化工具、稀疏化工具。一个新架构如果要真正进入生产，每个环节都要有人重新适配。

在评估阶段，至少问自己三个问题：

• 训练框架能不能用现有算子实现？如果每个前向都要写一个自定义kernel，开发成本会很高。
• 推理引擎能不能支持？如果vLLM、TensorRT不能直接加载，就需要额外开发推理服务。
• 是否能复用现有加速库？FlashAttention对标准Attention优化得极好，新架构如果采用不同于标准注意力的计算模式，就很难直接享受这个红利。

这里说的“生态适配成本”不是未来时，而是现在就要计入总成本。一个只在论文跑通、算力很低的架构，到了千卡集群上可能会暴露出大量工程问题。

4.5 第五张滤网：可验证的收益

最后一个滤网最硬：收益是否可验证。

可验证的标准包括：

• 同一团队或不同团队能不能独立复现论文结果。
• 效果提升是否在多个任务上成立，而不是只在作者选择的少数任务上成立。
• 是否在不同模型规模上都成立，比如参数量从1亿到70亿都有稳定收益。
• 是否有足够的训练时间、数据和算力细节供他人复现。
• 是否提供与Transformer在同预算下的直接对比，而不是单独展示新架构的绝对分数。

如果一个新架构只在某个特定规模、特定数据集上有效，那它更适合被称为“改进”而不是“革命”。Mobius目前最缺的，就是这个维度的公开证据。

5. 架构演进对工程团队意味着什么

5.1 从“换Backbone”到“重写算子”

对算法工程师来说，所谓架构演进可能只是“换一个Backbone”，但对系统工程师来说，架构变化会一路传导到算子层。

如果新架构只是调整注意力公式，比如用线性注意力替换标准注意力，那现有训练框架可以覆盖。如果新架构引入了跨层回环、图结构数据流、连续状态更新，那么：

• 训练时需要新的自动微分路径。
• 分布式并行时，张量切分策略要重新设计。
• 中间状态序列需要新的存储方式，内存管理不能沿用Transformer的层间流水假设。
• 推理引擎需要为新的状态更新逻辑单独写kernel。

这也是为什么架构革命会比想象中慢。模型结构从论文到生产，中间隔着大量系统工程。Mobius无论理念多先进，只要没有对应的高性能实现，就仍然停留在研究阶段。

5.2 训练框架、编译器与推理引擎都要跟着动

一个成熟的AI基础设施，几乎每一项优化都是针对Transformer的计算模式做的。

以推理引擎为例，vLLM的PagedAttention针对KV Cache做了分页管理，TensorRT的Transformer插件针对QKV投影和FFN做了融合，FlashAttention针对HBM带宽做了IO优化。这些优化全部隐含了“模型结构是标准Transformer”这个前提。新架构一旦改变注意力结构，这些优化就要重新评估。

在实践层面，工程团队可以先做一次“算子兼容性扫描”：把新架构前向图里的每个算子列出来，检查现有框架是否支持、有没有高性能kernel、能否进行算子融合。这个过程会很快暴露架构的真实工程成本。

5.3 数据与评测：不能只用旧基准

新架构需要新的评测口径。旧基准只回答“模型在相对固定的任务上表现如何”，不足以回答“新架构是否真的打开了新空间”。

建议增加以下几类评测：

• 长上下文压力测试：超过训练长度后，模型是否仍然保持稳定的检索能力。
• 模态对齐测试：跨模态检索、图文指代、音视频对齐等细粒度任务。
• 效率曲线测试：绘制“质量-成本”曲线，比较同等算力预算下新旧架构的质量差距。
• 长尾鲁棒性测试：处理拼写错误、噪声输入、领域外文本时的稳定程度。

这套评测体系不只是为了验证Mobius，也是为了更准确地判断整个架构演进的健康度。

5.4 什么时候值得跟进：一个务实的决策框架

不同阶段的团队，对Mobius这类新架构应采取不同的跟进策略：

学习环境里可以快速试错，因为试错成本只是时间。生产环境里不能轻易把核心链路切换到一个没有推理引擎、没有监控工具、没有社区支持的新架构上。正确的做法是：先在离线任务上做小规模验证，如果再叠加“效率提升明显、效果持平或更好、至少一个主流推理引擎支持”三个条件同时成立，再考虑更大范围迁移。

6. 关于Mobius的几个常见误判与调整思路

6.1 误判一：把“另一种注意力”当成“全新架构”

现象：看到一个新注意力公式，比如某种线性注意力或稀疏注意力，就认为这是下一代架构革命。

原因：对“架构层”的定义不清楚。注意力公式属于交互计算层，架构则包括表示方式、信息流动、训练目标和系统实现。只改注意力公式，本质上是Transformer的变体，而不是全新架构。

调整思路：把变化分成四个层级来审视：

• 表示层：输入是离散token还是连续状态。
• 交互层：内部使用标准注意力还是其他交互算子。
• 流动层：信息是否只从低层向高层单向传递。
• 系统层：训练和推理能否复用现有基础设施。

只有多个层级同时改变，才有资格讨论“架构革命”。如果Mobius只在第三层做文章，那它就是一次重要改进，但还没有脱离Transformer的边界。

6.2 误判二：只看单点精度，不看效率曲线

现象：新架构在某个benchmark上比Transformer高0.5个百分点，就认为应该切换。

原因：忽略了达到这个精度消耗了多少训练资源和推理资源。如果新架构训练成本是Transformer的3倍，那0.5个百分点的精度提升没有实际价值。

调整思路：绘制效率曲线，横轴是训练FLOPS或训练时间，纵轴是目标任务指标。在同等算力下比较两条曲线，只有当新架构的曲线在上方，才能说明“同样的钱买到更好的效果”。否则就应该认为新架构暂时不具备竞争力。

6.3 误判三：低估生态成本，高估架构红利

现象：已经看到新架构有20%的效率提升，立刻决定迁移核心业务。

原因：没有把生态适配成本计入收益。PyTorch、FlashAttention、TensorRT、vLLM都是围绕Transformer优化的，新架构的每个算子都需要工程验证。这个成本在初期可能完全抵消架构红利。

调整思路：先把“架构红利”和“迁移成本”分开记账。架构红利是模型效果和Capex的改善，迁移成本包括开发时长、人员培训、推理引擎适配、监控重建。只有当红利净值明显为正，才进入正式决策。

6.4 误判四：把“论文有效”等同于“工业可用”

现象：论文里展示了很好的效果和很低的显存占用，就认为可以立刻部署。

原因：论文实验通常在固定规模、固定数据分布、有限任务上进行，缺少长尾、噪声、失败恢复、多租户并发等工业场景的验证。一个在论文里稳定收敛的架构，在真实数据上可能频繁loss尖刺。

调整思路：建立“工业试用”标准：

• 在至少10倍于论文batch size的规模下跑通。
• 在包含噪声和长尾分布的自有数据上复现收益。
• 连续训练24小时以上，观察loss是否稳定。
• 在推理引擎上验证吞吐、延迟和显存占用。
• 准备回滚方案，一旦新架构出现顽固问题能立即切换回Transformer。

这五条全部通过之前，新架构都处于“候选观察期”，而不是“投产期”。

7. 一份可复用的架构技术评估清单

在做技术选型时，可以按这个清单逐项打分，避免被单个亮点带偏：

architecture_review: candidate: Mobius review_date: evidence_needed: - 是否有完整技术报告或论文 - 是否有可运行的公开代码 - 是否有独立第三方复现 effect_dimension: - 多任务平均效果是否优于基线 - 长序列、多跳推理是否有明显收益 - 跨模态对齐是否真实改善 cost_dimension: - 训练FLOPS是否下降 - 解码吞吐是否提升 - 状态缓存内存是否减少 - 算子是否能在现有框架下运行 engineering_dimension: - PyTorch支持度 - 推理引擎支持度 - 分布式并行适配度 - 量化与稀疏化兼容度 risk_dimension: - 训练稳定性 - 初始化敏感性 - 长尾数据鲁棒性 - 社区与人才储备 decision_rule: - 至少两个维度获得明显优势 - 至少一项收益超过20% - 必须有生产环境可验证的推理路径 - 必须保留回滚到Transformer的通道

这套清单不只适用于Mobius，也适用于未来任何新的架构候选。它强迫评估者从“这个技术听起来很厉害”切换到“这个技术能在我的任务、我的成本约束、我的运维能力下落地吗”。

回到最初的问题：Mobius能否引发下一代模型架构的革命？答案取决于它能不能在表达力、效率、可训练性、生态适配和可验证收益这五个维度里至少拿下两个。架构革命的标志不是替代某个模型，而是让原本做不到的事情变得便宜。当一个新的架构能在同等预算下持续产生可复现的收益，并且有工程团队愿意为它建设工具链时，它才有资格成为下一代基座。在Mobius拿出足够完整的证据之前，更合理的态度是保持跟进而非押注，用清单逐项验证，让数据决定它是否真的站在了Transformer的肩膀之上。