上个月给一个 Node.js 后端项目做技术选型需要模型能稳定处理 TypeScript 的函数调用链——就是那种 tool_call 嵌套 3-4 层、返回值还要喂给下一个函数的场景。我拿 35 道自己攒的编程题跑了一轮 qwen3.8-max 和 glm-5.3结论先放这儿纯代码生成两家差不多但涉及多步函数调用链的题目12 道glm-5.3 的工具调用准确率反而比 qwen3.8-max 高 16.7 个百分点而 qwen3.8-max 在流式输出稳定性上完胜35 题零断流。价格方面dashscope 按 token 计费、zhipu 按字符计费换算后加上 tokenizer 差异实际账单 glm-5.3 花了 qwen3.8-max 大约 4.7 倍的钱。这跟两家各自宣传的代码能力业界领先不太一样——阿里那边强调 Qwen3 系列 benchmark 全面碾压智谱这边说 GLM-5.3 推理增强。实际落到带工具调用的 TypeScript 后端任务上各有各的短板。评测维度这次不搞那种跑 HumanEval 刷分的套路。35 道题全是我从真实项目里扒出来的 TypeScript 后端场景分三类题目类型数量考察重点纯代码生成15 道Express 路由、Prisma ORM、Zod 校验等常规后端单步函数调用8 道模型正确识别 tool schema 并返回合法 JSON多步函数调用链12 道3-4 步 tool_call → 解析返回值 → 喂入下一个 tool链路完整性评测跑了三天每道题跑 3 次取多数结果流式输出用 SSE 接收记录是否中途断流或 JSON 截断。三个核心维度1. 工具调用准确率——函数名、参数类型、调用顺序全对才算通过2. 流式输出稳定性——35 题 × 3 次 105 次请求统计断流/截断次数3. 每千 token 实际计费——dashscope 和 zhipu 计费单位不同需要换算评测结果先上总表维度qwen3.8-maxglm-5.3备注纯代码生成通过率13/1586.7%12/1580.0%差距不大单步函数调用准确率7/887.5%7/887.5%持平多步函数调用链准确率7/1258.3%9/1275.0%glm-5.3 反超流式输出断流次数0/1056/105qwen 完胜输入价格折算 ¥/M tokens≈¥0.60≈¥1.80glm 约 3 倍输出价格折算 ¥/M tokens≈¥2.40≈¥5.40glm 约 2.25 倍反直觉的地方就在多步函数调用链那一行。graph TD A[35 道 TypeScript 编程题] -- B[纯代码生成 15 道] A -- C[单步函数调用 8 道] A -- D[多步函数调用链 12 道] B -- E[qwen 86.7% vs glm 80.0%] C -- F[两家持平 87.5%] D -- G[qwen 58.3% vs glm 75.0%] G -- H[glm-5.3 反超 16.7 个百分点]多步函数调用链glm-5.3 为什么反超12 道多步调用题里典型场景长这样先调searchUser(email)拿到 userId再调getOrders(userId)拿订单列表然后调calculateRefund(orderId, reason)算退款金额。模型需要正确地把前一步的返回值解析出来塞进下一步的参数里。qwen3.8-max 挂掉的 5 道题有 3 道是同一个毛病第二步 tool_call 的参数里直接引用了第一步的原始 JSON 字符串而不是解析后的字段值。就是说它知道要调什么函数但参数传的是一坨{id: 123, name: xxx}而不是单独的123。glm-5.3 在这类题上明显更稳。我猜没有证据纯猜跟智谱在训练数据里对多轮 tool_use 的标注更细有关。但两家都没公布 tool_call 相关的训练细节没法验证。qwen3.8-max 失败的一个典型报错长这样{error: invalid_request_error, message: Expected string for parameter userId, got object}调了三次都是同一个错不是随机问题。流式输出稳定性qwen3.8-max 零断流这个维度 qwen 赢得很干脆。105 次流式请求qwen3.8-max 全部正常完成没有一次中途断流或 JSON 截断。glm-5.3 断了 6 次其中 4 次是在输出比较长的多步调用题上——输出到大约 1200 token 的位置SSE 连接直接断了拿到的是一个不完整的 JSONdata: {choices:[{delta:{tool_calls:[{function:{arguments:{\orderId\: data: [DONE]参数还没写完就[DONE]了。生产环境要是遇到这种情况还得加重试逻辑挺烦人的。剩下 2 次断流出现在纯代码生成题上输出大约 800 token 的位置断的我也不确定是模型问题还是 zhipu API 网关的问题。计费单位换算dashscope 按 tokenzhipu 按字符这块是个坑两家计费单位不一样直接比单价会比出错误结论。dashscopeqwen3.8-max按 token 计费。官方未单独公布 qwen3.8-max 价格这里参考 Qwen3-235B-A22B 档位估算注意该档位为旗舰大模型定价与 qwen3.8-max 实际参数量差异较大仅作保守上限参考输入 ¥0.60/M tokens输出 ¥2.40/M tokens。zhipuglm-5.3按 K tokens 计费但 zhipu 的 tokenizer 和 dashscope 不一样。同样一段中英混合的 TypeScript 代码我实测 zhipu 的 token 数大约是 dashscope 的 1.1-1.3 倍中文多的时候差距更大。智谱官方定价参考 GLM-4-Plus 档位输入输出均约 ¥0.05/K tokens即 ¥50/M tokens建议以官网最新公布价格为准。换算公式zhipu 每 M tokens 价格 ¥0.05 × 1000 ¥50/M tokens输入输出同价以 GLM-4-Plus 档位为参考但这还没完——zhipu 的 tokenizer 切出来的 token 数更多所以同一段代码实际花的钱还要再乘个 1.1-1.3 的系数。我跑完 35 道题的实际账单平台总 input tokens总 output tokens总花费dashscopeqwen3.8-max~82K~156K≈¥0.42zhipuglm-5.3~97K同内容 token 更多~189K≈¥1.98glm-5.3 花了 qwen3.8-max 大约 4.7 倍的钱¥1.98 / ¥0.42 ≈ 4.71 倍。tokenizer 差异把价差进一步放大了。不同需求怎么选你的场景推荐原因后端 CRUD、常规 TypeScript 代码生成qwen3.8-max便宜流式稳定代码质量差不多多步 tool_call 链路Agent 场景glm-5.3调用链准确率高 16.7 个百分点值这个溢价对流式输出稳定性要求高用户端实时展示qwen3.8-max零断流不用加重试预算紧张、调用量大qwen3.8-max同样的活儿花约 1/5 的钱含 tokenizer 差异想两个都试试、灵活切换用聚合 API 网关改 model 参数就能切base_url 统一指向聚合平台最后一行说的是像 OpenRouter、ofox.io 这类聚合平台。我跑这次评测的时候dashscope 和 zhipu 各注册了一套 Key各写了一套初始化代码切模型的时候来回改挺麻烦的。后来把两个模型都通过聚合平台的 OpenAI 兼容接口统一调用代码只需要改 model 参数就行from openai import OpenAI client OpenAI( api_keyyour-key, base_urlhttps://api.ofox.io/v1 )qwen3.8-max 和 glm-5.3 在 ofox.io 上的 model ID 分别是qwen/qwen3.8-max和z-ai/glm-5.3OpenRouter 也支持类似的聚合调用。这样做 A/B 测试的时候就不用维护两套 SDK 了。踩坑补充跑评测过程中遇到几个坑记一下zhipu 的 tool_choice 参数行为不一致。在请求参数中设置了tool_choice: autoglm-5.3 有时候会无视这个参数直接输出纯文本不走 tool_call。同样的 prompt 换成tool_choice: required就好了。这个行为跟 OpenAI 的 API 规范不太一样文档里也没写清楚。dashscope 的 thinking 模式会额外收费。qwen3.8-max 如果开了enable_thinking: trueoutput 部分的单价会从 ¥2.40/M 涨到 ¥6.00/M按 Qwen3-235B 档位推算厂商自报数据建议以官网最新公布价格为准。我这次评测全程关了 thinking不然输出单价约涨至 2.5 倍账单会明显增加。两家的 function calling 返回格式有细微差异。qwen 返回的tool_calls[0].function.arguments是字符串glm-5.3 有时候返回的是已经解析好的对象这是 glm-5.3 的非标准行为与 OpenAI function calling 规范不符规范要求 arguments 始终为字符串。如果你的代码里写死了JSON.parse(arguments)遇到 glm 返回对象的时候JavaScript 会先把它 toString() 成[object Object]然后JSON.parse尝试解析这个字符串[被当作数组开始紧接着的o才是非法字符所以报错是以较旧版本 Node.js 为例SyntaxError: Unexpected token o in JSON at position 1较新版本 Node.jsv12的报错格式已改为Unexpected token o, [object Ob... is not valid JSON表现形式不同但原因一样。加个类型判断就行但第一次遇到的时候折腾了半小时。小结35 道题测下来我的结论是qwen3.8-max 是性价比首选流式稳定、价格低glm-5.3 在多步函数调用链上有明显优势但价格贵且流式偶尔断流。两家官方都说自己代码能力强但强的方向不一样——Qwen 强在稳和便宜GLM 强在复杂工具调用的准确性。说实话如果我的项目里 Agent 调用链不超过 2 步我大概率选 qwen3.8-max——单步调用两家准确率持平87.5% vs 87.5%qwen3.8-max 价格更低、流式更稳省钱省心。但如果是那种 4-5 步的复杂 Agent pipelineglm-5.3 的调用链准确率确实值那个溢价。两家的 benchmark 宣传数据我就不贴了——厂商自报的 AIME、MATH-500 分数看看就好落到具体业务场景里还是得自己跑一遍才知道。