大模型架构正在进入一个微妙节点。OpenAI 和 Google 里负责核心模型的人陆续离开出来做下一代架构这本身就是一个信号。过去几年大模型的核心竞争集中在参数规模、数据规模和算力堆叠上但 Transformer 架构本身的问题已经越来越明显训练成本高、推理效率受限、长上下文处理不稳定、记忆与规划能力不足。现在有人决定从架构层重新做一遍而不是继续在现有框架上打补丁这件事值得认真关注。这篇文章适合三类人看正在做模型训练的工程师、准备本地部署大模型的技术负责人、以及关注大模型方向的学生或研究者。最值得关注的不是谁离开了哪家公司而是他们选择的新方向可能改变未来两到三年的模型开发方式。下面从行业信号、架构瓶颈、可能的新方向、落地评估和团队行动五个维度拆开讲。1. 核心负责人出走为什么值得关注1.1 出走的不是普通工程师而是定方向的人在大模型公司里核心负责人和普通工程师的影响范围完全不同。普通工程师可以负责某个模块的性能优化但核心负责人通常掌握着模型整体设计思路用什么样的架构、走什么样的训练路线、如何分配算力、如何取舍能力边界。这些人离开大厂意味着他们对现有路线的长期发展产生了不同判断。一个常见的误区是把这种离职理解为“待遇没谈拢”或者“内部权力斗争”。实际上真正做过大模型核心研发的人都知道继续留在顶级实验室里资源、数据、算力、团队配置都是最好的。愿意离开这些条件去重新创业说明他们看到了现有架构之外的更大空间也说明他们相信自己能在资源更少的情况下做出更有突破性的成果。我关注这类消息重点从来不是八卦而是三个问题他们准备在哪个层面做创新他们选择的技术路线是什么以及第一批验证结果什么时候能公开。1.2 大模型公司留不住核心研究人员的三个原因从行业规律看这类出走通常有三个层次的原因。第一个原因是技术路线分歧。大厂的核心目标是稳定交付可商用的大模型所以对不确定性较高的架构创新会保持谨慎。研究团队想做大胆尝试但产品团队更关心当前版本能不能稳定上线、成本能不能压住。时间一长研究团队的空间会被压缩。第二个原因是架构创新需要从零开始。在现有模型上做微调、做对齐、做推理优化都是在 Transformer 框架内打补丁。但如果你想设计一种新的序列建模方式可能需要抛弃大量现有工具链和优化经验从数据加载、算子实现、分布式并行到推理引擎全部重来。这种工作在大厂内部很难立项因为短期看不到回报。第三个原因是新公司的资源效率更高。新团队没有历史包袱不需要维护旧模型也不需要兼容已有产品线。他们可以从最近两年的技术积累中挑选最优组件用更小的团队、更聚焦的目标快速迭代。我见到过不少类似的项目前半年进展不会太快但一旦跑通技术代差会很明显。2. 现有 Transformer 架构到底遇到什么问题2.1 注意力机制的算力瓶颈Transformer 架构的核心是自注意力机制。自注意力的计算复杂度是输入序列长度的平方级。也就是说输入长度从 2048 加到 8192计算量不是翻四倍而是翻十六倍。这个特性在短文本时代还可以接受但到了多轮对话、长文档分析、代码仓库理解、视频摘要这些场景代价越来越高。你可以做个简单实验用同一个模型处理 2000 个 token 的文本和 20000 个 token 的文本观察显存占用和生成速度。多数情况下长文本输入会让显存曲线快速上升推理首 token 延迟明显增加。很多本地部署的用户为了压显存只能把上下文窗口设置得很小但这样又会牺牲模型的理解能力。这已经变成了一个结构性问题。你可以在工程上优化 Flash Attention、做分页 KV Cache、做量化压缩但这些优化只是让平方级复杂度在常数项上更好看并没有改变复杂度本身。2.2 长上下文中的信息丢失和注意力分散另一个更隐蔽的问题是Transformer 在长上下文中并不像宣称的那样稳定。即使通过技术手段把上下文窗口扩到了几十万 token模型也不一定能在整段上下文中稳定找到需要的关键信息。位置编码、注意力分数分布、中间层信息衰减都会导致所谓“长上下文能力”只在测试数据上成立在真实复杂文档中打折扣。我在实际测试中经常遇到这种情况给模型一份几十页的 PDF让它提取某几个具体数据点。它有时能找到有时找错位置有时会把不同章节的信息混在一起。表面上看是模型“不够聪明”本质上是注意力机制在长序列上难以维持足够的聚焦度。这也是为什么很多人开始研究显式记忆、外部知识库和可寻址存储而不是继续加大上下文窗口。2.3 为什么架构层创新比调参更被看重如果只是效果不够好还可以通过更多数据、更大模型、更强对齐来弥补。但 Transformer 瓶颈已经到了一个成本拐点继续扩大参数量和上下文长度带来的收益在边际递减而训练和推理成本在边际递增。举个例子训练一个万亿参数模型需要的算力、数据清洗、故障恢复、并行策略都要推到极限。即使训练出来了在线部署时单卡也装不下需要多卡并行、模型切分、内存换出。对一个商业团队来说这不是“效果好一点”就能覆盖的成本。架构层创新想解决的是更底层的问题能不能让模型在更少的算力下达到同样的效果能不能让推理成本随长度增长更慢能不能用新的模块替代注意力机制让模型在长序列、多模态、记忆规划这些场景下有更好表现这些问题是调参、加数据、做对齐解决不了的。3. 下一代架构可能往哪些方向走3.1 更接近线性复杂度的序列建模方案这几年最受关注的方向之一是用近似注意力或者状态空间模型替代标准注意力。这类方法的核心思路是把序列建模从“每一个位置都要看所有前序位置”变成“用一个固定大小的状态来压缩历史信息”。这样计算复杂度可以从平方级降到线性级长序列处理成本也会更可控。代表性思路包括状态空间模型SSM、线性注意力、基于门控更新的循环结构等。它们各自的实现方式不同但共同点都是希望摆脱 Transformer 对全局注意力的依赖。我建议关注这类工作的人不要只看论文里的复杂度公式要重点看它在真实长文本、长音频、长视频任务上的表现以及训练稳定性和硬件利用率。目前这些方案还没有完全取代 Transformer但在某些任务上已经表现出明显优势。比如处理几十万 token 的长文档或长时间语音时线性复杂度的模型在显存占用和推理延迟上容易更有优势。它们的短板往往是短文本上的表达能力和并行训练效率这也是后续改进的重点。3.2 混合架构和路由机制另一种可能性不是彻底抛弃 Transformer而是把不同模块混合在一起。比如一部分层用全注意力一部分层用线性近似或状态空间模型再通过路由机制决定不同 token 或者不同信息片段走哪条路径。这种设计在工程上更稳妥因为它不需要一次性推翻现有优化工具链可以先在部分模块上验证新结构的效果。混合架构的好处是灵活。训练时可以保留注意力机制在复杂推理上的优势推理时把简单的、重复的、低信息量的部分交给更轻量的模块处理。坏处是系统复杂度增加模型结构不再是单一顺序而是多分支、多策略的组合。调试和优化的难度也会同步上升。我看到很多团队已经开始尝试“轻量模块负责记忆压缩注意力模块负责关键细节推理”的组合。短期来看这可能是更务实的下一代架构形态。3.3 推理时扩展与系统级架构还有一种趋势不是改变模型内部的注意力计算方式而是改变模型使用方式。现在越来越多人接受一个观点大模型的能力不光来自训练阶段还来自推理阶段的策略。比如让模型在回答前先规划步骤、生成多个候选方案再筛选、用外部工具验证结果、动态决定是否需要搜索或者调用代码执行器。这实际上是把“模型架构”从单模型扩展为“模型 工具 记忆 调度器”的完整系统。单看某一个模型参数和架构可能没有明显变化但组合起来之后系统整体能力会大幅提升。这也是很多从大厂出来的人更愿意做的事不做单个模型而是设计一套可以持续迭代的系统架构。对开发者来说这意味着以后学习大模型不能只学 PyTorch 训练还要理解编排、调度、工具调用、结果校验这些工程环节。3.4 多模态和统一表示下一代架构另一个重要方向是多模态统一。现在的常见做法是把文本、图像、音频分别用不同编码器处理再拼接给语言模型。这个方案能用但不同模态之间的信息融合比较浅。更激进的做法是从底层就设计一个统一的序列表示让文本、图像、音频、视频都变成同一种可操作的 token 序列或状态表示。这样做的好处是模型更接近人类大脑处理多模态信息的方式不区分“文字还是图片”而是提取统一的语义结构。困难也很明显不同模态的数据量、信息密度、噪声分布差异很大统一表示后如何平衡训练目标、如何避免模态之间相互干扰都是需要解决的工程问题。从实际经验看这类工作在短期内很难有公开的商业化成果但技术上只要跑通一个较小型号的验证就能说明方向是否可行。对关注者来说值得记录的是技术报告的实验设置和消融结论。4. 新架构落地时开发者最需要盯住什么4.1 用五个维度评估新架构而不是只看跑分我看到很多人评估新架构时只看两个指标跑分高不高、参数量大不大。这两个指标远远不够。我一般会用五个维度来判断一个新架构是否值得深入训练稳定性换架构后loss 是不是能稳定下降有没有剧烈震荡或突然发散。长序列扩展性从 4096 扩展到 16384显存和速度的变化是线性还是平方级。推理效率单卡能部署多大模型首 token 延迟和生成速度怎么样。下游任务泛化不能只在合成数据上有效要看代码、文档、聊天、工具调用等真实场景。工程生态成熟度是否有成熟的算子、训练框架、量化和分布式方案。前两个维度决定这个架构能不能训练出可用模型后三个维度决定这个架构能不能让人真正用起来。如果只有前两个好那还是一个研究项目如果后三个也成立才值得投入资源跟进。4.2 训练、微调、推理三阶段的变化如果下一代架构真正落地它在训练、微调、推理三个阶段带来的变化是不同的。训练阶段最大的变化来自并行策略和优化器设计。新结构如果是线性复杂度那么数据并行的粒度、张量并行的切分方式、梯度通信的开销都会和 Transformer 时代不同。如果你用惯了现有的分布式训练框架迁移时可能需要重写部分算子。微调阶段影响最大的是 LoRA 等技术是否仍然有效。Transformer 的微调通常只调一小部分低秩参数但新架构的核心模块可能是状态更新函数或门控单元它们的参数分布和注意力层差异很大。你需要重新实验哪些层适合冻结、哪些层适合适配以及不同任务要用多大的适配参数量。推理阶段影响最明显的是 KV Cache 策略和批处理方式。Transformer 推理需要缓存每一层的 key 和 value长序列下缓存非常大。下一代架构如果不需要缓存或只需要固定大小的状态那么推理时的显存占用会明显降低批处理吞吐量也可能更高。但代价可能是逐 token 计算必须串行难以像 Transformer 那样并行预填充。4.3 用低成本方式验证新架构思路不是每个团队都有资源从零训练一个几十亿参数的模型。但我建议至少可以用低成本方式验证思路不要只看别人的结论。一个可行的方法是用不超过 1B 参数的小模型做训练实验。先在小规模数据集上跑通前向和反向观察 loss 曲线是否稳定然后把序列长度从 1024 逐步加到 8192记录显存变化和训练速度。如果 1B 模型在合理步数内能正常收敛且长序列扩展性优于 Transformer那么这个方向就值得继续关注。对于没有训练卡的开发者也可以从推理侧验证。找一个公开的权重用同样的输入和参数对比不同架构在生成速度、显存占用、长文本记忆准确率上的差异。这类实测数据比论文里的理论分析更有参考价值。5. 对普通开发者和技术团队的实际影响5.1 个人学习路线要不要调整我的观点是不要急着放弃 Transformer但也不要只学 Transformer。Transformer 仍然是未来几年最主流的模型结构你去看大模型岗位的招聘要求大部分还是要求熟悉 PyTorch、Transformer、分布式训练、模型量化。这些知识在下一代架构中也不会完全失效因为很多底层能力是通用的比如梯度下降、分布式通信、数据并行、推理优化。但这些底层能力之外你需要补充新的知识结构。线性注意力、状态空间模型、混合路由、长序列高效处理、多模态统一表示这些方向以后会越来越重要。学习时可以从小规模代码库入手跑通一个最小训练示例再逐步修改结构。只看理论文章是不够的你至少要动手改一次注意力模块才能真正理解它的问题。5.2 业务团队需不需要追新架构不同团队对架构的态度应该不一样。如果你的业务用现有开源模型已经能稳定满足需求核心问题在业务数据、知识库、产品交互而不是模型能力那暂时不需要追新架构。大模型项目的瓶颈往往不在模型结构而在数据质量、系统稳定性和用户体验贸然换架构只会增加风险。如果你的业务严重受限于推理成本、上下文长度或响应速度比如长文档分析、持续对话机器人、海量文档检索那么下一代架构值得关注。你可以先设计一个小规模对照实验在同一批测试数据上分别用现有 Transformer 模型和新架构模型跑一遍比较成本和效果。不要直接在生产环境切换先用旁路镜像和灰度流量观察。5.3 我建议先建立一个判断框架真正落地下一代架构之前团队最该做的不是立刻采购算力或者换技术栈而是建立一个判断框架。我建议把这个框架分成三层能力层、成本层、风险层。能力层看新架构能否解决现有的长文本、延迟或者多模态问题成本层看训练成本、部署成本、人员学习成本风险层看生态成熟度、工具链完整度、社区活跃度、可维护性。每层设定明确的验证标准和负责人不要用“感觉更强”作为决策依据。如果你现在要做一个持续一年以上的技术规划至少要把下一代架构列入备选方案并排出一个可执行的验证节奏。先读论文再跑实验再评估接入路径。等到新技术被广泛讨论、社区已经出现成熟工具时你再从零开始准备通常已经晚了。5.4 留给团队的验证清单最后分享一个我在观察新架构时常用的验证清单团队可以直接拿来修正是否有公开的模型权重或可复现的最小训练代码。在相同 token 数下训练 loss 能否在合理步数内下降到与 Transformer 相当。序列长度翻倍后显存增长是否明显低于平方级。长输出时模型是否能在几百步之后仍然保持稳定的采样质量和信息一致性。微调时常用方法是否需要大量改动。推理时批量并发的吞吐量有多大提升延迟是否可接受。社区工具链是否已经支持权重转换、量化、服务化部署。这些检查项不需要一次全部通过。但通过越多说明该架构进入工程化的可能性越高。如果只有论文和跑分没有可复现代码也没有清晰的推理实现我的建议是再等等。6. 未来一年值得关注的信号和行动建议6.1 值得跟踪的技术信号未来一段时间我建议关注几类信号而不是只盯着新闻标题。第一类是技术报告和代码库同步发布的新架构项目。如果项目公布时同时给出可运行代码、训练日志、消融实验和推理示例说明团队已经有了较完整的工程闭环可信度远高于只有论文的项目。第二类是开源社区的适配进展。新架构出来之后重点关注它对 Hugging Face Transformers、vLLM、llama.cpp 等常用工具链的兼容程度。如果没有社区适配再好的架构也只能留在实验室里。第三类是其他团队复现后的反馈。一个架构是否成熟不能只看原作者的结论要看第三方能否在相近配置下复现出相似效果。你可以去搜索公开讨论、复现笔记和吐槽帖信息往往比官方文档更真实。6.2 什么时间点适合切换到新架构我一般参考三个条件来判断切换时机。第一个条件是效果胜出。新架构在多个重要基准和真实业务任务上效果稳定超过同等规模的 Transformer 模型而不是只在一个特定数据集上领先。第二个条件是工具链成熟。新架构至少支持常见的微调、量化和部署流程你可以用已有的工程经验完成服务化。如果还需要自己写算子、自己搞定并行策略那成本会非常高。第三个条件是社区活跃度。有足够多的开发者参与有问题库、讨论组、第三方教程遇到问题能快速找到解决方案。这个条件看似次要但实际影响非常大。很多优秀架构最后普及不了就是因为小问题没人处理团队被卡住两三天就放弃了。如果这三个条件都没有完全满足可以在小规模非核心业务上做试点。试点项目应该选择长文本、多模态、高并发推理这些 Transformer 短板明显的业务这样更能体现出新架构的价值。6.3 与其猜测哪家公司赢不如盯住模型能力变化最后说一点更宏观的判断。大模型公司之间的竞争短期内还会围绕模型效果、价格、生态展开。但未来两到三年真正的变量很可能来自架构层。如果新一代架构在同样的算力预算下能够获得更长的上下文、更低的推理成本和更稳定的能力那么后发团队就有机会重新洗牌。对普通开发者和技术团队来说最重要的不是押注某一家公司而是持续跟踪模型能力的变化并建立自己的评估和验证方法。你能不能在新技术出现时快速跑通一个小实验能不能判断它适不适合你的业务场景这比记住几家公司的人事变动更有价值。我更倾向于把这件事看成一次大模型技术路线的重要转折点。转折期会出现大量真假难辨的信息但也会出现真正改变行业的技术突破。保持跟进保持动手验证不要被标题带着走也不要因为短期看不到结果就放弃关注。