云雀 · 轻技术笔记

2026年10月27日：Anthropic 上市申请里没有 KV cache，Cloudflare 的 GLM-5.3 却漏了 155 条

AIAgentLLM大模型AIGC

先说结论。

10 月 26 日这一天有三件事撞在一起：

  • Anthropic 向 SEC 递交 S-1 招股书，股票代码 ANT。HN 1521 分、1485 条评论。
  • Cloudflare 公开披露，GLM-5.3 在 Workers AI 上有 155 条响应包含了其他用户的会话数据。研究者是 Knostic 的 Gadi Evron，8 月 27 日暴露、9 月 8 日报告、9 月 9 日修复、10 月 26 日协调披露。
  • 微软对大约六万名员工开放自愿离职方案。HN 819 分。

这三件事看起来不相干：一个是IPO，一个是安全事故，一个是裁员。但我把 Anthropic 那份 996 页的招股书全文扒下来搜了一遍之后，发现它们说的是同一件事，而且这件事跟绝大多数人理解的不一样。

Anthropic 在招股书里承诺了 4758 亿美元的算力采购承诺（我按文件里逐条列出的六笔基础设施协议加总，Google 1145 亿、Amazon 1100 亿、SpaceXAI 1205 亿、Microsoft 449 亿、Nscale 446 亿、Lambda 413 亿）。

这份 996 页的文件里，"KV cache" 出现 0 次，"KV" 作为独立单词出现 0 次，"prefill" 0 次，"SGLang" 0 次，"vLLM" 0 次，"Mooncake" 0 次，"RDMA" 0 次，"tenant isolation" 0 次。

我是用两种方式交叉验证的：一种是把 HTML 标签剥掉抽纯文本，一种是在原始 HTML 里直接做字符串计数。两种方式的结果一致。

同一天，一个跑在 SGLang 上的模型发生了跨租户数据泄漏，155 条响应里混进了别人会话的内容。

把这两件事放在一起，指向的结论就很难躲了：AI 产业正在把推理基础设施当成可以采购的商品，但它在软件层面还是共享内存里的一块裸页。 商业侧算力已经从「产能」变成了「负债」，技术侧它还是「一块没人认领的 GPU 显存」。

而这两侧，本该由同一份文档连接起来。它没有。

1. 一份 996 页的招股书，怎么把「共享内存」写没了

先看这份文件的财务骨架。这些数字全部来自 anthropicpbc-sx1.htm 原文的合并损益表，单位是百万美元：

项目 2023 2024 2025 2025 上半年 2026 上半年
营收 41 386 4,585 1,163 16,286
算力与基础设施 433 2,522 7,326 2,334 8,945
人员 95 454 1,839 538 3,152
总运营费用 592 3,366 12,645 3,298 16,979
运营亏损 (551) (2,980) (8,060) (2,135) (693)
可转债/SAFE 公允价值变动 (1,045) (5,434) (34,308) (10,942) (72,388)
净亏损 (1,531) (8,309) (41,965) (12,969) (80,748)

注意一件事：2026 上半年净亏损 807 亿，这个数字里绝大部分不是经营亏损。经营亏损只有 6.93 亿。剩下的 800 亿是「可转债、衍生负债和 SAFEs 的公允价值变动」——文件自己解释得很清楚，这项是因为企业估值上涨产生的会计变动，不是现金流出。

所以你在新闻里看到「上半年净亏损 807 亿美元」这种标题，会被严重误导。真正烧掉的是算力：896 亿是六个月的实际算力账单。

而这份文件最狠的一行不在损益表里，在第 171-172 页的「基础设施服务安排」。逐字引用：

In March 2026, we entered into an agreement with Google, which was subsequently amended between May and August 2026, and pursuant to which we committed to spend at least approximately $114.5 billion between April 2026 and July 2033, regardless of actual usage. If our actual spend falls short, we must pay Google the difference as a true-up subject to certain adjustments and exceptions if available.

Amazon 那笔是同样的措辞，1100 亿，期限到 2036 年 4 月。Microsoft 那笔 449 亿，2025 年 11 月签的。

"regardless of actual usage"（不论实际使用量）加上 true-up（差额补缴）。 这不是采购，是包年包月买流量，而且不许退。Google 那笔还额外承诺了 2028 到 2031 年追加 TPU 算力，金额估计 1250 亿到 1500 亿，这个数字连合同承诺表都没进。Broadcom 那边是五年期融资租赁，租金合计 1612 亿，同样不可取消。AMD 的 Helios 机架首批产能，文件估「超过 200 亿美元」。

我把六笔具名的基础设施协议加总：

114.5 (Google) + 110.0 (Amazon) + 120.5 (SpaceXAI) + 44.9 (Microsoft)
+ 44.6 (Nscale) + 41.3 (Lambda) = 475.8 十亿美元

加上 Broadcom 租赁 161.2 亿、额外 TPU 1250-1500 亿、AMD 200 亿以上，总量在 6200 亿到 6500 亿美元这个量级。

对着 2026 上半年 162.86 亿的营收看：这相当于 29 倍半年收入。年化之后接近 19 倍。

HN 上有个叫 dyslexit 的用户把这份表列了出来，还多加了一笔 Broadcom 161.2 亿，结论是「十年摊下来大约每年 637 亿，但大部分比这更早到期」。这条评论下面有个叫 extraextra 的说了一段我觉得比原文更值得记的话：

First of all, revenue exceeds compute just for the most recent 2 quarters. Before that, revenue was not exceeding compute. With 500 billion $ in commitments over the next decade, the compute bill will start increasing rapidly and the new commitments are not at the old prices, they're at higher prices.

他说得对，而且这一点在招股书里没有明说。承诺是照着今天的算力价格签的，如果 AI 训练和推理的效率继续以过去一年的速度涨，这批固定支出就成了模型效率提升的负债。 招股书里 Anthropic 自己的说法是正面的：「Our compute efficiency drives more intelligence from research and model development」，收入同比涨 1368%，算力费用同比涨 300%。这个比率漂亮得很。但如果效率提升的速度放缓呢？如果毛利率被这个比率绑架了呢？

有意思的是，文件里承认收入结构变了，但没给出任何关于「服务承载层」的描述。招股书里 "inference engine" 只出现 1 次，"serving" 出现 43 次，"data center" 出现 124 次，"GPU" 出现 24 次。这些词全部指向「我们买了很多硬件」，没有一次指向「我们怎么保证一个用户看不到另一个用户的内存」。

这不是遗漏，这是行业现状的缩影。在推理引擎这一层，今天还没有值得写进招股书的标准实践。 因为它压根没有一个行业公认的安全模型。

2. 出事的那一行代码，第 1659 行

Cloudflare 那篇披露写得很克制，但它把机制交代得比我见过的任何一次事故复盘都清楚。我把 SGLang 的 python/sglang/srt/managers/schedule_batch.py 拉下来逐行读了，这个 bug 的形状比论文里描述的还干净。

先看它怎么出事的。

Cloudflare 在 Workers AI 上用 SGLang 跑 GLM 5.3，架构是分离式 prefill/decode：prefill 节点处理 prompt 算出 KV cache，通过 RDMA（经 Mooncake）传给 decode 节点生成。

配置上有个不匹配：他们给 GLM 5.3 开了 1,048,576 token 的上下文窗口，但 prefill GPU 上的 KV cache 池只装得下 681,280 token。

按 Cloudflare 自己的说法，他们上线前就知道这个不匹配。他们指望引擎会对处理不了的 prompt 返回错误。长期上下文测试返回的是成功状态码、正常的流式 body、没有错误帧。于是他们相信了。

问题在于：prompt 超过 681,280 token 时，SGLang 的调度器会拒绝这个请求。拒绝走的是 Req.set_finish_with_abort()，这个函数把 prompt 换成一个 1 token 的占位符，让请求能「排干」而不占真实显存。单节点部署下这没问题：占位符跑一下，batch 结束，客户端收到错误。

分离式部署下出事了。Cloudflare 的原文：

In disaggregated mode such as we operate, the admission queues on both prefill and decode checked whether a request was finished, not whether it was rejected. A rejected request reported itself as live.

现在看源码。schedule_batch.py 第 1657 到 1659 行：

def finished(self) -> bool:
    # Whether request reached finished condition
    return self.finished_reason is not None

再看第 1186 到 1189 行的字段声明：

# If we want to abort the request in the middle of the event loop,
# set to_finish instead of directly setting finished_reason.
# Note: We should never set finished_reason in the middle, the req will get filtered and never respond
self.to_finish: Optional[BaseFinishReason] = None

再看第 2221 到 2238 行的拒绝函数：

def set_finish_with_abort(
    self,
    error_msg: str,
    status_code: int = HTTPStatus.BAD_REQUEST,
    err_type: str = "BadRequestError",
):
    ...
    self.origin_input_ids = array(
        "q", [0]
    )  # set it to one token to skip the long prefill
    self.return_logprob = False
    self.logprob_start_len = -1
    self.to_finish = FINISH_ABORT(error_msg, status_code, err_type)

这就是全部。 set_finish_with_abort 把错误写进 to_finish，把 origin_input_ids 截成一个 token。而 finished() 只看 finished_reason。to_finish 不是 finished_reason，所以 finished() 返回 False。

被拒绝的请求，在 admission queue 眼里，是一个活着的请求。

于是完整链条是这样走的：

  1. Bootstrap：router 把 prompt 长度告诉 decode 节点。decode 按 8 个 KV page 给这个请求预留空间。
  2. Prefill admission：prefill 的准入队列检查 req.finished() 是 False，于是放行了这个已经被拒绝的请求。
  3. Prefill forward：origin_input_ids 已经被换成了 1 token 的占位符，prefill 对着这个占位符跑了一次毫无意义的 forward pass。
  4. KV transfer：prefill 发出 1 个 page 的 KV，信号「传输完成」。
  5. Decode admission：decode 的队列做同样的 finished() 检查，也放行。
  6. Decode attention：decode 开始生成，attention 读全部 8 个预留 page。只有 P0 是这次请求写的，P1 到 P7 还是上一个请求留下的东西——别人的 prompt 和别人的生成内容。
  7. Response：客户端拿到 HTTP 200，不是 400。prompt_tokens 对得上那个超长 prompt，回复语法通顺，但里面混着其他用户 KV page 里的内容。

第 7 步有个细节我反复看了两遍：Cloudflare 说这个响应「arrived faster than an 8-page prefill should take」（比 8 个 page 的 prefill 应有的耗时更快）。因为它只算了 1 个 token 的 prefill。

我顺手去翻了 SGLang 的 issue 区。这个 bug 早在 2026 年 7 月 6 日就被人报了，issue #30233，标题是：

[Bug] PD disaggregation: aborted prefill requests (input too long) cause decode to generate garbage from incomplete KV cache

那个 issue 里的复现步骤写得比很多官方文档都清楚，关键参数 max_total_num_tokens = 284928 (determined by mem_fraction_static)。issue 下面只有 1 条评论，2026 年 9 月 5 日关闭。

从 7 月 6 日有人报告，到 10 月 26 日协调披露，中间隔了 112 天。 期间 Cloudflare 的 GLM 5.3 是 8 月 27 日上线的，暴露窗口从上线当天就开始了。

3. 22 个 PR，一半在修「页的所有权」

Cloudflare 和 SGLang 团队（RadixArk）的修复规模，我按官方 PR 表格逐条数了一遍：Incident 类 2 条、Race 类 9 条、Lifetime 类 2 条、Observability 类 3 条，一共 16 条已合入，加上表格里列的 PR 总共 22 个编号，除了 1 条（#46435，还在 draft）之外全部进了 v0.5.22。

版本发布时间线我用 GitHub API 拉了：

v0.5.20   2026-09-18   ← #36988 退役被中止的 prefill 结果
v0.5.21   2026-10-02   ← #38935 在 admission 就拒绝 + #39500 KV 传输校验和
v0.5.22   2026-10-19   ← #41612 / #43719 / #37077 / #36612 / #43562 / #41128

几个关键的 PR 我读了原始描述。

#38935（已合入，9 月 16 日，作者 ShangmingCai）：这个 PR 的作者自己写了段话，我觉得比整个 Cloudflare 博客都诚实：

This is a waste-and-latency fix, not a correctness fix. The stale-KV and wrong-status symptoms this change was first written against are pre-#36988 and do not reproduce on main — an earlier revision of this PR description claimed otherwise and was wrong.

翻译过来：这个 PR 最初以为自己修的是「陈旧 KV 和错误状态码」，后来发现那是因为 #36988 已经先修掉了，所以它现在修的是「浪费和延迟」：被拒绝的请求还在白白走完 bootstrap 握手、预留 metadata buffer、初始化 RDMA sender、对占位符跑 forward pass。

一个 PR 作者主动在自己的 PR 描述里承认前一版描述写错了，这在开源项目里不常见。

#38704（未合入，作者 kflansburg，就是 Cloudflare 那位安全工程师本人）：这是 Cloudflare 自己提的补丁，但没有合进 SGLang 主线。它做了两件上游后来用别的方式做了的事：admission 层保留 pending error 跳过分配，以及「Publish logical KV sequence coverage in spare metadata slot 7」，把逻辑 KV 序列覆盖率塞进 metadata 的空槽位，decode 侧用它校验实际收到的 token 数是否等于它预留的数。

这个设计想法很好，但没进主线。Cloudflare 在博客里也承认了：「We are working with the SGLang team to build a production version into the engine that works across every model, rather than maintaining Cloudflare-specific patches.」

#36988（已合入，9 月 6 日，作者 mickqian）：修的是同类问题的另一个面。VLM encoder 失败会在 KV block 已经分配之后中止请求，但完成的 GPU 结果照样回来，导致已中止的请求占着 KV/Mamba 状态，下一个空闲的 InvariantChecker 报出精确的泄漏位置然后重启调度器。这个 PR 的描述里有一句很硬：

No exception is caught around InvariantChecker; any remaining accounting bug still terminates loudly.

宁可响亮地挂掉，不许静默地算错账。 这是正确的取舍。

剩下那些 Race 类 PR 我不逐个展开了，但分类本身就说明问题：9 条里全是「page 被 A 释放的同时 B 还在读它」这类所有权竞争。Cloudflare 自己在博客里归纳成两类原因：

The first is page lifetime within a single node. Several tasks on a decode node can hold the same page at once: token generation, offload to host memory, the KV transfer receiver, and the abort and error paths. If one of them frees the page while another is still using it...

The second is a race across nodes. When a request is aborted while prefill is still writing its KV cache to decode over RDMA, the writes already sent cannot be recalled.

这两类都是「引用计数错了」，不是「权限判断错了」。 KV page 是 GPU 显存里的固定大小页，分配和释放之间没有所有权令牌。它靠调度器的簿记来保证不被人提前释放。簿记一旦有一个分支漏了，别的请求的密钥和值就进了你的上下文。

Cloudflare 的最终答案叫「完整性靠构造」，思路是：每个物理 KV page 带一个 tag，page 被重新分配时 tag 就变；每个请求记录它期望的 tag 集合；decode 读缓存之前先核对映射，对不上就只让这一个请求失败，不返回别人的数据。

他们夏天做了原型，8 月发过文章。实测代价：吞吐和尾延迟的不到 1%。8 月中旬在 GLM 5.2 上测过，但因为可靠性问题很快关掉了。而且原型绑定在特定的 attention backend 和模型架构上，做不到通用。

也就是说，一个已经被验证「几乎零成本」的方案，因为可靠性问题被搁置了，而这次事故恰好证明它才是能根治的方向。

4. 「我们只测了状态码」——这句话比 155 这个数字更值得记

Cloudflare 在复盘里自己认了一条 Testing gap，写得没有任何修辞：

This was one critical gap in our testing: we only validated HTTP response codes and engine performance at long contexts, without validating model output and coherence.

只验证 HTTP 状态码和引擎性能，没有验证模型输出和连贯性。

这段话我读了三遍。因为它精确描述了一种极其常见的工程盲区：在一个「返回 200 就等于成功」的接口约定下，你的测试会在一个返回错误内容的接口上全绿。

而且他们知道 KV pool 小于 context window，他们选择相信引擎会拒绝。这是一次典型的「用一层的正确性担保另一层」。引擎确实有拒绝路径，但拒绝路径的实现恰好有 bug。

有意思的是，Cloudflare 在做这个判断时的推理链是这样的：「long-context 测试返回了成功的 HTTP 状态码和流式 body，没有错误帧」→ 「所以引擎能优雅处理 pool 和 context 的差异」。这个推理在单节点部署下是成立的。bug 只在分离式部署下才暴露，而分离式部署是他们后来为了性能才上的。

HN 评论区里有个叫 Graziano_M 的把这一点说透了：

Sounds like they are saying they tested with a long prompt and just tested for a failure, but the test likely would have seen that same KV cache leakage and just interpreted it as success.

测试看见了泄漏，把它当成了成功。 因为泄漏的内容语法通顺、token 数对得上、状态码是 200。

HN 上还有几条评论我觉得对做基础设施的人有直接价值。

thehamkercat（顶层）：「Other providers probably don't even know/care that this is happening.」

6thbit：「Last year it happened to me more than once that dictating something in chatgpt would become a completely different message after processing, not in a misheard type of way but just a separate conversation more easily explained by the same type of KV cache issue here.」

这条我要单独说，因为它是今天最难验证也最值得警惕的一条。如果 6thbit 说的是真的，那么「ChatGPT 偶尔会返回别人会话的完整对话」这件事，已经在真实用户手里发生了一年多了，而且从来没有被当成安全事故上报过。

我没法验证这条。但我可以说清楚它为什么可能：ChatGPT 的多轮对话有很长的公共前缀，prefix cache 命中率极高，这种架构下 KV page 的跨请求复用是默认行为而不是例外。问题从来不是「会不会复用」，是「复用之后能不能保证读到的是自己的」。

0xbadcafebee 说了一句所有做 SaaS 的人都该记住的话：

I kind of forgot about the shared tenancy attack model. I think I was assuming/hoping the software was magically isolating my tokens, when in reality that's impossible for shared tenants. There's whole classes of attacks on things like shared cache, before we get to the LLM-specific features and potential bugs. Enterprises with highly sensitive data should really be on non-shared hosts.

共享租户的攻击面在 LLM 出现之前就有（共享缓存、共享内存），但 LLM 把它的严重程度拉高了一个量级——因为泄漏出来的不是一段 HTML，是一个模型在特定上下文下的完整推理。

5. 同一份招股书，同一个矛盾

现在把 Anthropic 的文件和 Cloudflare 的事故放在一起看。

Anthropic 的模型跑在什么上面？招股书里说了 4758 亿美元的具名承诺 + 1612 亿的 Broadcom TPU 租赁 + 1250-1500 亿的额外 TPU + 200 亿以上的 AMD。这些算力最终都要跑在某个推理引擎上。 文件里 "inference engine" 出现 1 次，不是在说技术栈，是在别的语境。

而承载这 4758 亿美元的引擎，如果它是 SGLang、vLLM 或者任何共享内存池的实现，那么它的核心数据结构是一块由调度器簿记所有权的 GPU 显存页。这块内存里装的东西是：模型的注意力键值，也就是模型在推理时读到的「你的上下文」。

模型上下文 = KV cache。而 KV cache 是共享的。

招股书用了 996 页来讲自己的安全性、负责任的扩展策略、Long-Term Benefit Trust、创始人 80% 股权的慈善承诺、Class T 股票的多数董事选举权。它讲得都挺好。

但它没有一句话讲，一个用户在 700k token 的长文档分析请求里，怎么保证不读到另一个用户 700k token 长文档分析的残留。

我说这不是恶意。招股书是财务文件，不是技术设计文档，要求它披露 KV cache 布局是不合理的。我要说的是另一件事：

当一家公司把 6000 亿美元押在「推理基础设施」上，而这份基础设施在软件层面是一个「共享内存池 + 调度器簿记」的时候，它的风险披露里出现了一个结构性空洞。 空洞的位置不在模型能力、不在监管、不在竞争，而在承载层。

同一天 Anthropic 招股书里另一段话，跟今天这个主题意外地呼应：

Each generation of Claude models has expanded along multiple dimensions: ... the duration and autonomy of the work they can sustain...

Ultimately, millions of Virtual Collaborators can run in parallel... what we refer to as a country of geniuses in a data center, available to every organization and sector of the economy.

「数据中心里的天才之国」。 几百万个虚拟协作者并行跑不同的问题。

从推理引擎的角度看，「几百万个并行协作者」这个承诺的技术含义是：几百万个并发 KV cache 池共享在一批 GPU 显存里，各自的 page 靠簿记区分所有权。 而今天出事的那个 bug，本质就是簿记漏了一个分支。

「国家」这个隐喻还有另一层意思：国家是有边界的。当几百万个并发协作者共享一片显存，而边界的执行者是一行 return self.finished_reason is not None，那这个国家的边界就是由一个布尔表达式维持的。

6. 微软那 60000 人，和这一切的关系

第三件事：微软对大约 60000 名员工开放自愿离职方案。HN 819 分、732 条评论。36氪的 8 点 1 氪也把它列为当日热点之一。

有一条 HN 评论我觉得比新闻本身更有信息量：

But like if your company is making money over foot you don't typically cut staff by 25%. You could just as easily do a hiring freeze and get out ahead of it... The move is management saying they are overstaffed for the work they think they need.

But you have to realize what this means. It's basically entire divisions that the company no longer needs because agents are doing the work.

把这条和 Anthropic 的「数据中心里的天才之国」放一起看，微软的动作是成本侧，Anthropic 的叙事是产能侧，而两者的交点是同一个东西：agent。

Anthropic 的招股书里有一个很具体的数字，我觉得是整个文件里最能说明问题的一处：

in the three months ended September 30, 2026, Claude Enterprise users who did not use Claude Code spent less than $75 per month on average, while the top 5% of Claude Enterprise users who used Claude Code spent approximately 20 times that amount.

不用 Claude Code 的企业用户，人均月消费不到 75 美元。用 Claude Code 的前 5% 用户，人均月消费是前者的 20 倍。

这个 20 倍的差距意味着什么？意味着 Anthropic 的收入结构里，绝大部分金额来自极少数「让 agent 自己跑长任务」的重度用户。而重度用户跑长任务，意味着：

  • 上下文窗口开到几十万到一百万 token（正好是今天出事那个阈值）
  • 长时间运行的 session
  • 高频的 prefix cache 命中
  • KV cache 池必须开得足够大，才能装下这些请求

我把这个链条串起来了：

Claude Code 这类 coding agent 的重度使用，会把推理引擎推向「必须把 KV pool 开到接近 context window 尺寸」的配置——因为用户真的会往里塞几十万 token 的代码库。而 KV pool 一旦小于 context window，拒绝路径就会被触发。拒绝路径的实现质量，直接决定了有没有用户的数据泄漏。

所以微软裁员和 Anthropic 上市不是同一件事，但它们共享同一个技术前提：agent 承担了越来越多真实工作负载，而这个工作负载的形态（超长上下文 + 长 session + 高前缀复用），恰好是推理引擎内存隔离最容易出错的形态。

雷峰网这篇值得单独说一句：这是今天唯一一篇中国媒体（10 月 26 日）跟国际技术圈撞上的报道：

DeepSeek 近日全面开源推理框架 DeepInfer。继模型权重和 FlashMLA、DeepGEMM 等算子库之后，他们把模型运行的链路开放了。其中的 FlashMLA，有工程师在芯片上逐行手调的版本，算子性能跑到了硬件极限的 90% 以上……而这个极限，同一周就被 AI 刷新了。

FlashMLA 手工调优到硬件极限的 90%，然后被一个完全由 AI 写的算子（ForgeKernel）超越——登顶 SOL-ExecBench FlashInfer-Bench 合集第一和昇腾 CANNBench A3 硬件榜第一，基准加速比 1.835×，领先第二名 25%。

这里有一个值得琢磨的反差：算子优化这一层，AI 已经能超过人类专家的手工调优。 同一周，承载算子的推理引擎这一层，一个布尔判断写错了，155 个用户的数据混在了一起。

算子层在往「AI 超越人类」推进，内存管理层还卡在一个 finished_reason is not None 上。 这两件事的距离，比我以为的要远得多。

7. 如果你今天就要动手

我把这几天的材料压成一份能直接执行的清单。这不是通用建议，每一条都对应上面某一个具体的事故或数字。

给跑自建推理引擎的人（自建 vLLM/SGLang 的人）

第一件事，去你部署日志里捞出实际的 KV pool size。SGLang 启动时会把选定的 KV pool size 打进日志，同时有 metric 暴露。把这个数字和你的 context length 对一遍。 Cloudflare 上线前就知道这两个数不匹配，但他们没有做这个检查。每次改权重、改量化、改并行度、改 memory fraction 之后都要重新对一遍——因为 pool size 不是配置项，是 SGLang 启动时「加载完模型权重后剩下的显存」算出来的。

第二件事，量一下你的 KV pool 是不是真的 ≥ context length。Cloudflare 修完配置后，pool 撑到大约 204 万 token，是 context length 的两倍左右。不是刚好装下，是留一倍余量。因为 pool size 会随量化方式、张量并行度、CUDA graph 大小变化，这些都不是你能一眼看出来的。

第三件事，升级到 v0.5.22 或更高。#36988 和 #38935 都在里面。这意味着「超长请求在 admission 阶段就被拒，不会走到 KV 传输」。这是引擎侧的兜底——为的是你第一步那个检查万一做错的那一天。

第四件事，两个角色都打开 deferred KV release，并给 Mooncake 传输批次设上限。v0.5.21 之后 decode 侧默认开了，但 prefill 侧要确认。

第五件事，如果你的模型架构支持，开 --disaggregation-enable-kv-checksum 和 --kv-canary。注意 Cloudflare 明确说了这两个不覆盖所有模型架构——GLM 5.3、GLM 5.3 Flash、DeepSeek V4 当时还没覆盖。去日志里确认请求真的被校验了，别把开关打开就当有校验。

第六件事，检查你的负载均衡器。Cloudflare 改了一件事：客户端断开不再中途 abort 请求，而是持有 prefill 连接直到 prefill 完成、持有 decode 连接直到第一个 token 出来。因为 abort 会触发跨节点协调，而跨节点协调就是那些 race 的温床。

第七件事，如果你有多条并发路径，统一用一个「canary」标记做交叉验证。这个是研究者 Gadi Evron 的方法，Cloudflare 复现时用的也是它：在请求 A 里写入一个唯一的标记，在请求 B 里检查它有没有泄漏出来。 这是目前唯一能确定性地验证「KV 隔离没坏」的手段。

给用云 API 的人

如果你的数据敏感到「泄漏 155 条里的任何一条都算事故」，Cloudflare 评论里那条建议是对的：独占部署，不要共享租户。 这不是技术洁癖，是在共享 GPU 显存池上，「引擎正确实现了所有权簿记」这个前提没有第三方背书。

同时记住 6thbit 那条评论。如果你在 ChatGPT 或者任何产品里遇到过「输入的 A，回来的像是 B 的对话」，那不是你手滑，那是可报告的事故。Cloudflare 这次是研究者主动报出来的，Cloudflare 评论里还有个人（reassess_blind）讲自己在某个浏览器测试服务的 iOS 虚拟机里拿到了别人粘贴的凭据，报告之后对方没有赏金项目，只说可以寄一封感谢信。这类报告历史上得不到响应，所以你自己要留证据：截屏、记时间、记具体输入。

给做 agent 产品的团队

微软那条新闻不是预测，是已经发生的事实。对 Claude Code 这类产品的重度用户来说，人均月消费是用普通企业用户的 20 倍。这 20 倍的差额里，有一部分是超长上下文和长 session 贡献的——而这正是推理引擎最容易出错的形态。

你的产品形态（长上下文、长时间运行、高前缀复用），会系统性地把上游引擎推向「KV pool 开到接近 context window」的危险配置。你在自己代码里看不到这一层，但你的成本结构和你的 SLA 都建立在这一层之上。

最后一条，也是我觉得今天最重要的一条

如果你是公司的技术负责人，去问你的模型服务商一个问题：你们的 KV cache 跨请求隔离是怎么保证的，有没有人验证过。

你不会得到一个让人满意的答案。大概率是「我们用了行业标准的引擎」。而今天的材料证明了，行业标准引擎在这个位置有一行代码的判断写错了，写错了 112 天没人修，修了之后 155 条响应已经出去了。

8. 三份文件放在一起看

我把这三份材料的性质并排放一下：

Anthropic S-1 Cloudflare 事故报告 SGLang issue #30233
日期 2026-10-26 2026-10-26 2026-07-06
体量 996 页 一篇博客 1 条 issue，1 条评论
视角 商业与财务 事故与工程 缺陷与复现
提到 KV cache 0 次 全篇核心 全篇核心
提到租户隔离 0 次 明确「tenant isolation issue」 隐含

同一件事的两端。

一端是资本在为一个承载层写 6000 亿美元的承诺，那份文件对承载层的内存所有权只字未提。

另一端是一个 7 月 6 日就该被发现的布尔判断错误，它在 112 天里安静地待着，等到它在一个 1M context 的模型上被触发，等到有人拿两把不同的钥匙去敲同一扇门。

我今天想说的其实就一句话：

当「推理基础设施」从成本项变成负债项的那天，承载层就从一个工程问题变成了一个财务风险。 Anthropic 在招股书里把它当产能写，Cloudflare 在事故里把它当 bug 修。两种视角看到的是同一块 GPU 显存。

而这块显存上，跑着 155 份本不该出现在那里的别人的会话；同时它承载着 4758 亿美元不可撤销的采购承诺、和一个自称「数据中心里的天才之国」的产品线。

账面上的每一个 token 都有价格。显存里的每一个 page 现在也有价格了——是别人的隐私。

附：今天这篇的所有一手来源

源码与一手缺陷报告

  • sgl-project/sglang / python/sglang/srt/managers/schedule_batch.py — 第 1657-1659 行 finished()、第 1186-1189 行 to_finish 字段声明、第 2221-2238 行 set_finish_with_abort()（我实读源码，逐行核对）
  • SGLang issue #30233（2026-07-06 报告，2026-09-05 关闭，含完整复现步骤与 max_total_num_tokens = 284928 参数）
  • SGLang PR #36988（已合入 v0.5.20）、#38935（已合入 v0.5.21）、#38704（Cloudflare 提交，未合入主线）
  • SGLang v0.5.20 / v0.5.21 / v0.5.22 release notes（GitHub API 实测发布时间）

安全事件

  • Cloudflare Blog《Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang》（2026-10-26，全文实读，含 16 条已合入 PR 表格、时间线、22 个 PR 编号）
  • 事故时间线（UTC）：8 月 27 日上线即暴露 → 9 月 8 日 23:11 收到 HackerOne 报告 → 9 月 9 日 13:22 声明事故 → 14:00 模型转私有 → 14:52 全部 prefill 节点改配置 → 19:04 重建部署 → 19:40 恢复公开 → 9 月 10 日与 RadixArk 会面 → 10 月 19 日 v0.5.22 → 10 月 26 日协调披露

财务与上市

  • Anthropic PBC S-1（SEC EDGAR，CIK 2130357，2026-10-26 提交，996 页，全文实读）— 损益表五年五期数据、六笔基础设施协议、true-up 条款、Broadcom 五年融资租赁 1612 亿、额外 TPU 1250-1500 亿、AMD 200 亿+、5,300 名员工、TTM 人均营收 660 万美元、NRR 约 900%、Claude Code 用户消费倍数

第三方讨论

  • HN《Cross-request KV cache exposure in the GLM-5.3 Workers AI model (155 responses)》（96 分 / 10 条，item 50252159）— thehamkercat、6thbit、kami23、Graziano_M、jacquesm、0xbadcafebee、reassess_blind、kflansburg（Cloudflare 作者本人回复）等
  • HN《Anthropic S-1》（1521 分 / 1485 条，item 50242939）— extraextra 的收入/算力比率分析、dyslexit 的承诺总额表、nonethewiser 的估值测算、jmuguy 的 Amazon 类比
  • HN《Microsoft offers mass buyouts for roughly a quarter of its workforce》（819 分 / 732 条，item 50245524）

中文源

  • 雷峰网《DeepSeek 开源看家算子的同一周，AI 超过了它》（2026-10-26）— FlashMLA 手工调优至硬件极限 90%+、ForgeKernel 双榜登顶、加速比 1.835× 领先第二名 25%
  • 36氪《8点1氪丨Anthropic正式提交IPO申请》（2026-10-27）— 中文侧对 S-1 的报道