GLM-5.3-Flash 双链路排查：Command Code vs OpenRouter

日期：2026-08-27 ｜ 数据源：pi sessions JSONL（2026-08-26 ~ 08-27）+ 实时探测

一、会话数据统计

昨天到今天共有 6 个会话用到 glm-5.3-flash，其中走 Command Code 的请求 199 次，走 OpenRouter 的 86 次。统计口径为"每次 LLM 调用的纯间隔时间"（上一次事件结束 → 本条 assistant 消息落盘，已剔除 >10 分钟的跨工具执行间隙，但注意仍包含一部分 thinking 生成时间，两边口径一致、可对比）。

三个层面的差距：

• 中位延迟差 2.2 倍：CC 平均每次调用要近 18 秒才返回首段，OpenRouter 只要 8 秒。
• P90 差 5 倍以上：CC 有约 10% 的调用超过 98 秒，OpenRouter 的尾部几乎不存在（P90 才 18 秒）。这个尾巴就是"体感卡死/转圈很久"的来源。
• 吞吐差 3.3 倍：CC 端流式输出速率明显更慢。

二、"丢包"/停滞的直接证据

看最慢的那批单次调用，很多是只吐了不到 200 个 token 却耗了十几分钟级等待：

• 03:24:39 cmd-code：15 个 token 花了 1258 秒
• 02:52:37 cmd-code：88 个 token 花了 1283 秒
• 02:50:56 / 02:48:20：百来个 token 各花 1000+ 秒
• 18:52~18:54 一连串：每条 70~600 token 都卡在 1000 秒以上——这是一整段时间内连续被拖慢的典型"排队窗口"

这不像模型本身慢（OpenRouter 底层同是 Z.AI 官方，跑得飞快），而是 CC 网关层的排队/限流/转发问题：部分请求被长时间滞留，表现为随机的大延迟毛刺，正是你说的"丢包感"。

三、实时探测交叉验证

监控上线后跑了三次完全相同的探测请求（"Reply with exactly: OK"，几十个 token）：

第 1 次：CC 52.9s vs OpenRouter 4.9s 第 2 次：CC 32.1s（仅 2.2 tok/s）vs OpenRouter 2.2s（17.7 tok/s） 第 3 次：CC 2.0s（19.0 tok/s）vs OpenRouter 8.0s

同一个端点三次之间从 53 秒抖到 2 秒，方差极大；而 OpenRouter 三次都在个位数秒。结论：问题在 Command Code 链路（网关排队/不稳定），不在 Z.AI 官方模型本身。

四、监控方案（已上线）

部署了 glm-watch，每小时用相同的小 prompt 同时探测两条链路：

• 记录：延迟秒数、输出 token 数、tok/s、状态码，追加写入 ~/.config/glm-watch/log.csv
• 告警①（变坏）：CC 连续 2 次失败或非 200 → Telegram 推送"CC 链路异常"
• 告警②（恢复）：最近 6 次探测 CC 全部成功且中位延迟 < 25 秒 → Telegram 推一次"可以切回 cc-code/z-ai/glm-5.3-flash"，之后如再恶化会重置标记，下次恢复再次提醒（不会只提醒一次就沉默）
• 运行方式：launchd com.joye.glm-watch（RunAtLoad + 每小时），日志 /tmp/glm-watch.log

你不用做任何事：等收到 🟢 恢复通知时说一声，我就把 pi 主模型切回 cmd-code，省钱链路即恢复；在那之前 OpenRouter 继续（价格一样，只是不走套餐额度）。

五、结论

1. 定责明确：慢的是 Command Code 端（网关层），不是 Z.AI 官方——同样的模型名走 OpenRouter 快且稳。
2. 切到 OpenRouter 是对的，中位快 2.2 倍、P90 快 5 倍多。
3. 监控每小时自动跑，CC 恢复稳定（连续 6 次成功且中位 <25s）会主动通知你，届时无痛切回。