DTU Model Deployment

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.

For the general model deployment workflow, see Model deployment and Provisioned Throughput.

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. Prices for each model are shown in the table below; the starting and scaling prices are both the total for 1× baseline TPM of 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.

China (Beijing) 2

Model	Spec	Baseline Input (TPM)	Baseline Output (TPM)	Starting Price (CNY/month)	Scaling Price (CNY/month)
qwen3.7-plus-2026-05-26	Fast	1,372,000	170,000	556,466	556,466
qwen3.6-27b	Standard	273,000	34,000	49,118	49,118
qwen3.5-397b-a17b	Standard	896,000	112,000	1,107,904	1,107,904
qwen3.5-122b-a10b	Fast	7,288,000	904,000	2,226,984	2,226,984
qwen3.5-35b-a3b	Standard	656,000	82,000	109,962	109,962
qwen3.5-27b	Standard	2,432,000	304,000	1,108,688	1,108,688
	Efficient	291,000	36,000	48,996	48,996
qwen3.5-4b	Standard	1,072,000	134,000	109,478	109,478
glm-5.2	Fast	1,004,000	120,000	1,895,260	1,895,260
glm-5.1	Standard	256,000	32,000	504,704	504,704
deepseek-v4-flash	Standard	2,240,000	280,000	1,107,400	1,107,400
deepseek-v4-flash-0731	Fast	1,676,000	213,000	277,984	277,984

The performance reference data for each model under standard workload is shown in the table below, subject to the actual console display.

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	Spec	Input Length	Output Length	Cache Hit Rate	First-token Latency (ms)	Per-token Latency (ms)
qwen3.7-plus-2026-05-26	Fast	16,000	2,000	0	2,418	15
qwen3.6-27b	Standard	4,000	500	0	1,292	19
qwen3.5-397b-a17b	Standard	4,000	500	0	996	27
qwen3.5-122b-a10b	Fast	16,000	2,000	0	568	8
qwen3.5-35b-a3b	Standard	4,000	500	0	471	10
qwen3.5-27b	Standard	4,000	500	0	703	14
	Efficient	4,000	500	0	1,448	23
qwen3.5-4b	Standard	4,000	500	0	552	6
glm-5.2	Fast	16,000	2,000	0	1,558	15
glm-5.1	Standard	4,000	500	0	769	27
deepseek-v4-flash	Standard	4,000	500	0	651	19
deepseek-v4-flash-0731	Fast	16,000	2,000	0	1,079	13

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

1. 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).
2. 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).
3. 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.
4. 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.

If latency requirements are not strict, you can raise concurrency — within the purchased TPM cap — to increase actual throughput.

Business estimation example:

For a model with baseline input 656K TPM and baseline output 82K TPM: business peak profiling shows peak input ~1,300K TPM and peak output ~160K TPM. Compute multiples: input ⌈1300÷656⌉=2, output ⌈160÷82⌉=2; take the larger (2×), purchasing input 1,312K TPM (656K×2) + output 164K TPM (82K×2). Then load-test with evalscope at the peak workload to confirm latency passes. If business volume doubles (peak input ~2,600K, output ~320K), multiples become input ⌈2600÷656⌉=4, output ⌈320÷82⌉=4; purchase 4×: input 2,624K TPM (656K×4) + output 328K TPM (82K×4), and re-test.

Estimation formula:

Purchase multiple = max(⌈peak input TPM ÷ baseline input TPM⌉, ⌈peak output TPM ÷ baseline output TPM⌉)

Deployment Management and Scaling

The deployment list shows the purchased input/output TPM quotas; the details page shows the TPM capacity details.

Scaling: Click "Scale" in the deployment list to modify the input/output TPM capacity. Scaling up shows the additional amount due; scaling down shows the estimated refund. Input and output must be increased or decreased together; one cannot increase while the other decreases. Only running deployments can be operated.

Renewal: Pre-paid monthly deployments can be renewed upon expiry. The renewal button on the details page enters the renewal flow, supporting an auto-renewal toggle and a single renewal duration.

Unsubscription: Prepaid monthly orders support early termination; the used portion is settled at a 1.2x coefficient for refund. For details, see Refund rules for configuration downgrades. Unsubscription is irreversible; after unsubscription, dedicated resources are released and the service stops.

FAQ

What is the difference between DTU deployment and Token pay-as-you-go billing?

Token pay-as-you-go bills by token usage on a shared resource pool; DTU uses dedicated GPU resources and bills by input/output TPM, suitable for scenarios requiring stable throughput and dedicated deployment.

What billing methods does DTU deployment support?

Only pre-paid (monthly) billing is supported.

How do I view the usage of purchased TPM?

You can view the purchased input/output TPM quotas in the deployment list and details page on the Bailian console model deployment. See Model deployment.