Kimi K3.1 Pro: se il modello cambia senza dirtelo, il benchmark è inutile

Un modello che risponde non è necessariamente il modello che hai chiesto di usare. È un dettaglio piuttosto scomodo, soprattutto quando stai valutando un agente AI, confrontando costi o decidendo se sostituire un componente della tua architettura. La richiesta arriva, la risposta è plausibile, la demo funziona. Peccato che il sistema potrebbe aver cambiato motore durante il percorso e tu stia attribuendo il risultato a quello sbagliato.

L’annuncio di Kimi K3.1 Pro da parte di Moonshot AI, il 23 ottobre 2026, offre un caso concreto per affrontare il problema. Il modello è già accessibile attraverso i prodotti Kimi e le API, con una variante Highspeed. I pesi completi, invece, sono promessi entro il 4 novembre 2026: al momento dell’annuncio non sono ancora scaricabili. Fin qui è una notizia di prodotto. Il punto interessante per chi sviluppa sistemi è ciò che succede tra la scelta del modello e la prova che quel modello abbia davvero eseguito il lavoro.

Il lancio: disponibilità API e pesi aperti non sono la stessa cosa

Moonshot presenta K3.1 Pro come evoluzione di K3 ottenuta soprattutto con un post-training più intenso, e dichiara una finestra di contesto fino a 1.048.576 token. Annuncia capacità migliori nel coding, nei flussi con strumenti, nella modellazione 3D e nell’analisi documentale. Sono caratteristiche e risultati presentati dal produttore; il loro trasferimento a un repository reale va misurato, non dato per acquisito.

La differenza temporale conta. Oggi puoi chiamare il modello attraverso l’infrastruttura del fornitore. Non puoi ancora prendere i pesi annunciati, esaminarne la licenza definitiva, distribuirli nel tuo ambiente e ripetere gli esperimenti con un’inferenza controllata da te. Definire un modello “open-weight” sulla base di un rilascio futuro significa descrivere una promessa come se fosse già una proprietà disponibile. Non è una sfumatura lessicale: cambia le opzioni di audit, deployment e continuità operativa.

Anche un’analisi indipendente come quella di Simon Willison, che ha provato il modello tramite API, distingue l’accesso immediato dal rilascio futuro dei pesi. È la distinzione da conservare fino al giorno in cui i file e la licenza saranno effettivamente verificabili.

Due famiglie di identificatori, un errore che può falsare la prova

La documentazione ufficiale espone un particolare facile da trascurare. Sulla Kimi API il nome da inviare è kimi-k3.1-pro, oppure kimi-k3.1-pro-highspeed. Nel catalogo della sottoscrizione Kimi Code gli identificatori mostrati sono invece k3.1-pro e k3.1-pro-highspeed. Non sono stringhe da usare indistintamente: dipendono dal prodotto e dal protocollo che stai chiamando.

La stessa documentazione Kimi Code avverte che, nelle configurazioni di strumenti di terze parti, un identificatore di modello digitato male può produrre un fallback verso K2.8 Preview, senza thinking. Questo comportamento è documentato per quel percorso di integrazione; non significa che l’endpoint generale Moonshot API effettui sempre lo stesso fallback. Generalizzare sarebbe inventare un bug dove non abbiamo prove.

Il rischio pratico, però, è reale. Se la tua applicazione non registra il modello effettivamente selezionato, potresti attribuire tempi, qualità e consumo di token a K3.1 Pro quando il routing ha portato altrove. Peggio: potresti confrontare due esperimenti convinto di aver cambiato soltanto il prompt, mentre è cambiato anche il motore. La risposta apparentemente corretta diventa una pessima prova di identità.

Un benchmark senza identità verificata del modello misura un risultato. Non dimostra quale componente lo abbia prodotto.

Thinking obbligatorio e cache: cambiare una variabile può cambiarne tre

K3.1 Pro supporta soltanto il thinking mode. Nelle API Moonshot l’effort può essere impostato su low, high o max; tentare di disabilitare il ragionamento non è un modo per ottenere una variante più economica dello stesso esperimento. In Kimi Code la documentazione segnala inoltre che cambiare modello o livello di effort dentro una sessione può invalidare la cache del contesto e costringere a un nuovo prefill.

Questo crea una trappola di misurazione. Immagina due esecuzioni di un agente con lo stesso repository, gli stessi strumenti e lo stesso obiettivo. Nella seconda cambi modello per confrontare la qualità, ma riutilizzi una sessione la cui cache viene invalidata. La differenza osservata nel tempo totale non riguarda più soltanto la capacità di generazione: contiene anche il costo del contesto rielaborato. Se poi il router ha effettuato un fallback, hai modificato anche l’identità del modello.

Per un confronto credibile servono sessioni nuove e configurazioni fissate: modello richiesto, modello effettivo quando il protocollo lo espone, effort, lunghezza del contesto, stato della cache, versione dell’harness e condizioni degli strumenti. Non è burocrazia da laboratorio. È il minimo per non trasformare una tabella di risultati in una raccolta di coincidenze.

Highspeed promette più token al secondo, non automaticamente più lavoro concluso

Moonshot dichiara per K3.1 Pro Highspeed una generazione da due a tre volte più veloce rispetto alla variante standard. Nel servizio Kimi Code, secondo la documentazione, questo comporta circa il doppio del consumo di quota. Per l’API a consumo la struttura dei prezzi va verificata separatamente: una quota di abbonamento e una fattura per token non sono la stessa unità economica.

Il tempo di un task agentico, però, non coincide con il tempo di emissione dei token. Un workflow può passare gran parte della durata a eseguire test, attendere chiamate agli strumenti, consultare file, installare dipendenze, correggere un errore o ripetere una fase. Se la generazione pesa il 20% del tempo totale, anche triplicandone la velocità il limite teorico di miglioramento complessivo è modesto: da 100 unità di tempo a circa 86,7, ipotizzando invariato tutto il resto. È un esempio matematico, non una misurazione su Kimi.

Per questo non mi interessa soltanto il prezzo per milione di token. Mi interessa il tempo per task verificato, il costo dei tentativi falliti e il numero di correzioni che un essere umano deve ancora fare. È una distinzione già affrontata parlando del costo per modifica accettata nei coding agent. Un modello più rapido può essere economicamente peggiore se genera più tentativi inutili; uno più lento può risultare conveniente se riduce i passaggi di verifica. Senza dati del tuo workflow, entrambe restano ipotesi.

Come costruire un test che non premi il modello sbagliato

Partirei da un insieme piccolo ma rappresentativo di task reali, con condizioni di successo verificabili: un bug con test di regressione, un refactoring circoscritto, una modifica che richiede più tool e un’attività documentale con fonti controllabili. Non servono cento demo scenografiche; servono esperimenti ripetibili e un sistema capace di dire quando qualcosa è andato storto.

• Identità e configurazione: registrare endpoint, model ID richiesto, modello restituito se disponibile, versione del client, effort e policy di fallback. Se l’identità effettiva non è osservabile, il test deve segnalarlo come limite, non fingere certezza.
• Stato della sessione: annotare se è nuova, se il prefisso è in cache e quanti token vengono riletti; evitare confronti tra sessioni calde e fredde senza dichiararlo.
• Tempo e costo: separare prefill, generazione, attesa dei tool, retry, verifica e costo totale per task; non confondere quota Kimi Code e listino API.
• Esito: misurare artefatti accettati, test superati, regressioni e interventi manuali. Un testo che dice “completato” non è un criterio di accettazione.

Qui si collega un’altra questione già documentata: negli agenti la coppia modello-harness conta più del nome in classifica. K3.1 Pro non cambia questa regola; la rende più urgente. Se un modello ha requisiti specifici di thinking, cache e routing, l’harness non è un involucro neutro: decide che cosa il modello vede, quanto contesto ricostruisce e quale errore il sistema è in grado di rilevare.

Il 4 novembre sarà un test diverso: non un’altra classifica

Quando e se Moonshot pubblicherà i pesi completi, il controllo cambierà natura. Sarà possibile verificare concretamente repository, file, licenza, requisiti hardware e modalità di inferenza, anziché affidarsi soltanto a un servizio gestito. Ma anche allora l’etichetta “open-weight” non renderà automaticamente semplice o economico distribuire un modello di questa classe: i parametri attivi e quelli complessivi descrivono aspetti diversi del carico, e l’hardware necessario dipenderà da quantizzazione, parallelismo e implementazione.

Fino a quel momento, il risultato più utile dell’annuncio non è scegliere un vincitore da una tabella di benchmark. È ricordare che una scelta tecnica ha bisogno di un contratto osservabile: quale modello è stato richiesto, quale ha risposto, con quali limiti, a quale costo e con quale prova di riuscita. Se manca uno di questi pezzi, puoi anche avere il modello più interessante della settimana. Quello che non hai ancora è un sistema affidabile.