Ervaringen met zelf gehoste AI assistenten

[DeNachtwacht]

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.

Mja, deze bron is ook uit februari 2026 he: https://www.navyaai.com/reports/ai-cost-report-token-prices-vs-ai-bill

Maargoed het is sowieso op dit gebied lastig zoeken wat de feiten zijn; honderden nieuwe websites/bedrijven die allemaal dingen zeggen/claimen op dit gebied en betrouwbaarheid achterhalen is... een uitdaging.

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.

[Deepflame]

Ik werk zelf nu al een paar maanden met OpenClaw, eerst met Claude Sonnet/Opus, toen GPT-5.4 toen Anthropic een drama momentje had, en nu zit ik al weer een tijdje primair met GPT-5.5 te werken. Werkt fijn, heb er veel plezier mee en het is erg leerzaam allemaal.

Sinds kort klus ik ook met lokale modellen, heb een Qwen 3.6 27b Q4_K_M draaien met 256k context window op mijn RTX 3090 (24gb) door TurboQuant toe te passen. Ik gebruik daar een fork van llama.cpp voor (een soort van Ollama, maar dan meer performance) van TheTom: https://github.com/TheTom/llama-cpp-turboquant en een assymetrische KV-quant van Turbo4/Turbo3 toe te passen.

Werkt prima, krijg ongeveer 50 tok/s token generation er uit waardoor het best responsive aanvoelt. Maar je moet het niet gebruiken als primaire agentic driver, daar mist het de capaciteit voor. Heb op kantoor ook een Qwen 3.6 27b aan de praat gekregen op een oud server bordje met 4x een GTX 1070 er in.

De Chinese open modellen zijn best wel leuk, DeepSeek V4 Flash is ook al verrassend goed, ik zou dat wel als daily driver willen gebruiken, in theorie zou ik dat in 80gb kwijt moeten kunnen, maar ik heb daar de GPUs niet voor.

Maar goed, die komen natuurlijk niet in de buurt van de brute kracht van GPT-5.5 en Claude Opus 4.7 en zo. Maar als je een beetje in de loop blijft en de vinger aan de pols houd dan kom je zelfs met Qwen al een heel eind! Het is capabeler dan je denkt.

[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

[DeNachtwacht]

@Bontje Blauw het gekke daarvan is dat de tokensnelheid dan niet zo rap zou zijn denk ik. Welke vllm versie draai je en wat voor ramsnelheid?

[Theswitch]

Van 8 tot 16 gb GPU is dit model op.dit moment wel goed. Snel en veel context mogelijk en goed genoeg voor normaal vibecode. gemma-4-12B-agentic-fable5-composer2.5-v2-3.5x-tau2-GGUF

Voor het goed draaiend krijgen wel even de comments lezen mbt vllm. Of kies het ollama pad die wat minder efficient is.

code:

ollama run xentriom/gemma-4-12B-agentic-fable5-composer2.5-v2:Q8_0

[ Voor 9% gewijzigd door Theswitch op 22-06-2026 20:12 ]

[Felicia]

DeNachtwacht schreef op maandag 22 juni 2026 @ 19:53:
@Bontje Blauw het gekke daarvan is dat de tokensnelheid dan niet zo rap zou zijn denk ik. Welke vllm versie draai je en wat voor ramsnelheid?

Tenzij juist de actieve parameters in VRAM draaien en de rest op schijf. Dat zou ik wel heel erg toevallig vinden.

Wat betreft de performance, ik weet dat bij MOE modellen het helpt om de experts op CPU te draaien en de KV-cache in Vram. Zo kan ik met GPT-OSS 120B met een Intel Arc B60 Pro (24GB VRAM) en 64GB RAM nog steeds 20tok/sec halen bij lage context dingen. Leuk om te proberen maar niet meer dan dat

[Bontje Blauw]

LM Studio0.4.16 (stable) + CUDA 12 llama.cpp v2.22.0
Ik heb wel snel RAM, 2 x 16GB 8000mt/s en Core Ultra 7 265K met 20 cores.
Ik merk met settings vol op CPU zet en geen layers op de GPU dat ik 22~25 tokens/sec
10 CPU cores lijkt de max. setting in LM Studio. Ik kom ook nog niet boven de 55% CPU uit tijdens code genereren.

Deze test is met Qwen3-coder-30b

[Felicia]

Bontje Blauw schreef op maandag 22 juni 2026 @ 20:18:
LM Studio0.4.16 (stable) + CUDA 12 llama.cpp v2.22.0
Ik heb wel snel RAM, 2 x 16GB 8000mt/s en Core Ultra 7 265K met 20 cores.
Ik merk met settings vol op CPU zet en geen layers op de GPU dat ik 22~25 tokens/sec
10 CPU cores lijkt de max. setting in LM Studio. Ik kom ook nog niet boven de 55% CPU uit tijdens code genereren.

Deze test is met Qwen3-coder-30b

[Afbeelding]

Bij de LM studio screenshot staat wel dat je KV-cache naar GPU memory gaat, daar zal een groot deel van je performance in zitten.

[Bontje Blauw]

Theswitch schreef op maandag 22 juni 2026 @ 20:11:
Van 8 tot 16 gb GPU is dit model op.dit moment wel goed. Snel en veel context mogelijk en goed genoeg voor normaal vibecode. gemma-4-12B-agentic-fable5-composer2.5-v2-3.5x-tau2-GGUF

Voor het goed draaiend krijgen wel even de comments lezen mbt vllm. Of kies het ollama pad die wat minder efficient is.

code:

ollama run xentriom/gemma-4-12B-agentic-fable5-composer2.5-v2:Q8_0

Thanks die ga ik eens uitproberen. Dan wel de Q6_K versie van 9.79 GB.

[Bontje Blauw]

Felicia schreef op maandag 22 juni 2026 @ 20:26:
[...]

Bij de LM studio screenshot staat wel dat je KV-cache naar GPU memory gaat, daar zal een groot deel van je performance in zitten.

Met Offload KV Cache to GPU Memory off zie ik geen verschil in performance. Maar dat is wellicht en LM Studio dingetje, want met reload lijkt LM Studio dit toch weer aan te zetten.
VRAM is namelijk ook 477 MB tijdens inladen model en genereren code (nog weinig context). Haal dan 20+ tokens/sec.
Als ik het model unload daalt VRAM naar 45 MB.

[CT]

DeNachtwacht schreef op maandag 22 juni 2026 @ 17:41:
[...]

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.

Als het om 2 relatief recente RTX kaarten gaat (die geen xx90 versie zijn), zoals ik heb, dan kan je deze driver patch installeren dan krijg je P2P over PCIe, kunnen de kaarten zonder omleiding direct via PCIe elkaar in de VRAM bereiken.
Met mijn 2x 3080 kaarten heb ik nu spikes (met qwen 3.6 27b q8) naar 100tk/s, waar het via de CPU/RAM omweg niet hoger kwam met spikes naar 70-80tk/s.

[switchboy]

sudo ./llama-cpp-turboquant/build/bin/llama-server   -m /Downloads/Qwen_Qwen3.6-35B-A3B-4_K_M.gguf   -ngl 99   --n-cpu-moe 35   --no-mmap   --mlock   --cache-type-k turbo4   --cache-type-v turbo3   -c 262144   --port 8888   --host 0.0.0.0

Haal tussen de 23 en 35 T/s afhankelijk van het type taak. Het prompten en denk ik roteren van de expert modellen neemt soms wel wat tijd in beslag.

Best onder de indruk hij wist een logica bug uit mijn RTS state machine voor de units te halen waardoor ze willekeurig soms stopte met een taak. Gemini lukt dat natuurlijk ook wel maar de vorige generatie gemma beet er zijn tanden op stuk.

Iemand nog tips om er nog meer uit mijn hardware te knijpen?

[Felicia]

switchboy schreef op maandag 22 juni 2026 @ 21:34:
sudo ./llama-cpp-turboquant/build/bin/llama-server   -m /Downloads/Qwen_Qwen3.6-35B-A3B-4_K_M.gguf   -ngl 99   --n-cpu-moe 35   --no-mmap   --mlock   --cache-type-k turbo4   --cache-type-v turbo3   -c 262144   --port 8888   --host 0.0.0.0

Haal tussen de 23 en 35 T/s afhankelijk van het type taak. Het prompten en denk ik roteren van de expert modellen neemt soms wel wat tijd in beslag.

Best onder de indruk hij wist een logica bug uit mijn RTS state machine voor de units te halen waardoor ze willekeurig soms stopte met een taak. Gemini lukt dat natuurlijk ook wel maar de vorige generatie gemma beet er zijn tanden op stuk.

Iemand nog tips om er nog meer uit mijn hardware te knijpen?

Turboquant is vrij rekenintensief, er is al een alternatief in de vorm van Rotorquant maar die is (iirc) nog niet naar main gemerged: YouTube: RotorQuant vs TurboQuant: 31x Speed Claim - Reality Check (Local AI)

[edit]
Ter correctie, Turboquant is ook nog niet gemerged naar main waar ik dacht van wel.

[ Voor 4% gewijzigd door Felicia op 23-06-2026 19:31 ]

[DeNachtwacht]

Bontje Blauw schreef op maandag 22 juni 2026 @ 20:27:
[...]

Thanks die ga ik eens uitproberen. Dan wel de Q6_K versie van 9.79 GB.

Ik ben eruit. Het qwen3-coder-30b Q4_K_M model past in een rtx 3090 of 4090 en haalt daar tussen de 80-110 tokens. Jouw snelheid is van 28 tokens / seconde is dus simpelweg trager dan wanneer je alles in het vram hebt. Ziehier dus ook je antwoord op de vraag of een tweede rtx 5060 ti GPU alles sneller gaat maken; het antwoord is dus ja. Met een 5060 ti kom je rond de 60 tot 90 tokens per seconde uit volgens AI.

Dat raakt ook aan iets anders bij je plannen voor het Gemma model; hou het bij Q4. Zelfs die is al aan de krappe kant als je met context aan de slag wil gaan. Zoals hier eerder gepost heb ik Qwen 3.6 27B (19GB) draaien met 192K context in ongeveer 28-29GB vram. Dan is hij echt poepsnel. Ga ik naar 256K context dan wordt hij ineens echt fors trager doordat alles samen dan niet meer in 32gb vram past. Even in perspectief; in jouw bericht van 17:16 uur zie ik in de eerste screenshot dat je 8192 oftewel 8K context hebt. Dat is echt superweinig, zéker voor programmeren. Dat betekent dat er maar zo’n 2000-3000 woorden worden onthouden en alles wat langer geleden is, vergeet hij. Het voordeel is dan weer dat dit relatief maar weinig vram nodig heeft, maar zoals hierboven uitgelegd is het dus alsnog toch traag door offloaden met jouw setup, simpelweg omdat 19gb sowieso niet in je vram past.

Als je lokale LLM’s als chatbot een beetje bruikbaar wil gebruiken wil je minimaal 32K context gebruiken zodat de bot niet direct na 5-6 vragen al vergeten is wat je daarvoor vroeg en wat hij antwoordde. Voor programmeerwerk wil je om een logische reden nóg veel meer en wordt op zijn minst 128K altijd aangeraden.

In dit geval is jouw voordeel dat je dat bij Qwen direct dus kan die , trager dan 28 tokens wordt het denk ik niet want er wordt toch al geoffload. Het voordeel is dan dat je merkbaar betere code krijgt.

Maar ik zou ook echt even zoals eerder gezegd met een heel klein model eens testen, puur om de snelheid van die 60-90 tokens per seconde te ervaren. Als je het dat waard is, is die 5060 ti een erg goed idee want je kan ten eerste grotere modellen draaien en ten tweede dus ook fors meer context.

[combimagnetronn]

Draai op dit moment LM Studio + open WebUI met een Llama 3.2 4B model op mijn Mac Mini 16GB M4 en ben toch lichtelijk geschokt van hoeveel RAM of VRAM je in moet zetten om degelijke resultaten te krijgen.

[Deepflame]

DeNachtwacht schreef op maandag 22 juni 2026 @ 23:51:
[...]

Zoals hier eerder gepost heb ik Qwen 3.6 27B (19GB) draaien met 192K context in ongeveer 28-29GB vram. Dan is hij echt poepsnel. Ga ik naar 256K context dan wordt hij ineens echt fors trager doordat alles samen dan niet meer in 32gb vram past.

[...]

Dat is ook alleen maar omdat jij per sé bij Ollama wilt blijven, als je een llama.cpp met turboquant pakt dan past Qwen 3.6 27B Q4 met 256k context én multimodal projector in 22GB.

@Bontje Blauw Je zou kunnen kijken of je moederbord bifurcation aanbied in de BIOS, dan kan je je x16 slot opsplitsen in twee x8 slots, dan heb je en de performance en de vram. Passive 2-slot bifurcation bordjes kosten geen drol op aliexpress. Maar ook op x4 draait het prima hoor, als je de kaart er in krijgt. Je moet er misschien een extender voor kopen als het geen open x4 slot is. Ook die kosten niets op aliexpress.

Ik heb zelf 4 1070s in x8x8x8x8 direct op het moederbord gezet, en later nog eens getest over 1 x16 poort met een x4x4x4x4 bifurcation bordje, en in beide gevallen kon ik Qwen 3.6 27B Q5 draaien. Kreeg er in beide situaties dezelfde prompt processing en token generation snelheden uit, 150 en 11 tokens/s respectievelijk. Niet slecht voor een stel afdankertjes die ik gratis meegekregen heb.

[Bontje Blauw]

@Deepflame

Ik heb een intel B860 chipset en die ondersteunt helaas geen bifurcation. Dat zou een upgrade naar een Z890 chipset betekenen. Dat betekend al 100 euro bijleggen.
Ik vermoed dat ik aangewezen ben op een 1 slots RTX A4000 met 16 GB VRAM a 600 euro in V&A.
Dan heb ik voor 1100 euro waarde in 2 GPU's zitten. En dan lijkt een upgrade naar een gebruikte RTX 3090 of een Intel Pro B70 ook in die buurt te liggen.
Ik hoopte voor 300 euro een gebruikte RTX30xx 12GB er bij te kunnen prikken, maar dat lijkt nog niet zo maar te lukken helaas.

[DeNachtwacht]

Deepflame schreef op dinsdag 23 juni 2026 @ 12:26:
[...]

Dat is ook alleen maar omdat jij per sé bij Ollama wilt blijven, als je een llama.cpp met turboquant pakt dan past Qwen 3.6 27B Q4 met 256k context én multimodal projector in 22GB.

Tuurlijk, maar dat heeft feitelijk niet zoveel te maken met de vraag die gesteld werd. Het punt dat ik maakte was dat zijn tokens sneller kunnen als hij voor een model kies dat geheel in het vram past. Je hebt natuurlijk ook gelijk dat een andere oplossing daarvoor is om een turboquant model te kiezen… ik ga daar later nog eens naar kijken ik heb nu een hele setup in elkaar waarbij ollama ook als server de LLM in het netwerk heeft staan, bevalt eigenlijk prima dus hoop simpelweg dat turboquant snel ook naar ollama komt. En mijn vraag daarbij is dan weer; zijn in llama.ccp alle modellen ook met turboquant beschikbaar?

[ocf81]

Wat vinden we er eigenlijk van dat Continue.dev wordt overgenomen door Cursor, wat dan op zichzelf weer eigendom is van xAI, onderdeel van spaceX?

Op zich was continue.dev al enorm aan het verslechteren, maar ik had nog geen vervanger gevonden. Zed ben ik nog aan het verkennen, maar het heeft gewoon niet de integratie met VSCode/VSCodium die ik graag zou zien. Heeft iemand nog suggesties?

[ Voor 17% gewijzigd door ocf81 op 23-06-2026 14:59 ]

[eheijnen]

ocf81 schreef op dinsdag 23 juni 2026 @ 14:57:
Wat vinden we er eigenlijk van dat Continue.dev wordt overgenomen door Cursor, wat dan op zichzelf weer eigendom is van xAI, onderdeel van spaceX?

Op zich was continue.dev al enorm aan het verslechteren, maar ik had nog geen vervanger gevonden. Zed ben ik nog aan het verkennen, maar het heeft gewoon niet de integratie met VSCode/VSCodium die ik graag zou zien. Heeft iemand nog suggesties?

Das toch een vrij normale gang van zaken.
De moloch koopt succesvolle startups en integreert ze in hun eigen productportfolio.

Microsoft, als een voorbeeld, heeft dat wel meer dan een keer gedaan.

Kan goed zijn dat ze Cursor ombouwen om alleen met Grok / inhouse AI te werken. Wie weet doen ze nog een gooi om Claude op te kopen.

[Deepflame]

@Bontje Blauw Ah, ja, dan houd het op. Er zijn ook actieve bifurcation kaarten, dan maakt je moederbord niet uit, maar die zijn gelijk weer een stuk duurder. :')

@DeNachtwacht Dat kan ik niet garanderen. Ik heb er weinig problemen mee gehad, maar weinig is niet nul. In het begin supporten ze Gemma 4 niet, dat duurde even voordat dat breed geïntegreerd was in de TurboQuant fork die ik zelf gebruik. Stock llama.cpp heeft namelijk nog geen support voor TurboQuant.

Maar het is niet als of ik elke dag llama.cpps zit te installeren en updaten, in fact, meestal doet mijn OpenClaw agent dat eigenlijk allemaal voor me. Ik zeg zelf bijna "zoek het maar uit" en dan een kwartier, twintig minuten later werkt het. Alleen in het begin en later tijdens het fine-tunen heb ik er wat aangezeten, maar gewoon onderhoud laat ik mijn AI voor me doen.

[Felicia]

Bontje Blauw schreef op dinsdag 23 juni 2026 @ 13:30:
@Deepflame

En dan lijkt een upgrade naar een gebruikte RTX 3090 of een Intel Pro B70 ook in die buurt te liggen.

Ik heb een Prob B60 en daar zijn driver technisch nog wel wat issues met llama.cpp en LM Studio in.c.m. specifieke settings. Als het het niet erg vind om te switchen van server hoeft dat geen issue te zijn natuurlijk.

Qua snelheid lijkt de B70 wel sneller dan de B60 maar niet veel sneller van een 5070. En het wachten op prompt processing en roken generation bij hogere context moet je ook tegen kunnen. Mijn B60 doet 85tok/sec bij lege context maar nog maar 15tok/sec bij zo'n 100k context.

[CT]

ocf81 schreef op dinsdag 23 juni 2026 @ 14:57:

[...]
Zed ben ik nog aan het verkennen, maar het heeft gewoon niet de integratie met VSCode/VSCodium die ik graag zou zien. Heeft iemand nog suggesties?

Ik gebruik Zed nu meer dan intellij en vscode, heb mn intellij abbo ook opgezegd, nu mn workflow bijna 100% met mn Lokale Qwen werkt. Zed werkt het "beste" al moeten ze nog wel paar puntje op de i zetten, maar de updates komen en verbeteren het per week.
En tussendoor (snelle check in een repo of iets los, gebruik ik https://pi.dev, overigens is daar ook een plugin voor in Zed, maar de Zed agent werkt natuurlijk het beste in zed zelf en pi.dev beste in zn eigen console client)

Beide vind ik de meest polished oplossingen en voelen het minste ge-vibe'ed, meeste tools en agents lijken namelijk erg gevib'ed en werken echt .. raar vaak UI/UX ziet er mooi uit maar voelen erg omslachtig of kloppen kleine details niet.

[CSB]

Wacht even, is turboquant dan nu in de officiele branch van llama.cpp gemerged? Ik heb idd Rotorquant voorbij zien komen maar volgens mij staat de request voor merge nog steeds open voor Turbo?

[Deepflame]

CSB schreef op dinsdag 23 juni 2026 @ 18:34:
Wacht even, is turboquant dan nu in de officiele branch van llama.cpp gemerged? Ik heb idd Rotorquant voorbij zien komen maar volgens mij staat de request voor merge nog steeds open voor Turbo?

Nee, maar https://github.com/TheTom/llama-cpp-turboquant is gewoon goed bruikbaar.

[Felicia]

CSB schreef op dinsdag 23 juni 2026 @ 18:34:
Wacht even, is turboquant dan nu in de officiele branch van llama.cpp gemerged? Ik heb idd Rotorquant voorbij zien komen maar volgens mij staat de request voor merge nog steeds open voor Turbo?

Yes, mijn fout. Ik verwarde Turboquant met MTP, zal de post even bijwerken.

[_Apache_]

Ik gebruik AI op verschillende manieren thuis.


Heb OpenWebUI draaien, waarbij ik verschillende modellen kan inzetten (gemma4, deepseek, qwen, phi). Basicly gewoon ChatGPT / Gemini voor thuis.


Heb Whisper draaien om voor media files ondertitels te maken. Dit werkt erg goed , zelfs zo goed, dat andere talen die voorbij komen in de film, gerust meevertaald worden.


Er worden diverse bewerkingen op gedaan om het gesproken woord eruit te halen. (achtergrond geluid eruit, beeld eruit, volume boost, en diverse 'voice isolation' technieken.

Dit word dan door FasterWhisper model getrokken, het v3-large model in dit geval. Dat is het grootste model dat in het VRAM past.

En de Engelse tekst word vervolgens door Google Translate heen gehaald. Met als resultaat een 1:1 vertaling van het Engels naar NL.

De performance vind ik best acceptabel, het gaat ongeveer 2-3x sneller dan de afspeelsnelheid van de video. Een Lord of The Rings film gaat er in 45-50min doorheen.

De vertaler zoals hierboven, vind ik te veel 1:1 vertalingen doen en matig zijn met uitdrukkingen. Dus ik ben Deepseek aan het inzetten om gezegdes en vertalingen beter te vertalen.

Ik heb een overzicht van namen van acteurs, zodat vertalingen niet mis gaan. Zo word 'Special Agent McGee' nog wel eens vertaald naar 'Special Agent Mickey'. Met het meegeven van deze context ben ik nog wat aan het spelen

Verder wil ik meer context meegeven (voorgaande zinnen en komende zinnen) zodat uitdrukkingen beter vertaald worden.

Dit allen draait op een (oude) i7 7700k, en een 1080TI. Geen spectaculaire hardware, maar een snellere GPU zou maar iets van 20-25% winst zijn. En die zijn **** duur.

OpenwebUI draait op mijn k3s cluster, 2 worker nodes van wat oudere hardware. Wel met sata ssd's en 32gb ram.

[ocf81]

CT schreef op dinsdag 23 juni 2026 @ 18:33:
[...]

Ik gebruik Zed nu meer dan intellij en vscode, heb mn intellij abbo ook opgezegd, nu mn workflow bijna 100% met mn Lokale Qwen werkt. Zed werkt het "beste" al moeten ze nog wel paar puntje op de i zetten, maar de updates komen en verbeteren het per week.
En tussendoor (snelle check in een repo of iets los, gebruik ik https://pi.dev, overigens is daar ook een plugin voor in Zed, maar de Zed agent werkt natuurlijk het beste in zed zelf en pi.dev beste in zn eigen console client)

Beide vind ik de meest polished oplossingen en voelen het minste ge-vibe'ed, meeste tools en agents lijken namelijk erg gevib'ed en werken echt .. raar vaak UI/UX ziet er mooi uit maar voelen erg omslachtig of kloppen kleine details niet.

Zed is op zich een fijne editor hoor, maar het ecosysteem is nog redelijk karig. Voor mij is PlatformIO toch wel een kritieke afhankelijkheid. PlatformIO vereenvoudigt de zaken omtrent het ontwikkelen en installeren van firmware door als het ware de npm van firmwareontwikkeling te zijn. Daardoor is het voor mij nog niet echt makkelijk om van VSCodium af kan stappen, want er is (nog) geen PlatformIO voor Zed.

[ocf81]

eheijnen schreef op dinsdag 23 juni 2026 @ 15:04:
[...]

Das toch een vrij normale gang van zaken.
De moloch koopt succesvolle startups en integreert ze in hun eigen productportfolio.

Microsoft, als een voorbeeld, heeft dat wel meer dan een keer gedaan.

Kan goed zijn dat ze Cursor ombouwen om alleen met Grok / inhouse AI te werken. Wie weet doen ze nog een gooi om Claude op te kopen.

De basisprincipes van kapitalisme veroordeel ik ook niet. Maar het effect is nu wel dat de plug in die ik nu gebruik niet zo 1-2-3 te vervangen lijkt door iets soortgelijks dat ook mooi lokaal draait. Misschien dat ik wat beter moet zoeken, dat kan ook

[ocf81]

@_Apache_ heel erg interessant. Denk je jouw opstelling ook kan worden aangepast om een lijst van hoofdstukken op te stellen, zodat je een video die je met yt-dlp download ook kan voorzien van tijdstempels?

[ Voor 10% gewijzigd door ocf81 op 24-06-2026 00:07 ]

[_Apache_]

ocf81 schreef op woensdag 24 juni 2026 @ 00:06:
@_Apache_ heel erg interessant. Denk je jouw opstelling ook kan worden aangepast om een lijst van hoofdstukken op te stellen, zodat je een video die je met yt-dlp download ook kan voorzien van tijdstempels?

Dat zal een flinke ombouw moeten worden. Zou er een apart script van maken. Maar ik vraag me af of ytdl dat soort markers kan zien.

[ocf81]

_Apache_ schreef op woensdag 24 juni 2026 @ 08:46:
[...]

Dat zal een flinke ombouw moeten worden. Zou er een apart script van maken. Maar ik vraag me af of ytdl dat soort markers kan zien.

yt-dlp kan op zich wel tijdstempels downloaden, maar als die er niet zijn, dan kan je die natuurlijk ook niet downloaden. Waar ik nu mee zit is dat ik streams van 2 à 4 uur heb van kanalen zoals 3D Musketeers, waar de tijdstempels dus nooit worden gemaakt.

Als het jou lukt om de ondertiteling te genereren, dan is het wellicht ook mogelijk om die uitvoer als eerste stap te gebruiken voor een analyse van waar de onderwerpen zich afwisselen. Dat lijkt me op zich een taak die een lokale LLM wel aan zou moeten kunnen. Vandaar de interesse in jouw opstelling.
En ik wil het ook wel zelf doen, maar zelf het wiel opnieuw uitvinden is een beetje overbodig lijkt me, dus vandaar de vraag

[_Apache_]

ocf81 schreef op woensdag 24 juni 2026 @ 09:55:
[...]

yt-dlp kan op zich wel tijdstempels downloaden, maar als die er niet zijn, dan kan je die natuurlijk ook niet downloaden. Waar ik nu mee zit is dat ik streams van 2 à 4 uur heb van kanalen zoals 3D Musketeers, waar de tijdstempels dus nooit worden gemaakt.

Als het jou lukt om de ondertiteling te genereren, dan is het wellicht ook mogelijk om die uitvoer als eerste stap te gebruiken voor een analyse van waar de onderwerpen zich afwisselen. Dat lijkt me op zich een taak die een lokale LLM wel aan zou moeten kunnen. Vandaar de interesse in jouw opstelling.
En ik wil het ook wel zelf doen, maar zelf het wiel opnieuw uitvinden is een beetje overbodig lijkt me, dus vandaar de vraag

Wat voor CPU heb je, of een GPU die je kan inzetten?

Voro wat testwerk is een deftige cpu (8 of 10 cores) wel goed, maar dat zal de helft van de afspeelsnelheid lopen.

[ocf81]

_Apache_ schreef op woensdag 24 juni 2026 @ 10:12:
[...]

Wat voor CPU heb je, of een GPU die je kan inzetten?

Voro wat testwerk is een deftige cpu (8 of 10 cores) wel goed, maar dat zal de helft van de afspeelsnelheid lopen.

Ik heb een Threadripper 5955WX met 256GB RAM en vier Radeon Pro AI 9700's.

[_Apache_]

ocf81 schreef op woensdag 24 juni 2026 @ 10:41:
[...]

Ik heb een Threadripper 5955WX met 256GB RAM en vier Radeon Pro AI 9700's.

Whisper heeft geen AMD GPU support voor zover ik weet, maar die ripper zo er zo doorheen moeten komen. Als je een voorbeeld media file kunt aanleveren, wil ik hem er best even doorheen trekken. Kijken of het wat is voor je.

[ocf81]

Kan je eens kijken wat de transcriptie van deze video oplevert?

[_Apache_]

ocf81 schreef op woensdag 24 juni 2026 @ 11:24:
Kan je eens kijken wat de transcriptie van deze video oplevert?
[YouTube: WE SCREWED UP (And Now We Have A Mess To Clean Up)!!- Making Awesome 263]

Engels (spraak) naar Engels (tekst) of naar Nederlandse tekst?

[ocf81]

_Apache_ schreef op woensdag 24 juni 2026 @ 11:27:
[...]

Engels (spraak) naar Engels (tekst) of naar Nederlandse tekst?

Engelse spraak naar Engelse tekst.

[_Apache_]

ocf81 schreef op woensdag 24 juni 2026 @ 11:29:
[...]

Engelse spraak naar Engelse tekst.

Ik heb de media inmiddels lokaal en waag een poging.
Eens kijken of het lukt, het is wel continu gepraat. Bij films gebruikt hij de stiltes als 'ankerpunt' van de einde van een gesproken zin. Dus moet even zien hoe het eruit komt, heb best wat parameters die ik nog kan wijzigen.

Snelheid zit er wel in ieder geval, hij is op de helft nu.

[ocf81]

_Apache_ schreef op woensdag 24 juni 2026 @ 11:38:
[...]

Ik heb de media inmiddels lokaal en waag een poging.
Eens kijken of het lukt, het is wel continu gepraat. Bij films gebruikt hij de stiltes als 'ankerpunt' van de einde van een gesproken zin. Dus moet even zien hoe het eruit komt, heb best wat parameters die ik nog kan wijzigen.

Snelheid zit er wel in ieder geval, hij is op de helft nu.

Heel fijn dat je dat voor mij wil proberen. Ik ben benieuwd!

[_Apache_]

ocf81 schreef op woensdag 24 juni 2026 @ 11:39:
[...]

Heel fijn dat je dat voor mij wil proberen. Ik ben benieuwd!

Linkje in je DM, nog niet perfect, maar best tevreden voor een eerste run.

• het heeft door dat er namen genoemd worden, Murph, Morflabs, en hij zet er een hoofdletter bij
• De praat snelheid is wat aan de hoge kant, moet daar wat parameters op tunen.
• Door het constante gepraat heeft hij moeite met hele zinnen (punten plaatsen, hoofdletters enzo).

[ Voor 51% gewijzigd door _Apache_ op 24-06-2026 12:09 ]

[_Apache_]

ocf81 schreef op woensdag 24 juni 2026 @ 11:39:
[...]

Heel fijn dat je dat voor mij wil proberen. Ik ben benieuwd!

[ Voor 17% gewijzigd door _Apache_ op 24-06-2026 11:59 ]

[ocf81]

_Apache_ schreef op woensdag 24 juni 2026 @ 11:56:
[...]

Linkje in je DM, nog niet perfect, maar best tevreden voor een eerste run.

• het heeft door dat er namen genoemd worden, Murph, Morflabs, en hij zet er een hoofdletter bij
• De praat snelheid is wat aan de hoge kant, moet daar wat parameters op tunen.
• Door het constante gepraat heeft hij moeite met hele zinnen (punten plaatsen, hoofdletters enzo).

Super. Dit is wel iets waar ik wellicht iets mee kan. Ik ga eens kijken of ik jouw opstelling na kan maken. Ik zie dat Whisper wel met ROCm overweg kan, dus het zou wel moeten kunnen op mijn hardware.

[DeNachtwacht]

_Apache_ schreef op dinsdag 23 juni 2026 @ 21:19:
Dit allen draait op een (oude) i7 7700k, en een 1080TI. Geen spectaculaire hardware, maar een snellere GPU zou maar iets van 20-25% winst zijn. En die zijn **** duur.

Wat zou je duur vinden dan? een RTX 5060 Ti met 16GB kost €550, is zo'n 50-75% sneller, profiteert van optimalisaties als nvfp4 én heeft 5GB meer vram (er vanuitgaande dat je 11GB hebt). Met de verkoop van de 1080 Ti voor zo'n €150 lijkt me dat best een te overwegen investering.

[ Voor 3% gewijzigd door DeNachtwacht op 24-06-2026 12:50 ]

[_Apache_]

DeNachtwacht schreef op woensdag 24 juni 2026 @ 12:50:
[...]

Wat zou je duur vinden dan? een RTX 5060 Ti met 16GB kost €550, is zo'n 50-75% sneller, profiteert van optimalisaties als nvfp4 én heeft 5GB meer vram (er vanuitgaande dat je 11GB hebt). Met de verkoop van de 1080 Ti voor zo'n €150 lijkt me dat best een te overwegen investering.

Fair point, wel heb ik al een ouder moederbord. De meerwaarde van de 5060 kon mijn Z270 met i7 7700k moederbord nog niet echt benutten voor games.

[DeNachtwacht]

Ja dat is wel zo, je krijgt her en der cpu bottleneck natuurlijk, maar voor LLM gebruik zal dat niet snel opspelen.