TTFT 长上下文实测：Codex 连上 TaoToken 能复算 prefill 单价

原文系列第 10 篇测的是 Qwen2.5-0.5B/1.5B 在纯 NumPy CPU 引擎上的 TTFT，结论是 TTFT 近似等于输入 token 数乘以 prefill 单价。这篇直接把 Codex 接到 TaoToken，让 Codex 读 eng_ctxscale_real.py 和 eng_ctxscale.json，把同一批数据的 prefill 单价自动复算一遍。TaoToken 官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 上创建 API Key 后，Base URL 填 https://taotoken.net/api，剩下的核对工作就在 Codex 对话里完成。手动复算要先拆 TTFT/TPOT 再去掉 BOS，这两步都很容易出错，换成 Codex 来读脚本逻辑，就不用手工一个个算。

1. 为什么别手算：eng_ctxscale_real.py 的几个暗坑

1.1 脚本到底在测什么

eng_ctxscale_real.py 是原文的数据来源脚本。它用纯 NumPy CPU 内核加载真实权重，对 6 档不同长度的输入分别做推理，每档记录两个关键指标：TTFT，也就是从提交请求到模型吐出第一个 token 的墙钟时间；以及 TPOT，也就是开始出字之后平均每个 token 的解码耗时。原始结果存在 eng_ctxscale.json 里，后续所有结论都来自这个文件。

复算的时候，TTFT 和 TPOT 必须分开处理。TTFT 代表 prefill 阶段全部输入被计算一遍的成本，长上下文请求的等待几乎全部发生在这里；TPOT 是解码阶段的速度，与输入长度基本无关。如果我们只看一个「每秒 X token」的平均吞吐，prefill 这个大头会被后面的解码速度平均掉，得到一种「模型很快」的错觉。原文 0.5B 的 TPOT 只有约 70ms，但输入 1527 token 时 TTFT 却要 108.81s，这就是为什么长上下文等待和模型生成速度是两回事。

1.2 四个容易翻车的手算坑

坑一是 BOS。encode()会自动加一个 BOS token，原文表格里的「实际 token」是扣掉 BOS 后的数字。如果我们拿「目标长度」那一栏直接当实际 token 数，小档位偏差会很明显。拿 100 目标档举例，实际是 123 token，如果拿 100 去算「每输入 token 成本」，0.5B 那档会得约 80.6ms/tok，正确值是 65.6ms/tok，偏差接近 23%；而 1500 档实际 1527 token，用 1500 去除是 72.5ms/tok，正确是 71.3ms/tok，偏差只有 1.7%。换句话说，手算不扣 BOS 会让「单价是否稳定」的判断在小档位明显失真。

坑二是把 TPOT 混进 prefill 单价。计算每输入 token 的 prefill 成本，标准算法是 TTFT 除以实际输入 token 数。如果用总耗时去除，长档位碰巧和正确值接近，但短档位因为输出 token 占比大，误差会被放大。原文 0.5B 只生成 10 个 token，短档位下输出 token 的解码时间占了大头，混用之后算出来的「单价」并不反映 prefill 本身的成本。

坑三是 TPOT 的局部抖动。0.5B 在 750 token 档时 TPOT 一度跳到 88.7ms，其他档都在 70ms 左右。如果拿 TPOT 的涨跌去推断「是不是超过某长度就崩」，会误判成拐点。实际上这是 CPU 上 KV cache 内存带宽抖动造成的，和 prefill 单价无关。复算时只看 TTFT 段，不要被 TPOT 的波动干扰。

坑四是填充文本不能乱换。eng_ctxscale_real.py 里的 FILLER 是正常中文句子，tokenizer 切分后接近真实业务 prompt。如果为了省事把填充文本改成重复单字，token 数会偏离真实分布，缩放曲线也会跟着歪。我们自己复算时应该保持原文件的填充文本不变，或者明确知道改动后 token 数会不同。

1.3 手动复算的工作量

手动复算 0.5B 六档至少要做六次除法，还要反复确认每档用的是「目标长度」还是「实际 token」，json 里存的是扣过 BOS 还是没扣过的字段。这些确认工作并不是脚本复杂，而是字段定义只有回到代码里才能确定。交给 Codex 读脚本和 json，它可以直接从代码逻辑里判断应该用哪个字段，复算结果也就不容易再踩这些坑。

2. 先配 Codex 到 TaoToken：config.toml 里的 provider 怎么写

2.1 去 TaoToken 拿 Key 和模型 ID

打开 TaoToken 注册登录，在控制台创建 API Key，得到 YOUR_API_KEY。模型 ID 不写死，以 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 模型广场当前列表为准，不要凭记忆猜一个 ID。网站里的链接只用来注册、创建 Key、看模型、查用量；Codex 请求要走接口地址 https://taotoken.net/api，末尾不要加 /v1。

2.2 配置文件示例

在 ~/.codex/config.toml 里追加自定义 provider：

model = "YOUR_MODEL_ID" # 以模型广场当前列表为准 model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY" wire_api = "chat"

保存后在 shell 里设置 Key，再启动 Codex：

export TAOTOKEN_API_KEY="YOUR_API_KEY" codex

config.toml 里不要写明文 Key，用 env_key 指向环境变量，避免把密钥带进 git 提交。Codex 启动后，后续所有补全和对话都走 https://taotoken.net/api 这个通道。

这一步只是让 Codex 有模型通道可用，并不需要重新执行 eng_ctxscale_real.py。那个脚本要在本机 CPU 上跑几分钟甚至更久，Codex 要做的只是读代码和 json 文件，理解逻辑后复算，不需要再跑一遍推理。

3. 让 Codex 读两个文件，把 TTFT 单价复算出来

3.1 给 Codex 的 prompt 怎么写

把 eng_ctxscale_real.py 和 eng_ctxscale.json 放在当前目录，然后在 Codex 对话里粘贴下面这段，或者用codex exec在命令行直接跑：

codex exec "读当前目录下的 eng_ctxscale_real.py 和 eng_ctxscale.json。不要执行 python 推理脚本。先看脚本里对 BOS 的处理，确认 json 里的实际 token 是否已扣除 BOS；然后按模型分组，对每档计算 prefill 单价 = TTFT / 实际输入 token 数，并输出 Markdown 表格；最后判断同一模型各档的单价是否近似稳定，TTFT 是否随输入长度近似线性。"

这段 prompt 有两个要点。第一，明确禁止执行 python 推理脚本，因为那是在本机跑原始推理，Codex 环境不一定有 NumPy 权重文件，也不该等几分钟。第二，要求 Codex 先从脚本里确认 BOS 的扣除方式，而不是直接让它减 1。json 里存的实际 token 可能已经是扣过 BOS 的，也可能存的是目标长度，这个判断应该由 Codex 从代码里找答案。

3.2 预期输出长什么样

如果读到的就是原文那批数据，Codex 复算后的表格应该类似这样：

读这张表时重点看两件事。第一，0.5B 的 prefill 单价从 65.6ms/tok 到 71.3ms/tok，输入 token 涨了大约 12.4 倍，TTFT 涨了 13.5 倍，说明 TTFT 与输入长度近似线性，而不是平方级增长。第二，1.5B 两档单价落在 169~185ms/tok，大约是 0.5B 的 2.6 倍，与模型参数规模差异的方向一致。绝对毫秒数是原文那台 CPU 机器上的值，换 GPU 会整体改变，但「TTFT 随输入长度近似线性、单价由模型大小决定」这个缩放关系与硬件无关。

3.3 Codex 输出和表格不一致怎么办

先让 Codex 重读脚本里处理 json 的代码，并明确写出它用的是 json 里哪个字段。多数不一致来自「目标长度」和「实际 token 数」混用。如果 Codex 回答里没有说明 BOS 的处理方式，就追问一句「这里算出来的实际 token 是否已经排除 BOS」。不要让 Codex 自行假设，要求它在输出里把依据写清楚。

4. 复算结果读法：TTFT 近似线性，代价全在第一个字

4.1 复算之后支持什么结论

复算完的表格直接支撑原文的核心发现：TTFT 约等于输入 token 数乘以模型 prefill 单价。0.5B 长输入从 8.06s 到 108.81s，不是模型本身变慢，而是每个输入 token 都要参与一遍注意力计算。1.5B 在 1527 token 时要等约 282s 才吐出第一个字，换到端侧 CPU 场景这就是「发出去之后迟迟没有反馈」的直接原因。Codex 复算出的表格让我们不用手动算，也能确认这个线性关系是否成立。

4.2 短回答加长上下文是纯亏

复算表格里还有一个反直觉点。0.5B 生成 10 个 token 大约只要 0.7s，但送 1527 个输入 token 要等 108s。一个只想要 yes/no 的请求，如果带上一大段背景资料，几乎全部时间都花在 prefill 上，而不是在等模型思考或输出。优化首 token 延迟，正确的顺序是先数输入 token 数，再考虑要不要换模型。截断、检索、缓存这些减少喂入量的手段，对 TTFT 的影响近似线性：输入砍一半，首 token 等待就少一半。

4.3 顺手让 Codex 做几件相关的事

Codex 复算完成后，可以继续在同一个对话里做这三件事。第一，让它统计你项目里最高频那次 LLM 调用的输入 token 数，用真 tokenizer 而不是 len(text)/4，再乘上你所用模型的 prefill 单价，估算首 token 等待。第二，让它扫一遍 prompt 模板，把每次重复发送的静态前缀标出来，这些前缀占了多少 token、是否适合做缓存，都能直接算出来。第三，对长文档场景，让 Codex 估算「全文塞入」和「只喂相关段」之间的 token 差，再乘上模型单价，TTFT 差距就一目了然。

5. 排障：401、model not found、Base URL 多加了 /v1

5.1 接入 Codex 时的三个报错

Codex 连 TaoToken 最常见的报错是 401 Unauthorized。这通常是TAOTOKEN_API_KEY没有成功 export，或者 Key 前后带了空格。先执行echo $TAOTOKEN_API_KEY确认环境变量非空，再重启 codex，因为环境变量只在进程启动时读一次。

第二个常见问题是 model not found。config.toml 里 model 字段填了模型广场当前没有的 ID。模型 ID 不是固定的，别拿网上教程里的旧名字直接填，去 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 模型广场看当前列表再填。

第三个是 404 Not Found，通常是 Base URL 写成了https://taotoken.net/api/v1。Codex 会在 base_url 后面继续拼路径，多加 /v1 会导致请求打到不存在的路由。把 base_url 保持为 https://taotoken.net/api，末尾不带 /v1 即可。

5.2 复算结果对不上时怎么排查

如果 Codex 输出的单价和上面的表对不上，优先让它重读 eng_ctxscale_real.py 里处理 json 的段落，确认每档记录的是「目标长度」还是「实际 token」。如果 json 里的实际 token 已经扣过 BOS，计算时就不要手动再减 1。另一种情况是 Codex 把 TPOT 算进了 prefill 单价里。可以在追问里写明「只用 TTFT 字段，不用总耗时，不用 TPOT」。这两类排查做完，复算结果一般就能和原表对齐。

6. 回到控制台核账，再让 Codex 做三件优化

配置保存后，先在 TaoToken 模型对话 里用同一把 Key 发一条消息，确认 Key 和 Base URL 都没有问题。这一步能顺带验证刚才 Codex 的复算调用是否已经在用量列表里记账。如果接下来要高频写代码，可以打开 Coding Plan 看套餐是否够用；需要换 Key 或建多把 Key 时，在 控制台 API Keys 操作。以后想把同一个通道接到 Claude Code，环境变量对照见 接入文档。

这次对话完成后，回到你的项目里再问 Codex 三件事。找出最高频那次 LLM 调用的输入 token 数，用真 tokenizer 数而不是拍脑袋估算；把 prompt 里每次重复发送的静态前缀抽出来，评估占总 token 多少；对长文档场景，先让 Codex 给出 RAG 切块后的 token 估算，别再盲目把整段长文塞进上下文。做完这三件事，再回到 TaoToken 控制台刷新一下用量，刚才每一次 Codex 调用都会在记录里出现。到那时候再看「TTFT 约等于输入长度乘以模型单价」这句话，心里就有数了。