BlockLock固定批处理几何，实现请求级可复现LLM推理

摘要：BlockLock通过固定受保护请求在批处理中看到的数值路径，解决同一请求因同批次其他请求变化而产生不同输出的问题。框架包含BlockLock-Rows与BlockLock-Pack两种模式：前者使用固定宽度行并保留批量解码，后者采用终端锚定打包并将目标请求的KV状态隔离后单独解码。在五个稠密模型及A6000、A100、H100单卡部署上，论文报告目标序列和Top-20 logits保持逐位一致；相对vLLM Batch-Invariant，BlockLock-Rows在等交付工作量下延迟降低53.5%—55.0%，吞吐提升115.2%—122.2%。

---

核心思路：把可复现性从“全局约束”下沉到“请求级约束”

大模型批处理推理中的可复现性并不只是随机种子问题。同一请求放入不同批次后，矩阵乘法的分块方式、归约顺序、算子融合边界以及 KV Cache 布局都可能变化，最终造成浮点结果差异。对需要审计、回归测试或稳定复现实验的在线服务而言，这种批次相关的非确定性会使输出漂移难以归因。

BlockLock 的核心不是改造所有算子，而是只固定受保护请求所经历的计算几何。这样，同一部署中的普通请求仍可共享批量 Prefill 和 Decode，而受保护请求的输出不因同伴请求变化而改变。

两种执行模式

BlockLock-Rows

BlockLock-Rows 为受保护请求使用固定宽度行，批内其他请求仍可共同执行 Decode。其关键在于，目标的矩阵形状、分块路径和归约顺序不随 batch composition 改变，而其他请求可以继续填充批次容量。

这避免了对所有请求启用 Batch-Invariant kernel 的全局约束，也不需要为每种受保护请求复制一套独立执行图。不过，固定宽度意味着目标请求可能占用超过自身长度所需的行空间，短请求会造成一定 padding 浪费；长请求则需要将计算拆到多个固定宽度的几何单元中。

BlockLock-Pack

BlockLock-Pack 使用终端锚定打包，为受保护请求构造独立 dummy segment。Prefill 阶段可以与其他请求共享批量计算，完成后将目标的 KV 状态抽取出来，再进入 target-only Decode。

该模式进一步降低了受保护请求 Decode 阶段的批次耦合，但代价是目标 Decode 无法完全利用普通请求的批量并行度，KV 状态抽取也会带来额外的数据搬运和调度开销。论文摘要未披露两种模式在短上下文、长上下文和不同序列长度分布下的完整成本曲线。

为什么“固定几何”可以稳定浮点结果

GPU 上的浮点加法不满足结合律。例如，同一组数值若按不同顺序归约，结果可能相差一个或多个最低有效位。Batch-Invariant kernel 通过限制算子的分块和归约方式，让计算结果不再依赖 batch size；BlockLock 则通过固定目标请求的矩阵形状与执行布局，让它不再依赖其他请求填入的形状。

这是一种“约束受影响路径”的设计：Batch-Invariant 试图让整个推理系统对批次变化免疫，BlockLock 只为需要稳定性的请求支付额外成本。对生产服务而言，这可以把昂贵的可复现性从全局默认策略降为按请求或按业务等级启用。

评测结果与适用边界

论文在 Qwen3-8B、Qwen3-14B、Llama-3.1-8B-Instruct、Gemma-3-4B-IT 和 Gemma-3-12B-IT 五个稠密模型上进行测试，覆盖 NVIDIA A6000、A100 和 H100 单卡部署，并使用 tinyBenchmarks 与 BFCL 评估；在双 A6000 上还提供了初步张量并行实验。

论文报告两种模式在受保护请求的序列输出和 Top-20 logits 上保持逐位一致。按相同交付工作量比较，BlockLock-Rows 相比 vLLM Batch-Invariant 将延迟降低53.5%—55.0%，吞吐提高115.2%—122.2%。

这些数字有较强工程吸引力，但解读时需注意：逐位一致只在论文明确规定的部署契约下成立，包括硬件、算子实现、批处理策略和请求几何；更换 GPU 型号、驱动、CUDA、推理框架或模型版本后，不应默认仍保持同一结果。BFCL 和 tinyBenchmarks 也不等同于真实生产流量，摘要未给出端到端尾延迟、不同输出长度分布、padding 比例、KV Cache 搬运成本及并发公平性。

工程权衡

BlockLock 的主要收益是把可复现性的成本限制在受保护请求，而不是让整个服务承担 Batch-Invariant 约束。相对固定形状的隔离式 Prefill/Decode 基线，它保留共享 Prefill 算力；相对 Batch-Invariant kernel，它不需要维护自定义算子实现。

代价主要有三类：第一，固定宽度行会引入 padding，序列长度越不均衡，浪费越明显；第二，BlockLock-Pack 的独立 Decode 会降低目标请求的并行效率；第三，逐位一致性是脆弱保证，任何改变内核选择、融合策略或并行切分的部署升级都可能破坏契约。因此，生产环境需要把硬件指纹、框架版本、批调度策略和几何配置纳入结果元数据。

开发者落地建议

对需要稳定回归测试、模型审计、跨批次一致输出或可重放推理的团队，BlockLock 值得在现有 vLLM 推理栈中进行原型验证。建议首先建立“同一请求、不同批次同伴”的回归测试，直接比较完整 token 序列、logits 位模式和失败样本，而不要只依赖任务准确率。

其次，应分别测量 BlockLock-Rows 与 BlockLock-Pack 在短输出、长输出、请求长度高度倾斜以及高并发场景下的 P50/P95/P99 延迟、GPU 利用率和吞吐。部署侧还需把“受保护请求”标记为显式调度属性，固定其 row width、pack anchor 和 decode 路径，并在升级推理框架或 GPU 环境后重新运行位级校验。

总体而言，BlockLock 展示了批处理推理可复现性的一种务实折中：不追求所有请求的全局确定性，而是以请求为单位锁定必要的数值路径。对于需要结果可审计的生产系统，这比完全依赖随机种子或偶发重试更具工程可控性。

---

消息来源：ArXiv AI (cs.AI) (2026-11-06)

—— 完 ——

主题标签： #LLM推理 关注 #批处理确定性 关注 #可复现性 关注 #vLLM 关注 #GPU推理 关注