一分钟读论文：《80 行改动，批量推理快 6 倍》
内容提要
UCSC预印本《Read Once, Answer Many》指出，前缀缓存仅节省预处理，解码阶段每个问题每一步仍需重读文档KV。作者将多问题合并为同一请求内的并行回答流，通过流编号掩码使各流只读取文档和自身问题，从而共享一次KV读取。在A100上提速3.7倍，A6000上提速5.9–6.0倍；但GQA模型仅提速1.3–1.9倍，长答案基准LooGLE上仅1.12倍甚至更慢。局限包括仅支持Triton后端、单GPU、贪心解码和离线批式处理，且尚无第三方复现。
延伸解读
加速数字要看清基线
文中三组加速比对应不同基线：3.7倍和5.9–6.0倍是相对开启前缀缓存与CUDA graphs的stock SGLang；5.1–7.5倍是相对共用同一注意力内核的stock Triton；真实基准QuALITY和LooGLE上则只有1.81倍和1.12倍。引用时若混用口径，容易把实验室理想条件当成普遍收益。
GQA模型收益明显缩水
该方法的核心是让多条回答流共享一次文档KV读取，收益取决于stock解码每步重读多少KV。MHA模型每token的KV较大，重读成本高，所以提速显著；换成主流的GQA模型后，每token的KV变小，stock本来重读量就少，加速缩水到1.3–1.9倍。只提6倍而不交代MHA前提会误导读者。
长答案是明确失效边界
在QuALITY上方法比stock FlashInfer快1.81倍，但LooGLE上只比Triton快1.12倍，反而比FlashInfer慢1.26倍。主因是两边平均答案长度不同：QuALITY答案短，生成步数少，共享文档读取的便宜能体现；LooGLE答案长，解码时长主导，文档KV重复读占比被摊薄，共享读取省不出多少。
落地限制与复现状态
论文自标预印本，尚无同行评审；方法仅支持Triton后端、单GPU、贪心解码和离线批式处理，同一文档的问题须提前知道，输出也因浮点运算次序改变并非逐位一致。代码仓虽提供逐表复现脚本，但发布仅四天，第三方独立复现为零，实际采用前需谨慎评估。
Q&A
前缀缓存为什么没有解决长文档批量推理的成本问题？
前缀缓存只节省了预处理阶段，但在解码阶段，每个问题每一步仍然需要重新读取文档的KV cache，导致成本随问题数线性增长。
《Read Once, Answer Many》论文提出的并行回答流方法是怎么工作的？
将多个问题合并为同一请求内的多条并行回答流，通过流编号掩码使每条流只能看到文档和自身问题，从而共享一次文档KV读取，实现并行解码。
这个方法的加速效果如何？在不同硬件和模型上有什么差异？
在A100上对MHA模型（如CodeLlama-7B）提速3.7倍，在RTX A6000上提速5.9-6.0倍；但对GQA模型仅提速1.3-1.9倍，因为GQA每token的KV更小，重读量少。
在真实长文本基准测试中，这个方法的表现如何？
在QuALITY上比stock FlashInfer快1.81倍，但在LooGLE上仅比Triton快1.12倍，甚至比FlashInfer慢1.26倍，因为长答案生成步数多，文档KV重复读的占比被摊薄。
这个方法有哪些使用限制？
仅支持Triton后端、单GPU、贪心解码、离线批式处理（需提前知道同一文档的所有问题），且输出因浮点运算次序改变并非逐位一致。
论文的代码和复现情况如何？
代码仓库为jlab-nlp/parallel-prompting（Apache-2.0），包含复现脚本和原始结果，48GB工作站卡即可运行头条场景，但发布四天尚无第三方独立复现。
