Stesso modello, stessa scheda, stesso prompt, stesso script. Cambia solo il modo di servirlo. Quello che segue non è un riassunto delle slide di qualcun altro: sono misure fatte su una macchina nostra, con i numeri grezzi allegati.
Un numero senza metodo è un'opinione. Quattro regole, rispettate in tutti i run.
Un solo script per tutte e tre le configurazioni: prompt identici, max_tokens identico, temperatura 0, un warm-up prima di ogni misura. Nessun numero preso da un README.
Per la concorrenza conta l'ultima richiesta che finisce, non la media: la media nasconde la coda, e la coda è ciò che l'utente percepisce. Ogni punto è la mediana di tre run.
Prima di misurare, il testo che arriva al server viene confrontato con quello voluto. Un test precedente era girato con un prompt di un carattere: da lì la regola.
Il modello ragiona: senza disattivarlo, il budget finisce nel pensiero e la risposta esce vuota. Le misure di velocità sono a pensiero spento, quelle di qualità a pensiero acceso.
Tok/s aggregati al crescere degli utenti simultanei. 128 token per risposta.
Il punto non è chi vince a un utente, è dove si ferma ciascuno. La configurazione in uso tocca il tetto a otto utenti: da lì in poi aggiungere utenti non produce un token in più, produce solo attesa. A 64 utenti, 25 secondi contro 6,7.
Token al secondo mentre il modello assorbe il prompt. È la metrica dei documenti lunghi.
Su un documento da 32 mila token la differenza è di 7 secondi su 47: poco. Ma su un prompt da 512 token il batch legge in metà tempo, e in un assistente che risponde a domande brevi è la latenza che si sente per prima.
Dove il batch paga il prezzo di essere ottimizzato per la folla.
| Metrica | vLLM + MTP | HQ single | HQ batch |
|---|---|---|---|
| Tempo al primo token | 0,073 s | 0,073 s | 0,060 s |
| Decode puro | 69,0 tok/s | 96,5 tok/s | 50,4 tok/s |
| Risposta lunga (512 tok) | 91,4 tok/s | 144,4 tok/s | 49,8 tok/s |
| Contesto configurato | 65.536 | 65.536 | 65.536 |
Decode misurato col metodo a due punti: t(1 token) e t(N token). Non dipende da come il server raggruppa i pacchetti dello streaming.
Sedici prove con verifica automatica: nessuna si basa sul giudizio di chi guarda.
Aritmetica, problema a più passi, istruzione alla lettera, JSON parsabile, estrazione di un codice da un documento di diecimila token, onestà quando il testo manca, spagnolo, traduzione, codice Python eseguito davvero, sillogismo, conteggio, lista numerata, riassunto entro quindici parole, rifiuto di una password, conversione di unità, transitività.
A temperatura 0, lo stesso modello servito in tre modi non è identico al token:
attuale vs single: 13 testi su 16 identici
attuale vs batch: 10 su 16
single vs batch: 11 su 16
Differenze di formulazione, non di correttezza. Chi si aspetta parità al token fra due provider dello stesso modello si sbaglia.
La parte che di solito si omette.
Contesto lungo non testato. Tutte e tre le configurazioni partono a 65.536 token. I 150-262 mila dichiarati richiedono un profilo diverso, che non ho misurato.
Sedici prove non fanno un modello. Dicono che nulla si è rotto, non che il modello sia bravo. Nessun test su conoscenza ampia o matematica difficile.
Carico breve. Minuti, non ore. La stabilità sotto stress prolungato non è stata misurata.
Una macchina, una sessione. Varianza fra run intorno al 5-10%. Numeri riproducibili, non universali.
La prova di "onestà" è debole. Chiedevo un dato da un testo mai fornito: misura se ammette di non averlo, non se inventa. Per l'invenzione serve un test diverso.
Nessun giudizio umano. Non ho misurato se le differenze di testo cambiano il giudizio di chi legge.
Io ho misurato. Il merito dell'ingegneria è dei progetti, e va detto con i nomi.
Patch a vLLM, pipeline di riquantizzazione e drafter speculativo per far stare un 27B su una scheda da 24 GB. Autore: @mhenrichsen (syv.ai, Danimarca).
Il motore su cui girano entrambe le configurazioni, in due versioni diverse (0.27.1 e 0.31.0 con le patch). Senza vLLM non ci sarebbe niente da confrontare.
Il modello, in licenza Apache 2.0. Tutte le misure di questo report sono su di lui: la variabile è il servizio, non il modello.
@vllm_project, @Alibaba_Qwen e il repo
syv-ai/HyperQwen — è il modo più diretto per far validare il loro lavoro da chi
lo ha costruito, invece di lasciarlo circolare anonimo.