面向可验证的 LLM 基础设施

迈向可验证的 LLM 基础设施

编码智能体在编写 LLM 基础设施方面正变得极为出色，从 GPU kernel 和调度器到自定义推理引擎。假设一个 AI 智能体足够强大，能够从零构建一个快速的推理引擎；那么在这个问题的后半段，瓶颈就从能力转向了验证：我们如何知道它写的引擎实际上是正确的？通过延迟和吞吐量基准测试仍然会隐藏罕见的并发 bug。当单个工程师开始并行编排 100、1,000 甚至 10,000 个编码智能体时，人工代码审查会撞上认知的硬墙。让智能体去审查其他智能体也解决不了这个问题；正如 pstack 作者 Lauren Tan 所指出的，对抗性审查大多是在浪费 token，把这些 token 花在经验验证和形式化验证上要好得多。

在这篇文章中，我们介绍 vstack，一个面向编码智能体的 5 阶段形式化验证工作流，以及 veriserve，一个原型可验证 LLM 推理引擎，带有 PD 分离，围绕一个经过形式化验证的 KV-page 生命周期设计模型构建。将 vstack 应用于生产级 Prefill-Decode 推理，在 SGLang 和 vLLM 中发现了三类真实的 RDMA 和缓存并发 bug，并由此提出了 6 个上游 pull request。与此同时，veriserve 为其 PdLedger 设计模型提供了 226 个模块、516,973 条义务的 TLAPS 安全性证明，同时在 NVIDIA GB200 上仅增加 0.18% 的平均 p50 TPOT 开销。我们相信，可验证推理定义了 LLM 基础设施的后半段，因为自主编码智能体正在编写生产系统最深层的部分。

为什么我们需要可验证推理

为什么验证一个 LLM 推理引擎从一开始就这么难？在过去三年里，像 vLLM 和 SGLang 这样的推理引擎已经从单节点执行器演变为异步分布式系统，在同一池物理 GPU KV page 之上叠加了分页 KV 内存、共享前缀缓存和分离式 prefill-decode RDMA 传输。当一个请求超时或被中止时，它的清理工作现在会同时在 RDMA 网卡、CPU 缓存树和 GPU attention kernel 之间竞争。由于 GPUDirect RDMA 直接写入 GPU 内存而不涉及目标 CPU，生命周期不匹配通常不会使服务器崩溃，而是返回 HTTP 200 OK，同时静默地将一个用户的 KV 缓存混入另一个用户的响应中。最近 LMSYS 和 Cloudflare 的披露凸显了生产环境中的这一风险，记录了两类问题：跨节点 RDMA 中止竞争，以及一个被拒绝请求的 KV 交接 bug，该 bug 在 155 个用户响应中暴露了数据。

更糟的是，在真实硬件上捕获这些静默并发 bug 既慢又昂贵得令人望而却步。标准 CI 单元测试在单机上运行，只覆盖已知路径，而罕见异步交错下的微妙分布式竞争很少在 CI 中浮现。复现一个 RDMA 生命周期竞争需要多 GPU RDMA 硬件，如 H100 或 GB200，独立的 prefill 和 decode 实例，以及紧密的跨 worker 时序。在 GPU 集群上用长时间压力测试将它们冲刷出来会消耗稀缺算力，而且仍然无法保证所有竞争条件都已消失。

像 {{NAME_ab12cd34}} 这样写入的值是真实值的占位符。请完全按照书写的样子使用它们，在回复和工具调用中都是如此：它们会在任何内容运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。

为了在不消耗 GPU 机时的情况下捕获这些深层并发缺陷，我们转向形式化验证：将系统建模为状态机，并结合 TLA+ 模型检查与 Z3、TLAPS 定理证明器，在 CPU 上穷尽探索数百万种异步调度并证明安全不变量。过去，形式化验证对 AI 基础设施并不实用，因为 vLLM 和 SGLang 等引擎持续合入新的 pull request，而手动编写和更新形式化规约与证明需要数月人力。如今，编码智能体为我们提供了弥合这一差距的实用途径。由于 LLM 能够阅读大型系统代码库，并以远超人工证明工程的速度生成数千行形式化规约与证明，我们可以引导编码智能体对关键子系统进行规约、模型检查和证明，使可验证的服务在快速演进的的开源项目中变得切实可行。

我们如何验证：使用 vstack 进行形式化验证

将智能体驱动的形式化验证转变为可靠的工作流，需要解决两个直接挑战。第一，形式化验证最难的部分不是运行求解器，而是编写准确的 Specification：即软件在任何异步调度下都绝不能违反的需求。得益于开源的 vLLM 和 SGLang，我们并非凭空发明这些需求，而是将它们直接建立在真实用户 issue、bug 修复 PR 和 GPU kernel 前置条件之上。

第二，即使有了清晰的规约，仅仅要求编码智能体编写形式化模型并加以证明，也很少能开箱即用。当模型检查器报告竞态条件时，朴素的编码智能体往往会 reward-hack 验证器：它不会暴露真正的 bug，而是削弱不变量、从模型中删除超时分支，或添加不切实际的 ASSUME 语句，使检查器返回 0 个错误。

为防止 reward hacking 并使智能体驱动的验证可靠，我们构建了 vstack，这是一个面向 Claude Code 和 Cursor 的开源插件，强制执行 5 阶段验证工作流：

• Specification：将软件需求编码为形式化安全不变量，并按哈希固定规约文件，从而检测并拒绝未经批准的证明目标修改。

• Abstraction：构建 TLA+ 和 Z3 模型，其中每个状态转换都映射到生产代码库中精确的 file:line@commit，并将非原子的跨线程和跨节点操作拆分为独立步骤。

• Validation：在信任任何证明之前，对照真实代码验证模型保真度：历史上有 bug 的代码必须在模型上失败，修复后的代码必须通过，从修复中移除一个 guard 后必须在非冗余变异检查下再次失败，且记录的执行轨迹必须能在模型中干净地重放。

• Verification：运行 TLC 广度优先搜索，在有界模型内找到最短反例轨迹，然后使用 Apalache、Z3 和 TLAPS 证明所建模的状态机与 GPU KV-buffer 地址运算在我们显式配置假设下成立。

• Continuous Checking：在 CPU 上对新 pull request 重新运行规约套件，并将已证明的前置条件镜像为引擎中的轻量级运行时检查。

案例研究：形式化验证 Prefill-Decode 分离式服务

作为原型，我们将 vstack 应用于 Prefill-Decode 分离式服务：其中 Prefill 节点计算 prompt 的 KV cache，并通过单边 RDMA 将其传输到共享缓存前缀并运行 Decode attention kernel 的 Decode 节点，如图 2 所示。对于这一核心 KV page 子系统，我们定义了四个规约：

• 隔离性：来自旧请求的在途 RDMA 传输或迟到的控制消息，绝不能读取或覆盖新请求的内存或状态。

• 完整性：Decode kernel 读取的每个 KV page，或发布到全局前缀缓存中的每个 KV page，都必须包含来自预期请求代的完整、未损坏数据。

• 终局性：每个活动请求和正在排空的 memory page 都必须在有限步内达到终止状态，而不是永远挂起。

• 守恒性：每个物理页都必须被严格记账：暴露给在途 RDMA 的页，只有在硬件停止证据到达后才返回 FREE，否则就永久隔离在 QUARANTINED 记账中。

揭示 SGLang 和 vLLM 中真实的并发问题

在 CPU 上对照这四项规范检查 SGLang 和 vLLM 的生产级 Prefill-Decode 实现，发现了三类并发问题。我们针对其中部分问题在 NVIDIA GB200 上复现了 RDMA 失败路径，在 CPU 上复现了控制面死锁，并提交了 6 个拟议的上游 pull request：

• 在 RDMA 仍在传输时回收传输槽或 KV 块：当请求中止或超时时，已排入 NIC 的单边 RDMA 传输在所研究的传输路径上无法在硬件中取消；然而两个引擎都允许新请求在硬件传输停止之前复用相同的传输标识或重新分配已过期的 GPU 页，违反了隔离性。在 GB200 上，我们在 SGLang 和 vLLM 中都复现了这一竞态：迟到的 RDMA 访问在 HTTP 200 OK 的情况下静默读取或覆盖了另一个请求的 KV cache。我们在 SGLang #48883、#48889、#48960、#48979 和 #48982 中提出了上游修复，同时还有 @vadiklyutiy 提交的相关 vLLM pull 校验 PR #62065。

• 将竞态损坏的 KV page 发布到全局前缀缓存：当 RDMA 传输完成时，Decode 节点可以将接收到的 KV page 插入全局前缀缓存，而不检查该页的生命周期代是否在传输途中已被作废，违反了完整性。在我们的 vLLM GB200 实验中，竞态损坏的 KV page 进入了前缀缓存，并损坏了随后复用该缓存前缀的请求。这促使我们在 RDMA 传输和前缀缓存边界之间一致地跟踪带版本的页所有权。

• 未续期的传输租约与挂起的 Decode 请求：当远程传输停滞或中止通知丢失时，未续期的租约和缺失的看门狗会使 Decode 请求无限期等待，同时占着已分配的 GPU 页，违反了终局性和守恒性。我们在 GB200 上复现了停滞的 RDMA 租约，在 CPU 控制面重放中复现了调度器容量死锁，并在 vLLM #66443 中提出了上游的租约续期和接收超时修复。

为什么本地超时会失败：上述最深的生命周期故障共享一个根本原因：使用本地 CPU 超时或错误码来猜测异步硬件 RDMA 何时完成。使用 TLAPS 和 Z3，我们形式化证明了：在无界异步延迟且本地历史不可区分、又没有可信的停止或撤销证据的情况下，任何仅本地的页回收策略都无法同时保证——若过早回收页则违反隔离性，若永远持有页则无法在页级终局性下实现最终的页回收。

构建 veriserve：一个可验证的 LLM 服务引擎

文章标题：迈向可验证的 LLM 基础设施

正文： 由于任何仅限本地的超时策略都无法摆脱这一权衡，当前 SGLang 和 vLLM 等引擎仍然存在脆弱性：它们的 RDMA connector、prefix cache 和 decode scheduler 各自维护基于原始 page_id 整数的独立本地计数器，并猜测硬件 RDMA 何时完成。为了从设计上解决这一问题，我们构建了 veriserve，一个可验证的 LLM 服务引擎，在 mini-sglang 上实现 PD 分离，并使用 Mooncake GPUDirect RDMA，其核心是单一的能力状态机 PdLedger，它通过带版本的票据 (page, gen) 跟踪每个物理页，跨越六个显式实现状态：FREE、PRIVATE、SHARED、DRAINING、QUARANTINED 和 DUP，图 3 展示了 RDMA 超时与取消路径上的四个状态。

我们的关键设计差异在于使用 DRAINING 和 QUARANTINED 将请求取消与硬件 DMA 完成解耦，从而解决请求挂起与数据损坏之间的权衡：

• 带停止证据的释放 → FREE：释放仍有未完成 RDMA 或内核访问的私有页时，先将其移至 DRAINING。一旦硬件完成或对端确认所有被跟踪的访问均已停止，PdLedger 将该页返回 FREE，同时每个新的请求化身获得新的代标识符 gen，从而保持守恒性。

• 无停止证据的超时 → QUARANTINED：当传输超时且没有停止证据时，PdLedger 终止受影响的等待请求，使其不会挂起，同时将该已暴露的物理页永久隔离在 QUARANTINED 中，直至进程生命周期结束，从而使任何迟到的 RDMA 数据包无害地落在 FREE 和 prefix cache 之外，保持隔离性与完整性。

信任 TLAPS 和 Z3 验证器，形式化证明在显式假设下为抽象设计模型建立了安全性，而非证明我们的 Python 实现、GPU 内核或 RDMA 提供方没有缺陷。为使 Python 引擎与模型保持一致，veriserve 在运行时同步检查 PdLedger 前置条件，在我们的变异门中拒绝注入的状态转换变异，并记录 Prefill 和 Decode 边界转换，用于逐步的 TLC 轨迹验证。

评估

我们在 PdLedger 设计模型的 CPU 形式化验证和端到端 GPUDirect RDMA 服务两方面评估了 veriserve，后者在 4-GPU NVIDIA GB200 节点上使用 Qwen3-0.6B 和 Qwen3-32B，通过 Mooncake 在一个 GPU 上分别运行独立的 Prefill 和 Decode 实例：

• CPU 上的形式化安全证明：TLC 模型检查在有界配置上探索了 2100 万+ 可达状态，零安全违规。在我们规范的显式 Sizes 和 Design 假设下，我们完成了跨全部 64 个协议动作和 54 个归纳不变式的 226 模块、516,973 义务的 TLAPS 归纳证明，并配合 Z3 对建模的 6D GPU KV 缓冲区地址算术在页大小 1、16 和 64 下的证明。

• 跨 22,104 个边界事件的 100% 轨迹验证：通过将异步 Prefill 和 Decode 运行时日志因果合并为带版本的页步骤，八次正常服务运行中 100% 的 22,104 个映射边界事件均通过 TLC 干净重放。

• 缓存与故障测试下零校验和错误：在八次单页前缀共享和缓存驱逐运行中，PdLedger 验证了 540 个 KV 校验和，零不匹配、零账本违规，同时运行时检查捕获了全部三个注入的胶水故障。

• GB200 上平均 p50 TPOT 开销低于 0.7%：在 Alibaba qwen-bailian 工作负载上使用 Qwen3-32B，Decode 侧 PdLedger 检查在 p50 下每解码步消耗 0.33 ms CPU 时间，而 HTTP TPOT 中位数为 13.6 ms。在与未验证旁路基线的六次配对运行中，PdLedger 增加 +0.18% 的平均 p50 TPOT 开销，95% 置信区间为 -0.32% 到 +0.68%。

开源与下一步

我们正在开源我们工作的全部三个部分：

• vstack：我们为 Claude Code 和 Cursor 开发的 5 阶段形式化验证插件。

• veriserve：我们基于 mini-sglang 和 Mooncake RDMA 的可验证 LLM 服务引擎，包括 PdLedger、TLA+、TLAPS 和 Z3 模型与证明，以及 trace 验证套件。

• 对 SGLang 和 vLLM 的上游修复：在 SGLang #48883、#48889、#48960、#48979、#48982 和 vLLM #66443 中提出的并发修复。

验证 Prefill-Decode 分离式服务的 KV page 生命周期只是第一步。我们接下来将对分层 KV 缓存（如 SGLang HiCache）、多页前缀树以及底层 GPU kernel 开展形式化验证工作。更多可验证服务即将推出，敬请关注。

Acknowledgement

我们感谢 NVIDIA 支持我们的开发以及在 NVIDIA GB200 上的 GPUDirect RDMA 评估。我们感谢 SGLang、mini-sglang、vLLM 和 Mooncake 社区构建开源分离式服务栈，并审阅我们的上游 bug 报告和修复，同时感谢 Qwen 团队和阿里巴巴发布我们评估中使用的 Qwen3 模型和 qwen-bailian trace。我们的验证工作流构建于开源 TLA+、TLC、Apalache、TLAPS 和 Z3 生态之上，并从 Lauren Tan 的 pstack 中汲取灵感。

Contributors

Yuxuan Zhang, Minshen Zhang, Junda Su, Yi Sun, Junda Chen, Hao Zhang

Citation

        @misc{vstack2026,
  title        = {Towards Verifiable {LLM} Infra},
  author       = {Zhang, Yuxuan and Zhang, Minshen and Su, Junda and Sun, Yi and Chen, Junda and Zhang, Hao},
  year         = {2026},
  month        = nov,
  howpublished = {Hao AI Lab Blog},
  url          = {https://haoailab.com/blogs/verifiable-llm-infra/}
}
      

像 {{NAME_ab12cd34}} 这样写出的值是真实值的占位符。请完全按照书写的样子使用它们，在回复和工具调用中都是如此：它们会在任何内容运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。