Christian Stano, Field CTO bei Anyscale – Interview-Serie

Christian Stano, Field CTO bei Anyscale, hat seine Karriere an der Schnittstelle von groß angelegter KI-Infrastruktur, Machine-Learning-Plattformen und verteilter Rechnung aufgebaut. Bevor er zu Anyscale kam, leitete er die AI/ML-Plattform-Organisation bei Attentive, wo er die Infrastruktur für die Personalisierung von über einer halben Milliarde Abonnenten skalierte und half, die Übernahme von Ray-basierten Einheitsrechnungssystemen voranzutreiben, die die Entwicklungszeit verkürzten und die Betriebskosten reduzierten. Früher in seiner Karriere arbeitete er in den Bereichen Cybersicherheit, Cloud-Architektur und öffentliche AI-Initiativen bei Organisationen wie Coalfire und Deloitte, wo er zu einem der ersten Machine-Learning-Plattformen des US-Verteidigungsministeriums beitrug. Sein Hintergrund umfasst AI-Plattform-Engineering, MLOps, cloud-natürliche Infrastruktur, Entwickler-Enablement und organisatorische Skalierung, was ihm tiefgreifende Erfahrungen bei der Unterstützung von Unternehmen bei der Operationalisierung von KI im Produktionsmaßstab gibt.

Anyscale ist das Unternehmen hinter Ray, dem Open-Source-Verteilter-Rechnungs-Framework, das weit verbreitet für die Skalierung von KI- und Python-Workloads auf Clustern von CPUs und GPUs verwendet wird. Gegründet von den ursprünglichen Erfindern von Ray von der UC Berkeley’s RISELab, konzentriert sich das Unternehmen auf die Vereinfachung der Bereitstellung, Orchestrierung und Verwaltung von groß angelegter KI-Infrastruktur für Training, Inferenz, Datenverarbeitung und agente KI-Workloads. Seine Plattform ermöglicht es Organisationen, verteilte KI-Systeme in Cloud- und On-Premises-Umgebungen auszuführen, während sie Beobachtbarkeit, Governance und Leistungsoptimierungen für moderne KI-Anwendungen bieten. Ray ist zu einer Kernschicht in der aufkommenden KI-Infrastruktur-Stack geworden, die Entwicklern hilft, Workloads von einem einzelnen Rechner auf Tausende von Knoten mit minimalen Änderungen an bestehendem Python-Code zu skalieren.

Sie haben in den Bereichen Cybersicherheit, öffentliche ML-Plattformen und hyperskalige Personalisierungssysteme gearbeitet. Welche Muster haben Sie bei Organisationen beobachtet, die von KI-Piloten in die Produktion übergehen?

Über Branchen hinweg treten drei Muster regelmäßig auf. Erstens haben Teams keinen zuverlässigen, gepflasterten Weg von der Entwicklung zur Produktion. Sie können ein Modell in einem Notebook erstellen, aber es gibt keinen standardisierten Weg, es in der Produktion auszuführen. Jede Bereitstellung wird zu einem Einzelstück, und jeder Fehler ist eine Überraschung. Zweitens kann die Infrastruktur nicht mit den Bedürfnissen skaliert werden. Das System, das im Piloten funktioniert hat, bricht zusammen, wenn man es mit realen Datenmengen oder realen Verkehr füttert. Drittens fliegen Teams blind. Ihnen fehlt die Beobachtbarkeit, um zu wissen, wie ihre Systeme tatsächlich funktionieren, wo sie zusammenbrechen werden und wann man eingreifen muss.

Was alle drei verbindet, ist die gleiche Wurzelherausforderung – Teams haben kein solides mentales Modell für die Skalierung. Sie versuchen, alles auf einmal zu lösen, anstatt sich darauf zu konzentrieren, die Sequenzierung zu priorisieren. Ich denke darüber nach in drei Phasen: es funktioniert machen, es richtig machen, es schnell machen. Diese Phasen sind nicht einmalige Meilensteine – diese Phasen sind iterativ. Man priorisiert ständig zwischen dem, was gerade kaputt ist, und dem, was als nächstes kaputt gehen wird. Die Teams, die erfolgreich sind, wissen, in welcher Phase sie sind und bleiben diszipliniert, ohne voranzuschreiten, bevor die Grundlage solide ist.

Bei Anyscale sehen wir Teams, die in jedem Stadium hereinkommen. Einige versuchen noch, es zum Laufen zu bringen – sie benötigen einen zuverlässigen Weg von der Entwicklung zur Produktion. Andere haben das, aber ertrinken in operativer Komplexität und benötigen es, um es richtig zu machen. Und viele kommen zu uns, weil sie etwas aufgebaut haben, das funktioniert, aber es nicht auf die Skala bringen können, die das Geschäft fordert. Eine einheitliche Rechenebene hilft in jeder Phase, aber der Einstiegspunkt hängt davon ab, wo der Schmerz am schärfsten ist.

Bei Attentive halfen Sie dabei, KI-Systeme zu skalieren, die Hunderte von Millionen von Nutzern unterstützten. Was waren die größten architektonischen oder organisatorischen Flaschenhälse, die Sie überwinden mussten, um dieses Maß an Skalierbarkeit zu erreichen?

Der größte Flaschenhals war die S-Kurve der Infrastrukturkomplexität. Als wir unsere Modelle dazu brachten, mehr Daten zu integrieren und mehr Kunden zu bedienen, trafen wir auf einen Rechen-Inflektionspunkt, an dem sogar die größten vertikal skalierten Knoten Out-of-Memory-Fehler auswarfen und naive horizontale Skalierung nicht ausreichte. Unsere Rechenleistung konnte nicht mit der Skala unserer Daten mithalten.

Die natürliche Reaktion war, mehr Tools aufzuschichten, um die Grenzen zu umgehen. Das war mein internes Spielbuch aus vorheriger Erfahrung. Jedes Tool löste ein enges Problem, fügte aber operative Komplexität hinzu. Unser ML-Pipeline drohte, ein Flickwerk aus Integrationen zu werden, und jeder neue Anwendungsfall bedeutete mehr Flickwerk, mehr Fehlermodi, höhere Kosten und mehr Overhead für das Plattform-Team.

Was letztendlich die Skalierbarkeit für uns entriegelte, war die Vereinigung von Datenverarbeitung, Training, Inferenz und Bedienung auf Ray und Anyscale. Die Auswirkung war sofortig: mit dramatisch niedrigeren Infrastrukturkosten, deutlich schnelleren Trainingszyklen, auch als die Datenmengen wuchsen, und der Fähigkeit, Modelle auf das Zehnfache mehr Kunden zu skalieren.

Was motivierte Ihre Entscheidung, Anyscale bei diesem Stadium beizutreten, und wie sehen Sie die Rolle des Field CTO bei der Gestaltung der Unternehmens-KI-Adoption?

Meine Erfahrung, Anyscale bei Attentive einzuführen, hat mein Spielbuch für den Aufbau von ML-Plattformen grundlegend geändert. Vorher war ein erheblicher Teil des Plattform-Engineerings der Kosten für das Zusammennähen von fragmentierten Systemen. Mit Anyscale konnten wir viel von diesem Overhead eliminieren und uns stattdessen auf die Entwicklererfahrung, Zuverlässigkeit und Leistung konzentrieren. Diese Verschiebung hatte einen enormen Einfluss auf die Team-Produktivität und die System-Ergebnisse. Der Beitritt zu Anyscale war eine Gelegenheit, an diesem Problem Vollzeit zu arbeiten und anderen Organisationen zu helfen, den gleichen Übergang zu meistern. Als Field CTO ist meine Rolle wirklich darin, diese realen Lektionen in wiederholbare Muster zu verwandeln, die unsere Kunden anwenden können, wenn sie KI skalieren.

Viele Unternehmen stecken noch in der “Pilot-Phase” von KI. Aus Ihrer Perspektive, was bricht speziell, wenn Unternehmen diese frühen Experimente in Produktions-Systeme skalieren?

Wenn Unternehmen von KI-Experimenten in die Produktion übergehen, bricht selten nur das Modell – es bricht das umgebende System und die Operationen. In einigen Fällen stoßen Teams früh an Infrastruktur-Grenzen und können nicht im gewünschten Maß trainieren oder bedienen. Sie müssen die Anzahl der Kunden oder Anwendungsfälle, die ihr Modell bedient, begrenzen. Häufiger treten Probleme in der Produktion durch unerwartete Randfälle oder Änderungen in den Daten auf. Einer der häufigsten Fehlerpunkte ist der Speicher: Wenn die Daten-Größe, -Verteilung oder -Modalität sich ändert, laufen Jobs aus dem Speicher und brechen ab. Diese Probleme sind schwer vorherzusagen und noch schwerer, automatisch wiederherzustellen. Die Realität ist, dass der Fehler in der Produktions-KI unvermeidlich ist. Das Ziel ist nicht, ihn vollständig zu vermeiden, sondern ihn schnell zu erkennen, zu verstehen und selbstheilende Systeme zu bauen, um ihn zu lösen, bevor er das Geschäft beeinträchtigt.

Ray, das verteilte Rechen-Framework, das von dem Team hinter Anyscale erstellt wurde, gewinnt an Zugkraft als Grundlage für KI-Workloads. Warum wird die verteilte Ausführung zu einer so kritischen Schicht in der modernen KI-Infrastruktur?

Die verteilte Ausführung und die Workload-Verwaltung sind zu einem Muss für KI-Pipelines geworden. Moderne KI-Workloads sind von Natur aus parallel und ressourcenintensiv. Training, Inferenz und Datenverarbeitung erfordern alle die Koordination großer Mengen von Aufgaben über CPUs und GPUs, oft dynamisch. In der heutigen Rechen-Landschaft ist die Komplexität der Verwaltung dieser Workloads über knappe Ressourcen eine massive operative Belastung. Traditionelle Systeme wurden nicht für diese Komplexität oder Skalierbarkeit konzipiert. Frameworks wie Ray sind kritisch, weil sie es Teams ermöglichen, Workloads nahtlos von einem einzelnen Rechner auf Tausende von Knoten zu skalieren, indem sie die zugrunde liegende Koordination automatisieren. Diese Verschiebung spiegelt einen umfassenderen Trend zur KI-nativen Rechnung wider, bei der die Infrastruktur speziell für die Muster von KI-Workloads und nicht aus älteren Paradigmen adaptiert wird.

Wenn mehr Unternehmen Ray über die Plattform von Anyscale adoptieren, welche Unterschiede sehen Sie zwischen Organisationen, die auf eine einheitliche Herangehensweise standardisieren, und solchen, die fragmentierte Tools zusammenfügen?

Der Unterschied zwischen einheitlichen Plattformen und fragmentierten Tools kommt letztendlich auf Fokus und Effizienz an. Wenn Teams auf mehrere unabhängige Systeme angewiesen sind, verbringen sie viel Zeit damit, diese Systeme zusammenzufügen, Inkonsistenzen zu verwalten und auf Fehler in verschiedenen Umgebungen zu reagieren. Dies schafft operative Overhead und verlangsamt die Experimentierung. Im Gegensatz dazu ermöglicht eine einheitliche Herangehensweise es Teams, ihre Bemühungen auf die Verbesserung eines einzigen Systems zu konzentrieren, was zu besserer Zuverlässigkeit, stärkerer Leistung und einer gestrafften Entwicklererfahrung führt. Es vereinfacht auch die On-Call- und Debug-Prozesse, da Muster konsistent und einfacher zu verstehen sind. Das Ergebnis ist nicht nur technische Effizienz, sondern auch organisatorische Klarheit.

Basierend auf Ihrer Erfahrung beim Aufbau von End-to-End-ML-Plattformen, wie wichtig ist die Entwicklererfahrung (DevEx) für die Beschleunigung der KI-Adoption in Teams?

Die Entwicklererfahrung ist einer der höchsten Hebel für die Beschleunigung der KI-Adoption. Wenn Plattform-Teams in die Verbesserung der Systeme investieren, um sie durch standardisierte Workflows, Vorlagen und reduzierten Infrastruktur-Friction einfacher zu machen, verstärken sie die Produktivität jedes Ingenieurs in der Organisation. Dies ist besonders wichtig in der KI, wo der Wandel sehr schnell ist und Teams schnell iterieren müssen, um wettbewerbsfähig zu bleiben. Verbesserungen in der Entwicklererfahrung übersetzen sich direkt in schnellere Experimentierung, schnellere Zeit bis zur Produktion und letztendlich mehr Geschäftsauswirkungen. KI-Coding-Tools verstärken diese DevEx-Grundlagen. Auf viele Weise ist es der skalierbarste Weg, um die Geschwindigkeit in einer Organisation zu erhöhen.

Kosten-Effizienz wird zu einer großen Sorge, wenn KI-Workloads skaliert werden. Welche sind einige der am meisten übersehenen Möglichkeiten, wie Unternehmen Infrastrukturkosten ohne Leistungs-Einbußen reduzieren können?

Wenn KI-Workloads skaliert werden, wird die Kosten-Verwaltung sowohl wichtiger als auch komplexer. Eine der am meisten übersehenen Herausforderungen ist, wie schnell Kosten aufgrund von Ineffizienzen, insbesondere bei GPU-basierten Infrastrukturen, spiralisieren können. Große Cluster können Tausende von Knoten starten, und wenn Ressourcen nicht ordnungsgemäß verwaltet oder beendet werden, kumulieren die Kosten schnell. Dies schafft eine Art KI-spezifische Ausbreitung, bei der die Rechen-Nutzung schneller wächst, als Teams sie verfolgen oder kontrollieren können. Die Lösung erfordert eine Kombination aus starker Governance, Sichtbarkeit und Automatisierung, wie z.B. Auto-Skalierung, Auto-Beendigung und zentrale Ressourcen-Verwaltung. Im großen Maßstab ist Kosten-Effizienz nicht nur eine operative Sorge, sondern ein fundamentaler Teil des System-Designs.

Sie haben an allem gearbeitet, von Feature-Stores bis hin zu Echtzeit-Schluß-Systemen. Wie denken Sie, dass sich das Gleichgewicht zwischen Batch- und Echtzeit-KI-Workloads entwickelt?

Das Gleichgewicht zwischen Batch- und Echtzeit-KI-Workloads hat sich nicht grundlegend geändert – es bleibt eine Frage der Geschäftsanforderungen. Batch-Verarbeitung ist typischerweise kostengünstiger und einfacher zu betreiben, was sie für viele Anwendungsfälle geeignet macht. Echtzeit-Systeme sind dagegen unerlässlich, wenn die Latenz direkt die Benutzererfahrung oder das Geschäftsergebnis beeinträchtigt, wie in Chat-Anwendungen oder Betrugs-Erkennung. Beide Ansätze werden weiterhin koexistieren, und der Schlüssel für Organisationen ist, Plattformen aufzubauen, die beide effektiv unterstützen können. Die Entscheidung kommt letztendlich auf Kompromisse zwischen Kosten, Latenz und Zuverlässigkeit an.

Wenn man in die Zukunft blickt, wie sieht eine “reife” Unternehmens-KI-Plattform in 2-3 Jahren aus – und wie passen Tools wie Ray und Plattformen wie Anyscale in diese Zukunft?

In den nächsten Jahren werden reife Unternehmens-KI-Plattformen durch einige Schlüsselmerkmale definiert. Sie werden auf einer einheitlichen Infrastruktur basieren, die den gesamten KI-Lebenszyklus unterstützt, von der Datenverarbeitung bis zum Training und zur Inferenz, anstatt eine Sammlung von unabhängigen Tools. Sie werden starke Day-2-Operationen haben, mit agenten-automatisierter Beobachtbarkeit, Zuverlässigkeit und schneller Fehlersuche. Kosten-Verwaltung wird vorhersehbar und reguliert sein, was es Organisationen ermöglicht, nachhaltig zu skalierten. Und vielleicht am wichtigsten: Sie werden hohe Entwickler-Geschwindigkeit ermöglichen, was es Teams ermöglicht, von der Idee zur Produktion schnell zu gelangen. Plattformen wie Ray und Anyscale spielen eine zentrale Rolle in dieser Zukunft, indem sie die KI-nativen Grundlagen liefern, die dieses Maß an Skalierbarkeit und Effizienz ermöglichen.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Anyscale besuchen.