Dedicated compute deployment offers two plans: Dedicated Throughput Unit (DTU) and Model Unit (MU), providing dedicated GPU resources for specified models. DTU targets newly released models (billed by input/output TPM x duration); MU is used for existing models (billed by model unit count x duration). This document introduces both plans' features, billing, usage flow, and supported models.
Overview
Dedicated compute deployment provides dedicated GPU resources and performance guarantees for specified models, supporting both base and custom model deployment. Bailian offers two dedicated compute plans:
- DTU (Dedicated Throughput Unit): Sold by Input/Output TPM, providing more direct throughput guarantees. Fully managed inference service with dedicated underlying GPU resources maintained by the platform.
- Model Unit (MU): Configures compute power by usage duration and model unit count, with dedicated resources. Supports custom performance metrics and PD disaggregation mode. Billing granularity is model unit count x duration.
- 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).
- 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 a complete comparison of all billing methods including Token pay-as-you-go and PTU, see the Dedicated Deployment Overview main table.
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 rules
- DTU billing
- MU billing
Supported models and pricing
- DTU pricing and performance benchmarks
- MU pricing
- Singapore
Model | 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 | 1,192,000 | 148,000 | 37 | 295 | 87,764 |
1,372,000 | 170,000 | 32 | 257 | 87,594 | |
660,000 | 124,000 | 66 | 352 | 87,208 | |
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 | Input Length | Output Length | Cache Hit Rate | First Token Latency (ms) | Per-Token Latency (ms) |
|---|---|---|---|---|---|
qwen3.7-plus-2026-05-26 | 16,000 | 2,000 | 0 | 888 | 10 |
16,000 | 2,000 | 0 | 2,418 | 15 | |
2,600 | 500 | 0 | 819 | 14 | |
2,600 | 500 | 0 | 970 | 13 |
Deployment creation
- DTU deployment creation
- MU deployment configuration
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.
Scaling and renewal/unsubscription
- DTU scaling and renewal/unsubscription
- MU scaling and renewal