GLM-5.3 Workers AI 跨请求缓存暴露怎么排查-TKMiss Notes

如果请求 A 的独有内容出现在请求 B 的响应中，应立即按潜在的 Cross-request KV cache exposure 处理：暂停官方公告涉及的 GLM-5.3 Workers AI 模型或路由，保留脱敏后的请求、响应、时间戳和平台请求标识，再根据 Cloudflare 官方修复说明核对受影响范围与处置状态。

这类异常不一定伴随 HTTP 错误，状态码正常也不能证明请求隔离正常。修改 CORS、JSONP 或浏览器缓存，解决的不是服务器内部的 KV Cache 隔离问题，不能替代停用、迁移和隔离复测。

响应里出现别的请求内容，怎么确认是跨请求 KV Cache 暴露

响应里出现“前文”并不直接等于缓存串用。同一会话本来就可能携带多轮历史，RAG 会把检索片段放进上下文，应用中间件也可能注入工具结果或模板内容。应先核对这些来源，再使用独立会话和随机唯一标记做对照。

KV Cache 保存注意力计算所需的 Key、Value，用于避免解码阶段重复计算；Prefix Cache 通常只复用匹配的公共前缀。因此，两个请求使用相同 system prompt 并不构成异常证据，后缀不同且互不相关的请求不应因此继承对方内容。

排查示例使用 messages 请求体的 Workers AI 端点。完整模型端点和鉴权头必须按 Cloudflare 当前官方文档填写，不要自行猜测 GLM-5.3 的模型 slug；若当前端点采用不同请求体，只替换请求体构造部分。

export MODEL_ENDPOINT='<按官方文档填写完整模型推理端点>'
export AUTH_HEADER='<按官方文档填写完整鉴权请求头>'

MARKER_A="A-$(openssl rand -hex 16)"
MARKER_B="B-$(openssl rand -hex 16)"
PREFIX='kv-isolation-shared-prefix-v1'

jq -n --arg p "$PREFIX" --arg m "$MARKER_A" \
  '{messages:[
    {role:"system",content:$p},
    {role:"user",content:("仅返回此唯一标记："+$m)}
  ]}' > /tmp/kv-a.json

jq -n --arg p "$PREFIX" --arg m "$MARKER_B" \
  '{messages:[
    {role:"system",content:$p},
    {role:"user",content:("仅返回此唯一标记："+$m)}
  ]}' > /tmp/kv-b.json

curl -sS "$MODEL_ENDPOINT" \
  -H "$AUTH_HEADER" \
  -H 'Content-Type: application/json' \
  --data-binary @/tmp/kv-a.json \
  -D /tmp/kv-a.headers \
  -o /tmp/kv-a.out &
PID_A=$!

curl -sS "$MODEL_ENDPOINT" \
  -H "$AUTH_HEADER" \
  -H 'Content-Type: application/json' \
  --data-binary @/tmp/kv-b.json \
  -D /tmp/kv-b.headers \
  -o /tmp/kv-b.out &
PID_B=$!

wait "$PID_A" "$PID_B"

# 先确认两个请求分别回显了自己的标记
grep -F "$MARKER_A" /tmp/kv-a.out
grep -F "$MARKER_B" /tmp/kv-b.out

# 再检查是否出现交叉标记；无匹配时不会输出内容
grep -F "$MARKER_B" /tmp/kv-a.out || true
grep -F "$MARKER_A" /tmp/kv-b.out || true

只有 A 的响应确实包含 A 标记、B 的响应确实包含 B 标记，后两条交叉检查才有判定价值。如果 B 的响应出现只属于 A 的随机标记，才形成有效的跨请求暴露证据。

这组测试还应改变前缀后重跑，并用不同用户或不同租户分别发送请求。常见验收组合是“相同公共前缀、不同后缀”“完全不同前缀”“同时发送多个请求”和“跨租户请求”。测试数据应全部使用合成标记，不要把生产环境中的秘密或个人数据放进复现样本。

确认串用后，先止损并划定影响范围

确认异常后，应立即暂停官方公告涉及的模型或路由，将业务迁移到公告确认不受影响且当前确实可用的替代模型或版本。若公告没有给出停用入口、迁移路径或替代项名称，应以官方说明为准，不要套用其他平台的开关或配置。

同时保存模型标识、请求与响应时间戳、平台实际提供的请求标识、账户或租户范围，以及经过脱敏的输入输出样本。排查记录中不要直接复制泄露的秘密、访问令牌或个人数据；浏览器缓存、本地缓存和 API Key 轮换都不能证明服务器端的 KV Cache 隔离已经恢复。

受影响模型、版本、路由和时间窗需要逐项对照官方修复说明。Hacker News 标题里的“155 responses”是热点帖的回复标注，不能写成 155 个受影响请求；官方没有公布受影响请求总数时也不要补写数字。

网上常见的 GLM-4.5 上下文长度、KV 头数量、FP8 配置和 vLLM 启动参数只对应其他模型与版本，不能套到 GLM-5.3 上；GLM-5.2 的 API 延迟或错误处理材料也不能解释本次事件。根因、具体处置动作和平台开关同样应以官方修复说明为准。

修复后怎样确认请求隔离已经恢复

按公告完成模型修复或服务恢复后，先确认测试使用的是官方指定的修复版本和路由，再重复执行“双唯一标记＋公共前缀＋不同后缀＋并发请求＋跨租户请求”的组合。测试顺序可以先串行排除会话与 RAG 回显，再并行发送多个请求，最后从独立租户重复验证。

验收不能只看 HTTP 状态码。每个响应都应包含本请求的随机标记，不能出现任何其他请求的标记；用于共享 system prompt 的场景，还要确认公共前缀命中没有把另一请求的独有后缀带入响应。测试结果应同时记录模型版本、路由、时间戳和请求标识，并与官方公布的修复状态对应。在官方修复版本和确认恢复的路由上完成并发复测后，应将结果作为通过结论留档。

文章版权归作者所有，未经允许请勿转载。

THE END