Kimi K2.5, veröffentlicht von der Pekinger Firma Moonshot AI am 27. Januar 2026, stellt eine bedeutende Weiterentwicklung im Bereich großer offener Modellarchitekturen dar. Mit 1,04 Billionen Parametern und 32 Milliarden aktivierten Parametern pro Token ist es eines der größten öffentlich zugänglichen Modelle, übertrifft jedoch nicht nur MiniMax-M2.5 und Qwen3.5 in der Größe, sondern auch GLM-5 in der Gesamtanzahl an Trainingsdaten – insgesamt rund 32 Billionen Token, darunter 15 Billionen visuell-textuelle Daten und 700 Milliarden für langen Kontext. Die Architektur bleibt der des Vorgängers K2 nahezu identisch: 384 Experten, davon 8 pro Token, MLA-Attention, SwiGLU-Aktivierung und ein 256K-Context-Fenster. Der Vision-Encoder MoonViT-3D basiert auf SigLIP-SO-400M und nutzt eine NaViT-Packing-Strategie für variable Bildauflösungen; Videos werden in Gruppen zu vier Frames temporär komprimiert. Ein zentrales Neuland ist die „Agent Swarm“-Fähigkeit, die durch das Parallel-Agent Reinforcement Learning (PARL)-Framework ermöglicht wird. Statt sequenzielle Aktionen abzuarbeiten, zerlegt das Modell Aufgaben in parallel ausführbare Teilprozesse, wobei der Orchestrierer trainiert wird, während die Sub-Agenten aus früheren Checkpoints stammen und fixiert bleiben. Dies vermeidet Kreditzuweisungsprobleme und wurde durch zusätzliche Belohnungsterme gegen Serial Collapse und spurious Parallelismus abgesichert. Ergebnisse zeigen eine Steigerung von 60,6 % auf 78,4 % bei BrowseComp und eine bis zu 4,5-fache Beschleunigung bei geeigneten Aufgaben – ein Meilenstein für offene Modelle, da dies erstmals eine echte parallele Aggregation von Agenten im Modell selbst ermöglicht. In Benchmarks überzeugt K2.5 besonders in visuellen Aufgaben: 92,3 % bei OCRBench, 90,1 % bei MathVista, 92,6 % bei InfoVQA. Auch HLE-Full mit Tools erreicht 50,2 % – überlegen gegenüber GPT-5.2 (45,5 %). Bei anderen Benchmarks wie AIME 2025 (96,1 %) oder SWE-Bench Verified (76,8 %) bleibt es hinter den führenden proprietären Modellen zurück, insbesondere bei komplexen logischen Aufgaben (GPQA-Diamond: 87,6 %). Ein deutlicher Schwachpunkt ist die hohe Verbalität: K2.5 erzeugt bis zu sechsmal mehr Tokens als Konkurrenten, was die Kosten trotz niedriger Token-Preise erhöht. Zudem zeigt es signifikante Halluzinationen (–11 im AA-Omniscience-Index), was auf mögliche Lücken im Trainingsdatenprovenienz hinweist – etwa das gelegentliche Identifizieren als Claude. Community-Feedback bestätigt starke Leistung in der Codeerstellung, besonders bei visuellen Aufgaben, aber oft überdimensionierte, anfänglich unvollkommene Ausgaben, die nach Nachbesserung effizienter werden. Die Agent-Swarm-Funktion funktioniert gut bei paralleler Webrecherche, jedoch führt sie zu Inkonsistenzen bei gemeinsamen Begriffen (z. B. unterschiedliche Spaltenbezeichnungen in Tabellen). Technisch ist K2.5 ein Meilenstein: Die Erkenntnis, dass frühe Fusion mit geringem visuellen Anteil (10 %) bessere Ergebnisse liefert als späte Fusion mit hohem Anteil (50 %), ist entscheidend für zukünftige Multimodal-Modelle. Zudem zeigt die „Zero-Vision SFT“-Methode, dass Text-Only-Fine-Tuning visuelle Fähigkeiten aktivieren kann – ein Hinweis auf bidirektionale Transferleistung. Geopolitisch ist bemerkenswert, dass das Modell auf US-exportkontrollierten Hardware trainiert wurde und dennoch konkurrenzfähig ist. Moonshot hat mit 4,8 Mrd. USD bewertet und setzt auf kostengünstige Nutzerakquise – der Lizenztyp (Modified MIT) erlaubt kommerzielle Nutzung bis 100 Mio. MAU. Für die lokale Nutzung benötigt man mindestens 24 GB GPU-RAM und 256 GB System-RAM, mit Unsloth-Quantisierung auf 1,8 Bit (~240 GB) läuft es auf einer einzigen GPU mit ~10 Tokens/Sekunde. API-Anbieter wie Fireworks (283 t/s), DeepInfra ($0,90/1M Token) und Baseten (336 t/s) bieten hohe Geschwindigkeit und Wirtschaftlichkeit. Insgesamt bleibt K2.5 eine der stärksten offenen Modelle mit herausragenden visuellen Fähigkeiten und einem bahnbrechenden Agent-Swarm-Ansatz. Doch die hohe Verbalität und die Kostensteigerung durch übermäßige Token-Generierung stellen praktische Herausforderungen dar. Ob PARL sich auf komplexe, nicht-embarrassingly-parallel Workflows übertragen lässt, bleibt abzuwarten. Für Entwickler ist es eine lohnende Option – besonders bei visuellen und parallelen Aufgaben – aber eine sorgfältige Evaluation der Use-Cases ist unerlässlich.