Twee GPU's combineren voor grotere lokale taalmodellen

In de doorlopende route van lokale AI — van het selecteren van basiscomponenten en software-installatie tot het schalen naar een volwaardige thuisserver — vormt de fysieke VRAM-limiet van een enkele videokaart vaak de eerste grote barrière. Wie wil opschalen van compacte 7B- of 8B-modellen naar geavanceerde 32B- of 70B-architecturen ontdekt al snel dat een enkele consumentenkaart met 12 of 16 GB videogeheugen tekortschiet. Voordat de stap naar extreem kostbare enterprise-hardware wordt overwogen, biedt het combineren van twee grafische processors (GPU's) een flexibele en modulaire methode om het totale VRAM te verdubbelen.

Wie de hardwarevereisten van lokale modellen wil begrijpen en wil zien hoe VRAM zich verhoudt tot systeemgeheugen, kan beginnen bij het overzicht over welke hardware nodig is voor lokale LLM's. In deze handleiding kijken we specifiek naar de technische werking van dual-GPU configuraties: het fundamentele verschil tussen het sequentieel verdelen van rekenlagen en het parallel splitsen van matrices, de invloed van het moederbord en PCIe-lanes op de doorvoer, en de concrete configuratie van inferentie-engines zoals llama.cpp, Ollama en vLLM onder Linux. Voor de inrichting van de onderliggende distributie raadpleeg je de handleiding over lokale LLM's draaien op Linux.

Waarom twee GPU's: wiskunde van de VRAM-muur

Bij het uitvoeren van autoregressieve taalmodellen moeten alle modelparameters permanent in snel adresseerbaar geheugen aanwezig zijn. Wanneer een model 70 miljard parameters bevat en gekwantiseerd is naar 4-bit precisie, vraagt het statische modelgewicht al snel 38 tot 40 GB aan opslag. Daarnaast vereist de KV-cache (het sleutel- en waardegeheugen dat eerdere tokens in de context vasthoudt) extra VRAM: bij een contextlengte van 8.192 tokens en meerdere gelijktijdige sequenties loopt dit op met 2 tot 6 GB, naast de vaste CUDA runtime allocaties.

Op een enkele consumentenkaart van 16 GB of 24 GB past een 70B-model met een bruikbare contextlengte niet. Zodra een deel van de netwerklagen naar het reguliere DDR4- of DDR5-systeemgeheugen van de CPU wordt verplaatst (offloading), daalt de doorvoersnelheid drastisch. Dit snelheidsverlies ontstaat doordat de geheugenbandbreedte van werkgeheugen (circa 50 tot 80 GB/s) vele malen lager ligt dan de interne bandbreedte van grafisch geheugen (circa 900 tot 1000 GB/s op GDDR6X).

Door twee kaarten met elk 24 GB VRAM samen te schakelen ontstaat een theoretische pool van 48 GB. Hierdoor kan het volledige model inclusief een ruime contextbuffer binnen de snelle videogeheugens blijven, wat de verwerkingstijd per token drastisch reduceert ten opzichte van CPU-geheugenhybrides.

De twee smaken van parallellisatie: Pipeline versus Tensor

Het verdelen van een neuraal netwerk over meerdere grafische processors kan grofweg via twee strategieën plaatsvinden: laagsgewijze opsplitsing (Pipeline Parallelism) of gelijktijdige matrixsplitsing (Tensor Parallelism). Het onderscheid bepaalt welke hardware-eisen en software-engines van toepassing zijn.

Bij Pipeline Parallelism, zoals toegepast in llama.cpp, fungeert de keten als een estafette. GPU 0 berekent de eerste serie lagen en zendt de resulterende activatievector (enkele tientallen kilobytes) via de PCIe-bus naar GPU 1. Omdat deze data-overdracht slechts eenmaal per token plaatsvindt, heeft de beperkte doorvoersnelheid van een standaard moederbord nauwelijks een nadelige impact op de generatiesnelheid.

Bij Tensor Parallelism worden de gewichtsmatrices binnen elke aandachts- en feedforward-laag opgesplitst. Beide chips voeren parallel berekeningen uit en moeten na elke laag tussenresultaten synchroniseren. Wie een schaalbare omgeving voor meerdere gebruikers wil bouwen, vindt de stappen voor deze architectuur in de gids over vLLM configureren voor hoge doorvoer op Linux.

Hardwarevereisten: Moederbord, PCIe-lanes en voeding

Het toevoegen van een tweede krachtige videokaart stelt specifieke eisen aan de mechanische lay-out, de communicatielijnen en de stroomvoorziening van de hostmachine.

PCIe-lane distributie en moederbordkeuze

Standaard desktopprocessors beschikken over een beperkt aantal directe PCIe-lanes vanaf de CPU (meestal 16 tot 24 lanes). Wanneer twee fysieke x16-slots worden benut, splitst het moederbord deze verbindingen doorgaans op in een x8/x8 configuratie via PCIe-bifurcatie. Goedkopere moederborden leiden het tweede slot soms via de chipset op x4-snelheid, wat extra latentie introduceert.

Voor Pipeline Parallelism is een x8/x8-opstelling op PCIe 4.0 of zelfs PCIe 3.0 ruimschoots voldoende; de meetbare impact op de sequentiële tokengeneratie is verwaarloosbaar. Bij Tensor Parallelism zonder NVLink levert een x4-verbinding via een chipset daarentegen een merkbare vertraging op tijdens de frequente All-Reduce communicatiefasen.

Fysieke ruimte en thermische huishouding

Consumentenvideokaarten met forse koelers nemen vaak 3 tot 3,5 expansieslots in beslag. Twee kaarten direct naast elkaar monteren blokkeert de luchttoevoer naar de bovenste kaart. Een moederbord met minimaal drie slots fysieke tussenruimte, een computerkast met gerichte intake-ventilatoren, of het gebruik van afgeschermde PCIe 4.0 riserkabels is noodzakelijk om oververhitting en thermische terugklokking (throttling) te voorkomen.

Voeding (PSU) en transient vermogenspieken

Krachtige GPU's met een thermisch ontwerp van 300 tot 450 watt per stuk kunnen tijdens piekbelastingen kortstondige uitschieters (transient spikes) vertonen. Samen met de processor en randapparatuur vereist een dual-GPU werkstation een hoogwaardige voeding van 1200 tot 1500 watt met afzonderlijke voedingskabels per kaart, bij voorkeur conform de ATX 3.0 standaard.

Twee verschillende GPU's combineren: Mogelijkheden en beperkingen

Het samenvoegen van twee niet-identieke kaarten — zoals een model met 24 GB VRAM en een secundaire kaart met 12 of 16 GB VRAM — is een veelbesproken scenario. De haalbaarheid hangt direct af van de parallellisatietechniek:

• Pipeline Parallelism (llama.cpp / Ollama): Dit ondersteunt asymmetrische hardware volledig. Lagen kunnen naar evenredigheid worden verdeeld (bijvoorbeeld 45 lagen op een 24 GB GPU en 20 lagen op een 12 GB GPU). De uiteindelijke doorvoersnelheid wordt wel begrensd door de traagste kaart in de keten, aangezien de snelste chip moet wachten op de afronding van de voorafgaande of volgende laagserie.
• Tensor Parallelism (vLLM / TensorRT-LLM): Dit vereist symmetrie. Matrices worden in gelijke blokken gesplitst over het aantal GPU's (tensor_parallel_size). Als een 24 GB en een 16 GB kaart worden gecombineerd, kan de engine op beide kaarten maximaal 16 GB toewijzen, waardoor 8 GB op de primaire kaart onbenut blijft. Bovendien veroorzaken verschillen in rekencapaciteit synchronisatiewachttijden na elke transformerlaag.

Configuratie in de praktijk: llama.cpp en Ollama

In het llama.cpp-ecosysteem is ondersteuning voor meerdere CUDA-apparaten rechtstreeks geïntegreerd. Met specifieke startparameters kan de verdeling over de GPU-geheugens nauwkeurig worden ingesteld.

Met de vlaggen -sm (split-mode) en -ts (tensor-split) regisseert de beheerder hoe de rekenlagen over de beschikbare apparaten worden verspreid.

Handmatige laagverdeling in llama-server

In het onderstaande configuratievoorbeeld worden 80 transformerlagen van een 70B-model in een evenredige 50/50 verhouding over twee identieke 24 GB kaarten verdeeld:

# Start llama-server met 80 lagen verdeeld over GPU 0 en GPU 1 (symmetrische 50/50 split)
./llama-server \
  -m /pad/naar/Llama-3.1-70B-Instruct-Q4_K_M.gguf \
  -ngl 80 \
  -sm layer \
  -ts 24,24 \
  -c 8192 \
  --host 0.0.0.0 \
  --port 8080

Bij een asymmetrische configuratie — bijvoorbeeld een 24 GB kaart op positie 0 en een 16 GB kaart op positie 1 — kan de verhouding procentueel worden ingesteld:

# Asymmetrische toewijzing: 60% van het gewicht naar GPU 0, 40% naar GPU 1
./llama-server \
  -m /pad/naar/Qwen-2.5-32B-Instruct-Q4_K_M.gguf \
  -ngl 64 \
  -sm layer \
  -ts 60,40 \
  -c 16384

Aansturing binnen Ollama

Ollama detecteert standaard alle aanwezige NVIDIA-videokaarten en verdeelt het model automatisch op basis van de vrije VRAM-capaciteit. Via de omgevingsvariabele CUDA_VISIBLE_DEVICES kan de selectie van specifieke kaarten worden geforceerd:

# Controleer eerst de beschikbare GPU-indices en geheugencapaciteit
nvidia-smi --query-gpu=index,name,memory.total --format=csv

# Start de Ollama-service expliciet met GPU 0 en GPU 1
CUDA_VISIBLE_DEVICES=0,1 ollama serve

Configuratie in vLLM voor productiedoorvoer

Voor scenario's waarin gelijktijdige verzoeken van meerdere gebruikers moeten worden verwerkt, biedt vLLM geoptimaliseerde prestaties door middel van PagedAttention en Tensor Parallelism. Hierbij worden de berekeningen binnen afzonderlijke lagen simultaan uitgevoerd.

Het starten van een OpenAI-compatibele API-server met een 70B AWQ-gekwantiseerd model over twee GPU's vereist de parameter --tensor-parallel-size 2 (of -tp 2):

# Start vLLM met Tensor Parallelism over twee identieke GPU's
python3 -m vllm.entrypoints.openai.api_server \
  --model casperhansen/llama-3.1-70b-instruct-awq \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 8192 \
  --port 8000

Tijdens het opstarten reserveert vLLM op beide kaarten een identieke hoeveelheid VRAM voor de gewichten en splitst het de dynamische KV-cache gelijkmatig op. Wie een dergelijke server inricht binnen een bredere netwerkomgeving, kan de richtlijnen raadplegen over hoe je de IT-infrastructuur voorbereidt op lokale LLM's met betrekking tot netwerkbeveiliging en serverruimtes.

Prestaties en doorvoermodellen: Single GPU versus Dual GPU

Het toevoegen van een tweede videokaart verdubbelt de totale geheugencapaciteit, maar verdubbelt niet per definitie de generatiesnelheid voor een individuele interactieve sessie. De onderstaande tabel toont een indicatief rekenvoorbeeld van hoe geheugentoewijzing en theoretische verwerkingssnelheden zich verhouden bij verschillende modelgroottes en parallelle methoden.

Uit deze theoretische modellering komen drie belangrijke dynamieken naar voren:

• Voor compacte modellen die reeds volledig in het geheugen van één kaart passen, biedt een tweede GPU geen snelheidswinst. De noodzakelijke inter-GPU communicatie introduceert juist een minimale overhead.
• Voor modellen die de capaciteit van een enkele kaart overschrijden (zoals 32B en 70B), voorkomt een dual-GPU opstelling dat lagen naar het trage systeem-RAM moeten worden uitgeweken. Dit voorkomt de beruchte prestatie-instorting bij geheugentransfers.
• Tensor Parallelism verdeelt de wiskundige rekenlast over beide GPU-kernen gelijktijdig, wat bij voldoende snelle interconnects kan leiden tot een hogere promptverwerkingscapaciteit dan sequentiële laagsplitsing.

Kwaliteit op Nederlandse taken met 70B-modellen

Het operationeel kunnen draaien van een model met 70 miljard parameters levert aanzienlijke voordelen op bij complexe tekstverwerking. Waar kleinere modellen (zoals 7B of 8B) bij ingewikkelde redeneringen of lange contexten vaker steken laten vallen in zinsbouw of nuance, behouden 70B-modellen hun logische coherentie en stijlvastheid aanzienlijk beter.

Met name bij formele Nederlandstalige correspondentie, beleidssamenvattingen of juridische teksten vermindert een groter model het risico op anglicismen en contextuele ontsporingen. Hoe je promptstructuren optimaal formuleert voor Nederlandstalige verwerking lees je in het artikel over je AI beter laten presteren in het Nederlands.

Stroomverbruik en operationele kosten

Het gelijktijdig belasten van twee grafische kaarten heeft directe gevolgen voor de energieopname. Twee moderne high-end videokaarten verbruiken in rusttoestand gezamenlijk circa 25 tot 40 watt. Tijdens intensieve inferentietaken kan het gecombineerde vermogen van de GPU's oplopen tot 500 à 700 watt.

Omdat LLM-inferentie primair wordt begrensd door de geheugenbandbreedte en minder door de maximale klokfrequentie van de rekenkernen, kan het verlagen van de vermogenslimiet (power limit) via de driver het stroomverbruik aanzienlijk reduceren zonder noemenswaardig verlies aan tokendoorvoer:

# Verlaag de vermogenslimiet van GPU 0 en GPU 1 naar bijvoorbeeld 280 Watt
sudo nvidia-smi -i 0 -pl 280
sudo nvidia-smi -i 1 -pl 280

Een complete economische afweging over kilowattuur-tarieven en afschrijving staat beschreven in de analyse over wat het stroomverbruik van lokale AI kost.

Privacy en datasoevereiniteit in een lokale setup

De belangrijkste beweegreden om te investeren in een meervoudige GPU-opstelling is volledige datasoevereiniteit. Door krachtige 70B-modellen lokaal te hosten, kunnen vertrouwelijke bedrijfsdocumenten, medische dossiers of persoonsgegevens worden verwerkt zonder afhankelijkheid van externe cloud-API's of dataoverdrachten naar servers van derden.

Tijdens het inferentieproces blijven alle prompts en antwoorden binnen het lokale geheugen van de hostmachine. Richtlijnen voor het borgen van privacy en gegevensbeveiliging binnen lokale infrastructuren staan uitgewerkt in het overzicht over privacyvriendelijk AI gebruiken.

Veelvoorkomende valkuilen en foutdiagnose

Bij het inrichten van multi-GPU systemen doen zich regelmatig specifieke configuratiefouten voor. De drie meest voorkomende knelpunten en hun oplossingen zijn:

1. Onevenwichtige geheugentoewijzing (OOM op GPU 0)

Dit gebeurt wanneer software standaard alle contextbuffers en initiële allocaties op de primaire videokaart plaatst, waardoor GPU 0 volloopt terwijl GPU 1 nauwelijks wordt aangesproken. In llama.cpp kan dit worden gecorrigeerd door de verhouding in de parameter -ts handmatig bij te stellen, bijvoorbeeld naar -ts 22,24, om extra marge op het primaire apparaat vrij te houden.

2. Communicatiefouten bij gedistribueerde backends (NCCL P2P)

Wanneer vLLM start, probeert het via PCIe Peer-to-Peer (P2P) direct geheugentoegang tussen beide kaarten te initialiseren. Als het moederbord of de BIOS-instellingen dit niet volledig ondersteunen, resulteert dit in initialisatiefouten. Dit kan worden opgevangen door de communicatieroute expliciet via de omgevingsvariabelen aan te sturen:

# Schakel PCIe P2P communicatie expliciet in of pas fallback toe
export NCCL_P2P_DISABLE=0
export NCCL_IB_DISABLE=1
# Indien het moederbord hardwarematige P2P-blokkades opwerpt:
# export NCCL_P2P_DISABLE=1

3. Asynchrone thermische terugval

Wanneer de primaire kaart door beperkte luchtinlaat warmer wordt dan de secundaire kaart, schroeft de interne beveiliging van die chip de kloksnelheid terug. In een sequentiële pipeline-opstelling moet de tweede kaart continu wachten op de vertraagde tussenresultaten van de eerste, waardoor de totale tokensnelheid plotseling inzakt. Het continu monitoren van de temperaturen en klokfrequenties biedt hier inzicht in:

# Monitor temperaturen, kloksnelheden en actueel vermogen per seconde
watch -n 1 nvidia-smi --format=csv,noheader --query-gpu=index,temperature.gpu,utilization.gpu,power.draw,clocks.current.graphics

Conclusie: Afweging en randvoorwaarden voor een dual-GPU setup

Het combineren van twee GPU's vormt een effectieve methode om de geheugengrens van een enkele videokaart te doorbreken en geavanceerde 70B-modellen lokaal met werkbare snelheden uit te voeren. Door gebruik te maken van Pipeline Parallelism binnen software zoals llama.cpp is deze aanpak bovendien realiseerbaar op standaard moederborden zonder gespecialiseerde NVLink-bruggen.

De randvoorwaarden — waaronder een robuuste voeding, toereikende koeling en een weloverwogen geheugenverdeling — vragen om een zorgvuldige planning. Wie deze factoren onder controle heeft, realiseert een krachtig lokaal AI-systeem dat schaalbaarheid combineert met volledige gegevensprivacy.