FlashInfer：面向 LLM 推理服务的高效可定制注意力引擎

• 生命周期：推理服务（注意力 kernel 引擎，库形态）
• 部署形态：SGLang / vLLM / MLC-Engine 内集成（第 1–2 页）
• 目标硬件：NVIDIA Turing–Hopper（sm75–sm90a）；评测 A100 40GB SXM / H100 80GB SXM（第 5、8 页）
• 核心资源：KV-Cache 布局 · HBM 带宽 · SM 负载均衡
• 证据状态：P 主导 + 官方仓库（R）+ 论文脚注文档（E）+ 4 条编辑推断（I）

一句话判断

对「注意力变体多、序列长度分布动态、已用 SGLang/vLLM/MLC-Engine 且被注意力 kernel 拖累」的 LLM 推理服务，FlashInfer 在内核层给出三件事：用块稀疏行（BSR）格式统一页表/基数树等异构 KV-Cache 存储，用JIT 编译的可定制注意力模板承接各式注意力变体，用负载均衡且兼容 CUDAGraph 的运行时调度应对批内长度动态。论文口径下：对比编译器后端（SGLang v0.3.4 + Triton v3.0）端到端 token 间延迟（ITL）降 29–69%，长上下文（StreamingLLM 融合 RoPE）延迟降 28–30%，并行生成服务提速 13–17%（全部数字的条件与定位见实验与指标）。边界同样清楚：仅前向（反向是未来工作，第 11 页）、不替代服务框架的调度器与显存管理（与 vAttention 正交互补，论文第 10 页明言可结合）、kernel 级收益可能被 host 侧开销稀释（vLLM 集成近持平，第 21 页 Table 8）。P R I（边界判断为编辑观点）

3 分钟速读

1. 问题：LLM 服务的注意力 kernel 面临两重挑战——负载多样（prefill、批量 decode、前缀复用、投机解码树掩码；批内查询长度与 KV 长度随时间变化，朴素实现负载不均）与硬件/变体定制压力（分页 KV、分组查询头、特异掩码、自定义打分如 soft-cap/FlashSigmoid）；各系统各自为战导致维护成本高（第 1–2 页 §1）。P
2. 统一存储：把 PageAttention 页表、RadixAttention 基数树等非连续 KV 布局统一表达为块稀疏行（BSR）矩阵——Br 对应查询 tile 大小、Bc 由 KV 管理算法决定，kernel 支持任意 (Br, Bc)（第 4 页 §3.1.1 + 图 2）；查询/输出用无填充 ragged 张量打包（第 4 页）。P
3. 可定制执行：CUDA/CUTLASS FlashAttention 模板覆盖 Turing–Hopper（sm75–sm90a，FA2 算法至 Ada、FA3 算法用于 Hopper，第 5 页 §3.2）；注意力变体经六个仿函数（Query/Key/Value/OutputTransform、LogitsTransform/LogitsMask）声明，由 JIT 编译器生成优化 kernel，经 PyTorch JIT 编译并注册为自定义算子（第 6 页 §3.2.3 + 图 5）。P
4. 动态调度：每生成步由 CPU 侧 plan() 按代价模型 cost=α·l_q+β·l_kv 均衡分派工作到 CTA，产出工作队列与部分输出约简映射（计划跨层复用、不被 CUDAGraph 捕获）；run() 是 attention+contraction 合一的持久 kernel，grid 编译期固定、workspace 段偏移恒定，满足 CUDAGraph 全图捕获（第 7 页 Alg.1/§3.3.1、第 7–8 页 §3.4、第 19 页附录 D）。P
5. 结果与边界：端到端（SGLang）ITL 较 Triton 后端降 29–69%、StreamingLLM 长上下文降 28–30%、MLC-Engine 并行生成提速 13–17%（第 1 页摘要 + 第 8–10 页 §4）；kernel 级对 FlexAttention 四种变体全序列长占优（第 20–21 页表 1–4）。边界：仅前向（第 11 页）；vLLM 集成因 host 侧 Python 开销收益近零（bf16）但 fp8 KV 下 ITL 约 −13%（第 21 页 Table 8）。P I（综合）

论文声称的主要结果

术语与记号

BSR（块稀疏行）

把非零元素组织为 (Br, Bc) 连续子块的稀疏格式，利于寄存器复用并贴合张量核心矩阵指令；FlashInfer 用它统一表达页表/基数树等 KV-Cache 布局，支持任意 (Br, Bc)（第 3 页 §2.3、第 4 页 §3.1.1）。

ragged 张量

不规则、无填充的紧致打包张量；FlashInfer 用同一 indptr 把各请求的查询/输出紧凑打包（第 4 页 §3.1.1）。

Attention State 与 ⊕

规范 kernel 输出 =（输出 O, 对数求和归一化 LSE）；⊕ 为其组合算子，可结合/可交换，支撑 split-KV 分块与共享前缀分解（Ring-Attention/Flash-Decoding 同源思想，第 3 页 §2.2）。

可组合格式（composable formats）

把 KV 稀疏矩阵按先验拆成多个不同块大小的 BSR 子矩阵（如共享前缀 (3,1) + 独有后缀 (1,1)）；只计算 index/indptr、不搬运 KV 数据（第 4–5 页 §3.1.2 + 图 3）。

plan()/run()（IE 模型）

受 Inspector-Executor 模型启发：CPU 侧 plan 每生成步产出调度计划（可跨层复用、不被 CUDAGraph 捕获），GPU 侧 run 执行注意力并可被 CUDAGraph 捕获（第 7–8 页 §3.3.1/§3.4 + Listing 1）。

CUDAGraph 兼容

attention 与 contraction 合一持久 kernel、grid 编译期固定、workspace 按最大容量分配且段偏移恒定，使捕获图中 kernel 指针各步不变（第 7 页 §3.3.1、第 19 页附录 D.1）。

GQA 头组融合

KV 头映射到独立线程块、查询头并入查询长度维，一次共享内存 KV 加载服务整个头组；短查询长度时优先（第 18 页附录 A + 图 11；类似 TensorRT-LLM 的 XQA）。

论文出处

《FlashInfer: Efficient and Customizable Attention Engine for LLM Inference Serving》，MLSys 2025（第 1 页页脚）；作者来自 UW/NVIDIA/Perplexity AI/CMU 等；本地文件 05_FlashInfer_2501.01005.pdf。

问题背景

注意力 kernel 是 LLM 服务的咽喉

LLM 推理的核心是注意力：读取 KV-Cache 中的历史上下文、以当前查询计算输出。kernel 效率直接决定整体服务性能；而训练环境里不存在的难题在服务侧集中爆发（第 1 页 §1）。P

挑战一：负载多样与输入动态

服务中的注意力形态横跨 prefill（处理上下文）与批量 decode（逐 token 生成）；多请求处理中不断出现前缀复用机会，投机解码引入树形注意力掩码；批内查询长度与 KV-Cache 长度随时间变化——朴素实现会负载不均，最优调度要求 kernel 动态自适应（第 1 页 §1）。P 从运算强度看，FlashAttention 的运算强度 O(1/l_qo + 1/l_kv) 在服务场景（查询长度 ≤ KV 长度）简化为 O(l_qo)，MQA/GQA 以组大小 g = H_qo/H_kv 把它提升到 O(g·l_qo)（第 3 页 §2.1）——decode 是内存受限问题，KV 布局与访存路径是第一性的。P

挑战二：存储异构与变体爆炸

• 存储侧：PageAttention 页表、SGLang 基数树等非连续存储已成 KV 管理标配，各框架粒度与结构不一（第 1–2 页 §1）；注意力计算需要一种能统一表达它们的格式。P
• 变体侧：分组查询头（GQA）、特异掩码（滑动窗口、ALiBi）、自定义打分（Grok 的 logit soft-cap、FlashSigmoid 的 sigmoid 自注意力）不断涌现；为每个变体在 CUDA 库里手工特化不可持续（第 2 页 §1、第 6 页 §3.2.3）。P
• 稀疏格式背景：多数注意力库把块稀疏块限制为 (128,128) 的倍数，而研究表明 (16,1)/(1,16) 的向量稀疏同样能吃满张量核心——FlashInfer 据此支持任意列块大小 Bc（第 3 页 §2.3）。P

既有方案与基线格局

FlashAttention 系列解决了计算与显存footprint（在线 softmax、循环重排、流水线，第 3 页 §2.1），但面对「非连续 KV + 长度动态 + 变体定制」需要系统级答案；各服务框架各自实现特化注意力导致高维护成本与潜在低效（第 2 页 §1）。FlashInfer 的对照面由此确定：编译器后端（SGLang Triton 后端）、开源 FlashAttention 库、FlexAttention（Triton 生成）、以及各服务框架自带内核（第 8–9 页 §4）。P

本页使用的延迟/吞吐口径

与全站一致：在线服务看 ITL/TTFT（论文 §4.1 以「请求率调至 P99 TTFT < 200ms」为约束）、kernel 级看带宽利用率与 TFLOPS/s；两套口径不可混用，跨论文横比被禁止。P I（口径整理）

核心机制

FlashInfer 的系统设计分两条输入线（第 2 页图 1）：编译时喂给 JIT 编译器三样东西——注意力变体规格、任务信息、KV-Cache 布局规格；运行时只喂序列长度信息给负载均衡调度器，经用户提供的 workspace 缓冲产出注意力输出。P

1 · 统一 KV-Cache 存储：BSR 作为通用抽象（第 4 页 §3.1.1 + 图 2）

页表（PageAttention）与基数树（RadixAttention）等非连续 KV 布局统一为块稀疏行矩阵：非零块即请求访问的 KV 物理页；块大小 (Br, Bc) 中 Br 对应查询 tile、Bc 由 KV 管理算法指定，kernel 支持任意取值（图 2 示例 Br=4、Bc=1）。查询/输出以 ragged 无填充张量紧致打包；新生成的 K/V 先沿用查询的 indptr，再写入 BSR KV-Cache。P

2 · 可组合格式：不搬数据的内存效率（第 4–5 页 §3.1.2 + 图 3）

单一块稀疏格式受固定 Br 制约：Br 大则共享内存/寄存器复用好但碎片多。可组合格式按先验把 KV 稀疏矩阵拆成多个 BSR 子矩阵——共享前缀落入大块 (3,1)（同块查询经共享内存/寄存器共享 KV），独有后缀留在 (1,1)（各查询走全局内存/L2）。关键性质：不需要搬动 KV 数据，只计算稀疏子矩阵的 index 与 indptr 数组。P

3 · 计算抽象：CUDA/CUTLASS 模板与数据搬运（第 5 页 §3.2 + 图 4）

模板兼容 Turing–Hopper（sm75–sm90a）：FA2 算法用于至 Ada（sm89），FA3 算法用于 Hopper。稀疏/稠密的差异被压缩到装载模块：分散 KV tile 用 128B 宽 LDGSTS 异步拷贝汇聚成连续共享内存后，两者收敛到同一 kernel 主体；Hopper 的 TMA 不支持非仿射访问，仅用于连续 KV-Cache。头维通常 128 或 256，末维连续以贴合缓存行。P

4 · tile 尺寸族与启发式（第 5 页 §3.2.2、第 6 页 §3.2.3）

FA2 kernel 提供 (1, 16, 32, 64, 128) × (32, 64, 128) 的 tile 菜单，两步启发式选择：先按批均查询长度（GQA 时查询长度与头组维融合）取≥它的最小查询 tile，再在寄存器/共享内存约束下最大化 SM 占用。查询 tile=1 走 CUDA 核心（张量核心 MMA 最小 16 行）；FA3 行 tile 取 64 的倍数以对齐 Hopper WGMMA。P

5 · JIT 编译的注意力变体与接口层次（第 6 页 §3.2.3 + 图 5）

受 FlexAttention 启发，变体以「仿函数集合 + 附加变量/张量 + 数据类型」的规格声明（CUDA 代码字符串），JIT 编译器把变体类插入 kernel 模板生成优化代码。下表是本页归纳的接口层次（层次划分为编辑整理，各层内容均为论文事实）：P I（分层归纳）

6 · 负载均衡调度（第 7 页 Alg.1 + §3.3.1 + 图 6）

目标是最小化 SM 空闲时间：以 cost(l_q, l_kv) = α·l_q + β·l_kv 计 tile 代价，按 L_kv = Σ⌈l_qo/T_q⌉·l_kv / #CTA 求最大 KV 分块，长任务降序排列后经 CTA 优先队列分配。灵感来自 Stream-K，但因 LLM 服务要求确定性输出，不使用原子聚合，给定相同序列长度信息时聚合顺序确定。长 KV 分块的各 chunk 产出部分输出写入用户提供的 workspace 缓冲，最终输出由 contraction kernel 按调度器算好的约简映射合成；attention 与 contraction 合并为一个持久 kernel，消除 kernel 间开销。P

7 · CUDAGraph 兼容的静态化手段（第 7 页 §3.3.1、第 19 页附录 D）

• 持久 kernel 的 grid 规模编译期固定；workspace 按各段最大容量分配、段偏移恒定，保证捕获图生命周期内 kernel 指针不变（附录 D.1）。P
• plan 信息在锁页（pinned）主机缓冲上计算，经 cudaMemcpyAsync 异步下发到 workspace 对应段（附录 D）。P
• split-K 直写优化：仅「长」请求（KV 长度 > 总 KV 长度 / #CTA）需要分块；短请求部分输出直写最终输出缓冲，省 workspace 与 contraction 工作；部分输出总量上界 2·#CTA × T_q × H_qo × (D+1)；默认 #CTA = k×#SM，Ampere 上 k≤2、Hopper 上常为 1（持久 kernel）（附录 D.2/D.3）。P
• 不同查询长度/可组合配置编译并捕获不同 CUDAGraph，运行时按当前 KV-Cache 配置选择（第 8 页 §3.4）。P

8 · 精度与硬件扩展点（第 20 页附录 F、第 19–20 页附录 E/B）

附录 F 提供 FP8–FP16 混合精度 kernel：查询/输出保持 fp16、KV-Cache 以 fp8 存储，借快速数值转换器与 fragment shuffler 完成反量化，目标是降内存占用、提带宽利用率而不显著损失精度。附录 E：attention 可占用的 SM 数量可由用户经 plan 函数提供（对照 Nanoflow 的固定 SM 划分，可与其余算子重叠）。附录 B：TMA 稀疏汇聚在块列 ≥128 时可行，留作未来工作。P

GPU / 系统数据路径

端到端文字序列

1. ① 请求/上下文：prompt 与已生成 token 构成请求；各请求查询打包为 ragged 无填充张量，输出采用同一 ragged 布局（第 4 页 §3.1.1）。P
2. ② 服务运行时：SGLang / vLLM / MLC-Engine 已集成 FlashInfer；按 Listing 1 构造 AttentionWrapper(attn_spec, task_info, workspace)，运行时输入为各请求查询/KV 长度（第 1–2 页摘要/§1、第 7–8 页 §3.4、第 2 页图 1）。P
3. ③ Attention State 选择：规范 kernel 输出 =（输出 O, LSE），⊕ 可结合/可交换；据此决定 split-KV 分块求积与共享前缀分解的组成（第 3 页 §2.2）。P
4. ④ BSR / 可组合 KV-Cache：页表等非连续 KV 布局统一为 BSR 矩阵；可组合格式拆出多个子矩阵，只计算 index/indptr、不搬运 KV 数据；KV 块读取不经控制面、直接由 kernel 访存（第 4–5 页 §3.1.1/§3.1.2 + 图 2/图 3）。P
5. ⑤ 模板 + 变体仿函数：CUDA/CUTLASS 模板按编译时输入（变体规格、任务信息、KV 布局规格）实例化；六个仿函数定义查询/KV 变换与 logits 处理（第 5–6 页 §3.2–§3.2.3 + 图 5）。P
6. ⑥ JIT 编译与缓存：生成的 CUDA 经 PyTorch JIT 编译并注册为自定义算子；init 时编译、缓存复用；DLPack 供其他运行时（第 6 页 §3.2.3、第 7–8 页 §3.4）。P
7. ⑦ 负载均衡 plan：CPU 每生成步执行 plan()：按 cost=α·l_q+β·l_kv 均衡分派工作队列到 CTA，产出约简映射与 workspace 段偏移；计划跨层复用，不被 CUDAGraph 捕获（第 7 页 Alg.1/§3.3.1、第 7–8 页 §3.4）。P
8. ⑧ 静态缓冲下发：plan 信息由锁页主机缓冲 cudaMemcpyAsync 至 GPU workspace 对应段；workspace 按最大容量分配、偏移恒定；短请求可直写最终输出、旁路 workspace（第 7 页 §3.3.1、第 19 页附录 D.1–D.3）。P
9. ⑨ GPU attention kernel：attention 与 split-KV contraction 合一持久 kernel，grid 编译期固定；分散 KV tile 经 128B LDGSTS 汇聚至连续共享内存后进入稠密张量核心流水线；TMA 仅用于 Hopper 连续 KV-Cache（第 5 页 §3.2.1、第 19 页附录 D）。P
10. ⑩ logits/tokens：（输出 O, LSE）写回 ragged 输出张量，交回服务运行时采样；该端到端闭环为本页编辑装配（各环节为论文事实，闭环叙述标 I）（第 3 页 §2.2）。P I（装配）

架构权衡

云上部署映射

本节为部署映射：论文硬件事实标 P，云产品对应标 E（厂商中立示例、非推荐，参数与价格以云厂商文档为准，本站未联网核验），运维建议/推断标 I。FlashInfer 是实例内 kernel 库，论文不涉及跨节点网络与存储架构。

成本 / 性能 / SLO

论文的 SLO 与实验口径

容量规划变量（SLO 达成率的自变量）

• 序列长度分布的偏斜度与长度：负载均衡收益随其放大——ShareGPT/U(512,2048) 上消融差距小、U(4096,16384) 上 ITL 8.63 vs 13.89 ms（第 21 页表 6–7）。P
• GPU 代际 → 模板路径：Hopper 走 FA3（WGMMA、行 tile 为 64 倍数、TMA 连续路径），Ampere/Ada 走 FA2；prefill 吞吐参考 FA3 模板 343–627 vs FA2 模板 265–370 TFLOPs/s（H100 SXM5、32+32 头、head_dim 128、(batch,seq) (32,1024)–(1,32768)、causal；精度论文未明确披露）（第 18 页附录 B + 图 12）。P
• SM 预算：#CTA = k×#SM（k≤2 Ampere、Hopper 常 1）；attention 可占 SM 数可经 plan 指定以与 GEMM/通信重叠（第 19–20 页附录 D.3/E）。P
• workspace 上界参数：最大并发请求数、最大累计请求长度（首个 plan 阶段必须提供）+ 部分输出上界公式（第 19 页附录 D.3）。P
• GQA 组大小与头配置：组大小 g 提升运算强度（第 3 页 §2.1）；头组融合在短查询时优先（第 18 页附录 A）。P
• 精度选择：f16 为基线口径；fp8 KV 混合精度可降显存/提带宽（第 20 页附录 F；vLLM 集成实测 fp8 下中位 ITL 约 −13%，第 21 页表 8）。P
• host 侧效率：vLLM 集成的 host Python 开销使 bf16 近持平——kernel 收益兑现需要 host 路径足够薄（第 21 页表 8 + §G.4）。P

成本模型（参数化，非论文结论）

论文不含任何成本数据（只有延迟/吞吐/利用率）。架构师可用下式估算（I，价格项为参数）：

每百万生成 token 成本 ≈ ( p_gpu × N_GPU ) ÷ ( T_gen × (1 − φ) ) × 10⁶ …（公式 1）

• p_gpu：单卡时租价（A100/H100 按查询日云价代入，E，非论文数据）；
• N_GPU：实例卡数——论文口径参考：8B 单卡 H100、70B 四卡 H100（第 8 页图 7 面板标注，P）；
• T_gen：实测生成吞吐（token/s）——由注意力 kernel、序列分布、GQA 配置、CUDAGraph 与宿主框架共同决定；可按论文相对收益修正（如 vs SGLang Triton 后端 ITL −29~−69% 对应的负载条件，第 1、8 页，P）；
• φ：非生成开销占比——CPU plan() 每步开销（跨层摊薄，第 7–8 页）、host 侧 Python 开销（vLLM 集成 bf16 近持平的主因，第 21 页表 8）、workspace 显存挤占批容量（第 19 页附录 D.3）。P（成分） I（取值）

敏感项：序列分布变长变偏斜 → 负载均衡收益放大（表 6，P）；KV 换 fp8 → 带宽压力下降、ITL 收益约 13%（vLLM 集成口径，表 8，P）；代际升级 A100→H100 → FA3 模板 prefill 吞吐上台阶（图 12，P）；host 侧不优化 → kernel 收益被 φ 吃掉（表 8，P）。JIT 冷启动为一次性成本，摊销后通常可忽略，但高频扩缩场景需计入（I）。

安全与可运维性

论文披露范围

• 论文未涉及多租户隔离、数据驻留、权限与故障恢复议题——以下部署要点除标注论文事实外均为编辑推断。I
• 官方仓库：论文第 11 页 §7 明示开源地址 github.com/flashinfer-ai/flashinfer，并称项目「已在生产级系统规模化部署」（论文表述，P；仓库归属 flashinfer-ai 经论文自身引用确认，R；论文未提供 commit/tag 与访问日期）。
• 论文脚注引用的外部文档：flashinfer.ai 项目主页（第 1 页脚注，论文原文为 http）、docs.flashinfer.ai 的两个 prefill wrapper API（第 18 页脚注 8–9）、PyTorch JIT/自定义算子文档与 DLPack 仓库（第 6 页脚注 2–4）。按本站链接策略，以上仅作文字引用、不加超链接（本页外链仅 arXiv 与官方仓库）。E

部署方必须自行覆盖的项

适用 / 不适用场景

适用（触发条件 → 理由）

1. 注意力变体多、迭代快的模型栈：触发条件——产品/模型使用 soft-cap、滑动窗口、ALiBi、sigmoid 自注意力、MLA（需融合 RoPE/归一化/投影）等非标准注意力。理由——JIT 变体模板以仿函数级成本承接（第 6 页 §3.2.3），kernel 级对 FlexAttention 四种变体全序列长占优（第 20–21 页表 1–4，H100 80GB SXM、batch 16、16 头、head_dim 128；精度论文未明确披露）。P
2. 序列长度分布动态/偏斜的 decode 服务：触发条件——批内 KV 长度不均（如 Zipf 型）或长上下文为主。理由——负载均衡调度器消融：U(4096,16384) RR=1 时 ITL 8.63 vs 13.89 ms（关闭负载均衡）vs 11.08 ms（Triton）；Llama 3.1-8B-Instruct、H100 SXM5（第 21 页表 6–7）。P
3. 被编译器后端注意力拖累的 SGLang 类部署：触发条件——profile 显示注意力 kernel 主导 ITL。理由——端到端 ITL 较 SGLang v0.3.4 Triton v3.0 后端降 29–69%（A100/H100 SXM、Llama 3.1 8B/70B、f16、ShareGPT+Variable、P99 TTFT<200ms 约束；论文聚合口径）（第 1、8 页）。P
4. 共享前缀 + 并行生成场景（多轮对话、agent 的 n 路采样）：触发条件——请求间大量共享前缀且并行度 4≤n≤32。理由——可组合格式解耦前缀/后缀，聚合提速 13–17%、n=4 峰值 ITL −13.73%/−17.42%（MLC-Engine、Llama 3.1 8B/70B、ShareGPT RR=16）（第 9–10 页 §4.4）；且统一页表管理、无需改造框架内存模块（第 10 页 §5.4）。P
5. KV 剪枝/细粒度稀疏长上下文算法：触发条件——采用 Quest 类 page-budget 稀疏 KV。理由——小块稀疏 kernel（block 16）在 seq 32768/pb64 下 22.371 µs vs PyTorch SDPA 1711.955 µs / FlexAttention 1169.109 µs，论文 prose 称长序列至 20×（H100 SXM5、32+32 头、head_dim 128；精度论文未明确披露）（第 21 页 §G.5 + 表 9–11）。P

不适用（触发条件 → 理由）

1. 训练 / 需要注意力反向的场景：触发条件——训练或微调管线需要注意力 backward。理由——论文明言「目前仅支持前向，可定制反向模板留作未来工作」（第 11 页 §6）。P
2. 非 NVIDIA 或早于 Turing（sm75 之前）的 GPU：触发条件——AMD/其他加速器或老卡。理由——模板覆盖面为 sm75–sm90a，论文未声称其他硬件支持（第 5 页 §3.2）。P I（外推边界）
3. 诉求是调度/显存管理/跨实例缓存层的团队：触发条件——需要过载准入、prefill/decode 分离、跨实例 KV 复用或虚拟内存化管理。理由——FlashInfer 是内核层组件，这些属服务框架与显存管理层职责；论文将 vAttention（显存管理）定位为可结合的互补层（第 10 页 §5.4）。此类诉求应对照本站 DistServe / Sarathi-Serve / Mooncake / vAttention 页。P（定位） I（对照建议）
4. 短序列、低并行度的前缀复用负载：触发条件——ShareGPT 型短序列或 n<4 的并行生成。理由——n 过小时块尺寸增量不足、可组合格式无收益；大 n 时注意力不再主导、收益趋平（第 10 页 §4.4）。P
5. 无法提供 workspace 上界或不接受每步 CPU plan 的部署：触发条件——峰值并发/最大上下文无法估计，或对每步 CPU 开销零容忍。理由——workspace 上界是首个 plan 阶段的显式契约（第 19 页附录 D.3）；plan 每步在 CPU 执行（靠跨层复用摊薄，第 7–8 页）——契约无法满足时该方案不成立。P（机制） I（适用判断）

实验与指标

复现实验的完整条件（论文口径）

关键结果（均带条件）

公平性限制与已知差异

• 图柱乱序：图 7–10 与图 12 的柱状标签在文本提取中交错乱序，逐柱「FlashInfer vs 基线」配对无法从提取恢复——本页只引用论文 prose 明示的聚合（29–69%、28–30%、13–17%、20×、1.6–3.7×）与附录表格数值，未做任何柱级配对。I
• 基线时点：对照基于 FlashInfer v0.2、SGLang v0.3.4、Triton v3.0/3.2、FA commit c1d146c（论文发表时点）；当前各库已演进，绝对数字不能外推到今日版本栈。P（口径） I（时效）
• 精度披露缺口：附录 B/G 的表格未复述精度（多处亦未复述硬件/模型），本页记「论文未明确披露」，不臆测。I
• §4.1 第二对照设置：原文提及「two settings」但第二设置名称在提取中缺损（其注意力 kernel 为闭源的某领先引擎）；本页不点名、不猜测。I
• 数字不可与 DistServe、Mooncake、vAttention 等其他论文横比（硬件、负载、口径均不同）。I

建议复现路径

论文提供官方开源仓库与完整实验配置；以下步骤顺序为编辑建议（I），配置项均出自论文（P）：

1. 获取官方仓库 github.com/flashinfer-ai/flashinfer（论文第 11 页 §7 唯一锚定；建议锁定明确 commit/tag 后再复现）；
2. 环境对齐论文口径：CUDA 12.4 + PyTorch 2.4.0 + f16；A100 40GB SXM / H100 80GB SXM（第 8 页 §4）；
3. 端到端：装 SGLang v0.3.4，分别以 Triton v3.0 后端与 FlashInfer 0.2 后端跑 ShareGPT 与 Variable U(512,2048)，按 P99 TTFT < 200ms 调请求率，记录 ITL/TTFT（第 8 页 §4.1）；
4. kernel 级：batch 16、constant(1024)/uniform(512–1024)/Zipf 三分布对照 FlashAttention（记录所用 commit），prefill 开 causal（第 8–9 页 §4.2）；变体对比用 AttentionGym、Triton 3.2、batch 16/16 头/head_dim 128（第 20 页 §G.1）；
5. 附录复刻：调度器消融（表 6–7 配置）、共享前缀（表 5）、vLLM 集成（表 8）、Quest 稀疏（表 9–11）逐表对齐负载参数；输出与论文数值的偏差先核工具链版本再论结论。

论文 / 链接 / 延伸阅读

论文引用的关联工作（FlexAttention、PagedAttention、SGLang、Quest、Nanoflow 等）仅按论文转述；除 arXiv 与官方仓库外本页不提供任何外部链接。上一篇：vAttention（04）；下一篇：EAGLE（06）；或从首页目录进入。

给架构师的决策清单

证据台账

分级（本论文台账 schema：sources/flashinfer.evidence.json）：P = 论文正文/附录/图表（含论文报告的实验结果，锚定 PDF 页码/章节）；R = 论文明确链接的官方仓库（owner flashinfer-ai 经论文自身引用确认，commit/tag/访问日期论文未提供）；E = 论文脚注引用的外部文档（仅作映射/接口锚点）；I = 编辑推断。注意与 04 页（vAttention）schema 不同——彼页 R=论文实验结果，本页 R=官方仓库，以各页台账为准。「已核验（页码推导）」指内容已对照提取文本核验、但印刷页码系按页眉分隔行推得（第 1 页=标题/摘要页，共 21 页），未对 PDF 二进制目视复核。最后核验日期：2026-09-14。

数据与文件说明：本页全部性能数字与机制描述均取自论文《FlashInfer: Efficient and Customizable Attention Engine for LLM Inference Serving》（arXiv:2501.01005v2，MLSys 2025）的提取文本，并通过 sources/flashinfer.summary.json 与 sources/flashinfer.evidence.json 逐条对应（claims 40 条、performance_rows 22 行，行行带硬件/模型/精度/负载/基线/定位字段，缺失字段记「论文未明确披露」）。编辑推断与部署建议已用 I 标注；本页外链仅 arXiv 与官方仓库两处（HTTPS + rel="noopener noreferrer"）。数据路径图 assets/diagrams/flashinfer-data-path.svg（含 title/desc 无障碍描述）。台账外不捏造任何数字、出处或日期。