FASTDECODE: High-Throughput GPU-Efficient LLM Serving using Heterogeneous Pipelines

发表时间: 2024-03 · arXiv:2403.11421 (preprint)

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

作者/机构：Jiaao He (Tsinghua University), Jidong Zhai (Tsinghua University)

速读

一句话结论
本文提出了 FASTDECODE 系统，通过将大语言模型推理中的注意力计算与 KV-Cache 卸载到多台分布式 CPU 上进行近数据计算，从而在单 GPU 上支持超大批处理量，实现了高达 vLLM 5.04 倍的吞吐量。

要解决什么问题
大语言模型在解码阶段的效率极低，核心卡点在于显存墙限制了并行度。在自回归生成中，模型每次只生成一个 Token，全连接层的计算本质是矩阵乘向量，无法有效利用 GPU 庞大的计算单元。提高 GPU 利用率的唯一途径是增大批处理量，将其转化为矩阵乘矩阵。然而，生成新 Token 必须依赖历史生成的 KV-Cache，随着批处理量增大和序列变长，KV-Cache 的显存占用会迅速撑爆 GPU 显存。现有的卸载方案（如将 KV-Cache 放到主机内存）卡在 PCIe 带宽上：KV-Cache 并非冷数据，每次生成新 Token 都需要将完整的 KV-Cache 搬运到 GPU 参与注意力计算，庞大的数据传输开销使得系统不得不维持较小的批处理量，导致 GPU 算力依然被严重闲置。

怎么做的
作者的核心思路是将 Transformer 模型拆分为计算密集型和访存密集型两部分，并构建 CPU-GPU 异构流水线。方法内核由三个关键设计构成：
第一，模型拆分与近数据计算。模型被拆分为 S-Part（包含所有共享权重的全连接层，适合 GPU）和 R-Part（包含无参数、仅依赖 KV-Cache 的注意力计算，受限于访存）。系统将 R-Part 和 KV-Cache 彻底移出 GPU，交由多台远端 CPU 节点处理。GPU 仅计算 S-Part，生成查询、键、值向量后通过网络发给 CPU；CPU 在本地内存中直接完成注意力计算并返回输出向量。由于网络中只传输极小的激活向量而非海量的 KV-Cache，彻底绕开了带宽卡点，使得 GPU 能够毫无显存压力地将批处理量开到 1024 甚至更高。
第二，序列级负载均衡调度。在流水线中，GPU 处理 S-Part 的耗时仅与批处理量有关（固定值），而 CPU 处理 R-Part 的耗时会随序列变长而线性增加，这会导致流水线出现大量气泡。为此，系统采用固定步长 $F$ 间隔注入微批次的策略，让 CPU 同时处理不同长度的序列。若总批处理量为 $B$，序列目标长度为 $S$，该调度能将单步最大总序列长度从 $B S$ 压降至约一半：

$$W_{\mathrm{max}}^{\prime} \approx \frac{B S}{2}$$


这使得 CPU 的负载在整个生成周期内保持平稳，大幅减少了 GPU 的等待时间。
第三，性能模型驱动的硬件配置。为了防止 CPU 算力不足拖慢 GPU，系统通过微基准测试建立性能模型。给定批处理量 $\mathcal{B}$、序列长度 $S$、CPU 处理单个 Token 的耗时 $R$ 以及 GPU 计算 S-Part 的耗时 $\mathbb{T}(\mathcal{B})$，系统能直接算出恰好能喂饱 GPU 所需的最佳 CPU 数量 $\mathcal{P}$：

$$\mathcal{P} \approx \frac{\mathcal{B} S R}{2 \mathbb{T}(\mathcal{B})}$$
此外，为了弥补 CPU 缺乏高效神经网络库的短板，作者还在 CPU 侧手写了基于 AVX-2 指令集的混合精度注意力算子，进一步榨干了 CPU 的内存带宽。

效果如何
实验在 1 张 NVIDIA A10 GPU 和最多 4 台双路 AMD Epyc CPU 节点上搭建，测试了 Llama-7b、Llama-13b 和 Opt-175b 模型（生成 1024 长度序列）。对比基线点名了代表显存分页与交换路线的 vLLM、代表极致 GPU 算子优化的 TensorRT-LLM、代表 C++ 高效部署的 FastLLM 以及 Vanilla PyTorch。在追求最大吞吐量的设置下（批处理量 1024），FASTDECODE 在 7b 模型上达到了 vLLM 的 4 倍、TensorRT-LLM 的 8.7 倍；在 13b 模型上达到了 vLLM 的 5.04 倍。即使为了控制延迟将批处理量降至 128，吞吐量依然是 vLLM 的 1.88 倍到 2.32 倍。代价与局限在于：极致的吞吐量是用单步延迟换来的，当批处理量拉满时，单步延迟会增加约 3.5 倍；分布式架构引入了网络开销，传输激活向量占用了约 25% 的单步延迟时间；且该方案必须额外调用多台 CPU 服务器才能喂饱单张 GPU，存在额外的硬件成本。

主要贡献

大型语言模型（LLM）的推理服务成本高昂。由于生成Token的自回归特性，模型需要逐个生成Token，导致昂贵且稀缺的GPU在顺序生成时利用率极低。虽然扩大批处理大小（Batch Size）是提升GPU利用率的有效途径，但批处理大小受到不断累积的中间结果（即KV-Cache）的内存占用限制。如图1所示，随着批处理大小和序列长度的增加，KV-Cache的内存占用远超GPU显存容量。如果将KV-Cache卸载到主机内存（Host Memory），CPU与GPU之间的PCIe带宽又会成为不可避免的瓶颈。

图1：KV-cache的内存占用阻碍了通过扩大批处理大小来提高GPU利用率
图1：KV-cache的内存占用阻碍了通过扩大批处理大小来提高GPU利用率

为了解决这一困境，本文提出了一种新颖的系统 FASTDECODE。研究目标是通过将Transformer模型分解为具有不同特征的两个部分，利用多节点CPU的聚合内存容量、带宽和计算能力来处理包含KV-Cache的受限部分，从而释放GPU资源以高吞吐量处理模型的另一部分。如图2所示，典型CPU和GPU的性能特征恰好与模型两部分的需求相匹配。

图2：典型GPU和CPU的性能特征，与模型两部分的需求相匹配
图2：典型GPU和CPU的性能特征，与模型两部分的需求相匹配

本文的核心创新点如下：
1. 发现了一种非常规的Transformer模型分解方法，将受限于内存带宽的KV-Cache访问部分与计算密集型部分解耦，具有极大的性能提升潜力。
2. 提出了一种基于KV-Cache的近数据处理（Near-memory processing）系统，利用机箱外分布式CPU的聚合内存带宽来提高吞吐量，通过仅传输极小的激活张量来降低数据传输开销。
3. 发明了一种序列级负载稳定调度算法（Sequence-level load-stabilizing schedule），解决了LLM生成过程中随时间增长的计算负载与固定负载之间的异构不平衡问题。
4. 建立了一个性能模型，能够针对不同的模型和需求，为该系统提供最优的硬件配置指导。

背景知识与关键Observation

Transformer模型与KV-Cache
自回归模型基于Transformer结构【28，Attention is all you need+2017+NeurIPS】。其核心模块是注意力层。假设序列中第$i$个Token的特征向量为$X_i$。首先，$X_i$被映射到三个不同的线性空间，由三个全连接层实现：
$Q_i = W_q X_i$
$K_i = W_k X_i$
$V_i = W_v X_i$
对于第$i$个Token，其特征向量与之前所有Token的$K_j$进行内积计算，生成注意力向量：
$A_i = \operatorname{Normalize}\{Q_i \cdot K_j (j=1,\ldots,i-1)\}$
注意力向量经过Softmax归一化后，作为权重对之前所有Token的$V_j$进行加权求和：
$O_i = \sum_{j=1}^{i-1} A_{ij} V_j$
最后，输出经过另一个全连接层进行最终的线性变换：
$Y_i = W_o O_i$
在实际文本生成任务中，Token是逐个生成的。为了获取下一个Token，由于全连接层和MLP独立处理每个Token，因此只需处理最新的Token。但是，注意力层的计算涉及最新Token与之前所有Token的交互。为了避免重复计算，$K_j$和$V_j$可以被保存在内存中供新生成的Token复用，这就是KV-Cache【23，Efficiently scaling transformer inference+2023+MLSys】。对于长度为$s$的序列，KV-Cache将特征向量间的内积计算量从$O(S^3)$降低到$O(S^2)$。

加速解码的挑战
使用GPU生成单一序列效率极低，因为解码阶段的主要计算任务是将全连接层应用于一个特征向量，即矩阵向量乘法（GeMV）。GeMV难以复用近处理器内存中的矩阵数据，受限于全局内存访问，导致GPU的浮点运算单元未被充分利用。扩大批处理大小是最可行的方法，它将GeMV转化为高度优化的矩阵乘法（GeMM）。Orca【30，Orca: A distributed serving system for transformer-based generative models+2022+OSDI】提出了细粒度的Token级批处理，但引入了内存碎片。vLLM【14，Efficient memory management for large language model serving with pagedattention+2023+SOSP】采用Paged Attention解决内存碎片并管理KV-Cache，但由于通过PCIe在GPU和主机内存间频繁交换庞大的KV-Cache开销极高，vLLM不得不降低交换频率，导致批处理大小依然受限。FlexGen【24，Flexgen: High-throughput generative inference of large language models with a single GPU+2023+ICML】研究了权重和KV-Cache的最佳卸载顺序，但通过较慢的PCIe传输庞大数据本质上仍效率低下。

内存受限工作负载适合CPU
尽管CPU的浮点计算吞吐量远不及GPU上的专用张量处理单元，但在内存访问带宽方面，CPU和GPU的差距较小。现代服务器级CPU可达到数百GB/s的带宽，中端GPU（如NVIDIA A10）的内存带宽仅为CPU的几倍。此外，CPU成本更低，通过添加标准DIMM即可轻松扩展内存容量和带宽。在执行以内存访问为主的工作负载时，硬件的实际功耗通常远低于TDP，因此CPU在处理内存受限任务时是一个极具吸引力的高效选项。

性能困境与模型分解
如图3所示，Transformer块中全连接层的吞吐量随批处理大小增加而显著提升。然而，注意力操作在扩大批处理大小时收益甚微，因为每个序列有不同的$K$和$V$，计算仍是受限于内存的批量GeMV。更糟的是，KV-Cache的大小与批处理大小成正比，导致显存迅速耗尽。

图3：自回归生成中的性能困境
图3：自回归生成中的性能困境

为此，我们将生成Token的计算工作负载分为两部分：
* R-Part（自回归部分）：涉及序列中之前Token的自回归计算。每个序列使用自己的KV-Cache独立处理。扩大批处理大小几乎没有收益，但会带来巨大的内存占用。值得注意的是，R-Part不涉及任何模型参数。
* S-Part（共享部分）：模型中序列共享相同参数的其余部分。主要由全连接层组成。通过将更多序列中的Token进行批处理，可以显著提高GPU利用率。

CPU在LLM中可承担更多工作
基于上述分解，由于R-Part本质上是内存受限的工作负载，使用GPU相比CPU几乎没有优势。因此，关键洞察是：不仅应将KV-Cache存储在CPU内存中，还应该用CPU处理它们。换句话说，R-Part应该在靠近数据（KV-Cache）的地方处理。这样，KV-Cache被彻底从GPU内存中移除，批处理大小可以扩大到1024或更多，从而充分利用S-Part的计算能力。
对于可能存在的担忧：
1. CPU速度是否足够匹配GPU？测试表明，在使用7B模型时，由于总硬件内存带宽相似，R-Part在GPU或CPU上的延迟几乎相同。而S-Part在GPU上将批处理扩大1024倍时，延迟仅增加约5倍，带来了百倍的吞吐量提升潜力。
2. 跨设备传输中间数据是否缓慢？与现有系统传输庞大模型或KV-Cache不同，本方法仅传输中间向量（$Q_i, K_i, V_i, O_i$）。这些向量比KV-Cache小几个数量级。即使是1024个序列的大批处理，通过网络传输这些向量的预估延迟也仅为几毫秒，通信开销极小。

方法细节

系统架构概述
由于单台配备GPU的服务器上的本地CPU可能过于繁忙且速度不够，FASTDECODE利用了机箱外（out-of-chassis）CPU的聚合计算能力。如图4所示，系统包含两类Worker：
* S-worker：负责计算LLM的S-Part。它使用一个或多个GPU，拥有模型的所有权重（可通过模型并行划分）。S-worker表现得像一个仅使用GPU的常规Token生成节点，区别在于它采用极大的Batch Size，并且不计算R-Part。在生成新Token时，前馈层产生$Q_i, K_i, V_i$后，S-worker不将其存入本地KV-Cache，而是将它们按序列发送给相应的R-workers，并从R-workers取回输出$O_i$，接着将$O_i$输入到S-Part的后续层。因为排除了KV-Cache，S-worker的GPU内存仅需存放模型权重和当前层的小块暂存区，批处理大小理论上可达数百万。
* R-workers：使用远程节点上的CPU计算R-Part。因为R-Part不涉及模型参数，这些Worker非常轻量。其功能是接收一批Token的$Q_i, K_i, V_i$，将$K_i$和$V_i$追加到本地KV-Cache中，然后利用$Q_i$与本地KV-Cache执行注意力计算，最后将结果返回。

图4：FASTDECODE的Worker架构
图4：FASTDECODE的Worker架构

在生成Token时，S-worker和R-workers交替工作，形成一个基础的Token级两阶段流水线。如图5(b)所示，S-worker将请求分为两个微批次（Mini-batches A和B）。当S-worker处理微批次B的S-Part时，R-workers同时处理微批次A的R-Part。然而，由于工作负载异构，这种基础流水线必然存在气泡（图5(c)）。

图5：FASTDECODE的时间视图
图5：FASTDECODE的时间视图

序列级负载稳定调度
基础两阶段流水线中存在大量气泡，因为R-Part和S-Part的工作负载随生成序列长度的变化规律不同。S-Part的延迟仅与批处理大小相关（计算量固定），而R-Part的延迟与处理序列的总长度相关（新Token需与所有历史Token交互）。如图6所示，当处理一批序列时，随着序列变长，R-Part的延迟不断增加，导致整体延迟被较慢的一方主导，GPU或CPU会出现大量空闲。

图6：工作负载异构导致的硬件空闲
图6：工作负载异构导致的硬件空闲

为了解决R-Part延迟波动大的问题，系统采用了序列级负载稳定调度。如图7所示，系统不再将一大批序列同时启动，而是以固定的间隔（$F$步）启动较小的微批次。由于生成目标长度为$s$的序列需要$s$步，因此在任何时刻，都有多个处于不同生成阶段（不同长度）的微批次在同时被处理。这些微批次的S-Part被合并成一个大Batch在GPU上执行，从而保持GPU的高利用率。

图7：序列级负载稳定调度
图7：序列级负载稳定调度

具体而言，假设原有$B$个长度为$S$的序列。如果同时启动，最后一步的总序列长度将达到峰值$W_{max} = BS$。在我们的调度中，微批次的大小定义为 $M = \frac{BF}{S}$。在生成微批次的最后一步，最大总序列长度变为：
$W_{max}' = \sum_{k=1}^{S/F} M k F = \frac{B(S+F)}{2} \approx \frac{BS}{2} = \frac{W_{max}}{2}$
这表明最大总长度减少了约50%。经过冷启动后，流水线中总会混合存在不同长度的序列，使得总工作负载稳定在$W_{max}'$附近。这不仅降低了最大延迟，提高了整体吞吐量，还将在线服务中新请求的等待时间从最多$s$步大幅缩短到$F$步。
该调度逻辑被泛化为动态负载控制算法（Algorithm 1）。给定最大负载限制$W_{lim}$，系统通过计算当前正在处理的微批次的剩余生命周期和负载，推导出下一个微批次的最早允许启动步数。

# Algorithm 1 Load-control Algorithm
Require: M: array of batch sizes of all current micro-batches
Require: E: ending step index of all current micro-batches
Require: W: array of workload
Require: t: starting step index of the micro-batch
Require: m: size of the micro-batch

function ADDMICROBATCH
    M.append(m)
    E.append(t + S)
    W.append(m * S)
    for all i in current micro-batches do
        W[i] = W[i] + (E[i] - t) * m
    end for
end function

function GETEARILIESTSTEP
    r = t
    for all i in current micro-batches do
        x = floor((W_lim - W[i]) / m)  # Maximum allowed length
        r = max(r, E[i] - x + 1)
    end for
    return r
end function

负载均衡的硬件选择
为了最佳地利用GPU和CPU，除了稳定负载，还需要定量确定系统的两个核心参数：批处理大小$\mathcal{B}$和CPU数量$\mathcal{P}$。
首先通过微基准测试测量给定模型在GPU上计算S-Part的吞吐量，得到延迟函数$\mathbb{T}(\mathcal{B})$。假设流水线效率完美，生成具有$N$层的模型的一个Token的延迟约束为：
$2 N S \cdot \mathbb{T}(\mathcal{B}) \leq L$
其中$L$为用户期望的序列生成延迟。系统会选择满足该约束的最大可能$\mathcal{B}$。若无$L$约束，则根据GPU整体吞吐量 $\mathbb{E}(\mathcal{B}) = \frac{\mathcal{B}}{\mathbb{T}(\mathcal{B})}$ 进行选择，选取使$\mathbb{E}(\mathcal{B})$边际收益变小的点。
确定$\mathcal{B}$后，需通过另一个微基准测试获取CPU处理单个Token R-Part的延迟$R$。为了使CPU计算R-Part的时间与S-Part的时间近似相等，建立约束：
$\frac{\mathcal{B} S}{2 \mathcal{P}} R \approx \mathbb{T}(\mathcal{B})$
由此得出最优CPU数量的近似公式：
$\mathcal{P} \approx \frac{\mathcal{B} S R}{2 \mathbb{T}(\mathcal{B})} = \frac{1}{2} S R \mathbb{E}(\mathcal{B})$
此外，S-Part的工作负载与模型特征维度$h^2$成正比，而R-Part的每Token工作负载与$h$成正比，因此$\mathcal{P}$大约与$\frac{1}{h}$成正比。这意味着对于特征维度更大的大型模型，所需的最优CPU数量往往更少。

混合精度CPU注意力机制
R-worker的性能对系统整体吞吐量至关重要。S-worker使用PyTorch实现，而R-worker作为轻量级服务使用C++实现。由于当前LLM大多使用16位浮点数（fp16），而大多数现成的CPU神经网络库不支持fp16。如果使用fp32库，内存访问量会翻倍，导致延迟翻倍。为此，系统开发了一个混合精度注意力算子，从内存读取fp16数据，在寄存器中转换为fp32进行计算。通过利用AVX-2指令集中的内联函数，系统能够在一个指令中完成向量化的fp16到fp32转换（为保证更广泛的CPU兼容性，未使用AVX-512指令集）。

支持量化
系统支持模型量化以进一步提升性能。用户可以提供自定义函数，在接收到fp16的$Q_i, K_i, V_i$后，按照量化算法的要求对$K_i$和$V_i$进行量化并存入KV-Cache。如果使用4位整数存储$K$和$V$，内存访问量将减少到四分之一，从而带来约4倍的速度提升，或者节省4倍的CPU资源。

模型并行支持
对于显存无法容纳的超大模型，FASTDECODE天然支持模型并行。
* 流水线并行（层间并行）：不同的Transformer块由不同的S-worker处理，因此与每个Worker相关的R-Part完全独立。
* 张量并行（层内并行）：R-Part前后的全连接层通常按注意力头（Attention Heads）进行划分【20，Efficient large-scale language model training on GPU clusters using megatron-lm+2021+SC】。因此，每组R-workers只需为不同的注意力头维护独立的KV-Cache。
在这两种并行模式下，S-Part和R-Part的工作负载被相同的因子划分，因此配合每个S-worker所需的R-worker数量保持不变，系统延迟直接受益于并行带来的计算减少。

实验环境

  • 数据集与任务：采用文本生成任务，基于短提示词生成Token，所有测试中生成序列的总长度设定为1024。
  • 模型架构：选用开源模型 Llama-7b、Llama-13b 和 Opt-175b。数据格式采用fp16，未使用量化或剪枝。为降低评估成本，实验中减少了模型的层数。由于层数与整体延迟呈强线性关系（如图8证实），且各系统未在层维度进行特殊优化，因此按比例折算后不影响比较的公平性。
  • 硬件配置：S-worker节点配备1块NVIDIA A10 GPU（24GB显存）和256GB主机内存（用作vLLM的交换空间）。R-workers使用最多4个节点，每个节点配备双路AMD Epyc CPU。集群通过Infiniband网络连接。
  • 软件配置与基线：S-worker基于PyTorch实现，R-worker基于C++实现。基线系统均仅在GPU节点运行（因现有系统无法利用机箱外CPU），包括：vLLM（采用Paged Attention）、TensorRT-LLM（NVIDIA最新优化系统）、FastLLM（纯C++高度优化实现）、Vanilla（PyTorch原生实现）。
图8：FASTDECODE服务Opt-175b的延迟
图8：FASTDECODE服务Opt-175b的延迟

实验结果

1. 最大吞吐量评估
实验内容：测量各系统在生成任务中的最大吞吐量（Tokens/s）。
结果与分析：如图9所示，由于FASTDECODE将KV-Cache剥离到分布式的庞大主机内存中，其批处理大小可达数千。在Llama-7b模型上，FASTDECODE（Batch Size=1024）的最大吞吐量超过2200 tokens/s，是vLLM的4倍，TensorRT-LLM的8.7倍。在Llama-13b模型上，最大吞吐量是vLLM的4.12倍。即使出于延迟考虑将Batch Size降至128，FASTDECODE仍能达到vLLM吞吐量的1.88倍至2.32倍。vLLM在序列较短时能维持大Batch，但随序列变长，KV-Cache交换开销使其Batch Size受限；其他GPU-only系统受限于显存，Batch Size几乎无法超过16。

图9：Token生成吞吐量
图9：Token生成吞吐量

2. Token生成延迟评估
实验内容：测量生成新Token的平均延迟以及P0.01/P0.50/P0.99延迟分布。
结果与分析：如图10所示，TensorRT-LLM实现了最低的绝对延迟。当FASTDECODE采用128的Batch Size时，7b和13b模型的平均延迟分别为120.8ms和191.6ms。这意味着FASTDECODE以至多2.5倍的延迟代价，换取了4.5倍的吞吐量提升。vLLM虽然在大多数步骤中延迟较低，但由于其KV-Cache在主机和GPU间交换的步骤极其缓慢，导致其平均延迟高于所有FASTDECODE的设置。

图10：Token生成延迟
图10：Token生成延迟

3. 应对异构性的效果分析（序列级负载稳定调度）
实验内容：追踪生成过程中每一步的延迟变化，对比有无序列级负载稳定调度（SLS）的差异。
结果与分析：如图11所示，Vanilla实现的延迟随R-Part负载（序列长度）线性增长。FASTDECODE在无SLS时，当序列长度超过某一点后，R-Part延迟主导整体延迟，导致延迟急剧上升。引入SLS后，经过初期的冷启动，延迟稳定在无SLS最大延迟的66%-70%，且可持续吞吐量提升了8%-11%。当缩短目标序列长度至768时（图12），S-Part和R-Part的负载更加平衡，SLS带来的吞吐量提升增加到13%。

图11：每步的延迟
图12：减少序列长度的Llama-7b模型每步延迟

4. 系统的可扩展性
实验内容：测试R-worker数量扩展时的强可扩展性，以及增加S-worker时的扩展能力。
结果与分析：如图13所示，当序列长度为1024时，从1个Socket扩展到8个Socket，7b和13b模型分别实现了72.8%和84.1%的扩展效率。当序列长度缩短至128时，13b模型的效率降至37.6%，这是因为短序列需要的R-worker较少，此时S-worker成为瓶颈，增加R-worker不再提升性能，这与理论性能模型一致。对于特征维度更大的Opt-175b模型（图14），当同时翻倍R-worker和S-worker（采用模型并行）时，系统实现了1.84倍的吞吐量提升。

图13：FASTDECODE的强可扩展性
图14：在FASTDECODE中使用更多Worker

5. 延迟分解分析
实验内容：详细追踪13b模型在一次迭代（43ms）中各Worker的操作耗时分布。
结果与分析：如图15所示，R-workers在超过75%的时间内忙于计算。将QKV数据从GPU拷贝到CPU耗时3ms，通过网络发送QKV耗时7.4ms。FASTDECODE的分布式设计仅引入了约25%的特征向量传输开销（在生产环境中可被异步通信部分重叠）。S-worker的实际工作时间不到50%，但由于批处理大小极大，S-Part的计算效率得到显著提升，整体吞吐量依然极具竞争力。

图15：13b模型中两层的延迟
图15：13b模型中两层的延迟

结论

本文提出了 FASTDECODE，一个能够使用有限的GPU资源实现高吞吐量LLM Token生成的系统。与完全依赖GPU进行计算的传统解决方案不同，系统将模型拆分为两部分，并将受限于内存带宽的KV-Cache的存储和计算全部转移到机箱外的分布式CPU上，充分利用了CPU的聚合计算能力和内存带宽。通过引入序列级负载稳定调度和性能预测模型，系统成功克服了工作负载随时间动态变化以及硬件异构性带来的性能挑战。最终，得益于GPU端批处理大小的极大扩展，GPU得到了更充分的利用，系统在保证可接受延迟的同时，实现了极具竞争力的整体吞吐量。

补充细节（相关工作）

优化注意力算子
在LLM训练中，FlashAttention【5，Flashattention-2: Faster attention with better parallelism and work partitioning+2023+CoRR】【6，Flashattention: Fast and memoryefficient exact attention with io-awareness+2022+NeurIPS】通过消除存储消耗内存的中间矩阵$A$来提升性能。这一思想被FlashDecoding【9，Flashdecoding++: Faster large language model inference on gpus+2023+CoRR】移植到Token生成场景中。窗口注意力机制（Window attention）【1，Longformer: The long-document transformer+2020+CoRR】及其在StreamingLLM【29，Efficient streaming language models with attention sinks+2023+CoRR】中的扩展，通过减少新Token需要交互的历史Token数量来降低R-Part的工作负载。量化【2，7，17】和剪枝【13，25】技术同样可以减轻R-Part的负载。推测性生成（Speculative token generation）【19，Specinfer: Accelerating generative LLM serving with speculative inference and token tree verification+2023+CoRR】则是目前唯一通过准确预测Token来实质性提高注意力操作效率的方法。这些技术均可移植到CPU上以进一步加速FASTDECODE的计算。

分布式与异构LLM服务
典型的模型划分系统【11，15，33】几乎无法处理硬件和模型工作负载双重异构的Token生成场景。除了将KV-Cache卸载到主机内存【10，12，14，24】或对等GPU【16】之外，FPGA【4，31】可能是存储和处理KV-Cache的更好选择。本文的思想可以泛化为：利用异构硬件处理LLM的不同部分以提高整体效率。除了CPU，内存密集型部分的潜在硬件选择还包括廉价GPU、FPGA、领域专用芯片，或者通过CXL【8，Direct access, high-performance memory disaggregation with directcxl+2022+USENIX ATC】直接连接到GPU的内存池。在众多可能性中，本文释放CPU算力处理R-Part的方法，是目前利用现有高可及性硬件最直接可行的方案。