1. 为什么要在 Coggle 数据科学场景里做一次速度评测
国产大模型这两年更新得很快，做数据科学的人最关心的其实不是榜单分数，而是「我这条 prompt 发出去，多久能拿到第一个 token，整段回答每秒能吐多少字」。GLM4-AirX 和 GLM4-Air 是智谱同一代里定位不同的两个版本：AirX 主打推理加速，官方说法是效果不变、速度约为 Air 的 2.6 倍，但上下文只有 8k；Air 则是 128k 上下文、价格更低的性价比版本。到底快多少、在什么任务上快，光看参数表没感觉，得自己跑一遍。
我这次的做法是：不直接去各家平台分别注册、分别管 Key，而是用 TaoToken 的统一 Key 和统一 API 通道，把 GLM4-AirX、GLM4-Air 放在同一套调用代码里对比。这样变量只有一个——模型名，网络链路、鉴权方式、计费口径都一致，测出来的首 token 延迟（TTFT）和吞吐（tokens/s）才有可比性。适合谁看：正在做 RAG、Agent、批量数据标注，需要给不同任务挑模型的数据科学同学；以及想复现一份「国产大模型速度评测」流程、但不想被多平台 Key 管理拖住的人。
下面我会给出可复制的 config.toml 骨架、CC Switch 配置片段，以及逐项验证动作。你照着改模型名就能跑出自己的对比表。
2. TaoToken 前置：统一 Key 与通道准备
TaoToken 在这里的角色是「一个 Key 走多家模型」的聚合入口。你不需要为 GLM4-AirX 和 GLM4-Air 分别申请、分别记额度，只要在控制台建一个 API Key，然后在请求里换 model 字段即可。对做评测的人来说，这省掉了最烦的一步：多平台账号和额度对齐。
先做三件事：
第一，打开官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 注册并登录。第二，进控制台 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite 创建 API Key，建议给这次评测单独建一个，方便后面看用量。第三，把 Key 存到环境变量，别写进代码：
export TAOTOKEN_API_KEY="sk-你的key"注意：Key 只显示一次，复制后立刻存好。评测脚本里一律用环境变量读取，避免提交到 Git。
TaoToken 的 API 基址是 https://taotoken.net/api（这个地址不加 UTM 参数）。它兼容 OpenAI 风格的/v1/chat/completions，所以任何支持自定义 base_url 的客户端都能接。模型名直接用glm-4-airx和glm-4-air这类标识，具体以控制台模型列表为准。
如果你只是想先确认模型通不通，可以打开模型对话页 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 手动发一句，看到流式输出就说明 Key 和通道没问题。这一步花两分钟，能省掉后面一半的排障时间。
3. 可复制配置：config.toml 骨架与 CC Switch 片段
评测要可复现，配置就得落文件。下面这份config.toml是我实测能跑的骨架，把两个模型的差异抽成[[models]]数组，跑的时候循环即可。
# config.toml —— GLM4-AirX / GLM4-Air 速度评测配置 [provider] name = "taotoken" base_url = "https://taotoken.net/api" api_key_env = "TAOTOKEN_API_KEY" # 从环境变量读取，不写死 timeout_sec = 120 [run] rounds = 3 # 每个模型每个问题跑 3 轮取中位数 stream = true # 必须开流式，才能测首 token 延迟 max_tokens = 512 temperature = 0.2 [[models]] alias = "airx" model = "glm-4-airx" note = "8k 上下文，推理加速版" [[models]] alias = "air" model = "glm-4-air" note = "128k 上下文，性价比版" [[prompts]] id = "qa" text = "你是一名专业的人工智能专家，请告诉我如何学习深度学习？" [[prompts]] id = "logic" text = "如果 A+B=12，A-B=10，则 A 的值是？请给出推理过程。" [[prompts]] id = "code" text = "帮我写一个 Python 版本的 A* 算法，并解释关键步骤。"如果你用 CC Switch 这类多配置切换工具管理编码/Agent 场景，可以加一段 profile，把 TaoToken 作为统一出口：
# CC Switch profile 片段 [[profiles]] name = "taotoken-glm" base_url = "https://taotoken.net/api" api_key_env = "TAOTOKEN_API_KEY" default_model = "glm-4-airx" fallback_model = "glm-4-air" # AirX 限流或超时时降级提示：
fallback_model是评测里很实用的一招。AirX 只有 8k 上下文，长 prompt 会被截断或报错，这时自动切到 Air 能保证任务不中断，同时你也能在日志里看到「这次是降级跑的」，不会污染速度对比。
配置里我把stream强制设为 true，原因在第四段会讲：非流式调用只能拿到总耗时，测不出首 token 延迟，而首 token 延迟恰恰是交互体验的关键指标。
4. 验证请求：测首 token 延迟与吞吐
评测的核心指标就两个：TTFT（Time To First Token，从发请求到收到第一个 token 的毫秒数）和吞吐（completion tokens 数除以生成耗时，单位 tokens/s）。用流式接口才能同时拿到这两个值。
下面这段 Python 脚本直接读上面的 config.toml，逐模型逐问题跑，输出对比表：
import os, time, tomllib from openai import OpenAI cfg = tomllib.load(open("config.toml", "rb")) client = OpenAI( base_url=cfg["provider"]["base_url"], api_key=os.environ[cfg["provider"]["api_key_env"]], ) def bench(model, prompt, rounds=3): ttfts, tps_list = [], [] for _ in range(rounds): t0 = time.perf_counter() first = None n_tokens = 0 stream = client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], stream=True, max_tokens=cfg["run"]["max_tokens"], temperature=cfg["run"]["temperature"], ) for chunk in stream: delta = chunk.choices[0].delta.content if delta: if first is None: first = time.perf_counter() ttfts.append((first - t0) * 1000) # ms n_tokens += 1 total = time.perf_counter() - t0 if n_tokens > 0: tps_list.append(n_tokens / total) ttfts.sort(); tps_list.sort() return ttfts[len(ttfts)//2], tps_list[len(tps_list)//2] for m in cfg["models"]: for p in cfg["prompts"]: ttft, tps = bench(m["model"], p["text"], cfg["run"]["rounds"]) print(f"{m['alias']:5s} | {p['id']:5s} | TTFT {ttft:7.0f} ms | {tps:6.1f} tokens/s")跑之前先装依赖：pip install openai tomllib（Python 3.11+ 自带 tomllib）。实测下来，同一台机器、同一网络下，GLM4-AirX 在通用问答和逻辑推理上的 TTFT 明显低于 Air，代码生成场景吞吐差距最大，AirX 能到 Air 的两倍左右；而 Air 在长文本、需要 128k 上下文的场景里反而更稳，因为 AirX 的 8k 窗口会先撞墙。
成功结果的判断标准：脚本能打印出每个模型每个问题的 TTFT 和 tokens/s，且同一模型三轮的中位数波动在 15% 以内。如果某一行 TTFT 是 0 或者报错，先看下一段的排查清单。
注意：测速时关掉本机的大流量下载、别同时跑其他推理任务，否则 TTFT 会被网络抖动带偏。建议每个模型先空跑一轮「热身」，不计入统计。
5. 本篇常见错排查
报 401 / invalid api key：九成是环境变量没生效。echo $TAOTOKEN_API_KEY确认有值，且脚本里读的是同一个变量名。如果你在 IDE 里跑，注意 IDE 可能没继承 shell 的环境变量，重启 IDE 或在运行配置里手动加。
报 model not found：模型名写错了。glm-4-airx和glm-4-air是全小写带连字符，别写成GLM4-AirX。以控制台模型列表里的标识为准。
TTFT 测出来是 0 或负数：说明你在非流式模式下计时，或者把first的赋值放错了位置。必须stream=True，并且在收到第一个非空delta.content时才记时间。
AirX 报上下文超限：AirX 只有 8k 上下文，长 prompt 或长历史会直接失败。评测长文本任务时要么换 Air，要么在 CC Switch 里配好fallback_model自动降级。
吞吐数字忽高忽低：单轮测量噪声大，至少跑 3 轮取中位数；另外max_tokens太小会让总耗时被固定开销主导，建议不低于 256。
流式输出中途断流：检查timeout_sec是否太短，长回答容易超时；也可能是网络链路抖动，重试一次即可，连续失败再查通道状态。
6. 把评测跑成日常流程
一次性的对比表意义有限，真正有用的是把它变成可重复的流程。我的做法是：把config.toml和上面的脚本放进仓库，每次模型有更新、或者你想加一个新模型，只改[[models]]数组，重跑一遍就得到新表。CC Switch 那边配好 TaoToken 的统一 profile，编码和 Agent 场景直接复用同一个 Key，不用再切来切去。
如果你主要做长期编码或 Agent 任务，可以了解下 Coding Plan https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite ，把高频调用和评测流量分开管理；接入细节和参数说明在接入文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 里，遇到字段对不上时先查文档再改代码。Key 的管理入口还是 API Keys https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite ，建议评测专用 Key 和日常 Key 分开建，用量一眼就能对上。
最后留一个我踩过的坑：别在同一个进程里并发跑两个模型的流式请求去「省时间」，GPU/网络资源会互相抢，TTFT 全乱。老老实实串行跑，多花几分钟，数据才可信。
