Definire il risultato utile prima di cercare throughput
In interazione, misura l'attesa del primo token e quella della risposta completa. Per un corpus offline, misura il tempo necessario a ottenere tutti gli output attesi. In entrambi i casi, fissa la regola di accettazione: accuratezza su risposte note, qualità di una classificazione o estrazione di campi verificata. Un JSON sintatticamente valido può comunque contenere una risposta sbagliata.
Separa l'attesa in coda, l'elaborazione e il percorso completo osservato dal tuo client quando i tuoi strumenti lo permettono. Una misura interna al motore non ha gli stessi limiti di quella dell'applicazione. La documentazione delle metriche vLLM distingue in particolare attesa, primo token e durata totale: mantieni questa distinzione nei tuoi rilevamenti, qualunque sia il motore scelto.
Fonti tecniche: vLLM — metriche di richieste e latenza
Trasformare le tue richieste in criteri di scelta
Prepara input brevi, abituali e lunghi con identificatori stabili. Conserva modello, tokenizer, formato di conversazione e parametri di generazione. Conta i token realmente trasmessi, incluso lo storico e i documenti aggiunti dall'applicazione. Annota separatamente batch richiesto, concorrenza inviata e richieste effettivamente elaborate simultaneamente: non sono necessariamente gli stessi numeri.
| Input da fissare | Misura e unità | Conseguenza per la scelta |
|---|---|---|
| Prompt completo e limite di output | Token di input e output per richiesta | Verificare i casi lunghi e le risposte troncate al limite |
| Richieste simultanee e ritmo di arrivo | Richieste attive, in attesa e completate | Determinare il carico sostenibile con il tempo di risposta richiesto |
| Precisione, quantizzazione e cache | Picco di memoria per GPU, in byte o GiB | Scartare le impostazioni che superano la memoria sul carico previsto |
| Regola di qualità e riferimenti | Output accettati / output attesi; metrica di business | Confrontare solo le varianti che rispettano lo stesso criterio |
| Perimetro del cronometro | Primo token, risposta completa o corpus: secondi | Confrontare durate con gli stessi estremi |
| Calendario fino ai file recuperati | Finestra totale, in ore o giorni | Scegliere poi un piano di 3, 7 o 30 giorni |
Misurare la memoria con contesto e concorrenza
Per un modello autoregressivo che genera token per token, la cache KV conserva gli stati di attenzione. La sua dimensione dipende dal modello e dai token conservati. Una cache dinamica può crescere durante la generazione; una cache statica riserva una dimensione massima. Alcuni layer a finestra scorrevole limitano questa crescita. Testa quindi le lunghezze e la concorrenza previste con la strategia effettivamente utilizzata.
La quantizzazione dei pesi e quella della cache sono due scelte distinte. Per esempio, bitsandbytes sostituisce alcuni layer lineari con versioni quantizzate; questo non descrive tutte le allocazioni della tua esecuzione. Dopo un cambio di precisione, verifica di nuovo memoria e qualità invece di supporre che l'intero picco diminuisca nella stessa proporzione.
Con PyTorch, rileva separatamente il picco dei tensori allocati e quello della memoria riservata dall'allocatore. Non sommarli. Indica la GPU misurata e l'unità: 1 GiB corrisponde a 2³⁰ byte. Questi contatori non rappresentano necessariamente tutta l'occupazione del dispositivo. La cartella memoria ne dettaglia i limiti.
Fonti tecniche: Hugging Face Transformers 5.17 — strategie di cache KV · Hugging Face Transformers 5.17 — quantizzazione bitsandbytes · PyTorch 2.14 — gestione e contatori di memoria CUDA
Una prova misurabile su 300 documenti
Esempio da realizzare con il tuo corpus autorizzato: estrarre data, importo e categoria da 300 documenti. Rileggi i valori attesi, specifica la gestione dei campi assenti e fissa la soglia di accettazione prima della prova. Il numero di documenti descrive il protocollo; nessun tempo, punteggio o throughput è presunto.
- Fissa i 300 identificatori, la revisione del modello, i prompt, i limiti di token e la regola di parsing. Mantieni i documenti lunghi identificabili nel bilancio.
- Esegui un riferimento con una richiesta alla volta. Separa caricamento, warm-up e misurazione; conserva le predizioni e gli errori per documento.
- Aumenta poi un solo parametro: batch per un'elaborazione a gruppi, o concorrenza per un motore di richieste. Mantieni gli stessi input e criteri di qualità.
- Per ogni passaggio, rileva durata, picco di memoria, numero di identificatori ritrovati senza duplicati e output accettati. Ripeti le misurazioni e conserva i valori grezzi con la loro dispersione.
- Se una variante fallisce, annota il motivo: memoria, troncamento, formato o qualità. Un batch ridotto o una ripresa crea una decisione da documentare, non un fallimento da cancellare.
Fonti tecniche: IteraGPU — protocollo dettagliato di confronto a qualità equivalente
Usare le risorse di IteraGPU Lab v1 nel perimetro corretto
Il notebook e il suo script complementare propongono un calcolo dei pesi e una misurazione su una piccola rete sintetica. Il loro codice di misurazione è stato eseguito su una RTX 5070 locale con PyTorch 2.11.0, su una piccola configurazione in float32. Questa prova verifica quel caso di esecuzione; non misura né un LLM, né una cache KV, né le GPU del catalogo sulle tue richieste.
Usa il notebook per comprendere i contatori, poi misura il tuo carico reale con il suo ambiente. Il protocollo di qualità e la tabella grezza servono a preparare il confronto. Gli output del notebook distribuito e le righe di risultati del CSV restano vuoti; la procedura non installa alcun modello né driver. Leggi i prerequisiti del README prima dell'esecuzione.
- Notebook di memoria IteraGPU Lab v1
Calcoli e piccola rete sintetica per comprendere la misurazione della memoria.
- Protocollo di qualità da completare
Input fissi, accettazione degli output e confronto delle prove.
- Tabella grezza vuota
Una riga per passaggio reale, con parametri, misurazioni e verdetto.
- Prerequisiti e limiti di IteraGPU Lab v1
Istruzioni e portata precisa della prova locale già realizzata.
Passare dalle misurazioni a un'offerta
La tua scheda di scelta deve riunire ambiente compatibile, memoria per scheda, contesto, concorrenza, qualità raggiunta e tempi misurati. Confronta le configurazioni che soddisfano questi criteri, poi i pacchetti da 3, 7 e 30 giorni secondo il calendario completo: preparazione, elaborazione, valutazione, riprese ed export. Il calcolatore della cartella benchmark utilizza il pacchetto intero e corpus utili realmente convalidati.
Conserva questa scheda e le versioni del codice nel tuo quaderno. Scegli tu i software e le elaborazioni; IteraGPU non procede a un'ispezione del contenuto dei tuoi file, prompt o calcoli. Una scelta di ambiente all'ordine esprime la tua esigenza di preparazione: non costituisce una prova che il tuo modello sia già stato installato o testato.
Domande pratiche
24 GB bastano per il mio modello di inferenza?
La capacità di 24 GB non basta per rispondere senza conoscere il modello e il carico. Verifica insieme pesi, allocazioni di esecuzione, contesto e richieste simultanee. La configurazione deve completare i casi lunghi con la qualità richiesta; una dimensione di file o una stima dei pesi da sola non lo dimostra.
Quale throughput bisogna confrontare per un corpus offline?
Confronta prima la durata necessaria per completare e valutare lo stesso corpus. Se pubblichi un throughput, indica il numero di output utili accettati, il tempo considerato e gli errori. Un throughput in token al secondo senza lunghezza della risposta né controllo qualità non basta a distinguere due configurazioni.
Un superamento della memoria impone di cambiare GPU?
Un superamento della memoria richiede innanzitutto di identificare l'impostazione e l'input che l'hanno provocato. Puoi esaminare batch, concorrenza, lunghezza o precisione, conservando l'obiettivo del progetto. Qualsiasi riduzione che cambi i documenti trattati o le risposte attese impone una nuova verifica di qualità; più memoria può essere necessaria se queste condizioni devono essere mantenute.
Il notebook fornito convalida la mia applicazione di inferenza?
Il notebook fornito non convalida la tua applicazione: misura una piccola rete sintetica e spiega i contatori di memoria. La prova locale documentata riguarda solo questo caso. La tua applicazione deve essere valutata con il suo modello, i suoi input, il suo ambiente e i suoi criteri di accettazione prima di qualsiasi conclusione su capacità o prestazioni.