Server IA locale: come calcolare la concorrenza reale prima di promettere un assistente privato a tutto il team

Il numero della demo non è la capacità del servizio

Un modello che genera testo rapidamente per una sola persona non dimostra, per questo solo fatto, di avere capacità per un team. La demo isolata parte spesso da una richiesta breve, senza coda, con cache e processo già caldi e senza altre conversazioni che trattengono memoria. Un servizio condiviso funziona in condizioni diverse: le richieste arrivano con ritmi irregolari, hanno input e output eterogenei, competono per la memoria della GPU e attendono quando il sistema non può eseguirle subito.

La capacità utile non dovrebbe essere comunicata come un unico valore di token al secondo. È preferibile esprimerla come un impegno condizionato: per scenari definiti di input e output, una determinata concorrenza mantiene obiettivi di tempo al primo token, tempo totale di risposta e tasso di rifiuto o attesa. Questa formulazione permette di confrontare una promessa interna con un test ripetibile ed evita estrapolazioni da una demo favorevole.

Nel serving di modelli generativi esistono metriche distinte per tempo in coda, tempo al primo token, tempo di generazione, latenza tra token e latenza end-to-end. La distinzione conta perché due configurazioni con la stessa prestazione media possono offrire esperienze molto diverse: una può iniziare a rispondere presto ma finire lentamente; un'altra può ritardare l'avvio per accumulo di lavoro. Le guide ai modelli locali e i confronti tra runtime devono considerare queste dimensioni separatamente prima di raccomandare una configurazione.

La domanda operativa non è semplicemente «quante persone ci sono in azienda?». È: «quante richieste attive, di quali dimensioni e con quale obiettivo di latenza devono essere sostenute nello stesso momento?». Trenta persone con uso occasionale possono implicare una concorrenza ridotta. Al contrario, poche automazioni che allegano documenti estesi o producono risposte lunghe possono saturare lo stesso server. La misurazione deve rappresentare questi carichi, non un'idea astratta di utente.

Definite il servizio prima di scegliere o ampliare l'hardware

Iniziate descrivendo la domanda prevista in unità osservabili dal server. Registrate il numero di richieste attive, non solo gli utenti registrati; la distribuzione dei token di input; il massimo di output consentito; il tipo di attività; il tasso di arrivo; e gli obiettivi di disponibilità e latenza. Se non esiste traffico storico, formulate ipotesi esplicite e testate scenari conservativi. Una stima non diventa un fatto solo perché viene espressa con precisione numerica.

Separate almeno tre classi di lavoro. La chat breve ha in genere pochi input e output moderati. Una richiesta con retrieval augmented generation può includere estratti di documenti e avere un input consistente anche se la risposta è breve. Redazione, estrazione o generazione di codice possono richiedere output lunghi e mantenere attiva la conversazione più a lungo. Riunirle in un'unica media nasconde i casi che consumano più memoria o bloccano la coda.

Per ogni classe definite un budget: token di input tipici e massimi, token di output tipici e massimi, richieste simultanee previste e limiti di esperienza. L'obiettivo di latenza deve includere almeno il tempo al primo token e il tempo al completamento. Dovete inoltre decidere se un utente può annullare una generazione, cosa accade al raggiungimento di un limite e se esistono classi prioritarie. Senza queste regole, la capacità dipende da decisioni implicite prese dal runtime sotto pressione.

Il confronto tra modelli locali è utile solo dopo aver fissato questo contratto di servizio. Un modello più piccolo può consentire maggiore concorrenza o risposte più prevedibili sullo stesso hardware; un altro può essere giustificato dalla qualità per un carico specifico, ma richiedere limiti più severi. Non esiste una configurazione universalmente sufficiente: la decisione deve collegare la qualità richiesta ai risultati misurati con il proprio modello di utilizzo.

Costruite un budget di memoria, senza confonderlo con una garanzia

La memoria disponibile per servire un modello non coincide con la dimensione pubblicata dei suoi pesi. Devono convivere pesi caricati, cache di chiavi e valori delle conversazioni attive, buffer e spazio temporaneo di esecuzione, strutture del runtime e una riserva per variazioni e recupero. La ripartizione esatta dipende dal modello, dalla quantizzazione, dal runtime, dall'hardware e dalla configurazione; quindi una formula generica non deve essere presentata come se fosse una misurazione universale.

La cache KV è decisiva per la concorrenza. Conserva lo stato di attenzione necessario per proseguire una sequenza e cresce con i token elaborati. In un servizio, la sua occupazione cambia per richiesta: una conversazione estesa, un input recuperato di grandi dimensioni o un output lungo possono trattenere una quota rilevante di memoria più a lungo di una domanda breve. La ricerca su PagedAttention individua la gestione di questa cache, inclusi frammentazione e duplicazione in determinati schemi, come un elemento che condiziona la dimensione effettiva del batch.

È ragionevole usare un budget operativo per pianificare, purché sia etichettato come stima. Misurate prima la memoria di base con il modello già caricato e senza traffico. Osservate poi come cambia eseguendo ogni scenario con lunghezze controllate e concorrenza crescente. Riservate capacità non assegnata al carico nominale. Infine, verificate che la politica di ammissione eviti di oltrepassare il limite durante una raffica. Il risultato rilevante è il comportamento osservato nella configurazione concreta, non un calcolo isolato.

Le metriche del runtime possono esporre utilizzo della cache KV, richieste in esecuzione e richieste in attesa, oltre a misure di prefill e decode. Queste osservazioni consentono di attribuire un incidente con maggiore cautela: non dimostrano da sole un'unica causa fisica, ma aiutano a distinguere una coda crescente da una pressione sostenuta sulla cache o da una generazione lenta. Conservate la configurazione che ha prodotto ogni serie temporale affinché l'analisi sia riproducibile.

Prefill e decodifica: due fasi, due possibili colli di bottiglia

La richiesta non consuma risorse nello stesso modo durante tutta la sua vita. Nel prefill il sistema elabora l'input per costruire lo stato usato dalla generazione. Nella decodifica produce token successivi e aggiorna quello stato. Una richiesta con un documento lungo può avviarsi lentamente anche se la risposta è breve; una risposta estesa può iniziare presto e tuttavia trattenere risorse a lungo. Misurare solo la durata completa cancella questa differenza.

Il tempo al primo token è un segnale utile per l'utente e spesso riflette sia l'attesa in coda sia il lavoro preliminare necessario per iniziare a generare. La latenza tra token, il tempo per token di output e il tempo totale offrono un'altra prospettiva sulla fase di generazione. Conviene registrare anche la dimensione effettiva di input e output, perché una variazione di tali lunghezze può spiegare una variazione apparente di latenza senza alcun cambiamento dell'hardware.

Il batching continuo può aumentare l'utilizzo mescolando lavoro di richieste diverse, ma non elimina i limiti di memoria né garantisce equità tra i carichi. Un carico con contesto ampio può competere con chat brevi; le decisioni dello scheduler incidono su chi inizia prima e su chi resta in coda. Per questo un test rappresentativo deve includere sia batch omogenei sia una miscela controllata di scenari, riportati separatamente.

Non interpretate una riduzione della prestazione media come una diagnosi automatica. Può derivare da arrivi più rapidi della capacità di servizio, input più lunghi, un massimo di output elevato, pressione di memoria o una politica di pianificazione. La strumentazione deve fornire contesto sufficiente per identificare correlazioni e, se non è possibile attribuire la causa, deve dichiarare l'incertezza.

Dalla VRAM a una concorrenza operativa

La concorrenza operativa è il maggior numero di richieste che il servizio può ammettere, per uno scenario definito, senza violare i suoi obiettivi. Non va dedotta direttamente dalla memoria libera né da un massimo teorico di contesto. La memoria può essere sufficiente e, nondimeno, la coda o la latenza possono superare il budget. Al contrario, un risultato accettabile a una certa concorrenza non convalida un carico con input o output maggiori.

Costruite una matrice di test. In una dimensione ponete classi di carico e relative lunghezze di input e output. Nell'altra aumentate le richieste simultanee. Per ogni cella ripetete il test dopo il riscaldamento e raccogliete percentili di attesa, TTFT, latenza di generazione e tempo end-to-end. Annotate token realmente elaborati, uso della cache, richieste attive e in coda, annullamenti, rifiuti ed errori. Le medie possono essere aggiunte, ma non devono sostituire i percentili.

La capacità deve essere definita dal peggior risultato accettato, non dal massimo che arriva a completare un'esecuzione. Se il p95 di avvio supera l'obiettivo, se la coda cresce in modo persistente o se compaiono errori di memoria, quella concorrenza non è capacità operativa per quello scenario. Può restare un punto di guasto studiato, utile per regolare i limiti, ma non una promessa all'utente.

È inoltre importante testare il recupero dopo la pressione. Dopo una raffica, osservate se la coda torna a livelli normali, se la memoria viene liberata come previsto e se le nuove richieste recuperano la latenza abituale. Un sistema che completa un breve test ma non recupera rapidamente può essere fragile per un'API interna.

Usate code e ammissione esplicite prima di arrivare al guasto

La coda non è necessariamente un errore: può essere una decisione controllata per proteggere richieste già avviate. Il problema nasce quando non esiste un limite, quando l'utente non sa di essere in attesa o quando si continua ad accettare lavoro che non potrà rispettare il budget. Una politica di ammissione deve decidere, prima di assegnare risorse, se una richiesta può entrare, attendere, ricevere un limite inferiore oppure essere rifiutata con una risposta chiara.

I controlli abituali includono limiti per utente o credenziale, massimo di token di input, massimo di output, numero massimo di richieste attive, lunghezza massima della coda e tempo massimo di attesa. L'annullamento deve liberare lavoro e memoria in modo verificabile. Se esistono classi prioritarie, documentatele: una priorità non crea capacità, ma distribuisce diversamente una capacità limitata.

Il degrado deve essere esplicito e compatibile con il caso d'uso. Per esempio, un'interfaccia può chiedere all'utente di ridurre i documenti allegati, applicare un limite di output dichiarato o rinviare un'attività non interattiva. Non è appropriato troncare silenziosamente informazioni critiche né cambiare modello senza informare quando questo altera il risultato atteso. La politica deve stabilire cosa accade prima che il runtime incontri un errore di memoria insufficiente.

I contatori delle richieste in attesa e in esecuzione, insieme alle metriche di lavoro di prefill e decode, permettono di valutare se le regole proteggono il servizio. Testate deliberatamente un carico superiore a quello ammesso: verificate che il nuovo lavoro venga limitato e che la latenza delle richieste in corso non peggiori senza controllo. Questo test di sovraccarico è importante quanto il test nominale.

Protocollo riproducibile sul proprio hardware

Un test utile deve poter essere ripetuto. Bloccate e registrate l'identità del modello disponibile, la sua quantizzazione, il runtime, la versione del driver, il tipo e il numero di GPU, i limiti di contesto e output, i parametri di batching e la politica di ammissione. Se una di queste variabili cambia, trattate il risultato come una nuova misurazione, non come una continuazione automatica della precedente.

Preparate un carico sintetico basato sugli scenari definiti, senza usare conversazioni reali salvo autorizzazione specifica e controlli adeguati. Il carico deve fissare o registrare le lunghezze di input e output. Eseguite un riscaldamento separato dalla misurazione, fate più ripetizioni e mantenete un periodo di osservazione sufficiente a rilevare code in crescita. Riportate p50, p95 e p99 quando il volume di campioni ne consente l'interpretazione; insieme a essi, indicate numero di richieste e intervallo di prova.

La documentazione di benchmarking di vLLM contempla metriche quali TTFT, tempo per token di output e latenza tra token, e avverte che la cache dei prefissi può migliorare i risultati se non viene controllata. Se utilizzate una cache dei prefissi in produzione, testatela in modo rappresentativo e dichiarate se i prompt si ripetono; se non rappresenta il carico previsto, disattivatela o separatela in un altro scenario. Un risultato che dipende da un riuso irrealistico non è una stima prudente della capacità.

Non basta conservare una dashboard. Salvate un riepilogo della configurazione, il generatore di carico, i parametri, i risultati aggregati e i criteri di accettazione. La riproducibilità permette di confrontare un aggiornamento del modello o del runtime e di scoprire regressioni. Evita inoltre che una decisione di acquisto o distribuzione dipenda da ricordi di una demo precedente.

Decidere con evidenze: limiti, cambio di modello o più hardware

Con i risultati raccolti, decidete rispetto al requisito, non all'intuizione. Mantenete la configurazione se soddisfa gli scenari prioritari con margine e recupera dopo i picchi. Riducete il contesto o il massimo di output quando il prodotto può farlo esplicitamente e i test mostrano che la misura ripristina gli obiettivi. Limitate la concorrenza se il modello di domanda ammette un'attesa controllata. Separare i carichi può essere preferibile quando le attività su documenti lunghi interferiscono con la chat interattiva.

Aggiungere GPU o cambiare architettura è ragionevole solo dopo aver identificato quale vincolo si vuole alleviare. Se domina la pressione sulla cache, sono centrali il budget di memoria e la distribuzione del contesto. Se il prefill di input lunghi non rispetta il TTFT, valutate separatamente quella fase. Se la qualità del modello non soddisfa l'attività, una maggiore concorrenza non risolve il problema. L'evidenza di un test non consente di dedurre automaticamente quale alternativa sarà ottimale senza misurarla.

Anche cambiare modello richiede di ripetere la matrice. Due modelli con denominazioni di dimensione simile possono usare configurazioni di contesto, quantizzazioni e runtime diversi. Il cambiamento può modificare sia la memoria di base sia il comportamento di generazione. In un confronto interno, comunicate le condizioni complete e non attribuite alla dimensione dei pesi una causalità che non sia stata isolata.

Se non esiste una configurazione che soddisfi il requisito con limiti accettabili, la decisione onesta può essere di non distribuire ancora il servizio condiviso. È preferibile offrire un pilota limitato, con perimetro chiaramente definito, piuttosto che promettere un assistente privato generalista senza budget di capacità. L'inventario dei modelli locali e i confronti devono presentare questa conclusione come una possibilità operativa, non come un fallimento.

Privacy, telemetria e checklist di distribuzione

La strumentazione della capacità non deve creare un archivio parallelo di conversazioni. Le specifiche di telemetria per l'IA generativa avvertono che messaggi di input, output, istruzioni e argomenti possono contenere informazioni sensibili o dati personali. Per misurare la concorrenza non è di norma necessario memorizzare il testo completo: lunghezze in token, timestamp, identificatori pseudonimizzati, esito dell'ammissione e metriche di latenza sono spesso sufficienti.

Prima di abilitare tracce dettagliate, definite quali campi vengono raccolti, per quale diagnosi, chi vi accede, per quanto tempo vengono conservati e come vengono eliminati. Se prompt o risposte vengono trattenuti per il debug, l'eccezione deve avere una giustificazione, controlli di accesso e un periodo di conservazione limitato. Verificate inoltre se attributi apparentemente innocui, come nomi degli strumenti o argomenti, possano rivelare informazioni aziendali.

L'evidenza minima per una distribuzione interna include contratto di servizio, scenari, ambiente tecnico, metodo di carico, percentili per scenario, comportamento oltre il limite, politica di ammissione e trattamento della telemetria. Distinguete sempre tra ciò che è stato misurato, ciò che è stimato e ciò che non è ancora stato testato. Questa disciplina permette di adeguare il servizio senza trasformare un dato di demo in una garanzia non supportata.

La capacità non è permanente. Cambiamenti di modello, quantizzazione, driver, runtime, parametri di contesto, cache o politica di pianificazione possono invalidare risultati precedenti. Programmate una ripetizione del test quando cambiano elementi rilevanti e monitorate in produzione che le distribuzioni reali di input, output e attesa non si allontanino dagli scenari approvati.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.