Waarom worden lokale LLM-antwoorden korter bij gelijktijdige belasting?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Why Do Local LLM Responses Become Shorter Under Concurrent Load? - Zima Store Online

Lokale LLM-antwoorden worden bij belasting korter wanneer de servinglaag generatiebudget inruilt voor concurrency via limieten, deadlines, preëmptie of mislukte verzoeken.

Het model besluit niet inherent om beknopt te zijn omdat er een andere gebruiker arriveert. Bij een vaste prompt en samplingstatus zou concurrency vooral de wachtrij- en tokentiming moeten veranderen. Kortere antwoorden geven aan dat de runtime, gateway, client of geheugenbeheerder een effectieve stopconditie heeft gewijzigd, werk heeft geannuleerd of een gedeeltelijke stream heeft teruggestuurd nadat de druk een drempel overschreed.

Concurrency breidt het KV-geheugen uit en activeert servinglimieten

Elke actieve sequentie bevat KV-cacheblokken die groeien met de behouden context en gegenereerde tokens. Wanneer meerdere verzoeken één accelerator delen, kan de runtime de maximale uitvoer verlagen, toelating weigeren, een sequentie preëmpten of blokken verwisselen om de batch binnen de geheugenlimieten te houden.

Een servingontwerp op basis van paged KV-cachetoewijzing gebruikt gepagineerde KV-blokken om fragmentatie te verminderen en hogere concurrency mogelijk te maken. Het mechanisme verbetert de capaciteit, maar maakt ook duidelijk dat elke actieve sequentie een groeiende geheugentoewijzing verbruikt tot voltooiing of verwijdering.

Een gateway kan een afzonderlijk tokenbudget per verzoek of voor het geheel opleggen. Als dat budget wordt afgeleid van beschikbare capaciteit, prioriteit of wachtrijdiepte, ontvangen identieke prompts verschillende maximale uitvoerlengtes, ook al lijken de modelgewichten en samplingparameters ongewijzigd.

Deadlines en preëmptie kunnen een geldig ogend gedeeltelijk antwoord opleveren

Interactieve systemen leggen vaak deadlines voor de verstreken tijd, time-outs voor inactieve streams of clientannuleringen op. Een tragere levering van tokens tussen opeenvolgende tokens bereikt die limieten eerder in het semantische antwoord, en sommige API's retourneren de al uitgegeven tokens in plaats van een opvallende fout.

De methode voor gesegmenteerde prefill splitst promptverwerking op in kleinere delen om te voorkomen dat lange prefills het decoderen blokkeren. Dit werk laat zien hoe wijzigingen in planning de tijd tot de eerste token en de latentie tussen tokens beïnvloeden bij gemengde verzoekdruk. Dit onderscheid blijft zichtbaar tijdens latere tests in de thuisomgeving.

Preëmptie kan een verzoek bewaren voor latere hervatting, het opnieuw starten of afbreken, afhankelijk van de engine. Als de client tijdens de pauze de verbinding verbreekt, kan de server een annulering loggen terwijl de interface een grammaticaal maar onvolledig prefix als voltooid antwoord weergeeft.

Alleen sampling zou niet betrouwbaar met belasting moeten correleren

Stochastisch decoderen produceert van nature variabele lengtes wanneer temperatuur en willekeurige seed verschillen. Die variatie kan in kleine steekproeven samenvallen met belasting, maar concurrency heeft geen direct semantisch signaal, tenzij gedeelde status, adaptief beleid of een softwarefout het decodeerpad wijzigt.

Onderzoek naar SLO-bewuste planning modelleert routering en planning en beschermt tegelijk doelstellingen voor de tijd tussen tokens. Het onderscheid tussen throughput, TTFT en decode-deadlines laat zien waarom capaciteitsbeleid onafhankelijk van de uitvoerkwaliteit van het model moet worden gemeten. Het tussenresultaat moet controleerbaar blijven voordat automatisering het overneemt.

De foutgrens ligt bij het de planner de schuld geven voordat stopmetadata is gecontroleerd. End-of-sequence-tokens, expliciete lengtelimieten, clientannuleringen, serverdeadlines, OOM-fouten en transportverbindingen die worden verbroken zijn verschillende oorzaken. Alleen herhaalde, gecontroleerde verschuivingen in lengte met bijbehorende stopredenen ondersteunen een belastingsmechanisme.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Vergelijk lengte en stopreden bij vaste concurrency-stappen

Herhaal vaste prompts en seeds met één, twee, vier en acht gelijktijdige verzoeken. Noteer het aangevraagde maximumaantal tokens, het werkelijke aantal uitvoertokens, de voltooiingsreden, wachtrijtijd, TTFT, latentie tussen tokens, de deadline voor de verstreken tijd, verbroken clientverbindingen, het aantal preëmpties, KV-bytes, vrije VRAM en serverfouten.

Breng het geheugengedrag in verband met limieten voor gelijktijdige workloads en herhaal de test vervolgens zonder time-outs van de gateway en met een vaste toelatingslimiet. Behoud prompts, templates, sampling en clientcode, zodat concurrency de enige beoogde wijziging is. Die grens moet afzonderlijk worden gemeten onder realistische bedrijfsomstandigheden.

Behandel kortere uitvoer als een servingdefect wanneer het voltooiingspercentage of de semantische dekking daalt vóór het geadverteerde budget is bereikt. Als alleen de latentie stijgt terwijl de voltooiingsredenen EOS blijven, verzamel dan meer tests met vaste seeds; als time-outs of limieten domineren, maak dat beleid expliciet en stem de omvang ervan af.