CoreWeave Direct-to-Expert: Kunden sitzen mit den Entwicklern in einem gemeinsamen Kanal

So funktioniert Direct-to-Expert

CoreWeave zufolge ist der Betrieb eines Trainingsclusters etwas anderes als eine Inferenz-Flotte unter realem Traffic stabil zu halten, und viele Teams müssen beides ohne eigene Expertise bewältigen. Wenn ein Job scheitert, so das Unternehmen, zeige der Fehler nicht, wo das Problem liegt. Die Untersuchung müsse Storage, Netzwerk und Scheduler durchqueren, während die Flotte stillsteht.

Direct-to-Expert läuft in einem Kanal, den sich CoreWeave mit dem Team des Kunden teilt. Ein Kunde meldet ein Problem, innerhalb von Minuten antwortet ein Mensch und zieht den Ingenieur hinzu, der für die jeweilige Ebene verantwortlich ist. Dieser Ingenieur bleibt bis zur Lösung am Fall, sodass niemand einem Neuen die Umgebung erneut erklären muss. CoreWeave sagt, die Ingenieure seien über den gesamten Stack hinweg geschult, weshalb die erste antwortende Person in der Regel auch diejenige sei, die das Problem löst.

Das Unternehmen gibt außerdem an, seit dem Training der ersten Frontier-Modelle auf diese Weise mit Frontier-Labs zu arbeiten, und wende denselben Ansatz nun auch auf Unternehmenskunden an. Nach Angaben von CoreWeave setzen 9 der 10 führenden Anbieter von Foundation-Modellen auf das Unternehmen.

Einstieg in CoreWeave ARENA, noch vor der Produktion

Die Zusammenarbeit beginnt meist schon vor einem Störfall. Für die meisten Teams startet sie in CoreWeave ARENA, das CoreWeave als strukturiertes Labor beschreibt, in dem Kunden ihre realen Modelle und Pipelines auf produktiver KI-Infrastruktur laufen lassen, begleitet von CoreWeave-Ingenieuren. Zur Umgebung gehört auch CoreWeave Forge, die vernetzte Entwicklerplattform des Unternehmens. Ziel ist es, vor dem Skalieren belastbare Daten zu Leistung, Kosten und Betrieb zu sammeln.

CoreWeave zufolge hat das Unternehmen Hunderte Tests durchgeführt, und manche enden damit, dass es einem Team mitteilt, dass seine Workload nicht benötigt, was es angefragt hat. Zum Start beantragt ein Team einen ARENA Pass, wird qualifiziert und einem Experten zugeordnet, der den Testlauf auf die Workload zuschneidet.

Brian Belgodere, Senior Technical Staff Member bei IBM, sagte, die Sandbox-Workloads des Unternehmens seien "bursty, unpredictable" gewesen, also sprunghaft und unvorhersehbar, und hätten nicht in einen Standard-Kapazitätsplan gepasst. Ihm zufolge halfen CoreWeave-Ingenieure dabei, das Design an die Anforderungen von IBM anzupassen, darunter die Skalierung der Sandboxes und das Abfangen gleichzeitiger Lastspitzen, und stimmten es auf das bestehende Netzwerk- und Zugriffssetup von IBM ab.

Onboarding, Migration und zuerst ein Mensch

CoreWeave argumentiert, dass zwischen der Buchung von Kapazität und einer laufenden Produktionspipeline Scheduler-Konfiguration, Storage-Layout, Checkpointing-Strategie und Workload-Tuning liegen. Der Ingenieur, der in ARENA den Cluster dimensioniert habe, leite das Onboarding mit dem Kunden, plane die Migration von Altinfrastruktur und bleibe bis zum Cutover dabei. Auch Monate später sei er noch die Person, die man im Kanal erreiche.

Peter Salanki, CTO von CoreWeave, brachte das teamübergreifende Argument so auf den Punkt: Ein Storage-Engpass könne sich als NCCL-Timeout äußern, weshalb die Ingenieure für Storage, Netzwerk und Scheduling gleichzeitig mit dem Kunden im selben Kanal sitzen.

CoreWeave räumt ein, dass Support branchenweit automatisiert wird, und hält das bei Fragen mit bekannten Antworten für sinnvoll. Bei KI-Workloads brauche es dagegen einen Menschen, etwa wenn ein Trainingslauf nach 40 Stunden abbricht. Das Unternehmen verweist zudem auf CoreWeave Mission Control, das nach eigenen Angaben bis auf die Siliziumebene und über jede Verbindung zwischen Knoten hinweg sieht, Fehler ohne Ticket behebt und weiß, wie vergleichbare Jobs laufen, sodass gewöhnliche Schwankungen nicht mit einer Regression verwechselt werden. Die Ingenieure gehen demnach von Live-Daten aus statt von einer Ticketbeschreibung.

Sam Braun, Member of Technical Staff bei Cohere, sagte, dass der CoreWeave-Ingenieur bereits im Thread war, habe "many hours of debugging and investigation" gespart, also viele Stunden an Fehlersuche und Analyse, und das bei Läufen, die sich das Unternehmen nicht leisten konnte zu verlieren.

Physical AI und was das für Kunden bedeutet

Bei Physical AI, Robotik und simulationslastigen Anwendungen kümmern sich laut CoreWeave Infrastrukturingenieure um Scheduler, Storage und Netzwerk, damit Fachspezialisten beim Modell oder bei der Simulation bleiben können. Über Physical AI Field Engineering arbeiten Ingenieure mit Hintergrund in Automobilbau, Luft- und Raumfahrt oder Maschinenbau direkt in den Teams der Kunden mit.

Für Kunden lautet das Versprechen: ein zentraler Ansprechpartner mit tiefem Plattformwissen, verfügbar von der Evaluierung bis in die Produktion, in den Kanälen, die sie ohnehin nutzen. Wie gut das in der Praxis funktioniert, hängt von Reaktionszeiten und Ergebnissen ab, die CoreWeave über die Aussagen von Kunden in seiner Ankündigung hinaus nicht veröffentlicht hat.