每百万 Token 的价格很低，并不足以说明一个 DeepSeek API 中转接口适合你。
你还需要知道：这个价格对应哪类 Token，缓存输入是否单独计费，请求使用的是哪个模型，以及最终怎样从账户余额里扣除费用。
对于正在比较中转服务的开发者，更实用的问题是：
调用前能不能估算费用，调用后能不能解释扣费？
这篇文章从一笔请求开始，把价格页面、Token 用量和账户账单对齐。
## 先看三种价格，而不是一个数字
一次 DeepSeek 模型请求，通常需要区分三类用量：
| 用量 | 对应含义 |
|---|---|
| 未命中的输入 Token | 按输入缓存未命中价格计费 |
| 命中的输入 Token | 按输入缓存命中价格计费 |
| 输出 Token | 按输出价格计费 |
[DeepSeek 官方价格页](https://api-docs.deepseek.com/quick_start/pricing/)分别列出了这些项目。
2026 年 11 月 4 日核对时，官方直连接口的峰时参考价如下：
| 模型 | 输入缓存命中 | 输入缓存未命中 | 输出 |
|---|---:|---:|---:|
| deepseek-flash | 0.006 美元 | 0.30 美元 | 1.20 美元 |
| deepseek-v4-pro | 0.044 美元 | 1.32 美元 | 3.96 美元 |
单位均为每百万 Token。官方页面另有谷时价格和适用时间说明。
这些数字是 DeepSeek 官方直连参考价，不是任何中转平台的账户分组报价。
中转服务可能采用不同的计费安排。比较时应核对实际条款，不能默认上游的所有价格规则都会原样传递。
## 用一笔请求算清楚
假设一次 DeepSeek Flash 请求包含：
- 输入总量：100,000 Token。
- 缓存命中输入：20,000 Token。
- 缓存未命中输入：80,000 Token。
- 输出：10,000 Token。
按照上面的官方峰时参考价：
```text
未命中输入：
80,000 ÷ 1,000,000 × 0.30 = 0.024 美元
命中输入：
20,000 ÷ 1,000,000 × 0.006 = 0.00012 美元
输出：
10,000 ÷ 1,000,000 × 1.20 = 0.012 美元
模型 Token 费用小计：
0.024 + 0.00012 + 0.012 = 0.03612 美元
```
这是计算示例，不是实际调用记录。
在所有条件完全相同的假设下，一千次请求的模型 Token 费用小计为 36.12 美元。真实业务的输入长度、输出长度、缓存情况和适用价格都会变化。
这里有一个容易算错的地方：命中的输入属于输入总量的一部分。不能先把 100,000 个输入 Token 全部按未命中计费，再额外计算其中的 20,000 个缓存 Token。
输出也应使用服务返回的计费用量，而不是根据用户看到的回答长度自行估计。
## 把中转报价统一成同一种口径
比较不同服务之前，先补齐下面的信息：
```text
具体模型：
账户分组或线路：
结算币种：
每百万未命中输入价格：
每百万命中输入价格：
每百万输出价格：
其他适用费用：
价格生效日期：
```
如果平台按积分或账户额度报价，需要明确它与实际付款币种的换算关系。
如果页面显示了线路调整系数，则需要确认单价是否已经包含该调整。重复计算一次，会导致你的估算出错，即使平台扣费本身没有问题。
同样，余额显示美元符号，也不足以说明人民币付款是如何换算的。
使用 TreeRouter 时，可以结合[价格与分组说明](https://treerouter.apifox.cn/)核对令牌选中的分组。计算时采用当前账户实际报价，不要沿用旧文章里的价格。
## 支持缓存和真正节省费用，是两件事
DeepSeek 提供上下文缓存机制，但评估中转接口时，需要分别确认：
1. 请求是否符合上游缓存复用条件。
2. 中转平台怎样展示和结算对应的用量。
[官方缓存文档](https://api-docs.deepseek.com/guides/kv_cache/)介绍了前缀复用及命中行为。
重复发送几次短提示词，不能证明生产环境一定有相同的命中率。响应里没有缓存字段，也不能直接证明没有发生缓存。
如果响应只提供输入总量，应结合账单记录或向服务方确认，不能为了让数字对上而自行假设缓存比例。
初期预算可以先按没有缓存优惠的情况计算，再用实际业务数据替换假设。
## 先核对一笔扣费，再估算整个月
第一次验证应尽量简单。
创建一个独立测试令牌，发送规模有限的请求，保存：
- 请求时间。
- 请求模型和账户分组。
- 可获取的响应标识。
- 响应中的用量字段。
- 对应的账户日志。
- 扣费金额和币种。
TreeRouter 的[用量日志说明](https://treerouter.apifox.cn/8659809m0)介绍了如何展开单条日志，查看 Token 消耗与计算方式。
把响应和日志中的同一次请求对应起来。如果两边没有共同请求标识，可以使用独立测试令牌和较短时间窗口，避免同时发送多笔请求造成混淆。
小额差异可能来自取整或计费单位。明显且无法解释的差异，应在扩大调用量之前查清楚。
## 比较通过验收的任务成本
假设某条线路每个 Token 更便宜，但经常截断业务需要的输出。
它的单价较低，却未必有更低的实际使用成本。
可以用同一组业务样本计算：
```text
每个通过验收任务的成本 =
测试期间实际计费总额
÷ 通过业务验收的结果数量
```
计费总额应包含已经计费的重试和不合格结果。不同候选服务必须使用相同的验收标准。
这不是让你购买更贵的线路，而是区分“单价低”和“完成任务的成本低”。
可以参考站内的[模型验收测试指南](https://api.treerouter.ai/en/blog/chinese-llm-api-acceptance-tests)，建立适合自己的验收条件。
## 模型费用和辅助服务费用分开算
完整工作流还可能使用搜索、网页抓取、存储或其他工具。
这些服务不一定按模型 Token 计费，应在预算里单独列出。
中转接口支持 DeepSeek 文本生成，也不代表同一价格已经包含所有相关服务。
比较普通聊天请求与会执行多次外部操作的 Agent 任务时，这个区别尤其重要。
## 第一次接入要回答一个具体问题
准备评估 TreeRouter 时，可以先[注册账号](https://treerouter.ai/)，选择需要的 DeepSeek 线路，按照账户计费条件完成小规模测试。
第一个目标是一笔能够解释清楚的扣费。
单次请求核对完成后，再测试代表性业务，比较通过验收的任务成本，然后决定是否扩大使用。
# Gemini API 中转怎么接？先选对接口，再改 Base URL
你已经拿到 Gemini 模型名称、API Key 和中转地址。
普通文字请求成功了。但加上 PDF、视频引用或某个 Google 专用参数以后，请求就开始报错。
这时，问题可能出在接口格式，而不是模型本身。
Gemini API 中转可以提供不同的接口形式。选哪一种，会影响现有代码能复用多少、媒体如何上传，以及响应应该怎样解析。
## 先确定应用真正需要的请求格式
两种常见形式如下：
| 接口形式 | 典型请求结构 | 典型响应位置 |
|---|---|---|
| OpenAI 兼容 Chat Completions | `model`、`messages` | `choices[].message` |
| Gemini generateContent 格式 | `contents`、`parts`，模型位于 URL | `candidates[].content.parts` |
它们是不同的请求约定，不能只换一个地址后继续发送完全相同的 JSON。
如果项目已经使用 OpenAI 兼容客户端，兼容接口可能减少应用改动。
如果项目依赖某项 Google 专用能力，则应该从该功能的接口要求出发，确认中转服务是否实现。
Google 自己也提供 [OpenAI 兼容接口文档](https://ai.google.dev/gemini-api/docs/openai)。但 Google 官方直连服务与第三方中转是不同目的地址，凭证和账户控制不能混用。
## 确认 Treerouter 文档中的两条路径
平台的 [Gemini Chat Completions 文档](https://treerouter.apifox.cn/451407471e0)使用：
```text
POST /v1/chat/completions
```
[Google 格式文档](https://treerouter.apifox.cn/451407482e0)提供 generateContent 形式，并注明需要选择对应的 Google Gemini 格式分组。
该页面的示例仍使用较早的模型标识。应把它作为接口结构示例，而不是新项目的模型推荐。
实际调用时，使用当前账户可用的准确模型 ID。
还要分清 Base URL 与完整请求地址。会自动追加 `/chat/completions` 的客户端，与需要手工填写完整路径的 HTTP 请求，配置值并不相同。
可以结合[请求地址说明](https://treerouter.apifox.cn/8659808m0)，检查软件要求填写哪一类地址。
## 先测试兼容接口的文字请求
下面的 Bash 示例使用文档中的 Chat Completions 路径。
提前在环境变量中设置 `TREEROUTER_API_KEY` 和 `GEMINI_MODEL`。模型变量应填写当前账户已开通的准确 Gemini 标识。
示例通过 `jq` 构建 JSON：
```bash
jq -n \
--arg model "$GEMINI_MODEL" \
'{
model: $model,
stream: false,
messages: [
{
role: "user",
content: "Reply with one short sentence describing an API."
}
]
}' > gemini-probe.json
curl --fail-with-body \
https://treerouter.com/v1/chat/completions \
-H "Authorization: Bearer $TREEROUTER_API_KEY" \
-H "Content-Type: application/json" \
--data-binary @gemini-probe.json
```
在后端或本地开发环境运行，不要把密钥写进浏览器可下载的前端代码。
成功响应说明这组 Key、模型、分组和文字请求能够配合使用，并不代表全部 Gemini 功能都已验证。
## Google 格式需要独立请求结构
最小 generateContent 请求体如下：
```json
{
"contents": [
{
"role": "user",
"parts": [
{
"text": "Reply with one short sentence describing an API."
}
]
}
]
}
```
请求路径遵循：
```text
/v1beta/models/{MODEL_ID}:generateContent
```
这里展示的是结构，实际认证方式和模型权限应采用所选分组的配置。
不能把上一段示例中的 `messages` 原样发送到这条路径，也不能在返回 `candidates` 后，继续读取 `choices[0].message.content`。
切换协议时，请求构建和响应解析都要一起检查。
## “支持文件”需要问得更具体
评估 Gemini 中转接口时，不要只问“能不能传文件”，而要确认：
- 能否接收内联 PDF？
- 能否使用供应商生成的文件引用？
- 能否读取应用提供的特定 URL 类型？
- 能否接收内联视频数据？
- 是否保留业务需要的响应元数据？
Treerouter 分别提供了使用视频链接的[兼容格式示例](https://treerouter.apifox.cn/451407478e0)，以及使用内联媒体数据的 [Google 格式示例](https://treerouter.apifox.cn/451407485e0)。
它们展示了不同的请求结构，但不能据此推断所有账号、模型、URL 类型、文件大小和 Google Files API 操作都能互换。
尤其不要默认一个服务生成的上传文件 ID，可以直接用于另一个账户或服务。
官方直连行为可以参考 Google 的[视频理解文档](https://ai.google.dev/gemini-api/docs/video-understanding)，随后再验证实际准备使用的中转路径。
## 每次只增加一项必需能力
文字请求通过以后，再加入产品需要的下一项能力。
文档助手可以使用一份内容容易人工核对的小 PDF；视频应用可以使用一段你已经了解内容的短视频。
建立一张能力记录表：
| 需求 | 测试证据 | 结果 |
|---|---|---|
| 文字回答 | 保存的请求与有效输出 | 通过或不通过 |
| 必需媒体输入 | 能回答媒体特有的问题 | 通过或不通过 |
| 必需流式行为 | 客户端识别正常完成 | 通过或不通过 |
| 用量可查 | 对应的账户日志 | 通过或不通过 |
媒体测试不能只看 HTTP 200，还要检查回答能否证明模型收到了相关内容。
需要进一步测试 PDF 内容提取时，可以阅读已有的 [Gemini 文档提取教程](https://api.treerouter.ai/en/blog/gemini-pdf-table-extraction)。本篇解决接口选择，后续教程解决内容任务，两者分开验收。
## 选择满足需求的较小接入方案
应用已经使用兼容请求结构，而且需要的功能也被支持时，可以优先评估兼容接口。
应用依赖明确的 Google 格式能力时，再评估对应原生格式线路。
同时维护两种协议也可以，但意味着两套请求构建、响应解析和测试路径，应有明确的产品需求作为理由。
如果两条路径都缺少必需能力，应在正式迁移前记录这个缺口。
## 让注册直接服务于接入判断
评估 TreeRouter 时，先[注册账号](https://treerouter.ai/)，选择与 Gemini 请求格式匹配的分组，运行文字测试。
随后增加一项必需媒体能力，并核对用量记录。
测试结束后，你应该能明确回答：项目适合哪条接口、需要什么请求结构，以及哪些能力仍需其他路径。
# Claude API 中转怎么选？付款前先确认这几件事
你已经决定使用 Claude。
接下来要选择的是接入方式：直接使用官方服务，通过 API 中转站，还是沿用团队现有的模型接入体系。
到了这一步，再看一份模型排行榜，通常无法解决真正的问题。你需要确认的是：服务能否提供项目要求的模型、协议、计费透明度和运行行为。
## “有没有 Claude”只是第一个问题
看到模型目录以后，还应该补齐：
```text
请求使用的模型 ID：
账户可用分组：
支持的 API 格式：
项目必需能力：
计费规则：
支持与排错入口：
```
具体模型标识很重要。“Claude 高级版”这样的名称，不能告诉应用应该发送什么字符串，也不能解释未来模型发生变化时如何处理。
例如，TreeRouter 的 [Claude Sonnet 5.5 模型页](https://api.treerouter.ai/en/models/claude-sonnet-5-5)提供了明确模型标识和接口类型。
这可以作为接入起点，但正式使用前仍要确认账户权限。
响应里的 model 字段有助于追踪，却不是独立的上游身份认证。文档、服务承诺、运行记录和可重复评估提供的是不同维度的证据。
不要向模型提问“你是什么模型”，再把生成的回答当作身份验证。
## “能不能继续使用现有客户端”
这取决于客户端要求什么接口。
基于 Chat Completions 的应用，使用一套请求与响应结构；基于 Anthropic Messages 的应用，使用另一套结构。
Anthropic 的 [Messages API 文档](https://platform.claude.com/docs/en/api/messages)介绍了原生接口。兼容线路可以减少现有应用的改动，但仍应按具体功能验证。
| 当前应用 | 优先评估的接口 |
|---|---|
| 普通 OpenAI 兼容聊天客户端 | 文档支持的 Chat Completions |
| 使用 Anthropic 内容块的应用 | Anthropic 兼容接口 |
| Claude Code | 中转服务的专用接入配置 |
| 依赖引用等原生能力的应用 | 明确支持该功能的接口 |
不要只因为某种方式配置步骤更少，就直接决定使用它。
## “第一次调用具体怎么做”
平台 Sonnet 模型页提供了 Chat Completions 示例。按照这个结构，可以发送一个小请求：
```bash
curl --fail-with-body \
https://treerouter.com/v1/chat/completions \
-H "Authorization: Bearer $TREEROUTER_API_KEY" \
-H "Content-Type: application/json" \
--data '{
"model": "claude-sonnet-5-5",
"stream": false,
"messages": [
{
"role": "user",
"content": "Explain the difference between an API key and a model ID in two short sentences."
}
]
}'
```
环境变量中应放置中转服务签发的 Key，不要把其他供应商的密钥发送到这个地址。
如果账户没有该模型权限，应先确认模型与分组，而不是不断猜测相似名称。
保存响应、用量信息和对应账户日志。
这一步证明基础连接可用，但不能直接证明整个编码 Agent 工作流或所有 Claude 原生能力都可用。
## “为什么聊天成功，项目仍然报错”
因为项目可能依赖的不只是文本回答，还包括：
- 工具请求和对应工具结果。
- 流式完成信号。
- 图片或文档内容块。
- 引用元数据。
- 特定结束状态和用量字段。
应该针对真正需要的能力设计小规模测试。
例如，回答里出现几个方括号编号，不等于返回了应用所需的结构化引用数据。
已有的 [Claude 原生引用教程](https://api.treerouter.ai/en/blog/claude-api-native-citations)介绍了这一具体场景。所选中转线路是否支持，应单独确认，不能从文字生成成功推导出来。
Claude Code 用户则应使用专门的[中转配置指南](https://treerouter.apifox.cn/8748837m0)。原始聊天请求成功和 Claude Code 会话成功，是两个不同的验证节点。
## “账单应该能看清什么”
至少应该能够解释这次扣费。
对于测试请求，应识别模型、适用分组、输入与输出用量，以及最终扣款金额。
[用量日志说明](https://treerouter.apifox.cn/8659809m0)介绍了单条记录的查看方式。
如果业务依赖缓存等价格类别，还需要确认它们怎样体现在账户记录里，不能默认其他供应商的 usage 结构会被完整保留。
比较节省金额时，应先统一币种、模型身份、线路和用量口径。直接拿两个首页单价相减，容易得到没有实际意义的结果。
便宜的报价有价值，但无法解释的报价很难用于预算。
## “上线前是否需要测试失败情况”
需要，但应采用有限、不会给服务制造不必要负载的测试。
例如，可以检查不存在的模型名称、在隔离测试中发送不支持的字段，或者设置客户端超时。
记录错误内容，以及应用是否能够区分配置错误和可能适合重试的情况。
不要为了探测限额，主动向共享服务大量发送请求。先取得适用的速率和并发条件，再在允许范围内测试。
还需要确认选定模型不可用时会发生什么。如果服务会切换到其他模型，应明确这种行为，让你判断是否符合项目要求。
测试过程中，静默更换模型可能让比较失去意义，即使最终回答仍然流畅。
## “什么时候值得使用中转站”
当它能减少你的真实工作时，才值得评估。
例如，统一多个模型的接入、减少客户端配置维护，或者更方便地追踪不同应用的用量。
如果只使用一家供应商，而且高度依赖刚发布的原生功能，官方直连也可能更简单。
选择应服务于必需能力和运行方式，而不是为了增加一个中间层。反过来，如果已经验证的中转线路可以满足需求，也不一定需要长期维护多套独立接入。
## 最后留下一个清楚的选择记录
决策记录可以很简洁：
```text
测试的 Claude 模型：
协议与请求地址：
已经验证的必需功能：
观察到的失败情况：
用量与扣费是否核对：
仍未确认的能力：
采用或暂不采用的原因：
```
准备评估 TreeRouter 时，先[注册账号](https://treerouter.ai/)，确认 Claude 模型和分组，再完成一个基础请求与一个项目真实任务。
目标是把不确定性变成证据：模型正确、接口匹配、费用可查，并且项目真正能够使用。
