智谱 GLM API 接入、价格与能力详解

智谱 AI 是清华大学系背景的大模型公司，GLM 系列在学术界和工业界均有广泛应用。GLM-4 是其旗舰模型，支持长上下文、工具调用（Function Calling）、代码执行（Code Interpreter）和网页浏览等”All Tools”能力。API 兼容 OpenAI 协议，是国产模型中功能最全面的选项之一。

如果你是从 OpenAI 或者别的国产模型迁移过来接 GLM，大概率是冲着两个理由：一是它的 All Tools 把联网、代码执行、文件解析打包在一个模型里，省得你自己拼工具链；二是它对企业客户的合规资质、发票流程比较完善，很多需要走对公报销的团队会优先选它。但接入过程里也有几个坑，下面按你实际会踩到的顺序讲。

注册与获取 API Key

1. 访问 open.bigmodel.cn 注册账号；
2. 进入控制台 → API Keys → 点击「新建 API Key」；
3. 复制并妥善保存密钥（仅展示一次）；
4. 控制台可查看余额、充值和用量统计；新用户有免费额度赠送。

这里有几个容易被忽略的细节。第一，智谱的账号分个人和企业两种认证等级，个人认证通常只能开通较低的并发速率限制（QPS），如果你是要接生产环境的批量任务，务必先做企业实名认证，否则大概率会在压测阶段撞到 429（Too Many Requests），你以为是代码写错了，其实是账号等级不够，加钱升级配额就能解决，跟代码没关系。第二，API Key 只在创建那一刻完整展示一次，关掉弹窗就再也看不到明文了，只能删掉重建，所以拿到手先存进你的密钥管理工具（比如本地 .env 或者团队的 Vault），不要截图存在聊天记录里，这是最容易被安全扫描工具标记出来的低级错误。第三，免费额度是有过期时间的，具体多少天以控制台实际展示为准，不要默认它永久有效，等你真正上线跑批量任务时突然发现余额被扣光了才发现早就该充值了。

接入示例：OpenAI 兼容调用

from openai import OpenAI

client = OpenAI(
    api_key="your-zhipu-api-key",
    base_url="https://open.bigmodel.cn/api/paas/v4/",
)

response = client.chat.completions.create(
    model="glm-4-air",                       # 或 glm-4、glm-4-flash 等
    messages=[
        {"role": "system", "content": "你是一个专业的数据分析助手"},
        {"role": "user", "content": "用 Python pandas 实现一个按月统计销售额的函数"},
    ],
)
print(response.choices[0].message.content)

这段代码看着和调 OpenAI 官方 SDK 一模一样，只改了 base_url 和 model 两个参数，这也是国产模型普遍主打”OpenAI 兼容”的意义所在——你原来接 GPT 的代码，理论上换两行配置就能跑通。但实际迁移时至少有三个地方会让你翻车，提前知道能省你半天调试时间：

• base_url 结尾的斜杠和路径层级不能错。智谱的完整路径是 https://open.bigmodel.cn/api/paas/v4/，如果你手滑写成不带 v4 或者少了末尾斜杠，SDK 内部拼接请求路径时会直接 404，报错信息还是英文的 Not Found，很容易让你怀疑是网络问题，其实就是路径拼错了。
• model 参数是大小写敏感的字符串，写错一个字母（比如把 glm-4-air 写成 GLM-4-Air）大概率会收到 400 错误，报文里会提示模型不存在，这时候先去控制台的模型列表核对一遍拼写，比盯着代码看更快。
• 认证头的格式。OpenAI SDK 会自动把 api_key 拼进 Authorization: Bearer xxx 请求头，智谱这边也吃这个格式，但如果你用的是别的 HTTP 客户端手写请求，漏加 Bearer 前缀会返回 401（Unauthorized），报错信息一般是”令牌无效”，第一反应先检查请求头格式，而不是怀疑密钥本身失效了。

生产环境里你大概率还需要流式输出（打字机效果）和超时重试，这两个是官方文档里一笔带过、但实际踩坑率很高的地方：

import time
from openai import OpenAI, APITimeoutError, RateLimitError

client = OpenAI(
    api_key="your-zhipu-api-key",
    base_url="https://open.bigmodel.cn/api/paas/v4/",
    timeout=30.0,   # 单次请求超时，建议按你的业务场景设置在 20-60 秒之间
    max_retries=0,  # 关掉 SDK 自带重试，自己控制退避策略，避免和限流叠加
)

def call_with_backoff(messages, model="glm-4-air", max_attempts=3):
    for attempt in range(max_attempts):
        try:
            stream = client.chat.completions.create(
                model=model, messages=messages, stream=True,
            )
            chunks = []
            for chunk in stream:
                delta = chunk.choices[0].delta.content or ""
                chunks.append(delta)
            return "".join(chunks)
        except RateLimitError:
            # 429，说明并发或 QPS 超限，指数退避后重试
            time.sleep(2 ** attempt)
        except APITimeoutError:
            # 超过 timeout 仍未返回，多见于长上下文或模型排队严重时
            if attempt == max_attempts - 1:
                raise
            time.sleep(1)
    raise RuntimeError("重试耗尽，请检查配额或降级到更轻量的模型")

这里的关键取舍是：max_retries 我手动设成 0，因为 SDK 自带的重试逻辑和你自己写的退避逻辑叠在一起，容易出现”重试了 6 次都还在等”的情况，尤其是在你的调用链路本身也有上层超时控制的时候（比如 Web 请求 15 秒超时，SDK 却重试到 20 秒才放弃），两边打架反而更难排查。流式输出（stream=True）除了做打字机效果，还有个实际好处：如果你的下游是网页或者客服机器人，用户能更快看到第一个字返回，体验上比等全部生成完再显示要好很多，尤其是 GLM-4 旗舰模型这种响应偏慢的场景。

带工具调用（Function Calling）示例：

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "获取指定城市的天气信息",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名称"},
                },
                "required": ["city"],
            },
        },
    }
]

response = client.chat.completions.create(
    model="glm-4",
    messages=[{"role": "user", "content": "北京今天天气怎么样？"}],
    tools=tools,
    tool_choice="auto",
)

工具调用这块有个容易踩的坑：模型返回的不一定是最终答案，而可能是一个 tool_calls 字段，里面带着它想调用的函数名和参数（比如上面例子里的 get_weather 和 {"city": "北京"}）。你需要自己解析这个字段，执行真正的函数逻辑（调天气 API），把结果拼回 messages 列表（角色设为 tool），再发起第二轮请求，模型才会用你返回的数据组织出最终回答。很多人第一次接工具调用时以为”传了 tools 参数模型就会自动帮你查天气”，结果发现返回的是一堆 JSON 参数而不是自然语言答案，愣了半天——这其实是设计如此，模型只负责决策”该调用哪个函数、传什么参数”，真正的执行永远得你自己写代码去做。

GLM-4 主要模型对比

模型	上下文	定位	特色
glm-4	128k tokens	旗舰，最强综合能力	复杂推理、代码、工具调用
glm-4-air	128k tokens	轻量旗舰，高性价比	速度快，适合生产高频调用
glm-4-flash	128k tokens	极速轻量	简单对话、低延迟场景
glm-4v	8k tokens	多模态版	图文理解，图片分析
glm-4-alltools	128k tokens	All Tools 版	联网+代码执行+文件处理
embedding-3	-	Embedding 模型	语义检索、RAG 向量化

选择建议：复杂任务用 glm-4；生产高频调用用 glm-4-air；需要联网或代码执行用 glm-4-alltools。

这个表格看着简单，但真到选型的时候，很多团队会犯一个共同的错误：直接拿 glm-4 旗舰去跑所有请求，图省事。这么做的问题不只是费用会更高，更实际的是延迟——旗舰模型排队和生成耗时都比 Air、Flash 长，如果你的场景是客服机器人这种需要秒回的交互，用户等 3 秒和等 8 秒的体感差距非常明显。我自己的判断顺序是：先拿 glm-4-flash 把业务跑通，观察输出质量能不能满足要求；不够用再切 glm-4-air，这一档基本能覆盖八成的生产场景；只有涉及复杂多步推理（比如需要模型自己拆解任务、做长链条工具调用编排）才上旗舰 glm-4。这个”先低配试水再按需升级”的路径，比一上来就用最贵的模型更省钱，也更容易发现问题出在 Prompt 设计上还是模型能力上。

另外提一句 glm-4v 多模态版：它的上下文窗口只有 8k tokens，明显比其它几个 128k 的版本小很多，这是因为图片本身要占用大量 token 预算。如果你的场景是”一张图 + 一段简短问题”没什么问题，但要是想把多轮对话历史和好几张图都塞进去，很容易撞上下文超限报错（常见报错关键字是 context_length_exceeded 或类似的”输入过长”提示），这时候的正确做法不是硬塞，而是主动做历史截断或者用摘要替代早期轮次的原文。

All Tools 特色能力

• Code Interpreter：模型可以执行 Python 代码并返回结果，适合数据分析、图表生成；
• Web Search：联网检索实时信息，弥补训练数据截止的不足；
• File Reader：上传文档（PDF、Word、Excel 等）让模型直接读取分析；
• Function Calling：标准 OpenAI 格式，完整支持 Agent 框架。

这几项能力实际用起来体验差异很大，值得展开说说各自的边界。Code Interpreter 跑的是一个隔离的沙箱环境，不是你本地机器，所以它没法访问你本地文件系统或者内网接口，你得先把数据文件上传给模型（走 File Reader 的入口），它才能在沙箱里读到；同时沙箱执行有时间限制，跑一个几秒钟能出结果的统计脚本没问题，但如果你丢一个需要跑几分钟的重计算任务过去，大概率会超时失败，这种场景应该老老实实自己写代码跑，而不是指望模型去执行。Web Search 联网检索这块要提醒一句：它查到的是当次检索的网页摘要，不是实时数据库查询，如果你的业务需要绝对精确的实时数据（比如股票价格、火车票余票），联网检索给出的信息可能有几分钟到几十分钟的滞后，这种强实时性场景应该接专门的数据 API，而不是依赖模型联网。File Reader 支持的文件格式和大小都有上限，具体以控制台文档为准，扫描版 PDF（图片形式没有文字层）这类文件模型未必能准确提取文字，遇到解析质量差的情况，先检查一下原始文件是不是图片扫描件，这类问题不是模型的锅，是文件本身没有可提取的文字层。

价格定性

截至 2026-06，以官方公示为准：

• GLM-4-Flash 是免费或极低价的轻量版，适合开发测试；
• GLM-4-Air 属于中等价位，性价比在旗舰中较高；
• GLM-4（旗舰）价格高于 Air，适合对质量要求最高的场景；
• All Tools 模式因包含工具执行算力，费用略高于纯对话模式。

具体单价以 智谱开放平台价格页 为准，也可用 价格对比工具 横向比较。

估算成本时别只看官网挂的单价表，容易漏算两笔账。第一笔是输入输出的价格通常不对等，输出 token 的单价普遍比输入 token 贵不少，如果你的场景是让模型生成长文（比如写报告、写代码），实际花费会比”按平均单价乘以总 token 数”估算的更高，建议按输入输出分别估算再相加，不要图省事用一个笼统单价去乘。第二笔是工具调用的隐性消耗，用 All Tools 跑代码执行或联网检索时，模型内部往往需要多轮”思考-调用-总结”的过程，每一轮都会计入 token 消耗，看似问了一个问题，实际计费的 token 数可能是普通对话的好几倍，如果你的业务是高频调用 All Tools，务必先拿真实用例跑一遍、看控制台账单里实际扣了多少，再去做规模化前的预算测算，不要拿”单次问答价格”直接乘以预期调用次数来估算月度成本，这样估出来的数字往往偏低。

常见问题

GLM-4 和 GLM-4-Air 质量差距大吗？ 日常文本生成和代码任务两者差距不明显；在复杂多步推理、深度语义理解上 GLM-4 旗舰版表现更稳定。建议先用 Air 测试，若有明显质量不足再升级旗舰。

调用 All Tools 模式时如何指定工具？ 使用 glm-4-alltools 模型时，可通过 tools 参数传入自定义函数，也可不传任何工具让模型自主决定是否联网或执行代码。控制台还可配置 Retrieval（知识库检索）能力。

GLM Embedding 模型适合做 RAG 吗？ embedding-3 支持维度压缩，在中文语义检索任务上有良好表现，可与 Milvus、Chroma 等向量数据库配合构建 RAG 管线。

遇到 401 Unauthorized 该怎么排查？ 先别怀疑密钥本身有问题，按顺序查三件事：一是密钥是否复制完整（前后有没有多余空格或者被截断，尤其是从网页复制到终端时很容易漏掉最后几位）；二是 base_url 是否写对，路径错了有些客户端也会报成认证失败而不是 404；三是密钥是否已经在控制台被禁用或者过期，企业账号如果有成员权限变更，旧密钥可能被批量吊销。这三步排查下来基本能定位到问题，比反复重新生成密钥要快。

批量调用时经常超时或报错怎么办？ 先看报错是 429 还是纯粹的网络超时。429 说明你的并发或 QPS 超过了账号当前等级允许的上限，解法是降低并发数或者升级账号配额，而不是加大 timeout 参数硬扛；纯超时（客户端等了很久没收到任何响应）多半是模型排队严重或者你的 max_tokens 设得过大导致生成时间过长，可以尝试拆分任务、缩短单次生成长度，或者把 stream=True 打开——流式模式下只要有数据陆续返回，就不容易触发整体请求超时。批量任务建议加一层限流控制（比如信号量限制并发数），而不是一次性把几百个请求全部并发甩出去，那样几乎必然撞上限流。

---

相关阅读：国产大模型 API 全景指南 · Kimi 长文本 API 详解 · MiniMax API 详解

分类导航：国产模型专题

实用工具：价格对比工具 · Token 计数器