Tokens kaufen, GPUs mieten oder das Rack besitzen?

Bis vor Kurzem war es keine ernsthafte Frage, ein Frontier-Modell selbst zu hosten. Open-Weight-Modelle lagen eine Generation hinter den proprietären, also gab es nichts zu rechnen.

Dann schloss sich die Lücke. Nicht ganz, aber auf etwa dreißig Elo. Kimi K3 kam mit offenen Gewichten heraus und steht in der Frontend-Code-Arena auf Platz zwei mit 1.682, hinter Claude Opus 5 Max mit 1.712 und vor allem anderen¹. Seine Gewichte passen auf dem Papier auf einen einzigen Node mit acht GPUs. Du kannst das Modell heute Abend kostenlos herunterladen.

Die Kiste ist eine andere Sache. Vorausgesetzt, du kannst die Investition stemmen. Und vorausgesetzt, die Rechnung ergibt am Ende überhaupt, dass es sich lohnt.

Also habe ich vier Wege durchgerechnet, dieselbe Last zu betreiben: ein Rack in deinem Büro, eigene Hardware in einer Colocation, gemietete dedizierte GPUs und APIs mit Abrechnung pro Token. Den letzten Punkt nenne ich im ganzen Text den Zähler.

Die Antwort ist nicht “kauf das Rack”. Unter etwa 44 Entwicklern bleibt der Zähler am billigsten. Zwischen etwa 44 und 95 gewinnen gemietete GPUs. Darüber lohnt sich Eigentum, und bei 750 Entwicklern schlägt es den Zähler ungefähr sechs zu eins.

Die Zahl, die entscheidet, ist die Auslastung. Ein Rack, das auf drei Jahre abgeschrieben wird, kostet nachts um drei dasselbe, ob es Tokens ausliefert oder das Gebäude heizt.

K3 ist hier nur das Rechenbeispiel. Dieselbe Methode gilt für das, was als Nächstes erscheint.

Vier Wege, Inferenz zu kaufen

Option	Dir gehört	Du mietest	Du bezahlst für
Büro-Rack	GPUs, Stromversorgung, Kühlung	nichts	Capex, Strom, einen Elektriker, Fläche, Personal
Colo-Rack (deine Hardware, fremdes Gebäude)	GPUs	Platz, Strom, Kühlung	Capex, Rackmiete pro kW², Personal
Dedizierte / gemietete GPUs	nichts	Ganze GPUs stundenweise	Reservierte Stunden, Personal
Der Zähler (API pro Token)	nichts	nichts	Tokens

Je weiter du in der Tabelle nach unten gehst, desto kleiner wird deine feste Bindung und desto größer deine Flexibilität. Dafür gibst du Kontrolle auf und, ab genug Größe, Stückkosten. Herauszufinden, wo dieser Tausch kippt, ist die ganze Übung.

Vor der Tabellenkalkulation aber eine grundlegendere Frage: Kannst du so eine Maschine überhaupt in ein Büro stellen?

Geht das überhaupt?

In Staffel zwei von Silicon Valley fangen Gilfoyles Server Feuer. Das Team packt zu viel Last auf Anton, er reizt die Stromstärke aus, löst die Hauptsicherung aus und brennt. Alle erinnern sich an einen Gag über Hybris. Wir behandeln ihn hier als Kommentar zur Elektrotechnik.

Die Server von Pied Piper brennen im Hintergrund des Hacker Hostel — Anton, Sekunden nachdem die Hauptsicherung aufgegeben hat. Silicon Valley, HBO.

Falls du Silicon Valley nicht gesehen hast: Sorry. Es ist ein moderner Klassiker und war seiner Zeit voraus.

K3 hat 2,8 Billionen Parameter, 104 Milliarden davon aktiv pro Token, 896 Experts und ist direkt nach dem Training auf MXFP4 quantisiert³. Das sind auf dem Papier 1.390GB an Gewichten. Ein B200-Node mit acht GPUs bietet 1.440GB, also passt es rechnerisch mit 50GB Reserve. Berichte über den tatsächlichen Checkpoint sehen ihn eher bei 1,56TB, sobald alles mitgezählt ist, was kein quantisiertes Gewicht ist. Dann passt er gar nicht. Das ist der feuchte Traum von r/selfhosted: das zweitbeste Coding-Modell der Welt, das in einer Abstellkammer vor sich hin summt, und es gehört dir.

Dann liest du das Datenblatt.

Datenblatt, ein DGX B200	Wert	Was das im Büro heißt
Leistungsaufnahme	14,3 kW⁴	Zwei komplette Induktionsherde, jede Platte, dauerhaft
Britischer Ringstromkreis	7,4 kW	Ein Server will zwei ganze Stromkreise für sich
Wärmeabgabe	~48.800 BTU/h	Drei bis vier Split-Klimaanlagen im Dauerbetrieb
Luftstrom	2.145 CFM⁴	Keine Abstellkammer. Ein Technikraum
Gewicht	130 kg⁴	Vor Rack, PDUs und Kühlung
Zwei Nodes pro Rack	2x 380V Drehstrom 32A⁴	Du rufst einen Elektriker, du kaufst keine Verlängerungsschnur

Eine Unstimmigkeit gebe ich zu: Die Werte für Leistung, Gewicht und Luftstrom stammen von NVIDIA für den DGX B200, das eigene integrierte Gerät. Die $450.000, die ich ansetze, sind dagegen ein Straßenpreis für einen HGX B200 mit 8 GPUs, das Board, um das ein OEM einen Server baut. Ein DGX kostet laut Liste eher $515.000. Ich nehme den günstigeren Preis mit der Leistungsaufnahme der teureren Maschine. Das schönt Self-Hosting beim Capex und bestraft es beim Strom.

Anton hat die Sicherung nicht ausgelöst, weil ein Autor im dritten Akt ein Feuer wollte. Er hat sie ausgelöst, weil das passiert, wenn du Industrielast an Haushaltsverkabelung hängst.

Ein Node ist übrigens der gutmütige Fall, und zwar auf eine zweite Art. Die 50GB Reserve lassen nichts für den KV-Cache übrig, den Arbeitsspeicher, den ein Modell braucht, um ein langes Gespräch zu halten. Ein echter Produktivbetrieb braucht also mehr Beschleuniger als das. Moonshot empfiehlt 64 oder mehr⁵. Das sind acht dieser Kisten, 114 Kilowatt, in deinem Büro. Eher ein Mini-Atomreaktor als ein Serverraum, der nur darauf wartet, dass jemand eine Series A um ihn herum verkündet.

Ich habe trotzdem den einzelnen Node gerechnet, weil er das Billigste ist, was die Gewichte plausibel halten könnte. Aber sei vorsichtig: Das ist kein schlimmster Fall. Personal und Elektroarbeiten sind nahezu fix, mehr Nodes verteilen sie also, und die Wirtschaftlichkeit wird besser. Ein Ein-Node-Ergebnis ist der härteste Test für Self-Hosting, nicht der leichteste.

Dazu kommt die Lieferbarkeit. Blackwell-Kontingente gehen zuerst an die größten Käufer, also stehst du für eine Kiste hinter Musk in der Schlange.

Du brauchst einen Gilfoyle

Gilfoyle ist der Systemtyp. Ihm gehören die Racks, er traut nichts, und er ist der Einzige im Haus, der weiß, warum der Cluster brennt.

Womit wir bei meiner liebsten Fiktion in jedem Self-Hosting-Business-Case sind: dem Bruchteil eines Ingenieurs.

Du kannst keine 0,3 Personen einstellen. Die Rolle betreibt vLLM oder SGLang in Produktion, weiß, was Expert Parallelism ist, debuggt NCCL um zwei Uhr nachts und hält mehrere hundert Gigabyte Mixture-of-Experts heiß und lieferbereit. Robert Half beziffert den Median für einen Machine-Learning-Engineer in London auf £102.000 und das obere Quartil auf knapp £119.000⁶. Ich habe £120.000 angesetzt, bewusst eine Einstellung im oberen Quartil, weil der Median diesen Job nicht kann.

Er oder sie wird auch Meinungen haben. Zu deinen Cloud-Kosten, zu der Tastatur, die er oder sie verlangt, zu den Anteilen, die dem Einzigen im Haus zustehen, der das Ding versteht, von dem jetzt alle abhängen. Das sind die wahren Kosten, es selbst zu betreiben, und sie stehen auf keinem GPU-Datenblatt.

Du brauchst zwei davon, weil einer ein Single Point of Failure ist, mit Reisepass und starken Gefühlen zum Jahresurlaub.

Posten	Wert (GBP)
Grundgehalt (oberes Quartil)	£120.000
Gemeinkostenfaktor (Arbeitgeberanteile, Rente, Ausstattung)	1,3
Volle Kosten pro Person	£156.000
Benötigte Personen	2
Summe pro Jahr	£312.000 (etwa $396.000)

Diese Zahl wird nicht abgeschrieben. Sie wird nicht billiger, und es ist ihr egal, ob deine Hardware ausgelastet ist.

Die Last entscheidet mehr als die Hardware

Die meisten Self-Hosting-Rechnungen, die ich gesehen habe, werden gegen Chat gerechnet. Das ist der schlechteste denkbare Fall für eigene Hardware und hat nichts damit zu tun, was ein Entwicklungsteam den ganzen Tag macht.

Agentisches Coding läuft mit 4,17 Millionen Tokens pro Aufgabe, bei einem Verhältnis von Input zu Output von etwa 153:1⁷. Nichts hier zählt mehr als dieses Verhältnis, außer der Auslastung.

Auf eigener Hardware hilft es. Prefill, das Lesen deines Prompts, und Decode, das Schreiben der Antwort, sind verschiedene Aufgaben mit verschiedenen Kosten. vLLM schafft 26.200 Tokens pro GPU und Sekunde beim Prefill gegen 10.100 beim Decode⁸, Prefill ist also zweieinhalbmal effizienter. Agentisches Coding ist fast reines Prefill. Die Arbeit deines Teams ist zufällig genau die, die GPUs am besten können.

Auf dem Zähler hilft es auch, weil Input-Tokens fünfmal billiger sind als Output.

Komponente	Rechnung	$/1M Tokens
Input ohne Cache	0,30 × 0,9935 × $5	1,49
Input aus dem Cache (Lesen zu 0,1×)	0,70 × 0,9935 × $5 × 0,1	0,35
Output	0,0065 × $25	0,16
Gemischt, 70% Cache-Treffer		$2,00
Gemischt, ganz ohne Caching	0,9935 × $5 + 0,0065 × $25	$5,13

Die 70% sind eine Annahme und keine Messung, und sie ist die zweitwichtigste Zahl in diesem Text. Sie halbiert den Zähler mehr als, von $5,13 auf $2,00. Halbierst du die Trefferquote auf 35%, kostet der Zähler $3,57, und das verschiebt jeden Kreuzungspunkt weiter unten deutlich Richtung Self-Hosting. Geh in die andere Richtung, und der Zähler gewinnt fast überall.

Zwei Dinge zu diesen $2,00, bevor du ihnen traust. Anthropic berechnet etwa das 1,25-fache des Inputs, um einen Cache-Eintrag zu schreiben, und ich habe jedes Token ohne Cache als normalen Lesezugriff bepreist. Wären alle 30% ohne Cache Schreibzugriffe, läge der Zähler bei $2,37 statt $2,00. Die Wahrheit liegt irgendwo dazwischen.

Jemand wird fragen, warum ich selbst gehostetes K3 gegen Opus 5 bepreise und nicht gegen die eigene API von K3, die mit $3 und $15 pro Million und Cache-Treffern für $0,30 günstiger ist⁹, bei dieser Token-Mischung etwa $1,20. Weil für die meisten Firmen, an die sich dieser Text richtet, Produktivverkehr in eine chinesische Cloud zu schicken keine echte Option ist, was auch immer die Preisliste sagt. Das ist keine technische Einschätzung, sondern eine Beschaffungsentscheidung, und sie fällt über deinem Kopf. Die realistische Wahl ist, K3 selbst zu betreiben oder Opus 5 bei Anthropic zu kaufen, und genau das vergleichen die Tabellen.

Es ist übrigens derselbe Instinkt, der Leute überhaupt erst zum Self-Hosting bringt. Wärst du entspannt dabei, wo die Gewichte laufen, würdest du die API nehmen und aufhören zu lesen.

Also bevor du irgendetwas davon verwendest: Schau dir deine tatsächliche Cache-Trefferquote an. Sie zählt mehr als der Preis einer GPU.

Was eine Kiste tatsächlich schafft

Um vier Optionen zu vergleichen, brauche ich zwei Zahlen: wie viel Arbeit ein Node verarbeitet und wie viel Arbeit ein Entwickler erzeugt. Keine von beiden ist exakt, also hier jede Annahme, auch die, die die Fantasie ruinieren.

Schritt	Rechnung	Ergebnis
Input-Anteil an den Tokens	153 ÷ 154	0,9935
Gemischter Durchsatz pro GPU	harmonisches Mittel aus 26.200 Prefill und 10.100 Decode bei diesem Mix	25.932 tok/s
Abschlag für K3 gegenüber DeepSeek-Klasse	104B aktive Parameter gegen ~37B	× 0,35
Abschlag für B200 gegenüber GB200	der Benchmark lief auf GB200	× 0,70
Abschlag für echten Verkehr gegenüber Benchmark	Benchmarks sind aufgeräumt, Produktion nicht	× 0,60
Durchsatz nach Abschlägen pro GPU	25.932 × 0,147	3.812 tok/s
Pro Node	× 8 GPUs	30.496 tok/s
Jahreskapazität bei 100% Last	× 31.536.000 Sekunden	962.000M Tokens

Dagegen die Nachfrage:

Schritt	Rechnung	Ergebnis
Aufgaben pro Entwickler und Tag	Annahme zur Last, nicht gemessen	6
Tokens pro Aufgabe	Bai et al.⁷	4,17M
Arbeitstage pro Jahr	260 abzüglich Urlaub und Feiertage	230
Tokens pro Entwickler und Jahr	6 × 4,17M × 230	5.755M

Auf Volllast versorgt ein Node etwa 167 Entwickler. Bei 21% Jahresauslastung, ungefähr Nutzung zu Bürozeiten, trägt er etwa 35.

Die genaue Kapazitätszahl ist anfechtbar, und ich komme darauf zurück, wie falsch sie sein könnte. Sobald die Hardware gekauft ist, überstimmt die Auslastung jede andere Variable.

Die Auslastung entscheidet

Eigene Hardware kostet schlafend genauso viel wie unter Volllast. Die Abschreibung läuft, die Rackmiete läuft, und deine zwei Gilfoyles werden trotzdem bezahlt. Strom ist die einzige Position, die der Nachfrage folgt, und Strom ist, wie sich zeigt, Kleingeld.

Auslastung	Büro-Rack $/1M	Colo $/1M	Zähler $/1M
5%	12,23	12,81	2,00
10%	6,14	6,40	2,00
21% (nur Bürozeiten)	2,95	3,05	2,00
35%	1,79	1,83	2,00
50%	1,27	1,28	2,00
80%	0,81	0,80	2,00
100%	0,66	0,64	2,00

Die Büro-Linie kreuzt den Zähler bei 31,2% Auslastung, Colo bei 32,0%.

Eine Einschränkung, die genau hierher gehört und nicht ans Ende: Das ist eine Kurve für einen Node. Zwei Plattform-Ingenieure und die Rechnung des Elektrikers skalieren nicht mit der Node-Zahl, bei zwei Nodes fällt der Kreuzungspunkt also auf etwa 21% und bei fünf auf etwa 14%. Je größer du wirst, desto weniger Auslastung brauchst du, um Eigentum zu rechtfertigen.

Jetzt halte ein echtes Team dagegen. Acht Stunden am Tag, 230 Tage im Jahr, macht 1.840 Stunden von möglichen 8.760. Eine Auslastung von 21%. Ein Team, das zu Bürozeiten arbeitet und dann nach Hause geht, liegt unter dem Break-even, und Self-Hosting verliert.

Die Frage war also nie, ob Open-Weight-Modelle gut genug sind oder GPUs billig genug. Beides ist geklärt. Die Frage ist, ob du die Nachtschicht mit Batch-Jobs, Evals, Reindexierung und der CI füllen kannst, die keiner beobachtet. Bring die Kiste auf 35%, und du gewinnst. Bei 50% gewinnst du deutlich. Lässt du sie jeden Abend leerlaufen, hast du einen sehr teuren Heizlüfter auf einem Dreijahresvertrag gekauft.

Unabhängige Analysen zu Azures Provisioned Throughput legen den Break-even gegenüber Pay-as-you-go bei etwa 80% Dauerauslastung¹⁰. Weder AWS noch Microsoft veröffentlichen eine eigene Break-even-Zahl, nimm das also als Rechnung von Dritten und nicht als Empfehlung der Anbieter. Das ist weit weg von meinen 31%, und ich tue nicht so, als wäre es anders. Sie messen unterschiedliche Dinge: Deren Produkt trägt eine Marge und wird gegen die eigene Liste bepreist, meins sind Rohkosten gegen die Liste eines Konkurrenten. Beide haben dieselbe Richtung gemeinsam, nämlich dass reservierte Kapazität die meiste Zeit ausgelastet sein muss, bevor sie sich auszahlt.

Gemietete GPUs gewinnen die Mitte

Die Auslastung bestimmt den Stückpreis. Die Teamgröße entscheidet, welche Option gewinnt, weil sie die Fixkosten verteilt.

Bei 25 Entwicklern läuft ein Node mit 15% Auslastung, und der Zähler gewinnt klar. Zwei Plattform-Ingenieure kosten $396.240 im Jahr. Die gesamte Token-Rechnung, die sie ersetzen würden, beträgt $287.777. Das Personal kostet mehr als das Problem. Nichts anderes in der Tabelle ist lesenswert.

Bei 60 Entwicklern läuft ein Node mit 36% Auslastung, und gemietete Kapazität zieht knapp vorbei.

Jahrespostenzeile (USD)	Büro	Colo	Gemietet	Zähler
Hardware-Abschreibung¹¹	150.000	150.000	0	0
Stromversorgung	25.400	0	0	0
Strom	31.821	0	0	0
Rackmiete	0	69.564	0	0
GPU-Miete	0	0	138.382	0
Plattform-Ingenieure	396.240	396.240	396.240	0
Token-Gebühren	0	0	0	690.664
Summe	603.461	615.804	534.622	690.664
Pro Entwickler	10.058	10.264	8.910	11.511
Pro 1M Tokens	1,75	1,78	1,55	2,00

Beachte, was in dieser Tabelle fehlt: ein Personalrabatt fürs Mieten. Jede selbst gehostete Option trägt zwei ganze Plattform-Ingenieure, weil du um zwei Uhr nachts keinen Bruchteil eines Menschen anpiepen kannst, egal wem das Blech gehört. Mieten spart dir das Capex, den Elektriker und die Schlange hinter Musk. Es spart dir nicht die Gehälter.

Deshalb ist der Sieg knapp. Vom billigsten zum teuersten der vier Optionen sind es hier 29%, bequem innerhalb der Fehlergrenzen meiner eigenen Annahmen.

Ich habe nach jemandem gesucht, der diese Option gegen die anderen drei durchgerechnet hat, und bin leer ausgegangen. Das wundert mich, denn am Mieten von GPUs ist nichts obskur. Lambda, CoreWeave, Spheron und ein Dutzend andere veröffentlichen ihre B200-Stundenpreise, und ein Aggregator verfolgt mehr als 26 davon¹². Die Mitte ist durchaus zu haben, und für ein Team mit 60 Entwicklern schlägt sie beide Enden.

Bei 750 Entwicklern laufen fünf Nodes mit 90% Auslastung, und Mieten verliert deutlich, weil es stundenweise abrechnet und du bei dieser Auslastung fast alle Stunden bezahlst. Die Hardware zu besitzen kostet $1.494.059 in einer Colo oder $1.565.997 im eigenen Büro, gegen $2.126.018 gemietet und $8.633.301 am Zähler. Das ist die eine Stelle im ganzen Modell, an der Eigentum offensichtlich richtig ist, und es schlägt den Zähler ungefähr sechs zu eins.

Beachte aber, wie nah Büro- und Colo-Spalte beieinanderliegen. Ab etwa 95 Entwicklern liegen sie wenige Prozent auseinander und tauschen je nach Node-Zahl die Plätze. Da meine Büro-Option keine Miete zahlt, ist die ehrliche Lesart, dass es dieselbe Antwort ist, und die Wahl zwischen beiden dreht sich darum, wer die Filter wechseln soll.

Teamgröße	Günstigste Option	Jahreskosten pro Entwickler	Hauptgrund
25	Der Zähler	$11.511	Plattform-Personal kostet mehr als die ganze Token-Rechnung
60	Gemietete GPUs	$8.910	Genug Last für Kapazität, nicht genug, um Capex zu rechtfertigen
750	Eigene Hardware (Colo)	$1.992	Fast durchgehende Nachfrage macht Mietstunden teuer

Tokens sind kein Geld

In der Technologieplanung hält sich hartnäckig die Annahme, und ich sage das als jemand, der unübersehbar Teil des Problems ist, dass Tokens das neue Fass Öl sind. Die universelle Tauscheinheit. Ganze Firmen führen inzwischen Planungszyklen in ihnen.

Voll belastet und voll ausgelastet kostet der eigene Node in diesem Modell etwa $0,66 pro Million Tokens gegen $2,00 am Zähler mit Cache. Allein der Strom macht davon 6,6 Cent aus, das ist ein Zehntel der Summe und, ärgerlicherweise, ein Faktor zehn neben der Zahl direkt darüber. Beides stimmt.

Posten	Rechnung	Wert
Node-Leistung	14,3 kW × 8.760 Stunden	125.268 kWh/Jahr
Zu britischen Gewerbetarifen¹³	× £0,25	£31.317
Mit Kühlaufschlag im Büro (PUE 1,6)	× 1,6	£50.107
In Dollar	× 1,27	$63.636
Erzeugte Tokens bei Volllast		962.000M
Strom pro 1M Tokens		6,6 Cent

Es geht nicht darum, dass irgendjemand sieben Cent verlangen sollte. Der Preis eines Tokens enthält Hardware, Personal, Risiko, Forschung und Marge, und das soll er auch. Es geht darum, dass ein Token eine Abrechnungsabstraktion für den Endkunden über GPU-Sekunden ist, mit einem Wechselkurs, den der Verkäufer festlegt. Wenn Tokens wirklich das neue Öl sind, dann sind die Hyperscaler die OPEC, mit dem praktischen Vorteil, dass sie die Physik jederzeit anpassen dürfen, wenn die Margen Hilfe brauchen.

Damit sind wir bei dem, was als Nächstes kommt, und es ist weniger eine Vorhersage als ein Muster, das schon einmal gelaufen ist. KI-Rechenleistung wird genauso finanzialisiert wie die Rechenleistung im Web 2.0. EC2 startete mit Preisen pro Instanzstunde, und innerhalb weniger Jahre bestand der echte Markt aus Reserved Instances, Savings Plans, Spot und Rabatten für Dauernutzung. Große Käufer zahlen seit Jahren nicht mehr den On-Demand-Preis.

Es fängt schon an. Bedrock verkauft Provisioned Throughput pro Model-Unit-Stunde, von $4,11 bis $49,50 je nach Modell, und der Preis sinkt, je länger du dich bindest¹⁰. Azure verkauft dasselbe Muster als Provisioned Throughput Units. Das sind keine Token-Preise, das sind Kapazitätsreservierungen mit einer Bindungskurve.

Das Verräterische ist, was auf dieser Seite fehlt. Für kein aktuelles Claude-Modell gibt es überhaupt einen veröffentlichten Preis für Provisioned Throughput. Den Markt für reservierte Frontier-Modelle gibt es, aber er wird angeboten und nicht gelistet, und das verrät dir, wie früh es noch ist.

Denk es weiter, und du hörst auf, Tokens zu kaufen. Du reservierst Kapazität für deine Grundlast, nimmst den Rabatt für Dauernutzung mit und weichst bei Spitzen auf den Zähler aus. Tokens werden zum Abgas einer Leitung, die du schon bezahlt hast, und die Größe, in der du budgetierst, wird die GPU-Stunde, hinter der wenigstens eine echte Angebotskurve steht.

Sollten wir?

Manches davon liest sich wie ein Plädoyer, rauszugehen und Metall zu kaufen. Das ist es nicht, jedenfalls nicht ganz.

Du würdest ein Wirtschaftsgut kaufen, das an Wert verliert, während der Zählerpreis fällt. Opus 5 kam zu genau dem Preis von Opus 4.8 heraus, $5 und $25 pro Million Tokens, und es ist ein deutlich besseres Modell¹⁴. Die Preisliste hat sich nicht bewegt, während das Ding dahinter besser wurde. Dein Capex ist also eine Dreijahreswette darauf, dass Frontier-Intelligenz langsamer billiger wird, als deine Hardware verschleißt, und die Front bewegt sich im Takt von Monaten. Hardware, die du heute spezifizierst, steckt bis 2029 in der heutigen Wirtschaftlichkeit fest.

Beides stimmt also gleichzeitig. Tokens tragen eine fette Marge, und Maschinen zu kaufen ist für die meisten ein schlechter Weg, ihr zu entkommen. Der Ausweg ist, dass du kein Rack kaufen musst, um nicht mehr den Endkundenpreis zu zahlen. Reserviere die Kapazität, kauf nicht das Gebäude.

Zwei Dinge überleben die Arithmetik, wenn auch nur eines sauber.

Souveränität. Wenn deine Daten das Haus nicht verlassen dürfen, vergleichst du nicht gegen $2,00, sondern gegen nichts, denn der Zähler wird dir zu keinem Preis verkauft. Rechne die Auslastung trotzdem durch, aber du hast dich schon entschieden.

Latenz, aber weniger als du hoffst. Ein Modell im selben Rack spart dir eine Netzwerk-Rundreise. Das sind vielleicht vierzig Millisekunden gegen die gut dreißig Sekunden, die das Ding mit Nachdenken verbringt, für agentische Arbeit ist das Rauschen. Es lohnt sich bei dem engen Zeug, Autocomplete und Inline-Vorschlägen, wo du ein Budget unter 100ms jagst und das Netzwerk einen echten Anteil daran hat. Ist das nicht deine Last, nimm es nicht in den Business Case.

Das würde ich also tatsächlich tun: Hör auf, dich für eine der vier zu entscheiden. Reserviere genug Kapazität für deine Grundlast und miss den Rest. Vorhersehbare Arbeit mit hohem Volumen läuft nachts auf der Leitung, die du schon bezahlt hast, bei der Auslastung, wo sie zwei zu eins oder besser gewinnt. Das schwere Denken geht ans Frontier-Modell am Zähler, wo du für etwas zahlst, das du nicht nachbauen und nicht abschreiben kannst.

In der Praxis ist die Platzierung der wichtigste ökonomische Hebel, nicht die Modellwahl. Das war das Argument, das ich beim Routing zwischen Modellen gebracht habe, eine Schicht tiefer im Stack.

Wo dieses Modell falsch liegen könnte

Vier Dinge.

Mein Durchsatz-Abschlag ist wahrscheinlich zu hart, und eine Korrektur spricht fürs Mieten. Ich habe den vLLM-Benchmark um den Faktor sieben gekürzt, weil K3 größer ist, die Hardware luftgekühlt ist und echter Verkehr unordentlicher ist als ein Benchmark. Das ist Bierdeckel-Mathematik, und ein grober Check gegen die rohen FLOPs sagt, dass der wahre Wert drei- bis viermal höher liegen könnte. Rechnest du mit dieser Zahl neu, kippt 200 Entwickler von Besitzen zu Mieten, weil schnellere Hardware die gemieteten GPU-Stunden sofort senkt und am bereits gebundenen Capex nichts ändert. Es bewegt sich gegen ein Rack, nicht dafür.

Aufgaben pro Entwickler und Tag sind geraten. Ich habe sechs genommen. Das bestimmt die absolute Nachfrage und damit die Ergebnisse nach Teamgröße. Die Auslastungstabelle berührt es nicht, deshalb ist sie die stärkere Aussage und deshalb steht sie zuerst.

Die Konfiguration mit einem Node ist optimistisch, wie oben angemerkt. Moonshot will 64 Beschleuniger für Produktion, und ich habe acht gerechnet, die großzügigste Lesart, die Self-Hosting verlangen könnte.

Die Büro-Option bekommt ihr Gebäude geschenkt. Sie zahlt für Hardware, die Elektro- und Kühlinstallation und den Strom. Sie zahlt keine Miete, keine Gewerbesteuern, keine Versicherung, keine Brandbekämpfung, keine USV, keine PDUs, keine Statik für 130kg pro Node und keinen Ausbau des Netzanschlusses, und ab etwa zwei Nodes braucht ein britisches Gewerbegebäude diesen Ausbau und keinen Elektriker. Colo zahlt all das innerhalb der £285/kW/Monat. Diese Lücke ist ein Grund, warum das Büro in meinen Tabellen überall vor Colo liegt, und du solltest die beiden für näher beieinander halten, als sie aussehen. Berechnest du der Büro-Option die Hälfte des Komplettpreises von Colo, liegt sie bei jeder Teamgröße immer noch vorn, und nur deshalb habe ich nicht versucht, dafür eine Zahl zu erfinden.

Jede Zahl hat im Workbook dahinter eine Quelle und eine Konfidenzstufe. Die mit niedriger Konfidenz sind die drei, die du gerade gelesen hast.

Die Arithmetik könnte an den Rändern also falsch sein. Die Physik nicht. Vierzehn Kilowatt sind vierzehn Kilowatt, ob meine Durchsatzschätzung hält oder nicht, die Wärme muss irgendwohin, und der Elektriker will immer noch bezahlt werden.

Ich könnte Tokens kaufen und nie wieder über all das nachdenken. Oder ich denke über alles nach und bekomme einen Hitzschlag beim Verkabeln der nächsten Grafikkarte.

Arena WebDev leaderboard, 28 July 2026, 492,170 votes. claude-opus-5-max 1,712; kimi-k3-max 1,682; claude-opus-5-high 1,669; claude-fable-5 1,628; gpt-5.6-sol-xhigh 1,623; claude-opus-4-8-thinking 1,568. Worth holding onto: K3’s coding rank flatters it. On the main text leaderboard (27 July 2026) kimi-k3-max is eleventh on 1,486 ±10, behind claude-fable-5 (1,508) and claude-opus-5-max (1,495), and in a statistical tie with claude-opus-4-8-thinking (1,484 ±5). It is a coding specialist, not the best model in the world. ↩
Ich setze Colo mit £285 pro kW und Monat an. Die Zahl habe ich mir aus den Fingern gesogen, weil ich keine Quelle gefunden habe, die gut genug ist, um dafür geradezustehen. Für das, was es wert ist: Britische Großhandels-Colocation liegt bei £150-300 pro kW und Monat ab 1MW, im Einzelhandel in London werden £300-800 pro Schrank genannt, bei hoher Dichte über £2.000, und GPU-Racks mit hoher Dichte tragen einen Aufschlag, auf den niemand eine Zahl setzt. Mein Einsatz liegt bei 14 bis 72kW, viel zu klein für Großhandelspreise. Wenn du weißt, was ein GPU-Rack mit 30kW in London tatsächlich kostet, sag es mir, und ich korrigiere das. Ich behandle den Satz als Komplettpreis für Platz, Kühlung, Ausfallsicherheit und Strom, weil gemessener Strom obendrauf den größten Posten einer Colo-Rechnung doppelt zählen würde. ↩
Moonshot AI, Kimi-K3 model card. Hugging Face. 2,8T Parameter insgesamt, 104B aktiv (16 von 896 Experts), MXFP4-Gewichte mit MXFP8-Aktivierungen, Kontext von 1.048.576 Tokens. ↩
NVIDIA, Data Center Best Practices with DGX B200. Spec sheet. Geschätzte Systemleistung 14,3kW max, Gewicht >130kg und 150 CFM pro Kilowatt, ergibt 2.145 CFM pro Node (das Dokument nennt 4.290 CFM für ein Rack mit zwei Nodes). Zwei Nodes pro Rack brauchen 2x 380V-Drehstromzuleitungen mit 32A. Die Wärmezahl ist meine eigene Umrechnung, nicht die von NVIDIA: 14,3kW x 3.412 = ~48.800 BTU/h. ↩ ↩² ↩³ ↩⁴
Moonshot AI, Kimi K3 launch post: “we recommend deploying Kimi K3 on supernode configurations with 64 or more accelerators”. Eine Empfehlung, keine Untergrenze. Moonshot veröffentlicht keine Mindestzahl an GPUs. ↩
Robert Half, 2026 Salary Guide, machine learning engineer, London. 50. Perzentil £102.000, 75. Perzentil etwa £119.000. ↩
Bai et al. (2026), How Do AI Agents Spend Your Money? Paper, Figure 1. Agentisches Coding liegt im Schnitt bei 4,17M Tokens pro Aufgabe bei einem Verhältnis von Input zu Output von 153,85:1, gegen 1,33 bei Code-Chat und 0,16 bei Code-Reasoning. Das Paper nennt auch $1,86 pro Aufgabe, aber das ist ein Durchschnitt über acht Modelle, die meisten weit billiger als Opus 5, und ergibt grob $0,45 pro 1M Tokens. Ich übernehme Token-Volumen und Verhältnis aus dem Paper und bepreise sie selbst: Dieselbe Aufgabe auf Opus 5 bei einer Cache-Trefferquote von 70% kostet etwa $8,34. Die beiden Kostenzahlen sind nicht vergleichbar. ↩ ↩²
vLLM, Driving vLLM WideEP and Large-Scale Serving Toward Maturity on Blackwell (Part I), 3 February 2026. Link. 26,2K Prefill- und 10,1K Decode-Tokens pro GPU-Sekunde auf GB200 für DeepSeek-artiges MoE bei 2K rein / 2K raus. Zwei Dinge, die du zu der Zahl mitnehmen solltest: Sie stammt aus einer disaggregierten Topologie mit 16 GPUs (vier Prefill-Instanzen mit je zwei GB200, eine Decode-Instanz mit acht), und der Durchsatz flacht bei einer Batch-Größe von etwa 64K ab. Das lineare Hochskalieren auf eine einzelne luftgekühlte Kiste mit acht GPUs ist genau der Fehler, den meine Abschläge abdecken sollen. ↩
Kimi K3 kostet an Moonshots API $3 pro Million Input-Tokens und $15 pro Million Output-Tokens, mit Cache-Treffern für $0,30, einheitlich über den vollen Kontext von 1M. Die Preise werden breit berichtet, aber ich konnte sie auf Moonshots eigener Preisseite nicht bestätigen, nimm sie also als Richtwerte. Bei der Token-Mischung dieses Textes ergibt das $1,20 pro Million gegen $2,00 für Opus 5. ↩
AWS, Bedrock pricing. Die veröffentlichten Preise für Provisioned Throughput reichen von $4,11 bis $49,50 pro Model-Unit-Stunde und betreffen nur ältere Modelle (Llama 2 $21,18 für einen Monat, Cohere Command $49,50 für einen Monat gegen $23,77 für sechs, Command Light von $8,56 herunter auf $4,11). Für kein aktuelles Claude-Modell gibt es einen veröffentlichten Preis. Azures Gegenstück ist die Provisioned Throughput Unit, deren Mechanik bei Microsoft Learn dokumentiert ist, auch wenn die Seite keine Dollarbeträge nennt. Der Break-even von ~80% ist eine Analyse von Dritten und keine Empfehlung der Anbieter, und keine der beiden Plattformen veröffentlicht eine solche Zahl. ↩ ↩²
Straßenpreise für einen HGX B200 mit 8 GPUs liegen bei etwa $400.000 bis $500.000, und ich habe $450.000 über eine lineare Nutzungsdauer von drei Jahren ohne Restwert angesetzt. Nimm das als meine Annahme und nicht als Beleg: Die einzigen öffentlichen Quellen sind Content-Marketing-Seiten von Anbietern ohne genannten Autor und ohne Primärquellen, und eine davon räumt ein, dass es keinen funktionierenden Gebrauchtmarkt gibt, gegen den man prüfen könnte. Wenn du ein echtes Angebot hast, schlägt deines meins. ↩
Veröffentlichte B200-Stundenpreise schwanken je nach Anbieter und Bindung enorm, grob von $2,14 bis $27,04 pro GPU-Stunde. Lambda listet $4,99 und Spheron $3,70 On-Demand gegen $2,74 Spot, während AWS p6 bei $14,24 liegt. getdeploying aggregiert mehr als 26 Anbieter. Ich habe $5,50 angesetzt, das zwischen Neocloud- und Hyperscaler-Preisen liegt und zu keinem passt, nimm es also als Annahme für die Mitte und nicht als Angebot. ↩
DESNZ, Quarterly Energy Prices, June 2026, tables 3.4.1 to 3.4.2. Volumengewichteter durchschnittlicher Strompreis für Nicht-Haushalte von 24,14p/kWh im Q1 2026, vorläufig, einschließlich Climate Change Levy und ohne Mehrwertsteuer. Ich habe auf 25p aufgerundet, wodurch die selbst gehosteten Optionen etwas schlechter dastehen und nicht besser. PUE ist die Power Usage Effectiveness, das Verhältnis der gesamten Anlagenleistung zu der Leistung, die tatsächlich bei der Hardware ankommt. ↩
Anthropic, Models overview. Opus 5 und Opus 4.8 kosten beide $5 pro Million Input-Tokens und $25 pro Million Output-Tokens. ↩