Welke invloed heeft acceleratorplanning op AI voor meerdere gebruikers thuis?

Acceleratorplanning beïnvloedt multi-user thuis-AI door te bepalen welke verzoeken starten, elke iteratie delen, hun geheugentoestand behouden of achter ander werk wachten.

Meerdere gebruikers in een huishouden kunnen prompts versturen met zeer uiteenlopende kosten: een korte vraag over lichtbediening, een lang document, een afbeelding, een spraakverzoek of een agent die veel aanroepen genereert. De accelerator kan het belang binnen het huishouden niet alleen op basis van aankomsttijd afleiden. Een planner moet wachtrijvolgorde, tokenbudgetten, batching, prioriteiten, geheugentoewijzing en modelresidentie combineren, terwijl de uitvoer onvoorspelbaar blijft. In de onderstaande secties wordt uitgelegd waarom dezelfde hardware eerlijk, snel of onbruikbaar kan aanvoelen, afhankelijk van hoe die keuzes worden gemaakt.

FIFO behandelt aankomsttijd als de enige prioriteit

Een first-in-first-out-wachtrij is eenvoudig, maar een lange prompt of respons kan veel korte verzoeken vertragen die later zijn aangekomen.

LLM-verzoeken hebben ongelijke tokenkosten, waardoor eerlijkheid die alleen op het aantal verzoeken is gebaseerd, één gebruiker veel meer acceleratortijd kan geven dan een andere.

FIFO is voorspelbaar bij lage belasting, maar veroorzaakt blokkering aan het begin van de wachtrij wanneer workloads binnen een huishouden uiteenlopend worden.

Continue batching deelt iteraties tussen gebruikers

Planners op iteratieniveau kunnen tussen decodeerstappen nieuwe reeksen toevoegen en voltooide reeksen verwijderen zonder telkens een vaste batch opnieuw op te bouwen.

De iteratieplanning van Orca verbetert de benutting en stelt meerdere gebruikers in staat tegelijk voortgang te boeken.

Delen garandeert geen gelijke snelheid. Een planner bepaalt nog steeds hoeveel reeksen worden toegelaten, hoe vaak elke reeks vooruitgaat en of een nieuwe prefill actieve decoderingen onderbreekt.

Prioriteitsbeleid beschermt latentiegevoelige verzoeken

Spraakbediening en korte interactieve chats kunnen snellere toelating verdienen dan achtergrondsamenvattingen, embeddings of het genereren van afbeeldingen.

Llumnix richt zich op latentieprioriteiten voor heterogene LLM-verzoeken.

Prioriteit moet veroudering of quota omvatten, zodat achtergrondtaken uiteindelijk worden uitgevoerd en één bevoorrechte gebruiker de rest van het huishouden niet kan uithongeren.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Geheugentoewijzing kan een verzoek blokkeren voordat het rekenen begint

Een verzoek heeft naast modelgewichten ook een KV-cache en werkruimte nodig. De planner kan toelating uitstellen, zelfs wanneer rekeneenheden inactief lijken, omdat er onvoldoende geheugenruimte beschikbaar is.

De gids van ZimaSpace over geheugendruk bij meerdere gebruikers legt uit waarom langere contexten verminderen hoeveel gesprekken actief kunnen blijven.

Het onderbreken van een reeks maakt capaciteit vrij, maar kan betekenen dat de toestand later opnieuw moet worden berekend of hersteld, waardoor geheugenbeleid extra latentie veroorzaakt.

Prefill en decode vereisen een verschillende aanpak bij planning

Lange prefills gebruiken veel rekenkracht, terwijl tokendecodering herhaaldelijk gewichten en cachetoestand uitleest. Als ze zonder controle samen worden uitgevoerd, kan gestreamde uitvoer vertragen.

Sarathi-Serve gebruikt planning zonder blokkeringen en opgedeelde prefill om de doorvoer te verbeteren en tegelijkertijd verstoring van de latentie te beperken.

Een thuisplanner kan decodeermogelijkheden reserveren voor actieve gesprekken en grote document-prefills opsplitsen, in plaats van één verzoek een lange iteratie te laten monopoliseren.

Eerlijkheid moet worden gemeten in termen die gebruikers merken

Het totale aantal tokens per seconde kan verbeteren terwijl één gebruiker veel langer wacht dan een andere. Houd wachtrijtijd, tijd tot het eerste token, vertraging tussen tokens, voltooiingstijd en het serviceaandeel per gebruiker of workloadklasse bij.

De Virtual Token Counter definieert tokenbewuste eerlijkheid in plaats van elk verzoek gelijk te tellen.

Gebruik expliciete klassen voor spraak, interactieve chat, agents, embeddings en onderhoudswerk. Test vervolgens overlappende lange en korte verzoeken om te controleren of het gekozen beleid overeenkomt met de verwachtingen binnen het huishouden.

Planning kan geen extra acceleratiecapaciteit creëren, maar kan wel bepalen of een tekort zich uit als een eerlijke vertraging, pieken in staartlatentie of één gebruiker die iedereen blokkeert.