压缩记忆
在标准注意力机制中引入压缩记忆，让模型把历史上下文压进有限参数里，而不是为每个 token 都保存一份键值状态。
Infini-attention
AI TOOL PROFILE工具资料把压缩记忆装进注意力机制，让 Transformer 处理无限长输入
价格官网未标价
平台—
归类大模型与开发平台
收录2024-04-10
复核2024-04-10
编辑评分
4.2 / 5
★★★★☆
Infini-attention编辑总结
Infini-attention 是 Tsendsuren Munkhdalai、Manaal Faruqui、Siddharth Gopal 在 2024 年 4 月提交的一篇论文提出的注意力技术，目标是让大语言模型在内存和计算有界的前提下处理无限长的输入。做法是在标准注意力里加入压缩记忆，把掩码局部注意力与长期线性注意力合并进同一个 Transformer 块。论文在 1B 和 8B 模型上验证了长上下文语言建模、1M 序列长度的 passkey 上下文块检索以及 500K 长度的书籍摘要任务，并支持流式推理。它的短板也很明显：目前仍属于研究阶段的论文方法，没有可直接调用的产品化接口，落地需要自行实现。
Infini-attention是什么？
Infini-attention 是一种面向大语言模型的注意力技术，由 Tsendsuren Munkhdalai、Manaal Faruqui、Siddharth Gopal 提出。它要解决的问题是 Transformer 处理超长输入时内存和计算会随序列长度快速膨胀，目标是让模型在内存与计算保持有界的情况下扩展到无限长输入。
技术上，它把一块压缩记忆引入标准注意力机制，在同一个 Transformer 块里同时保留掩码局部注意力和长期线性注意力。这样模型既能关注近处的上下文，也能通过压缩记忆保留远处的信息。论文在 1B 和 8B 规模的大语言模型上做了验证，覆盖长上下文语言建模、1M 序列长度的 passkey 上下文块检索和 500K 长度的书籍摘要任务，并支持快速的流式推理。
对研究者和工程团队来说，这是一条公开的方法路线：可以在自己的长上下文模型改造中参考它的注意力结构设计；普通用户不会直接用到它，因为它是论文层面的技术而非成品工具。论文标注为 9 页、4 图、4 表，第二版补充了背景、实现细节、近期引用和致谢。
Infini-attention核心功能
单块双注意力
把掩码局部注意力和长期线性注意力放进同一个 Transformer 块，近处细节与远处信息由两种机制分工处理。
有界内存与计算
方法的目标是让内存和计算不随输入长度无限增长，从而把 Transformer 扩展到无限长输入。
1M 长度检索验证
在 1M 序列长度的 passkey 上下文块检索任务上验证了效果，说明模型能在极长上下文中找回指定信息。
500K 书籍摘要
在 500K 长度的书籍摘要任务上做了测试，覆盖需要通读超长文本再生成摘要的场景。
流式推理
方法支持快速流式推理，适合边输入边处理的连续长序列场景，而不必等整段文本就绪。
Infini-attention值不值得用？
当你的工作是长上下文模型的研究或工程改造，尤其是想解决超长输入的显存与计算瓶颈时，Infini-attention 值得细读：它给出了把压缩记忆和线性注意力合进单个 Transformer 块的具体思路，并在 1B、8B 模型和 1M 检索、500K 摘要任务上做了验证。但如果你要的是一个能直接调用的长文本产品，它并不合适——这是论文方法而非成品工具，没有公开的调用接口，落地需要自己实现并做工程验证。 另外，论文只给出方法层面的结果，除验证任务外并未公开推理成本、延迟等指标，选型前需要在自己的数据上做一轮实测。
建议选它的情况
- 做长上下文方向研究，需要一份可参考的注意力结构设计时
- 模型要处理超长输入，显存被键值缓存卡住，想找有界内存方案时
- 需要流式推理能力，希望边输入边处理连续长序列时
- 在 1B 到 8B 规模模型上做长序列实验，需要对照方案时
不建议选它的情况
- 想要拿来即用的长文本产品或 API，论文方法不会直接给你接口
- 团队没有实现和调参注意力机制的工程能力
- 需要现成的推理成本与延迟数据来做采购决策
Infini-attention使用建议
入门先把路子走对
- 先看摘要arXiv 页面上的摘要已经把方法核心讲清楚：压缩记忆加双注意力结构，先读这段再决定要不要往下看全文。
- 第二版补了实现细节第二版补充了背景、实现细节、近期引用和致谢，动手复现前先确认自己看的是 v2 而不是初版。
- 对着验证任务复现先按 1M 序列长度的 passkey 上下文块检索任务搭一个小实验，这条最容易验证方法是否按预期工作。
- 按论文结构读论文标注 9 页、4 图、4 表，篇幅不长，建议先看方法配图再看实验表格，比从头顺读省时间。
进阶省时间也省钱
- 记忆容量要单独调压缩记忆的容量决定了长期信息的保留程度，在小模型上先扫描不同记忆规模，再迁移到大模型上。
- 近远信息分开评估局部注意力和线性注意力各自负责不同距离的上下文，评估时把近距和远距任务拆开测，才知道是哪一部分没达标。
- 先测流式场景如果目标是流式推理，优先在连续输入场景下测吞吐与稳定性，比只跑离线长序列更能暴露问题。
Infini-attention适合谁用？
长上下文研究者
推荐研究 Transformer 扩展到超长输入的方法，可以直接对照其压缩记忆与双注意力设计，论文篇幅只有 9 页，读完成本低。
大模型训练工程团队
推荐要在 1B 到 8B 规模模型上改造注意力结构，论文给出了在 1M 检索和 500K 摘要任务上的验证结果，可作为方案参考。
需要流式推理的产品团队
有条件方法支持快速流式推理，适合边输入边处理的连续长序列；但落地需自行实现，官网未公开可直接调用的接口。
想直接处理长文档的普通用户
不推荐这是论文层面的注意力技术，没有成品工具可下载或调用，普通用户无法直接拿它切分文件或总结文章。
采购选型人员
不推荐论文未公开推理成本、延迟与授权条件，无法据此做预算与合规判断，需要先做技术验证再谈采购。
Infini-attention优点和缺点
优点
- 在 1B 和 8B 模型上完成长上下文语言建模验证
- 在 1M 序列长度的 passkey 上下文块检索任务上验证有效
- 在 500K 长度的书籍摘要任务上做了测试
- 压缩记忆带来最小的有界内存参数增量
- 支持快速流式推理，适合连续长输入
- 方法写在同一个 Transformer 块内，结构相对集中
缺点
- 属于论文方法，没有可直接调用的产品或接口
- 官网未公开推理成本与延迟等工程指标
- 官网未说明代码与模型的开放范围和授权条件
- 落地需要团队自行实现并做大量工程验证
- 除论文验证任务外，缺少更多场景的效果数据
Infini-attention关键指标
| 指标 | 数值 | 数据来源 |
|---|---|---|
| 论文页数 | 9 pages | arXiv 摘要页 Comments |
| 图表数量 | 4 figures, 4 tables | arXiv 摘要页 Comments |
| 验证模型规模 | 1B and 8B LLMs | arXiv 摘要页 Abstract |
| 检索任务序列长度 | 1M sequence length passkey context block retrieval | arXiv 摘要页 Abstract |
| 摘要任务长度 | 500K length book summarization | arXiv 摘要页 Abstract |
Infini-attention常见问题
Infini-attention 是什么？＋
它是一种让大语言模型处理无限长输入的注意力技术，由 Tsendsuren Munkhdalai、Manaal Faruqui、Siddharth Gopal 在 2024 年 4 月提交的论文中提出。做法是在标准注意力里加入压缩记忆，并把掩码局部注意力和长期线性注意力放进同一个 Transformer 块。
它真的能处理无限长的输入吗？＋
论文的目标是在内存和计算有界的前提下把 Transformer 扩展到无限长输入，并在 1M 序列长度的 passkey 上下文块检索、500K 长度的书籍摘要任务上做了验证。这里的「无限」是方法层面的设计目标，实际能力取决于具体实现和模型规模。
在什么模型规模上验证过？＋
论文在 1B 和 8B 两个规模的大语言模型上做了实验，覆盖长上下文语言建模、1M 序列长度的 passkey 上下文块检索以及 500K 长度的书籍摘要任务，并支持快速流式推理。
和标准注意力相比改了什么？＋
标准注意力要为每个 token 保存键值状态，长输入下开销迅速膨胀。Infini-attention 在注意力机制中引入一块压缩记忆，同时保留掩码局部注意力和长期线性注意力，使内存和计算不随序列长度无限增长。
可以直接拿来用吗？＋
不能直接用。它是论文提出的方法，没有公开的调用接口或成品工具，落地需要团队按论文实现并自行完成工程验证。此外论文未说明代码与模型的开放范围和授权条件。
论文篇幅长吗？＋
标注为 9 页、4 图、4 表。第二版补充了背景、实现细节、近期引用和致谢，读第二版比初版信息更完整。
Infini-attention最新动态
-
第二版发布
第二版补充了背景、实现细节、近期引用和致谢，同时对部分表述做了修订。
-
论文提交
论文首次提交至 arXiv，编号 arXiv:2404.07143，归属 cs.CL，同时涉及 cs.AI、cs.LG、cs.NE。
