InfLLM与StreamingLLM长上下文方案

可视化演示

展示StreamingLLM滑动窗口注意力、注意力汇聚锚点机制，以及KV缓存内存效率对比。

长上下文困境

想象你正在读《世界全书》，第 1000 页上出现了一个线索，但你必须同时对照第 1 页、第 37 页、第 512 页……如果每次读到新页都要把前面的所有页重新翻一遍，阅读速度就会越来越慢，直到彻底卡住。Transformer 的全注意力机制正是如此：每生成一个新 token，都要回头看所有历史 token，并计算它们两两之间的相关程度。页数越多，这种“回头看”的代价就越大。

更麻烦的是，模型还要把每一页的“读书笔记”（也就是 K 和 V 向量）都保存在内存里，以便后续快速复用。这意味着不仅计算量随序列长度急剧膨胀，显存占用也在不停上升。为了缓解这个问题，早期方案会直接截断历史，只看最近的一小段。可这样做的代价是：模型把更早的关键信息全忘了。还有一类问题是“位置编码漂移”——模型训练时见过的位置范围是有限的，一旦输入超出训练长度，页码本身都变得不可信。

回到图书馆的例子：书页无限增加的时候，“每次都重读全书”的方案显然不可持续。我们必须像聪明的读者一样，只保留最关键的几页，或按需去远处取回少数的几页。

注意力与KV缓存

在动手解决长上下文之前，要先理解模型“读笔记”的方式。假设你现在有一个问题，比如“这本书的定价是多少”，这就是查询 \(Q\)。图书馆里每页的标题、标签就是键 \(K\)，而页面上真正的答案内容就是值 \(V\)。注意力机制做的，就是拿你的问题去和每页的标签做匹配，找出哪些页最值得阅读，然后把最有价值的内容汇总成回答。

模型的注意力公式可以拆成三步：先让 \(Q\) 和所有 \(K\) 做点积，得到初步的“相关分数”；再经过 softmax 归一化，让所有分数变成正数且加起来等于 1；最后用这些分数对 \(V\) 做加权求和。这个加权求和的过程，就像把若干张便签纸上的答案按可信度混合成一条新笔记。

理解了这套笔记机制，就能明白 KV Cache 的价值：过去页面的 \(K\) 和 \(V\) 一旦算好，就存在“缓存区”里，新问题来时只需要带上新的 \(Q\)，不必重新计算历史页面的笔记。可如果缓存区无限膨胀，终究还是会撑爆内存。

流式锚点方法：StreamingLLM

现在你决定采用“书签派”读法：手边永远放着《世界全书》的第一页，以及最近翻过的几页。第一页虽然内容不多，但它给出了全书的话题基调，所以模型在产生注意力时，会不自觉地给它分配很高权重。这种现象被称为“注意力汇聚”（attention sink），就像开会时大家都习惯性地看向主持人，即使主持人并没有说出关键信息。

StreamingLLM 正是利用这一点：无论序列已经写到多长，只保留初始 token 的 KV Cache 作为锚点，再结合一个滑动窗口，窗口里是最近 \(w\) 个 token 的 KV Cache。计算新 token 的注意力时，只看锚点和窗口，完全不看中间那些古老但非开头的 token。这样 KV Cache 不再随序列长度增长，真正实现了“无限流式处理”。

这一招的精妙之处在于：锚点提供了长期主题，窗口提供了最新语境，而中间的旧细节被主动遗忘。就像一位读者永远知道这本书讲的是“宇宙历史”，也记得刚刚读到的章节，至于第 300 页的某个数字，丢掉就丢掉了。

检索记忆方法：InfLLM

如果一个问题偏偏要依赖第 300 页的某个细节呢？书签派会无能为力。这时轮到“检索派”登场：请图书管理员根据你的问题，去书库深处把相关的那几页取回来。InfLLM 的思路正是如此——它并不试图记住所有历史 token，而是把历史 KV 按块存放在“记忆银行”中，每个块有一个精炼的“块级摘要”。

当新的查询到来时，InfLLM 先用查询和各个块摘要做相似度计算，选出最相关的 Top-k 个远距离 KV 块。随后，注意力只在“当前滑动窗口 + 这 k 个被检索出来的块”上进行。这样，模型既能保持滑动窗口的流式特性，又能主动触及很久以前的细节，而成本只由窗口大小和 k 决定，不随历史总长度增长。

InfLLM 的工程细节中，块级摘要通常不是把块内所有 token 都存一遍，而是通过“采样评估”的方式选取少量代表性 token 来计算块级键。这就像图书管理员只看目录和摘要，而不会把整本书背诵下来。于是检索成本大大降低，长程记忆却依然精准。

方案对比分析

现在我们把“书签派”和“检索派”放在同一张书桌上比较。书签派（StreamingLLM）最大的优点是零检索开销：它只需要锚点加窗口，显存是固定大小，部署简单、推理速度快。缺点也很明显：除了初始 token，中间的历史细节全部丢失，遇到“第 300 页的细节”这种问题时只能靠猜。

检索派（InfLLM）则多了一道“管理员检索”工序。它需要额外的记忆银行、块级摘要和 Top-k 排序，因此实现更复杂，但只要检索准确，就能覆盖更远的内容。两者的共同点是都避开了全注意力的二次方增长，改为“局部注意力 + 有限补充”。

选择哪个方案，取决于你的场景：如果任务只依赖最近的对话和系统提示，StreamingLLM 是轻量首选；如果任务需要回答文档深处的细节，InfLLM 的检索能力则更有价值。两者甚至可以在同一产品里配合使用。

工程实践要点

把论文里的方法变成可用的系统，还需要一套“阅览室规则”。首先是窗口配置：窗口太小，模型连当前话题都接不上；窗口太大，显存和延迟又会上升。实践中通常根据任务类型扫描 512、1024、2048 等窗口大小，同时观察困惑度（Perplexity，PPL）和下游任务指标。

其次是缓存管理：StreamingLLM 要保证锚点永远不被淘汰，窗口内的旧 token 按先进先出淘汰；InfLLM 要设计好块大小、块摘要的采样数量以及 Top-k 的召回策略。实现时还要注意检索延迟，不能让管理员找书的时间拖慢整个阅读节奏。评测指标里，PPL 是最常用的语言模型质量度量，它衡量模型对文本的预测能力。

工程实践的核心，是把“书签”和“检索”变成一套可监控、可调参的机制。锚点位置不能丢，窗口淘汰要平滑，检索块要控制时延。调试的路子走对了，无限长文本就真的能在产品里跑起来。

应用前景展望

当“书签派”和“检索派”的能力合在一起，我们几乎拥有了一本永远不会读完、也永远不会读不完的书。长文档问答不再需要把全文塞进模型，多轮对话可以无限延续而不爆显存，代码仓库的理解也不必把整个项目复制到上下文窗口里。

在这些应用中，模型的有效上下文范围可以用一个简单的公式表达：

未来，无论是一本百万字的书、一整天不间断的语音流，还是一整个大型代码库，AI 都可以用近乎恒定的资源去阅读。书签派保证当下的流畅，检索派保证远方的记忆，两条路正在共同通向真正的“无限上下文”。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""Simulate StreamingLLM and InfLLM attention selection."""import mathimport random  def softmax(scores):    m = max(scores)    exps = [math.exp(s - m) for s in scores]    total = sum(exps)    return [e / total for e in exps]  def attention(q, keys, values, indices):    scores = [sum(q[d] * keys[i][d] for d in range(len(q))) for i in indices]    weights = softmax(scores)    out = [0.0 for _ in range(len(q))]    for pos, i in enumerate(indices):        for d in range(len(q)):            out[d] += weights[pos] * values[i][d]    return out, indices  def full_attention(q, keys, values):    return attention(q, keys, values, list(range(len(keys))))  def streaming_attention(q, keys, values, window=4):    n = len(keys)    if n == 1:        return attention(q, keys, values, [0])    start = max(1, n - window)    indices = [0] + list(range(start, n))    return attention(q, keys, values, indices)  def infllm_attention(q, keys, values, window=4, block_size=2, top_k=2):    n = len(keys)    if n <= window + top_k * block_size:        return streaming_attention(q, keys, values, window)    start = max(1, n - window)    window_indices = list(range(start, n))    used = set(window_indices)    blocks = []    for b in range(0, start, block_size):        if b + block_size <= start:            score = sum(q[d] * keys[b][d] for d in range(len(q)))            blocks.append((score, b))    blocks.sort(reverse=True)    retrieved = []    for _, b in blocks[:top_k]:        for i in range(b, b + block_size):            if i not in used:                retrieved.append(i)                used.add(i)    indices = window_indices + retrieved    return attention(q, keys, values, indices)  if __name__ == "__main__":    random.seed(0)    n = 20    dim = 4    keys = [[random.random() for _ in range(dim)] for _ in range(n)]    values = [[random.random() for _ in range(dim)] for _ in range(n)]    q = [random.random() for _ in range(dim)]     _, full_idx = full_attention(q, keys, values)    _, stream_idx = streaming_attention(q, keys, values, window=4)    _, infllm_idx = infllm_attention(q, keys, values, window=4, block_size=2, top_k=2)     print("full attention tokens:", len(full_idx))    print("streaming tokens:", len(stream_idx))    print("infllm tokens:", len(infllm_idx))    print("streaming selected:", stream_idx)    print("infllm selected:", infllm_idx)

1. scores = [sum(q[d] * keys[i][d] for d in range(len(q))) for i in indices]计算当前查询与每个候选键的点积，作为相关分数。
2. weights = softmax(scores)把原始分数变成和为 1 的注意力权重，模拟“关注度分配”。
3. indices = [0] + list(range(start, n))这是 StreamingLLM 的核心：固定锚点 \(0\) 加上最近窗口。
4. blocks.sort(reverse=True)按块级相关分数排序，模拟图书管理员先看摘要再取书。
5. indices = window_indices + retrieved把当前窗口和检索到的远端块合并，作为 InfLLM 的注意力候选集合。
6. if n <= window + top_k * block_size:当序列本身足够短时，退化为 StreamingLLM，避免过度设计。

常见误区

面试题