Latenza di Kimi K3

Tempo al primo token

Cinque esecuzioni in streaming, prompt banale («Count to three»), tetto di 128 token:

La mediana del TTFT è 2.82s. Ma guarda la colonna centrale: tre esecuzioni su cinque non hanno prodotto nemmeno un token di contenuto. Non è un risultato di latenza — è la trappola del budget di ragionamento colta sul fatto. Un tetto di 128 token è stato consumato per intero dal ragionamento, e lo stream è finito avendo emesso solo ragionamento. Se stai facendo streaming di K3 verso un utente, un errore silenzioso ha esattamente questo aspetto.

Per la velocità percepita conta lo scarto tra il primo token e il primo token di contenuto: nell'esecuzione 1 il ragionamento è partito a 2.74s, ma la risposta solo a 4.62s. Se mostri reasoning_content, l'utente vede movimento già a ~2.8s. Se non lo mostri, resta a fissare uno spinner per ~4.6s.

Rimisurato il 2026-07-18: i prompt reali sono un altro regime

Due giorni dopo abbiamo fatto un giro più ampio: dieci esecuzioni in streaming per endpoint, ognuna con un prompt realistico diverso (una spiegazione in due frasi — qualcosa su cui K3 pensa davvero), senza hit della cache, attraverso entrambi gli endpoint di EvoLink:

Tre cose che questo aggiunge al quadro del 2026-07-16:

• La complessità del prompt sposta il TTFT di 3–4×. Stesso giorno, stesso client: un prompt banale restituiva ancora il primo token in ~3.35s. Chiedi un ragionamento vero e la mediana del primo token si sposta a 11.3s. Fai il budget sul prompt che invierai davvero, non su quello del benchmark.
• L'oscillazione è enorme. Le singole esecuzioni sono andate da 2.9s a 40s al primo contenuto. Un p95 di ~36s significa che una chiamata su venti fa aspettare al tuo utente mezzo minuto prima del primo carattere visibile — a meno che tu non mandi in streaming il ragionamento o non mostri l'avanzamento.
• L'endpoint principale si merita il nome. direct.evolink.ai ha battuto il fallback api.evolink.ai su ogni mediana, di circa 4s al centro della distribuzione. In produzione usa direct; tieni api come il fallback che la documentazione dice che è.

Lo stesso giorno il throughput è rimasto stabile dove il TTFT non lo era: 15–18 token/secondo di mediana una volta partito il contenuto, su entrambi gli endpoint e in entrambi i giorni. L'attesa è tutta concentrata all'inizio; lo stream in sé va bene. Stai confrontando i gateway? Lo stesso protocollo è passato anche per OpenRouter, in round appaiati su due finestre — nessun vincitore stabile. La mediana di EvoLink è passata da 21.4s nella prima finestra a 31.1s un'ora dopo: una deriva legata all'ora del giorno grande quanto il divario tra i gateway.

Contesto lungo

Senza streaming, con output banale: quindi in pratica è «quanto ci mette K3 a leggere il tuo prompt e a pensarci sopra».

Il tempo reale cresce con il prompt

Secondi per chiamata, output banale · misurato il 2026-07-16

Mezzo milione di token sono 52 secondi e $1.49 per una singola richiesta, prima che K3 scriva qualsiasi cosa. La finestra da un milione di token è reale, ma non è né veloce né gratis: con ~5× i token abbiamo visto ~5× il tempo reale, quindi il tetto di ~1M plausibilmente si avvicina ai due minuti. Non l'abbiamo testato — sarebbe stata una deduzione, non una misura.

La velocità viene dalla progettazione, non dalla cache

Una speranza ragionevole: scaldi il prefisso, salti il lavoro, ti riprendi la latenza. L'abbiamo verificata. Non regge. Confrontando chiamate fredde e calde sugli stessi prefissi, il tempo reale non è migliorato in modo consistente — 3.56s→3.80s, 3.02s→4.29s, 3.99s→3.54s, 4.38s→4.27s, 5.22s→3.78s. La varianza tra un'esecuzione e l'altra ha coperto qualsiasi effetto della cache.

Il motivo è strutturale: K3 passa secondi a ragionare a ogni chiamata, che il prompt fosse in cache o no, e questo domina la timeline. Il caching del prompt è un'ottimizzazione della fattura, non della latenza.

Riconfermato il 2026-07-18 su quattro dimensioni di prefisso, da 1.2k a 70k token: ogni chiamata calda ha centrato la cache (verificato in fattura), e il TTFT continua a non migliorare in modo consistente — una dimensione è andata più veloce, tre no.

Cosa farci

• Usa sempre lo streaming. Senza streaming, il contesto lungo significa un minuto di silenzio. stream: true più stream_options: {"include_usage": true}.
• Imposta i timeout del client in minuti. I timeout predefiniti degli SDK uccidono chiamate a contesto lungo del tutto legittime. Abbiamo misurato 52s su una singola richiesta andata a buon fine.
• Decidi cosa fare della pausa di ragionamento. ~3s al primo token di ragionamento sui prompt banali, mediana di 11s su quelli reali, e il primo token di contenuto arriva da secondi a decine di secondi dopo. O mostri il ragionamento, o metti un'interfaccia di avanzamento pensata per un'attesa di decine di secondi al p95.
• Non mettere K3 in un percorso di richiesta sincrono in cui una persona aspetta con poco tempo a disposizione. Ragiona. È quello il prodotto.
• Riduci il contesto. La latenza cresce con la dimensione del prompt e, a differenza del costo, non c'è nessuno sconto della cache ad attutirla.

Cosa questi numeri non sono

Non sono un benchmark. Un solo client, un solo percorso di rete, due giorni, campioni da uno a dieci. Si portano dietro la nostra rotta verso i server di Moonshot e qualunque carico avesse Moonshot in quel momento — il 2026-07-16 e di nuovo due giorni dopo, quando un modello di punta appena uscito è presumibilmente sotto pressione.

A dominare ogni numero qui è K3 che ragiona, e si misura in secondi. Il routing di rete — incluso il salto attraverso un gateway pass-through — al confronto è questione di millisecondi, ed è per questo che li trattiamo come tempi di K3 e non di un singolo endpoint. Dove li abbiamo eseguiti.

Leggili come ordini di grandezza, non come misure del modello: secondi e non millisecondi al primo token sui prompt banali, decine di secondi su quelli reali; decine di secondi e non secondi a 100k; un minuto e non dieci secondi a 500k. Questa è la forma della cosa, e basta per progettarci intorno. Una ripetizione l'abbiamo già fatta — il giro del 07-18 qui sopra — e continueremo ad aggiornare misure e date.

FAQ sulla latenza di Kimi K3

Quanto è veloce l'API di Kimi K3?

Dipende dal prompt. Su un prompt banale abbiamo misurato una mediana di ~3 secondi al primo token (2.8s il 2026-07-16, 3.35s il 07-18). Su prompt realistici, la mediana del 2026-07-18 è stata di 11.3s al primo token di ragionamento e 21.4s al primo token di contenuto (n=10, p95 35.7s), con un throughput di 18.4 tok/s (mediana) una volta partito il contenuto. Quel primo token è sempre ragionamento, non la risposta. Sono misure da un singolo client, non un benchmark.

Quanto ci mette Kimi K3 con un contesto lungo?

Abbiamo misurato 10.5 secondi per un prompt da 98,625 token e 52.0 secondi per un prompt da 497,718 token, entrambi con output banale. La scalabilità è sembrata grossomodo lineare, quindi la finestra piena da 1,048,576 token plausibilmente si avvicina ai due minuti, anche se non l'abbiamo testata.

Il caching del prompt rende Kimi K3 più veloce?

No. Confrontando chiamate fredde e calde sugli stessi prefissi, il tempo reale non è migliorato in modo consistente, e alcune chiamate calde sono state più lente. K3 ragiona a ogni chiamata a prescindere dalla cache, e questo domina la timeline. Il caching del prompt è un'ottimizzazione della fattura, non della latenza.