模型定价
AISIX Cloud 控制面根据观测到的用量以及上游模型服务提供方和模型对应的价格计算请求成本。大多数模型按 Token 数计费；按时长计费的模型则按音频时长计价。当模型没有目录价格，或组织采用不同费率时，可以配置价格覆盖项。
定价会影响 Usage 中显示的支出和 AISIX Cloud 预算评估的总额。提示词和补全费率也会影响使用 least_cost 路由组时的目标顺序。定价不会改变上游模型服务提供方实际收取的费用。
AISIX 如何解析价格
AISIX 会直接应用配置费率，不添加隐藏乘数。每个用量事件都会按精确的 (provider, model name) 组合解析价格：
- 与服务提供方和模型名称匹配的组织覆盖价格优先。
- 否则，AISIX 使用 models.dev 中匹配的目录默认价格。
- 如果两者都不匹配，用量事件会保留上报的用量，但将支出记录为
$0.00。
目录刷新行为取决于定价同步的配置方式。在线模式下，控制面会在启动时以及每 24 小时刷新目录。默认情况下，On-Premises Docker Compose 软件包即使可以访问互联网，也会在启动时加载内置目录快照。若要为该软件包启用在线同步，请参阅价格目录。
对于匹配的价格，AISIX 会分别计算 Token 成本和时长成本，再将两者相加。Token 定价使用提示词和补全费率，并采用下文所述的缓存和推理回退规则。只有当事件上报了音频时长且 Audio per minute 不为零时，才会计入时长成本。
成本在记录用量事件时计算，并与事件一起保存。修改价格只影响修改后记录的事件，不会重新计算历史事件的价格。
推理 Token 如何计费
上游统计推理 Token 的方式有两种。例如 OpenAI 把推理计入 completion_tokens， 再单独标出其中的推理部分；而 Vertex AI 适配器上的 Gemini 可能把思考 Token 报告在补全之外。用量事件按上游上报的原样保存这些计数，因此控制面会针对每个事件，依据上游自己上报的总数（total_tokens）判断适用哪种口径：
- 推理在补全之外。 当
total_tokens和reasoning_tokens都大于零，且total_tokens等于提示词 + 补全 + 推理 Token 之和、而不等于提示词 + 补全 Token 之和时适用。此时全部completion_tokens按补全费率计费，全部reasoning_tokens按推理费率计费。 - 推理在补全之内。 其他所有事件（包括所有没有上报总数的事件）都按这种方式计价：
reasoning_tokens按推理费率计费，completion_tokens的剩余部分（不低于零）按补全费率计费。因此，上报的推理多于补全的上游，只按其上报的推理 Token 计费，不会多收。
无论哪种口径，没有单独推理费率的模型都按补全费率计算推理 Token。例如，下面两个事件都是 20 个 Token 按补全费率、30 个 Token 按推理费率计费：
| 上游 | 提示词 | 补全 | 推理 | 上报总数 | 口径 |
|---|---|---|---|---|---|
| Vertex AI 上的 Gemini | 100 | 20 | 30 | 150 | 推理在补全之外 |
| OpenAI | 100 | 50 | 30 | 150 | 推理在补全之内 |
缓存输入同样按上报原样记录。当 cached_prompt_tokens 超过 prompt_tokens 时，未缓存输入按零计费，而不会出现负数。
1.4.0 及更早版本的网关不上报 total_tokens，因此其事件按第二条规则计价，与以前完全一致。在更新版本的网关上，/v1/messages 和 /v1/completions 会像 /v1/chat/completions 一样记录 reasoning_tokens 和 total_tokens，因此到达这两个端点的推理 Token 会按模型的推理费率计费。1.4.0 及更早版本的网关在这两个端点上不记录推理计数。各计数的含义请参阅记录的 Token 计数。
识别缺失的价格
先在请求日志中展开事件。请求日志会以六位小数显示每个用量事件或路由尝试的成本；聚合 Usage 视图会把支出四舍五入到两位小数，并且只显示前 10 个环境/模型组合。因此，看到 $0.00 或模型未出现在 Usage 中，并不能证明定价缺失。对于价格很低的请求，应产生足够的 Token 用量后再判断。
以下情况可能缺少目录价格：
- 模型运行在 models.dev 未定价的自托管或转售商上游中。
- 配置的模型名称是自定义别名。
- 服务提供方提供了较新的模型，但目录尚未在该服务提供方名下收录该模型。
添加覆盖项前，请准确记录模型配置中的服务提供方和模型名称。任一值不同，定价行都不会匹配用量事件。
添加价格覆盖项
- 从组织导航中打开 Model pricing。
- 选择 Add pricing。
- 按模型配置中的值准确填写 Provider 和 Model name。成本会按这一服务提供方与模型名称组合匹配用量事件，因此不匹配的值不会生效。Provider 字段会建议已知目录服务提供方，但也可以输入任意值，包括自定义值。
- 根据服务提供方的计费依据进行配置：
- 对于按 Token 计费的模型，输入每 1M Token 的 USD Prompt 和 Completion 费率，并将 Audio per minute 保持为
0。 - 对于按时长计费的语音转文本模型，将 Token 费率保持为
0，并输入以 USD/音频分钟为单位的 Audio per minute 费率，例如0.006。
- 对于按 Token 计费的模型，输入每 1M Token 的 USD Prompt 和 Completion 费率，并将 Audio per minute 保持为
- 对于按 Token 计费的模型，可选：分别设置 Cache read、Cache write 和 Reasoning 费率。
- 保存覆盖项。
缓存或推理费率为 0 表示没有设置独立费率：缓存 Token 回退到提示词费率，推理 Token 回退到补全费率。
为按音频时长计费的模型定价
部分语音转文本模型按音频分钟计费，而不是按 Token 计费，并且不会上报 Token 数。此类请求会改为记录音频时长，并使用 Audio per minute 费率将时长换算为支出。如果此费率保持为 0，模型不会产生基于时长的成本。
当前 AISIX 定价目录不提 供时长费率，因此没有可继承的默认值：请使用与模型配置完全一致的服务提供方和模型名称创建定价行。例如，OpenAI 目前列出的 whisper-1 价格为每分钟 $0.006。按此费率，60 秒的转录成本为 $0.006。
Token 成本和时长成本会相加。如果事件同时包含 Token 用量和音频时长，并且匹配价格中的两类费率均不为零，AISIX 会将两项成本相加。请只配置服务提供方实际采用的计费依据。
验证覆盖项
最直接的验证方式是向匹配模型发送一个新请求，然后在 Request Logs 中展开事件。对于按 Token 计费的模型，应产生足够的 Token 用量，以显示可见成本。对于按时长计费的模型，应使用时长已知或足够长的音频样本。确认事件显示的模型和事件成本符合预期。Request Logs 当前不显示测得的音频时长，因此请根据样本时长计算预期的时长成本。
如果验证的是路由或合议请求，请找到共享同一请求 ID 的事件或尝试行，将成本相加后再 与预期值比较。
Request Logs 显示六位小数。如果预期成本会四舍五入为 $0.000000，请增加 Token 用量，使成本在该精度下可见。
产生足够流量后，也可以在 Usage 中确认聚合支出。Usage 只显示两位小数和前 10 个模型，因此不适合验证单个低成本请求。
保存覆盖项后，历史记录不会变化。应比较修改后创建的新事件，不要期待先前的 $0.00 事件被重新计算。
编辑或重置价格
编辑定价行可更改后续事件使用的费率。Reset to catalog default 会删除组织覆盖价格。如果存在目录价格，则该价格会从下一个用量事件开始重新生效。
手动创建的时长定价行通常没有目录默认值。重置该行会移除其有效价格，因此之后匹配的事件会记录 $0.00，直到再次配置覆盖价格。