Kimi K3 raggiunge 2.8 trilioni di parametri combinando Kimi Delta Attention, Attention Residuals e un sistema Stable LatentMoE estremamente sparso con 896 esperti. Per ogni token vengono attivati solo 16 esperti, consentendo alla capacità totale del modello di crescere molto più velocemente rispetto al calcolo attivo.
Moonshot afferma che queste modifiche all'architettura e alla formazione producono all'incirca 2.5× l'efficienza di scalabilità complessiva di Kimi K2. Ciò non significa che K3 sia economico da gestire. Il modello è ancora progettato per l'inferenza su scala supernodo con 64 o più acceleratori.
Informazioni sull'architettura verificate il 21 luglio 2026. Moonshot ha pubblicato una panoramica del lancio, mentre è ancora previsto il rilascio del rapporto tecnico completo e dei pesi. Questo articolo etichetta le domande aperte invece di inventare i dettagli di implementazione mancanti.
L'architettura in uno sguardo
| Componente | Dettaglio pubblicato per Kimi K3 |
|---|---|
| Parametri totali | 2.8 trilioni |
| Attenzione | Kimi Delta Attention, con Gated MLA nell'architettura |
| Connessione di profondità | Attention Residuals |
| MoE | Stable LatentMoE |
| Esperti | 896 esperti instradati |
| Esperti attivi | 16 per token |
| Bilanciamento | Bilanciamento quantilico |
| Tecnica di ottimizzazione | Per-Head Muon |
| Componente di attivazione | Sigmoid Tanh Unit |
| Formato peso | MXFP4 attraverso la formazione basata sulla quantizzazione |
| Formato di attivazione | MXFP8 |
| Contesto | 1 milione di token |
| Direzione di distribuzione | Supernodo con almeno 64 acceleratori |
Cos'è Kimi Delta Attention?
Kimi Delta Attention, o KDA, è il meccanismo ibrido di attenzione lineare di Moonshot. Il suo ruolo è quello di fornire una base più efficiente per l'elaborazione di lunghe sequenze rispetto al fare affidamento solo sulla convenzionale piena attenzione a ogni livello e token.
I metodi di attenzione lineare generalmente cercano di evitare la crescita quadratica associata al confronto di ogni token con ogni altro token. La parola “ibrido” è importante: l’esatta architettura K3 combina componenti di attenzione anziché ridurre il modello a una semplice formula lineare.
KDA è fondamentale per il posizionamento del 1M token di K3, ma la lunghezza del contesto è una proprietà di sistema. Il layout della memoria, i kernel, la gestione del KV o dello stato, la memorizzazione nella cache, il parallelismo e l'infrastruttura di servizio influiscono tutti sulla praticità di un contesto lungo.
KDA e memorizzazione nella cache dei prefissi
I sistemi di servizio convenzionali spesso memorizzano nella cache lo stato di attenzione per un prefisso ripetuto. KDA introduce diversi requisiti di stato e precompilazione, quindi non si può semplicemente presumere che le normali implementazioni della cache dei prefissi funzionino in modo efficiente.
Moonshot afferma di aver contribuito con il supporto della cache di precompilazione di KDA alla comunità vLLM per il rilascio insieme a K3. Questo aiuta a spiegare come l'API ufficiale possa offrire un prezzo di input di cache-hit molto inferiore a quello di input non memorizzato nella cache, nonostante le dimensioni del modello.
I team dell'infrastruttura dovrebbero attendere il supporto esplicito di K3 nella versione vLLM e nei kernel pertinenti anziché modificare il nome di un modello in una distribuzione esistente.
Cosa sono i residui di attenzione?
Le reti profonde tradizionali trasmettono le informazioni attraverso connessioni residue che si accumulano strato dopo strato. Moonshot descrive i residui di attenzione, o AttnRes, come il recupero selettivo di rappresentazioni attraverso la profondità anziché l'accumulo uniforme di tutto.
Il vantaggio previsto è un flusso di informazioni più fluido attraverso un modello molto profondo. Invece di forzare ogni livello a dipendere solo dallo stato immediatamente accumulato, AttnRes può enfatizzare utili rappresentazioni precedenti.
Ciò è concettualmente importante su scala 2.8T, dove l'ottimizzazione e il flusso del segnale diventano difficili. Le equazioni complete, le ablazioni e i dettagli della formazione dovrebbero essere valutati quando la relazione tecnica sarà pubblica.
Stable LatentMoE e 896 esperti
K3 è un modello misto di esperti. Un router seleziona un piccolo sottoinsieme di reti esperte per ciascun token.
K3 ha:
- 896 esperti instradati;
- 16 esperti attivi per token;
- componenti esperti condivisi e instradati nel diagramma pubblicato;
- un framework LatentMoE stabile progettato per la scarsità estrema.
Il rapporto di attivazione è approssimativamente:
16 / 896 ≈ 1.8%
Tale percentuale non rivela direttamente il conteggio dei parametri attivi. I livelli condivisi, le dimensioni degli esperti, il routing, l'attenzione e altri componenti contribuiscono al calcolo al di fuori del rapporto semplice. Trattare le affermazioni secondo cui K3 ha un numero esatto di parametri attivi come non verificato a meno che Moonshot non lo pubblichi.
Perché la scarsità estrema del MoE è difficile
Più esperti creano più capacità, ma anche problemi di routing e infrastrutturali più difficili:
- i token possono sovraccaricare gli esperti popolari;
- capacità di scarto degli esperti sottoutilizzata;
- il posizionamento degli esperti influisce sulla comunicazione;
- lo squilibrio del carico riduce l'utilizzo dell'acceleratore;
- le forme dinamiche e la sincronizzazione dell'host possono compromettere la produttività;
- Le decisioni di routing devono rimanere stabili durante la formazione.
K3 affronta questi problemi con il bilanciamento, l'esecuzione in forma statica e domini di comunicazione di grandi dimensioni.
Bilanciamento quantile
Moonshot descrive il bilanciamento dei quantili come la derivazione dell'allocazione esperta dai quantili del punteggio del router. L'obiettivo è evitare regole di aggiornamento euristiche e un iperparametro di bilanciamento sensibile.
In parole povere, l’allocazione si adatta alla distribuzione dei punteggi di routing piuttosto che dipendere da una soglia regolata manualmente. Ciò è rilevante quando 896 esperti devono rimanere utili e serviti in modo uniforme su larga scala.
Sono ancora necessari risultati indipendenti di riproduzione e ablazione per quantificare il contributo del bilanciamento quantilico rispetto al resto del sistema di addestramento.
Per-Head Muon
Muon è un approccio di ottimizzazione utilizzato durante l'allenamento. K3 lo estende in base al livello di attenzione, consentendo alle teste di essere ottimizzate in modo più indipendente.
La motivazione dichiarata di Moonshot è l'ottimizzazione più adattiva su larga scala. Questa è una tecnica di training piuttosto che una funzionalità API: gli utenti non configurano Per-Head Muon durante l'inferenza.
SiTU e Gated MLA
La panoramica del lancio identifica inoltre:
- Sigmoid Tanh Unit (SiTU): destinato a migliorare il controllo dell'attivazione;
- Gated MLA: destinato a migliorare la selettività dell'attenzione.
Questi componenti si trovano all'interno di un design a blocchi più ampio che combina KDA, esperti latenti, esperti condivisi, elementi convoluzionali e gating. Il loro esatto contributo richiede la relazione tecnica e le ablazioni controllate.
Pesi MXFP4 e attivazioni MXFP8
K3 utilizza l'addestramento basato sulla quantizzazione dalla fase di messa a punto supervisionata in poi, con pesi MXFP4 e attivazioni MXFP8.
L'addestramento sensibile alla quantizzazione espone il modello a un comportamento di precisione inferiore durante l'addestramento invece di convertire un modello finito ad alta precisione in un secondo momento. Ciò può preservare una maggiore qualità in un formato di inferenza efficiente.
MXFP4 riduce sostanzialmente la memorizzazione del peso teorico. Con quattro bit per parametro, i parametri grezzi 2.8T corrispondono a circa 1.4 TB prima di scale, metadati, componenti non quantizzati, buffer di runtime e ridondanza. Rimane ben oltre l'hardware di consumo.
Formazione parallela tra esperti completamente bilanciata
Moonshot afferma che K3 utilizza un addestramento parallelo esperto completamente bilanciato con forme statiche e nessuna sincronizzazione dell'host sul percorso critico. Queste scelte mirano al lavoro prevedibile dell'acceleratore e riducono le pause causate dal coordinamento della CPU.
Al momento dell’inferenza, rimane la stessa ampia sfida: gli esperti distribuiti su molti dispositivi devono comunicare rapidamente. Moonshot consiglia un supernodo con almeno 64 acceleratori in modo che avvenga una maggiore comunicazione all'interno di un dominio a larghezza di banda elevata.
Come K3 raggiunge un contesto 1M token
Nessun singolo componente spiega la finestra 1M. La capacità dipende da:
- efficiente elaborazione della sequenza KDA;
- flusso di informazioni stabile attraverso AttnRes;
- servire i kernel e gestire la memoria;
- supporto per la precompilazione della cache;
- infrastruttura di accelerazione distribuita;
- dati e obiettivi di addestramento che insegnano al modello a utilizzare un contesto lungo.
Un modello che accetta un milione di token non significa che ogni token riceva la stessa attenzione o che una richiesta di un milione di token sia sempre la soluzione migliore. La valutazione a lungo contesto dovrebbe testare il recupero, le dipendenze distanti, la distrazione, la latenza e i costi.
Kimi K3 rispetto a Kimi K2
| Zona | Kimi K3 direzione | Kimi Linea di base K2 |
|---|---|---|
| Scala | 2.8T parametri totali | Generazione precedente più piccola |
| Attenzione | Attenzione lineare ibrida KDA | Architettura precedente |
| Profondità | Attention Residuals | Architettura residua precedente |
| MoE | Esperti 896, 16 attivi | Scarsità meno estrema |
| Efficienza | ~2.5× efficienza di ridimensionamento dichiarata | Base |
| Visione | Comprensione visiva nativa | Superficie di capacità precedente diversa |
| Contesto | 1M token | Limite precedente inferiore a seconda del modello |
Il valore 2.5× rappresenta l'affermazione complessiva di Moonshot in termini di efficienza di scalabilità, non una promessa di velocità 2.5× API o prestazioni benchmark 2.5×.
Limiti dell'architettura e questioni aperte
Importanti domande senza risposta includono:
- conteggio esatto dei parametri attivi;
- struttura completa dei livelli e dimensioni degli esperti;
- conteggio dei token di addestramento e combinazione di dati;
- metodo di formazione completo a lungo contesto;
- ablazioni ad architettura indipendente;
- hardware supportato e throughput misurato in base alla configurazione;
- impronta esatta del peso del file;
- supporto runtime e licenza finale.
A queste domande dovrebbe essere data risposta dal rapporto tecnico di Moonshot e dai repository ufficiali dopo il rilascio.
Perché l'architettura è importante per gli sviluppatori
La maggior parte degli utenti API non ha bisogno di implementare il routing KDA o MoE. Devono comprendere le conseguenze operative:
- K3 è forte nel lavoro ricco di contesto e con agenti;
- preservare lo stato della conversazione è essenziale;
- il caching automatico può ridurre sostanzialmente i costi;
- il self-hosting richiede infrastrutture estreme;
- il comportamento del modello non può essere dedotto solo dal conteggio totale dei parametri;
- i nuovi runtime e kernel devono supportare esplicitamente K3.
Leggi Kimi K3 è open source? per lo stato della distribuzione e guida all'API di Kimi K3 per l'integrazione dell'applicazione.
Domande frequenti
Quanti parametri ha Kimi K3?
K3 ha 2.8 trilioni di parametri totali in un'architettura sparsa di miscela di esperti.
Quanti esperti sono attivi?
Moonshot afferma che vengono attivati 16 dei 896 esperti instradati. Anche i componenti condivisi e non esperti contribuiscono al calcolo.
Cos'è Kimi Delta Attention?
KDA è il meccanismo ibrido di attenzione lineare di Moonshot per un'elaborazione efficiente delle sequenze e il ridimensionamento di contesti lunghi.
Perché Kimi K3 supporta il contesto 1M?
La finestra è abilitata dall'architettura, dalla formazione, dalla memorizzazione nella cache, dai kernel, dalla gestione della memoria e dal servizio distribuito anziché da una sola funzionalità.
Kimi K3 può essere eseguito su GPU consumer?
Il modello completo non può essere realisticamente eseguito su GPU consumer. Moonshot consiglia distribuzioni di supernodi con 64 o più acceleratori.