MoE-Expert-Offload mit KTransformers: Kimi K2.6 auf vier GPUs und DDR5-Hauptspeicher

Was Expert-Offload leistet und wo es endet

Kimi K2.6 passt nicht auf vier GPUs: Sein Checkpoint mit 595 GB ist größer, als vier RTX PRO 6000 Blackwell Server Edition oder vier H200 NVL aufnehmen können. Expert-Offload hält die Attention-Schichten, den Shared Expert und einen Teil der gerouteten Experten auf den GPUs und rechnet die übrigen Experten auf den Prozessoren des Servers, aus dem DDR5-Hauptspeicher. Das Modell läuft dann auf einem Server mit vier Karten für einen oder wenige Nutzer gleichzeitig, mit einer Geschwindigkeit, die die Bandbreite des Hauptspeichers bestimmt; ein Dienst, den viele Menschen gleichzeitig nutzen, braucht weiterhin acht Karten, wie sie unser Leitfaden zur Kimi-K2-Hardware dimensioniert.

Die GPUs verarbeiten die Prompts und rechnen die Attention-Schichten; der Hauptspeicher erweitert nur den Platz für Experten, es bleibt also GPU-Inferenz mit erweitertem Speicher. Der Ansatz funktioniert, weil ein Mixture-of-Experts-Modell (MoE) je Token nur einen kleinen Teil seiner Gewichte nutzt. Kimi K2.6 hat laut Modellkarte 1T Parameter, davon 32B aktiv, 61 Schichten, 384 geroutete Experten, von denen je Token 8 ausgewählt werden, einen Shared Expert und eine dichte erste Schicht. Unser Artikel zu aktiven und gesamten Parametern bei MoE erklärt, warum trotzdem alle Experten irgendwo im Speicher liegen müssen.

Die Karte von Kimi-K2.6 nennt drei empfohlene Engines: vLLM, SGLang und KTransformers. Ihr Deployment-Leitfaden betreibt vLLM und SGLang auf einem H200-Knoten mit TP=8 und KTransformers zusammen mit SGLang „for CPU+GPU heterogeneous inference“.

Wohin die 595 GB gehen

Die Konfiguration von K2.6 quantisiert die gerouteten Experten auf 4-Bit-Ganzzahlen in Blöcken von 32 und hält Attention, Shared Experts, die dichte Schicht, die Ausgabeschicht und den Vision-Encoder in 16 Bit. In jeder der 60 MoE-Schichten hat bei einer Hidden Size von 7.168 und einer Expertenbreite von 2.048 jeder Experte drei Matrizen zu 7.168 × 2.048, 44,0 Millionen Gewichte.

config.json und Dateiliste von Kimi-K2.6 auf Hugging Face (Repository mit 595 GB), gelesen am 24. Oktober 2026; unsere Rechnung mit 4 Bit plus einer 16-Bit-Skala je Block von 32, das gespeicherte Format ist unsere Annahme; die zweite Zeile ist der Rest.

Die rund 24 GB auf den GPUs werden für jedes Token gelesen, die Experten nur dann, wenn ein Token an sie geleitet wird. Offload legt den großen, selten genutzten Teil in den Hauptspeicher und hält den kleinen, ständig genutzten Teil auf den Karten. Der KV-Cache bleibt auf den GPUs: Kimi K2 nutzt Multi-Head Latent Attention mit 68,6 KiB je Token in 16 Bit, 2,14 GiB je Gespräch zu 32K Token, die vLLM bei Tensor-Parallelismus auf jeder Karte vollständig hält, wie unser Kimi-Leitfaden berechnet.

Vier RTX PRO 6000 Server Edition oder vier H200 NVL mit Hauptspeicher

Wie viel der Expertengewichte auf den GPUs bleibt, hängt von den Karten ab. Wir reservieren je Server die 24 GB gemeinsamer Gewichte, den Cache für vier Gespräche zu 32K auf jeder Karte und, als unsere Annahme, rund 9 GB je Karte für lange Prompts: Die kt-kernel-Dokumentation von KTransformers hält fest, dass ihr schichtweises GPU-Prefill „requires one MoE layer extra VRAM (e.g., ~9GB+ for Kimi-K2-Thinking)“.

Unsere Schätzungen: nutzbarer Speicher nach unserer Regel für Nutzer je Karte, abzüglich 22,4 GiB gemeinsamer Gewichte, 4 × 4 × 2,14 GiB Cache und 4 × 8,4 GiB Reserve für das Prefill. Compute Capability laut NVIDIA; Liste des Wheels aus der kt-kernel-README auf GitHub, gelesen am 24. Oktober 2026.

Für die RTX PRO 6000 ergibt das 332,2 − 22,4 − 34,2 − 33,5 = 242,1 GiB, rund 260 GB Expertengewichte auf den Karten. Der H200-NVL-Server hält drei Viertel der Experten auf den GPUs, deutlich weniger Token warten also auf die Prozessoren; seine NVLink-Brücke verbindet die vier Karten für den tensorparallelen Teil. Unsere Seiten zum Server mit 4× RTX PRO 6000 Server Edition und zum Server mit 4× H200 NVL beschreiben beide Maschinen.

KTransformers legt beim Start fest, welche Experten auf den GPUs liegen. Die kt-kernel-Dokumentation nennt die Platzierungsstrategien uniform, den Standard, der „distributes GPU experts evenly across all MoE layers“, und frequency, die „places the most frequently activated experts on GPU“ anhand einer Statistikdatei. Mit echten Prompts ist das Routing ungleichmäßig, eine Platzierung nach Häufigkeit aus Ihrem eigenen Verkehr bedient also mehr Token aus dem GPU-Speicher, als der Anteil in der Tabelle nahelegt.

Wir liefern beide Server mit vier Karten und dimensionieren Hauptspeicher und Prozessoren für Offload; schicken Sie uns Modell, Zahl der gleichzeitigen Nutzer und Kontextlänge, und unser Team antwortet mit der Aufteilung zwischen GPU- und Hauptspeicher und einer Schätzung der Geschwindigkeit.

Geschwindigkeit: Die Bandbreite des Hauptspeichers ist die Obergrenze

Jeder Experte, den die Prozessoren rechnen, wird aus dem DDR5 gelesen. AMD nennt für den EPYC 9355 eine Speicherbandbreite von 614 GB/s je Sockel mit 12 Kanälen DDR5-6400; zwei Sockel mit vollständig bestückten Kanälen bieten also 1.229 GB/s. Ein Token mit allen gerouteten Experten im Hauptspeicher liest rund 11,9 GB, das ergibt eine Obergrenze von rund 100 Token pro Sekunde für einen Nutzer. Liegen 45 Prozent der Experten auf vier RTX PRO 6000 Server Edition, lesen die Prozessoren je Token rund die Hälfte.

Mehr gleichzeitige Nutzer skalieren diesen Wert nicht. Jedes Gespräch leitet sein Token an seine eigenen 8 Experten je Schicht, ein Batch liest also die Vereinigung der Experten, die seine Token brauchen. Mit gleichmäßigem Routing als unserer Annahme wächst diese Vereinigung schnell:

Unsere Rechnung, nach unserer Schätzung Obergrenzen: alle gerouteten Experten im Hauptspeicher, 1.229 GB/s theoretische DDR5-Bandbreite voll genutzt, gleichmäßiges Routing (384 × (1 − (376/384)^Nutzer) Experten je Schicht), Rechenzeit der Prozessoren und der GPUs nicht gezählt. Reale Systeme erreichen einen Bruchteil jedes Werts.

Die Tabelle nennt Grenzen aus der Rechnung; ein Server liefert weniger. Die erreichbare DDR5-Bandbreite liegt unter dem theoretischen Wert, jeder Sockel liest am schnellsten aus seinem eigenen Speicher, und die Prozessoren müssen die Experten auch berechnen. Sie zeigt aber die Form: Ab einer Handvoll gleichzeitiger Nutzer erhält jeder Nutzer wenige Token pro Sekunde, während acht GPUs, die alle Experten halten, sie mit 1.597 bis 4.800 GB/s je Karte aus HBM oder GDDR7 lesen.

Veröffentlichte Ergebnisse mit KTransformers

Der Deployment-Leitfaden auf der Kimi-K2.6-Karte von Moonshot AI meldet für KTransformers mit SGLang: „Achieves 640.12 tokens/s Prefill and 24.51 tokens/s Decode (48-way concurrency) on 8× NVIDIA L20 + 2× Intel 6454S.“ Der Leitfaden sagt nicht, ob 24,51 Token pro Sekunde die Summe über 48 Anfragen oder die Rate je Anfrage sind, und beide Lesarten unterscheiden sich um den Faktor 48; der Wert taugt deshalb allein nicht zur Dimensionierung eines Servers. Sein Startbefehl setzt außerdem --tensor-parallel-size 4 neben der Hardwarezeile mit acht Karten.

Die README von KTransformers nennt einen zweiten Wert: DeepSeek-R1-0528 in FP8 auf acht L20 mit einem Xeon Gold 6454S erreichte 227,85 Token pro Sekunde Gesamtdurchsatz und 87,58 Ausgabe-Token pro Sekunde bei acht gleichzeitigen Anfragen. Beide Ergebnisse stammen vom KTransformers-Projekt und von Moonshot AI. Ein veröffentlichtes Offload-Ergebnis für Kimi K2.6 auf der RTX PRO 6000 oder der H200 NVL haben wir nicht gefunden; der einzige belastbare Wert ist also ein Test mit Ihren Prompts und Ihrer Gleichzeitigkeit.

Software: KTransformers, SGLang und llama.cpp

KTransformers ist ein Forschungsprojekt der Organisation kvcache-ai unter Apache 2.0 für heterogene Inferenz und Fine-Tuning auf CPU und GPU; seine README nennt das Release v0.7.0 vom 17. August 2026. Unter den unterstützten Modellen führt sie Kimi-K2, K2-0905, K2-Thinking und K2.5, nicht K2.6, während die K2.6-Karte festhält, dass das Modell „has the same architecture as Kimi-K2.5, and the deployment method can be directly reused“. Das K2.5-Tutorial verlangt insgesamt mindestens 48 GB GPU-Speicher, eine „x86 CPU with AVX512F support“, „At least 600GB system memory“ und rund 600 GB Speicherplatz für die Gewichte, die CPU und GPU aus einem gemeinsamen Ordner lesen.

kt-kernel-README von KTransformers auf GitHub, gelesen am 24. Oktober 2026. Die README warnt, dass AMXINT4 „May cause huge accuracy drop for some models“.

AMD hält fest, dass die EPYC-Prozessoren der 5. Generation „implement the full set of AVX-512 instructions“ (AMD-Blog, 22. Januar 2025); der RAWINT4-Pfad, den der K2.6-Leitfaden nutzt, läuft also auf EPYC 9005, die AMX-Methoden brauchen Intel Xeon. Die README empfiehlt, --kt-cpuinfer auf die Zahl der physischen Kerne zu setzen, nicht der Hyperthreads, und --kt-threadpool-count auf die Zahl der NUMA-Knoten.

Für die RTX PRO 6000 ist die GPU-Seite der offene Punkt. Die kt-kernel-README nennt GPU-Beschleunigung für SM 80, 86, 89 und 90 (Ampere, Ada, Hopper) und erwähnt Blackwell nicht. Die H200 NVL mit Compute Capability 9.0 liegt in dieser Liste. Für die RTX PRO 6000 mit 12.0 planen Sie einen Build aus dem Quellcode und einen Testlauf, bevor Sie sich auf die Aufteilung festlegen; unsere Seite zur Software-Unterstützung für Blackwell RTX behandelt SGLang und vLLM auf dieser Architektur.

llama.cpp bietet eine einfachere Form des Offloads: Sein Server hält mit --cpu-moe „all Mixture of Experts (MoE) weights in the CPU“, mit --n-cpu-moe die der ersten N Schichten. Es braucht eine GGUF-Konvertierung und gehört nicht zu den Engines, die Moonshot AI für K2.6 empfiehlt. Die Offload-Option im K2.6-Rezept von vLLM arbeitet anders: Sie erweitert den Prefix-Cache in den Hauptspeicher, wie unser Kimi-Leitfaden und unser Artikel zum Auslagern des KV-Caches in CPU-Speicher und NVMe erklären, und verschiebt keine Experten.

Prozessoren und Speicher für einen Offload-Server

Beim Offload ist der Hauptspeicher Teil des Inferenzpfads, und seine Bandbreite zählt so viel wie seine Größe.

• Alle Kanäle bestückt. Zwei EPYC 9005 haben 24 Kanäle; ein Modul je Kanal mit DDR5-6400 hält die vollen 614 GB/s je Sockel. Unser Leitfaden Wie viel RAM braucht ein GPU-Server? nennt die Stufen: 24 Module zu 32, 64 oder 96 GB ergeben 768, 1.536 oder 2.304 GB.
• Kapazität. Das K2.5-Tutorial verlangt mindestens 600 GB. Die 768 GB unseres Inferenzknotens mit vier Karten auf der Seite KI-Server erfüllen das mit wenig Platz für Page Cache und Betriebssystem; 1.536 GB mit Modulen zu 64 GB lassen Reserve für ein zweites Modell oder einen größeren Cache.
• Kerne. KTransformers führt seine Experten-Threads auf physischen Kernen aus, das K2.6-Beispiel setzt 96 davon. Mehr Kerne je Sockel erhöhen die Rechenleistung der Prozessoren je Schritt; unser Leitfaden zur CPU für einen GPU-Server vergleicht EPYC und Xeon.
• Strom. Vier RTX PRO 6000 Server Edition bei 600 W mit zwei EPYC 9355 kommen nach unserer Schätzung auf rund 3,4 kW aus dem Netz; Prozessoren mit mehr Kernen kommen mit ihrer TDP hinzu, und eine Messung am gelieferten System bestätigt den Wert.

Wann Offload passt und wann acht Karten

Expert-Offload passt in diesen Fällen:

• Kimi K2.6 auf einem vorhandenen Server mit vier Karten evaluieren, bevor Sie für die Produktion kaufen.
• Wenige Nutzer gleichzeitig: der Agent eines Teams, ein Batch-Job über Nacht, ein Forschungsteam.
• Entwicklungsarbeit, bei der die Qualität des 1T-Modells mehr zählt als die Geschwindigkeit der Antwort.

Für einen Unternehmensassistenten mit Dutzenden gleichzeitigen Gesprächen passt es nicht. Nach unserer Schätzung oben erhielten 32 gleichzeitige Nutzer bestenfalls je rund 4 Token pro Sekunde. Acht H200 NVL halten die INT4-Gewichte im GPU-Speicher, und das Kimi-K2-Thinking-Rezept von vLLM auf acht H200 meldet Cache für rund 21 Gespräche zu 32K mit Tensor-Parallelismus und rund 174 mit Decode Context Parallelism, wie unser Kimi-Leitfaden zeigt; auch acht RTX PRO 6000 Server Edition halten die Gewichte, und unsere Seite zu acht RTX PRO 6000 Server Edition für LLMs behandelt diesen Server. Zwei Server mit vier Karten, verbunden über Pipeline-Parallelismus, sind ein dritter Weg, beschrieben in Ein 600-GB-Modell auf zwei 4-GPU-Servern. Und ein kleineres MoE-Modell, das vollständig auf vier Karten passt, etwa DeepSeek-V4-Flash-0731 mit 167 GB oder gpt-oss-120b, läuft auf derselben Hardware schneller.

Moonshot AI veröffentlicht K2.6 unter einer Modified MIT License. Ihre einzige Änderung betrifft kommerzielle Produkte oder Dienste mit „more than 100 million monthly active users, or more than 20 million US dollars (or equivalent in other currencies) in monthly revenue“, die auf ihrer Benutzeroberfläche „prominently display "Kimi K2.6"“ müssen. Ob das für Ihr Unternehmen gilt, bestätigt Ihre Rechtsabteilung. Modell, Engine und Messung richten wir im Rahmen unseres Service Private AI/ML ein; beschreiben Sie die Nutzer und Aufgaben, die Sie für Kimi K2.6 planen, und wir schlagen Offload für einen Pilotbetrieb oder einen Server mit acht Karten für die Produktion vor.

Was wir liefern

Sie können dieses System bei uns kaufen: Unser Team dimensioniert die Konfiguration für Ihre Last und Ihr Budget und antwortet innerhalb eines Werktages. Wir bauen KI-Server auf Bestellung mit vier oder acht RTX PRO 6000 Server Edition oder H200 NVL, zwei AMD-EPYC- oder Intel-Xeon-Prozessoren und DDR5-ECC-Speicher in jedem Kanal, vor der Lieferung montiert und getestet, auf Wunsch mit Betriebssystem, NVIDIA-Treiber, CUDA und Container-Laufzeit. Jede Komponente hat die Herstellergarantie, abgewickelt über uns, auf einem EU-Vertrag und einer Rechnung; Stückzahlen und Lieferzeit werden mit dem Angebot schriftlich bestätigt.

FAQ