日志怎么看：用时、上游首包、缓存命中与计费

控制台「日志」页是每一笔请求的完整记录。很多人第一次看到「用时/上游首包」那一列有两个数字、以及「提示」下面多出一行「缓存读 · 写」，不知道是什么意思。

这篇先讲清三个前提（能避开大部分误判），再逐个拆开：哪个数字代表多快、哪个数字代表省了多少、钱是怎么算出来的。

零、三个前提（先读，能省掉大部分误判）

前提 1：这三个数字都没有固定值，都是逐次计算的

日志里的每一个数值，都只代表那一次请求。不存在「这个模型的 TTFT 是 4.5 秒」这种说法。

指标	有固定值吗	为什么
用时（总耗时）	❌ 逐次不同	输入多长、输出多少、上游当时多忙，每次都不一样
上游首包	❌ 逐次不同	主要取决于上游模型的排队与实时负载
缓存命中	❌ 逐次不同	取决于你的会话是否连续、前缀是否一致、有没有超时

我们抽查某分组近期 128 条 claude-opus-5-5 流式请求，差距是这样的：

指标	最小	中位数（P50）	P90	最大
上游首包	2,239 ms	4,549 ms	8,696 ms	12,954 ms
缓存命中率	0.0%	95.8%	99.6%	99.9%

最多差了 5.8 倍。所以：

⚠️ 判断快慢、判断缓存效果，都要看一段时间内的 P50 / P90，不要拿单次数据下结论。
拿一次 12.9 秒说「慢」，或拿一次 99.9% 说「缓存好」，都会误判。

前提 2：上游首包只存在于「对话模型 + 流式请求」

这是最容易被误解的一点。有没有首包，不看模型贵不贵，而是看你的调用方式。

stream: true 才有；stream: false 没有。图像、视频类模型天然没有流式概念，所以永远没有首包。

我们抽了近期 400 条真实日志，按模型统计如下（同一时段、同一批用户）：

模型	类型	请求条数	其中流式	有首包
gemini-3.1-flash-image-preview	图像	280	0	0
gemini-3.1-pro-preview	对话	60	0	0
gpt-5.6-sol	对话	20	20	20
gpt-image-2-c	图像	16	0	0
gpt-5.6-luna	对话	10	10	10
grok-4.5	对话	7	2	2
deepseek-v4-flash	对话	2	0	0

从这张表能读出三件事：

图像模型 100% 没有首包（前两行合计 296 条，全部为 0）；

gemini-3.1-pro-preview 是对话模型，但 60 条全是非流式，所以一个首包都没有 —— 不是模型不支持，是调用时没开流式；

grok-4.5 的 7 条里只有 2 条是流式 —— 同一个模型，流式和非流式混着用，只有流式那 2 条有首包。

💡 结论：日志里没有首包，先查自己是不是没开流式，而不是怀疑模型有问题。

各类型的表现汇总：

模型类型	典型模型	支持流式	日志里有首包	日志里有什么
对话 / 推理	claude-opus-5-5、gpt-6-astra、gemini-4-argon、deepseek-v4-flash	✅	开流式才有	用时 + 首包 + tokens
图像生成	gpt-image-2-c、gemini-3.1-flash-image-preview	❌	❌ 永远没有	用时 + 张数
视频生成	kling-video、viduq4-preview	❌（异步任务）	❌ 永远没有	任务耗时 + 时长/条数

前提 3：缓存命中只对「支持缓存的模型」有意义

不是所有模型都有缓存这回事。没有配置缓存能力的模型，日志里根本不会出现「缓存读 / 写」，也不存在命中率。

截本文更新时（2026-11-03），在架 336 个模型中有 127 个配置了缓存价；其中对话类 191 个模型里，120 个有缓存、71 个没有。

情况	日志表现	你能做什么
模型支持缓存	显示「缓存读 N · 写 M」	优化前缀，把命中率做高，成本直降
模型不支持缓存	只显示一个输入 tokens 数	无缓存空间，只能从「减少输入量」省钱

另外，支持缓存的模型还分两种计费结构，别拿一种的经验套另一种：

结构	代表模型（倍率：命中 / 写入）	特点
收写入费	claude-opus-5-5（0.05 / 1.25）、gpt-6-astra（0.1 / 1.25）、kimi-k3.1-pro（0.1 / 1.0）	首次写入要额外付费，复用越多越赚
不收写入费	gemini-4-argon（0.05 / 无）、qwen3.8-flash（0.1067 / 无）、glm-5.3（0.186 / 无）	命中直接打折，没有写入成本，命中即赚

倍率的含义：命中倍率 0.05 = 命中部分按输入价的 5% 收费；写入倍率 1.25 = 写入部分按输入价的 125% 收费。具体以模型广场该模型显示为准。

前提 4：这三个指标各自是干什么用的

指标	本质	用来判断什么	什么时候该看
用时	端到端总时长	用户等待是否可接受、要不要调超时/并发	排查「太慢了」「超时了」
上游首包	首字延迟（TTFT）	交互是否「跟手」，打字机效果是否流畅	做对话产品、编程助手时
缓存命中	缓存复用的输入占比	成本结构是否健康、提示词写得对不对	排查「为什么这么贵」

三者不要混着看：用时长短主要由输出长度决定，首包快慢主要由上游排队决定，缓存命中只影响钱、几乎不影响速度。

一、先看懂这条日志

以图中的 claude-opus-5-5 为例：

列	这条记录里的值	含义
类型	消费	正常扣费请求（错误日志会显示「错误」）
模型	claude-opus-5-5	实际调用的模型
用时/上游首包	`25 s` + `2.3 s` + 「流」	总耗时 25 秒、上游首包 2.3 秒、流式请求 —— 见第二节
提示	`601` + 缓存读 9,737 · 写 1,684	三个 token 数，不是三个价格 —— 见第三节
详情	模型 2 · 分组倍率 0.113 · 缓存 0.05	用到的倍率摘要，点开有完整计费过程 —— 见第四节

💡 一句话记住：「用时/上游首包」是速度，「提示」下面那行是省钱的依据，「详情」里是钱怎么算出来的。

二、「用时/上游首包」：两个数字，别搞混

这一列在流式请求下会显示两个数字（非流式只有前面一个，原因见前提 2）：

25 s    2.3 s    流
 ↑        ↑      ↑
总耗时   上游首包  流式标记

1. 总耗时（25 s）

从我们网关发出请求，到最后一个字返回完毕，全程用了多久。这个数字对应你实际等待的总时长。

2. 上游首包（2.3 s）

从我们网关发出请求，到收到上游模型的第一个数据包，用了多久。这就是大家常说的 TTFT（Time To First Token，首字延迟）。

3. 为什么它不完全等于你感受到的「首字延迟」

它止于我们网关。从我们机房到你本地客户端之间还有最后一段网络往返，这段不计入这个数字。所以你在自己程序里测到的首字时间通常会比这个数字略高一些；

上游第一个包不一定已经是正文。有些模型会先发一段元数据（比如角色声明、思考标记），这时「上游首包」已经计时结束，但你的界面还没看到文字；

它只反映上游那一段。你本地网络的抖动、你程序的解析耗时，都不会体现在这里。

✅ 想测端到端首字延迟（含你本地网络），要在你自己的客户端里打点：记录发出请求的时间戳，和收到第一个 delta 的时间戳，两者相减。控制台这个数字只能作为参考基准。

三、缓存命中：三个 token 数

「提示」列显示 601，下面还有一行灰色小字：

601
缓存读 9,737 · 写 1,684

这三个数字加起来，才是这条请求的总输入量：

名称	这条记录	意思	单价
提示（未命中输入）	601	全新、没有缓存可用的输入 tokens	原价
缓存读	9,737	命中缓存、直接复用的输入 tokens	大幅折扣（本例 5%）
缓存写（缓存创建）	1,684	本次新写入缓存的输入 tokens	略高于原价（本例 1.25 倍）

1. 命中率怎么算

控制台不直接给百分比，因为「命中多少算高」取决于你的用法。算法是：

缓存命中率 = 缓存读 ÷（提示 + 缓存读 + 缓存写）

这条记录：9737 ÷ (601 + 9737 + 1684) = 9737 ÷ 12022 ≈ 81.0%

⚠️ 别用 缓存读 ÷ 提示。这里的「提示」只统计未命中的部分，不是总输入量，除出来会大于 100%，是最常见的算错方式。

2. 为什么有时候缓存读是 0

命中需要同时满足三个条件：

条件	说明
模型支持缓存	前提 3 里那 127 个模型才有；其余模型不显示这一行
前缀完全一致	系统提示词、工具定义、历史消息的顺序和内容都不能变。改动一个字、调换顺序，整段前缀就失效
同一会话连续请求，且没超时	新开会话 = 全新前缀，第一轮必然 0 命中；超过有效期（默认 5 分钟）也要重建

💡 怎么把命中率做高，写法示例见 👉 如何提高缓存命中率：提示词结构写法指南

3. 关于「写」比原价还贵

收写入费的模型，写入按 1.25 倍（5 分钟档）或 2 倍（1 小时档）计费，看着像被多收钱了，其实是预付：

写入时多付 25%，换来之后每一次读取只付 5%；

只要这段前缀被复用 2 次以上，总体就是省的；

如果前缀只用一次（一问一答就结束），缓存反而更贵。

💡 结论：缓存对「反复带同一段长上下文」的场景（编程助手、客服机器人、长文档问答）收益最大；对「每次都是全新问题」的场景基本无感。这是机制决定的，不是配置问题。

四、计费怎么算：用这条日志实算一遍

点开「详情」，能看到完整的计费过程。还是这条 claude-opus-5-5：

1. 先看倍率

模型倍率 2，输出倍率 5，缓存倍率 0.05，缓存创建倍率 1.25，分组倍率 0.113

2. 把倍率翻译成单价（每百万 tokens）

项目	算式	单价
提示价格	$4 / 1M tokens	$4.00
补全（输出）价格	$4 × 5	$20.00
缓存价格	$4 × 0.05	$0.20
缓存创建价格	$4 × 1.25	$5.00

提示价格 2 × 模型倍率 2。不同模型的基准倍率不同，以控制台显示为准。

3. 代入实际用量

提示      601  tokens ÷ 1M × $4.00  = $0.0024040
缓存    9,737  tokens ÷ 1M × $0.20  = $0.0019474
缓存创建 1,684  tokens ÷ 1M × $5.00  = $0.0084200
补全    1,228  tokens ÷ 1M × $20.00 = $0.0245600
                          ─────────────────
                          小计  $0.0373314
× 分组倍率 0.113                     = $0.004220

这一单实际扣费约 $0.0042（不到半分钱）。

4. 缓存到底帮你省了多少

同样这一单，如果 9,737 tokens 全部按未命中价 $4 计：

	这单实际	若完全没缓存	差额
输入侧成本	$0.012771	$0.049772	省 74.3%
整单成本	$0.004220	$0.008199	省 49.8%

⚠️ 注意：命中率 81%，整单只省了约 50%，不是因为算错了。缓存只作用于「缓存读」那一部分，输出（补全）和缓存写入都不打折。这条请求的 1,228 个输出 tokens 占了整单成本的 66%，所以缓存省钱的效果被稀释了。
判断缓存值不值，看「输入在总额里占多大比重」，而不是只看命中率。

五、为什么每次都不一样（展开说）

前提 1 已经把结论说了，这里补原因。

1. 两个指标的波动原因完全不同

这是本文最值得记住的一点：首包快慢和缓存命中，基本没有关系。

前面的 128 条样本里，命中率 99.9% 的请求照样出现过 10,157 ms / 12,954 ms 的首包；而命中率 0% 的请求最低只有 2,239 ms。

指标	主要受什么影响	次要影响
上游首包	上游模型的排队与实时负载（高峰期、长上下文、复杂推理都会拉长）	输入长度（prefill 计算量）
缓存命中率	你的调用方式：会话是否连续、前缀是否一致、间隔是否超时	模型是否支持缓存

所以「我明明命中率 99% 了，为什么首字还是 10 秒」是个伪命题 —— 这两件事本来就不是一条因果链。

2. 命中率的典型三段式

同一个人连续跑一下午，日志会呈现很规律的三个阶段：

冷启动：每条都是新会话，命中率几乎全是 0%；

稳定期：同一会话连续进行，缓存读一路累积（从 5 万涨到 13 万 tokens），命中率稳定在 98%~99.9%；

掉档：某几次请求的「写」突然飙到 3 万多 tokens、命中率掉到 60%~70% —— 那是缓存过期后重建（超过 5 分钟 TTL）。

看到掉档不用紧张，这是正常的重建成本，重建完下一轮就回到高位。

3. 所以要看分位数，不要看单次

❌ 容易误判	✅ 建议的做法
拿某一次的耗时当「这个模型的速度」	看一段时间内的 P50 / P90
拿某一次的命中率当「缓存效果」	分清冷启动轮次和稳定期轮次再比
跨模型直接比首包时间	同分组、同时段、同类型任务下再比
拿非流式日志找首包	先确认这条是不是流式（见前提 2）

六、常见疑问

问题	解答
命中率高是不是一定更快？	不是。首包时间主要由上游排队决定，与缓存命中无直接关系。缓存省的是钱，不保证省时间（能省一部分 prefill 计算，但不是主导因素）。
为什么我的日志只有「25 s」，没有第二个数字？	这条是非流式请求。常见于三种情况：代码里没开 `stream`、用的是图像/视频类模型、或者客户端默认走了非流式。详见前提 2。
图像、视频模型的日志该看什么？	它们没有首包和缓存，看总耗时和张数/时长即可。视频是异步任务，日志记录的是任务耗时而非首包。
为什么我一直是 0% 命中？	先确认模型是否支持缓存（前提 3）；若支持，再查是不是每次新会话、系统提示词里有变量（时间戳、随机 ID）、或间隔超过 5 分钟。
缓存写为什么比不缓存还贵？	收写入费的模型按 1.25 倍（5m）/ 2 倍（1h）计费，是预付。前缀复用 2 次以上就划算，只用一次就亏。不收写入费的模型（Gemini / Qwen / GLM 等）没有这个问题。
5 分钟和 1 小时缓存怎么选？	间隔短、调用密集用 5 分钟档（写入便宜）；要跨较长间隔保住上下文用 1 小时档（写入贵一倍，但不用反复重建）。
同一条日志刷新后数字会变吗？	不会。日志落库后就是最终值，不会二次改写。
为什么「详情」里的金额和列表的扣费看起来对不上？	详情里是乘分组倍率前的明细过程，列表里是乘完倍率后的实际扣费。以列表的最终扣费为准。

七、核对与排查

拿到一条看起来「不对劲」的日志，按这个顺序核：

确认模型和分组 —— 同一模型不同分组单价不同，先看是不是走错了分组；

确认是不是流式 —— 非流式日志没有首包时间，别误以为「没记录」；

看「提示」的三个数字 —— 输入成本暴涨通常是缓存失效导致的重复计费，不是单价变了；

看「详情」的完整算式 —— 每一项倍率和 token 数都列出来了，可以逐项手算复现。

如果仍然对不上，把 Request ID（详情里可一键复制）发给客服，我们可以按这一条精确定位到上游的实际计费返回。

💡 Request ID 是最快的排查入口。它对应上游一次唯一的调用，有它就不需要你在几百条日志里翻找。

八、延伸阅读

想解决的问题	看这篇
命中率太低，想知道提示词该怎么摆	👉 如何提高缓存命中率：提示词结构写法指南
不知道某个模型在哪个分组、多少价	👉 模型分组与价格差异
想按任务挑模型	👉 【模型选择】一张表说清按任务选模型
调用报错、连不上	👉 配置报错对照表

日志怎么看：用时、上游首包、缓存命中与计费

零、三个前提（先读，能省掉大部分误判）#

前提 1：这三个数字都没有固定值，都是逐次计算的#

前提 2：上游首包只存在于「对话模型 + 流式请求」#

前提 3：缓存命中只对「支持缓存的模型」有意义#

前提 4：这三个指标各自是干什么用的#

一、先看懂这条日志#

二、「用时/上游首包」：两个数字，别搞混#

1. 总耗时（25 s）#

2. 上游首包（2.3 s）#

3. 为什么它不完全等于你感受到的「首字延迟」#

三、缓存命中：三个 token 数#

1. 命中率怎么算#

2. 为什么有时候缓存读是 0#

3. 关于「写」比原价还贵#

四、计费怎么算：用这条日志实算一遍#

1. 先看倍率#

2. 把倍率翻译成单价（每百万 tokens）#

3. 代入实际用量#

4. 缓存到底帮你省了多少#

五、为什么每次都不一样（展开说）#

1. 两个指标的波动原因完全不同#

2. 命中率的典型三段式#

3. 所以要看分位数，不要看单次#

六、常见疑问#

七、核对与排查#

八、延伸阅读#