Kimi K3 Qwen3.8: Selbsthosting und VRAM-Kosten

Der Gewinner ist die API- und Kurzzeit-Rechenmiete als Doppelstrategie, solange Modellgewichte, Framework-Unterstützung und reale Auslastung noch nicht nachgewiesen sind. Selbsthosting von Kimi K3 oder einem vergleichbaren Modell lohnt sich erst bei dauerhaft hoher Nutzung, verbindlichen Datenschutzanforderungen und einem Team, das verteilten GPU-Betrieb übernehmen kann. Eine bloße Multiplikation von Parametern und Quantisierungsbits reicht für die Beschaffung nicht aus.

Diese Analyse richtet sich an AI-Agent-Teams, die private Modellnutzung mit laufenden API-Kosten vergleichen. Sie hilft Verantwortlichen für Inferenzplattformen, aus Gewichten, Kontext, Parallelität und Reserve eine abnahmefähige Kapazität abzuleiten. Auch für den Einkauf entsteht eine klare Grenze zwischen eigener Infrastruktur, Rechenmiete und API.

Beschaffungsfähigkeit statt Parameterwerbung

Bei einem großen MoE-Modell müssen vier Werte getrennt betrachtet werden:

• Gesamtparameter: sämtliche Experten und gemeinsam genutzten Schichten.
• Aktivierte Parameter: der Teil, der pro Token tatsächlich berechnet wird.
• Speicherformat: etwa FP16, BF16, FP8 oder MXFP4.
• Laufzeitbedarf: Gewichte, KV-Cache, Aktivierungen, Kommunikationspuffer und Reserven.

Kimi K3 ist laut offiziellem Modell-Repository ein Mixture-of-Experts-Modell mit 2,8 Billionen Gesamtparametern und 104 Milliarden aktivierten Parametern. Das Modell verwendet 896 Experten, wählt 16 Experten pro Token aus, besitzt 93 Schichten und unterstützt einen Kontext von 1.048.576 Tokens. Die Gewichte liegen im Format MXFP4 vor, während Aktivierungen mit MXFP8 angegeben werden. Diese Werte stammen aus der offiziellen Kimi-K3-Modellkarte.

Der entscheidende Punkt: Die 104 Milliarden aktivierten Parameter ersetzen nicht die 2,8 Billionen Parameter, die für eine vollständige Inferenz verfügbar sein müssen. Bei klassischer Ausführung müssen die Experten im Speicher erreichbar sein. Eine Community-Ausarbeitung zu Kimi K3 schätzt den reinen Gewichtsspeicher bei MXFP4 auf ungefähr 1,4 TB; bei FP16 wären es ungefähr 5,6 TB. Das ist eine theoretische Speicherrechnung, keine produktionsfähige Mindestkonfiguration. Sie berücksichtigt weder KV-Cache noch Laufzeitreserve. Siehe dazu den Überblick zur MXFP4-Gewichtsgröße von Kimi K3.

Für die Einkaufsentscheidung müssen außerdem folgende Punkte vorliegen:

1. Vollständige Gewichtsdateien statt eines Teil- oder Demo-Repositories.
2. Eine Lizenz, die den geplanten kommerziellen Einsatz und die interne Weitergabe erlaubt.
3. Ein stabiles Ladeverfahren im vorgesehenen Inferenz-Framework.
4. Ein reproduzierbarer Start mit festgelegtem Quantisierungsformat.
5. Messwerte für normale Dialoge, lange Kontexte und Tool-Aufrufe.

Solange einer dieser Punkte fehlt, gehört das Modell auf eine Validierungsliste, nicht auf eine Bestellung. Das gilt besonders für Qwen3.8. In den aktuell sichtbaren offiziellen Qwen-Modellübersichten sind verschiedene Qwen3- und Qwen3.5-Varianten dokumentiert. Für Qwen3.8 sind dagegen je nach Veröffentlichungsstand nicht automatisch vollständige Gewichts-, Lizenz- und Framework-Angaben verfügbar. Die offizielle Qwen-Modellübersicht ist deshalb vor jeder Kalkulation gegen das konkrete Repository, die Dateiversion und die Lizenz zu prüfen.

Speicherrechnung mit getrennten Variablen

Die belastbare Grundformel lautet:

Gesamter GPU-Speicher =
Gewichtsspeicher
+ KV-Cache
+ Laufzeit- und Aktivierungsspeicher
+ Kommunikationspuffer
+ Fragmentierungsreserve
+ Ausfallsicherheitsreserve

Der Gewichtsspeicher kann zunächst so berechnet werden:

Gewichtsspeicher =
Parameterzahl × Bytes pro Parameter
+ Quantisierungsmetadaten
+ nicht quantisierte Schichten
+ Embeddings und Ausgabekopf
+ Multimodal-Komponenten

Die Bytes pro Parameter sind nicht einfach immer „Bits geteilt durch acht“. Bei blockweiser Quantisierung kommen Skalierungswerte und zusätzliche Strukturen hinzu. Manche Implementierungen lassen bestimmte Schichten bewusst in höherer Genauigkeit. Bei Kimi K3 müssen beispielsweise die native Vision-Komponente und die gewichtsbezogene MXFP4-Implementierung getrennt vom reinen Expertenblock betrachtet werden. Die offizielle Modellkarte nennt für den Vision Encoder 401 Millionen Parameter. (offizielle Kimi-K3-Modellkarte)

Der KV-Cache ist eine eigene Rechnung:

KV-Cache =
Anzahl der Ebenen
× Schlüssel-/Wertbreite
× Cache-Bytes
× Kontextlänge
× Anzahl paralleler Sequenzen

Die genaue Formel hängt vom Attention-Design ab. Bei Multi-Query- oder Multi-Head-Latent-Attention ist die Cache-Struktur nicht identisch mit einer klassischen Multi-Head-Attention. Deshalb darf ein Team nicht einfach eine allgemeine LLM-Formel auf jedes Modell übertragen. Die verwendete Framework-Version, der Cache-Datentyp und die Attention-Implementierung müssen in den Testaufzeichnungen stehen.

Die vLLM-Dokumentation zu KV-Cache, Quantisierung und Tensor-Parallelität beschreibt diese Komponenten als getrennte Speicher- und Ausführungsbereiche. Besonders wichtig ist die Unterscheidung zwischen Modellgewichten, Aktivierungen und KV-Cache.

Wie viel Speicher benötigt Kimi K3 nach der Quantisierung mindestens?

Eine seriöse Antwort lautet nicht „1,4 TB GPU-Speicher“. Die genannte Größenordnung beschreibt den theoretischen Speicherbedarf der MXFP4-Gewichte. Für einen Dienst kommen Cache, Laufzeit, Parallelisierung, Modellstart und Fehlerreserve hinzu. Außerdem kann die Dateiablage größer sein als der effektiv belegte Gewichtsspeicher.

Ein vollständiger Kimi-K3-MXFP4-Datensatz wurde in einer Community-Repack-Variante mit ungefähr 1,51 TB angegeben; zugleich wird darauf hingewiesen, dass die Architektur nicht vollständig von jeder Standardimplementierung geladen werden kann. Das ist ein Hinweis auf die praktische Bereitstellungshürde, aber kein offizieller Mindestwert für ein Produktionssystem. Siehe die Dokumentation des Community-Repositories.

Für den Betrieb muss zusätzlich die Verteilung auf Geräte und Knoten geplant werden:

• Tensor-Parallelität: Die Modellberechnung wird über mehrere GPUs geteilt. Kommunikationskosten und Synchronisation steigen.
• Pipeline-Parallelität: Schichten werden auf verschiedene Geräte verteilt. Mikro-Batches und Pipeline-Lücken beeinflussen die Auslastung.
• Experten-Parallelität: MoE-Experten liegen auf unterschiedlichen Geräten. Routing und All-to-All-Kommunikation können zum Engpass werden.
• Knotenübergreifende Verbindung: Ein Modell kann rechnerisch in den Speicher passen und trotzdem wegen Netzwerkwartezeiten keine brauchbare Dienstqualität erreichen.
• Reserveknoten: Ohne Ersatzkapazität führt ein einzelner GPU- oder Netzwerkausfall direkt zum Dienstabbruch.

Die Summe dieser Variablen entscheidet, ob ein Modell nur startet oder tatsächlich als Dienst betrieben werden kann.

Dienstqualität zwischen Laden und Nutzen

Ein erfolgreicher Modellstart ist kein Produktionsnachweis. Ein Agenten-Team benötigt mindestens vier Messwerte:

1. Zeit bis zum ersten Token.
2. Generierungsdurchsatz unter definierter Parallelität.
3. Warteschlangenlänge bei Spitzenlast.
4. Stabilität bei langen Gesprächen und Tool-Aufrufen.

Die Messung muss mit dem späteren Nachrichtenformat erfolgen. Bei Kimi K3 ist die vollständige Rückgabe der Denk- und Tool-Aufruf-Historie laut Modellkarte für mehrteilige Gespräche und Werkzeugnutzung relevant. Wird nur der sichtbare Antworttext zurückgegeben, kann das Verhalten von der vorgesehenen Nutzung abweichen. Dieser Integrationspunkt ist für AI-Agenten oft wichtiger als ein synthetischer Benchmark. (Kimi-K3-Modellkarte)

Ein realistischer Abnahmetest besteht aus drei Lastklassen:

• Normaler Dialog: kurze Eingaben, begrenzter Kontext, mehrere parallele Nutzer.
• Langer Kontext: große Dokumente oder Repository-Ausschnitte, wachsende Cache-Größe.
• Agentenlauf: mehrere Werkzeugschritte, strukturierte Ausgaben, Wiederaufnahme vorheriger Denk- und Tool-Zustände.

Bei langen Kontexten steigt der KV-Cache mit jeder zusätzlichen Sequenz. Bei Agentenläufen bleibt der Kontext häufig länger erhalten als bei einem einzelnen Frage-Antwort-Vorgang. Dadurch kann eine scheinbar ausreichende Konfiguration unter realer Nutzung in die Speicherreserve laufen.

Vorteile des Selbsthostings

• Daten bleiben innerhalb der eigenen Sicherheits- und Compliance-Grenzen.
• Modellversion, Prompt-Format und Routing können kontrolliert werden.
• Bei stabiler Dauerlast sinkt die Abhängigkeit von nutzungsabhängigen API-Rechnungen.
• Interne Systeme können ohne externe Datenübertragung angebunden werden.

Nachteile des Selbsthostings

• Gewichtsablage, GPU-Betrieb und Netzwerk sind laufende Kosten.
• Framework-Updates können ein funktionierendes Setup brechen.
• MoE-Routing und Parallelisierung erhöhen die Fehlersuche.
• Ein hoher Spitzenbedarf verlangt Reservekapazität, die außerhalb der Spitzen oft ungenutzt bleibt.
• Lizenz- und Datenschutzprüfungen bleiben auch bei eigener Hardware erforderlich.

Ein Cloud-Mac kann in dieser Architektur sinnvoll sein, aber nicht als Ersatz für die große Inferenzplattform. Er eignet sich für Agentenentwicklung, Remote-Zugriff, Testskripte, Monitoring-Dashboards und Betriebswerkzeuge. Für das vollständige Laden eines mehrterabytegroßen MoE-Modells ist er nicht die passende Hauptschicht. Anforderungen an Datenverarbeitung und Zugriffsrechte sollten zusätzlich in der Datenschutzerklärung von ProxyMac und in der technischen Betriebsdokumentation geprüft werden.

Validierung in sieben Schritten

1. Modellstand einfrieren

Das Team notiert Repository, Commit oder Dateiversion, Konfiguration, Tokenizer, Lizenz und Quantisierungsformat. Ein Modellname allein reicht nicht. Ein später aktualisiertes Repository kann andere Dateien oder andere Laufzeitanforderungen enthalten.

2. Gewichtsbestand prüfen

Alle Shards, Prüfsummen und Zusatzdateien werden vollständig erfasst. Teil-Downloads oder automatisch konvertierte Formate dürfen nicht als Produktionsbasis gelten. Bei Kimi K3 muss insbesondere geprüft werden, ob das gewählte Framework die Architektur und das MXFP4-Format direkt unterstützt.

3. Speicherformel ausfüllen

Gewichte, KV-Cache, Aktivierungen, Kommunikationspuffer, Fragmentierung und Reserve werden in separaten Zeilen geführt. Aktivierte Parameter dürfen ausschließlich für Rechenaufwand und Routing-Analyse genutzt werden, nicht als Ersatz für die Gesamtgewichte.

4. Ein-GPU-Test vermeiden

Ein Minimaltest auf einem einzelnen Gerät sagt bei einem verteilten MoE-Modell wenig über den späteren Dienst aus. Das Testdesign muss die geplante Tensor-, Pipeline- oder Experten-Parallelität abbilden. Andernfalls werden Netzwerk- und Synchronisationskosten zu spät sichtbar.

5. Drei Lastprofile ausführen

Normale Dialoge, lange Kontexte und Agenten-Tool-Aufrufe werden jeweils separat gemessen. Für jedes Profil werden Eingabelänge, Ausgabelimit, parallele Sequenzen, Cache-Datentyp und Abbruchkriterien dokumentiert.

6. Fehlerfälle erzwingen

Das Team beendet einen Worker, trennt eine Testverbindung und füllt den Cache bis zur Reservegrenze. Dabei wird geprüft, ob der Dienst sauber zurückfällt oder alle Anfragen verliert. Eine Konfiguration ohne Fehlerprobe ist keine belastbare Kapazitätsplanung.

7. Kosten mit Auslastung rechnen

Die Kalkulation verwendet nicht nur den Preis pro Stunde oder pro Token. Sie enthält unproduktive Reservezeit, Speicher, Netzwerk, Monitoring, Bereitschaft, Upgrade-Tests und Wiederherstellung. Erst danach wird die Eigenlösung gegen API und Kurzzeitmiete verglichen.

Kostenmodell mit Auslastung

Die Kosten des Selbsthostings sollten als monatliche Gesamtgröße geführt werden:

Selbsthosting =
GPU- und Serverkosten
+ Speicher
+ Netzwerk
+ Strom oder Rechenzentrumsgebühren
+ Bereitstellung
+ Monitoring und Bereitschaft
+ Upgrade- und Testaufwand
+ Ausfall- und Ersatzkapazität

Für eine API lautet das Gegenmodell:

API-Kosten =
Eingabetokens × Preis je Eingabetoken
+ Ausgabetokens × Preis je Ausgabetoken
+ Zusatzkosten für Cache-Misses
+ eventuelle Daten-, Routing- oder Plattformkosten

DeepSeek veröffentlicht für V4 eine offizielle Preistabelle mit getrennten Preisen für Cache-Hits, Cache-Misses und Ausgabetokens. Die Seite nennt außerdem unterschiedliche Parallelitätsgrenzen für die dort aufgeführten Varianten. Diese Werte müssen vor einer Entscheidung am Einsatztag geprüft werden, weil Anbieter Preise und Limits ändern können. Die offizielle DeepSeek-V4-Preisdokumentation ist daher die maßgebliche Quelle.

Ist ein eigener DeepSeek-V4-Cluster günstiger als die API?

Das lässt sich erst mit dem echten Tokenprofil beantworten. Ein Cluster kann bei hoher, gleichmäßiger Auslastung einen niedrigeren internen Preis pro Token erreichen. Bei unregelmäßigen Agentenläufen werden jedoch GPU-Reserve, Bereitschaft und Wartung auf wenige produktive Stunden verteilt. Die API kann dann trotz höherem Einzelpreis günstiger sein, weil nur tatsächliche Eingaben und Ausgaben abgerechnet werden.

Ein einfaches Entscheidungskriterium lautet:

Eigenbetrieb lohnt sich nur, wenn
monatliche API-Vergleichskosten
>
monatliche Vollkosten des Eigenbetriebs

Dabei müssen beide Seiten dieselbe Dienstqualität liefern. Ein günstigerer Preis bei längerer Wartezeit, häufigen Abbrüchen oder geringerer Parallelität ist kein fairer Vergleich.

Für die kurzfristige Rechenmiete gilt:

Mietkosten =
Stundensatz oder Zeitraum
× tatsächliche Mietdauer
+ Einrichtung
+ Datenübertragung
+ Speicher
+ Test- und Abbauzeit

Diese Variante ist vor allem dann sinnvoll, wenn ein Team ein Modell prüfen, ein Deployment-Skript validieren oder Agenten-Workflows mit realer Inferenz testen möchte. Sie verhindert eine frühe Investition in Hardware, ohne die technische Prüfung auf einen reinen API-Test zu reduzieren.

Entscheidungstabelle für die Abnahme

Die folgende Tabelle ersetzt keine Messung. Sie zwingt das Einkaufsteam jedoch, die Entscheidung an überprüfbare Bedingungen zu knüpfen.

Option	Geeignete Bedingungen	Hauptvorteil	Hauptrisiko	Entscheidung
Selbsthosting	Dauerlast, strenge Datenhoheit, verifiziertes Framework, Betriebsteam	Kontrolle und planbare interne Datenwege	Hohe Reserve- und Betriebsaufwände	Nur nach erfolgreicher Abnahme
Kurzzeitmiete	Validierung, Migration, schwankende Last, begrenzter Zeitraum	Schneller Test ohne langfristige Bindung	Lieferzeit, Datenübertragung und Abbauaufwand	Geeignet für die Prüfphase
API	Unklare Auslastung, schnelle Markterprobung, geringe Betriebsressourcen	Keine Modellinfrastruktur erforderlich	Anbieterabhängigkeit und variable Tokenkosten	Geeignet als Startpunkt
Doppelstrategie	Datenschutzkritische Kernlast plus variable Spitzenlast	Kombination aus Kontrolle und Elastizität	Zwei Betriebsmodelle müssen gepflegt werden	Häufig beste Übergangslösung

Die Entscheidung „weiter beobachten“ sollte nicht das Ergebnis sein. Nach dem Test wird eine der vier Optionen gewählt. Dafür können Verantwortliche folgende Bedingungen unterschreiben:

• Selbsthosting, wenn Ziel-Latenz, Durchsatz, Datenschutz und Reserve nachweislich erfüllt sind.
• Miete, wenn das Modell technisch geeignet wirkt, aber die Dauerlast noch nicht sicher ist.
• API, wenn die Nutzung klein, unregelmäßig oder organisatorisch nicht bereit für verteilten Betrieb ist.
• Doppelstrategie, wenn sensible Standardlast intern bleiben muss, während Spitzen und Experimente über API oder Rechenmiete laufen.

Klare Abbruchlinien

Ein Team sollte das Selbsthosting eines großen MoE-Modells vorerst aufgeben, wenn mindestens eine dieser Grenzen erreicht ist:

• Das Framework lädt die vollständigen Gewichte nicht reproduzierbar.
• Die Lizenz deckt den geplanten Einsatz nicht eindeutig ab.
• Die Zielwerte für Zeit bis zum ersten Token oder Durchsatz werden unter Agentenlast nicht erreicht.
• KV-Cache und Parallelität verbrauchen die Reserve bereits bei normaler Auslastung.
• Ein einzelner Worker-Ausfall führt zu einem nicht akzeptablen Dienststillstand.
• Die notwendige Bereitschaft und Upgrade-Prüfung überschreiten das interne Betriebsbudget.
• Die Erweiterung der Kapazität dauert länger als der geschäftlich tolerierte Zeitraum.
• Der tatsächliche Bedarf schwankt so stark, dass ein großer Cluster überwiegend ungenutzt bleibt.

Für Qwen3.8 gilt bis zur vollständigen Prüfung des konkreten offiziellen Modell-Repositories eine zusätzliche Abbruchlinie: keine langfristige Hardwarebestellung, solange Gewichtsformat, Lizenz, vollständige Dateien und stabile Framework-Unterstützung nicht dokumentiert sind. Berichte aus Foren oder sozialen Netzwerken können eine Testpriorität begründen, aber keine Kaufentscheidung. Dasselbe gilt für angebliche Leistungs- oder Speicherwerte zu noch nicht vollständig belegten Varianten.

Die sinnvollere Übergangsarchitektur

Für viele AI-Agent-Teams ist die derzeitige Lösung aus API, lokaler Entwicklung und gelegentlicher Rechenmiete zunächst wirtschaftlicher als ein eigener Cluster. Sie vermeidet die Anschaffung ungenutzter Reserve, reduziert den Aufwand für verteilte Fehlersuche und erlaubt trotzdem realistische Deployment-Tests. Nachteile bleiben: API-Kosten schwanken mit dem Tokenvolumen, Datenflüsse müssen rechtlich geprüft werden und die Abhängigkeit vom Anbieter bleibt bestehen.

Eine reine lokale oder selbst betriebene Infrastruktur hat dagegen hohe Anfangskosten, lange Beschaffungszyklen und laufende Pflege. Sie ist nicht automatisch stabiler, wenn Framework-Updates, Routing-Fehler oder fehlende Ersatzkapazität den Dienstbetrieb beeinträchtigen. Ein gemieteter Mac von ProxyMac ist für Agentenentwicklung, Remote-Betrieb, CI/CD-Skripte und die Verwaltung einer getrennten Inferenzumgebung oft die flexiblere Ergänzung. Er ersetzt jedoch nicht die GPU- oder Mehrknotenschicht für das vollständige Modell.

Wer die technische Prüfung in einer kontrollierten Arbeitsumgebung durchführen möchte, kann die ProxyMac-Hilfe für den Remote-Betrieb und die ProxyMac-Konsole in die Betriebsplanung einbeziehen. Vor einer langfristigen Bindung sollte die Kostenvariablentabelle dieses Artikels mit dem eigenen Kontextfenster, der parallelen Sequenzzahl und der realen Auslastung ausgefüllt werden. Liegt das Ergebnis nahe am Gleichgewichtspunkt, ist eine kurze, isolierte Mietphase der sauberste nächste Schritt: Deployment-Skript, Agenten-Workflow, Monitoring und Fehlerwiederherstellung werden geprüft, bevor ein dauerhafter Cluster gekauft oder gemietet wird.