跳转到主要内容
Model Inference 采用按量计费，依据实际 token 用量和所调用模型的单价结算。不同模型的单价可能不同，具体价格请以 模型广场 中的模型详情页为准。

​
Token 类型

一次请求通常由输入、缓存读、缓存写和输出等计费项构成。各类 token 的统计口径如下：
推理 Tokens 是否在 API 响应中返回，取决于具体模型、协议和请求参数。有些模型会返回 reasoning 或 reasoning_content，有些模型不会。即使推理 Tokens 不作为可见内容返回，也会进入平台用量统计。

​
计费公式

Model Inference 的完整计费公式如下： 费用 = 输入 Tokens × 输入单价 + 缓存读 Tokens × 缓存读单价 + 缓存写 Tokens × 缓存写单价 + 输出 Tokens × 输出单价
  • 输入、缓存读、缓存写和输出都有独立单价，具体以模型广场的模型详情页为准。
  • 图像输入折算为输入 Tokens 后，按输入单价计费。
不同模型类型的计费项说明如下：

​
max_completion_tokens

max_completion_tokens 限制的是生成侧总预算，也就是推理 Tokens 和可见输出 Tokens 的合计。它不是只限制最终可见回答。 如果使用推理模型，内部推理会先消耗一部分生成预算。当 max_completion_tokens 设置过小时，可能出现以下情况：
  • 可见回答很短，但输出 Tokens 较多。
  • 推理过程耗尽生成预算，导致 content 为空。
  • 回答被截断，finish_reason 为 length。
可以通过适当增大 max_completion_tokens，或调整 thinking_budget 缓解这类问题。thinking_budget 是 hint，不是严格上限；模型可能参考它控制推理量，也可能只部分采用这一设置。
算秩 API 文档统一使用 max_completion_tokens。如果您在第三方工具或旧示例中看到 max_tokens，它表达的是同类含义。

​
查看用量

您可以在 使用详情 页面查看单次请求的 token 用量。 使用详情会展示输入、图像输入、缓存读、缓存写、推理、输出、总 Tokens 等字段。其中，“输出”包含“推理”，排查成本时不要重复相加。
499 请求的最终用量需要等模型生成结束后才能确定，因此用量记录可能晚于客户端断开时间出现。记录生成后，您可以在使用详情中查看实际 token 用量和费用。
使用详情的查看方法，请参见 查看使用详情。

​
哪些请求会计费

判断请求是否计费，关键看请求是否已经到达模型并开始推理。

​
会产生费用的请求

请求已经到达模型并开始推理后，会产生模型调用费用。以下情况都属于计费请求：
  • 请求正常完成并返回响应，例如状态码为 200。
  • 客户端在响应完成前断开连接，例如状态码为 499。只要服务端推理已经开始，模型生成的输出仍会进入用量统计并参与计费。

​
不产生模型调用费用的请求

如果请求在进入模型推理前失败，则不产生模型调用费用。常见情况包括：
  • 请求参数无效或模型不支持该调用协议。
  • API Key 无效、余额不足，或已达到消费额度。
  • 无权调用指定模型，或模型不存在。
  • 触发限流，或平台侧故障导致请求没有进入模型推理。

​
常见状态码的计费口径

下表用于快速判断常见状态码是否计费： 各错误的响应结构和处理方式，请参见 错误处理。

​
客户端断开连接（499）计费说明

​
为什么 499 请求会计费

499 / client_aborted 表示客户端在响应完成前断开了连接，例如客户端主动取消请求、网络中断，或客户端 / 代理超时。 请求到达模型后，服务端推理会立即开始，并继续运行到自然结束，与客户端何时断开、是否仍保持连接无关。即使客户端已经断开，模型已经生成的完整输出仍会进入用量统计并参与计费，包括客户端断开后继续生成的部分。 该口径同时适用于流式和非流式请求。
不要把断开连接当作停止推理的方式。关闭连接只会停止客户端侧接收响应，不会停止服务端推理。

​
如何避免意外的 499 费用

  • 设置 max_completion_tokens：限制生成侧总预算，避免单次请求生成过多输出。
  • 使用 stop 序列：在确认答案结束的位置停止生成。
  • 合理设置客户端超时：复杂任务或长响应可能需要更长时间。如果客户端超时过短，可能在模型仍在生成时断开连接。
  • 长响应使用流式输出：通过 stream: true 持续接收生成内容，及时了解请求进度。
  • 谨慎设计重试逻辑：如果一次请求在生成过程中被断开，随后立即发起重试，原请求和重试请求都可能产生费用。

​
成本控制建议

  • 控制输入长度：减少无关历史消息、长文档和重复上下文，避免输入 token 持续增长。
  • 控制生成预算：合理设置 max_completion_tokens，避免模型生成过长回复。
  • 控制推理预算：对推理模型合理设置 thinking_budget，在推理深度、延迟和成本之间做平衡。
  • 选择合适模型：开发验证阶段优先使用低成本模型，正式上线前再根据效果和成本选择目标模型。
  • 复用长上下文：对于重复长前缀、固定系统提示或多轮长材料，可参考 Prompt 缓存。
  • 稳定 prompt 前缀：让系统消息、工具定义、few-shot 示例等稳定内容在多次请求中保持顺序和内容一致，有助于提高 Prompt Caching 命中机会。
  • 按应用拆分 API Key：为不同应用创建独立 API Key，并设置每月额度、总额度、TPM 和 RPM。密钥管理方法请参见 管理 API 密钥。

​
常见问题

对于推理模型，内部推理会消耗推理 Tokens。推理 Tokens 可能不作为可见内容返回，但会计入输出 Tokens，并按输出单价参与计费。因此，可见回答短不代表输出 Tokens 一定少。
max_completion_tokens 限制推理 Tokens 和可见输出 Tokens 的合计。如果推理过程耗尽生成预算，模型可能没有剩余预算生成最终可见回答，导致 content 为空。
这通常表示生成内容达到了 max_completion_tokens 上限，或者请求整体超过模型上下文限制。可以减少输入内容、增大 max_completion_tokens，或启用流式输出改善长回复体验。
API 是否返回 reasoning 或 reasoning_content 取决于模型、协议和请求参数。即使它们不作为响应内容返回，平台仍会统计模型内部推理消耗，并在用量详情中展示。
如果请求已经到达模型，服务端推理会继续运行到自然结束。客户端断开只会停止客户端侧接收响应，不会停止服务端推理，因此模型生成的输出仍会进入用量统计并参与计费。
499 请求的最终用量需要等模型生成结束后才能确定，因此记录可能晚于客户端断开时间出现。生成完成后，可以在使用详情中查看实际 token 用量和费用。
不能。thinking_budget 是 hint，不是严格上限。它可以帮助模型控制推理量，但不同模型对该参数的支持和采用程度可能不同。
是。每次请求都是独立的，您发送的完整对话历史都会计入本次请求的输入。Prompt Caching 可以降低重复前缀的处理成本，但不会让模型自动继承上一轮上下文。