CAR enables you to run your application in the cloud, so that end users can use your application in real time through a webpage or lightweight Android and iOS application. CAR is billed based on the concurrencies you purchase. One concurrency represents the collection of virtual computing resources, including CPU, bandwidth, disk, and GPU, required for one user to render your cloud application.
CAR Concurrency Scales
CAR supports hybrid scheduling of concurrencies in x86 and ARM architectures.
x86 concurrency: It has a high performance and computing power of a desktop graphics card, and is generally suitable for PC desktop applications.
ARM concurrency (in beta test): Has a high-cost performance and low application adaptation costs and is generally suitable for Android applications.
Concurrency Architecture
Concurrency Scale
Configuration
Application
CPU
Memory
GPU
Video Memory
Bandwidth
x86
GPU
S - For rendering small applications
4-core or above vCPU performance
8 GB or above
2 TF SP/30T INT or above
4 GB or above
Up to 6 Mbps
Small desktop applications
M - For rendering medium-sized applications
4-core or above vCPU performance
16 GB or above
4 TF SP/30T INT or above
6 GB or above
Up to 8 Mbps
Medium-sized desktop applications
L - For rendering large applications
10-core or above vCPU performance
32 GB or above
8.1 TF SP/30T INT or above
12 GB or above
Up to 8 Mbps
Large desktop applications
x86
CPU
4-core CPU type concurrency
4-core or above vCPU performance
8 GB or above
-
-
Up to 6 Mbps
Desktop or web applications without GPU requirements
8-core CPU type concurrency
8-core or above vCPU performance
16 GB or above
-
-
Up to 8 Mbps
16-core CPU type concurrency
16-core or above vCPU performance
32 GB or above
-
-
Up to 8 Mbps
ARM
(in beta test)
ARM concurrency (this feature is in beta test and available in multiple scales. If you want to use it, please contact your Tencent Cloud sales rep)
Android applications
Note:
The ARM concurrency feature is in beta test. If you want to use it, please contact your Tencent Cloud sales rep.
In CAR, a concurrency is a virtual resource that supports one user to access your cloud application. Concurrency scales differ in their architecture and configuration, but they do not determine the number of concurrent users that can access an application.
Suppose you have a large-scale virtual concert application. To guarantee there are enough computing resources to render your application, you can choose concurrency scale L with a high GPU performance. If you want to sustain 1,000 users accessing your cloud environment at the same time during peak hours, you can purchase 1,000 monthly or daily subscribed L concurrencies and make additional users queue up to wait for concurrencies to become available. To learn more about queueing, see Queue Feature.
The main metrics for the GPU performance are floating-point operations capabilities.
TF indicates floating-point operations per second (FLOPS).
Currently, CAR concurrency is available in three prepaid billing modes: monthly subscription, daily subscription, and prepaid resource packages.
Prepaid monthly subscription: Suitable for a business with stable traffic or multiple businesses sharing resources, such as virtual branches, shops, and exhibition halls, which have steady user access.
Prepaid daily subscription: Suitable for virtual events such as virtual concerts and cloud marketing events, which involve a high concurrency.
Prepaid resource package: Hourly billing and the hours are purchased before being used. This billing mode is suitable for businesses that have irregular concurrent user access and require elastic scaling.
Monthly subscriptions are suitable for a business with stable traffic or multiple businesses sharing resources, such as virtual branches, shops, and exhibition halls, which have steady user access.
Concurrency Architecture
Concurrency Scale
AZ
Billing Cycle
Billing Unit
Minimum Purchase Unit
North America
Singapore
Tokyo
Seoul
Frankfurt
x86
GPU
S - For rendering small applications
✓
✓
✓
✓
✓
Monthly
USD/concurrent user/month
One concurrent user for one month
M - For rendering medium-sized applications
✓
✓
✓
✓
✓
L - For rendering large applications
✓
✓
✓
✓
✓
x86
CPU
4-core CPU type concurrency
✓
✓
✓
✓
✓
8-core CPU type concurrency
✓
✓
✓
✓
✓
16-core CPU type concurrency
✓
✓
✓
✓
✓
ARM
(high cost-effectiveness)
ARM concurrency (in beta test)
✓
Daily subscription
Daily subscriptions are suitable for virtual events such as virtual concerts and cloud marketing events, which involve a high concurrency.
Concurrency Architecture
Concurrency Scale
AZ
Billing Cycle
Billing Unit
Minimum Purchase Unit
North America
Singapore
Tokyo
Seoul
Frankfurt
x86
GPU
S - For rendering small applications
✓
✓
✓
✓
✓
Daily
USD/concurrent user/day
One concurrent user for one day
M - For rendering medium-sized applications
✓
✓
✓
✓
✓
L - For rendering large applications
✓
✓
✓
✓
✓
x86
CPU
4-core CPU type concurrency
✓
✓
✓
✓
✓
8-core CPU type concurrency
✓
✓
✓
✓
✓
16-core CPU type concurrency
✓
✓
✓
✓
✓
Note:
The ARM concurrency feature is in beta test and cannot be purchased in the console. If you want to use it, please contact your Tencent Cloud sales rep.
Fee calculation method for monthly or daily subscription
Fees = Unit price of the specified concurrency scale x Number of concurrencies x Purchase duration
Example:
Suppose you need to hold a cloud exhibition for one month and want to sustain up to 100 concurrent users accessing your exhibition hall application on the first day of the exhibition and up to 10 concurrent users on the later days. For this, you can purchase a daily subscribed concurrency pack with 90 concurrencies for one day and a monthly subscribed concurrency pack with 10 concurrencies for one month (for additional users, you can use the queue feature to utilize resources efficiently). If the unit prices of scale S in Singapore region are 100 USD/month and 10 USD/day, the total fees will be 10 x 90 x 1 + 100 x 10 x 1 = 1900 USD.
Prepaid resource package
A prepaid resource pack is a billing mode where CAR resources are purchased before being used. A resource pack can be used for applications that experience irregular concurrent access and require elastic scaling. A prepaid resource package is billed hourly. The system counts the peak number of concurrencies in an hour and deducts it from the total number of hours included in the package.
Example:
Suppose you purchased a prepaid resource package of 10,000 hours and there were up to 25, 10, and 74 concurrent users in the first, middle, and last 20 minutes respectively between 10:00 and 11:00, the peak number of concurrencies in the hour is 74. After 11:00, CAR will settle the fees for the last hour and deduct 74 hours from the package of 10,000 hours, and there will be 9,926 hours available remaining.
Note：
Concurrencies under a prepaid package do not support prelaunch, and even if they are allocated to a single-application project as described in Project types and the prelaunch feature is enabled for the project, prelaunch will not take effect if a prepaid package is used. To quickly start the application without loading it, you need to purchase a monthly or daily subscribed concurrency pack.
It takes time to add concurrencies under a prepaid resource package, and up to 50 concurrencies can be added per minute. If too many users access your application faster than concurrencies are added, a failure will be prompted. Therefore, we recommend that you purchase daily subscribed concurrency packs for scenarios involving a spike in concurrencies.
Multiple prepaid resource packs can be bound to the same project or different projects. However, they do not support accumulating concurrency limits. The actual available concurrency depends on real-time inventory. When the monthly or daily demands are high and result in insufficient inventory, the resource packs may not provide the maximum concurrency, and users may need to queue.
Resource pack specifications and AZs
Resource Pack Specification
AZ
Concurrency Architecture
Concurrency Scale
Total Hours
Peak Concurrency Limit
x86
S - For rendering small applications
10,000 hours
≤500 concurrency
Regardless of whether they are bound to the same project or different projects, the peak concurrency limits of multiple resource packs cannot accumulate.
The actual available concurrency depends on real-time inventory. When the monthly or daily demands are high and result in insufficient inventory, the resource packs may not provide the maximum concurrency.
The peak concurrency of 500 is a limit set for the resource pack. If the demand for concurrency is more than 500, you can make multiple purchases of monthly/daily resource packs, or contact us to evaluate special billing models and quotes.
North America, Singapore, Tokyo, Seoul, and Frankfurt
(If resource packs from different regions are required, they must be purchased separately.)
5,000 hours
≤400 concurrency
2,000 hours
≤200 concurrency
1,000 hours
≤100 concurrency
M - For rendering medium-sized applications
10,000 hours
≤500 concurrency
5,000 hours
≤400 concurrency
2,000 hours
≤200 concurrency
1,000 hours
≤100 concurrency
L - For rendering large applications
10,000 hours
≤500 concurrency
5,000 hours
≤400 concurrency
2,000 hours
≤200 concurrency
1,000 hours
≤100 concurrency
XL - For rendering extra large applications
10,000 hours
≤500 concurrency
5,000 hours
≤400 concurrency
2,000 hours
≤200 concurrency
1,000 hours
≤100 concurrency
Note
Purchasing instructions for prepaid resource packs
After purchasing, the prepaid resource pack becomes immediately effective and remains valid for 6 months. Unused resource packs will expire at the end of this period. Validity period of each resource pack is calculated separately, and that of multiple ones do not accumulate.
Prepaid resource packs that satisfy the requirement for a five-day unconditional refund are eligible for refunds. However, under other circumstances, once activated, these packs will not be eligible for refunds.
To inquire about the activation and remaining amount of resource packs, please go to [Concurrency Management - View Usage] in the console.
How to understand the concurrency upper limit of the prepaid resource packs? What are the differences between prepaid resource packs and directly purchasing monthly or daily concurrency packs?
You can exclusively use the monthly and daily packs, while the concurrency in the resource packs is called in real-time from the inventory. Therefore, the concurrency upper limit in the resource packs is the theoretical maximum, the actual supply of concurrency depends on the real-time inventory. For instance, you have purchased a resource pack containing 10,000 hours, which supports up to 500 users connecting simultaneously. However, if the demand for monthly and daily packs is high one day resulting in only 100 remaining concurrency instances in the inventory, then the resource packs can only support 100 users at most at the same time, the others will have to wait in a queue.
Multiple prepaid resource packs do not support accumulating in concurrency limit whether they are bound to the same project or different projects.
The peak concurrency of 500 is a limit set for the resource pack. If the demand for concurrency is more than 500, you can make multiple purchases of monthly/daily resource packs, or contact us to evaluate special billing models and quotes.
When a project is simultaneously bound with monthly&daily concurrency packs and resource packs, the monthly&daily concurrency packs will be prioritized. Usage exceeding the limit of the monthly&daily concurrency packs will be charged through the resource pack billing.
Apart from the billing differences, are there any functional differences between prepaid resource packs and prepaid monthly&daily concurrency packs?
Prepaid resource packs do not support pre-launching, meaning that even when assigned to Project: Single-application with the pre-launch feature enabled, the resource packs can not start pre-launching. To ensure an instant loading in the application, it is necessary to purchase monthly or daily concurrency packs.
Expansion of prepaid resource pack concurrency will take time. The maximum amount of concurrency is 50 per minute. Any attempt at exceeding this limit will result in failure and users will need to join a queue. Therefore, for scenarios involving high concurrency in a short time, it is recommended to purchase daily concurrency packs, or contact us to evaluate special billing models and quotes.
Special billing mode
We recommend that you select an optimal billing mode based on your business scenario as described in Selecting the Optimal Billing Mode Based on the Business Scenario. If neither monthly subscription nor daily subscription can meet the requirements for your specific business scenario, please contact your Tencent Cloud sales rep for a special billing mode and quotation.
Optimal Billing Mode by Scenario
Typical business scenarios
Type
Characteristics
Example
Recommended Billing Mode
Business with stable traffic
A single business
The daily peak number of concurrent users is stable, and there are no obvious peak and off-peak hours.
Scenarios with a stable daily concurrency such as a virtual shop and 3D automobile viewer
Monthly subscription
Multiple businesses
The businesses are only loosely related, and the total daily peak number of their concurrent users is stable.
Multiple cloud exhibition hall projects unrelated to each other
Business with long-term stable traffic and short-term spikes
A single business
The business has obvious peak and off-peak hours (high concurrency during certain times and stable traffic for the rest of the time).
Cloud marketing events, where the concurrency is high during the event and gradually decreases to a stable level after the event
The businesses are loosely related. Certain businesses involve a high concurrency sometimes but stable traffic most of the time.
Multiple digital architectural model projects. Each project involves a high concurrency during the launch, but the total number of concurrent users for all projects is stable for the rest of the time.
Business with a traffic spike during an event
Businesses with a short-term traffic spike during an event, which involve a high concurrency during a short period of time
Virtual concert or festival celebration, which requires over 1,000 or even 10,000 concurrencies during the event
Daily subscription
Special business scenarios
If you are uncertain of your business scenario or your business scenario has special requirements, please contact your Tencent Cloud sales rep for a special billing mode and quotation.
Value-Added Features: CAR Cloud-Based Streaming
CAR supports the additional streaming of images rendered in the cloud. Cloud-based streaming supports two ways of streaming: (1) Streaming to Tencent Cloud Streaming Services (CSS) by binding a cloud live broadcast domain; (2) Transmitting the target streaming address, stream the image to the specified address.
Streaming to Tencent Cloud Streaming Services (CSS)
For the pricing of cloud live streaming products, please refer to the description Billing of LVB. No additional streaming fees are charged during the application of cloud rendering products.
Streaming to a Specified Address
Convey the target streaming address, directing the video stream to the specified address. When utilizing this feature, the system will record the peak bandwidth of each stream, and calculate the total peak bandwidth (Mbps) generated in the billing period streaming service region. The region where cloud rendering is concurrently used is the streaming region. If you stream to multiple regions in a billing period, fees will be charged separately based on the peak bandwidth usage in each region.
Region
Price (USD/Mbps/Month)
Chinese mainland
12.67
Singapore
8.04
Frankfurt
7.1
Seoul
16.56
Silicon Valley
7.1
Virginia
7.1
Japan
13.01
Billing details
Billing mode: Monthly pay-as-you-go
Billing cycle: Monthly billing. Your bill for each month is generated between the 1st and 3rd day of the following month.
Billing rules: Streaming to specified address fees are charged in the pay-as-you-go mode based on your average daily peak bandwidth usage in each month.
Billing examples
Suppose you streaming to a specified address on five days in August 2023. The region was the Chinese mainland, and the peak bandwidth used on the five days were 10 Mbps, 80 Mbps, 70 Mbps, 75 Mbps, and 60 Mbps respectively.
There are 31 days in August. Your streaming to specified address fee for August would be as follows:
(10 Mbps + 80 Mbps + 70 Mbps + 75 Mbps + 60 Mbps) /31 days x 12.67 (USD/Mbps/month) = 120.569 USD .
In the multiplayer interaction mode, the room is created by a CAR player (i.e., the room owner), and then other players (i.e., interactive audience) can join the same room via the room owner's UserId. In the same room, all users can see the same cloud-rendered scene through a cloud rendering connection. To use the multiplayer interaction feature, it must be actively enabled in the console, and then it can be called via API.
When this feature is used, the system will record the bandwidth of interactive users. The bandwidth of multiple users will be cumulatively calculated to determine the peak value, and the peak bandwidth (in Mbps) generated in the service's region during the billing cycle will be the basis for settlement. The region of cloud-rendering concurrency usage will be considered the region for multiplayer interaction. If multiplayer interaction services occur in multiple regions in the same billing cycle, the bandwidth peak values for the involved regions will be billed separately.
Region
Price (USD/Mbps/Month)
Mainland China
12.67
Singapore
8.04
Frankfurt
7.1
Seoul (South Korea)
16.56
Silicon Valley, USA
7.1
Virginia, USA
7.1
Tokyo, Japan
13.01
Billing Details
Billing method: Postpaid monthly billing.
Billing cycle: billed monthly, with multiplayer interaction billing statements for the previous month generated from the 1st to the 3rd of the following month.
Billing rule: Billing is based on the total bandwidth of all users involved in multiplayer interaction, with the default postpaid mode being the average of daily peak values within the billing cycle (average daily peaks per month).
Note:
The bandwidth used by the host is not counted; the bandwidth of multiple interacting users will be cumulatively calculated. For example, for a multiplayer interaction concurrency with 1 host and 2 interactive players, each with a bandwidth of 5Mbps. During calculation, the host's bandwidth is excluded, and the bandwidth of the 2 interactive players is merged for statistics, resulting in 10Mbps.
Billing Example
The user utilized the cloud rendering multiplayer interaction feature for a total of 5 days in August 2023, in the region of Mainland China, with daily peak bandwidths of 10Mbps, 80Mbps, 70Mbps, 75Mbps, and 60Mbps. Given that the maximum number of days in August 2023 is 31 days, the fee for the multiplayer interaction value-added feature in August is:
(10Mbps + 80Mbps + 70Mbps + 75Mbps + 60Mbps)/31 days x 12.67 (USD/Mbps/month) = 120.569 USD.
Yes
No
Was this page helpful?