Selbst betreiben oder aufrufen: die Frage hinter der Modellwahl
Alle paar Monate fragt ein Kunde, ob er das Modell selbst betreiben soll. Die Frage handelt fast nie von Leistungsfähigkeit, und sie so zu beantworten ist der Weg, auf dem Organisationen Infrastruktur betreiben, die sie nie wollten.
Wie die Frage ankommt
Sie kommt meist als technischer Vergleich: Ist das offene Modell gut genug? Bis Januar 2024 war diese Rahmung weitgehend uninteressant geworden, denn für die begrenzte Arbeit, die die meisten Geschäftssysteme leisten, waren mehrere offene Modelle offenkundig gut genug — und der verbleibende Abstand lag nicht dort, wo diese Kunden arbeiten.
Worum es tatsächlich geht, sind Kontrolle, Kosten bei Menge und der Verbleib der Daten. Das sind drei verschiedene Gespräche mit drei verschiedenen Antworten, und sie zu einer Leistungsfrage zu verschmelzen erzeugt eine Entscheidung, die ein halbes Jahr später niemand mehr vertreten kann.
Was sich im Feld geändert hat
Jiang und Kollegen veröffentlichten in jenem Januar Mixtral of Experts, ein spärlich besetztes Mixture-of-Experts-Modell, dessen freigegebene Gewichte starke Leistungsfähigkeit für jeden erreichbar machten, der bereit ist, es zu betreiben. Das architektonische Interesse ist echt, die Wirkung auf unsere Gespräche war jedoch kaufmännischer Natur.
Sobald ein glaubwürdiges offenes Modell existiert, hört Eigenbetrieb auf, ein Kompromiss zu sein, für den man argumentiert, und wird zu einer Option, die man ehrlich bewerten muss. Das ist die bessere Ausgangslage und zugleich mehr Arbeit, denn die ehrliche Bewertung handelt nicht von Benchmark-Werten.
Die vier Punkte, die wir abwägen
Datenhaltung zuerst, denn sie kann die Diskussion beenden. Darf ein Kunde die Daten aus regulatorischen Gründen nicht aus der eigenen Infrastruktur geben, ist Eigenbetrieb keine Vorliebe, und die restlichen Fragen betreffen das Wie statt das Ob.
Dann Menge, Latenz und Betriebsfähigkeit. Die Menge entscheidet, ob Preis je Aufruf oder feste Infrastruktur günstiger ist. Die Latenz entscheidet, ob ein Netzwerksprung vertretbar ist. Die Betriebsfähigkeit entscheidet, ob überhaupt jemand erreichbar ist, wenn ein GPU-Knoten zur Unzeit ausfällt — und genau diese Frage beantworten Kunden am häufigsten zu optimistisch.
| Spricht für Eigenbetrieb | Spricht für einen Dienst |
|---|---|
| Daten dürfen die Umgebung nicht verlassen | Keine Auflage zur Datenhaltung |
| Hohe gleichmäßige Menge | Schwankende oder geringe Menge |
| Vorhandenes Plattformteam mit Rufbereitschaft | Niemand, den man nachts rufen kann |
| Eine feste Modellversion ist vorgeschrieben | Verbesserungen des Anbieters sind willkommen |
Was Eigenbetrieb wirklich kostet
Die Rechenleistung ist der Teil, den alle schätzen, und selten der, der wehtut. Weh tut, dass ein selbst betriebenes Modell zu einer Komponente mit Rufbereitschaft wird: Versionswechsel, Kapazitätsplanung, ein Rückfallweg und jemand, der versteht, warum der Durchsatz nach einem Treiberwechsel eingebrochen ist.
Wir stellen eine Frage, die das meist klärt. Wenn dieser Knoten sonntags um zwei Uhr ausfällt — wer wird geweckt, und was tut er dann? Gibt es darauf keine gute Antwort, raten wir ab, unabhängig davon, wie attraktiv die Rechnung je Token auf einer Folie aussieht.
Wo wir ohne Zögern dazu raten
Der erste Fall ist regulatorisch: Daten, die wirklich nicht heraus dürfen, wo die Alternative wäre, das System gar nicht zu bauen. Dann ist der Betriebsaufwand schlicht der Preis der Fähigkeit, und das Gespräch dreht sich darum, diesen Aufwand so klein wie möglich zu halten.
Der zweite ist hohe gleichmäßige Menge auf einer schmalen Aufgabe. Ein Klassifikationsschritt, der monatlich millionenfach gegen einen stabilen Prompt läuft, ist genau dort, wo feste Infrastruktur den Preis je Aufruf schlägt — und genau dort, wo ein kleines Modell auf bescheidener Hardware genügt, was die Betriebsfläche klein hält.
Die Mischform, die wir am häufigsten bauen
In der Praxis machen die meisten Systeme, die wir ausliefern, beides. Die mengenstarken begrenzten Schritte laufen auf etwas Kleinem im Eigenbetrieb, das offene Schlussfolgern ruft ein gehostetes Spitzenmodell auf. Der Schnitt folgt der Arbeit, nicht einer Richtlinie.
Damit das handhabbar bleibt, braucht es eine Disziplin: Jeder Modellaufruf läuft über eine Schnittstelle mit einer benannten Fähigkeit statt mit einer Modellkennung. Welches Modell welche Fähigkeit bedient, ist Konfiguration — ein Schritt lässt sich also zwischen gehostet und selbst betrieben verschieben, ohne etwas neu zu schreiben.
Was wir früher falsch gemacht haben
Wir haben das früher als Kostenoptimierung behandelt und mit der Rechnung eröffnet. Das war ein Fehler, denn Vergleiche je Token ignorieren die Personalkosten und fallen deshalb immer zugunsten des Eigenbetriebs aus — so redet man einem Kunden ein Plattformteam ein, das er nicht eingeplant hatte.
Wir eröffnen heute mit Datenhaltung und Betriebsfähigkeit und kommen erst auf Kosten, wenn diese beiden das Feld eingeengt haben. Die Gespräche sind kürzer, und die Entscheidungen haben länger gehalten.
Was wir nicht behaupten
Wir behaupten nicht, offene und gehostete Modelle seien austauschbar. Für die schwierigste Schlussfolgerungsarbeit liegen die Spitzenmodelle weiter vorn, und ein System, dessen Qualität an diesem Abstand hängt, sollte nicht aus Betriebsbequemlichkeit verschoben werden.
Wir behaupten auch nicht, unsere vier Kriterien seien vollständig. Lizenzbedingungen spielen für manche Kunden eine Rolle, ebenso die politische Frage der Anbieterabhängigkeit — ein berechtigtes Anliegen, das wir schlecht stellvertretend abwägen können.