notes: GLM 双链路延迟排查卡

[joyehuang]

285 次调用统计（中位 2.2 倍/P90 5 倍差） / 百 token 卡千秒的排队证据 / 实时探测交叉验证 / 恢复通知式监控。

止步 PR 不合并。bun run check 0 errors。

---

Summary by cubic

Adds a research note documenting a 2.2x median latency difference between Command Code and OpenRouter routes for the same GLM model, based on 285 real calls, with evidence pointing to gateway queuing and a monitoring plan. Also fixes the neon query result cast in SiteStats.astro to match the existing type pattern.

^{Written for commit f96c62e. Summary will update on new commits.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
blog	Ready	Preview	Sep 1, 2026 6:33pm UTC

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/content/notes/0926-glm-dual-route-latency.md">

<violation number="1" location="src/content/notes/0926-glm-dual-route-latency.md:32">
P3: 同一句里的概括与具体数据互相矛盾：1258s≈21 分钟、1283s≈21.4 分钟，不是“十几分钟”；而“只吐了不到 200 token”又和随后“一连串 70~600 token”里的 600 相冲突。建议把概概括改成与数据一致的表述，避免读者按错误口径引用这个“排队窗口”证据。</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: 同一句里的概括与具体数据互相矛盾：1258s≈21 分钟、1283s≈21.4 分钟，不是“十几分钟”；而“只吐了不到 200 token”又和随后“一连串 70~600 token”里的 600 相冲突。建议把概概括改成与数据一致的表述，避免读者按错误口径引用这个“排队窗口”证据。

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/content/notes/0926-glm-dual-route-latency.md, line 32:

<comment>同一句里的概括与具体数据互相矛盾：1258s≈21 分钟、1283s≈21.4 分钟，不是“十几分钟”；而“只吐了不到 200 token”又和随后“一连串 70~600 token”里的 600 相冲突。建议把概概括改成与数据一致的表述，避免读者按错误口径引用这个“排队窗口”证据。</comment>

<file context>
@@ -0,0 +1,64 @@
+
+## 「丢包」的直接证据
+
+最慢的单次调用呈现独特模式：**只吐了不到 200 token 却耗了十几分钟**——15 token 花 1258 秒、88 token 花 1283 秒、一连串 70~600 token 各卡 1000 秒以上（连续的「排队窗口」）。
+
+推理排除了模型本身：OpenRouter 底层是同一个 Z.AI 官方端点，跑得飞快。症状是**随机的大延迟毛刺**，指向 CC 网关层的排队/限流/转发问题。
</file context>

Suggested change

	最慢的单次调用呈现独特模式：**只吐了不到 200 token 却耗了十几分钟**——15 token 花 1258 秒、88 token 花 1283 秒、一连串 70~600 token 各卡 1000 秒以上（连续的「排队窗口」）。
	最慢的单次调用呈现独特模式：**只吐了几十到几百 token 却耗时 20 分钟以上**——15 token 花 1258 秒、88 token 花 1283 秒、一连串 70~600 token 各卡 1000 秒以上（连续的「排队窗口」）。