De meest onthullende maatstaf voor lokale AI staat niet vetgedrukt op de doos. Hij heet geheugenbandbreedte, wordt uitgedrukt in gigabytes per seconde, en bepaalt of een model soepel draait op je machine of hakkend de dood in stevent. Wie serieus met AI wil experimenteren en leunt op de TOPS- en NPU-cijfers zoekt op de verkeerde plek. Rekenkracht is goedkoop geworden. Bandbreedte is het schaarse goed.

Dat klinkt contra-intuïtief, en dat is het ook. Daarom loont het om nauwkeurig te kijken — niet naar benchmarkranglijsten, maar naar wat er werkelijk in de behuizing gebeurt wanneer een model token voor token samenstelt.

Waarom bandbreedte wint

Taarmodellen werken autoregressief. Elk volgend woord ontstaat pas nadat het volledige gewicht van alles tot dan toe één keer door het geheugen is gestroomd. De vermenigvuldigingseenheden wachten niet op zware wiskunde — zij wachten op geheugen. Begrijp dat, en je begrijpt waarom een videokaart met weinig VRAM nutteloos is tegen een groot model, hoe snel zijn shaders ook tikken: het model moet passen en doorstromen, elke stap.

Grofweg: tokens per seconde benaderen geheugenbandbreedte gedeeld door modelgrootte. Een zeventig-miljard-parameter-model in 4-bit-kwantisering neemt bijna veertig gigabyte in. Door een pijp van 273 GB/s stroomt dat in theorie rond zeven tokens per seconde — min overhead, min KV-cache, min alles wat het besturingssysteem ernaast doet. Door gewone laptop-DDR van 64 GB/s wordt dezelfde rekensom een oefening in geduld. Beide keren zitten de rekenkernen stil. Het verschil ligt uitsluitend in de breedte van de pijp.

Juist daarom zijn recentelijk chips interessant geworden die niemand op een lijstje van ‘AI-versnellings’ zou hebben gezet.

Twee chips die niemand op het lijstje had

Beschouw eerst de Apple M4 Pro. Apple geeft ongeveer 273 GB/s aan unified-memory-bandbreedte — gedeelde opslag voor zowel CPU als GPU, configureerbaar tot 48 gigabyte. Niets eraan is een datacenter-accelerator. Maar omdat het geheugen zo breed is aangesloten en voor CPU en grafische eenheid gelijkelijk zichtbaar, draaien middelgrote modellen verrassend vloeiend. Dat is geen marketingmagie; het is fysica.

Ten tweede de AMD Ryzen AI Max+ 395, codenaam Strix Halo. AMD specificeert tot 256 GB/s, eveneens unified, en het platform houdt tot 128 gigabyte LPDDR5X. Je vindt hem in compacte mini-pc’s, werkstation-laptops en apparaten zoals de Framework Desktop. Opnieuw: geen H100, geen wondermachine. Maar wie een groot model volledig in snel geheugen kan leggen terwijl een concurrerende kaart verstikt in out-of-core-swapping, haalt plots realistische doorvoersnelheden voor geld dat elders slechts een fractie van een professionele kaart koopt.

Eerlijkheid is hier verplicht. Geen van beide chips is magie. Thermisch throttling onder blijvende belasting is real, vooral in smalle behuizingen. Volwassenheid van drivers en runtimes verschilt: Apples Metal-pad is glad; AMD’s ROCm/OpenCL-route is verbeterd maar blijft ruwer dan de CUDA-wereld waarnaar alles wordt gemeten. En natuurlijk blijft een enkele desktop-chip mijlenver achter bij wat een H200- of B200-kaart in een rack levert. Beweringen dat consumentenhardware ‘net zo goed’ is, zijn onzin. Beweringen dat hij irrelevant is, ook.

Een droge observatie: benchmarkdiagrammen liegen routinematig, omdat ze tijd-tot-eerste-token meten op een warme cache — niet dinsdagmiddags, zes tabbladen open, de helft van het model geswapt. Plan AI onder belasting, niet in het laboratorium.

Fase een: klikken en verwonderen

Het natuurlijke begin loopt via bureaublad-apps. Ollama trekt een GGUF; LM Studio biedt een nette interface om modellen te bladeren, kwantiseringen te vergelijken, dingen uit te proberen. Dat is waardevol. Het is de snelste route om te voelen hoe een 8B-, 13B- of 32B-model zich gedraagt, waar de kwaliteitscurve buigt, waar 4-bit nog acceptabel is en waar niet meer.

Deze fase is speels, en dat hoort. Wie hier meteen ‘architectuur!’ roeit mist het punt: je moet voelen wat de tools doen voordat je ze formaliseert. Maar de grenzen tonen zich spoedig. Alles hangt vast aan één machine, één gebruiker, één grafische sessie. Zodra een tweede persoon het model wil, zodra een nachtelijk script automatisch moet infereren, wordt de GUI een obstakel. Netwerktoegang voelt aangeplakt, niet ontworpen.

Fase twee: het bureau wordt een server

Op een gegeven moment volstaat dat niet meer. Je wilt één endpoint dat het hele kantoor, het hele thuisnetwerk, alle automatisering kan bereiken. Je bindt Ollama of een lichtgewicht runner aan ::, plaatst OpenWebUI ervoor — meerdere gebruikers, authenticatie, modelselectie, document-chat — en wijst tools zoals opencode, de CLI-code-agent, naar het lokale OpenAI-compatibele endpoint.

Opeens is het werkstation infrastructuur. Elke editor, elke collega, elke pijplijn spreekt naar hetzelfde adres. Dat is een ware paradigma-wissel, ook al ziet hij er technisch klein uit: een applicatie is een dienst geworden. En met de dienst komen de plichten die infrastructuur kent — transportversleuteling, authenticatie, logging, updates, modelgovernance. Wie deze stap zet is opgehouden met prutsen en begonnen met beheren. Velen merken dat pas wanneer iemand anders voor het eerst toegang krijgt tot het model.

Fase drie: wanneer het ophoudt speelgoed te zijn

Groeiende ambitie brengt de volgende laag gereedschap. vLLM is de motor die GPU-inferentie economisch maakte — continue batching, PagedAttention, hoge doorvoer, schoon omgaan met veel gelijktijdige verzoeken. LiteLLM gaat ervoor zitten als proxy en router: één uniforme, OpenAI-vormige API boven veel backends, sleutelbeheer, fallback-paden, budget-routering, integratie met metrics en logging. En Bifrost is het soort project dat je ontmoet zodra je GPU-capaciteit begint te poolen en delen tussen workloads of huurders in plaats van een kaart aan één proces te wijden — benutting boven heldenkastjes.

Deze tools belonen grotere hardware: meerdere GPU’s per node, NVLinks, een rack in plaats van een bureau. Maar ze straffen nalatigheid ook harder af. Continue batching helpt alleen wanneer genoeg verzoeken tegelijk binnenkomen — voor de eenzame power-user betaalt de overhead zichzelf nooit terug. Een router is waardeloos met enkel een sloom backend erachter. Pooling werkt alleen als fair-share, wachtrijdiepte en koude starts serieus worden beheerd. Kortom: op dit punt houdt experimenteren op en beginnen verdeelde systemen. Monitoring, scheduling, kostentoerekening, update-strategieën — allemaal bekend uit klassieke IT-operaties, nu onverwachts deel van AI.

Veel homelabbers raken deze muur en kiezen een van twee wegen: terugtrekken naar een comfortabele enkele doos die goed genoeg is — of bewust de stap zetten naar echt beheer. Beide legitiem. Geloven dat nog een klik je erlangs tilt, is een vergissing.

De moeilijke kunst: hardware en software samen denken

Hier zit de werkelijke moeite. Nooit hardware alleen of software alleen wint. Parairing is alles.

Koop een enorme GPU en stuurt hem door een single-stream-runner zonder batching, dan verspil je negentig procent van zijn vermogen. Richt vLLM in voor een werkplek met één gebruiker en je betaalt overhead zonder回报. Pers een groot model in 4-bit waar 8-bit kwalitatief nodig was en je spaart geheugen en verliest precisie. Omgekeerd, laat alles in FP16 draaien omdat “hoger beter klinkt”, pas minder in VRAM, en bevries. Kwantisering is geen schakelaar maar een regelaar. Koeling, geluid en constant vermogensverbruik bepalen of een apparaat in de woonkamer mag staan of thuishoort in de kelderlab. Afschrijving hoort in de berekening, niet in de voetnoot.

En dan de olifant die niemand graag ziet: API-prijzen. Ze lijken goedkoop — centen per miljoen tokens — tot het volume oploopt. Agentic-loops vermenigvuldigen verzoeken vaak tien- tot honderdmaal. Retry-stormen, redundante retrieval-passages, breedsprakige systeem-prompts die elke turn opnieuw worden verzonden, een verkeerd gedimensioneerd model voor een triviale taak: een goedkoop experiment wordt een maandfactuur van vier cijfers. De methode bepaalt de prijs sterker dan het tarief.

Zelf-hosting keert dit om: vaste kosten in plaats van variabele. Ergens breekt het economisch, maar alleen bij behoorlijke benutting. Een GPU die de hele dag ledig draait verenigt de nadelen van twee werelden — aanschaf en opportuniteitskosten. Romantiek helpt hier niet. Er is rekenwerk voor nodig, en de eerlijkheid om je eigen benutting realistisch in te schatten in plaats van te idealiseren.

Een reden om te vieren

Door alle moeite heen is er reden om te vieren, en die weegt zwaar: de hele hiërboven beschreven ladder is open source. Ollama, llama.cpp, vLLM, LiteLLM, Bifrost, OpenWebUI, opencode — gemeenschapsgebouwd, inspecteerbaar, auditeerbaar, forkable. Niemand kan je ze afnemen, niemand kan ’s nachts de voorwaarden herschrijven zonder jou de optie te laten stil te blijven staan.

Één nuance hoort hier: LM Studio is handig, maar niet vrij in OSI-zin. Gratis voor persoonlijk gebruik, anders commercieel gelicenseerd. Wie waarde hecht aan consequent vrije software kiest het Ollama- en llama.cpp-pad. Dat is geen dogma; het is een verheldering die je moet kennen voordat je er architecturen op bouwt.

Breder bekeken: AI heeft ons beroepsleven opgeschud — allemaal, op de een of andere manier. Hij kwam, en hij blijft; daarvan ben ik zeker. Hem ontkennen is nostalgie. Maar naïviteit is precies het tegenovergestelde en net zo fout. Gemak verbergt afhankelijkheid, en verbergt kosten die stil stijgen. De wetende houding is: gebruik AI bewust, op jouw voorwaarden, begrijpend wat het kost, wat het kan en waar het faalt. Dat is geen houding tegen de technologie. Het is een houding voor je eigen handelingsbekwaamheid.

Wat dit met libcom.de te maken heeft

Sinds een kwarteeuw bouw ik — Jochen Demmer, libcom.de — op open-source-infrastructuur. De laatste jaren hoort daar steeds vaker het beheren van AI-stacks op eigen hardware bij: loganalyse, conceptwerk, codereview, interne assistentiesystemen, documentzoek. Niet als demo, maar in de dagelijkse praktijk en op klantsystemen.

Uit die praktijk komen oordelen die geen tutorial leert: waar de break-even tussen API en eigen bedrijf omslaat, hoe de kwantizerings/kwaliteits-regelaar staat voor welke workload, welke netwerk- en veiligheidsarchitectuur een netjes blootgestelde enterprise-inference-endpoint vereist — en waar de grens ligt tussen een homelabspeeltje en een beheerde dienst. De frequentste taak is niet hardware aanschaffen, maar de juiste hardware paren met de juiste serving-strategie, in plaats van eerst een dure doos kopen en dan zoeken naar software die haar rechtvaardigt.

Als jij je afvraagt of lokale AI zinvol is voor jouw omgeving, welke hardware past bij geplande software, en hoe een stack eruitziet die na drie maanden niet instort: schrijf naar contact@libcom.de. Wij nemen eerlijk inventaris — open, zonder verkoopdruk, met de blik op wat langdurig standhoudt.

Het begint met nieuwsgierigheid en eindigt, voor wie het serieus neemt, met infrastructuur. Daartussen ligt het mooiste ambacht dat momenteel opnieuw wordt uitgevonden — stukje bij beetje, op je eigen hardware, met open gereedschap.

Noot: Dit artikel biedt algemene oriëntatie over hardware- en softwarekeuze en kostenoverwegingen en vervangt geen aanschaf- of juridisch advies. Prestatie- en prijscijfers zijn illustratief en kunnen variëren met configuratie, driverstand en marktontwikkelingen; alle gegevens worden zonder garantie verstrekt.