Ervaringen met zelf gehoste AI assistenten

[Tazzy]

Snap ik, ik ben nog een beetje aan het kijken welk model het beste werkt, maar het doel is ondersteunend zijn bij Osint werk.

[Felicia]

Tazzy schreef op vrijdag 26 juni 2026 @ 08:15:Heb er nu een P100 inzitten die ik echt niemand aanraad. V100 is onderweg als vervanger

Ik ben benieuwd waarom je de P100 afraad?

Als je de V100 binnen hebt ben ik ook wel benieuwd hoe die presteert.

[DeNachtwacht]

Tazzy schreef op zaterdag 27 juni 2026 @ 11:14:
Snap ik, ik ben nog een beetje aan het kijken welk model het beste werkt, maar het doel is ondersteunend zijn bij Osint werk.

Wat voor toepassingen/ondersteuning denk je dan aan?

[Tazzy]

Felicia schreef op zaterdag 27 juni 2026 @ 19:14:
[...]

Ik ben benieuwd waarom je de P100 afraad?

Als je de V100 binnen hebt ben ik ook wel benieuwd hoe die presteert.

Ik kreeg met de P100 dingen niet aan de praat, door context size maar ook door het totaal ontbreken van tensor cores. Ik probeer data te verzamelen mijn collectie, te verbeteren etc. Daar is multi-step reasoning denk ik voor nodig. Nja het werkt gewoon niet lekker

[Bryan Vreijsen]

Tazzy schreef op zondag 28 juni 2026 @ 09:42:
[...]

Ik kreeg met de P100 dingen niet aan de praat, door context size maar ook door het totaal ontbreken van tensor cores. Ik probeer data te verzamelen mijn collectie, te verbeteren etc. Daar is multi-step reasoning denk ik voor nodig. Nja het werkt gewoon niet lekker

Dat is inderdaad de bottleneck. Zonder tensor cores is multi-step reasoning op een P100 een frustrerend traject, zeker voor OSINT-werk waar je toch die context window nodig hebt. Ik heb zelf ook recent m'n setup onder de loep genomen omdat ik tegen vergelijkbare limitaties aanliep; die V100 zal die hardware-bottleneck voor je wegnemen, al blijft die 16GB bij complexe datasets met zware reasoning soms echt een krap jasje.

Heb je al modellen op het oog die je wilt draaien? Ik ben benieuwd of je ze 'kaal' draait of dat je al direct richting zware quantisatie moet om het passend te krijgen in je VRAM?

[ocf81]

Er is een stuk over hardwarevereisten aan de OP toegevoegd. Als iemand nog feedback heeft, dan horen wij dat graag

[himlims_]

Afgelopen week een kleine duik gedaan in zelf hosten, met wisselend succes en resultaat.

Tijdens “zoeken” kwam ik dit project tegen;

Air-LLM

AirLLM is an open-source Python library that lets you run massive Large Language Models (LLMs)—like Llama 3 70B and Llama 3.1 405B—on standard consumer hardware. By using layer-by-layer inference, it streams weights from your disk to memory and discards them immediately after use. This circumvents VRAM bottlenecks, letting you run a 70B parameter model on a single 4GB GPU

Dat vond wel mooi klinken, en lijkt potentie te hebben gebaseerd op de beschrijving. Maar het project lijkt niet heel actief meer in ontwikkeling te zijn:

https://github.com/lyogavin/airllm

Iemand ervaring mee?

[ApexAlpha]

himlims_ schreef op zondag 28 juni 2026 @ 18:30:
Afgelopen week een kleine duik gedaan in zelf hosten, met wisselend succes en resultaat.

Tijdens “zoeken” kwam ik dit project tegen;

Air-LLM


[...]


Dat vond wel mooi klinken, en lijkt potentie te hebben gebaseerd op de beschrijving. Maar het project lijkt niet heel actief meer in ontwikkeling te zijn:

https://github.com/lyogavin/airllm

Iemand ervaring mee?

Krijg je hier dan niet 'gewoon' de snelheid van je harde schijf als bottleneck ipv VRAM dan?

[himlims_]

ApexAlpha schreef op maandag 29 juni 2026 @ 10:05:
[...]


Krijg je hier dan niet 'gewoon' de snelheid van je harde schijf als bottleneck ipv VRAM dan?

volgens mij wel, worden delen 'gefaseerd' (gelaagd) ingeladen, zal ongetwijfeld stuk minder snel zijn. maar 'goedkoper' en eigen baas, tozv commerciele diensten of modellen die high-end hardware vereisten

[ApexAlpha]

himlims_ schreef op maandag 29 juni 2026 @ 10:07:
[...]

volgens mij wel, worden delen 'gefaseerd' (gelaagd) ingeladen, zal ongetwijfeld stuk minder snel zijn. maar 'goedkoper' en eigen baas, tozv commerciele diensten of modellen die high-end hardware vereisten

Ja ik vraag me af wat het nut dan is. Heb liever Qwen 3.6 met 40 tok/sec dan een groter model met 5tok/s denk ik.

[DeNachtwacht]

himlims_ schreef op zondag 28 juni 2026 @ 18:30:
Dat vond wel mooi klinken, en lijkt potentie te hebben gebaseerd op de beschrijving. Maar het project lijkt niet heel actief meer in ontwikkeling te zijn:

https://github.com/lyogavin/airllm

Iemand ervaring mee?

Nee, en 2024 in de wereld van AI is zo ongeveer vergelijkbaar met teruggaan naar de middeleeuwen. Er is in 2 jaar zoveel gebeurd .

Mijn gok is dat dit project een stille dood is gestorven doordat iedereen heeft ontdekt dat 1 token/sec misschien zorgt dat een 70B model draaien technisch gezien kan, maar gewoon onbruikbaar is. Verkijk je bovendien ook niet op die 70B. De laatste jaren zijn kleinere modellen stukken beter geworden, met een model tussen de 15-25B kun je lokaal best aardige dingen doen met een fors hogere snelheid.

[ Voor 7% gewijzigd door DeNachtwacht op 29-06-2026 10:37 ]

[Felicia]

DeNachtwacht schreef op maandag 29 juni 2026 @ 10:35:
[...]

Nee, en 2024 in de wereld van AI is zo ongeveer vergelijkbaar met teruggaan naar de middeleeuwen. Er is in 2 jaar zoveel gebeurd .

Dat zeg je heel goed want recent is Deepseek met Dspark gekomen: https://github.com/deepseek-ai/DeepSpec

Daar is al een pull request voor bij llama.cpp: http://github.com/ggml-org/llama.cpp/pull/25173/

En als ik die draai (Intel Arc Pro B60 dus gecompileerd voor SYCL) met het Qwen3 8B (bf16) model (met en zonder Dspark) dan haal ik 24-25tps zonder en 38-42tps met Dspark. Ik ga nu kijken wat ie met een model als dit* gaat doen...
_{*Ik ben niet per se op zoek naar een unscensored model maar er is nog geen ander MOE model als deze waarmee ik kan testen :P}

[R3m3d7]

Felicia schreef op zaterdag 4 juli 2026 @ 20:07:
[...]

Dat zeg je heel goed want recent is Deepseek met Dspark gekomen: https://github.com/deepseek-ai/DeepSpec

Daar is al een pull request voor bij llama.cpp: http://github.com/ggml-org/llama.cpp/pull/25173/

En als ik die draai (Intel Arc Pro B60 dus gecompileerd voor SYCL) met het Qwen3 8B (bf16) model (met en zonder Dspark) dan haal ik 24-25tps zonder en 38-42tps met Dspark. Ik ga nu kijken wat ie met een model als dit* gaat doen...
_{*Ik ben niet per se op zoek naar een unscensored model maar er is nog geen ander MOE model als deze waarmee ik kan testen :P}

Ik vind het lastig om te snappen wat ze hier doen, is dit heel anders dan MTP of een mini model voor het grote model zetten voor predictie?

edit:
het is idd speculative decoding

[Yarisken]

Ik heb dit weekend met Hermes liggen spelen. Echter mijn optiplex 3080 mff met 32GB ram is te traag, zelf met kleine modellen. Hermes is vanalles aan het inladen en duurt 3 minuten voor ik een antwoord krijg. Ga ik via ollama dan gaat het allemaal wel veel sneller.

Spijtig had wel leuke plannen ermee ... Optie is nog een cloud model zoals Claude of deepseek te gebruiken maar hangt wel kost en afhankelijkheid vanaf.

[Tazzy]

Wat voor videokaart heb je er ingestopt? Als je het draaid op de interne GPU van de CPU dan snap ik het wel dat het niet echt vlot is

[R3m3d7]

@Yarisken ik zou, afhankelijk van je prompt privacy eisen en budget je dell servertje als host gebruiken voor hermes maar bv super goedkoop deepseek tokens kopen, Hermes kan daarmee praten via de api. Werkt top. Als je wel lokaal wilt werken hangt het van je plannen af wat je nodig hebt voor gpu maar een agent gebruiken zonder gpu versnelling of een heel fors aantal channels vol met snelle dimms gaat geen pretje worden.

[Yarisken]

Ja ik ben helaas ook tot die conclusie gekomen. Zal idd is naar deepseek tokens kijken. Bedankt voor de schouder om op te huilen :-)

[eheijnen]

Zijn er tweakers die deze al getest hebben:
https://huggingface.co/zai-org/GLM-5.2

Schijnt een behoorlijke stap vooruit te zijn...

[ocf81]

eheijnen schreef op zondag 5 juli 2026 @ 09:45:
Zijn er tweakers die deze al getest hebben:
https://huggingface.co/zai-org/GLM-5.2

Schijnt een behoorlijke stap vooruit te zijn...

Is ook heel interessant... Als je ergens zo'n €700k hebt liggen. Het model heeft namelijk 753B parameters. Dan heb je dus een cluster met meerdere supersnel genetwerkte machines nodig. Een DC GPU zoals de MI300X kost naar verluidt zo'n €40k. Volgens de ApX ML calculator heb je dan een cluster van vier machines met vier GPU's nodig om een context van ca. 850k aan te kunnen. (1mio vereist dat je dan opschaalt naar de volgende tweemacht aan clusternodes, wat dus wel heel veel geld is voor 150k extra context.)
Met zo'n omvang is thuis draaien vooralsnog uitgesloten.

[ Voor 46% gewijzigd door ocf81 op 05-07-2026 11:48 ]

[DeNachtwacht]

Hoho is ook een FP4 versie beschikbaar

Die draai je al met 6 blackwell 6000 Pro gpu's a €13.000, buitenkansje voor +/- een ton!

[ Voor 4% gewijzigd door DeNachtwacht op 05-07-2026 12:08 ]

[ocf81]

DeNachtwacht schreef op zondag 5 juli 2026 @ 12:08:
Hoho is ook een FP4 versie beschikbaar

Die draai je al met 6 blackwell 6000 Pro gpu's a €13.000, buitenkansje voor +/- een ton!

Trek eens aan die slider voor KV cache in de ApX calulator en je zal heel snel naar lucht gaan happen
(overigens volgen tensor parallelisme verbeteringen een verdubbelingspatroon, dus het is 4 of 8, maar 6 gaat niet)
Het kan met een paar PLX kaarten wellicht ook met één machine.

[ Voor 5% gewijzigd door ocf81 op 05-07-2026 12:25 ]

[eheijnen]

Nog effe spaaruh...

[DeNachtwacht]

Nu het hier dan toch over multi-gpu ervaringen gaat even mijn ervaringen hier delen + wat vragen. Ik heb naast mijn 5090 een 5060 Ti erbij gekocht omdat het een relatief goedkope manier is om de 32GB vram die ik al heb met 50% te verhogen (kwam een tweedehandsje tegen voor onder de €400 dus dat kon ik niet laten liggen). Het idee was niet GLM 5.2 maar om Ornith 35B in plaats van op nvfp4 op fp8 (37GB groot) te kunnen draaien.

Alles werkt inmiddels goed, maar in tegenstelling tot wat je online leest werkt ollama toch nog steeds fijner dan wat ik uit llama.cpp krijg, ondanks dat dat "de ultieme tool" zou zijn. Ik heb hier uiteindelijk met diverse settings wat geexperimenteerd en kwam uiteindelijk hier uit

.\llama-server.exe -m .\ornith-1.0-35b-Q8_0.gguf --flash-attn on -ngl 999 --main-gpu 1 --cache-type-k q8_0 --cache-type-v q8_0

Maar waar ik dan tegenaan blijf lopen is dat het ddr geheugen en vram volgeladen blijft met dit model, wat niet bijster ideaal is als je het gebruikt om een openclaw bot aan te sturen. 90% van de tijd doet die namelijk niks en in windows of tijdens een spelletje is het zegmaar vrij lastig dat al je vram en een groot deel van het ram constant gereserveerd is.

Ollama doet dat veel netter, sowieso wordt er bij exact ditzelfde model (nog) niet direct ddr geheugen gereserveerd, ik vermoed dat hij dit pas aanspreekt als de context daar aanleiding toe geeft. Maar ook het vram wordt bij even niet meer in gebruik nettjes leeggemaakt en weer volgeladen zodra het weer nodig is. Kortom het geheugenmanagement gaat automatisch een stuk netter.

Heeft iemand een idee of en zo ja hoe dit in llama.cpp is in te stellen? Vooralsnog lijkt het gemak van ollama namelijk een stuk meer waard dan het (ook vrij minieme) snelheidsverschil in het voordeel van llama.cpp.

[ Voor 4% gewijzigd door DeNachtwacht op 05-07-2026 12:40 ]

[JJ Le Funk]

DeNachtwacht schreef op zondag 5 juli 2026 @ 12:39:
Nu het hier dan toch over multi-gpu ervaringen gaat even mijn ervaringen hier delen + wat vragen. Ik heb naast mijn 5090 een 5060 Ti erbij gekocht [...]

de vram van de 5090 is 4x sneller dan de 5060 dacht ik.
kan het zijn dat je memory pool als geheel gaat hangen op de snelheid van de 5060 en daarbij nog de issue dat je software nodig hebt om het als 1 memory pool te vullen voor grotere context.
Of is dat niet hoe je de dual GPU setup probeert in te zetten?

[lariekoek]

Opdat het iemand helpt:

Ik was een hele tijd in de veronderstelling dat het allemaal GPU-native moet, want CPU traag.
Zo deed ik veel tests met qwen3.5:4b (want maar 8GB VRAM).
En let's face it: die is knap waardeloos.

Waarom toch iets anders proberen?
1. Ollama kan prima CPU/GPU doen, RAM en VRAM. Het delen.
2. qwen3-coder:30b en qwen3:30b.

Dit zijn MoE modellen waarbij 3B naar de GPU gaan en de rest op CPU.
De Tokens/second is gelijk aan de GPU native 4b modellen waarmee ik getest heb.
Máár, de 'nuttige' tokens per seconde zijn daarmee wel hoger.
Op mijn 3070 deed qwen3.5:4b zo'n 41 tok/s aan waardeloze output.
Nu 38.9 met een hogere kwaliteit.

Nou is de keerzijde natuurlijk dat er een hele smak je RAM in gaat, een deel is dus CPU en een deel GPU.
Ja, dan is je PC/workstation best een kacheltje.
Als dit voor jou ook werkt, is dat een prima manier om wel iets meer kwaliteit én gewogen snelheid te behalen.

Heb aardig wat tijd gestoken om d.m.v. tooling, try/retry/fail patterns, het beste te behalen met 4b maar uiteindelijk is het kosten/baten, ook tijd is kostbaar.

[ Voor 8% gewijzigd door lariekoek op 05-07-2026 14:04 ]

[DeNachtwacht]

JJ Le Funk schreef op zondag 5 juli 2026 @ 12:49:
[...]

de vram van de 5090 is 4x sneller dan de 5060 dacht ik.
kan het zijn dat je memory pool als geheel gaat hangen op de snelheid van de 5060 en daarbij nog de issue dat je software nodig hebt om het als 1 memory pool te vullen voor grotere context.
Of is dat niet hoe je de dual GPU setup probeert in te zetten?

De 5060 Ti heeft inderdaad maar iets van 5000 cuda cores, de 5090 20000. Dus natuurlijk is een model op nvfp4 dat inclusief context geheel in de 5090 past sneller. Maar wat je dus feitelijk doet is in plaats van offloaden naar traag ramgeheugen, offloaden naar de 5060 Ti. En dan gaat bij taalmodellen de snelheid niet ineens op het langzame tempo, maar alle lagen die op de 5090 passen (dat zal dus niet de volle 32GB zijn maar bijv. 28 gb ofzo zie ik vaak) gaat gewoon op normale 5090 snelheid. Dus je hebt met 32|16 gb vram dat het snelheidsverlies maximaal is dat 66% van de workload op het snelle 5090 deel zit, en 33% op de tragere. Maar meestal is dat dus hoger, stel het model + context is 40gb dan is iets als 30+10 een logischere verdeling in de praktijk. Het voordeel is dus dat de 2e gpu alsnog fors sneller is dan ddr geheugen dus daar zit je snelheidswinst.

Maar goed dat is een antwoord op jouw vraag.. nu hopen dat iemand mijn vraag ook nog kan beantwoorden

[Felicia]

lariekoek schreef op zondag 5 juli 2026 @ 13:21:
Opdat het iemand helpt:

Ik was een hele tijd in de veronderstelling dat het allemaal GPU-native moet, want CPU traag.
Zo deed ik veel tests met qwen3.5:4b (want maar 8GB VRAM).
En let's face it: die is knap waardeloos.

Waarom toch iets anders proberen?
1. Ollama kan prima CPU/GPU doen, RAM en VRAM. Het delen.
2. qwen3-coder:30b en qwen3:30b.

Dit zijn MoE modellen waarbij 3B naar de GPU gaan en de rest op CPU.
De Tokens/second is gelijk aan de GPU native 4b modellen waarmee ik getest heb.
Máár, de 'nuttige' tokens per seconde zijn daarmee wel hoger.

Je bent een dense-model met een MOE model aan het vergelijken, die architecturen hebben allebei voordelen en nadelen. Er wordt niet voor niets gezegd dat de Qwen 3.6 27b de beste uit de Qwen 3.6 reeks is máár, dat Qwen 3.6 35b A3b het beste alternatief is als de 27b's snelheid onvoldoende is.

Ter referentie, de 27b haalt bij mij zo'n 20 tok/sec maar de 35b ruim 40 tok/sec (beide met SYCL, met Vulkan haal ik initieel veel meer maar dat zakt rap in als de context groeit).

[lariekoek]

Felicia schreef op zondag 5 juli 2026 @ 15:31:
[...]

Je bent een dense-model met een MOE model aan het vergelijken, die architecturen hebben allebei voordelen en nadelen. Er wordt niet voor niets gezegd dat de Qwen 3.6 27b de beste uit de Qwen 3.6 reeks is máár, dat Qwen 3.6 35b A3b het beste alternatief is als de 27b's snelheid onvoldoende is.

Ter referentie, de 27b haalt bij mij zo'n 20 tok/sec maar de 35b ruim 40 tok/sec (beide met SYCL, met Vulkan haal ik initieel veel meer maar dat zakt rap in als de context groeit).

Ik maak maar één punt en dat is: staar je niet blind op dat het GPU-native moet.
Waar het uiteindelijk om gaat is: dat nuttiger werk bij dezelfde brandbreedte/t tegenover de kosten een afweging is.
Bovendien ligt het ook volledig aan je eigen stack, wat je überhaupt maakt en verwacht. Dus wat je meet.

Mijn agents zijn volledig autonoom in een task-driven stack. Ik hoef bijvoorbeeld de inputs en outputs niet te lezen, er niet op te wachten. Ik verwacht enkel 'daadwerkelijke output' aan het einde van de rit.
Dat is een heel andere afweging dan iemand die een leuke interactieve agent wil, meer abstract.

Dus nee, ik vergelijk geen dense model met een MOE an sich. Dat is noise.
"Beste" mag iedereen voor zichzelf bepalen dacht ik.

Daarmee lag mijn focus op proberen om met 4b te werken terwijl er meer winst te behalen was door toch een stap terug te nemen. 91t/sec met een hoop fails en retries tegenover 30t/sec aan one-shots is het punt.
Dus dan gaat het niet langer om hoeveel tokens per seconde an sich, niet welk model an sich, maar of je je resultaten sneller/beter behaalt. Snap dat de post een beetje teveel open liet, en laat, maar 'tokens per seconde' is niet de benchmark als het om persoonlijke toepassing en meetbare resultaten in een tijdvenster gaat.

[ Voor 34% gewijzigd door lariekoek op 05-07-2026 16:45 ]

[DeNachtwacht]

lariekoek schreef op zondag 5 juli 2026 @ 15:43:
Ik maak maar één punt en dat is: staar je niet blind op dat het GPU-native moet.
...

Dus nee, ik vergelijk geen dense model met een MOE an sich. Dat is noise.
"Beste" mag iedereen voor zichzelf bepalen dacht ik.

Dat kan allemaal wel, maar je moet alsnog appels met appels vergelijken. Een dense model heeft hogere kwaliteit en lagere snelheid. Een MoE model heeft lagere kwaliteit maar is sneller. In jouw redenering vergelijk je appels met peren.

Jouw stelling is "je kan taalmodellen best op een CPU draaien, de snelheid valt reuze mee!". en dat kan best kloppen, maar het meest volledige antwoord is "je kan sommige MoE modellen nog met best acceptabele snelheid draaien op een cpu" (want voor dense modellen is dat simpelweg onwerkbaar traag). En dan hoort daar nog achteraan dat de kwaliteit die dat MoE model heeft niet vergelijkbaar is met een dense model.

[ Voor 4% gewijzigd door DeNachtwacht op 05-07-2026 22:18 ]

[lariekoek]

DeNachtwacht schreef op zondag 5 juli 2026 @ 22:17:
[...]

Dat kan allemaal wel, maar je moet alsnog appels met appels vergelijken. Een dense model heeft hogere kwaliteit en lagere snelheid. Een MoE model heeft lagere kwaliteit maar is sneller. In jouw redenering vergelijk je appels met peren.

Jouw stelling is "je kan taalmodellen best op een CPU draaien, de snelheid valt reuze mee!". en dat kan best kloppen, maar het meest volledige antwoord is "je kan sommige MoE modellen nog met best acceptabele snelheid draaien op een cpu" (want voor dense modellen is dat simpelweg onwerkbaar traag). En dan hoort daar nog achteraan dat de kwaliteit die dat MoE model heeft niet vergelijkbaar is met een dense model.

Jeetje, misschien je moet je gewoon even beter lezen of anders even thinking op true zetten. 👍
Simpel punt, er zijn modellen die minder parameters op GPU doen.
Ga iemand anders woorden in zijn mond leggen en vertellen wat zij denken en redeneren.

[ Voor 10% gewijzigd door lariekoek op 05-07-2026 22:49 ]

[ocf81]

Ik denk dat het perspectief dat je met niet zo veel hardware toch nog wat nuttigs kan op zich wel waardevol is, maar de kanttekeningen die worden gemaakt omtrent de beperkingen van MoE modellen zijn ook terecht.

[lariekoek]

ocf81 schreef op zondag 5 juli 2026 @ 22:56:
Ik denk dat het perspectief dat je met niet zo veel hardware toch nog wat nuttigs kan op zich wel waardevol is, maar de kanttekeningen die worden gemaakt omtrent de beperkingen van MoE modellen zijn ook terecht.

Klopt, maar dan moeten ze dat stellen zonder mij iets in mijn schoot te werpen.

[DeNachtwacht]

lariekoek schreef op zondag 5 juli 2026 @ 22:20:
[...]


Jeetje, misschien je moet je gewoon even beter lezen of anders even thinking op true zetten. 👍
Simpel punt, er zijn modellen die minder parameters op GPU doen.
Ga iemand anders woorden in zijn mond leggen en vertellen wat zij denken en redeneren.

Je mag het even vriendelijker verwoorden volgende keer.

Je eerste claim breng je alsof AI allemaal heel goed te doen is met de CPU, maar vertelt er niet bij dat dat met modellen is die een andere opzet en objectief mindere kwaliteit hebben. Juist met jouw toon van "ik zal met iedereen hier even een briljant idee komen delen" is dat eruit laten m.i. gewoon onvolledig en als je daar dan netjes op gewezen wordt ga je de loopgraven in i.p.v. erkennen dat dat inderdaad wel een belangrijke kanttekening is.

Maar goed, het punt is wel gemaakt laten we dit verder houden bij wat het is.

[ Voor 7% gewijzigd door DeNachtwacht op 06-07-2026 13:40 ]

[Deepflame]

DeNachtwacht schreef op zondag 5 juli 2026 @ 12:39:
Nu het hier dan toch over multi-gpu ervaringen gaat even mijn ervaringen hier delen + wat vragen. Ik heb naast mijn 5090 een 5060 Ti erbij gekocht omdat het een relatief goedkope manier is om de 32GB vram die ik al heb met 50% te verhogen (kwam een tweedehandsje tegen voor onder de €400 dus dat kon ik niet laten liggen). Het idee was niet GLM 5.2 maar om Ornith 35B in plaats van op nvfp4 op fp8 (37GB groot) te kunnen draaien.

Alles werkt inmiddels goed, maar in tegenstelling tot wat je online leest werkt ollama toch nog steeds fijner dan wat ik uit llama.cpp krijg, ondanks dat dat "de ultieme tool" zou zijn. Ik heb hier uiteindelijk met diverse settings wat geexperimenteerd en kwam uiteindelijk hier uit


[...]

Maar waar ik dan tegenaan blijf lopen is dat het ddr geheugen en vram volgeladen blijft met dit model, wat niet bijster ideaal is als je het gebruikt om een openclaw bot aan te sturen. 90% van de tijd doet die namelijk niks en in windows of tijdens een spelletje is het zegmaar vrij lastig dat al je vram en een groot deel van het ram constant gereserveerd is.

Ollama doet dat veel netter, sowieso wordt er bij exact ditzelfde model (nog) niet direct ddr geheugen gereserveerd, ik vermoed dat hij dit pas aanspreekt als de context daar aanleiding toe geeft. Maar ook het vram wordt bij even niet meer in gebruik nettjes leeggemaakt en weer volgeladen zodra het weer nodig is. Kortom het geheugenmanagement gaat automatisch een stuk netter.

Heeft iemand een idee of en zo ja hoe dit in llama.cpp is in te stellen? Vooralsnog lijkt het gemak van ollama namelijk een stuk meer waard dan het (ook vrij minieme) snelheidsverschil in het voordeel van llama.cpp.

Probeer dit eens:

Bash:

.\llama-server.exe `
  -m .\ornith-1.0-35b-Q8_0.gguf `
  --flash-attn on `
  -ngl 999 `
  --device CUDA0,CUDA1 `
  --split-mode layer `
  --tensor-split 32,16 `
  --ctx-size 32768 `
  --parallel 1 `
  --cache-type-k q8_0 `
  --cache-type-v q8_0 `
  --cache-ram 0 `
  --no-cache-idle-slots `
  --sleep-idle-seconds 300

De magische houd-niet-alles-in-geheugen setting is --sleep-idle-seconds 300. Dat laat llama-server na 5 minuten idle slapen/unloaden, en bij de volgende request weer laden. Waarschijnlijk heeft ollama onderwater een setting hiervoor.

Daarnaast voor je DDR probleem: --cache-ram 0 helpt je hier dan bij, want recente llama-server builds hebben host-memory prompt caching. Dat is nuttig voor TTFT, maar niet als je vooral wil dat idle RAM leeg blijft. --no-cache-idle-slots past daar ook bij, dus probeer die allebei.

Verder:
Zet --ctx-size expliciet. KV-cache groeit met context en kan anders verrassend groot worden.
Zet --parallel 1 als er maar één OpenClaw bot tegelijk op zit.
--main-gpu 1 is voor je normale layer split waarschijnlijk niet de belangrijkste knop. Voor 5090 32GB + 5060 Ti 16GB zijn --device en --tensor-split 32,16 / 2,1 logischer.

Verder nog wat semi-relevante settings om te vermijden:
Laat --mmap aan (default); niet naar --no-mmap grijpen. Met mmap kan de OS page cache veel zelf regelen. Zonder mmap laad je het model eerder als gewone private process memory.
Gebruik geen --mlock, want dat is letterlijk “hou dit vast in RAM”.

En houd er rekening mee dat als iets /metrics blijft pollen (geen idee of OpenClaw dat doet), kan dat in router/sleep setups het model wakker houden. Dus monitoring kan een “waarom slaapt hij niet?” boosdoener worden.

[DeNachtwacht]

Deepflame schreef op maandag 6 juli 2026 @ 12:31:
[...]

Probeer dit eens:

Bash:

.\llama-server.exe `
  -m .\ornith-1.0-35b-Q8_0.gguf `
  --flash-attn on `
  -ngl 999 `
  --device CUDA0,CUDA1 `
  --split-mode layer `
  --tensor-split 32,16 `
  --ctx-size 32768 `
  --parallel 1 `
  --cache-type-k q8_0 `
  --cache-type-v q8_0 `
  --cache-ram 0 `
  --no-cache-idle-slots `
  --sleep-idle-seconds 300

Ik zal de ai tekst maar even weglaten

ik had dit ook al daar gecheckt natuurlijk en het lost helaas niks op. Hij laadt alsnog alles in het ramgeheugen direct bij starten, en de 5090 krijgt een poule van 64GB geheugen en de 5060 ti 48, wat direct allemaal vrolijk naar het ram wordt geoffload. Waar het mij om gaat is juist dat er bij de start niet direct allerlei vram/ram wordt geserveerd en dat pas gebeurt als het gebruikt gaat worden.

[Deepflame]

DeNachtwacht schreef op maandag 6 juli 2026 @ 14:21:
[...]

Ik zal de ai tekst maar even weglaten

[..]

Hey, dat was grotendeels zelf getypt! :') Alleen een d/t pass laten doen door ChatGPT want ondanks de ijverige pogingen van mijn docenten heb ik dat nooit goed onder de knie gekregen.

DeNachtwacht schreef op maandag 6 juli 2026 @ 14:21:
[...]

ik had dit ook al daar gecheckt natuurlijk en het lost helaas niks op. Hij laadt alsnog alles in het ramgeheugen direct bij starten, en de 5090 krijgt een poule van 64GB geheugen en de 5060 ti 48, wat direct allemaal vrolijk naar het ram wordt geoffload. Waar het mij om gaat is juist dat er bij de start niet direct allerlei vram/ram wordt geserveerd en dat pas gebeurt als het gebruikt gaat worden.

Hm, bij mij word het geheugen wel vrijgegeven na een paar minuten, welke versie van llama.cpp draai jij? Zal wel een recente zijn, aangezien je tot nu toe altijd met ollama hebt gewerkt. Maar volgens de docs zou dat gewoon pas in moeten laden bij gebruik. En dat gedrag zie ik hier ook, niets laad automatisch in totdat ik het aanklik in de webinterface om in te laden.

Is het mogelijk dat OpenClaw direct dat inladen forceert omdat je agent dat model nodig heeft?

Oh en 64GB op je 5090 kan natuurlijk niet.

[Felicia]

DeNachtwacht schreef op zondag 5 juli 2026 @ 12:39:
Maar waar ik dan tegenaan blijf lopen is dat het ddr geheugen en vram volgeladen blijft met dit model, wat niet bijster ideaal is als je het gebruikt om een openclaw bot aan te sturen. 90% van de tijd doet die namelijk niks en in windows of tijdens een spelletje is het zegmaar vrij lastig dat al je vram en een groot deel van het ram constant gereserveerd is.

Start llama.cpp eens met --no-mmap. mmap zorgt er namelijk voor dat een kopie van het model in zowel Vram als Ram wordt geladen.

[DeNachtwacht]

Deepflame schreef op maandag 6 juli 2026 @ 15:36:
[...]

Hey, dat was grotendeels zelf getypt! :') Alleen een d/t pass laten doen door ChatGPT want ondanks de ijverige pogingen van mijn docenten heb ik dat nooit goed onder de knie gekregen.


[...]

Hm, bij mij word het geheugen wel vrijgegeven na een paar minuten, welke versie van llama.cpp draai jij? Zal wel een recente zijn, aangezien je tot nu toe altijd met ollama hebt gewerkt. Maar volgens de docs zou dat gewoon pas in moeten laden bij gebruik. En dat gedrag zie ik hier ook, niets laad automatisch in totdat ik het aanklik in de webinterface om in te laden.

Is het mogelijk dat OpenClaw direct dat inladen forceert omdat je agent dat model nodig heeft?

Oh en 64GB op je 5090 kan natuurlijk niet.

1. Dingen als "De magische houd-niet-alles-in-geheugen setting is" zijn echt Ai taal, en dat hele stukje tekst gaat zo verder, sorry
2. Nee, het gaat al fout bij llama.cpp starten zonder dat ik uberhaupt een server gestart ben. Ik voer exact dat commando uit wat jij invoert en vervolgens zit het vram en ddr direct overal vol.
3. Dat 64GB is wat windows taakbeheer zegt zodra je gaat offloaden naar ram.

[DeNachtwacht]

Felicia schreef op maandag 6 juli 2026 @ 16:00:
[...]

Start llama.cpp eens met --no-mmap. mmap zorgt er namelijk voor dat een kopie van het model in zowel Vram als Ram wordt geladen.

Dit zorgt er inderdaad voor dat het geheugen nu niet meer zo bizar vol geladen wordt, dank . Maar helaas zoals verwacht gaat het met het vram nog niet goed. Binnenkort nog eens verder induiken, want vooralsnog doet ollama dat soort dingen toch nog wel lekkerder. Je hoeft nergens over na te denken en het werkt gewoon. Aangezien OpenClaw van zichzelf al een aardig tweakproject is, is het eigenlijk wel lekker dat ik me dan over ollama geen zorgen hoef te maken, dat het dan iets trager is neem ik dan wel op de koop toe.

[Deepflame]

DeNachtwacht schreef op maandag 6 juli 2026 @ 16:51:
[...]

1. Dingen als "De magische houd-niet-alles-in-geheugen setting is" zijn echt Ai taal, en dat hele stukje tekst gaat zo verder, sorry
2. Nee, het gaat al fout bij llama.cpp starten zonder dat ik uberhaupt een server gestart ben. Ik voer exact dat commando uit wat jij invoert en vervolgens zit het vram en ddr direct overal vol.
3. Dat 64GB is wat windows taakbeheer zegt zodra je gaat offloaden naar ram.

Blijft het ook vol, of geeft ie het na 300 seconden weer vrij?

[ Voor 17% gewijzigd door Deepflame op 06-07-2026 17:54 ]

[DeNachtwacht]

Hij wordt idd wel netjes na 5 minuten geleegd ja. Het is denk ik puur ergens een setting vinden dat hij zodra hij wordt opgestart (met de pc) niet direct het taalmodel gaat inladen, maar dat pas gaat doen als deze voor het eerst wordt aangevraagd.

[Deepflame]

Misschien niet direct het model meegeven met de CLI, maar het model configureren in de models.ini file?

[lariekoek]

DeNachtwacht schreef op maandag 6 juli 2026 @ 10:21:
[...]

Je mag het even vriendelijker verwoorden volgende keer.

Je eerste claim breng je alsof AI allemaal heel goed te doen is met de CPU, maar vertelt er niet bij dat dat met modellen is die een andere opzet en objectief mindere kwaliteit hebben. Juist met jouw toon van "ik zal met iedereen hier even een briljant idee komen delen" is dat eruit laten m.i. gewoon onvolledig en als je daar dan netjes op gewezen wordt ga je de loopgraven in i.p.v. erkennen dat dat inderdaad wel een belangrijke kanttekening is.

Maar goed, het punt is wel gemaakt laten we dit verder houden bij wat het is.

Pas je eigen les toe. Kwam een hardstijke neutrale tip geven, heb geen behoefte aan dat heen en weer van woorden verdraaien en achterlijke aannames. Vooral het er bij verzinnen en anderen afkraken is men hier goed in.
Zegt steevast meer over de lezer dan iets anders.
Herinner plots waarom Tweakers forums op sterven na dood zijn.

[ Voor 6% gewijzigd door lariekoek op 06-07-2026 19:23 ]

[Felicia]

Deepflame schreef op maandag 6 juli 2026 @ 18:53:
Misschien niet direct het model meegeven met de CLI, maar het model configureren in de models.ini file?

Daarom heb ik bij die van mij gewoon een call naar de API die Hoi zegt en 1 token terug verwacht, doet bijna niets met de performance maar model blijft wel netjes in het geheugen. (bij die van mij lijkt de power saving van de GPU de oorzaak, die gaat na 30s al afschalen ongeacht wat ik qua powersaving instel)

DeNachtwacht schreef op maandag 6 juli 2026 @ 17:07:
[...]

Dit zorgt er inderdaad voor dat het geheugen nu niet meer zo bizar vol geladen wordt, dank . Maar helaas zoals verwacht gaat het met het vram nog niet goed. Binnenkort nog eens verder induiken, want vooralsnog doet ollama dat soort dingen toch nog wel lekkerder. Je hoeft nergens over na te denken en het werkt gewoon. Aangezien OpenClaw van zichzelf al een aardig tweakproject is, is het eigenlijk wel lekker dat ik me dan over ollama geen zorgen hoef te maken, dat het dan iets trager is neem ik dan wel op de koop toe.

Je zou ook even kunnen kijken of je met LM Studio vooruit kan, die is ook net zo makkelijk maar maakt wel gebruik van llama.cpp als backend. En, die kan ook gewoon server draaien dus in dat opzicht geen verschil met Ollama en llama.cpp.

[DeNachtwacht]

Ik zal er eens naar kijken, net als vllm... uiteindelijk ook goed om te leren hoe die programma's werken. Maar op zich voldoet ollama voor dit gebruik dus ook wel, het werkt dus dan vind ik het misschien voor nu wel even goed

[Deepflame]

Felicia schreef op maandag 6 juli 2026 @ 19:36:
[...]

Daarom heb ik bij die van mij gewoon een call naar de API die Hoi zegt en 1 token terug verwacht, doet bijna niets met de performance maar model blijft wel netjes in het geheugen. (bij die van mij lijkt de power saving van de GPU de oorzaak, die gaat na 30s al afschalen ongeacht wat ik qua powersaving instel)


[...]

Bij mijn blijft Qwen 3.6 27B gewoon braaf altijd ingeladen, maar ik heb ook een hoop automation die hem ook continu gebruikt voor verschillende kleine taakjes, dus dat helpt ook mee denk ik. :-) Ik weet niet zeker of ie in geheugen blijft uit eigen initiatief, of omdat ik er een heel harness omheen heb geklust.

Overigens is het niet erg om je GPU in powersaving te laten gaan, GPU schakelt daar snel genoeg weer uit, zolang het model maar in het geheugen blijft is dat meestal gewoon heel vlot weer actief, en bespaart het je behoorlijk wat stroom.

[Felicia]

Deepflame schreef op maandag 6 juli 2026 @ 19:53:
[...]

Overigens is het niet erg om je GPU in powersaving te laten gaan, GPU schakelt daar snel genoeg weer uit, zolang het model maar in het geheugen blijft is dat meestal gewoon heel vlot weer actief, en bespaart het je behoorlijk wat stroom.

True, ware het niet dat die van mij te pas en te onpas vastloopt en reboot als de GPU uit power saving komt. Lijkt nog een stukje onvolwassenheid van de Intel drivers.

[Deepflame]

Felicia schreef op maandag 6 juli 2026 @ 20:13:
[...]

True, ware het niet dat die van mij te pas en te onpas vastloopt en reboot als de GPU uit power saving komt. Lijkt nog een stukje onvolwassenheid van de Intel drivers.

Ah, ja, dat is knap irritant. x) En ik dacht dat mijn RX 6700 XT met gehackte ROCm drivers vervelend was om mee te werken.

[CSB]

Misschien iemand dit mij hier wat inzichten in kan verschaffen. Ik werk ook met Qwen3.6 35B A35 omdat ik een 8GB VRAM gpu heb (RX6650XT) maar ik loop met name tegen de context aan. Als ik een beetje snelheid wil hebben (want let's face it, 30 token/s is wel echt het minimale voor agentic use) probeer ik mijn kostbare VRAM zoveel mogelijk te benutten voor rekenkracht. Waar ik nat op ga is de context. Die blijft ook alleen maar groeien naar mate je meer aan je sessie toevoegd. Is er nou niet een methode om de context to "offloaden" naar RAM ofzo? Ik weet het, lagere quants nemen of zelfs turbo of rotorquant, maar dat zit nog niet in de mainbranch van llama.cpp. (ik kan helaas de fork van TheTom niet gebruiken want die ondersteunt mijn GPU niet)

Dus: wie heeft hier de gouden tip?

[DeNachtwacht]

Ik ben inderdaad bang dat de gouden tip inderdaad toch turboquant is. Wat voor nu nog een alternatief kan zijn is hem op een relatief kleine max context zetten die voor agentic werken nog wel genoeg is, denk dan aan 64K. Daarmee kun je de groei en dus snelheidsverlies iig nog enigszins beperken.

En dat offloaden naar ram is overigens precies waardoor het trager wordt; omdat steeds grotere delen van je werk op het relatief trage ram ipv snellere vram worden gedaan.

[Felicia]

CSB schreef op dinsdag 7 juli 2026 @ 19:46:
Misschien iemand dit mij hier wat inzichten in kan verschaffen. Ik werk ook met Qwen3.6 35B A35 omdat ik een 8GB VRAM gpu heb (RX6650XT) maar ik loop met name tegen de context aan. Als ik een beetje snelheid wil hebben (want let's face it, 30 token/s is wel echt het minimale voor agentic use) probeer ik mijn kostbare VRAM zoveel mogelijk te benutten voor rekenkracht. Waar ik nat op ga is de context. Die blijft ook alleen maar groeien naar mate je meer aan je sessie toevoegd. Is er nou niet een methode om de context to "offloaden" naar RAM ofzo? Ik weet het, lagere quants nemen of zelfs turbo of rotorquant, maar dat zit nog niet in de mainbranch van llama.cpp. (ik kan helaas de fork van TheTom niet gebruiken want die ondersteunt mijn GPU niet)

Dus: wie heeft hier de gouden tip?

Kijk eens naar de Moe-cpu setting. Daarmee kon ik met het GPT-OSS120b op een 24GB GPU toch nog zo'n 40 tokens/sec halen. Ligt aan je overall systeem natuurlijk maar KV-cache op GPU lijkt meer performance te behouden dan moe-weights in Vram.

[DeNachtwacht]

Ik zat nog te denken, je kan bij het starten sowieso eens beginnen met opgeven van deze parameters:

>>   --cache-type-k q4_0 `
>>   --cache-type-v q4_0 `

De cache wordt er dan fors kleiner van en ook minder accuraat, maar je kan eens zien in hoeverre het kwaliteitsverlies opweegt tegen de snelheidswinst

[ Voor 8% gewijzigd door DeNachtwacht op 07-07-2026 21:48 ]

[Felicia]

DeNachtwacht schreef op dinsdag 7 juli 2026 @ 21:44:
Ik zat nog te denken, je kan bij het starten sowieso eens beginnen met opgeven van deze parameters:

>>   --cache-type-k q4_0 `
>>   --cache-type-v q4_0 `

De cache wordt er dan fors kleiner van en ook minder accuraat, maar je kan eens zien in hoeverre het kwaliteitsverlies opweegt tegen de snelheidswinst

Dat kan wel zorgen dat KV quantization op de CPU wordt afgewenteld, dat gebeurt bij mijn Intel Arc dus

[DeNachtwacht]

@Felicia wellicht is dat ook nog te forceren met iets als -ngl 999 (forceer zoveel mogelijk GPU gebruik) en dus een kleinere max context (-c 64000 oid).

@CSB ik zou het toch ook eens proberen met Ollama. Zie hierboven over mijn ervaring dat het misschien niet 100% van de snelheid biedt die je met llama.cpp kan krijgen als alles goed is ingesteld, maar het biedt bij mij iig wel gebruiksgemak dat veel zaken automatisch beter gaan. Misschien is dit er wel 1 van.

[ Voor 9% gewijzigd door DeNachtwacht op 07-07-2026 22:02 ]

[Deepflame]

CSB schreef op dinsdag 7 juli 2026 @ 19:46:
Misschien iemand dit mij hier wat inzichten in kan verschaffen. Ik werk ook met Qwen3.6 35B A35 omdat ik een 8GB VRAM gpu heb (RX6650XT) maar ik loop met name tegen de context aan. Als ik een beetje snelheid wil hebben (want let's face it, 30 token/s is wel echt het minimale voor agentic use) probeer ik mijn kostbare VRAM zoveel mogelijk te benutten voor rekenkracht. Waar ik nat op ga is de context. Die blijft ook alleen maar groeien naar mate je meer aan je sessie toevoegd. Is er nou niet een methode om de context to "offloaden" naar RAM ofzo? Ik weet het, lagere quants nemen of zelfs turbo of rotorquant, maar dat zit nog niet in de mainbranch van llama.cpp. (ik kan helaas de fork van TheTom niet gebruiken want die ondersteunt mijn GPU niet)

Dus: wie heeft hier de gouden tip?

Check dit filmpje, deze had wel een paar goede tips ook om modellen te tunen, en van daaruit ben ik ook echt in het local LLMs tunen terecht gekomen. YouTube: Running a 35B AI Model on 6GB VRAM, FAST (llama.cpp Guide) (Hij heeft overigens nog wel meer leuke tips voor setups die niet het model in z'n geheel in VRAM kunnen zetten,

De KV cache blijft wel een dingetje. Als je het aandurft kan je een frontier model vragen om TheTom TurboQuant voor je GPU te proberen te laten fixen. Kost je wat tokens, maar als dat lukt dan is dat een eenmalige investering.

Ik heb GPT-5.5 zo ooit eens lokaal TheTom/TQ laten mergen met Atomic llama omdat in het begin TheTom's TQ branch Gemma 4 niet ondersteunde (ondertussen wel).

Ik weet niet hoe dicht de RX 6650 XT ligt op de RX 6700 XT (die heb ik namelijk) maar daar heb ik TheTom/TQ wel op aan de praat gekregen. Ik moet het wel opstarten met een speciale environment variable:
HSA_OVERRIDE_GFX_VERSION=10.3.0

Als ik dat niet doe, dan crashed het direct, maar met die setting forceert ie iets in de AMD drivers en dan werkt het wel.

[CSB]

Dan voor de tips allen. Ik heb Inderdaad mijn KV caches op q4 staan, dat is acceptabel. Ik heb de video van Codacus al eens gezien, hij heeft vaak goede inzichten. Ik heb daarmee mijn setup wat kunnen finetunen.

@Deepflame Ik heb diezelfde override in mijn docker compose staan (draai llama.cpp via docker) maar wat Gemini mij kon vertellen bij het proberen TheTom's fork te draaien is dat wellicht de Navi23 versie van deze GPU bepaalde instructies niet heeft, die de Navi22 wel heeft. TheTom heeft deze specifieke instructies in zijn build hardcoded, waardoor het bij mij crasht.

Of Gemini nu hallucineert of dat het klopt, dat weet ik niet, maar na weer een paar uur k*tten om dit werkend te krijgen was ik er wel klaar mee.

[CSB]

DeNachtwacht schreef op dinsdag 7 juli 2026 @ 21:56:

@CSB ik zou het toch ook eens proberen met Ollama. Zie hierboven over mijn ervaring dat het misschien niet 100% van de snelheid biedt die je met llama.cpp kan krijgen als alles goed is ingesteld, maar het biedt bij mij iig wel gebruiksgemak dat veel zaken automatisch beter gaan. Misschien is dit er wel 1 van.

Ik ben juist van Ollama naar Llama.cpp overgestapt omdat ik dan veel meer kan finetunen. Ik kreeg mijn MoE model namelijk niet op 30+ token/s draaiend middels Ollama.
Feit blijft wel dat Ollama inderdaad een stuk "vriendelijker" is om te configureren dan Llama.cpp.

Ik heb overigens nu 2 modellen draaien die ik om-en-om draai; de 35b MoE van Qwen en de 9B dense voor agentic, waar ik net aan 64k context uit kan persen voor Hermes. Het is echter puur om mee te stoeien op dit moment. Het model zelf is niet "slim" genoeg en verzuipt vaak in zijn eigen denken, wat het MoE model veel minder heeft.

[DeNachtwacht]

Daarom zou ik dus eens kijken of een INT4 versie van de 35B MoE wat meer ruimte / snelheid geeft.

[Deepflame]

CSB schreef op woensdag 8 juli 2026 @ 12:10:
Dan voor de tips allen. Ik heb Inderdaad mijn KV caches op q4 staan, dat is acceptabel. Ik heb de video van Codacus al eens gezien, hij heeft vaak goede inzichten. Ik heb daarmee mijn setup wat kunnen finetunen.

@Deepflame Ik heb diezelfde override in mijn docker compose staan (draai llama.cpp via docker) maar wat Gemini mij kon vertellen bij het proberen TheTom's fork te draaien is dat wellicht de Navi23 versie van deze GPU bepaalde instructies niet heeft, die de Navi22 wel heeft. TheTom heeft deze specifieke instructies in zijn build hardcoded, waardoor het bij mij crasht.

Of Gemini nu hallucineert of dat het klopt, dat weet ik niet, maar na weer een paar uur k*tten om dit werkend te krijgen was ik er wel klaar mee.

Ja het heeft voor mij de eerste keer ook een avond of twee gekost voordat ik het functionerend had, maar ik had wel als voordeel dat ik mijn OpenClaw agent gewoon z'n gang heb kunnen laten gaan, dus die heeft heel wat trial-and-error voor me uit handen genomen. Die heeft denk ik 2 uur zitten itereren terwijl ik een film keek.

Ik heb mijn Claw eens gevraagd om voor je naar de code van TheTom/TurboQuant te kijken. Die beweert dat het wel te doen zou moeten zijn, en had geen Navi22 specifieke instructies gespot, maar je moet je binaries wel heel nauwkeurig compilen.

Ik verwacht dat Gemini je dezelfde suggesties heeft gegeven, maar voor het geval dat er toch iets nieuws staat, dit is wat mijn agent zei (let wel, dit is een letterlijke AI copy-paste):

I’d give them a two-path checklist, because the important part is consistency between what ROCm thinks the card is and what the binary was built for.

First try the native path:
cmake -B build-rx6650xt \
-DGGML_HIP=ON \
-DCMAKE_HIP_ARCHITECTURES=gfx1032 \
-DCMAKE_BUILD_TYPE=Release
cmake --build build-rx6650xt -j"$(nproc)"

Then run it normally, no override. RX 6650 XT is gfx1032, so that is the honest target.

If that fails in ROCm consumer-card fashion, try the spoofed path:
cmake -B build-rx6650xt-gfx1030 \
-DGGML_HIP=ON \
-DCMAKE_HIP_ARCHITECTURES=gfx1030 \
-DCMAKE_BUILD_TYPE=Release
cmake --build build-rx6650xt-gfx1030 -j"$(nproc)"

And run with:
HSA_OVERRIDE_GFX_VERSION=10.3.0 ./build-rx6650xt-gfx1030/bin/llama-cli ...

The rule of thumb:
gfx1032 build → no override.
gfx1030 build → HSA_OVERRIDE_GFX_VERSION=10.3.0.

Also: always use a fresh build directory. CMake caches GPU target choices, and stale ROCm builds are very good at pretending to be new builds while quietly lying through their tiny little teeth.

[CSB]

Ik heb je Claw advies eens opgevolgd en een aantal zaken geprobeerd. Toch komt het erop neer dat mijn specifieke GPU drivers mist in Ubuntu, waardoor ik die override moet gebruiken. Ik heb geprobeerd een eigen image to compilen op Ubuntu 22 en 24, beiden met specifiek support voor de gfx1032 architectuur van mijn RX6650XT. Bij het starten van de container crasht de boel door het ontbreken van de gfx1032 Tensile drivers.

Het lijkt erop dat Turboquant voor mijn systeem niet gaat werken.

[Liegebeest]

Ik ga er dan toch aan geloven: naast veel theoretische studies rondom AI compliance, en een hands-on cursus over AI security heb ik nu toch een eigen sandbox nodig. Ik blijf bij mijn weigering om AI/LLMs voor mijn eigen bedrijf in te zetten, maar ik heb onze beleidsdocumenten nu aangepast zodat er in elk geval ruimte is voor research en studie, in een afzonderlijke sandbox-omgeving.

Voor een aankomende hands-on workshop AI-assisted coding wel voor één maand Claude Pro genomen, maar dat is alleen om te overbruggen tot m'n lokale sandbox klaar is.

'k Heb meerdere dingen overwogen: Mac Studio M3 Ultra, DGX Spark, een SFF met Ryzen AIMax (zoals de GMKTec), of natuurlijk gewoon een 3090/4090/5090 in een dikke bak.

Qua verhoudingen tussen kosten en prestaties vond ik die het allemaal niet echt, dus ik heb een middenweg: ik dupliceer de build van Donato Capitella, met niet twee, maar één R9700. Later kan die tweede er alsnog in, als het nodig is en het budget is er. Build list bij Alternate. Is dit een fantastisch systeem? Nee, vast niet. Maar voor het experimenteren met lokale RAG, coding assistance en meer, voor leer en pentest-doeleinden vast een heel net systeem.

[DeNachtwacht]

@Liegebeest mooie basis inderdaad en die opzet zorgt wel voor lekkere hoeveelheid snel vram.

Paar overwegingen / suggesties
- Hoewel ROCm steeds betere support krijgt is nvidia/cuda wel industry standard, als het puur voor leren / experimenteren is en een snellere "it just works" setup, zou ik dat wel aanraden. Snel vram is leuk, maar het begrenst door software support wel welke modellen je kan draaien bijv.
- een 9800X3D is behoorlijk fors geprijsd en de CPU doet bij AI vrij weinig. Kun je dus best bij een 9700X o.i.d. houden
- dat moederbord is behoorlijk fors geprijsd, volgens mij kom je ook al prima uit met een uitvoering: ASUS TUF Gaming B850-PLUS WIFI waarop je 1x een PCIe 5.0 16x hebt en 1x een PCIe 4.0 16x.

[Deepflame]

Ik sluit me aan bij DeNachtwacht, voor minder geld kan je ook 2x RTX 5060 kopen met 16gb, kom je ook aan 32gb, maar zit je niet met ROCm gezeur.

[Liegebeest]

DeNachtwacht schreef op donderdag 9 juli 2026 @ 19:33:
@Liegebeest mooie basis inderdaad en die opzet zorgt wel voor lekkere hoeveelheid snel vram.

Paar overwegingen / suggesties
- Hoewel ROCm steeds betere support krijgt is nvidia/cuda wel industry standard, als het puur voor leren / experimenteren is en een snellere "it just works" setup, zou ik dat wel aanraden. Snel vram is leuk, maar het begrenst door software support wel welke modellen je kan draaien bijv.
- een 9800X3D is behoorlijk fors geprijsd en de CPU doet bij AI vrij weinig. Kun je dus best bij een 9700X o.i.d. houden
- dat moederbord is behoorlijk fors geprijsd, volgens mij kom je ook al prima uit met een uitvoering: ASUS TUF Gaming B850-PLUS WIFI waarop je 1x een PCIe 5.0 16x hebt en 1x een PCIe 4.0 16x.

Crap, die ASUS TUF had ik over het hoofd gezien, ik had wel gekeken naar andere opties met 2x een 16x. Die pikte ik er bij Alternate helaas niet gauw uit; da's mijn verlies. Ik heb het bij deze gehouden om inderdaad wel ruimte over te houden voor een tweede r9700 zodat ik op termijn 64GB heb voor model + context en cache.

De CPU heb ik me inderdaad niet goed genoeg in verdiept. De bestelling is helaas al de deur uit, dus aanpassen zit er niet zomaar meer in zonder retourprocedure. Vooralsnog houd ik het gewoon hier bij.

Bedankt voor jullie input! Altijd handig om meer bij te leren, ook al is het al iets te laat.

Één verschil dat ik niet weg wil cijferen: een RTX 5090 vreet het dubbele als één zo'n r9700. Zelfs met twee r9700 zou ik nog onder het vermogen van één 5090 zitten. Ja, die laatste is alsnog veel sneller (want sneller VRAM), maar dit is de middenweg die ik wel zag zitten.

[ Voor 11% gewijzigd door Liegebeest op 09-07-2026 20:09 ]

[ocf81]

Het is al een tijdje zo dat ROCm in de meeste gevallen niet echt een obstakel is. Soms werkt het inderdaad niet, maar qua prijs/prestatie-verhouding is AMD heel interessant voor inferentie.

[DeNachtwacht]

Zie het zo, uiteindelijk koop je hiermee natuurlijk een prima systeem en de performance is natuurlijk ook top. Alsnog iets waar ik jaloers op ben

[Liegebeest]

DeNachtwacht schreef op donderdag 9 juli 2026 @ 20:05:
Zie het zo, uiteindelijk koop je hiermee natuurlijk een prima systeem en de performance is natuurlijk ook top. Alsnog iets waar ik jaloers op ben

Ik heb de mazzel een zelfstandige te zijn, waardoor het een te-verantwoorden aanschaf is. Ik denk niet dat ik het geld uit ga halen, maar het helpt me wel om aan mijn eigen IT- en inkoop-beleid te voldoen: geen SaaS LLM, alles on-prem. Minder performance voor meer geld, dat is de bedrijfskundige afweging die ik heb gemaakt.

[Deepflame]

Liegebeest schreef op donderdag 9 juli 2026 @ 20:11:
[...]

Ik heb de mazzel een zelfstandige te zijn, waardoor het een te-verantwoorden aanschaf is. Ik denk niet dat ik het geld uit ga halen, maar het helpt me wel om aan mijn eigen IT- en inkoop-beleid te voldoen: geen SaaS LLM, alles on-prem. Minder performance voor meer geld, dat is de bedrijfskundige afweging die ik heb gemaakt.

Ik maak zelf gebruik van een combinatie van GPT-5.5 en lokale LLM.

GPT-5.5 doet het technische ontwerp, lokale LLM (Qwen 3.6 of nu eigenlijk Agents A1) doet de implementatie, en dan doet GPT-5.5 de eerste code review, voordat ik er naar kijk.

Op die manier bespaar ik nogal op mijn GPT gebruik, kon mijn subscription halveren.

[Tarkin]

Deepflame schreef op donderdag 9 juli 2026 @ 21:25:
[...]

Ik maak zelf gebruik van een combinatie van GPT-5.5 en lokale LLM.

GPT-5.5 doet het technische ontwerp, lokale LLM (Qwen 3.6 of nu eigenlijk Agents A1) doet de implementatie, en dan doet GPT-5.5 de eerste code review, voordat ik er naar kijk.

Op die manier bespaar ik nogal op mijn GPT gebruik, kon mijn subscription halveren.

Hoe regel je dat dan in je ide? Ik gebruik momenteel intellij en wil ook naar zo een soort set-up kijken. Setup, Controle + security checks door een Claude en de daadwerkelijke implementatie, testen,... door een lokaal draaiend model

[Liegebeest]

Tarkin schreef op donderdag 9 juli 2026 @ 22:03:
[...]

Hoe regel je dat dan in je ide? Ik gebruik momenteel intellij en wil ook naar zo een soort set-up kijken. Setup, Controle + security checks door een Claude en de daadwerkelijke implementatie, testen,... door een lokaal draaiend model

Volgens mij is dit wel een mooie uitleg om mee te beginnen, als je Claude Code gebruikt. Ga ik ook naar kijken, om mee te beginnen.

https://unsloth.ai/docs/basics/claude-code

[ Voor 14% gewijzigd door Liegebeest op 09-07-2026 22:09 ]

[DeNachtwacht]

Tarkin schreef op donderdag 9 juli 2026 @ 22:03:
[...]

Hoe regel je dat dan in je ide? Ik gebruik momenteel intellij en wil ook naar zo een soort set-up kijken. Setup, Controle + security checks door een Claude en de daadwerkelijke implementatie, testen,... door een lokaal draaiend model

Ik ben zelf geen die-hard programmeur maar rommel een klein beetje bij als experiment met lokale modellen... met Codex kun je werken via ollama. Maar je kan daar ook werken met je cloud abonnement. Dus dan ben je er toch volgens mij?

[Tarkin]

Morgen eens kijken hoe ik het kan koppelen. Ben ook geen diehard programmeur (meer) maar met AI is het gewoon te leuk om je ideeën op een avond uit te werken.

Deze avond as we speak heb ik al een mini straat app gemaakt waar ik mijn eigen routes op een kaart inlaad met filters op jaar en type (fiets, wandel, other).


Ja er zijn veel tools. Maar het simpele: alles op 1 kaart tonen, zijn ze toch bizonder slecht in. Al helemaal als je de betaalde versie niet neemt. Heb het nu zelf maar gemaakt

[Deepflame]

Tarkin schreef op donderdag 9 juli 2026 @ 22:03:
[...]

Hoe regel je dat dan in je ide? Ik gebruik momenteel intellij en wil ook naar zo een soort set-up kijken. Setup, Controle + security checks door een Claude en de daadwerkelijke implementatie, testen,... door een lokaal draaiend model

Ik zet hem op GPT-5.5, ik laat GPT-5.5 het technisch ontwerp uitschrijven. Vervolgens wissel ik naar lokaal model en laat ik die het werk uitvoeren. Daarna wissel ik terug naar GPT-5.5 en laat ik die het werk reviewen. Is gewoon een paar model swaps.

[Vintelligence]

Is er iemand die mij met de Continue plugin zou kunnen helpen in Visual Code?

Heb via LM Studio Qwen Coder Next draaien en heb de Continue plugin hier aan gelinkt. Chatten in de Continue plugin in Visual Code werkt perfect. Het enige waar ik tegenaan blijf lopen is dat in mijn chat gevraagd blijft worden om "Run Terminal Command" goed te keuren. Dit terwijl ik in de Continue settings heb aangegeven dat dit automatisch mag (Continue settings/Tools/run_terminal_command staat op Automatic).

Ook heb ik het voor de zekerheid toegevoegd aan mijn rules.md:

## Automatische Acties

- Zonder vragen te stellen, voer de bovenstaande stappen uit tot het doel bereikt is. Dus geen melding tonen of ik Run Terminal Command wil accepteren

Ik heb gevalideerd dat deze rules actief zijn in de Continue instellingen, dat zijn ze.

Iemand die hier ervaring mee heeft?

[R.G]

Vintelligence schreef op zaterdag 11 juli 2026 @ 00:03:
Is er iemand die mij met de Continue plugin zou kunnen helpen in Visual Code?

Heb via LM Studio Qwen Coder Next draaien en heb de Continue plugin hier aan gelinkt. Chatten in de Continue plugin in Visual Code werkt perfect. Het enige waar ik tegenaan blijf lopen is dat in mijn chat gevraagd blijft worden om "Run Terminal Command" goed te keuren. Dit terwijl ik in de Continue settings heb aangegeven dat dit automatisch mag (Continue settings/Tools/run_terminal_command staat op Automatic).

Ook heb ik het voor de zekerheid toegevoegd aan mijn rules.md:

## Automatische Acties

- Zonder vragen te stellen, voer de bovenstaande stappen uit tot het doel bereikt is. Dus geen melding tonen of ik Run Terminal Command wil accepteren

Ik heb gevalideerd dat deze rules actief zijn in de Continue instellingen, dat zijn ze.

Iemand die hier ervaring mee heeft?

Loop je niet tegen het probleem aan dat continue maar een paar files indexeeert en gebruikt.


Probeer eens een c++ project van meer dan 30+ files dan faalt comtimue grandioos?

[Vintelligence]

R.G schreef op zondag 12 juli 2026 @ 05:08:
[...]

Loop je niet tegen het probleem aan dat continue maar een paar files indexeeert en gebruikt.


Probeer eens een c++ project van meer dan 30+ files dan faalt comtimue grandioos?

Nee geen last van. Heb in mijn rules.md ook staan hoe de structuur eruit ziet en waarvoor welk bestand dient. Werk wel met een klein project.

[Ruitenwisser]

Een algemene vraag. Hoe houden jullie jullie zelf up to date met deze enorme snelheid aan ontwikkeling? Ik heb nu llama.cpp en openwebui draaien op mijn server en op mijn laptop heb ik Pi geïnstalleerd en ben daar wat mee aan het klooien en proberen de md files, skills en packages onder de knie te krijgen. Maar als ik de verschillende subreddits een beetje meevolgt zie ik daar jan en alle man hun tools op github smijten en promoten waardoor ik het bos door de bomen niet meer kan zien. Ik ben een beginneling, een noob, maar er is zoveel informatie dat ik precies niet goed weet wat nuttig is voor mij en wat niet. Beetje zoals te veel keuze in de supermarkt dat je je keuze niet kan maken haha.
Kortom, kunnen jullie een goede guide aanraden waar je veel aan gehad hebt? Zijn er bepaalde benchmarks die je draait om functionaliteit, performantie en correctheid te testen? Ik zou graag Pi willen gebruiken om samen mee wat eigen projectjes te programmeren.

[Puff_Uncle]

Ruitenwisser schreef op dinsdag 14 juli 2026 @ 13:18:
Een algemene vraag. Hoe houden jullie jullie zelf up to date met deze enorme snelheid aan ontwikkeling? Ik heb nu llama.cpp en openwebui draaien op mijn server en op mijn laptop heb ik Pi geïnstalleerd en ben daar wat mee aan het klooien en proberen de md files, skills en packages onder de knie te krijgen. Maar als ik de verschillende subreddits een beetje meevolgt zie ik daar jan en alle man hun tools op github smijten en promoten waardoor ik het bos door de bomen niet meer kan zien. Ik ben een beginneling, een noob, maar er is zoveel informatie dat ik precies niet goed weet wat nuttig is voor mij en wat niet. Beetje zoals te veel keuze in de supermarkt dat je je keuze niet kan maken haha.
Kortom, kunnen jullie een goede guide aanraden waar je veel aan gehad hebt? Zijn er bepaalde benchmarks die je draait om functionaliteit, performantie en correctheid te testen? Ik zou graag Pi willen gebruiken om samen mee wat eigen projectjes te programmeren.

Ik vind het ook overweldigend, ik gebruik zelf Hermes en opencode. Vaak vind ik Youtube hier echt handig en dan limiteer ik mezelf ook tot bepaalde creators.
misschien kan je een PI agent maken hiervoor maken die bepaalde websites scrapt en jou up to date houd bijv 1 keer dagelijks1 keer.

[DeNachtwacht]

Ruitenwisser schreef op dinsdag 14 juli 2026 @ 13:18:
Een algemene vraag. Hoe houden jullie jullie zelf up to date met deze enorme snelheid aan ontwikkeling? Ik heb nu llama.cpp en openwebui draaien op mijn server en op mijn laptop heb ik Pi geïnstalleerd en ben daar wat mee aan het klooien en proberen de md files, skills en packages onder de knie te krijgen. Maar als ik de verschillende subreddits een beetje meevolgt zie ik daar jan en alle man hun tools op github smijten en promoten waardoor ik het bos door de bomen niet meer kan zien. Ik ben een beginneling, een noob, maar er is zoveel informatie dat ik precies niet goed weet wat nuttig is voor mij en wat niet. Beetje zoals te veel keuze in de supermarkt dat je je keuze niet kan maken haha.
Kortom, kunnen jullie een goede guide aanraden waar je veel aan gehad hebt? Zijn er bepaalde benchmarks die je draait om functionaliteit, performantie en correctheid te testen? Ik zou graag Pi willen gebruiken om samen mee wat eigen projectjes te programmeren.

Wat ik zelf gemerkt heb is dat ik om die reden teruggegaan ben naar Ollama. Ook die is het laatste jaar flink verbeterd, en de snelheidsverschillen met llama.cpp zijn zo groot niet meer. En het voordeel van ollama is dat geheugenmanagement en dat soort zaken automatisch gebeurt, het is veel meer een "it just works" server dan llama.cpp. Aangezien ik zelf het tweaken met OpenClaw wil doen, en niet óók constant met de runner wil prutsen, is dit voor mij nu de snelste weg.

Juist omdat de ontwikkelingen zo snel gaan. Als over 1-2 jaar alle ontwikkelingen er een beetje uit zijn loont het ongetwijfeld nog eens goed in llama.cpp te duiken om e.e.a. optimaler te gaan doen. Maar in een tijd waarin de modellen, runners en gevibecode "kijk mijn hippe fork!" varianten je om de oren vliegen houd ik het graag overzichtelijk. Met name al die gevibecode projecten moet je echt enorm oppassen: 1) vaak stopt na een paar maanden de vibecoder er alweer mee 2) al diverse keren zijn bewust of onbewust projecten gepubliceerd met veiligheidslekken erin 3) vaak is even goed naar llama.cpp zelf kijken net zo makkelijk als de gevibecode fork en is die helemaal niet nodig. 4) als de fork slecht onderhouden wordt (99% van de gevallen) heb je na de eerste llama.cpp update alweer iets dat op punten achterloopt of niet meer hetzelfde werkt

[ Voor 3% gewijzigd door DeNachtwacht op 14-07-2026 14:27 ]

[Deepflame]

Het gros van de projecten is inderdaad dikke rommel. Af en toe komt er iets bovenuit met een goed idee, en daar moet je maar net zin in hebben om mee bezig te gaan. Maar de meeste github projecten zijn slecht in elkaar gezette stukken software, geprogrammeerd door een AI die aangestuurd is door iemand die nog nooit eerder zelf een regel code heeft geschreven, zonder duidelijke, sterke product visie of plan, en dat zie je vervolgens meteen in de code (rommelig) en software (buggy in specifieke manieren).

Soms hebben ze goede ideeën, maar vaker dan niet kan je beter de kern van het idee pakken en daar zelf de meerwaarde uit destilleren.

Ik volg zelf een mix van TLDR (https://tldr.tech/ai), Hacker News (https://news.ycombinator.com), en wat ik af en toe per ongeluk voorbij zie komen in de OpenClaw community discord of op youtube. En verder gewoon lekker veel zelf prutsen en kritisch nadenken over waar mijn setup staat en wat ik er mee kan.

[Vintelligence]

Vintelligence schreef op zaterdag 11 juli 2026 @ 00:03:
Is er iemand die mij met de Continue plugin zou kunnen helpen in Visual Code?

Heb via LM Studio Qwen Coder Next draaien en heb de Continue plugin hier aan gelinkt. Chatten in de Continue plugin in Visual Code werkt perfect. Het enige waar ik tegenaan blijf lopen is dat in mijn chat gevraagd blijft worden om "Run Terminal Command" goed te keuren. Dit terwijl ik in de Continue settings heb aangegeven dat dit automatisch mag (Continue settings/Tools/run_terminal_command staat op Automatic).

Ook heb ik het voor de zekerheid toegevoegd aan mijn rules.md:

## Automatische Acties

- Zonder vragen te stellen, voer de bovenstaande stappen uit tot het doel bereikt is. Dus geen melding tonen of ik Run Terminal Command wil accepteren

Ik heb gevalideerd dat deze rules actief zijn in de Continue instellingen, dat zijn ze.

Iemand die hier ervaring mee heeft?

Excuses voor de herhaling. Zou iemand mij hiermee kunnen helpen? Iemand die ervaring heeft met de Continue extensie in Visual Code en lokaal een model draait?

[Ruitenwisser]

@DeNachtwacht Ik ben net overgeschakeld van ollama naar llama.cpp omdat ik er meer controle over had. Of toch zo voelde het toch aan. Context size, gpu layers, temperature, ... aanpassen -> is gewoon een vlaggetje veranderen. Met llama.cpp heb ik ook leren kijken naar de verbose logging zodat ik begon te weten wat er gaande was en gebeurde of waarom iets faalde. Maar eerlijk gezegd had ik me ook niet echt verdiept in ollama en wat het allemaal kon.

@Deepflame dank voor de TLDR link

[DeNachtwacht]

@Ruitenwisser klopt, het is een beetje een keus maken. Volle tweakmogelijkheden of toch het gemak dat je heel veel dingen niet in hoeft te stellen omdat automatisch naar de best passende settings wordt gezocht op basis van je systeem.

[Deepflame]

Het is net waar je naar op zoek bent.

Ik zelf ben van ollama naar llama overgestapt omdat ik juist wel graag loop te klooien, maar ik heb mijn AI op z'n eigen PC draaien (oude gaming PC) dus ik heb niet het probleem van Nachtwacht dat het geheugen van de AI vrij moet blijven tot gebruik, ik wil het juist wel 24/7 in het geheugen hebben.

[Ruitenwisser]

Ik vind het interessant om juist te weten wat er achter zit. Ik heb ook een oude PC staan waar llama.cpp op draait (Proxmox server in eigen LXC), het is momenteel de enige LXC die de GPU's gebruikt (Immich kan later nog aan bod komen maar ik ben er nog niet aan toe), dus zit ook niet echt met dat probleem. Ik had wel een FastAPI switcher programma laten schrijven om van model te kunnen wisselen en volledig uit het VRAM te halen buiten de LXC om maar sinds ik met argumenten ben beginnen spelen gebruik ik het eigenlijk niet meer en ssh ik naar de LXC.

[Ruitenwisser]

Vandaag deze extensie voor Pi tegengekomen om websearches uit te voeren: https://pi.dev/packages/pi-ketch-web-access

Werkt wel goed. Bij deze ook SearXNG leren kennen en ben direct ook aan het kijken om deze als LXC toe te voegen tot mijn server .

[ Voor 8% gewijzigd door Ruitenwisser op 15-07-2026 22:19 ]

[Bontje Blauw]

Vintelligence schreef op dinsdag 14 juli 2026 @ 17:01:
[...]

Excuses voor de herhaling. Zou iemand mij hiermee kunnen helpen? Iemand die ervaring heeft met de Continue extensie in Visual Code en lokaal een model draait?

VScode ontwikkelt zich heel snel momenteel. Wekelijkse updates.
Continue is minder relevant aan het worden, omdat VScode Chat al zo compleet aan het worden is en al bij default workspace / context bewust is.
Ik heb ook met Continue / Roo / Aider zitten prutsen, maar kreeg dat nooit helemaal vlekkeloos draaiend en dan mis ik de kennis om allerlei parameters te verfijnen in de agent/provider en VScode.

Ik test nu local LLM's met Command Palette -> Chat: Manage Language Models.
Klik Install Model Provider -> Extensions -> tag:"language-models"
Installeer bijv. Ollama.
Download modellen in terminal, bijvoorbeeld: Ollama pull gemma4:12b
Deze modellen komen dan automatisch in de Chat beschikbaar als modellen.
Dit is de meest klik en gaan methode en een goed startpunt. Kies eerst modellen die in je VRAM passen.
Met Developer: Show Chat Debug View kan je monitoren wat er op de achtergrond allemaal gebeurt.
Met ollama ps kan je zien welk mode Ollama werkelijk draait en hoeveel GPU / CPU hij gebruikt.

Je kan enorm veel met VScode Chat en VScode Agents.
Ik lees mij in op https://code.visualstudio.com/docs
Dat is altijd actueel en soms met een link naar een video turorial.

[ Voor 15% gewijzigd door Bontje Blauw op 16-07-2026 12:09 ]

[Ruitenwisser]

Gisteren het argument `--ctx-checkpoints` leren kennen. Deze staat standaard op 32 en zegt hoeveel checkpoints van de sessie die llama-server moet maken en bijhouden. Dit is goed bij het editen van eerdere antwoorden en bij het 'branchen' zodat hij niet telkens alles opnieuw moet berekenen. Met 32 en een oplopende grootte van checkpoints naargelang hoe meer context, werd llama-server gewoon 'gekilled' toen mijn RAM vol zat. Checkpoint groottes waren dan rond de 500-600MB en met maar 16GB in het systeem (12GB toegewezen aan de LXC), zat hij telkens al vlug tegen zijn limiet.

Momenteel heb ik het op 8 gezet met dat ik niet echt edit of branch en volgens mij wordt er ook gebruik gemaakt van system RAM bij het compacteren van de context en ik daar dus ook nog genoeg RAM voor vrij moet hebben.

[Vintelligence]

Bontje Blauw schreef op donderdag 16 juli 2026 @ 11:39:
[...]

VScode ontwikkelt zich heel snel momenteel. Wekelijkse updates.
Continue is minder relevant aan het worden, omdat VScode Chat al zo compleet aan het worden is en al bij default workspace / context bewust is.
Ik heb ook met Continue / Roo / Aider zitten prutsen, maar kreeg dat nooit helemaal vlekkeloos draaiend en dan mis ik de kennis om allerlei parameters te verfijnen in de agent/provider en VScode.

Ik test nu local LLM's met Command Palette -> Chat: Manage Language Models.
Klik Install Model Provider -> Extensions -> tag:"language-models"
Installeer bijv. Ollama.
Download modellen in terminal, bijvoorbeeld: Ollama pull gemma4:12b
Deze modellen komen dan automatisch in de Chat beschikbaar als modellen.
Dit is de meest klik en gaan methode en een goed startpunt. Kies eerst modellen die in je VRAM passen.
Met Developer: Show Chat Debug View kan je monitoren wat er op de achtergrond allemaal gebeurt.
Met ollama ps kan je zien welk mode Ollama werkelijk draait en hoeveel GPU / CPU hij gebruikt.

Je kan enorm veel met VScode Chat en VScode Agents.
Ik lees mij in op https://code.visualstudio.com/docs
Dat is altijd actueel en soms met een link naar een video turorial.

[Afbeelding]

[Afbeelding]

Dit lijkt inderdaad te werken qua auto approve. Dankjewel voor de tip en gebruik natuurlijk veel liever ingebouwde dingen in VS Code dan weer een extensie. Ik ga ermee aan de slag!

Overigens andere vraag, heb nu Ollama geinstalleerd op mijn Mac. Daar draaien MLX modellen beter op heb ik begrepen maar heb ook begrepen dat Ollama standaard GGUF modellen installeert. Klopt dat? En kan MLX in Ollama ook draaien of is dat niet mogelijk? En zo ja, hoe download ik dan die MLX versies? Dat zie ik op deze site er niet bij staan: https://ollama.com/search

[DeNachtwacht]

Vintelligence schreef op vrijdag 17 juli 2026 @ 12:09:
Klopt dat? En kan MLX in Ollama ook draaien of is dat niet mogelijk? En zo ja, hoe download ik dan die MLX versies? Dat zie ik op deze site er niet bij staan: https://ollama.com/search

Ja.

Vaak uploaden andere gebruikers andere versies van modellen (nvfp4, mlx et cetera). Je kan alles wat binnen ollama beschikbaar is hier vinden: https://ollama.com/library en je kan de benodigde terminalcode om het model te draaien er ook vinden. Ik weet niet welk model je zoekt, maar stel dat dat bananenLLM is, dan vind je daar alle beschikbare varianten en hopelijk dus ook een MLX. Zo nee, dan heb je even pech en is het wachten tot iemand deze beschikbaar maakt.

Als je het model in de ollama GUI niet kan vinden kun je heel simpel via de terminal

ollama run bananenLLM-mlx

typen, dan wordt dat specifieke model gedownload en staat hij er de volgende keer in ollama ook tussen.

Nu hopen dat er ooit iemand nog bananenLLM uitbrengt

[doldrums]

Voor de M line draait Ollama standaard met MLX tegenwoordig en als je modellen download vanuit Ollama zijn het ook meteen mlx versies van de modellen. Dat geldt precies zo voor ML Studio.

[Ruitenwisser]

Voor de fans van Qwen, versie 3.8 is op komst