Dedicated Throughput Unit (DTU) provides performance and throughput guarantees for specified models through dedicated deployment, billed by input/output TPM (Tokens Per Minute). This document introduces DTU features, billing, usage flow, and supported models.
Product Overview
DTU (Dedicated Throughput Unit) provides performance and throughput guarantees for specified models through dedicated deployment, billed by Input/Output TPM. It supports both base models and custom models. DTU offers a fully managed inference service with dedicated underlying GPU resources maintained by the platform.
DTU is the successor to the Model Unit (MU) billing model: while retaining MU's dedicated compute, resource isolation, and fine-tuned model deployment capabilities, it shifts the metering granularity from model unit count to input/output TPM, providing more direct throughput guarantees. New dedicated deployments are recommended to use DTU.
- Dedicated GPU resources; the inference environment is physically isolated from other users.
- Supports base models and custom models (Bailian fine-tuned models or user-uploaded models).
- Purchase by performance tier; the platform maintains the underlying operations, no need to manage GPUs.
- No proactive RPM/TPM limits; traffic is bound by actual capacity.
Solution Selection
Bailian offers multiple capacity and billing plans for inference calls. DTU suits scenarios requiring dedicated deployment, fine-tuned model deployment, low latency with high concurrency, or data isolation. The plans are compared in the table below.
For Token pay-as-you-go and PTU deployment, see Model deployment.
Comparison Dimension | DTU | PTU | Token Pay-as-you-go | PAI/Lingjun |
|---|---|---|---|---|
Feature | Dedicated compute + fine-tuned models | Throughput guarantee + low latency | Elastic and zero-threshold | Custom runtime |
Resource isolation | Physical isolation | Logical isolation | Shared pool | Physical isolation |
Fine-tuned models | Full-parameter + LoRA | Not supported | LoRA | Supported |
Custom framework | Not supported | Not supported | Not supported | Supported |
Billing mode | TPM quota × duration | TPM quota × duration | Token usage | GPU × duration |
Billing
DTU is billed separately by input TPM and output TPM, using a pre-paid (monthly) model. Each model has fixed input/output baseline TPM (see table below), and you must purchase in integer multiples of the baseline TPM. Purchase at least 1× baseline TPM for both input and output; for production, 2× or above is recommended for each.
Fees are calculated by the backend based on model, input/output TPM, service region, and purchase duration. The input/output unit prices and monthly price for each model are shown in the table below. Unit prices are billed per kTPM·month, and the monthly price is the total for 1× baseline TPM of both input and output. Fine-tuned model prices are the same as the corresponding base model, subject to the actual console display.
For the same model, the performance ranking by spec is: Fast > Efficient > Standard.
- Singapore
Model | SKU | Baseline Input (TPM) | Baseline Output (TPM) | Input Unit Price (USD/kTPM·mo) | Output Unit Price (USD/kTPM·mo) | Monthly Price (USD) |
|---|---|---|---|---|---|---|
qwen3.7-plus-2026-05-26 | sku-qwen3.7-plus-2026-05-26-llm-thinking-fast | 1,192,000 | 148,000 | 37 | 295 | 87,764 |
sku-qwen3.7-plus-2026-05-26-llm-instruct-fast | 1,372,000 | 170,000 | 32 | 257 | 87,594 | |
sku-qwen3.7-plus-2026-05-26-vlm-thinking-fast | 660,000 | 124,000 | 66 | 352 | 87,208 | |
sku-qwen3.7-plus-2026-05-26-vlm-instruct-fast | 704,000 | 132,000 | 62 | 331 | 87,340 |
The following performance reference data was measured at a 0% cache hit rate. In actual use, as the cache hit rate increases, model performance improves accordingly.
Model | SKU | Input Length | Output Length | Cache Hit | First Token Latency (ms) | Per-token Latency (ms) |
|---|---|---|---|---|---|---|
qwen3.7-plus-2026-05-26 | sku-qwen3.7-plus-2026-05-26-llm-thinking-fast | 16,000 | 2,000 | 0% | 888 | 10 |
sku-qwen3.7-plus-2026-05-26-llm-instruct-fast | 16,000 | 2,000 | 0% | 2,418 | 15 | |
sku-qwen3.7-plus-2026-05-26-vlm-thinking-fast | 2,600 | 500 | 0% | 819 | 14 | |
sku-qwen3.7-plus-2026-05-26-vlm-instruct-fast | 2,600 | 500 | 0% | 970 | 13 | |
qwen3.8-27b | sku-qwen3.8-27b-efficient | 4,000 | 500 | 0% | 1,249 | 26 |
Create Deployment
Before using DTU, enable the DTU feature in the console and apply for a resource quota. Once enabled, select the target model on the Bailian console model deployment page and choose DTU as the billing method to create a deployment.
For the basic workflow of general model deployment, see Model deployment.
The form fields for creating a deployment are shown in the table below.
Parameter | Description | Required | Value Description |
|---|---|---|---|
Service Name | Name of the deployment service | Yes | Custom |
Model | Target model to deploy | Yes | Dropdown selection |
Deployment Template | Deployment architecture | No | Dropdown selection, default to the first |
Payment Type | Billing method | Yes | Pre-paid (monthly) |
Input Throughput Quota | Purchased input TPM capacity | Yes | Integer multiple of baseline input TPM (kTPM) |
Output Throughput Quota | Purchased output TPM capacity | Yes | Integer multiple of baseline output TPM (kTPM) |
Purchase Duration | Purchase period | Yes | 1-12 (integer, months) |
Auto Renewal | Auto-renew on expiry | No | On/Off |
Single Renewal Duration | Required when auto-renewal is enabled | Yes | 1-12 (integer, months) |
Capacity Planning
DTU is sold by input/output TPM; the purchased TPM defines the maximum tokens processable per minute. Capacity planning aims to derive the purchase multiple from your business's peak token demand, then verify through load testing that the actually sustainable concurrency and latency meet requirements. Baseline input/output TPM and standard-workload performance references for each model are in the tables above.
Use a load-testing tool such as evalscope to test against your real business scenario (input/output length, concurrency, latency requirements), then determine the purchase multiple against the pricing table.
Capacity Planning Method
- Profile peak business metrics: typical request input/output token length, target concurrency, and requirements for first-token latency (TTFT) and per-token generation latency (TPOT).
- Estimate peak throughput demand: peak input TPM ≈ concurrency × per-request input length ÷ per-request processing time (minutes); peak output TPM ≈ concurrency × per-request output length ÷ per-request generation time (minutes).
- Compute the purchase multiple: input multiple = ⌈peak input TPM ÷ baseline input TPM⌉, output multiple = ⌈peak output TPM ÷ baseline output TPM⌉. DTU requires input and output to scale together, so take the larger of the two as the final multiple.
- Verify with load testing: after purchasing the computed multiple, re-test with evalscope under the target workload to confirm actual throughput and latency meet business requirements. If latency is high, raise concurrency within the TPM headroom to improve effective throughput.