InfLLM是一种无需再训练的LLMs长上下文处理方法，通过Memory Units和Sliding Window分别建模远距离和局部上下文。它将历史KV Cache分块为memory units，选取代表性tokens，并设计高效的检索和LRU缓存机制，仅加载相关memory units至GPU，显著降低显存占用。这种方法使模型能够处理超长序列，同时保持性能，且无需昂贵的持续预训练。
参考：
- InfLLM: Training-Free Long-Context Extrapolation for LLMs with an Efficient Context Memory
- Github
Motivation & Contribution
Motivation
现有 LLMs 在预训练时受限于最大长度序列，当尝试将其应用于更长序列时，会面临两大核心问题：
域外输入问题：模型所依赖的位置编码（如 [RoPE：让大模型更懂位置信息的“旋转密码”]）在超出预训练长度时失效，导致其无法正确建模 token 间的相对或绝对位置关系，从而引发性能急剧下降
干扰问题：长文本中包含大量与当前任务无关的噪声内容，导致注意力分数分散，模型可能错误地依赖这些噪声 token，而非关键信息
常见的解决方案通常需要在更长序列上进行持续预训练，但这会引入高昂的计算开销，并导致模型能力不可控的变化
Contribution
提出 infLLM，一种 training-free memory-based 方法：
- 使用 Memory Units + Sliding Window，分别建模远距离上下文和局部上下文，以处理长文本输入
- 设计高效的 memory unit 检索和缓存机制，减少 GPU 显存占用，并提高推理效率
Methods
整体架构
图 1：InfLLM 示意图
如上图所示，为 InfLLM 的核心原理示意图。
根据与当前 token 的距离，可将 Past Key-Value 分为三部分：
- initial Tokens
- 位于输入最开头、具有关键任务语义的固定部分，通常包括系统提示、用户指令等
- 这部分会始终保持在每个 Step 的生成过程中，确保模型始终“记得”任务目标，避免在长生成过程中偏离主题
- 比如用户输入的 prompt，请以‘传说两百年前，月球背面’ 为开头，写一篇 8000 字的科幻小说
- Local Tokens
- 与当前 token （不含当前）相邻若干历史生成的 token 的固定窗口，这部分 KV Cache 常驻显存，直接参与 attention 计算
- 用于提供局部上下文连贯性，比如保持句子语法正确、情节衔接自然
- 比如当前正在生成第 3267 个 token，Local Tokens 大小为 2048，则 Local Tokens 表示从第 1219 个到第 3266 个的 tokens 的 KV Cache
- Evicted Tokens
- 位于 Initial 之后，Local 之前的历史内容，比如本例中的第 1 到第 1218 个 tokens 的 KV Cache
- InfLLM 将其分块（比如每 128 token 一个 chunk），组成 Memory Units，不常驻显存
- 只有被选中的 Memory Units 的“代表性 tokens”的 KV 向量，才会被加载进当前 KV Cache 并参与 attention 计算。整个 chunk 不参与
在每个 generate step 中，InfLLM 将这三部分进行拼接，作为当前 step 的 KV Cache：
其中 表示 Memory Units 的检索出的代表性的 tokens。因此，当前 step 对应的 attention 计算为：
其中：
- 表示当前在处理的 tokens
- 对于编码阶段（对输入长序列分块编码），current tokens 表示当前分块内的 tokens，本文设置为
- 对于生成阶段（模型生成结果），current tokens 表示当前在生成的 token，对应的
- 为投影参数矩阵
- 为 Key-Value 向量
Context Memory
Memory Units & Representative Tokens
先前的研究表明，LLMs 的 attention score matrix 具有稀疏性，也就是说，我们只需要保留少量的 KV vectors 即可生成相同的输出。受此启发，我们设计了一种高效的上下文记忆机制。
考虑到长序列下的局部语义一致性，我们：
将 past KV Cache 分块（比如 128 个 tokens），每个 chunk 作为一个 memory unit
在每个 memory unit 中，通过如下方式选取最具代表性的若干个 tokens 作为该 chunk 的代表
即：计算该 chunk 中第 个 token 的 key 向量与其后 个 token 的 query 向量的点积（表示相似度）的均值，以表征该 token 的重要性。
为何这里是其后的 （一般为 Sliding Window 窗口大小）个 tokens（可能跨 chunks），而非同一 chunk 内的其他 tokens，原因如下：
- 符合 LLMs 的单向性：InfLLM 主要用于 decoder-only 模型，其解码顺序为从左往右，即：当前 token 只会影响其后的 tokens
- 影响力总和反映的是语义引导能力：第 m 个 token 的语义信息，在接下来的一段文本中被多少次关注，是否是一个关键概念、主题句或转折点
- 避免“自我中心”偏差：在本 chunk 内反复出现的 token，不一定是最具代表性的，比如 “the”、“and” 等停用词
Memory Unit 是在编码阶段（encoding）动态构建的：
- 当输入长序列被分块（chunk-by-chunk）编码时，每处理完一个 chunk，就将其 KV Cache 划分为 memory units，并选出 representative tokens，存入 CPU
- 这是 流式处理（streaming） 的关键
对于每个 memory unit，本文选取前 个代表性的 tokens。
Units Selection
同时，由于完整的历史 KV Cache 会占用大量显存，因此 InfLLM 首先将其存储于 CPU 内存中。随后在每个 generate step 中进行 memory lookup，会计算所有 memory units 与当前 token 的相关性得分，仅将 个最相关的 memory units 的代表性 tokens 加载至 GPU 显存参与 attention 计算。
其中相关性得分计算方式如下：
其中：
- 表示当前正在处理的 token 序列（长度为 ，编码阶段为 512；解码阶段为 1）
- 表示第 个当前 token 的 query 向量
- 表示 memory unit B 中第 个代表性 token 的 key 向量
Cache Management
Why？
在 Units Selection 步骤中，我们需要计算当前 token 与所有 memory units 之间的相关性得分。这就要求存储每个 memory unit 对应的代表性 tokens（本节统一用 memory units 指代）的 keys。对于超长文本而言，对应的显存需求将不能接受。因此我们将历史 KV Cache 存储于 CPU 内存中。
同时，筛选后的 memory units 需要参与 attention 计算，因此需要在 GPU 中保存其对应的 KV Cache。鉴于长序列具有语义连贯性，相邻 token 通常依赖类似的 memory units。因此我们采用 off-load 机制，在 GPU 显存中保留当前 generate step 所需的关键 memory units。具体通过 LRU（Least Recently Used）策略进行管理。
从结果来看，该机制使得 InfLLM 能够仅使用 26G VRAM 处理包含 100K 标记的序列。此外，GPU 缓存未命中率非常低，因此对应的 CPU 到 GPU 的数据加载开销极小。
How to Look Up？
因此，memory units look up 的基本步骤如下：
遍历 memory units
若不存在于 GPU 缓存中，则：
从 CPU 加载对应的 keys 至 GPU
在 GPU 上计算相关性得分
若存在于 GPU 缓存中，则：
直接在 GPU 上计算相关性得分
选择最相关的 个 memory units
若不存在于 GPU 缓存中，则加载至 GPU，并通过 LRU 策略更新缓存
将这 个 memory unit 的 KV Cache 与 Initial Tokens 和 Local Tokens 拼接，构建 current KV Cache，参与 attention 计算
How to Update LRU？
那么，如何维护 LRU 缓存呢？我们为每个已缓存的 memory unit 维护一个频率得分 ，用于衡量 memory unit 被访问的频繁程度。其在 attention 计算后，通过如下方式更新：
其中：
- 表示 current tokens 长度（编码阶段为 512；解码阶段为 1）
- 表示衰减系数，表示对历史访问的“遗忘”，本文设置为
- 表示 current tokens 中第 个 token
- 表示该 memory unit 中第 个代表性 token
下面是 LRU 更新策略与其他更新策略的效果对比：
图 4：不同缓存管理策略的缺失率wefew
Position Embedding
在 InfLLM 中，KV Cache 不再连续，因此不能直接使用连续的位置编码。为此，我们为所有 Evicted Tokens 分配相同的 Position Embedding 。
后续实验发现，LLMs 可以自行搞清楚相对顺序。这是因为 LLM 是单向的（从左往右生成），在处理每个 token 时，前面的内容已经编码至其 memory 中。
Experiments
详见原论文。
SOTA
Compare to SOTA
Comparing to Models with Continual Training
长度拓展时的性能变化
消融实验
最后
我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。
我整理出这套 AI 大模型突围资料包：
- ✅AI大模型学习路线图
- ✅Agent行业报告
- ✅100集大模型视频教程
- ✅大模型书籍PDF
- ✅DeepSeek教程
- ✅AI产品经理入门资料
完整的大模型学习和面试资料已经上传带到CSDN的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇
为什么说现在普通人就业/升职加薪的首选是AI大模型？
人工智能技术的爆发式增长，正以不可逆转之势重塑就业市场版图。从DeepSeek等国产大模型引发的科技圈热议，到全国两会关于AI产业发展的政策聚焦，再到招聘会上排起的长队，AI的热度已从技术领域渗透到就业市场的每一个角落。
智联招聘的最新数据给出了最直观的印证：2025年2月，AI领域求职人数同比增幅突破200%，远超其他行业平均水平；整个人工智能行业的求职增速达到33.4%，位居各行业榜首，其中人工智能工程师岗位的求职热度更是飙升69.6%。
AI产业的快速扩张，也让人才供需矛盾愈发突出。麦肯锡报告明确预测，到2030年中国AI专业人才需求将达600万人，人才缺口可能高达400万人，这一缺口不仅存在于核心技术领域，更蔓延至产业应用的各个环节。
资料包有什么？
①从入门到精通的全套视频教程⑤⑥
包含提示词工程、RAG、Agent等技术点
② AI大模型学习路线图（还有视频解说）
全过程AI大模型学习路线
③学习电子书籍和技术文档
市面上的大模型书籍确实太多了，这些是我精选出来的
④各大厂大模型面试题目详解
⑤ 这些资料真的有用吗?
这份资料由我和鲁为民博士共同整理，鲁为民博士先后获得了北京清华大学学士和美国加州理工学院博士学位，在包括IEEE Transactions等学术期刊和诸多国际会议上发表了超过50篇学术论文、取得了多项美国和中国发明专利，同时还斩获了吴文俊人工智能科学技术奖。目前我正在和鲁博士共同进行人工智能的研究。
所有的视频教程由智泊AI老师录制，且资料与智泊AI共享，相互补充。这份学习大礼包应该算是现在最全面的大模型学习资料了。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
智泊AI始终秉持着“让每个人平等享受到优质教育资源”的育人理念，通过动态追踪大模型开发、数据标注伦理等前沿技术趋势，构建起"前沿课程+智能实训+精准就业"的高效培养体系。
课堂上不光教理论，还带着学员做了十多个真实项目。学员要亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事！
如果说你是以下人群中的其中一类，都可以来智泊AI学习人工智能，找到高薪工作，一次小小的“投资”换来的是终身受益！
应届毕业生：无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。
零基础转型：非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界。
业务赋能 突破瓶颈：传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型。
👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓**
