Eigentlich wollte ich nach knapp sechs Monaten selbst gehosteter Inferenz eine Kostenaufstellung machen. Habe ich etwas gespart, oder zahle ich drauf? Es ist nicht lösbar. Die vier Sparks haben ganz andere Probleme gelöst, als ich ihnen zugedacht hatte. Außerdem sind sie zwischenzeitlich massiv im Preis gestiegen. Alles Dinge, die eine seriöse Berechnung, ob es sich gelohnt hat und wann der Breakeven kommt, völlig absurd erscheinen lassen.
Das ist kein Messfehler. Das ist der eigentliche Befund.
Wo der Zähler sitzt
Ich werde oft gefragt, wann sich selbst gehostete Inferenz rechnet. Meine Antwort: sofort und nie.
Klar, stehen die Sparks ungenutzt im Rack, bringen sie nichts. Stehen sie dauernd unter Volllast und ersetzen Cloud-Anfragen, rechnen sie sich sehr schnell. Aber das ist verkürzt gedacht. Der Tokenzähler und das Abrechnen pro einer Million Token verändern das Verhalten.
Würde bei SQL jede Query kosten, würde man ganz anders programmieren und sich sogar überlegen, was man überhaupt in der Datenbank abspeichert. Oder ein Laptop: Würde ich pro Tastenanschlag zahlen, müsste ich mir auch überlegen, was ich überhaupt tippe.
Der Zähler verändert nicht die Kosten. Er verändert, was gebaut wird.
Was ich deshalb tue und was nicht
Wenn man sich selbst Inferenz aufbaut, hat man zu Beginn meist keine Dienste, die produktiv darauf laufen. Einzig, wenn man schon etwas hat, das mit der Cloud läuft und das man dann ablöst. Sonst sind die Maschinen anfänglich eher unterbeschäftigt. Man beginnt, Testsuiten zu bauen und solche Dinge. Kostet ja nichts, kann man schön die Grenzen der Modelle ausloten. Das Invest trägt sich, gefühlt.
Mit der Zeit beginnt man, Dienste darauf aufzubauen. Einen nach dem anderen. Da man die Inferenz hat, ist man gerne gewillt, sie auch sinnvoll einzusetzen. Da sie schon bezahlt ist, wird hier auch nicht gespart. Manchmal ist es weniger sinnvoll, manchmal mehr. Aber es gibt keine Schranke zu Beginn, wo man sich überlegt: Brauche ich das überhaupt, kostet ja doch Tokens.
Die Knappheit ist nicht weg, sie hat die Währung gewechselt
Irgendwann laufen dann produktive Dienste auf der eigenen Inferenz, und in dem Moment stampft man Dinge wie Evals wieder ein.
Der Grund ist nicht Sparsamkeit, sondern Kapazität. Ein Eval-Lauf nimmt einem produktiven Request die GPU weg. Genau das ist der Punkt: In der Cloud konkurriert der Eval mit dem Budget, bei mir konkurriert er mit dem laufenden Betrieb. Und die Rechnung kommt am Monatsende, die Rechenzeit ist sofort weg. Die Knappheit ist also nicht verschwunden. Sie hat nur die Währung gewechselt: In der Cloud ist Kapazität unendlich und Geld knapp, bei mir ist Geld fix und Kapazität knapp. Gleiche Disziplin, anderer Zähler.
Dazu kommt: Evals machen ohnehin schon genug andere. Und man kommt dahinter, dass sie gar nicht so entscheidend sind. Die Modelle sind sich in ähnlichen Größen oft doch ähnlicher, als das Marketing verspricht.
Was das Kostenrisiko in der Cloud wirklich verhindert
Wenn Tokens einem selbst in der Entwicklung und im Betrieb Geld kosten, und sei es auch noch so wenig, ist man geneigt, ein Feature, das sich nicht schon von der Idee her trägt, gar nicht erst zu entwickeln. Es verursacht ja Kosten.
Allerdings war kaum ein Feature bei mir am Anfang der Heilsbringer. Es hat gedauert, es hat sich entwickelt, und nach mehreren Iterationen und Weiterentwicklungen war es auf einmal richtig hilfreich. Hätte ich das mit der Cloud gemacht, hätte ich es vermutlich nie umgesetzt.
Das ist der Kern: Das Kostenrisiko verhindert keine Ausgaben. Es verhindert Features. Man kann den Nutzen nicht kennen, bevor man gebaut hat, muss ihn aber vorher rechtfertigen. Also baut man nicht.
Ein Beispiel dazu. Ich hatte einfach aus Spaß und Interesse ein Feature gebaut, bei dem mir das LLM Vorschläge machen soll, was sich an einer Website noch verbessern lässt. Anfänglich war das schlicht unbrauchbar. Dann sind mehr Auswertungen und mehr Daten dazugekommen. Mit der Zeit hat es immer besser funktioniert, und mittlerweile ist es ein richtig gutes Feature, das wirklich brauchbare Ergebnisse liefert.
Zwei Dinge daran sind bemerkenswert. Erstens: Besser wurde es nicht durch bessere Prompts, sondern durch mehr Kontext. Zweitens, und das ist der Punkt: In der Cloud wäre dieses Feature nach der ersten Version gestorben. Nicht weil es zu teuer gewesen wäre, sondern weil ich nach einem unbrauchbaren Ergebnis den Token-Zähler gesehen und die Sache eingestellt hätte. Es hätte nie die Chance gehabt, gut zu werden. Und man kann einem Feature nicht ansehen, was es nach zehn Iterationen ist.
Ehrlich dazu: Risikofrei ist das lokal auch nicht. Nur ist das Risiko begrenzt. In der Cloud ist es eine Rechnung ohne Deckel nach oben, bei mir wird es im schlimmsten Fall langsamer. Mit begrenzter Verschlechterung kann man leben, mit unbegrenzten Rechnungen plant man defensiv.
Eine Kategorie zu groß
Features entwickeln sich dank Programmier-Agenten brutal schnell weiter. Das ist die entscheidende Beobachtung. Ein Feature, das anfänglich mit einem kleinen Modell auskommt, wird weiterentwickelt, und dann reicht das kleine Modell bei Weitem nicht mehr, weil es von Anfang an knapp war.
In einer produktiven Umgebung ein Modell einzusetzen, das eine Aufgabe gerade halt mal so schafft, ist deshalb viel zu riskant. Es braucht Puffer.
Gefühlt nehme ich immer eine Nummer zu groß. Sollte ein 9B die Aufgabe schaffen, kommt ein 35B zum Einsatz. Bin ich mir beim 35B nicht sicher, wird es das 397B. Genug Reserven, und wenn sich das Modell im Hintergrund ändert, läuft die Aufgabe sehr wahrscheinlich immer noch korrekt. Das ist im Grunde nichts anderes als der Sicherheitsfaktor in der Statik oder beim Kabelquerschnitt: Niemand dimensioniert auf exakt die Last, die draufkommt. Und niemand fährt einen Server auf hundert Prozent.
Was das praktisch bringt: keine Timeouts mehr. Ruhige Versionswechsel. Eingaben, an die ich nie gedacht habe, werden geschluckt. „Sollte besser sein" ist mit Reserve egal und an der Grenze existenziell.
Warum ich kaum noch Prompt Engineering mache
Gerade am Anfang legt man jedes Wort im Prompt auf die Waagschale. Man testet: Geht es mit einer geänderten Anweisung? Was muss ich ändern, damit es endlich läuft? Man dreht Runde um Runde, um den Prompt so lange zu schärfen, bis es doch irgendwie funktioniert.
Ich spare mir das mittlerweile. Ich greife im Regal einfach zur nächstgrößeren Kategorie, und es funktioniert.
Denn was ich da eigentlich gemacht habe, war kein Prompt Engineering. Es war Kompensation für ein zu knapp gewähltes Modell. Man kann mit einem Prompt einem Modell keine Fähigkeit beibringen, die es nicht hat. Ein Prompt ist Format, Fokus und Verhalten, mehr nicht. Wer Reserve hat, muss nicht schärfen. Meist ist ein kurzer, klarer Prompt ohnehin die bessere Wahl. Mehr Puffer und mehr Resilienz in einer Zeit, in der sich gefühlt jede Woche etwas ändert, ist nie verkehrt.
Kein Widerspruch: klein rechnen und trotzdem größer wählen
Ich habe es in einem anderen Artikel schon dargelegt: Die Architektur eines Features entscheidet, wie viele Stufen es braucht und wie klein jede Stufe sein darf. Die Reserve im Modell entscheidet, dass keine dieser Stufen am Limit läuft.
Schlau programmiert gibt mir die Möglichkeit, kleinere Modelle zu nehmen. Dann doch wieder eine Kategorie höher zu greifen, gibt mir die Sicherheit und die Resilienz. Das eine finanziert das andere.
OPEX oder CAPEX
Man kann es aus meiner Sicht ganz einfach zusammenfassen: OPEX, wenn es das Geschäftsmodell ist und ich an der Marge verdiene. CAPEX, wenn es die Grundlage ist.
Ich vergleiche das gerne mit Handwerkern. Werkzeug kauft man, den Turmdrehkran mietet man tageweise, je nach Projekt. Die Skala: Ein 12B am Laptop ist eine Schnur. Eine Spark mit einem 35B ist eine Schaufel. Das 397B ist ein kleiner Bagger, kein Hochhaus, aber ein Einfamilienhaus lässt sich damit schon bauen. Für das Hochhaus geht man zu OpenRouter oder direkt zu den großen Anbietern.
Wofür Mieten natürlich auch immer sehr brauchbar ist: herausfinden, was ein Modell kann. Man muss sich nicht alles gleich selbst installieren, das ist auch Aufwand. Mieten, um zu entscheiden. Kaufen, um zu arbeiten.
Die meisten bauen Einfamilienhäuser
Spannend ist ja, dass für einfachste Aufgaben wie Zusammenfassungen oder das Klassifizieren von Listen oft wirklich die Frontier-Modelle der großen Anbieter verwendet werden. Größtes Modell, Thinking an, gib ihm. Für simple Aufgaben.
Am Ende bauen sie alle Einfamilienhäuser, kommen aber mit dem Werkzeug für den Wolkenkratzer an.
Technik ist Handwerk
Ich empfinde unsere Branche als Handwerk. Werkzeug ist Voraussetzung. Niemand fragt einen Baumeister, ob sich sein Bagger rechnet. Ich als Kunde gehe aber selbstverständlich davon aus, dass er einen hat.
Ein Handwerker ohne eigene Maschinen ist vielleicht Architekt oder Sachverständiger, aber keiner, der Häuser baut.
Wenn es dann heißt, dass ja nicht jeder Programmierer ein Rechenzentrum braucht: Der Handwerker besitzt auch nicht den Steinbruch oder die Schottergrube. Er besitzt die Werkzeuge, die er täglich braucht. Strom verbraucht man, den Bagger setzt man an. Inferenz ist heute die Kontaktstelle zur Arbeit.
Der Bagger wird nicht so schnell kaputt, wie man denkt
Der ernsthafteste Einwand gegen CAPEX ist die Alterung. Ein Bagger steht zwanzig Jahre und gräbt. Hardware dagegen verliert an Wert, während sie abgeschrieben wird, nicht durch Verschleiß, sondern weil die Welt weiterläuft. So war die Regel jedenfalls immer.
2026 steht diese Regel auf dem Kopf. Nvidia bringt ab Juli die RTX-30-Serie zurück in den Handel, Manli legt RTX 3060 und 3050 auf Basis der vier Jahre alten Ampere-Architektur neu auf. MaxSun zeigte auf der Computex eine Neuauflage der Radeon RX 580, einer Karte aus dem Jahr 2016. Bei den Plattformen dasselbe Bild: Mainboard-Hersteller und Modulhäuser richten ihre Planung wieder stärker auf DDR4 aus. Die Faustregel, dass Hardware mit der Zeit billiger wird, ist derzeit schlicht außer Kraft. Eine Entspannung erwarten Analysten frühestens gegen Ende 2027, alte Preise womöglich erst 2028.
Der Grund ist ausgerechnet der KI-Boom selbst. Jeder Wafer, der in HBM und Server-DRAM geht, fehlt woanders. Und das trifft nicht nur die Consumer-Ecke: Nvidia soll die Speicherkapazität des Vera-Rubin-Superchips wegen LPDDR5X-Mangels von 192 auf 96 Gigabyte halbiert haben. Wenn schon die Spitzenprodukte beim Speicher zurückgestuft werden, ist „warte auf die nächste Generation" keine sichere Wette mehr, sondern eine Hoffnung.
Die Pointe: Dieselbe Nachfrage, die meine Hardware veralten lassen sollte, frisst den Speicher, aus dem der Nachfolger gebaut würde. Der Bagger geht nicht kaputt, und der bessere Bagger kommt später und teurer als gedacht. Hardware ist mittlerweile fast schon eine Wertanlage.
Wo es nicht aufgeht
Mehrere Sparks, die stehen, sind kein Werkzeug, sondern gebundenes Kapital. Das ist keine Kleinigkeit, das ist der Punkt, an dem meine ganze Argumentation kippt. Wenn ein Handwerker zweimal im Jahr einen Bagger braucht, hat er keinen im Fuhrpark. Dann ist mieten schlicht die richtige Entscheidung, und zwar ohne schlechtes Gewissen. Wer nicht auslastet, soll nicht kaufen. Die Rechnung, die bei mir aufgeht, geht bei ihm nicht auf, und daran ist nichts zu deuteln.
Und was der KI-Boom zusätzlich zur Folge hat: Wachstum wird immer teurer. Die Knappheit schneidet in beide Richtungen. Mein Bestand ist wertstabil, aber würde ich meinen Stack erweitern wollen, kostet das jetzt deutlich mehr. Wertschutz nach hinten, Deckel nach vorne.
Die Ressource wechselt, das Handwerk bleibt
Der Markt ist gerade extrem volatil. Allein was ich warten musste, bis ich alle Sparks hatte. Es gab sogar Hardware-Bestellungen, die nie bei mir angekommen sind. Auch das kommt vor.
Aber das ist eigentlich nichts Neues. Erst war der Speicher im Programm knapp, dann waren es die Tokens im Budget, jetzt ist es DRAM in der Lieferkette. Die knappe Ressource wechselt, knapp ist sie immer. Und genau das ist der Beruf: bauen mit dem, was da ist, und nicht mit dem, was unendlich wäre.
Deshalb ist die Frage am Ende nicht, ob sich der Bagger rechnet. Die Frage ist, ob man Häuser baut.