pricepertoken.com

Anthropic（Claude）API 按 token 计费，核心规则是：输入 token 和输出 token 分开计价，输出单价通常明显高于输入；缓存写入和缓存读取各自是独立价格档位，命中缓存能大幅压低重复上下文的成本。 估算自己的账单时，不能只记一个"每百万 token 多少钱"，而要按"输入量 × 输入单价 + 输出量 × 输出单价 + 缓存写入量 × 缓存写入单价 + 缓存读取量 × 缓存读取单价"分开算。适用前提是你已经确定要用哪个 Claude 模型档位——Haiku、Sonnet、Opus 之间的单价差距很大，选错档位比算错公式影响更大。

三个计费维度：输入、输出、缓存

Anthropic 的账单结构可以拆成四类 token 事件：

关键机制在于：输出 token 的单价高于输入 token，所以"让模型少说废话"和"让模型多读资料"对成本的影响方向相反。一个只输出 200 token 但读了 5 万 token 上下文的请求，和一个输出 5 千 token 的请求，谁更贵取决于具体单价，必须分开算。

缓存则是为重复使用的长上下文设计的。比如你把一份 3 万 token 的产品文档作为系统提示反复调用，第一次是缓存写入（较贵），之后每次命中缓存读取（便宜很多）。如果同一段上下文只用一次，缓存反而增加成本。

不同 Claude 档位单价差异大，先选模型再算钱

Anthropic 的模型按能力分档（如 Haiku、Sonnet、Opus），档位越高单价越贵。这意味着：

• 分类、抽取、简单问答这类任务，用低档模型往往够用，单价低一个量级。
• 复杂推理、长文写作、代码生成才需要高档模型。
• 同一个应用里可以混用：简单请求走便宜档，复杂请求走贵档，整体成本能显著下降。

所以正确的顺序是：先按任务难度选模型档位，再拿该档位的单价去套公式，而不是先算总价再纠结模型。

怎么核对最新单价

Anthropic 的官方定价页是权威来源，单价会随新模型发布调整。第三方对比站可以作为交叉核对，例如 pricepertoken.com 这类站点汇总了 OpenAI、Anthropic、Google、Mistral 等多家 API 的 token 单价，并标注"Updated daily with official prices"，适合快速横向比较。使用时注意两点：

• 对比站的数据有更新日期（该站页面显示 "Last updated: October 4, 2026"），核对时看清时效。
• 缓存写入、缓存读取这类细分档位，以官方文档为准，对比站不一定完整覆盖。

按自己的用量套公式估算

拿到单价后，用你真实的月均用量估算：

月成本 ≈
  月输入 token 量   × 输入单价
+ 月输出 token 量   × 输出单价
+ 月缓存写入量     × 缓存写入单价
+ 月缓存读取量     × 缓存读取单价

举例：假设某档模型输入单价为每百万 token X 元、输出为每百万 token Y 元（Y 通常大于 X）。若你每月发送 200 万输入 token、生成 50 万输出 token，且没有用缓存，成本就是 2X + 0.5Y。如果其中 150 万输入 token 是重复的长上下文并命中缓存，那部分就从输入单价换成更低的缓存读取单价，总成本随之下降。

估算时预留两块波动：

• 缓存命中率不稳定：上下文改动、请求间隔过长都可能导致缓存失效，退回按普通输入计价。
• 长上下文放大输入量：把整份文档塞进每次请求，输入 token 会成倍增长，这是最常见的超支来源。

常见卡点

• 只记一个单价：把输入和输出当成同价，估算必然偏差。
• 忽略输出占比：对话类应用输出往往比预期多，输出单价高时影响明显。
• 缓存用错场景：一次性上下文开缓存只增加写入成本，不省钱。
• 用过时单价：模型迭代快，几个月前的数字可能已失效，务必核对更新日期。

OpenAI API 按 token 计费，一次请求的成本由三部分构成：输入 token、输出 token、缓存输入 token，三者单价不同，必须分开看。估算月成本的基本公式是：输入 token 数 × 输入单价 + 输出 token 数 × 输出单价，命中缓存的输入部分按更低的缓存单价计算。适用条件是：你能拿到自己的实际调用量（token 数），并且以官方最新价目为准——价格会随新模型发布和官方调整变化。

三个计费项分别是什么

关键机制：缓存只作用于输入中重复的部分，输出永远按输出单价算。所以“把长文档塞进上下文反复提问”这类用法，缓存收益最明显；而“每次都要模型生成大段新内容”的用法，成本主要压在输出上。

怎么估算自己的月成本

1. 取实际 token 量：从调用日志或用量面板拿到每类 token 的累计数（输入、输出、缓存命中分别统计）。
2. 乘对应单价：分别乘以输入、输出、缓存输入的单价，再相加。
3. 乘调用次数或按周期汇总：单次成本 × 月调用量，得到月成本区间。
4. 验证：用一周的真实数据外推一个月，比拍脑袋估更可靠；注意区分测试流量和线上流量。

例如需要做一个每天处理 500 次问答的客服机器人：如果每次输入约 2000 token、输出约 300 token，且系统提示词固定不变（可命中缓存），那么成本主要由“输入 × 500”和“输出 × 500”决定，缓存部分能压掉固定提示词那一段的输入开销。

不同模型单价差距很大，按任务选型

同一家厂商的不同模型，单价可以差出数量级。以 pricepertoken.com 收录的数据为例（页面标注最后更新于 2026 年 10 月 4 日）：

• OpenAI gpt-oss-20b：输入 $0.018 / 输出 $0.090 / 缓存输入 $0.003（每百万 token 量级）
• OpenAI gpt-oss-120b：输入 $0.030 / 输出 $0.100 / 缓存输入 $0.0045

可以看到，同系列里更大的模型单价更高，但差距不是线性的。选型逻辑是：简单分类、抽取、改写用便宜的小模型；需要推理、长上下文理解、复杂工具调用的任务再上更贵的模型。不要用旗舰模型跑所有请求，这是最常见的成本浪费。

和 Anthropic、Google、DeepSeek 等横向比

比价时要用相同维度：同一类 token（输入对输入、输出对输出、缓存对缓存），而不是只比一个“起价”。pricepertoken.com 这类聚合站的价值就在于把 300+ 模型的输入、输出、缓存单价放在同一张表里，并支持按能力筛选（工具调用、视觉、推理、缓存、开源等）。

对比时注意三点：

• 上下文长度不同，长文档场景要确认模型是否支持你需要的窗口。
• 能力标签（如是否支持缓存、工具调用）直接影响实际可用成本，便宜但不支持缓存的模型在重复上下文场景未必更省。
• 更新频率：聚合站标注“每日更新、来自官方价格”，但下单前仍应回官方价目核对一次。

常见卡点

• 只算输入不算输出：输出单价往往更高，长回答场景会严重低估成本。
• 忽略缓存命中率：固定系统提示词、固定知识库前缀如果不走缓存，等于白付高价输入。
• 拿旧价格做预算：新模型发布和官方调价都会改变单价，用前核对最新官方价目。
• 把测试量当线上量：小规模测试的单价感受和真实并发下的月账单差距很大。

价格与登录限制以官方和聚合站页面为准，未标注免费的项目不应默认免费。

Google AI(Gemini)API 的成本由三类 token 单价叠加而成:输入 token、输出 token 和缓存输入 token。要估算一次调用的费用,你需要分别拿到这三个单价,再乘以对应的 token 数量——输出单价通常高于输入,缓存输入单价通常低于普通输入。适用条件:你已经在用或准备接入 Gemini API,想在下单前把成本算清楚,或者想拿它和 OpenAI、Anthropic 等模型做横向比较。

三类 token 分别是什么

关键点在于:一次调用的账单不是"一个单价 × 总 token",而是三类分别计价后相加。只盯着输入单价做对比,很容易得出错误结论。

怎么算一次调用的成本

用统一公式,把三类分开:

总成本 = 输入token数 × 输入单价
       + 输出token数 × 输出单价
       + 缓存输入token数 × 缓存单价

举例说明:假设某次请求有 10,000 个输入 token、2,000 个输出 token,其中 8,000 个输入 token 命中缓存。你需要分别查这三个单价(通常以"每百万 token"为单位),再按上面的公式相加。注意缓存命中的那部分输入,不应再按普通输入单价重复计费。

验证方法:先用一次真实调用记录实际 token 用量,再套公式算一遍,和账单或用量面板对一下,确认三类单价取值正确。

为什么不能只看一个数字

• 输入和输出单价不同:输出往往更贵,所以"回答很长"的任务,成本可能主要来自输出而非输入。
• 缓存单价单独一档:如果你的应用反复发送同一段系统提示或长文档,缓存输入能明显压低这部分成本;但如果每次上下文都不同,缓存几乎用不上。
• 模型档位差异大:同一家厂商的 Flash 系列和 Pro 系列单价不在一个量级,选型时先按用途定档位,再比价格。

和 OpenAI、Anthropic 横向比的方法

要公平比较,必须用同一套维度,而不是各取一个"起价":

1. 同一计费项对同一计费项:输入比输入,输出比输出,缓存比缓存。
2. 统一单位:都换算成"每百万 token 单价"再比。
3. 带上上下文窗口:窗口大小决定你能塞多少内容,直接影响可用场景。
4. 结合任务需求:需要推理、工具调用、视觉、长文档的,先筛能力,再比价格。

像 pricepertoken.com 这类聚合站会把多家厂商的输入、输出、缓存单价和上下文窗口放在同一张表里,并标注 Tool Use、Vision、Reasoning、Caching 等能力标签,适合做初筛;但最终仍建议回到各厂商官方定价页核对,因为聚合数据可能滞后。

常见卡点

• 把缓存输入当成免费:缓存单价低不等于零,仍要计入。
• 忽略输出占比:只按输入单价估算,长回答任务会严重低估。
• 拿不同档位对比:用 A 家的轻量模型比 B 家的旗舰模型,结论没有意义。
• 忘记单位:有的页面按每千 token,有的按每百万 token,换算错一位就是 1000 倍误差。

结论

算 Google AI(Gemini)API 成本,核心就三步:分清输入、输出、缓存输入三类 token;分别取单价;按公式相加。做横向对比时,坚持同项对同项、同单位、同能力档位,再结合上下文窗口和任务需求判断性价比。价格会随模型版本更新,下单前以官方定价页为准。

翻译 API 是把机器翻译能力封装成接口，让程序直接调用并拿到译文。它适合需要把翻译嵌进产品流程的场景，比如网站多语言、App 内实时翻译、批量文档处理；如果只是偶尔翻译几句话，直接用网页版工具更省事。选型时主要看四点：语言覆盖、能否离线部署、费用模式、数据是否离开自己的服务器。

翻译 API 在做什么

调用一次翻译 API，通常就是三步：

1. 输入：把待翻译文本（或文件）和源语言、目标语言发给接口。
2. 动作：服务端运行机器翻译模型，生成译文。
3. 预期结果：接口返回译文，程序可以直接展示、存储或继续处理。

以 LibreTranslate 的页面为例，它同时提供网页界面和 API：界面上有“翻译文本”“翻译文件”“翻译为”等入口，支持上传文件并下载译文，也展示“请求/响应”结构。这说明翻译 API 的典型形态就是——你发一段文本或一个文件，它回一段译文。

常见用途

• 网站/App 多语言：用户切换语言时，前端把界面文案或用户内容发给翻译 API，实时替换。
• 文档批量翻译：把一批文件提交给接口，拿回译文后统一入库或分发。
• 实时翻译：聊天、客服、评论等场景，边输入边翻译。
• 内容本地化流水线：把翻译 API 接进已有的发布流程，减少人工搬运。

这些场景的共同点是：翻译要发生在程序里，而不是靠人手动复制粘贴。

自建开源 API 与调用商业 API 的区别

LibreTranslate 页面明确写到“开源的机器翻译 API，可自由下载、支持离线运行且部署简便”。如果你的内容敏感、要求数据不出内网，或者希望不依赖外部服务，自建是更合适的方向；如果更看重开箱即用和语言覆盖，商业 API 往往更省事。费用和登录限制在给定资料中没有说明，不能默认免费或无需登录，需要到对应服务确认。

选择翻译 API 时看什么

• 语言支持：先确认源语言和目标语言是否覆盖，尤其是小语种。
• 离线部署：数据不能外发时，优先选支持离线运行的开源方案。
• 费用模式：按字符、按请求还是订阅，直接决定长期成本。
• 隐私与合规：文本是否会离开你的服务器，是否有留存策略。
• 接入成本：接口是否简单、是否支持文件、是否有请求/响应示例可参考。

如何快速搭建或接入

自建（以 LibreTranslate 为例）：页面提供“下载”入口，说明可自由下载并离线运行，部署只需数分钟即可搭建专属 API 服务。具体安装命令、端口和参数在给定资料中没有展开，需要以官方文档为准。

接入已有 API：一般流程是——拿到接口地址和密钥（如有）→ 按文档构造请求，带上待翻译文本和目标语言 → 解析返回的译文 → 在业务里使用。LibreTranslate 页面展示了“请求/响应”的对应关系，可以作为理解接口输入输出的参考。

验证方法：先用一句已知答案的短句测试，确认返回语言正确、编码正常；再测一个文件，确认上传和下载流程可用。

常见卡点：语言代码写错导致译文语言不对；文本过长超出单次限制；文件格式不被支持（页面会提示“支持的文件格式”）；自建时模型未加载完整导致翻译失败。

一句话结论

翻译 API 解决的是“让程序自己完成翻译”这件事。要数据可控、能离线，选自建开源方案；要省事、语言覆盖广，选商业 API。先明确你的语言需求和数据边界，再决定用哪种。

LLM API 的账单不是按"每次调用"算的，而是按 token 分项计价：输入 token、输出 token、缓存输入 token 各有单价，同一模型这三项可能相差几十倍。要判断一个模型贵不贵，先看你的调用里输入和输出各占多少，再拿对应单价去乘。下面按"计费项 → 横向对比 → 估算月费 → 避坑"的顺序讲清楚。

三类计费项，先分清再比价

以价格页上的数据为例，DeepSeek 的 deepseek-v4.1-flash 输入 $0.003、输出 $0.180、缓存输入 $0.0028（每百万 token）——输出单价是输入的 60 倍。而 deepseek-chat 输入 $0.014、输出 $0.028，输出只有输入的 2 倍。这说明"哪个模型便宜"没有统一答案，取决于你的输入输出比例。

判断方法：如果你的场景是长文档问答（输入巨大、输出很短），输入单价权重高；如果是内容生成（输入短、输出长），输出单价才是主要成本。

按每百万 token 单价横向对比

价格页把主流提供商的模型放在同一张表里，按输入单价从低到高排列。以下是页面中出现的部分模型（单位：美元/百万 token）：

几个值得注意的点：

• 输入为 $0.000 不等于完全免费。这类模型往往靠缓存输入或其他方式计费，且能力指标（如 GPQA）差异很大，不能只看价格。
• 上下文窗口和价格不成正比。deepseek-v4-flash 有 1.0M 上下文且输入标价 $0.000，而 nova-micro-v1 只有 128K 却要 $0.035。窗口大不代表贵，但大窗口模型处理长输入时总 token 数会更高。
• 缓存输入单价普遍低于普通输入，适合有固定系统提示词或重复上下文的场景。

估算你自己的月度费用

公式很简单：

月费 ≈ (月输入 token 数 × 输入单价) + (月输出 token 数 × 输出单价) + (缓存命中 token 数 × 缓存单价)

具体步骤：

1. 统计一次典型调用的平均输入 token 和输出 token（可用 tokenizer 或 API 返回的 usage 字段）。
2. 乘以日均调用次数，得到日 token 量，再乘 30 得月量。
3. 换算成"每百万 token"单位，套用上表单价。

举例：假设某客服机器人每天 5000 次调用，每次输入 2000 token、输出 300 token。

• 月输入 = 5000 × 2000 × 30 = 3 亿 token = 300 百万
• 月输出 = 5000 × 300 × 30 = 4500 万 token = 45 百万

用 deepseek-chat（输入 $0.014、输出 $0.028）：300 × 0.014 + 45 × 0.028 = $4.2 + $1.26 = $5.46/月

用 deepseek-v4.1-flash（输入 $0.003、输出 $0.180）：300 × 0.003 + 45 × 0.180 = $0.9 + $8.1 = $9.0/月

输入输出比例一变，便宜的模型就换了。这就是为什么必须按自己的场景算，而不是看排行榜。

用能力筛选缩小候选范围

价格页支持按能力过滤，包括：工具调用（391 个模型）、视觉（212）、推理（126）、网页搜索（107）、PDF 输入（99）、缓存（210）、音频输入（26）、开源（294）。

用法：先确定你的硬性需求（比如必须支持工具调用 + 缓存），筛掉不满足的模型，再在剩下的里比价格。否则容易选到单价极低但缺少关键能力的模型，返工成本远高于省下的 token 费。

常见卡点

• 只看单价忽略能力：$0.000 的模型可能在 MMLU、GPQA 等指标上明显偏低，任务复杂时错误率上升，实际成本反而更高。
• 用过期报价做决策：价格页标注"Last updated: October 4, 2026"，并注明价格来自 OpenAI、Anthropic 等官方渠道、每日更新。模型价格变动频繁，决策前应回到来源页确认当前数字。
• 忽略缓存收益：有重复上下文的场景，启用缓存后输入成本可显著下降，选型时应把"是否支持缓存"纳入考量。
• 混淆上下文窗口与计费：窗口大意味着单次能塞更多 token，但每个 token 都要付费，长上下文场景要单独估算。

一句话选择逻辑

输入为主、追求低单价 → 看输入列最低且支持缓存的模型；输出为主 → 重点比输出单价；需要工具调用/视觉/推理 → 先用能力筛选，再在候选里比价。任何情况下，都用自己的输入输出比例套公式算一遍，而不是直接抄排行榜。