GLM-5.3-Flash 实测为何出现两种答案

智谱 Z.ai 在 8 月 26 日发布了 GLM-5.3-Flash。官方给出的定位很直接：这是 GLM-5 系列第一个原生多模态模型，总参数 3200 亿，每次只激活 180 亿，价格只有 GLM-5.2 的十分之一，多项编程与 Agent 评测已经接近 Claude Opus 4.8。

更有意思的是，大家其实已经提前用了一周。发布前，它以 ox-alpha 的匿名身份出现在 OpenRouter 和 OpenCode，免费开放给开发者测试。身份公开之后，社区留下了完整的 DeepSWE 运行、LiveCodeBench、前端生成、并行 Agent 和通宵开发记录。

我会把这些可检查的实测放在一起，看看为什么有人认为 GLM-5.3-Flash 已经可以替代 DeepSeek，也有人测完之后得出了相反结论，以及“Flash”到底快在什么地方。这里的“实测”来自公开社区记录，不是我本人运行的结果；每组数据都会保留原始来源。期望对大家有所帮助。

先看价格与官方成绩

GLM-5.3-Flash 的基本规格确实很激进。

项目	GLM-5.3-Flash
总参数	320B
激活参数	18B
模型层数	45
上下文	1M token
输入模态	文本、图像、视频
开放权重	MIT License

官方发布把它与 GLM-5.2、DeepSeek-V4-Vision-Exp、Opus 4.8、GPT-5.6 Terra 和 Gemini 3.7 Flash 放在同一张表里。几项和 Coding Agent 关系较大的结果如下：

Benchmark	GLM-5.3-Flash	GLM-5.2	DeepSeek-V4-Vision-Exp	Opus 4.8
Terminal Bench 2.1	84.3	81.0	83.9	85.0
DeepSWE v1.1	63.4	46.2	59.3	58.0
Toolathlon Verified	78.4	59.9	75.9	76.2
AutomationBench	48.8	26.2	38.8	41.0
Agents' Last Exam	26.3	20.4	27.3	27.0

单看这张表，GLM-5.3-Flash 在几项 Agent 任务上确实领先：Terminal Bench 略高，DeepSWE、Toolathlon 和 AutomationBench 的差距更明显。不过这些成绩由智谱发布，比较模型和运行参数也是厂商选择的。它们适合告诉我们“哪些方向值得测”，不能代替真实工作中的对照，更不能据此推导出社区已经形成一致评价。

目前更可信的独立参照来自 Artificial Analysis。它给 GLM-5.3-Flash 的 Intelligence Index 是 57，Time to First Token 为 1.47 秒，输出速度约 50.2 token/s。能力和价格处在很靠前的位置，但持续输出速度低于同规模开放权重模型约 67 token/s 的中位数。

换句话说，“Flash”首先指价格与计算效率，不一定代表文字生成特别快。

18B 激活参数如何撑住长上下文

GLM-5.3-Flash 不是把同一个模型缩小后换个名字。它重新设计了注意力结构，把线性注意力与稀疏注意力放在一起。

线性注意力通过状态建模处理附近的信息，计算量不会随着上下文长度快速膨胀；稀疏注意力再通过轻量索引，找回远处真正相关的内容。新的 IndexPool 会把四组 indexer key vector 加权压成一组，进一步减少一百万 token 上下文里的索引延迟与内存压力。

flowchart LR
    A[长上下文输入] --> B[线性注意力]
    A --> C[稀疏注意力]
    B --> D[附近依赖]
    C --> E[IndexPool]
    E --> F[远处相关信息]
    D --> G[当前 token 表示]
    F --> G

按照智谱公布的架构测量，相比 GLM-5.3，Flash 的每 token 注意力计算量降低了 3 倍，平均 KV cache 降低了 4.4 倍。它只有 45 层，GLM-4.5 则有 92 层；激活参数也从 GLM-4.5 的 32B 降到 18B。

这组结构差异能解释价格，却不能直接证明模型会写好代码。真正有参考价值的部分，在匿名测试期间留下的运行记录里。

完整 DeepSWE 跑了二十个小时

目前信息最完整的一组社区测试来自 MatchaOnMuffins/oxalpha。作者通过 OpenRouter 调用 stealth/ox-alpha，使用 pier 0.3.1、mini-swe-agent 和 Docker，跑完了 DeepSWE 的 113 个任务。

整次运行耗时 20 小时 39 分，最终解决 66 个任务，通过率为 58.4%。这个结果低于智谱正式发布时给出的 63.4%，但两组运行的入口、负载和细节未必完全一致，不能直接说哪一边“错了”。社区结果的价值在于，它公开了任务级记录和失败形态。

其中有两个数字比最终通过率更值得看：

• 80% 的任务完成了至少 90% 的 fail-to-pass tests。
• 约 9.7% 的任务因为工具调用格式错误而丢分。

第一点说明，不少失败并不是完全不会做，而是代码已经接近通过，仍差一个边界条件或局部修复。第二点则提醒我们，模型能力与 Agent Harness 的兼容性不能混成一个数字。模型可能已经找到正确方向，却因为工具调用 JSON、参数格式或结束条件不符合 Harness 预期而失败。

对实际开发来说，两种失败都意味着任务没有完成；对判断模型来说，它们又不是一回事。

裸代码生成没有同样亮眼

另一组可复现测试用了 LiveCodeBench v6。作者选择 175 道题，temperature 设为 0，每题只允许回答一次，代码需要在 20 秒内通过隐藏测试。

最终结果是 49/175，Pass@1 为 28.0%。按难度拆开：

难度	Pass@1
Easy	51.2%
Medium	30.8%
Hard	13.8%

测试者平时大量使用 DeepSeek V4-Flash，对 ox-alpha 的主观评价并不高。这与官方 DeepSWE 的强势结果形成了一个很重要的反差：GLM-5.3-Flash 的优势可能更依赖 Agent Harness、工具使用、长时间修改和测试反馈，并不等于它在一次性算法题上同样领先。

这也是为什么用三五道 LeetCode 题判断 Coding Agent 很容易失真。裸代码题检查的是一次生成能否得到正确答案；仓库任务还要检查文件、执行命令、读取报错、修改方案，再把测试跑到通过。两者都会写代码，但考察的不是同一种能力。

一次生成前端用了四分多钟

前端页面是最容易录屏展示的案例，也最容易只留下漂亮截图。一位日本开发者记录了 ox-alpha 生成完整 HTML 页面的过程：

项目	结果
请求状态	HTTP 200
总耗时	278.009 秒
Prompt tokens	497
Completion tokens	5,997
总 tokens	6,494
生成代码	585 行、15,200 字符

页面可以在浏览器中打开，但生成代码仍有需要修正的问题。这个案例没有证明 GLM-5.3-Flash 很差，反而说明应该如何记录前端实测：除了最终截图，还要保留总耗时、输出规模、浏览器错误、首次可用程度与修复轮数。

如果只截最终页面，四分多钟的等待和后续修复都会消失。可这些才是决定开发体验与总成本的部分。

便宜模型也可能消耗更多 token

Byron Wall 做了一个规模更大的实验：让 Codex 调度多个 ox-alpha worker，在同一个项目里并行执行任务。他在复盘文章中记录了约 1,010 次请求和 5,770 万 token。

这套流程确实运行起来了。每个 worker 都有明确的任务边界，系统会保存请求、最终输出、耗时、退出状态与日志。但 5,770 万 token 也说明，模型的单价不能单独代表 Agent 的性价比。

应该比较的是“完成同一个任务花了多少钱”：

任务总成本 = 输入 token 成本
           + 输出 token 成本
           + 缓存成本
           + 失败重试
           + 人工介入
           + 等待时间

便宜模型如果需要更多轮修改、输出更长的推理内容，或者经常因为工具格式失败而重试，单 token 优势会被一部分抵消。反过来，如果它可以在无人干预的情况下完成更多任务，即使输出稍长，总成本仍然可能更低。

另一个通宵自主开发实验运行了 49 次请求，消耗 233 万 token，最终合并两个 PR。免费预览期间 API 成本是 0 美元，但服务拥堵造成了一次停滞。这个结果同时展示了两面：它能产出可以合并的工程结果，服务稳定性又会直接影响长任务。

两种答案从哪里来

现有材料还不足以判断 GLM-5.3-Flash 已经全面超过 DeepSeek。社区会出现两种答案，主要是因为大家测试的任务并不相同。能从公开记录中确认的结论更具体：

• 在智谱公布的 Agent benchmark 中，GLM-5.3-Flash 大多领先 DeepSeek-V4-Vision-Exp。
• 在完整 DeepSWE 社区运行中，它表现出较强的仓库级问题处理能力。
• 在 LiveCodeBench 裸代码生成中，它没有表现出同样明显的优势。
• 工具调用格式、输出速度和服务拥堵，都会影响真实完成率。
• 原生多模态是一项实际差异，但公开社区测试目前主要集中在文本编码，还没有充分验证截图理解、界面操作与视觉校验。

如果要为自己的工作选择模型，我会用同一套 Harness 做六组小规模测试：

测试	观察指标
修复真实仓库 bug	根因定位、测试结果、修改轮数
按规格实现功能	完成度、误改文件、测试通过率
单 prompt 前端页面	首次可用程度、浏览器错误、修复轮数
根据截图修复 UI	视觉问题识别与最终截图差异
裸算法题小样本	Pass@1、输出长度、运行正确率
长上下文仓库问答	文件定位、引用准确率、响应时间

两边使用相同 prompt、相同超时、相同工具权限和尽量一致的 reasoning effort。最终表格至少记录首次成功率、最终成功率、请求轮数、输入与输出 token、墙钟时间、API 成本、工具错误和人工介入次数。

到这一步，“谁更便宜”才会变成“谁能用更低的总成本把任务做完”。排行榜可以帮我们缩小候选范围，真实仓库里的结果才负责决定默认模型。

---

• 官方发布：GLM-5.3-Flash
• 开放权重：zai-org/GLM-5.3-Flash
• DeepSWE 社区运行：MatchaOnMuffins/oxalpha
• LiveCodeBench 复现：xnasarx/ox-alpha-benchmarks