GLM-5.3-FlashX 冲到 200 tokens/s:真正该测的不只是生成速度

2026-09-18 23 预计阅读时间: 1 分钟
来源: oschina.net AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:10 分钟

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 服务。

大规模推理系统通常需要同时处理几类问题:

  1. 模型切分与通信:单卡无法容纳模型时,需要张量并行、流水线并行或其他切分策略。跨卡通信效率会直接影响生成速度。
  2. 请求调度:连续批处理可以提高芯片利用率,但批次过大又会拉高单请求延迟。
  3. KV Cache 管理:长上下文和高并发会快速占用显存。缓存分配、复用与淘汰策略决定了系统能承载多少会话。
  4. 算子与编译优化:模型能运行不等于运行得快。算子融合、量化、内存布局和编译器适配都会影响最终吞吐。
  5. 故障隔离:十万卡规模下,硬件故障和网络波动是日常事件,服务必须能够迁移请求并缩小故障范围。

因此,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 展示了国产芯片推理栈能够触及的速度上限。真正决定它能否进入生产环境的,则是这个速度在真实上下文、真实并发和真实网络条件下还能保留多少。


相关推荐