校订说明：原文包含无法追溯的公司案例、成本数字和自制性能表，现已删除。本文只保留 NVIDIA 与 vLLM 一手资料能够支持的结论；所有收益都必须在具体模型、上下文分布和硬件上复测。
自回归解码会为历史 token 保存每层的 Key 和 Value。忽略对齐和元数据时，缓存大小可近似写成：
\[M \approx 2 \times L \times N \times H_{kv} \times D \times B\]其中 $L$ 是层数，$N$ 是已缓存 token 数，$H_{kv}$ 是 KV 头数，$D$ 是头维度，$B$ 是每个元素的字节数。量化降低 $B$，因此主要改善容量与内存带宽压力；它不会自动让所有算子获得同等比例的加速。
NVFP4 使用 E2M1 的 4-bit 数据值，并采用两级缩放：每 16 个值共享一个 E4M3 FP8 微块缩放因子，张量再共享一个 FP32 缩放因子。计入缩放开销后，它不是“严格每元素 4 bit”，但仍明显小于 FP8。
NVIDIA 公布的 KV Cache 方案把缓存从 FP8 压缩到 NVFP4，官方测试中缓存占用约减少 50%，并在所测代码、知识与长上下文基准上报告了小于 1% 的精度差异。这里的比较基线是 FP8 KV Cache，不能误写成相对 FP16 只减少 50%。
对每个 16-value 微块，先选择 FP8 E4M3 scale，把值映射到 E2M1 可表示范围；整个 tensor 还有 FP32 scale 负责更大范围校准。概念上：
x
-> divide by tensor_scale
-> divide by block_scale (one per 16 values)
-> round/clip to E2M1
-> pack two 4-bit values per byte
读取时反向应用 scales，并通常转换到 attention kernel 使用的更高精度。两级 scale 改善局部动态范围，但引入 metadata 和量化/反量化工作。
从 16-bit 数值到裸 4-bit 看似减少 75%，但 NVFP4 还需每 16 个值一个 FP8 scale 和每 tensor 一个 FP32 scale，并有对齐/页 metadata。相对 FP8 的官方 KV 方案约节省 50% 更符合实际对比。相对 BF16 的比例需按具体布局计算，不能只用 4/16。
Prefill 计算密集，KV 写入只是一部分；decode 每步反复读取历史 KV，更容易受缓存带宽影响。NVFP4 可能在长上下文 decode 和高缓存压力下更有价值，但反量化 kernel、缓存命中和 batch shape 会决定实际 TPOT。
GQA 通过减少 KV heads 降低 token cache，MLA 用低维 latent 表示压缩 KV，NVFP4 再降低存储精度。这些优化可以叠加，但基线已经很小时，量化 metadata/反量化成本占比会提高；质量敏感性也依表示而变。
校准集应覆盖不同层、head、上下文位置和输入领域。除平均误差外，观察 scale saturation、异常值比例和 attention/logit 偏差。部署验证使用与业务相同的长上下文任务，而不是只跑短问答。
先根据模型配置计算未量化 KV bytes/token，再乘目标并发和上下文分布；随后加入 block 对齐、scale metadata、prefix cache、CUDA Graph 和权重占用。只有剩余 HBM 才是可分配 KV 池，不能用 GPU 总显存直接除。
校订说明：原文把概念性 YAML、Redis 任务队列和匿名金融公司数据写成 llm-d 的既成实现，缺少来源且会误导部署，现已移除。本文依据当前官方架构重新整理。
llm-d 不是替代 vLLM 的单机推理引擎，而是位于模型服务器之上的 Kubernetes 分布式服务栈。它组合 vLLM、Kubernetes Gateway API/Inference Gateway 及 KV 传输组件，解决大规模服务中的路由、缓存、解耦部署和运维问题。
官方当前将能力概括为：
client
-> Gateway / llm-d Router
-> selected model-server endpoint (vLLM)
-> optional disaggregated prefill and decode workers
-> KV transfer/offload layer when the chosen recipe enables it
路由器可以利用队列、负载和前缀缓存信息选择端点。Prefill/Decode 解耦适合两个阶段资源特征不同的工作负载，但会引入 KV 传输、故障恢复和容量规划成本，并非默认一定更快。
官方展示的性能结果都绑定具体模型、硬件和流量分布，不能直接外推为通用的“成本降低 35%”或“QPS 提升 54%”。
普通 round-robin 不知道请求长度、队列、KV 命中或各副本 GPU 状态。llm-d Router 的 Endpoint Picker 可以利用推理相关信号给候选 endpoint 打分，再由 proxy 转发。评分仍需防止热点：所有共享同一热门前缀的请求都去一个副本，可能让缓存收益被排队延迟抵消。
request -> prefill worker -> KV blocks
\-> transfer metadata
-> decode worker -> tokens
解耦允许两个池分别扩缩容和选择并行策略。代价是 KV 传输延迟、路由一致性和失败恢复。只有当阶段资源特征、网络带宽和请求长度分布适合时，解耦才优于共置。
GPU HBM 最快但最小，CPU 内存/本地盘/远端存储更大但更慢。分层缓存的目标是把热门前缀留在快层，把较冷数据下沉，并用全局索引判断数据位置。命中慢层是否值得，取决于传输成本与重新 prefill 成本的比较。
生产 recipe 还需处理 GPU 拓扑、Gang scheduling、健康探针、PodDisruptionBudget、滚动升级和多租户限流。HPA 仅看 CPU 利用率通常不足，应结合队列、TTFT/TPOT、KV 容量与模型加载时间设计扩缩容信号。
先对同一批 prompt 比较 round-robin 与 prefix-aware routing；再增加请求率观察热点和尾延迟；最后才引入 P/D 解耦并测 KV transfer。每次只改变一个维度，更容易确定收益来自路由、缓存还是资源池拆分。
校订说明：原文重复了整段“最佳实践”，并把多个研究构想、vLLM/SGLang 配置和精确收益写成已验证生产能力。以下版本删除这些断言。
推测解码减少目标模型串行执行的轮数。MoE 目标模型的每轮验证还包含路由、专家 GEMM 和 all-to-all，因此一次成功验证多个 token 可能摊薄权重读取与通信启动成本。
但“MoE 更贵”不自动推出“加速比更高”：草稿 token 可能触发不同专家，验证宽度会改变 grouped GEMM shape 和通信量，低接受率还会浪费这些工作。
可用一个简化模型判断是否值得开启：
\[T_{spec}=T_{draft}(k)+T_{verify}(k)+T_{rollback}\]只有当每轮平均接受 token 数带来的串行步数减少，超过草稿、宽验证和回滚成本时，端到端才会加速。MoE 场景还应把 dispatch/combine 通信计入 $T_{verify}$。
“限制验证时激活的专家”可能改变目标模型分布，除非方法给出严格修正或明确接受近似，否则不能与 lossless speculative sampling 混为一谈。
一次验证多个候选 token 会把更多 token 同时送入 router。优点是每个 expert 的局部 batch 可能变大，grouped GEMM 更高效；缺点是候选分支可能分散到更多 experts，增加 dispatch 和 all-to-all。收益取决于草稿树形状和路由分布。
可把目标模型有效工作定义为“最终保留 token / 目标验证成本”。只看 accepted token 数会忽略验证了多少最终被丢弃的分支。MoE 场景还可记录每个保留 token 对应的 expert token executions 和通信字节。
若多个验证 microbatch 独立，可尝试在一组 experts 计算时 dispatch 下一组。但 dependency、buffer ownership 和 collective 顺序必须一致，尤其在多 rank 上不能让不同 rank 以不同顺序发起 collective。
为了省成本而少激活目标模型原本选中的 expert，会改变 logits，经典接受/拒绝证明不再直接成立。此类方法应标为 approximate decoding，并通过质量指标与分布差异评估；不能与严格 lossless 方法混在同一表中。
先在单 GPU/单节点上验证解码正确性和接受率，再启用 EP 测通信；随后比较无推测、密集/小模型草稿、EAGLE/MTP 等方案。把 kernel、通信和调度时间分别 profile，才能判断瓶颈是否真的被摊薄。
校订说明：原文包含 GPT-4/Claude 草稿模型、跨硬件吞吐表和成本/碳排放数字，官方资料并不支持这些内容，现已删除。
SpecForge 是 SGLang 团队维护的推测解码模型训练框架。它的价值主要在工程链路：支持在线/离线数据、张量并行和 FSDP 训练，并让训练产物更顺畅地接入 SGLang serving。
推测解码包含两个不同问题：
因此“训练完成”不等于必然获得固定加速比。端到端收益取决于草稿成本、平均接受长度、目标模型验证效率、batch 大小和请求分布。
EAGLE 系列不是简单地用一个小语言模型独立生成 token，而是利用目标模型的特征来预测后续候选。EAGLE-3 进一步融合多层特征，旨在提高草稿对目标分布的拟合能力。
“接受率”也不能单独代表性能：更大的草稿树可能提高每轮接受 token 数，却同时增加草稿计算、验证宽度和显存占用。应同时报告：
prompts
-> target model rollout / hidden-state capture
-> tokenize + align target features
-> training shards
-> EAGLE drafter training
-> checkpoint conversion
-> SGLang serving validation
离线数据易复现，但可能与最新 drafter 分布不一致；在线/on-policy 数据更贴近当前模型行为，成本和系统复杂度更高。实际训练可混合使用，并记录生成参数与目标模型 revision。
草稿训练样本中的 token position 必须和目标 hidden feature 一一对应。BOS/EOS、chat template、padding、截断和 packed sequence 都可能造成 off-by-one。最先应做的小测试，是在单条短序列上打印 token IDs、labels 和 feature indices，确认每个预测目标对齐。
FSDP 主要切分参数/优化器状态，Tensor Parallel 切分层内计算。训练 drafter 时还要考虑目标特征数据的读取吞吐，避免 GPU 等待大量 hidden-state 文件。shard 应按样本边界组织并支持断点续训。
产物至少要记录 base/target model、tokenizer、feature layers、drafter architecture、dtype、训练配置和导出格式。Serving 启动时应验证这些字段，而不是等到生成错误后才发现模型不匹配。
更低训练 loss 不一定带来更高 accepted length。最终模型选择应在代表性 prompt 上测 acceptance、draft latency、verify latency 和端到端 TPOT，并监控不同领域/语言的差异。
校订说明：原文虚构了多组模型吞吐、内存碎片率和匿名电商案例，并把实验性状态写成完全兼容，现已删除。本文按 vLLM 官方公告与发布说明更新。
Model Runner V2（MRV2）是 vLLM 对 GPU 执行路径的重新实现，不是 “vLLM V2”。官方总结的三项原则是：
它还重新梳理 persistent batch 的状态所有权，降低请求插入、删除和重排时的耦合。
目标是减少热路径上不必要的 GPU→CPU 同步点，让调度、输入准备、采样与下一轮执行尽可能重叠；它不意味着整个系统永远没有同步。日志、返回 token、动态控制流和不支持的算子仍可能形成同步边界。
MRV2 最初通过 VLLM_USE_V2_MODEL_RUNNER=1 试用，之后逐步覆盖更多模型与功能。到 vLLM v0.25.0，官方发布说明称它已成为所有 dense 模型的默认路径；MoE、混合架构或特殊功能仍可能使用不同路径或回退策略。
因此部署文档不要固定写“v0.20+ 一律手动开启”或“API 完全兼容”。正确做法是：
官方文章展示了部分平台和工作负载上的提升，但不能把某张图的最大值复制成所有模型的固定 “56%”。MRV2 主要减少 CPU bookkeeping 和同步开销，因此小模型、高并发、短步长 workload 往往更敏感；大模型计算占主导时，收益比例可能不同。
相邻 decode step 的 batch 大部分请求不变，重建所有输入浪费 CPU 时间，因此 runner 会维护持久状态，只增量处理新增、完成和重排请求。状态通常包括 token IDs、positions、slot mapping、block table、sampling metadata 等。
V1 的困难在于这些结构既充当长期状态又直接充当某些 kernel 输入，布局变化容易牵动多个功能。MRV2 用更明确的状态层和输入准备层隔离这种耦合。
“GPU-native”不是把所有 Python 逻辑机械搬进 CUDA，而是识别适合批量执行的索引、拷贝和 metadata 更新，用 GPU/Triton kernel 处理，减少大量小 CPU 操作和 H2D 传输。复杂控制面仍可留在 CPU。
若 step $t+1$ 的准备只依赖 step $t$ 的少量采样结果，就可以让 GPU 上的后处理产生紧凑结果，再通过 event/stream 串联下一步，而不把完整 tensor 同步回 CPU。遇到动态停止、logprobs 或 unsupported feature 时可能需要不同路径。
除了性能，MRV2 迁移应验证 greedy/sampling、logprobs、beam/speculative decoding、prefix cache、LoRA、量化、多模态、TP/PP 和 CUDA Graph。任何 fallback 都应出现在日志/指标中，避免把 MRV1 结果误认为 MRV2。
校订说明：原文自制了客服、翻译和代码生成的性能表，并使用了并不存在的统一配置 API。本文改为解释官方算子的统计语义与集成边界。
Top-k/Top-p 采样的直观实现会对整个词表排序。词表很大、batch 较小时，排序和中间张量会成为可见开销。FlashInfer 提供基于 GPU 拒绝采样的算子，在不显式全排序的情况下实现 top-k、top-p 及组合过滤。
关键点是 分布等价，不是固定随机种子下逐 token 与另一实现完全相同。不同实现消耗随机数的顺序可能不同，因此输出样本可不同，但应服从同一目标分布。
当前官方 API 包括：
top_k_sampling_from_probstop_p_sampling_from_probstop_k_top_p_sampling_from_logitsmin_p_sampling_from_probs参数名、输入是 logits 还是 probabilities、以及 top-k/top-p 的应用顺序会随具体接口而不同，应以安装版本的文档为准。
单独测 kernel 延迟后，还要在真实 serving workload 中测端到端 TPOT。采样通常只是解码路径的一部分；当模型前向占主导时，即使采样 kernel 大幅加速，端到端收益也可能有限。
vLLM 已包含调用 FlashInfer sampling 的实现，但是否启用取决于版本、安装和采样配置。不要依赖博客中的虚构 sampling_backend 配置，应查看目标版本源码与文档。
Top-k 只保留概率最高的 $k$ 个 token；top-p 保留按概率从高到低累积达到阈值 $p$ 的最小集合，再归一化采样。两者组合时，先后顺序可能影响候选集合，因此 API 提供的 filter_apply_order 需要明确记录。
Min-p 则按当前最大概率的比例设置动态阈值，常写成保留 $p_i\ge p_{min}\max_j p_j$ 的 token。它与 top-p 的累计概率语义不同。
无需排序的方法可以从原分布提出候选，再检查候选是否位于 top-k/top-p 允许集合；不满足则重试。GPU 上可并行生成随机量、估计/确定阈值并进行接受判断。最坏情况下可能多轮重试，因此实现通常设置最大轮数和 fallback。
FlashInfer 文档中的 deterministic 通常描述算法执行/随机数使用的特定模式，不应直接理解为跨 GPU、跨版本和跨实现逐 bit 相同。需要可重放时，还要固定 generator/seed、offset、输入 logits 和软件栈。
构造小词表和已知概率，采样足够多次，比较经验频率与 reference 分布。除了卡方/总变差距离，还应检查被过滤 token 从未出现、概率和为 1、每请求不同 $k/p$ 以及 NaN 输入行为。
动态 batch 中每个请求可有不同 top-k/top-p/seed。实现需避免为每个请求启动独立 kernel，并正确维护 generator 状态。返回 logprobs 时，过滤前还是过滤后的概率也要遵循 API 契约。
校订说明：原文包含不存在的 Python API、概念性 Docker/Kubernetes 配置和无来源性能表，现已删除。
vLLM V1 把请求处理、调度、KV Cache 管理和模型执行重新组织为更清晰的 EngineCore 边界。EngineCore 可以运行在同一进程，也可以通过进程间通信与前端解耦；“V1”并不简单等于“所有部署都强制多进程”。
API / AsyncLLM frontend
↓ request / output messages
EngineCore client
↓
EngineCore: scheduler + KV cache manager + executor
↓
model runner / workers
V1 以 token budget 为核心统一处理 prompt token 与 output token，使 chunked prefill、prefix caching 和 speculative decoding 更容易组合。调度器仍需在吞吐、TTFT、TPOT 和公平性之间取舍，不存在对所有 workload 都最优的固定策略。
Automatic Prefix Caching 通过块哈希识别可复用前缀。命中缓存能跳过部分 prefill 计算，但不会跳过 decode，也不会保证所有重复文本都命中：tokenization、块边界、LoRA/模型配置和缓存驱逐都会影响复用。
前端把请求转换为 EngineCore 可处理的结构，EngineCore 每轮返回新增 token、完成状态和必要统计。把核心放到独立进程可以隔离 tokenizer/API 的波动，也允许不同 frontend 共享核心，但会增加序列化、IPC 队列、背压与进程故障处理。
高性能实现通常传递紧凑 metadata，而不是复制大张量。输入、输出与控制消息还需要 request ID 和严格生命周期，避免取消请求后迟到结果污染新请求。
假设本轮预算为 1024 token：一个新请求还有 900 prompt tokens，两个在途请求各需生成 1 token。调度器可以先给 decode 各 1 token，再把剩余 1022 分给 chunked prefill。下一轮继续未完成 prompt。这样既避免一次大 prefill 阻塞 decode，也提高 GPU batch 的有效工作量。
真实策略还要受可用 KV blocks、encoder inputs、speculative lookahead 和优先级约束。
命中能省 prefill FLOPs，但哈希查找、block 引用和缓存占用仍有成本。高基数随机 prompt 可能让缓存快速驱逐；共享前缀短于块边界时收益也有限。评测应同时报告 hit rate 和被跳过的 token 数，单纯“请求命中比例”可能夸大价值。
多进程 EngineCore 必须明确：队列满时拒绝还是等待、worker 退出后请求如何失败、frontend 断连是否取消生成、以及重启后 KV state 是否重算。架构解耦提高可维护性，但这些分布式系统问题不会自动消失。
校订说明：原文把概念性命令、虚构基准和未经验证的在线替换写成现成功能。FlashInfer-Bench 首先是定义、生成、验证和评测 kernel 的框架，不是自动替换线上算子的无风险控制面。
AI 生成的 GPU kernel 很容易在单一 shape 上跑得快，却在边界输入、不同 dtype 或不同 GPU 上出错。FlashInfer-Bench 用标准化 definition、workload 和 reference implementation 描述任务，让候选 solution 能在同一套正确性与性能规则下比较。
definition + workload + reference
↓
candidate solution
↓
correctness gate -> benchmark -> ranking/artifact
这里最重要的是 correctness gate 在性能排名之前。仅通过少量随机输入，不能证明数值稳定性、越界安全或所有 shape 都正确。
报告至少应包含延迟分布、吞吐、warm-up、重复次数、输入 shape 分布和硬件信息。单个 batch size 的最大提升不能概括真实服务收益；kernel 级加速也不能直接等同于端到端加速。
FlashInfer-Bench 让“生成—验证—比较”更系统，但生产上线仍属于独立的软件供应链与安全问题。更准确的表述是：它为 AI 生成 kernel 提供可复现评测基础，而不是保证生成代码可直接进入生产。
把三者分离后，同一语义可比较多个实现，同一 kernel 也能在多个 workload 上测试。若 definition 含糊，AI 很容易通过利用未说明边界“刷榜”而非正确优化。
正确性不应只有单一 allclose：
可在 sanitizers、超时和隔离进程中运行候选，防止错误 kernel 挂死整个评测服务。
隐藏测试集、变化 shape 分布、检查输出依赖输入、限制硬编码和异常缓存。性能结果要包含编译时间还是只含运行时间也必须明确。只优化公开的少量输入可能得到高分，却无法泛化到线上。
候选通过评测后生成不可变 artifact，记录源码 hash、工具链、GPU 架构和测试报告。进入 staging 后用 shadow traffic 比较 reference；只有质量、稳定性和端到端收益都达标才逐步放量。
运行时选择 kernel 时应有兼容性谓词和已知正确 fallback。驱动、CUDA 或框架升级会使旧二进制失效，因此 artifact 不能只按算子名缓存。
校订说明：原文把概念性 vLLM/SGLang 类写成现成 API，并添加了法律、金融等虚构案例。以下内容严格区分论文方案与推理框架现成功能。
长上下文下，目标模型与独立草稿模型各自维护 KV Cache 会增加显存压力。QuantSpec 采用同一模型的低精度路径生成草稿，再由高精度路径验证，并对不同阶段使用分层量化 KV Cache，以降低草稿开销和缓存占用。
已确认前缀 -> 更激进的低比特缓存
近期/候选区域 -> 较高精度缓存
draft -> verify -> accept/reject -> update cache state
“自推测”避免额外加载一个完整草稿模型，但低精度执行仍需要可用 kernel，量化/反量化也有成本。分层缓存还必须正确处理回滚：被拒绝的候选 token 不能污染已确认状态。
经典推测采样可以通过接受/拒绝与修正分布保持目标分布不变；量化草稿只影响提议效率。若验证路径、概率计算或 KV 状态也被近似，就必须重新说明误差来源，不能笼统声称“完全无损”。
论文中的加速与显存结果绑定模型、序列长度、GPU、量化格式和 batch size。工程评估至少应复现：
截至校订时，不能仅凭一段自定义 QuantSpecConfig 代码断言 vLLM 或 SGLang 已原生提供同名接口。应先确认官方 release、文档和实现；没有上游支持时，它仍是研究复现/自定义后端工作，而非开箱即用配置。
近期 token 往往更可能受到局部注意力和高权重访问，较早 token 的缓存数量却占长上下文的大部分。分层策略可让近期窗口保留较高精度，远端历史使用更低精度，在容量和误差间折中。这个经验并非对每个模型成立，检索型任务可能突然强烈访问很早位置。
KV 量化通常需要 scale：按 tensor 最省 metadata 但适应性弱；按 head、token 或 block 能更好跟随动态范围，却增加 scale 存储和 kernel 复杂度。4-bit 数据还涉及 nibble packing、对齐和反量化向量化。
一个对称量化示意为：
\[s=\frac{\max |x|}{2^{b-1}-1},\qquad q=\operatorname{clip}(\operatorname{round}(x/s))\]论文具体格式应以原文为准；这个公式只用于理解 scale 与舍入误差。
草稿路径写入低精度候选状态，验证路径需要高精度/目标状态。实现可维护 staging 区：接受的前缀提交到正式缓存，拒绝及其后候选丢弃。原地覆盖若没有事务式边界，容易让下一轮读取错误 KV。
分别比较 K/V 重构误差、单层 attention output、整模型 logits 与最终任务质量。若只看 perplexity，可能漏掉长上下文检索的局部失败；若只看 end-to-end task，又难定位是量化、草稿还是回滚错误。
先实现无推测的分层 KV 量化并验证质量；再加入 self-draft；最后加入接受/回滚。每一步都有独立 reference，能避免多个近似同时引入后无法定位问题。
校订说明：原文对 Claude/Gemini 的内部注意力结构作了无来源断言，并包含自制硬件基准、质量表和成本数据，现已删除。
DeepSeek Sparse Attention（DSA）由两个阶段组成：
当 $k$ 固定且 $k\ll n$ 时，正式注意力部分由 $O(n^2)$ 降为约 $O(nk)$。但索引、top-k、稀疏 gather 和缓存布局也有成本，所以不能直接把渐进复杂度等同于端到端加速。
官方 V3.2-Exp 说明中，indexer 使用少量头，并可采用 FP8。概念上可写为：
\[I_{t,s}=\sum_j w_{t,j}^{I}\,\operatorname{ReLU}(q_{t,j}^{I}\cdot k_s^{I})\]随后根据 $I_{t,:}$ 选择 top-k 历史位置。这里的 index 分数服务于候选选择，不等同于最终 attention probability。
稀疏选择会改变模型能访问的上下文。评测应覆盖 needle retrieval、长文档问答、长代码和长链推理，并与 dense attention 在相同权重/采样条件下比较。不能把某个平均分差异概括为所有任务“质量无损”。
hidden state h_t
-> lightweight query/index weights
-> score against historical index keys
-> top-k positions
-> gather compressed/full KV for selected positions
-> sparse attention
-> output projection
Indexer key 可以比正式 K/V 更小，并使用更低精度，从而让扫描历史的成本低于完整 attention。最终 attention 仍使用模型定义的表示计算输出。
令序列长度为 $n$、选择数量为 $k$。正式 attention 约为 $O(nk)$，但 index score 若对所有历史位置计算，仍有 $O(n^2d_I)$ 项，只是 $d_I$ 和头数较小、精度更低。工程收益来自“便宜的全局筛选 + 昂贵计算只做 top-k”，不能简单忽略 indexer 成本。
长序列 top-k 需要分块选择和归并。直接生成完整 score 矩阵会破坏内存优势；更合理的是每个 tile 保留局部候选，再层级归并全局 top-k。并行实现还要稳定处理相同分数、mask 和 causal 范围。
逻辑 token position 经 block table 转成物理 page/offset，稀疏选择结果可能非常离散。实现需要批量 gather 并尽量合并相邻位置，减少随机访存。IndexCache 一类结构可缓存 indexer 所需状态，但不等同于正式 KV Cache。
当上下文不超过 $k$、top-k 管理成本高于 dense kernel，或某种 backend 不支持稀疏路径时，使用 dense attention 更合理。阈值应由 microbenchmark 决定，并按 GPU 架构调整。