Hardware e latenza misurata

Ogni valore qui riportato indica l'hardware su cui è stato misurato, e le stime sono indicate esplicitamente come tali.

Tutte le misurazioni utilizzano lo stesso set di riferimento di 50 foto con i medesimi prompt. La metodologia completa, gli intervalli di confidenza e le esecuzioni vere e proprie si trovano in eval/BASELINE.md e eval/PERFORMANCE.md.

I profili

Entrambe le varianti di lite funzionano su CPU. Anche quality funziona su CPU, ma molto lentamente, ed è pensato a tutti gli effetti per GPU.

quality su GPU: misurazioni

Entrambe le righe: Qwen3-VL-8B-Instruct Q4_K_M + F16 mmproj, contesto 8192, immagini ridotte a 896 px, llama.cpp llama-server b10380, pod a noleggio, 50 foto. Entrambe includono circa 0,35-0,6 s di round trip di rete e proxy che un container sulla tua macchina non sconta, quindi l'elaborazione locale è più veloce di questi numeri, non più lenta. Accuratezza sulla stessa esecuzione: 72,8% di recall sugli elementi principali con zero allucinazioni sui 50 piatti, statisticamente indistinguibile dal modello cloud di punta usato in modo predefinito da openplate.

Qualsiasi scheda da circa 24 GB di quella classe va bene. È ciò che abbiamo misurato; non ne abbiamo provata una più piccola.

Soglia minima di VRAM. I pesi occupano 4,68 GiB (Q4_K_M) + 1,08 GiB (vision tower F16) = 5,8 GiB, e il working set totale misurato con contesto a 8192 e 2 slot è stato di 6,3 GB. Di conseguenza una scheda di classe 12 GB dovrebbe bastare senza problemi e una scheda da 8 GB è plausibile ma al limite (probabilmente dovresti ridurre il contesto o scaricare parte del modello). Si tratta di un calcolo teorico, non di un valore testato: 24 GB è l'unica dimensione che abbiamo misurato. Se provi con 12 GB e funziona, è un'informazione utile.

La vera variabile è la larghezza di banda della memoria, non la VRAM

La velocità di generazione su una singola richiesta è limitata dalla larghezza di banda: ogni token scorre l'intero set di pesi attivi. Le due schede misurate appartengono entrambe all'incirca alla classe ~1.000 GB/s (RTX 4090 ≈ 1008 GB/s, RTX 3090 ≈ 936 GB/s), e i relativi p50 misurati seguono questo andamento: 0,94 s contro 1,72 s.

Stima, non una misurazione: una scheda di classe ~300 GB/s (L4, e il segmento adatto all'inferenza della maggior parte delle schede per workstation) ha circa 3 volte meno larghezza di banda rispetto alla 3090, portandola a una stima di 4-6 s per scansione. Si tratta di una stima proporzionale calcolata a partire dalla riga della 3090, non di una misurazione diretta, e i valori effettivi sono in genere peggiori di una semplice scala lineare.

CPU: misurato

Host per ogni riga seguente: AMD Ryzen 9 7940HS, 14 thread, nessuna GPU (-ngl 0), llama.cpp llama-server, contesto 8192, le stesse 50 foto.

lite: la riga su cui basare la configurazione. Misurato il 2026-08-13 tramite il servizio incluso: esattamente questo codice, la sua riduzione a 896 px, la sua grammatica, la sua mappatura dell'output, 50 immagini su 50, 0 errori, richieste sequenziali su loopback.

Fonte: eval/runs/2026-08-13-lite-cpu-v3/results.json. Quella sessione ha misurato solo la latenza, senza valutare l'accuratezza. Il valore di recall di lite proviene da una sessione diversa (2026-08-12: 62,1 % di recall sugli elementi base, motivo per cui lite è documentato come base minima per chi ha risorse limitate e non come configurazione principale). Due sessioni, due numeri, citati separatamente.

La latenza aumenta con la complessità del piatto e con il numero di thread. Il costo di una scansione dipende dalla lunghezza del prompt, cioè dai token letti dal modello per quella foto, e il prompt per una colazione completa era quattro volte più lungo rispetto a quello per un piatto semplice. Due scansioni misurate tramite il servizio distribuito sullo stesso modello di CPU, all'interno di una macchina virtuale con 6 vCPU e i 4 thread predefiniti (2026-09-27):

Di conseguenza, su una comune macchina con CPU, calcola da circa 5 secondi a un minuto per piatto: il limite inferiore con molti thread e un piatto semplice, quello superiore con pochi thread e uno ricco. Si tratta di due singole scansioni, non di una distribuzione.

quality sulla stessa CPU: ≈94 s / piatto (p50, 2026-08-12), misurato con una pipeline precedente e più prolissa alla risoluzione massima dell'immagine, e non ricalcolato con la pipeline definitiva, quindi consideralo come un limite superiore. quality è un profilo GPU.

RAM (RSS misurata): lite 1,55 GB, quality 6,31 GB.

Il throughput della CPU non migliora con la concorrenza. Dati misurati: due richieste simultanee costano da 0,75 a 0,83× rispetto alle stesse due eseguite in sequenza, con un recupero del throughput da 1,2 a 1,3× su un fan-out di 2×, pagato del tutto in latenza per richiesta (una richiesta da sola 2,5 s; due contemporanee, 3,7 s ciascuna). Pianifica la capacità come se la macchina fosse seriale.

Macchina minima con CPU per lite: Oltre 8 core moderni con AVX2, 4 GB di RAM libera (1,55 GB per il modello, margine per tutto il resto), circa 3 GB di disco (1,96 GiB di pesi più l'immagine, circa 1 GB). 8 thread invece di 14 raddoppiano all'incirca la latenza per ogni piatto. Nessuna GPU, niente CUDA, nessuna chiamata esterna, come verificato da scripts/smoke-lite.sh, che compila l'immagine CPU, la avvia senza GPU e vi elabora una foto reale.

Nessun limite massimo di latenza per impostazione predefinita

LATENCY_CEILING_MS ha come valore predefinito 0, vale a dire disattivato. Una macchina che riducesse il carico a una determinata soglia rifiuterebbe richieste che è perfettamente in grado di gestire, e su CPU una scansione richiede legittimamente da qualche secondo a diversi minuti. L'esperienza d'uso adatta è asincrona: scatti la foto, metti via il telefono, il piatto viene analizzato prima che tu guardi di nuovo. Ciò che non funziona su CPU è un'anteprima in tempo reale che si aggiorna mentre componi l'inquadratura.

Se vuoi impostare un limite sulla tua macchina, imposta LATENCY_CEILING_MS=10000 e il servizio inizierà a rifiutare il lavoro che non può terminare in dieci secondi. La maggior parte degli utenti con server proprio dovrebbe lasciarlo disattivato.