Waarom hangt de koude start van een lokaal AI-model af van de opslagindeling?

De koude start van een lokaal AI-model hangt af van de opslagindeling, omdat de runtime elk vereist gewicht moet vinden, lezen, decoderen, mappen en overbrengen voordat inferentie kan beginnen.

Twee kopieën van hetzelfde model kunnen met verschillende snelheden starten wanneer de ene al in de lokale NVMe-cache staat en is opgeslagen in een laadvriendelijk formaat, terwijl de andere zich op een netwerkshare, gefragmenteerd bestandssysteem, gecomprimeerd archief of in een map met slecht gerangschikte shards bevindt. Het koude pad omvat ook tokenizerbestanden, configuratie, runtime-initialisatie, toewijzing van de accelerator en de eerste uitvoering. In de onderstaande secties worden ruwe opslagbandbreedte en checkpointindeling afzonderlijk behandeld, zodat opstartvertragingen aan de juiste fase kunnen worden toegeschreven.

Een koude start is een keten van opslag- en runtimefasen

Een model is niet klaar zodra het proces alleen het eerste bestand heeft geopend. De runtime moet checkpointmetadata ontdekken, de modelstructuur aanmaken, gewichtsbytes lezen, tensors deserialiseren of mappen, bestemmingsgeheugen toewijzen, gegevens overbrengen en kernels of uitvoeringsgrafieken initialiseren.

Onderzoek naar serverloze inferentie identificeert het laden tijdens een koude start als een belangrijk onderdeel van de vertraging voordat een LLM-service gereed is. De langzaamste fase verandert afhankelijk van de modelgrootte, het formaat, de opslaglaag, het hostgeheugen en het acceleratorpad.

Een snelle SSD kan het lezen versnellen, terwijl deserialisatie, CPU-kopieën, GPU-overdracht of het opwarmen van kernels onveranderd blijven. Meet de tijd bij elke grens in plaats van de volledige pauze als één schijfbenchmark te behandelen.

Lokalisatie bepaalt of gewichten uit de cache, het LAN of van de schijf komen

Gewichten die op lokale NVMe zijn opgeslagen, kunnen worden gelezen zonder netwerklatentie of de wachtrij van een andere server. Een model op SMB, NFS, objectopslag of een koude externe schijf voegt transport- en externe-cachegedrag toe voordat het lokale laden begint.

Recent onderzoek naar modellen in de nodecache laat zien dat grote artefacten lokaal houden ervoor kan zorgen dat latere replicastarts veel minder afhankelijk zijn van herhaalde levering op afstand. Op een homeserver geldt hetzelfde principe voor het onderscheid tussen een eerste download en een herhaalde lokale start.

Lokaal betekent niet altijd warm. Een herstart, cache-evictie, opnieuw aangekoppeld bestandssysteem of concurrerende bulklezing kan ervoor zorgen dat de volgende start de meeste modelpagina's opnieuw uit fysieke opslag moet ophalen.

Het artikel van ZimaSpace over model-evictie behandelt de gerelateerde geheugenbarrière: zodra een model niet langer resident is, moet de volgende aanvraag de snelle uitvoeringstoestand opnieuw opbouwen.

Het checkpointformaat bepaalt de hoeveelheid deserialisatie- en kopieerwerk

Een checkpoint kan bestaan uit één aaneengesloten laadgeoptimaliseerd bestand, meerdere tensorshards met een index, een gecomprimeerd archief of frameworkspecifieke serialisatie waarbij Python-objecten en tensor­metadata opnieuw worden opgebouwd.

ServerlessLLM gebruikt sequentiële checkpointlezingen om de overhead van koude starts te beperken. Een indeling die grote directe lezingen en voorspelbare tensorplaatsing ondersteunt, verspilt minder tijd aan kleine metadatahandelingen en tussentijdse reconstructie.

Sharding kan het maximale host-RAM-gebruik verlagen omdat telkens één shard wordt verwerkt, maar te veel kleine bestanden vergroten het aantal directoryzoekopdrachten, openbewerkingen, zoekacties en indexbewerkingen. De beste shardgrootte hangt af van de parallelliteit van de loader en het onderliggende bestandssysteem.

Compressie ruilt opslagcapaciteit in voor CPU-werk tijdens het opstarten. Dat kan helpen wanneer de opslag erg traag is, maar nadelig zijn wanneer een snelle SSD moet wachten op decompressie en geheugenkopieën.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Geheugenmapping verandert wanneer pagina's het RAM binnenkomen

Een eager loader kan een grote hostbuffer toewijzen en het grootste deel of het volledige checkpoint lezen voordat tensors verder worden gekopieerd. Een loader met geheugenmapping maakt virtuele mappings aan en laat het besturingssysteem bestandspagina's in het RAM laden zodra ze worden aangeraakt.

Onderzoek en moderne laadsystemen gebruiken laden met geheugenmapping om te voorkomen dat het volledige artefact in anoniem geheugen wordt gedupliceerd. Dit kan het maximale RAM-gebruik verlagen en ervoor zorgen dat herhaalde processen pagina's via de bestandssysteemcache kunnen hergebruiken.

Geheugenmapping verwijdert opslaglatentie niet. Het verplaatst lezingen naar het moment van een page fault, waardoor de eerste inferentie nog steeds kan haperen als vereiste pagina's niet zijn geladen of vooraf opgehaald.

Sequentieel vooraf ophalen kan helpen bij een model dat de meeste gewichten in volgorde aanraakt, terwijl willekeurige toegang tot experts of multimodale componenten het patroon van page faults minder voorspelbaar kan maken.

Parallel laden helpt alleen wanneer het opslagpad voldoende ruimte heeft

Meerdere loaderthreads of GPU-kopiestromen kunnen lezen, decoderen en overdragen overlappen. Ze kunnen echter ook één geordende leesstroom veranderen in meerdere concurrerende stromen die een zwakke SSD, USB-bridge, netwerkshare of metadata­pad van het bestandssysteem verzadigen.

NVIDIA's technische resultaten over gelijktijdige gewichtsstreaming laten zien dat laadontwerp en opslagkeuze samen de verbetering bepalen. Parallelliteit is nuttig wanneer bron en bestemming dit kunnen volhouden zonder dat de wachtrij groeit.

Een homeserver kan tegelijkertijd media aanbieden, back-ups schrijven, bestanden scannen of databases uitvoeren op dezelfde pool. Die workloads veranderen de latentie van een koude start, ook al blijft de modelmap zelf ongewijzigd.

Een warme cache en hergebruik van gewichten kunnen herhaalde starts domineren

De eerste start na het opstarten kan elke modelbyte uit de opslag lezen, terwijl de tweede start profiteert van de bestandssysteem-paginacache, behouden GPU-geheugen of een runtime die gewichten gereed houdt voor hergebruik.

Tangram versnelt het opstarten via hergebruik van gewichten in GPU-geheugen. De bredere les voor een homeserver is dat bij “koude start” moet worden aangegeven welke caches en processen vóór de test zijn gewist.

Vergelijk niet het ene model direct na een warme run met een ander model na een herstart. Definieer afzonderlijk een koude toestand, een toestand met een warme bestandssysteemcache, een runtime-warme toestand en een accelerator-warme toestand.

Benchmark de indeling met een herhaalbare test vanuit een koude toestand

Noteer de modelgrootte, het aantal bestanden, de shardgroottes, het bestandssysteem, de aankoppelopties, het opslagapparaat, het netwerkpad, de laadmodus, het host-RAM, het acceleratorgeheugen en concurrerende I/O. Meet vervolgens de tijd voor metadataontdekking, lezen naar de host, deserialisatie, overdracht naar het apparaat, runtime-initialisatie en het eerste token.

FlowLoader onderzoekt lokale modelcaching, omdat checkpointplaatsing en pipeline-overlap het opstarten van seconden of minuten kunnen terugbrengen. De exacte winst hangt ervan af of de werkelijke bottleneck opslag, kopieën of initialisatie is.

Herhaal de test nadat je de bestandssysteemcache hebt geleegd, na een normale warme run en tijdens representatief NAS-verkeer. Het resulterende verschil laat zien of een wijziging in de indeling, een snellere lokale opslaglaag, minder shards, geheugenmapping of een keep-alivebeleid zal helpen.