GLM-5.2 API 接入与按量计费

先说结论:两个值加一个 Key

任何 OpenAI 兼容客户端都认 base_url 和 Key 这两个值。base_url 填 https://api.kkaiapi.com/v1,model 精确填 glm-5.2,请求体和调用其他任何聊天模型完全一样。不需要单独装智谱的 SDK,也不需要单独开智谱账号。 模型 ID 比看起来重要:glm-5.2、glm-5.1、glm-5 是三个价格不同的独立模型,打错字不会降级到别的版本,而是直接返回模型不存在。接入自动化流程前,先对照 /v1/models 的列表核实一次拼写。

curl https://api.kkaiapi.com/v1/chat/completions \
  -H "Authorization: Bearer sk-你的kkaiapi密钥" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.2",
    "messages": [{"role": "user", "content": "用两句话讲清楚什么是 MoE 模型"}]
  }'

GLM-5.2 到底是什么

智谱在 2026 年 6 月中旬发布了 GLM-5 系列的这个新版本:6 月 13 日先给 Coding Plan 订阅用户,6 月 16 日公开发布,权重按 MIT 协议开源。发布材料给出的参数规模大约是 7500 亿总参数的 MoE 架构,每个 token 激活约 400 亿参数,不同信源的具体数字在 7440 亿到 7530 亿之间浮动,当成约数看待即可。 智谱把它定位在编程和长程 Agent 任务上,官方文档描述的上游上下文是 100 万 token,单次响应最多输出 12.8 万 token。有两点接入前要知道:第一,GLM-5.2 是带思考模式的推理模型,官方 API 把思考模式做成开关加强度设置,思考产生的 token 按输出计费;第二,kkaiapi 这边 glm-5.2 的目录上下文是 20 万 token,预算 prompt 长度按这个数字算,不要按官方上游的 100 万来估。

为什么不只订 Coding Plan

智谱自己的 Coding Plan 是订阅制,按月固定付费换取一定额度,适合用量稳定、每月都会跑满的场景。但很多场景用量并不稳定:偶尔跑几个 Agent 任务、给个人项目接一个聊天功能、只是想对比 GLM-5.2 和别的模型效果,按月订阅反而不划算。 按量计费的 API 路径解决的正是这个问题:不订阅任何套餐,充多少花多少,GLM-5.2 和 Claude、GPT、DeepSeek 这些模型共用一个 Key、一个人民币余额,想跑 Agent 就跑 Agent,想切模型对比就改一个 model 字符串,不需要为每家单独订阅。

Python 与 JavaScript 快速接入

两个官方 OpenAI SDK 在创建客户端时都能传自定义 base_url,model 字段原样传字符串,同一个客户端对象上一行调 glm-5.2,下一行就能调 claude-sonnet-5 或 deepseek-v4-pro。 把 Key 放进环境变量而不是写死在代码里,model ID 固定在一个配置常量里,以后从 glm-5.1 升级到 glm-5.2 只改一处。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["KKAIAPI_KEY"],
    base_url="https://api.kkaiapi.com/v1",
)

resp = client.chat.completions.create(
    model="glm-5.2",
    messages=[
        {"role": "system", "content": "你是一个简洁的编程助手。"},
        {"role": "user", "content": "写一个 Python 函数,对列表去重并保留原始顺序。"},
    ],
    max_tokens=2000,
)
print(resp.choices[0].message.content)
print(resp.usage)  # prompt_tokens / completion_tokens 每次请求都能看到

思考模式与流式输出

GLM-5.2 会在给出可见回答前先"想一想",这部分思考 token 按输出计费,所以同一个问题,GLM-5.2 消耗的输出 token 可能比看起来的答案长度多不少。流式返回对这类推理模型格外有意义:开着 stream 能让用户先看到"正在处理"的动态,而不是盯着一个卡住的请求。 Agent 类工具调用循环里,GLM-5.2 的推理发生在选择调用哪个工具之前,所以工具调用轮次消耗的输出 token 可能比看到的 JSON 参数多,按 usage.completion_tokens 而不是工具调用本身的字节数来估算成本更准确。

stream = client.chat.completions.create(
    model="glm-5.2",
    messages=[{"role": "user", "content": "写一份 CLI 工具的 README 大纲"}],
    max_tokens=2000,
    stream=True,
)
for chunk in stream:
    delta = chunk.choices[0].delta.content if chunk.choices else None
    if delta:
        print(delta, end="", flush=True)

glm-5.2 / glm-5.1 / glm-5 怎么选

因为三个 ID 挂在同一个接口下,这个对比就是一下午的 A/B 测试,不是迁移项目,控制台的用量记录会把每个候选的花费算清楚。

• glm-5.2:系列里目前最新最强,编程和长程 Agent 任务优先用它,价格也是三档里最高的
• glm-5.1:主打长程自主运行,官方给出的场景是单任务可以跑很长时间,5.2 的能力用不完时是合理选择
• glm-5:量大场景的性价比款,摘要、抽取、批量任务足够用,三档里价格最低
• 三个 ID 请求格式完全一样,原型阶段用 glm-5.2 起步,评测通过的任务再迁到 glm-5 或 glm-5.1 上省钱

验证接入与排查首次调用

接入前先查一次自己 Key 能调的模型列表,确认 glm-5.2 拼写和列表里完全一致。 首次调用失败集中在几类:401 多半是 Key 没导出到运行代码的那个 shell;404 常见于 base_url 漏了 /v1,SDK 会在 base_url 后面自动拼 /chat/completions;模型不存在多是拼写问题,glm-5.2 是带点的写法,不是 glm-52;返回在 finish_reason=length 处截断,说明 max_tokens 对一个推理模型来说设小了,先把这个值调大再评判输出质量。

curl -s https://api.kkaiapi.com/v1/models \
  -H "Authorization: Bearer sk-你的kkaiapi密钥" | grep glm

常见问题