百万 Token 预填充提速 21.9 倍、128K 检索近满分！NeurIPS 2026 新架构重写注意力

「以棱镜之思，折射 AI 研究的多维光谱」——学术棱镜是奇点折射推出的精品论文栏目。我们相信，每一篇扎实的论文都是照亮技术未来的光束，而棱镜，让光芒绽放出应有的色彩。

论文投稿请联系：zhanghy@csdn.net

责编丨梦依丹

出品丨奇点折射（ID：rgznai100）

如果让大模型读完 100 万 Token 的材料，却只回答几十个 Token，算力应该花在读材料，还是找答案上？

传统 Transformer 在读取输入时，会让每个 Token 与此前大量内容进行注意力计算，上下文越长，成本越高。来自香港理工大学、中国科学院大学、悉尼大学等机构的研究团队提出了新架构 Orthros——读取长输入时快速建立上下文，真正生成答案时再调用全局注意力。

这种「 分阶段用力 」的设计，让 Orthros 在 100 万 Token 输入下实现最高 21.9 倍的预填充加速，同时在 128K 「 大海捞针 」测试中保持接近满分的检索能力。它不仅可以从头训练，还能通过持续训练，将Llama 3.1-8B 和 Qwen3-8B 转换为 Orthros 架构。

论文已被 NeurIPS 2026 接收。第一作者 Yuhong Chou 负责核心想法、实验设计与论文撰写，Jibin Wu 担任通讯作者并负责项目指导。团队还包括 Zehao Liu、Yuqi Pan、Qian Liu、Xianwei Chen 和 Zhongzhu Zhou。

• 论文地址： https://arxiv.org/abs/2610.13735

• 标题：Orthros: Phase-Aware Heterogeneous Attention for Efficient Transformers

Transformer 真正昂贵的，不只是“上下文长”

理解 Orthros 之前，需要先区分大模型推理的两个阶段。

大模型推理分为两个阶段：

• 预填充（Prefill）负责读取整段输入、建立 KV Cache 并生成首个 Token；

• 解码（Decode）则负责逐个生成后续 Token。

传统 Transformer 在两个阶段都使用全注意力，预填充的注意力计算量随输入长度近似按 T² 增长。输入从 10 万Token 增加到 100 万 Token，注意力部分的理论开销可能增加至原来的 100 倍。

而 Agent、代码模型和多模态模型越来越常见的工作负载，恰恰是输入很长、输出很短。读完大量工具说明、代码或视频 Token，最后可能只生成一次工具调用、几行修改或几句话。

Orthros 正是针对这种「 重预填充、轻解码 」的场景设计的——减少模型读取长输入的成本，把更昂贵的全局注意力留到真正生成答案时

线性注意力更快，为什么还没有取代 Transformer？

过去几年，研究者已经提出了滑动窗口注意力、线性注意力和状态空间模型等多种高效架构。

它们能够把计算复杂度从平方级降到线性级，但往往需要付出一个代价，即模型对远距离信息的检索能力可能下降。

滑动窗口注意力只关注附近的一小段内容。如果关键事实出现在 10 万 Token 之前，它可能早已离开模型的视野。

线性注意力则会把历史信息压缩到固定大小的状态中。速度更快了，但压缩过程也可能丢失细节。

因此，很多模型采用一种折中办法，即在部分层使用线性注意力或滑动窗口注意力，同时保留一些全注意力层。

问题在于，只要模型中仍然存在全注意力层，处理超长输入时的平方级瓶颈就没有真正消失。高效注意力带来的优势，最终可能只剩下一个固定倍数的加速。

Orthros 认为，问题可能不在于“ 每一层应该使用哪种注意力 ”，而在于为什么输入阶段和输出阶段，一定要使用完全相同的计算方式？

读材料时快速扫描，回答问题时全局检索

Orthros 在每一层中维护两条不同的 Token 流。

第一条是基础 Token 流。

所有输入 Token 都经过这条路径，使用窗口大小为 128 的滑动窗口注意力。它主要负责理解局部上下文，并为每一层建立完整的 KV Cache。

第二条是输出专用 Token 流。

只有那些真正承担“ 预测下一个输出 Token ”任务的位置，才会进入这条路径。它们通过全交叉注意力，访问基础 Token 流建立的全部 KV Cache，从整个历史上下文中寻找信息。

可以把它理解成两种阅读模式：

基础 Token 流像快速通读，一边阅读，一边整理索引；

输出专用 Token 流像带着问题查资料，可以回头搜索整份文档。

两条路径共享主要的 Query 投影矩阵，但 Orthros 增加了一组轻量的缩放和偏移参数，让同一个投影能够分别适应「 局部理解 」和「 全局检索 」两种任务。

这套设计的关键不是取消全注意力，而是只在真正需要形成输出的位置使用全注意力。

图注：Orthros 在同一层中维护滑动窗口注意力与全交叉注意力两条路径，并根 据预训练、微调、预填充和解码阶段改变输出专用 Token 的数量

同一个模块，在四个阶段「 切换工作模式 」

Orthros 没有为预训练、微调和推理分别设计不同的模型，而是通过调整输入 Token 与输出专用 Token 的数量，让同一套模块适应四种状态。

预训练：所有 Token 都要学习预测

在普通的自回归预训练中，每个位置都需要预测下一个 Token。

因此，Orthros 会为整段序列复制一组输出专用 Token。每个位置都需要进行全局检索，训练阶段仍然具有平方级复杂度。

这也意味着，Orthros 并不是一种能够降低预训练成本的架构。相反，为了保证训练和推理保持一致，它在预训练阶段需要处理接近双倍的 Token。

监督微调：只为答案部分增加全局检索

在监督微调中，损失通常只计算在模型回答部分。

因此，用户问题主要经过基础 Token 流，只有答案对应的位置需要增加输出专用 Token。强化学习产生的回答轨迹也可以采用类似方式训练。

预填充：长 Prompt 只留下一个全局查询

这是 Orthros 最关键的阶段。面对一段很长的 Prompt，模型只复制最后一个输入 Token。此前的大量 Token 全部通过滑动窗口注意力完成处理，最后一个输出专用 Token 再对完整 KV Cache 执行一次全局检索，生成答案的第一个 Token。

因此，不管 Prompt 有多长，真正执行全局注意力的查询数量都可以保持为 1。

预填充阶段由此从平方复杂度降到接近线性复杂度。

解码：每一步生成一对 Token

进入解码阶段后，每生成一个 Token，Orthros 都会创建一对功能不同的 Token，一个负责更新 KV Cache 和处理局部信息，另一个负责查询完整历史并预测下一个 Token。

这会让解码阶段的计算量增加，但论文认为，低批量解码通常受显存带宽和权重读取限制，而不是受纯计算量限制。

GPU 本来就在等待模型权重从显存中被加载出来，多计算一个 Token 的算术开销，在特定条件下可以被这段等待时间掩盖。

这是一种很有意思的系统设计，即把额外计算放到 GPU 没有被充分利用的阶 段，把最昂贵的计算从真正拥堵的阶段移走。

百万 Token 预填充，最高提速 21.9 倍

论文首先测试了 8B 参数的 Orthros 与 Qwen3 在长上下文预填充阶段的速度。

单 GPU 测试覆盖 8K 至 128K 输入，8 GPU 测试覆盖 64K 至 100 万 Token。随着上下文长度增加，Orthros 的优势越来越明显。

在 100 万 Token 输入下，Orthros 取得了最高 21.9 倍的预填充加速。

这组结果证明了线性复杂度在超长上下文中的价值，但它仍然只是预填充阶段的测试。用户真正感知到的，是从提交问题到生成完整答案所需的端到端时间。

为此，团队又在单张 H100 GPU 上，通过相同的 SGLang 推理引擎测试了完整推理过程。实验 batch size 为2。

图注：输入越长，Orthros 的线性预填充相对于 Qwen3 全注意力的优势越明显，100 万 Token 时最高达到 21.9 倍。

在 128K 输入、128Token 输出的场景中：

• Transformer 首 Token 延迟为 77.249 秒；

• Orthros 降至 17.016 秒，约为原来的四分之一；

• Transformer 端到端耗时为 84.911 秒；

• Orthros 为 24.647 秒，端到端速度提升约 3.44 倍；

• 输出吞吐从 3.0 Token/s 提高到 10.4 Token/s。

与此同时，两者的纯解码吞吐分别为 33.7 Token/s 和 33.3 Token/s，几乎没有差别。

这验证了论文的判断。虽然 Orthros 在解码时处理了两个 Token，但在这组 batch size 为 2 的实验中，额外计算基本被显存 I/O 瓶颈掩盖。

不过，输出越长，Orthros 的端到端优势越小。

在 127K 输入、1K 输出时，端到端耗时从 137.715 秒降至 76.345 秒，约加速 1.8 倍。

当任务变成 120K 输入、8K 输出时，耗时只从 548.357 秒降至 488.830 秒，整体加速约 1.12 倍。

原因并不复杂。Orthros 主要节省的是读取长输入的时间。如果模型需要生成很长的答案，解码重新成为主要成本，预填充带来的优势自然会被摊薄。

读得更快之后，还能记住前面的内容吗？

高效注意力最容易牺牲的能力，就是远距离召回。

论文在 DROP、NarrativeQA、TriviaQA、SQuAD 等六项依赖上下文检索的任务上，对 1.3B 模型进行了测试。

结果显示：

• 全注意力 Transformer 平均得分为 33.9；

• Orthros 达到 34.4；

• GatedDeltaNet、GLA、RetNet 和单纯滑动窗口注意力的平均分为 25.7 至28.8。

换句话说，Orthros 在这组实验中基本保留了全注意力 Transformer 的上下文召回能力，同时明显领先于其他高效注意力架构。

团队还将由 Qwen3-8B 转换得到的 Orthros 继续用 20B Token 长上下文数据进行训练，并测试 128K「 大海捞针 」任务。

在这项测试中，一条关键信息会被随机埋进长达 128K 的上下文，模型需要在不同长度和不同位置下将其找出来。

Orthros 最终取得了接近满分的检索结果。需要注意的是，这并不是模型转换完成后直接获得的能力，而是在额外完成 20B Token 长上下文扩展训练之后得到的结果。

图注：经过 20B Token 长上下文扩展训练后，8B Orthros 在 128K 大海捞针测试中保持接近满分的召回率。

不必重新训练一个大模型，但转换也不是「一键完成」

一种新架构能否进入产业，除了从头训练的能力，还取决于现有模型能否迁移过去。

Orthros 采用的是相对独立的注意力模块，不需要把整个模型拆成上下两个解码器，也不依赖跨层共享一份 KV Cache。

因此，团队尝试直接替换 Llama 3.1-8B 和 Qwen3-8B 原有的注意力模块，再通过持续预训练完成架构转换。

为了区分「 架构变化 」与「 多看了训练数据 」的影响，论文为每个模型设置了三组对比：

• 原始基础模型；

• 保持 Transformer 架构、继续训练 80B Token；

• 更换为 Orthros 架构、同样继续训练 80B Token。

结果来了，在八项任务的平均分上：

• Llama 3.1-8B 原始模型为 65.47；

• 保持原架构继续训练后为 67.00；

• 转换为 Orthros 后为 67.26。

Qwen3-8B 的结果分别为：

• 原始模型 67.87；

• 原架构继续训练 67.55；

• Orthros转换模型 68.37。

这说明在论文的训练设置下，架构转换没有明显破坏原模型能力，平均表现甚至略高于使用相同数据继续训练的 Transformer 基线。

可以转换不等于低成本转换。两组 8B 模型都继续训练了 80B Token，训练序列长度为 32768，共运行 10000 步。因此，它更准确的定位是不用从零训练，但仍然需要一次规模不小的持续预训练。

从头训练，它还是一个合格的语言模型吗？

团队还从零训练了一个 1.3B 参数的 Orthros，训练数据量为 100B Token，并与 Transformer、GatedDeltaNet、GLA、RetNet 及滑动窗口注意力进行比较。

在七项常识推理任务上：

• Transformer 平均分为 53.41；

• Orthros 为 53.98；

• 其他高效架构为 51.90 至 53.29。

Orthros 并没有在每个单项任务上都领先，但综合结果与标准 Transformer 相当，平均分略高 0.57分。

此外，团队还把模型规模从 160M 扩展到 6.8B 参数。在统一的 10B Token 训练预算下，Orthros 整体呈现出与 Transformer 相近的规模扩展趋势。

这些实验至少说明，Orthros 不是一个只能依附于现有模型的推理技巧，而是一种可以独立训练的模型架构。

图注：在 1.3B 参数、100B Token 训练条件下，Orthros 的常识推理平均分与全注意力 Transformer 相当。

Orthros 最适合什么场景？

Orthros 的优势并不会平均出现在所有任务中。

它最适合的是「 输入很长、输出较短 」的工作负载：

• Agent 读取大量工具说明、历史轨迹与观察结果，输出简短动作；

• 代码智能体分析完整代码仓库，生成补丁或工具调用；

• RAG 系统读取大量检索材料，回答少量问题；

• 多模态模型处理长视频、高分辨率图像或大规模传感器 Token；

• 长文档摘要、合同审查和日志分析。

这些场景中，用户往往不是在等待模型慢慢写答案，而是在等待模型先把材料读完。

Orthros 把优化重点放在首 Token 出现之前，实际改善的是长上下文系统中最容易让用户感到停顿的部分。

Orthros 目前还有几个清晰的限制。

首先，它优化的是推理阶段，而不是预训练阶段。为保持训练与推理一致，预训练时需要复制整段序列，Token 计算量接近翻倍。

其次，它没有解决 KV Cache 的显存占用。模型仍然需要为每一层保存完整 KV，超长上下文带来的显存压力依然存在。

第三，21.9 倍是 100万 Token 条件下的预填充峰值加速，不是所有请求都能获得 21.9 倍端到端提升。论文的端到端实验使用单张 H100、batch size 为 2 和 SGLang。当输出长度增加时，整体收益明显缩小。

第四，Llama 和 Qwen 的架构转换使用了 80B Token 持续预训练，128K 近满分检索还增加了 20B Token 长上下文训练。这些训练成本不能从结论中省略。

此外，MoE 模型中的两个 Token 可能被路由到不同专家，反而增加权重读取压力。Orthros 在 Agent 强化学习、批量解码和现代推理框架中的最佳实现方式，也仍有待进一步研究。

但它提出了一个值得讨论的问题，即读取材料和生成答案，是否真的需要使用同样昂贵的计算方式？

当百万 Token 逐渐进入真实应用，大模型架构的竞争或许不再只是「 谁的注意力更快 」，还包括谁能更合理地分配算力——什么时候快速浏览，什么时候认真回头看，什么时候才值得调用完整的全局注意力。

最后，论文作者之一、Together AI 高级研究科学家，FutureMLS 创始人及首席研究员周中柱，将于 11 月 20—21 日在 2026 C++及系统软件技术大会带来主题分享。

如果说 Orthros 关注的是如何重新分配长上下文推理中的注意力计算，那么周中柱此次分享的《不止于论文：2-bit KV Cache 的工程落地之路》，将进一步聚焦长上下文推理的另一项关键瓶颈——KV Cache 的显存与带宽开销。

届时，他将结合 OSCAR 项目，分享 2-bit 量化、混合精度 KV Cache、Paged KV Cache 布局、低比特算子以及推理服务框架集成等工程实践，并讨论如何在显存、首 Token 延迟、吞吐量与模型准确率之间取得平衡。