Es lief ab Tag eins. Und war dennoch unverkäuflich.

Kimi K3 auf acht AMD Instinct MI350X: 317 Token pro Sekunde sind kein Dienst, sondern ein Lebenszeichen. Heute liefert dieselbe Anlage 33.168 — ohne eine einzige zusätzliche Karte, bei einer Million Token Kontext mit geprüfter inhaltlicher Korrektheit. Was dazwischen liegt, stand in keiner Anleitung.

Erfahrungsbericht · Juli 2026 · ADVISORI FTC GmbH Transformation. Innovation. Sicherheit.

Teil 1 — Für Entscheider

Die Lücke, über die selten gesprochen wird

Ein neues Spitzenmodell erscheint. Die Gewichte sind frei verfügbar, die Inferenz-Software unterstützt es „ab Tag eins„, die Ankündigungen nennen beeindruckende Zahlen. Der naheliegende Schluss: einspielen, starten, anbieten.

Der konkrete Fall: Kimi K3 — 2,8 Billionen Parameter, veröffentlicht im Juli 2026 — auf acht AMD Instinct MI350X.

Das Modell lief am ersten Tag tatsächlich. Es lieferte 317 Token pro Sekunde.

Damit lässt sich kein Dienst anbieten. Ein einzelner Nutzer mit einem längeren Dokument hätte die Anlage für Minuten belegt; zu einem Preis, der jeden Vergleich verloren hätte. Der Zustand „läuft„ war nicht verkäuflich — er war ein Lebenszeichen der Software, kein Leistungswert. Von den Stellschrauben, die den Unterschied machten, war ein Teil in keiner Dokumentation erwähnt, ein anderer Teil auf unserer Hardwareplattform nachweislich defekt: Codepfade, die dort noch nie ausgeführt worden waren, Geräteprüfungen mit fest verdrahteten Konstanten eines anderen Herstellers — und ein Übersetzungsflag, das die aktuelle Treiberversion nicht mehr kennt und das trotzdem als erfolgreich gemeldet wurde, während es unbrauchbaren Maschinencode erzeugte.

Heute liefert dieselbe Anlage, dasselbe Modell, dieselben Gewichte:

Token pro Sekunde, Gesamtdurchsatz. Die ersten beiden Etappen aus einem internen Vergleichsmaßstab, die beiden hervorgehobenen aus dem Standard-Lasttool des Inferenz-Servers.

Was 33.168 Token pro Sekunde an Menge bedeutet

Diese Mengen sind der gemessene Durchsatz auf die Zeit hochgerechnet — sie beschreiben die Kapazität der Anlage, nicht eine Auslastungsprognose. Zum Vergleich: Ein umfangreiches Sachbuch entspricht rund einer Viertelmillion Token. Die Anlage verarbeitet diese Menge in etwa acht Sekunden und hält dieses Tempo über 128 parallele Anfragen.

DIE KERNAUSSAGE DIESES BERICHTS
Zwischen „läuft„ und „trägt einen Dienst“ liegt bei einem neu veröffentlichten Modell selbst auf marktführender Hardware ein Vielfaches an Leistung. Diese Differenz ist nicht durch Hardware zu kaufen. Sie entsteht durch Detailarbeit an der Software, die das Modell ausführt — bis hinunter in den Quelltext der Inferenz-Engine und der Kernel-Bibliothek des Hardwareherstellers.

Und das bei einer Million Token Kontext

Der Durchsatz ist die eine Hälfte. Die andere ist die Kontextlänge — und sie ist der Grund, warum diese Aufstellung überhaupt gebaut wurde.

Eine Anfrage über 1.024.134 Token wird angenommen und in rund elf Minuten vollständig verarbeitet — ohne Speicherfehler, ohne Neustart des Dienstes. Wird das Fenster überschritten, lehnt der Dienst sauber mit einer regulären Fehlermeldung ab statt abzustürzen.

Entscheidend ist die zweite Frage: Findet das Modell darin noch, was es finden soll? Wir prüfen das mit einem Nadeltest — eine einzelne Information wird mitten in einen sehr langen Text eingebettet, und das Modell muss sie am Ende wiedergeben. Das System besteht diesen Test über das volle Millionenfenster. Bei 704.131 Token liegt eine automatisierte Serie vor: zehn von zehn Läufen fehlerfrei.

WARUM DIESE UNTERSCHEIDUNG ZÄHLT
„Eine Million Token Kontext„ ist eine Angabe, die viele Anbieter machen. Sie bedeutet zunächst nur, dass die Anfrage angenommen wird. Ob das Modell eine Information aus der Mitte eines so langen Textes noch findet, ist eine zweite, unabhängige Frage — und die beantwortet man nur durch Messen. Wir prüfen beides und weisen beides nach.

Um welche Größenordnung von Arbeit es geht

Zur Einordnung: Kimi K3 hat 2,8 Billionen Parameter in Mixture-of-Experts-Architektur, davon je Token rund 104 Milliarden aktiv, hybride Aufmerksamkeit aus 69 linearen und 24 klassischen Schichten, Gewichte in MXFP4 und ein Kontextfenster von einer Million Token. Es läuft bei uns verteilt über acht AMD Instinct MI350X mit je 288 GB Speicher, dazu spekulative Dekodierung.

Jede dieser Eigenschaften vervielfacht die Zahl der Codepfade, die zusammenpassen müssen — und verringert die Wahrscheinlichkeit, dass genau diese Kombination vor uns jemand betrieben hat.

Der Vergleich, der die Zahl überprüfbar macht

Moonshot AI, der Hersteller des Modells, betreibt für Kimi K3 eine eigene API. Deren Geschwindigkeit wird unabhängig gemessen und öffentlich veröffentlicht (Artificial Analysis): 32 Token pro Sekunde im Einzelstrom.

Beides ist dieselbe Größe: die Geschwindigkeit, mit der ein einzelner Nutzer seine Antwort erhält. Wir sind auf dieser Kennzahl 2,3-mal schneller als der Hersteller des Modells selbst — und zwar auf europäischer Infrastruktur, auf Hardware, die nicht die des Marktführers ist.

Das ist der Punkt, an dem die Rechnung nachprüfbar wird: Der Vergleichswert stammt nicht von uns.

Was das wirtschaftlich bedeutet

Wir betreiben Kimi K3 — ein Modell der Billionen-Parameter-Klasse — auf souveräner Infrastruktur in Europa, auf AMD-Beschleunigern, ohne Abhängigkeit von US-Hyperscalern. Der Leistungsgewinn stammt vollständig aus Softwarearbeit — die Hardware ist unverändert. Genau diese Art von Betrieb — offene Spitzenmodelle wie Kimi K3, souverän gehostet in europäischen Rechenzentren oder On-Premise — bieten wir als lokale KI und Sprachmodelle für Unternehmen an.

Allein die jüngste Optimierungsrunde brachte 36 Prozent mehr Durchsatz bei realistischer Kundenlast und senkte die Wartezeit auf die erste Antwort um 76 Prozent — die Leistung von rund 1,4 Servern aus einem.

DER EHRLICHE ZUSATZ
Der Gewinn ist Kapazität, kein automatischer Umsatz. Er materialisiert sich dort, wo Nachfrage vorhanden ist, die vorher nicht bedient werden konnte. Die verkürzte Antwortzeit wirkt dagegen sofort — und für jeden Nutzer spürbar.

Woher solche Reserven kommen

Drei Beobachtungen, die sich in dieser wie in früheren Untersuchungen wiederholen:

Voreinstellungen sind Kompromisse. Inferenz-Software muss auf einer breiten Palette von Modellen und Beschleunigern lauffähig sein. Die Standardwerte sind darauf ausgelegt, überall zu funktionieren — nicht darauf, irgendwo optimal zu sein. Bei ungewöhnlichen Kombinationen, und jede souveräne Aufstellung ist ungewöhnlich, liegt dazwischen viel Raum.

Die wirksamsten Schalter stehen in keiner Anleitung. Unser größter Einzelsprung kam von zwei Umgebungsvariablen, die in keiner Dokumentation, keinem Beispiel und keiner Referenzkonfiguration auftauchen. Gefunden wurden sie durch das Lesen des Quelltexts. Ohne eine davon verwarf die Software ein Drittel ihrer Rechenarbeit.

Nicht-marktführende Hardware wird seltener begangen. Codepfade, die auf einer Plattform selbstverständlich funktionieren, sind auf der anderen mitunter nie ausgeführt worden. Wir haben in der Inferenz-Engine und der Kernel-Bibliothek des Hardwareherstellers mehrere solcher Stellen gefunden und korrigiert — darunter einen Kernel, der auf unserer Plattform überhaupt nie geladen wurde.

Was das für Ihre Planung heißt

1. Rechnen Sie die Inbetriebnahme mit ein. „Unterstützt ab Tag eins„ beschreibt Lauffähigkeit, nicht Wirtschaftlichkeit. Zwischen beidem liegt qualifizierte Ingenieursarbeit — in unserem Fall Wochen.
2. Messen Sie mit Ihrem Lastprofil. Ein Durchsatzwert aus einem Standard-Benchmark sagt wenig über Anfragen mit langen gemeinsamen Vorgaben — und genau die dominieren den Unternehmenseinsatz.
3. Bewerten Sie Optimierung gegen Zukauf. Ein Vielfaches an Leistung aus dem Bestand ist häufig günstiger und deutlich schneller verfügbar als zusätzliche Hardware.
4. Verlangen Sie Nachweise, keine Einzelmessungen. Ein einzelner Messwert trägt keine Entscheidung. Dazu mehr im zweiten Teil.

Teil 2 — Für Technik und Architektur

Vier Schichten zwischen Modellgewichten und Antwort. An dreien mussten wir eingreifen.

Der Stapel, und warum er die Schwierigkeit erklärt

Zwischen den Modellgewichten und einer ausgelieferten Antwort liegen mindestens vier Schichten: das Modell selbst, der Inferenz-Server, die Kernel-Bibliothek des Hardwareherstellers und der Treiber. Jede wird von einem anderen Team entwickelt, in einem anderen Rhythmus veröffentlicht und primär gegen eine andere Kombination getestet.

Bei einer verbreiteten Kombination — bekannte Architektur, marktführende Beschleuniger, mittlere Kontextlänge — hat jemand diesen Pfad vor Ihnen begangen. Bei einer souveränen Aufstellung mit alternativer Hardware, sehr langem Kontext und einer neuen hybriden Architektur ist das seltener der Fall.

Dann findet man Dinge, die niemand versteckt hat, die aber auch niemand vorher gebraucht hat.

Was tatsächlich zu tun war

Unsere Eingriffe lassen sich in vier Kategorien ordnen. Sie sind übertragbar — wer eine ähnliche Aufstellung betreibt, wird Verwandtes finden.

Die Stellschrauben, um die es geht

Der folgende Auszug nennt die Ebenen, auf denen wir gearbeitet haben. Er ist absichtlich unvollständig: Die wirksamen Werte und ihre Kombination veröffentlichen wir nicht. Wer die Namen kennt, weiß aber, wo zu suchen ist.

Auf Ebene der Startparameter

Auf Ebene der Umgebungsvariablen

Zwei Variablen brachten den größten Einzelsprung. Sie tauchen in keiner Anleitung, keinem Beispiel und keiner Referenzkonfiguration auf; gefunden haben wir sie durch das Lesen von environ.py, mxfp4.py und k3_gemm_ar.py im Quelltext.

Ohne eine davon füllte die Software eine interne Dimension der Mixture-of-Experts-Schichten auf 512 statt auf 384 auf. Die Folge: ein Drittel jeder Matrixmultiplikation wurde berechnet und verworfen — und der Zwischenspeicher für den Kontext blieb um den Faktor sechs kleiner als möglich.

Auf Ebene des Quelltexts

WAS HIER BEWUSST FEHLT
Die Werte, die Kombination und die Reihenfolge. Ein Parametername sagt, wo zu suchen ist; welcher Wert auf welcher Hardware mit welchem Modell trägt, ist das Ergebnis systematischer Messung. Bei zwei der genannten Parameter gilt zudem: in der falschen Kombination gesetzt, kosten sie Durchsatz oder verhindern den Start.

Neue Architekturen brauchen neue Mechanismen

Moderne Modelle kombinieren mehrere Aufmerksamkeitsverfahren in einem Netz. Das hat eine Folge, die man dem Betrieb nicht ansieht: Optimierungen, die für ältere Architekturen selbstverständlich sind, greifen dort nicht automatisch.

Konkret betrifft das die Wiederverwendung gemeinsamer Anfragenanfänge — den wichtigsten Hebel überhaupt, wenn Kundenanfragen lange, wiederkehrende Vorgaben teilen. Ein Teil der Modellschichten führt einen fortlaufenden Zustand, der sich aus dem üblichen Zwischenspeicher nicht rekonstruieren lässt. Ohne einen erweiterten Mechanismus fällt die Wiederverwendung für diese Schichten aus — und damit für das gesamte Modell.

Der Mechanismus existiert. Er ist nur nicht voreingestellt, weil er ausschließlich für bestimmte Architekturen sinnvoll ist. Bei uns brachte sein Einschalten 36 Prozent mehr Durchsatz und eine Viertelung der Wartezeit.

Wie wir Zahlen belastbar machen

Jede Zahl in diesem Bericht musste erst verlässlich gemacht werden.

Eine Optimierung ist erst dann eine, wenn sie nachweisbar ist. Unser Messverfahren arbeitet deshalb mit:

• Drei Messläufen je Variante statt eines, mit echtem Median
• Korrektheitsprüfung bei jeder Messung — ein Verfahren, das Tempo bringt und die Antwortqualität kostet, wird nicht freigegeben. Geprüft wird unter anderem, ob das Modell eine gezielt versteckte Information in einem Kontext von 336.000 Token noch findet
• Getrennter Variation der Faktoren — solange zwei Dinge gemeinsam wechseln, ordnet jede Messung die Wirkung möglicherweise dem falschen zu
• Vorab festgelegten Freigabekriterien, damit nicht im Nachhinein entschieden wird, was als Erfolg gilt

Warum eine Messreihe kein Luxus ist

Vor der Umsetzung haben wir dieselbe Konfiguration dreimal gemessen, jeweils mit frisch gestarteter Umgebung. Das Ergebnis war doppelt nützlich.

Erstens bestätigte es die Änderung: dreimal die volle Leistung, dreimal bestandene Qualitätsprüfung, kein Auftreten des historischen Fehlerbildes.

Zweitens vermaß es die Streuung: Die drei Läufe lagen knapp vier Prozent auseinander. Damit ist definiert, wie groß ein Unterschied sein muss, um als Effekt zu gelten. Ein anderes Softwarepaket hatte in einer Einzelmessung 4,5 Prozent Vorteil gezeigt — dieser Wert liegt innerhalb der Streuung und wurde deshalb nicht als Ergebnis gewertet.

DER METHODISCHE KERN
Eine Messreihe misst nicht nur den Effekt. Sie misst auch, wie groß ein Effekt sein muss, um überhaupt einer zu sein. Ohne diese Information ist jede Optimierung unter zehn Prozent eine Vermutung — und die meisten Optimierungen liegen unter zehn Prozent.

Nachhaltigkeit der Eingriffe

Alle Änderungen liegen als reproduzierbare Bauvorschrift vor.

Wer Fremdsoftware ändert, übernimmt Verantwortung für jede künftige Aktualisierung. Unsere Änderungen liegen deshalb nicht als veränderte Dateien vor, sondern als Differenzen mit exakter Verankerung. Passt eine Verankerung nach einem Update nicht mehr, bricht der Bauvorgang — nicht der Betrieb. Eine Selbstprüfung stellt zusätzlich sicher, dass die Änderungen im tatsächlich geladenen Code angekommen sind.

Das ist der Unterschied zwischen einer Anpassung, die man pflegen kann, und einer, die irgendwann unbemerkt veraltet.

Was wir daraus mitnehmen

1. Der größte Gewinn lag in undokumentierten Details. Nicht in der Hardware, nicht im Modell, sondern in Schaltern und Codepfaden, die man nur durch Lesen des Quelltexts findet. Ein einzelner nicht gesetzter Schalter kostete ein Drittel jeder Matrixmultiplikation.
2. Nicht-marktführende Hardware verlangt eigene Arbeit — und lohnt sie. Wir erreichen auf europäischer, souveräner Infrastruktur das 2,3-fache dessen, was die API des Modellherstellers liefert.
3. Zuordnung schlägt Optimierung. Solange mehrere Faktoren gemeinsam wechseln, weiß man nicht, welcher wirkt. Erst die getrennte Messung machte die entscheidende Erkenntnis der letzten Runde sichtbar.
4. Negative Ergebnisse gehören dokumentiert. Von den zuletzt untersuchten Ansätzen ließen sich mehrere mit Messwerten ausschließen. Das verkleinert den Suchraum für alle folgenden Runden — und ist damit ebenso wertvoll wie ein Erfolg.

ADVISORI FTC GmbH betreibt souveräne KI-Infrastruktur für Unternehmen und öffentliche Auftraggeber in Europa. Dieser Bericht beschreibt Vorgehen und Ergebnisse einer Optimierungsuntersuchung; Konfigurationsdetails und Quelltextänderungen sind nicht Gegenstand dieser Veröffentlichung.