Produkt und unbegrenzte Nutzung
Ein Abonnement gewährt 3, 7 oder 30 Tage Zugriff auf das ausgewählte Modell ohne Gesamtlimit für Ein- und Ausgabetokens. Jedes Abonnement umfasst vier parallele Anfragen. Kontoschlüssel verwenden einen gemeinsamen Slot-Pool des jeweiligen Modells. Nach Abschluss des Vorgangs wird der Slot freigegeben.
Rate Cloud verwaltet die Platzierung der Gewichte, Ausführungs-Engines, Genauigkeitsprofile und Anfrageverteilung. Die Hardware wird von Unternehmenseigentümern gemietet. Verfügbare Kapazität ihrer Cluster ergänzt die stabile Reserve. Unbegrenzte Nutzung bezieht sich auf Tokens im Zeitraum; Kontext, Vorgangsdauer, Parallelität und Schutzbeschränkungen bleiben endlich.
Server und Rechenleistung
Die Architektur verwendet Huawei-Atlas-Plattformen und Ascend-Beschleuniger: Atlas 800I A2 und A3 für große Modelle, Atlas 900 A2 PoD und A3 SuperPoD für verteilte Gruppen. Atlas 500 und 500 A2 sind für kleine Dienstaufgaben vorgesehen; Atlas 800 mit Atlas 300I Duo ist eine eigene Kompatibilitätsklasse.
Atlas 800I A2 enthält 8 NPU mit jeweils 64 GB. Atlas 800I A3 enthält 8 physische NPU mit jeweils 128 GB, dargestellt als 16 logische Geräte. Dies sind zwei Darstellungen desselben Speichers und sie dürfen nicht addiert werden. Die Unterstützung wird für jedes Modell separat geprüft. Zwischen Standorten werden vollständige Anfragen umgeschaltet; eng gekoppelte Berechnungen einer Replik verwenden ein kompatibles lokales Netzwerk.
Modelle und Quantisierung
Dasselbe Modell ist in mehreren Quantisierungsvarianten vorbereitet. Beispielsweise kann GLM 5.3 verschiedene Anfragen in einem Qualitäts-, ausgewogenen oder sparsamen Profil bearbeiten. Das intelligente System bewertet die Aufgabe und wählt eine passende Variante desselben Modells. Nutzer müssen nur das Modell auswählen und die Bitbreite nicht manuell wechseln.
Das Qualitätsprofil verwendet das geprüfte Originalformat, W8A8 oder eine andere zugelassene Konfiguration. Das ausgewogene Profil kombiniert die Genauigkeit der Komponenten, zum Beispiel 4 und 8 Bit mit einem effektiven Durchschnitt von etwa 6 Bit. Dies ist keine Zusage eines universellen INT6. Das Sparprofil verwendet geprüfte W4A16-, W4A8- oder MXFP4-Varianten desselben Modells. Die Verfügbarkeit hängt von Hardware und Qualitätsprüfung ab.
Stellen Sie sich Modellzahlen als Werte mit unterschiedlicher Schreibgenauigkeit vor. Eine kompakte Darstellung benötigt weniger Speicher, kann aber das Ergebnis beeinflussen. Eine einfache Informationssuche kann daher an eine geprüfte kompakte Variante gehen, komplexer Code, Mathematik und Toolnutzung an ein Qualitätsprofil. Im Zweifel wählt das System Qualität. Flash und Pro bleiben getrennte Modelle und ersetzen einander nicht.
| Modell | Ursprüngliche Version | Varianten desselben Modells: Das System wählt passend zur Anfrage |
|---|---|---|
| GLM 5.3 | zai-org/GLM-5.3 / GLM-5.3-BF16 | Ursprüngliches Format; geprüftes W8A8C8 oder MXFP4 auf kompatibler Hardware. |
| GLM 5.3 Flash | zai-org/GLM-5.3-Flash / BF16 | W8A8; für A3 und 950DT werden verschiedene Hardwarevarianten verwendet, darunter MXFP8. |
| DeepSeek V4 Pro | deepseek-ai/DeepSeek-V4-Pro-0813 | Native MXFP8 und MXFP4; vorbereitetes W4A8 bei bestätigter Kompatibilität. |
| DeepSeek V4.1 Flash | deepseek-ai/DeepSeek-V4.1-Flash-1017 | Native MXFP4, FP8 und genauere Komponenten; W8A8-Anpassung für A2/A3 mit separater Engram-Platzierung. |
| Qwen 3.8 Max | Qwen/Qwen3.8-2.4T-A95B | Geprüfte Qualitäts- und Sparprofile desselben Modells. Diese Architekturausgabe legt kein einziges festes Format fest. |
Qualitätsprüfung
Jedes Profil wird mit öffentlichen, synthetischen und eigens vorbereiteten Aufgaben gegen die exakte ursprüngliche Version geprüft: Code, Mathematik, langer Kontext, Tools und striktes JSON. Nutzergespräche werden weder zum Training noch zur Kalibrierung verwendet.
Die Prüfung umfasst Ergebnisqualität, Speicher, Geschwindigkeit und korrekte API-Funktionen. Eine niedrige Bitbreite ist nur für geeignete Aufgaben zulässig. Eine Erhöhung der Bitbreite bereits veröffentlichter niedrigbitiger Gewichte stellt verlorene Informationen nicht wieder her. reasoning_effort ist eine eigenständige Einstellung und wird nicht als Effekt der Quantisierung ausgegeben.
Anfragepfad
Sichere Verbindung → Schlüssel, Abonnement und freien Slot prüfen → Anforderungen bestimmen → Profil für das ausgewählte Modell wählen → bereite Replik zuweisen → Antwort streamen → Slot freigeben und temporäre Inhalte löschen.
Ein logischer Vorgang hat eine request_id; jeder Rechenversuch hat eine attempt_id. Vor Beginn der Ausgabe ist innerhalb der Gesamtfrist ein erneuter Versuch auf einer kompatiblen Replik zulässig. Nach Beginn des Streams wird der Anfang einer Antwort nicht mit der Fortsetzung einer neuen Generierung verbunden. Der Client sollte einen unterbrochenen Stream als unvollständig behandeln.
Intelligente Verteilung
Der Router berücksichtigt Kontext, Bilder, Tools, Antwortformat, Aufgabenkomplexität, verfügbaren Speicher, Warteschlange, Replikzustand und Ressourcenzuweisungsfrist. Code, Mathematik, strikte Schemas, Tools und unsichere Aufgaben erhalten Qualitätspriorität. Eine kurze Frage ist nicht zwangsläufig einfach.
Kosten werden nur unter geeigneten Routen berücksichtigt. Gewichtsversion und zulässige Funktionen werden für die Dauer des Vorgangs festgehalten. Inkompatible Server werden vor der Zuweisung ausgeschlossen. Ist keine geeignete Kapazität verfügbar, kann innerhalb des internen Budgets gewartet werden oder ein ausdrücklicher Fehler wegen vorübergehender Nichtverfügbarkeit zurückkommen; ein anderes Modell wird nicht unbemerkt eingesetzt.
Ausfallsicherheit und Wiederherstellung
Stabile Gruppen tragen den Hauptbetrieb und die Wiederherstellung. Zusätzliche unterbrechbare Gruppen erhöhen die Kapazität. Bei einer Widerrufswarnung nimmt ein Server keine neuen Vorgänge mehr an; unfertige Aufgaben laufen innerhalb der ursprünglichen Frist weiter. Der Verlust eines kritischen Beschleunigers schließt die gesamte abhängige Replik aus.
Eine vorbereitete Replik durchläuft das Laden der Gewichte, Aufwärmen und Bereitschaftsprüfungen. Unabhängige Fehlergruppen verringern die Auswirkungen eines einzelnen Ausfalls. Wiederholte Berechnungen können die Latenz erhöhen. Die Wiederherstellungsarchitektur garantiert keine 24/7-Verfügbarkeit jedes Modells.
Infrastruktursicherheit
Externe Übertragungen sind durch TLS geschützt. Verbindungen zwischen Diensten verwenden Identitätsprüfung und mTLS. Zugriffsrechte werden nach den Arbeitsanforderungen vergeben. Schlüssel, Konten, Projekte und Cache-Bereiche sind isoliert. API-Geheimnisse und Anfrageinhalte dürfen nicht in Protokollen oder Sicherungen erscheinen.
Verbindungsschutz unterscheidet sich vom Datenschutz während der Berechnung. Gemietete Hardware hat eine eigene Vertrauensgrenze: Hardwaregeschützte Ausführung kann nicht für jeden Beschleuniger zugesagt werden. Bei Kontrollverlust wird ein Knoten ausgeschlossen und seine Berechtigung widerrufen; vor der Rückkehr sind Prüfung und Bereinigung erforderlich.
Löschen von Anfragen und temporärer Cache
Rate Cloud erstellt keinen dauerhaften Verlauf von Anfrage- und Antworttexten und trainiert Modelle nicht mit Nutzerdaten. Inhalte werden im temporären Speicher verarbeitet. Das Bereinigungsziel für verfügbare verwaltete Anwendungs-Puffer beträgt bis zu 5 Sekunden nach erfolgreicher Übermittlung und bis zu 30 Sekunden nach einem endgültigen Fehler, Abbruch oder Verbindungsverlust.
Der isolierte Rechen-KV-Cache hat eine eigene Frist: bis zu 5 Minuten ohne Wiederverwendung und bis zu 15 Minuten absolutes Alter. Nach Fristablauf ist der Block von neuen Treffern ausgeschlossen; ein Vorgang, der ihn bereits nutzt, darf innerhalb seiner Frist beendet werden. Nach Freigabe der letzten Referenz wird der Speicher gelöscht. Der Cache wird nicht auf dauerhaften Datenträger geschrieben und ist nicht in Snapshots enthalten.
Der Kompatibilitätsschlüssel umfasst Konto, Modell, Gewichtrevision, Quantisierung, Tokenizer, Chatvorlage und Systemanweisungen. Der Index ist durch HMAC geschützt. Nutzer können keinen Cache-Bereich einer anderen Person wählen. Ein Profil ohne anfrageübergreifenden Cache wird durch die Verarbeitungsrichtlinie des Projekts festgelegt. Den Verlauf in einer Clientanwendung steuert diese Anwendung.
Technische Metadaten umfassen Kennungen, Modell, Profil, Zeit, Dauer, usage, Slotstatus und Fehlercodes. Detaillierte Einträge werden nach 30 Tagen gelöscht. Sie enthalten keine Prompts, Antworten, Toolargumente, Dateien oder Autorisierungstokens. Konto-, Zahlungs- und freiwillige Supportdaten haben eigene Zwecke und Aufbewahrungsfristen.
Verfügbarkeit und Entschädigung
Die Modellverfügbarkeit rund um die Uhr an 7 Tagen pro Woche wird nicht garantiert. Ist das gesamte System länger als 4 Stunden ununterbrochen vollständig nicht verfügbar und geben Anfragen HTTP 503 zurück, werden bezahlte Abonnements verlängert: Bei 3 Tagen um 12 Stunden, bei 7 Tagen um 1 Tag und bei 30 Tagen um 3 Tage.
Diese Regel gilt nur für einen vollständigen Systemausfall mit HTTP 503. Fehler einzelner Modelle, langsame Antworten, Parallelitätsbeschränkungen und andere Fehlercodes erfüllen die Voraussetzung nicht. Wenden Sie sich zur Prüfung des Vorfalls mit Zeitpunkt und Vorgangs-IDs an den Support, ohne API-Geheimnis oder Anfrageinhalte zu übermitteln. Zwingende Nutzerrechte bleiben bestehen.
Versionen und Umsetzungskriterien
Bei der Abnahme werden die Beibehaltung des gewählten Modells, Qualitätspriorität, Wiederherstellung innerhalb der ursprünglichen Frist, Cache-Isolierung, Inhaltslöschung, Verbindungsschutz und das Fehlen von Texten in Analysen geprüft. Änderungen an API-, Cache- und Profilverträgen müssen in Dokumentation, Kontoportal und Bedingungen übereinstimmen.