Celeris-1 以 2158 tokens per second 的生成速度在 AI 推理速度排行榜上冲到了第一。这个数字一出来很多人第一反应是它凭什么这么快我的第二个问题是这个速度放到我们自己的机器上还成立吗跑分榜单上的数值和真实项目里的可用性从来不是同一个东西。下面不打算复述新闻而是拆一遍 tokens/s 这个指标怎么测、怎么理解以及为什么 Celeris-1 能冲到 2158自己部署同类模型时却不一定能复现相同数据。1. Celeris-1 跑到 2158 tokens per second这个数字究竟代表什么1.1 tokens per second 是什么不是普通的“每秒单词数”大模型处理文本时的最小单位是 token而不是我们日常读到的完整单词。英文里一个 token 大约对应 3 到 4 个字符所以一个普通英文单词可能被拆成 1 到 3 个 token。中文的情况更复杂一个汉字有时候是一个 token有时候是两个具体要看分词器和模型。tokens per second简称 tokens/s表示模型每秒能够生成多少个 token。如果按英文粗略换算2158 tokens/s 大约是每秒生成 500 到 800 个英文单词。这个速度比绝大多数人阅读文本的速度还要快。也就是说模型生成一段 1000 个英文单词的内容理想情况下只需要两三秒。但要注意这个“理想情况”很重要。实际使用里生成速度并不是恒定的。上下文越长注意力计算量越大后面生成的速度通常会变慢。榜单上测到的 2158 tokens/s通常是在设计好的固定 prompt、固定输出长度、固定并发数下得到的峰值或均值和现实场景里随机输入、长上下文、多用户并发的结果并不完全一致。1.2 排行榜第一不代表所有场景都快Celeris-1 能在速度排行榜上排第一说明它至少在榜单定义的那套测试条件下推理吞吐做得非常好。但如果要在办公场景、客服机器人、内容生成工具里实际替换现有模型不能只看这个数字。原因很简单榜单测的是生成吞吐不是响应延迟。一个只能回答“你好”的模型和一个能写长报告的模型如果都在测长文本生成前者的 tokens/s 可能会更高但这不是它更好而是它生成的内容更短、更简单。真实业务里用户更关心首字返回要多快、长文本能不能稳定生成、多用户同时用的时候会不会排队卡顿。所以我的判断是Celeris-1 最值得关注的不是“第一名”这个位置而是背后使用了什么推理优化手段以及这些手段能不能迁移到自己的模型部署环境里。2. 速度是测出来的先确认测试环境再谈复现2.1 硬件资源GPU、显存、内存、CPU 都会影响 tokens/s我自己做过不少次推理测速最大的感受是同一个模型换一张卡速度差别能拉到好几倍。大模型生成 token 的过程非常依赖显存带宽GPU 的型号和显存类型直接决定了上限。如果你要复现 2158 tokens/s 这个数字至少要先确认测试机器是什么级别的 GPU是单卡还是多卡有没有使用高速互联。普通家用显卡和专业计算卡之间的差距不是软件优化能完全弥补的。显存容量同样重要。模型太大、显存放不下的时候框架会自动把部分参数放到内存里跨内存读取会让速度断崖式下跌。除了显存CPU 和内存也会影响速度。尤其在加载模型、做 token 编码、处理并发请求时CPU 过弱会成为瓶颈。评估一台机器能不能跑快我一般会看四个东西GPU 型号、显存容量、内存大小、磁盘类型。磁盘影响的是热加载和冷启动不能漏掉。2.2 模型体积与量化精度同一个模型不同精度速度差别很大同样一个 7B 模型用 FP16 跑和用 INT4 量化跑速度可能差 50% 以上。量化的本质是把模型权重从高精度压缩到低精度减少显存占用和计算量。INT4 因为权重更小显存带宽压力更小所以生成速度通常更快。但速度变快不全是免费的。量化可能带来精度损失尤其对数学推理、代码生成这类任务比较敏感。榜单如果用了量化后的模型那么 2158 tokens/s 就不是原模型的最佳速度而是“压缩后模型”的速度。在复现测速结果之前一定要先搞清楚三件事模型的参数规模是多少是 7B、13B 还是 70B。模型权重是 FP16、BF16还是 INT8、INT4。是否使用了量化工具比如 AWQ、GPTQ、GGUF 里的 Q4_K_M。这些条件只要有一个不一样测出来的 tokens/s 就没有直接可比性。2.3 推理框架和依赖版本环境不同成绩可以差 30% 以上同样的硬件和模型用 Hugging Face transformers 硬跑和用 vLLM、TensorRT-LLM、llama.cpp 这类专门优化的推理框架跑速度差距非常明显。推理框架做的事不只是加载模型还包括算子融合、KV Cache 管理、动态批处理、显存分配等。很多人只看模型本身忽略了框架版本。比如 CUDA 版本太老、PyTorch 版本不匹配、cuDNN 缺失都会导致程序找不到正确的算子最后退回到低效实现。常见表现是能跑但速度上不去GPU 利用率也不高。所以复现任何跑分第一步不是改参数而是把环境信息完整记录下来。包括 GPU 驱动版本、CUDA 版本、推理框架版本、依赖包版本、模型权重的 sha256 或者来源。没有这些测出来的数字就是孤立的没法对比。3. 一轮完整测速流程从启动到记录结果3.1 第一步先跑一个最小样例不要一上来就测并发和长文本。先跑一个单条、短输出的最小样例确认模型能加载、能推理、能正常返回结果。我一般会准备一个非常短的 prompt比如“请用一句话介绍自己”设置输出长度不要超过 100 个 token。这样做的原因很简单如果最基础的通路都跑不通后面调并发、调参数只会让问题更复杂。如果你用的是常见推理框架启动命令里通常会包含模型路径、端口、量化参数等。跑通之后要确认三件事模型是否成功加载。返回内容是否符合预期。日志里有没有 warning 或 error。这一步不急重点是排除环境问题。报错不一定是模型问题可能是路径、权限、依赖版本或输入格式问题。3.2 第二步记录生成速度和资源占用最小样例跑通后再开始测速。测速最直接的方法是记录从收到请求到生成完成的总耗时以及实际生成的 token 数量然后用 token 数除以耗时。比如生成了 200 个 token耗时 1.2 秒那么 tokens/s 大约是 166。这个算法简单但要注意不能把 prefilled 阶段的耗时混进去。大模型第一次接收到 prompt 时需要把输入文本处理成缓存这个过程称为 prefill。prefill 的快慢和输入长度强相关和生成速度不是一回事。更完整的记录至少包括首 token 延迟也就是从发出请求到第一个 token 返回的时间。平均生成速度也就是生成阶段的 tokens/s。总体耗时包括排队、prefill、生成、传输。显存占用、显存峰值、GPU 利用率。这些信息可以帮助判断瓶颈在哪。如果 GPU 利用率一直很低说明 CPU 和 GPU 之间的数据传输有瓶颈如果显存峰值接近容量上限那么并发稍微增加就很容易 OOM。3.3 第三步多次运行取一个稳定区间单次测速结果不可信。第一次运行可能包含模型加载预热、算子编译、缓存建立速度偏慢。连续跑几次之后速度通常会上升然后进入相对稳定的区间。所以我建议连续测 5 到 10 次短输出和长输出分开测记录每次的 tokens/s然后看波动范围。如果数值来回跳说明机器上可能有其他任务在抢占资源或者模型推理过程中有显存碎片、动态显存分配等问题。榜单通常只给一个最高或平均数字但我们在自建评测时更该看“稳定区间”。稳定区间才代表真实部署环境下用户会体验到的性能。4. 影响 tokens/s 的关键因素逐个拆开看4.1 模型参数量和激活内存模型参数量越大每秒能生成的 token 通常越少。原因不只是权重占用显存还有计算量。推理过程中每一层都要读取权重并计算中间激活值参数量越大每一步计算越重。假设 Celeris-1 的榜单成绩是在高性能 GPU 上测出来的我们部署在普通环境里速度当然会差很多。同类模型在 7B 和 13B 之间速度可能差 40% 到 50%。如果模型超过 70B单卡基本跑不动需要多卡并行或模型分片通信开销又会进一步拉低速度。4.2 批量请求数对吞吐的影响tokens/s 有两种算法单条请求每秒生成多少个 token以及系统总吞吐。同一个模型batch size 从 1 调到 8总吞吐可能提升很多但单条请求的响应速度可能变慢。原因在于大模型支持连续批处理。框架可以把多个请求拼在一起计算共享矩阵乘法的开销。这样一来每条请求的生成速度未必提升但整体每秒生成的 token 总数会上升。榜单如果测的是系统吞吐那 2158 tokens/s 可能来自多个并发请求的总和而不是单条请求的速度。所以看到这个数字时先问一句是并发 N 条请求的总吞吐还是单条请求的生成速度这是一个很关键的区别。4.3 前缀缓存与 KV Cache大模型生成时会缓存历史 token 的 Key 和 Value这部分缓存叫 KV Cache。缓存越大后续生成需要重新计算的量就越少。同一个 prompt 反复被请求时如果框架支持前缀缓存速度会明显提升。这个能力在聊天机器人、智能客服场景里非常有用。很多用户问的问题开头相似比如“请帮我写一封邮件”这部分前缀可以先缓存不需要每次重新计算。但如果每次请求的 prompt 都完全不同前缀缓存就起不了太大作用。所以 Celeris-1 的榜单测试如果用了固定 prompt那自然能获得缓存优化带来的速度增益。真实场景里请求五花八门速度会下降。4.4 输出长度和任务类型输出长度对 tokens/s 的影响很直接。短输出任务的总耗时主要花在 prefill 和首 token 上平均 tokens/s 可能很高因为只有几秒钟生成。长文本生成任务中生成阶段占主导速度更接近稳定值但会因为上下文变长而逐渐变慢。上下文越长每次生成一个新 token 时模型都要重新读取之前所有 token 的 KV Cache计算量随时间线性增加。这就是为什么很多模型在长文本生成后期会越来越慢。如果你是做新闻稿批量生成、长文章续写这类任务单看排行榜的 2158 tokens/s 没有太大意义更该关注模型在 2048、4096、8192 上下文下的实际吞吐。此外任务类型也会影响速度。代码生成、数学推理这类任务虽然 token 数和文本生成任务相同但采样策略可能不同比如需要输出更长的思考过程或者需要调用工具这些都会增加额外时间。4.5 并发排队与接口延迟如果模型被部署成 HTTP 服务用户感受到的速度就不只是推理速度还包括排队时间和网络传输时间。高并发场景下请求会进入队列。即使单条请求的 tokens/s 很高一旦排队整体体验也可能很差。指标上有个常见误区只关心单请求生成速度忽略 QPS、P99 延迟和排队长度。生产环境里一个系统稳不稳定往往不取决于峰值 tokens/s而取决于高并发下的 P95、P99 延迟是否可接受。如果 P99 延迟从 1 秒涨到 10 秒即使平均 tokens/s 没降用户也会觉得系统变慢了。所以当你看到某个模型在速度排行榜上领先时最好追问一句榜单测试并发是多少请求长度分布是什么有没有包含排队时间5. 为什么实测通常跑不到榜单数字5.1 榜单常用的短输出样例和真实场景不一致很多推理速度榜单为了快速出结果会使用固定 prompt比如输入 128 个 token输出 128 个 token。这样跑一轮很快便于横向对比。但实际业务里输入可能是几十行日志输出可能是一整篇文章长度和动态变化都远超榜单样例。我自己实测过一些模型用短 prompt 测出来的速度是 50 tokens/s换成 2000 字的中文长文生成后速度可能掉到 30 tokens/s。原因就是上下文变长导致计算量增加加上显存占用升高缓存命中率下降。所以当 Celeris-1 的成绩没有附带输入长度、输出长度、并发数时这个数字只能作为参考。你必须在自己的数据和场景里重新测一遍。5.2 首 token 延迟和生成速度是两个指标实时交互场景中首 token 延迟的重要性甚至超过生成速度。用户点击发送后如果 5 秒内什么都看不到会觉得很卡。即使后续每个 token 都非常快最初的等待也会破坏体验。推理流程里prefill 阶段处理整个输入 prompt输入越长首 token 时间越长。榜单如果只公布 tokens/s看不出首 token 延迟。有可能一个模型生成速度快但 prefill 很慢另一个模型生成速度稍慢但首 token 很快。对聊天机器人来说后者可能体验更好。因此评价一个模型或推理服务的速度至少要同时看首 token 延迟和生成吞吐。只看 2158 tokens/s容易忽视实时性。5.3 稳定性、长文本和错误重试才是生产关键跑分是一次性的生产是持续的。一个模型在测试里跑出很高的 tokens/s不代表它在连续运行一整天后还能保持这个速度。热积累、显存泄漏、KV Cache 没释放、长连接耗尽都会让服务越跑越慢。生产环境还需要考虑失败重试、超时、日志记录、输出一致性、并发安全。批量任务尤其要关注失败跳过和断点续跑。比如一次生成 100 篇文章如果第 50 篇因为显存峰值超限崩掉了整个队列全停那之前的 2158 tokens/s 就没意义。我见过太多项目只盯着峰值速度忽略了稳定性和错误处理。最后真正上线时真正的瓶颈往往不是模型算不快而是服务在持续压力下不稳定。6. 想让推理速度更快优先从这些方向优化6.1 先做量化再考虑换模型如果你的目标是让普通单卡环境跑得更快第一步先做量化。从 FP16 降到 INT8 或 INT4显存占用和计算量都会下降。量化的精度影响可以通过混合量化、校准数据来缩小。注意量化不是万能的。小模型量化后速度提升明显但大模型量化后反而可能因为解量化操作增加额外开销。建议在目标硬件上实测比较 FP16、INT8、INT4 的真实 tokens/s 和输出质量。6.2 调整批处理和缓存参数在服务部署时优先检查 batch size、max_num_seqs、prefix caching、max_model_len 这几个参数。不同的框架叫法不同但背后逻辑一致批量越大吞吐越高延迟也会变高。最开始不要追求最大并发先保持少量并发稳定运行再逐步增加。KV Cache 的容量也是关键。如果框架允许配置 cache 内存上限可以调大一些提升长上下文命中率。但显存有限时调大缓存会增加 OOM 风险。建议边改边用一个小脚本监控显存占用别等到服务崩溃才去检查。6.3 换用更合适的推理服务框架如果目前只用 transformers 的generate接口速度通常不够理想。可以考虑切到 vLLM、TensorRT-LLM、llama.cpp 等更高效的推理框架。这些框架的算子融合、连续批处理、KV Cache 管理都做得更深入。但要提醒一点换框架不是简单的改一行代码。需要用对应的量化格式重新转换模型还要确认框架支持的算子范围。如果模型里有某些自定义层或算子可能无法完全加速甚至会报错。建议先在测试环境里跑通一个最小样例再切换到生产。6.4 如果只是学习先别急着上高并发很多人一拿到新模型就想着部署成高并发服务。结果机器配置不够显存爆掉日志刷满整个环境一团糟。更好的顺序是先用小模型、小批量、短输入跑通再把参数慢慢往上加。学习阶段单卡 7B 模型、batch size 为 1、输出 256 token已经足够验证大部分功能。真要压榨性能再考虑多卡和并发优化。低配置能跑不代表适合批量跑这一点要提前认清。7. 常见坑与排查清单7.1 现象速度很慢或输出为空先看输入和日志速度慢不一定是模型不行先检查输入格式。有的模型只接受特定对话模板直接拼一段文本进去可能输出为空或胡言乱语。还有编码问题中文输入在切换编码后容易变成乱码导致 tokenizer 效率下降。日志里如果出现 fallback、CPU offload、warning说明慢可能不是因为模型本身而是环境配置不对。建议按这个顺序排查输入文本是否符合预期的对话格式。模型加载路径是否完整量化文件是否缺失。日志里有没有显存不足、算子 fallback 的警告。依赖版本是否和推理框架兼容。7.2 现象并发一高就超时先看排队和显存并发高的时候报超时不一定是因为模型生成变慢很可能是请求在排队。打开框架自带的监控看队列长度、每秒请求数、显存占用率。显存接近上限时框架会等待空闲缓存表现就是请求排队。解决思路通常有三个降低并发数、减少 max_model_len、增加显存容量。注意不要同时调大并发和长度否则会加速 OOM。7.3 现象速度波动大先看热重启、调度和共享环境如果你发现同一模型的速度忽高忽低不要急着调量化。先确认服务器上有没有其他进程抢占 GPU有没有容器频繁重启有没有 CPU 自动降频。共享 GPU 环境下其他人的任务也会影响你的速度。再检查框架是否开了动态批处理。动态批处理会等待几个请求合并后再开始计算低峰期吞吐高但单请求延迟不稳定。这是正常现象需要根据业务类型取舍。兜底做法是在固定时间、固定环境、固定请求下连续跑 10 次用中位数而不是最高值作为参考。这样得到的数字才更接近真实能提供给用户的速度。Celeris-1 跑出 2158 tokens per second 的成绩至少说明 AI 推理速度优化的天花板还在被不断抬高。但对我们这些要实际部署模型、做产品、处理批量任务的人来说比追逐第一名更有价值的是把测试条件、资源占用、稳定性和真实场景指标都摸清楚。先把单任务跑稳再把并发和长文本问题处理干净榜单数字才有落地的意义。