最近在梳理下一代模型架构时总被同学问到同一个问题Transformer 是不是真的到顶了如果到顶了下一个能打的架构是什么这个问题其实不能简单回答“是”或“否”。更准确的说法是Transformer 在大模型时代仍然是最稳妥的底座但它的扩展成本和有效上下文利用率已经在多个方向出现明显的边际收益递减。于是围绕“Transformer 换道”的探索越来越多Mobius 就是其中一个值得拆开看的架构方向。本文会从 Transformer 的工作原理和瓶颈讲起再分析 Mobius 在数学直觉上提供了哪些不一样的东西最后给出一个可以运行的 PyTorch 验证方案以及一套评估新架构的工程思路。适合对 LLM 架构有一定基础、正在关注下一代模型架构的开发者也适合想动手做架构实验的同学。1. 背景与核心概念在看 Mobius 之前有必要先把 Transformer 为什么能统领大模型这件事说清楚。很多人背过 Self-Attention 的公式但对它“为什么赢”缺乏系统理解。1.1 Transformer 为什么能成为大模型底座Transformer 核心是缩放点积注意力Attention(Q, K, V) softmax(QK^T / sqrt(d_k)) VQ、K、V 分别由输入序列经过线性变换得到得到的是序列内部任意两个位置之间的相关性权重。正是因为这种“两两直接交互”的设计Transformer 与 RNN 有本质区别。RNN 擅长按时间步逐步处理序列但每一步必须等上一步算完串行特性让它在 GPU 上很难大规模并行。LSTM 和 GRU 虽然缓解了梯度消失但长距离依赖仍然不够稳定。Transformer 的注意力机制把序列中任意两个位置的距离缩短为一次矩阵运算从架构上绕开了“逐步传递”带来的长程依赖问题。再加上 ResNet 风格的残差连接、LayerNorm、Feed-Forward NetworkFFN以及位置编码Transformer 成了一个高度并行、相对稳定、可扩展性极强的模块。后续 GPT、BERT、T5 等模型把“预训练 微调”范式推到了极致Transformer 也因此从 NLP 一路扩展到 CV、多模态、语音等领域。1.2 从 RNN 到 Transformer 再到“换道”探索简单梳理一下这条演进线模型核心机制主要问题复杂度RNN / LSTM循环状态传递难以并行长程依赖弱O(n)Transformer自注意力长序列计算和显存成本高O(n²)Linear Attention / Performer核函数近似注意力表达能力强弱依赖核函数设计O(n)Longformer / BigBird稀疏注意力全局信息依赖少量特殊 tokenO(n)Mamba / RWKV状态空间模型 / 线性 RNN序列建模能力仍在验证中O(n)Mobius 方向双曲空间 / Möbius 变换建模序列工程生态尚未成熟待验证可以看到大家并不满足于“优化 Transformer”而是在尝试把序列建模的底层几何结构换掉。Mobius 就是其中一个有理论深度的方向。2. Transformer 的“上限”到底在哪把“上限触顶”说成“Transformer 已经完全不行了”是不严谨的。更准确的说法是Transformer 在实际工程中的扩展效率和有效上下文利用已经面临多个硬约束。2.1 注意力矩阵的平方复杂度标准 Self-Attention 需要对 QK^T 计算 n×n 的矩阵空间和时间复杂度都是 O(n²)。序列长度从 2K 涨到 8K、32K、128K计算量不是线性增长而是平方级增长。针对这个问题业界提出了很多方案局部窗口注意力比如 Swin Transformer 里的 window attention。稀疏注意力比如 Longformer。线性注意力把 softmax 换成可分解的核函数比如 Performer。混合注意力在注意力层之间插入全局 token。这些方案都能降低复杂度但都存在一个共性代价损失一部分全局建模能力。换句话说长序列场景下Transformer 的“全局注意力”优势正在被成本稀释。2.2 长上下文不等于长记忆很多人把“上下文窗口达到 128K”等同于“模型能记住 128K 的信息”这是一个常见的认知误区。实际评测发现当关键信息位于长文本中间位置时模型的表现会明显下降这种现象通常称为 Lost in the Middle。也就是说模型即使把 128K token 都放进了上下文窗口真正有效利用的往往还是开头和结尾的部分。这说明 Transformer 在处理超长序列时不仅面临算力问题还面临“注意力分配”问题。窗口扩得越大内部信息相互干扰的概率越高注意力权重分布容易变得碎片化。2.3 KV Cache 与推理成本自回归生成时要反复读取历史 token 对应的 Key 和 Value这些缓存就是 KV Cache。序列越长KV Cache 占用的显存越大推理吞吐量受到明显限制。举个例子一个 7B 模型在生成 2K 长度的回复时KV Cache 可能占据数 GB 显存。到了 32K 上下文显存压力会让小显存显卡直接无法推理。这也是为什么近期很多模型在 KV Cache 压缩上做文章比如量化、剪枝、张量分解等。2.4 扩展收益递减与幻觉问题Scaling Laws 告诉我们在数据、参数、算力按比例扩大时模型能力会稳定提升。但这里有个前提数据质量要足够高数据总量要足够大。当数据集已经覆盖了互联网大部分公开语料之后继续增加模型规模带来的提升会逐渐放缓。同时自回归模型天生只优化“下一个 token 的概率”它并不理解事实边界因此在信息密度低的场景下幻觉问题会被放大。这些问题不是靠简单增加 Transformer 层数就能解决的它需要架构层面提供更强的结构性约束。2.5 跨模态输入的拓扑失配Transformer 处理图像时通常要先切成 Patch比如 ViT 把图片切成 16×16 的 Patch然后展平成 token。这种方式其实牺牲了图像本身的空间拓扑结构。Swin Transformer 通过窗口注意力和 shifted window 来缓解这个问题但本质上还是在“尽量逼近卷积的局部先验”而不是从图像本身的几何结构出发设计算子。多模态场景下文本是一维序列图像是二维网格视频是三维时空把一切都强行展平成 token并不一定是最优编码方式。3. Mobius 架构数学直觉与核心主张Mobius 这个名字来自数学中的莫比乌斯带和 Möbius 变换。它的核心思路是把序列建模的空间结构从“直线”或“平面”换成带扭转和周期性的拓扑结构从而在有限参数下表达更复杂的依赖关系。3.1 莫比乌斯带单一表面与循环周期莫比乌斯带最著名的特征是它只有一个面只有一条边界。你沿着表面走走两圈才会回到原点而且“内外”是连通的。这给序列建模提供了一个非常有趣的启发信息在莫比乌斯带上循环传递时不需要额外的路径切换。两圈一循环意味着状态更新可以拥有一个自然的周期。单面性质让“前后文”的联系可以跨越传统线性顺序。如果模型的状态传递发生在类似莫比乌斯带的拓扑结构中那么长距离依赖可能不再依赖“路径长度”而是依赖“循环圈数”。这在直觉上更接近人类阅读时的回看和联想行为。需要说明的是这里的“莫比乌斯带”更多是一种设计哲学而不是说模型内部真的放了一条物理纸带。具体实现需要落到数学算子上。3.2 Möbius 变换双曲空间的等距变换Möbius 变换在复平面上的标准形式是f(z) (a*z b) / (c*z d)其中 a、b、c、d 是复数参数并且要求 ad - bc ! 0。这个变换在双曲几何中扮演等距变换的角色可以理解为“在双曲空间中保持距离结构的操作”。为什么双曲空间很重要因为自然语言和知识图谱里的层级结构非常普遍。比如“动物”下面是“哺乳动物”“哺乳动物”下面是“狗”。这种树状结构如果嵌入到欧几里得空间需要很高维度才能表达父子关系但放入双曲空间用很小的维度就能表达得很清楚。Mobius 架构的探索方向之一就是把 token 嵌入和状态更新放到双曲空间里利用 Möbius 变换来建模序列中的层次化信息。与 Transformer 的线性投影相比Möbius 变换天然带有非线性结构而且这种非线性来自几何本身不是靠激活函数硬生生加进去的。3.3 与 Mamba、线性注意力的区别Mamba 这类状态空间模型的核心是用固定的状态转移矩阵 A 和输入输出投影 B、C在 O(n) 复杂度内完成序列建模。它的优点是快但状态更新是线性的表达复杂动态模式时比较吃力。Mobius 方向的差异在于状态更新用 Möbius 变换而非简单矩阵乘法。空间结构从欧几里得空间扩展到双曲空间。模型对层级结构和周期结构有更强的归纳偏置。严格来说Mobius 不一定要完全取代注意力它也可以作为注意力机制的补充层存在比如替换 FFN、位置编码或状态更新函数。当前公开的讨论更多把它看作“架构改造的数学工具箱”而不是一个已经定型的单一模型。3.4 为什么说它可能是“下一代”探索方向判断一个架构是否值得研究可以看三个问题能不能解决 Transformer 当前最痛的问题有没有一套自洽的数学基础在小规模实验里能不能看到增量收益Mobius 在这三方面都有故事可讲它面向长程依赖和结构压缩底层有双曲几何和复分析支撑并且可以通过 Möbius 变换的参数化设计把它嵌入现有 Transformer 做增量验证。当然最终是否成立取决于大量实验和工程落地而不是概念层面的“看起来很美”。4. 一个可运行的验证方案PyTorch 实现下面进入实操环节。我不打算凭空实现一个几十亿参数的大模型而是给出一套“最小验证方案”用来验证 Möbius 变换作为算子插入模型后能否跑通、能否维持训练稳定性。4.1 项目结构与环境建议环境Python 3.10 或更高版本。PyTorch 2.x支持复数运算。如果有 GPU 更好没有 GPU 也能跑 CPU 小规模验证。transformers 库用于加载基线模型版本按实际环境调整。项目结构如下mobius-exp/ ├── mobius_layer.py # Möbius 变换层 ├── position.py # 环形位置编码 ├── train_compare.py # 对比训练脚本 └── requirements.txt这份代码的目的不是马上刷出 SOTA而是帮助你确认三件事Möbius 变换能否在 PyTorch 中稳定前向和反向。训练 loss 能不能正常下降。与标准 Transformer 基线相比收敛速度大概是什么水平。4.2 实现 Möbius 变换层先实现一个基础的 Möbius 变换层。为了保持数值稳定我会在变换后做一次 Layer Normalization并限制参数的初始化范围。# 文件路径mobius-exp/mobius_layer.py import torch import torch.nn as nn import torch.nn.functional as F class MobiusTransform(nn.Module): 一个简化的 Möbius 变换层。 在双曲空间体系里Möbius 变换可以表达为 f(z) (a*z b) / (c*z d) 这里把输入当作复向量处理参数 a、b、c、d 也是可学习的复参数。 为了避免除零和数值溢出做了 epsilon 保护。 def __init__(self, dim: int, eps: float 1e-6): super().__init__() self.dim dim self.eps eps # 初始化参数接近单位变换a1, b0, c0, d1 # 这样模型在初始阶段不会剧烈改变输入分布 scale 0.05 self.a nn.Parameter(torch.randn(dim, dtypetorch.complex64) * scale torch.tensor(1.0, dtypetorch.complex64)) self.b nn.Parameter(torch.randn(dim, dtypetorch.complex64) * scale) self.c nn.Parameter(torch.randn(dim, dtypetorch.complex64) * scale) self.d nn.Parameter(torch.randn(dim, dtypetorch.complex64) * scale torch.tensor(1.0, dtypetorch.complex64)) # 变换后接一个 LayerNorm稳定训练 self.norm nn.LayerNorm(dim) def forward(self, x: torch.Tensor) - torch.Tensor: x: [batch, seq_len, dim] 先转为复数向量做 Möbius 变换再转回实数。 original_dtype x.dtype x_c x.to(torch.complex64) numerator self.a * x_c self.b denominator self.c * x_c self.d # 防止复数的实部或虚部接近 0 时的数值问题 denominator_real denominator.real.abs() self.eps denominator_imag denominator.imag.abs() self.eps safe_denominator torch.complex(denominator_real, denominator_imag) y_c numerator / safe_denominator y torch.view_as_real(y_c) # [batch, seq_len, dim, 2] # 将实部和虚部拼起来后投影回 dim 维度 b, s, d, _ y.shape y y.reshape(b, s, d * 2) y F.linear(y, torch.eye(d * 2, d, dtypeoriginal_dtype).to(y.device)) y self.norm(y) return y.to(original_dtype)这段代码有几个关键点复数参数在 PyTorch 中的 dtype 是 complex64需要输入也转为复数。除以复数时先构造一个安全的分母避免实部或虚部为零导致的除零问题。输出阶段把复数的实部和虚部拼接后压缩到原维度再接 LayerNorm。这里的实现属于“教学验证”版本距离生产级实现还有优化空间但它足够让你验证“Möbius 变换作为网络层是否可训练”。4.3 环形位置编码Möbius 拓扑的一个重要特征是“两圈回到原点”。为了在序列建模里模拟这种周期性可以设计一个环形位置编码让位置索引在奇偶轮次之间交替。# 文件路径mobius-exp/position.py import torch def mobius_position_ids(seq_len: int, cycle_len: int) - torch.Tensor: 生成环形位置索引。 模拟 Möbius 带两圈一循环的性质 位置先递增到 cycle_len再镜像递减到 0然后再循环。 positions [] idx 0 direction 1 for _ in range(seq_len): positions.append(idx) if direction 1: if idx cycle_len - 1: direction -1 idx - 1 else: idx 1 else: if idx 0: direction 1 idx 1 else: idx - 1 return torch.tensor(positions, dtypetorch.long) if __name__ __main__: # 示例cycle_len4 时序列长度 16 的位置索引 ids mobius_position_ids(16, 4) print(ids)预期输出类似tensor([0, 1, 2, 3, 2, 1, 0, 1, 2, 3, 2, 1, 0, 1, 2, 3])这个位置索引不是唯一答案但它演示了“折返 周期”的序列结构。你可以用它替换模型的 position_ids再观察长序列任务上是否有变化。4.4 对比训练脚本为了验证 Möbius 层能否正常训练我写一个非常小的对比脚本用随机生成的整数序列做语言建模分别跑“标准 Transformer”和“标准 Transformer Möbius 层”观察 loss 是否下降。# 文件路径mobius-exp/train_compare.py import torch import torch.nn as nn from torch.utils.data import DataLoader, TensorDataset from mobius_layer import MobiusTransform class TinyLanguageModel(nn.Module): def __init__(self, vocab_size, dim, num_layers, use_mobiusFalse): super().__init__() self.embed nn.Embedding(vocab_size, dim) self.use_mobius use_mobius if use_mobius: self.mobius MobiusTransform(dim) self.layers nn.TransformerEncoderLayer( d_modeldim, nhead2, dim_feedforwarddim * 2, dropout0.1, batch_firstTrue, ) self.lm_head nn.Linear(dim, vocab_size) def forward(self, x): hidden self.embed(x) if self.use_mobius: hidden self.mobius(hidden) hidden self.layers(hidden) logits self.lm_head(hidden) return logits def make_batch(vocab_size, seq_len, batch_size): data torch.randint(0, vocab_size, (batch_size, seq_len 1)) x data[:, :-1] y data[:, 1:] return x, y def train_step(model, optimizer, criterion, x, y): model.train() optimizer.zero_grad() logits model(x) loss criterion(logits.reshape(-1, logits.size(-1)), y.reshape(-1)) loss.backward() nn.utils.clip_grad_norm_(model.parameters(), 1.0) optimizer.step() return loss.item() def main(): torch.manual_seed(42) vocab_size 128 seq_len 32 batch_size 16 dim 64 steps 100 for use_mobius in [False, True]: model TinyLanguageModel(vocab_size, dim, num_layers1, use_mobiususe_mobius) optimizer torch.optim.AdamW(model.parameters(), lr1e-3) criterion nn.CrossEntropyLoss() print(f\n use_mobius{use_mobius} ) for step in range(1, steps 1): x, y make_batch(vocab_size, seq_len, batch_size) loss train_step(model, optimizer, criterion, x, y) if step % 10 0: print(fstep {step}, loss {loss:.4f}) if __name__ __main__: main()运行方式pip install torch python train_compare.py在没有 GPU 的小机器上也能跑主要看 loss 是否能稳定下降。如果带 Mobius 的版本 loss 也能正常收敛说明这个算子至少在训练稳定性层面是可行的。4.5 如何把 Möbius 层接入真实 Transformer在小脚本里我把 Möbius 层放在了 Embedding 之后、TransformerEncoderLayer 之前。真实项目里可以尝试几个不同插入点Embedding 之后对输入表示先做一次双曲空间变换。FFN 位置替换原来的 Feed-Forward Network考察非线性表达能力。Attention 输出之后在残差连接之前增加几何变换。位置编码模块用 Mobius 位置编码替代 RoPE 或 ALiBi。建议不要一次性全部替换。先选一个插入点跑通小规模实验再逐步扩展。架构创新最怕的是“改动太大出了问题不知道来自哪里”。5. 如何科学评估新架构很多人在架构实验里容易犯一个错误只盯 PPL困惑度一个指标。对于 Mobius 这类新架构只看 PPL 远远不够。5.1 指标体系至少关注四类指标指标类型具体指标说明语言建模能力Perplexity代表基础建模能力但受 tokenizer 影响长程依赖能力LongBench、ZeroSCROLLS模型对长文本中间信息的利用能力推理效率显存占用、Tokens/s、首 token 时延新架构必须证明自己“便宜”才有工程价值训练稳定性梯度范数、loss 曲线、是否出现 NaN新算子数值稳定性是关键风险5.2 基线对比新架构必须在完全相同的条件下和 Transformer 对比相同的 tokenizer。相同的训练语料和 token 数量。相同的参数量至少数量级一致。相同的训练步数和优化器设置。如果基线条件不一致对比出来的差距无法被有效归因。5.3 消融实验为了证明“是 Möbius 变换带来的提升而不是参数增多带来的提升”要做消融实验A 组标准 Transformer。B 组标准 Transformer 普通线性层代替 Mobius 层。C 组标准 Transformer Mobius 变换层。如果 C 组比 B 组效果好说明提升确实来自 Möbius 变换的几何性质而不是额外参数。5.4 长序列与任务验证小规模语言建模 loss 下降只能说明“能训练”。能不能在真实业务场景中打败 Transformer需要做长序列压力测试。推荐用这样的验证路径用 1B 以下小模型验证基础模型能力。在长文本分类、摘要、检索任务上测试效果。用 Needle-in-a-Haystack 方法测试模型从长上下文中取信息的能力。对比推理阶段的显存和吞吐量。只有在这些测试里表现出明确优势才值得继续向更大的模型参数规模推进。6. 常见问题与排查思路在跑 Mobius 相关实验时最常遇到的问题可以归纳为下面几类。问题现象常见原因解决思路训练 loss 不下降参数初始化不合理让 a、d 初始化为 1b、c 初始化为 0loss 出现 NaN复数除法分母接近 0增加 eps 保护或对分母做 clamp显存占用不降只是把 Mobius 层加到 Attention 上长序列瓶颈仍在 Attention需配合线性注意力或稀疏注意力小规模实验有效大规模失效训练数据不足或超参不匹配保持参数量相当增加训练步数重新调学习率与基线差距不明显插入位置选择不佳尝试多个插入点检查梯度流动推理速度反而更慢复数运算在 GPU 上算子尚未优化考虑用实数矩阵参数化近似或等待库更新这里要特别提醒一个问题如果只是把 Mobius 变换层插入标准 TransformerAttention 的 O(n²) 复杂度依然存在。在这种情况下显存不会被“革命性”降低。要让长序列真正受益需要把 Mobius 变换与状态空间模型、稀疏注意力或分段注意力结合起来。7. 工程落地与最佳实践架构探索不能只停留在论文和实验脚本最终要回答“能不能落地”的问题。7.1 从插件到主架构对于大多数团队最稳妥的做法不是一步到位把模型替换成 Mobius 架构而是先做成插件。以 Transformer 的 FFN 为例原始h h FFN(LayerNorm(h)) 改造h h MobiusBlock(LayerNorm(h))插件化改造的好处是可以复用成熟的 Attention 组件。便于逐步观察收益。出问题时可以快速回退。只有插件化改造在小规模实验里持续表现出优势才值得进一步设计完整的 Mobius 主架构。7.2 新算子部署风险Mobius 变换涉及复数运算在 PyTorch 里很方便但到了推理引擎就有兼容性问题。vLLM、TensorRT-LLM 等推理框架可能不支持自定义复数算子。ONNX 导出复杂算子的支持度有限。边缘设备上可能需要手写 CUDA 或 C 算子。工程上可行的折衷方案是训练阶段用完整 Mobius 变换推理阶段把它蒸馏成更常规的算子组合或者用实数参数化近似。7.3 数据、权限与合规任何时候探索新架构都不能绕开数据合规问题。训练语料必须有合法授权。涉及用户隐私数据时必须做脱敏处理。基准测试集要避免污染不能拿训练集里的数据去测“长程能力”。大规模 GPU 实验需要评估成本上限避免超出预算。新架构实验通常会消耗大量算力建议先做小规模验证再申请大规模资源并把每一步实验的数据、脚本、日志记录下来方便复盘。7.4 团队的架构评估流程一个相对靠谱的流程是明确要解决的问题比如“长上下文中间信息利用率低”。选择 1 到 2 个基线模型跑通复现。实现 Mobius 插件小参数规模训练记录 loss 曲线。对比相同预算下与 Transformer 基线的差异。如果收益稳定再逐步扩大数据规模和模型规模。同步做推理性能测试确认部署可行性。形成完整的实验报告再决定是否全线迁移。8. 总结与建议回到最初的问题Transformer 上限触顶了吗从工程角度看它还在被大规模使用短期内不会被取代从研究角度看它的扩展效率和长序列利用确实已经触到了“工程天花板”这给新架构留出了空间。Mobius 作为双曲几何与序列建模的结合方向最大的价值不是立刻替代 Transformer而是提供了一套新的设计语言把“线性堆层”变成“几何变换”把“欧几里得空间”换成“双曲空间”把“注意力路径”升级为“周期循环结构”。如果你打算参与这个方向的探索我的建议是先不要急着从零训练一个大模型。把那套 PyTorch 小脚本跑起来把 Mobius 变换层插进一个现成的小 Transformer 里观察 loss 曲线、梯度范数和长序列任务表现。真正有价值的结论往往来自这些不起眼的小实验而不是概念层面的争论。架构革命从来不是一篇论文或一篇文章能定论的它需要大量可复现的实验、扎实的算子优化和工程验证。Transformer 的统治地位被打破的那一天一定是从一个“看起来很小”的插件开始的。