Hoeveel geheugen laat je over voor de AI-assistent bij een stream in 1080p

Bereken eerst wat al in gebruik is

Een AI-assistent werkt niet in een vacuüm: hij deelt de hardware met de game, de encoder en de stream zelf. Voordat je geheugen toewijst, bereken je hoeveel de andere deelnemers al opslokken. Bij 1080p ligt de grootste last bij de encoder — hardwarematig op de videokaart of softwarematig op de processor — plus bij de game zelf en het vastleggen van het scherm.

Praktische richtlijn: als de game en de encoder samen een flink deel van het videogeheugen innemen, gaat het vrije restant naar het model in plaats van naar de cache — en dan krijg je drops niet door een tekort aan geheugen, maar door het voortdurend herverdelen ervan. Reken dus niet met "hoeveel geef ik", maar met "hoeveel blijft er over na de game en de encoder".

Lokaal model of cloud

Dit is de belangrijkste splitsing, en alles hangt ervan af.

Een cloud-assistent gebruikt bijna geen lokaal geheugen: verzoeken gaan over het netwerk, op je machine blijft alleen de client over. De vraag gaat dan niet over gigabytes, maar over de stabiliteit van de verbinding en de vertraging — tijdens een actieve stream is de upload al bezet, en de assistent deelt die met de video. Is de verbinding smal, dan antwoordt de assistent met een pauze of concurreert hij met de stream om bandbreedte.

Een lokaal model houdt de gewichten permanent in het videogeheugen of het werkgeheugen. Hier is geheugen een directe kostenpost die je vooraf moet reserveren. Daar staat tegenover dat er geen netwerkvertraging is en de upload vrij blijft.

Hoeveel videogeheugen vraagt een lokaal model

De exacte cijfers hangen af van het model en de kwantisering, maar je kunt rekenen met de formule: aantal parameters maal de opslagbreedte. Bij 4-bit kwantisering neemt elk miljard parameters iets meer dan een halve gigabyte in — plus overhead voor interne buffers en de contextcache. Daaruit volgen praktijkrichtlijnen voor VRAM:

• model van 3–4 miljard parameters in 4 bit — ongeveer 2–3 GB;
• 7–8 miljard parameters in 4 bit — ongeveer 4,5–5,5 GB;
• 13–14 miljard parameters in 4 bit — zo'n 8–9 GB;
• 30–34 miljard parameters in 4 bit — ongeveer 18–20 GB.

Tel bij deze getallen de contextcache op: die groeit mee met de lengte van het gesprek en kan bij een lange correspondentie enkele gigabytes extra toevoegen. Volledige precisie in plaats van kwantisering vergroot het volume van de gewichten 3–4 keer en betekent bij een 1080p-stream bijna altijd dat er geen videogeheugen meer overblijft voor de game.

Welke modellen van 7–8 miljard voor een stream

De klasse 7–8B in 4-bit kwantisering is de werkbare middenweg voor builds met 12–16 GB VRAM. Voor een chat-assistent van de streamer kijk je naar instruct-versies van families als Qwen, Llama, Mistral, Gemma: die worden voorspelbaar volgens bovenstaande formule berekend en passen binnen de genoemde volumes. Het verschil tussen hen zit in de kwaliteit van de antwoorden in het Nederlands en in de generatiesnelheid, niet in de geheugeneisen — het aantal parameters is ongeveer gelijk.

Voor een assistent die de chat leest en reacties in korte uitspraken aandraagt, volstaat 7–8B bij een gematigde context. Modellen van 3–4B zijn duidelijk zwakker in samenhangende tekst, maar maken 2–3 GB vrij voor de game. Volledige, niet-gekwantiseerde gewichten van 7–8B nemen vele malen meer in beslag en passen bij een 1080p-stream niet binnen het budget.

VRAM-tekort en offload: hoe dat de berekening verandert

Als de gewichten niet in het videogeheugen passen, gaan een deel van de lagen via offload naar het systeemgeheugen — en het model blijft werken. De prijs daarvoor is snelheid: de uitwisseling gaat over de bus, de inferentie vertraagt, en zowel RAM als VRAM gaan tegelijk in de min. Offload heft de berekening niet op — het verplaatst de kosten van VRAM naar RAM en verlaagt de antwoordsnelheid.

Daarom is "een groter model nemen en offload aanzetten" tijdens een actieve stream een compromis op het randje: de assistent doet er langer over, en het systeem begint te swappen bij de pieken van de game. Je kunt beter een kleiner model nemen en dat volledig in het vrije restant laten passen.

Werkgeheugen

Draait het model op de CPU, dan verhuist het verbruik naar het RAM: diezelfde halve gigabyte per miljard parameters in 4 bit plus buffers. Een model van 7–8B op de processor neemt ongeveer 5–6 GB RAM in beslag bovenop de behoeften van het systeem, de game en de encoder, en inferentie op de CPU gaat merkbaar langzamer — de assistent antwoordt met een voelbare pauze. Softwarematig coderen van 1080p belast de processor op zichzelf al, en daar inferentie op dezelfde CPU bij optellen is een zekere manier om drops te krijgen.

Waarom je niet al het vrije geheugen kunt geven

De verleiding is simpel: er is zoveel vrij — ik geef alles aan het model. Dat is een fout. Geheugen is nodig als buffer voor pieken: het laden van assets in de game, bitrate-pieken bij de encoder, achtergrondwerk van het systeem. Als het model het restant heeft ingenomen, begint het systeem te swappen — en krijg je haperingen waarvan je de oorzaak niet meteen vindt. Pieken in een stream komen op de meest onhandige momenten — bij dynamische scènes en bij het wisselen van locatie.

Waarmee je het gebruikte geheugen op de piek meet

Gemiddelden uit Taakbeheer misleiden je: je hebt de piek nodig tijdens een gevecht, niet bij een rustig scherm.

• nvidia-smi met verversing in een loop toont het gebruikte VRAM en de totale limiet per proces;
• MSI Afterburner met RivaTuner-overlay toont het gebruikte VRAM en de GPU-belasting direct over de game heen — handig om de piek op het oog te volgen;
• de ingebouwde statistieken of de overlay van het stuurprogramma geven dezelfde waarden zonder extra programma's;
• Taakbeheer en Resourcemonitor heb je nodig voor RAM en swap — daar zie je wanneer het systeem pagina's begint weg te schrijven.

Kijk niet naar het gemiddelde, maar naar het maximum per sessie: dat bepaalt wat er voor het model overblijft.

Hoe je het volume afstemt op je build

1. Start de game en de encoder in de echte 1080p-modus en meet de piek via nvidia-smi of de Afterburner-overlay.
2. Trek de piek af van het beschikbare volume — dat geeft de bovengrens voor het model, met marge voor pieken.
3. Start de assistent en houd de frames, de swap en de antwoordtijd in de gaten.
4. Krijg je haperingen — verkort eerst de context, verlaag daarna de modelklasse of schakel agressievere kwantisering in, en herhaal tot de drops en de swap verdwijnen.

De methode vraagt om herhaald meten: pieken veranderen per game en per scène.

Wat echt geheugen bespaart

Is geheugen schaars, dan zijn er meerdere knoppen, en elk heeft zijn prijs:

• een kortere context en het resetten van de geschiedenis verlagen het cacheverbruik, maar je verliest de rode draad van het gesprek;
• een kleiner model of agressievere kwantisering bespaart gigabytes, maar de kwaliteit van de antwoorden gaat omlaag;
• een cloud-assistent maakt lokaal geheugen volledig vrij, maar voegt vertraging en afhankelijkheid van het netwerk toe;
• 1080p overzetten naar de hardware-encoder haalt de last van de processor en levert vaak meer op dan het puzzelen met gigabytes;
• het beperken van de antwoordlengte en de geschiedenisgrootte in de clientinstellingen houdt het cacheverbruik voorspelbaar.

Begin bij de encoder en de context: dat zijn de maatregelen die qua kwaliteit het goedkoopst zijn. Raak kwantisering en een kleiner model pas aan als die stappen niet genoeg waren.