前言¶

大模型线上推理常把多条请求拼成一批跑，硬件算得更快，但数值路径会随「这一批里还有谁」而变：同一请求的浮点累加顺序、内存布局都可能不同，输出便难以逐比特对齐。对审计、对拍基线、对需要严格一致下游环节的场合，这是实打实的落地痛点。arXiv 论文《BlockLock: Reproducible LLM Inference with Fixed Batch Geometry》（arXiv:2611.06977）于 2026-11-04 提交，讨论的是：在保留共享批处理预填充的前提下，只把「被保护请求」所见的几何结构钉死，从而在同伴请求变化时仍保持该请求输出按比特一致。下面按论文摘要整理机制要点与实验设置，并顺一句和常见基线的取舍。

论文与发布信息¶

稿件归类 cs.AI，并带 cs.CL 主题标签。署名作者为 Xiuyuan Qi、Pedro Reviriego、Javier Conde、Shanshan Liu。版本记录显示 [v1] 提交时间为 UTC 时间 2026-11-04 13:40:05（摘要页记为 Wed, 4 Nov 2026 13:40:05 UTC）。正文入口与 DOI 可在 arXiv 条目页查看：https://arxiv.org/abs/2611.06977，以及 https://doi.org/10.48550/arXiv.2611.06977。

问题设定：要的是「同伴在变，目标不变」¶

论文把可复现推理写成一条硬约束：某个请求的输出必须不随同一批内其他请求的变动而改变。摘要里对照了两类已有代价：一类是用批处理不变（batch-invariant）内核，把每个算子都约束住；另一类是类似 CoRun 基线那样把预填充隔离开、用固定形状的解码，代价是放弃共享预填充算力并在解码侧做填充。BlockLock 的路线是保留共享的批式预填充，只对被保护请求钉死其数值路径所依赖的「几何」。

BlockLock 两种模式在做什么¶

先做概念对齐：「固定几何」指的是被保护请求在计算图里看到的块排布、行宽或打包方式按部署约定固定下来，而不是整批所有算子一律改成批不变实现。

1、BlockLock-Rows：用固定行宽（fixed-width rows），解码阶段仍可对所有请求做批处理解码；在摘要所述的每部署合同（per-deployment contract）下，同伴更换时目标请求的比特级输出仍与合同一致。

2、BlockLock-Pack：采用终端锚定的打包（terminal-anchored packing），给被保护段旁挂隔离用的哑段（dummy segment），再取出该请求的 KV 状态做仅针对目标的解码。同样在所述合同下，同伴变动不改变目标输出比特模式。

摘要强调：与「整批批不变内核」相比，这种做法不必为全请求定制内核实现，约束面主要集中在被保护请求上。

实验与报告数字（均来自论文摘要）¶

模型侧覆盖五款稠密模型：Qwen3-8B、Qwen3-14B、Llama-3.1-8B-Instruct、Gemma-3-4B-IT、Gemma-3-12B-IT。部署侧在三套单 GPU 环境上评估：NVIDIA A6000、A100、H100；并补充了初始张量并行实验（两台 NVIDIA A6000）。评测数据包含 tinyBenchmarks 与 BFCL。摘要写明：在报告的测试中，两种模式均保持目标序列一致，且 Top20 logit 的比特与基线一致。

在与 vLLM Batch-Invariant 比较、并在「等量交付工作」（equal delivered work）条件下，BlockLock-Rows 相对该基线的摘要数字为：延迟降低 53.5%–55.0%，吞吐提高 115.2%–122.2%。论文同时说明相对批不变内核路线，其优势之一是不需要自定义内核实现。

对工程和排产的一点含义¶

把可复现性从「整模型、整批算子一律批不变」收窄到「声明要保护的请求及其几何合同」，运维上更接近「给关键流量打标、给部署写清合同」这一条线；共享预填充还在，吞吐与延迟的权衡便直接出现在论文数字里——至少对摘要所报配置，BlockLock-Rows 相对 vLLM 批不变基线给出了明确区间的改进。张量并行只写了初始实验，是否覆盖更大集群与更多并行策略，需读全文再定。

生产侧若采纳，仍要把「per-deployment contract」里的几何细节、保护集合、与调度器的交互写进变更说明与回归集合；摘要未替代具体实现手册，但能提供一个可核对的公共表述与数据源。

来源：arXiv 条目页 2611.06977 所收录之论文摘要及元数据（提交日期、作者、主题分类等）。