Moonshot AI hat am 27. Juli die offenen Gewichte für Kimi K3 veröffentlicht. Der Download-Zähler auf Hugging Face nähert sich bereits der 100.000er-Marke. Das zentrale Argument: ein Modell mit 2,8 Billionen Parametern, das Claude Opus 4.8 bei jedem von Moonshot veröffentlichten Benchmark geschlagen hat und nun selbst gehostet werden kann.
Apidog noch heute ausprobieren
Der Aufwand ist allerdings erheblich: Inferenz mit voller Präzision benötigt 1,57 TB Speicher. Selbst die veröffentlichten MXFP4-Gewichte umfassen 594 GB. Kimi K3 lässt sich selbst betreiben, aber „lokal“ bedeutet hier Datacenter, große Workstation oder ein sehr langsames Experiment — nicht ein typisches Entwickler-Laptop.
Dieser Leitfaden zeigt:
- welche Hardware und Gewichte Sie benötigen,
- wie Sie K3 mit vLLM oder llama.cpp starten,
- welche Grenzen Consumer-Hardware hat,
- wie Sie den lokalen OpenAI-kompatiblen Endpunkt in Ihren API-Workflow mit Apidog einbinden.
Was Sie herunterladen
Für den vollständigen Hintergrund lesen Sie zuerst Was ist Kimi K3?. Für die Bereitstellung sind diese Eigenschaften entscheidend:
- 2,8T Gesamtparameter, 104B pro Token aktiviert: K3 ist ein Mixture-of-Experts-Modell mit 896 Experten. Pro Token werden 16 ausgewählte Experten sowie 2 geteilte Experten aktiviert. Die Rechenlast pro Token liegt damit deutlich unter der Gesamtparameterzahl.
- 93 Schichten: 69 Kimi Delta Attention (KDA)-Schichten und 24 Gated-MLA-Schichten. Das KDA-Design ermöglicht das Kontextfenster von bis zu 1 Million Token.
- Native Vision: Ein MoonViT-V2-Encoder mit 401 Millionen Parametern verarbeitet Text-, Bild- und Videoeingaben.
- MXFP4-Gewichte und MXFP8-Aktivierungen: Moonshot hat quantisierungsbewusst trainiert. MXFP4 ist daher das vorgesehene Serving-Format, nicht nur eine nachträgliche Komprimierung.
- Nur Denkmodus: K3 erzeugt vor Antworten Begründungsinhalte mit niedrigem, hohem oder maximalem Anstrengungsgrad. Einen direkten Sofortmodus gibt es nicht.
Die Gewichte sind im Hugging-Face-Repository hinter der Kimi-K3-Lizenz geschützt. Akzeptieren Sie die Lizenz und laden Sie die Gewichte anschließend mit huggingface-cli herunter.
Planen Sie bei einer 1-Gbit/s-Verbindung ungefähr 80 bis 90 Minuten für 594 GB ein.
Option 1: Datacenter-Serving mit vLLM oder SGLang
Moonshot empfiehlt vLLM, SGLang und TokenSpeed. Der KDA-Prefill-Cache wurde zusammen mit den Gewichten in vLLM ausgeliefert. Daher ist vLLM der pragmatischste Einstieg.
Starten Sie K3 auf einem 8-GPU-Knoten mit Tensor-Parallelität:
vllm serve moonshotai/Kimi-K3 \
--tensor-parallel-size 8 \
--max-model-len 131072
Praktische Konfiguration
Starten Sie mit acht GPUs.
Moonshot evaluierte auf H20-Clustern. Ein 8-GPU-Knoten ist eine realistische Untergrenze für Tensor-Parallelität. Hardware der B200-Klasse kann über 100 Token/s erreichen.Begrenzen Sie den Kontext zunächst auf 131K.
K3 unterstützt bis zu 1.048.576 Token, aber der KV-Cache für den vollen Kontext benötigt allein etwa 27 GB. Erhöhen Sie--max-model-lenerst, wenn Ihre Anwendung tatsächlich lange Kontexte benötigt.Setzen Sie Sampling explizit.
Moonshots Standardwerte sind Temperatur1.0und Top-P0.95. Für agentenbasierte Workloads können Sie Top-P auf1.0setzen:
# Beispielwerte für Ihre Client-Anfrage
temperature=1.0
top_p=1.0
Dieses Setup ist lokal im Sinne von Datensouveränität: Infrastruktur, Logs und Compliance-Historie bleiben unter Ihrer Kontrolle. Es ist jedoch kein Laptop-Deployment — auch mit Quantisierung nicht.
Option 2: GGUF-Quantisierungen auf einer großen Workstation
Unsloth bietet GGUF-Konvertierungen für llama.cpp an. Die dynamischen Quantisierungen sind der realistischste Weg, K3 unter die Größe des offiziellen Releases zu bringen.
| Quantisierung | Größe | Bedeutung |
|---|---|---|
| UD-IQ1_M | ~345 GB | Untergrenze mit aggressiver dynamischer 1-Bit-Quantisierung |
| UD-IQ1_S | ~650 GB | Unsloths empfohlener Gleichgewichtspunkt |
| UD-Q4_K_XL | ~1,55 TB | Nahezu volle Präzision |
| UD-Q8_K_XL | ~1,6 TB | Praktisch verlustfrei |
Als Faustregel sollte die Summe aus RAM und VRAM ungefähr der Größe der Quantisierung entsprechen. llama.cpp kann fehlende Daten zwar per Offloading nachladen, aber jedes fehlende Gigabyte reduziert die Geschwindigkeit.
Ein Mac Studio mit 128 GB Unified Memory oder eine DGX Station liegen am praktischen unteren Ende.
Starten Sie eine GGUF-Variante inklusive Vision-Projektor beispielsweise so:
./llama.cpp/llama-cli \
--model unsloth/Kimi-K3-GGUF/UD-IQ1_S/Kimi-K3-UD-IQ1_M-00001-of-00015.gguf \
--mmproj unsloth/Kimi-K3-GGUF/mmproj-F16.gguf \
--temp 1.0 \
--top-p 0.95
Wenn Ihre Hardware deutlich darunter liegt, sollten Sie K3 nicht erzwingen. Die Liste der besten lokalen LLMs von 2026 enthält offene Modelle für 24 bis 128 GB Speicher, die in Echtzeit antworten können. K3 mit 1-Bit-Quantisierung auf unzureichendem RAM wird das nicht leisten.
Das M1-Max-Experiment: Ja, aber 16 Sekunden pro Token
Ein Hacker-News-Thread dokumentierte, wie K3 auf einem M1 Max mit 64 GB RAM lief. Die Gewichte wurden dabei von einer 2-TB-SSD gestreamt, statt vollständig im Speicher zu liegen.
Das funktioniert technisch, ist aber für interaktive Nutzung ungeeignet:
- K3 enthält ungefähr 115 GB dichte Parameter, die jedes Token berührt, sowie rund 25 GB geroutete Expertengewichte pro Token.
- Der dichte Anteil überschreitet bereits den Arbeitsspeicher des Geräts.
- Die SSD wird damit zum langsamen Ersatzspeicher.
- Das Ergebnis lag bei etwa 16 Sekunden pro Token; einige Konfigurationen meldeten sogar mehr als eine Minute pro Token.
Als Demonstration für MoE-Sparsity und mmap ist das interessant. Für produktive Nutzung ist es keine sinnvolle Option. Wenn Sie K3 auf einem MacBook verwenden möchten, sind kostenlose Tarife oder eine gehostete API besser geeignet.
Lokales K3 in Ihren API-Workflow einbinden
Sowohl vLLM als auch der Servermodus von llama.cpp stellen am Ende einen OpenAI-kompatiblen HTTP-Endpunkt bereit. Behandeln Sie ihn wie jede andere API.
Der Workflow entspricht dem Vorgehen zum Testen lokaler LLMs als APIs.
1. Umgebung für den lokalen Endpunkt erstellen
Erstellen Sie in Apidog eine Umgebung mit einer Variable für die Basis-URL:
base_url = http://localhost:8000/v1
Für vLLM ist dies üblicherweise der Standardendpunkt. Später können Sie dieselbe Variable gegen einen gehosteten Moonshot-Endpunkt austauschen. Ihre Requests bleiben unverändert.
2. Chat-Completion-Request testen
Verwenden Sie einen OpenAI-kompatiblen Request:
POST {{base_url}}/chat/completions
Content-Type: application/json
Authorization: Bearer {{api_key}}
{
"model": "moonshotai/Kimi-K3",
"messages": [
{
"role": "user",
"content": "Erkläre kurz, wie Tensor-Parallelität beim LLM-Serving funktioniert."
}
],
"temperature": 1.0,
"top_p": 0.95,
"stream": true
}
3. Denk-Stream prüfen
K3 arbeitet ausschließlich mit Denkmodus. Antworten können daher Begründungsinhalte vor der finalen Antwort enthalten.
Die SSE-Debugging-Ansicht von Apidog zeigt eintreffende Streaming-Events direkt an. Damit können Sie prüfen:
- ob Streaming korrekt funktioniert,
- welche Inhalte vor der finalen Antwort gesendet werden,
- wie Änderungen des Anstrengungsgrads Latenz und Ausgabe beeinflussen.
4. Struktur statt subjektiver Qualität testen
Automatisieren Sie Tests für technische Eigenschaften der Antwort:
- Antwortschema,
- erwartete Felder für Token-Nutzung,
- maximale Latenz,
- Statuscodes,
- Streaming-Verhalten.
Beispiel für einfache Prüfungen:
pm.test("Antwort liefert choices", () => {
const body = pm.response.json();
pm.expect(body.choices).to.be.an("array").that.is.not.empty;
});
pm.test("Antwort enthält Nutzungsdaten", () => {
const body = pm.response.json();
pm.expect(body.usage).to.exist;
});
So erkennen Sie Probleme nach einem Quantisierungswechsel oder Engine-Upgrade über fehlgeschlagene Tests statt über Nutzerberichte.
5. Antworten mocken, während das Modell lädt
Ein 594-GB-Modell braucht Zeit zum Laden. Zeichnen Sie eine echte Antwort einmal auf und verwenden Sie sie anschließend in einem Mock-Server. So kann das Frontend-Team weiterarbeiten, während die Inferenzhardware beschäftigt ist.
Sie können Apidog herunterladen, um Mock- und Test-Workflows mit jedem OpenAI-kompatiblen Server einzurichten.
Das Request-Format entspricht dem Kimi-K3-API-Leitfaden. Tests für die gehostete API lassen sich deshalb direkt auf Ihre lokale Bereitstellung übertragen.
Sollten Sie K3 lokal ausführen?
| Ihre Situation | Empfehlung |
|---|---|
| 8+ GPU-Knoten und Anforderungen an Datensouveränität oder Compliance | Ja. Nutzen Sie vLLM mit Tensor-Parallelität und MXFP4-Gewichte. |
| Workstation mit 350 GB+ RAM/VRAM | Machbar. Nutzen Sie Unsloth-1-Bit-GGUFs mit gedämpften Erwartungen. |
| 64 bis 128 GB Mac oder PC | Nein. Sie erhalten Sekunden pro Token statt Token pro Sekunde. |
| Sie möchten K3 einfach im Produkt verwenden | Nutzen Sie die gehostete API; sie ist OpenAI- und Anthropic-kompatibel. |
Die offenen Gewichte von K3 sind vor allem deshalb relevant, weil Teams das Modell auditieren, feinabstimmen und selbst hosten können. Das bedeutet nicht, dass die meisten Entwickler es auf eigener Hardware betreiben sollten.
Für Teams mit passender Hardware funktioniert der vLLM-Pfad heute. Für alle anderen bleibt der wichtigste Integrationspunkt derselbe: der API-Endpunkt. Testen Sie ihn mit Schema-Prüfungen, Streaming-Inspektion und Mocks, damit die Entwicklung weiterläuft, während das Modell nachdenkt.
Top comments (0)