Kimi K3 selbst hosten: VRAM, Kosten und Alternativen

Voraussetzungen für das Self-Hosting von Kimi K3

Das Self-Hosting von Kimi K3 erfordert Speicherplatz für 2,8 Billionen Parameter. Moonshot hat die offenen Gewichte im Format MXFP4 veröffentlicht, was etwa einem halben Byte pro Gewicht entspricht. Allein die Gewichte beanspruchen daher etwa 1.4 TB, bevor Sie auch nur einen einzigen Token für den Cache reservieren. Kein aktuell erhältlicher Beschleuniger kann diese Datenmenge allein speichern. Für eine einzelne GPU lautet die Antwort daher nein. Für einen einzelnen Server ist die Antwort in zwei Konfigurationen ja. Die erste ist ein 8-GPU-Knoten mit 288-GB-Beschleunigern, wie er in den kleinsten veröffentlichten Rezepten für Multi-User-Serving verwendet wird. Die zweite ist ein System mit etwa 1,6 TB kombiniertem RAM und VRAM, auf dem Unsloth's verlustfreies Q8 GGUF in llama.cpp läuft – mit oder ohne GPU –, um jeweils einen Benutzer gleichzeitig zu bedienen.

Dies ist das Fazit. Alles Folgende ist die Arithmetik dahinter, da Sie diese Berechnungen bei der nächsten Veröffentlichung wiederverwenden können. Mehrere Infrastrukturanbieter haben in den Wochen nach der Ankündigung am 16. Juli 2026 Anleitungen zur Bereitstellung von K3 veröffentlicht, wobei jeder davon ausging, dass Sie bereits über einen Cluster verfügen. Diese Seite beginnt am anderen Ende: Was es kostet, was Sie stattdessen ausführen können und wie Sie feststellen, welche dieser beiden Optionen auf Sie zutrifft.

Die Gesamtzahl der Parameter und die Zahl der aktiven Parameter sind nicht identisch

K3 ist ein Mixture-of-Experts-Modell. MoE (Mixture of Experts) teilt das Netzwerk in viele Teilnetzwerke auf und lässt einen Router pro Token einige davon auswählen. Die Model Card nennt 2.8T Gesamtparameter und 104B aktivierte Parameter pro Token. Diese stammen aus 896 gerouteten Experten, von denen für ein bestimmtes Token 16 aktiviert werden, verteilt auf 93 Layer.

Diese beiden Parameterzahlen beantworten unterschiedliche Fragen. Sie zu vertauschen, ist der häufigste Fehler in jedem Thread nach dem Muster „Kann ich dieses Modell ausführen?“.

Die aktiven Parameter bestimmen den Rechenaufwand. Ein Token durchläuft Berechnungen mit ungefähr 104B Parametern. Daher ähnelt der erwartete Durchsatz eher dem eines dichten 104B-Modells als dem eines 2.8T-Modells. Genau deshalb werden MoE-Modelle eingesetzt.

Die Gesamtzahl der Parameter bestimmt den Speicherbedarf. Der Router kann für jedes Token einen beliebigen Experten auswählen. Deshalb müssen alle Experten bereits vor der ersten Anfrage an einem schnellen Speicherort gespeichert sein. Es ist möglich, nur die häufig verwendeten Experten im VRAM zu halten und die übrigen bei Bedarf abzurufen: llama.cpp's --moe-cache-mib verwaltet einen GPU-Cache für Experten, die ansonsten im Systemspeicher liegen, und lädt fehlende Experten hoch, sobald der Router sie auswählt. Dadurch verringert sich die Gesamtgröße jedoch nicht. Die übrigen Experten müssen weiterhin im RAM liegen. Außerdem überträgt eine PCIe-Verbindung mehrere Dutzend Gigabyte pro Sekunde, während HBM mehrere Terabyte pro Sekunde verarbeitet. Jeder Cache-Miss kostet daher Zeit. Werden Experten aus NVMe gestreamt, weil das Modell nicht einmal in den RAM passt, ist die Ausführung noch langsamer. Der K3-Leitfaden von Unsloth weist ebenfalls darauf hin, dass das Auslagern auf Datenträger deutlich langsamer ist.

Die Berechnung ist also vergleichsweise günstig, die Speicherung jedoch teuer. Dimensionieren Sie die Hardware für 2.8T. Richten Sie Ihre Erwartungen an die Geschwindigkeit auf 104B aus.

Bytes pro Gewichtung und die Herkunft der Terabytes

Anzahl der Parameter multipliziert mit Bytes pro Gewichtung. Das ist die gesamte Formel für die Gewichtungen.

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 wurde mit Quantisierungsbewusstsein trainiert und mit MXFP4-Gewichtungen sowie MXFP8-Aktivierungen veröffentlicht, daher ist die 4-Bit-Zeile die maßgebliche. Die Zeilen darüber dienen dem Vergleich: Bei bf16 würde dasselbe Modell 5.6 TB benötigen. MXFP4 speichert zudem eine gemeinsam genutzte 8-Bit-Skalierung für jeden Block von 32 Gewichtungen, was etwa 6 Prozent hinzufügt. Die Konfiguration von Moonshot schließt die Attention-Layer, die geteilten Experten und den Vision-Tower vom 4-Bit-Format aus. Daher kommt der vollständige Checkpoint laut Unsloth auf etwa 1,56 TB statt auf glatte 1.4 TB.

Dies schränkt den üblichen Ausweg ein, ohne ihn vollständig zu verschließen. Da der veröffentlichte Checkpoint bereits 4-Bit ist, wurde die einfache Einsparung bereits realisiert, aber eine weitere Reduzierung verändert die Zahl dennoch. Stand 27. Oktober 2026 reichen die von Unsloth gemessenen dynamischen GGUF-Quantisierungen von K3 von 861,3 GB für das 2-Bit UD-Q2_K_XL bis hinunter zu 594 GB für das 1-Bit UD-IQ1_S. Unsloth veröffentlicht die damit verbundenen Kosten: Die Übereinstimmung der Top-1-Token mit dem vollständigen Modell liegt bei 90,390 Prozent für UD-Q2_K_XL, 84,127 Prozent für das 711,1 GB große UD-IQ2_XXS und 78,875 Prozent für UD-IQ1_S. Das zugehörige Hugging Face-Repository enthält auch kleinere 1-Bit-Dateien, bis hinunter zu 466 GB für UD-Q1_0, für die jedoch keine Übereinstimmungsrate veröffentlicht wurde. Dies stellt einen messbaren Genauigkeitsverlust dar, und selbst die kleinste Datei ist immer noch etwa 1,6-mal so groß wie die Kapazität der größten Einzelkarte.

Wie viele GPUs benötigt Kimi K3

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

Betrachten Sie diese Werte als Untergrenze, nicht als Zielvorgabe. Sie berücksichtigen ausschließlich die Gewichte: kein KV-Cache, keine Aktivierungspuffer, keine Fragmentierung durch den Allokator und kein Spielraum für eine zweite gleichzeitige Anfrage. Die Aufteilung muss nicht gleichmäßig erfolgen: Die Pipeline-Parallelität von vLLM teilt das Modell entlang der Layer und unterstützt ungleiche Aufteilungen; die K3-Prefill-Rezepte von SGLang führen 8 und 16 Pipeline-Stufen über 93 Layer aus.

Die veröffentlichten Empfehlungen liegen über dieser Untergrenze. Die Startempfehlung von Moonshot empfahl einen Supernode mit 64 oder mehr Beschleunigern. Stand 27. Oktober 2026 liefert das SGLang-Kochbuch eine H100-Konfiguration, die aus vier 8-GPU-Nodes besteht, also 32 GPUs und 2.560 GB Gesamtspeicher, gegenüber einer Untergrenze von 18 Karten. Es listet zudem Single-Node-Rezepte für einen 8-GPU-B300-Node sowie einen 8-GPU-MI350X- oder MI355X-Node auf, mit 2.304 GB bei 288 GB pro Karte. Dieser Puffer über der Untergrenze ist keine Verschwendung. Er dient dem KV-Cache, dem Aktivierungsspeicher und dem Spielraum, der es dem Server ermöglicht, viele Anfragen gleichzeitig zu verarbeiten. Die günstigste Zeile, 5 GB300-Klasse-Karten, wird in der Praxis auf genau diese Art von 8-GPU-Node aufgerundet, was die kleinste Maschine darstellt, für die öffentlich ein Multi-User-K3-Serving-Rezept existiert.

Der KV-Cache ist der Teil, der viele überrascht

Die Gewichte verursachen einen festen Speicherbedarf. Der KV-Cache (Key-Value-Cache) nicht: Er wächst mit der Kontextlänge und zusätzlich mit jedem gleichzeitig aktiven Benutzer. Für gewöhnliche Attention lautet die Formel bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element. Anschließend multiplizieren Sie mit der Kontextlänge und mit der Anzahl der gleichzeitigen Benutzer.

Hier ist ein durchgerechnetes Beispiel, das ausschließlich der Veranschaulichung dient: 64 Layer, 8 KV-Heads, eine Head-Dimension von 128 und fp8. Daraus ergibt sich 2 64 8 128 1 = 131,072 Byte, also 128 KiB pro Token.

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

Ein Benutzer mit einem Kontext von 128k benötigt 16 GiB. Ein Benutzer mit dem vollständigen Millionen-Kontext benötigt 128 GiB. Das entspricht für eine einzige Unterhaltung fast der Hälfte einer 288-GB-Karte, bevor auch nur ein einziges Gewicht geladen wurde.

K3 verwendet keine gewöhnliche Attention. Genau deshalb ist die letzte Zahl relevant. Seine 93 Layer bestehen aus 69 KDA-Layern (Kimi Delta Attention) und 24 Gated-MLA-Layern (Multi-Head Latent Attention). KDA verwendet einen rekurrenten Zustand fester Größe statt eines Caches, der mit jedem Token wächst. MLA komprimiert Key und Value in einen gemeinsamen Latent-Vektor mit niedriger Rangzahl. Dadurch liegt der tatsächliche Bedarf pro Token deutlich unter dem des durchgerechneten Beispiels. Die von Moonshot veröffentlichte config.json gibt für diesen Latent eine kv_lora_rank mit 512 sowie einen 64 breiten Rotary-Key (qk_rope_head_dim) an, also 576 Werte pro Token und MLA-Layer. Über 24 Layer und bei 2 Byte pro Wert ergibt das 27,648 Byte, also etwa 27 KiB pro Token beziehungsweise ungefähr 27 GiB für eine vollständige Unterhaltung mit 1,048,576 Token, zuzüglich des festen KDA-Zustands. Betrachten Sie diesen Wert als Schätzung und nicht als Messung: Engines richten den Cache unterschiedlich aus und legen ihn unterschiedlich im Speicher ab. Ein 8-Bit-Cache halbiert den Bedarf ungefähr.

Um festzustellen, wie viel Ihre eigene Bereitstellung hält, beobachten Sie nvidia-smi nicht, während Sie --max-model-len erhöhen. vLLM reserviert seinen KV-Cache-Pool vorab. Dessen Größe wird aus --gpu-memory-utilization (in der aktuellen Dokumentation standardmäßig 0.92) oder aus einem expliziten Cache-Budget pro GPU bestimmt. Daher zeigt der gesamte GPU-Speicher den Pool und nicht den Bedarf einer einzelnen Unterhaltung. Lesen Sie stattdessen das Startprotokoll. Dort meldet vLLM die Größe des KV-Caches in Token sowie die maximale Parallelität für Ihre Kontextlänge.

Die grundsätzliche Überlegung bleibt auch beim nächsten Release gültig. Wenn ein Modell einen Kontext von einer Million Token angibt und keine Informationen über sein Attention-Design liefert, sollten Sie davon ausgehen, dass der Cache die begrenzende Ressource ist, bis das Gegenteil nachgewiesen wurde.

Tier 1: Mieten des Clusters nach Stunden

Dies ist die Stufe, die K3 in der ausgelieferten Präzision für viele Benutzer gleichzeitig bereitstellt. Eine Maschine mit ausreichend RAM kann K3 in der veröffentlichten Präzision auch über Unsloth Q8 GGUF halten, was Unsloth als verlustfreie volle Präzision bezeichnet. Dieser Weg bedient jedoch nur einen Benutzer gleichzeitig und wird in Stufe 2 behandelt. Hier kaufen Sie die Hardware nicht. Sie mieten sie für die benötigten Stunden und beenden die Instanz danach.

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

Der Preis ist eine Annahme, kein verbindliches Angebot. Die On-Demand-Preise variieren je nach Anbieter und GPU-Generation stark. Die 288-GB-Komponenten, die für die Single-Node-Rezepte benötigt werden, kosten pro Stunde mehr als eine H100, während reservierte Kapazitäten günstiger sind. Verwenden Sie den tatsächlichen Wert Ihres Anbieters und führen Sie die Multiplikation erneut durch: GPUs mal Stunden mal Preis. Der Zweck der Tabelle ist das Verhältnis. Der Betrieb eines 8-GPU-Knotens für vier Stunden am Tag kostet 2,400 USD pro Monat, während die SGLang-konfigurierte 32-GPU-H100-Konfiguration 57,600 USD kostet, wenn sie durchgehend läuft.

Beide Mainstream-Server veröffentlichen einen Startbefehl auf der Modellkarte.

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

Keiner dieser Basisbefehle ist das, was Sie auf einem echten Cluster ausführen. Fügen Sie die Parallelisierungs-Flags hinzu, die zu Ihrer Hardware passen: SGLang verwendet --tp-size für Tensor-Parallelität, --pp-size für Pipeline-Parallelität und --ep-size für Experten-Parallelität. Das Produkt aus Tensor-Parallelität und Pipeline-Parallelität muss der Anzahl Ihrer tatsächlich vorhandenen GPUs entsprechen. Die Experten-Parallelität teilt die Experten innerhalb dieser Gruppe auf, weshalb das 32-GPU-H100-Rezept sowohl --tp-size 32 als auch --ep-size 32 festlegt.

Prüfen Sie, ob der Server gestartet ist, bevor Sie echten Datenverkehr senden:

curl http://127.0.0.1:30000/v1/models

Ein funktionierender Server antwortet mit einem JSON-Objekt, das die Modell-ID auflistet. Connection refused bedeutet, dass der Prozess noch Gewichte lädt oder bereits beendet wurde. Lesen Sie daher das Server-Log, bevor Sie es erneut versuchen.

Ein in den ersten Wochen häufig auftretender Fehler war eine Laufzeitumgebung, die älter als das Modell war. K3 wurde mit KDA und einer neuen MoE-Schicht ausgeliefert, die die stabilen vLLM- und SGLang-Releases zum Zeitpunkt der Veröffentlichung noch nicht enthielten. Das Symptom ist, dass der Server während des Starts mit einer Zeile der Form Model architectures [...] are not supported for now beendet wird. Keine Konfigurationsänderung behebt dies, da der Code zum Ausführen dieser Schichten in Ihrem Build fehlt. Dies hat sich inzwischen geändert: Zum Stand vom 27. Oktober 2026 enthält SGLang die K3-Unterstützung in seinen Releases seit v0.5.17, wobei v0.5.22 die aktuellste Version ist. Die Release-Notes von vLLM von v0.28.0 bis v0.32.0 enthalten ebenfalls K3-Arbeiten. Installieren Sie ein aktuelles Release. Einige hardwarespezifische Pfade benennen weiterhin ein dediziertes Image, zum Beispiel SGLang NVFP4-Builds auf Blackwell. Prüfen Sie daher das Rezept für Ihre Karte.

Ein Kostenhinweis, der oft übersehen wird: Die Abrechnung beginnt, wenn die Instanz startet, nicht wenn das Modell bereit ist. Ein 1,56-TB-Download bei 1 GB/s entspricht etwa 26 Minuten Cluster-Zeit vor dem ersten Token. Speichern Sie die Gewichte auf einem Volume, das die Instanz überdauert, damit der zweite Durchlauf in Minuten startet.

Stufe 2: Ausführung eines kleineren Modells auf einem Beschleuniger

Sie führen in dieser Stufe kein K3 aus. Sprechen Sie dies laut aus, bevor Sie beginnen, da die meisten Threads zum Thema "K3 lokal ausführen" hier enden, ohne dies zuzugeben.

Die Regel für die Passgenauigkeit folgt derselben Formel im Miniaturformat: Parameter multipliziert mit Bytes pro Gewichtung, zuzüglich KV-Cache und etwa 2 GB Laufzeit-Overhead, müssen in Ihren VRAM passen. Bei 4-Bit entspricht dies etwa einem halben Byte pro Parameter, was zu komfortablen Kombinationen führt:

• 16 GB Karte: ein 7B-Modell bei 4-Bit mit Spielraum für einen langen Kontext
• 24 GB Karte: ein 14B-Modell bei 4-Bit
• 48 GB Karte: ein 32B-Modell bei 4-Bit
• 80 GB Karte: ein 70B-Modell bei 4-Bit oder ein MoE der 30B-Klasse bei 8-Bit

Jede der oben genannten Kombinationen geht von einer Anfrage zur gleichen Zeit aus. Sobald eine zweite Person einen Prompt sendet, benötigt jeder gleichzeitige Slot seinen eigenen KV-Cache. Dies ist der Kompromiss, den Ollama's NUM_PARALLEL und MAX_QUEUE Einstellungen für Sie zwischen parallelen Slots, Anfragewarteschlangen und dem verbleibenden VRAM eingehen.

Es gibt einen Weg, K3 selbst auf einer einzelnen großen Maschine auszuführen; er liegt zwischen dieser Stufe und der letzten. Unsloth dokumentiert GGUF-Builds von K3 in llama.cpp, von 1-Bit- und 2-Bit-Quantisierungen bis hin zu UD-Q8_K_XL, was als verlustfreie volle Präzision bezeichnet wird. Als Hardware, die diese ausführen kann, wird eine NVIDIA DGX Station genannt. Die Faustregel besagt, dass RAM plus VRAM in etwa der Quantisierungsgröße entsprechen muss: von etwa 610 GB für den 1-Bit UD-IQ1_S-Build bis zu etwa 1,6 TB für den Q8. Darunter greift das Modell auf den Datenträger zurück und verlangsamt sich drastisch. Eine GPU ist optional: Die Build-Anweisungen von Unsloth schalten CUDA ab, "wenn Sie keine GPU haben oder nur CPU-Inferenz nutzen möchten". Die 1-Bit- und 2-Bit-Builds sind stark quantisiertes K3, mit den oben gemessenen Genauigkeitseinbußen. Der Q8-Build ist K3 in seiner veröffentlichten Präzision, bereitgestellt für einen Benutzer bei RAM-Geschwindigkeit. Keines davon ist ein kleineres Modell.

Ollama ist der kürzeste Weg zu einem funktionierenden Server auf einem VPS mit angeschlossener GPU:

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama run lädt das Modell bei der ersten Verwendung herunter und stellt Ihnen dann eine Eingabeaufforderung bereit. Ein Tag, das nicht existiert, führt zu Error: model "..." not found. Kopieren Sie daher Tags von der Bibliotheksseite, anstatt sie aus dem Gedächtnis einzugeben. Die vollständige Anleitung, einschließlich der systemd-Unit und des Fernzugriffs, finden Sie unter Ollama auf einem VPS ausführen.

llama.cpp bietet Ihnen mehr Kontrolle über Quantisierung und Offloading:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99 fordert an, jede Schicht auf die GPU auszulagern. Lesen Sie das Ladeprotokoll: Es gibt aus, wie viele Schichten ausgelagert wurden. Schichten, die in den System-RAM überlaufen, laufen mit RAM-Bandbreite statt mit HBM-Bandbreite, sodass die Generierungsgeschwindigkeit um eine Größenordnung sinkt, sobald das Modell nicht mehr vollständig in den Speicher passt. Die Kompromisse zwischen den beiden Werkzeugen werden unter Ollama und llama.cpp im Vergleich behandelt.

Tier 3: Gehostete API, selbst gehostete Orchestrierung

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

Der Endpunkt ist OpenAI-kompatibel, sodass ein vorhandener Client nach dem Ändern der Basis-URL funktioniert.

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

Ein gültiger Schlüssel gibt ein JSON-Objekt mit einem choices-Array zurück. Ein 401 bedeutet, dass die Authentifizierung fehlgeschlagen ist: Prüfen Sie, ob der Schlüssel korrekt ist, nicht abgelaufen oder deaktiviert wurde und ob der Header Authorization: Bearer gefolgt vom Schlüssel enthält. Ein "Model-not-found"-Fehler bedeutet normalerweise, dass die ID geändert wurde, da Anbieter IDs zwischen Checkpoints zurückziehen.

Nun zum Break-Even unter Verwendung des oben angenommenen Mietpreises. Ein dauerhaft laufender 8-GPU-Knoten kostet 14,400 USD pro Monat. Bei 15.00 USD pro Million Output-Token erhält man für denselben Betrag etwa 960 Millionen Output-Token über die API. Um bei der Miete eines Clusters kosteneffizienter als mit der API zu sein, müssen Sie fast eine Milliarde Output-Token pro Monat generieren – das entspricht etwa 30 Millionen pro Tag. Zudem muss der Cluster durchgehend ausgelastet sein, da ungenutzte GPUs zum gleichen Preis abgerechnet werden wie ausgelastete. Agenten-Workloads mit hohem Prompt-Aufkommen verschieben die Schwelle noch weiter: Wiederholter Kontext wird mit der Cache-Hit-Rate von 0.30 USD pro Million abgerechnet, anstatt mit der Cache-Miss-Rate von 3.00 USD.

Was Sie in dieser Stufe selbst hosten, ist alles um das Modell herum: ein Gateway, das den API-Schlüssel hält, damit dieser niemals einen Client erreicht, Anforderungs- und Antwort-Logs, Wiederholungsversuche, Ratenbegrenzungen und Budgets pro Benutzer. Dies läuft auf einem kleinen VPS ganz ohne GPU. Die gleiche Aufteilung gilt für geschlossene Gewichte, bei denen Self-Hosting von Claude auf Modellebene nicht möglich ist und die Orchestrierung der einzige Teil ist, den Sie kontrollieren.

Welcher Serving-Stack gehört zu welcher Ebene

vLLM- und SGLang-Klassenserver gehören zur Ebene 1. Sie sind darauf ausgelegt, viele Anfragen gleichzeitig zu bedienen, nutzen Continuous Batching und einen Paged-KV-Cache sowie Tensor- und Expert-Parallelität über mehrere Knoten hinweg. Sie setzen Rechenzentrums-Beschleuniger und eine schnelle Interconnect-Verbindung zwischen diesen voraus. Auf einer einzelnen Consumer-Grafikkarte ist die Installation aufwendiger und bietet kaum wahrnehmbare Vorteile.

llama.cpp und Ollama gehören zur Ebene 2. Sie zielen auf eine einzelne Maschine ab, nutzen GGUF-Quantisierung, CPU-Offloading bei unzureichendem Speicherplatz und sind für geringe Nebenläufigkeit konzipiert. llama.cpp lädt ein umfangreiches MoE, indem es Expert-Gewichte im Systemspeicher (--cpu-moe oder --n-cpu-moe) hält und mit --moe-cache-mib die verwendeten Experten auf der GPU zwischenspeichert; so laufen Unsloth K3 GGUF-Builds auf einer einzelnen Maschine. Die Geschwindigkeit hängt dann von der RAM-Bandbreite und der Trefferquote des Routers im Cache ab. Ist die Datei größer als RAM und VRAM zusammen, wird auf den Datenträger ausgelagert. Dies ist ein praktikables Setup für einen einzelnen Benutzer. Es ist kein Dienst, der für viele Benutzer gleichzeitig geeignet ist. Der vollständige Vergleich findet sich unter Ollama im Vergleich zu vLLM, und dieser ändert sich nicht mit dem Modell: Die entscheidende Frage ist immer, ob Sie viele Benutzer auf gemeinsam genutzter Hardware bedienen oder einen einzelnen Benutzer auf Ihrem eigenen System.

Die vier Kennzahlen, die diesen Checkpoint überdauern

1. Die Gesamtzahl der Parameter multipliziert mit den Bytes pro Gewicht ergibt den Mindestspeicherbedarf. Unterhalb dieser Schwelle läuft bei der ausgelieferten Präzision nichts. Eine Quantisierung unterhalb eines 4-Bit-Releases bringt Ihnen bis zu etwa 70 Prozent Ersparnis, jedoch auf Kosten der Genauigkeit und nicht in einer Größenordnung.
2. Die aktiven Parameter bestimmen die Durchsatzklasse. Ein 2.8T MoE mit 104B aktiven Parametern rechnet wie ein 104B-Modell.
3. Der KV-Cache pro Token, multipliziert mit der Kontextlänge und der Parallelität, ist der Kostenfaktor, der weiter wächst, nachdem Sie die Gewichte bereits bezahlt haben.
4. Tokens pro Sekunde pro Dollar ist die einzige Kennzahl, die eine Leistungsklasse definiert. Alles oben Genannte ist lediglich eine Eingangsgröße dafür.

Wenden Sie diese vier Punkte auf jedes Release an, und Sie erhalten die richtige Antwort, bevor Sie ein Anbieterhandbuch öffnen. Das nächste Modell ist bereits angekündigt: Moonshot hat am 23. Oktober 2026 K3.1 Pro in Kimi Code eingeführt, das auf K3 basiert und weiterem Post-Training unterzogen wurde. Der API-Quickstart besagt, dass die vollständigen Gewichte bis zum 4. November veröffentlicht werden. Versehen Sie daher jede Zahl, die Sie notieren, mit einem Datum. Preise und Listen unterstützter Architekturen haben sich in den zwei Wochen nach dem Start von K3 beide verändert. Die Startzahlen auf dieser Seite wurden im Juli 2026 veröffentlicht, und die Serving-Rezepte, Runtime-Releases sowie Quantisierungszahlen wurden am 27. Oktober 2026 erneut überprüft.

FAQ

Kann ich Kimi K3 auf einer einzelnen GPU betreiben?

Nein. Die Gewichte betragen etwa 1.4 TB in der von Moonshot ausgelieferten MXFP4-Präzision. Selbst die kleinste veröffentlichte Quantisierung von K3, die 466 GB große UD-Q1_0-Datei von Unsloth, ist etwa 1,6-mal so groß wie die 288 GB der größten weit verbreiteten Beschleuniger. llama.cpp kann Experten im System-RAM halten und die aktiven auf der GPU zwischenspeichern, aber dies erfordert dennoch in etwa die Größe der Quantisierung im RAM zuzüglich VRAM. Unterschreitet man diesen Wert, lagert das Modell auf die Festplatte aus und arbeitet deutlich langsamer. Die kleinsten veröffentlichten Serving-Rezepte nutzen einen 8-GPU-Knoten mit B300- oder MI350X/MI355X-Karten; das H100-Rezept verwendet 32.

Wie viel VRAM benötigt Kimi K3?

Rechnen Sie für die Gewichte allein mit 1.4 TB, was 18 H100 80GB-Karten oder 5 GB300-Karten entspricht. Hinzu kommen Speicher für den KV-Cache und Aktivierungen. Die Einführungsempfehlungen von Moonshot empfahlen 64 oder mehr Beschleuniger. Stand 27. Oktober 2026 veröffentlicht das SGLang-Kochbuch Single-Node-Rezepte für 8 B300- oder 8 MI350X/MI355X-Karten mit insgesamt 2.304 GB sowie eine 32-GPU-H100-Konfiguration mit insgesamt 2.560 GB. Betrachten Sie den Wert für die Gewichte daher eher als Untergrenze denn als Anforderung.

Passt Kimi K3 durch Quantisierung auf einen einzelnen Knoten?

Der ausgelieferte 4-Bit-Checkpoint passt bereits auf einen Knoten, sofern dieser aus acht 288-GB-Karten besteht, wie es bei den B300- und MI355X-Rezepten von SGLang der Fall ist. Ebenso passt er auf eine Maschine mit etwa 1,6 TB RAM zuzüglich VRAM mittels Unsloths verlustfreiem Q8 GGUF. Eine stärkere Reduzierung hilft kleineren Maschinen: Die gemessenen dynamischen GGUF-Builds von Unsloth reichen von 861,3 GB bei 2-Bit bis 594 GB bei 1-Bit, und das Repository listet 1-Bit-Dateien bis hinunter zu 466 GB, gegenüber etwa 1,56 TB verlustfrei. Die Einbußen bei der Genauigkeit wurden gemessen: Die Top-1-Übereinstimmung mit dem vollständigen Modell sinkt auf 90,390 Prozent bei UD-Q2_K_XL und auf 78,875 Prozent bei UD-IQ1_S. Keines davon passt auf eine einzelne Karte.

Ist das Mieten von GPUs günstiger als die Kimi K3 API?

Nur bei hohem und konstantem Volumen. Bei angenommenen 2,50 USD pro GPU-Stunde kostet ein dauerhaft laufender 8-GPU-Knoten 14,400 USD pro Monat. Für denselben Betrag erhält man etwa 960 Millionen Output-Token zum veröffentlichten Preis von 15.00 USD pro Million. Sie zahlen zudem für Leerlaufzeiten, das Herunterladen der Gewichte und das Personal, das den Cluster betriebsbereit hält. Mieten Sie stundenweise für Lastspitzen und vergleichen Sie dies mit Ihrem eigenen gemessenen Token-Volumen, anstatt Schätzungen zu verwenden.

Was bedeutet 104B aktive Parameter für die Geschwindigkeit?

Es bedeutet, dass der Rechenaufwand pro Token dem eines 104B-Modells entspricht; der Durchsatz liegt also in dieser Klasse und nicht in der 2,8T-Klasse. Über den Speicher sagt dies nichts aus: Alle 2,8T Parameter bleiben resident, da der Router für jedes Token jeden Experten aufrufen kann. Verwenden Sie die Anzahl der aktiven Parameter zur Vorhersage der Token pro Sekunde und die Gesamtzahl zur Dimensionierung des VRAM.