Baseten bietet ab Tag 0 Support für Kimi K3 auf unseren Model APIs. Wir möchten Moonshot AI dafür danken, dass sie uns die Kimi-K3-Gewichte für den frühen Zugriff zur Verfügung gestellt haben, sowie den Teams von Inferact und RadixArk für ihre Zusammenarbeit während des gesamten Entwicklungsprozesses.
Kimi K3 ist ab heute auf Baseten Model APIs mit Vision-Input und vollem 1-Million-Token-Kontextfenster verfügbar.
Kimi K3 ist ein neues offenes Frontier-Modell. Mit 2,8 Billionen Parametern ist es deutlich größer als jedes vorherige offene Modell und bringt eine Reihe von Herausforderungen für den Aufbau einer leistungsfähigen Inferenz-API mit sich. Neue architektonische Techniken ermöglichen es Kimi K3, die Billionen-Parameter-Schwelle früherer offener Frontier-Modelle zu überschreiten:
- Kimi Delta Attention (KDA) und Attention Residuals (AttnRes) als skalierbares Rückgrat der Kimi-Architektur.
- Extrem spärliche Experten, von denen jeweils nur 16 von 896 Experten aktiv sind, organisiert mittels Stable LatentMoE.
- Ein neuer Vision-Encoder zur Verarbeitung von Bildeingaben und zur Abbildung visueller Informationen in den latenten Raum.
Dieser Artikel beschreibt die technische Arbeit, die erforderlich war, um Kimi K3s neuartige Modellarchitektur und die riesigen Gewichte rechtzeitig zum Starttag in großem Maßstab auszuführen.
Meilenstein 1: Ein Token generieren
Nachdem wir von Moonshot AI frühzeitig Zugang zu den Kimi-K3-Gewichten erhalten hatten, bestand unsere erste Priorität darin, das Modell überhaupt zum Laufen zu bringen.
Um die ersten Token von Kimi K3 zu generieren, waren folgende Schritte erforderlich:
- Bereitstellung der Hardware: Angesichts der Größe von Kimi K3 haben wir uns entschieden, das Modell auf NVIDIA GB300 NVL72-Systemen auszuführen.
- Laden der Gewichte: In MXFP4 betragen die Kimi-K3-Gewichte über 1,4 TB Daten.
- Inbetriebnahme einer Inferenz-Engine: Wir haben mit den Teams hinter vLLM und SGLang zusammengearbeitet, um Vorabversionen der Inferenz-Engines für Kimi K3 auszuführen.
Beim Aufbau von APIs ab Tag 0 besteht ein früher Schritt oft darin, die Gewichte in NVFP4 zu portieren, um die Leistung und Kompatibilität mit NVIDIA Blackwell und unserem Inferenz-Stack zu verbessern. Kimi K3 verwendet jedoch native MXFP4-Gewichte mit MXFP8-Aktivierungen, und wir konnten diese Gewichte direkt verwenden.
Mit den Gewichten in der Hand haben wir eng mit Inferact (vLLM) und RadixArk (SGLang) zusammengearbeitet. Bevor wir Kimi K3 auf dem Baseten Inference Stack ausführen konnten, mussten wir in Zusammenarbeit mit den führenden Open-Source-Inferenz-Engines eine Basislinie etablieren.
Die Unterstützung eines Modells in einer Inferenz-Engine zu integrieren, ist nicht trivial. Es erfordert die Implementierung von zentralem Modellcode, optimierten Kernels für neue Architekturen wie KDA sowie den Aufbau von Frontend-Kompatibilität für Kimi K3 – von der Tokenisierung bis zum Tool Calling.
Das Early-Access-Image von vLLM für NVIDIA Blackwell GPUs half uns, grundlegende Funktionsvollständigkeit zu erreichen, erste Evaluierungen zu bestehen und ein Basis-Leistungsziel festzulegen. Diese Arbeit zur Anpassung an die architektonischen Merkmale von Kimi K3 wie KDA, AttnRes und Stable LatentMoE bildete eine solide Grundlage, auf der wir aufbauen konnten. Wir haben auch umfangreiche Validierungen der vLLM-Inferenz-Engine für Kimi K3 durchgeführt und basierend auf unserer Arbeit Beiträge zur Open-Source-Engine geleistet.
Das Early-Access-Image von SGLang bot eine Referenz für schnelles, zuverlässiges Serving von Kimi K3. SGLang hat eine Geschichte der starken Unterstützung für Vision-Language-Modelle, und Kimi K3 ist keine Ausnahme. Mit dem Team von RadixArk konzentrierten wir uns auf Frontend-Kompatibilität und Kernel-Optimierung, und unser Engineering-Team trug Fehlerbehebungen für Frontend-Probleme im Zusammenhang mit Tool-Call-Handling und strukturierten Ausgaben bei, um die Release-Bereitschaft sicherzustellen.
Vielen Dank an die Teams von Inferact und RadixArk für die gemeinsame Arbeit während des gesamten Vorschauzeitraums. Diese Arbeit bildete sowohl eine wesentliche Grundlage für unsere Kimi-K3-API als auch eine Gelegenheit, einen Beitrag zur Open-Source-Community zu leisten.
Meilenstein 2: Die Inferenz-Engine validieren
Kimi K3 ist das intelligenteste offene Modell, das es je gab. Es ist entscheidend, diese Intelligenz während der Inferenz tatsächlich zu liefern.
Kimi-K3-Benchmarks zeigen eine starke Leistung bei agentischen Aufgaben, die von präzisen Tool-Aufrufen und qualitativ hochwertigen Modellausgaben abhängen.
Die Qualitätsvalidierung kann auf verschiedenen Strenge-Ebenen erfolgen. Einfache Plausibilitätschecks, wie das Aufrufen des Modells mit einem bekannten Prompt oder das Ausführen eines leichten Benchmarks wie gsm8k oder BFCL und die Überprüfung, ob die Ergebnisse innerhalb der Fehlertoleranz liegen, sind während des Entwicklungsprozesses nützliche Kontrollpunkte, um sicherzustellen, dass alles im Rahmen bleibt. Die Veröffentlichung einer öffentlichen API erfordert jedoch strengere Benchmarks.
Das Team von Moonshot AI betreibt Kimi Vendor Verifier, der Inferenz-Anbietern hilft, eine genaue und hochwertige Bereitstellung der Modellgewichte sicherzustellen. Das Bestehen des Kimi Vendor Verifier war ein wichtiger früher Meilenstein in unserer API-Entwicklung und ein äußerst hilfreiches Werkzeug während des gesamten Entwicklungsprozesses.
Es gibt viele Gelegenheiten, beim Serving von Modellen Fehler zu machen. Während die gängige Erzählung besagt, dass Quantisierung die Wurzel aller Qualitätsprobleme sei, trifft das in der Praxis nicht zu. Die meisten Qualitätsprobleme, insbesondere bei Tool-Calling und anderen strukturierten Modellverhalten, stammen vom Frontend des Inferenz-Servers.
Das Frontend sitzt vor der Inferenz-Engine und verarbeitet die Ein- und Ausgaben.
Das Frontend ist deterministischer Code, der auf der CPU vor der Inferenzschleife läuft. Es ist dafür verantwortlich, Eingaben entgegenzunehmen und Ausgaben zurückzugeben. Das Frontend muss:
- Die API betreiben und validieren
- Prompts tokenisieren und Ausgaben detokenisieren
- Die Chat-Vorlage rendern
- Reasoning und Tool-Aufrufe parsen
- Die Ausgabe in ChatCompletions, Messages oder ein anderes Standardformat formatieren
Diese Aufgaben unterscheiden sich von Modell zu Modell, und es kommt nur allzu oft vor, dass beim schnellen Aufbau von Tag-0-Support Fehler und Leistungseinbußen eingeführt werden. Robuste Checks wie der Kimi Vendor Verifier bewerten die Leistung über häufige Fehlermodi wie Tool-Calling hinweg, um sicherzustellen, dass das Modell sowohl in der Inferenzschleife als auch auf der API-Oberfläche mit hoher Genauigkeit bedient wird.
Während der weiteren Entwicklung der API haben wir den Kimi Vendor Verifier bei späteren Meilensteinen eingesetzt, um sicherzustellen, dass Leistungsoptimierungen keine Fehler eingeführt haben, die die Genauigkeit beeinträchtigen.
Meilenstein 3: Die richtige Konfiguration finden
Inferenz-Engines bieten eine breite Palette von Konfigurationsoptionen, um die Leistung für verschiedene Modelle, Hardware, Traffic-Formen und Latenz-/Durchsatz-Kompromisse abzustimmen. Diese Optionen und die Wechselwirkungen zwischen ihnen sind komplex.
Um die richtige Konfiguration zu finden, führen wir einen Durchlauf über verschiedene Optionen durch, wie Tensor Parallelism (TP) und Expert Parallelism (EP)-Einstellungen, Attention Data Parallelism (ADP)-Umschaltung, Batch-Größen, spekulative Decoder-Draft-Längen, Caching-Intervalle für lineare Schichten, Routing-Parameter und Inferenz-Engine-Einstellungen.
Tensor Parallelism und Expert Parallelism verteilen große Modelle über mehrere GPUs.
Zum Ausführen von Kimi K3 sind acht NVIDIA GB300 GPUs erforderlich, um die enormen Modellgewichte in den VRAM zu bekommen. Im Gegensatz zu vielen anderen NVIDIA GPUs, die in Achter-Knoten geliefert werden, kommen GB300s jedoch in Vierer-Knoten. Dies scheint zunächst die möglichen Parallelisierungsstrategien einzuschränken – Tensor Parallelism ist traditionell nicht über Knoten hinweg möglich, da langsame Interconnects teure All-Reduce-Operationen zu einem Engpass für die Inferenz machen – aber das GB300 NVL72-System hat einen ausreichend schnellen Interconnect zwischen den Knoten, sodass wir Inferenz mit Tensor Parallelism und Expert Parallelism über Knoten hinweg ausführen können.
Diese Konfigurationsentscheidungen sind abhängig von der Wahl der Inferenz-Engine. Ingenieure arbeiteten parallel daran, vLLM, SGLang und unsere eigene hauseigene Engine zu konfigurieren, tauschten Erkenntnisse aus und wandten die Erkenntnisse auf unsere eigene Inferenz-Engine an, während sie gleichzeitig PRs zu den Open-Source-Engines beitrugen.
Meilenstein 4: Leistung optimieren
Sobald ein Modell mit einer optimierten Konfiguration läuft, gibt es eine Vielzahl von Inferenz-Engineering-Techniken, die die Latenz, den Durchsatz oder eine Kombination davon erheblich verbessern können. Für Modell-APIs betrachten wir in der Regel:
- Spekulation: Verwendung eines kleinen Draft-Modells zur Vorhersage mehrerer Token, die dann im Rahmen des Forward-Passes validiert werden. Diese verlustfreie Optimierung verbessert die TPS pro Benutzer beim Decode.
- Disaggregation: Verschieben von Prefill und Decode auf separate Worker. Dies verhindert Ressourcenkonflikte, ermöglicht eine gezieltere Konfiguration und macht das Verhältnis von Prefill- zu Decode-Berechnung anpassbar an den Traffic.
- Caching: Zuweisen von Speicher zum Speichern von KV-Cache- und KDA-Zuständen zwischen Anfragen, sodass nachfolgende Anfragen mit gemeinsamen Präfixen in Eingabesequenzen das Prefill ganz oder teilweise überspringen können. Dies verbessert TTFT und den Gesamtsystemdurchsatz.
Dass das Modell aus früheren Meilensteinen läuft, ist eine Voraussetzung für diese Arbeit. Beispielsweise erfordert das Trainieren eines Spekulator-Modells mit einer Methode wie DSpark, DFlash oder EAGLE-3 die Generierung von versteckten Zuständen aus dem Zielmodell (Kimi K3) unter Verwendung einer Reihe von Prompts, die der erwarteten realen Nutzung ähneln. Dazu benötigen Sie eine einigermaßen durchsatzstarke Instanz des Modells, die live läuft und Inferenz ausführt.
Eine neuartige Leistungsoptimierung betraf den Tokenizer. Jahrelang konnten Inferenz-Ingenieure die Tokenisierungszeit als vernachlässigbar betrachten. Bei einem Modell wie Kimi K3 mit langen Eingabesequenzen und hohen KV-Cache-Wiederverwendungsraten ändert sich dies jedoch tatsächlich, und die Tokenisierung kann einen erheblichen Einfluss auf die Prefill-Zeit haben, da die Tokenisierung unabhängig davon erfolgen muss, ob die Eingabesequenz ein Cache-Treffer ist oder nicht.
Wir haben einen benutzerdefinierten Tokenizer entwickelt, der bei langen Eingabesequenzen bis zu 18x schneller ist als tiktoken, und ihn zusammen mit unserer Kimi-K3-API ausgerollt.
Basetenkenizer ist bei langen Eingabesequenzen bis zu 18x schneller als Tiktoken.
Es gibt noch mehr Arbeit an der Leistung. Bei jedem Modell, das wir starten, investieren wir in den Wochen nach der Veröffentlichung weiterhin in Latenz- und Durchsatzoptimierungen. Angesichts der beispiellosen Größe von Kimi K3 gibt es eine riesige Angriffsfläche für weitere Leistungsverbesserungen bei jeder wichtigen Inferenz-Engineering-Technik und jeder Schicht des Inferenz-Stacks.
Meilenstein 5: In großem Maßstab bereitstellen
Die branchenweite Begeisterung für Kimi K3 ist enorm. Dies wird von einer großen Nachfragewelle für die API zum Start begleitet. Daher hat der systemweite Durchsatz, nicht nur die Latenz pro Benutzer, höchste Priorität.
In einem GB300 NVL72-System besteht ein Knoten aus 4 einzelnen GPUs, was bedeutet, dass es 18 Knoten gibt. Als Instanz belegt Kimi K3 2 Knoten (8 GPUs); jedes NVL72-Rack kann 9 Replikate des Modells aufnehmen. Jeder Cluster verfügt über mehrere GB300 NVL72-Racks, und wir bedienen das Modell über mehrere Regionen und Cloud-Anbieter hinweg, um auf mehr Kapazität zuzugreifen.
Jedes NVL72-System kann neun Replikate von Kimi K3 ausführen.
Der entscheidendste Faktor für den Durchsatz eines bestimmten Replikats ist die Präfix-Cache-Trefferquote. Angesichts des Umfangs der Bereitstellung macht dies das KV-bewusste Routing zur primären Herausforderung, die es auf der Infrastrukturebene zu lösen gilt. Wenn ein Benutzer eine Sequenz von Eingabe-Tokens sendet, die wir bereits gesehen haben, müssen wir diese Anfrage an ein Replikat weiterleiten, das auf den gespeicherten KV-Cache zugreifen kann, um das Prefill zu überspringen.
Unser KV-bewusstes Routing-System, das mit dem NVIDIA Dynamo Toolkit erstellt wurde, stellt sicher, dass wir in der Lage sind, Traffic zu Replikaten mit warmen Caches für wiederholte Abfragen zu leiten. Da Coding und Multi-Turn-Agents häufige Anwendungsfälle für Kimi K3 sind, ist dieses cache-bewusste Routing-System entscheidend, um Benutzern Geld zu sparen und einen hohen Gesamtsystemdurchsatz aufrechtzuerhalten.
Mit Kimi K3 auf Baseten entwickeln
Wir freuen uns, den Zugang ab Tag 0 über Model APIs anbieten zu können, und freuen uns darauf, unsere Implementierung dieses Modells weiter zu optimieren, um die höchsten Standards in Bezug auf Leistung und Zuverlässigkeit zu erreichen.
Die Ankündigung von Kimi K3 durch das Team von Moonshot AI enthält eine Reihe interessanter Tests für das Modell, darunter Codierungsaufgaben wie Kernel-Optimierung und spielerische Entwicklung mit Vision, Forschungsaufgaben sowie agentische Aufgaben wie Videobearbeitung und Wissensarbeit. Am Dienstag, den 28. Juli um 11:00 Uhr Pazifischer Zeit werde ich ein Executive Briefing zu Kimi-K3-Anwendungsfällen gemeinsam mit Joey Zwicker leiten, der die gesamte Forward-Deployed-Engineering bei Baseten verantwortet.
Kimi K3 ist ab heute auf Baseten Model APIs verfügbar. Willkommen an der neuen Grenze der offenen Gewichts-Intelligenz.
Vielen Dank an die vielen Ingenieure hinter unserer Kimi-K3-API, dass sie mir erlaubt haben, ihre harte Arbeit in diesem Artikel zu dokumentieren, darunter zu viele Menschen, um sie namentlich zu nennen, aus den Teams für Modellleistung, Infrastruktur, Kapazität, Training, Produkt und Forward-Deployed Engineering. Auch danke an die Teams von Moonshot AI, Inferact und RadixArk für ihre Zusammenarbeit und Unterstützung.
