GLM-5.2 vs MiniMax-M3:我把它们从写小函数一路逼到修真实开源库的 bug

不念跑分,真跑

智谱开放了 GLM-5.2:1M 上下文,下周开源,主打长程 Coding 和 Agent。我是内测用户,手上又有 MiniMax-M3 的 key(走一个第三方 API 代理)。

我不想再念跑分表了。想把两个模型丢进完全一样的环境,真跑一遍。两边都挂在 Claude Code 里当后端(GLM-5.2 用 glm-x-preview[1M],MiniMax 用 MiniMax-M3),变量只剩模型本身。

我不只跑一个任务。我让难度逐级往上走:写小函数,做一个带前端的全栈应用,最后给真实开源库修隐蔽的 bug。看谁先掉链子。

六轮下来,故事比跑分有意思,也没那么一边倒。

怎么比才公平

模型对比最大的坑是环境不一样。我把变量压到只剩一个。

• 同一个 harness:都用 Claude Code,只换底层模型。
• 同一个任务:两模型拿完全一样的输入。
• 客观判据,不靠模型自评。这条最关键。我用外部测试门(go test 必须全绿),或者可量化的 diff 和耗时,而不是让模型自己说”我完成了”。为什么不能让它自评,后面 /goal 那段会讲。
• 先用自己的”标答”把验收测试跑通,才交给模型。这一步还真抓出了 bug:我最初把”固定窗口”写成按整秒重置,自检时测试挂了。一查才发现,这么写 rate 参数形同虚设。测试反过来逼我把规格修对了,也说明这套判据是真在干活。

下面每一轮,我都把具体数字摆出来,不糊弄。

第一轮:小任务,谁一次过

最简单的:从零写一个并发安全的限流器(Go,三种算法:令牌桶、滑动窗口、固定窗口,go test -race 必须干净)。验收测试里有个狠角色,TestConcurrentBurstExact:500 个 goroutine 同时抢令牌,放行数不得超过上限,数据竞争一抓一个准。两个模型都让测试全绿,硬标准没掉链子。差别在过程。

指标	GLM-5.2	MiniMax-M3
go test 次数	1(一次过)	5(反复试错)
对话轮数 / 工具调用	18 / 9	25 / 20
峰值上下文	~45k	~16k(代理遥测失真,偏小)

GLM-5.2 基本一把过:读完规格,写一版代码,跑一次测试直接全绿。MiniMax-M3 也通过了,但 go test 跑了 5 次,改了又改。小任务上,GLM 明显更高效。

第二、三轮:那 1M 长上下文呢?

第一轮峰值上下文才几十 k,根本没碰到 1M。我想真触发它,喂了大概 58 万 token 的真实代码:18 个限流、并发库,跨 Go、Python、JS、Java、Rust 五种语言,446 个文件。要求”先通读全部、写调研报告,再实现”。我还在语料深处,按 20%、40%、60%、80% 的深度埋了 4 条”设计说明”,测它读得深不深。

结果两个模型都只读了 446 个文件里的二十几个(GLM 22 个,MiniMax 47 个,5 到 10%),峰值上下文停在 ~100k。我喂了 58 万,还明令”全读”,它俩还是挑着读。Agent 按需读文件,所以 1M 窗口很难被真正填满。不过埋在深处的 4 条细节,两家一个没丢。检索能力没问题。

我不服气,又逼了一轮:强制它把整个 corpus 从头读到尾。这次它真读完了,41 次 Read,一直读到文件第 81438 行(总共 81439 行),4 个细节照样全找到。但峰值上下文到 261k 就报错 Prompt is too long。

结论先写清楚,不打包其他通道:

在 Claude Code + 智谱 bigmodel /anthropic 端点 + 我这个账号的组合下,GLM-5.2 每轮请求的实际输入上限大概 256k,不是 1M。

没测、不打包票的部分:这 256k 是模型本身的极限,还是这个端点、账号 tier、或者 Claude Code 自身(我这环境装了一堆 MCP 和 skills,系统提示加工具定义就占掉不少)造成的?我没拆开测。裸 API 直打、换个 tier 能不能真到 1M,本文不下结论。但有一点很实在:1M 在我日常这条通道里用不满,实际天花板 ~256k。这跟英伟达 RULER 说的”长上下文虚标”是同一类问题。标称的窗口,不等于你能用上的窗口。

第四轮:任务变大,质量反而收敛

我换了个有规模的任务:从零做一个全栈微信复刻。Go 后端、WebSocket 实时聊天、消息持久化(落 JSON),加朋友圈、公众号、微信运动四个模块,再加前端单页。

这是最难的一档 build app。实时性这种最容易糊弄的地方,我没看它自己说”能跑”,而是写了个 WebSocket 客户端(python websockets),连两个 session,在 A 发一条,查 B 有没有收到推送。这才叫真验证。

结果有点意外。两个模型都把最难的部分做对了:两个浏览器标签实时收发、房间隔离(A 房间的消息 B 房间收不到)、重启服务后历史还在、四个模块全可用。功能层面 10/10 打平。

中间还有个小插曲:GLM 那份默认端口 8090,被我上一轮残留的静态服务占着,起服务时报 bind: address already in use,换了端口才跑起来。这种环境小坑,两家都得趟。

差别退化成了风格,而且挺稳定:

• GLM-5.2 工程更规范。按模块拆文件(聊天、朋友圈、公众号、运动各自独立),还主动写了两份单元测试(hub_test、router_test)。
• MiniMax-M3 功能更全、更巧。REST 路由更多(公众号还做了关注、取关),而且 WebSocket 不只用于聊天,还顺手驱动朋友圈和运动的实时更新。它甚至自己用浏览器截了 3 张图自检。

任务从”写小函数”变成”做有规模的应用”,两家在完成质量上就收敛了。都很完整、很可用,差别只在风格。想靠”做个 app”分高下,分不开。

第五轮:给真实开源库修隐蔽 bug

既然 build app 分不开,我就换业界公认最能拉开差距的玩法:SWE-bench 式,给真实代码、让它修 bug。这也是 GLM 自己强调的 agentic engineering 主场。

载体是真实开源库 github.com/cenkalti/backoff/v5(Go 退避、重试库,几百行,有完整测试套件,基线 go test 全绿)。我在它源码里精确植入了 3 个隐蔽 bug,让测试失败:

1. MaxTries 差一:numTries >= MaxTries 被改成 >,WithMaxTries(3) 实际跑 4 次。
2. MaxInterval 封顶失效:封顶阈值 MaxInterval / Multiplier 被改成 * Multiplier,间隔会冲破上限。
3. Reset 重置到错的值:currentInterval = InitialInterval 被改成 = MaxInterval,重置后直接跳到封顶值。

任务:只改源码,不许改测试,把 go test ./... 修到全绿,并在 FIXES.md 写清每个 bug 的根因。我用 git 提交了基线,事后能 git diff 验证它有没有偷偷改测试作弊。

顺带说个重要发现:这一轮我故意没用 /goal。因为 /goal 的”完成判定”是模型自己(或者一个弱 judge 模型)打的。业界有句话,agents are reliably bad at grading their own work。让它自评,它会在”差不多”时就停,逼不出极限。这一轮的判据是外部的测试门,go test 全绿,不是它自己说 done。

结果是六轮里第一次,在客观门上拉开了明显差距。

维度	GLM-5.2	MiniMax-M3
go test 全绿 / vet 干净 / 没改测试	✅	✅
diff 行数	3 增 / 3 减	10 增 / 6 减
耗时	263s	507s
go test 迭代次数	2 次	4 次

功能两边都修对了(都让测试全绿,git diff 证明没碰测试文件)。但修法差别很大。

GLM-5.2 是外科手术。3 处最小改动,每处都精准还原成库的原始正确写法:> 改回 >=、* 改回 /、MaxInterval 改回 InitialInterval。FIXES.md 把三个根因讲得很准。

MiniMax-M3 也修对了,但有点用力过猛。前两个 bug 同样最小改;第三个却把整个 incrementCurrentInterval 函数重写了,还加了一道”乘完再封顶”的防御。能用,但不是最小化修法,多了 7 行。

GLM-5.2 快一倍,试错更少(2 次 test 对 4 次),修得最干净。这一轮最贴近工程实战:读别人的真实代码、定位隐蔽 bug、最小化修复。GLM-5.2 客观领先,跟它 agentic engineering 的定位也对得上。

过程里的几个真发现

benchmark 一般看不到这些:

• 请求 glm-5.1,实际 served glm-5.2。我本想拿 5.1 当旧版对照,跑完一看 transcript,26 轮对话里模型字段全是 glm-5.2。智谱把 glm-5.1 静默路由到了 5.2,对照组直接作废。
• MiniMax 的 /anthropic 端点谎报 200K 上下文。M3 真实是 1M,但兼容端点向上层上报 200K,会误导 Claude Code 提前压缩。我三组都把压缩阈值手动钉到 1M 才拉平。
• 这个代理把 token 遥测全搞丢了。回传的 output_tokens 恒为 0,缓存数据也全 0。所以 MiniMax 这边我只能比行为(轮数、工具次数),不能比 token 效率。这点不说明白,就是耍流氓。
• 1M 实际 ~256k 封顶,跟长上下文那条呼应。
• /goal 适合”把事干完”,不适合”测出极限”。测极限得靠外部硬门,不是模型自评。

这次测试,到底测出了什么

测出了什么:一套公平、可复现、逐级加码的比法(每个任务的输入、验收、脚本都摆出来,别人能照着重跑),加几个反直觉的发现。小任务看效率差,中型应用质量收敛,真实修 bug 才真正分高下。还有”1M 实战用不满”这件被营销盖住的事。

没测出、别过度解读:这不是正式 benchmark,样本小、单通道;“256k 墙”是这条通道的特例,别的通道没测;MiniMax 的 token 指标因代理失真,不可比;5.1 对照组因路由失效。

那为什么还有意义?因为决定”我用不用得上”的,不是跑分表,是实战里能不能用满、能不能在最难的活上不掉链子。跑分告诉你”支持 1M”,实测告诉你”这条路实际 256k”;跑分告诉你”coding SOTA”,实测告诉你”真实修 bug 时谁又快又干净、谁的 diff 最小”。把数字摁到实战里检验,门槛不高,但比背一张榜单有用。

所以,谁更强?

把六轮放一起,诚实地说:

• 小任务:GLM-5.2 一次过,更高效。
• 长上下文:1M 在我这条通道用不满(~256k 墙),两家都卡在这个限制上。
• 中型全栈应用:质量收敛,都合格。GLM 偏工程纪律,m3 偏功能广度。
• 真实修 bug(最难、最工程):GLM-5.2 客观领先,又快一倍,修得最干净。

我不会把它说成”GLM 全面碾压”。中型应用上,它俩真的打平。但如果问真实工程任务里谁更利落、更可靠,这组数据指向 GLM-5.2。至于它最响亮的卖点,1M 长上下文,至少在我日常的用法下,是个还没兑现的能力。

本文为 GLM-5.2 内测真实体验分享。#智谱 #GLM