Perché le risposte dei modelli LLM locali diventano più brevi sotto carico concorrente?
Le risposte degli LLM locali diventano più brevi sotto carico quando il livello di serving sacrifica il budget di generazione a favore della concorrenza tramite limiti, scadenze, preemption o richieste non riuscite.
Il modello non decide intrinsecamente di essere conciso perché è arrivato un altro utente. A prompt e stato di campionamento invariati, la concorrenza dovrebbe modificare principalmente i tempi di coda e di generazione dei token. Risposte più brevi indicano che il runtime, il gateway, il client o il gestore della memoria ha modificato una condizione effettiva di arresto, annullato l'elaborazione o restituito uno stream parziale dopo che la pressione ha superato una soglia.
La concorrenza espande la memoria KV e attiva i limiti del serving
Ogni sequenza attiva mantiene blocchi di cache KV che crescono con il contesto conservato e i token generati. Quando diverse richieste condividono lo stesso acceleratore, il runtime può ridurre l'output massimo, rifiutare l'ammissione, sospendere una sequenza o trasferire blocchi per mantenere il batch entro i limiti di memoria.
Un'architettura di serving basata sull'allocazione paginata della cache KV utilizza blocchi KV paginati per ridurre la frammentazione e consentire una maggiore concorrenza. Il suo meccanismo migliora la capacità, ma chiarisce anche che ogni sequenza attiva consuma un'allocazione di memoria crescente fino al completamento o all'espulsione.
Un gateway può imporre un budget di token separato per richiesta o globale. Se tale budget deriva dalla capacità disponibile, dalla priorità o dalla profondità della coda, prompt identici ricevono un output massimo diverso anche se i pesi del modello e i parametri di campionamento sembrano invariati.
Le scadenze e la preemption possono restituire una risposta parziale dall'aspetto valido
I sistemi interattivi applicano spesso scadenze di tempo reale, timeout dello stream inattivo o annullamenti da parte del client. Una consegna più lenta tra i token sotto carico raggiunge questi limiti prima nella risposta semantica, e alcune API restituiscono i token già emessi invece di mostrare un errore evidente.
Il metodo di prefill suddiviso in blocchi divide l'elaborazione del prompt in blocchi più piccoli per impedire che i prefill lunghi blocchino la decodifica. Questo lavoro dimostra come le modifiche alla pianificazione influenzino il tempo al primo token e la latenza tra i token sotto pressione da richieste miste. Questa distinzione resta visibile durante i successivi test domestici.
La preemption può conservare una richiesta per riprenderla in seguito, riavviarla o interromperla, a seconda del motore. Se il client si disconnette durante la pausa, il server può registrare l'annullamento mentre l'interfaccia mostra un prefisso grammaticalmente corretto ma incompleto come risposta terminata.
Il solo campionamento non dovrebbe correlare in modo affidabile con il carico
La decodifica stocastica produce naturalmente lunghezze variabili quando temperatura e seed casuale differiscono. Questa variazione può coincidere con il carico in piccoli campioni, ma la concorrenza non contiene alcun segnale semantico diretto, a meno che uno stato condiviso, una policy adattiva o un difetto software non modifichi il percorso di decodifica.
La ricerca sulla pianificazione consapevole degli SLO modella il routing e la pianificazione proteggendo al contempo gli obiettivi relativi al tempo tra i token. La separazione tra throughput, TTFT e scadenze della decodifica mostra perché la policy di capacità debba essere misurata separatamente dalla qualità dell'output del modello. Il risultato intermedio deve restare ispezionabile prima di procedere con l'automazione.
Il limite dell'analisi consiste nel dare la colpa alla pianificazione prima di aver controllato i metadati di arresto. Token di fine sequenza, limiti di lunghezza espliciti, annullamenti del client, scadenze del server, errori OOM e disconnessioni del trasporto sono cause diverse. Solo variazioni di lunghezza ripetute e controllate, accompagnate da motivi di arresto corrispondenti, supportano l'ipotesi di un meccanismo legato al carico.
Confronta lunghezza e motivo di arresto a livelli di concorrenza fissi
Riproduci prompt e seed fissi con una, due, quattro e otto richieste simultanee. Registra il numero massimo di token richiesti, i token di output effettivi, il motivo di completamento, il tempo in coda, il TTFT, la latenza tra i token, la scadenza di tempo reale, la disconnessione del client, il numero di preemption, i byte KV, la VRAM libera e l'errore del server.
Metti in relazione il comportamento della memoria con i limiti dei carichi di lavoro simultanei, poi ripeti senza timeout del gateway e con un limite di ammissione fisso. Mantieni invariati prompt, template, campionamento e codice client, in modo che l'unico cambiamento previsto sia la concorrenza. Questo limite deve essere misurato separatamente in condizioni operative realistiche.
Considera l'output più breve un difetto del serving quando il tasso di completamento o la copertura semantica diminuiscono prima di raggiungere il budget dichiarato. Se aumenta solo la latenza mentre i motivi di arresto restano EOS, raccogli più prove con seed controllati; se prevalgono timeout o limiti, rendi esplicite queste policy e dimensionale adeguatamente.
Prodotti consigliati
Hub Tecnologico e AI
Altro da leggere
Perché i cluster della ricerca facciale si separano dopo la rotazione delle foto?
Scopri come i metadati dell’orientamento, la rotazione dei pixel, l’allineamento dei volti, la geometria del ritaglio, il ricampionamento e le soglie di qualità suddividono...
Perché i grafici della casa intelligente fanno salti quando i timestamp dei sensori vengono arrotondati?
Scopri come arrotondamento, intervalli temporali, aggregazione, interpolazione, fusi orari e timestamp duplicati creano sbalzi artificiali nei grafici della smart home.
Perché le richieste di approvazione dell'agente ricompaiono dopo l'aggiornamento del browser?
Scopri come lo stato della pagina, l'archiviazione della sessione, i record del flusso di lavoro del server, l'ambito dell'approvazione, l'idempotenza e la scadenza fanno...
