Ervaringen met zelf gehoste AI assistenten

[R3m3d7]

DeNachtwacht schreef op zaterdag 13 juni 2026 @ 00:09:
[...]

Zo ben ik nu toevallig aan eht kijken of het slim is OpenClaw om te wisselen voor Hermes.. nou youtube zit vol met clickbait overstap filmpjes zoals altijd, maar werkelijk geen één die echt degelijk/betrouwbaar oogt... websites idem dito. Dat is weer het nadeel van die AI wereld je weet nog niet wat de echt goed betrouwbare bronnen zijn.

Ik heb geen ervaring met openclaw maar heb wel iets van 6 hermes agents draaien op verschillende containers voor verschillende rollen voor mijn hele gezin. Ik lees en zie dat mensen klagen dat openclaw soms/vaak breekt bij updates. Ik heb geen idee of dit echt zo is maar ik heb nog nooit een issue gehad na een hermes update en draai veel updates. Dat zou voor mij een reden zijn om overstappen te overwegen.

[DeNachtwacht]

@Deepflame ja, mijn daily driver is nu ook Qwen 3.6:27B, is zelfs de eerste die echt bruikbaar is voor coding ook. Maar die TurboQuant versie ziet er idd ook goed uit, hopen dat dat snel naar Ollama komt. Mijn OpenClaw draait op een aparte linux mini pc en gebruikt de Ollama server op het netwerk, dat is wel lekker gebruiksvriendelijk dus daar weer vanaf stappen doe ik ook niet snel. Hopen dat Ollama TurboQuant ook gaat ondersteunen.

[Martinspire]

ZpAz schreef op vrijdag 12 juni 2026 @ 23:26:
[...]

[Afbeelding]
Misschien dat de trend recentelijker is omgekeerd, ik gebruikte het niet zoveel in GPT 3 tijd eigenlijk. Maar bouw nu een jaar aan agentic systemen - en tot nu toe was dat wel mijn ervaring dat elke update wat duurder was dan voorheen.

Behalve DeepSeek V4, die bleef permanent op 75% korting staan. Woo.

----

Hier kan je trouwens benchmarked (en ook open source) modellen vergelijken. En ook 'prijs per intelligentie'

Mja die lijn zet zich nog wel even door, denk ik. En dat is ook meteen het jammere aan de nieuwe modellen: ze zijn enorm duur en je krijgt er maar marginaal betere antwoorden van. Want sure de marketing doet het allemaal een stuk beter lijken, maar ze zijn zwaarder om te draaien en kosten dus ook meer geld. Dan heb ik liever een iets minder zwaar LLM maar een normale prijs. Het loont echt om gewoon een paar versies achter te lopen als je nog een beetje van je geld houdt. Maar qua self hosting zie ik vooral stilstand momenteel.

[Ruitenwisser]

Mijn Ollama en OpenWebUI containers werkend gekregen.

code:

ollama pull gemma4:31b

Volgens Ollama library zou deze 20 gig moeten innemen maar hij neemt 37 GiB in beslag. Vreemd

code:

root@Ollama:~# ollama ps
NAME          ID              SIZE     PROCESSOR          CONTEXT    UNTIL              
gemma4:31b    6316f0629137    37 GB    51%/49% CPU/GPU    32768      4 minutes from now

Eens een nieuwe pull aan het doen en opnieuw proberen. Samen met system RAM gaat het inderdaad wel vree traag.

[DeNachtwacht]

@Ruitenwisser je kan het best even kijken in welke kwantisatie je hem gedownload hebt (met 'ollama list' zie je direct hoe groot het gedownloade model zelf is, dit zou idd 20GB moeten zijn). De context kan vrij hard oplopen maar inderdaad is 37GB wel fors met 32K context. Gek is alleen dat het grootste model inderdaad 20GB kan zijn, dat zo weinig context 17GB zou zijn vind ik ook wat vreemd.

Maar onderschat niet hoe groot dat kan zijn. Ik draai hier 192K context met Qwen 3.6B 27B, dat model is 17GB groot, en inclusief context blijft alles veilig binnen 29GB van mijn 32GB VRAM. Misschien kost de context bij Gemma meer data?

[Ruitenwisser]

DeNachtwacht schreef op zaterdag 13 juni 2026 @ 20:40:
@Ruitenwisser je kan het best even kijken in welke kwantisatie je hem gedownload hebt (met 'ollama list' zie je direct hoe groot het gedownloade model zelf is, dit zou idd 20GB moeten zijn). De context kan vrij hard oplopen maar inderdaad is 37GB wel fors met 32K context. Gek is alleen dat het grootste model inderdaad 20GB kan zijn, dat zo weinig context 17GB zou zijn vind ik ook wat vreemd.

Maar onderschat niet hoe groot dat kan zijn. Ik draai hier 192K context met Qwen 3.6B 27B, dat model is 17GB groot, en inclusief context blijft alles veilig binnen 29GB van mijn 32GB VRAM. Misschien kost de context bij Gemma meer data?

Geen idee met betrekking tot context kosten. Dit is de allereerste keer dat ik zelf een LLM draai. Meer prutsen dus om het te leren kennen

Heb nu ook de 26B model gedownload en die gaat vliegensvlug. De 31B model blijft 37GB.

code:

root@Ollama:~# ollama list
NAME          ID              SIZE     MODIFIED          
gemma4:26b    5571076f3d70    17 GB    29 minutes ago       
gemma4:31b    6316f0629137    19 GB    About an hour ago 
root@Ollama:~# ollama ps
NAME          ID              SIZE     PROCESSOR          CONTEXT    UNTIL              
gemma4:31b    6316f0629137    37 GB    51%/49% CPU/GPU    32768      4 minutes from now  
root@Ollama:~# ollama ps
NAME          ID              SIZE     PROCESSOR    CONTEXT    UNTIL              
gemma4:26b    5571076f3d70    17 GB    100% GPU     32768      4 minutes from now

[DeNachtwacht]

@Ruitenwisser de context is zegmaar simpel gezegd de lengte van de chat voordat de kennis die daarvoor zat, verdwijnt. Dus je hebt 32.000 tokens aan communicatie met het model voordat de eerste regel helemaal bovenaan verdwijnt en hij vergeet dat dit besproken is. Je ziet dat in beide gevallen, ook in deze uitput, de context 32768 is (dus 32K). Dat is ook de ollama default.

Waarom Gemma 26B zo snel blijft omdat je ook ziet dat deze 100% op de GPU draait: zodra dat niet zo is, wordt een stuk van het model naar het DDR geheugen ge-offload, en dat is echt fors trager dan je VRAM. Ik snap zelf alleen dus ook niet goed waarom de 31B variant meteen 37GB groot is inclusief 32K context, dat was best logisch geweest als hij op 256K context had gestaan (zie hierboven ook dat 192K context bij mij dus ook al ruim 12GB is).

Misschien zou je het 31B model eens kunnen verwijderen en opnieuw installeren. In ieder geval wil je altijd zorgen dat als het enigszins kan, het model+context in je Vram past zodat je er lekker snel mee kan werken. Maar zo te zien heb je dus een GPU met 24GB vram, dus de 4090?

[Ruitenwisser]

@DeNachtwacht Dank voor de uitleg, ik zal wat meer experimenteren met de context en andere modellen. Gelukkig dat ik onbeperkt internet heb haha

Ik heb de 31B variant opnieuw gedownload en het bleef hetzelfde, vreemd dus.

Ik heb 2x RTX3060 wat uitkomt op 24GB.

[DeNachtwacht]

Aaahhh wacht ik heb het uitgezocht en gevonden.

Gemma 4 31B is een dense model. Dit betekent dat alle 31B beschikbaar zijn en te activeren zijn. Gemma 4 26B heeft A4B achter de naam, wat betekend dat het een MoE ofwel mixture of experts is: hij heeft 26B, maar het aantal actieve connecties zijn max 4B die dus veel sneller en slimmer te benaderen zijn.

Daardoor kan de cache bij 26B veel kleiner zijn. Bij een dense model is de cache veel groter omdat alle "neuronen" te benaderen moeten zijn. Dus het is simpelweg normaal dat hij 37GB is bij dit model. Ik zou het dus lekker bij 26B houden en de context ook iig op 64K zetten en ook eens proberen of zelfs 128K past in het geheugen zonder dat je naar het ram hoeft te offloaden. Want 32K wordt doch altijd best wel een nadeel bij wat langere chats omdat hij relatief snel dingen vergeet. Ideaal is altijd 128K als je dat minimaal haalt, afhankelijk van de taak natuurlijk. Als je alleen simpel wat promptjes wil doen kan 32K wel genoeg zijn, maar zeker als je er een agent mee aanstuurt of wil programmeren is minimaal 128K wel lekker.

[DeNachtwacht]

Maar ik zit nu te kijken, misschien komt het wel door je setup van 2x 12GB VRAM. Daardoor past één model dus al niet op 1 videokaart. Hoe zijn deze kaarten verbonden, gewoon op aparte PCIe sloten in een normaal moederbord? Kan best zijn dat de cache dan ook x2 gaat omdat het op beide GPU's beschikbaar moet zijn.

[Ruitenwisser]

Top man, je bent me voor. Ik was momenteel eerst aan het uitvogelen hoe ik die Qwen3.6 27B Q4 kon inladen want met 'ollama run' vond ie hem niet. Chatgpt zei lokaal downloaden en dan zelf bouwen.

Wel, mijn doel is een projectje dat ik wil laten programmeren. Ik heb met claude een .org document zitten maken met coding standaarden en het project in verschillende fasen opgedeeld, met wat elke fase moet implementeren en krijgt fase de vorige fase. Het is een serieus document geworden, 150KB. En dermee dat ik Gemma gedownload had met dat ik las dat die wel goed was voor coding tasks.

Ja die zitten gewoon op aparte PCIe sloten.

EDIT: nu wanneer qwen3.6-27B-Q5 aan het lopen is

code:

root@pve:~# nvidia-smi
Sun Jun 14 11:21:44 2026       
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 595.80                 Driver Version: 595.80         CUDA Version: 13.2     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 3060        Off |   00000000:02:00.0 Off |                  N/A |
| 30%   55C    P2            107W /  170W |    8883MiB /  12288MiB |     31%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+
|   1  NVIDIA GeForce RTX 3060        Off |   00000000:81:00.0 Off |                  N/A |
| 59%   72C    P2            127W /  170W |   10209MiB /  12288MiB |     49%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|    0   N/A  N/A           69277      C   ...local/lib/ollama/llama-server       8874MiB |
|    1   N/A  N/A           69277      C   ...local/lib/ollama/llama-server      10200MiB |
+-----------------------------------------------------------------------------------------+

[ Voor 5% gewijzigd door Ruitenwisser op 14-06-2026 11:22 ]

[Deepflame]

R3m3d7 schreef op zaterdag 13 juni 2026 @ 07:55:
[...]


[...]


Ik heb geen ervaring met openclaw maar heb wel iets van 6 hermes agents draaien op verschillende containers voor verschillende rollen voor mijn hele gezin. Ik lees en zie dat mensen klagen dat openclaw soms/vaak breekt bij updates. Ik heb geen idee of dit echt zo is maar ik heb nog nooit een issue gehad na een hermes update en draai veel updates. Dat zou voor mij een reden zijn om overstappen te overwegen.

OpenClaw had een wat rommelige periode tussen maart en begin mei, maar ondertussen hebben ze het concept van stable builds releasen ontdekt, en word er iets voorzichtiger gemerged. Daarnaast hebben ze de architectuur op de schop genomen waardoor het ook iets robuster geworden is.

Hermes heb ik inderdaad ook nooit problemen mee gehad, OpenClaw is iets wilder.

Het leuke van OpenClaw t.o.v. Hermes is dat je met 1 OpenClaw instance al die 6 agents kan draaien, in plaats van dat je 6 verschillende containers op moet zetten. Ik gebruik ze zelf allebei voor verschillende doeleinden. Hermes gebruik ik voor mijn "bouw" agent, en OpenClaw is mijn "planning" agent, die planning agent stuurt de bouw agent dan weer aan. Hermes blijft iets beter op z'n taak zitten vind ik.

[R3m3d7]

Deepflame schreef op zondag 14 juni 2026 @ 11:55:
[...]

OpenClaw had een wat rommelige periode tussen maart en begin mei, maar ondertussen hebben ze het concept van stable builds releasen ontdekt, en word er iets voorzichtiger gemerged. Daarnaast hebben ze de architectuur op de schop genomen waardoor het ook iets robuster geworden is.

Hermes heb ik inderdaad ook nooit problemen mee gehad, OpenClaw is iets wilder.

Het leuke van OpenClaw t.o.v. Hermes is dat je met 1 OpenClaw instance al die 6 agents kan draaien, in plaats van dat je 6 verschillende containers op moet zetten. Ik gebruik ze zelf allebei voor verschillende doeleinden. Hermes gebruik ik voor mijn "bouw" agent, en OpenClaw is mijn "planning" agent, die planning agent stuurt de bouw agent dan weer aan. Hermes blijft iets beter op z'n taak zitten vind ik.

Ik ben inderdaad begonnen met elke agent op 1 container maar nu gebruik ik de Hermes profiles om op 1 container meerdere Hermes agents te kunnen draaien en dat werkt goed. Je kan een schonen clone maken of het geheugen en de soul van het orgineel meenemen naar je nieuwe Hermes profile.

Ik weet niet of je daar op doelt maar dit kan nu wel met Hermes, je kan Hermes zelf vragen om dit voor je te regelen en voor je het weet heb je tig agents op 1 container draaien.

Voor mij is de volgende stap om lokaal Hindsight te gaan draaien en te zien of dit een nog beter ervaring is, hebben je hier toevallig ervaring mee?

[CSB]

Welke modellen gebruiken jullie voor je Hermes agents?

[Deepflame]

R3m3d7 schreef op zondag 14 juni 2026 @ 21:02:
[...]


Ik ben inderdaad begonnen met elke agent op 1 container maar nu gebruik ik de Hermes profiles om op 1 container meerdere Hermes agents te kunnen draaien en dat werkt goed. Je kan een schonen clone maken of het geheugen en de soul van het orgineel meenemen naar je nieuwe Hermes profile.

Ik weet niet of je daar op doelt maar dit kan nu wel met Hermes, je kan Hermes zelf vragen om dit voor je te regelen en voor je het weet heb je tig agents op 1 container draaien.

Voor mij is de volgende stap om lokaal Hindsight te gaan draaien en te zien of dit een nog beter ervaring is, hebben je hier toevallig ervaring mee?

Ah, cool. Dat wist ik niet. :-)

Ik heb zelf een soort van Hindsight gemaakt, ik laat mijn sessies altijd samenvatten door mijn lokale Qwen, dat schrijft ie weg in een journal, en ik injecteer de samenvattingen van vandaag en gisteren altijd in elke nieuwe sessie via een OpenClaw context engine plugin. Verder ook de instructie hoe mijn agent oude samenvattingen kan doorzoeken met memory_search tool en via de OpenClaw Active Memory plugin.

Met die features bij elkaar is mijn main agent doorgaans redelijk goed op de hoogte van dingen.

[Chadi]

DeNachtwacht schreef op vrijdag 12 juni 2026 @ 14:44:
[...]

Het lastige met dit soort sites is dat ontwikkelingen razendsnel gaan. Dit artikel prijst Qwen 2.5 aan en je leest over Gemma 3, inmiddels is Qwen 3.6 al twee maanden uit en Gemma 4 ook .

@Chadi wat bedoel je "en daar context aan geeft."? Het helpt als je iets duidelijker uitlegt wat je precies met die pdf's wil doen, en ook hoe groot ze zijn (2-3 A4? pdf's van boeken van 400 pagina's?).

Het gaat om medische pdf ongeveer 5 pagina's.

De AI moet dan een samenvatting maken voor de verschillende domeinen en dat op chronologische volgorde.

Ik kan het nu heel goed met de API van Google maar wil dat soort data niet online laten komen.

[CT]

Chadi schreef op maandag 15 juni 2026 @ 00:25:
[...]


Het gaat om medische pdf ongeveer 5 pagina's.

De AI moet dan een samenvatting maken voor de verschillende domeinen en dat op chronologische volgorde.

Ik kan het nu heel goed met de API van Google maar wil dat soort data niet online laten komen.

Dit raakt veel zaken, bijv. hoeveel gebruikers gaan het gebruiken, hoeveel op piek momenten tegelijk, is die 30s max. wachttijd per gebruiker ook in piek momenten?
En, is het altijd 5 pagina's (puur tekst) gaat dit groeien? zitten er plaatjes/grafieken etc in de pdf?

3090 met en model erop (gemini4 lijkt mij hier wel geschikt, maar nog een ding, licenties, gemini4 is volgens mij niet commercieel te gebruiken). Maar dan serveer je in 30s 1 pdf van 5 pagina's, pdf moet wel eerst naar tekst worden omgezet. En vind maar is een pdf->tekst library die het altijd goed doet en gratis is, dat is ook nog een uitdaging. Makkelijkst tegenwoordig is de pdf in plaatjes omzetten en die laten lezen door een model, helemaal als er grafieken in zitten, maar dat gaat die 30s wel oprekken...

Enfin, denk dat je met alleen videokaart en een model nog niet helemaal bent.

[DeNachtwacht]

Je wil hier wel een beetje kwaliteit voor en hebt ook voldoende context nodig voor dit soort klussen. Gemma 4 of Qwen 3.6 neemt bij mij zo'n 29GB VRAM met 192K context. Dus een 9700 Ai Pro GPU is denk ik wel de slimste keus.

Ik zou trouwens idd goed oppassen, als het medische data met ook persoonsgegevens is mag je dat idd niet zomaar in de cloud downloaden zonder zeer scherpe checks & balances. Als het AI bedrijf waarmee jullie werken ook de data traint om het model te verbeteren heb je een data lek.

[Liegebeest]

Sterker nog, sprekend als AI Officer in wording: zelfs experimenteren of bouwen aan wat je hier beschrijft moet je niet doen totdat jullie Data Officer daar expliciet toestemming voor heeft gegeven.

[DeNachtwacht]

@Liegebeest haha je weet wel dat je het hier hebt tegen hobbyisten op een forum

Nee maar je hebt zeker gelijk, in de AI wereld wordt volop ge-experimenteerd en hoewel de AI Act nog niet formeel rond is natuurlijk wordt die momenteel nog grootschalig (vaak goedbedoeld en uit onwetendheid) met voeten getreden.

[ocf81]

Ik heb er de tijd/energie niet echt voor, maar de OP is nu wat verouderd en moet eigenlijk een opfrisbeurt krijgen. Zaken als RAG en agenten moeten worden toegevoegd. Verder is het wellicht handig om de voor- en nadelen van de verschillende runners uit te leggen.
Zijn er nog mensen die willen bijdragen aan de OP?

[Liegebeest]

DeNachtwacht schreef op maandag 15 juni 2026 @ 13:30:

Nee maar je hebt zeker gelijk, in de AI wereld wordt volop ge-experimenteerd en hoewel de AI Act nog niet formeel rond is natuurlijk wordt die momenteel nog grootschalig (vaak goedbedoeld en uit onwetendheid) met voeten getreden.

Mwah, we hebben nog anderhalve maand.

https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act

Desondanks: AVG en de verschillende wet- en regelgeving omtrent medische gegevens zijn natuurlijk al veel langer van kracht. De AI Act komt daar bovenop.

[ Voor 11% gewijzigd door Liegebeest op 15-06-2026 15:03 ]

[DeNachtwacht]

Nou... https://www.rijksoverheid.nl/actueel/nieuws/2026/04/20/kabinet-zet-stap-met-toezicht-op-europese-ai-regels

De uitvoeringswet AI verordening stond tot 1 juni nog als concept ter consultatie open dus voorlopig zijn we nog niet bij uitvoering

Trouwens wel ook een slim idee ook, een meer "juridische vragen over AI" topic. Dat leeft best breed ook.

[ocf81]

Op zich is wat mij betreft een bredere discussie over de toepassing van LLM's/AI hier best welkom, maar ik denk dat het wel op de een of andere manier gerelateerd moet zijn aan het zelf draaien ervan om relevant te zijn voor deze discussie.

[Chadi]

CT schreef op maandag 15 juni 2026 @ 08:46:
[...]

Dit raakt veel zaken, bijv. hoeveel gebruikers gaan het gebruiken, hoeveel op piek momenten tegelijk, is die 30s max. wachttijd per gebruiker ook in piek momenten?
En, is het altijd 5 pagina's (puur tekst) gaat dit groeien? zitten er plaatjes/grafieken etc in de pdf?

3090 met en model erop (gemini4 lijkt mij hier wel geschikt, maar nog een ding, licenties, gemini4 is volgens mij niet commercieel te gebruiken). Maar dan serveer je in 30s 1 pdf van 5 pagina's, pdf moet wel eerst naar tekst worden omgezet. En vind maar is een pdf->tekst library die het altijd goed doet en gratis is, dat is ook nog een uitdaging. Makkelijkst tegenwoordig is de pdf in plaatjes omzetten en die laten lezen door een model, helemaal als er grafieken in zitten, maar dat gaat die 30s wel oprekken...

Enfin, denk dat je met alleen videokaart en een model nog niet helemaal bent.

Dankjewel voor het meedenken. Ik krijg juist nu van Gemini het voorstel om de originele pdf in te laden in plaats van foto's omdat tekst uit de originele makkelijker te extraheren is dan uit foto's. Er zitten geen grafieken in. Gemini 2.5 gebruikt ongeveer 15 seconden nu. Anthropic is iets sneller. Ik dacht zelf aan mistral om die op de server te zetten. Heb je daar ervaring mee?

[Chadi]

DeNachtwacht schreef op maandag 15 juni 2026 @ 09:23:
Je wil hier wel een beetje kwaliteit voor en hebt ook voldoende context nodig voor dit soort klussen. Gemma 4 of Qwen 3.6 neemt bij mij zo'n 29GB VRAM met 192K context. Dus een 9700 Ai Pro GPU is denk ik wel de slimste keus.

Ik zou trouwens idd goed oppassen, als het medische data met ook persoonsgegevens is mag je dat idd niet zomaar in de cloud downloaden zonder zeer scherpe checks & balances. Als het AI bedrijf waarmee jullie werken ook de data traint om het model te verbeteren heb je een data lek.

Er gaat op dit moment alleen dat in die verzonnen is om te kijken hoe scherp het model is. De software die op de achtergrond allerlei kusjes moet doen is al gebouwd. Nu kan je data anonimiseren maar ik heb voor de volgende stap liever al experiment binnen de eigen omgeving. Ik vertrouw derde partijen die zeggen dat data bij hun veilig is ook niet echt. Als het niet anders kan dan gaan we hun AI gebruiken omdat dat ook goedkoper is op de lange termijn.

Voor nu will ik kijken of het in huis kan blijven en of het doet wat ik wil dat het gaat doen.


Er worden maximaal 100 pdf documenten per dag verwacht nu. De software is zo ingesteld dat er nu genoeg tijd is tussen uploaden pdf en rond resultaat. Ik wil alleen de lab wel zo hebben dat ik niet heel erg lang hoef te wachten.

[ocf81]

Wat is het budget voor de proef? En wat zou het budget zijn voor de definitieve implementatie?

[DeNachtwacht]

Chadi schreef op maandag 15 juni 2026 @ 20:48:
[...]


Er gaat op dit moment alleen dat in die verzonnen is om te kijken hoe scherp het model is. De software die op de achtergrond allerlei kusjes moet doen is al gebouwd.

Sorry, je eerste zin snap ik niet en bij de tweede zin ben ik benieuwd wat de software / setup is om de LLM te draaien, en natuurlijk ook op welke hardware het is.

Wat in jouw geval ook belangrijk is om even te checken of het betreffende model vision heeft (= getraind op afbeeldingsherkenning) en OCR (= getraind op taalherkenning). De laatste ministral heeft dat bijvoorbeel, maar zelf zou ik eerder Gemma 4 en Qwen 3.6 ook proberen want dat zijn beide wel de meest recente modellen en (volgens mij?) nu het best wat op de 'opensource' markt te vinden is.

[CT]

Chadi schreef op maandag 15 juni 2026 @ 20:42:
[...]

Dankjewel voor het meedenken. Ik krijg juist nu van Gemini het voorstel om de originele pdf in te laden in plaats van foto's omdat tekst uit de originele makkelijker te extraheren is dan uit foto's. Er zitten geen grafieken in. Gemini 2.5 gebruikt ongeveer 15 seconden nu. Anthropic is iets sneller. Ik dacht zelf aan mistral om die op de server te zetten. Heb je daar ervaring mee?

Heb zelf een pilot gedaan met RAG & Vector search voor LLM's, waarbij PDF's de input waren. Maar je verzand wel snel in een houtje-touwtje oplossing, allemaal cli-tools om pdf text te extracten door gebrek aan (gratis) werkende libraries, maar als je de tekst hebt kan je het gewoon elke LLM insturen die je wilt, 5 pagina's heb je niet super veel context nodig maar een model dat goed van begrip is en evt. talen snapt als de input NL is ipv ENG. Momenteel is Gemma 4 26B-A4B of Qwen 3.6 35B-A3B voor jou usecase het 'snelst' om relatief nauwkeurige samenvattingen te krijgen.

Maar dit is altijd afhankelijk van budget, snelheid en nauwkeurigheid: budget voor de VRAM, meer VRAM is duurder zijn grotere modellen, nog meer VRAM nog duurder, heel model inladen is sneller meer context.
Minder budget is minder VRAM is kleinere modellen voor meer snelheid is minder nauwkeurig.

[DeNachtwacht]

CT schreef op maandag 15 juni 2026 @ 21:33:
[...]

Heb zelf een pilot gedaan met RAG & Vector search voor LLM's, waarbij PDF's de input waren.

Ik ben wel benieuwd hoe je dit hebt aangevlogen, kun je je setup/workflow eens omschrijven?

[CT]

DeNachtwacht schreef op maandag 15 juni 2026 @ 23:12:
[...]

Ik ben wel benieuwd hoe je dit hebt aangevlogen, kun je je setup/workflow eens omschrijven?

Vereiste was soort AI assistent die dus bronnen (documenten) kon raadplegen bij beantwoorden van vragen. En de documenten moesten bijna 'realtime' ge-processed worden.
Wat je dan doet is RAG gebruiken, je upload een pdf, haalt de tekst eruit, hakt dit in stukken (vaak 1000 karakters per blok) gebruikt een vector (ai) model om een search vector te maken per blok, zet deze vectors in een een vectordb.
Als de ai-assistent (standaard llm wrapper) een vraag krijgt vul je de context tijdens het antwoorden van de vraag door de vraag ook door een vector-ai model te halen, deze vector als query op de db, de results die je krijgt moet je dan met een 'reranker' (ook ai model) sorteren, dan pak je X aantal resultaten en vult de context er mee en dan pas laat je de llm het antwoord geven.
Had laatst openwebUI is geprobeert, daar zit een tab bij de configuratie waar je document-search instelt, en dat leek akelig precies op wat ik had gemaakt, text-splitter (1000), embedding (vector) model, reranker, zelfde soort document upload modal.. je ziet het ook met de codign agents, die beginnen ook allemaal akelig veel op elkaar te lijken

[Chadi]

CT schreef op maandag 15 juni 2026 @ 21:33:
[...]

Heb zelf een pilot gedaan met RAG & Vector search voor LLM's, waarbij PDF's de input waren. Maar je verzand wel snel in een houtje-touwtje oplossing, allemaal cli-tools om pdf text te extracten door gebrek aan (gratis) werkende libraries, maar als je de tekst hebt kan je het gewoon elke LLM insturen die je wilt, 5 pagina's heb je niet super veel context nodig maar een model dat goed van begrip is en evt. talen snapt als de input NL is ipv ENG. Momenteel is Gemma 4 26B-A4B of Qwen 3.6 35B-A3B voor jou usecase het 'snelst' om relatief nauwkeurige samenvattingen te krijgen.

Maar dit is altijd afhankelijk van budget, snelheid en nauwkeurigheid: budget voor de VRAM, meer VRAM is duurder zijn grotere modellen, nog meer VRAM nog duurder, heel model inladen is sneller meer context.
Minder budget is minder VRAM is kleinere modellen voor meer snelheid is minder nauwkeurig.

Dat is best zwaar om te draaien op een eenvoudige 3090 /24Gb. Of is de ervaring dat het wel meevalt

[Deepflame]

Chadi schreef op dinsdag 16 juni 2026 @ 22:58:
[...]

Dat is best zwaar om te draaien op een eenvoudige 3090 /24Gb. Of is de ervaring dat het wel meevalt

Ik draai zelf Qwen 3.6 27B op mijn 3090 met 24gb, en met ~450 tok/s prompt processing en ~60 tok/s token generation vind ik dat best wel vlot werken om eerlijk te zijn.

Geheel gebruikt ongeveer 22 GB VRAM, dus heb zelfs nog een beetje over.

[CT]

Chadi schreef op dinsdag 16 juni 2026 @ 22:58:
[...]

Dat is best zwaar om te draaien op een eenvoudige 3090 /24Gb. Of is de ervaring dat het wel meevalt

dit draaide op een hosted server, daar zitten server componenten in en kom je bij van die SFF versies uit geschikt voor data centre's, dit was een ADA 4000 SFF, dat is 20GB vram, en ging met de juiste modellen prima, je kan ook cloud achtige oplossingen afnemen en betalen per VRAM zegmaar, voor bedrijven is iig genoeg mogelijk kwa 'private' oplossing als het om infra gaat

[Bontje Blauw]

Ik overweeg een 2e GPU voor extra VRAM en LLM werk.
Momenteel heb ik: RTX 5070 OC 12GB, 32GB 8000MT/s, Core Ultra 7 265K.
De 5070 zit in een PCIe 5.0 x 16 slot, verder is alleen een PCIe 4.0 16 x4 slot beschikbaar voor een 2e GPU en dan maximaal 1/1.5 slots hoogte of extern alternatief via ThunderBolt 4

Is een 2e GPU zinvol gezien de wat mindere PCIe bandbreedte?
Zo ja, is Intel of AMD een optie naast Nvidia?
Ik gebruik LLM's voornamelijk voor het genereren van code.

[ocf81]

Bontje Blauw schreef op maandag 22 juni 2026 @ 14:11:
Ik overweeg een 2e GPU voor extra VRAM en LLM werk.
Momenteel heb ik: RTX 5070 OC 12GB, 32GB 8000MT/s, Core Ultra 7 265K.
De 5070 zit in een PCIe 5.0 x 16 slot, verder is alleen een PCIe 4.0 16 x4 slot beschikbaar voor een 2e GPU en dan maximaal 1/1.5 slots hoogte of extern alternatief via ThunderBolt 4

Is een 2e GPU zinvol gezien de wat mindere PCIe bandbreedte?
Zo ja, is Intel of AMD een optie naast Nvidia?
Ik gebruik LLM's voornamelijk voor het genereren van code.

Technisch kan het, maar PCI-e 4.0 x4 is wel mager. Vermoedelijk loopt dat ook via de chipset? Dat is dan echt een merkbare flessenhals en niet aan te raden. Is er geen manier om een x8/x8 verdeling te realiseren? Het is niet aan te raden om twee verschillende architecturen naast elkaar te draaien. Dat betekent dus GPU's van dezelfde chipfabrikant met dezelfde generatie.

Wellicht is het opwaarderen naar een GPU met 32GB VRAM anders een optie, zoals bijvoorbeeld met een AI 9700.

[ Voor 7% gewijzigd door ocf81 op 22-06-2026 14:27 ]

[DeNachtwacht]

@Bontje Blauw als het om code gaat dan heeft het op zich wel zin. Inderdaad is er wat prestatieverlies door de langzamere poort, maar het voordeel ervan is dat je een groter model in je GPU kan laden zonder offloaden. De prestatiewinst die je daardoor krijgt levert al flink wat op, maar de beginvraag is natuurlijk: welk model gebruik je nu en doet die ook offloading naar het ram? Daar staat of valt het namelijk wel mee.

[ocf81]

DeNachtwacht schreef op maandag 22 juni 2026 @ 14:46:
@Bontje Blauw als het om code gaat dan heeft het op zich wel zin. Inderdaad is er wat prestatieverlies door de langzamere poort, maar het voordeel ervan is dat je een groter model in je GPU kan laden zonder offloaden. De prestatiewinst die je daardoor krijgt levert al flink wat op, maar de beginvraag is natuurlijk: welk model gebruik je nu en doet die ook offloading naar het ram? Daar staat of valt het namelijk wel mee.

Die vraag staat natuurlijk wel centraal, maar tegelijkertijd is het ook ontdekken wat voor jou werkt .Als ik kijk naar de opmerkingen die op het forum van Level1Techs langs zie komen, dan zie ik dat een link via de chipset wel vragen om problemen is.

[DeNachtwacht]

@ocf81 ik snap niet wat je bedoelt met "een link via de chipset" bedoelt, misschien handig even te linken naar dat topic op het forum daar?

Ik ben me er zelf ook in aan het verdiepen en voor zover ik op fora er dingen over tegen kom is het voor taalmodellen (dus LLM output) wel zinvol, ook een 12GB model bijvoorbeeld heeft flink wat ruimte nodig voor context dus dan heb je met een 16GB GPU niet voldoende.

Heb je een 2e gpu, dan kan je taalmodel in de ene GPU, en de context (pakweg 8GB gok ik in dit voorbeeld voor 256K, wat wel lekker is bij programmeren) in de andere. Je krijgt wel even vertraging doordat een PCIe 4.0 x4 poort maar 8GB/s heeft, maar zodra je model eenmaal in de GPU geladen is heb je daar geen last meer van en ga je profiteren van de snelheidswinst: DDR5-600 is +/- 100GB/s, maar een 5060 Ti 450GB/s. Dus na een eerste vertraging ga je daarna wel 4,5 keer zo snel met het echte werk beginnen volgens mij. Perplexity zegt me iig dat het onderaan de streep snelheidswinst oplevert, maar ik hoor het ook graag mocht dat toch genuanceerder zijn

[Bontje Blauw]

Ik speel met LM studio / Ollama en VScode op een Fedora 44 machine.
Code is voornamelijk ESP32, scripts, web development.
Vooral ESP32 projecten bestaan uit veel bestanden met veel regels en ik krijg lokale LLM modellen niet lekker aan de praat met een grotere codebases en aanpassen van code over meerdere bestanden.
Ik gebruik nu Codex via een ChatGPT plus abbonement / Copilot via Github en lokaal Qwen2.5-coder 7b/14b en qwen3-coder-30b, gemma-4 om tokens te sparen. De qwen coder llm's zijn Q4_K_M.

Mijn moederbord is beperkt door PCIe 4.0 via de chipset en mijn Lian Li A3 beperkt de hoogte van een 2e GPU in het onderste slot.


Ik zoek een beetje naar kosten / baten.
De GPU vervangen kan, maar dan is naar 16GB upgraden de meest economische optie. En die 4GB VRAM schiet niet echt op. Voor Nvidia zijn dat duurdere modellen zoals de 5070ti of een gebruikte RTX 40xx series.

LLM's offloading naar een server over IP is niet mogelijk dacht ik.
Ik heb nog een thuisserver draaien op 32GB 4800MT/s + i5-13400. Maar dan gaat 24/7 idle verbuik flink omhoog verwacht ik.

Aanvulling:
De RTX 5070 doet 3 watt in idle volgens nvidia-smi.
Wellicht een docker container starten voor LLM's en die afsluiten bij geen gebruik maken van LLM's zodat GPU in low idle power gaat.

Workflow die ik nu gebruik is:
- ChatGPT 5.5 als architect en sparring partner (o.a. "grill me" promt)
- Diverse markdownfiles aanmaken voor AGENTS, planning, sprint files, coding rules, API contracts etc.
- ChatGPT 5.5 maakt promts voor Codex
- Codex gaat aan de slag binnen de codebase.
- Validatie na uitvoering.

[ Voor 19% gewijzigd door Bontje Blauw op 22-06-2026 15:30 ]

[DeNachtwacht]

@Bontje Blauw het qwen3-coder:30b-a3b-q4_K_M model is al ongeveer 20gb groot. Dat betekent dat het model deels al op je ramgeheugen draait via offloading en dus veel trager gaat omdat het niet geheel in de gpu zit. In dat geval zal een tweede 16GB gpu erbij zeker baat hebben, want dan kan het gehele model inclusief +/- 256K in de 28gb vram draaien die je hebt.

Om een beetje een gevoel te krijgen hoe snel je reacties dan worden kun je als test eens Qwen3 8B Q5_K_M draaien, die is maar 8gb groot. Als je dan 32K context selecteert en wat proefjes doet heb je een goed gevoel van de snelheidswinst die je krijgt met de antwoorden van de LLM.

[ Voor 4% gewijzigd door DeNachtwacht op 22-06-2026 16:40 ]

[ocf81]

DeNachtwacht schreef op maandag 22 juni 2026 @ 15:18:
@ocf81 ik snap niet wat je bedoelt met "een link via de chipset" bedoelt, misschien handig even te linken naar dat topic op het forum daar?

Ik ben me er zelf ook in aan het verdiepen en voor zover ik op fora er dingen over tegen kom is het voor taalmodellen (dus LLM output) wel zinvol, ook een 12GB model bijvoorbeeld heeft flink wat ruimte nodig voor context dus dan heb je met een 16GB GPU niet voldoende.

Heb je een 2e gpu, dan kan je taalmodel in de ene GPU, en de context (pakweg 8GB gok ik in dit voorbeeld voor 256K, wat wel lekker is bij programmeren) in de andere. Je krijgt wel even vertraging doordat een PCIe 4.0 x4 poort maar 8GB/s heeft, maar zodra je model eenmaal in de GPU geladen is heb je daar geen last meer van en ga je profiteren van de snelheidswinst: DDR5-600 is +/- 100GB/s, maar een 5060 Ti 450GB/s. Dus na een eerste vertraging ga je daarna wel 4,5 keer zo snel met het echte werk beginnen volgens mij. Perplexity zegt me iig dat het onderaan de streep snelheidswinst oplevert, maar ik hoor het ook graag mocht dat toch genuanceerder zijn

Het voornaamste probleem is de vertraging die de chipset introduceert vis-a-vis de vertraging die een GPU ervaart als alles via de CPU loopt. Deze is niet mals en zorgt voor een veel tragere effectieve communicatie, zelfs al is de bandbreedte nominaal afdoende. Vooral dit punt is waarom je de chipset wil vermijden, omdat er, voor zover ik dat begrijp, geen goede parallellisatie mogelijk is om dat op te vangen, waardoor de effectieve doorvoersnelheid enorm daalt. (hierbij baseer ik mij ook deels op de lessen netwerktheorie die ik ooit bij mijn B.ICT heb mogen aanhoren, maar om dat volledig uit de doeken te doen is wel veel werk om uit te tikken, dus laat ik dat even achterwege)
Ik denk dat er in deze draad wel wat interessante dingen worden gezegd, hoewel er elders op het forum ook wel interessante dingen worden gezegd door mensen van wie ik denk dat ze het uit ervaring kunnen vertellen. Ik heb alleen geen zeeën van tijd om al die draadjes die ik daar lees nog eens na te pluizen, dus geef ik je alleen deze even, omdat die het meest recent nog op mijn netvlies stond.

[ Voor 9% gewijzigd door ocf81 op 22-06-2026 16:55 ]

[ocf81]

Bontje Blauw schreef op maandag 22 juni 2026 @ 15:19:
LLM's offloading naar een server over IP is niet mogelijk dacht ik.
Ik heb nog een thuisserver draaien op 32GB 4800MT/s + i5-13400. Maar dan gaat 24/7 idle verbuik flink omhoog verwacht ik.

Dat kan zeker wel! Ollama, llama.cpp en vLLM hebben allemaal een mogelijkheid om een OpenAI API interface te draaien en die op het netwerk aan te bieden. Dat is ook hoe ik mijn lokale AI-diensten gebruik. Die hangen allemaal in het rek.

[ Voor 8% gewijzigd door ocf81 op 22-06-2026 16:58 ]

[DeNachtwacht]

@ocf81 die vertraging klopt, maar zodra het taalmodel en de context in het vram geladen zijn heb je daar geen last meer van. De output is allemaal zo klein dat dat niet meer uitmaakt voor zover ik het lees. Het inladen van het model en de context gaat inderdaad natuurlijk wel trager, maar bij een middagje coden haal je dus even koffie tijdens dat inladen en vanaf dat moment heb je er de hele middag snelheidsplezier van.

[ocf81]

DeNachtwacht schreef op maandag 22 juni 2026 @ 16:59:
@ocf81 die vertraging klopt, maar zodra het taalmodel en de context in het vram geladen zijn heb je daar geen last meer van. De output is allemaal zo klein dat dat niet meer uitmaakt voor zover ik het lees. Het inladen van het model en de context gaat inderdaad natuurlijk wel trager, maar bij een middagje coden haal je dus even koffie tijdens dat inladen en vanaf dat moment heb je er de hele middag snelheidsplezier van.

Ik weet niet precies meer waar ik het heb gelezen, maar als ik het mij goed herinner is het de KV-cache activaties die dan problemen gaat geven. Het model moet dan tussen de kaarten communiceren, en dan is vertraging in de communicatie juist het probleem. Maar als ik het niet goed in de gaten heb, dan laat ik mij graag bijpraten

[Bontje Blauw]

ocf81 schreef op maandag 22 juni 2026 @ 16:57:
[...]

Dat kan zeker wel! Ollama, llama.cpp en vLLM hebben allemaal een mogelijkheid om een OpenAI API interface te draaien en die op het netwerk aan te bieden. Dat is ook hoe ik mijn lokale AI-diensten gebruik. Die hangen allemaal in het rek.

Maar niet met VRAM PC1 + VRAM PC 2 = totale VRAM dacht ik?

[ocf81]

Bontje Blauw schreef op maandag 22 juni 2026 @ 17:07:
[...]

Maar niet met VRAM PC1 + VRAM PC 2 = totale VRAM dacht ik?

Nee, dat is inderdaad niet mogelijk als zodanig met de hardware die jij hebt. Dan moet je naar RDMA opstellingen gaan kijken en zit je aan >40GbE netwerkkaarten en serverhardware. Dan zit je in een andere prijsklasse te kijken. (technisch gezien kan het dus wel)

[ Voor 7% gewijzigd door ocf81 op 22-06-2026 17:13 ]

[Bontje Blauw]

Deze sites vind ik wel informatief:
localaimaster blog over multi GPU
Of
oLLM op github, oLLM github
Offloading bovenop Huggingface Transformers en Pytorch

[Bontje Blauw]

DeNachtwacht schreef op maandag 22 juni 2026 @ 16:39:
@Bontje Blauw het qwen3-coder:30b-a3b-q4_K_M model is al ongeveer 20gb groot. Dat betekent dat het model deels al op je ramgeheugen draait via offloading en dus veel trager gaat omdat het niet geheel in de gpu zit. In dat geval zal een tweede 16GB gpu erbij zeker baat hebben, want dan kan het gehele model inclusief +/- 256K in de 28gb vram draaien die je hebt.

Om een beetje een gevoel te krijgen hoe snel je reacties dan worden kun je als test eens Qwen3 8B Q5_K_M draaien, die is maar 8gb groot. Als je dan 32K context selecteert en wat proefjes doet heb je een goed gevoel van de snelheidswinst die je krijgt met de antwoorden van de LLM.

Als ik qwen3-coder-30b Q4_K_M (18,6GB) laad in LM studio zie ik VRAM = 8333 MiB en systeem RAM stijgt maar met 0.6 GiB (totaal systeem is 9 GiB in gebruik van 32 GiB)

Met deze promt:
generate a complete website with 3 files; html + css + javascript. Add a Title header on top. Second a bar with 6 navigation buttons. Make theme electronics/space/sci-fi. Give the first page a card with local times New York, Amsterdam, Albanie, Sidney.

Begint met 40tk/s en eindigd met 28tk/s.
VRAM blijft ca. 8.4 GiB, CPU 25% and GPU 10 a 15% belast. Systeem RAM blijft stabiel.

Logs:
4.43.771.670 I slot print_timing: id 3 | task 4273 | prompt eval time = 421.66 ms / 70 tokens ( 6.02 ms per token, 166.01 tokens per second)
4.43.771.672 I slot print_timing: id 3 | task 4273 | eval time = 619.23 ms / 13 tokens ( 47.63 ms per token, 20.99 tokens per second)
4.43.771.673 I slot print_timing: id 3 | task 4273 | total time = 1040.88 ms / 83 tokens
4.43.771.673 I slot print_timing: id 3 | task 4273 | graphs reused = 4266
4.43.771.770 I slot release: id 3 | task 4273 | stop processing: n_tokens = 4420, truncated = 0
4.43.771.777 I srv update_slots: all slots are idle

Update:
Als ik over de context window ga is token generatie 15 a 20 tk/s
Maar ik zie geen toename in systeem- of vram gebruik

[ Voor 12% gewijzigd door Bontje Blauw op 22-06-2026 17:53 ]

[DeNachtwacht]

ocf81 schreef op maandag 22 juni 2026 @ 17:06:
[...]

Ik weet niet precies meer waar ik het heb gelezen, maar als ik het mij goed herinner is het de KV-cache activaties die dan problemen gaat geven. Het model moet dan tussen de kaarten communiceren, en dan is vertraging in de communicatie juist het probleem. Maar als ik het niet goed in de gaten heb, dan laat ik mij graag bijpraten

Ja dat klopt, je krijgt inderdaad wel vertraging ten opzichte van een setup met 1 gpu die 2x zo groot is, of de ideale situatie dat je met nvlink (ipv pcie) de GPU’s aan elkaar knoopt. Maar het ding is dat normaal ramgeheugen zoveel trager is (factor 15-20 volgens mij), dat je onderaan de streep met zo’n dual gpu setup alsnog wel sneller bent als je daardoor niet hoeft te offloaden.

[DeNachtwacht]

@Bontje Blauw hm, ik vind dit heel vreemd. Ik zie online dat dat model in Q4 bijna 20gb is. En jij bevestigt dat hier nu ook toch, of haal je die gb uit mijn post? Aan de snelheid te zien lijkt het wel alsof het in zijn geheel of vrijwel in vram draait, maar dat kan helemaal niet als dat model 20gb is en jouw gpu 12GB vram heeft. Ergens hebben we de nummers dus niet goed 😅

[ocf81]

DeNachtwacht schreef op maandag 22 juni 2026 @ 17:55:
@Bontje Blauw hm, ik vind dit heel vreemd. Ik zie online dat dat model in Q4 bijna 20gb is. En jij bevestigt dat hier nu ook toch, of haal je die gb uit mijn post? Aan de snelheid te zien lijkt het wel alsof het in zijn geheel of vrijwel in vram draait, maar dat kan helemaal niet als dat model 20gb is en jouw gpu 12GB vram heeft. Ergens hebben we de nummers dus niet goed 😅

Ik zie in het tweede scherm dat maar 7 lagen naar de GPU worden overgeheveld? Het lijkt me dat een deel op de CPU draait? (maar waar is dan de systeem RAM belasting ) Het is ook een MoE model, dus dat kan ook een factor zijn.

[ Voor 7% gewijzigd door ocf81 op 22-06-2026 17:59 ]

[Bontje Blauw]

ocf81 schreef op maandag 22 juni 2026 @ 17:57:
[...]

Ik zie in het tweede scherm dat maar 7 lagen naar de GPU worden overgeheveld? Het lijkt me dat een deel op de CPU draait? (maar waar is dan de systeem RAM belasting ) Het is ook een MoE model, dus dat kan ook een factor zijn.

Volgens mij doet LM studio een automatische setting voor GPU offload gebaseerd op de hardware die hij detecteerd.
Voor qwen3-coder-30b is dat 21 layers.
Voor qwen3-vl-8b maakt zet hij deze op 31 en voor gemma 4-12b op 48.

[DeNachtwacht]

@ocf81 ik mis dus ook dat ramgeheugen idd.. en het is inderdaad een MoE model, maar dat bespaart geen geheugen. Die bijna 20gb die het model groot is, moeten simpel gezegd gewoon ergens zijn.

[Bontje Blauw]

DeNachtwacht schreef op maandag 22 juni 2026 @ 18:06:
@ocf81 ik mis dus ook dat ramgeheugen idd.. en het is inderdaad een MoE model, maar dat bespaart geen geheugen. Die bijna 20gb die het model groot is, moeten simpel gezegd gewoon ergens zijn.

Op de SSD wellicht?

Een test met model gemma4-12b and volledige 48 layers op de GPU en 9GiB in VRAM gaat GPU naar 100% en haalt mijn PC 70+ tokens/s