Provisioned throughput for long input and caching

更新时间:
复制 MD 格式

This document covers the long input and prefix caching capabilities for provisioned throughput (PTU) deployments, including quota consumption rules, use of the capacity calculator, and relevant API response field descriptions.

Overview

PTU deployments support long input requests (up to 200K tokens for some models) and prefix caching, using a tiered capacity factor and cache discount for flexible quota management.

Key features:

  • Long input support: Some models support inputs that exceed 32K tokens. Input tokens exceeding this limit consume your tokens per minute (TPM) quota at a higher rate based on a tiered factor. For more information, see Quota consumption rules.

  • Prefix caching discount: Some models support prefix caching. When a request hits the cache, the cached input tokens consume quota at a discounted rate, which varies by model. This can reduce quota consumption for use cases like multi-turn conversations and requests with repetitive prefixes.

  • Automatic fallback to pay-as-you-go: If a request exceeds your PTU quota or the model's maximum input length (128K for Qwen models / 64K for DeepSeek), it automatically falls back to pay-as-you-go billing. You do not need to change your calling code.

Important

After a request falls back to pay-as-you-go, the system bills it at the pay-as-you-go rate for the corresponding model. We recommend using the capacity calculator to plan your PTU quota to avoid unexpected charges.

These features are common in scenarios with inputs exceeding 32K tokens, such as long-document analysis (contracts, research paper summaries) and multi-turn conversations (customer support, coding assistants).

Quota consumption rules

The tiered capacity factor for long input and the cache discount vary by model. The following table lists the parameters for currently supported models.

Model

Maximum input length

Cache discount

Tiered capacity factor

glm-5.1

200K

0.2 (Cached tokens consume capacity at 20% of the normal rate)

[0, 32K): Input 1.0 / Output 1.0
[32K, 200K]: Input 1.33 / Output 1.17



deepseek-v4-pro

64K

0.08 (Cached tokens consume capacity at 8% of the normal rate)

No tiers (1.0)

qwen3.7-plus-2026-05-26

128K

0.2 (Cached tokens consume capacity at 20% of the normal rate)

No tiers (1.0)

Other models

Refer to the console for details.

Not supported

No tiers (1.0)

Calculation example (glm-5.1)

Scenario 1: Short input (10K tokens, no cache)
  Input consumption: 10K × 1.0 = 10K TPM

Scenario 2: Long input (50K tokens, no cache)
  Input consumption: 32K × 1.0 + 18K × 1.33 = 55.94K TPM
  Output consumption (assuming 1K tokens): 1K × 1.17 = 1.17K TPM

Scenario 3: Long input with cache hit (50K tokens, first 30K hit the cache)
  Cached input portion (first 30K, all within the [0, 32K) tier):
    30K × 1.0 × 0.2 = 6K TPM
  Non-cached input portion (remaining 20K):
    2K × 1.0 + 18K × 1.33 = 25.94K TPM
  Total input consumption = 31.94K TPM (43% saving compared to no cache)

Estimate quota with the capacity calculator

Note

We recommend using the calculator to estimate your quota requirements for long input scenarios before creating or scaling out a deployment. This helps prevent insufficient quota, which can cause requests to fall back to pay-as-you-go billing. The maximum purchase amount is determined by the limit shown in the console.

Before you begin, ensure that you have activated Model Studio and have the required permissions for PTU deployments. Log in to the Model Studio console. On the model deployment > create deployment page (or by clicking scale out on an existing deployment's details page), select a deployable PTU model and expand the capacity calculator.

image

The capacity calculator recommends a TPM quota based on your workload. After you enter the following parameters, the calculator outputs the recommended input TPM and output TPM.

Parameter

Description

Impact on results

Requests per minute (RPM)

The number of requests per minute during peak traffic.

A higher RPM proportionally increases the recommended input and output TPM.

Average input length (tokens)

The average number of input tokens per request.

Longer inputs may fall into a higher tier with a larger capacity factor, which increases the recommended input TPM. Tier boundaries vary by model and are displayed in the console.

Average output length (tokens)

The average number of output tokens per request.

Longer outputs may have a larger capacity factor, which increases the recommended output TPM.

Estimated cache hit rate (%)

The percentage of repetitive prefixes in requests that are expected to hit the cache. The actual hit rate depends on the repetitiveness of your request content and is calculated at runtime.

A higher hit rate slows input quota consumption, which decreases the recommended input TPM. This only affects the input TPM, not the output TPM.

API response fields

The API response for a PTU deployment includes the following quota-related fields to identify the billing method and quota consumption.

Field

Type

Description

service_tier

String

A top-level field in the response body, consistent across all API formats. A value of ptu-standard indicates that the PTU quota was used. A value of default or the absence of this field indicates that the request was billed as pay-as-you-go.

provisioned_tokens

Integer

The number of PTU quota tokens consumed, adjusted for the tiered capacity factor and cache discount.

cached_tokens

Integer

The number of tokens that hit the prefix cache. For more information, see Context caching.

The JSON paths for these fields differ depending on the API format.

OpenAI Chat compatibility

Field

JSON path

Description

cached_tokens

usage.prompt_tokens_details.cached_tokens

Cache hits for the input.

provisioned_tokens

usage.prompt_tokens_details.provisioned_tokens

PTU quota consumed by the input.

provisioned_tokens

usage.completion_tokens_details.provisioned_tokens

PTU quota consumed by the output.

OpenAI responses

Field

JSON path

Description

cached_tokens

usage.input_tokens_details.cached_tokens

Cache hits for the input.

provisioned_tokens

usage.input_tokens_details.provisioned_tokens

PTU quota consumed by the input.

provisioned_tokens

usage.output_tokens_details.provisioned_tokens

PTU quota consumed by the output.

Anthropic compatibility

Field

JSON path

Description

provisioned_tokens

usage.prompt_tokens_details.provisioned_tokens

PTU quota consumed by the input.

provisioned_tokens

usage.output_tokens_details.provisioned_tokens

PTU quota consumed by the output.

Note

The Anthropic-compatible format does not currently return the cached_tokens field. You can infer the effect of caching by observing the value of provisioned_tokens.

DashScope

Field

JSON path

Description

cached_tokens

usage.prompt_tokens_details.cached_tokens

Cache hits for the input.

provisioned_tokens

usage.prompt_tokens_details.provisioned_tokens

PTU quota consumed by the input.

provisioned_tokens

usage.completion_tokens_details.provisioned_tokens

PTU quota consumed by the output.

For complete definitions and value ranges for each field, see the API reference.

Monitoring and verification

You can monitor PTU deployments using the model monitoring feature in Model Studio. It allows you to view the following metrics related to long input and caching:

  • PTU utilization: Includes three separate curves for input, output, and thought mode output. In long input scenarios, the tiered capacity factor may cause utilization to exceed 100%, which is expected behavior.

  • Token usage and cache hits: Includes the cached_tokens data series, which shows the ratio of cached tokens to total input tokens.

  • In-quota/out-of-quota calls: Shows the percentage of requests that fall back to pay-as-you-go billing after exceeding the PTU quota.

For more information about monitoring metrics and procedures, see Model monitoring.

FAQ

Q: What happens when usage exceeds the PTU quota?

The request automatically falls back to pay-as-you-go billing. In the API response, the service_tier field is absent or set to default, and the response header contains x-dashscope-ptu-overflow:true. Your service continues uninterrupted.

Q: What happens if a single input exceeds the model's maximum length?

The maximum input length for Qwen series models is 128K tokens, and for DeepSeek series models, it is 64K tokens. Requests that exceed these limits also automatically fall back to pay-as-you-go billing.

Q: How can I confirm that caching is working?

Check the cached_tokens field in the API response. A value greater than 0 indicates a prefix cache hit. The cached portion consumes quota at a discounted rate specific to the model (for details, see Quota consumption rules). You can also view the trend in the token usage chart on the monitoring page in the console.

Q: Why is cached_tokens always 0, indicating that caching is not working?

Common reasons include inconsistent input prefixes between requests (such as a changing System Message), the interval between requests exceeding the cache expiration period, or an input token count that is too low to trigger caching. For troubleshooting steps and cache usage limitations, see Context caching.

Q: Why does utilization exceed 100%?

For some models, such as glm-5.1, the tiered capacity factor for long input causes the actual quota consumption to be higher than the original token count. Utilization is calculated as (Adjusted Consumption) ÷ (Purchased Quota). A value over 100% means the consumption rate is exceeding your purchased quota. The excess portion automatically falls back to pay-as-you-go billing without affecting service availability.