Varför blir svar från lokala LLM-modeller kortare under samtidig belastning?
Lokala LLM-svar blir kortare under belastning när serveringslagret byter generationsbudget mot samtidighet genom begränsningar, tidsgränser, företrädesbrytning eller misslyckade förfrågningar.
Modellen beslutar inte automatiskt att vara kortfattad för att en annan användare ansluter. Med en fast prompt och ett fast samplingstillstånd bör samtidighet främst påverka kö- och token-timing. Kortare svar visar att körmiljön, gatewayen, klienten eller minneshanteraren har ändrat ett effektivt stoppvillkor, avbrutit arbete eller returnerat en ofullständig dataström efter att belastningen passerat en tröskel.
Samtidighet utökar KV-minnet och aktiverar serveringsbegränsningar
Varje aktiv sekvens innehåller KV-cache-block som växer med det bibehållna kontextet och antalet genererade token. När flera förfrågningar delar på samma accelerator kan körmiljön sänka den maximala utmatningen, neka insläpp, avbryta en sekvens eller växla ut block till lagring för att hålla batchen inom minnesgränsen.
En serveringsdesign baserad på paged KV-cache-allokering använder paged KV-block för att minska fragmentering och möjliggöra högre samtidighet. Mekanismen förbättrar kapaciteten, men tydliggör också att varje aktiv sekvens förbrukar en växande minnesallokering tills den slutförs eller avlägsnas.
En gateway kan införa en separat tokenbudget per förfrågan eller globalt. Om budgeten härleds från tillgänglig kapacitet, prioritet eller ködjup får identiska promptar olika maximal utmatning, även om modellvikterna och samplingparametrarna verkar oförändrade.
Tidsgränser och företrädesbrytning kan returnera ett giltigt men ofullständigt svar
Interaktiva system tillämpar ofta tidsgränser i väggklocketid, tidsgränser för inaktiva dataströmmar eller klientavbrott. Långsammare leverans mellan token under belastning når dessa gränser tidigare i det semantiska svaret, och vissa API:er returnerar redan utskickade token i stället för ett tydligt fel.
Metoden med chunked prefill delar upp promptbearbetningen i mindre delar för att förhindra att långa prefills blockerar avkodningen. Arbetet visar hur schemaläggningsändringar påverkar tiden till första token och latensen mellan token vid blandad förfrågningsbelastning. Denna skillnad förblir synlig under senare tester i hemmet.
Företrädesbrytning kan bevara en förfrågan för senare återupptagning, starta om den eller avbryta den, beroende på motorn. Om klienten kopplas från under pausen kan servern logga ett avbrott medan gränssnittet visar ett grammatiskt men ofullständigt prefix som ett färdigt svar.
Sampling i sig bör inte ha ett tillförlitligt samband med belastning
Stokastisk avkodning ger naturligt varierande längder när temperatur och slumpfrö skiljer sig åt. Den variationen kan sammanfalla med belastning i små urval, men samtidighet har ingen direkt semantisk signal om inte delat tillstånd, en adaptiv policy eller ett programvarufel ändrar avkodningsvägen.
Forskning om SLO-medveten schemaläggning modellerar dirigering och schemaläggning samtidigt som målen för tiden mellan token skyddas. Åtskillnaden mellan genomströmning, TTFT och avkodningstidsgränser visar varför kapacitetspolicy måste mätas separat från modellens utmatningskvalitet. Mellanresultatet måste förbli granskningsbart innan automatisering införs.
Felgränsen går vid att skylla på schemaläggaren innan stoppmetadata har kontrollerats. Slutsekvenstoken, uttryckliga längdbegränsningar, klientavbrott, serverns tidsgränser, OOM-fel och transportfrånkopplingar är olika orsaker. Endast upprepade, kontrollerade längdförskjutningar med motsvarande stopporsaker stöder en belastningsmekanism.
Jämför längd och stopporsak vid fasta samtidighetsnivåer
Spela upp fasta promptar och slumpfrön med en, två, fyra och åtta samtidiga förfrågningar. Registrera begärt maximalt antal token, faktiska utmatningstoken, avslutsorsak, kötid, TTFT, latens mellan token, tidsgräns i väggklocketid, klientfrånkoppling, antal företrädesbrytningar, antal KV-byte, ledigt VRAM och serverfel.
Koppla minnesbeteendet till gränser för samtidiga arbetsbelastningar och upprepa sedan utan gateway-tidsgränser och med en fast insläppsgräns. Bevara promptar, mallar, sampling och klientkod så att den enda avsedda förändringen är samtidigheten. Den gränsen bör mätas separat under realistiska driftförhållanden.
Behandla kortare utmatning som ett serveringsfel när slutförandegraden eller den semantiska täckningen sjunker innan den annonserade budgeten har utnyttjats. Om endast latensen ökar medan avslutsorsakerna förblir EOS bör fler försök med fasta slumpfrön samlas in; om tidsgränser eller begränsningar dominerar ska dessa policyer synliggöras och dimensioneras uttryckligen.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Varför separeras ansiktssökningskluster efter att foton har roterats?
Se hur orienteringsmetadata, pixelrotation, ansiktsjustering, beskärningsgeometri, omsampling och kvalitetsgränser delar upp ansiktssökningskluster efter rotation.
Varför hoppar diagram för smarta hem när sensorernas tidsstämplar avrundas?
Lär dig hur avrundning, tidsintervall, aggregering, interpolering, tidszoner och duplicerade tidsstämplar skapar konstgjorda hopp i diagram för smarta hem.
Varför visas godkännandeuppmaningar för agenter igen efter att webbläsaren har uppdaterats?
Lär dig hur sidstatus, sessionslagring, serverarbetsflödesposter, godkännandets omfattning, idempotens och utgångstid gör att agentprompter visas igen efter en uppdatering.
