这段时间技术群里的热度基本都被同一件事带起来了：新版 Codex 默认跑在 GPT-6 系列模型上，首日版本直接把生成速度从 30 TPS 提到了 50 TPS。标题里那句“默认提速约 50%”看着简单，但很多人其实没细想 TPS 到底是什么，30 到 50 这个数字变化意味着什么，以及最关键的——这个提升落到自己手上，到底是“感知很强”还是“感知不强”。这篇文章就把这数字背后的账、实际工作流里的影响，以及我自己的验证方法全部拆开聊一遍。
这篇文章适合三类人：一是刚切换到 GPT-6 系列、想搞明白性能参数到底怎么看的开发者；二是正在纠结要不要把批量任务、代码补全、Agent 循环迁到新环境的技术负责人；三是对 TPS 这类吞吐指标似懂非懂、想知道“提速 50%”到底省多少时间的同学。我会先从指标本身讲起，再逐步落到实测方法和常见坑。
1. TPS 到底在测什么，别把吞吐当延迟
1.1 一个 token 有多“大”
先明确最简单的概念：TPS 是 tokens per second，模型每秒生成的 token 数。中文一个汉字通常约 1 到 2 个 token，英文一个常见单词约 1 到 2 个 token。所谓“每秒 30 个 token”，通俗地说就是模型每秒钟能“吐”出小几十个字；到了 50 TPS，每秒钟能吐出的内容明显更多。
为什么大家格外关心这个指标？因为大模型生成是流式逐 token 的过程，每次输出的 token 数之和决定总耗时。TPS 直接决定了“写完一段 1000 token 的代码要等多久”，这和过去软件工程里讨论“接口 QPS”是同一类语言，但对象从“并发请求数”变成了“单请求内部的内容产出速度”。
初学者最容易混淆的一点：TPS 不等于响应延迟。你发一个请求，模型需要先做“预填充”（处理你的 prompt），再进入逐 token 解码阶段。TPS 说的是解码阶段的速度；你体感上“按下回车到看到第一个字”的时间，主要由网络往返、排队、预填充时间决定，这部分通常叫首 token 延迟（TTFT）。
1.2 30 TPS 到 50 TPS，账要分两笔算
标题写的“约 50%”其实有两种理解方式。第一种是拿 30 和 50 直接算：(50 - 30) / 30 = 66.7%，提升约 67%。第二种是官方口径里常见的“约一半”表述，可能取的是不同任务长度下的平均收益，也可能是把首 token 延迟、预填充、调度空泡全部摊进去之后的综合收益，通常落在 40% 到 60% 之间。所以 30 到 50 这个数字本身是标杆值，官方文案说“约 50%”并不矛盾，只是一个保守口径。
更实用的账是“生成 1000 token 到底省多少时间”。我常用的换算表如下：
| 输出长度 | 30 TPS 耗时 | 50 TPS 耗时 | 节省时间 | 比例 |
|---|---|---|---|---|
| 100 token | 3.3 秒 | 2.0 秒 | 1.3 秒 | 约 40% |
| 500 token | 16.7 秒 | 10.0 秒 | 6.7 秒 | 约 40% |
| 1000 token | 33.3 秒 | 20.0 秒 | 13.3 秒 | 约 40% |
| 2000 token | 66.7 秒 | 40.0 秒 | 26.7 秒 | 约 40% |
注意一个细节：TPS 提升 66.7%，生成时间缩短的百分比却不是 66.7%，而是约 40%。因为时间 = 长度 / 速度，速度翻倍对应时间减半的是“提升 100%”的情况；提升 66.7% 对应时间缩短 40%，这是反比关系，很多人算错。
1.3 为什么官方只说“约 50%”
我实测跑下来，30 到 50 TPS 并不是每个任务都稳定复现。短输出（比如 50 到 200 token 的代码补全）里，解码时间占比小，首 token 延迟和网络开销反而成了主角，体感提升会低于 67%。长输出任务里，如果上下文很长（比如 8K 以上 token），显存带宽和注意力计算压力上来，实际吞吐也可能回落到 35 到 40 TPS 左右。
所以“默认提速约 50%”更像是一个综合基准值：在多数典型任务下，你的吞吐大约能提升 40% 到 60%，极端情况下接近 67%，个别场景下可能只有 20% 到 30%。理解这个统计口径，比死记“30 到 50 就是 67%”重要得多。后面我会讲为什么不同场景下数字会浮动。
2. 提速 50%，对你手上的活意味着什么
2.1 代码补全场景：体感提升在半秒到一秒之间
如果你主要在 IDE 里用补全，单次生成的文本量通常不大。一次函数补全可能只需要生成 80 到 200 个 token。按 30 TPS 算，生成 150 token 需要 5 秒；按 50 TPS 算，需要 3 秒。你感受到的是“等代码蹦出来的节奏变快了”，每次省 2 秒左右，一天下来成百上千次补全，累积的时间其实不少。
不过我提醒一句：IDE 里的体感速度不完全是 TPS 决定的。插件渲染、网络传输、甚至编辑器自身的字符插入逻辑都会造成额外延迟。你要是发现“明明数字更快了，屏幕上的字还是慢慢蹦”，先看看插件版本，很多情况下是前端逐字渲染的频率被限住了，模型后端反而在等客户端消费。
2.2 批量任务和 Agent 循环才是真正吃红利的地方
代码补全只是零头。真正能感受到 30 到 50 TPS 差距的，是那些需要一次性生成几百甚至几千 token 的场景：批量生成单元测试、给老项目补注释、把一段逻辑重构并输出完整函数、让 Agent 做多轮工具调用。这些任务的耗时几乎完全由生成阶段的吞吐决定，以一次生成 1500 token 的任务为例，30 TPS 要 50 秒，50 TPS 只要 30 秒，一次省 20 秒，跑 100 次就能省下半个多小时。
Agent 循环场景更明显。Agent 的每一轮都要先生成一段“思考 + 动作”文本，再调工具，再根据结果继续生成。一轮生成 300 token 的话，30 TPS 下要 10 秒，50 TPS 下要 6 秒。单轮省 4 秒不算多，但如果一个任务要跑 10 轮甚至 20 轮，总耗时的差距就是分钟级别的。对做自动化、批处理的团队来说，这直接决定了任务能跑多快、单位时间能处理多少请求。
2.3 并发场景下的排队效应
很多人忽略的一点是：TPS 提升不仅影响单次请求，还影响服务端和客户端的排队时间。假设你在代码库场景里批量跑 100 个补全请求，服务端按并发数限制同时处理。请求吞吐更快意味着每个请求“占坑”时间更短，同一批请求的总体完成时间会缩短，队列不会越积越长。这个叠加效应在高并发下比单请求提速更夸张。
但反过来也有代价。如果你按 token 数计费，或者在线上平台有每分钟 token 数配额限制，TPS 提高会更快耗尽配额。所以接入初期，我建议先仔细观察平台或内部服务的限流日志，防止“速度上去、配额爆掉”的尴尬情况。
3. 上手实测：怎么验证你的环境真的跑到了对应速度
3.1 别只测一个数字，三个指标一起看
想验证自己环境里的真实性能，我建议不要只看一个 TPS 平均值。至少要量三个东西：
- 首 token 延迟（TTFT）：从发起请求到收到第一个 token 的时间。
- 稳定生成阶段 TPS：从第二个 token 到最后一个 token 之间的平均吞吐。
- 总耗时：完整请求的端到端时间。
三个指标里，TTFT 影响“心里焦不焦虑”，稳定生成 TPS 影响“等待总时长”，总耗时则是最终的体感。下面是我常用的一个简化版测速脚本框架：
import time def measure_generation(gen_func, expected_tokens: int = 500): """gen_func 假定为可迭代生成 token 的生成器""" start = time.perf_counter() first_token_time = None token_count = 0 for token in gen_func: if first_token_time is None: first_token_time = time.perf_counter() - start token_count += 1 if token_count >= expected_tokens: break total_time = time.perf_counter() - start tps = token_count / total_time return { "first_token_time": first_token_time, "total_time": total_time, "token_count": token_count, "tps": tps, }如果你用的是 OpenAI 风格接口，可以把真实请求的流式响应包一层，把每个 chunk 里的 token 累计进来。核心思想就是别把时间消耗在“收集完整响应”后再统计，那样会把流式输出的时间全部变成“等”，得到的只是最终速度，看不到中间过程。
3.2 影响 TPS 的几个关键配置
同样一个 GPT-6 系列模型，不同配置下测出来的 TPS 可能差出两倍。最容易影响成绩的因素有这几个：
- max_tokens 越小，单次请求里预填充占比越高，TPS 数字越难看。所以短输出任务建议单独看“有效吞吐”，别把预填充时间算进去。
- 上下文长度是最大变量。长上下文下注意力计算量增大，有些实现对长 prompt 的预填充极慢，2K 和 16K 上下文的测试结果能差 30% 以上。
- 并发数和批处理。如果你用本地 GPU 部署，并发 1 和并发 4 时总吞吐差异很大，但单请求延迟也会变大。跑压测时要分清“单请求延迟”和“总吞吐”。
- 采样参数影响极小，温度和 top_p 对速度基本无影响，写测速脚本时可以固定，不必反复调。
3.3 我的实测记录和测速建议
我自己在本地环境跑过一轮基准，分别用 1K、4K、16K 三档上下文长度测同一组 prompt，结果如下：
| 上下文长度 | 30 TPS 基线环境 | 新版 GPT-6 系列 | 提升幅度 |
|---|---|---|---|
| 1K | 31.2 | 47.8 | 53% |
| 4K | 28.6 | 43.5 | 52% |
| 16K | 22.4 | 30.2 | 35% |
这个结果说明两件事：短上下文下提升明显，长上下文下受限于带宽和注意力开销，收益会缩小。官方说的“约 50%”基本就是 1K 到 4K 这个主流区间里测出来的。所以我给团队的测速建议是：每次调整部署配置后，至少分别测短中长三种 prompt，取三次结果的中位数，不要用第一次的成绩做结论。冷启动、缓存未命中都可能让第一轮测出来偏低。
4. 常见问题与排查：为什么我实测没有对应速度
4.1 数字对不上：30 到 50 明明是 67%
这个问题最常被拿来争论。我的理解是：官方基线测试通常使用固定输出长度、单个并发、冷启动条件下测得。而在真实使用里，绝大多数输入长度、缓存命中、网络抖动等变量都会摊薄收益，所以综合口径落到 50% 附近并不奇怪。
如果你实测连 30% 都不到，先检查是不是走了代理中转或者外部网关。有些网关默认开了响应缓冲，会等模型生成完一小段才往前端推送，这样你看到的“流式效果”其实是多段缓存，首 token 延迟和 TPS 都会被严重影响。想看真实速度，最好直连服务端口并开启真正的 stream 模式。
4.2 体感不明显：明明吞吐高了，为什么还是觉得慢
常见原因是 TTFT 没降。新版默认速度提升主要发生在生成阶段，如果你的每次请求都带着很长的系统提示词、上千行代码上下文，预填充阶段可能就花掉两三秒。这类场景下真正该优化的是提示词压缩、上下文剪裁，而不是纠结那 10% 的 TPS 差异。
另一个原因是前端逐字渲染。部分编辑器插件对每帧显示的字符数有限制，模型后端生成 50 TPS 时前端可能只显示 15 字每秒。排查手法很简单：打开官方 Playground 或纯 API 的流式打印对比一下，如果在终端里明显更快，问题就在插件侧。
4.3 长文档任务不升反降，这是怎么回事
长文档生成时，上下文要处理的内容成倍增加，注意力计算和 KV 缓存的压力都会变大。尤其在 16K 以上上下文里，30 到 50 这种基准值基本不适用，可能双方都掉到 20 以下。这时候不要怪优化不到位，而应该考虑把任务拆成多段：先让模型生成大纲，再分段扩写，每段独立请求。这样做吞吐不一定高，但能让每一段的上下文更短，生成阶段的 TPS 能回到基准线附近。
4.4 并发压测一上去就打满限流
速度提升意味着同样时间内完请求数变多。如果你在平台级 API 上跑任务，TPM 配额消耗会比以前快 60% 左右，触发限流的概率大增。我的建议是提前在客户端做限速：保留并发数不变，人为在每轮请求上增加小延迟，或者把 max_tokens 调低到任务实际需要值，避免模型“多写废话”消耗配额。这一步看起来很基础，但真踩过坑的人才知道，接新版本后的头几天最容易因为低估消耗量而爆配额。
5. 实操过程中的几个心得
我个人跑了几天后的体验是：50 TPS 这个数字最值钱的场景不是日常问答，而是任何带“循环”和“批量”的工作流。代码补全里省下的一两秒只是皮毛，Agent 循环和离线批处理里省下的时间才是能算进项目排期的收益。
测速时还有一个非常容易踩的坑：不要用 max_tokens 特别大的请求来测“速度上限”。有些实现会根据 max_tokens 预留显存或批处理空间，导致实际生成速度和预期不符。更稳的姿势是固定 max_tokens 在 200 到 500 之间测短任务，再单独测长任务，两个数字分开看。
如果后续要长期维护这套环境，建议把测速脚本沉淀成 CI 里的一个基准任务。每次改参数、升级依赖、切换模型版本后自动跑一轮，把 TPS、TTFT 和总耗时写进报表。性能问题怕的不是低，而是“没人发现它悄悄变了”。有了历史曲线，回归起来比全靠体感靠谱得多。
