Lokale AI: van laptop naar een betrouwbare teamvoorziening

Vier lagen die je uit elkaar moet houden

Bij lokale AI helpt een eenvoudige indeling. Het model bevat de getrainde gewichten. De runtime voert de berekeningen uit. De toepassing regelt bijvoorbeeld het gesprek, documenten en uitvoercontrole. De infrastructuur levert rekenkracht, opslag, netwerk en toegangsbeheer.

Ollama en llama.cpp zijn voorbeelden van software waarmee je modeluitvoering kunt organiseren. llama.cpp ondersteunt verschillende hardwarebackends, quantisatie en verdeling van berekeningen over CPU en GPU. Ondersteuning hangt wel af van de combinatie van model, hardware en softwareversie. [1]

Dit onderscheid voorkomt een dure misvatting: een andere chatinterface verhelpt niet automatisch te weinig geheugen, en een snellere videokaart corrigeert geen slechte documentselectie. Bepaal eerst in welke laag je probleem zit.

Hoeveel geheugen heeft een model nodig?

Voor de gewichten van een dicht model kun je een eerste rekensom maken: aantal parameters × bits per parameter ÷ 8. Vier miljard parameters op 4 bits is theoretisch ongeveer 2 GB, in decimale eenheden. Acht miljard parameters op 4 bits komt op ongeveer 4 GB. Dit zijn geen minimale systeemeisen: het zijn uitsluitend theoretische groottes van de gewichten.

Quantisatie slaat waarden met minder precisie op. In echte bestanden komen daar onder meer schaalfactoren, metadata en mogelijk onderdelen met hogere precisie bij. Tijdens het draaien zijn ook werkruimte, runtime en contextgeheugen nodig. Andere toepassingen en het besturingssysteem gebruiken eveneens geheugen. Bij een model met meerdere experts mag je het aantal per token actieve parameters niet zomaar gebruiken als totale opslagomvang.

Let bovendien op het soort geheugen. RAM is het werkgeheugen van de computer; VRAM zit op een afzonderlijke GPU. Bij unified memory delen CPU en GPU een geheugenpool, waarvan niet alles vrij beschikbaar is voor jouw model. Je kunt “16 GB RAM plus 8 GB VRAM” niet zonder meer behandelen als één even snelle pool van 24 GB.

Een model dat gedeeltelijk buiten het GPU-geheugen valt, kan soms nog draaien met hulp van de CPU. Dat kan de snelheid veranderen. Meet daarom de werkelijk gebruikte configuratie. Alleen zien dat het model geladen wordt, zegt weinig over de bruikbaarheid tijdens je werk.

Lange documenten en extra gebruikers veranderen de rekening

De context is de tekst die het model tijdens een aanroep kan meenemen: instructies, gespreksgeschiedenis, documentfragmenten en ruimte voor de uitvoer. Tokens zijn teksteenheden; hun verhouding tot woorden verschilt per taal en tokenizer. Een groot contextvenster op de modelkaart betekent niet dat je runtime dat venster ook heeft ingesteld, of dat je hardware het comfortabel aankan.

Meer context vraagt extra geheugen. Ollama documenteert hoe je de ingestelde context en de verdeling over CPU en GPU controleert. [2] Gelijktijdige verzoeken kunnen extra contextgeheugen vereisen; te veel aanvragen leiden afhankelijk van de configuratie tot wachtrijen of fouten. [3]

Een bruikbare capaciteitstest heeft daarom minstens drie situaties: een korte vraag, het langste document dat je echt verwacht en meerdere van zulke verzoeken tegelijk. Meet niet alleen tokens per seconde, maar ook wachttijd, tijd tot het eerste zichtbare antwoord, totale taakduur en piekgeheugen. Een snelle korte demo is geen capaciteitsplan.

Thuis: begin met de computer die je al hebt

Voor een eerste proef heb je geen complete serveromgeving nodig. Kies één afgebakende taak, één compatibel model en een interface waarmee je de invoer en uitvoer kunt controleren. Gebruik eerst niet-gevoelige voorbeelden. Download de benodigde bestanden voordat je offline gebruik test.

1. Leg je uitgangspunt vast. Noteer vrij RAM, eventuele GPU en VRAM, besturingssysteem en hoeveel vrije opslag je hebt.
2. Begin klein. Kies een bescheiden modelvariant en een context die bij je voorbeelden past. Een lagere geheugenbehoefte kan komen door een kleiner model, quantisatie of een kortere context; dat zijn verschillende ingrepen.
3. Test een echte werksessie. Houd je normale programma’s open. Kijk of je laptop begint te wisselen naar schijfgeheugen, onprettig warm wordt of te traag reageert.
4. Vergelijk vóór je koopt. Bewaar dezelfde testgevallen voor een eventuele krachtigere machine. Meer hardware is pas zinvol als je weet welke beperking je ermee oplost.

Noteer modelnaam én variant. Een 4-bit versie is niet automatisch inhoudelijk gelijk aan de oorspronkelijke versie. Bewaar ook de prompt die goed werkte, zodat je bij een update kunt vaststellen of de uitkomst veranderde.

Voor een team: bouw toegang en begrenzing eromheen

Voor een gedeelde interne toepassing is dit een mogelijke basisarchitectuur. Het is een ontwerppatroon, geen kant-en-klare veilige installatie:

1. GebruikersinterfaceCollega’s melden zich aan met hun eigen account.
2. ToepassingslaagControleert rechten, begrenst invoer en zet aanvragen in een wachtrij.
3. Modelserver op een intern netwerkVerwerkt toegestane verzoeken met een vastgelegde modelconfiguratie.
4. UitvoercontroleValideert het resultaat en vraagt waar nodig menselijke goedkeuring.

Een API is hier de afgesproken manier waarop de toepassing de modelserver aanroept. Dat maakt nog geen toegangsbeveiliging. Ollama luistert standaard op het lokale adres 127.0.0.1; een configuratiewijziging kan de server bereikbaar maken voor andere apparaten. [3] Zet zo’n endpoint niet rechtstreeks op internet. Regel onder meer authenticatie, versleuteld verkeer, netwerkafscherming en limieten op aanvragen in de omliggende infrastructuur.

Maak ook een onderscheid tussen lezen en handelen. Een assistent die documenten samenvat hoeft geen bestanden te kunnen verwijderen. Laat risicovolle acties buiten het model om autoriseren. Behandel tekst uit documenten als informatie, niet als toestemming om systeeminstructies te veranderen.

Eigen documenten vragen een eigen gegevensroute

Voor vragen over bedrijfsinformatie kun je relevante passages ophalen en aan de modelinvoer toevoegen. Dit heet retrieval-augmented generation, meestal afgekort tot RAG. Het model wordt daarmee niet opnieuw getraind. De toepassing selecteert informatie die het model bij die specifieke vraag mag gebruiken.

Die route bevat meer dan een zoekindex: documenten inlezen, tekst extraheren, fragmenten maken, terugvinden en bronverwijzingen tonen. Controleer toegangsrechten vóórdat fragmenten naar het model gaan. Een verborgen document achteraf uit het antwoord filteren is geen volwaardige vervanging voor die controle.

Voor volledig lokale verwerking moeten ook documentextractie, eventuele embeddingmodellen en zoekopslag lokaal draaien. Embeddings zijn numerieke representaties waarmee je onder andere op betekenis kunt zoeken. Niet elke kleine verzameling heeft daarvoor een aparte vectordatabase nodig: begin met de zoekmethode die je taak aantoonbaar goed bedient.

Test ontbrekende en tegenstrijdige bronnen. Het systeem moet kunnen aangeven dat het antwoord niet uit de beschikbare informatie volgt. Een bronverwijzing is pas nuttig als de aangehaalde passage de conclusie werkelijk ondersteunt.

Wanneer is de proef klaar voor dagelijks gebruik?

Een werkende demonstratie is het begin. Voor een team moet duidelijk zijn wie updates uitvoert, welke gegevens in logs terechtkomen, hoe lang die nodig zijn en hoe je teruggaat naar de vorige werkende versie. Bewaar modellen, prompts en toepassingsconfiguratie als herkenbare versies.

Voer vóór een wijziging dezelfde kwaliteitstest uit en test herstel na uitval. Wat ziet iemand als de server vol zit? Gaan taken verloren? Wordt er zonder melding naar een cloudmodel uitgeweken? Ontwerp die antwoorden vooraf, inclusief een begrensde wachtrij en een begrijpelijke foutmelding.

Pas daarna kun je hardware begroten op echte belasting. Thuis kan wat extra wachttijd acceptabel zijn. Voor een team zijn voorspelbare responstijden, herstelbaarheid en een verantwoordelijke beheerder vaak belangrijker dan de snelste losse modelaanroep.