Wat is model-sharding en waarom is het belangrijk voor de geheugenlimieten van AI voor thuisgebruik?

Modelsharding verdeelt de benodigde modelstatus over meerdere apparaten, zodat een model dat het geheugen van één accelerator overschrijdt toch kan worden geladen en uitgevoerd.

Voor een AI-server thuis is de belangrijke vraag niet of een checkpoint als meerdere bestanden is aangeleverd, maar of runtimegewichten, lagen, tensors of andere status daadwerkelijk op verschillende apparaten worden geplaatst. Sharding kan een onhaalbare geheugenvereiste voor één GPU omzetten in een haalbare implementatie met meerdere apparaten, maar de shards moeten nog steeds gegevens uitwisselen of werk tussen fasen doorgeven. Daardoor worden bandbreedte van de verbinding, verschillen tussen apparaten en runtimeondersteuning de volgende beperkingen.

Runtime-sharding verdeelt modelstatus over apparaten

Een actief model bevat tensors die beschikbaar moeten zijn wanneer de bijbehorende lagen worden uitgevoerd. Sharding wijzigt de plaatsing, zodat verschillende apparaten verschillende delen beheren in plaats van overal de volledige status te repliceren.

Een gedistribueerde tensor kan gebruikmaken van plaatsing van geshardde tensors, waarbij gedistribueerde dimensies over een apparaatmesh worden verdeeld in plaats van identiek op elke rank te worden opgeslagen.

Het directe geheugenvoordeel is een lagere geheugentoewijzing per apparaat. De systeemkosten zijn dat geen enkel apparaat nu alle gegevens voor elke bewerking bevat, waardoor coördinatie onderdeel wordt van de inferentie.

Checkpoint-shards zijn niet hetzelfde als een geshard model tijdens runtime

Grote modelrepositories splitsen een checkpoint vaak op in veel bestanden, zodat deze stapsgewijs kunnen worden gedownload en geladen. Die verpakkingskeuze bepaalt op zichzelf niet waar tensors zich bevinden nadat de runtime het model heeft geladen.

Sharding op bestandsniveau en runtimeplaatsing blijven afzonderlijke zaken, omdat een loader geshardde checkpoints kan combineren met distributie over meerdere apparaten.

Een thuisgebruiker kan daarom tientallen `.safetensors`-shards op schijf zien, terwijl de runtime nog steeds probeert het volledige model op één GPU te plaatsen. Omgekeerd kan een runtime een checkpoint tijdens het laden opnieuw verdelen over een andere indeling met meerdere apparaten.

Bij capaciteitsplanning moet je na het opstarten de daadwerkelijke apparaatindeling en geheugentoewijzingen controleren, in plaats van aan te nemen dat het aantal repositorybestanden de inferentietopologie onthult.

Sharding introduceert communicatie of overdrachten tussen fasen

Wanneer het ene apparaat waarden produceert die een andere shard nodig heeft, moeten gegevens via een verbinding worden verzonden of via een collectieve bewerking worden gesynchroniseerd. Het exacte dataverkeer hangt ervan af of de runtime tensors binnen lagen opsplitst, verschillende lagenbereiken op verschillende apparaten plaatst of geshardde status alleen verzamelt wanneer dat nodig is.

Verschillende strategieën voor inferentie met meerdere apparaten maken verschillende afwegingen tussen communicatiepatronen en geheugenplaatsing.

Daarom kunnen twee GPU's met voldoende gecombineerd VRAM een model toch langzaam uitvoeren. Het verplaatsen van activaties of het synchroniseren van gedeeltelijke resultaten kan de prestaties domineren wanneer PCIe of een andere verbinding veel trager is dan lokaal acceleratiergeheugen.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Ongelijke apparaten kunnen van één shard de bottleneck maken

Een heterogene thuisserver kan GPU's combineren met verschillende geheugengroottes, rekensnelheden, verbindingsbreedtes of generaties. Een wiskundig gelijkmatige verdeling kan er nog steeds voor zorgen dat het langzaamste of kleinste apparaat het tempo van het volledige verzoek bepaalt.

Tools voor laagplaatsing en offloading moeten daarom rekening houden met de werkelijke apparaatcapaciteit in plaats van uit te gaan van symmetrische hardware. Expliciete gedistribueerde uitvoering van modellen gebruikt een parallelle configuratie in plaats van een automatische abstractie van gebundeld geheugen.

Een praktische indeling kan een grotere GPU meer lagen geven of latentiegevoelige componenten op het snelste pad houden. Het doel is niet een gelijk aantal shards, maar een gebalanceerd kritiek pad waarin elk apparaat past.

Meet per apparaat het geheugen, de benutting, de overdrachtstijd en de inactieve tussenpozen bij dezelfde prompt. Een shard die voortdurend moet wachten of gegevens naar een ander geheugenniveau moet verplaatsen, is een aanwijzing dat de topologie, en niet het ruwe gecombineerde VRAM, de prestaties beperkt.

Modelsharding is in de eerste plaats belangrijk als hulpmiddel om geheugenhaalbaarheid te bereiken

Sharding is het waardevolst wanneer het ongeshardde model helemaal niet op één apparaat past. Zodra het model kan worden geladen, verschuift de optimalisatie naar verbindingskosten, batching, de plaatsing van de KV-cache en de vraag of een kleiner of gekwantiseerd model eenvoudiger zou zijn.

Een specifieke uitvoeringsstrategie is tensorparallelle inferentie; modelsharding is het bredere plaatsingsprobleem dat bepaalt welke benodigde status op welk apparaat moet staan.

Behandel het totale VRAM niet als één transparante geheugenpool. Sharding kan afzonderlijke geheugens laten samenwerken, maar elke runtime heeft nog steeds plaatsingsregels en communicatiekosten die bepalen of de resulterende implementatie bruikbaar is.

Veelgestelde vragen

Is een geshard checkpoint hetzelfde als een geshard model tijdens runtime?

Nein. Checkpoint-shards splitsen bestanden op voor opslag of laden; runtime-sharding bepaalt welke modelstatus tijdens de inferentie op welk apparaat staat.

Is modelsharding hetzelfde als tensorparallelisme?

Nein. Tensorparallelisme is één manier om een geshard model uit te voeren door tensorbewerkingen op te splitsen; sharding omvat ook strategieën voor de plaatsing van lagen, fasen, parameters of andere onderdelen.

Leveren twee GPU's van 12 GB automatisch één bruikbare pool van 24 GB?

Nein. Een runtime moet het model expliciet verdelen, en communicatie, gedupliceerde status, de KV-cache en de benodigde marge per apparaat verminderen de hoeveelheid gecombineerde capaciteit die praktisch bruikbaar is.