Vertiefende Analyse · Etwa 6 Min. Lesezeit
Wie OpenAI Habitat umgebaut hat: geteilte Kapazität, regionale Caches und ein begrenzter 12×-Gewinn beim Lesen
OpenAI erläutert Cosmos-DB-Mandanten, CDC-Invalidierung und Rust; die verbesserte Medianlatenz beruht auf mehreren Änderungen.
- Hier veröffentlicht
- Datum der Quelle
- Quelle geprüft
In einem Technikartikel vom 23. Oktober beschreibt OpenAI Änderungen am Azure-Cosmos-DB-Speicher und Lesepfad von Habitat. Es geht um betriebliche Abwägungen und vom Unternehmen berichtete Messungen, nicht um ein neues Modell oder ein öffentliches Speicherprodukt.
Nachrichten anhören
Diesen Artikel vorlesen oder mit den Nachrichten fortfahren.
Vorlesen wird vorbereitet…
Gerätestimme
Browser oder Gerät verarbeiten die Sprache. AISubHub sendet den Text nicht an eine Audio-API. Stimmen und Wiedergabe bei gesperrtem Bildschirm hängen vom Gerät ab.
Beim Fortsetzen kann sich ein kurzer Satzteil wiederholen.
Auf einen Blick
- OpenAI führt die Senkung des weltweiten Lese-p50 von etwa 120 ms auf 10 ms auf Datenplatzierung, regionale Caches und eine Rust-Neuimplementierung zurück; langsame Cache-Fehlzugriffe erreichen weiterhin entfernten Speicher.
- Habitat wechselte von gemeinsamen zu isolierten Containern und nach gemeinsamer Entwicklung mit Azure zurück zum standardmäßigen Teilen. Ein separates System im Exabyte-Maßstab wird noch entwickelt.
Warum gemeinsamer Speicher unabhängige Funktionen drosseln konnte
OpenAI beschreibt Habitat als Speicherschicht mit mehr als 500 Petabyte für Produkte, die über 1 Milliarde Nutzer in 40 geografischen Regionen bedienen. Das sind Größenangaben des Autors, keine unabhängig gemessene Nutzerzahl und keine Meldung über entsprechend viele Neuzugänge. Die praktische Frage lautet, wie Kapazität gebündelt werden kann, ohne dass eine Funktion andere beeinträchtigt. Anfangs nutzte jedes Cosmos-DB-Konto einen Standardcontainer; Clients wählten logische Partitionsschlüssel. Häufige Kennungen konnten dadurch verschiedene Anwendungsfälle unter dieselben Schlüsselgrenzen bringen.
RU/s bezeichnet Anforderungseinheiten pro Sekunde, keine feste Anzahl von Abfragen. Der ursprüngliche Entwurf setzte für Rückstau auf eine angegebene Grenze von 10.000 RU/s je logischem Schlüssel. Tatsächlich werden Grenzen auf gemeinsam genutzten physischen Partitionen durchgesetzt, wo unabhängige Schlüssel konkurrieren. Ein weiterer Fallstrick: Teilt Speicherwachstum eine physische Partition, ohne den Gesamtdurchsatz des Containers zu erhöhen, erhält jede Tochter weniger Kapazität. Große Objekte können so trotz gleichbleibender Anfragerate zu Engpässen führen. Die Schaubilder erklären Mechanismen; ihre Proportionen sind keine Produktionsmessungen.
Isolation begrenzte Schäden und vervielfachte Kapazitätsplanung
Dedizierte Container verschafften kritischen Diensten separate physische Partitionen und begrenzten den Einfluss störender Nachbarn. Das Team passte außerdem den bereitgestellten Durchsatz an die Partitionszahl an, um schwache Partitionen zu verwalten. Dafür musste jede Dienstgrenze Kapazität planen. Der Sprung von internen Tests zu öffentlichem Verkehr konnte einen kleinen isolierten Container überlasten, während derselbe Zuwachs einen großen gemeinsamen Pool kaum verändert hätte. Isolation verschob Fehlergrenzen, beseitigte aber nicht die Vorhersage der Nachfrage vor einer Einführung.
Habitat kehrte zum Teilen als Standard zurück: mit Drosselung heißer Schlüssel, niedrigerer Priorität für Massenarbeit und einer mit Azure entwickelten Serverless-Variante. Der Artikel vergleicht die frühere Grenze von 5.000 RU/s je physischer Partition mit einem angepassten Modus bis 10.000 RU/s, der Teilungen sowohl nach RU-Nutzung als auch nach Datenmenge auslöst. Diese konkrete Zusammenarbeit belegt keine allgemeine Aktivierbarkeit für Azure-Kunden. Unsere Analyse: Bündelung wird wieder tragfähig, wenn interaktive Arbeit geschützt ist und die Kapazitätsregelung auf Nachfrage reagiert.
Warum auch ein verwalteter Dienst gemeinsame Ausfalltests brauchte
Laut OpenAI speichert sein größtes Cosmos-DB-Konto Dutzende Petabyte und bedient über 20 Millionen Abfragen pro Sekunde. Ein Stromausfall Ende 2024 und ein Vorfall beim Rückwechsel etwa einen Monat später zeigten ungetestete Größenannahmen: Nach einem Stromausfall hätten die größten Konten mehrere Stunden für den Wechsel in eine Ersatzregion benötigt. Etwa einen Monat später löste der Rückwechsel einen Verbindungsansturm aus, der das ursprüngliche Gateway überlastete. Clients verbanden sich dort erneut, bevor alle relevanten physischen Partitionen zurückgekehrt waren. Es handelt sich um zwei Vorfälle in unterschiedlichen Erholungsphasen, keinen durchgehenden Ausfall.
Die Reaktion ging über zusätzliche Kapazität hinaus. Habitat und Azure überwachen die Schichten gemeinsam, testen ein Nichtproduktionskonto in produktionsnaher Größe, entwickeln SDKs zusammen weiter und haben direkte technische Eskalationswege. Genannt werden außerdem Gateway-Metadaten-Caches, Lastschutz, Verbindungswiederverwendung sowie die Trennung kritischer und Offline-Arbeit. Wir leiten daraus ab, sowohl Umschalten als auch Rückkehr in repräsentativer Größe zu testen. Dass der Anbieter die Datenbank verwaltet, validiert weder das Verbindungsverhalten des Kunden noch Wiederherstellungszeit oder akzeptablen Schadensradius automatisch.
Was die zwölfmal bessere Leselatenz tatsächlich umfasst
Nach OpenAI sind mehr als 90 % der Habitat-Anfragen Lesezugriffe. Die Strategie platziert Daten nach Möglichkeit näher am Nutzer, repliziert wenige kleine latenzkritische Datensätze breit und verwendet nahe Valkey-Caches für andere häufig genutzte Objekte und Beziehungen. Manche kritischen Konten replizieren in alle 40 bedienten Azure-Regionen; daraus folgt keine weltweite Vollreplikation aller Daten. Speicher und Rechenleistung konkurrieren um Strom, Kühlung und Platz. Datenplatzierung bleibt deshalb eine Produkt- und Kapazitätsabwägung, keine unbegrenzte Lokalitätsgarantie.
Die Invalidierung nutzt den Cosmos-DB-Änderungsfeed: CDC-Verbraucher verwerfen nach Änderungen lokale Kopien; der nächste Lesezugriff füllt sie erneut. OpenAI nennt weltweite Weitergabe innerhalb von Sekunden, ohne allein auf TTL-Ablauf zu setzen. Das bedeutet keine sofortige Konsistenz. Die Rust-Neuimplementierung senkte zusätzlich Dienst-Overhead. Zusammen reduzierten die Änderungen den globalen Lese-p50 von ungefähr 120 ms auf 10 ms. Das Diagramm trennt nahe Replikation, regionale Caches und Rust. Der Faktor 12× lässt sich nicht Rust allein zuschreiben, auf Schreibzugriffe übertragen oder als gesamte ChatGPT-Antwortzeit jedes Nutzers lesen.
CDC-Skalierung und die Grenze zwischen Betrieb und Entwicklung
CDC versorgt außerdem Sekundärindizes, Datenbewegung und Analysen. OpenAI berichtet Millionen erfasster Änderungen pro Sekunde aus Tausenden Containern und Millionen Containerpartitionen über mehr als hundert Kafka-Topics. Eine Steuerungsebene verteilt Regionen und Worker; Replikatlesezugriffe und niedrige Priorität schützen interaktiven Verkehr. Stream-Isolation, Lease-Verwaltung, Warteschlangen für dauerhaft fehlgeschlagene Nachrichten und Leserwechsel bei regionalen Ausfällen behandeln unterschiedliche Fehler. Das Auslagern dauerhaft scheiternder Zustellungen verhindert eine Blockade des Streams, beweist aber nicht den aktuellen Stand aller nachgelagerten Verbraucher.
Grenzen bleiben: Langsame Cache-Fehlzugriffe erreichen entfernten Speicher; der Artikel liefert weder einen kontrollierten Einzelvergleich aller Optimierungen noch eine allgemeine Garantie für hohe Latenzperzentile. OpenAI entwickelt ein Exabyte-System mit Rocksets RocksDB-Cloud-Kern, Raft-Replikation und einem Cosmos-kompatiblen Dokumentmodell. Disaggregierter Speicher und physische Replikation sollen Flash-Bedarf gegen niedrigere Spitzen-QPS tauschen. Das System ist noch in Entwicklung, kein abgeschlossener Cosmos-Ersatz. Wir lasen Teil II und das Latenzdiagramm; Teil I, verlinkten SDK-Code und Dienstgarantien haben wir nicht unabhängig geprüft.
Warum es wichtig ist
Infrastrukturteams können Isolation, gemeinsame Kapazitätsreserven und Betriebsverantwortung gegeneinander abwägen. Cache-Aktualität, Wiederanlauf und hohe Latenzperzentile brauchen getrennte Abnahmekriterien.
Grenzen und Verfügbarkeit
Dies sind Aussagen von OpenAI, keine Reproduktion durch AISubHub oder Azure-Garantie. Der Artikel belegt weder allgemeinen Zugang zum angepassten Serverless-Modus noch neue Abo-Leistungen oder eine Beschleunigung der gesamten Anwendung.
Quellen und Belege
Datum der Quelle: · Quelle geprüft:
KI-gestützte redaktionelle Beiträge, anhand der genannten Primärquellen geprüft. Anbieterangaben werden zugeordnet; eine Aufnahme ist keine Empfehlung.