Kimi K3 selbst zu hosten wurde am 27. Juli 2026 technisch möglich, als Moonshot AI die Gewichte eines Modells mit 2,8 Billionen Parametern zusammen mit produktionsreifer Inferenzunterstützung veröffentlichte. Sehr viele Organisationen lasen diese Nachricht und schlossen daraus, sie könnten nun Reasoning der Spitzenklasse auf eigener Hardware betreiben und aufhören, pro Token zu zahlen.

Diese Schlussfolgerung ist meist falsch, aber nicht aus dem erwarteten Grund. Die Technik ist machbar. Es ist die Rechnung, die die meisten Projekte scheitern lässt, und sie tut es leise, mehrere Monate nach der Budgetfreigabe.

Die kurze Antwort: Bei MXFP4-Präzision belegen 2,8 Billionen Parameter rund 1,4 TB, noch ohne jeden Key-Value-Cache. Ein einzelner Knoten mit acht H100 fasst 640 GB und kann dieses Modell daher überhaupt nicht ausliefern. Realistische Deployments beginnen bei etwa 1,7 TB VRAM, also aktuellen Knoten mit 288-GB-Beschleunigern oder Sechzehner-Konfigurationen der vorherigen Generation, und Moonshot verweist Produktionsnutzer auf Cluster mit vierundsechzig oder mehr Beschleunigern.

Was offene Gewichte Ihnen wirklich geben

Vor der Hardware die Lizenz, denn sie entscheidet, ob sich das alles überhaupt zu planen lohnt.

Die veröffentlichten Gewichte tragen eine eigene Lizenz, die die Modellkarte Kimi K3 License nennt. Es ist keine schlichte MIT- oder Apache-Gewährung, und Zusammenfassungen Dritter, die sie so beschreiben, sollten Sie nicht heranziehen. Lesen Sie den Lizenztext selbst und lassen Sie ihn prüfen, bevor Sie sich auf einen kommerziellen Einsatz festlegen, mit besonderem Blick auf Namensnennungspflichten und auf Bedingungen, die ab bestimmten Nutzungsgrößen greifen. Das kostet einen Nachmittag und erspart ein schwieriges Gespräch.

Was die Gewichte tatsächlich kaufen, ist Kontrolle. Ihre Daten verlassen Ihre Umgebung nie. Niemand stellt das Modell unter Ihnen ein oder ändert den Preis. Sie können feinjustieren, weiter quantisieren oder das Auslieferungsverhalten so verändern, wie es eine API nie erlauben wird. Für Organisationen mit Souveränitätspflichten sind genau das die entscheidenden Eigenschaften, und Kosten sind zweitrangig.

Was sie Ihnen nicht kaufen, ist ein billigerer Weg, das zu tun, was die API bereits tut. Diese Unterscheidung klarzustellen ist das Nützlichste, bevor irgendjemand Hardware spezifiziert.

Kimi K3 selbst hosten: die Hardware-Rechnung

Beginnen Sie bei den Gewichten und arbeiten Sie nach außen, denn jede weitere Anforderung folgt daraus.

Zwei Komma acht Billionen Parameter zu je vier Bit ergeben etwa 1,4 TB, und all das muss im Speicher der Beschleuniger liegen, um Anfragen mit vernünftigem Tempo zu bedienen. Schon diese Zahl schließt die Konfiguration aus, die die meisten Teams voraussetzen. Acht H100-Karten mit je 80 GB liefern 640 GB, weniger als die Hälfte dessen, was die Gewichte brauchen.

Dann kommt der Key-Value-Cache hinzu. Ein Modell, das eine Million Token Kontext bewirbt, braucht Platz für den Attention-Zustand jeder gleichzeitigen Anfrage, und diese Zuteilung skaliert mit Kontextlänge und Batchgröße. Veröffentlichte vLLM-Metadaten setzen den minimal tragfähigen Auslieferungsbedarf bei rund 1.680 GB an, was zu Gewichten plus bescheidenem Cache ohne Reserve für ehrgeiziges Batching passt.

Praktisch bedeutet das eine von wenigen Formen. Acht aktuelle Beschleuniger mit je 288 GB, ob NVIDIA B300 oder AMD MI355X, ergeben rund 2,3 TB in einem Knoten und sind die geradlinigste Option. Sechzehn Karten der B200- oder GB200-Klasse erreichen eine ähnliche Summe über eine größere Fläche. Für dauerhaften Produktionsdurchsatz statt eines Machbarkeitsnachweises verweist Moonshots eigene Empfehlung auf Supernode-Konfigurationen mit vierundsechzig oder mehr Beschleunigern.

Ein Detail verdient Nachdruck, weil es jene trifft, die zuvor dichte Modelle betrieben haben. Dies ist eine Mixture-of-Experts-Architektur, die jedes Token an sechzehn von 896 Experten leitet, was erhebliche All-to-All-Kommunikation zwischen den Geräten mit unterschiedlichen Experten erzeugt. Interconnect-Bandbreite ist hier kein Nice-to-have. Eine Konfiguration mit ausreichendem Gesamtspeicher, aber schwachem Interconnect liefert einen Durchsatz weit unter dem Datenblatt, und das nach dem Kauf zu diagnostizieren ist eine teure Lektion.

Den Betrieb zum Laufen bringen

Die Softwareseite ist gefestigter als noch vor einem Jahr, was hilft.

Die Modellkarte nennt vLLM, SGLang und TokenSpeed als unterstützte Inferenz-Engines. Entscheidend ist, dass die Unterstützung für Kimi Delta Attention zeitgleich mit den Gewichten erschien und nicht später, sodass ein aktueller vLLM-Build die von der Architektur benötigten Kernel enthält. Eine ältere Installation tut das nicht, und das ist das Erste, was Sie prüfen sollten, wenn ein Deployment nicht startet.

Planen Sie über die Engine hinaus die Logistik. Sie ziehen und speichern über ein Terabyte an Gewichten, also stellen Sie schnellen lokalen Speicher bereit und rechnen Sie damit, dass der erste Download und das Laden echte Zeit brauchen statt Minuten. Begrenzen Sie die maximale Kontextlänge pro Anfrage, denn wenn Sie jedem Aufrufer eine Million Token zugestehen, erschöpfen wenige gleichzeitige Nutzer Ihre Cache-Zuteilung. Entscheiden Sie früh, ob Sie auf Latenz oder Durchsatz optimieren, da aggressives Batching die Token pro Sekunde verbessert und die Zeit bis zum ersten Token verschlechtert. Beides zugleich geht nicht.

Behandeln Sie das schließlich als Produktionsinfrastruktur und nicht als Forschungsaufbau. Es braucht Monitoring, Kapazitätsplanung, Disziplin bei Treiber- und Kernelversionen und jemanden, der erreichbar ist, wenn es steht. Genau diese Betriebslast fehlt am häufigsten im Business Case.

Der Kostenvergleich, den niemand rechnet

Hier ist die Rechnung, die die meisten dieser Projekte entscheidet, und sie gehört vor das Hardwaregespräch, nicht danach.

Ein Knoten, der K3 ausliefern kann, kostet je nach Anbieter, Region und Bindung sehr unterschiedlich, aber eine Spanne zwischen 25.000 und 50.000 US-Dollar im Monat ist ein vernünftiger Planungsrahmen für aktuelle Hardware. Ein Direktkauf kostet vorab deutlich mehr und lohnt sich nur mit mehrjährigem Horizont.

Vergleichen Sie das nun mit der API. Bei rund 15 US-Dollar je Million Output-Token kauft eine Infrastrukturrechnung von 30.000 US-Dollar monatlich zwei Milliarden Output-Token beim gehosteten Dienst. Zwei Milliarden Output-Token im Monat sind etwa sechsundsechzig Millionen am Tag. Wenn eine typische Antwort 1.500 Token umfasst, sind das rund vierundvierzigtausend Antworten jeden Tag, dauerhaft, bevor Selbsthosting allein bei den Kosten die Gewinnschwelle erreicht.

Schlimmer noch: Dieser Vergleich unterstellt, dass Ihr Cluster rund um die Uhr voll ausgelastet läuft. Die meisten Workloads tun das nicht. Sie haben Spitzen zu Geschäftszeiten und liegen nachts brach, und Sie zahlen die Leerlaufzeit genau wie die Betriebszeit. Eine effektive Auslastung von dreißig Prozent, üblich bei internen Werkzeugen, verdreifacht die effektiven Kosten je Token ungefähr und rückt die Gewinnschwelle weiter außer Reichweite.

Der Schluss ist unbequem, aber konsistent. Für die überwältigende Mehrheit der Organisationen kostet das Selbsthosten von Kimi K3 mehr als die Nutzung der API. Wenn der Business Case auf Kostenersparnis beruht, rechnen Sie diese Zahlen mit echten Angeboten und echten Mengenprognosen durch, bevor jemand eine Bestellung unterschreibt.

Wann Selbsthosting wirklich richtig ist

Kosten sind der falsche Grund. Dies sind die richtigen.

Regulatorische oder vertragliche Pflichten, die verhindern, dass Daten Ihre Infrastruktur verlassen, entscheiden für Sie, und keine noch so günstige API-Preisgestaltung ändert daran etwas. Verteidigung, Gesundheitswesen und Teile der Finanzdienstleistung stehen regelmäßig an dieser Stelle, und für sie lautet die Rechnung schlicht, was Compliance kostet.

Wirklich hohes Dauervolumen dreht die Arithmetik. Wenn Sie monatlich Milliarden von Token bei gleichmäßiger Auslastung verbrauchen, gewinnt das Fixkostenmodell, und es gewinnt mit wachsendem Volumen weiter, statt linear mitzuwachsen.

Planbarkeit hat einen eigenen Wert. Das Deployment zu besitzen bedeutet keine Abkündigungen, keine Preisänderungen mitten im Vertrag und keine Ratenbegrenzungen aus fremder Kapazitätsplanung. Für ein Produkt, dessen Kernfunktion vom Modell abhängt, kann diese Stabilität die Ausgabe allein rechtfertigen.

Und wenn Sie feinjustieren, das Auslieferungsverhalten ändern oder in einer abgeschotteten Umgebung betreiben wollen, kann die API Ihnen zu keinem Preis helfen.

Seien Sie im Gegenzug ehrlich zu den Fällen, in denen es falsch ist: schwankendes oder bescheidenes Volumen, ein Team ohne GPU-Betriebserfahrung, oder ein Business Case, der vor allem auf Kostensenkung baut. Unser Leitfaden zur Kimi K3 API behandelt den gehosteten Weg, und die sinnvolle Reihenfolge lautet für die meisten Organisationen: zuerst gegen die API bauen und erst dann auf eigene Infrastruktur wechseln, wenn Volumen und Anforderungen es rechtfertigen.

Ein vernünftiger Mittelweg

Sehr wenige Organisationen brauchen eine Alles-oder-nichts-Antwort, und die hybride Anordnung ist meist die stärkste.

Leiten Sie den Großteil des Verkehrs auf die gehostete API, wo Sie nur für tatsächliche Nutzung zahlen. Reservieren Sie ein selbst gehostetes Deployment für genau die Workloads, die Daten tragen, welche Ihre Umgebung wirklich nicht verlassen dürfen. Weil K3 hinter beiden Wegen dasselbe Modell bereitstellt, können Sie Anfragen nach Datenklassifizierung statt nach Fähigkeit lenken, und die Anwendung muss nicht wissen, welchen Pfad sie genommen hat.

Dieser Ansatz verlangt dieselbe Abstraktionsschicht, die unser Leitfaden zur OpenAI-API-Integration beschreibt: einen Proxy, dem Zugangsdaten, Routing und Messung gehören, sodass Anbieter und Standort zur Konfiguration werden statt zur Architektur. Bauen Sie sie einmal, und beide Optionen bleiben offen.

Planen Sie das Deployment mit Leuten, die es schon gemacht haben

Mecanik bietet KI-Integrationsleistungen für gehostete, selbst gehostete und hybride Sprachmodell-Deployments, einschließlich der Kapazitätsmodellierung, die Ihnen sagt, welche Variante Ihre Workload tatsächlich rechtfertigt.

Wir rechnen Auslastung und Gewinnschwelle gegen Ihren echten Verkehr, spezifizieren die Hardware ehrlich und sagen Ihnen, wann die API die bessere Antwort ist, was häufig der Fall ist. Wo ein selbst gehostetes Deployment gerechtfertigt ist, decken unsere Leistungen zur Softwareentwicklung den Serving-Stack, die Routing-Schicht, das Monitoring und die Logik zur Datenklassifizierung ab. Die vollständigen Spezifikationen sind auf der Kimi K3 Modellkarte veröffentlicht.

Siehe auch: Existiert echte KI? Die Mythen und Realität entwirren , Retrieval-Augmented Generation (RAG) erklärt 2026 , OpenAI ChatGPT 5 vs Grok 4 - Welcher erstellt besseren Python-Code? , KI-Agentur vs. Inhouse: KI-Einführung in Großbritannien 2026 ., Tiny BPE Trainer - Ein schneller und leichter BPE-Trainer in C++

Häufig gestellte Fragen

Welche Hardware brauche ich, um Kimi K3 selbst zu hosten? Bei MXFP4-Präzision belegen die Gewichte rund 1,4 TB, und realistisches Ausliefern braucht mit Key-Value-Cache etwa 1,7 TB VRAM. Das schließt einen Achter-H100-Knoten mit 640 GB aus und verweist stattdessen auf acht aktuelle 288-GB-Beschleuniger, Sechzehner-Konfigurationen der Vorgängergeneration oder größere Cluster für Produktionsdurchsatz.

Ist das Selbsthosten von Kimi K3 günstiger als die API? Meist nicht. Ein geeigneter Knoten kostet rund 25.000 bis 50.000 US-Dollar im Monat, was etwa zwei Milliarden Output-Token bei der gehosteten API kauft. Solange Sie dieses Volumen nicht rund um die Uhr bei hoher Auslastung halten, ist die API günstiger. Selbsthosting rechtfertigt sich durch Datenhoheit und Kontrolle, nicht durch Kosten.

Welche Lizenz haben die Kimi K3 Gewichte? Die Modellkarte nennt eine eigene Lizenz, die Kimi K3 License, und keine übliche MIT- oder Apache-Gewährung. Lesen Sie den Lizenztext direkt und holen Sie vor kommerziellem Einsatz eine rechtliche Prüfung ein, da Zusammenfassungen Dritter, die sie als Standard-Open-Source-Lizenz beschreiben, nicht verlässlich sind.

Welche Inferenz-Engines unterstützen Kimi K3? Die Modellkarte nennt vLLM, SGLang und TokenSpeed. Die Unterstützung für den Kimi-Delta-Attention-Mechanismus erschien zeitgleich mit den Gewichten, Sie brauchen also einen aktuellen Build mit diesen Kerneln. Ältere Installationen können das Modell nicht laden.

Kann ich Kimi K3 auf einer einzelnen Maschine betreiben? Nur auf einem hochwertigen Server mit mehreren Beschleunigern. Ein Knoten mit acht 288-GB-Karten kann das Modell halten, Consumer-Hardware und Einzel-GPU-Workstations kommen aber nicht annähernd heran. Durch das Mixture-of-Experts-Routing ist zudem die Interconnect-Bandbreite zwischen den Beschleunigern ein wesentlicher Faktor für den erreichten Durchsatz.