Google Cloud ha pubblicato un benchmark che confronta carichi di lavoro di classificazione e generazione su TPU v6e alle 15:36 UTC del 4 settembre. Il risultato principale: "Per i task di generazione con forte componente di decode, il modello Gemma 3 27B raggiunge un rigido limite di prestazioni oltre i 64 utenti concorrenti, stabilizzandosi a un moltiplicatore di throughput normalizzato di 4.12x a 128 utenti. Al contrario, il modello 12B arriva a un moltiplicatore di 8.19x."

La cautela più in basso

"A livelli estremi di concorrenza (ad esempio, 128 utenti), potreste notare picchi matematicamente anomali nel throughput medio. … In condizioni di forte vincolo sulle risorse, un --max-num-seqs o un --max-model-len configurati in modo errato possono portare a eliminazioni silenziose delle richieste, timeout delle connessioni client o OOM dei nodi worker di GKE. Quando queste richieste non riuscite terminano immediatamente, accorciano falsamente la durata della sessione e gonfiano artificialmente le metriche di throughput. I punti dati a 128 utenti in questi benchmark rappresentano il limite assoluto della stabilità del cluster e dovrebbero essere considerati un tetto, non una metrica di produzione sostenibile."

Ciò che dicono le righe avallate

La tabella di generazione, per 16, 32, 64 e 128 utenti, riporta 1.00x / 1.98x / 2.96x / 8.19x per Gemma 3 12B e 1.05x / 1.97x / 4.00x / 4.12x per il 27B. A 64 utenti concorrenti — l’ultima riga che il post non prende le distanze — il modello più grande è quello più veloce, l’opposto del titolo. L’intera narrativa del "limite di prestazioni" è un confronto tra due numeri tratti dalla riga disconosciuta.

Qui non c’è alcuna misura assoluta

Ogni cella è un multiplo di Gemma 3 12B a 16 utenti, in una tabella il cui intestazione di colonna recita "Throughput (req/s)". Non c’è alcun dato assoluto di richieste al secondo e nessun dato di costo — in un post la cui prima frase parla di unit economics. La configurazione è un pool di nodi TPU v6e su un singolo host in una topologia chip 2x2 su GKE Autopilot, servito da vLLM tramite tpu-inference, con max-model-len=128000, max-num-batched-tokens=8192, max-num-seqs=512.

Dove il framing ricevuto sbaglia

Questo verrà citato come "TPU v6e offre 8x". È un multiplo normalizzato, su un solo nodo, su un solo stack di serving, a un livello di concorrenza che il publisher definisce instabile e potenzialmente alterato da richieste eliminate. Il post è insolitamente franco — la nota è lì, senza attenuanti — e questa franchezza si trova nel paragrafo che nessuno legge. Anche la tabella di classificazione, i cui picchi di 6.04x-6.37x provengono dalla stessa riga a 128 utenti, presenta lo stesso problema.