Die Kosten lokaler KI
Im Rahmen von KI-Souveränität, Datenschutz oder auch nur steigenden Tokenkosten stellt sich immer wieder die Frage nach einer selbst gehosteten KI-Lösung für den eigenen Bedarf. Aber was würde es kosten, eines der großen Open-Weight-Modelle aus unserem letzten Modellvergleich selbst zu betreiben und daraus einen verlässlichen Dienst für ein Unternehmen zu machen?
Die Gewichte gibt es umsonst, die Hardware aber nicht. In diesem Artikel geben wir eine grobe Schätzung der Hardwareanschaffungs- und Betriebskosten für GLM-5.3 und Kimi K3.
Ergebnis vorweg: Unsere Beispielrechnung landet bei rund 360.000 Euro Investition und 17.500 Euro monatlichen Vollkosten für GLM, bei 550.000 Euro und 26.600 Euro für Kimi. Daher sprechen wir auch noch Konzepte wie Quantisierung und Distillation an, die den Hardwarebedarf reduzieren können, und vergleichen die Kosten mit denen von Alternativen wie Self-Hosting auf gemieteten GPUs sowie der Nutzung von APIs. Zum Abschluss geben wir noch unsere Einschätzung dazu, welche Firmengrößen welche Betriebsarten ins Auge fassen sollten.
Preise sind nicht tagesaktuell und unterliegen Schwankungen mit Trend nach oben (Preisstand: Ende September 2026). Eigene Schätzungen netto, keine verbindlichen Angebote oder gemessenen Hardwareleistungen.
Welche Hardware brauchen GLM und Kimi?
Für unsere Beispielrechnung setzen wir einen Server mit acht H200-GPUs für GLM-5.3 und einen Server mit acht B300-GPUs für Kimi K3 an. Einschließlich Einrichtung kommen wir damit auf 360.000 beziehungsweise 550.000 Euro Anschaffungskosten. Soll für Kimi eine zweite vollständige Instanz als Ausfallreserve bereitstehen, steigt die Investition auf rund 1,08 Millionen Euro. Wie daraus die monatlichen Vollkosten entstehen, sehen wir uns im nächsten Abschnitt an.
Der größte Kostentreiber ist der benötigte GPU-Speicher. Die Gewichte der Modelle belegen mehrere hundert GB bis über ein TB. Für schnelle Inferenz sollten sie vollständig im Speicher der GPUs liegen. Zusätzlich wird Platz für die Verarbeitung der Anfragen benötigt. Gewichte teilweise in den Arbeitsspeicher oder auf SSDs auszulagern ist zwar möglich, verändert aber die erreichbare Geschwindigkeit und die Zahl gleichzeitig bedienbarer Anfragen.
Bei GLM-5.3 nennt das vLLM-Rezept rund 753 Milliarden Parameter (laut Hugging Face Model Card) und einen Server mit acht H200-GPUs für die veröffentlichte FP8-Variante. Für sehr lange Kontexte beschreibt das Rezept eine Konfiguration mit mehr GPU-Speicher. Die acht H200 sind deshalb nur ein Ausgangspunkt für unsere Kalkulation.
Kimi K3 ist noch einmal deutlich größer. Laut Model Card besitzt es 2,8 Billionen Parameter, von denen pro Token etwa 104 Milliarden aktiv sind. Diese Aufteilung auf sogenannte Experten spart Rechenarbeit. Für den schnellen GPU-Betrieb müssen trotzdem die Gewichte aller Experten Platz finden. Selbst in der veröffentlichten MXFP4-Darstellung mit überwiegend vier Bit pro Gewicht umfasst der dokumentierte Repository-Stand etwa 1,56 TB.
Für Kimi kalkulieren wir mit acht B300-GPUs. Ein vLLM-Bericht dokumentiert den Betrieb auf einem solchen Knoten. Das Serving-Rezept nennt dagegen mindestens acht GB300 und empfiehlt mehrere Knoten für Produktionsverkehr. Unser B300-Server ist daher eine Konfiguration für einen Pilotbetrieb, deren Kapazität mit den eigenen Aufgaben geprüft werden muss. Benötigt die tatsächliche Last mehrere Knoten, erhöht sich auch das Budget entsprechend.
Als Hardwarebudget ergibt unsere Recherche 280.000 bis 400.000 Euro für einen Server mit acht H200 und 450.000 bis 600.000 Euro für einen Server mit acht B300, jeweils vor der projektspezifischen Einrichtung. Orientierung bieten etwa das H200-Angebot von UpStation und die HGX-Angebote von Nelpx. Ausstattung, Lieferbedingungen und Service unterscheiden sich; die Angebote sind deshalb Preisanker für eine Größenordnung. Für die folgende Rechnung wählen wir daraus 330.000 Euro für den H200-Server und 500.000 Euro für den B300-Server.
Anschaffung, laufende Ausgaben und Vollkosten
Mit dem Kauf ist es nicht getan. Die Server verbrauchen Strom, müssen gekühlt und betreut werden und brauchen Platz in einer geeigneten Infrastruktur. Für einen Vergleich mit laufenden API-Ausgaben verteilen wir außerdem die Anschaffung auf die geplante Nutzungsdauer. Zusammen ergeben diese Positionen die monatlichen Vollkosten: rund 17.500 Euro für GLM und 26.600 Euro für Kimi.
Unsere Rechnung geht von drei Jahren Nutzung ohne Restwert und durchschnittlich 730 Betriebsstunden im Monat aus. Für den gesamten H200-Server nehmen wir im Monatsmittel 7 kW elektrische Leistung an, für den B300-Server 11 kW. Das sind Planungsannahmen, keine Messwerte. Bei 0,25 Euro je Kilowattstunde berücksichtigen wir zusätzlich einen Infrastrukturaufschlag über eine PUE von 1,20. PUE steht für das Verhältnis der gesamten Energieaufnahme zur Energieaufnahme der IT: Zu jeder Kilowattstunde für den Server kommen in dieser Annahme 0,20 Kilowattstunden für Kühlung und elektrische Verluste hinzu.
Für Wartung und Ersatzteile reservieren wir jährlich fünf Prozent des Hardwarepreises. Die Betreuung setzen wir mit 3.000 Euro monatlich für GLM, 4.500 Euro für eine Kimi-Instanz und 9.000 Euro für zwei Instanzen an. Zusätzlich rechnen wir mit sechs Prozent jährlichen Kapitalkosten auf das im Mittel noch gebundene Kapital, vereinfacht die Hälfte der Gesamtinvestition.
GPU-Hosting dieser Größenordnung stellt gegenüber klassischem Web- oder Anwendungsserver-Hosting deutlich höhere Anforderungen an Stromversorgung und Wärmeabfuhr. Bei angenommenen 11 kW IT-Dauerlast müssen ungefähr 11 kW Wärme abgeführt werden. Flüssigkühlung ist dabei nicht grundsätzlich erforderlich, eine entsprechend ausgelegte Kühlung aber schon. Hinzu kommen Anforderungen an Rack- und Bodenlast, Lärmschutz sowie schnelle Verbindungen zwischen den GPUs bei mehreren Knoten. Auch der Betrieb erfordert zusätzliche Expertise, um GPU-Treiber, Inferenzsoftware und Modellformate aufeinander abzustimmen und Ersatzkapazität für Ausfälle vorzuhalten. Für den Produktivbetrieb müssen außerdem die Lizenzbedingungen der konkreten Modellversion geprüft werden, denn offene Gewichte bedeuten nicht automatisch uneingeschränkte kommerzielle Nutzung.
Damit ergibt sich folgende Aufstellung. Alle Werte sind eigene Szenariorechnungen, netto und auf volle Euro gerundet:
| Kostenblock | GLM: 8 H200 | Kimi: 8 B300 | Kimi: zwei Instanzen |
|---|---|---|---|
| Hardware einmalig | 330.000 € | 500.000 € | 1.000.000 € |
| Einrichtung einmalig | 30.000 € | 50.000 € | 80.000 € |
| Gesamtinvestition | 360.000 € | 550.000 € | 1.080.000 € |
| Energie inkl. Kühlung pro Monat | 1.533 € | 2.409 € | 4.818 € |
| Wartung/Ersatzteilreserve pro Monat | 1.375 € | 2.083 € | 4.167 € |
| Infrastruktur ohne Strom pro Monat | 700 € | 1.000 € | 1.500 € |
| Zusätzliche Betreuung pro Monat | 3.000 € | 4.500 € | 9.000 € |
| Laufende Ausgaben inkl. Betreuung pro Monat | 6.608 € | 9.992 € | 19.485 € |
| Abschreibung pro Monat | 10.000 € | 15.278 € | 30.000 € |
| Kalkulatorische Kapitalkosten pro Monat | 900 € | 1.375 € | 2.700 € |
| Monatliche Vollkosten | 17.508 € | 26.645 € | 52.185 € |
Die Unterscheidung zwischen laufenden Ausgaben und Vollkosten ist wichtig: Für eine Kimi-Instanz fallen in unserem Beispiel rund 10.000 Euro monatlich für Energie, Infrastruktur, Betreuung und Wartungsreserve an. Einschließlich Abschreibung und Kapitalbindung kostet der Betrieb wirtschaftlich jedoch rund 26.600 Euro im Monat.
Die dritte Spalte zeigt schließlich, was eine zweite Kimi-Instanz als Ausfallreserve kostet. Sie bietet nur dann Reserve für die gesamte zugesagte Last, wenn ein einzelner Server diese Last im Fehlerfall übernehmen kann. Werden beide Server schon im normalen Betrieb vollständig ausgelastet, fehlt diese Reserve. Ob die vorgesehene Konfiguration ausreicht, muss ein Lasttest zeigen.
Geht es auch kleiner? Quantisierung und Distillation
Eine halbe Million Euro ist eine erhebliche Investition. Sie ist aber keine Eintrittsgebühr für jede Form von selbst betriebener KI. Entscheidend ist, welche Fähigkeiten die eigenen Anwendungen tatsächlich benötigen und in welcher Form das Modell betrieben wird. Für bestimmte Aufgaben kann ein kleineres Modell auf einer Workstation bereits ausreichen.
Zwei Konzepte helfen, diese Unterschiede zu verstehen: Quantisierung reduziert den Speicherbedarf, indem Gewichte mit weniger Bits dargestellt werden. Distillation überträgt Fähigkeiten eines Lehrermodells auf ein eigenständiges, häufig kleineres Schülermodell. Beides kann die Hardwareanforderungen senken, muss aber an der Qualität der Ergebnisse gemessen werden.
Die oben kalkulierten Varianten nutzen mit FP8 und MXFP4 bereits reduzierte Präzision. Eine pauschale weitere Halbierung oder Viertelung ihrer Kosten lässt sich deshalb nicht ableiten. GLM-5.3 gibt es aber auch als NVFP4-Variante (rund 465 GB) und kann auf 8×RTX PRO 6000 für etwa 150.000–200.000 € betrieben werden.
Ein kleineres Distillat wäre wiederum ein anderes Modell, für das wir Qualität, Kapazität und Kosten neu bewerten müssten.
Einen tieferen Einstieg in diese Konzepte bieten unter anderem Artikel wie Hugging Face zur 8-Bit-Quantisierung und NVIDIA zu Pruning und Knowledge Distillation
Was kostet dieselbe Tokenmenge über eine API?
Der eigenen Hardware stehen Dienste gegenüber, bei denen wir die tatsächlich verarbeiteten Tokens bezahlen. Dabei lohnt sich zunächst der Vergleich mit der API desselben Modells: Wer GLM selbst betreiben möchte, muss sich auch an den Preisen der GLM-API messen lassen. Erst danach stellt sich die Frage, ob sich damit teurere Modelle von OpenAI oder Anthropic ersetzen lassen.
Neben den Modellherstellern bieten auch Drittanbieter API-Zugriff auf verschiedene Modelle an, beispielsweise GLM über Amazon Bedrock. Die genaue Modellverfügbarkeit und die jeweiligen Preise dieser Angebote gehen über den Rahmen dieses Artikels hinaus und müssen für den konkreten Einsatz geprüft werden.
Für eine erste Gegenüberstellung nehmen wir einen Beispielmix aus vier Millionen Input-Tokens und einer Million Output-Tokens*. Input umfasst die an das Modell übergebenen Inhalte, Output die vom Modell erzeugten Tokens.
*Das Verhältnis von vier zu eins ist eine Rechenannahme. Wie es in einer Anwendung tatsächlich ausfällt, hängt unter anderem von der Länge der Dokumente, dem Gesprächsverlauf und den erzeugten Antworten ab.
Angegeben sind US-Dollar für die Standardverarbeitung bei kurzen Kontexten, ohne Cache-Nutzung, Steuern, Mengenrabatte oder zusätzliche Toolkosten. Die verlinkten Preisseiten können inzwischen andere Konditionen ausweisen. Die Annahme „ohne Cache“ ist maximal pessimistisch, tatsächliche Kosten liegen in den meisten Fällen darunter.
| Modell / Preisquelle | Input je Mio. Tokens | Output je Mio. Tokens | Kosten des Beispielmixes |
|---|---|---|---|
| GLM-5.3 | 1,40 $ | 4,40 $ | 10,00 $ |
| GPT-6 Sol | 2,00 $ | 10,00 $ | 18,00 $ |
| Kimi K3 | 3,00 $ | 15,00 $ | 27,00 $ |
| Claude Opus 5.5 | 4,00 $ | 20,00 $ | 36,00 $ |
| Claude Fable 5.1 | 10,00 $ | 50,00 $ | 90,00 $ |
| GPT-6 Astra | 10,00 $ | 50,00 $ | 90,00 $ |
Schon bei identischer Tokenmenge unterscheidet sich die Rechnung erheblich. Daraus folgt allerdings noch keine Rangfolge der Wirtschaftlichkeit. Ein teureres Modell kann eine Aufgabe mit weniger Versuchen oder weniger menschlicher Nacharbeit erledigen. Umgekehrt kann ein günstigeres Modell für die benötigte Leistung vollkommen ausreichen.
Für die fachliche Entscheidung zählt letztlich der Preis pro erfolgreich erledigter Aufgabe. Verschiedene Modelle zerlegen denselben Text unterschiedlich in Tokens. Zusätzliche Reasoning-Tokens, Wiederholungen und Korrekturen verändern den Verbrauch ebenfalls. Eigene Tests, wie in unserem Beitrag zum Schlösserknacken für LLMs, sind deshalb die Grundlage dafür, welche Modelle sich tatsächlich gegenseitig ersetzen können.
Der rechnerische Break-even muss auf den Server passen
Mit diesen Preisen können wir ausrechnen, bei welchem Verbrauch eine API dieselben monatlichen Kosten verursacht wie unser eigener Server. Wir behalten dafür den Mix aus vier Input-Tokens je Output-Token ohne Cache bei und verwenden einen Planungswechselkurs von 1 USD = 0,90 EUR.
Für GLM kostet ein Paket aus vier Millionen Input- und einer Million Output-Tokens damit 9 Euro. Teilen wir die monatlichen Vollkosten des eigenen Servers von 17.508 Euro durch diesen Paketpreis, erhalten wir rund 1.945 solcher Pakete. Das entspricht 1,945 Milliarden Output-Tokens und zusätzlich rund 7,782 Milliarden Input-Tokens pro Monat. Erst bei diesem Volumen wäre die GLM-API in unserer vereinfachten Rechnung genauso teuer wie der Eigenbetrieb.
Diese Menge muss der Server allerdings auch bewältigen können. Verteilt auf 730 Stunden wären durchschnittlich rund 740 Output-Tokens pro Sekunde erforderlich. Konzentriert sich die Nutzung auf 176 Bürozeitenstunden im Monat, steigt der notwendige Durchschnitt auf rund 3.070 Output-Tokens pro Sekunde. Hinzu kommt jeweils die Verarbeitung der vierfachen Input-Menge. Lastspitzen würden zusätzliche Kapazität verlangen.
Bei Kimi kostet der Beispielmix umgerechnet 24,30 Euro. Gegenüber den monatlichen Vollkosten von rund 26.645 Euro liegt der Gleichstand bei 1,097 Milliarden Output-Tokens pro Monat, wiederum zuzüglich der vierfachen Input-Menge. Bei gleichmäßiger Nutzung über 730 Stunden müsste der Server dafür im Mittel etwa 417 Output-Tokens pro Sekunde erzeugen. Laut dem vLLM Bericht wurden mit der Beispielhardware 725 Tokens/s erreicht. Genug für das Mittel, beim reinen „Bürozeitbetrieb“ wären ~1730 Tokens pro Sekunde notwendig, also deutlich über dem Messwert.
Gegenüber den teureren APIs von Astra oder Fable erreicht der Kimi-Server bereits bei rund 329 Millionen Output-Tokens monatlich den Gleichstand.
Also hat der wirtschaftliche Break-even damit zwei Voraussetzungen: Das eigene Modell muss nicht nur die benötigte Qualität liefern, sondern auch die erforderliche Menge innerhalb der akzeptierten Antwortzeiten bewältigen. Reicht die Kapazität eines Servers nicht aus, müssen weitere Instanzen eingerechnet werden. Was natürlich die Kosten weiter in die Höhe treibt.
GPUs mieten als dritte Option
GPUs können natürlich auch bei einem Cloud-Anbieter gemietet werden. Zum Beispiel bietet Lambda unter anderem Instanzen mit acht B200 an.
Auch Hyperscaler wie AWS, Microsoft Azure und Google Cloud bieten vergleichbare GPU-Instanzen an. Vorsicht beim Buchungsmodell: Bei AWS Capacity Blocks wird ein festes Zeitfenster im Voraus reserviert und bezahlt, unabhängig von der anschließenden Nutzung.
Für kleinere Modelle oder stark quantisierte Varianten können auch einzelne GPUs über Runpod Pods infrage kommen.
Als Preisanker für einen GLM-Pilot nennt Lambda 6,69 USD je GPU-Stunde bei einer Instanz mit acht B200, insgesamt also 53,52 USD pro Stunde. Ein durchgehender Betrieb über 730 Stunden würde bereits rund 35.163 Euro monatlich erreichen, jeweils vor Steuern und eigener Betreuung.
Die Miete eignet sich besonders, um Qualität und Kapazität vor einer Anschaffung zu prüfen oder zeitlich begrenzte Lasten abzudecken. Für einen dauerhaften Betrieb müssen Tarif, Standort, Verfügbarkeit, zusätzlicher Speicher und bei mehreren GPUs deren Verbindung in die Rechnung einfließen.
Welche Firmengröße sollte darüber nachdenken?
Für sehr kleine Teams lässt sich der Eigenbetrieb aktueller großer LLMs in unserer Beispielrechnung wirtschaftlich kaum rechtfertigen. Dafür ist die Kostenschwelle einfach zu hoch. Für die interaktive Nutzung kommen auch Abos infrage: Je nach Tarif und Nutzung können sie für 20–200 US-Dollar/Monat mehr Modellnutzung ermöglichen als ein entsprechendes API-Budget. Das kann auch die Miete von Rechenleistung unattraktiv machen. Ein Abo ersetzt allerdings keinen API-Zugang für eigene Anwendungen.
Für mittelständische Unternehmen gilt es, die aktuelle und geplante KI-Nutzung möglichst exakt zu schätzen. Die Mitarbeiterzahl ist dabei eine schwache Kenngröße, und auch die Zahl der aktiven KI-Nutzer ist nur mäßig geeignet. Zehn Poweruser, die Anwendungen entwickeln, können wesentlich mehr Tokens verbrauchen als 100 Nutzer, die sich nur täglich ihre neuen E-Mails zusammenfassen lassen. Dabei ist auch die Art der Aufgaben zu beachten: Schon kleine Modelle sind in der Lage einen Text gut zusammenfassen. Fehler im eigenen Legacy-Code mit proprietären Bibliotheken beheben zu lassen, erfordert dagegen wahrscheinlich mehr „Gehirnkapazität“.
Sind KI-Aufgabenfeld, Nutzeranzahl und ungefährer Tokenverbrauch hinreichend geklärt, kann man folgende von uns aufgestellte Entscheidungshilfen als Orientierung nehmen:
- Bei unter 10.000 Euro (optimierten) API-Ausgaben monatlich ist der Kauf von Hardware für diese Modellklasse schwer zu begründen.
- 10.000–30.000 Euro monatlich rechtfertigen eher einen Pilotbetrieb auf gemieteten GPUs.
- 30.000–60.000 Euro dauerhaft ersetzbare Ausgaben pro Monat machen eine konkrete Eigenbetriebsrechnung interessant. Für hohe Last und Redundanz kann mehr nötig sein.
- Datensouveränität, Offlinefähigkeit und Versionskontrolle können Mehrkosten rechtfertigen.
Für die konkrete Entscheidung empfehlen wir folgendes Vorgehen:
Erst mieten und messen, dann kaufen
Zuerst mit einigen repräsentativen Aufgaben aus dem eigenen Unternehmen beginnen. Die Performance verschiedener Modelle anhand möglichst fachlicher Kriterien prüfen. Auch kleine Modelle und Distillate sollten eine Chance bekommen. Sind diese bereits gut genug, kann der Eigenbetrieb deutlich günstiger werden als in den obigen Referenzkonfigurationen.
Parallel dazu sollte der aktuelle Verbrauch möglichst genau über einen hinreichend langen Zeitraum (etwa drei Monate) erfasst werden. Eine Aufschlüsselung nach Aufgabe, Modell, Input-, Cache-, Output- und Reasoning-Tokens sowie Tageszeit kann dabei hilfreich sein. So wird sichtbar, welche Kosten regelmäßig entstehen und wann Lastspitzen auftreten.
Damit lässt sich anschließend ein Pilotbetrieb auf gemieteten GPUs planen. Dafür sollte möglichst genau die Zielhardware- und Modellkonfiguration zum Einsatz kommen. Mit realistischen Kontextlängen und Spitzenlasten kann man sowohl die Ergebnisqualität als auch die Antwortzeiten und die nutzbare Kapazität messen.
Erst nach all dem sollten vollständige Angebote eingeholt werden. Neben der reinen Hardware sollten diese auch Service, Stellplatz, Stromversorgung und Kühlung abdecken. Am besten stellt die Kostenrechnung mehrere Nutzungsdauern von 24, 36 und 48 Monaten gegenüber. Längere Planungshorizonte sind bei den aktuellen Entwicklungen im Feld wahrscheinlich nicht sinnvoll. Auch weiterhin benötigte APIs sowie der Integrations- und Migrationsaufwand müssen berücksichtigt werden.
Mit diesem Ansatz entsteht eine Entscheidungsgrundlage, die auf erfolgreich erledigten Aufgaben und gemessener Auslastung beruht.
Weiterlesen
- Coding-Modelle im Herbst 2026: Sieben Modelle, eine Messlatte — Modellleistung und Aufgabenkosten als Ausgangspunkt.
- Schlösserknacken für LLMs — eigene Tests und ihre Aussagegrenzen.
- LLM-Modellfamilien im Überblick — Herkunft, offene Gewichte und europäische Optionen.
Sie möchten wissen, welches Modell zu Ihrem Anwendungsfall passt? Wir helfen bei der Auswahl, beim Aufbau eigener Testfälle und beim Betrieb, ob über eine API oder auf eigener Infrastruktur. Sprechen Sie uns an, wir freuen uns auf den Austausch.
Der Artikelentwurf wurde mit KI-Unterstützung erstellt und anschließend redaktionell geprüft und überarbeitet.