Warum Compute-Kosten eine Produktkennzahl sind, keine Ops-Fußnote
Der Abhängigkeitsgraph eines KI-Produkts beginnt nicht mit Features oder UX, sondern mit dem Preis einer einzelnen Inferenz. Dollar pro Anfrage, Millisekunden pro Token – diese Zahl bestimmt, welche Modelle tragfähig sind, welche Features ausgeliefert werden und welche im nächsten Sprint gestrichen werden. Compute als reines Backend-Problem zu behandeln, ist der schnellste Weg zu einem Produkt, das bei jeder Interaktion Geld verliert.
Betrachten Sie einen Echtzeit-Dokumentenzusammenfasser. Ein 7B-Parameter-Modell auf einer einzelnen T4-GPU kann schnell genug für die Aufmerksamkeitsspanne eines Nutzers bleiben, bei Kosten pro Anfrage von Bruchteilen eines Cents. Ein 70B-Modell auf derselben Hardware? Mehrere Sekunden, höhere Kosten und ein Produkt, das sich kaputt anfühlt, bevor es seinen ersten Satz beendet. Die Compute-Einschränkung betraf nicht nur das Backend – sie definierte die Form des Produkts vollständig.
Wie Latenz-Budgets die Modellauswahl und den Feature-Umfang bestimmen
Jedes benutzerorientierte KI-Feature hat ein Latenz-Budget. Dieses Budget ist kein technisches Ziel; es ist eine Produktbeschränkung, die den Modellsuchraum eingrenzt. Wenn Ihre App schnelle Antworten für eine Chat-Oberfläche benötigt, werden Sie kein großes Parameter-Modell betreiben. Sie quantisieren, prunen oder destillieren auf etwas, das in das Zeitfenster passt.
Der MLCommons Inference Datacenter Benchmark existiert genau deshalb, weil Latenz und Durchsatz keine abstrakten Zahlen sind – sie sind der Unterschied zwischen einem Feature, das sich nativ anfühlt, und einem, das sich anfühlt wie das Warten auf das Laden einer Seite im Jahr 1998. Der Benchmark misst reale Serving-Bedingungen, nicht theoretische Spitzen-Flops. Produktteams, die diese Zahlen ignorieren, landen bei Features, die in Demos funktionieren und in der Produktion scheitern.
Die versteckten Kosten von Batch-Inferenz und Kaltstarts
Batch-Inferenz sieht auf Kosten-pro-Token-Basis effizient aus. Aber Batching führt zu Latenz, die interaktive Features tötet. Eine Empfehlungs-Engine, die Anfragen schnell bündelt, fühlt sich reaktionsschnell an. Eine, die langsam bündelt, fühlt sich an, als ob das System zu viel nachdenkt.
Kaltstarts verschärfen das Problem. Serverlose GPU-Endpunkte, die zwischen Anfragen herunterfahren, sparen Geld, fügen aber spürbare Kaltstart-Latenz hinzu. Das funktioniert für Hintergrundjobs. Es tötet benutzerorientierte Features. Die Produktentscheidung ist nicht „Können wir dieses Modell servieren?“, sondern „Können wir dieses Modell innerhalb des Geduldsfensters des Nutzers zu einem für uns tragbaren Preis servieren?“.
Wann für Durchsatz vs. Latenz optimieren
Ein einfacher Entscheidungsrahmen: Wenn der Nutzer wartet, optimieren Sie für Latenz. Wenn der Nutzer nicht wartet, optimieren Sie für Durchsatz.
- Benutzerorientierter Chat, Suche, Zusammenfassung: Latenz zuerst. Akzeptieren Sie höhere Kosten pro Anfrage, um Antwortzeiten unter einer Sekunde zu halten. Quantisieren Sie Modelle, verwenden Sie kleinere Architekturen oder betreiben Sie dedizierte Endpunkte.
- Hintergrund-Datenpipelines, Batch-Verarbeitung, nächtliche Berichte: Durchsatz zuerst. Maximieren Sie Tokens pro Dollar. Batchen Sie aggressiv, verwenden Sie größere Modelle, tolerieren Sie Kaltstarts.
Der Fehler besteht darin, Durchsatzlogik auf latenzempfindliche Features anzuwenden. So liefern Sie ein Produkt aus, das zu viel kostet und sich zu langsam anfühlt – das Schlimmste aus beiden Welten.
Serving-Infrastruktur als Produkthebel
Die Wahl zwischen Edge, Cloud und On-Premises ist keine Ops-Entscheidung. Es ist ein Produkthebel, der Latenz, Datenschutz und Kostenstruktur beeinflusst.
Edge-Inferenz hält Daten lokal und die Latenz niedrig, begrenzt aber die Modellgröße und erfordert Hardware-Bereitstellung. Cloud-Inferenz skaliert elastisch, führt aber Netzwerklatenz und Datenübertragungskosten ein. On-Premises gibt volle Kontrolle, erfordert aber Kapitalausgaben und Kapazitätsplanung.
Jede Option ändert das Wertversprechen des Produkts. Ein medizinisches Bildgebungstool, das auf dem Gerät verarbeitet, kann Null-Datenabfluss behaupten. Ein Kundendienst-Chatbot, der auf Cloud-Endpunkten läuft, kann auf Millionen von Gesprächen skalieren, muss aber die Inferenzkosten in der Preisgestaltung pro Sitz berücksichtigen. Die Infrastrukturentscheidung ist die Produktentscheidung.
Praktische Schritte zur Überprüfung der Compute-Sensitivität
- Messen Sie die Kosten pro Anfrage in der Produktion, nicht in einem Notebook. Verwenden Sie echte Verkehrsmuster, nicht synthetische Benchmarks.
- Legen Sie ein Latenz-Budget pro Feature fest, bevor Sie das Modell auswählen. Wenn das Budget knapp ist, bewerten Sie keine Modelle, die es nicht einhalten können.
- Profilieren Sie das Kaltstartverhalten für serverlose Endpunkte. Wenn Kaltstarts die Geduld der Nutzer überschreiten, wärmen Sie vor oder wechseln Sie zu dedizierten Instanzen.
- Quantisieren oder destillieren Sie vor der Skalierung. Ein quantisiertes kleineres Modell erreicht oft ein größeres Modell in Bezug auf Latenz und Kosten bei akzeptabler Qualität.
- Modellieren Sie die Serving-Kosten als COGS-Posten, nicht als Cloud-Rechnungsposten. Wenn die Inferenzkosten den Umsatz des Features übersteigen, ist das Feature nicht tragfähig.
Compute-Constraints sind kein Backend-Problem, das später gelöst wird. Sie sind die erste Produktbeschränkung, und sie zu ignorieren bedeutet, auf einem Abhängigkeitsgraphen aufzubauen, der nicht halten wird.
