最近大模型圈有两则消息值得放在一起看。一位在 OpenAI 做到较高职级、参与过大模型预训练与扩展性核心工作的人选择离开另一位在 Google 深耕多年、长期负责语言模型技术路线的人也做出同样选择。更关键的是两人离职后的下一站都指向同一个方向下一代大模型架构。这不是普通的人事变动。过去几年大模型行业的几乎所有成果都长在 Transformer 这棵树上注意力机制、预训练范式、KV Cache、推理优化全部围绕它展开。当 Transformer 体系里的核心参与者开始转向“下一代架构”说明一个信号已经出现继续在现有架构上做增量优化的边际收益在下降更大数量级的提升可能要来自更底层的变化。这篇文章不聊人事内幕只聊技术判断。我会先梳理 Transformer 架构当前的核心瓶颈再逐一拆解状态空间模型、线性注意力、MoE、混合架构这几条“下一代路线”的实际进展然后分析架构更替对训练成本、推理性能、本地部署和 API 链路的具体影响最后给出一份可执行的观察清单。适合这几类读者做 AI Infra 和推理优化的工程师会关心显存曲线、KV Cache 和算子适配做大模型应用开发的读者会关心未来一到两年接口层和部署方式可能出现的变化做技术决策的读者可以用这份材料判断什么时间点值得把资源投入新架构。1. 关键信息速览项目性质大模型架构演进分析与工程影响解读背景事件两位大模型核心负责人分别离开 OpenAI 与 Google将研究方向转向下一代架构本文讨论方向Transformer 局限、SSM / 线性注意力 / MoE / 混合架构、训练与推理成本变化技术关键词Transformer、Attention、SSM、Mamba、RWKV、MoE、推理优化、显存占用重点关注指标训练效率、推理成本、上下文长度、显存占用、二次复杂度核心判断现有架构增量优化空间收窄下一代架构的机会窗口正在打开适合读者算法工程师、大模型应用开发者、AI Infra 工程师、技术决策者信息边界说明具体离职时间、新公司、融资细节以官方披露为准本文只做技术路线分析这里先明确一个前提本文不会去考证“谁去了哪家公司”“新公司估值多少”这些信息变动快且很容易失真。真正值得技术读者关注的是——为什么在 Transformer 体系里工作多年的核心角色会集体认为架构层面需要“推倒重来”。理解了这一点后面所有关于训练、部署、接口的判断才有依据。2. Transformer 的瓶颈为什么“原厂”也开始嫌它不够用要理解下一代架构为什么被重视先得看清 Transformer 在工程上的真实成本。这里不重复注意力机制的基础理论重点是三个和资源强相关的瓶颈。2.1 注意力机制的二次复杂度标准 softmax attention 的核心操作是对序列长度做两两注意力计算时间复杂度和空间复杂度都是 O(n²)n 是序列长度。训练阶段长序列意味着更高算力开销推理阶段长序列意味着更高显存占用。这个特性在短文本时代不明显一旦进入长文档、多轮对话、代码仓库级上下文成本立刻指数级上升。公式层面可以这样看标准注意力Attention(Q, K, V) softmax(QK^T / sqrt(d)) V 计算复杂度O(n²·d)为了绕过这个 O(n²)业界已经做过很多工程优化比如 FlashAttention 系列通过分块计算和 IO 感知重排把普通实现中的显存压力降了下来。但注意FlashAttention 优化的是“常数因子”并没有改变复杂度本身。序列继续拉长计算压力依然会追上。2.2 KV Cache 与长上下文的显存成本推理阶段Transformer 需要把历史 token 的 Key 和 Value 缓存下来供后续 token 计算注意力。这个缓存就是 KV Cache。它的显存占用和层数、batch size、序列长度、每条 head 的维度直接相关。一个典型的估算逻辑是这样# 估算标准 Transformer 推理时 KV Cache 占用字节 # num_layers: 层数 # batch_size: 并发批大小 # seq_len: 上下文长度 # kv_dim: 每条序列的 KV 特征维度 def estimate_kv_cache_bytes(num_layers, batch_size, seq_len, kv_dim, dtype_bytes): return num_layers * batch_size * seq_len * kv_dim * 2 * dtype_bytes kv_dim 128 num_layers 32 batch_size 8 seq_len 8192 bytes_per_element 2 # fp16 total estimate_kv_cache_bytes(num_layers, batch_size, seq_len, kv_dim, bytes_per_element) print(total / 1024**3, GB)这里用的是一组教学式参数不代表任何具体模型但能看出现有工程压力的来源上下文从 2048 翻到 8192KV Cache 占用直接翻四倍并发从 1 翻到 8占用再翻八倍。很多本地部署场景里模型权重明明不大显存却不够用问题通常就出在 KV Cache 上。2.3 固定结构的扩展性问题Transformer 的每一层结构高度同质输入输出维度固定注意力头数量固定。这种“规则化”设计有利于并行计算但也限制了模型的表达能力层与层之间的关系是固定的无法根据输入内容动态选择计算路径。扩展性问题在推理侧表现得更明显。纯 Transformer 做长上下文时要么冒险截断要么引入检索或压缩但检索会改变输入分布压缩会损失信息。这些补丁式方案越多系统复杂度越高稳定性越低。2.4 训练与推理的硬件利用瓶颈从 GPU 利用率角度看Transformer 的注意力矩阵、FFN、归一化层对算力、带宽、显存的需求差异很大。训练时可以通过大规模并行掩盖部分瓶颈但推理时单请求的 batch size 通常很小此时访存带宽往往比算力更早触顶。这一点对本地部署尤其明显。很多用户在消费级显卡上跑大模型时实际瓶颈不是每秒能做多少 FLOPs而是权重和 KV Cache 移动需要多少显存带宽。模型越来越大单卡越来越难承载这也是架构层面必须回答的问题能不能用更少的状态存储来完成同样的推理任务。3. 下一代架构的主流路线谁在挑战 Transformer“下一代架构”不是一个概念而是一组路线。它们的共同目标是用比注意力机制更低的理论复杂度或更小的运行时状态达成接近甚至超过 Transformer 的效果。目前公开讨论比较多的方向有五个。3.1 状态空间模型SSM与 Mamba状态空间模型把序列建模看成连续系统的离散化过程用固定大小的隐状态保存历史信息推理时的复杂度不再随上下文长度线性增长。Mamba 是这条路线最受关注的开源方向它提出了选择性扫描机制让模型根据输入动态决定保留哪些历史信息。Mamba 的优势在于长序列场景下的推理效率以及更小的 KV Cache 占用。代价是它对输入序列的顺序性更强部分并行化优化没有标准 Transformer 那么成熟。另外通用大模型里直接替换全部 Transformer 层的效果目前还需要更多大规模实验验证。3.2 线性注意力与简化的注意力机制线性注意力通过核函数或低秩近似把注意力矩阵分解为更容易计算的乘积形式从而把理论复杂度降到 O(n)。RWKV 是这一方向的代表性开源项目之一它把注意力机制改写成线性递推形式在 CPU 上也能获得不错的推理速度。这条路线适合对部署环境敏感、希望降低推理成本的场景。但线性注意力在信息检索类任务上通常需要额外的位置编码或门控机制来补偿表达能力损失否则容易在需要精确“找答案”的任务上掉点。3.3 稀疏注意力与层级注意力另一种思路是对注意力矩阵做稀疏化只让部分 token 之间存在注意力连接。比如窗口注意力只关注邻近 token全局注意力只关注少数全局 token再用层级结构把局部信息和全局信息做组合。从工程角度看稀疏注意力更容易在现有 GPU 上实现因为大部分算子可以复用。但它并没有完全摆脱 KV Cache 的概念只是让缓存规模可控。这类方案更像是“对 Transformer 的改造”而不是全新架构。3.4 MoE用更小的激活成本换更大参数MoE 不改变注意力机制本身而是把 FFN 层拆成多个“专家”网络每次推理只激活其中一部分。这样模型参数量可以做到很大但实际计算量只对应被激活的专家数。MoE 对训练和推理的影响都很直接训练时显存和算力需求依然高因为所有专家参数都占显存推理时如果按需加载专家可以降低单次请求的活跃参数。这也是很多大模型选择 MoE 化改造的原因。它的短板在于分布式训练和推理的调度复杂度明显上升路由不均匀还会造成部分专家过载。3.5 混合架构Transformer SSM / MoE 的组合目前最务实的做法不是“全盘替换 Transformer”而是把 SSM、MoE 等模块嵌入原结构形成混合架构。比如部分层用 SSM 处理长程依赖部分层保留标准注意力处理信息检索再通过 MoE 扩展容量。混合架构的工程价值在于它可以渐进式迁移不要求训练框架完全重写。对 Infra 团队来说这是风险最低的尝试路径。但混合架构也会带来新问题不同模块的并行策略、显存分配、序列处理顺序都需要重新设计调试难度比单一架构更高。3.6 推理时计算与测试时训练除了改主干结构另一条被频繁讨论的路线是在推理阶段增加“额外计算”。类似让模型先生成多个候选再自我校验或者在推理时从长时记忆模块中检索并更新状态。它不直接改变注意力复杂度但会让“模型大小”和“推理算力”之间的关系发生变化。这条路线对应用层的意义在于未来衡量模型能力可能不再只看参数量还要看推理时允许投入多少额外计算。API 定价和批量任务策略都会因此产生变化。4. 两位核心负责人“卷架构”背后的技术判断把这几条路线放在一起再回头看这次离开事件会更清楚行业正在发生什么。第一Transformer 的增量优化空间确实在收窄。过去两年大家做的事情非常一致扩大模型、扩大数据、改进训练目标、增强指令遵循。这些优化都有成效但越来越难产生“数量级”变化。模型效果提升开始变得依赖工程细节和算力投入而不是架构层面的结构性优势。第二头部实验室内部对新架构的尝试成本很高。已有的数据 Pipeline、分布式框架、推理引擎、评测体系全部围绕 Transformer 构建。在超大参数规模下引入全新架构意味着整个基础设施都要跟随调整。这个成本不是每个团队都愿意承担但对离开头部体系、重新创业的团队来说反而是机会没有历史包袱可以从第一天就为下一代架构设计训练和推理链路。第三长上下文和强推理能力被看作下一个必争点。如果新架构能用更低显存实现更长上下文或者说用更少算力达到当前同样效果它在 AI Infra 领域就有明确商业价值。这比单纯堆参数的路线更有想象空间。所以这件事的技术本质不是“两个人离职创业”而是“一群 Transformer 的资深使用者开始用脚投票”。他们判断下一代架构的机会窗口已经足够大值得放弃既有平台的资源去换一个更底层的位置。5. 架构更替对训练、推理、本地部署的真实影响如果下一代架构真的批量落地工程侧会先感受到变化。下面按训练、推理、本地部署三个层面拆开看。5.1 训练成本曲线线性注意力或 SSM 在长序列训练中的理论复杂度更低意味着同样的 GPU 卡数可以在更长时间窗口上训练。MoE 则把“模型变大”和“计算量变大”解耦让小团队也能训练更大参数规模的模型。这两条路线叠加会显著降低长上下文模型的训练门槛。但要注意理论复杂度下降不等于实际训练成本下降。新架构需要更细致的算子适配、更复杂的并行策略、更多调参实验。如果训练卡规模不够大很多理论优势无法转化成工期优势。5.2 推理吞吐与延迟推理侧的变化会更明显。去掉或压缩 KV Cache 后上下文长度不再线性消耗显存长对话和多轮 Agent 场景的并发能力会提升。这对 API 服务和离线批量任务都是利好。代价是部分新架构对 batch 的友好度不如标准注意力。SSM 和线性注意力在 batch 处理时状态张量的形状会更复杂推理框架需要针对这些形态做专门的 kernel 优化否则上量之后延迟反而可能恶化。5.3 本地部署门槛本地部署最敏感的是显存和 CPU 推理。当前很多 7B、13B 模型本地跑不动不是因为权重太大而是长上下文加上 KV Cache 后显存爆掉。如果新架构能在 CPU 上高效推理那么没有独显的笔记本也能跑长文本任务这会直接改变大模型应用的分发方式。从材料看RWKV 这类线性注意力模型已经在 CPU 场景有明显优势Mamba 系列也提供了多种规模的权重。但要判断是否适合本地部署不能只看架构类型还要看具体权重版本的量化支持和推理框架适配。比如有没有 GGUF、llama.cpp、MLX 等生态支持有没有 OpenAI 兼容接口这决定了一个模型能不能顺利接入现有工具链。5.4 对 API 和工程链路的影响对大多数应用开发者来说模型底层是 Transformer 还是 SSM感知并不直接。他们关心的是接口是否兼容、价格是否变化、长文本是否稳定。最稳妥的判断是即使下一代架构落地服务商也会尽量保持 OpenAI 兼容协议因为迁移成本是 API 用户最敏感的部分。真正会变的是服务商内部的路由策略、缓存策略和计费方式。比如长上下文的定价可能不再按 token 线性计价而是按实际计算量计价。给一个工程链路的示意伪代码便于理解面向新架构做适配时该如何抽象# 示意在模型结构层抽象不同 backbone便于做基准测试 # 实际实现需要按具体框架和模型仓库调整 class Backbone(torch.nn.Module): def __init__(self, arch_typetransformer, hidden_size768, num_layers12): super().__init__() if arch_type transformer: self.layers TransformerLayers(num_layers, hidden_size) elif arch_type ssm: self.layers SSMLayers(num_layers, hidden_size) elif arch_type hybrid: self.layers HybridLayers(num_layers, hidden_size) else: raise ValueError(funsupported arch: {arch_type}) def forward(self, x, stateNone): return self.layers(x, state)核心思路是上层逻辑不直接依赖具体 backbone而是通过统一的输入输出接口把验证成本控制在单层替换级别。这样即使未来某天架构切换应用层和接口层不需要大改。6. 看懂架构信号给工程师的观察清单架构革命不会一夜之间发生。与其猜测哪条路线会赢不如盯住一些可量化的信号。观察维度具体信号判断依据论文与源码新架构是否提供完整开源权重和训练代码只有论文没有开源落地周期会变长推理框架适配llama.cpp、vLLM、SGLang、Ollama 等是否支持有主流推理框架适配接入成本才低基准评测长文本检索、代码理解、多轮对话上的表现不能只看单一指标要关注关键能力是否掉点接口兼容是否提供 OpenAI 兼容 API兼容程度决定迁移成本显存曲线同一上下文长度下KV Cache 占用是否随长度线性增长占用增速越慢长上下文优势越明显社区热度Issues、Pull Requests、第三方教程数量生态活跃度决定踩坑后能否快速找到答案这里给一个更容易执行的建议先拿一个长文档解析或长代码库问答任务用当前主力模型跑通记录延迟和显存占用。然后在新架构模型可用时用同样的数据、同样的提问方式再跑一遍。两次结果对比比任何技术宣传都可靠。7. 如果想去亲手评估新架构环境可以这样准备“下一代架构”听起来很远但评估环境并不复杂。你不需要参与训练大模型只需要跑已有开源权重做基准对比。这类评估环境可以按下面步骤准备。7.1 基本硬件与软件操作系统Linux 优先Windows 可以通过 WSL2 或 Docker 替代。Python 环境3.10 或更高版本建议使用 conda 或 venv 隔离。GPU如果只是跑小规模模型验证8GB 以上显存即可用纯 CPU 推理也可以但要接受速度下降。依赖PyTorch、transformers、tokenizers、accelerate、einops 等具体版本以项目 README 为准。CUDA如果使用 NVIDIA GPU需要安装对应版本的 CUDA 和 cuDNN如果只是 CPU 推理可以不装。这里没有写死版本因为不同仓库要求不同。更稳妥的做法是先把目标模型的 GitHub 仓库 clone 到本地按 README 的安装命令执行。# 示例流程实际仓库地址和依赖以对应项目文档为准 git clone https://github.com/example/next-gen-model.git cd next-gen-model pip install -r requirements.txt python scripts/download_weights.py --model-size 1b这段命令只是占位不应直接复制运行。关键习惯是先看 README再装依赖不要跳步骤。7.2 评估一个长文本任务的通用流程可以先准备一段 5K 到 10K 字的业务文档比如技术白皮书、产品协议、开源代码文件然后执行以下操作用当前 Transformer 模型对文档做“摘要 定点提问”任务记录首 token 延迟和显存峰值。用新架构模型做同样的任务记录相同指标。对比两次答案是否完整特别关注中间段落的信息是否被正确引用。如果新架构支持 CPU 推理再在 CPU-only 环境跑一遍观察速度差。所有结果都只代表当前权重、当前框架、当前上下文长度下的表现。架构优势不会在所有任务上等价体现评估一定要覆盖“精度”和“成本”两侧。7.3 部署配置的占位模板如果新架构模型提供了本地推理服务一个常见的服务配置模板如下# 假设的推理服务配置模板需要按实际框架调整 model: backend: transformer # 可选 transformer / ssm / hybrid precision: fp16 context: max_length: 8192 kv_cache: true compression: false serving: host: 127.0.0.1 port: 8000 batch_size: 4这个模板不是真实可用配置只是用来提示你部署时应该关注哪些字段模型 backend、上下文长度上限、是否启用 KV Cache、服务端口、batch 策略。这些参数直接决定了显存占用和并发能力。8. 常见误判与风险提示关于架构演进技术社区讨论很多但误判也不少。这里挑几个高频问题。常见误判实际情况建议新架构一定全面碾压 Transformer大部分新架构在通用能力上仍有短板用业务任务实测不只看跑分通用大模型会一夜之间换架构基础设施迁移需要很长的过渡期关注混合架构这是阻力最小的路径线性复杂度就一定便宜实际端到端成本还需要算算子效率比较同精度、同上下文下的真实吞吐小团队能快速复现下一代大模型数据、训练框架、评测体系都是壁垒先做小规模验证再做技术选型现有 API 知识会失效大概率会保持兼容接口关注服务商是否调整计费和上下文策略新架构不需要关心显存显存瓶颈仍存在只是表现形式不同观察训练和推理两个阶段的峰值占用还有一点需要提醒无论架构怎么变使用任何模型权重、训练数据和生成内容时都要注意授权边界。开源模型有各自许可证数据有版权生成内容在商用前要复核是否合规。架构激进工程应用仍要稳健。9. 当前阶段可以做的准备与最佳实践架构演进是长周期事件对大多数团队来说眼下最重要不是立刻重写系统而是做四件事。第一把模型的抽象层做好。无论上层走 OpenAI 兼容 API还是直接用本地推理框架底层是否方便替换会影响未来半年的技术债。至少在服务层把 prompt 构造、上下文管理、输出解析与具体模型解耦。第二建立自己的评测集。不要只依赖公开榜单要保存至少 20 到 50 条业务相关的输入输出样本包含长文本、多轮对话、代码、数据表格等类型。架构切换时用同一套评测集快速对比。第三标记成本敏感场景。对所有调用模型的生产接口记录 token 数、延迟、返回质量。这样新架构接入时可以直接用历史数据做收益核算。第四关注推理框架的适配进度。对 Mamba、RWKV、混合架构等方向一旦看到 vLLM 或 llama.cpp 的正式适配和量化支持就可以进入小规模测试。没有框架支持前不建议直接上生产。如果是在团队里推动这件事建议先跑一个 1B 到 3B 规模的新架构模型放到离线批量任务中和当前基线做一个月的并行对比。通过真实数据决定是否扩大投入比口头争论技术路线有说服力得多。10. 总结与下一步这篇文章从“两位大模型核心负责人离开 OpenAI 和 Google转向下一代架构”这个事件出发梳理了 Transformer 的核心瓶颈、下一代架构的主要路线、架构更替对训练和推理成本的影响以及工程师和技术决策者可以采取的落地动作。不用急着把所有服务切换到新架构但应该把“关注架构演变”纳入团队的例行工作。接下来最值得跟踪的三个点是否有线性复杂度模型在长文本基准上稳定超过同规模 Transformer主流推理框架对 SSM 和混合架构的支持进度以及新一代模型的 API 兼容和定价策略。如果这篇文章对你判断技术方向有帮助建议收藏备用。后续新架构开源项目进入可部署阶段我会继续按“环境准备、启动方式、显存占用、接口能力”的方式做更具体的实测。