Welke invloed heeft read-ahead op de laadtijd van modellen en het dataverkeer op gedeelde opslag?
Read-ahead kan het sequentieel laden van modellen versnellen door toekomstige pagina's vooraf op te halen, maar te grote vensters kunnen cache en bandbreedte van gedeelde opslag verspillen.
Wanneer meerdere AI-processen thuis hetzelfde model van meerdere gigabytes vanaf een NAS openen, kunnen aanvragen om ontbrekende pagina's op elk proces blokkeren. Prefetch kan latere pagina's alvast gereedmaken, maar elke client kan ook gegevens opvragen die hij nooit gebruikt of verkeer van een andere client dupliceren. Het resultaat hangt af van de toegangsvolgorde, geheugentoewijzing, hergebruik van de paginacache, het opsplitsen van modellen, gelijktijdigheid, opslaglatentie en de locatie van de cache.
Read-ahead zet sequentiële aanvragen om in eerdere I/O
Zonder bruikbare cachestatus bereikt een lader een pagina en wacht hij terwijl de opslag deze terugstuurt. Read-ahead herkent sequentiële toegang en verstuurt aanvragen voor latere pagina's voordat het proces daar om vraagt. Als voorspelling en timing goed op elkaar aansluiten, verwerkt de berekening het huidige gebied terwijl de opslag het volgende vult.
De Linux-paginacache past read-ahead toe en vergroot of verkleint het venster op basis van waargenomen toegang. Dit helpt bij gebufferde sequentiële leesbewerkingen, omdat toekomstige pagina's al in het geheugen kunnen staan wanneer de lader ze bereikt.
Het voordeel is het grootst wanneer opslaglatentie anders hiaten zou veroorzaken en het model in een voorspelbare volgorde wordt gelezen. Het voordeel is kleiner wanneer het bestand al in de cache staat, directe I/O de paginacache omzeilt, de lader alles expliciet vooraf laadt of de runtime toegewezen pagina's in een onregelmatig patroon aanraakt.
Geheugentoewijzing maakt de volgorde van page faults onderdeel van het laden
Geheugentoewijzing kan het opstarten van een model snel laten lijken, omdat de runtime adreskoppelingen maakt voordat elke gewichtspagina in het geheugen staat. Fysieke I/O vindt plaats wanneer pagina's worden aangeraakt. De schijnbare laadtijd hangt daarom af van de vraag of de benchmark stopt nadat de toewijzing is gemaakt of doorgaat totdat de inferentie de werkset in het geheugen heeft geladen.
In het geheugen toegewezen modelgewichten kunnen opslagvertraging veroorzaken bij page faults voor ontbrekende pagina's, en onregelmatige toegang kan veel kleine leesbewerkingen opleveren. Read-ahead helpt wanneer de aanraakvolgorde sequentieel genoeg blijft voor voorspelling; anders kunnen de verkeerde gebieden worden opgehaald.
Meet zowel de tijd om het modelobject te maken als de tijd tot het eerste volledig gegenereerde token. Een wijziging die I/O van het opstarten naar het eerste verzoek verplaatst, heeft het laadwerk niet verwijderd. Tests met een warme cache moeten worden gescheiden van tests met een koude cache, omdat hergebruik van pagina's het resultaat kan domineren.
Te grote vensters vervuilen de cache en verbruiken gedeelde bandbreedte
Een prefetchvenster dat verder reikt dan de werkset die de lader op korte termijn nodig heeft, verplaatst pagina's die mogelijk worden verwijderd voordat ze worden gebruikt. Die pagina's nemen clientgeheugen in beslag, verdringen andere cache-items en verbruiken bandbreedte op de NAS-verbinding en de opslagbackend. De verspilling wordt duidelijker wanneer laders gelijktijdig verschillende modellen starten.
Te veel read-ahead kan caches vervuilen met nutteloze gegevens, terwijl te weinig read-ahead latere aanvragen om gegevens veroorzaakt; beide schaden de prestaties. Eén vaste standaardinstelling kan niet tegelijk optimaal zijn voor sequentieel laden, schaarse toegang tot experts en gemengd opslagverkeer.
Gedeelde opslag vergroot de gevolgen van fouten, omdat elke client lokaal voorspellingen doet zonder noodzakelijkerwijs te weten wat andere clients ophalen. Als caching aan de serverzijde deze leesbewerkingen niet kan samenvoegen, kunnen gesynchroniseerde opstarts agressieve prefetching veranderen in een verkeerspiek die elke lader en ander NAS-werk vertraagt.
De locatie van de cache bepaalt of laders het voordeel delen
Een clientpaginacache helpt processen op die machine, terwijl een NAS-cache meerdere clients kan helpen, maar nog steeds netwerkoverdracht vereist. GPU-geheugen is weer een afzonderlijke bestemming. Dezelfde modelbytes kunnen daarom op de server, in het client-RAM en in de accelerator worden gecachet, zonder dat één laag de verplaatsing op de andere lagen overbodig maakt.
Met het opsplitsen van modellen kunnen workers alleen toegewezen gebieden lezen in plaats van het hele bestand. Read-ahead voor het volledige bestand kan dat voordeel tenietdoen door shards op te halen die een worker nooit gebruikt, terwijl shardgerichte toegang prefetching binnen het nuttige bereik kan houden.
Gelijktijdige processen op één host kunnen bestandspagina's delen, maar afzonderlijke hosts kunnen het client-RAM niet delen. Test de werkelijke topologie: lokale SSD, NAS via Ethernet, gedistribueerde cache of gekopieerde modelbestanden. Dezelfde read-ahead-instelling kan lokale vertragingen verminderen en toch het totale aantal netwerkbytes verhogen.
Stem read-ahead af met koude, warme en gelijktijdige ladingen
Houd het modelbestand, de runtime, het opslagpad en de hardware gelijk terwijl je verschillende vensters test. Noteer de koude tijd tot het eerste token, de tijd voor een warme herstart, het aantal bytes dat uit de opslag wordt gelezen, de netwerkdoorvoer, page faults, cachebelasting en de latentie voor andere NAS-workloads. Herhaal dit met één lader en met het verwachte aantal gelijktijdige laders.
Een praktische bespreking van prefetch en cache laat zien dat deze lagen op elkaar inwerken in plaats van als onafhankelijke schakelaars te functioneren. Verbeteringen moeten worden toegeschreven aan nuttige vroege leesbewerkingen, caching aan de serverzijde of hergebruik aan de clientzijde, en niet aan één enkel opstartcijfer.
De beste instelling is afhankelijk van de workload. Vergroot read-ahead zolang dit koude vertragingen vermindert zonder het aantal ongebruikte bytes of de interferentie tussen gelijktijdige processen merkbaar te verhogen; verklein het wanneer de toegang schaars of opgesplitst is of wanneer de cache zwaar wordt belast. Beoordeel de instelling opnieuw nadat de runtime, het modelformaat, de shardindeling of de opslagtopologie is gewijzigd.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Waarom de architectuur van je Jellyfin-thuisserver verandert naarmate je meer services toevoegt
Een Jellyfin-box wordt een dienstenstack naarmate er meer apps worden toegevoegd. Daarom moeten CPU, opslag, netwerk, geheimen, back-ups en herstelgrenzen expliciet worden toegewezen.
Jellyfin-prestaties meten zonder cache met capaciteit te verwarren
Een betrouwbare Jellyfin-benchmark labelt de koude en warme toestand afzonderlijk, zodat metadata uit de cache of bestandssysteempagina’s niet wordt aangezien voor permanente hardwarecapaciteit.
Hoeveel iGPU-capaciteit heeft Jellyfin nodig voor meerdere gebruikers?
De iGPU-reservecapaciteit van Jellyfin is werkbelastingsspecifiek: houd marge boven de zwaarste herhaalbare combinatie van gelijktijdige transcoderingen aan, in plaats van een willekeurig gebruikspercentage.
