计费与用量

图灵平台对每一次 LLM 调用都在后端重算账单——不直接使用上游厂商返回的 cost header，而是按模型 + 用量明细按类目单价相加。本页是所有接口共享的计费参考：单价维度、算法顺序、如何从响应里读到用量、如何通过 trace 接口对账。

阅读顺序

如果只想看自己请求花了多少钱，直接跳到从响应里读用量和对账接口。要理解每一项单价代表什么、为什么有时候按 fallback 价计费，看计费维度速查表和计费算法。

计费维度速查表

所有 LLM 模型的单价都由 LLMModelEngineInfo 描述，覆盖 13 个可计费维度。请求到达时，平台按计数器（usage 里返回的数量）× 单价得到该类目的金额。

单价字段	单位	对应计数器	fallback
`input_cost_per_token`	每百万 token	`prompt_tokens`（已减去其它类目后的 text + 未归类 token）	必填，无 fallback
`output_cost_per_token`	每百万 token	`completion_tokens`（已减去其它类目后的 text + 未归类 token）	必填，无 fallback
`input_cost_per_cached_token`	每百万 token	`prompt_tokens_details.cached_tokens`（缓存读）	→ `input_cost_per_token`
`cache_creation_input_token_cost`	每百万 token	`prompt_tokens_details.cache_creation_token_details.ephemeral_5m_input_tokens`（5 分钟缓存写）或扁平的 `cache_creation_tokens`	→ `input_cost_per_token`
`cache_creation_input_token_cost_above_1hr`	每百万 token	`prompt_tokens_details.cache_creation_token_details.ephemeral_1h_input_tokens`（1 小时缓存写）	→ `cache_creation_input_token_cost` → `input_cost_per_token`
`audio_input_cost_per_token`	每百万 token	`prompt_tokens_details.audio_tokens`	→ `input_cost_per_token`
`audio_output_cost_per_token`	每百万 token	`completion_tokens_details.audio_tokens`	→ `output_cost_per_token`
`image_input_cost_per_token`	每百万 token	`prompt_tokens_details.image_tokens`	→ `input_cost_per_token`
`image_output_cost_per_token`	每百万 token	`completion_tokens_details.image_tokens`	→ `output_cost_per_token`
`video_input_cost_per_token`	每百万 token	`prompt_tokens_details.video_tokens`	→ `input_cost_per_token`
`output_cost_per_reasoning_token`	每百万 token	`completion_tokens_details.reasoning_tokens`（思考 token）	→ `output_cost_per_token`
`cost_per_web_search_request`	每千次请求	`prompt_tokens_details.web_search_requests`	无 fallback，未配置时按 0 计

注意

cost_per_web_search_request 是唯一没有 fallback 的维度。当一个新接入的模型支持 web search 但忘了配这一项时，平台会静默不计费。接入新模型时务必核对这一条。

计费算法（按类目）

每一次调用的账单由 _calculate_fixed_cost 计算，输入 / 输出两侧独立累加。流程按以下顺序处理，每一步从总量里"挖出"对应类目再按单价结算，剩余的 text / 未归类 token 按基础价兜底。

输入侧

音频（audio_tokens × audio_input_cost_per_token 或 fallback）
缓存读（cached_tokens × input_cost_per_cached_token 或 fallback）
缓存写
- 若有 5m / 1h 分桶（Anthropic 新版）：
  - ephemeral_5m_input_tokens × cache_creation_input_token_cost 或 fallback
  - ephemeral_1h_input_tokens × cache_creation_input_token_cost_above_1hr 或 fallback
- 否则：cache_creation_tokens × cache_creation_input_token_cost 或 fallback
视频（video_tokens × video_input_cost_per_token 或 fallback）
图像（image_tokens × image_input_cost_per_token 或 fallback）
网页搜索（web_search_requests × cost_per_web_search_request，未配置则为 0）
文本（text_tokens × input_cost_per_token）
未归类兜底：remaining = prompt_tokens - (text + audio + cached + cache_creation + video + image)，若 > 0 按 input_cost_per_token 计。部分上游（如 Gemini）返回的 text_tokens 不覆盖所有类目，兜底确保整体总量完整计费。

输出侧

图像（image_tokens × image_output_cost_per_token 或 fallback）
音频（audio_tokens × audio_output_cost_per_token 或 fallback）
思考 token（reasoning_tokens × output_cost_per_reasoning_token 或 fallback）
文本（text_tokens × output_cost_per_token）
未归类兜底：remaining = completion_tokens - (text + audio + reasoning + image)，若 > 0 按 output_cost_per_token 计。

fallback 不等于少收

很多模型不区分 audio/image/text 价格（上游就是同一档），此时 audio_input_cost_per_token 是 null，算法回退到 input_cost_per_token——这是正确的账单，不是漏计。只有 cost_per_web_search_request 未配置时才会真正漏计。

分阶梯计费（tiered pricing）

部分模型按输入 token 规模分档，典型如：

Gemini 2.5 Pro / 3 Pro / 3.1 Pro：≤ 200K 档 vs > 200K 档，单价翻一倍左右。
Claude Sonnet 4 / 4.5：≤ 200K vs > 200K，输入 / 输出 / 缓存三组单价整体翻倍。
Zhipu GLM / Doubao / Qwen3 系列：多档组合（输入 × 输出二维）。

选档算法（见 PricingTier.matches）：

按 tiers 顺序匹配，命中第一个就用该档的单价覆盖基础单价计费。
两种匹配模式：
- INPUT_OUTPUT：min_input_tokens ≤ input_tokens < max_input_tokens 且 min_output_tokens ≤ output_tokens < max_output_tokens 同时成立。
- CONTEXT_WINDOW：input + output 落在窗口区间内（少用）。
都没命中走 fallback_*_cost_per_token。

命中哪档要看 output

分阶梯按的是本次请求的 input + output token，不是历史累计。一次输入 190K 但模型生成 20K 输出的请求，仍会命中"输入小于 200K"那一档。

从响应里读用量

所有 LLM 接口都支持 turing_options.include_service_usages: true，开启后响应里会多出一个 service_usages 数组。

curl $TURING_BASE_URL/chat/completions \
  -H "Authorization: Bearer $TURING_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "turing/claude-sonnet-5",
    "messages": [{"role": "user", "content": "hello"}],
    "turing_options": {"include_service_usages": true}
  }'

响应片段：

{
  "choices": [...],
  "usage": {
    "prompt_tokens": 11,
    "completion_tokens": 5,
    "prompt_tokens_details": {
      "text_tokens": 11,
      "cached_tokens": 0
    }
  },
  "service_usages": [
    {
      "deployment_name": "turing/claude-sonnet-5",
      "service_name": "claude-sonnet-5",
      "service_provider": "turing",
      "usage_unit": "tokens",
      "usage_amount": 16,
      "usage_detail": {
        "usage_type": "tokens",
        "prompt_tokens": 11,
        "completion_tokens": 5,
        "prompt_tokens_details": { "text_tokens": 11 },
        "completion_tokens_details": { "text_tokens": 5 }
      },
      "bill_amount": 0.00018,
      "bill_currency": "USD",
      "time_stats": { "duration_ms": 812 }
    }
  ]
}

关键字段：

usage_detail.prompt_tokens_details / completion_tokens_details：每个计费类目的 token 明细，字段与计费维度速查表的"对应计数器"列一一对应。
bill_amount：平台按上述算法重算的金额。权威账单以此为准。
bill_currency：USD 或 CNY，由模型配置决定（见币种与区域）。
time_stats：延迟统计（可选）。

多次服务调用（如一次请求中 LLM + web search + 预处理模型同时触发）会产生多条记录，按服务分组。

对账接口

持久化的账单可以通过 trace 接口回查，适合离线对账、用量统计、成本追溯。

端点：GET /api/v1/trace/{trace_id}/billing

trace_id 由响应 header x-turing-trace-id 返回，同时记录在每次调用的日志里。

curl -X GET $TURING_BASE_URL/trace/trace_abcdef/billing \
  -H "Authorization: Bearer $TURING_API_KEY"

响应体是 list[ServiceUsage]，字段与上面 service_usages 内联返回的完全一致。差别在于：

对账接口持久存储，不依赖客户端开 include_service_usages 标记即可查询。
查询时间窗口对齐后端 tracing 策略，建议对关键业务在调用完成后 ≥ 2 秒再查询（确保写入已完成）。

bill_amount 是权威账单

上游厂商返回的 x-litellm-response-cost header 只用于内部观察，不作为客户账单。ServiceUsage.bill_amount 是唯一对外暴露的计费数字。

厂商相关注意事项

Claude：显式缓存控制

Anthropic 的缓存是调用方主动声明的：在 messages 或 system 的某个 content block 上加 cache_control: {"type": "ephemeral"} 才会写入缓存，下一次命中后按 input_cost_per_cached_token 读出。

缓存写比基础输入贵（Sonnet 4.6: 写 $3.75/M vs 读 $0.3/M vs 基础输入 $3/M），单次不划算；只有在被命中 ≥ 2 次时才开始回本。
4.6 / 4.7 起 Anthropic 新增 1 小时 TTL，单价再贵一档（cache_creation_input_token_cost_above_1hr），用于长时间维持的 context，典型场景是多轮 agent 会话。
详见 Prompt 缓存 (Claude)。

Claude：web_search 工具

Claude 在 Vertex 上的网络搜索通过 tools: [{"type": "web_search_20250305", ...}] 启用。搜索次数写在响应的 usage.server_tool_use.web_search_requests 字段里，平台内部会 lift 到 prompt_tokens_details.web_search_requests 并按 cost_per_web_search_request = $10/1K 计费。

适用模型以模型列表 → Claude 中的 Web Search / 内置工具标记为准。
/v1/messages 与 /v1/chat/completions 两条路径定价一致，响应里都能看到 usage.server_tool_use.web_search_requests。
工具参数 max_uses 可上限调用次数；Sonnet 复杂任务下单轮见过 20+ 次搜索，生产环境建议显式设置。
详见模型内置 Web Search。

Gemini：googleSearch grounding

Gemini 在 Vertex 上的 grounding 通过 tools: [{"googleSearch": {}}] 启用。搜索次数写在响应顶层的 vertex_ai_grounding_metadata 数组里（每一项一次 grounding 调用），平台内部会 lift 到 prompt_tokens_details.web_search_requests 并按 cost_per_web_search_request = $14/1K 计费。

Pro / Flash / Lite 全线统一 $14/1K。
max_uses 等工具参数可以进一步限制调用次数以控费。
详见模型内置 Web Search。

OpenAI / DeepSeek / Gemini / Doubao：隐式自动 prompt caching

非 Claude 系的主流模型(GPT-4o / GPT-5.x、DeepSeek V4、Gemini 2.5/3.x Pro、Doubao 1.6+ 等)在上游自动对请求间的公共前缀做缓存,无需客户端开关。命中的 cached_tokens 会直接出现在 usage.prompt_tokens_details.cached_tokens,按 input_cost_per_cached_token 计费(OpenAI 5.x 系约 10%、4.x 系约 25-50%;DeepSeek / Gemini 约 20%)。

不需要 cache_control 参数,也无写入费用。
最小命中长度因厂商而异(DeepSeek 256 tokens、OpenAI / Gemini 约 1,024 tokens)。
TTL 由上游平台动态管理,客户端不可控。
完整的模型列表与单价见 Prompt 缓存。

思考 token（reasoning tokens）

思考型模型（OpenAI o1/o3/o4/GPT-5 推理、Claude 的 adaptive thinking、DeepSeek R1、Qwen 思考版）生成的思考过程默认按 输出 token 计费，且与可见输出一起占用 max_tokens。

若模型配了 output_cost_per_reasoning_token（多数 OpenAI 推理模型、DeepSeek R1），思考部分按该单独单价计；否则 fallback 到 output_cost_per_token。
Claude adaptive thinking 下，thinking.display: "omitted" 不会节省 token，只影响是否在响应里回显思考正文（见思考模型配置）。

币种与区域

bill_currency 只有两种值：

币种	覆盖 provider
`USD`	OpenAI、Azure、Anthropic、Google Vertex、AWS Bedrock 等全球 / 海外厂商
`CNY`	阿里 Qwen、智谱 GLM、字节豆包、腾讯混元、讯飞星火、百度、中国移动九天等国内厂商

币种由模型配置的 currency 字段决定，调用方无需显式指定；跨币种的账单汇总会按日汇率换算到 USD 做累计（见 budget 相关 API）。

常见误区

"Claude 缓存一定省钱"：写成本是基础价的 1.25 倍左右，读是 0.1 倍。若某段 context 只被读 1 次就扔掉，反而贵。经验值：同一段 context 至少被 2 次请求命中时开启缓存才划算。
"fallback 到 text 单价 = 漏计"：大多数 provider 音频 / 图像 / 文本一个价，fallback 是预期行为。只有 cost_per_web_search_request 是真正的 silent-zero。
"web search 无上限成本"：每次对话可能触发多次搜索，单次请求 max_uses 不设上限时，Sonnet + 复杂任务下见过 20 + 次搜索。生产环境务必设置 max_uses。
"上游 cost header 就是账单"：图灵后端自己算账，不信任上游 header。若发现 bill_amount 与预期偏差，先核对 usage_detail 里的计数器。

扩展阅读

Chat Completions 接口 — OpenAI 兼容的主入口
OpenAI Response API — GPT-5 系列的新响应协议
Anthropic Messages 接口 — Claude 原生协议
模型内置 Web Search — googleSearch / web_search_20250305 等搜索能力
Prompt 缓存 (Claude) — 缓存的触发、命中、回本计算
思考模型配置 — reasoning / thinking 的启用和计费
模型价格清单 — 每个模型的具体单价

计费维度速查表​

计费算法（按类目）​

输入侧​

输出侧​

分阶梯计费（tiered pricing）​

从响应里读用量​

对账接口​

厂商相关注意事项​

Claude：显式缓存控制​

Claude：web_search 工具​

Gemini：googleSearch grounding​

OpenAI / DeepSeek / Gemini / Doubao：隐式自动 prompt caching​

思考 token（reasoning tokens）​

币种与区域​

常见误区​

扩展阅读​