Kimi K2.6: il modello precedentemente servito da Gonka

Kimi K2.6 è un grande modello linguistico (LLM) della serie Kimi, sviluppato dall'azienda di Pechino Moonshot AI. Moonshot AI è uno dei principali laboratori di AI in Cina, fondato nel 2023 da un team di ricercatori guidato da Yang Zhilin. L'azienda ha ottenuto finanziamenti da Alibaba, Tencent e altri grandi investitori ed è entrata nella lista delle "tigri AI cinesi" — le aziende che dettano il ritmo dello sviluppo dell'AI in Asia.

La serie Kimi è nota dal 2024. Le prime versioni (K1, K1.5) hanno subito attirato l'attenzione per la finestra di contesto eccezionalmente lunga — fino a 200.000 token in un'unica richiesta, un record per i modelli pubblicamente accessibili al momento del lancio. Un contesto lungo significa la possibilità concreta di analizzare in una sola richiesta un intero libro, una codebase di medie dimensioni o una raccolta di documenti legali. Al momento dell'uscita di Kimi, questa caratteristica era un forte vantaggio competitivo.

La versione K2 è apparsa nel 2025 e ha portato un salto architetturale decisivo — il passaggio a MoE (Mixture of Experts). Questa stessa architettura è alla base di Qwen3-235B e DeepSeek-R1 — è diventata di fatto lo standard per i modelli più grandi del 2025—2026. Il MoE permette di avere centinaia di miliardi di parametri "in totale", ma di attivarne solo un sottoinsieme a ogni richiesta (di solito il 5—10%), riducendo radicalmente il costo computazionale dell'inference a qualità comparabile.

K2.6 è l'ultima iterazione della serie K2 al momento della stesura di questo articolo. Dalle dichiarazioni pubbliche di Moonshot AI risulta che in questa versione sono state migliorate le capacità del modello nel reasoning (ragionamento logico), nella generazione di codice e nel tool calling nativo. Finché il modello era servito dalla rete Gonka, era disponibile con l'identificatore moonshotai/Kimi-K2.6; ora il gateway non accetta più questo identificatore — l'elenco aggiornato dei modelli è sempre restituito da GET /v1/models.

Entrambi i modelli rappresentano sviluppi di punta dei più grandi laboratori di IA cinesi; finché entrambi sono stati supportati dalla rete, erano disponibili tramite un'unica interfaccia compatibile con OpenAI, JoinGonka Gateway — oggi, di questa coppia, solo MiniMax M2.7 è disponibile tramite il gateway. Tuttavia, hanno punti di forza e un'eredità diversi, il che rende la scelta tra loro non una questione di «quale sia migliore», ma «quale sia adatta al compito».

Sui benchmark di reasoning (MATH-500, GSM8K, AIME) la serie Kimi K2 mostra storicamente risultati nel gruppo superiore dei modelli open-weights, competendo con DeepSeek-R1 e i modelli di stile o1. Nei compiti di generazione di codice (HumanEval, MBPP) entrambi i modelli si mantengono su livelli simili. Il punto di forza di MiniMax M2.7 è l'efficiente (linear) attention per sequenze molto lunghe, mentre Kimi è nota per il forte reasoning e il contesto lungo della serie Kimi.

Un'importante precisazione sui benchmark nel 2026: il divario tra i modelli top nei test pubblici si è ridotto a pochi punti percentuali e questa differenza spesso risulta entro l'errore statistico dei benchmark stessi. Per il lavoro pratico non conta «chi è al 2% in più in MMLU», ma la natura dei compiti: quale contesto si trasmette al modello, quanto sono complesse le catene logiche, se è necessaria una lunga cronologia di dialogo, quali lingue vengono utilizzate. Pertanto, la tabella sopra non classifica i modelli, ma aiuta a capire rapidamente per quale profilo di compiti ciascuno di essi è ottimizzato.

Per la scelta pratica oggi: la nicchia di Kimi K2.6 — contesto lungo (analisi di grandi documenti, lettura di basi di codice voluminose, lunghi dialoghi con conservazione della cronologia) e compiti di reasoning complessi — nell'attuale composizione della rete è coperta da due modelli. Del ragionamento si occupa GLM-5.3 Flash: pensa prima di rispondere, ed è proprio quella da scegliere per logiche intricate; ha anche il contesto più lungo della rete (390K). Per prompt grandi senza ragionamento e lunghe sessioni di agenti — DeepSeek V4 Flash (380K, secondo contesto più lungo). Se la priorità è l'elaborazione di sequenze di input molto lunghe e dati in streaming con risposta rapida — MiniMax M2.7 con la sua efficiente attention. Una buona strategia in produzione non è cambiata: mantenere diversi modelli della rete nel proprio codice; la rapida sostituzione tramite il parametro model permette di passare da uno all'altro a seconda del compito senza modificare l'architettura dell'applicazione.

Fino alla primavera del 2026 l'intera rete Gonka serviva esattamente un modello — Qwen3-235B. Dal punto di vista architetturale era una scelta sensata: l'inference distribuita tramite DiLoCo richiede che tutti i partecipanti alla rete tengano lo stesso modello nella memoria video, altrimenti non è possibile garantire che qualsiasi nodo possa elaborare qualsiasi richiesta. La Qwen3-235B completa in formato FP8 occupa circa 640 GB di VRAM, che di per sé è già un impegno enorme per ogni ML-node.

Per passare a una rete multi-modello serviva un meccanismo che permettesse di tenere più modelli contemporaneamente, senza però obbligare ogni host a eseguirli tutti. Questo meccanismo sono i DevShards — shard separati della rete, ognuno specializzato su un modello. I nodi all'interno di uno stesso shard lavorano sullo stesso modello, e il router della rete indirizza la richiesta allo shard con il modello desiderato.

L'idea non è nata dal nulla — è stata formalizzata nella Gonka Improvement Proposal #800 «Multi-Model PoC», portata al voto della community nella primavera del 2026. La proposta ha ottenuto il sostegno dei partecipanti e dei validator della rete ed è stata implementata tra aprile e maggio 2026. Kimi K2.6 è diventato il primo modello eseguito su un DevShard separato — di fatto, quindi, un'implementazione di test del nuovo approccio. L'esperienza si è rivelata un successo: sulla sua scia sono arrivati MiniMax M2.7, DeepSeek V4 Flash e GLM-5.3 Flash, ognuno sul proprio shard — ciascuno con il proprio insieme di host e la propria economia. Lo stesso meccanismo funziona anche al contrario: un modello che gli host smettono di supportare viene rimosso dalla rete tramite voto — ed è così che a settembre 2026 è uscito anche Kimi K2.6 stesso.

Cosa significa questo per utenti e sviluppatori:

• Una sola API — più modelli. Tramite JoinGonka Gateway non serve cambiare endpoint o chiavi: basta indicare un altro model nel body della richiesta. Il formato compatibile con OpenAI resta del tutto invariato.
• Il prezzo è lo stesso. Finché Kimi K2.6 è stato servito, veniva tariffato allo stesso prezzo di MiniMax M2.7; la tariffa unica della rete vale anche per i modelli attuali — $0.0069 per 1M token tramite Gateway. Il pricing unificato è una scelta consapevole per semplificare la migrazione degli utenti tra i modelli.
• La stabilità dipende dal carico dello shard. Nella fase iniziale lo shard di un nuovo modello ha meno host, quindi con una concentrazione di richieste il modello può restituire temporaneamente 429 too many concurrent requests. È una fase normale per un nuovo modello: man mano che l'interesse cresce, gli host si collegano al suo shard e i limiti salgono. Vale anche il contrario — se gli host lasciano lo shard, il modello perde capacità; è esattamente così che si è conclusa la storia di Kimi K2.6 sulla rete.
• Il tool calling è diverso per ogni modello. Su Kimi K2.6 nella rete Gonka, all'inizio si registravano piccoli problemi con la selezione automatica degli strumenti (tool_choice: "auto"), poi risolti con un aggiornamento dei nodi. La lezione resta valida per qualsiasi modello della rete: il formato di chiamata degli strumenti è una proprietà specifica del modello su uno specifico nodo, quindi per gli scenari critici in produzione testate in anticipo il comportamento del modello scelto sulle vostre richieste.

Risposta diretta: attraverso la rete Gonka, Kimi K2.6 non è più disponibile. Gli host hanno smesso di servirlo all'inizio di settembre 2026, e la proposta di governance #101 ha rimosso definitivamente il modello dall'elenco dei modelli della rete — una richiesta con model: "moonshotai/Kimi-K2.6" verrà rifiutata dal gateway. Poiché i pesi del modello sono aperti, è comunque possibile ottenerlo da hosting di terze parti per modelli open-weights (ad esempio tramite OpenRouter) oppure distribuirlo autonomamente.

Se invece ti serve quell'inference decentralizzata ed economica per cui si viene su Gonka, non è scomparsa: funziona semplicemente sui modelli attivi della rete. Tramite JoinGonka API Gateway, con API compatibile OpenAI e Anthropic, sono disponibili tre modelli, e ciascuno copre una parte di ciò che si apprezzava di Kimi:

• GLM-5.3 Flash (zai-org/GLM-5.3-Flash) — il modello di reasoning di Z.ai: ragiona prima di rispondere, quindi è proprio quello da scegliere per logica complessa, analisi del codice e compiti che richiedono di "pensare"; ha anche il contesto più lungo della rete (390K). Il ragionamento rientra nel limite della risposta — imposta max_tokens con margine e attiva lo stream.
• DeepSeek V4 Flash (deepseek-ai/DeepSeek-V4-Flash-0731) — uno dei contesti più lunghi della rete (380K), l'output più lungo e un forte agentic coding: repository grandi, lunghe catene di chiamate a strumenti.
• MiniMax M2.7 (MiniMaxAI/MiniMax-M2.7) — il modello predefinito del gateway: risposte rapide e uniformi su compiti quotidiani, documenti lunghi ed elaborazione in streaming.

Passare da Kimi K2.6 significa sostituire una riga. Qualsiasi codice scritto per OpenAI funziona senza modifiche: basta cambiare URL, API key e nome del modello.

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"}]
  }'

Negli strumenti di sviluppo vale la stessa regola: ovunque nelle impostazioni ci fosse moonshotai/Kimi-K2.6, inserisci l'identificativo di uno dei modelli attivi. In Cursor è il campo Custom Model, in Claude Code la variabile d'ambiente ANTHROPIC_MODEL o il flag --model, in OpenClaw, Cline e Continue.dev il nome del modello nella config del provider, in LangChain e n8n il parametro model all'inizializzazione del client. L'installer npx @joingonka/setup scriverà il gateway e il modello aggiornato nella config dello strumento con un solo comando. L'elenco dei modelli disponibili è sempre aggiornato nell'endpoint GET /v1/models — da lì è comodo recuperarlo dinamicamente nella UI dell'app, così che la scomparsa o l'arrivo di un modello nella rete non rompa il tuo prodotto.

Puoi provarlo senza registrazione nella chat gratuita alla pagina /try — lì sono disponibili i modelli attivi della rete. Con la registrazione a JoinGonka Gateway ricevi 3M token gratuiti per testare qualsiasi modello della rete — abbastanza per provare le tue attività su tutti e tre e scegliere il sostituto con cognizione di causa.

Cosa ha insegnato la vicenda di Kimi K2.6 alla rete Gonka: il meccanismo DevShards ha funzionato in entrambe le direzioni. Ha permesso di aggiungere modelli senza fermare la rete — dopo Kimi sono arrivati MiniMax M2.7, DeepSeek V4 Flash e GLM-5.3 Flash — e allo stesso tempo ha permesso di ritirare senza intoppi un modello che gli host non supportavano più. Una rete legata a un solo modello è fondamentalmente fragile; una rete capace di cambiare composizione tramite voto si evolve in modo morbido e continuo. Per lo sviluppatore ne deriva una regola semplice: non "scegliere un modello per sempre", ma tenere il nome del modello nella configurazione e verificare l'elenco live.