Celeris-1 最近在 AI 推理速度排行榜中冒了出来以 2,158 tokens per second 的成绩冲到前列。这个数字对普通用户来说可能只是一个漂亮的指标但对于做模型部署、服务性能调优、做 AI 工程落地的人来说它背后涉及的知识量其实很大tokens per second 到底代表什么影响这个指标的因素有哪些我们手里的模型能不能也优化到这个数量级本文就以这个新闻为切入点把推理速度指标、测量方式、优化手段和常见坑点梳理一遍。如果你是刚刚接触大模型开发还没有弄清楚“token”和“TPS”的概念不用着急我会从最基础的概念讲起。如果你已经在做推理服务优化可以直接跳到后面的实测脚本和优化清单里面有些命令和代码可以直接复制到项目里使用。1. 背景AI 速度排行里的“新面孔” Celeris-11.1 排行榜的意义在哪里AI 领域现在有很多排行榜有的比模型效果比如问答准确率、代码生成通过率、多模态理解能力有的比推理速度这类排行榜通常会把同一个模型跑在不同硬件、不同推理引擎上再统计每秒能生成的 token 数量。Celeris-1 的 2,158 tokens per second 之所以被关注并不仅仅是因为数字本身大而是因为推理速度直接关系到产品体验。你在网页端使用 AI 对话时从点击发送到看到第一个字再到内容逐渐输出每个环节都和时间有关。如果模型生成速度慢用户就会觉得“卡”如果速度快到一定程度人眼几乎感知不到逐字输出的延迟交互体验就会非常接近真人对话。对一个服务于真实业务的技术团队来说推理速度还关系到成本。同样一台 GPU每小时能处理的请求越多单次推理的成本就越低。速度排行榜实际上反映的是“在相同硬件和模型条件下通过优化能达到什么程度”。这也是为什么很多团队会把 tokens per second 当成核心观测指标。1.2 2,158 tokens per second 意味着什么我们可以先把 2,158 这个数字放到实际场景里感受一下。中文大约平均一个字对应 1 到 1.5 个 token英文单词和 token 的对应关系比较复杂但可以粗略认为 1 个单词约等于 1.3 到 1.5 个 token。假设按照 1 token 约等于 0.75 个汉字来估算每秒生成 2,158 个 tokens相当于一秒钟可以生成约 1600 个汉字左右每分钟接近 100000 个汉字。一般的阅读速度是每分钟几百字也就是说它的生成速度已经远远超过人的阅读速度。这个速度带来的典型变化是流式输出不再是一段一段地“挤”出来而是几乎瞬间填满对话内容。对用户体验而言大段代码、长篇文章、批量数据处理任务的等待感会被明显削弱。不过需要提醒的是排行榜上的数字通常是在特定测试条件下得到的比如使用特定的 batch 大小、输入序列长度、量化精度、显存、显卡型号以及推理框架。不同条件下测得的 tokens per second 差异可能很大甚至相差数倍。所以关键不是记住某个排行榜数字而是理解这个数字是怎么测出来的以及它能不能复现到自己的项目环境里。1.3 本文面向的读者本文主要面向以下三类读者第一类是正在做大模型部署和推理优化的开发者你可能已经能把模型跑起来但发现输出速度不理想想弄清楚瓶颈在哪里。第二类是刚接触大模型工程、对 tokens per second 这类指标有概念但不够系统的学习者你希望通过一篇文章把测速、优化、排错的流程串起来。第三类是准备做技术选型的工程师你需要比较不同推理框架、不同硬件组合的性能差异那么理解 TPS 的测量方法和影响因素就非常重要。文中涉及的概念不会太深但也不会只停留在“什么是 token”这种层级。我会给出可运行的测速脚本、不同推理引擎的对比思路、参数优化建议以及常见报错排查方法。2. 认识 tokens per second 指标2.1 什么是 token在大模型领域token 是模型处理文本时的最小单位。模型并不是像人一样一个字一个字地阅读而是把输入文本切分成若干 token再通过神经网络计算这些 token 之间的关联。不同分词器对 token 的切分方式不同。比如 OpenAI 的 cl100k_base 分词器会把常见英文单词直接切成一个 token把罕见单词切成多个子词中文字符通常 1 个 token 对应 1 到 2 个汉字。模型每次生成一个 token然后把这个 token 拼接到输入序列末尾再继续预测下一个 token直到生成结束标记或达到最大长度。理解这一点的意义在于tokens per second 测量的是“大模型生成文本的速度”而不是字符速度。同一句中文在不同分词器下 token 数量可能不一致所以不同模型之间的 TPS 不能简单看数字还要看分词策略。2.2 tokens per second 的统计口径tokens per second简称 TPS指模型每秒生成的 token 数量。统计公式很简单TPS 生成总 token 数 / 生成耗时秒但在实际操作中我们需要区分两个时间段第一个是 prefill 阶段也就是处理输入提示词的过程。模型要把用户输入的上下文完整计算一遍生成 KV Cache为后续解码做准备。这个阶段通常计算量大、耗时长但它不产生可见的文本输出。第二个是 decode 阶段也就是逐 token 生成回复的阶段。从用户界面上看到的“打字机”效果主要发生在这个阶段。很多测速工具报告的 TPS 只统计 decode 阶段也就是从第一个 token 生成到最后一个 token 生成的平均速度。这样做的原因是 prefill 阶段耗时与输入长度强相关如果把它计入整体时间会稀释模型“生成”本身的速度。但也有工具会把完整请求时间纳入计算。这就是为什么同一模型在不同测试文章中 TPS 数字不一致不是模型变了而是统计口径变了。2.3 还需要关注哪些配套指标只看 TPS 是不完整的。一个高 TPS 模型如果首字延迟很长用户在页面上还是会感觉“半天不出结果”。因此工程上通常把以下三个指标放在一起看第一个是 TTFTTime to First Token指从发起请求到生成第一个 token 的时间。这个时间主要受 prefill 阶段影响输入越长TTFT 越长。第二个是 TPOTTime Per Output Token指生成每一个输出 token 的平均耗时。TPOT 的倒数乘 1000 就是单流场景下的 TPS。比如 TPOT 为 20 毫秒时单请求 TPS 约为 50。第三个是端到端延迟End-to-End Latency指整个请求从发起到完成的总耗时等于 TTFT 加上所有后续 token 的生成时间。在实际服务中系统可能同时处理多个请求所以还需要关注吞吐量throughput单位是“每秒处理的请求数”或“每秒钟所有请求生成的 token 总数”。吞吐量高并不一定意味着单个请求速度快因为系统可能把同一批请求合并处理牺牲单请求延迟来换取整体吞吐。2.4 为什么 2,158 这个数字值得关注当看到“2,158 tokens per second”时我们会自然地想到两个问题它是在什么硬件上达到的它用了什么推理优化如果这个成绩是在高性能服务器上配合专用加速器和静态批处理得到的那么数字主要代表“优化后的系统峰值能力”如果它是单路请求在通用消费级显卡上跑出来的那意味着相关技术可以在普通开发者的设备上复现。文章标题虽然没有给出完整测试环境但它至少在传递一个信号通过合理的批处理、量化、缓存和推理框架优化模型推理速度可以达到远超人眼感知范围的水平。这让我们后续优化自己的服务时有了更明确的方向。3. 影响 TPS 的核心因素TPS 不是模型一个因素决定的它是“模型 硬件 推理框架 推理参数 服务架构”共同作用的结果。下面拆开来看每个环节的影响。3.1 模型参数规模与量化方式模型参数量越大推理时需要的计算量越大生成速度通常越慢。7B 模型和 70B 模型在相同硬件上TPS 可能相差接近一个数量级。为了让大模型跑得更快量化是常用手段。所谓量化就是把模型权重从 FP16 或 FP32 精度转换成 INT8、INT4 等低精度格式。低精度带来的好处有两点一是模型权重占用的显存变小可以容纳更大的模型或更大的 batch二是部分硬件对低精度矩阵计算有专门加速单元计算速度更快。不过量化不是完全没有损失。虽然主流量化方案通常能保持较好的生成质量但在极端低比特、敏感任务上仍可能出现生成质量下降。选择 INT8、INT4 还是 FP8需要做评测。3.2 硬件与推理引擎GPU 的显存带宽是影响 decode 阶段速度的一个核心因素。解码过程每次生成一个 token都需要把模型权重从显存中读取一遍。权重读取速度越快单个 token 产生得就越快。这也是为什么有些模型的参数量明明很大但在高端显卡上依然能保持不错的速度高端显卡显存带宽更高。反过来如果显存带宽不够即使 GPU 算力很强decode 速度也会被“搬运权重”这个环节卡住。推理引擎同样重要。同一份模型权重在不同推理框架中经过的算子融合、优化调度水平不同最终速度差异很明显。常见选择有 Hugging Face Transformers、vLLM、TensorRT-LLM、ONNX Runtime、llama.cpp 等。它们各有适用的部署场景Transformers 适合研究和快速验证vLLM 在服务化场景下支持连续批处理TensorRT-LLM 适合追求极致性能llama.cpp 对 CPU 和苹果芯片支持较好。3.3 输入序列长度与 KV Cache模型生成过程中需要不断读取之前所有 token 的注意力计算结果这些缓存叫做 KV Cache。输入序列越长KV Cache 越大每一步计算时的访存量也越大速度就越慢。这也是为什么测速时通常要限定输入长度。例如“TLD;DR”数据集测速可能只需要几十个 token 的输入而代码任务可能需要输入 2000 甚至更多 token。输入短生成的 TPS 就会好看很多。KV Cache 显存占用还和并发量相关。如果 8 个请求同时进行每个请求的 KV Cache 都会占用显存显存不足时就会被迫降低并发影响整体吞吐。3.4 推理参数的影响decode 阶段的生成策略对 TPS 也有明显影响。贪心解码greedy decoding和温度采样temperature sampling在计算方式上略有不同但额外开销通常不大。真正影响速度的是 beam search。beam search 在每一轮同时保留多个候选序列内部会维护多个 KV Cache计算量成倍增加。相比之下greedy 和 sample 的 TPS 会高很多。max_new_tokens 也会影响体验。如果设置过短模型在输出过程中频繁被截断看起来好像生成很快但结果不完整。如果设置过长模型可能在结束标记已经出现后仍继续占着资源但这种情况通常会被设计为提前终止不一定显著影响 TPS。3.5 并发与批处理从单用户角度来看TPS 只反映单个请求的生成速度。但从服务端角度看同一时刻可能有多个请求服务端可以把请求合并到一个 batch 中统一进行矩阵计算从而提升 GPU 利用率。传统静态批处理需要等 batch 填满才开始推理会增加延迟。vLLM 等框架引入连续批处理请求完成一个就插一个新请求不需要一直等这样可以在不显著增加单请求延迟的情况下提升整体吞吐。如果你在自己的服务中做压测可能会发现一个规律并发从 1 增加到 8 时单请求 TPS 略有下降但系统总吞吐明显上升并发继续增加显存可能不够用速度反而下降。这就是一个典型的权衡过程。4. 如何实测 TPS一份可以直接运行的脚本了解影响因素之后最好亲自动手测一下。下面我给出一个测速脚本的思路。这个脚本基于 Hugging Face Transformers逻辑清晰、适合对照学习如果你希望在生产环境用更高性能框架可以替换成 vLLM、TensorRT-LLM 或 llama.cpp 对应的测速方式。4.1 准备测试环境建议准备一台配置了 GPU 的服务器显存至少 8GB。如果没有 GPU也可以使用 CPU 测试但速度会慢很多主要用来验证脚本流程。Python 环境建议使用 3.10 及以上版本。安装依赖pip install torch transformers accelerate注意torch 的版本需要和你的 CUDA 环境匹配。安装时可以直接使用 PyTorch 官网给出的命令例如pip install torch --index-url https://download.pytorch.org/whl/cu124如果你只需要在 CPU 上测试可以安装 CPU 版pip install torch --index-url https://download.pytorch.org/whl/cpu4.2 编写测速脚本下面是一个完整的 Python 脚本它完成以下工作加载一个生成式语言模型。构造固定输入文本。执行预热生成避免首次加载和 CUDA 初始化的干扰。正式计时统计生成 token 数。计算并打印 TPS、TTFT 和 TPOT。# 文件路径benchmark_tps.py import time import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-1.5B-Instruct device cuda if torch.cuda.is_available() else cpu print(f加载模型: {model_name}, 设备: {device}) tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, trust_remote_codeTrue, torch_dtypetorch.float16 if device cuda else torch.float32, ).to(device) model.eval() prompt 请用中文写一段关于人工智能发展的介绍大约300字左右。 inputs tokenizer(prompt, return_tensorspt).to(device) # 预热避免首次调用时 CUDA 初始化影响速度 with torch.no_grad(): _ model.generate( **inputs, max_new_tokens32, do_sampleFalse, use_cacheTrue, ) # 正式测量 torch.cuda.synchronize() if device cuda else None start time.time() with torch.no_grad(): output model.generate( **inputs, max_new_tokens256, do_sampleFalse, use_cacheTrue, ) torch.cuda.synchronize() if device cuda else None end time.time() input_len inputs[input_ids].shape[1] output_len output.shape[1] new_tokens output_len - input_len elapsed end - start tps new_tokens / elapsed ttp elapsed / new_tokens # 平均每个 token 耗时单位秒 print(f输入 tokens: {input_len}) print(f输出 tokens: {new_tokens}) print(f总耗时: {elapsed:.4f} 秒) print(f平均 TPS: {tps:.2f} tokens/s) print(f平均每个 token 耗时: {ttp * 1000:.2f} ms/token)4.3 运行与结果解读在命令行中执行python benchmark_tps.py如果一切正常会输出类似下面的信息加载模型: Qwen/Qwen2.5-1.5B-Instruct, 设备: cuda 输入 tokens: 22 输出 tokens: 256 总耗时: 3.2145 秒 平均 TPS: 79.64 tokens/s 平均每个 token 耗时: 12.56 ms/token注意这只是示例输出实际数字取决于你的显卡、模型和输入长度。如果你在性能更强的显卡上运行更小的模型TPS 可以达到几百甚至上千如果使用 CPU 运行较大的模型TPS 可能只有个位数。但这并不代表模型“不行”而是硬件限制。4.4 测速时容易出现的三个错误第一个错误是不预热。CUDA 在第一次推理时会有初始化开销如果不预热直接计时TPS 会偏低而且每次运行结果波动很大。第二个错误是不做 CUDA 同步。在 GPU 上PyTorch 的部分操作是异步的time.time()可能先于 GPU 实际计算完成执行导致统计时间偏短。正确的做法是在计时结束后调用torch.cuda.synchronize()。第三个错误是输入太短。如果 prompt 只有几个字符prefill 阶段耗时几乎可以忽略测出的 TPS 主要反映 decode 速度如果你的实际业务输入是长文本就应该用接近真实场景的长度测试。4.5 用 vLLM 做更贴近生产的测速Transformers 的generate方便但不够高效。如果你已经在做服务化部署更推荐使用 vLLM 做测速。它的 API 也很简单下面是一个最小示例# 文件路径benchmark_vllm.py from vllm import LLM, SamplingParams llm LLM(modelQwen/Qwen2.5-1.5B-Instruct) prompt 请用中文写一段关于人工智能发展的介绍大约300字左右。 outputs llm.generate([prompt], SamplingParams(max_tokens256, temperature0)) for output in outputs: generated output.outputs[0].text # 这里的 token 数可以通过 output.outputs[0].token_ids 获取 token_count len(output.outputs[0].token_ids) print(f生成 token 数: {token_count})vLLM 还提供了性能测试脚本在安装 vLLM 后可以执行python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-1.5B-Instruct \ --port 8000然后使用压测工具发起请求观察 TPS 和延迟。这里的重点是vLLM 在服务化场景下的连续批处理可以明显提升吞吐你可以在不同并发数下观察总 TPS 的变化。5. 提升 TPS 的优化路径实测只是第一步。要让自己的服务跑得更快需要从多个层面做优化。这里我给出一个从“最容易着手”到“收益最高但复杂度也更高”的优化清单。5.1 从推理引擎入手如果你还在用 Transformers 直接对外提供推理服务建议优先切换到更高效的推理引擎比如 vLLM 或 TensorRT-LLM。vLLM 的优化核心包括 PagedAttention 和连续批处理。PagedAttention 把 KV Cache 划分成固定大小的块按需分配减少显存浪费连续批处理让 GPU 在等待单个请求时也能处理其他请求。很多场景下同样的 GPU换成 vLLM 之后吞吐可以提升数倍。切换时需要注意模型格式。vLLM 支持 Hugging Face 格式模型可以直接加载目录TensorRT-LLM 则需要先编译模型构建 engine部署流程更重但性能上限更高。5.2 启用量化如果显存不宽裕量化是提升速度的另一个有效手段。常见的量化工具包括 bitsandbytes、AutoGPTQ、llama.cpp 的 GGUF 量化。在 Transformers 中可以快速加载量化模型from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Qwen/Qwen2.5-1.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, trust_remote_codeTrue, load_in_4bitTrue, torch_dtypetorch.float16, device_mapauto, )上面的示例使用了 4-bit 量化。量化后模型权重变小显存占用降低访存压力也降低decode 阶段的速度通常会提升。不过你需要用真实业务数据验证生成质量不能盲目追求低比特。5.3 调整推理参数max_new_tokens的设置要符合业务需求。如果业务场景是生成简短回复没必要设置成 4096否则用户等待时间被拉长。解码策略尽可能使用贪心或采样避免 beam search。如果你需要从多个候选结果中选择最佳答案建议使用一次采样多次请求再在后端做结果排序这样比 beam search 在推理阶段更容易控制资源。如果模型支持use_cacheFalse时不使用缓存那么强烈建议保持use_cacheTrue。关闭 KV Cache 会导致每一步重新计算之前所有 token 的注意力速度会慢很多。5.4 优化输入长度输入 token 过长会显著拖慢 prefill并且占用大量显存。在业务层可以做 prompt 压缩去除不必要的系统提示词冗余。对历史对话做摘要而不是把完整聊天记录全部传给模型。对超长文档做切片或检索只把相关片段传给模型。对“理解长文档”类任务可以考虑使用支持长上下文的模型但这不一定能让 TPS 变高——长上下文模型在长序列计算上通常更优但参数量往往也更大。5.5 服务架构层面把模型部署为服务后TPS 的另一个瓶颈可能是单请求的处理流程。如果每个请求都走完整链路包括鉴权、数据库读取、历史记录存储、模型生成、后处理、结果回写那么模型生成时间只是总延迟的一部分。压测时需要关注并发请求下 GPU 的利用率是否接近饱和。是否存在锁竞争或串行 IO。是否因为网络传输或者序列化格式导致 CPU 成为瓶颈。连续批处理框架通常已经处理了调度问题但服务端的业务代码仍然需要留意。6. 常见问题与排查思路在推理测速和部署中下面几类问题经常出现问题现象常见原因解决思路TPS 结果波动大没有预热或者显存频率不稳定增加预热多次测量取平均值GPU 显存不足模型太大或 batch 太大降低量化位数、减小 batch、缩短输入长度输出很快但首字很慢prefill 耗时过高检查输入长度减少 prompt tokens 数量并发升高后 TPS 不升反降显存不足导致 swapping 或排队查看显存占用降低并发或升级硬件CPU 跑大模型速度极慢权重访存成为瓶颈换 GPU 或使用 llama.cpp 的 CPU 优化版本使用 HT 仍很慢.generate()中use_cacheFalse将use_cache设为 True6.1 为什么换了更高档显卡TPS 提升不明显这种情况可能出现在目标模型参数量较小、计算时间占比不高时。模型很小时每次生成 token 的计算量不大瓶颈可能转移到了 Python 调度开销、tokenizer、数据搬运或框架本身的 Python 层。解决办法是使用更高性能的推理引擎或者把模型编译成优化格式比如直接使用 TensorRT-LLM、或者使用 vLLM 的在线批处理模式减少 Python 调用开销。6.2 为什么输入长度变长后 TPS 明显下降这是 prefill 和 KV Cache 访存的共同作用。输入变长prefill 阶段需要处理更多 tokendecode 阶段每一步的注意力计算需要读取更大的 KV Cache。两种作用叠加导致 TPS 下降。如果业务无法避免长输入可以尝试对 KV Cache 使用分页或量化缓存方案vLLM 的 PagedAttention 就是典型方案。也可以考虑把长文档切分后检索只保留关键片段。6.3 为什么在不同工具中测得的 TPS 差异很大三个可能原因统计口径不同、硬件算力和显存带宽不同、框架优化程度不同。建议先确认工具的输出是只统计 decode 阶段还是包含 prefill。然后确认是否使用了相同模型、相同输入、相同量化格式。最后再对比框架层面的差异。6.4 为什么 2,158 tokens per second 难以复现很少有人能完整复现排行榜上的极端数字因为排行榜可能使用了多项优化叠加包括 INT4 量化、连续批处理、多请求并发、短输入、静态优化、专用硬件等。对我们日常工程来说不必追求一定达到某个数字。更重要是建立自己的测试集记录模型、输入长度、GPU、引擎、量化方法、TPS 和 TTFT形成一份可对比的报告。后续调优时通过这套测试集判断改动是否有效。6.5 测速脚本中得到的结果和线上服务相差很大本地测速脚本一般只测量模型推理耗时而线上服务还包括 tokenizer、网络层、认证、限流、日志等环节。建议在线上压测使用真实请求体查看整体延迟分布不要只看模型内部 TPS。7. 工程实践中的建议与注意事项7.1 建立自己的基准测试集不要只用几条短 prompt 就得出结论。建议准备一份包含不同长度、不同领域、不同复杂度的测试集例如短问答20 tokens 以内中等指令100 到 300 tokens长文档理解2000 tokens 以上代码生成包含缩进和注释每个类别测出 TPS、TTFT、TPOT记录模型版本和推理参数。这样后续换模型、换框架、调参数都能有据可依。7.2 量化前必须做质量评测量化会带来速度提升但可能改变模型输出。上线前建议准备 100 到 200 条业务样例把量化前后的输出做对比检查是否有明显的逻辑错误、格式错乱、敏感内容遗漏。如果业务对输出质量要求很高可以优先尝试 INT8 或 FP8而不是直接降到 4-bit。7.3 监控与告警生产环境中只关注 TPS 远远不够。需要同时监控 GPU 利用率、显存使用量、请求排队长度、TTFT 分位数和端到端延迟。建议设置告警规则例如TTFT 超过 3 秒或请求排队长度超过阈值时触发报警。这样可以及时发现流量突增或模型退化。7.4 权限与安全边界在部署推理服务时注意以下安全事项对外暴露的 API 必须做身份认证和限流防止被恶意刷请求。模型生成的输出不要直接写入数据库或执行系统命令必须经过过滤和校验。如果服务支持用户上传文件需要限制文件类型和大小避免触发超大输入导致显存耗尽。涉及生产环境的变更先在测试环境验证保留回滚方案。这些内容看起来和 TPS 关系不大但在真实项目中它们决定了推理服务能否稳定运行。7.5 硬件选型建议如果你正在做硬件选型不要只看单卡 TPS。要结合业务的并发量、平均输入长度、模型参数量和预算综合判断。低并发、交互式场景单卡推理重点看 TTFT 和单请求 TPS。高并发、批处理场景重点看吞吐量、显存容量和连续批处理支持。训练和部署混合场景需要额外考虑显存分配和任务调度。建议先使用自己的模型和测试集在候选硬件上做 POC拿到真实数据后再决定采购方案。8. 下一步学习路线回到开头的新闻Celeris-1 的 2,158 tokens per second 是当前速度竞争中的一个参考值但比这个数字更重要的是它所代表的优化方向更高效的推理引擎、更合理的量化策略、更强的并发调度能力和更科学的速度测量方法。如果你沿着这个方向继续学习我建议按下面顺序推进熟悉 tokens per second 的计算逻辑和统计口径能解释 TTFT、TPOT、吞吐量之间的关系。手写一份测速脚本在自己的机器上跑通记录基线数据。把 Transformers 推理切换成 vLLM 或同类引擎对比基线数据的变化。对模型做 INT8 或 INT4 量化再次对比速度和生成质量。研究连续批处理和 PagedAttention 的调度细节理解高并发下的行为。搭建一个简单的推理服务加入鉴权、限流、监控和压测形成一套完整的部署方案。当你走完这条路线再看排行榜上的数字时你会更清楚它为什么能跑那么快也更能判断自己是否能复现——这才是技术文章最想帮你建立的判断力和工程能力。希望这篇文章能成为你优化推理性能的一个起点。 大模型推理速度指标TPS全解析：从测量原理到优化实践
Celeris-1 最近在 AI 推理速度排行榜中冒了出来以 2,158 tokens per second 的成绩冲到前列。这个数字对普通用户来说可能只是一个漂亮的指标但对于做模型部署、服务性能调优、做 AI 工程落地的人来说它背后涉及的知识量其实很大tokens per second 到底代表什么影响这个指标的因素有哪些我们手里的模型能不能也优化到这个数量级本文就以这个新闻为切入点把推理速度指标、测量方式、优化手段和常见坑点梳理一遍。如果你是刚刚接触大模型开发还没有弄清楚“token”和“TPS”的概念不用着急我会从最基础的概念讲起。如果你已经在做推理服务优化可以直接跳到后面的实测脚本和优化清单里面有些命令和代码可以直接复制到项目里使用。1. 背景AI 速度排行里的“新面孔” Celeris-11.1 排行榜的意义在哪里AI 领域现在有很多排行榜有的比模型效果比如问答准确率、代码生成通过率、多模态理解能力有的比推理速度这类排行榜通常会把同一个模型跑在不同硬件、不同推理引擎上再统计每秒能生成的 token 数量。Celeris-1 的 2,158 tokens per second 之所以被关注并不仅仅是因为数字本身大而是因为推理速度直接关系到产品体验。你在网页端使用 AI 对话时从点击发送到看到第一个字再到内容逐渐输出每个环节都和时间有关。如果模型生成速度慢用户就会觉得“卡”如果速度快到一定程度人眼几乎感知不到逐字输出的延迟交互体验就会非常接近真人对话。对一个服务于真实业务的技术团队来说推理速度还关系到成本。同样一台 GPU每小时能处理的请求越多单次推理的成本就越低。速度排行榜实际上反映的是“在相同硬件和模型条件下通过优化能达到什么程度”。这也是为什么很多团队会把 tokens per second 当成核心观测指标。1.2 2,158 tokens per second 意味着什么我们可以先把 2,158 这个数字放到实际场景里感受一下。中文大约平均一个字对应 1 到 1.5 个 token英文单词和 token 的对应关系比较复杂但可以粗略认为 1 个单词约等于 1.3 到 1.5 个 token。假设按照 1 token 约等于 0.75 个汉字来估算每秒生成 2,158 个 tokens相当于一秒钟可以生成约 1600 个汉字左右每分钟接近 100000 个汉字。一般的阅读速度是每分钟几百字也就是说它的生成速度已经远远超过人的阅读速度。这个速度带来的典型变化是流式输出不再是一段一段地“挤”出来而是几乎瞬间填满对话内容。对用户体验而言大段代码、长篇文章、批量数据处理任务的等待感会被明显削弱。不过需要提醒的是排行榜上的数字通常是在特定测试条件下得到的比如使用特定的 batch 大小、输入序列长度、量化精度、显存、显卡型号以及推理框架。不同条件下测得的 tokens per second 差异可能很大甚至相差数倍。所以关键不是记住某个排行榜数字而是理解这个数字是怎么测出来的以及它能不能复现到自己的项目环境里。1.3 本文面向的读者本文主要面向以下三类读者第一类是正在做大模型部署和推理优化的开发者你可能已经能把模型跑起来但发现输出速度不理想想弄清楚瓶颈在哪里。第二类是刚接触大模型工程、对 tokens per second 这类指标有概念但不够系统的学习者你希望通过一篇文章把测速、优化、排错的流程串起来。第三类是准备做技术选型的工程师你需要比较不同推理框架、不同硬件组合的性能差异那么理解 TPS 的测量方法和影响因素就非常重要。文中涉及的概念不会太深但也不会只停留在“什么是 token”这种层级。我会给出可运行的测速脚本、不同推理引擎的对比思路、参数优化建议以及常见报错排查方法。2. 认识 tokens per second 指标2.1 什么是 token在大模型领域token 是模型处理文本时的最小单位。模型并不是像人一样一个字一个字地阅读而是把输入文本切分成若干 token再通过神经网络计算这些 token 之间的关联。不同分词器对 token 的切分方式不同。比如 OpenAI 的 cl100k_base 分词器会把常见英文单词直接切成一个 token把罕见单词切成多个子词中文字符通常 1 个 token 对应 1 到 2 个汉字。模型每次生成一个 token然后把这个 token 拼接到输入序列末尾再继续预测下一个 token直到生成结束标记或达到最大长度。理解这一点的意义在于tokens per second 测量的是“大模型生成文本的速度”而不是字符速度。同一句中文在不同分词器下 token 数量可能不一致所以不同模型之间的 TPS 不能简单看数字还要看分词策略。2.2 tokens per second 的统计口径tokens per second简称 TPS指模型每秒生成的 token 数量。统计公式很简单TPS 生成总 token 数 / 生成耗时秒但在实际操作中我们需要区分两个时间段第一个是 prefill 阶段也就是处理输入提示词的过程。模型要把用户输入的上下文完整计算一遍生成 KV Cache为后续解码做准备。这个阶段通常计算量大、耗时长但它不产生可见的文本输出。第二个是 decode 阶段也就是逐 token 生成回复的阶段。从用户界面上看到的“打字机”效果主要发生在这个阶段。很多测速工具报告的 TPS 只统计 decode 阶段也就是从第一个 token 生成到最后一个 token 生成的平均速度。这样做的原因是 prefill 阶段耗时与输入长度强相关如果把它计入整体时间会稀释模型“生成”本身的速度。但也有工具会把完整请求时间纳入计算。这就是为什么同一模型在不同测试文章中 TPS 数字不一致不是模型变了而是统计口径变了。2.3 还需要关注哪些配套指标只看 TPS 是不完整的。一个高 TPS 模型如果首字延迟很长用户在页面上还是会感觉“半天不出结果”。因此工程上通常把以下三个指标放在一起看第一个是 TTFTTime to First Token指从发起请求到生成第一个 token 的时间。这个时间主要受 prefill 阶段影响输入越长TTFT 越长。第二个是 TPOTTime Per Output Token指生成每一个输出 token 的平均耗时。TPOT 的倒数乘 1000 就是单流场景下的 TPS。比如 TPOT 为 20 毫秒时单请求 TPS 约为 50。第三个是端到端延迟End-to-End Latency指整个请求从发起到完成的总耗时等于 TTFT 加上所有后续 token 的生成时间。在实际服务中系统可能同时处理多个请求所以还需要关注吞吐量throughput单位是“每秒处理的请求数”或“每秒钟所有请求生成的 token 总数”。吞吐量高并不一定意味着单个请求速度快因为系统可能把同一批请求合并处理牺牲单请求延迟来换取整体吞吐。2.4 为什么 2,158 这个数字值得关注当看到“2,158 tokens per second”时我们会自然地想到两个问题它是在什么硬件上达到的它用了什么推理优化如果这个成绩是在高性能服务器上配合专用加速器和静态批处理得到的那么数字主要代表“优化后的系统峰值能力”如果它是单路请求在通用消费级显卡上跑出来的那意味着相关技术可以在普通开发者的设备上复现。文章标题虽然没有给出完整测试环境但它至少在传递一个信号通过合理的批处理、量化、缓存和推理框架优化模型推理速度可以达到远超人眼感知范围的水平。这让我们后续优化自己的服务时有了更明确的方向。3. 影响 TPS 的核心因素TPS 不是模型一个因素决定的它是“模型 硬件 推理框架 推理参数 服务架构”共同作用的结果。下面拆开来看每个环节的影响。3.1 模型参数规模与量化方式模型参数量越大推理时需要的计算量越大生成速度通常越慢。7B 模型和 70B 模型在相同硬件上TPS 可能相差接近一个数量级。为了让大模型跑得更快量化是常用手段。所谓量化就是把模型权重从 FP16 或 FP32 精度转换成 INT8、INT4 等低精度格式。低精度带来的好处有两点一是模型权重占用的显存变小可以容纳更大的模型或更大的 batch二是部分硬件对低精度矩阵计算有专门加速单元计算速度更快。不过量化不是完全没有损失。虽然主流量化方案通常能保持较好的生成质量但在极端低比特、敏感任务上仍可能出现生成质量下降。选择 INT8、INT4 还是 FP8需要做评测。3.2 硬件与推理引擎GPU 的显存带宽是影响 decode 阶段速度的一个核心因素。解码过程每次生成一个 token都需要把模型权重从显存中读取一遍。权重读取速度越快单个 token 产生得就越快。这也是为什么有些模型的参数量明明很大但在高端显卡上依然能保持不错的速度高端显卡显存带宽更高。反过来如果显存带宽不够即使 GPU 算力很强decode 速度也会被“搬运权重”这个环节卡住。推理引擎同样重要。同一份模型权重在不同推理框架中经过的算子融合、优化调度水平不同最终速度差异很明显。常见选择有 Hugging Face Transformers、vLLM、TensorRT-LLM、ONNX Runtime、llama.cpp 等。它们各有适用的部署场景Transformers 适合研究和快速验证vLLM 在服务化场景下支持连续批处理TensorRT-LLM 适合追求极致性能llama.cpp 对 CPU 和苹果芯片支持较好。3.3 输入序列长度与 KV Cache模型生成过程中需要不断读取之前所有 token 的注意力计算结果这些缓存叫做 KV Cache。输入序列越长KV Cache 越大每一步计算时的访存量也越大速度就越慢。这也是为什么测速时通常要限定输入长度。例如“TLD;DR”数据集测速可能只需要几十个 token 的输入而代码任务可能需要输入 2000 甚至更多 token。输入短生成的 TPS 就会好看很多。KV Cache 显存占用还和并发量相关。如果 8 个请求同时进行每个请求的 KV Cache 都会占用显存显存不足时就会被迫降低并发影响整体吞吐。3.4 推理参数的影响decode 阶段的生成策略对 TPS 也有明显影响。贪心解码greedy decoding和温度采样temperature sampling在计算方式上略有不同但额外开销通常不大。真正影响速度的是 beam search。beam search 在每一轮同时保留多个候选序列内部会维护多个 KV Cache计算量成倍增加。相比之下greedy 和 sample 的 TPS 会高很多。max_new_tokens 也会影响体验。如果设置过短模型在输出过程中频繁被截断看起来好像生成很快但结果不完整。如果设置过长模型可能在结束标记已经出现后仍继续占着资源但这种情况通常会被设计为提前终止不一定显著影响 TPS。3.5 并发与批处理从单用户角度来看TPS 只反映单个请求的生成速度。但从服务端角度看同一时刻可能有多个请求服务端可以把请求合并到一个 batch 中统一进行矩阵计算从而提升 GPU 利用率。传统静态批处理需要等 batch 填满才开始推理会增加延迟。vLLM 等框架引入连续批处理请求完成一个就插一个新请求不需要一直等这样可以在不显著增加单请求延迟的情况下提升整体吞吐。如果你在自己的服务中做压测可能会发现一个规律并发从 1 增加到 8 时单请求 TPS 略有下降但系统总吞吐明显上升并发继续增加显存可能不够用速度反而下降。这就是一个典型的权衡过程。4. 如何实测 TPS一份可以直接运行的脚本了解影响因素之后最好亲自动手测一下。下面我给出一个测速脚本的思路。这个脚本基于 Hugging Face Transformers逻辑清晰、适合对照学习如果你希望在生产环境用更高性能框架可以替换成 vLLM、TensorRT-LLM 或 llama.cpp 对应的测速方式。4.1 准备测试环境建议准备一台配置了 GPU 的服务器显存至少 8GB。如果没有 GPU也可以使用 CPU 测试但速度会慢很多主要用来验证脚本流程。Python 环境建议使用 3.10 及以上版本。安装依赖pip install torch transformers accelerate注意torch 的版本需要和你的 CUDA 环境匹配。安装时可以直接使用 PyTorch 官网给出的命令例如pip install torch --index-url https://download.pytorch.org/whl/cu124如果你只需要在 CPU 上测试可以安装 CPU 版pip install torch --index-url https://download.pytorch.org/whl/cpu4.2 编写测速脚本下面是一个完整的 Python 脚本它完成以下工作加载一个生成式语言模型。构造固定输入文本。执行预热生成避免首次加载和 CUDA 初始化的干扰。正式计时统计生成 token 数。计算并打印 TPS、TTFT 和 TPOT。# 文件路径benchmark_tps.py import time import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-1.5B-Instruct device cuda if torch.cuda.is_available() else cpu print(f加载模型: {model_name}, 设备: {device}) tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, trust_remote_codeTrue, torch_dtypetorch.float16 if device cuda else torch.float32, ).to(device) model.eval() prompt 请用中文写一段关于人工智能发展的介绍大约300字左右。 inputs tokenizer(prompt, return_tensorspt).to(device) # 预热避免首次调用时 CUDA 初始化影响速度 with torch.no_grad(): _ model.generate( **inputs, max_new_tokens32, do_sampleFalse, use_cacheTrue, ) # 正式测量 torch.cuda.synchronize() if device cuda else None start time.time() with torch.no_grad(): output model.generate( **inputs, max_new_tokens256, do_sampleFalse, use_cacheTrue, ) torch.cuda.synchronize() if device cuda else None end time.time() input_len inputs[input_ids].shape[1] output_len output.shape[1] new_tokens output_len - input_len elapsed end - start tps new_tokens / elapsed ttp elapsed / new_tokens # 平均每个 token 耗时单位秒 print(f输入 tokens: {input_len}) print(f输出 tokens: {new_tokens}) print(f总耗时: {elapsed:.4f} 秒) print(f平均 TPS: {tps:.2f} tokens/s) print(f平均每个 token 耗时: {ttp * 1000:.2f} ms/token)4.3 运行与结果解读在命令行中执行python benchmark_tps.py如果一切正常会输出类似下面的信息加载模型: Qwen/Qwen2.5-1.5B-Instruct, 设备: cuda 输入 tokens: 22 输出 tokens: 256 总耗时: 3.2145 秒 平均 TPS: 79.64 tokens/s 平均每个 token 耗时: 12.56 ms/token注意这只是示例输出实际数字取决于你的显卡、模型和输入长度。如果你在性能更强的显卡上运行更小的模型TPS 可以达到几百甚至上千如果使用 CPU 运行较大的模型TPS 可能只有个位数。但这并不代表模型“不行”而是硬件限制。4.4 测速时容易出现的三个错误第一个错误是不预热。CUDA 在第一次推理时会有初始化开销如果不预热直接计时TPS 会偏低而且每次运行结果波动很大。第二个错误是不做 CUDA 同步。在 GPU 上PyTorch 的部分操作是异步的time.time()可能先于 GPU 实际计算完成执行导致统计时间偏短。正确的做法是在计时结束后调用torch.cuda.synchronize()。第三个错误是输入太短。如果 prompt 只有几个字符prefill 阶段耗时几乎可以忽略测出的 TPS 主要反映 decode 速度如果你的实际业务输入是长文本就应该用接近真实场景的长度测试。4.5 用 vLLM 做更贴近生产的测速Transformers 的generate方便但不够高效。如果你已经在做服务化部署更推荐使用 vLLM 做测速。它的 API 也很简单下面是一个最小示例# 文件路径benchmark_vllm.py from vllm import LLM, SamplingParams llm LLM(modelQwen/Qwen2.5-1.5B-Instruct) prompt 请用中文写一段关于人工智能发展的介绍大约300字左右。 outputs llm.generate([prompt], SamplingParams(max_tokens256, temperature0)) for output in outputs: generated output.outputs[0].text # 这里的 token 数可以通过 output.outputs[0].token_ids 获取 token_count len(output.outputs[0].token_ids) print(f生成 token 数: {token_count})vLLM 还提供了性能测试脚本在安装 vLLM 后可以执行python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-1.5B-Instruct \ --port 8000然后使用压测工具发起请求观察 TPS 和延迟。这里的重点是vLLM 在服务化场景下的连续批处理可以明显提升吞吐你可以在不同并发数下观察总 TPS 的变化。5. 提升 TPS 的优化路径实测只是第一步。要让自己的服务跑得更快需要从多个层面做优化。这里我给出一个从“最容易着手”到“收益最高但复杂度也更高”的优化清单。5.1 从推理引擎入手如果你还在用 Transformers 直接对外提供推理服务建议优先切换到更高效的推理引擎比如 vLLM 或 TensorRT-LLM。vLLM 的优化核心包括 PagedAttention 和连续批处理。PagedAttention 把 KV Cache 划分成固定大小的块按需分配减少显存浪费连续批处理让 GPU 在等待单个请求时也能处理其他请求。很多场景下同样的 GPU换成 vLLM 之后吞吐可以提升数倍。切换时需要注意模型格式。vLLM 支持 Hugging Face 格式模型可以直接加载目录TensorRT-LLM 则需要先编译模型构建 engine部署流程更重但性能上限更高。5.2 启用量化如果显存不宽裕量化是提升速度的另一个有效手段。常见的量化工具包括 bitsandbytes、AutoGPTQ、llama.cpp 的 GGUF 量化。在 Transformers 中可以快速加载量化模型from transformers import AutoModelForCausalLM, AutoTokenizer import torch model_name Qwen/Qwen2.5-1.5B-Instruct tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained( model_name, trust_remote_codeTrue, load_in_4bitTrue, torch_dtypetorch.float16, device_mapauto, )上面的示例使用了 4-bit 量化。量化后模型权重变小显存占用降低访存压力也降低decode 阶段的速度通常会提升。不过你需要用真实业务数据验证生成质量不能盲目追求低比特。5.3 调整推理参数max_new_tokens的设置要符合业务需求。如果业务场景是生成简短回复没必要设置成 4096否则用户等待时间被拉长。解码策略尽可能使用贪心或采样避免 beam search。如果你需要从多个候选结果中选择最佳答案建议使用一次采样多次请求再在后端做结果排序这样比 beam search 在推理阶段更容易控制资源。如果模型支持use_cacheFalse时不使用缓存那么强烈建议保持use_cacheTrue。关闭 KV Cache 会导致每一步重新计算之前所有 token 的注意力速度会慢很多。5.4 优化输入长度输入 token 过长会显著拖慢 prefill并且占用大量显存。在业务层可以做 prompt 压缩去除不必要的系统提示词冗余。对历史对话做摘要而不是把完整聊天记录全部传给模型。对超长文档做切片或检索只把相关片段传给模型。对“理解长文档”类任务可以考虑使用支持长上下文的模型但这不一定能让 TPS 变高——长上下文模型在长序列计算上通常更优但参数量往往也更大。5.5 服务架构层面把模型部署为服务后TPS 的另一个瓶颈可能是单请求的处理流程。如果每个请求都走完整链路包括鉴权、数据库读取、历史记录存储、模型生成、后处理、结果回写那么模型生成时间只是总延迟的一部分。压测时需要关注并发请求下 GPU 的利用率是否接近饱和。是否存在锁竞争或串行 IO。是否因为网络传输或者序列化格式导致 CPU 成为瓶颈。连续批处理框架通常已经处理了调度问题但服务端的业务代码仍然需要留意。6. 常见问题与排查思路在推理测速和部署中下面几类问题经常出现问题现象常见原因解决思路TPS 结果波动大没有预热或者显存频率不稳定增加预热多次测量取平均值GPU 显存不足模型太大或 batch 太大降低量化位数、减小 batch、缩短输入长度输出很快但首字很慢prefill 耗时过高检查输入长度减少 prompt tokens 数量并发升高后 TPS 不升反降显存不足导致 swapping 或排队查看显存占用降低并发或升级硬件CPU 跑大模型速度极慢权重访存成为瓶颈换 GPU 或使用 llama.cpp 的 CPU 优化版本使用 HT 仍很慢.generate()中use_cacheFalse将use_cache设为 True6.1 为什么换了更高档显卡TPS 提升不明显这种情况可能出现在目标模型参数量较小、计算时间占比不高时。模型很小时每次生成 token 的计算量不大瓶颈可能转移到了 Python 调度开销、tokenizer、数据搬运或框架本身的 Python 层。解决办法是使用更高性能的推理引擎或者把模型编译成优化格式比如直接使用 TensorRT-LLM、或者使用 vLLM 的在线批处理模式减少 Python 调用开销。6.2 为什么输入长度变长后 TPS 明显下降这是 prefill 和 KV Cache 访存的共同作用。输入变长prefill 阶段需要处理更多 tokendecode 阶段每一步的注意力计算需要读取更大的 KV Cache。两种作用叠加导致 TPS 下降。如果业务无法避免长输入可以尝试对 KV Cache 使用分页或量化缓存方案vLLM 的 PagedAttention 就是典型方案。也可以考虑把长文档切分后检索只保留关键片段。6.3 为什么在不同工具中测得的 TPS 差异很大三个可能原因统计口径不同、硬件算力和显存带宽不同、框架优化程度不同。建议先确认工具的输出是只统计 decode 阶段还是包含 prefill。然后确认是否使用了相同模型、相同输入、相同量化格式。最后再对比框架层面的差异。6.4 为什么 2,158 tokens per second 难以复现很少有人能完整复现排行榜上的极端数字因为排行榜可能使用了多项优化叠加包括 INT4 量化、连续批处理、多请求并发、短输入、静态优化、专用硬件等。对我们日常工程来说不必追求一定达到某个数字。更重要是建立自己的测试集记录模型、输入长度、GPU、引擎、量化方法、TPS 和 TTFT形成一份可对比的报告。后续调优时通过这套测试集判断改动是否有效。6.5 测速脚本中得到的结果和线上服务相差很大本地测速脚本一般只测量模型推理耗时而线上服务还包括 tokenizer、网络层、认证、限流、日志等环节。建议在线上压测使用真实请求体查看整体延迟分布不要只看模型内部 TPS。7. 工程实践中的建议与注意事项7.1 建立自己的基准测试集不要只用几条短 prompt 就得出结论。建议准备一份包含不同长度、不同领域、不同复杂度的测试集例如短问答20 tokens 以内中等指令100 到 300 tokens长文档理解2000 tokens 以上代码生成包含缩进和注释每个类别测出 TPS、TTFT、TPOT记录模型版本和推理参数。这样后续换模型、换框架、调参数都能有据可依。7.2 量化前必须做质量评测量化会带来速度提升但可能改变模型输出。上线前建议准备 100 到 200 条业务样例把量化前后的输出做对比检查是否有明显的逻辑错误、格式错乱、敏感内容遗漏。如果业务对输出质量要求很高可以优先尝试 INT8 或 FP8而不是直接降到 4-bit。7.3 监控与告警生产环境中只关注 TPS 远远不够。需要同时监控 GPU 利用率、显存使用量、请求排队长度、TTFT 分位数和端到端延迟。建议设置告警规则例如TTFT 超过 3 秒或请求排队长度超过阈值时触发报警。这样可以及时发现流量突增或模型退化。7.4 权限与安全边界在部署推理服务时注意以下安全事项对外暴露的 API 必须做身份认证和限流防止被恶意刷请求。模型生成的输出不要直接写入数据库或执行系统命令必须经过过滤和校验。如果服务支持用户上传文件需要限制文件类型和大小避免触发超大输入导致显存耗尽。涉及生产环境的变更先在测试环境验证保留回滚方案。这些内容看起来和 TPS 关系不大但在真实项目中它们决定了推理服务能否稳定运行。7.5 硬件选型建议如果你正在做硬件选型不要只看单卡 TPS。要结合业务的并发量、平均输入长度、模型参数量和预算综合判断。低并发、交互式场景单卡推理重点看 TTFT 和单请求 TPS。高并发、批处理场景重点看吞吐量、显存容量和连续批处理支持。训练和部署混合场景需要额外考虑显存分配和任务调度。建议先使用自己的模型和测试集在候选硬件上做 POC拿到真实数据后再决定采购方案。8. 下一步学习路线回到开头的新闻Celeris-1 的 2,158 tokens per second 是当前速度竞争中的一个参考值但比这个数字更重要的是它所代表的优化方向更高效的推理引擎、更合理的量化策略、更强的并发调度能力和更科学的速度测量方法。如果你沿着这个方向继续学习我建议按下面顺序推进熟悉 tokens per second 的计算逻辑和统计口径能解释 TTFT、TPOT、吞吐量之间的关系。手写一份测速脚本在自己的机器上跑通记录基线数据。把 Transformers 推理切换成 vLLM 或同类引擎对比基线数据的变化。对模型做 INT8 或 INT4 量化再次对比速度和生成质量。研究连续批处理和 PagedAttention 的调度细节理解高并发下的行为。搭建一个简单的推理服务加入鉴权、限流、监控和压测形成一套完整的部署方案。当你走完这条路线再看排行榜上的数字时你会更清楚它为什么能跑那么快也更能判断自己是否能复现——这才是技术文章最想帮你建立的判断力和工程能力。希望这篇文章能成为你优化推理性能的一个起点。