Kimi K3 lokal ausführen: 610 GB VRAM-Floor und was das für Mittelstands-Server bedeutet

TL;DR

Kimi K3 von Moonshot AI ist das größte jemals veröffentlichte Open-Weight-Modell: 2,8 Billionen Gesamtparameter, davon 104 Milliarden aktiv pro Token. Die Größe ist aber auch das Problem: Selbst die aggressivste 1-Bit-Quantisierung braucht rund 610 GB RAM plus VRAM, die offiziellen 4-Bit-Gewichte liegen bei ~1,4–1,6 TB. Damit ist K3 für klassische Mittelstands-Server nicht lauffähig – weder mit einer RTX 5090 noch mit einer 512-GB-Mac-Studio. Der Ollama-Eintrag kimi-k3 ist nur ein Cloud-Tag, der auf den Servern von Moonshot läuft. Für die eigene GPU bleiben kleinere Modelle wie DeepSeek, Qwen oder Gemma die realistische Wahl. Wer trotzdem in Richtung K3 plant, muss mit Server-Kosten ab ca. 25.000–40.000 EUR rechnen – oder K3 über die API mit Zero Data Retention nutzen.

Warum Kimi K3 gerade jetzt relevant ist

Am 04.11.2026 hat Moonshot AI die Gewichte von Kimi K3.1 Pro veröffentlicht – pünktlich zum angekündigten Termin, als 96 Dateien mit insgesamt 1,56 TB in nativer MXFP4-Quantisierung. K3.1 Pro ist die Weiterentwicklung des im Juli 2026 veröffentlichten K3 mit deutlich mehr Training, nutzt aber dieselbe Architekturklasse: 2,8T Gesamtparameter / 104B aktiv (Mixture of Experts), 1M Token Kontext, multimodal über den MoonViT-V2-Encoder.

Für IT-Verantwortliche im Mittelstand tauchen dazu gerade zwei Fragen auf:

1. Können wir dieses „größte Open-Weight-Modell der Welt" auf einem eigenen Server betreiben?
2. Was bedeutet der Ollama-Eintrag „kimi-k3"? Lohnt sich das Modell für lokale KI?

Die Antworten sind ernüchternd – und genau deshalb planungsrelevant. Denn wer eine GPU-Beschaffung mit K3 im Hinterkopf startet, investiert schnell in die falsche Richtung. Dieser Artikel liefert die Zahlen, die Kosten und eine Entscheidungsmatrix.

Die harte Realität: Was K3 wirklich braucht

Die entscheidende Kennzahl ist nicht die Parameterzahl, sondern der Speicherbedarf. Da K3 ein MoE-Modell mit 2,8T Parametern ist, müssen die Gewichte vollständig im Speicher liegen – auch wenn pro Token nur 104B aktiv sind.

Quellen: Unsloth-Dokumentation (Stand 04.11.2026), LLM Configurator. Die 1-Bit-Werte sind kalibrierte Community-Builds.

Diese Zahlen sind keine Hypothesen, sondern gemessene Dateigrößen. Schon der Download der 1-Bit-Variante verbraucht 594 GB – etwa die Hälfte eines typischen 1,2-TB-Datenvolumens.

Drei Wege an den 610-GB-Floor – und was sie kosten

Es gibt genau drei Hardware-Pfade, die den Floor erreichen. Keiner davon ist ein normales Serversystem:

Letzteres ist der Haken: Die offizielle Deployment-Arbeit von Moonshot fokussiert auf vLLM, SGLang, TokenSpeed und accelerator-spezifische Kerne. Für „normale" GPU-Server gibt es kein produktionsreifes Serving. Ein Mittelständler, der K3 selbst hosten will, betritt Neuland – mit Datacenter-Budget.

Kimi K3 und Ollama: Was der Cloud-Tag bedeutet

Ollama listet kimi-k3 in der Modellbibliothek. Der entscheidende Punkt: Es gibt keinen lokalen Tag. Der veröffentlichte Tag ist ein Cloud-Tag – kimi-k3:cloud – der auf den Servern von Moonshot/Ollama läuft, nicht auf Ihrer Maschine.

Das heißt konkret:

• ollama run kimi-k3 sendet Ihre Prompts und Dateien an einen gehosteten Dienst.
• Es ist kein lokaler Betrieb im Sinne von Datenhoheit.
• Es gibt kein GGUF für K3.1 Pro: Die neue Architektur kimi_k31 mit 24 Sparse-Attention-Layern ist kein Drop-in für die vorhandene K3-Tooling-Kette. Unsloth prüft kalibrierte Builds, Stand 04.11.2026 existieren sie nicht.
• Der für lokales Hosting übliche Weg (GGUF via llama.cpp/Ollama) ist damit aktuell komplett versperrt.

Wer im Unternehmenskontext „Kimi K3 auf dem eigenen Server" sucht, findet also aktuell keine technisch tragfähige Lösung. Das dürfte sich mit kalibrierten Quantisierungen in den nächsten Monaten ändern – aber die 610 GB bleiben. K3 ist kein Mittelstands-Modell, sondern ein Hyperscaler-Modell.

Kostenvergleich: K3 lokal vs. API vs. kleinere Modelle

Die Kostenfrage lässt sich sauber über drei Szenarien beantworten:

Für typische Mittelstands-Workloads – Dokumentenanalyse, RAG, Code-Assistenz, Chat-Bots – ist das dritte Szenario fast immer die wirtschaftliche Wahl. Ein Detail am Rande: Moonshot selbst nennt DeepSeek V4.1-Flash als das Open-Modell aus den eigenen Vergleichscharts, das auf Prosumer-Hardware läuft.

DSGVO-Einordnung: Cloud-Tag ist kein lokaler Betrieb

Der häufigste Missverständnis in der Praxis: „Das Modell ist Open Weight, also ist alles DSGVO-konform." Das stimmt nur bedingt:

1. Lokal gehostete Gewichte: Der Betrieb unterliegt der Verantwortung des Unternehmens gemäß Art. 32 DSGVO (technische und organisatorische Maßnahmen). Open Weight heißt nicht automatisch DSGVO-konform – es heißt nur, dass die Daten nicht das Unternehmen verlassen.
2. Kimi-K3-Cloud-Tag: Prompts werden an Server von Moonshot übertragen. Moonshot bietet für API-Kunden Zero Data Retention – das ist eine echte Zusage, aber sie regelt nur, was Moonshot speichert, nicht wo die Inferenz stattfindet. Für personenbezogene Daten ohne Auftragsverarbeitungsvertrag bleibt das ein Problem.
3. K3.1-Pro-Lizenz (Bespoke): Die kommerzielle Nutzung ist erlaubt, unterliegt aber zwei „Commercial Gates" der Sonderlizenz (im Gegensatz zu Apache-2.0-Modellen wie Gemma). Vor Vertrags- und Produktentscheidungen gehört die Lizenz geprüft.

Die pragmatische Faustregel für den Mittelstand: Wenn Datenhoheit zählt, bleibt lokal. Lokal heißt aber nicht K3, sondern ein Modell, das auf die vorhandene Hardware passt.

Entscheidungsmatrix: Was ist Ihr Use-Case?

Empfehlung: Für 95 % der Mittelstands-Anwendungen gewinnt das kleine lokale Modell oder die K3-API. Der Selbstbau eines 610-GB-Servers lohnt nur, wenn ein Kernprozess explizit die Qualität eines Frontier-Modells braucht und Datenhoheit nicht verhandelbar ist – etwa bei geschützten Konstruktions- oder Patentdaten.

FAQ

Kann ich Kimi K3 mit Ollama lokal ausführen? Nein. Der Ollama-Eintrag kimi-k3 ist ein Cloud-Tag, der auf Moonshot-Servern läuft. Für lokalen Betrieb fehlt aktuell ein GGUF – insbesondere für K3.1 Pro mit der neuen Sparse-Attention-Architektur.

Wie viel VRAM braucht Kimi K3? Minimum rund 610 GB RAM + VRAM bei der 1-Bit-Quantisierung (Unsloth), ~1.690 GB bei 4-Bit. Keine einzelne Consumer-GPU kommt dem nahe; selbst eine 512-GB-Mac-Studio erreicht den Floor nur mit einer zweiten Maschine und Netzwerk-Pooling.

Warum kann K3 nicht auf einer RTX 5090 laufen? Die 32 GB VRAM der RTX 5090 sind um den Faktor ~19 zu klein. Bei MoE-Modellen dieser Größe lassen sich die Experten-Gewichte auch nicht sinnvoll „auslagern" – die aktiven 104B Parameter pro Token überschreiten jede Consumer-GPU bereits allein.

Was ist der Unterschied zwischen Kimi K3 und K3.1 Pro? K3.1 Pro ist das stärker trainierte Update mit derselben Architekturklasse (2.8T/104B MoE). Neu sind 24 Sparse-Attention-Layer statt Vollattention, was Serving-Kosten senkt, aber die bestehende K3-Tooling-Kette bricht. Die Gewichte kamen am 04.11.2026.

Gibt es DSGVO-konforme Alternativen zu K3? Ja – praktisch alle Modelle, die auf 24–48 GB VRAM passen: Qwen 3, DeepSeek, Gemma 4 (Apache 2.0) und Llama. Wer wirklich Frontier-Qualität braucht, aber nicht hosten kann, findet in der K3-API mit Zero Data Retention einen Kompromiss – dann aber mit Blick auf den Auftragsverarbeitungsvertrag.

Was kostet ein Server für Kimi K3? Gebrauchte CPU-Server mit 768 GB+ RAM ab ca. 8.000 EUR (langsam), Datacenter-GPU-Lösungen ab 25.000 EUR pro Monat Miete. Inklusive Strom, Wartung und Spezial-Serving kommen schnell 50.000+ EUR im ersten Jahr zusammen.

Nächster Schritt

Vor jeder GPU- oder Server-Investition: VRAM-Bedarf für KI-Modelle konkret rechnen und den GPU-Rechner für KI-Server nutzen. Dann gegen die laufenden Kosten eines KI-Servers stellen. Wer K3 im Blick hat, sollte parallel klären, welche GPU für den KI-Server realistisch ist und ob GPU-Server-Miete statt Kauf das flexiblere Modell ist. Die gute Nachricht: Modelle wie Gemma 4 liefern Frontier-nahe Qualität auf 24–48 GB – und zwar heute, ohne Cloud und ohne 610-GB-Server.