Anyscale on Azure ist jetzt allgemein verfügbar und deckt komplette KI-Workflows ab

Vom Token-Mieten zur eigenen Kontrolle über den Kreislauf

Anyscale argumentiert, dass die Bezahlung pro Token bei Frontier-Modell-APIs der schnellste Weg sei, einen KI-Anwendungsfall zu validieren, aber mit Nachteilen verbunden sei. In seiner Ankündigung erklärt das Unternehmen, Teams gäben die Kontrolle über drei Dinge ab: das Modell, ihre Daten und die Kosten. Die Modell-Roadmap liege in fremden Händen, Daten müssten die Unternehmensumgebung verlassen, um das Modell zu erreichen, und die Rechnung steige linear mit der Nutzung.

Laut Anyscale stoßen KI-native Unternehmen als Erste an diese Grenzen. Ihre Antwort sei der Wechsel zu kleineren, domänenspezifischen Modellen gewesen, die mit eigenen Daten angepasst und auf eigenen GPUs betrieben werden. Das habe, so das Unternehmen, schnellere Antworten bei geringeren Kosten gebracht. Der größere Vorteil habe sich aus der kontinuierlichen Verbesserung dieser Modelle ergeben: Wer den Kreislauf kontrolliere, der Produktionsdaten in Training und Post-Training und anschließend in aktualisierte Inferenz-Deployments überführt, könne seine Modelle laufend weiterentwickeln.

Dieser Kreislauf ersetzt eine reine Inferenz-Pipeline durch mehrere Workloads, die sich GPU-Cluster teilen müssen. Anyscale zufolge wurde Ray zur gemeinsamen Laufzeit- und Orchestrierungsschicht für KI-native Teams, und die eigene Plattform macht aus Ray, einer verteilten Compute-Engine, ein unternehmenstaugliches Produkt.

So läuft es auf Azure

Azure-Kunden stellen Anyscale über das Azure-Portal bereit und betreiben produktive KI auf dem Azure Kubernetes Service (AKS) in ihrer eigenen Subscription. Abgerechnet wird wie bei jedem anderen Azure-Dienst, und die Ausgaben werden auf das bestehende Microsoft Azure Consumption Commitment (MACC) angerechnet.

Anyscale zufolge laufen die Workloads in der Subscription des Kunden, die dem Microsoft-Entra-Tenant der Organisation zugeordnet ist, und bestehende Azure-RBAC- und Azure-Policy-Kontrollen gelten unverändert. Daten, Evals, Modelle und Container-Images bleiben in der Subscription des Kunden. Das Netzwerkmodell ist ausschließlich auf ausgehenden Verkehr (Egress) ausgelegt: Jede Verbindung geht vom Anyscale-Operator und von den Ray-Clustern im AKS-Cluster des Kunden aus und führt nach außen zur Anyscale-Control-Plane, sodass keine eingehenden Firewall-Regeln geöffnet werden müssen.

Die Plattform basiert auf dem Open-Source-Projekt Ray, das von der PyTorch Foundation verwaltet wird. Da Ray Python-Code skaliert, funktioniert die Plattform laut Anyscale mit Frameworks, die Teams bereits nutzen, etwa PyTorch und vLLM, sowie mit neuen, sobald sie erscheinen.

• Datenaufbereitung für multimodale Daten wie Text, Bilder, Video und Dokumente
• Fine-Tuning und Post-Training-Verfahren, darunter Reinforcement Learning (RL)
• Modellbereitstellung über Anyscale Services, mit unterbrechungsfreien Upgrades, Skalierung auf null bei Leerlauf und Replica Compaction, um die GPU-Auslastung hoch zu halten

Das Unternehmen nennt zwei Beispiele. Auf dem Ray Summit 2026 erklärte Microsoft AI, sein Frontier-Reasoning-Modell MAI-Thinking-1 sei mit Ray trainiert worden. BMW setzte Ray zunächst für das Modelltraining ein und band es später in sein AI Gateway ein, um Inferenz für Open-Source-Modelle im gesamten Unternehmen zu betreiben.

Kampf gegen GPU-Verschwendung

Anyscale gibt an, dass die durchschnittliche GPU-Auslastung auf herkömmlicher ML-Infrastruktur im typischen Unternehmen unter 30 % liegt. Durch optimierte Planung und Orchestrierung für einzelne Workloads und über Teams hinweg erreiche man eine durchschnittliche GPU-Auslastung von über 80 %, was das Unternehmen als das Zwei- bis Dreifache an Arbeit aus derselben GPU-Flotte beschreibt. Dabei handelt es sich um Angaben von Anyscale selbst.

Auf Workload-Ebene startet die Plattform nach Unternehmensangaben so viele CPU-Worker wie nötig, um Daten parallel zu laden und vorzuverarbeiten, damit GPUs nicht untätig auf den nächsten Batch warten. Mit fraktionalen GPUs lassen sich mehr Workloads oder Modelle auf einem Gerät unterbringen. Das Autoscaling passt Ressourcen an, bevor einem Job der Speicher ausgeht, und Checkpointing startet einen fehlgeschlagenen Job ab dem letzten abgeschlossenen Schritt statt von vorn.

Über Teams hinweg fasst Anyscale isolierte Cluster zu gemeinsam genutzter Rechenleistung zusammen, die über eine zentrale Oberfläche verwaltet wird und Spot-, reservierte und On-Demand-Kapazität nutzt. Die Planung berücksichtigt Prioritäten: Trifft ein dringender Job ein, wird Arbeit mit niedrigerer Priorität pausiert statt beendet und später fortgesetzt. Im Beispiel des Unternehmens teilen sich drei Teams eine H100-Reservierung, und der Scheduler verdrängt einen Evals-Job mit niedriger Priorität, sobald ein Training mit hoher Priorität eintrifft. Der Scheduler kann Workloads zudem über Cluster und Azure-Regionen hinweg platzieren, wobei Azure der Kontrollpunkt für Identität und Richtlinien bleibt. Dasselbe Modell lasse sich auf GPU-Kapazität ausweiten, die ein Kunde außerhalb von Azure anbindet.

Was das für Unternehmen bedeutet

Für Unternehmen, die bereits auf Azure standardisiert haben, bietet die Veröffentlichung einen Weg, den gesamten Zyklus vom Training bis zur Bereitstellung unter bestehender Governance zu betreiben und gegen vorhandene Azure-Verpflichtungen abzurechnen. Anyscale verweist zudem auf einen Kostenhebel jenseits der Auslastung: Post-Training mit den eigenen Daten eines Unternehmens erlaubt den Umstieg auf kleinere, domänenspezifische Modelle, die im Betrieb weniger kosten.

Die Ankündigung zitiert Microsoft-Chairman und -CEO Satya Nadella, der Anfang des Jahres sagte: "a company should be able to use a model without giving up the knowledge that makes it unique." Anyscale präsentiert sein Azure-Angebot als Möglichkeit, diesen Gedanken umzusetzen.