Kimi K2.6: Ein Modell, das früher von Gonka betrieben wurde

Kimi K2.6 ist ein großes Sprachmodell (LLM) aus der Kimi-Reihe, entwickelt vom Pekinger Unternehmen Moonshot AI. Moonshot AI ist eines der führenden AI-Labore Chinas, 2023 von einem Forscherteam unter der Leitung von Yang Zhilin gegründet. Das Unternehmen hat Finanzierung von Alibaba, Tencent und weiteren großen Investoren erhalten und zählt zu den „chinesischen AI-Tigern" – jenen Firmen, die das Tempo der AI-Entwicklung in Asien vorgeben.

Die Kimi-Reihe ist seit 2024 bekannt. Schon die frühen Versionen (K1, K1.5) erregten mit einem außergewöhnlich langen Kontextfenster Aufmerksamkeit – bis zu 200.000 Tokens pro Anfrage, was zum Release-Zeitpunkt Rekord für öffentlich verfügbare Modelle war. Ein langer Kontext bedeutet praktisch, in einer einzigen Anfrage ein ganzes Buch, eine mittelgroße Codebasis oder eine Sammlung juristischer Dokumente zu analysieren. Zum Markstart von Kimi war das ein starkes Wettbewerbsargument.

Die Version K2 erschien 2025 und brachte einen grundlegenden Architektursprung – den Wechsel zu MoE (Mixture of Experts). Dieselbe Architektur liegt Qwen3-235B und DeepSeek-R1 zugrunde – sie ist zum faktischen Standard für die größten Modelle der Jahre 2025–2026 geworden. MoE erlaubt Hunderte Milliarden Parameter „insgesamt", aktiviert pro Anfrage aber nur eine Teilmenge (meist 5–10 %), was die Rechenkosten der Inference bei vergleichbarer Qualität radikal senkt.

K2.6 ist die jüngste Iteration der K2-Reihe zum Zeitpunkt dieses Artikels. Aus öffentlichen Aussagen von Moonshot AI geht hervor, dass in dieser Version die Fähigkeiten des Modells in Reasoning (logisches Schlussfolgern), Codegenerierung und nativem Tool Calling verbessert wurden. Solange das Modell über das Gonka-Netzwerk bereitgestellt wurde, war es unter der Kennung moonshotai/Kimi-K2.6 verfügbar; derzeit akzeptiert das Gateway diese Kennung nicht – die aktuelle Modellliste liefert immer GET /v1/models.

Beide Modelle repräsentieren Flaggschiff-Entwicklungen der größten chinesischen KI-Labore; solange beide vom Netzwerk betrieben wurden, waren sie über die einheitliche OpenAI-kompatible Schnittstelle JoinGonka Gateway zugänglich – heute ist aus diesem Paar nur noch MiniMax M2.7 über das Gateway verfügbar. Dabei haben sie unterschiedliche Stärken und Hintergründe, was die Wahl zwischen ihnen nicht zu einer Frage macht, „welches besser ist“, sondern zu einer Frage, „welches zur Aufgabe passt“.

Bei reasoning-Benchmarks (MATH-500, GSM8K, AIME) zeigt die Kimi K2-Serie historisch Ergebnisse in der oberen Gruppe der open-weights Modelle und konkurriert mit DeepSeek-R1 und o1-style Modellen. Bei Codegenerierungsaufgaben (HumanEval, MBPP) bewegen sich beide Modelle auf ähnlichem Niveau. Die Stärke von MiniMax M2.7 liegt im effizienten (linearen) attention für sehr lange Sequenzen, während Kimi für starkes reasoning und den langen Kontext der Kimi-Serie bekannt ist.

Ein wichtiger Hinweis zu Benchmarks im Jahr 2026: Die Kluft zwischen Top-Modellen in öffentlichen Tests hat sich auf wenige Prozentpunkte verringert, und dieser Unterschied liegt oft innerhalb der statistischen Fehlerquote der Benchmarks selbst. Für die praktische Arbeit zählt nicht, „wer bei MMLU 2 % besser ist“, sondern die Art der Aufgaben: Welchen Kontext übergeben Sie dem Modell, wie komplex sind die logischen Ketten, wird eine lange Dialoghistorie benötigt, welche Sprachen werden verwendet. Daher ordnet die obige Tabelle die Modelle nicht ein – sie hilft dabei, schnell zu verstehen, für welches Aufgabenprofil jedes Modell optimiert ist.

Für die praktische Wahl heute: Die Nische von Kimi K2.6 – langer Kontext (Analyse großer Dokumente, Lesen umfangreicher Codebasen, lange Dialoge mit Historien-Speicherung) und komplexe reasoning-Aufgaben – wird in der aktuellen Netzwerkbesetzung durch zwei Modelle abgedeckt. Für logische Schlussfolgerungen ist GLM-5.3 Flash zuständig: Es denkt vor der Antwort nach, und genau dieses Modell sollte man für komplexe Logik wählen; es hat zudem das längste Kontextfenster im Netzwerk (390K). Für große Prompts ohne logische Schlussfolgerungen und lange Agenten-Sitzungen – DeepSeek V4 Flash (380K, zweitlängster Kontext). Wenn die Verarbeitung sehr langer Eingabesequenzen und Streaming-Daten mit schneller Antwort Priorität hat – MiniMax M2.7 mit seinem effizienten attention. Eine gute Strategie in der Produktion hat sich nicht geändert – mehrere Modelle des Netzwerks im eigenen Code vorzuhalten: Der schnelle Wechsel über den Parameter model ermöglicht es, je nach Aufgabe zwischen ihnen zu wechseln, ohne die Anwendungsarchitektur zu ändern.

Bis zum Frühjahr 2026 betrieb das gesamte Gonka-Netzwerk genau ein Modell — Qwen3-235B. Aus architektonischer Sicht war das eine wohlüberlegte Entscheidung: verteiltes inferenced über DiLoCo erfordert, dass alle Teilnehmer des Netzwerks dasselbe Modell im VRAM halten — andernfalls lässt sich nicht garantieren, dass jeder Knoten jede Anfrage verarbeiten kann. Eine vollständige Qwen3-235B belegt im FP8-Format rund 640 GB VRAM, was für jede ML-Node bereits eine enorme Verpflichtung darstellt.

Für den Übergang zu einem Multi-Modell-Netzwerk brauchte es einen Mechanismus, der es erlaubte, mehrere Modelle gleichzeitig vorzuhalten, ohne dass jeder Host sie alle betreiben muss. Dieser Mechanismus sind die DevShards — separate Shards des Netzwerks, von denen jeder auf ein Modell spezialisiert ist. Die Knoten innerhalb eines Shards arbeiten am selben Modell, und der Router des Netzwerks leitet die Anfrage an den Shard mit dem gewünschten Modell weiter.

Die Idee entstand nicht aus dem Nichts — sie wurde in Gonka Improvement Proposal #800 „Multi-Model PoC" formalisiert, das im Frühjahr 2026 zur Abstimmung durch die Community gestellt wurde. Der Vorschlag erhielt die Unterstützung der Teilnehmer und Validatoren des Netzwerks und wurde im April—Mai 2026 umgesetzt. Kimi K2.6 war das erste Modell, das auf einem eigenen DevShard lief — also faktisch die Testumsetzung des neuen Ansatzes. Die Erfahrung war erfolgreich: Ihr folgten MiniMax M2.7, DeepSeek V4 Flash und GLM-5.3 Flash auf eigenen Shards — jedes mit eigenem Host-Set und eigener Ökonomie. Derselbe Mechanismus funktioniert auch in die umgekehrte Richtung: Ein Modell, das von den Hosts nicht mehr unterstützt wird, wird per Abstimmung aus dem Netzwerk entfernt — genau so verabschiedete sich im September 2026 auch Kimi K2.6 selbst.

Was das für Nutzer und Entwickler bedeutet:

• Eine API — mehrere Modelle. Über das JoinGonka Gateway muss man weder Endpoint noch Keys wechseln: Es genügt, im Request-Body ein anderes model anzugeben. Das OpenAI-kompatible Format bleibt vollständig erhalten.
• Der Preis bleibt gleich. Solange Kimi K2.6 betrieben wurde, wurde es zum selben Satz abgerechnet wie MiniMax M2.7; der einheitliche Tarif des Netzwerks gilt auch für die aktuellen Modelle — $0.0069 pro 1 Mio. Tokens über das Gateway. Einheitliches Pricing ist eine bewusste Entscheidung, um Nutzern die Migration zwischen Modellen zu erleichtern.
• Die Stabilität hängt von der Auslastung des Shards ab. In der frühen Phase hat der Shard eines neuen Modells weniger Hosts, daher kann das Modell bei konzentrierten Anfragen vorübergehend 429 too many concurrent requests zurückgeben. Das ist eine normale Phase für ein neues Modell: Mit wachsendem Interesse schließen sich Hosts seinem Shard an, und die Limits steigen. Das Umgekehrte gilt ebenso — wenn Hosts den Shard verlassen, verliert das Modell an Kapazität; genau so endete die Geschichte von Kimi K2.6 im Netzwerk.
• Tool-Calling ist bei jedem Modell anders. Bei Kimi K2.6 im Gonka-Netzwerk traten zum Start kleinere Probleme bei der automatischen Auswahl von Tools auf (tool_choice: "auto"), die später durch ein Node-Update behoben wurden. Die Lehre bleibt für jedes Modell des Netzwerks aktuell: Das Format des Tool-Aufrufs ist eine Eigenschaft des konkreten Modells auf dem konkreten Node. Testen Sie daher für produktionkritische Szenarien das Verhalten des gewählten Modells vorab mit Ihren Anfragen.

Direkte Antwort: Über das Gonka-Netzwerk ist Kimi K2.6 nicht mehr verfügbar. Die Hosts haben den Betrieb Anfang September 2026 eingestellt, und der Governance-Vorschlag #101 hat das Modell endgültig aus der Modellliste des Netzwerks entfernt — eine Anfrage mit model: "moonshotai/Kimi-K2.6" wird vom Gateway abgelehnt. Da die Gewichte des Modells offen sind, kann man es weiterhin bei Drittanbietern für Open-Weights-Modelle beziehen (etwa über OpenRouter) oder selbst deployen.

Wenn Sie jedoch genau die günstige dezentrale Inferenz suchen, für die man zu Gonka kommt — die gibt es weiterhin, sie läuft nur auf den aktiven Modellen des Netzwerks. Über das JoinGonka API Gateway sind per OpenAI- und Anthropic-kompatibler API drei Modelle verfügbar, und jedes deckt einen Teil dessen ab, wofür Kimi geschätzt wurde:

• GLM-5.3 Flash (zai-org/GLM-5.3-Flash) — das Reasoning-Modell von Z.ai: Es denkt vor der Antwort nach, daher sollte man es für komplexe Logik, Code-Analyse und Denkaufgaben wählen; es hat zudem den längsten Kontext im Netzwerk (390K). Die Überlegungen zählen zum Antwortlimit — setzen Sie max_tokens mit Puffer und aktivieren Sie Stream.
• DeepSeek V4 Flash (deepseek-ai/DeepSeek-V4-Flash-0731) — einer der längsten Kontexte im Netzwerk (380K), die längste Ausgabe und starkes agentisches Coding: große Repositories, lange Ketten von Tool-Aufrufen.
• MiniMax M2.7 (MiniMaxAI/MiniMax-M2.7) — das Standardmodell des Gateways: schnelle, gleichmäßige Antworten bei Alltagsaufgaben, lange Dokumente und Streaming-Verarbeitung.

Der Umstieg von Kimi K2.6 ist der Austausch einer einzigen Zeile. Jeder Code, der für OpenAI geschrieben wurde, funktioniert unverändert: Es genügt, URL, API-Schlüssel und Modellnamen zu ersetzen.

curl https://gate.joingonka.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMaxAI/MiniMax-M2.7",
    "messages": [{"role": "user", "content": "Explain the difference between MoE and dense models"}]
  }'

In Entwicklungs-Tools gilt dieselbe Regel: Überall, wo in den Einstellungen moonshotai/Kimi-K2.6 stand, setzen Sie die Kennung eines der aktiven Modelle ein. In Cursor ist das das Feld Custom Model, in Claude Code die Umgebungsvariable ANTHROPIC_MODEL oder das Flag --model, in OpenClaw, Cline und Continue.dev der Modellname in der Provider-Konfiguration, in LangChain und n8n der Parameter model bei der Initialisierung des Clients. Der Installer npx @joingonka/setup trägt Gateway und aktuelles Modell mit einem Befehl in die Konfiguration des Tools ein. Die Liste der verfügbaren Modelle ist stets aktuell im Endpoint GET /v1/models — von dort lässt sie sich bequem dynamisch in die UI der Anwendung einbinden, damit das Verschwinden oder Hinzukommen eines Modells im Netzwerk Ihr Produkt nicht kaputt macht.

Ohne Registrierung können Sie es im kostenlosen Chat auf der Seite /try ausprobieren — dort sind die aktiven Modelle des Netzwerks verfügbar. Bei der Registrierung im JoinGonka Gateway erhalten Sie kostenlose 3M Token zum Testen aller Modelle des Netzwerks — genug, um Ihre Aufgaben auf jedem der drei durchlaufen zu lassen und die Ersetzung bewusst zu wählen.

Was die Geschichte von Kimi K2.6 für das Gonka-Netzwerk gezeigt hat: Der DevShards-Mechanismus funktionierte in beide Richtungen. Er ermöglichte das Hinzufügen von Modellen ohne Netzwerkunterbrechung — nach Kimi kamen MiniMax M2.7, DeepSeek V4 Flash und GLM-5.3 Flash — und er ermöglichte ebenso das schmerzfreie Entfernen eines Modells, das die Hosts nicht mehr unterstützen wollten. Ein Netzwerk, das an ein einziges Modell gebunden ist, ist fundamental fragil; ein Netzwerk, das seine Zusammensetzung per Abstimmung ändern kann, entwickelt sich sanft und kontinuierlich weiter. Für den Entwickler folgt daraus eine einfache Regel: nicht „ein Modell für immer wählen“, sondern den Modellnamen in der Konfiguration halten und die lebendige Liste prüfen.