GLM-5.3 此前以“Ox Alpha”的匿名身份上线,并成为 OpenCode 与 OpenRouter 两个平台调用量最大的模型。如今智谱推出更快的 GLM-5.3-FlashX,最高生成速度达到 200 tokens/s。这个数字足够醒目,但对准备接入生产环境的团队来说,更值得关注的是:速度发生在哪个阶段、并发后能否保持,以及国产芯片集群如何支撑稳定的推理服务。
200 tokens/s 改变了哪些应用体验
对聊天机器人而言,20 tokens/s 已经可以形成连续输出的感觉;当速度提升到 100 甚至 200 tokens/s 后,生成环节可能不再是主要瓶颈。用户感知会更多取决于首 token 延迟、网络往返时间、上下文长度以及工具调用耗时。
FlashX 这类高速版本更适合以下负载:
- 代码生成与修改:一次输出数百行代码时,高吞吐可以明显缩短等待时间。
- 长文档整理:摘要、报告和结构化结果往往需要生成大量 token。
- Agent 工作流:模型需要在一次任务中多轮规划、调用工具和修正结果,单轮节省的时间会累积。
- 实时交互产品:语音助手、IDE 补全和交互式分析对延迟抖动比平均速度更敏感。
不过,“最高 200 tokens/s”不能直接理解为每个请求都能稳定获得这个速度。模型输出长度、输入上下文、采样参数、服务负载和网络位置都可能改变实测结果。它更像峰值能力指标,而不是服务等级承诺。
国产卡上的难点不只在矩阵计算
摘要提到,上一代 GLM 上线时,团队曾在由 10 万张国产芯片组成的集群上从零搭建推理服务。这个背景说明,高速推理并不只是把模型权重装进显存,然后启动一个 HTTP 服务。
大规模推理系统通常需要同时处理几类问题:
- 模型切分与通信:单卡无法容纳模型时,需要张量并行、流水线并行或其他切分策略。跨卡通信效率会直接影响生成速度。
- 请求调度:连续批处理可以提高芯片利用率,但批次过大又会拉高单请求延迟。
- KV Cache 管理:长上下文和高并发会快速占用显存。缓存分配、复用与淘汰策略决定了系统能承载多少会话。
- 算子与编译优化:模型能运行不等于运行得快。算子融合、量化、内存布局和编译器适配都会影响最终吞吐。
- 故障隔离:十万卡规模下,硬件故障和网络波动是日常事件,服务必须能够迁移请求并缩小故障范围。
因此,FlashX 的意义不应只看成单模型跑分。它也反映出模型、推理引擎、芯片适配和集群调度之间的联合优化。需要注意的是,来源摘要没有披露 FlashX 的具体并行策略、量化方式或硬件配置,不能仅凭 200 tokens/s 反推出这些实现细节。
用真实请求测首 token 和生成吞吐
接入模型前,建议分别记录首 token 延迟(TTFT)和首 token 之后的生成速度。下面是一个可以改造的 Python 基准脚本,假设服务提供 OpenAI 兼容接口;实际地址、模型标识和是否支持 stream_options,需要按服务文档调整。
先安装 SDK,并配置环境变量:
python -m pip install -U openai
export OPENAI_BASE_URL="https://your-endpoint.example/v1"
export OPENAI_API_KEY="replace-with-your-api-key"
export MODEL_NAME="glm-5.3-flashx"
将以下内容保存为 bench_glm.py:
import json
import os
import statistics
import time
from openai import OpenAI
client = OpenAI(
base_url=os.environ["OPENAI_BASE_URL"],
api_key=os.environ["OPENAI_API_KEY"],
)
model = os.getenv("MODEL_NAME", "glm-5.3-flashx")
prompt = """请为一个 Python Web 服务编写上线检查清单,覆盖配置、数据库、
可观测性、回滚和安全。输出约 800 个中文字符,使用 Markdown 列表。"""
def run_once():
started = time.perf_counter()
first_token_at = None
completion_tokens = None
parts = []
stream = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": prompt}],
temperature=0,
max_tokens=1000,
stream=True,
# 如果服务不支持该参数,请删除它;此时脚本无法得到精确 token 数。
stream_options={"include_usage": True},
)
for chunk in stream:
delta = chunk.choices[0].delta if chunk.choices else None
content = getattr(delta, "content", None) if delta else None
if content:
if first_token_at is None:
first_token_at = time.perf_counter()
parts.append(content)
usage = getattr(chunk, "usage", None)
if usage and usage.completion_tokens is not None:
completion_tokens = usage.completion_tokens
finished = time.perf_counter()
first_token_at = first_token_at or finished
generation_seconds = max(finished - first_token_at, 1e-9)
return {
"ttft_seconds": round(first_token_at - started, 3),
"total_seconds": round(finished - started, 3),
"completion_tokens": completion_tokens,
"generation_tokens_per_second": (
round(completion_tokens / generation_seconds, 2)
if completion_tokens is not None
else None
),
"output_characters": len("".join(parts)),
}
# 一次预热,减少连接建立和冷启动对结果的干扰。
run_once()
results = [run_once() for _ in range(5)]
print(json.dumps(results, ensure_ascii=False, indent=2))
print(
"median_ttft_seconds=",
statistics.median(item["ttft_seconds"] for item in results),
)
speeds = [
item["generation_tokens_per_second"]
for item in results
if item["generation_tokens_per_second"] is not None
]
if speeds:
print("median_generation_tokens_per_second=", statistics.median(speeds))
运行:
python bench_glm.py
这个脚本刻意把两个指标拆开:
ttft_seconds衡量用户等待多久才看到第一个输出片段。generation_tokens_per_second衡量开始输出后的平均生成速度。total_seconds则包含首 token 等待和完整生成过程。
如果接口不返回 token usage,不要用字符数直接冒充 token 数。中文字符、英文单词和代码经过 tokenizer 后的映射不同,此时可以报告字符吞吐作为辅助指标,但必须明确单位。
单请求快,不代表并发后仍然快
生产测试还需要逐步提高并发,例如分别测试 1、8、32 和 100 个并发请求。每一档至少记录:
- TTFT 的 P50、P95 和 P99;
- 完整请求延迟的 P50 与 P95;
- 成功率、超时率和限流比例;
- 每秒完成的请求数与输出 token 总量;
- 长上下文请求是否挤压短请求;
- 持续压测时速度是否因排队而下降。
峰值 tokens/s 适合回答“单条生成最快能有多快”,容量测试则回答“在目标流量下还能不能这么快”。对 Agent 系统,还应单独统计模型时间、工具执行时间和每个任务的模型调用次数,否则模型加速可能被慢数据库或外部 API 完全抵消。
接入前的决策清单
GLM-5.3-FlashX 值得在代码生成、长文本输出和低延迟 Agent 场景中进行实际评估,但不宜只凭峰值速度直接替换现有模型。上线前可以检查以下事项:
- 使用自己的提示词、上下文长度和输出格式做质量回归;
- 在相同网络区域、相同 token 上限下比较候选模型;
- 同时评估 TTFT、生成吞吐、并发容量和错误率;
- 确认模型标识、接口兼容性、限流策略和计费方式;
- 为超时、限流和服务波动准备重试、降级与备用模型;
- 对关键任务保留人工审核或确定性校验环节。
200 tokens/s 展示了国产芯片推理栈能够触及的速度上限。真正决定它能否进入生产环境的,则是这个速度在真实上下文、真实并发和真实网络条件下还能保留多少。