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

NeurIPS 2026：Orthros架构实现百万Token预填充加速21.9倍

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

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

责编丨梦依丹

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

如果让大模型处理100万 Token的输入材料，却仅生成几十个 Token的回答，算力应主要消耗在读取材料还是生成答案上？ 传统 Transformer 在处理长输入时，每个 Token 均需与此前内容进行全量注意力计算，导致上下文越长成本越高。来自香港理工大学、中国科学院大学、悉尼大学等机构的研究团队提出新架构 Orthros。该架构在读取长输入时快速建立上下文，仅在真正生成答案时调用全局注意力。 这种“分阶段用力”的设计，使 Orthros 在 100 万 Token 输入下实现最高 21.9 倍的预填充加速，同时在 128K “大海捞针”测试中保持接近满分的检索能力。Orthros 不仅支持从头训练，还能通过持续训练将 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 正是针对这种“重预填充、轻解码”场景设计，旨在降低读取长输入的成本，将昂贵的全局注意力保留至生成答案阶段。

线性注意力的局限与 Orthros 的突破

过去几年，研究者提出了滑动窗口注意力、线性注意力和状态空间模型等多种高效架构，试图将计算复杂度从平方级降至线性级。然而，这些方法往往以牺牲远距离信息检索能力为代价： * **滑动窗口注意力**：仅关注局部内容，关键事实若出现在视野之外则无法捕获； * **线性注意力**：将历史信息压缩至固定状态，虽提升速度但可能丢失细节。 许多模型采用混合策略，即在部分层使用高效注意力，同时保留全注意力层。但只要存在全注意力层，超长输入时的平方级瓶颈并未根本消除。 Orthros 提出不同思路：问题不在于“每层使用哪种注意力”，而在于输入阶段和输出阶段无需使用相同的计算方式。

双路径机制：快速扫描与全局检索

Orthros 在每一层维护两条不同的 Token 流： 1. **基础 Token 流**：所有输入 Token 经过此路径，使用窗口大小为 128 的滑动窗口注意力。其作用是理解局部上下文，并为每一层建立完整的 KV Cache。这类似于“快速通读并整理索引”。 2. **输出专用 Token 流**：仅承担“预测下一个输出 Token”任务的位置进入此路径。它们通过全交叉注意力访问基础流建立的全部 KV Cache，从整个历史上下文中寻找信息。这类似于“带着问题查资料，回头搜索整份文档”。 两条路径共享主要的 Query 投影矩阵，但 Orthros 增加了轻量缩放和偏移参数，使同一投影能适应“局部理解”和“全局检索两种任务。该设计的核心并非取消全注意力，而是仅在需要形成输出的位置使用全注意力。

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

四阶段动态切换工作模式

Orthros 通过调整输入 Token 与输出专用 Token 的数量，使同一套模块适应四种状态： **1. 预训练：全序列预测** 在自回归预训练中，每个位置均需预测下一个 Token。因此，Orthros 为整段序列复制一组输出专用 Token。此时训练阶段仍具有平方级复杂度，且需处理接近双倍的 Token 以保持训练与推理一致。这意味着 Orthros 并不能降低预训练成本。 **2. 监督微调：仅答案部分全局检索** 损失通常只计算在回答部分。用户问题主要经过基础 Token 流，仅答案对应位置增加输出专用 Token。强化学习产生的回答轨迹也可采用类似方式训练。 **3. 预填充：长 Prompt 仅保留一个全局查询** 这是 Orthros 最关键的优势阶段。面对长 Prompt，模型仅复制最后一个输入 Token。此前的大量 Token 通过滑动窗口注意力处理，最后一个输出专用 Token 对完整 KV Cache 执行一次全局检索，生成答案的首个 Token。无论 Prompt 多长，真正执行全局注意力的查询数量保持为 1，预填充阶段由此从平方复杂度降至接近线性复杂度。 **4. 解码：每一步生成一对 Token** 解码阶段每生成一个 Token，Orthros 创建一对功能不同的 Token：一个负责更新 KV Cache 和处理局部信息，另一个负责查询完整历史并预测下一个 Token。虽然解码计算量增加，但在低批量解码受显存带宽限制而非纯计算量限制的场景下，额外计算的算术开销可被权重加载的等待时间掩盖。这种设计将额外计算移至 GPU 未充分利用的阶段，从而优化整体效率。

性能实测：百万 Token 预填充提速显著

论文测试了 8B 参数的 Orthros 与 Qwen3 在长上下文预填充阶段的速度。单 GPU 测试覆盖 8K 至 128K 输入，8 GPU 测试覆盖 64K 至 100 万 Token。结果显示，在 100 万 Token 输入下，Orthros 取得最高 21.9 倍的预填充加速。 在单张 H100 GPU 上，通过 SGLang 推理引擎进行的端到端测试（Batch size=2）显示： 在 128K 输入、128 Token 输出场景中： * **首 Token 延迟**：Transformer 为 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 在解码阶段的额外计算基本被显存 I/O 瓶颈掩盖。 然而，输出越长，Orthros 的端到端优势越小： * 127K 输入、1K 输出：耗时从 137.715 秒降至 76.345 秒（加速约 1.8 倍）； * 120K 输入、8K 输出：耗时从 548.357 秒降至 488.830 秒（加速约 1.12 倍）。 原因在于 Orthros 主要节省读取长输入的时间。若生成长答案，解码重新成为主要成本，预填充带来的优势会被摊薄。

准确性评估：保留全注意力的召回能力

高效注意力架构常牺牲远距离召回能力。在 DROP、NarrativeQA 等六项依赖上下文检索的任务上，1.3B 模型测试结果显示： * 全注意力 Transformer 平均得分：33.9 * Orthros 平均得分：34.4 * 其他高效架构（GatedDeltaNet、GLA 等）：25.7 至 28.8 Orthros 基本保留了全注意力 Transformer 的上下文召回能力，并明显领先于其他高效架构。 在 128K “大海捞针”测试中，由 Qwen3-8B 转换得到的 Orthros 在经过 20B Token 长上下文扩展训练后，取得了接近满分的检索结果。需注意，这一能力并非转换后直接获得，而是依赖于额外的长上下文训练。

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

架构迁移：无需从头训练，但需持续预训练

Orthros 采用相对独立的注意力模块，无需拆解整个模型或跨层共享 KV Cache，便于现有模型迁移。团队尝试直接替换 Llama 3.1-8B 和 Qwen3-8B 的注意力模块，并通过持续预训练完成转换。 对比实验设置三组：原始模型、原架构继续训练 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 基线。但需注意，转换过程涉及 80B Token 的持续预训练，并非低成本的一键转换。

从头训练：具备独立架构能力

团队从零训练了一个 1.3B 参数的 Orthros（100B Token 数据）。在七项常识推理任务上，Orthros 平均分 53.98，略高于 Transformer 的 53.41，且优于其他高效架构（51.90 至 53.29）。此外，在 160M 至 6.8B 参数规模的扩展实验中，Orthros 呈现出与 Transformer 相近的规模扩展趋势。这证明 Orthros 是一种可独立训练的成熟架构，而非仅依附于现有模型的推理技巧。

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

适用场景与局限性

**最佳适用场景：** Orthros 最适合“输入很长、输出较短”的工作负载，如： * Agent 读取大量工具说明与历史轨迹，输出简短动作； * 代码智能体分析完整仓库，生成补丁； * RAG 系统读取大量材料回答问题； * 多模态模型处理长视频或高分辨率图像； * 长文档摘要、合同审查和日志分析。 在这些场景中，用户等待的主要是模型读取材料的时间，Orthros 优化了这一痛点。 **当前局限性：** 1. **预训练成本高**：为保持一致性，预训练时需复制整段序列，Token 计算量接近翻倍。 2. **显存占用未减**：仍需保存完整 KV Cache，超长上下文的显存压力依然存在。 3. **加速效果依赖场景**：21.9 倍是 100 万 Token 下的预填充峰值加速。当输出长度增加，端到端收益明显缩小。 4. **转换成本不低**：架构转换需 80B Token 持续预训练，长上下文能力还需额外 20B Token 训练。 5. **MoE 模型适配待研**：在 MoE 模型中，双 Token 机制可能增加权重读取压力，其在 Agent 强化学习和批量解码中的最佳实现方式仍有待研究。 Orthros 提出了一个核心问题：读取材料和生成答案是否需使用同样昂贵的计算方式？随着百万 Token 应用普及，大模型架构的竞争将聚焦于如何合理分配算力——何时快速浏览，何时认真回顾，何时调用全局注意力。 最后，论文作者之一、Together AI 高级研究科学家及 FutureMLS 创始人周中柱，将于 11 月 20—21 日在 2026 C++及系统软件技术大会带来主题分享《不止于论文：2-bit KV Cache 的工程落地之路》，深入探讨长上下文推理中 KV Cache 的显存与带宽开销优化方案。