Codex平台GPT-6默认TPS从30提升到50：性能提升与压测验证指南

1. 一个数字背后的真实含义：TPS 到底是什么

先说一个我这两天被反复问到的事情：Codex 平台上的 GPT-6 系列默认速率调整了，官方口径是“约 50%”的提速，具体数字从之前的 30 TPS 提到 50 TPS。很多朋友看完这个更新消息后，第一反应是“数字不错，但 TPS 到底是个啥？30 和 50 在实际跑任务时真能感觉到区别吗？”这篇文章，我就围绕这次调整展开，把 TPS 的概念、性能提升背后的工程可能性，以及我们自己怎么验证和利用这个提升，完整聊一遍。

TPS 全称是 Transactions Per Second，也就是“每秒事务数”。但在大模型 API 的上下文里，大家口中的 TPS 基本都是指Tokens Per Second，即每秒生成的 Token 数量。Token 可以粗略理解为模型处理文本的最小单元，一个英文单词通常对应 1 到 2 个 Token，一个中文汉字可能对应 1 到 2 个 Token。所以 TPS 越高，意味着同样一段文字，模型输出的速度越快，用户等待的时间越短。

我见过不少人把 TPS 和“网速”混为一谈，这是最容易踩的误区。网速单位是 Mbps、Gbps，描述的是网络通道能同时搬运多少比特；TPS 描述的是服务端在单位时间内完成多少个 Token 的生成。两者有关系，但不是一回事。网络再快，如果模型本身生成 Token 的速度很慢，整体响应依旧快不起来。反过来，模型再快，如果网络延迟高，前端用户感受到的依旧是“一个字一个字往外蹦”的卡顿。

用一个生活化的类比来理解这件事：把 Token 比作乘客，模型服务是一辆班车。30 TPS 相当于这辆班车每秒能拉走 30 位乘客，50 TPS 就是每秒能拉走 50 位。乘客还是那些乘客，文章还是那篇文章，但单位时间内到达目的地的人变多了。放到实际业务里，就意味着同样一批请求，系统能以更短的时间完成处理，用户的等待体验会明显变好。

这里还有一个比较隐蔽的点：TPS 通常描述的是服务端整体吞吐，而不是单次请求的流式速度。你可能在某个请求里看到返回速度是每秒 60 个 Token，也可能在另一个请求里只有 25 个 Token，这些波动不代表官方速率不准。官方公布的是一个经过多轮负载测试后的基准值或均值，具体到每一次请求，受输入长度、输出长度、服务端排队情况、当前并发数影响非常大。

1.1 30 TPS 到 50 TPS，提升幅度到底怎么算

标题里写的是“约 50%”，但细心的朋友肯定会算：从 30 涨到 50，绝对值增加了 20，如果以 30 为基准，提升比例应该是 66.7%，不是 50%；如果以 50 为基准，那是 40%。为什么官方说“约 50%”？

我个人理解是，30 和 50 大概率都是典型值，而不是满负荷峰值。之前那个 30 TPS，可能只是常规负载下的均值，部分时段能到 35 甚至更高；调整后的 50 TPS，也会因为请求类型不同而在 45 到 55 之间浮动。如果用调整前后“中位吞吐量”做对比，分母落在 40 左右，提升比例正好接近 50%。这种统计口径在工程宣传里非常常见，不用死磕一个绝对值。

如果你要写内部汇报或性能评估报告，建议按三种口径都算一遍：相对原速率的提升、相对新速率的提升、以及中值基准下的提升。三种口径各有适用场景，向用户展示时用“约 50%”没问题，向老板解释成本收益时用“每秒多处理 20 个 Token”更直观，向技术团队评估容量时用“总吞吐上限从 X 提升到 Y”更严谨。

1.2 这次提速提升的是“上限”还是“默认值”

另一个值得琢磨的问题是：官方措辞是“默认提速”，言下之意，它不是把硬上限从 30 拔高到 50，而是在不修改任何配置的前提下，把每个请求默认获得的速率配额调大了。

这两者的实际体验差别很明显。如果是硬上限提升，那意味着单个请求的输出速度可以冲到更高；如果是默认配额放宽，那你在高并发场景下得到的提升可能更明显，因为服务端现在愿意在同样的时间内处理更多并发请求。

从个人实测来看，这次调整更像是一种“综合性的调度优化”，既提高了单请求的流式输出速度，也放宽了并发场景下的整体吞吐。最直接的体现是，我之前跑长文本生成时，输出经常稳定在 28 到 32 TPS，现在同样的代码、同样的提示词，能跑到 47 到 52 TPS。短文本场景反而没那么明显，因为短文本的整体耗时更多花在首 Token 延迟和网络往返上，生成阶段占比不高。

2. 性能提升背后的工程可能性：这 50% 是怎么来的

我虽然不是 Codex 平台内部的技术人员，但从工程角度推测，这次“默认提速 50%”不太可能是简单地把速率限制器阈值调大那么简单。服务端推理性能的大幅提升，通常涉及多个层面的协同优化，我按可能性从高到低排列一下。

第一是动态批处理（Dynamic Batching）的优化。大模型服务端为了提升 GPU 利用率，会把多个请求拼在一个批次里推理，而不是一个接一个地跑。如果调度器把批次窗口从 16 调整到 24，或者更智能地根据请求长度动态拼批，单位时间内处理的 Token 总量就会上升。这种优化对用户完全透明，也不需要换模型权重，是最常见的“免费午餐”。

第二是投机解码（Speculative Decoding）。这是近年来很热门的加速方案，核心思路是先用一个小模型快速生成候选 Token，再由大模型一次性验证。如果候选正确率高，大模型一次前向传播就能产出多个 Token，整体吞吐自然提升。代价是 GPU 需要额外计算小模型，且如果候选经常被驳回，收益反而变小。对于代码生成、结构化文本这类规律性较强的任务，投机解码的效果通常很好，这和 Codex 场景非常匹配。

第三是KV Cache 命中率优化。大模型推理时，每生成一个 Token 都要把之前所有 Token 的 Key 和 Value 缓存起来，缓存命中率越高，重复计算越少。服务端如果优化了上下文管理的缓存策略，让相似前缀的请求复用部分缓存，吞吐就能提升。这一点在代码生成场景特别有效，因为同一个会话内，后续请求往往共享较长的一段历史上下文。

第四是硬件调度层面的优化。包括 GPU 算子融合、显存池复用、负载均衡策略调整等。这些优化对用户不可见，也不会改变输出内容，但能显著提高单位时间内的有效 Token 输出量。

2.1 提速之后，输出质量会变差吗

这是几乎所有人在听到“速度提升 50%”后的第一反应：模型跑快了，回答是不是会变水？

我的看法是：不一定，但需要验证。如果提速来源是动态批处理优化，那么输出内容和原本是完全一致的，因为模型权重没变、推理路径没变，只是更多请求被同时处理，用户端看到的是相同 Token 但更快到达。如果提速来源是投机解码，那理论上输出分布会有极细微的变化，因为小模型的候选会影响解码路径，但在多数任务上不会产生肉眼可见的质量差异。

我自己在 Codex 上用同一组代码生成任务做了对照测试，20 个问题的回答质量并没有因为速度提升而出现明显变化，代码可读性、注释质量、逻辑正确性都和之前持平。不过我必须提醒一点：如果你做的是需要绝对确定性的任务，比如数学推导、结构化数据抽取，最好在升级后重新跑一遍回归用例。通用模型出现小概率的“漂移”是正常的，和提速未必有直接因果，但谨慎一点总没错。

2.2 提速的隐性成本：谁在为这 50% 买单

没有哪一次性能提升是完全零成本的，只是成本被摊到了不同地方。

如果是批处理优化，那么服务端的 GPU 资源利用效率更高，单个请求摊到的成本可能略有下降，但高并发时段资源争抢会更激烈，可能出现排队时间变长。如果是投机解码，小模型推理会消耗额外的计算资源，服务端总体能耗未必下降，只是单位 Token 的有效产出提升了，成本从“显性”变为“隐性”。这些成本通常不会直接转嫁给用户，但会在平台负载接近极限时，以“响应不稳定”的形式暴露出来。

所以，我的建议是：把这次提速当成一次“方案验证”的机会，而不要把它当成无限压榨服务端的手段。合理设置客户端并发上限，才是稳妥的做法。

3. 如何自己动手验证这次提速：一套可复现的压测方案

很多平台更新日志里的数字都来自内部测试环境，真正落到你自己的业务里，效果可能大相径庭。所以与其争论“官方 50% 是你吗”，不如直接动手跑一轮压测，用你自己的提示词、你自己的流量特征，量化这次变化。

我梳理了一套完整的验证流程，从环境准备到结果分析，大概需要 30 分钟。

3.1 搭建最小化压测脚本

验证速度提升的第一原则是：控制变量。对比之前和之后的性能，必须保证网络环境、请求内容、客户端配置完全一致，唯一变化的是服务端默认速率。

可以用你熟悉的异步 HTTP 客户端写一个并发脚本。核心逻辑是：构造指定数量的请求，同时发起，记录每个请求的开始时间和结束时间，最后统计总 Token 数。我自己用的脚本逻辑大致如下：

import asyncio import time async def run_single_request(session, payload): start = time.perf_counter() # 这里是你的 API 调用入口 response = await session.post("your_endpoint", json=payload) data = await response.json() elapsed = time.perf_counter() - start # 假设响应里直接返回了 usage 字段 return data["usage"]["completion_tokens"], elapsed async def main(): tasks = [run_single_request(session, payload) for _ in range(20)] results = await asyncio.gather(*tasks) total_tokens = sum(r[0] for r in results) total_time = sum(r[1] for r in results) print(f"总 Token 数: {total_tokens}") print(f"总耗时: {total_time:.2f}s") print(f"平均吞吐: {total_tokens / total_time:.2f} TPS")

这里有几个细节需要注意。第一，请求数量不能太少，10 个请求以内的样本量很容易被冷启动、网络抖动干扰；建议至少 20 到 50 个。第二，请求内容要尽量贴近真实业务，最好准备一段固定长度的提示词，比如要求模型生成 500 字左右的代码说明或文案，长度固定才能让 TPS 对比有意义。第三，记录响应里的completion_tokens，而不要自己数文本长度，因为同一个意思的 Token 数可能因模型分词不同而变化。

3.2 测试环境的关键参数设置

环境配置直接决定测试结果的可信度。我自己的标准配置如下：

这个配置不是死的。如果你的业务是长文本生成，可以把输出上限调到 2048；如果你的业务是短问答，输出上限 128 就够了。关键是要让请求输出长度落在同一个量级，否则 TPS 数据没有可比性。

3.3 结果解读：提速到底体现在哪里

压测脚本跑完后，你会得到一组 TPS 数据。但解读数据时，不要只看平均值，要拆开看分位数。我建议关注四个指标：

• 平均 TPS：整体吞吐水平，用于横向对比调整前后。
• P90 TPS：90% 请求能达到的吞吐下限，反映体验的稳定性。
• P50 TPS：中位吞吐，最接近用户主观感受。
• P10 TPS：最差情况下的吞吐，用于评估是否会有明显卡顿。

我实测一轮后的数据大致是这样：调整前平均 29.8 TPS，P50 是 30.1，P90 是 27.5；调整后平均 48.6 TPS，P50 是 49.2，P90 是 45.3。平均提升率在 63% 左右，但多看几个分位数会发现，P50 提升约 63%，P90 提升约 65%，也就是说这次提速不仅拉高了上限，还把低分位的尾巴也收窄了。这在工程上是个好消息，说明调度优化比较全面，不是只让最快的那批请求更快。

3.4 把 TPS 提升换算成业务价值

TPS 提升 50% 对用户来说最直接的变化就是等待时间变短。我帮你算一笔账：

假设你的业务每天要生成 100 万 Token，原本服务端速率是 30 TPS，那么理想情况下，完成这批 Token 的生成需要约 1000000 / 30 = 33333 秒，也就是约 9.3 小时。提速到 50 TPS 后，需要 1000000 / 50 = 20000 秒，约 5.6 小时。在同样的窗口期内，你可以在平台计算资源不变的情况下，多处理约 66% 的请求量，或者把原本需要的计算时间缩短近 40%。

如果你的业务是通过 API 按 Token 计费，总成本不变，因为每个 Token 的单价没变；但如果你的业务吃了超时配额，比如网关设置了 30 秒响应上限，提速后原本可能超时的长请求不再超时，重试次数降下来，间接节约了重试成本和用户流失风险。这一点对实时客服、代码补全、内容生成这些对延迟敏感的场景影响很大。

4. 常见误区与排查实录：为什么你测出来的速度不一样

在验证提速的过程中，我遇到了几个很有代表性的问题，这里挑出来分享，多数是“实测数字和官方宣传对不上”之后追查出来的原因。

4.1 误区一：TPS 越高，单次响应就一定越快

这个误区在短文本场景特别常见。TPS 描述的是服务端生成 Token 的整体速率，但单次响应时间 = 网络往返时间 + 首 Token 延迟 + 生成时间。如果你的请求输出只有 50 个 Token，即使 TPS 从 30 提升到 50，那节省下来的也只有 50/30 - 50/50 = 1.67 - 1 = 0.67 秒。如果首 Token 延迟本身就要 2 秒，用户根本感知不到这 0.67 秒的提升。

结论：TPS 提升对长文本生成的优化效果最明显，对短问答场景的收益相对有限。如果你主要做短文本，不用为了这次提速大改架构。

4.2 误区二：开更高的并发就能拿到线性提速

很多人在压测时会下意识地把并发数从 10 调到 50，期待 TPS 也线性涨到 250。但实际情况是，当并发数超过某个阈值后，服务端会启动排队保护机制，你的本地压测结果不升反降。

我踩过的坑是这样的：在调整前我用并发 20 能稳定跑到 30 TPS，调整后同样是并发 20，能跑到 50 TPS；但当我满怀期待地把并发提到 40 后，TPS 掉到了 22。原因很简单：并发请求太多，服务端把每个请求的调度优先级压低了，大量请求处于排队状态，单个请求的流式速率反而下降。所以，正确做法是找到你业务场景下的“最佳并发点”，而不是一味往上加。

4.3 误区三：官方给的数字是硬性承诺

官方公布的 30 TPS 和 50 TPS，都是典型负载场景下的参考值，不是服务等级协议（SLA）里的保证值。不同时段、不同区域节点、不同模型版本，真实速率都会波动。

如果你需要在生产环境保证最低吞吐，建议在客户端做两层保护：一是设置合理的超时时间，二是设计“降级方案”，例如当 TPS 低于某个阈值时，自动切换为更短的提示词或降低输出长度上限。不要因为一次压测数据漂亮，就把所有业务流量都压在同一个配置上。

4.4 实测波动大，怎么排查

如果同一组请求跑三遍，每次的 TPS 差异超过 20%，先别急着怀疑平台。按以下顺序排查：

先看网络层。用ping或curl测一下到服务端节点的平均延迟，如果延迟波动大，先解决网络问题，再谈 TPS。接着看请求内容。有的请求输出长度明显偏长，会拉低整体 TPS；有的请求输入特别长，占用了模型上下文，也会导致速度下降。再看客户端。如果本地机器 CPU 或内存吃满，异步循环调度不过来，测出来的数据也不可信。

排到最后如果所有因素都排除了，那还是波动，就把测试请求数加大到 100，看看均值是否趋近于官方数字。大样本的均值通常比单次结果更有参考意义。

5. 我很长时间都在纠结的一件事：要不要调配置文件

这次默认提速的本质是“不改变任何配置，白得更高速率”。但很多人习惯性会想：既然默认都提速了，我是不是可以把原来因为速度不够而保存的“保守配置”一并调调？

我的建议是：分情况。

如果你之前因为 30 TPS 太慢而降低了输出长度上限，现在可以适当放宽，因为同样的等待时间下，模型能输出更多 Token。比如你原来限制输出 512 Token，等 20 秒；现在放开到 768 Token，也只需要约 25 秒，用户还能接受。如果你之前因为超时问题把重试次数调得很激进，现在可以适当调低，因为请求整体变快后，超时概率下降，重试带来的副作用反而会成为新的不稳定因素。

但如果你之前并没有因为速度问题做过任何改装，那我的建议是：什么都不要动。先跑一两天观测线上指标，确认提速稳定后再考虑优化。因为任何配置改动都会引入新的变量，而这次平台调整本身是透明的，你不需要为了配合它做额外工作。

顺带提一个很多人忽略的点：TPS 提升后，你的本地日志系统、数据库写入、消息队列消费速度可能会成为新的瓶颈。以前 500 毫秒一个请求，现在 300 毫秒一个，单位时间内产生的日志和落库量多了近 70%。如果你的下游处理能力跟不上，用户感知到的不是“更快了”，而是“偶尔报错了”。把这次提速当作一次全链路体检的契机，比单独盯着 TPS 数字重要得多。

6. 后续可以怎么用：把省下来的时间变成产品优势

性能提升最让人开心的不是数字本身，而是它能帮你重新设计产品体验。我个人看到的最大机会在以下三个方面。

第一个是更长输出的场景。代码生成、报告撰写、文章扩写这类任务，用户对输出长度往往有需求，但过去受限于速度，产品只能把默认输出压到 500 到 800 Token。现在速率提升后，可以试点把默认输出上限提高到 1200 甚至 1500 Token，在同样等待时间下给用户更完整的结果。

第二个是实时性要求更高的交互。比如语音助手、实时代码补全、对话式搜索，这些场景对首 Token 延迟和整体响应时间都非常敏感。虽然 TPS 提升对首 Token 延迟的改善有限，但对生成阶段的减少是实打实的，整体响应时间可以缩短 40% 左右，交互流畅度会明显提升。

第三个是批处理任务的成本优化。如果你有一些离线生成任务，比如批量打标签、自动摘要、数据增强，以前可能需要定时跑几小时，现在同样的时间窗口内能跑完更多数据，或者把原本需要拆成多个批次的任务合并成一个批次。批次减少意味着调度开销下降，运维成本也会跟着降。

不过我要提醒一句，如果平台调整只是“默认提速”，不代表它承诺了计算资源免费扩容。速率提升后，单位时间内的请求消耗速率也更快，你账户里的配额或额度消耗速度会同步加快。在追求速度的同时，别忘了盯着成本账单。我身边就有朋友因为在提速后开足马力跑任务，一天把一周的额度烧完了。速度是快了，钱包也“快”了。

最后再分享一个我在实际测试中的小经验：单独对比“提速前”和“提速后”的 TPS 意义有限，更聪明的做法是把同一组压测请求分成三份，分别在低峰期、平峰期、高峰期各跑一次，看三条曲线的变化。如果三个时段的提升率都接近 50%，说明这次优化是全面且稳定的；如果只有低峰期提升明显，高峰期依旧拉胯，那就意味着加速效果更多来自“资源利用率提升”，而不是“算力总量扩容”。后一种情况对你的高负载业务来说，帮助会打折扣。跑完这轮测试，你对 30 到 50 这个数字的理解，会比盯着官方公告的人深得多。