Infinite-LLM: Efficient LLM Service for Long Context with DistAttention and Distributed KVCache

发表时间: 2024-01 · arXiv:2401.02669 (preprint)

原文: https://arxiv.org/abs/2401.02669

Bin Lin, Chen Zhang, Tao Peng, Hanyu Zhao, Wencong Xiao, Minmin Sun, Anmin Liu, Zhipeng Zhang, Lanbo Li, Xiafei Qiu, Shen Li, Zhigang Ji, Tao Xie, Yong Li, Wei Lin (Alibaba Group, Shanghai Jiao Tong University, Peking University)

速读

一句话结论
本文提出了 Infinite-LLM 推理服务系统，通过在集群级别解耦并分布式调度注意力计算与 KVCache，在 32 张 A100 GPU 上支持了高达 2000K tokens 的超长上下文，并实现了相比现有系统 1.35 到 3.4 倍的吞吐量提升。

要解决什么问题
大模型推理中请求上下文长度极具动态性（1 到 2000K tokens 不等），导致原有静态模型并行和资源分配策略遭遇严重卡点。该卡点源于模型内部计算特征的割裂：非注意力层张量大小固定，计算效率高度依赖批处理大小；而注意力层的 KVCache 显存需求随文本长度剧增，且不受批处理大小影响。传统部署为支持长文本必须给单实例分配大量 GPU。这带来两个致命问题：一是实例内模型并行效率低下，非注意力层被过度切分，处理短文本时通信开销剧增；二是跨实例资源管理失效，长文本请求迅速耗尽所在实例显存，迫使系统降低批处理大小，导致 GPU 计算利用率极低（甚至降至 1%）；同时处理短文本的实例虽有大量闲置显存，却无法被长文本借用。这种显存与计算资源在实例间的旱涝不均，锁死了集群吞吐量上限。

怎么做的
核心思路是将注意力层计算与 KVCache 从整体推理中解耦，打破单实例物理显存边界，将整个集群的 GPU 显存作为统一资源池进行细粒度调度。这让非注意力层保持高效局部并行，同时注意力层按需借用全局显存。方法由三个关键部件构成：第一，DistAttention（分布式注意力机制）。这是实现解耦的底层算子。传统分布式注意力若沿序列维度切分 KVCache，解码时需跨实例传输海量数据。DistAttention 通过数学等价变换，允许每个实例在本地局部 KVCache（长度为 $seq_p$）上计算局部最大值 $m_j$、指数和 $e_j$ 及局部注意力结果 $MA_j$：

$$m_j = max(QK_1, ..., QK_{seq_p}), \quad e_j = \sum_{i=1}^{seq_p} \exp(QK_i^T - m_j)$$

$$MA_j(Q, K, V) = \sum_{i=1}^{seq_p} (\exp(QK_i^T - m_j)V_i)$$
计算后，实例只需发送查询向量 Query 及 $m_j$、$e_j$ 两个浮点数，并在本地聚合其他实例的局部结果：
$$m_g = max(m_1, ..., m_b), \quad e_g = \sum_{j=1}^b e_j \exp(m_j - m_g)$$
$$\mathrm{Attention}(Q, K, V) = \sum_{j=1}^b \frac{MA_j \exp(m_j - m_g)}{e_g}$$
此设计将传输 GB 级 KVCache 转化为传输 KB 级 Query，绕开了带宽卡点。第二，基于性能模型的集群级调度算法。系统将显存不足需卸载 KVCache 的实例称为“债务人”，显存富余可借出空间的称为“债权人”。债务人将部分 KVCache 转移给债权人可腾出显存提高批处理大小。作者构建了量化批处理大小与吞吐量关系的性能模型，采用贪心算法周期性寻找最优 KVCache 搬运块数，最大化集群吞吐量。第三，gManager 与 rManager 分布式协调架构。全局控制器 gManager 维护 KVCache 分布视图并下发调度决策；实例上的 rManager 定期汇报状态。系统设计了带尝试机制的通信协议，目标实例可根据实时剩余显存拒绝或接受迁入，保证动态调度稳定性。

效果如何
实验在 4 个节点共 32 张 A100（80GB）GPU 的集群上进行，评测 LLaMA2 系列模型，测试数据涵盖 1 到 2000K tokens 的 9 种真实请求轨迹。对比基线为推理引擎 vLLM 的两条路线：代表多实例静态切分的 vLLM-multi（并行配置相同，但受限于单实例显存），以及代表单实例全局切分的 vLLM-single（将 32 张卡作为巨大实例以支持超长文本，但非注意力层被极度切分）。量化结果显示，面对不超过单实例上限的短文本混合请求，Infinite-LLM 相比 vLLM-multi 吞吐量提升 1.35 倍到 1.73 倍；面对长达 2000K tokens 的超长文本混合请求，相比 vLLM-single 吞吐量提升 1.4 倍到 3.4 倍。在 4K 到 256K 上下文范围内，DistAttention 运行速度比基于张量并行的方法快 1% 到 25%，比需传输大量 KVCache 的 RingAttention 路线快 7.7 倍到 19.8 倍。代价方面，跨实例搬运 KVCache 会带来通信开销。消融实验表明，若每次解码搬运 32 个 tokens，实例吞吐量下降 8.6%；但若将搬运粒度控制在每次 16 个 tokens，通信耗时可被计算时间完全掩盖，实现无损性能提升。

主要贡献

当前的大型语言模型（LLMs）主要采用自回归机制生成输出，这导致模型服务过程中的内存和计算资源需求高度动态化，且上下文长度无法预先确定。随着模型支持的上下文长度不断扩展（从数个 token 到 2000K tokens），注意力（Attention）层表现出高度的动态行为，其计算特性和内存需求与非注意力层产生了显著差异。现有的静态模型并行（如张量并行、流水线并行）和单实例资源分配策略在应对这种动态性时显得力不从心，主要面临两大挑战：一是实例内部模型并行效率低下，短请求遭遇过度切分；二是跨实例资源管理效率低下，难以同时饱和内存和计算利用率。

为了解决上述问题，本文提出了 Infinite-LLM，这是一个旨在高效处理动态上下文长度的新型 LLM 服务系统。该系统的核心创新点包括：
1. 揭示了 LLM 请求服务的动态特征，并指出了现有单实例内静态模型并行部署和 KVCache 调度的局限性。
2. 提出了 DistAttention，一种在数学上与原始注意力等价的新型注意力机制，能够以分布式的方式灵活地解耦注意力计算和 KVCache。
3. 设计并实现了 Infinite-LLM，通过在集群级别调度 KVCache 来平衡各实例间的资源需求。在 32 张 A100 GPU 组成的集群上，Infinite-LLM 能够支持高达 2000K tokens 的上下文长度，与最先进的方法相比，端到端吞吐量提升了 $1.35\times$ 到 $3.4\times$，实现了高效且弹性的 LLM 部署。

背景知识与关键观察

LLM 推理与并行方法。大型语言模型主要由 Transformer 架构主导，包含 QKV 线性层、多头注意力机制（Multi-Head Attention）和前馈神经网络（FFN）。推理服务具有自回归特性，分为使用 Prompt 生成首个 token 的 Prefill 阶段，以及迭代生成后续 token 直至遇到 EOS 的 Decode 阶段。由于上下文长度跨度极大（从 1 到 2000K tokens），通常部署多个模型副本（即数据并行）来扩展吞吐量。为了支持单设备内存无法容纳的大模型，必须使用模型并行技术，主要包括张量并行（Tensor-parallel，需要层内通信）和流水线并行（Pipeline-parallel，避免层内通信但引入层间通信）。

实例内不同长度任务的性能悖论。观察 1：配置更多 GPU 的实例能够支持长文本任务，但在普通文本任务上表现极差。如图 1(a) 所示，包含 32 张 GPU 的实例（DP1TP32）能支持 2000K 长度，但 1K 长度的吞吐量最低；而单 GPU 实例（DP32TP1）支持最大长度短，但短文本吞吐量最高。这源于注意力层和非注意力层在不同长度下的计算特征差异。如图 1(b) 所示，注意力层的张量大小随上下文长度稳定增长，需要更多内存和更高并行度；而非注意力层张量大小不变。传统静态切分策略不区分两者，导致非注意力层被过度切分，如图 1(c) 所示，在 8 卡实例上非注意力层的性能仅为单卡的约三分之一。
图1. 静态模型并行难以在所有上下文长度上保持效率

跨实例资源利用率不均。观察 2：处理长上下文任务时 GPU 计算利用率显著下降，而处理短上下文时显存利用率不足。如图 2(a) 所示，实例通常处于低计算或低内存利用率状态。图 2(b) 的分析表明，当上下文长度为 20 时，单卡可支持 1800 个请求，但这属于过度批处理（Over batching），与 batch size 为 800 相比计算利用率几乎无提升且显著增加延迟。在合理的 batch size（800）下，显存利用率仅为 $42\%$。当长度达到 20K 时，最大 batch size 降为 3，计算利用率降至极低水平。图 2(c) 揭示了非注意力层可通过增加 batch size 将 GEMV 转换为高效的 GEMM 操作以提升计算利用率，但系统被迫减小 batch size 以容纳注意力层不断增长的 KVCache，导致整体计算利用率下降。
图2. 集群中实例间的资源利用不足

方法细节

Infinite-LLM 系统概览。Infinite-LLM 的核心理念是将注意力计算和 KVCache 分布到 LLM 推理实例的边界之外，从而利用整个 GPU 集群的资源。如图 3 所示，这种设计将注意力层与非注意力层解耦，允许它们采用独立的并行策略和资源调度策略，并增强了集群级别 GPU 计算和内存资源的管理能力。系统通过三大创新实现目标：首先，引入 DistAttention 机制，将注意力计算细分到多个 GPU 上，同时避免解码时的 KVCache 传输；其次，利用 DistAttention 解决长短请求的资源争用，通过基于经验研究的贪心调度策略最大化集群吞吐量；最后，引入中心化控制器 gManager，托管调度策略并与分布式 rManagers 协同，通过新定义的协议管理动态的跨实例 KVCache 跟踪和迁移。
图3. Infinite-LLM 系统概览

分布式注意力机制的通信挑战。为了实现 KVCache 的动态灵活管理，提出了 DistAttention，该方法将注意力和 KVCache 细分为规则的小子块，允许注意力层在多个实例间高效分布计算。传统的注意力计算公式需要跨所有序列计算最大注意力分数 $m_g$ 并沿序列维度求和：
$m_g = max(QK_1, ..., QK_{seq})$
$Attention(Q, K, V) = \sum_{i=1}^{seq} \frac{\exp(QK_i^T - m_g)}{\sum_{j=1}^{seq} \exp(QK_j^T - m_g)} V_i$
如果直接将 KVCache 分布式存储，每次计算都需要将远程 KVCache 传回本地。如图 4(a) 所示，由于 KVCache 体积庞大，每次解码步骤需传输 GB 或 TB 级数据，严重影响分布式注意力计算性能。

DistAttention 的等价数学变换。受在线 softmax 启发，DistAttention 对原始注意力进行了等价数学变换，避免了跨所有序列执行 max 和 summation 操作。它允许每个实例在部分序列长度 $seq_p$ 的局部 KVCache 数据上执行操作。MicroAttention ($MA$) 定义为切分后的局部注意力计算，可分布在不同实例上：
$m_j = max(QK_1, ..., QK_{seq_p}), e_j = \sum_{i=1}^{seq_p} \exp(QK_i^T - m_j)$
$MA_j(Q, K, V) = \sum_{i=1}^{seq_p} (\exp(QK_i^T - m_j) V_i)$
通过这种方式，实例只需传输查询（Query）向量以及两个浮点值 $e_j$ 和 $m_j$。

结果聚合与通信开销降低。由 $b$ 个远程实例计算的中间结果随后传回本地实例进行聚合，以获得与原始注意力等价的结果：
$m_g = max(m_1, ..., m_b), e_g = \sum_{j=1}^{b} e_j \exp(m_j - m_g)$
$Attention(Q, K, V) = \sum_{j=1}^{b} \frac{MA_j \exp(m_j - m_g)}{e_g}$
如图 4(b) 所示，聚合操作的 FLOPs 不到总 MA 计算负载的 $1\%$，开销可忽略不计。由于 Query 往返仅涉及几 KB 数据，DistAttention 大幅降低了数据通信开销，如图 4(c) 的时间对比所示。
图4. DistAttention通过等价数学变换降低通信开销
图4b

子块级调度的优势。DistAttention 允许将单请求的 KVCache 任意子块调度到不同实例，这不仅突破了单实例容量限制，更在集群层面提供了极细粒度的调度灵活性。如图 5(a) 所示，初始状态下实例 A 处理饱和的长请求，实例 D 处理有剩余空间的长请求，B 和 C 处理短请求且空间充足。如果采用仅在内存耗尽时才被动卸载新块的策略（图 5(b)），实例 A 的 batch size 仍为 1，而实例 D 的新块会与本地短请求竞争，导致计算利用率低下。相反，主动调度策略（图 5(c)）在长请求超出容量前，主动将更多子块放置到空间充足的 B 和 C 上，释放了 A 和 D 的空间以处理更多短请求，平衡了各实例的 batch size，从而最大化整体集群吞吐量。
图5. 两种不同放置方法的效果

债务人（Debtors）实例的性能影响。借用内存的实例被称为债务人。债务人将部分 KVCache 卸载到债权人，主要收益是减少了生成 token 的时间，并释放空间以提高 batch size。然而，这也带来挑战。首先，债务人需收集债权人的 MA 结果，若债权人计算过多会导致债务人空闲等待。如图 6(a) 所示，调度策略需限制远程 KVCache 大小，使远程计算和传输完全被本地计算掩盖。其次，KVCache 传输耗时，如图 6(b) 所示，系统将传输与本地模型推理进行重叠优化。图 7(a) 证实，随着卸载的 KVCache 增多，债务人吞吐量大幅提升，直至达到系统计算极限。
图6. 通信重叠优化

债权人（Creditors）实例与整体集群吞吐量。借出内存的实例被称为债权人。由于需为债务人执行额外的局部注意力计算，债权人本地请求性能会受损。图 7(b) 显示，随着转移的 KVCache 增加，性能缓慢下降；当超出剩余空间导致本地 batch size 减小时，性能急剧下降。整体集群吞吐量是所有实例吞吐量之和。如图 7(c) 所示，随着 KVCache 转移，总吞吐量从约 6500 tokens/s 升至 8800 tokens/s，但转移过多 MA 块后会急剧下降。由于寻找最佳策略的搜索空间高达 $\frac{(N+1)^{\sum_{i=1}^M Y_i}}{\prod_{i=1}^M Y_i!}$（其中 $N$ 为债务人数，$M$ 为债权人数，$Y_i$ 为空闲块数），在运行时直接求解极不现实，因此必须依赖性能模型。
图7. 债务人与债权人性能微基准测试

单层与集群性能建模。对于单层 Transformer，计算负载 $W(\beta)$ 主要受 batch size $\beta$ 影响，实际 GPU 性能 $f(\beta)$ 与 $\beta$ 紧密相关；注意力层负载由序列长度 $S$ 决定，其性能 $g(S)$ 通常保持不变。单层时间模型为：
$T^{lyr}(\beta, S) = T^{natn}(\beta) + T^{atn}(S) = \frac{W(\beta)}{f(\beta)} + \sum_{r=1}^{\beta} \frac{S^r}{g(S)}$
针对债务人和债权人，模型扩展为：
$T_{dbt}^{lyr}(\beta', K^d) = T^{lyr} - \frac{K^d}{g(S)}, \quad T_{cdt}^{lyr}(\beta, K^c) = T^{lyr} + \frac{K^c}{g(S)}$
单实例吞吐量计算为 $TPS = \frac{\beta}{n \cdot T^{layer}}$，集群总吞吐量为所有实例之和 $TPS_{cluster} = \sum_{i=1}^{M} TPS_i$。图 7 验证了该性能预测模型与真实测量结果高度一致。

贪心调度算法设计。为了在运行时高效找出 KVCache 放置计划，提出了一种基于性能模型的贪心算法。核心原则是将过载的债务人实例与空闲的债权人配对，持续进行负载均衡。
具体步骤如下：
1. 收集 batch size 小于阈值 $\beta^{thres}$ 的实例作为债务人集合 $D$，并按 batch size 升序排序。
2. 收集内存利用率低于阈值 $U^{thres}$ 的实例作为债权人集合 $C$，并按利用率升序排序。
3. 遍历每个债务人 $D^i$，挑选其最长请求 $r$，并计算可卸载的最大 MA 块数 $Block_{max}$。
4. 遍历每个债权人 $C^j$，在 $0$ 到 $Block_{max}$ 范围内，利用性能模型评估转移 $k$ 个块带来的潜在吞吐量增益。
5. 挑选出能产生最大吞吐量的块数 $Block_{best}$。如果增益小于等于 0，则中断当前债权人循环。
6. 调用迁移函数移动 KVCache，更新债权人状态并重新排序，同时扣减 $Block_{max}$。该算法周期性执行以适应动态负载。

1: Collect debtors with small batch size D^i \in \{I^i, \beta^i \leq \beta^{thres}\}
2: Sort debtors in increased batch size order \langle I^i, \beta^i \rangle
3: Collect creditors with low memory util C^i \in \{I^i, U^i \leq U^{thres}\}
4: Sort creditors in increased memory util order \langle I^i, U^i \rangle
5: for D^i \in D do
6:     r = pick_longest_request(D^i)
7:     Block_{max} = get_block_num(r)
8:     for C^j \in C do
9:         for k \in range(0, Block_{max}) do
10:            \langle perf, k \rangle = perf_model_throughput_esti(k, D^i, C^j)
11:        end for
12:        Block_{best} = pick_max_perf(\langle perf, k \rangle)
13:        if Block_{best} <= 0 then
14:            break;
15:        end if
16:        move_kvcache(r, Block_{best}, C^j)
17:        update_and_sort_mem_util(C)
18:        Block_{max} -= Block_{best}
19:    end for
20: end for

gManager 与 rManager 架构。为实现全局规划，Infinite-LLM 引入中心化 gManager，维护全局请求放置映射表（Request Placement Map）。为降低跟踪快速变化的内存状态带来的开销，系统引入了与实例共存的分布式 rManagers。gManager 不强制实时同步，而是依赖 rManagers 定期的心跳信号来更新状态，随后计算状态转换计划并指示 rManagers 移动 KVCache。

分布式协同通信协议。图 8 展示了协议工作流。rManager 使用 heartbeat API 报告本地状态（包含 RequestPlacementEntry 结构，记录 req_id, inst_id, num_blocks 等）。gManager 更新映射表后，通过 move_kvcache API 指示源实例向目标实例移动数据。考虑到全局视图可能存在延迟（目标实例内存可能已被新生成的 KVCache 占满），源实例在传输真实数据前，必须调用 try_move_kvcache API 尝试在目标实例上预留空间。目标实例采用先到先得策略分配空间，若空间不足则返回拒绝信号。若被拒绝，源实例将等待 gManager 在未来轮次基于最新状态发出的新指令。
图8. Infinite-LLM 协议整体工作流

class RequestPlacementEntry:
    req_id:int, inst_id:int, num_blocks:int, local:bool
heartbeat(List[RequestPlacementEntry]) -> None
move_kvcache(req_id:int, num_blocks:int, dst_inst:int) -> None
try_move_kvcache(req_id:int, num_blocks:int) -> bool

实验环境

实验结果

1. 上下文长度性能测试
- 实验内容：在 6 种上下文长度范围和 3 种模型下，测试最大 batch size 的吞吐量。对比 1K 长度、vLLM-multi 极限长度及 Infinite-LLM 极限长度。
- 实验结果：如图 9 所示，Infinite-LLM 支持的上下文长度比受限于单实例内存的 vLLM-multi 长 $2\times - 19\times$，同时在短序列上保持相当的吞吐量。与 vLLM-single 相比，Infinite-LLM 在短长度上获得了 $1.4\times - 5.3\times$ 的吞吐量提升，且支持的最大长度相似。
- 分析结论：Infinite-LLM 成功兼顾了长短序列的优势。它避免了 vLLM-single 因过度切分导致非注意力层计算利用率低下的问题，同时突破了 vLLM-multi 的单实例内存瓶颈。
图9. 上下文长度性能

2. 端到端服务性能（对比多小实例 vLLM-M）
- 实验内容：使用 Trace 0-2（短序列）在不同请求速率下对比 Infinite-LLM 与 vLLM-multi 的吞吐量-延迟变化。
- 实验结果：如图 10a 所示，Infinite-LLM 相比 vLLM 获得了 $1.35\times - 1.73\times$ 的吞吐量提升。随着 Trace 长度分布方差的增大（长度分布更不均匀）以及实例数量的增加，性能增益更为显著。
- 分析结论：长度分布越不均匀、实例越多，实例间资源需求的差异就越大，Infinite-LLM 跨实例统一管理资源的优势就越明显。

3. 端到端服务性能（对比单大实例 vLLM-S）
- 实验内容：使用 Trace 3-8（长序列）对比 Infinite-LLM 与独占所有 GPU 的 vLLM-single。
- 实验结果：如图 10b 所示，Infinite-LLM 获得了 $1.4\times$ 到 $3.4\times$ 的吞吐量提升。随着上下文长度范围的扩大，性能增益持续增长。
- 分析结论：vLLM 的静态模型并行将模型碎片化到过多 GPU 上，严重降低了非注意力层的效率和处理短请求的能力；而 Infinite-LLM 为非注意力部分维持了合理的并行策略。
图10. 端到端服务性能

4. 分布式注意力机制微基准测试
- 实验内容：在 4K 到 256K 长度范围内（基于 LLaMA2-13B，4 GPUs），对比 DistAttention、RingAttention 和按头切分（TP）的延迟性能。
- 实验结果：如图 11 所示，DistAttention 比 TP 快 $1\% - 25\%$，比 RingAttention 快 $7.7\times - 19.8\times$。
- 分析结论：RingAttention 需要传输庞大的 KVCache（MB 到 GB 级），而 DistAttention 仅传输极小的 Query（KB 级），因此通信开销大幅降低。
图11. 分布式注意力方法对比

5. KVCache 移动开销测试
- 实验内容：评估 KVCache 跨实例移动的通信开销对吞吐量的影响（保持 batch size 不变以隔离通信成本）。
- 实验结果：如图 12(a) 所示，每次解码步骤移动 32 个 tokens 时，吞吐量下降 $8.6\%$；而移动 16 个 tokens 时，吞吐量与关闭移动时完全一致。
- 分析结论：合理设置移动块大小（如 16 tokens）可以使通信与计算完美重叠，从而在不影响实例性能的前提下实现全局调度。
图12. KVCache移动开销

结论

本文提出了 Infinite-LLM，一个专为管理 LLM 请求中高度动态的上下文长度而设计的新型服务系统。研究揭示了 LLM 请求的动态特性，并倡导将注意力计算解耦作为 LLM 服务的通用技术。通过引入既高效又可扩展的全新系统架构，以及旨在同时饱和 GPU 计算和带宽的调度策略，Infinite-LLM 在真实流量轨迹的广泛评估中展现了显著的性能提升（最高 $3.4\times$）。未来，期望 Infinite-LLM 能够成为学术界和工业界迈向 AGI 的通用基础设施，并激发 LLM 服务领域的进一步创新。

补充细节

LLM 推理系统相关工作。现有的推理系统在提升吞吐量方面做出了诸多贡献。ORCA 【55, Orca: A distributed serving system for Transformer-Based generative models+2022+OSDI】引入了迭代级调度以提升批处理利用率；vLLM 【26, Efficient memory management for large language model serving with pagedattention+2023+SOSP】提出了 PagedAttention 以解决内存碎片问题；DeepSpeed-FastGen 【2, Deepspeed-fastgen: High-throughput text generation for llms via mii and deepspeed-inference+2023+URL】提出了 Dynamic SplitFuse 策略；DistServe 【59, Distserve: Disaggregating prefill and decoding for goodput-optimized large language model serving+2024】提出将 prefill 和 decode 阶段解耦到不同实例。尽管这些系统解决了许多问题，但如何支持超长上下文及应对高度动态的请求长度仍是未解难题。

长上下文 LLM 相关工作。FlashAttention 【18, Flashattention: Fast and memory-efficient exact attention with ioawareness+2022+NeurIPS】和 FlashDecoding 【1, Flashdecoding+2021+URL】优化了单卡上的长序列注意力性能，但未解决多卡通信开销。序列级并行（Context parallelism）【13, Striped attention: Faster ring attention for causal transformers+2023】【27, Lightseq: Sequence level parallelism for distributed training of long context transformers+2023】【28, Sequence parallelism: Long sequence training from system perspective+2021】和 Ring Attention 【31, Blockwise parallel transformer for long context large models+2023】【32, Ring attention with blockwise transformers for near-infinite context+2023】被用于长序列训练，但由于每次推理迭代需跨设备传输庞大的 KVCache，不适用于推理的 Decode 阶段。另一类方法使用稀疏 KVCache，如 Sliding Window Attention 【12, Longformer: The long-document transformer+2020】【17, Generating long sequences with sparse transformers+2019】【24, Mistral 7b+2023】、H2O 【58, $H_2O$: Heavy-hitter oracle for efficient generative inference of large language models+2023】和 StreamingLLM 【54, Efficient streaming language models with attention sinks+2023】，但由于 KVCache 被驱逐，会带来精度损失。Infinite-LLM 通过 DistAttention 实现了无损精度的注意力解耦。

调度策略相关工作。为了优化吞吐量和延迟，Llumnix 【43, Llumnix: Dynamic scheduling for large language model serving+2024】和 Parrot 【30, Parrot: Efficient serving of llm-based applications with semantic variable+2024】等系统优化了跨实例的请求调度。然而，这些系统局限于将整个请求调度到单一实例上，面对动态请求长度时仍会导致 GPU 利用率低下。Infinite-LLM 能够将请求的任意子序列调度到不同实例上，其调度粒度更细，灵活性远超现有系统。