Wie wird ein offenes KI-Modell zum Spezialisten für eine Aufgabe? Bei Shopify läuft das nicht über eine einzelne Modellwahl, sondern über einen Kreislauf: erst die Bewertung, am Ende reparierte Produktionsdialoge. Der Aufbau erinnert an eine Werkstatt mit eigenem Prüfstand. Zuerst wird festgelegt, was gute Arbeit ist, dann wird ausgebildet, gemessen und nachjustiert. Diese Reihenfolge verhindert, dass ein Modell nur deshalb besser wirkt, weil niemand genau geprüft hat. Am Ende steht ein günstiger Spezialist statt eines teuren Generalisten, ohne dass die Beratung der Händler darunter leidet.
Sidekick plant, Subagenten rechnen: wo die Kosten entstehen
Sidekick ist Shopifys KI-Commerce-Assistent und läuft auf einem Frontier-Modell. Es führt das Gespräch mit dem Händler, zerlegt die Aufgabe in Schritte und ruft die passenden Werkzeuge auf. Für eng umrissene Arbeiten übergibt es an Subagenten. Mehrere davon laufen auf offenen Modellen, die Shopify per Post-Training auf genau eine Aufgabe zugeschnitten hat. Post-Training heißt hier: ein fertiges Grundmodell weitertrainieren, nicht von null aufbauen.
Der GraphQL-Subagent ist das klarste Beispiel. Fragt ein Händler, welche Produkte fast ausverkauft sind, liest der Subagent das API-Schema, durchsucht die Dokumentation, schreibt eine Abfrage, führt sie aus und gibt das Ergebnis zurück. Diese Arbeit ist kontextlastig: Auf jedes geschriebene Token kommen rund vierzig gelesene, und eine Frontier-API berechnet jedes einzelne davon. Dort entstehen die Kosten, und dort setzt der Umbau an.
Qualität zuerst: ein Prüfmaßstab, dem man trauen kann
Bevor irgendein Modell trainiert wird, übersetzen Produktexperten die Anforderungen in eine Bewertungsrubrik. Für GraphQL umfasst sie Vollständigkeit, korrekte Ausführung und die Qualität der Antwort. Maßstab ist nicht der eigene Geschmack, sondern die Übereinstimmung zweier Experten bei denselben Gesprächen. Ein Sprachmodell als Prüfer, Judge genannt, wird mit den Optimierern GEPA und ACE so lange nachjustiert, bis es mit zurückgehaltenen menschlichen Bewertungen genauso gut übereinstimmt.
Ab hier bewertet der Judge jede Änderung am Agenten, jedes Kandidatenmodell und jeden Trainingslauf. Ohne diesen Schritt wäre jede Aussage über Modellqualität nur eine Meinung mit Zahlenformat. Mit ihm lässt sich Fortschritt belegen, der auch nach Monaten noch trägt.
Der Generalist als Messlatte, das offene Modell als Kandidat
Erst wird der bestehende Agent auf Frontier-Basis so weit wie möglich ausgereizt. Eine automatische Rechercheschleife schlägt jeweils eine kleine Änderung an Prompts, Werkzeugbeschreibungen oder Kontrollfluss vor und behält sie nur, wenn der Judge-Score steigt. Das Ergebnis ist die Latte, die ein offenes Modell schlagen muss. Der Vergleich ist fair, weil dieselben Werkzeuge und derselbe Prüfer gelten.
Shopify trainiert keine eigenen Grundmodelle von null. Das Team testet offene Modelle wie NVIDIA Nemotron direkt im echten Subagenten und wägt Startqualität, Antwortgeschwindigkeit im Betrieb und die Unterstützung in Megatron Bridge ab, dem Werkzeug für das Post-Training. Für GraphQL fiel die Wahl auf Nemotron 3.5 Lightning, ein Mixture-of-Experts-Modell, bei dem pro Token nur drei von dreißig Milliarden Parametern aktiv sind. Das senkt den Rechenaufwand pro Antwort, ohne die Modellgröße zu verkleinern.
Inferenz messen, bevor Trainingsaufwand entsteht
Inferenz, also das Ausführen des Modells im laufenden Betrieb, wird vom ersten Tag an gemessen. Ein Modell, das für die Produktion zu langsam ist, lohnt kein Post-Training, egal wie gut seine Bewertung aussieht. Gemessen wird mit AIPerf, einem Open-Source-Lasttester aus NVIDIA Dynamo, der Produktionsspuren mit synthetischem Text nachspielt statt mit Kundendaten. Shopify hat dazu beigetragen, dass sich auch laufende Antworten nachspielen lassen, damit Mehrrunden-Tests den Prefix-Cache des Servers so treffen wie im echten Betrieb.
Diese Messungen entscheiden über den Serving-Stack. Für den Batch-Job Buyer Profile verglich AIPerf vLLM, SGLang und NVIDIA TensorRT-LLM; TensorRT-LLM erledigte die meiste Arbeit pro GPU. Der Shopping-Simulator SimGym lief in NVIDIAs Messungen auf Blackwell B200 rund 4,5-mal schneller als auf H200, bei 1,48-fach niedrigeren Kosten. Geschwindigkeit entscheidet also mit.
Nachtschicht für kaputte Dialoge: selbstheilende Trainingsdaten
Jede Nacht zieht der Judge eine Stichprobe echter GraphQL-Gespräche, und alles, was nicht perfekt ist, geht in die Selbstheilung. Ein Frontier-Modell als Kritiker schreibt einen Hinweis, niemals die fertige Antwort. Ein simulierter Händler wiederholt die Anfrage mit diesem Hinweis gegen denselben Shop. Besteht der Judge den zweiten Versuch, wird der Hinweis entfernt, das Gespräch anonymisiert und dem Trainingsset hinzugefügt.
Scheitert der Versuch, darf der Kritiker bis zu dreimal nachbessern, danach übernehmen menschliche Annotatoren. In 86 nächtlichen Läufen reparierte das Verfahren 59.535 GraphQL-Gespräche, also 69 Prozent der Fehler, die es versucht hat. Die menschlichen Korrekturen wandern zugleich in die Referenzdaten, an denen der Judge kalibriert wird. Damit wird der Prüfmaßstab mit jedem Durchlauf schärfer.
Post-Training auf Blackwell: was die Schleife kostet und bringt
Trainiert wird mit Megatron Bridge, das Standard-Checkpoints aus Hugging Face in die Megatron-Core-Bibliothek bringt, ohne das Modell umzuschreiben. Skaliert wird über Knoten bei Nebius durch Einstellungen statt durch Codeänderungen. Auf Blackwell wird jeder Durchlauf günstiger: Beim identischen FP8-Post-Training für das Analytics-Modell waren acht B300-GPUs 1,86-mal schneller als acht H200 und brauchten 46 Prozent weniger GPU-Stunden.
Die Ergebnisse für GraphQL sind nüchtern. Aus der Box erreichte Nemotron 3.5 Lightning 37,7 Punkte auf der eigenen Bewertungsskala, das Frontier-Modell lag bei 73. Der erste Durchlauf hob den Wert auf 61,5, nach sechs Durchläufen und 61.000 geheilten Beispielen standen 74,5 Punkte. In einem Lasttest mit echter Verkehrsverteilung antwortete das nachtrainierte Modell im Median nach 0,87 Sekunden statt nach 6,50 Sekunden, und das langsamste Prozent der Anfragen war achtmal früher fertig. Ein vergleichbar großes offenes Modell lag im Median nahe heran, brauchte am oberen Rand aber mehr als doppelt so lange.
Die Betriebskosten liegen auf diesem Verkehr rund 90 Prozent unter denen der Frontier-API; über alle nachtrainierten Modelle senkt das Selbsthosting die Kosten um 90 bis 98 Prozent. Wichtiger als der Preis ist die Kontrolle: Weil die Gewichte im eigenen Haus liegen, lässt sich auf eigenen GPUs ausliefern und selbst bestimmen, wann sich ein Modell ändert. Wer solche Systeme baut, sollte den Aufwand nicht am Training messen, sondern am Prüfmaßstab und an der nächtlichen Pflege. Ohne verlässlichen Judge und eine Schleife, die aus Fehlern Trainingsmaterial macht, bleibt es beim teuren Generalisten. Der Gewinn ist deshalb kein einzelnes Modell, sondern eine Werkstatt, die gelernt hat, jedes Modell zu prüfen.
Die Zahlen sind als Shopifys eigener Produktionsbericht zu lesen. Das Unternehmen beschreibt Training, Bewertung und Betrieb auf der eigenen Infrastruktur; eine unabhängige Replikation oder ein allgemein gültiger Kostenvergleich ist damit nicht verbunden. Der Nutzen des Beispiels liegt in der Methode: reale Fehlerfälle sammeln, einen festen Prüfmaßstab bauen und ein kleines Modell eng auf eine wiederkehrende Aufgabe zuschneiden. Ob sich die genannten Einsparungen übertragen lassen, hängt von Anfragevolumen, Hardwareauslastung, Wartungsaufwand und der Stabilität der Aufgabe ab. Ein Team mit wenigen Aufrufen spart durch Selbsthosting nicht automatisch Geld. Erst wenn dieselbe Aufgabe häufig genug anfällt und sich zuverlässig bewerten lässt, trägt der zusätzliche Betriebsaufwand.
Quelle: shopify.engineering
