为什么吞吐量测试会漏掉首字延迟问题
吞吐量测试通常衡量的是系统在生成开始后每秒能生成多少token——但对于长上下文请求，用户真正的痛点在于首个token到达之前的等待时间。这段等待被称为首token延迟（TTFT），其主要由预填充阶段主导，即模型处理整个提示词的过程。块稀疏注意力可以大幅缩短这一时间：一种方法将32K token输入的TTFT降低了98.7%，FLOPs降低了99.8%，使首token延迟降至45毫秒[1]。一个仅报告每秒token数的服务系统永远不会揭示用户等待了45毫秒而非几秒钟——因为这段延迟发生在生成开始之前。
另一项研究从不同角度揭示了同样的差距：一个稀疏注意力服务系统将平均首令牌时间（TTFT）最多降低了9.26倍，相比最先进的系统，同时将生成吞吐量提升了3.14倍[3]。如果只看吞吐量数字，你会觉得该系统只是略有优势——但TTFT的改进才是交互式长上下文场景中的关键亮点。因此，吞吐量测试可能让一个系统看起来表现尚可，而实际上它在用户最先感知到的方面表现糟糕。
吞吐量测试掩盖了限制批处理规模的内存压力
即使稀疏注意力跳过了对大多数词元的计算，那些未被选中的词元的键值（KV）缓存仍必须保留在高带宽内存（HBM）中，以便后续快速解码。这意味着稀疏注意力并不会自动释放内存——它只是将瓶颈从计算转移到了内存容量上。一项研究发现，这种HBM容量限制制约了可并行批处理的请求数量，从而直接限制了吞吐量[3]。如果吞吐量测试未考虑这一点，就会高估系统实际能处理的并发长上下文请求数量。
同一篇论文还指出，将利用率不高的KV缓存卸载到DRAM可以释放HBM空间，从而支持更大的批处理规模，但这需要精细的管理——碎片化的缓存访问、HBM争用以及混合批处理都会成为问题[3]。因此，一个简单的吞吐量基准测试可能会显示稀疏注意力系统在单请求场景下能达到很高的每秒处理token数，但在真实的多请求服务场景中，内存压力会迫使批处理规模缩小，吞吐量随之骤降。这正是简单的吞吐量测试无法捕捉到的失败模式。
吞吐量测试忽视了激进稀疏化带来的精度代价
块稀疏注意力通过跳过它认为不重要的词元来加速计算——但如果选择有误，就会损失准确性。一项研究发现，在长上下文基准测试中，一种垂直斜线稀疏方法保留了全注意力准确性的98.35%，同时在128K上下文下实现了4.95倍的加速[4]。这听起来很棒，但也意味着1.65%的准确性下降——而吞吐量测试永远不会显示这一点。如果你正在为某项任务部署模型，而那1.65%的差异至关重要（比如法律或医疗推理），那么这种加速就毫无价值。
另一种方法SPLA则明确针对精度问题，将未选中的块压缩为循环状态而非直接丢弃，并在RULER基准测试[5]上实际超越了密集注意力。但这是例外——大多数稀疏方法以精度换取速度，而这种权衡在吞吐量数字中并不显现。仅报告每秒处理令牌数而不衡量任务性能的吞吐量测试，会给出一个危险的不完整图景，让人无法判断系统是否真正可用。
关于这些资料来源
这个回答基于5项研究（2项经同行评审，3项为预印本）——发表于2024年至2026年间，其中5项为2024年或之后发表——这些研究是从5项通过质量筛选的研究中选出的最相关者，而这些研究又源自从超过5亿篇论文的数据库中检索到的24篇文献。
本文引用的文献
用于高效预填充的块注意力机制
Block-attention将32K token输入的TTFT降低了98.7%，FLOPs降低了99.8%，实现了45毫秒的首token延迟，同时在11项基准测试中保持了与全注意力相当的性能。
FlashPrefill V2：面向长上下文LLM服务的块稀疏预填充注意力
FlashPrefill V2在FP8和BF16精度下，于128K上下文长度中分别实现了相比FlashAttention-2高达47.26倍和27.19倍的加速，并在FP8下相比密集FA3/4对齐基线实现了30.49倍加速，同时引入均值修正项以抑制近似误差。
SparseServe：解锁长上下文大语言模型服务中动态稀疏注意力的并行性
SparseServe通过管理HBM-DRAM KV缓存卸载以支持更大的批处理规模，与最先进的系统相比，将平均TTFT降低了最多9.26倍，并将令牌生成吞吐量提升了最多3.14倍。
VSPrefill：面向长上下文预填充的垂直斜线稀疏注意力与轻量级索引
VSPrefill在LongBench和RULER上保持了98.35%的全注意力准确率，同时在128K上下文下实现了4.95倍的平均加速，这得益于轻量级索引器和自适应稀疏预算。
SPLA：面向长上下文建模的块稀疏加线性注意力
SPLA采用二阶泰勒展开进行块选择，并对未选块使用残差线性注意力，在RULER上超越了密集注意力，同时保持了具有竞争力的通用知识与推理能力。