原文系列第 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_sourcetaotoken_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 到 TaoTokenconfig.toml 里的 provider 怎么写2.1 去 TaoToken 拿 Key 和模型 ID打开 TaoToken 注册登录在控制台创建 API Key得到 YOUR_API_KEY。模型 ID 不写死以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当前列表为准不要凭记忆猜一个 ID。网站里的链接只用来注册、创建 Key、看模型、查用量Codex 请求要走接口地址 https://taotoken.net/api末尾不要加 /v1。2.2 配置文件示例在 ~/.codex/config.toml 里追加自定义 providermodel 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再启动 Codexexport TAOTOKEN_API_KEYYOUR_API_KEY codexconfig.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 复算后的表格应该类似这样模型实际 tokenTTFT (s)prefill 单价 (ms/tok)TPOT (ms)0.5B1238.0665.665.40.5B27918.5966.670.70.5B53937.0168.768.70.5B79954.6268.488.70.5B105975.1070.973.10.5B1527108.8171.373.71.5B53991.25169.3167.51.5B1527281.94184.6193.6读这张表时重点看两件事。第一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 多加了 /v15.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_sourcetaotoken_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 约等于输入长度乘以模型单价」这句话心里就有数了。