GLM-5.3 API 使用指南：模型参数、迁移与 Flash 选择

截至 2026 年 8 月 26 日，glm-5.3 已经不再只是 GLM Coding Plan 里的编码模型。智谱中文模型文档已经给出模型 API，并列出 OpenAI Chat Completions、OpenAI Responses 与 Anthropic Messages 三种协议入口。

这次升级最容易踩错的地方，不是模型 ID，而是请求合同：GLM-5.3 始终启用深度思考，不能再发送 thinking.type: "disabled"。 它仍是文本输入、文本输出模型；当天上线的 glm-5.3-flash 才是带原生多模态能力的独立变体。

如果只需要一个起点，可以这样判断：

• 复杂代码仓库、长程 Agent、纯文本分析，先验证 glm-5.3；
• 前端截图、界面检查、视频或文件理解，验证 glm-5.3-flash；
• 从 GLM-5.2 直接换 ID，先改 thinking 与流式工具处理，再做回归；
• 想下载权重本地部署，先等官方组织出现 5.3 的模型仓库，不要把“open-weights 定位”理解成已经可以下载。

先确认当前的模型合同

1M 是一次请求可容纳的 token 上限，不是“塞满整个仓库仍保持相同准确率”的保证。最大输出 128K 也不是每次都应放开的预算。上下文越长，预填充、缓存、工具历史与失败重试越需要单独观察；真正的上限还会受到所用客户端、账户和接口参数约束。

GLM-5.3 与 GLM-5.2 使用相同基础模型。Z.ai 的发布说明把增量归因于后训练规模扩大，并报告内部 Z.ai Code Bench 的编程表现提升 50%。这是提供方在自己的任务环境与评测设置下得到的结果，不代表每个中文业务系统、代码库或 Agent harness 都会提升 50%。

最小调用先走 Chat Completions

中国 BigModel 端点中，Chat Completions 的 base URL 是 https://open.bigmodel.cn/api/paas/v4。下面的请求显式写出模 型 ID、thinking 与推理强度，便于排除旧默认值带来的歧义：

bash
export ZHIPU_API_KEY="替换为你自己的密钥"

curl -sS "https://open.bigmodel.cn/api/paas/v4/chat/completions" \
  -H "Authorization: Bearer ${ZHIPU_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "messages": [
      {
        "role": "user",
        "content": "阅读这段需求，列出实现风险、验收条件和第一步修改。"
      }
    ],
    "thinking": { "type": "enabled" },
    "reasoning_effort": "high",
    "temperature": 1.0,
    "max_tokens": 8192
  }'

官方默认 reasoning_effort 为 max，并建议复杂 Coding 使用 max。但生产系统不应把最高档当成无需验证的默认答案：先用 high 或 max 跑同一批真实任务，记录通过率、输出 tokens、端到端耗时、重试和人工修复，再决定默认档。抽取、分类或短格式转换也无法关闭思考，只能用 low 降低推理强度后重新测延迟与稳定性。

三种协议的当前 base URL 是：

“兼容”意味着可以降低迁移成本，不意味着所有参数、事件顺序、状态保存与工具语义都完全等价。先使用官方接口页对应的路径和示例，不要只替换 base URL 后就跳过回归。

还有一条当前账户限制需要单独看：官方中文模型页注明，曾订阅过 GLM Coding Plan（包括已过期）的账户，暂时只能通过 Chat Completions 协议调用模型 API。 如果 Responses 或 Anthropic 路线在该账户上不可用，不要先归因于模型下线；先回到 Chat Completions 验证密钥、余额、模型权限与最小请求。这条限制带有“暂时”字样，接入前应重新核对官方页面。

从 GLM-5.2 迁移，不能只改模型名

智谱的迁移清单明确写明：保留 thinking.type: "disabled" 再把 model 改为 glm-5.3，请求会失败。最小安全迁移应同时处理四件事：

1. 将模型 ID 更新为 glm-5.3；
2. 把 thinking 改为 enabled，若原任务不需要深推理，先设 reasoning_effort: "low"；
3. 只选择 temperature 或 top_p 之一调参，官方默认分别为 1.0 与 0.95；
4. 用固定输入重新验证流式文本、工具调用、结构化输出、超时与 token 上限。

流式响应需要分别处理 delta.reasoning_content 与 delta.content。如果还要边生成边读取工具参数，官方建议同时启用 stream: true 和 tool_stream: true，并按顺序拼接 delta.tool_calls[*].function.arguments。只保留最终可见文字，会让日志无法解释工具为什么被调用；把尚未拼完的 JSON 参数直接执行，又可能产生解析错误或错误工具请求。

回归集不需要很大，但必须来自真实流量。可以选 10–20 个最近发生过的任务，固定 prompt、工具权限、超时、最大轮次和验收方法；比较 GLM-5.2 与 5.3 的通过率，而不是只看答案是否“感觉更好”。涉及写代码时，让测试、类型检查或页面截图决定是否通过；涉及结构化数据时，用 schema 校验，不用人工浏览代替机器边界。

什么时候改用 GLM-5.3-Flash

glm-5.3-flash 不是给旗舰版加一个 speed 参数。官方 GLM-5.3-Flash 模型页给出的架构为 320B 总参数、18B 激活参数，并称它是 GLM-5 系列首个原生多模态模型。API 可在 messages[].content[] 中加入 image_url 内容块；能力列表还覆盖视频与文件输入。

因此，选择边界可以落到输入与验收上：

• 任务全是文本，且重点是复杂代码修改或长程推理：旗舰版应成为基线候选；
• 模型必须查看页面截图、渲染结果或图形界面再修代码：Flash 才能形成原生视觉反馈；
• 工作流要读视频、文件或多张图片：先用 Flash 的真实素材核验输入限制、上传方式与结果质量；
• 已购买 Coding Plan 且主要受积分额度约束：Flash 的“3 倍可用额度”值得验证，但它不是 API 每百万 tokens 价格的同义词。

Flash 同样不允许关闭思考。官方推荐 temperature: 1、top_p: 0.95、reasoning_effort: max，并建议在流式工具场景开启 tool_stream。如果你只需要低延迟文本抽取，不能因为名称里有 Flash 就推断它一定更快或更便宜；应在相同输入、相同验收与相同账户路线上测首 token、总耗时和被验收任务成本。

API、Coding Plan 与本地权重是三笔不同的账

Model API 按请求和 token 形成账单；GLM Coding Plan 使用订阅与积分配额；本地部署则要计算权重、量化、GPU/国产芯片、推理框架、运维和并发。三者不能用一个数字直接排序。

特别是，Coding Plan 中“Flash 可用额度增至 3 倍”只说明订阅池的相对消耗。它不能直接换算成某个稳定的人民币或美元 token 单价。比较成本时，至少使用同一个分母：

每个通过验收的任务成本 = 模型与工具消耗 + 重试 + 人工修复 + 运维，再除以通过任务数

公开权重也要按实际可得性判断。GLM-5.3 发布页在 8 月 14 日称将在安全评估与加固后约两周发布；截至 8 月 26 日，官方 Z.ai Hugging Face 组织仍未列出 GLM-5.3 或 GLM-5.3-Flash。准备自部署时，只从发布页、官方组织和官方仓库互相核对链接、模型卡与许可证；在正式模型仓库出现前，不要依据同名第三方下载包制定生产上线计划。

一次可验收的接入顺序

先用 Chat Completions 和 thinking: enabled 跑通最小请求，再把真实任务逐步加回来。随后根据账户支持选择 Responses 或 Anthropic 路线，并单独验证流式与工具循环。需要视觉输入时，把 Flash 作为独立候选，不在同一个 model ID 上猜参数。最后用真实任务通过率与完整成本决定默认模型和 effort 档，而不是用发布日期、上下文上限或一张发布方跑分表替代验收。

这样得到的不是“哪个型号听起来更新”，而是一条可以复现的选择：准确的模型 ID、准确的利用面、准确的请求合同，以及能在你的任务里客观通过或失败的停止条件。