128k

general · First seen 2026-05-28 · Last seen 2026-10-21 · 85 mentions

Overview

128k 指的是 128K(约 12.8 万)token 的上下文窗口长度,是当前主流大模型长文本能力的标志性规格,可用于一次性处理整本书、大型代码库或数小时对话记录。围绕 128k 级别上下文,行业竞争已从“能不能装下”转向“装下之后是否记得住、算得起”,长上下文的记忆管理与推理效率成为新的技术焦点。

128k 上下文背后的记忆与架构进展

  • MemOS 团队发布记忆原生大模型 MemT 1.0,记忆写入变成模型能力:MemOS 推出的 MemT 1.0 把记忆写入内化为模型自身能力,而非依赖外部检索。该系列提供 Flash 版 288B 与 Nano 版 36B 两个规格,相关论文已上线 arXiv。这被视为对“长上下文窗口越大越好”路线的一种补充——用原生记忆机制替代单纯堆 token 数。
  • Orthros 注意力机制实现线性预填充与全注意力解码:该方法在预填充阶段用线性注意力降低长文本的处理成本,同时在解码阶段保留全注意力的精度,针对的正是 128k 长上下文在预填充阶段的开销瓶颈。
  • LatentIndex:跨层共享加按层选择的稀疏注意力索引方法:来自 DeepSeek 方向的稀疏注意力索引工作,通过跨层共享索引减少长序列注意力的计算与显存占用,是长上下文推理加速的代表性思路。
  • Recursive Flint 40B 开源模型本地跑出 125 token/秒编码速度:开源 40B 模型在本地实现 125 token/秒的编码速度,说明中等参数规模模型配合优化后也能承担长上下文编程任务。
  • 当前焦点与观察点

    目前关于 128k 的讨论主要集中在三点:一是上下文利用率,即窗口标称 128k 但模型实际能有效利用多少中间信息;二是成本,长上下文的预填充计算量和 KV 缓存显存仍是主要开销,Orthros、LatentIndex 等工作都试图用线性化或稀疏化压低这部分成本;三是与记忆机制的路线之争,MemT 1.0 代表的“记忆原生”思路认为,与其无限扩大窗口,不如让模型具备持久记忆能力。短期内两条路线大概率并存:128k 级窗口继续作为通用规格,而记忆机制先在智能体等需要跨会话记忆的场景落地。对开发者而言,选型时除看标称上下文长度外,还需关注实际召回质量和单位推理成本。

    Coverage

    10 on file