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.
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).
For basic concepts and purchasing information about PTU deployments, see Introduction to model deployment. For details on how prefix caching works, see Context caching.
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 |
|
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
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.

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 |
|
|
String |
A top-level field in the response body, consistent across all API formats. A value of |
|
|
Integer |
The number of PTU quota tokens consumed, adjusted for the tiered capacity factor and cache discount. |
|
|
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 |
|
|
|
Cache hits for the input. |
|
|
|
PTU quota consumed by the input. |
|
|
|
PTU quota consumed by the output. |
OpenAI responses
|
Field |
JSON path |
Description |
|
|
|
Cache hits for the input. |
|
|
|
PTU quota consumed by the input. |
|
|
|
PTU quota consumed by the output. |
Anthropic compatibility
|
Field |
JSON path |
Description |
|
|
|
PTU quota consumed by the input. |
|
|
|
PTU quota consumed by the output. |
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 |
|
|
|
Cache hits for the input. |
|
|
|
PTU quota consumed by the input. |
|
|
|
PTU quota consumed by the output. |
For complete definitions and value ranges for each field, see the API reference.
Monitoring and verification
-
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_tokensdata 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.