---
title: "为什么第一次调用更贵"
description: "详解缓存写入成本的构成、计费规则、回本时机与无效成本场景，帮你全面清晰掌握AI编程缓存的核心价格逻辑与实用避坑技巧"
---

[上一篇](/guide/prompt-caching)的价格表里有一个反直觉的数字:**缓存写入是 1.25×**(1 小时 TTL 更是 2×)。也就是说,开启缓存后的第一次调用,不但没省钱,反而比完全不用缓存**更贵 25%**。这一篇解释这笔"入场费"从哪来、什么时候回本、什么情况下会白花。

## 普通调用:算完就扔

先看没有缓存时服务端在做什么。模型处理输入的过程,本质是为每个 token 计算注意力所需的内部状态(K/V 张量)。普通调用里,这些状态**用完即弃**:

- 你付的 1× 输入价,买的是"算一遍"的 GPU 算力;
- 请求结束,几十 GB 显存被释放给下一个用户;
- 下一轮同样的前缀进来,从零再算一遍,再付一遍 1×。

## 缓存写入:算一遍,还要存下来

标了 `cache_control` 之后,服务端做的事变成了**计算 + 持久化**两件:

```mermaid
sequenceDiagram
    participant C as 客户端
    participant S as API 服务端
    participant K as KV 缓存存储

    rect rgb(255, 240, 235)
    Note over C,K: 第一轮:缓存未命中(写入,计 1.25×)
    C->>S: 请求(30K token 前缀 + cache_control)
    S->>S: 全量计算前缀的 KV 状态(1× 的算力)
    S->>K: 把 KV 状态持久化保存(+0.25× 的存储与管理)
    S-->>C: 返回响应
    end

    rect rgb(235, 248, 240)
    Note over C,K: 后续轮:缓存命中(只计 0.1×)
    C->>S: 请求(同样的 30K 前缀 + 新增内容)
    S->>K: 按前缀哈希查找 → 命中
    K-->>S: 直接加载已算好的 KV 状态
    S->>S: 只计算新增部分
    S-->>C: 返回响应(首 token 延迟大幅下降)
    end
```

多出来的 0.25×,买的是"存下来"这件事的真实成本:

- **KV 状态非常大**。每个 token 的 K/V 张量在几十到上百 KB 量级(取决于模型结构),比 token 文本本身大几个数量级——30K token 的前缀,缓存下来是 GB 级的数据;
- **要占用昂贵的存储**。这些数据必须放在能被推理集群快速加载的地方,离 GPU 越近越贵;
- **要维护生命周期**。TTL 计时、每次命中刷新、过期回收、按账号和模型隔离,都是持续开销。

这也解释了为什么 **1 小时 TTL 的写入价是 2×**:计算部分没变,变的只是"存多久"——存 12 倍的时长,存储费自然更高。

一次请求进来,服务端的完整决策路径是:

```mermaid
flowchart TD
    A["请求到达<br/>(tools + system + messages)"] --> B["对断点之前的前缀<br/>计算哈希"]
    B --> C{"缓存中存在<br/>完全一致的前缀?"}
    C -->|"命中"| D["加载已存的 KV 状态<br/>只算新增部分"]
    D --> E["按 0.1× 计费<br/>并刷新 TTL"]
    C -->|"未命中"| F["从头全量计算前缀<br/>(首次 / 前缀变了 / TTL 过期)"]
    F --> G["把 KV 状态写入缓存"]
    G --> H["按 1.25× 计费<br/>(1h TTL 则 2×)"]

    style E fill:#e8f5e9,stroke:#4caf50
    style H fill:#ffebee,stroke:#ef5350
```

注意"未命中"的三种来源:**首次调用只是其中之一**。前缀变了一个字节、或 TTL 过期,都会让你再付一次 1.25×——这是[下一篇](/guide/cache-strategy)的主题。

## 什么时候回本:第二轮就回本

把写入费理解为一笔**投资**:多付 0.25×,换后续每轮 0.9× 的折扣。算一下回本点:

| 场景 | 两轮总费用(以 1× 为单位) |
| --- | --- |
| 不用缓存,跑 2 轮 | 1 + 1 = **2.0** |
| 用缓存,跑 2 轮 | 1.25 + 0.1 = **1.35** |

**只要同一前缀被复用一次,就已经回本**。轮数越多差距越大——沿用上一篇的例子(30K token 前缀),累计费用曲线是这样的:

```mermaid
xychart-beta
    title "累计输入费用对比(30K 前缀,单位:万 token 等效全价)"
    x-axis "轮次" [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
    y-axis "累计等效费用" 0 --> 32
    line "无缓存" [3, 6, 9, 12, 15, 18, 21, 24, 27, 30]
    line "有缓存" [3.75, 4.05, 4.35, 4.65, 4.95, 5.25, 5.55, 5.85, 6.15, 6.45]
```

上面那条陡峭的线是无缓存(每轮全价 3 万 token),下面平缓的线是有缓存(第一轮 3.75 万,之后每轮只加 0.3 万)。第一轮有缓存反而更高——这正是"第一次调用更贵"的直观图像;从第二轮起两条线交叉,之后差距一路拉大,50 轮时约为 12% 对 100%。

## 什么情况下写入费是白花的

这笔投资也有亏本的场景,都值得提前识别:

- **一次性请求**:前缀只用一次、不会有第二轮(比如批量离线处理里每条数据的前缀都不同),标 `cache_control` 纯属多付 25%;
- **前缀不稳定**:前缀里混进了时间戳等每轮变化的内容,结果是**每一轮都在付 1.25× 的写入费,却从来不命中**——比不开缓存还贵 25%,这是最糟的状态。验证方法:看 `usage` 里 `cache_read_input_tokens` 是否长期为 0 而 `cache_creation_input_tokens` 每轮都很大;
- **前缀太短**:低于最小长度门槛(多数模型 1024 token)不会真的写入,不亏钱,但也没意义。

:::tip[OpenAI 为什么"不收"写入费]
OpenAI 的 automatic prompt caching 不显式加收写入费,但命中折扣也只有五折(部分模型更低),且缓存去留由服务端决定。两家本质相同:**存储成本总要有人付**——Anthropic 选择显式计价、给你显式控制;OpenAI 选择摊进整体价格、全自动。对 Claude Code / Codex 用户来说结论一致:第一轮贵是正常的,别让它反复发生就好。
:::