每隔一段时间技术社区就会出现一轮关于 Transformer 的“退役预告”。新论文的标题越来越直白有的在长序列上做到线性复杂度有的宣布用 RNN 结构重新发明记忆模型有的直接把“Transformer 之后是什么”写进摘要。如果你长期关注大模型方向一定会有一种感觉Transformer 好像明天就要被替换。可一旦真正跑到工程里去看又会发现另一件事绝大多数线上系统依然跑在 Transformer 和它的各种变体上。这是否意味着那些“取代”都只是炒作也不是。真正在发生的不是单点革命而是架构分流。2024 年以来状态空间模型、线性注意力、RNN 式混合架构陆续从论文走向开源权重和推理框架它们不是在口号层面挑战 Transformer而是在一个非常具体的指标上发起攻击长文本场景下的推理成本和显存占用。普通开发者最关心的问题也不是“谁取代谁”而是“我什么时候应该从 Transformer 迁移出去什么时候不应该”。这篇文章的目标就是把这个判断框架讲清楚。1. 为什么越来越多人想取代 Transformer要理解“取代 Transformer”这件事先得理解 Transformer 当年为什么能赢。Transformer 在 2017 年提出时最大的突破不是“模型更深”而是用自注意力机制替代了循环神经网络中的顺序依赖。RNN 必须按时间步逐个处理单词梯度还要沿着时间方向反向传播长序列训练非常痛苦。CNN 虽然可以并行但要靠堆叠卷积核来扩大感受野长距离信息传递效率不高。Transformer 的 Self-Attention 让每个 token 直接和序列中所有 token 两两交互一步建模全局关系而且整段序列可以并行计算恰好踩中了 GPU 算力扩张的节奏。这也是为什么后来几乎所有大模型都选择 Transformer 而不回头。但注意这个“赢”是有代价的。Self-Attention 的时间和空间复杂度都是 O(n²)其中 n 是序列长度。序列越长计算量和显存占用就越高。到了推理阶段问题更加突出生成式模型的每一步都要维护一份 KV Cache把已经算过的 Key 和 Value 缓存下来避免重复计算。随着上下文长度从 2k 涨到 32k、128kKV Cache 也会线性增长显存占用越来越夸张。于是长文档、代码仓库级上下文、多轮 Agent 对话这类真实业务场景最先撞上 Transformer 的成本墙。真正的“取代压力”不在模型质量上而在工程成本里。Transformer 依然是目前综合效果最好的基础架构但它的运行成本正在让越来越多团队感到不舒服。如果一个新架构能在大致相同的效果下把推理显存降一半、长文本吞吐提升数倍那么即使它在个别任务上不如 Transformer也足以在某些场景里完成替换。这就是所有非 Transformer 研究的共同出发点。如果我们把这段话压缩成一句判断Transformer 的真正护城河已经从“精度最好”变成了“工程生态最完整”。非 Transformer 架构的真实切入点是“成本与能力的权衡曲线”而不是简单的“我比你聪明”。2. 替代方案的核心思路绕开平方复杂度过去两年出现的被讨论最多的非 Transformer 架构几乎都围绕同一个目标把序列建模的复杂度从 O(n²) 降下来同时保留“可并行训练”和“长程依赖建模”这两个关键能力。它们不是简单回归到 2017 年之前的 RNN/LSTM而是换了一种方式设计记忆结构。2.1 状态空间模型用状态变量代替注意力状态空间模型State Space ModelSSM是一类历史悠久的控制系统模型。简单理解它把输入序列 x_t 通过一个隐状态 h_t 逐步更新每一步只依赖当前输入和上一步状态天然是 O(n) 或 O(1) 的复杂度。真正让 SSM 进入大模型视野的是 S4 系列工作它把连续卷积、递归计算和线性代数结合在一起既能用卷积实现并行训练又能在推理时保持常量级状态。但 S4 有一个明显短板它的参数是固定的相当于“对序列里所有位置一视同仁”。Mamba 在 S4 基础上引入了选择机制让模型根据当前输入决定状态中哪些信息应该保留、哪些应该遗忘。这一步改动看似不大却让 SSM 第一次在语言建模任务上摸到了和 Transformer 接近的效果。Mamba 也因此成为“取代 Transformer”讨论中最具代表性的名字。2.2 线性注意力把 softmax 换成核函数标准的 Self-Attention 是计算 Query 和 Key 的 softmax 相似度再对 Value 加权求和。这一步 O(n²) 的根源在于“每个 Query 都要和每个 Key 做点积”。线性注意力的思路是能不能不计算完整的注意力矩阵而是先用某种核函数把 Query 和 Key 映射到高维空间然后交换求和顺序。原来需要先算 QK^T再和 V 相乘现在可以先算 K^T V再和 Q 相乘。复杂度从 O(n²) 降为 O(n)。这类方法最著名的代表是 Performer以及后来的各种 linear attention 变体。好处是理论复杂度低坏处是实际效果往往不如 softmax attention 稳定尤其是在长距离依赖任务上。因此很多论文并不把线性注意力当成“最优解”而是把它当作混合架构中的一个组件。2.3 RNN 式混合把 Transformer 的训练经验搬回 RNNRWKV 和 RetNet 走的是另一条路线继续保持 RNN 的递归推理形式但在训练阶段借鉴 Transformer 的并行策略。RWKV 设计了“时间混合”机制用类似注意力的方式在不同时间步之间传递信息但推理时只保留一个固定大小的状态。RetNet 则提出了三种计算模式并行训练模式、循环推理模式和分块递归模式。训练时用并行矩阵乘法推理时用 O(1) 的递归状态兼顾效率和兼容性。这个思想后来也被很多混合架构吸收。2.4 混合架构不选边只取长补短从经验来看纯 SSM 或纯 RNN 模型在语言建模上虽然进步很快但还没有在任何维度上全面压过 Transformer。因此越来越多研究走向混合模型一部分层用注意力一部分层用 SSM或者在全局用线性注意力、在局部用窗口注意力。Jamba 就是这类混合模型的代表。混合架构背后的判断是与其讨论“谁取代谁”不如把 Transformer 的强项和线性结构的效率放进同一个模型让注意力处理关键信息让 SSM 承担长序列的骨架计算。这也是生产环境最可能先落地的方向因为迁移风险比纯架构替换低很多。下表把这几个概念放在一起对比架构方向核心思想训练方式推理成本代表工作TransformerSoftmax 自注意力全局并行注意力 O(n²)KV Cache 随上下文增长GPT、Llama、Qwen 等SSM状态空间递推并行扫描固定大小状态线性解码S4、Mamba、Mamba-2线性注意力核函数近似交换求和顺序全局并行O(n) 复杂度Performer、Linear AttentionRNN 式混合线性递归 并行训练并行训练/递归推理O(1) 状态递推RWKV、RetNet、xLSTM混合架构Attention SSM 混合堆叠全局并行近似线性Jamba 等需要提醒的是“推理成本 O(1)”不等于“每一步生成更快”而是指每一步使用的内存状态大小固定不会随上下文长度膨胀。实际速度还要看算子实现、显存带宽和内核优化这一点在第 5 节会展开。3. 主要候选架构盘点Mamba、RWKV、RetNet、xLSTM 与混合模型这一节不打算把每篇论文都展开而是以工程视角简要说明每个架构“能拿来干什么”和“有什么坑”。3.1 Mamba目前最受关注的非 Transformer 开源方案Mamba 隶属于 SSM 家族。相比前代 S4它对每个输入 token 动态计算状态转移参数让模型具备“选择性记忆”的能力。从代码库上看Mamba 提供了高效的 CUDA 算子训练和推理速度在长序列上确实比同规模 Transformer 更占优。它的适用场景很清晰超长文本理解与生成例如一次处理整本书级别的内容端侧或单卡推理因为不需要维护不断膨胀的 KV Cache需要低显存的 RAG 场景可以把大量文档一次性塞进模型。但 Mamba 生态目前仍然小于 Transformer。量化工具、推理框架、LoRA 微调支持还在追赶中部分算子依赖 Linux CUDA 环境Windows 用户使用门槛更高。如果你只是想快速试一下可以先使用 HuggingFace transformers 的 Python 实现不必一开始就编译原生内核。3.2 RWKV社区驱动的 RNN 大语言模型RWKV 的定位非常务实把 RNN 的推理效率和 Transformer 的并行训练能力结合起来。它突出的优点是社区活跃开源权重丰富而且有一批中文社区模型对国内开发者比较友好。RWKV 的推理状态固定不随文本长度增长CPU 上也能跑出可用的速度。它的坑在于模型结构和 transformer 差异较大很多为 Transformer 设计的工具链不能直接复用如果要深度定制需要理解“时间混合”和“通道混合”两套模块。此外RWKV 在短文本和复杂推理任务上和同参数量 Transformer 相比仍有差距生产选择时需要先跑自己的业务评测集。3.3 RetNet三种模式切换的架构设计RetNet 来自研究机构核心卖点是“训练、推理、分块”三种模式。训练时用并行矩阵计算推理时用循环状态还可以按 chunk 分块来处理中等长度的序列。这使得它既有 Transformer 的并行训练能力又有 RNN 的低成本推理结构。RetNet 的工程化难度在于三种模式对应多套计算逻辑需要投入更多开发资源去统一实现。它目前在开源社区的模型和权重数量不如 Mamba 和 RWKV更多是作为研究方案被引用但如果未来有更多混合模型采用它这个方向会重新热门起来。3.4 xLSTM旧架构的野心翻新xLSTM 是 Hochreiter 团队LSTM 原作者团队在 2024 年前后提出的新架构。它试图解决传统 LSTM 记忆容量有限、无法并行训练等问题引入了矩阵记忆和指数门控等新机制让 RNN 家族重新具备竞争力。从工程角度看xLSTM 的意义更多是“证明 RNN 路线没有被放弃而且还在进化”。但要达到大模型生产级别还需要更多实际权重、预训练数据和推理框架支持。现阶段可以把它当作理解 RNN 新进展的学习材料直接部署到业务中的团队较少。3.5 混合架构最可能提前落地的方向混合架构的核心思路是“注意力管关键SSM 管长尾”。例如在模型的前几层和最后几层使用 SSM中间层保留部分注意力既控制长序列成本又保证复杂语义建模能力。Jamba 是这一类模型的代表。它的出现说明工业界并不关心“是不是纯 Transformer”只关心“每 token 成本能不能降下来效果能不能守住”。对于应用团队来说混合架构可能是迁移成本最低的切入点很多 Transformer 生态的工具依然能用模型底座换成了成本更低的骨架。综合来看这些架构没有一个已经在所有维度上打败 Transformer。但它们共同证明了一件事注意力不是序列建模的唯一答案而且长文本成本已经成为一个足够大的痛点值得整个行业去探索备选方案。4. 环境准备与前置条件如果只读概念很难建立体感。接下来用一个最小示例演示如何用 HuggingFace transformers 加载一个 Mamba 模型并完成一次中文文本生成。4.1 硬件与系统建议Mamba 官方的高性能内核主要面向 Linux NVIDIA GPU建议使用以下环境操作系统Ubuntu 20.04 或更高版本GPUNVIDIA GPU显存建议 16GB 以上Python3.9 或更高版本PyTorch2.x 或更新版本。如果手里只有 Windows 系统可以优先尝试两条路一是使用 WSL 并在 Linux 容器内安装依赖二是先使用 transformers 中的纯 PyTorch 实现不安装原生mamba_ssm内核。这样速度会慢一些但流程能跑通。4.2 安装依赖先用 conda 或 venv 创建一个干净环境避免依赖冲突conda create -n mamba-test python3.10 -y conda activate mamba-test pip install --upgrade torch transformers accelerate如果需要原生速度可以再安装 Mamba 官方内核。这一步在 Windows 裸环境下容易出现编译问题安装前建议确认 CUDA 版本和 PyTorch 版本匹配pip install mamba-ssm causal-conv1d如果编译失败不必强行解决。可以先跳过原生内核用 transformers 自带的实现跑通流程。从工程角度看能跑通比盲目追求高性能更重要。4.3 模型选择HuggingFace 上的state-spaces组织发布了多个 Mamba 权重本文示例使用state-spaces/mamba-2.8b。这个模型体积较大如果 GPU 显存不足可以换成更小的开源模型。具体有哪些历史版本可用以该组织在 HuggingFace 上实际发布的仓库为准。5. Mamba 最小推理示例代码实现与解释下面这个示例展示的是加载模型、输入提示词、生成一段文本然后统计生成耗时和显存峰值。代码可以直接复制但请确保依赖已经安装。# 文件路径mamba_minimal.py import time import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_id state-spaces/mamba-2.8b print(加载 tokenizer ...) tokenizer AutoTokenizer.from_pretrained(model_id) print(加载模型 ...) model AutoModelForCausalLM.from_pretrained( model_id, device_mapauto, torch_dtypetorch.float16, ) prompt 多模态大模型的核心挑战是什么 inputs tokenizer(prompt, return_tensorspt) # 记录生成前显存状态 if torch.cuda.is_available(): torch.cuda.reset_peak_memory_stats() torch.cuda.synchronize() start time.time() outputs model.generate( **inputs, max_new_tokens64, do_sampleFalse, ) if torch.cuda.is_available(): torch.cuda.synchronize() elapsed time.time() - start generated tokenizer.batch_decode(outputs, skip_special_tokensTrue)[0] print(生成结果) print(generated) print(f生成耗时{elapsed:.2f}s) if torch.cuda.is_available(): peak_memory torch.cuda.max_memory_allocated() / 1024 ** 2 print(f峰值显存{peak_memory:.1f} MB)代码中的关键步骤AutoTokenizer.from_pretrained自动加载模型对应的 tokenizerAutoModelForCausalLM.from_pretrained用 transformers 加载 Mamba 模型device_mapauto让加速库自动分配模型到 GPU 或 CPUtorch.float16降低显存占用但这需要 GPU 支持 FP16model.generate是通用的生成接口只要模型实现的是 CausalLM 结构就可以调用关闭do_sample可以让结果稳定复现方便后续做对比实验。运行命令python mamba_minimal.py如果一切正常你会看到类似下面的输出具体文本因模型权重和分词差异会有不同这里只作示意生成结果 多模态大模型的核心挑战是什么 多模态大模型的关键问题包括跨模态对齐、数据稀缺、推理效率以及评估方式。这段输出不是某个固定测试数据而是说明“能够生成连贯中文”的最低验证标准。只要看到模型输出了与提示词相关的自然语言就说明整条链路已经通了一半。6. 运行结果与效果验证不要只和 Transformer 比速度跑通示例以后下一步是正确评估一个非 Transformer 架构是否真的适合你的业务。很多宣传只会强调“复杂度降低到了 O(n)”但工程落地更关心三个问题长序列下的显存曲线、生成速度、以及任务质量是否稳定。6.1 测量长序列下的显存变化衡量 KV Cache 是否被消除最直接的办法是让输入长度翻倍观察峰值显存增量。可以在同一模型上分别使用 1024、4096、8192 个 token 的输入记录peak_memory。# 文件路径bench_memory.py import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_id state-spaces/mamba-2.8b tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained( model_id, device_mapauto, torch_dtypetorch.float16, ) text 这是一段用于测试长文本占用的输入内容。 * 200 inputs tokenizer(text, return_tensorspt) if torch.cuda.is_available(): torch.cuda.reset_peak_memory_stats() torch.cuda.synchronize() with torch.no_grad(): outputs model(**inputs) last_hidden outputs.logits[:, -1, :] if torch.cuda.is_available(): torch.cuda.synchronize() peak_memory torch.cuda.max_memory_allocated() / 1024 ** 2 print(f输入长度{inputs[input_ids].shape[1]} tokens) print(f峰值显存{peak_memory:.1f} MB)注意这段代码只做前向推理不是生成因此可以快速测出“模型处理一遍长输入需要多少显存”。如果输入长度翻倍后显存增量较小说明该架构在长文本场景下的扩展性确实优于 Transformer如果增量仍然很大就要检查是不是混合了注意力层。6.2 衡量生成速度生成速度通常用“每秒生成的 token 数”来衡量。由于自回归生成本质上是逐步进行的短 prompt 下 Mamba 和 Transformer 的差距不一定明显上下文变长后Transformer 因为 KV Cache 膨胀每一步的内存带宽压力越来越大Mamba 的优势才会放大。所以测试时建议固定一个较长的前缀例如 4096 token再统计生成 128 token 的耗时。6.3 用业务评测集做质量判断速度只是必要条件任务质量才是最终决策依据。最稳妥的方式是选 3 到 5 个你业务中最典型的任务准备一份固定的评测集分别用现有 Transformer 模型和候选模型跑出结果人工或自动评分对比。这里要特别提醒不要只看一两个通用 benchmark 分数就下结论。新架构在长文本提取类任务上可能表现不错但在代码推理、数学计算、多轮指令跟随上可能明显落后。每个业务的最佳选择都要靠自己的数据来回答。7. 常见问题与排查方法非 Transformer 架构目前生态还在快速变化新手最容易在环境安装和模型加载两个阶段出问题。下表整理了几类典型现象和排查思路。问题现象可能原因排查方式解决方案安装mamba-ssm时报编译错误CUDA 工具链不匹配或 Python 版本过高查看编译日志运行pip show torch确认 PyTorch 版本使用官方 Docker 镜像或直接跳过原生内核使用 transformers 纯 PyTorch 实现安装causal-conv1d失败PyTorch 与 CUDA 版本组合不被支持检查安装日志中的CUDA_HOME配置先安装匹配的 PyTorch再安装该依赖Windows 下建议用 WSLAutoModelForCausalLM.from_pretrained报未知模型类型transformers 版本过旧打印报错中出现的关键字检查 transformers 是否支持 Mambapip install -U transformersCPU 上生成速度很慢未使用 CUDA 内核或模型本身较大观察 CPU 占用确认模型没有任何层被放到 GPU使用更小模型或调整device_map分配策略prompt 很短但显存依然高模型权重本身较大权重占用和 KV Cache 不是一回事用model.parameters()估算权重显存改用更小参数量模型或使用低精度加载生成结果明显不对tokenizer 与模型不匹配或采样参数不合理检查 tokenizer 名称尝试使用官方示例参数从官方代码仓库复制推荐生成设置输出始终不完整被截断max_new_tokens设置过低检查生成参数增大max_new_tokens无法在 Windows 上安装原生算子Mamba 官方内核依赖 Linux 与 CUDA查看官方 README 的平台说明使用 WSL 或 Docker 运行实验如果一个问题排查超过半天还没有头绪建议先回到最简依赖集合只安装最新版 PyTorch、transformers、accelerate不安装任何原生 Mamba 内核。用纯 Python 实现把流程跑通再逐步加入加速依赖。这样可以把“环境问题”和“代码逻辑问题”分开定位。8. 最佳实践与工程建议不要为了换而换从工程角度看采用非 Transformer 架构不是一次代码替换而是一次成本模型的重建。以下几个建议可以在迁移前帮团队少踩坑。8.1 先给现有模型做成本基线没有基线就没有决策依据。在业务环境上用固定长度的 prompt 和固定长度的生成目标测量当前 Transformer 模型的平均耗时峰值显存单位 token 成本业务评测集准确率。然后对候选架构做同样的测量形成对照表。这个过程并不复杂但很多团队会跳过导致后续评估失去参照物。8.2 从小模型和小试点开始新架构的部署链路还不成熟不建议一上来就替换核心服务。比较好的做法是选择一个非核心场景例如“长文档摘要”“日志分析”或“知识库问答”先用小模型跑通完整链路观察推理稳定性、错误模式和运维成本。小试点通过后再扩大到生产流量。8.3 关注部署生态而不只是模型质量Transformer 的优势不只是效果好更在于 vLLM、Triton、TensorRT、量化、LoRA、Agent 框架等上下游都已经深度适配。非 Transformer 模型再快如果缺少必备的量化工具或服务框架项目进度也会被拖慢。选型时必须花时间确认候选模型是否支持以下能力批量推理和动态 batchingFP16/INT8/INT4 量化LoRA 微调流式输出与现有 RAG 或 Agent 框架的集成方式。如果这些能力都不支持那么“推理速度更快”带来的是运维复杂度大幅上升很可能得不偿失。8.4 优先考虑混合架构作为折中最优解纯 SSM 和纯 RNN 在部分任务上仍存在效果短板而混合架构天然包含部分注意力层保留了对复杂语义的建模能力。如果你的业务既要长文本成本又不想承担过多效果风险混合架构是更稳的选择。它本质上是把 Transformer 保留在一个可控的比例内而不是彻底移除。8.5 保留回滚方案任何新架构上线都应该在负载均衡、路由层或提示词层保留“切换回原模型”的能力。最简单的方式是在推理网关中配置模型别名例如default_model指向新模型fallback_model指向原 Transformer并记录每次请求对应的版本号。这样如果某类输入效果异常可以快速灰度回退到旧版本。8.6 建立监控指标不只盯准确率迁移到新架构后除了业务指标还要监控单次推理耗时 P50/P95峰值显存和 OOM 次数生成重复率长输入截断率服务端排队时间。这些指标决定了新架构能不能长期运行而不只是在测评集上证明“效果没差多少”。9. 结论与后续学习方向回看整个“取代 Transformer”的话题我的判断是Transformer 不会以“被推翻”的形式退场更可能发生的是“多架构并存”。云端超大模型的预训练仍然会以 Transformer 为主但长文本、端侧、推理密集型场景会逐步采用 SSM 或混合架构。这不是技术魅力之争而是成本结构驱动的分流。如果你是一名应用工程师下一步可以按这个顺序实践第一步跑通本文的 Mamba 最小示例观察长文本输入下的显存曲线第二步用自己业务的 3 到 5 个任务构建一个固定评测集让候选模型和现有 Transformer 模型做对照第三步等混合架构或新架构的推理框架、量化工具成熟后再考虑生产环境切换。比起反复阅读“手撕 Transformer”的源码解析更值得关注的是注意力的计算复杂度从哪里来、KV Cache 为什么成为长文本瓶颈、以及各种线性递归模型如何绕过它。把这些底层问题想清楚面对任何新架构就不会被宣传话术带偏也能更早判断它值不值得引入到自己的项目里。最后给你一个可直接复用的行动清单下次看到“某新架构完爆 Transformer”的帖子时不要急着收藏先问三个问题——同样效果下单位 token 成本降了多少、部署生态是否支持你的框架、在你自己业务数据上的评测结果是什么。三者都满足才值得动手试。