FlowPrefill：突破LLM推理瓶颈，算子级抢占实现5.6倍吞吐提升与严格SLO保障

关键词： LLM 服务系统 、预填充、 队头阻塞 、 _ SLO 感知调度_ 、 算子级抢占 、事件驱动调度

当我们正在使用一个智能聊天机器人，输入了一个简短的问题，满怀期待地等待回复。然而， 由于服务器正在处理一个长篇文档总结任务，请求被堵在后面，迟迟得不到响应，眼睁睁看着“正在输入”的提示转个不停 。这种体验像极了早高峰堵车——一辆大货车慢悠悠地走在前面，后面的小车只能干着急。

在大型语言模型（LLM）的服务系统中，这种现象被称为 头阻塞（Head-of-Line blocking，HoL） 。它发生在模型推理的 预填充阶段（prefill phase） ，即模型处理用户输入提示（prompt）的阶段。

图 1 | QwenTrace 中不同任务类型的请求长度分布与到达模式。本文探索了为具有多样化 SLO 保障的请求进行调度的可行性。该图直观呈现了聊天机器人、图像理解、网页搜索和摘要生成四类任务的请求特征差异，短输入高优先级的聊天任务与长输入宽松 SLO 的摘要任务并存，这种异质性加剧了预填充阶段的队首阻塞问题，凸显了灵活调度机制的必要性。

长提示的预填充计算量大，会长时间占用 GPU 资源，导致后续到达的短请求被阻塞，进而违反 首 Token 时间（Time-to-First-Token，TTFT） 的服务水平目标（SLO）。

现有的一些解决方案，比如分块预填充（chunked prefill），将长提示切成小块执行，允许在块间插入其他请求。 但这引入了一个根本性的权衡：

• 块越小，响应越快，但计算效率越低（因为内核启动开销和冗余内存访问增加）；
• 块越大，吞吐量越高，但阻塞延迟也越长。

这就好比在堵车时， _ 我们不可能把大货车拆成小块通过，但完全不让它走也不行。_

图 2 | 不同预填充粒度对首 token 延迟（TTFT）服务等级目标（SLO）的满足情况。(a) 分块预填充；(b) 分层预填充；(c) 本文方法。对比可见，分块和分层预填充均存在 SLO 违约问题，前者因块边界限制导致高优先级请求阻塞，后者受层执行时长约束，而本文方法通过算子级抢占实现精准响应，成功让高优先级请求 B 满足 SLO，破解了粒度与效率的矛盾。

那么，有没有一种方法既能保持高吞吐，又能实现细粒度抢占，让高优先级请求“插队”而不影响整体效率？

这正是本文要介绍的 FlowPrefill 系统所解决的核心问题。它通过将 抢占粒度 与 调度频率 解耦，实现了近乎无阻塞的预填充调度。

图 5 | FlowPrefill 的整体架构。架构核心包含代理、预填充实例和解码实例，预填充实例内置请求队列、执行池和调度器三大模块，通过事件驱动调度与算子级抢占的协同，实现高优先级请求的及时响应，同时借助 S-EDF 策略和 SLO 感知批处理最大化系统有效吞吐量。

一、背景：LLM 推理的两阶段与 PD 分离

1.1 Transformer 的推理流程

现代 LLM 大多基于 Transformer 架构，推理过程分为两个阶段：

1. 预填充阶段 ：输入整个提示序列（例如用户的问题），并行计算所有 token 的注意力，生成第一个输出 token，并初始化键值缓存（KV cache）。这个阶段主要执行矩阵-矩阵乘法（GEMM），计算密集，属于 计算密集型 。
2. 解码阶段 ：自回归地逐个生成后续 token。每步只输入一个 token，执行矩阵-向量乘法（GEMV），需要反复从高带宽内存（HBM）加载模型权重，属于 内存密集型 。

这两个阶段对资源的需求截然不同。预填充需要强大的算力，解码则受限于内存带宽。如果将它们混合在同一 GPU 上执行，预填充的突发计算会干扰解码的延迟敏感任务。

1.2 预填充-解码分离（PD Disaggregation）

为了解决上述干扰，现代系统采用 PD 分离架构，将预填充和解码部署在不同的 GPU 实例上。

这样，解码实例可以稳定地提供低延迟，预填充实例则专注于处理输入。 然而，PD 分离并没有消除预填充阶段内部的头阻塞问题—— 事实上，它把竞争全部集中到了预填充实例上 。一个长上下文请求可能独占 GPU 数百毫秒，后续的高优先级短请求只能排队等待，导致 TTFT SLO 违例。

二、动机：现有方法的局限

2.1 抢占粒度 vs. 效率的权衡

为了缓解头阻塞，现有系统通常采用固定粒度的抢占策略：

• 分块预填充 ：将长输入切分成固定大小的块（如 2K tokens），每块执行完后检查是否可以调度新请求。
• 分层预填充 ：利用 Transformer 层的自然边界作为抢占点，每层执行完后检查。

然而，作者通过实验揭示了这些方法的内在矛盾。图 3 展示了在 Llama3-8B 模型上处理 32K token 输入时，不同块大小对吞吐量和延迟的影响。

图 3 | 服务 Llama3-8B 模型时，32K token 输入在不同分块大小下的分块预填充吞吐量与延迟。每个条形内的交替颜色代表单个分块。实验结果清晰展现了分块大小的权衡困境：小块虽提升响应性但因内核启动开销和 KV 缓存冗余访问导致吞吐量骤降，大块虽恢复吞吐量却加剧阻塞，这为本文提出算子级抢占提供了现实依据。

观察可知，块越小，延迟越低，但吞吐量急剧下降。这是因为小块导致内核启动次数增加、KV 缓存重复加载，设备利用率下降。而块越大，吞吐越高，但单个块的执行时间过长，阻塞无法避免。这就是所谓的“吞吐-延迟权衡”。

更进一步，分层预填充虽然避免了内存开销，但将调度频率与层数耦合。
* 如果每层都做调度检查，开销巨大；
* 而如果间隔多层才检查，又可能错过及时的抢占机会。图 12 显示，分层抢占的平均阻塞时间可达十几毫秒，而算子级抢占能将其降至 4.5ms 以下。

图 12 | 算子级与分层级抢占边界下的平均抢占阻塞时间。不同抢占粒度通过在不同执行边界设置抢占检查实现。数据显示，算子级抢占将平均阻塞时间降低 3.5-4.2 倍，所有模型下均控制在 4.5 毫秒内，这种近无阻塞的性能表现，使得高优先级请求能快速获得资源，大幅缓解了预填充阶段的队首阻塞问题。

Takeaway 1： 固定粒度的执行单元在效率和响应性之间无法两全，需要一种自适应的、不依赖固定切分的抢占机制。

2.2 批处理中的请求不对称性

批处理（batching）也影响着不同长度请求的表现。图 4 展示了在预填充阶段，不同输入长度下吞吐量和 TTFT 随批大小的变化。

图 4 | 服务 Llama3-8B 模型时，不同输入长度在预填充阶段的吞吐量与归一化首 token 延迟（TTFT）。(a) 吞吐量；(b) 归一化 TTFT。

上图揭示了批处理对不同长度请求的异质影响：
* 对于短请求（32-256 token），单个请求无法充分利用 GPU 并行性，批处理能显著提高吞吐，且延迟增长平缓。
* 对于长请求（如 2K 以上），单个请求已接近饱和 GPU，批处理带来的吞吐增益微乎其微，但延迟却线性增加，极易导致 SLO 违例。

Takeaway 2： 短请求需要批处理来提高效率，而长请求应避免过度批处理，以免无谓地增加延迟。

三、FlowPrefill 核心设计

FlowPrefill 是一个以有效吞吐（goodput）为优化目标的 LLM 服务系统，它通过两个关键创新来解决上述问题：算子级抢占（Operator-Level Preemption） 和 事件驱动调度（Event-Driven Scheduling） 。图 5 展示了系统的整体架构。

图 5 | FlowPrefill 的整体架构。架构核心包含代理、预填充实例和解码实例，预填充实例内置请求队列、执行池和调度器三大模块，通过事件驱动调度与算子级抢占的协同，实现高优先级请求的及时响应，同时借助 S-EDF 策略和 SLO 感知批处理最大化系统有效吞吐量。

系统主要由三部分组成：
* Proxy：接收前端请求，以轮询方式分发到预填充实例。
* Prefill Instance：核心优化模块，包括请求队列、执行池和调度器。
* Decode Instance：沿用默认的解码逻辑，采用 FCFS 调度。

下面我们深入两个创新点。

3.1 算子级抢占

3.1.1 原理

算子级抢占的核心思想是：在模型执行过程中，将抢占检查点设置在算子（operator）的边界，而不是在固定大小的块或层边界。

算子是模型的最小执行单元，例如qkv_proj、attn、o_proj、gate_up_proj、down_proj等。每个算子执行完成后，插入一个轻量级的抢占检查，判断是否有更高优先级的请求到达。如果有，则暂停当前任务，保存状态，让出执行权。

图 6 对比了不同层次的抢占粒度。

图 6 | 执行逻辑具有层级性，抢占检查可置于不同执行边界。分块或分层级别的抢占检查导致较粗的抢占粒度，而 FlowPrefill 将其置于核心算子边界以实现最细粒度抢占（蓝色圆圈表示抢占检查点）。该图清晰展示了 LLM 执行的三级层级结构，算子级作为最细执行单元，其边界抢占无需拆分请求即可实现高效中断，既避免了分块的冗余开销，又突破了分层的粒度限制，为低延迟抢占提供了硬件友好的实现路径。

这种方法的好处是：
* 细粒度：算子执行时间通常很短（例如几毫秒），因此抢占延迟被限定在单个算子时间内。
* 无额外切分开销：不需要将请求拆分成小块，避免了内存重复加载和内核启动开销。
* 通用性：可适用于各种模型，只需在核心算子间插入检查点。

3.1.2 协同抢占过程

FlowPrefill 采用 协同抢占（cooperative preemption），而不是强制中断。这是因为强制中断正在执行的 GPU 内核可能导致资源泄漏或死锁。协同抢占的过程如图 7 所示。

图 7 | 协作式抢占流程。该流程体现了调度器与执行池的协同机制，调度器通过设置抢占信号触发中断，执行池在算子执行完毕后检查信号并安全挂起当前任务，整个过程仅涉及简单并发原语操作，开销可忽略，确保了抢占的高效性与安全性。

协作式抢占流程如下：
1. 高优先级请求到达：调度器设置抢占信号，并等待确认（ACK）。
2. 算子完成检查：执行池在算子边界检查信号，若发现被置位，则清除信号，暂停当前任务，并将其移入“被抢占队列”，然后发送 ACK 给调度器。
3. 调度新任务：调度器收到 ACK 后，提交高优先级请求执行。
4. 恢复被抢占任务：当高优先级任务完成且无更高优先级请求时，调度器发送 resume 命令，恢复被暂停的任务。

对于使用张量并行（tensor parallelism）的大型模型，FlowPrefill 通过同步迭代计数器确保所有并行进程在相同算子边界暂停，避免通信死锁。

3.2 事件驱动调度

算子级抢占提供了机制，但还需要一个智能的调度策略来决定何时抢占、选择哪个请求。FlowPrefill 采用事件驱动调度，即 仅在请求到达或完成时触发调度决策，避免了周期性检查的开销。

3.2.1 优先级定义：Slack-aware EDF（S-EDF）

每个请求被赋予一个优先级，公式如下：
Priority = sgn(slack) / deadline

其中：
* slack = deadline - (current_time + predicted_TTFT)，表示剩余可用时间（若为正，则有可能按时完成；若为负，则已注定超时）。
* sgn是符号函数：正 slack 返回 1，负 slack 返回 -1。
* deadline是请求到达时间加上其 TTFT SLO。

这个公式的含义是：优先级最高的请求是那些 deadline 最早且 slack 非负的请求。负 slack 的请求被赋予负优先级，即实际上被降级，避免它们浪费资源。

TTFT 预测通过一个离线拟合的多项式模型实现，输入为 token 数，输出预测时间。由于 PD 分离下预填充与解码互不干扰，预填充时间与 token 数近似线性，因此多项式拟合效果良好，见图 13。

图 13 | 三种模型在 QwenTrace 的一个轨迹片段上服务时，首 token 延迟（TTFT）的实际值与预测值对比（固定请求速率）。(a) Llama3-8B；(b) Qwen2.5-14B；(c) Llama3-70B。预测值与实际值高度吻合，少量异常值不影响整体效果。这得益于 PD 解耦架构下预填充计算与令牌数的近似线性关系，使得基于离线拟合的多项式模型能精准预测 TTFT，为松弛度计算和 SLO 感知批处理提供了可靠支撑。

表 2 | 本文中使用的关键符号及其描述。该表系统性地定义了 FlowPrefill 架构与算法的核心表征体系，涵盖请求属性、调度状态、执行参数三大维度。符号体系清晰区分了预填充与解码阶段的变量，尤其对松弛度、抢占信号等核心概念的界定，为算法 1 的批处理决策和算法 2 的抢占逻辑提供了严谨的数学表达与理论支撑。

3.2.2 SLO 感知批处理

为了在满足 SLO 的前提下最大化吞吐，FlowPrefill 采用 SLO 感知的批处理算法（算法 1）。其核心思想是：以当前最高优先级请求为基础，尝试加入其他候选请求，但必须保证加入后整个批次的预测延迟不超过其剩余时间，且总令牌数不超过预算。

算法步骤如下：
1. 初始化批次，计算剩余时间（当前时间与截止时间之差）和当前令牌数。
2. 遍历按优先级排序的候选请求：
* 计算加入候选请求后的总令牌数。
* 预测批次的延迟。
* 如果预测延迟不超过剩余时间，且总令牌数未超过预算，则将候选请求加入批次，并更新相关状态。
3. 返回最终构建的批次。

该算法确保批次处理不会导致最高优先级请求超时，同时通过令牌预算限制批次大小，避免因过度批处理长请求而影响系统响应性。

算法 1 | SLO 感知批处理算法。该算法是 FlowPrefill 事件驱动调度的核心模块之一，专为 LLM 预填充阶段的异构工作负载设计。它通过令牌预算和延迟预测控制批处理规模，在保障高优先级请求 SLO 的前提下最大化系统吞吐量，是实现高 SLO 达标率下高有效吞吐量的关键支撑。

3.2.3 完整调度流程

算法 2 给出了事件驱动调度的完整流程。

算法 2 | FlowPrefill 算子级抢占的核心调度逻辑。该算法深度耦合松弛感知 EDF（S-EDF）策略与算子边界检查机制，突破了传统分块/分层抢占的粒度限制。它通过精准的 TTFT 预测值计算请求松弛度，动态裁决执行权归属，不仅实现了毫秒级抢占响应，还通过主动降级无望满足 SLO 的请求避免了队列拥塞，是支撑系统在大模型上保持低阻塞、高 SLO 达标率的关键。

结合算法描述，其关键步骤可概括如下：
* 等待调度事件发生（如新请求到达或任务完成）。
* 将所有待处理请求按优先级排序，选出最高优先级请求 H。
* 如果 H 处于等待队列中，则尝试为其执行 SLO 感知批处理。
* 检查当前正在执行的任务 E 是否应被抢占（即 H 的优先级高于 E）。如果是，则抢占 E，然后提交或恢复执行 H。

图 8 用一个简单示例展示了整个流程。

图 8 | FlowPrefill 中处理两个不同优先级请求的调度示例。该示例完整呈现了事件驱动调度的核心逻辑：低优先级请求 A 执行中被高优先级请求 B 的到达事件触发抢占；B 完成后，通过完成事件唤醒 A 继续执行。整个过程无需多余调度检查，既保证了高优先级请求的时效性，又避免了资源浪费。

上图展示的具体示例如下：
* 请求 A（低优先级）先到达并开始执行。
* 请求 B（高优先级）到达后触发抢占，A 被暂停，B 开始执行。
* B 执行完成后，A 恢复执行。

四、评估

FlowPrefill 在真实生产轨迹 QwenTrace 上进行了全面评估，并与 DistServe 和 vLLM 等基线系统进行了对比。以下摘取关键结果进行解读。

4.1 实验设置

• 硬件：8×NVIDIA A800 80GB GPU，通过 NVLink 互联。
• 模型：Llama3-8B、Qwen2.5-14B、Llama3-70B（稠密模型），以及 Qwen3-30B-A3B（MoE 模型）。
• 工作负载：QwenTrace 包含四种任务类型（聊天、图像理解、网页搜索、文件总结），其提示长度分布见表 1。

表 1 | 实验中使用的模型、硬件、批处理大小和最大序列长度的配置。该表明确了基准实验环境，覆盖从 8B 到 70B 的不同规模模型。批处理大小与最大序列长度的设定贴合真实生产负载，为后续在 QwenTrace 上进行公平的性能对比奠定了基础。

每个任务被分配了不同的 TTFT SLO（见表 2），其中聊天任务最严格（0.25秒），文件总结任务最宽松（6.0秒）。

表 2 | 本文中使用的关键符号及其描述。该表系统性地定义了 FlowPrefill 架构与算法的核心表征体系，涵盖请求属性、调度状态、执行参数三大维度。符号体系清晰区分了预填充与解码阶段的变量，尤其对松弛度、抢占信号等核心概念的界定，为算法 1 的批处理决策和算法 2 的抢占逻辑提供了严谨的数学表达与理论支撑。

4.2 端到端性能

图 9 展示了在不同请求到达率和 SLO 要求下，各系统的 SLO 达标率。

图 9 | 三种模型在 QwenTrace 上不同请求速率和 SLO 要求下的端到端性能。(a) Llama3-8B；(b) Qwen2.5-14B；(c) Llama3-70B。结果显示，FlowPrefill 在各模型上均表现优异。在相同 SLO 达标率下，其支持的请求速率较 DistServe 提升 4.7-5.6 倍，较分块预填充变体提升 2.0-4.5 倍，且能支持 1.5-3.1 倍更严格的 SLO，验证了其在不同模型规模下的泛化性与高效性。

• 与 DistServe 对比：FlowPrefill 的最大有效吞吐比 DistServe（默认 FCFS 调度）高 4.7 倍至 5.6 倍；比 DistServe-CP2K（块大小为 2K）高 2.0 倍；比 DistServe-CP8K 高 4.5 倍。这是因为 FlowPrefill 能及时抢占低优先级请求，让高优先级的短请求几乎无阻塞地执行。
• SLO 收紧容忍度：FlowPrefill 能支持比 DistServe-CP2K 更紧 1.5 倍至 2.3 倍的 SLO，比 CP8K 更紧 2.1 倍至 3.1 倍。这得益于 S-EDF 和 SLO 感知批处理，在负载高时主动放弃注定超时的请求，避免系统整体性能崩溃。

4.3 消融实验

4.3.1 调度策略

图 10 比较了松弛感知 EDF（S-EDF）与普通 EDF、截止时间感知 EDF（D-EDF）的性能。S-EDF 显著优于二者，因为它利用松弛度提前排除不可行的请求，防止资源浪费。

图 10 | 三种调度策略的性能对比。D-EDF：截止时间感知 EDF；S-EDF：松弛感知 EDF；EDF：原生 EDF。对比表明，S-EDF 策略通过引入松弛度估计，能主动降级无法满足 SLO 的请求，避免队列拥堵导致的整体性能崩塌，在最大有效吞吐量和最小可支持 SLO 两方面均显著优于仅关注截止时间的 D-EDF 和原生 EDF，凸显了其设计的合理性。

图 11 展示了不同批处理令牌预算的影响。预算为 4K 时，SLO 达标率与吞吐达到较好平衡；无批处理时吞吐最低；预算过大（8K）虽吞吐略增但 SLO 达标率下降。

图 11 | 不同批处理令牌预算与无批处理情况下的性能对比。实验验证了 SLO 感知批处理的有效性，无批处理吞吐量最低，过大预算虽提升吞吐量但增加 SLO 违约风险，而中等预算（4K 左右）能在捕获短请求批处理收益的同时控制延迟，实现吞吐量与 SLO 达标率的平衡。

4.4 运行时分析

4.4.1 抢占阻塞时间

图 12 对比了算子级与层级抢占的阻塞时间。算子级平均阻塞时间仅 2.6ms（最大<4.5ms），层级则达 9.5ms 以上，前者降低 3.5 倍～ 4.2 倍。

图 12 | 算子级与分层级抢占边界下的平均抢占阻塞时间。不同抢占粒度通过在不同执行边界设置抢占检查实现。数据显示，算子级抢占将平均阻塞时间降低 3.5-4.2 倍，所有模型下均控制在 4.5 毫秒内，这种近无阻塞的性能表现，使得高优先级请求能快速获得资源，大幅缓解了预填充阶段的队首阻塞问题。

4.4.2 TTFT 预测准确性

图 13 显示了真实 TTFT 与预测值的散点图，大部分点靠近对角线，说明多项式预测模型足够准确。

图 13 | 三种模型在 QwenTrace 的一个轨迹片段上服务时，首 token 延迟（TTFT）的实际值与预测值对比（固定请求速率）。(a) Llama3-8B；(b) Qwen2.5-14B；(c) Llama3-70B。预测值与实际值高度吻合，少量异常值不影响整体效果，这得益于 PD 解耦架构下预填充计算与令牌数的近似线性关系，使得基于离线拟合的多项式模型能精准预测 TTFT，为松弛度计算和 SLO 感知批处理提供了可靠支撑。

4.5 扩展性评估

4.5.1 单 SLO 场景

在 ShareGPT 数据集上，所有请求共享相同 SLO（聊天）。图 14 显示 FlowPrefill 的吞吐与 DistServe-CP2K 相当，但 SLO 达标率更高，证明算子级抢占几乎没有额外开销。

图 14 | 单一 SLO 工作负载下的性能对比。FlowPrefill 的吞吐量与基线相当，表明算子级抢占的开销可忽略不计，但在请求速率提升时能提供更优的 SLO 达标率。在均为短输入的单一 SLO 场景中，FlowPrefill 保持了与 DistServe-CP2K 相当的吞吐量，证明其轻量级抢占检查无额外效率损耗，同时在高请求速率下仍能维持高 SLO 达标率，体现了其在不同负载场景下的稳定性。

4.5.2 结合分块预填充

对于极长输入（如>32K），单个算子也可能耗时较长。图 15 显示，将 FlowPrefill 与分块预填充结合（选择合适的块大小，如 8K）可进一步提升性能。

图 15 | FlowPrefill 结合分块预填充在不同分块大小下的性能。结果显示分块大小需合理配置，小块（2K）因频繁拆分引入额外开销，大块（16K）缺乏足够抢占粒度，中等分块能平衡算子执行时间与吞吐量，说明 FlowPrefill 可与分块预填充结合，进一步优化超长输入场景的性能。

4.5.3 PD-共存场景

FlowPrefill 也适用于预填充和解码共存于同一设备组的情况。图 16 显示，在 PD-共存下，FlowPrefill 不仅改善了 TTFT SLO，还因减少了预填充干扰而间接提升了 TBT（token 间时间）SLO。

图 16 | PD 共置架构下不同请求速率的性能对比，报告首 token 延迟（TTFT）和令牌间延迟（TBT）的 SLO 达标率。(a) TTFT；(b) TBT。尽管 FlowPrefill 主打 PD 解耦架构，但在共置场景下仍表现出色，TTFT 达标率显著高于 vLLM-CP2K，且因自适应抢占缩短了预填充对解码的干扰时间，TBT 达标率提升 1.6 倍，验证了其跨部署范式的鲁棒性。

4.5.4 MoE 模型

在 Qwen3-30B-A3B（混合专家模型）上，FlowPrefill 同样有效如图 17，说明其算子级抢占可扩展到专家路由等新算子。

图 17 | 服务 Qwen3-30B-A3B 模型的性能对比。针对混合专家（MoE）模型，FlowPrefill 通过在新增算子边界设置抢占检查实现快速适配，其有效吞吐量较 DistServe-CP2K 提升 1.6 倍，支持的 SLO 严格度提升 2.4 倍，证明其设计对复杂模型架构具有良好的兼容性与扩展性。

五、相关工作

FlowPrefill 并非孤立存在，它建立在前人研究的基础上，并针对性地解决了它们的不足。我们将其与以下几类工作对比：

结论

FlowPrefill 通过 算子级抢占 和 事件驱动调度 ，成功解耦了抢占粒度与调度频率，解决了 LLM 服务中预填充阶段的头阻塞问题。它能在保持高吞吐的同时，实现近乎无阻塞的响应，显著提升了有效吞吐（goodput）和对异构 SLO 的容忍度。

实验表明，FlowPrefill 相比现有系统，有效吞吐（goodput）提升高达 5.6 倍，支持更紧的 SLO 达 3.1 倍。

这一设计为 LLM 服务提供了一种新的思路：不依赖固定切分，而是利用模型自身的算子边界，结合智能调度，实现高效、灵活的抢占 。未来，随着模型规模不断增长和多模态模型的普及，类似 FlowPrefill 的细粒度、自适应调度技术将变得越发重要。

• Prefill 1.3倍、Decode 1.7倍加速！混合 CPU-GPU 调度和 Cache 管理的高效 MoE 推理！
• TTFT降3倍，GPU提速5倍！高通提出 88% KV 缩减的稀疏注意力创新方案 QuoKA：赋能 LLM 分块预填充
• NVIDIA提出长上下文加速方案BLASST：动态 Softmax 阈值稀疏注意力，74%稀疏度下预填充1.6倍速解码1.4倍速

关注“鲸栖”小程序，掌握最新AI资讯