如何读懂按令牌计费的价格表：逐步核算输入、输出与缓存成本
读懂模型价格表，关键不是寻找最小的数字，而是确认这个数字对应什么单位、哪些令牌，以及什么使用条件。下面按照实际核算顺序，把价格表转换成可以检查的单次请求费用。
§ 第一步：先确认计价单位
先看表头或价格说明，确认报价是每千令牌、每百万令牌，还是其他单位，同时核对币种。每百万令牌的价格不能直接乘以令牌数量，必须先除以一百万。
令牌是模型处理文本的计量单位，不等于汉字数、英文单词数或字符数。同一段文字经过不同模型的分词方式处理，数量可能不同。预算可以先估算，结算核对则应使用实际用量记录。
§ 第二步：分开阅读输入价与输出价
输入通常包括发送给模型的系统指令、用户内容、历史对话，以及工具返回的信息；输出则是模型生成的内容。两类令牌可能采用不同单价，不能把总令牌数全部乘以输入价。
基础费用＝输入令牌数÷计价单位×输入单价＋输出令牌数÷计价单位×输出单价。这里的“计价单位”，在每百万令牌报价下就是一百万。若存在缓存或其他单列项目，还需要继续拆分。
§ 第三步：用一条请求验证公式
假设某个模型的输入价为每百万令牌二美元，输出价为每百万令牌八美元。一次请求使用一万二千个输入令牌，并生成一千五百个输出令牌，则计算如下：
- 输入费用：12000÷1000000×2＝0.024 美元。
- 输出费用：1500÷1000000×8＝0.012 美元。
- 合计费用：0.024＋0.012＝0.036 美元。
以上数字仅用于演示，不代表 Vana API 的当前报价。这个例子也说明：输出数量较少，不代表输出成本可以忽略，仍需结合对应单价计算。
§ 第四步：有缓存时，检查是否需要拆账
如果价格表列出了缓存读取、缓存写入或类似项目，先阅读适用条件。重复发送相同内容，并不自动等于命中缓存；是否命中，应以接口返回的用量明细或可核对的账单记录为准。
例如，一万二千个输入令牌中，有一万个被记录为缓存读取，那么核算时应区分普通输入与缓存读取。若两者采用互斥分类，就不能既按全部输入收取普通输入费，又把缓存读取费重复加上。缓存写入是否另计、如何计价，也要按具体说明确认。
§ 第五步：检查价格适用条件
看到同一个模型名称后，还要检查是否存在上下文长度分档、不同处理模式或其他价格条件。不要默认所有请求都适用表格中最醒目的那一档。
- 确认调用的模型标识与所查价格行一致。
- 确认长上下文是否影响输入价或输出价。
- 如用量中出现推理、工具或多模态相关项目，核对它们是否已包含在某项费用内。
- 记录核价日期，避免用旧报价解释新请求。
§ 第六步：用真实任务比较模型
比较 Gemini 2.5 Flash 与 DeepSeek V4 Flash 时，不宜只比较输入单价。相同任务可能产生不同长度的回答，也可能需要不同次数的重试。更有用的指标是：得到一份符合要求的结果，实际花了多少钱。
可以准备一组固定任务，分别记录输入量、输出量、缓存情况、费用和结果是否合格。对于多轮对话，还应检查客户端是否每次重发历史消息；对话越长，后续请求的输入量越可能增加。
§ 第七步：把单次费用换算成日常预算
先测出有代表性的平均请求费用，再乘以预计调用次数。例如，平均每次费用为 0.036 美元，每天一千次请求，对应的估算就是每天三十六美元。若任务差异较大，应将短问答、长文生成和多轮工具调用分别估算，而不是共用一个平均值。
Vana API 按实际令牌用量计费，没有月费，因此阅读价格表时，应把关注点放在真实用量及其对应费率上。你可以创建一个 Vana API 账户，先用少量代表性请求检查用量记录，再决定日常预算。
最后复核四件事：单位是否一致，输入输出是否分开，缓存是否正确归类，适用条件是否匹配。把这四项核对清楚，价格表就能成为预算工具，而不只是一组看起来很低的数字。