Kimi K3 und Qwen3.8: Selbsthosting-Abnahme 2026

Kaufen Sie für Kimi K3 oder Qwen3.8 nicht zuerst die Hardware, sondern bestehen Sie zunächst fünf Abnahmetore: Gewichtsdaten und Lizenz, Speicherreserve, reale AI-Agent-Last, Fehlerwiederherstellung sowie die Kosten der ersten Betriebswoche. Erst wenn alle harten Kriterien erfüllt sind, lohnt sich eine langfristige Selbsthosting-Beschaffung; andernfalls ist eine kurzfristig gemietete Testumgebung, ein API-Doppelbetrieb oder ein vollständiger Stopp die rationalere Entscheidung.

Diese Abnahme für Kimi K3 und Qwen3.8 im Selbsthosting richtet sich an Teams, die einen unabhängigen Inferenzendpunkt für AI Agent, interne Wissensdienste oder produktive Workflows planen. Sie ist außerdem für Verantwortliche gedacht, die auf Qwen3.8-Gewichte warten oder Kimi K3 bereits laden können, aber noch keine belastbare Parallelitäts- und Stabilitätsprüfung durchgeführt haben.

Die fünf Tore vor jeder Beschaffungszusage

Die zentrale Fehlannahme lautet: „Wenn die Gewichte geladen werden, ist das Modell einsatzbereit.“ Bei einem großen MoE-Modell ist das nur ein sehr kleiner Teil der Prüfung. Kimi K3 wird im offiziellen Repository als Modell mit ungefähr 2,8 Billionen Gesamtparametern und etwa 104 Milliarden aktivierten Parametern beschrieben. Es verwendet 896 Experten, wählt davon 16 pro Token aus und unterstützt ein Kontextfenster von 1.048.576 Token. Diese Architektur macht die Rechnung anspruchsvoller, weil die aktivierte Rechenmenge nicht mit der vollständig vorzuhaltenden Gewichtsspeichermenge gleichzusetzen ist. (github.com)

Wir trennen deshalb zwischen harten Toren und optimierbaren Punkten:

Die wichtigste Konsequenz: Ein Modell darf nicht nur nach maximaler Speicherdichte oder theoretischer Rechenleistung bewertet werden. Die Freigabe muss an einem reproduzierbaren Geschäftsfall hängen.

Vor dem Test: Quelle, Lizenz und Softwarekette einfrieren

Erste Prüfung: Gewichtsdaten und Rechte

Für Kimi K3 existieren ein offizielles Repository, ein Modellüberblick und eine eigene Lizenzdatei. Das offizielle Repository nennt unter anderem MXFP4-Gewichte, MXFP8-Aktivierungen, 93 Schichten sowie die empfohlene Nutzung mit vLLM, SGLang und TokenSpeed. Diese Angaben sind jedoch kein Ersatz für einen eigenen Abnahmetest mit der tatsächlich geladenen Version. (github.com)

Wir halten vor dem ersten Start mindestens folgende Informationen fest:

1. Exakte Modellkennung und Commit oder Release-Stand.
2. Herkunft jedes Gewichtspakets.
3. Prüfsummen oder ein vergleichbares Integritätsverfahren.
4. Lizenztext einschließlich Einschränkungen für interne Nutzung, Weitergabe und Model-as-a-Service.
5. Quantisierungsformat und nachvollziehbare Konvertierungsschritte.
6. Verwendete Laufzeit, Container-Version, Treiber und Kernel.

Eine Community-Konvertierung darf nicht automatisch als offizielles Gewichtspaket behandelt werden. Das gilt besonders bei MXFP4-Formaten, weil ein scheinbar erfolgreiches Laden noch nicht beweist, dass Skalierungsfaktoren, Kernel und Aktivierungsformat korrekt zusammenspielen.

Für Qwen3.8 gilt eine strengere Zurückhaltung: Vor einer offiziellen Freigabe der Gewichte dürfen wir nur Testskripte, Container und Prüfabläufe vorbereiten. Downloadstatus, Lizenz, Quantisierung und Framework-Kompatibilität müssen aus dem dann tatsächlich verfügbaren offiziellen Modellrepository stammen. Community-Angaben zu einem möglichen Erscheinungstermin, einer Mindesthardware oder einer bestimmten Quantisierung bleiben bis dahin unbestätigte Hinweise.

Zweite Prüfung: Softwarekompatibilität statt vorschneller Speicherdiagnose

Ein Fehler beim Start kann aus mehreren Schichten kommen: falsches Chat-Template, unpassender Kernel, fehlerhafte Tensor- oder Expertenparallelität, inkompatible Quantisierung oder ein Problem im Werkzeugaufruf. Deshalb darf „CUDA out of memory“ nicht automatisch als Beweis gelten, dass die Hardware zu klein ist.

Für Kimi K3 dokumentiert das offizielle Repository derzeit mehrere unterstützte Inferenzwege. Die Laufzeit-Dokumentation zu vLLM beschreibt außerdem spezielle Arbeiten an Expertenparallelität, Lastverteilung und KDA-bezogenen Optimierungen. (github.com) Wir speichern jede getestete Kombination als unveränderliche Testmatrix, statt bei jedem Fehler mehrere Variablen gleichzeitig zu ändern.

Ein sinnvoller Testdatensatz enthält:

• eine Minimalanfrage ohne Werkzeuge,
• eine strukturierte Ausgabe mit festem Schema,
• einen einzelnen Werkzeugaufruf,
• mehrere aufeinanderfolgende Werkzeugaufrufe,
• einen Neustart der Inferenzinstanz,
• eine Anfrage mit dem tatsächlich erwarteten Kontextprofil.

So lässt sich unterscheiden, ob das Problem im Modell, in der Laufzeit oder in der Orchestrierung liegt.

Die erste Stunde: den vollständigen Inferenzkreislauf beweisen

Die erste Stunde ist keine Benchmark-Runde. Sie beantwortet nur die Frage, ob aus dem Gewichtspaket ein reproduzierbarer Dienst werden kann.

Schritt 1: Kaltstart protokollieren

Wir erfassen Startzeit, geladene Shards, verwendete Geräte, Parallelisierungsparameter, Speicherspitze und jede Warnung. Ein Dienst, der nur nach manuellen Änderungen an Umgebungsvariablen oder Kerneldateien startet, erhält noch keine Freigabe.

Schritt 2: Eine normale Antwort erzeugen

Eine kurze Anfrage muss vollständig beantwortet werden. Dabei werden Eingabe- und Ausgabetoken, Zeit bis zum ersten Token und die kontinuierliche Ausgaberate aus der Servicelogik oder einer nachvollziehbaren Messung übernommen. Geschätzte Werte aus der Benutzeroberfläche reichen nicht.

Schritt 3: Strukturierte Ausgabe erzwingen

Für interne Wissensdienste und Agenten ist eine gültige JSON-Struktur oft wichtiger als eine hohe Rohgeschwindigkeit. Wir prüfen Pflichtfelder, Datentypen, Fehlerbehandlung und das Verhalten bei absichtlich ungültigen Eingaben.

Schritt 4: Werkzeugaufruf ausführen

Der Test muss zeigen, dass das Modell ein Werkzeug korrekt auswählt, Argumente im vereinbarten Schema übergibt und nach der Rückgabe weiterarbeiten kann. Bei Kimi K3 ist die Behandlung des Denkverlaufs besonders relevant: Das offizielle Beispiel verlangt, die zurückgegebenen Denk- und Werkzeuginformationen in mehrstufigen Dialogen vollständig weiterzureichen. (github.com)

Schritt 5: Dienst kontrolliert neu starten

Nach einem kontrollierten Neustart darf kein manueller Zustand fehlen, der nicht in Container, Konfiguration oder Secrets-Management dokumentiert ist. Wenn ein Prozess nur nach dem Löschen temporärer Dateien oder dem händischen Zurücksetzen eines Kommunikationskanals wieder startet, ist das ein Warnsignal für die Betriebsphase.

Speicherprüfung: Formel als Filter, nicht als Kaufargument

Die grobe Gewichtsformel lautet:

Gewichtsspeicher ≈ Parameterzahl × Bits pro Parameter ÷ 8
Gesamtspeicherbedarf =
    Gewichte + KV-Cache + Laufzeit-Arbeitsbereich + Sicherheitsreserve

Diese Formel ist nützlich, um offensichtlich ungeeignete Varianten früh auszusortieren. Sie beantwortet aber nicht, ob ein Agentendienst stabil läuft. Bei einem MoE-Modell müssen die Expertengewichte über den Parallelisierungsverbund verteilt und für wechselnde Token-Routen erreichbar bleiben. Die aktive Expertenzahl senkt die Rechenarbeit pro Token, beseitigt aber nicht automatisch die Anforderungen an Gewichtsspeicher, Kommunikation und Lastverteilung.

Als Größenordnung nennt der offizielle Kimi-K3-Überblick ungefähr 2,8 Billionen Parameter, 104 Milliarden aktivierte Parameter und MXFP4-Gewichte. Die technische Dokumentation beschreibt zudem, dass die vollständigen Expertengewichte im GPU-Parallelbereich resident bleiben müssen, obwohl pro Token nur ein Teil der Experten ausgewählt wird. (github.com)

Für die Abnahme teilen wir den Speicher deshalb in vier Protokollspalten:

• Gewichte: dauerhaft belegter Speicher nach vollständigem Laden.
• KV-Cache: zusätzlicher Speicher bei den vorgesehenen Kontextlängen und parallelen Sitzungen.
• Arbeitsbereich: temporäre Puffer für Präfill, Dekodierung, Kommunikation und Kernel.
• Reserve: verbleibender Spielraum für Lastspitzen, Fehlerbehandlung und Systemprozesse.

Wenn die Lösung nur durch häufiges Auslagern in den Arbeitsspeicher, sehr kleine Kontexte oder einen nicht reproduzierbaren Patch startet, wird nicht erweitert. Wir markieren sie als Stoppsignal vor der Skalierung. Ein Dienst, der einen Einzelprompt gerade noch verarbeitet, kann unter Agentenlast trotzdem durch Warteschlangen, Kommunikationsspitzen oder KV-Cache-Wachstum unbrauchbar werden.

Erster Tag: die echte AI-Agent-Last messen

Am ersten Tag ersetzen wir synthetische Kurzprompts durch das reale Lastprofil der Organisation. Die Testanfragen sollten dieselbe Mischung aus Systemanweisungen, Wissenskontext, Werkzeugantworten und Ausgabelängen verwenden, die später im Betrieb erwartet wird.

Wir messen mindestens:

• Zeit bis zum ersten Token,
• kontinuierliche Ausgaberate,
• p95- und p99-Latenz,
• Wartezeit in der Warteschlange,
• Speicherspitze,
• Fehlerrate,
• erfolgreiche und abgebrochene Werkzeugaufrufe,
• effektiven Durchsatz erfolgreicher Aufgaben,
• Anzahl der Wiederholungen,
• Experten- und Kommunikationsauslastung, sofern die Laufzeit diese Daten liefert.

Die Teststufen werden schrittweise erhöht: zunächst eine einzelne Sitzung, anschließend mehrere parallele Anfragen, danach längere Kontexte und schließlich eine gemischte Agentenlast. Wir ändern nicht gleichzeitig Kontextgröße, Parallelität und Quantisierung. Sonst bleibt unklar, welcher Faktor die Schwanzlatenz verschlechtert.

Die offizielle Kimi-K3-Dokumentation weist auf die Abhängigkeit von erhaltenen Denk- und Werkzeugverläufen hin. Für Agenten bedeutet das: Ein Gateway, das diese Felder aus Platzgründen entfernt, kann die Qualität mehrstufiger Aufgaben beeinträchtigen, selbst wenn die reine Textgenerierung technisch funktioniert. (github.com)

Zusätzliche Vorsicht ist bei Fehlern unter Parallelität nötig. In einem öffentlichen Fehlerbericht zur Kimi-K3-Ausführung mit vLLM werden wiederkehrende Speicherzugriffsfehler unter gleichzeitiger Last beschrieben. Das ist kein allgemeiner Beweis gegen die Laufzeit, aber ein konkreter Hinweis darauf, dass Einzelanfragen keine ausreichende Freigabeprüfung darstellen. (github.com)

Erste Woche: Betrieb, Wiederherstellung und Personalaufwand

In der ersten Woche prüfen wir nicht mehr nur das Modell, sondern den Dienst als betriebliche Einheit. Dazu gehören Dauerlast, geplanter Prozessneustart, ungeplanter Knotenausfall, Modell-Rollback und ein vollständiger Neuaufbau aus dokumentierten Artefakten.

Die Abnahme ist erst belastbar, wenn folgende Fragen mit Logs beantwortet werden können:

• Wird ein Prozessausfall automatisch erkannt?
• Gibt es eine nachvollziehbare Warnung vor Speicherauslastung und Warteschlangenwachstum?
• Können fehlerhafte Modell- oder Laufzeitversionen zurückgerollt werden?
• Sind Rollen, Secrets und Zugriffe nach DSGVO-Grundsätzen begrenzt?
• Werden Eingabedaten, Werkzeugantworten und Protokolle mit einer klaren Aufbewahrungsregel behandelt?
• Kann ein anderes Teammitglied den Dienst ohne den ursprünglichen Entwickler rekonstruieren?
• Wie viele fehlgeschlagene Anfragen und manuelle Eingriffe entstehen pro Betriebstag?

Gerade bei internen Wissensdiensten wird Datenschutz häufig erst nach dem Hardwarekauf geprüft. Die Datenabgrenzung sollte vorher feststehen: Welche Dokumente dürfen den Dienst erreichen, welche Werkzeugaufrufe sind erlaubt, welche Protokollfelder müssen maskiert werden und wer darf Debugdaten einsehen? Für die interne Vorbereitung können wir die Datenschutz- und Sicherheitsinformationen von JexMac als Ausgangspunkt für die eigene Prüfliste heranziehen.

Die laufende Kostenrechnung umfasst daher nicht nur Rechenzeit. Einzubeziehen sind Speicher, Netzwerk, Ausweichkapazität, Überwachung, Bereitschaft, Versionspflege, Fehlersuche und die Zeit für wiederholte Abnahmen. Bei schwankender Nutzung kann ein dauerhaft reservierter Verbund einen großen Leerlaufanteil erzeugen, obwohl einzelne Spitzen technisch problemlos abgedeckt werden.

Die Abnahmebewertung für Kimi K3 und Qwen3.8

Wir vergeben je Tor eine Bewertung von 0 bis 2 Punkten:

• 0 Punkte: harte Bedingung nicht erfüllt; keine Beschaffung.
• 1 Punkt: grundsätzlich möglich, aber mit dokumentierter Einschränkung und Nachtest.
• 2 Punkte: reproduzierbar erfüllt und mit Log oder Testartefakt belegt.

Die Gesamtpunktzahl allein entscheidet nicht. Ein fehlender Lizenznachweis oder eine nicht beherrschbare Wiederherstellung kann nicht durch eine gute Antwortgeschwindigkeit ausgeglichen werden. Die Freigabeformel lautet:

Weiter zur Beschaffung:
alle fünf harten Tore bestanden
und kein 0-Punkte-Kriterium bei Datenschutz, Lizenz oder Wiederherstellung

Doppelbetrieb:
technische Tore bestanden, aber Nutzung, Version oder Kosten noch schwanken

Stopp:
Speicher nur mit Auslagerung, Agentenabläufe instabil,
Schwanzlatenz nicht erreichbar oder Betrieb nicht reproduzierbar

Für Qwen3.8 wird die Bewertung erst nach dem tatsächlichen Gewichtsdaten- und Lizenzrelease ausgefüllt. Bis dahin kann das Team die Testumgebung vorbereiten, aber keine seriöse Mindesthardware aus Community-Prognosen ableiten. Für Kimi K3 sollten die Werte aus dem offiziellen Repository, der verwendeten Laufzeit und den eigenen Logs zusammengeführt werden; die Modellarchitektur allein ist keine Leistungszusage.

Was gegen einen sofortigen Hardwarekauf spricht

Eine langfristige Eigenbeschaffung hat gegenüber einer kurzfristigen Testumgebung drei reale Nachteile. Erstens bindet sie Kapital, bevor Kontextprofil, Parallelität und tatsächliche Auslastung bekannt sind. Zweitens verlängert sie die Fehlersuche, weil Hardware-, Treiber- und Frameworkprobleme gleichzeitig eingeführt werden. Drittens bleiben Leerlauf, Bereitschaft und Wiederherstellungskosten beim eigenen Team, auch wenn das Modell nur unregelmäßig genutzt wird.

Ein API-Doppelbetrieb ist ebenfalls nicht automatisch besser: Datenschutz, Datenstandort, variable Nutzungskosten und Abhängigkeit von externen Verfügbarkeiten müssen geprüft werden. Er kann aber als Referenz dienen, wenn dieselben Agentenfälle parallel gegen die eigene Instanz und den API-Endpunkt laufen.

Für die Zwischenphase ist eine isolierte, zeitlich begrenzte Remote-Umgebung oft der sauberste Weg. Sie erlaubt es, Kimi K3 oder später Qwen3.8 mit realen Lasten zu prüfen, ohne die endgültige Hardwareentscheidung vorwegzunehmen. Hinweise zur Vorbereitung und zu bekannten Kimi-K3-Laufzeitfehlern haben wir in unserem Beitrag zum Reproduzieren von Kimi-K3-vLLM-Fehlern gebündelt.

Signierte Entscheidung nach der ersten Woche

Am Ende der Abnahme erstellen wir eine unterschriebene Entscheidungstabelle mit folgenden Feldern:

• Modell und exakte Version,
• Gewichtsdatenquelle und Lizenznachweis,
• getestete Laufzeit und Konfiguration,
• verantwortliche Person,
• Link zu Logs und Messartefakten,
• Datum der letzten Prüfung,
• erkannte Einschränkungen,
• Auslöser für eine erneute Bewertung,
• Entscheidung: Selbsthosting, Doppelbetrieb oder Stopp.

Bei vollständig bestandenen Toren kann die langfristige Beschaffung vorbereitet werden. Bei stark schwankender Nutzung oder schnell wechselnden Modellversionen bleibt der Doppelbetrieb vernünftig. Wenn die Dienstqualität nur durch nicht wartbare Patches, übermäßiges Auslagern oder manuelle Eingriffe erreicht wird, sollte das Team die Investition beenden und nicht durch weitere Geräte retten wollen.

Häufige Fragen zur Abnahme

Reicht ein erfolgreicher Ladevorgang von Kimi K3 für den Produktivbetrieb aus?

Nein. Der Ladevorgang bestätigt nur die technische Startfähigkeit einer bestimmten Version. Für die Freigabe müssen strukturierte Antworten, Werkzeugaufrufe, reale Kontextprofile, parallele Anfragen, Neustarts und Wiederherstellung funktionieren. Besonders bei großen MoE-Modellen können Speicher- und Kommunikationsfehler erst unter gleichzeitiger Last auftreten. Ein Einzelprompt ist deshalb ein Startsignal, aber kein Produktionsnachweis.

Welche Voraussetzungen sollten vor den Qwen3.8-Gewichten vorbereitet werden?

Vorbereitet werden sollten Container, Treiber, Protokollierung, Zugriffskontrollen, Testdaten, Agentenwerkzeuge und ein reproduzierbares Messverfahren. Außerdem sollte feststehen, wie Prüfsummen, Modellversionen und Lizenzdateien archiviert werden. Die konkrete Downloadquelle, Lizenz und Framework-Unterstützung müssen nach der offiziellen Veröffentlichung erneut geprüft werden. Vorher sind Aussagen zu Mindesthardware oder Quantisierung lediglich unbestätigte Community-Hinweise.

Welche Kennzahlen sind bei einem großen MoE-Modell für den Start wichtig?

Neben Zeit bis zum ersten Token und Ausgaberate zählen p95- und p99-Latenz, Warteschlangenzeit, Speicherspitze, Fehlerrate und erfolgreicher Agenten-Durchsatz. Werkzeugaufrufe müssen auf Schemafehler, Wiederholungen und Abbrüche geprüft werden. Wenn die Laufzeit Angaben zur Expertenauslastung oder Kommunikation liefert, gehören auch diese Messwerte in das Protokoll. Die reine Zahl aktivierter Parameter genügt nicht für eine Kapazitätsentscheidung.

Wie lange sollte ein Selbsthosting-Stresstest vor dem Hardwarekauf laufen?

Ein einzelner Durchlauf ist zu kurz. Sinnvoll ist eine zeitliche Staffelung aus Kaltstart, erstem Tag mit realen Agentenfällen und erster Woche mit Dauerlast, Neustarts, Rollback und Neuaufbau. Die konkrete Länge hängt vom Geschäftsfall ab. Entscheidend sind reproduzierbare Fehlerbilder, stabile Messwerte und dokumentierte Eingriffszeiten. Erst wenn diese Daten vorliegen, sollte die Beschaffung auf eine dauerhafte Auslastung hochgerechnet werden.

Wann ist der Wechsel von Selbsthosting zu einer API vernünftig?

Der Wechsel ist vernünftig, wenn die eigene Auslastung stark schwankt, die Schwanzlatenz trotz Erweiterung nicht genügt oder das Team dauerhaft mehr Zeit in Betrieb und Fehlerbehebung als in den eigentlichen Anwendungsfall investiert. Auch fehlende Lizenzklarheit, unzureichende DSGVO-Kontrollen und nicht reproduzierbare Patches sprechen gegen eine weitere Eigenbeschaffung. Ein zeitweiser Doppelbetrieb liefert dabei bessere Vergleichsdaten als eine reine Kostenannahme.

Bevor Sie langfristige Rechenkapazität kaufen, empfehlen wir daher eine getrennte Abnahmeumgebung mit Ihrem Modell, Framework, Parallelitätsprofil und gewünschten Testzeitraum. JexMac kann dafür eine passende Remote-Umgebung zur Validierung vermitteln; die konkrete Auswahl sollte sich an den nachweisbaren Testanforderungen orientieren, nicht an einer pauschal versprochenen Konfiguration. Den nächsten Schritt können Sie über die Anfrage für eine passende JexMac-Testumgebung starten.

FAQ