How We Work

Product and unlimited use

A subscription provides access to the selected model for 3, 7, or 30 days with no aggregate quota for input or output tokens. Each subscription includes four parallel requests. Account keys use a shared slot pool for the corresponding model. A slot is released when the operation finishes.

Rate Cloud manages weight placement, execution engines, accuracy profiles, and request distribution. The equipment is rented from enterprise owners. Available capacity in their clusters supplements the stable reserve. Unlimited use applies to tokens over the subscription period; context, operation time, concurrency, and protective limits remain finite.

Servers and compute

The architecture uses Huawei Atlas platforms and Ascend accelerators: Atlas 800I A2 and A3 for large models, and Atlas 900 A2 PoD and A3 SuperPoD for distributed groups. Atlas 500 and 500 A2 are for small service tasks; Atlas 800 with Atlas 300I Duo is a separate compatibility class.

Atlas 800I A2 contains 8 NPU units with 64 GB each. Atlas 800I A3 contains 8 physical NPU units with 128 GB each, represented as 16 logical devices. These are two representations of the same memory and must not be added together. Support is checked separately for each model. Whole requests are switched between sites; tightly coupled computations within one replica use a compatible local network.

Models and quantization

The same model is prepared in several quantization variants. For example, GLM 5.3 can handle different requests in a quality, balanced, or economy profile. The smart system assesses the task and selects a suitable variant of that same model. Users only need to choose the model; they do not need to switch bit depth manually.

The quality profile uses a verified original format, W8A8, or another approved configuration. The balanced profile combines component precision, for example 4 and 8 bits with an effective average of about 6 bits. This is not a promise of universal INT6. The economy profile uses verified W4A16, W4A8, or MXFP4 for the same model. Profile availability depends on hardware and quality validation.

Think of model numbers as values written with different precision. A compact representation uses less memory but can affect the result. A simple information lookup can therefore use a verified compact variant, while complex code, mathematics, and tool use can use a quality profile. When uncertain, the system chooses quality. Flash and Pro remain separate models and do not replace one another.

Quality validation

Each profile is checked against the exact original release on public, synthetic, and specially prepared tasks: code, mathematics, long context, tools, and strict JSON. User conversations are not used for training or calibration.

Validation covers result quality, memory, speed, and API function correctness. Low bit width is allowed only for suitable tasks. Increasing the bit width of already published low-bit weights does not restore lost information. Changing reasoning_effort is a separate setting and is not presented as an effect of quantization.

Request path

Secure connection → check key, subscription, and free slot → determine requirements → choose a profile for the selected model → assign a ready replica → stream response → release slot and clear temporary content.

A logical operation has a request_id; each compute attempt has an attempt_id. Before output starts, a retry on a compatible replica is allowed within the overall deadline. After a stream starts, the beginning of one response is not joined to the continuation of a new generation. The client should treat an interrupted stream as incomplete.

Smart distribution

The router considers context, images, tools, response format, task complexity, available memory, queue, replica health, and resource allocation deadline. Code, mathematics, strict schemas, tools, and uncertain tasks receive quality priority. A short question is not necessarily simple.

Cost is considered only among suitable routes. Weight version and allowed functions are fixed for the duration of an operation. Incompatible servers are excluded before assignment. If suitable capacity is unavailable, the request may wait within the internal budget or receive an explicit temporary-unavailability error; another model is never substituted without notice.

Resilience and recovery

Stable groups support primary operation and recovery. Additional interruptible groups increase capacity. When a revocation warning arrives, a server stops accepting new operations, while unfinished tasks continue within their original deadline. Loss of a critical accelerator excludes the entire dependent replica.

A prepared replica goes through weight loading, warm-up, and readiness checks. Independent failure groups reduce the impact of one outage. Retrying compute may increase latency. Recovery architecture does not guarantee 24/7 availability of each model.

Infrastructure security

External data transfers are protected by TLS. Inter-service connections use identity verification and mTLS. Access rights are granted as needed for work. Keys, accounts, projects, and cache areas are isolated. API secrets and request bodies must not appear in logs or backups.

Connection security differs from data protection during computation. Rented equipment has its own trust boundary: hardware-protected execution cannot be promised on every accelerator. If control is lost, a node is excluded and its authority revoked; return requires review and cleanup.

Request deletion and temporary cache

Rate Cloud does not create a permanent history of request and response text and does not train models on user data. Content is processed in temporary memory. The cleanup target for available, managed application buffers is up to 5 seconds after successful delivery and up to 30 seconds after a final error, cancellation, or connection loss.

The isolated compute KV cache has a separate lifetime: up to 5 minutes without reuse and up to 15 minutes absolute age. After expiry, the block is excluded from new cache hits; an operation already using it may finish within its deadline. Memory is cleared after the last reference is released. The cache is not written to persistent disk or included in snapshots.

The compatibility key includes account, model, weight revision, quantization, tokenizer, chat template, and system instructions. The index is protected with HMAC. Users cannot select another user’s cache area. A profile without cross-request caching is set by the project’s processing policy. History in a client application is controlled by that application.

Technical metadata includes identifiers, model, profile, time, duration, usage, slot status, and error codes. Detailed records are deleted after 30 days. They contain no prompts, responses, tool arguments, files, or authorization tokens. Account, payment, and voluntary support request data have separate purposes and retention periods.

Availability and compensation

Model availability 24 hours a day, 7 days a week is not guaranteed. If the entire system is fully unavailable continuously for more than 4 hours and requests return HTTP 503, paid subscriptions are extended: a 3 day term receives 12 hours, a 7 day term receives 1 day, and a 30 day term receives 3 days.

This rule applies only to a complete system outage with HTTP 503. Individual model errors, slow responses, concurrency limits, and other error codes do not qualify. To check an incident, contact support with the time and operation IDs, without an API secret or request content. The user’s mandatory rights remain in force.

Versions and implementation criteria

Acceptance checks verify that the selected model is preserved, quality is prioritized, recovery stays within the original deadline, cache is isolated, content is deleted, connections are protected, and text is absent from analytics. Changes to API, cache, and profile contracts must be aligned across documentation, the account portal, and terms.