在本地部署大模型或者调用云端模型接口时最影响体感的问题往往不是“模型笨不笨”而是“生成得太慢”。你盯着屏幕等回复一段几百字的回答可能要等上十几秒这时你才会意识到模型质量决定了回答好不好推理速度却决定了你愿不愿意等下去。最近一个名为 Celeris-1 的项目登上了 AI 速度排行榜靠前的位置对外公布的指标是2,158 tokens per second。这个数字放进真实场景里是什么概念连续生成 2,000 多个 token耗时只需要 1 秒。也就是说一篇 1500 字左右的中文短文理论上不到 1 秒就能生成完体感上几乎接近“瞬间”。但如果你只是把这个数字当成“谁跑得快”的谈资那就错过了它的真正价值。2,158 tokens per second 的背后是芯片架构、内存带宽、推理引擎、量化精度和工程落地水平的综合结果。这篇文章想和你一起拆开“tokens per second”这个指标它到底怎么算、怎么看、怎么测以及当你想让自己的模型跑得更快时有哪些工程手段可以真正派上用场。文章会先从基本概念讲起再分析 Celeris-1 这类速度榜单意味着什么然后给出一套可以自己动手测试推理速度的脚本最后讨论推理速度优化的常用手段以及生产环境里容易踩的坑。全程不堆砌术语尽量用开发场景解释清楚。1. 这篇文章真正要解决的问题很多人看到“2,158 tokens per second”的第一反应是这个项目很厉害但跟我有什么关系如果你是一名算法工程师、后端开发、AI 应用开发者或者正在做大模型项目选型这个问题就和你直接相关。先说一个常见的开发场景。你接入了某个大语言模型 API功能开发完了联调时发现每次用户提问后模型“打字”的速度肉眼可见地慢。产品经理问能不能优化你第一反应是“这是模型的问题”但你心里清楚模型生成速度由多个环节共同决定模型大小、量化精度、推理框架、硬件类型、并发策略、上下文长度等因素没有一项是孤立的。再说一个更实际的选型问题。公司要采购 GPU 服务器或者选择云上的推理服务看了很多宣传材料有的说“每秒生成 100 token”有的说“支持 200 并发”。这些数字到底能不能直接对标很少有人告诉你跑分用的模型、输入长度、输出长度、批处理大小、精度格式不同结果可能差一个数量级。所以这篇文章真正想解决的问题有三个让你彻底看懂tokens per secondTPS这个指标知道它如何计算也知道它有哪些局限。借助 Celeris-1 登顶速度榜这件事帮你建立一个判断 AI 推理性能的分析框架。给你一套可以复用的测试方法以及优化推理速度的工程路径。如果你正在做大模型应用开发、推理服务部署或者打算在团队内引入性能压测这篇文章建议收藏备用。2. 读懂 tokens per secondAI 速度的核心指标2.1 什么是 token在聊 TPS 之前先要弄清楚 token 是什么。大语言模型不是按“字”或“单词”来理解文本的而是先把文本切分成更小的单元这些单元就叫 token。token 可以是完整的单词、单词的一部分、标点符号甚至一个字。不同分词器切出来的 token 数量差别很大。举例来说英文里一个常见单词通常是一个 token但一个长单词可能被切成两个或三个 token。中文里一个汉字有时是一个 token有时会和其他字组合成一个 token。特殊字符、代码、表格内容往往会占用更多 token。因此“每秒生成 100 token”和“每秒生成 100 个字”不是一回事。同样一段中文在不同分词器下的 token 数不同同样 TPS 下肉眼可见的“打字速度”也不一样。这是理解 TPS 时最容易忽略的第一个细节。2.2 tokens per second 是吞吐量还是延迟TPS 的公式非常简单TPS 生成的 token 总数 ÷ 生成耗时秒比如模型生成 1000 个 token耗时 20 秒TPS 就是 50。但这里有一个关键区别这一个 TPS 到底是“单条请求的生成速度”还是“系统整体吞吐量”两种口径下数值差异巨大。单请求 TPS用户发一条请求从模型开始生成第一个 token 到生成完毕计算平均每秒能出多少个 token。这个指标更接近用户的真实体验。系统吞吐量服务端同时处理 N 条请求总生成 token 数除以总耗时。这个指标更接近服务端容量评估。如果一个推理引擎支持连续批处理系统吞吐量可以很高但单条请求的生成速度未必快。这就是为什么看宣传数据时要先问一句这个 TPS 是在什么并发下测出来的2.3 为什么 TPS 不能代表一切TPS 是一个“平均速度”指标它掩盖了两个影响体验的重要因素。第一个是首 token 延迟TTFT。用户点击发送之后需要等待多久才能看到第一个字出现。TTFT 受输入文本处理、模型 Prefill 阶段、显存分配、网络传输等环节影响。即便 TPS 很高如果 TTFT 要 2 秒体验依然不够“跟手”。第二个是生成速度的波动。有的系统在输出短文本时很快但输出长文本时越往后越慢甚至出现明显的卡顿。这种情况在长上下文场景下尤其常见因为 KV Cache 越来越大内存带宽开始成为瓶颈。所以TPS 是衡量推理速度的入门口径但不是完整口径。看一个速度排行榜时除了看 TPS还要追问测试条件用什么模型、什么精度、什么输入长度、什么并发数、什么硬件。3. Celeris-1“登顶速度榜”背后的三个技术判断Celeris-1 以 2,158 tokens per second 的速度登顶 AI 速度排行榜这个新闻本身信息量有限因为缺少完整的测试条件说明。但从这类项目的通用特征来看我们可以做出几个比较稳妥的判断。3.1 推理效率正在成为竞争焦点前两年大家在拼模型参数和评测分数现在越来越多人开始关注“同一个任务谁跑得更快、更省”。Celeris-1 能靠“速度”登顶说明AI 推理效率已经是一个可以和模型质量并列的卖点。这背后的技术原因是当模型能力普遍提升差距缩小时部署成本和用户体验就成了差异化竞争的关键。同样跑一个 70B 模型A 方案需要 8 张卡B 方案通过量化、剪枝和优化引擎只需要 4 张卡同时还快 30%那么 B 方案显然更容易落地。3.2 内存带宽可能是最大的推手熟悉大模型推理的人都知道生成阶段是 memory-bound 的也就是说限制生成速度的往往不是算力而是内存带宽。生成每个 token 的时候模型都要把所有参数从头到尾读取一遍。模型参数越多需要从显存搬到计算单元的数据量就越大。如果内存带宽不够GPU 的计算单元就在空等。Celeris-1 能将 TPS 推到 2,158很可能在内存带宽、高速缓存或者参数加载机制上做了针对性优化。3.3 工程栈优化比单一硬件更关键单靠硬件很难达到极高的 TPS还需要推理引擎、算子库、显存管理、批处理调度等软件层面的深度配合。从实测角度观察许多速度榜单上的高 TPS 都是在以下条件的组合下达成的使用较小或经过剪枝的模型。使用 INT8 / INT4 量化精度。使用高带宽计算硬件。启用连续批处理和 KV Cache 复用。输入输出长度控制在较短范围内。离开这些条件谈 TPS 没有意义。所以面对“2,158 tokens per second”这个数字更合理的态度是把它看作一个信号说明这个方向有非常大的优化空间而不是直接拿它和生产环境的真实指标做对比。4. 评估 AI 推理速度不能只看一个数字如果你想为自己的项目选型或者评估一个推理服务快不快只盯着 TPS 一定会踩坑。下面这些维度建议一起看。4.1 关键指标对照表指标全称/别名衡量什么对体验的影响TTFTTime to First Token从发送请求到收到第一个 token 的时间影响“响应快不快”的第一印象TPOTTime per Output Token生成一个输出 token 的平均耗时影响“打字”的流畅度越低越好TPSTokens per Second每秒生成的 token 数综合速度越高越好Throughput吞吐量单位时间处理的请求数或 token 数影响系统容量和并发能力Concurrency并发数同时处理的请求数量影响成本、利用率和稳定性TTFT 和 TPOT 共同决定了用户实际感知的生成速度。一个推荐的排障思路是如果用户觉得“响应慢”先看 TTFT如果用户觉得“生成得慢”再看 TPOT 和 TPS。4.2 一个容易混淆的对比离线跑分与在线服务很多模型卡上会标注“在 A100 上跑出 XX TPS”但实际部署时你用的是另一套推理框架加上网络开销和并发排队结果可能完全不同。离线跑分通常是单请求、短输出、高精度的理想情况。在线服务则要考虑多用户共享、显存不足时的调度、动态批处理策略、安全过滤等额外开销。建议把“官方宣称的 TPS”和“你自己压测得到的 TPS”当成两个指标来管理。4.3 和成本放在一起看才公平TPS 高不代表成本低。同样的速度如果用 8 张高端卡才跑出来而另一个方案用 1 张中端卡跑出 70% 的速度综合成本可能反而更低。在核算成本时建议统计单位 token 的硬件成本。单位 token 的电力成本。并发能力提升带来的部署节点减少量。这部分能力恰恰是 Celeris-1 这类“速度榜选手”最需要补充证明的地方高速之外是否同时具备成本优势。5. 自己动手测推理速度最小验证脚本与其只看别人的榜单不如自己搭一个最小测试环境。这里给出两套方案分别适合测试单模型的速度和测试推理服务的吞吐量。5.1 环境准备本文演示统一使用 Python 3.10需要安装以下依赖pip install transformers torch accelerate如果准备测试 OpenAI 兼容接口的推理服务还需要pip install openai硬件方面建议至少有一块支持 CUDA 的 NVIDIA 显卡显存 8GB 以上。如果没有 GPU也可以使用 CPU 跑小模型但 TPS 数据会明显低很多。5.2 单请求 TPS 测试脚本下面这段代码用transformers加载一个生成模型向模型输入固定 prompt统计生成 512 个 token 的耗时。文件路径benchmark_tps.pyimport time import torch from transformers import AutoTokenizer, AutoModelForCausalLM model_id Qwen/Qwen2.5-0.5B-Instruct # 可替换成你实际使用的模型 tokenizer AutoTokenizer.from_pretrained(model_id) model AutoModelForCausalLM.from_pretrained( model_id, torch_dtypetorch.float16, device_mapauto ) prompt 请用一段话介绍机器学习并给出三个实际应用场景。 inputs tokenizer(prompt, return_tensorspt).to(model.device) input_len inputs.input_ids.shape[1] print(f输入 token 数: {input_len}) # 预热让显存分配稳定 with torch.no_grad(): model.generate(**inputs, max_new_tokens32) # 正式测试 start time.time() with torch.no_grad(): outputs model.generate( **inputs, max_new_tokens512, do_sampleFalse ) elapsed time.time() - start new_tokens outputs.shape[1] - input_len tps new_tokens / elapsed print(f生成 token 数: {new_tokens}) print(f耗时: {elapsed:.2f} s) print(f平均速度: {tps:.2f} tokens/s)运行方式python benchmark_tps.py这段代码的核心逻辑是先用 32 个 token 做预热避免把模型首次加载和显存分配的时间算进结果然后正式生成 512 个 token用“新增 token 数 / 耗时”得到 TPS。如果运行失败优先检查两点model_id是否对应 Hugging Face 上真实存在的模型路径显卡驱动和 PyTorch 的 CUDA 版本是否匹配。5.3 使用 vLLM 测试高并发吞吐量如果你已经在用 vLLM 部署推理服务可以直接用它的benchmark_throughput脚本。这里给一个更通用的方法用 OpenAI 兼容接口发起并发请求。先用 vLLM 启动服务vllm serve Qwen/Qwen2.5-0.5B-Instruct \ --max-num-seqs 16 \ --gpu-memory-utilization 0.9服务默认监听http://localhost:8000。再执行下面的并发测试脚本文件路径benchmark_concurrency.pyimport time import threading from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY ) prompt 请写一段关于人工智能发展的介绍。 results [] def send_request(idx): start time.time() response client.chat.completions.create( modelQwen/Qwen2.5-0.5B-Instruct, messages[{role: user, content: prompt}], max_tokens256, temperature0.0 ) elapsed time.time() - start tokens response.usage.completion_tokens results.append({idx: idx, tokens: tokens, elapsed: elapsed}) threads [] for i in range(8): t threading.Thread(targetsend_request, args(i,)) threads.append(t) t.start() for t in threads: t.join() total_tokens sum(r[tokens] for r in results) total_time max(r[elapsed] for r in results) print(f总生成 token 数: {total_tokens}) print(f总耗时: {total_time:.2f} s) print(f系统吞吐量: {total_tokens / total_time:.2f} tokens/s)这个脚本用 8 个线程模拟 8 个并发请求统计系统总吞吐量。需要注意的是线程模拟只能代表基础并发场景严谨的压测建议使用locust、k6或 vLLM 自带的压测脚本。5.4 如何判断测试结果是否正常判断跑得快不快不能只看一个数字要把测试条件固定下来同一个模型要选择同一个精度。输入输出长度要一致。并发数要记录清楚。硬件型号和显存占用要记录。在这个基础上如果你发现自己的 TPS 和榜单数据差了很多优先排查是否启用了量化、是否开启了连续批处理、输入输出长度是否一致、是否有其他服务占用显存。6. 推理速度优化的常用工程手段了解自己的基线速度之后下一步就是对症下药。下面这几种优化手段是当前生产环境中最常用、效果最明显的。6.1 权重量化用精度换速度量化是降低模型存储和计算开销的最直接手段。把 FP16 权重降到 INT8 甚至 INT4可以显著减少显存占用和内存带宽压力从而提升生成速度。常见的量化方案方案精度适用场景注意点FP16 / BF1616 位默认最稳妥显存占用高INT8 量化8 位生产环境常见精度损失较小INT4 量化4 位显存紧张、追求高吞吐精度可能明显下降如果使用transformers可以用bitsandbytes加载 4-bit 模型from transformers import BitsAndBytesConfig, AutoModelForCausalLM import torch quant_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_compute_dtypetorch.float16 ) model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-0.5B-Instruct, quantization_configquant_config, device_mapauto )6.2 连续批处理提升系统吞吐传统批处理要等一批请求都到齐才开始处理浪费严重。连续批处理Continuous Batching允许新请求随时插入到当前批次中正在生成的请求完成后就移除把位置让给新请求。vLLM、TensorRT-LLM、SGLang 这些推理框架默认支持连续批处理。启用后系统吞吐量往往可以提升数倍。这也是同一个模型在原生transformers和 vLLM 里表现差异巨大的主要原因之一。6.3 编译优化让算子跑得更快torch.compile可以优化计算图减少算子启动开销。对部分模型这一项能带来可观的性能提升。model torch.compile(model)不过torch.compile并非对一切模型都有效存在首次编译耗时长、部分自定义算子不兼容的问题。生产环境使用前建议先做小规模验证。如果追求更极致的性能可以尝试 TensorRT-LLM它为 NVIDIA GPU 做了深度算子优化但学习成本和部署复杂度更高。6.4 KV Cache 优化与上下文长度控制长上下文是性能杀手。上下文越长KV Cache 占用显存越多生成阶段的注意力计算量也越大。实测中经常出现“同一模型上下文从 2K 扩展到 32K 后TPS 下降超过一半”的情况。优化思路包括尽量在提示词阶段就压缩上下文减少冗余内容。使用支持 PagedAttention 的推理框架避免 KV Cache 碎片化。对超长文档先做检索只把相关片段拼进上下文。6.5 模型并行与负载均衡当单个模型超出单卡显存时需要采用张量并行或流水线并行。但要注意并行度提高不一定会提升单请求速度因为通信开销也会增加。并行通常优先解决“能不能装下”的问题其次才是“能不能更快”。在服务层面可以在推理服务前加负载均衡层按 GPU 利用率或队列长度分发请求避免单点过热。7. 常见问题与排查思路下面整理了大模型推理速度优化中经常遇到的问题。这些问题在测试 Celeris-1 或自建推理服务时同样会遇到。问题现象可能原因排查方式解决方案TPS 明显低于预期未启用连续批处理检查推理框架配置换成 vLLM / TensorRT-LLM 部署首 token 延迟过高输入长度过长Preflfill 计算量大在日志中埋点统计 TTFT限制输入长度增加检索过滤并发一高速度就掉显存不够导致换入换出监控显存占用和 GPU 利用率减小批次大小增加节点启用量化量化后回答质量下降INT4 精度损失对比量化和未量化的输出改用 INT8或针对性做评测集验证长文本生成越来越慢KV Cache 占用增大观察生成后段时间趋势限制 max tokens使用 KV Cache 优化框架卡上显存占用很高但 TPS 低模型过大参数搬运频繁查看显存与算力利用率使用量化或选择小模型多卡并行后速度没有提升通信开销超过计算收益观察通信占比调整并行策略或减少并行卡数排查时有一个通用原则先把“速度”拆成 TTFT 和 TPOT 两个阶段再分别打点。不要笼统地说“服务很慢”而是确认慢在 prefill 阶段还是 decode 阶段这样定位问题的范围会小得多。8. 最佳实践与生产建议8.1 做任何压测前先固定测试基线一个标准的速度测试至少需要记录以下几项模型名称和版本。权重精度比如 FP16、INT8、INT4。推理框架名称、版本、启动参数。GPU 型号、数量、显存大小。输入 token 长度、输出 token 长度。并发请求数。结果TPS、TTFT、TPOT、系统吞吐量、延迟 P50/P99。没有基线的速度对比都是不可信的。在团队内做选型评估时建议用同一份基线表统一不同方案的对比口径。8.2 速度优化不能牺牲正确性量化、改并行策略、压缩上下文都可能在提升速度的同时影响模型输出质量。建议为线上模型准备一个回归测试集优化前后跑一遍对比关键任务的输出质量和格式稳定性。如果只是追求 TPS 而忽略精度很可能在业务指标上吃大亏。比如客服场景中模型输出一段金额计算错误省下的那点推理时间完全没有意义。8.3 生产环境变更前先验证、备份、可回滚涉及推理服务上线、量化方案切换、框架升级时建议遵循先在测试环境压测确认 TPS 和输出质量都达标。备份当前可用的模型权重和推理配置。采用灰度发布方式先在少量流量或内部用户中验证。保持旧版本可回滚一旦发现质量问题立即切回。这条原则同样适用于任何对数据库、配置文件、生产服务做出的变更。速度指标再好看也比不上线上稳定性重要。8.4 监控指标要覆盖“速度”和“资源”两面建议重点监控以下指标GPU 利用率。显存占用与 KV Cache 占用。请求队列长度。TTFT、TPOT、TPS 的 P50 和 P99。平均每条请求的 token 成本。把这些指标接入现有监控系统后后续做优化时才有数据支撑而不是凭感觉调参。9. 总结与后续学习方向Celeris-1 以 2,158 tokens per second 登上 AI 速度榜这件事本身更像是给行业提了一个醒当模型能力逐渐趋同推理速度和部署成本会变成下一个决定胜负的战场。对普通开发者来说与其纠结这个数字的真假不如借着这个话题把 tokens per second 彻底弄懂再亲手训练一套自己的推理速度测试流程。这篇文章的重点回顾一下TPS 是一个“平均速度”指标要结合 TTFT、TPOT、并发数、量化精度和硬件环境一起看。榜单数字只有在同一测试条件下才可比不要拿别人宣传的峰值和自己本地的实际速度做直接对比。推理优化有清晰的工程路径量化、连续批处理、编译优化、KV Cache 优化、并行策略每一步都需要用数据验证。速度和正确性必须一起管优化后一定要回归测试输出质量。如果你接下来想深入可以从这几个方向入手学习 vLLM 的 PagedAttention 原理了解 TensorRT-LLM 的算子优化思路再研究一下 INT8/INT4 量化对各类任务的实际影响。对照着手里的模型和硬件把基线跑出来再逐步试优化手段你会发现自己也能把推理速度提到一个满意的水平。