Diffusion LLM速度实测：理解tokens/s并编写Python基准测试脚本

1. 背景与核心概念1.1 为什么大模型圈开始卷“生成速度”过去一年里大家对大语言模型LLM的关注点发生了很明显的变化早期大家比的是谁更“聪明”也就是谁能答对更难的问题、谁写代码更准到了应用落地阶段讨论的重心逐渐转移到“快不快”“贵不贵”“能不能撑住线上并发”。尤其是使用 API 生成中长文本时那种等上十几秒、几十秒才能看到完整回复的体验几乎每一个做过 LLM 应用开发的读者都深有体会。响应慢不仅是体验问题还会直接推高单次请求的耗时和成本。如果业务是批量生成文章、批量处理工单、批量做内容总结那么每秒能输出多少 token往往直接决定了这条链路能不能在预算内跑起来。Celeris-1 这个名字就是在这种背景下进入大家视野的。“Celeris”在拉丁语中有“快速”的含义从命名就能看出这款模型的核心指向输出速度。根据公开 benchmark 信息Celeris-1 跑出了约 2,082 output tokens/s 的输出速率。换句话说在一秒钟之内模型可以生成大约两千多个 token 的文本内容。这个数据放在当下的大模型输出吞吐场景里属于相当亮眼的成绩。但“2,082 tokens/s”到底是怎样一个概念它是否意味着所有场景下都能达到这个速度要回答这些问题我们得先从 token、自回归生成、扩散模型这几个基础概念说起。1.2 先搞清楚 tokens 和 tokens/s很多刚接触大模型的读者容易把 token 当成“字”或者“词”其实 token 是模型处理文本的最小单位。以中文为例一个汉字可能对应一个 token也可能因为分词方式不同一个词被切分成一到多个 token。英文场景中一个单词往往会被拆成两三个 token。所以 token 数并不等于字符数也不完全等于词数。衡量一次大模型请求的规模时通常会区分输入 tokenprompt 部分的 token 数和输出 token模型生成内容的 token 数。很多 API 服务商的计费也是按“输入 token 输出 token”的总量来计算的也就是一些文档里提到的 TPMTokens Per Minute口径。output tokens/s全称是 output tokens per second翻译过来就是“每秒输出 token 数”。这个指标专门衡量模型的生成阶段速度不算输入部分的处理耗时也不包括请求排队的时间。比如一个模型在 5 秒内生成了 1000 个 token那么它的输出速率就是 200 tokens/s。看起来只是简单的除法但在实际 benchmark 中这个数字会受到硬件、量化精度、序列长度、批处理大小、是否流式输出等多种因素的影响。同一个模型在不同环境下跑出来的 output tokens/s 可能相差好几倍这也是为什么我们不能简单拿一个“官方成绩”去推导所有场景的表现。1.3 自回归 LLM 为什么慢要理解 diffusion LLM 的价值先要知道传统大语言模型普遍采用的生成方式自回归Autoregressive。自回归生成的核心逻辑是“逐 token 预测”模型先根据输入 prompt 生成第一个 token然后把第一个 token 拼到输入序列后面继续生成第二个 token接着生成第三个、第四个……一直循环到输出结束。每一步都依赖前面已经生成的所有内容因此无法在 token 级别做大规模并行。这种串行机制在理论上很清晰但在实际推理时会遇到明显的性能瓶颈。首先随着序列变长每一步需要“重新看”的上下文越来越长计算量会持续增加其次每一步都要读写 KV Cache键值缓存显存带宽往往会成为限制速度的关键因素。你可以把自回归生成想象成一个人写文章必须写完前一个字才能写下一个字哪怕后面的内容已经在脑子里想好了也得一个字一个字地落到纸上。这就是为什么传统 LLM 即使硬件很好生成速度也很容易被卡在每秒几十到几百个 token 的区间内。当然业界已经有很多优化手段比如 KV Cache 管理、continuous batching、投机解码speculative decoding、量化推理等这些技术都能显著提升吞吐。但自回归本身的“串行天花板”还是存在的。于是研究者开始寻找另一种思路能不能让模型像生成图片一样一次“铺开”生成整段文本而不是逐字排队这就是 diffusion LLM扩散大语言模型要解决的问题。1.4 Diffusion LLM生成方式的“路线切换”Diffusion 这个词做过图像生成的同学一定不陌生。Stable Diffusion、Midjourney 这些工具背后的 Diffusion Model扩散模型走的是另一条生成路径先对数据不断加噪直到变成近似纯噪声然后训练模型学会“去噪”从随机噪声中一步步还原出目标图像。这个过程中模型在每一步都能对整张图同时做预测天然具备并行生成的能力而不需要像文本自回归那样严格按顺序生成像素。既然扩散模型可以在图像这种高维数据上工作研究者自然会想文本的 token 序列能不能也放到扩散框架里于是出现了 diffusion LLM 这一研究方向。简单理解扩散式语言模型把文本 token 映射到一个连续空间模型在推理时从一个噪声向量出发经过若干步去噪逐渐还原出完整的 token 序列。它不需要严格地“第一个 token 生成完再生成第二个”而是可以在多步迭代中不断修正整段内容这让并行计算变得更容易也让输出吞吐有了更大的提升空间。Celeris-1 正是这个方向上的一个代表。根据项目公开信息它被定位为 diffusion LLM并以 2,082 output tokens/s 的输出速率作为核心 benchmark 亮点。如果你之前只接触过自回归型的大模型看到这个数字大概率会感叹原来文本生成也能这么快。但在实际使用之前我们需要做几件事准备合适的调用环境理解 output tokens/s 的测量口径写一个属于自己的基准测试脚本然后才能客观地评估这个模型适不适合你的业务。2. 环境准备与版本说明2.1 验证思路三种常见方式想要了解 Celeris-1 的实际输出速度通常有三种途径。第一种是直接访问官方提供的 API通过接口调用模型统计返回结果中的 token 数和耗时这是最接近真实业务的方式也是本文实战部分演示的方式。第二种是本地部署模型权重自己搭建推理服务这种方式的优点是环境可控可以反复压测但部署成本较高并且对 GPU 显存和推理框架有要求。第三种是参考第三方评测机构或公开榜单的 benchmark 数据这种方式省事但很难还原到自己的硬件和业务场景中。本文实战部分采用第一种思路使用 OpenAI 兼容的 HTTP 接口写一个 Python 脚本完成请求、计时、统计 token、输出速率计算。为什么强调“OpenAI 兼容”因为目前大多数新模型在对外提供服务时为了方便开发者接入都会参考 OpenAI 的接口格式。只要模型服务方提供了兼容接口你只需要修改 base_url 和 model 名称脚本基本不需要大改。2.2 运行环境与依赖清单在开始之前先明确一下环境要求。虽然不同的模型服务商对 Python 版本可能有一些细微差异但以下环境在绝大多数场景下都能正常工作操作系统Linux、macOS、Windows 均可但建议使用 Linux 服务器进行性能测试减少图形界面和后端进程对测试结果的干扰。Python3.10 或更高版本本文示例使用 Python 3.11 编写。网络环境能够访问模型服务地址内网测试需要确保网络带宽稳定。Python 依赖openai SDK用于调用 OpenAI 兼容接口requests 库备用方案。本文示例代码的重点是演示 benchmark 思路而不是绑定某个具体平台的 SDK。因此版本号不需要严格控制建议打开终端执行pip install openai1.30.0装成当前环境可用的较新版本即可。如果你使用的是其他推理框架比如 vLLM、TGI 或者本地部署的任意 OpenAI 兼容服务接口地址和请求参数基本都是通用的。2.3 项目目录与依赖安装为了方便后续拓展我们先创建一个干净的项目目录。这里的目录结构并不复杂但保持清晰对后面的实验有好处。llm-benchmark/ ├── benchmark.py ├── requirements.txt └── README.mdrequirements.txt 内容如下openai1.30.0然后在项目目录下创建虚拟环境并安装依赖Linux 或 macOS 下执行cd llm-benchmark python -m venv venv source venv/bin/activate pip install -r requirements.txt如果是 Windows 环境激活虚拟环境的命令略有不同cd llm-benchmark python -m venv venv venv\Scripts\activate pip install -r requirements.txt这里使用虚拟环境的原因是避免污染系统 Python 环境。后续如果我们要安装或升级 SDK 版本只需要在虚拟环境里操作不会影响机器上其他 Python 项目的依赖。依赖装好之后下面一步就是理解核心指标并编写测试脚本。3. 核心概念拆解output tokens/s 背后有哪些变量3.1 output tokens/s 的准确计算方式output tokens/s 最常见的一句话定义是模型生成阶段“每秒输出的 token 数量”。计算方式是用模型生成的 token 总数除以生成阶段耗时。但实际操作时有两个细节非常容易踩坑。第一个细节是“输入耗时”要不要算进去。一次完整的 API 请求通常包括网络传输、服务端排队、输入处理、生成、返回传输等阶段。如果直接把“从发起请求到收到完整响应”的耗时作为分母那得到的其实是端到端速率end-to-end throughput不是严格意义上的 output tokens/s。严格的做法是只有服务端真正开始生成之后才算时间。但普通开发者无法精确拿到服务端内部的时间戳所以我们可以通过多次请求取平均值尽量减少网络抖动和其他阶段的影响。第二个细节是“输出 token 数从哪里读取”。使用 OpenAI 兼容接口时响应体中的usage字段里会包含prompt_tokens、completion_tokens和total_tokens。其中completion_tokens才是模型实际生成的输出 token 数应该拿它作为分子。如果用每分钟口径来算就是 TPMTokens Per Minute很多服务商的限流配额也用它来定义。假设某个模型输出速率为 2,082 tokens/s那么换算成每分钟大约是 124,920 tokens/min。这只是一个单纯的速度换算不涉及输入 token。但如果你在服务商控制台看到的 TPM 限额写的是“输入 输出总和”那就要注意了实际消耗的 TPM 是 prompt_tokens 与 completion_tokens 之和而不是只看输出部分。3.2 首 token 延迟与生成速率不能混为一谈与 output tokens/s 密切相关的另一个概念是 TTFTTime To First Token也就是从发起请求到收到第一个 token 的时间。很多人容易把“生成速度慢”统一归因于 tokens/s 太低但实际上如果 TTFT 很高比如等待 5 秒才看到第一个字那么即使后续每秒能输出几千个 token用户的体感依然是“很卡”。TTFT 和 output tokens/s 共同决定了端到端延迟。举个例子假设 TTFT 是 0.5 秒输出速率是 2,082 tokens/s那么生成 1000 个 token 大约需要 0.5 1000 / 2082 ≈ 0.98 秒。如果 TTFT 涨到 4 秒输出速率不变生成 1000 个 token 的总时长就变成了约 4.48 秒。所以在评估 Celeris-1 这类速度型模型时不要只看每秒输出多少个 token还要关注在线交互场景下的首 token 延迟。对于聊天机器人这类实时性要求高的场景TTFT 往往比峰值输出速率更重要而对于离线批量生成任务output tokens/s 才是决定总耗时的关键。3.3 哪些变量会影响 tokens/s即便 Celeris-1 在 benchmark 中跑出了 2,082 output tokens/s这个数字也不是一个恒定值它会随环境变化而波动。主要有以下几个变量。第一是硬件和推理框架。GPU 型号、显存带宽、是否使用 vLLM 等高性能推理引擎、是否开启 continuous batching都会直接影响输出速度。官方 benchmark 用的硬件配置与生产环境不一致时数据会有明显差异。第二是精度与量化。模型权重使用 FP16、BF16、FP32 还是 INT8 量化会影响计算速度和显存占用。较低精度的推理通常更快但可能需要牺牲一点生成质量。如果你的应用对质量不是极端敏感可以优先尝试量化版本。第三是 batch size。在服务端一次推理请求中可以同时处理多个样本。batch size 越大GPU 利用率越高整体吞吐也越高。但 batch size 过大会增加单次请求的排队等待时间所以服务端往往需要平衡吞吐和延迟。第四是输入序列长度和输出长度。输入越长模型处理 prompt 的耗时越长也会占用更多 KV Cache。输出越长生成阶段累积的耗时越长。加上模型大多支持流式输出实际测到的 tokens/s 可能和一次性返回的测法不同。3.4 扩散模型与相关热词的关系搜索 Celeris-1 相关资料时经常同时出现 Stable Diffusion、Flow Matching、diffusion policy 这些词。这里做一个简单的概念区分。Stable Diffusion 是图像领域的扩散模型代表它生成的是像素Celeris-1 这类 diffusion LLM 生成的是文本 token两者共享“加噪-去噪”的思想但处理的数据类型和模型结构不同。Flow Matching 是扩散模型的一种推广通过设计更直接的“噪声到数据”路径来加速采样经常被视为扩散模型的一个演进方向如果你后面去读 diffusion LLM 的最新论文大概率会遇到它。diffusion policy 则是机器人决策领域的概念研究如何用扩散模型生成动作序列和大语言模型关系不大但“扩散用于序列生成”的底层思路是相通的。对于本文主题而言我们不需要把每个方向的细节都吃透。重点是理解扩散模型擅长从噪声中逐步恢复完整结构这种能力一旦迁移到文本生成上就有潜力摆脱自回归模型的串行瓶颈从而带来更高的输出吞吐。4. 完整实战案例用 Python 写一个吞吐测试脚本4.1 设计目标这一节我们动手写一个 benchmark 脚本。脚本的目标非常明确在真实 API 环境下测出模型的输出 token 数和端到端耗时然后计算出 output tokens/s。设计上要满足三个要求一是输出信息尽可能完整包括输入 token 数、输出 token 数、耗时、速率方便多轮对比二是支持多次请求取平均值避免单次网络抖动造成误判三是代码尽量简洁方便换成任何 OpenAI 兼容接口。为了便于初学者理解我们把脚本拆成三个简单的函数build_client负责创建客户端run_single_request负责执行一次请求并返回统计数据main负责参数解析和多次循环。4.2 编写核心代码在项目目录下新建benchmark.py完整代码如下# 文件路径llm-benchmark/benchmark.py import argparse import time from openai import OpenAI def build_client(api_key: str, base_url: str) - OpenAI: 创建 OpenAI 兼容客户端 return OpenAI( api_keyapi_key, base_urlbase_url, ) def run_single_request( client: OpenAI, model: str, prompt: str, max_tokens: int, ): 发起一次请求返回耗时、输入token数、输出token数、输出内容 start time.perf_counter() resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], max_tokensmax_tokens, ) elapsed time.perf_counter() - start prompt_tokens resp.usage.prompt_tokens completion_tokens resp.usage.completion_tokens content resp.choices[0].message.content return elapsed, prompt_tokens, completion_tokens, content def main(): parser argparse.ArgumentParser(descriptionLLM 输出速度基准测试) parser.add_argument(--api-key, defaultsk-xxx, helpAPI Key) parser.add_argument( --base-url, defaulthttp://localhost:8000/v1, helpOpenAI 兼容接口地址, ) parser.add_argument(--model, defaultceleris-1, help模型名称) parser.add_argument( --prompt, default请用 500 字介绍扩散模型的核心思想。, help测试提示词, ) parser.add_argument(--max-tokens, typeint, default500, help最长输出 token 数) parser.add_argument(--rounds, typeint, default5, help测试轮数) args parser.parse_args() client build_client(args.api_key, args.base_url) total_completion_tokens 0 total_elapsed 0.0 print(f模型: {args.model}) print(f地址: {args.base_url}) print(f提示词: {args.prompt}\n) for i in range(1, args.rounds 1): elapsed, prompt_tokens, completion_tokens, content run_single_request( client, args.model, args.prompt, args.max_tokens ) speed completion_tokens / elapsed if elapsed 0 else 0.0 total_completion_tokens completion_tokens total_elapsed elapsed print( f第 {i} 轮: 输入{prompt_tokens} tokens, f输出{completion_tokens} tokens, f耗时{elapsed:.2f}s, f速率{speed:.2f} tokens/s ) if total_elapsed 0: avg_speed total_completion_tokens / total_elapsed else: avg_speed 0.0 print(f\n平均输出速率: {avg_speed:.2f} tokens/s) print(f折合每分钟: {avg_speed * 60:.0f} tokens/min) if __name__ __main__: main()这段代码有几个关键点需要解释。time.perf_counter()是 Python 里精度较高的计时函数比time.time()更适合做性能测试。resp.usage.completion_tokens是服务端返回的真实输出 token 数直接作为分子。elapsed是从发起请求到拿到完整响应的时间虽然它包含了网络和排队阶段但对于普通开发者来说这是最容易获得的端到端统计口径。如果你的服务端支持流式返回还可以用流式方式单独计算 TTFT这部分我们在后面补充。4.3 补充流式测试观察首 token 延迟有些时候我们不仅关心平均输出速率还想知道“用户多久能看到第一个字”。这时可以把请求改成流式模式在收到第一个 content 片段时记录时间戳。下面是流式版本的核心片段仍然放到benchmark.py中# 流式示例统计首 token 延迟 import time from openai import OpenAI client OpenAI( api_keysk-xxx, base_urlhttp://localhost:8000/v1, ) responses client.chat.completions.create( modelceleris-1, messages[{role: user, content: 讲一下 diffusion LLM 的优势}], streamTrue, ) first_token_time None received_text start time.perf_counter() for chunk in responses: if not chunk.choices: continue delta chunk.choices[0].delta if delta and delta.content: if first_token_time is None: first_token_time time.perf_counter() - start received_text delta.content print(f首 token 延迟: {first_token_time:.4f}s) print(f总耗时: {time.perf_counter() - start:.2f}s) print(f接收文本长度: {len(received_text)} 字符)需要注意的是流式接口返回的是逐步到达的文本片段服务端不一定会在每个 chunk 中附带 usage 信息因此用流式方式精确统计 token 数比较困难。上面的示例用“接收文本长度”做了一个近似。如果想要更精确的 token 统计最好还是使用非流式接口或者在流式结束后从服务端提供的统计字段中读取准确数字。流式测试的真正价值在于 TTFT也就是用户等待第一个字出现的时间这个指标在聊天机器人场景中非常重要。4.4 运行与验证依赖安装完成、脚本保存之后就可以运行了。如果模型服务运行在本机的 8000 端口可以直接执行python benchmark.py --model celeris-1 --max-tokens 500 --rounds 3如果你的服务地址是远程 API比如https://api.example.com/v1则需要同时指定--base-url和--api-keypython benchmark.py \ --base-url https://api.example.com/v1 \ --api-key sk-your-key \ --model celeris-1 \ --prompt 请写一篇 800 字的技术博客大纲 \ --max-tokens 800 \ --rounds 5预期输出大致如下模型: celeris-1 地址: http://localhost:8000/v1 提示词: 请用 500 字介绍扩散模型的核心思想。 第 1 轮: 输入31 tokens, 输出412 tokens, 耗时0.31s, 速率1329.03 tokens/s 第 2 轮: 输入31 tokens, 输出388 tokens, 耗时0.27s, 速率1437.04 tokens/s 第 3 轮: 输入31 tokens, 输出401 tokens, 耗时0.29s, 速率1382.76 tokens/s 平均输出速率: 1381.94 tokens/s 折合每分钟: 82916 tokens/min这里的数字只是示例不一定能代表 Celeris-1 的真实环境表现。如果你在自己的环境里测出来的数值和官方 benchmark 差异较大不要急着下结论先检查一下网络延迟、服务端负载、max_tokens 设置、是否开启流式、是否使用量化版本。性能测试最忌讳的是“一次测量就定性”多跑几轮、多换几种提示词才能得到比较稳定的结论。4.5 如何解读结果假设脚本运行后得到的平均输出速率明显低于 2,082 tokens/s可能有几个原因。如果模型是远程 API网络往返时间会占据比较大比例尤其是短输出场景一次请求的耗时里网络传输可能占了很大一块计算出来的 tokens/s 自然偏低。如果模型是本地部署那么 GPU 型号和推理框架就对结果影响很大。另外prompt 长度和 max_tokens 设置也会影响测速输出 token 数越少网络和请求解析的固定开销占比越高输出越长越能反映模型生成阶段的真实速度。所以在几个模型之间做对比时建议固定同一套测试参数同样的 prompt、同样的 max_tokens、同样的轮数、同一个服务端环境。只有控制变量比较出来的数字才有意义。5. 常见问题与排查思路在实际测试和部署 diffusion LLM 的过程中大家可能会遇到一些重复出现的问题。为了方便查阅我整理了一张问题排查表。问题现象常见原因解决思路输出 tokens/s 远低于官方 benchmark远程 API 网络延迟高服务端负载大测试输出长度过短在内网环境测试多轮取平均提高 max_tokens调用时报错 “Model not found”模型名称写错服务地址不对未开通该模型权限检查文档中的模型名称确认 endpoint联系服务商响应体中无 usage 字段接口不是 OpenAI 兼容格式开启了流式但未解析 usage改用非流式接口从 final chunk 读取统计信息手动统计的 token 数与 API 返回不一致tokenizer 不同中英文分词方式差异使用 API 返回的 completion_tokens不要直接用字符数换算测试时偶发超时或连接中断网络不稳定并发过大触发限流增加重试机制降低并发检查服务端日志TPM 额度消耗比预期快输入 prompt 过长输入输出都计入 TPM缩短 prompt使用缓存关注输入 token 占比除了表格中的常见问题这里补充一个排查顺序。第一步确认接口连通性用一个最简单的 curl 请求测试服务是否正常返回。第二步确认模型名称和参数类型比如max_tokens是否被服务端支持。第三步确认响应中的 usage 字段是否正常如果 usage 缺失脚本就会直接报错。第四步再做性能测试。按照这个顺序逐步排查大部分问题都能快速定位。另外要提醒一点如果模型服务是你自己用推理框架搭建的那么服务端日志里的“平均生成吞吐”“每请求耗时”等统计信息往往是最权威的排障依据。客户端的计时会受到网络影响但服务端日志记录的是模型真实的推理耗时两者对比能帮你区分问题出在网络还是出在模型本身。6. 最佳实践与工程建议6.1 场景选型Diffusion LLM 适合什么业务Celeris-1 这类 diffusion LLM 的优势是输出吞吐高适合文本生成量大、对单次请求延迟不是极端敏感的场景。比较典型的是离线批量内容生成比如批量生成商品描述、批量总结文档、批量生成测试用例还有高吞吐的客服机器人在对话质量达标的前提下更高的输出速度意味着更小的服务器压力或更低的 API 成本。但如果你的业务是强交互式对话用户每输入一句话都希望立刻得到响应那就要重点考察 TTFT 而不是只看 output tokens/s。扩散模型在迭代去噪过程中往往需要多步计算如果工程优化不到位首 token 延迟可能不如成熟的自回归模型。这里的建议是先做一轮完整 benchmark分别测 TTFT、output tokens/s、端到端延迟和生成质量再决定是否替换原来自回归模型。6.2 Benchmark 标准化做性能测试时最怕的不是模型慢而是测试口径不一致导致得到的结论无法复用。建议在团队内部形成一套固定的 benchmark 规则。固定硬件环境比如 GPU 型号、CPU、内存、推理框架版本、模型精度。固定测试集比如准备三到五条不同长度的 prompt覆盖短文本、中文本、长文本。固定统计口径同时记录 TTFT、端到端耗时、output tokens/s、TPM 换算值并且注明是否使用流式接口。测量次数也很重要。单次请求的结果受网络波动和服务端调度影响很大建议至少跑 5 到 10 轮取中位数或平均值。如果某些轮次出现明显异常比如某次请求超时导致耗时暴涨可以把异常值标记出来而不是简单混入平均计算。只有数据可复现benchmark 才能成为后续优化和选型的依据。6.3 精度、量化与成本权衡部署 diffusion LLM 时精度选择是个绕不开的话题。FP16 和 BF16 是目前大模型推理中比较常用的精度类型。FP16 计算速度通常不错但表示范围有限训练或推理时需要注意溢出风险BF16 保留了和 FP32 类似的指数范围更适合大模型场景尤其是在训练和推理过程中数值变化剧烈的场景。如果你追求更大的吞吐还可以尝试 INT8 或 INT4 量化但量化后模型的生成质量可能会有所下降需要在测试集上做对比评估。从成本角度看output tokens/s 越高意味着同样的 GPU 资源单位时间内能服务的请求越多分摊到每个 token 的推理成本就越低。这也是 Celeris-1 这类模型最吸引人的地方。但在实际商务选型中不能只看速度。要看单位成本下生成的内容质量是否达标要看服务是否稳定还要看生态是否完善。速度只是其中一环。6.4 生产环境的安全与稳定性建议不管是调用第三方 API 还是自己部署模型服务都需要注意安全边界。API Key 要按最小权限原则管理定期轮换不要写死在代码仓库里可以通过环境变量或配置中心注入。做性能压测之前先确认服务端配额和限流策略避免测试请求打满生产环境影响真实用户。使用服务商提供的沙箱环境或者专用的测试环境进行压测是更稳妥的做法。对于自己部署的服务建议开启详细的访问日志和性能指标采集比如每轮请求的耗时、输出 token 数、服务端吞吐、排队长度。这样一旦线上出现速度异常可以快速定位是模型问题、硬件问题还是网络问题。还要注意热更新模型配置时先在灰度环境验证确认稳定后再全量发布避免一次配置变更拖垮整个推理服务。7. 总结与下一步从“跑分”到“可用”Celeris-1 让我们看到了 diffusion LLM 在输出速度上的潜力。2,082 output tokens/s 这个数字放在大模型推理吞吐的语境下确实值得关注。但作为一个开发者更重要的不是记住某个 benchmark 数值而是理解这个数据是怎么测出来的以及它对自己的业务意味着什么。本文从 token 和 tokens/s 的概念讲起对比了自回归 LLM 与 diffusion LLM 的生成差异然后给出了一个可以直接运行的 Python 吞吐测试脚本最后梳理了常见的排查问题和工程最佳实践。如果你对 diffusion LLM 这条路产生了兴趣下一步可以去看几个方向的内容扩散模型的基础原理尤其是加噪和去噪的数学过程Flow Matching 方法为什么能加速采样以及 vLLM 这类推理框架如何优化输出吞吐。理解了这些你就能更理性地看待未来的新模型和新 benchmark也能在自己的项目中更快地做出选型判断。最后想提醒所有读者下次再看到“某某模型跑到 XXX tokens/s”的宣传文案先不要急着兴奋可以先问一句——这个数字是在什么硬件上、用什么精度、什么测试条件、什么序列长度下跑出来的把这个问题想清楚你就比大多数只看标题的人更接近真相了。