Un modello IA domestico può servire in modo affidabile da uno a diversi utenti interattivi, ma il limite stabile dipende dalla richiesta di token, dal batching e dagli obiettivi di latenza.
Un modello che genera 30 token al secondo può sembrare veloce per una breve chat individuale, ma rallentare quando quattro persone inviano contemporaneamente prompt lunghi. La concorrenza consuma memoria della cache KV, condivide la capacità di decodifica e crea picchi nelle code. Il limite corretto è il carico offerto massimo che continua a rispettare un obiettivo p95 definito per il primo token e la velocità dei token durante il normale utilizzo familiare.
La concorrenza trasforma il throughput in tempi di attesa
Una stima approssimativa della capacità divide il throughput di generazione sostenuto per la media dei token richiesti al secondo nelle sessioni attive. Quando la domanda si avvicina alla capacità del servizio, piccoli picchi creano code lunghe. Gli utenti non sono unità identiche: una risposta di 50 token e una di 2.000 token impegnano il server in modo diverso.
Un'analisi di latenza e throughput spiega che il batching migliora il throughput complessivo, spesso a scapito della latenza della singola risposta. Questa tensione determina se le sessioni aggiuntive risultano stabili.
Il prefill del prompt può inoltre bloccare il lavoro di decodifica, a seconda dello scheduler. Due utenti che incollano documenti voluminosi possono penalizzare tutti più di sei utenti che pongono domande brevi. Un numero di utenti privo della distribuzione di prompt e output non è quindi trasferibile.
La cache KV e la pianificazione creano un secondo limite
Ogni sequenza attiva memorizza le chiavi e i valori dell'attenzione relativi al proprio contesto. Cronologie più lunghe e batch più grandi aumentano l'utilizzo della cache KV finché le richieste non vengono rifiutate, spostate o ritardate. Il batching continuo può accettare nuovo lavoro tra un'iterazione di decodifica e l'altra, migliorando l'utilizzo ma senza creare memoria aggiuntiva.
Una spiegazione tecnica del batching continuo mostra come la pianificazione a livello di iterazione riempia gli slot del batch altrimenti inattivi. Il vantaggio dipende dal carico di lavoro e può aumentare leggermente la contesa per richiesta.
La latenza diventa instabile in prossimità della saturazione, perché la lunghezza della coda reagisce bruscamente alla variabilità degli arrivi. La latenza media può aumentare gradualmente, mentre la latenza p95 e quella massima fanno un balzo. La capacità stabile dovrebbe collocarsi al di sotto di quel punto critico, non al valore massimo di token al secondo del benchmark.
Quando il numero di utenti smette di prevedere l'esperienza
Lo stesso server può supportare più utenti per il completamento automatico che per RAG, utilizzo di strumenti o generazione di testi lunghi. Avvii a freddo, throttling termico, recupero delle informazioni e sintesi vocale aggiungono fasi esterne all'erogazione del modello. Un dato sulla concorrenza del solo modello non può garantire la reattività dell'intera applicazione.
Una guida all'erogazione su memoria per l'erogazione descrive memoria, contesto, batching e parallelismo come vincoli interdipendenti. La modifica di uno qualsiasi di questi elementi può spostare il punto critico della capacità.
La previsione non è valida nemmeno se le richieste della famiglia arrivano in picchi sincronizzati invece che in modo indipendente. Quattro utenti che raramente si sovrappongono possono essere facili da gestire, mentre due agenti automatizzati possono saturare continuamente il modello. Misura il lavoro offerto, non gli account registrati.
Individua il punto critico della concorrenza con un test di carico
Riproduci richieste realistiche brevi, mediane e lunghe con una, due, quattro e otto sessioni concorrenti. Mantieni invariati modello, quantizzazione, limite del contesto e campionamento. Registra il tempo in coda, la latenza del primo token, la latenza tra i token, il tasso di completamento, l'utilizzo della cache KV e i valori p50, p95 e massimi.
Usa l'architettura delle sessioni con modello condiviso come contesto del test quando diverse sessioni domestiche condividono un unico modello. Mantieni le fasi RAG e degli strumenti disattivate oppure misurale separatamente.
Dichiara come limite stabile il livello massimo di concorrenza in cui la latenza p95 del primo token resta entro l'obiettivo domestico, senza una tendenza crescente della coda né errori di memoria. Mantieni un margine di throughput del 20–30% per gestire i picchi. Ripeti il test ogni volta che cambiano la lunghezza del contesto, il modello o lo scheduler.
Hub Tecnologico e AI
Altro da leggere

Come misurare la qualità del recupero RAG locale e interpretare recall, precisione e copertura delle citazioni
Crea un set di test RAG locale, calcola le metriche di base del recupero, interpretane i compromessi e verifica se le affermazioni nelle risposte...

Perché l’elaborazione delle funzionalità della casa intelligente diventa più importante all’aumentare del numero di sensori con la stessa frequenza di campionamento?
Monitora i calcoli per sensore e tra sensori all’aumentare del numero di dispositivi, identifica i costi di fusione non lineari e valuta le prestazioni...

Perché il costo della valutazione RAG diventa più importante con l’aumentare della libreria di documenti, a parità di volume di query?
Comprendi perché la crescita del corpus aumenta lo sforzo di valutazione del RAG senza un aumento delle query degli utenti e come i test...

