Hosting voor AI-toepassingen: CPU, GPU en opslagcapaciteit afstemmen

Beperk eerst de AI-workload

De keuze van de hardware begint bij de taak, niet bij een GPU. Bij de Inferentie Een bestaand model verwerkt invoergegevens en genereert bijvoorbeeld antwoorden. Bij fine-tuning wordt een vooraf getraind model aangepast aan aanvullende gegevens of een specifieke taak; bij volledige training worden de modelgewichten daarentegen opgebouwd in het kader van een afzonderlijke trainingsronde.

Deze doelstellingen leiden tot verschillende belastingprofielen: een chatdienst moet op verzoeken reageren, terwijl een trainingstaak gedurende langere tijd gegevens verwerkt en tussentijdse resultaten opslaat. Voor AI-hosting Daarom moet je aangeven of de responstijd, het aantal verwerkte verzoeken, de trainingsduur of bijvoorbeeld de kosten van een bepaalde taak voorop staan.

Leg de modelversie en looptijd vast, evenals het aantal parameters, de architectuur, de precisie en een geplande kwantisering. Noteer bovendien de verwachte invoer- en uitvoerlengtes, gelijktijdige verzoeken of batchgroottes en de piekbelasting. Zo kunnen offertes en latere tests op basis van dezelfde aannames worden vergeleken, in plaats van alleen nominale hardwaregegevens naast elkaar te leggen.

Bij een interne chatbot kan een enkele korte vraag probleemloos worden verwerkt, terwijl meerdere lange gesprekken het geheugen overbelasten. De KV-cache houdt bij het genereren van tekst extra statussen bij; de benodigde capaciteit hangt onder andere af van het model en de verwerking. Houd daarom niet alleen rekening met de gemiddelde dialoog, maar ook met lange contexten en gelijktijdig gebruik.

Leg ook vast welke gegevens worden verwerkt, waar deze mogen worden opgeslagen en welke beschikbaarheid en hersteltijd vereist zijn. Deze bedrijfsdoelstellingen zijn van invloed op de keuze tussen één enkele server en een complexere architectuur. De aannames blijven een uitgangspunt: of ze kloppen, blijkt pas uit een test met een representatieve belasting.

CPU en RAM in de pijplijn

Zelfs als een model op een GPU draait, werkt de CPU mee langs het datapad. Deze kan verzoeken ontvangen, tekst in tokens opsplitsen, bestanden lezen en invoer voorbereiden voor de modelverwerking. Als deze voorbereiding te traag verloopt, staat de GPU te wachten op werk; een krachtigere versneller lost dat knelpunt dan niet per se op.

De Werkgeheugen Neemt, afhankelijk van de toepassing, modelonderdelen, voorbereide gegevens en bestandscaches op. Daarbij komt nog opslagruimte voor processen die trainingsgegevens laden en omzetten. Plan daarom niet alleen het model zelf, maar ook het traject van de dataset tot de voltooide batch en voldoende reserves voor pieken in de verwerking.

PyTorch-DataLoaders kunnen meerdere workers gebruiken voor parallelle gegevensverwerking. Extra workers nemen echter ook geheugen in beslag; ook het gedeelde geheugengebied kan tekortschieten. Verhoog het aantal daarom stapsgewijs en houd de wachttijden voor gegevens en de geheugenbehoefte in de gaten, in plaats van een vaste waarde als algemeen geldende aanbeveling te hanteren.

Meer CPU-kernen helpen vooral wanneer de uit te voeren taken parallel kunnen worden uitgevoerd. Als daarentegen opslagtoegang, een afzonderlijke verwerkingsstap of de GPU zelf de doorvoersnelheid beperken, kunnen extra kernen weinig veranderen. Ook het klokgedrag kan van belang zijn bij korte verzoeken; meer achtergrondinformatie hierover is te vinden in het artikel over de CPU-regelaar op hostingservers.

Voor kleine modellen of incidentele verzoeken is CPU-inferentie een alternatief dat het overwegen waard is ten opzichte van een permanent beschikbaar GPU-systeem. Vergelijk beide varianten met hetzelfde model, de juiste nauwkeurigheid en het verwachte belastingprofiel. Het is van cruciaal belang of de CPU de vereiste responstijd ook tijdens pieken haalt en welke kosten hiermee daadwerkelijk gemoeid zijn.

GPU en VRAM goed begrijpen

Bij een volledig op de GPU uitgevoerde inferentie moeten de modelgewichten in het beschikbare GPU-geheugen worden opgeslagen. De VRAM-behoefte Maar daar houdt het niet op: de runtime heeft nog meer ruimte nodig voor tussentijdse resultaten en tijdelijke buffers. Een kaart waarop de gewichten rekenkundig net passen, biedt daarom nog geen betrouwbare basis voor productief gebruik.

Bij autoregressieve tekstgeneratie komt daar nog de KV-cache bij. Deze slaat reeds berekende sleutel- en waardetoestanden op, zodat ze bij volgende generatiestappen opnieuw kunnen worden gebruikt. Lange contexten en gelijktijdig verwerkte verzoeken kunnen deze extra opslagbehoefte vergroten; in welke mate hangt af van het model en de verwerking.

De documentatie van Transformers 4.48.2 beschrijft onder andere cachekwantisering en uitwisseling als manieren om VRAM te besparen. Het voordeel hangt daarbij af van de implementatie en de belasting; extra verwerking of gegevensoverdrachten kunnen de snelheid verminderen. Controleer daarom zowel het geheugengebruik als de responstijd, in plaats van een besparing op het geheugen automatisch als prestatiewinst te beschouwen.

Tijdens het trainen volstaat de inferentieberekening al helemaal niet. Naast de gewichten is er opslagruimte nodig voor gradiënten, optimalisatorstatussen en opgeslagen activeringen. Hoe groot deze hoeveelheden zijn, hangt onder andere af van de optimalisator, de precisie en de trainingsmethode; langere sequenties of grotere batches kunnen met name het geheugengebruik voor activeringen verhogen.

Voor een volledig op de GPU uitgevoerde berekening moet het beschikbare VRAM voldoende ruimte bieden voor de benodigde gewichten en runtime-gegevens. Bij hybride methoden kunnen delen van de verwerking of modelgewichten buiten de GPU worden opgeslagen; de geschiktheid hiervan en de kosten van gegevensoverdracht zijn afhankelijk van de looptijd. Dit moet worden onderscheiden van het uitbesteden van de KV-cache zoals beschreven in Transformers 4.48.2.

Bekijk het model, de looptijd en de geplande parallelliteit in hun onderlinge samenhang en controleer de maximale geheugenbelasting bij een representatieve belasting. Voldoende geheugen voor de gekozen uitvoeringswijze is nog geen garantie voor de gewenste responstijd of belasting.

Een ruwe schatting maken van de modelopslagcapaciteit

Een eerste geheugenberekening begint bij het aantal modelparameters en het formaat waarin hun gewichten daadwerkelijk worden opgeslagen. Deze berekening levert een ondergrens op voor dit geheugengebruik, maar nog geen volledige dimensionering van de GPU-server. Ze geeft met name geen uitsluitsel over hoeveel geheugen een concrete aanvraag tijdens de uitvoering nodig heeft.

Illustratief rekenvoorbeeld, geen meting: Zeven miljard parameters vermenigvuldigd met twee bytes levert 14 miljard bytes op voor de gewichten. Gedeeld door 1.073.741.824 bytes per GiB is dat ongeveer 13,0 GiB. Voorwaarde is dat alle beschouwde gewichten daadwerkelijk uniform zijn opgeslagen met twee bytes per parameter; andere formaten of aanvullende representaties veranderen de berekening.

Niet inbegrepen zijn de KV-cache voor het genereren van tekst, tijdelijke buffers en overhead tijdens de uitvoering. Vooral bij lange contexten kan de cache aanzienlijk groeien; ook het aantal gelijktijdig verwerkte verzoeken is van belang voor de benodigde reserve. De cache-documentatie van Transformers 4.48.2 beschrijft bovendien methoden die geheugen kunnen besparen, maar die, afhankelijk van de methode, ten koste gaan van de snelheid.

Voor training is de gewichtsberekening al helemaal niet toereikend. De documentatie bij Transformers 4.35.0 schat voor een voorbeeldconfiguratie met gemengde precisie en AdamW 18 byte per parameter, plus activeringen. Daarin zijn ook andere componenten meegenomen, zoals gradiënten en optimalisatorstatussen; de activeringen zijn onder andere afhankelijk van de sequentielengte en de batchgrootte.

De 18 bytes zijn geen algemene vermenigvuldigingsfactor voor elke training: optimalisatie, precisie en trainingsmethoden kunnen de benodigde hoeveelheid beïnvloeden. Noch uit dit getal, noch uit de 13,0 GiB volgt daarom een aanbeveling voor een bepaalde VRAM-grootte. Voor de keuze zijn de concrete looptijd en de verwachte maximale geheugenbelasting bij een representatieve belasting doorslaggevend.

Workloads en knelpunten vergelijken

Dezelfde modelgewichten kunnen, afhankelijk van de taak, tot zeer uiteenlopende eisen leiden. De tabel toont mogelijke knelpunten; er is geen rangorde en er zijn geen gegarandeerde knelpunten. Welke bron daadwerkelijk de beperkende factor is, hangt onder andere af van het model, de datapijplijn, de parallellisatie en de belasting.

Bij een interne chatbot vormen het model en de generatie slechts een deel van de planning. Stel een maximale invoerlengte, een verwachte uitvoerlengte en het aantal gelijktijdige gebruikers vast. Vervolgens kan worden gecontroleerd of de responstijd bij piekbelasting acceptabel blijft en of de gewichten, cache en buffer tegelijkertijd in het beschikbare geheugen passen.

Een documentzoekopdracht met een generatief antwoord heeft een langer gegevenspad: documenten worden geïmporteerd en verwerkt, er worden embeddings gegenereerd, er wordt in een index gezocht en relevante inhoud wordt doorgegeven aan het taalmodel. Het importeren en zoeken kunnen andere CPU-, RAM- en opslagvereisten hebben dan het genereren. Daarom is het de moeite waard om de tijden en opslagbehoeften van deze stappen afzonderlijk vast te leggen.

Bij het afstemmen kan Gradiëntaccumulatie een grotere effectieve batchgrootte mogelijk maken, hoewel er slechts kleinere afzonderlijke batches tegelijkertijd worden verwerkt. De gradiënten van meerdere stappen worden verzameld voordat de parameters worden bijgewerkt. Dit kan helpen bij beperkte opslagruimte, maar levert geen gegarandeerde toename van de doorvoer op; extra verwerkingsstappen kunnen tijd kosten.

Ook de gegevensaanvoer verdient aparte aandacht: als de voorbewerking of het laden achterblijft bij de modelverwerking, helpt een grotere GPU niet per se. Omgekeerd kan een snelle gegevenspijplijn een te klein VRAM-geheugen niet vervangen. Vergelijk alternatieven daarom met dezelfde invoergegevens en een inzichtelijk belastingsprofiel.

Opslag en GPU-verbindingen plannen

Bij het plannen van de opslag loont het de moeite om een onderscheid te maken tussen gegevenstype en toegangswijze: trainingsdatasets worden herhaaldelijk gelezen, modelgewichten worden vóór gebruik geladen. Voor beide is een betrouwbare bron nodig, waaruit ze na een hostwisseling opnieuw beschikbaar kunnen worden gesteld. Capaciteit alleen is niet voldoende; ook laadtijd en toegangs patronen beïnvloeden de werking.

Tijdelijke werkgegevens kunnen op een lokale NVMe-schijf worden opgeslagen als er een snelle werkruimte nodig is. Informeer bij de leverancier of deze gegevens herstarts en hostwisselingen doorstaan. Checkpoints en back-ups vereisen daarentegen een zorgvuldig geplande opslag en een geteste herstelprocedure; een lokale tijdelijke map is niet automatisch een onafhankelijke back-up.

Gedeelde of objectgebaseerde opslag kan het verspreiden en bewaren van datasets, gewichten en checkpoints vergemakkelijken. Het is van cruciaal belang of de toepassing de gekozen toegangswijze ondersteunt en of gegevens binnen de beoogde tijd kunnen worden geladen en hersteld. Een extra lokale werkruimte kan nuttig zijn, maar is geen vervanging voor permanente opslag.

GPUDirect Storage maakt, onder de juiste hardware-, software- en bestandssysteemomstandigheden, een directer gegevenspad tussen de opslag en het GPU-geheugen mogelijk. Dit is vooral interessant wanneer invoer en uitvoer zich op het kritieke pad bevinden en de toepassing gebruikmaakt van het ondersteunde pad. Als de CPU gegevens eerst moet decoderen of voorbewerken, kan dit het voordeel beperken.

Bij meerdere GPU’s moet onderscheid worden gemaakt tussen replicatie en verdeling. Replicatie zorgt voor kopieën van het model om verzoeken te verdelen; het maakt van afzonderlijke VRAM-gebieden niet automatisch een gedeeld geheugen. De documentatie bij vLLM 0.20.1 beschrijft een dergelijke parallelle gegevenslevering; hieruit volgt geen uitspraak over andere runtime-versies.

Tensor- en pipeline-parallellisme verdelen daarentegen delen van de verwerking en zorgen voor communicatiebehoeften. Controleer hiervoor de verbindingen tussen GPU’s en, bij meerdere servers, de netwerktopologie en de ondersteuning door het model en de runtime. De documentatie bij vLLM 0.8.5 behandelt deze strategieën voor gedistribueerde serving; de concrete aanwijzingen daarin zijn versiespecifiek.

Knelpunten onder belasting herkennen

Een zinvolle vergelijking begint met een gedocumenteerde lastprofiel. Leg de modelversie, de nauwkeurigheid, de specifieke hardwarevariant en de versie van de runtime vast. Vermeld ook de typische en maximale contextlengtes, de uitvoerlengtes en het aantal gelijktijdige verzoeken. Zo kan een latere wijziging van de infrastructuur onder dezelfde omstandigheden worden getest.

Meet bij de inferentie de tijd tot het eerste token en de generatiesnelheid. Registreer bovendien fouten en responstijden bij normale belasting en bij verwachte pieken. Een hoge gemiddelde doorvoer is niet voldoende als afzonderlijke verzoeken bij lange contexten of hoge parallelliteit te lang moeten wachten of mislukken.

Voor training en fine-tuning zijn stappen of verwerkte voorbeelden per tijdseenheid een geschikt uitgangspunt. Let daarnaast op hoe lang de datapijplijn laat wachten op de volgende batch. PyTorch-DataLoaders kunnen met meerdere workers worden voorbereid; hun geheugenbehoefte en de belasting van het gedeelde geheugen moeten ook in de afweging worden meegenomen.

Registreer pieken in het GPU-geheugen en het RAM, evenals de opslagbelasting en wachttijden. Op een bestaand NVIDIA-systeem geeft het leescommando nvidia-smi afhankelijk van het apparaat en het stuurprogramma, onder andere de GPU-status en het geheugengebruik. Het brengt geen wijzigingen aan in de productieve configuratie, maar vormt geen vervanging voor een meting van de toepassing.

Een lage GPU-bezetting duidt op zich noch op een CPU- noch op een opslagprobleem. Vergelijk deze gegevens in de tijd met wachttijden, het verloop van verzoeken en opslaggebruik, en wijzig indien mogelijk slechts één relevante variabele per vergelijking. Documenteer ook de beperkingen van de test, bijvoorbeeld wanneer zeldzame piekbelastingen of bijzonder lange invoer nog ontbreken.

AI-infrastructuur betrouwbaar beheren

Bij de bedrijfsplanning hoort een controleerbare combinatie van GPU-variant, stuurprogramma, framework en modelruntime. Controleer vóór updates welke versies samen worden ondersteund en hoe je bij problemen terug kunt keren naar de vorige combinatie. Bij speciale gegevenspaden zoals GPUDirect Storage moeten bovendien de hardware, de software en het bestandssysteem aansluiten bij het beoogde gebruik.

Bepaal wie modellen, trainingsgegevens, logbestanden en beheerinterfaces mag inzien of wijzigen. Voor gevoelige gegevens moeten bovendien de opslaglocatie, de gegevensoverdracht en de bewaartermijn worden afgestemd op de vereisten inzake gegevensbescherming. Controleer deze punten voor alle betrokken diensten, niet alleen voor de server waarop het model draait.

A Checkpoint slaat een trainingsstatus op voor het later hervatten van de training. Bepaal welke statussen je trainingssoftware hiervoor nodig heeft, hoe vaak ze worden opgeslagen en hoe lang ze bewaard blijven. Modelgewichten voor de levering en checkpoints voor het hervatten dienen verschillende doelen en moeten dienovereenkomstig worden gemarkeerd.

Lokale werkopslag is niet automatisch permanent en vormt geen vervanging voor een onafhankelijke back-up. Vraag de aanbieder wat er met de lokale gegevens gebeurt bij een herstart, vervanging van de host of het aflopen van het contract. Sla de benodigde gegevens apart van de werkomgeving op en test het herstel in de praktijk, inclusief de tijd die nodig is om de gegevens weer bruikbaar te maken.

Bij gedistribueerde taken omvat de monitoring niet alleen de afzonderlijke GPU’s, maar ook knooppunten, netwerkverbindingen en de voortgang van de gehele toepassing. Bepaal vanaf welke opgeslagen status een taak na een storing opnieuw moet starten en welke resources daarvoor beschikbaar moeten zijn. Als modelonderdelen over meerdere servers zijn verdeeld, beïnvloeden hun verbindingen ook de werking; de aanwijzingen in de vLLM-documentatie 0.8.5 zijn daarbij versiegespecificeerd.

Hostingmodel en GPU-server kiezen

Bij onregelmatige opdrachten kan een tijdelijk ingezette GPU-server kan zinvol zijn: je betaalt volgens de concrete aanbiedingsvoorwaarden voor de benodigde capaciteit, in plaats van permanent capaciteit aan te houden. Vergelijk daarbij ook de starttijden, de beschikbaarheid op het gewenste tijdstip en de kosten voor opgeslagen gegevens en gegevensoverdracht.

Bij een gelijkmatige belasting loont het de moeite om te kiezen voor permanent gereserveerde infrastructuur. Dit biedt meer controle over de looptijd en het gegevenspad, maar vereist wel een eigen planning voor updates, monitoring en herstel. Een beheerde inferentieservice neemt delen van deze werkzaamheden over; controleer daarentegen wel welke modellen, instellingen en datapaden daar daadwerkelijk beschikbaar zijn.

Voor de keuze van de machine learning-infrastructuur zijn gegevens nodig over de specifieke GPU-variant zoals: VRAM-capaciteit, geheugenbandbreedte, ondersteunde rekenformaten en bouwvorm. Pas de maximale waarden van een productfamilie niet zonder meer toe op elke variant. Vergelijk prestatiegegevens alleen met de bijbehorende testomstandigheden en het beoogde model, in plaats van uitsluitend op basis van een theoretische piekwaarde te beslissen.

Ook de schaalbaarheidsmethode maakt deel uit van het aanbod: gerepliceerde instanties kunnen verzoeken verdelen, terwijl een modelverdeling ondersteuning vereist op basis van looptijd en verbindingstopologie. De documentatie van vLLM behandelt gegevensparallelisme in versie 0.20.1 en gedistribueerde serving in versie 0.8.5; deze uitspraken mogen niet zonder controle worden toegepast op een andere versie.

Stel eerst het model en het belastingsprofiel in, maak vervolgens een schatting van de opslagcapaciteit en het gegevenspad en vraag passende offertes aan. Controleer daarna de responstijd, fouten en benodigde resources aan de hand van representatieve verzoeken of trainingsgegevens. Meer aspecten om dit in te schatten vind je bij de GPU-hosting voor webapplicaties. Zonder deze vergelijking van de werklast is het niet mogelijk om een algemeen geldende aanbeveling voor een GPU te doen.