Ervaringen met zelf gehoste AI assistenten

[CT]

Denk gewoon van huggingface?
Heb zelf net mn Qwen 3.6_Q8 vervangen met deze Qwen 3.8_Q8 en laad gewoon in en werkt perfect, niks kwa parameters te hoeven aan te passen in llama.cpp :-) nogsteeds rond de 60-80 tk/s.

Zal gedurende de week wel merken of het beter werkt dan 3.6 (wat ongeloogelijk is, als dat zo is, want 3.6 vond ik al eindeloos geweldig, erg veel software mee gemaakt :))

[ocf81]

Misschien wel interessant als je voor een bedrijf met lokale AI aan de slag gaat:

[pling]

DeNachtwacht schreef op zaterdag 15 augustus 2026 @ 10:49:
@Deepflame waar heb jij de Q6 vandaan?

Waarschijnlijk unsloth: unsloth/Qwen3.8-27B-GGUF · Hugging Face

[pling]

Ik heb er nu een kleine dagje gewerkt Qwen3.8 27B (6_K). Hij lijkt een stuk grondiger te werk te gaan. Het duurt allemaal flink langer, maar de resultaten zijn indrukwekkend. Het is mij niet helemaal duidelijk hoe het nu met MTP zit. Ik lees hier en daar berichten dat het 'out of the box' zou moeten werken.

Qwen3.8 - How to Run Locally | Unsloth Documentation:

Qwen3.8 GGUFs use Unsloth Dynamic V3.0 (preview) for SOTA quant performance. Thank you Qwen for day zero access. Unsloth quants also include:

• Developer Role Support for agentic tools like Codex
• MTP enabled for fast inference
• Tool calling: Improved parsing nested objects to make tools succeed more

Weet iemand hoe dat zit?

Ik kijk regelmatig naar dit kanaal: YouTube: Qwen 3.8 27B first tests - 16GB Local LLM setup Hij doet elke keer dezelfde tests. Qwen3.6 was eigenlijk al de beste (in zijn soort), maar 3.8 is het nu helemaal.

[Ozzi]

Ok, ik had mijn poging voor hetzelfde prompt met reasoning disabled uitgevoerd blijkbaar. Nu een nieuwe poging gedaan en na ca 32000 tokens reasoning, en daarna nog ca 28000 tokens voor de rest, heeft ie toch wel iets weekends gemaakt wat er best geinig uitziet en werkt.

Voor de liefhebber:
https://github.com/OscarD...owman-qwen3.8-27b-q6.html

[CT]

pling schreef op zaterdag 15 augustus 2026 @ 18:50:
Ik heb er nu een kleine dagje gewerkt Qwen3.8 27B (6_K). Hij lijkt een stuk grondiger te werk te gaan. Het duurt allemaal flink langer, maar de resultaten zijn indrukwekkend. Het is mij niet helemaal duidelijk hoe het nu met MTP zit. Ik lees hier en daar berichten dat het 'out of the box' zou moeten werken.

Qwen3.8 - How to Run Locally | Unsloth Documentation:


[...]

Weet iemand hoe dat zit?

Ik kijk regelmatig naar dit kanaal: YouTube: Qwen 3.8 27B first tests - 16GB Local LLM setup Hij doet elke keer dezelfde tests. Qwen3.6 was eigenlijk al de beste (in zijn soort), maar 3.8 is het nu helemaal.

Ja alle unsloth modellen werken met MTP optie enabled in llama.cpp, dus die layer zit er default bij. "Vroeger" was dit niet zo en had je een apart MTP model etc maar nu is het al aanwezig vanaf het begin vandaar de expliciete vermelding denk ik.

[pling]

Ozzi schreef op zaterdag 15 augustus 2026 @ 19:43:
Voor de liefhebber:
https://github.com/OscarD...owman-qwen3.8-27b-q6.html

Prachtig!

[DeNachtwacht]

Wie heeft een idee waarom het mij met llama.cpp niet lukt om met een RTX 5060 TI (cuda0) en RTX 5090 (cuda1) setup de Q6_K_XL te draaien zonder offloading naar het DDR geheugen?

Belangrijke kanttekening: ik wil de 256K context behouden, dus kv quants of een stap naar Q5 is een optie als dat nodig is, maar context verlagen niet.

.\llama.exe serve -m "Qwen3.8-27B-UD-Q6_K_XL.gguf" --device CUDA0,CUDA1 --tensor-split 1,2 --ctx-size 262144 --cache-type-k q4_0 --cache-type-v q4_0 -ngl 99 -fa on -b 512 -ub 128 --host 0.0.0.0 --port 8080

.\llama.exe serve -m "Qwen3.8-27B-UD-Q6_K_XL.gguf" --device CUDA0,CUDA1 --main-gpu 1 --tensor-split 1,2 --ctx-size 262144 --cache-type-k q8_0 --cache-type-v q8_0 -ngl 99 -fa on -b 512 -ub 128 --host 0.0.0.0 --port 8080

.\llama.exe serve -m "Qwen3.8-27B-UD-Q6_K_XL.gguf" --device CUDA0,CUDA1 --main-gpu 1 --tensor-split 1,2 -ngl 99 -fa on -b 512 -ub 128 --host 0.0.0.0 --port 8080

levert allemaal op dat er naar het ramgeheugen wordt geoffload en ik 25-28 tokens/sec krijg terwijl ik overal juichend lees dat Q6 op één 5090 al moet draaien.

Wat zie ik over het hoofd?

[Ozzi]

DeNachtwacht schreef op zondag 16 augustus 2026 @ 13:39:
Wie heeft een idee waarom het mij met llama.cpp niet lukt om met een RTX 5060 TI (cuda0) en RTX 5090 (cuda1) setup de Q6_K_XL te draaien zonder offloading naar het DDR geheugen?

Ik weet niet of je het nodig hebt, maar je kan nog proberen om

code:

--parallel 1

toe te voegen (of 2, standaard is meen ik 4). Nu heeft ie dus waarschijnlijk ook 4x 256k aan context. Wat ook nog kan helpen is om wat context compression toe te passen:
[code]--cache-type-k q8_0 --cache-type-v q8_0[/code]
Of anders q5_0 / q5_1 / q4_0 / q4_1. Bij mij zelf had minder als 8 negatieve impact.

[ Voor 1% gewijzigd door Ozzi op 16-08-2026 15:03 . Reden: kv was al op 4_0 :+ ]

[Deepflame]

DeNachtwacht schreef op zaterdag 15 augustus 2026 @ 10:49:
@Deepflame waar heb jij de Q6 vandaan?

Ja zoals de anderen zeiden, idd via huggingface, het Unsloth model. :-)

Ik heb een lokaal aangepaste versie van llama.cpp TheTom/TurboQuant draaien (zoals je al weet) waardoor ik mijn model op kan splitsen over CUDA en ROCm (moest ik een llama.cpp upstream bugfix voor importeren naar TheTom/TQ) waardoor ik genoeg VRAM heb om Q6 volledig in VRAM te draaien op mijn RTX 3090 (24 GB) en RX 6700 XT (12 GB) met een KV cache van 256k op turbo4/turbo3 KV cache quant.


Dit terzijde, ondertussen heb ik mijn clustertje van 3x RTX 3070 en 6x GTX 1070 ook draaiende. Plaatje bijgevoegd. Heb er een oude Kallax voor uit de woonkamer gehaald (vrouw ook blij, die wilde al jaren van dat ding af) en met mijn 3d printer wat custom GPU mounts gemaakt.



72 GB VRAM, heb er deze week mee met DeepSeek V4 Flash 0731 op zitten spelen. Heb DwarfStar 4 gepakt als basis inference engine, en loop daar nu aan te sleutelen om hem maar sneller te krijgen.

Stock DwarfStar 4 haalde ik ~4 tok/s mee, na mijn eerste optimalisatie heb ik nu een prefill van 30 tok/s en een decode van 8 tok/s, en ik ben nu bezig met een nieuw algoritme waarmee ik misschien wel de 16 tok/s aan kan tikken, met een beetje mazzel.

Daarna heb ik denk ik wel de grens bereikt van wat ik kan doen met zoveel oude GPUs. x)

Voor de nieuwsgierigen:
- Stroomverbruik: Als dat ding idle staat te staan verbruikt ie ongeveer 100W, als ik er op het moment actief inference op draai tikt ie de 500W aan.
- Model: Ik gebruik DeepSeek V4 Flash 0731 Q2_XSS (~81 GB)
- VRAM gebruik: Ongeveer 2/3de van het model past in mijn VRAM na KV Cache van 256k, CUDA buffers, etc.
- Geluidsniveau: Eigenlijk best stil, die 140mm fans draaien op half vermogen en houden het geheel op ongeveer 50-60c tijdens inference, 40c idle.
- Operating system is Ubuntu headless server
- Systeem is gebouwd op OCuLink adapters en kabels.
- Wat heeft me dit gekost: Mijn sanity, wat OCuLink apparatuur (€300), en 2 rollen ABS van een kilo. De grafische kaarten, voedingen, moederbord, RAM, etc. heb ik van de stort gered toen het bedrijf waar ik voor werkte sloot en IT alles naar de stort ging brengen.
- Wat heeft het me opgeleverd: Diepere kennis van hoe inference engines werken, en een apparaat waar ik met trots over kan praten. xD

[eheijnen]

@Deepflame
Wist nie dat ze bij IKEA ook al datacenter gerei verkopen...

[Deepflame]

eheijnen schreef op maandag 17 augustus 2026 @ 17:00:
@Deepflame
Wist nie dat ze bij IKEA ook al datacenter gerei verkopen...

IKEA spul is superhackable En een €50 kallax is een stuk goedkoper dan een rack van €500

[franssie]

eheijnen schreef op maandag 17 augustus 2026 @ 17:00:
@Deepflame
Wist nie dat ze bij IKEA ook al datacenter gerei verkopen...

De Lack tafels waren al jaren geliefd als 19" racks, niets nieuws

[pling]

DeNachtwacht schreef op zondag 16 augustus 2026 @ 13:39:
Wie heeft een idee waarom het mij met llama.cpp niet lukt om met een RTX 5060 TI (cuda0) en RTX 5090 (cuda1) setup de Q6_K_XL te draaien zonder offloading naar het DDR geheugen?

Wat zie ik over het hoofd?

Dit zijn mijn opstart parameters:

-m "models\unsloth_Qwen3.8-27B-GGUF\Qwen3.8-27B-Q6_K.gguf" -mm "models\unsloth_Qwen3.8-27B-GGUF\mmproj-BF16.gguf" --host 0.0.0.0 --port 8080 --ctx-size 192144 --split-mode layer -ngl 999 --batch-size 256 --ubatch-size 256 --threads 8 --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.00 --flash-attn on --tensor-split 24,8 --no-host --cache-type-k q8_0 --cache-type-v q8_0 -np 1 --presence-penalty 0.0 --repeat-penalty 1.0 --jinja --keep 1024 --ctx-checkpoints 128 --spec-type draft-mtp --spec-draft-n-max 4 --image-min-tokens 1024

--tensor-split 24,8 wil zeggen 24 GB van mijn RTX 4000 gebruiken en 8 van mijn 5060. Uiteraard is het belangrijk om te weten wat kaart 0 en kaart 1 is.

[R3m3d7]

Deepflame schreef op maandag 17 augustus 2026 @ 16:57:
[...]

Ja zoals de anderen zeiden, idd via huggingface, het Unsloth model. :-)

Ik heb een lokaal aangepaste versie van llama.cpp TheTom/TurboQuant draaien (zoals je al weet) waardoor ik mijn model op kan splitsen over CUDA en ROCm (moest ik een llama.cpp upstream bugfix voor importeren naar TheTom/TQ) waardoor ik genoeg VRAM heb om Q6 volledig in VRAM te draaien op mijn RTX 3090 (24 GB) en RX 6700 XT (12 GB) met een KV cache van 256k op turbo4/turbo3 KV cache quant.


Dit terzijde, ondertussen heb ik mijn clustertje van 3x RTX 3070 en 6x GTX 1070 ook draaiende. Plaatje bijgevoegd. Heb er een oude Kallax voor uit de woonkamer gehaald (vrouw ook blij, die wilde al jaren van dat ding af) en met mijn 3d printer wat custom GPU mounts gemaakt.

[Afbeelding]

72 GB VRAM, heb er deze week mee met DeepSeek V4 Flash 0731 op zitten spelen. Heb DwarfStar 4 gepakt als basis inference engine, en loop daar nu aan te sleutelen om hem maar sneller te krijgen.

Stock DwarfStar 4 haalde ik ~4 tok/s mee, na mijn eerste optimalisatie heb ik nu een prefill van 30 tok/s en een decode van 8 tok/s, en ik ben nu bezig met een nieuw algoritme waarmee ik misschien wel de 16 tok/s aan kan tikken, met een beetje mazzel.

Daarna heb ik denk ik wel de grens bereikt van wat ik kan doen met zoveel oude GPUs. x)

Voor de nieuwsgierigen:
- Stroomverbruik: Als dat ding idle staat te staan verbruikt ie ongeveer 100W, als ik er op het moment actief inference op draai tikt ie de 500W aan.
- Model: Ik gebruik DeepSeek V4 Flash 0731 Q2_XSS (~81 GB)
- VRAM gebruik: Ongeveer 2/3de van het model past in mijn VRAM na KV Cache van 256k, CUDA buffers, etc.
- Geluidsniveau: Eigenlijk best stil, die 140mm fans draaien op half vermogen en houden het geheel op ongeveer 50-60c tijdens inference, 40c idle.
- Operating system is Ubuntu headless server
- Systeem is gebouwd op OCuLink adapters en kabels.
- Wat heeft me dit gekost: Mijn sanity, wat OCuLink apparatuur (€300), en 2 rollen ABS van een kilo. De grafische kaarten, voedingen, moederbord, RAM, etc. heb ik van de stort gered toen het bedrijf waar ik voor werkte sloot en IT alles naar de stort ging brengen.
- Wat heeft het me opgeleverd: Diepere kennis van hoe inference engines werken, en een apparaat waar ik met trots over kan praten. xD

Haha, held!

Het voelt voor mij een beetje als de begintijd van computers of het internet. Erg gaaf om te lezen, ben jaloers op je speelgoed!

[DeNachtwacht]

Ja, dat is misschien nog wel het leukste van AI. Het is weer echt tweaken, pionieren en innoveren. Soms vervelend omdat daarbij natuurlijk ook installaties die breken, bugs en ander gezeur horen, maar het is wel weer echt terug naar de roots van tweakers.

[max3D]

Felicia schreef op vrijdag 24 juli 2026 @ 20:13:
[...]

Ik heb zelf een PC met upgrade pad van

• 4070 Super (12GB, geen blower, luid en irritant)
• Intel Arc Pro B60 (24GB Vram, blower en relatief rustig)
• en nu een Intel Arc Pro B70 (32GB Vram, blower en daar wordt je niet blij van in dezelfde ruimte, ik zet de GPU op max 40% vermogen als de jongeste naar bed gaat en PC staat in de kamer ernaast ).

Qua performance is de B60 niet gelijk aan de 4070 qua rekenkracht maar door het vele hogere Vram kan ik desondanks modellen draaien die met de 4070 niet haalbaar waren. De B70 lijkt qua rekenkracht op 5060/5070 niveau te zitten maar dan wel met 32GB Vram.
Met llama.cpp SYCL zijn de performance metrics de afgelopen maanden vooral op prompt processing behoorlijk verbeterd.

De kostprijs was voor mij reden om in ieder geval de B60 te proberen (~700 euro) en ook te upgraden naar de B70 (~1300 euro).

_{Ik had ook een 5070 Ti geprobeerd maar om onbekende redenen wilde mijn PC daarmee niet booten ondanks ruim voldoende voeding. Achteraf blij met de Intel wat veel meer Vram :D}

Leuk te zien. Ik heb een 4070S en 128Gb ram, maar de leuke modellen passen gewoon niet. Morgen komt mijn B70 binnen. Hoop dat de herrie meevalt; de 32GB gaat verschil maken.
De support vanuit Intel en de lokale AI community is een stuk beter dan een paar maanden geleden en voor 1300E koop je nergens meer zoveel Vram

[CSB]

Dit is vreemd zeg. Overnight werkt mijn setup opeens voor geen meter meer. Ik heb een RTX4070 Super en Ryzen 7 7800X3D met 32 GB DDR5 en draaide daarmee met Qwen3.6 35B A3B een Hermes Agent met 128k context met gemiddeld 50 token/s, met daarbij 90 tot 100% GPU utilization.

Windows 11 besloot gisteren opeens dat llama.exe en llama-gguf-split.exe een trojan zou hebben en plaatste deze in quarantaine, waardoor mijn hele stack niet meer werkte. Dit heb ik hersteld maar: nu gaat llama.cpp 70% naar de CPU gooien en dropt mijn GPU utilisation naar 0 tot 20%! En ik heb niks aangepast aan mijn opstart parameters.

Ra ra politiepet. Ik ben ff de weg kwijt nu. Hermes is iig nu totaal niet bruikbaar meer.

[DeNachtwacht]

@CSB hmm, ik zou dan toch eens kijken naar waarom Windows 11 die trojan detecteert, heb je geen verkeerde (custom) versie geïnstalleerd? Als er echt een trojan in zou zitten zou dat natuurlijk binnen de kortste keren overal op fora omhoogkomen en vooralsnog zie/lees ik hier nergens iets over.

Is het geen firewall / defender achtig iets daardoor, waardoor de GPU niet meer goed/vol gebruikt kan worden door llama.cpp?

[CSB]

Het is zeer waarschijnlijk een false positive, want alleen MS rapporteert dit als ik kijk op virustotal.

Maar ik ben er al achter. Laten we het erop houden dat ik een domme fout heb gemaakt met het restoren van mijn startup script. (had asymmetric KV caching aan staan in mijn oude script, dit veroorzaakte nogal overhead. nu met KV symmetric op Q8_0 werkt het weer, sorry voor de loze roep!)

[Tazzy]

Ben wel benieuwd of dit een optimalisatie kan zijn voor grote AI modellen:

https://pixelcluster.dev/VRAM-Overcommit/

[DeNachtwacht]

Interessant artikel. Ik zit zelf ook een beetje vergelijkbaar te denken dat driver updates voor multi-gpu setups serieus bij kunnen dragen. Ik heb nu een RTX 5060 Ti met daarop de monitor aangesloten, en een RTX 5090 apart voor het zwaarste LLM werk (rest gaat door naar de 5060 Ti). Maar dan loop je er dus ook tegenaan dat windows en de nvidia driver nog steeds max 30.3 GB van het vram van de 5090 beschikbaar maken voor tools omdat standaard 1.7 GB wordt gereserveerd voor aansluiting van de monitor / windows dekstop. Dit gebeurt bij serverdrivers logischerwijs niet, maar voor alle consumentenhardware kom je daar niet onderuit.

In deze tijden van vram geheugenschaarste is dat feitelijk nutteloos blokkeren van vram in multi-gpu setups. In mijn geval valt het procentueel nog enigszins mee maar als je een 16 GB of zelfs maar 12GB vram kaart hebt als 2e gpu wordt dus bijna 18% van je vram nutteloos gelockt.

Hoop dat ze daar ook iets aan gaan doen een keer.

[ Voor 6% gewijzigd door DeNachtwacht op 20-08-2026 14:48 ]

[max3D]

DeNachtwacht schreef op donderdag 20 augustus 2026 @ 14:47:
Interessant artikel. Ik zit zelf ook een beetje vergelijkbaar te denken dat driver updates voor multi-gpu setups serieus bij kunnen dragen. Ik heb nu een RTX 5060 Ti met daarop de monitor aangesloten, en een RTX 5090 apart voor het zwaarste LLM werk (rest gaat door naar de 5060 Ti). Maar dan loop je er dus ook tegenaan dat windows en de nvidia driver nog steeds max 30.3 GB van het vram van de 5090 beschikbaar maken voor tools omdat standaard 1.7 GB wordt gereserveerd voor aansluiting van de monitor / windows dekstop. Dit gebeurt bij serverdrivers logischerwijs niet, maar voor alle consumentenhardware kom je daar niet onderuit.

In deze tijden van vram geheugenschaarste is dat feitelijk nutteloos blokkeren van vram in multi-gpu setups. In mijn geval valt het procentueel nog enigszins mee maar als je een 16 GB of zelfs maar 12GB vram kaart hebt als 2e gpu wordt dus bijna 18% van je vram nutteloos gelockt.

Hoop dat ze daar ook iets aan gaan doen een keer.

Als je een mb met iGPU hebt of zoals jj een tweede GPU ziet het er een stuk beter uit want hoef je geen buffers te reserveren.Het fragmentatieprobleem uit het artikel heb je dan ook niet. Windows of WDDM maken je 5090 echter niet in een serverkaart. Gewone GeForce-kaarten ondersteunen Nvidia’s computegerichte TCC-modus niet
WDDM/Nvidia/CUDA-context en driveradministratie: (grofweg 1–1,5 GiB?) ben je dus kwijt

[Liegebeest]

eheijnen schreef op maandag 17 augustus 2026 @ 17:00:
@Deepflame
Wist nie dat ze bij IKEA ook al datacenter gerei verkopen...

De LackRack is al meer dan vijftien jaar een fenomeen!

https://wiki.eth0.nl/index.php/LackRack

[DeNachtwacht]

max3D schreef op donderdag 20 augustus 2026 @ 16:15:
[...]

Als je een mb met iGPU hebt of zoals jj een tweede GPU ziet het er een stuk beter uit want hoef je geen buffers te reserveren.Het fragmentatieprobleem uit het artikel heb je dan ook niet. Windows of WDDM maken je 5090 echter niet in een serverkaart. Gewone GeForce-kaarten ondersteunen Nvidia’s computegerichte TCC-modus niet
WDDM/Nvidia/CUDA-context en driveradministratie: (grofweg 1–1,5 GiB?) ben je dus kwijt

Ik snap je even niet.

Even verduidelijking: get heeft inderdaad niet met het fragmentatieprobleem uit dat artikel te maken.

Maar mijn punt was dat het los daarvan vrij zonde is dat er ook +/- 1.5 GB aan VRAM nutteloos geblokkeerd wordt bij een 2e GPU die niet op een monitor is aangesloten . En dat ik dus hoop dat drivers inderdaad ook een TCC modus gaan ondersteunen op consumentenkaarten zodat je die zelf aan kan zetten bij een 2e gpu indien gewenst.

[max3D]

Dan begreep ik jou gewoon niet en verder eens

[Felicia]

DeNachtwacht schreef op donderdag 20 augustus 2026 @ 14:47:
Interessant artikel. Ik zit zelf ook een beetje vergelijkbaar te denken dat driver updates voor multi-gpu setups serieus bij kunnen dragen. Ik heb nu een RTX 5060 Ti met daarop de monitor aangesloten, en een RTX 5090 apart voor het zwaarste LLM werk (rest gaat door naar de 5060 Ti). Maar dan loop je er dus ook tegenaan dat windows en de nvidia driver nog steeds max 30.3 GB van het vram van de 5090 beschikbaar maken voor tools omdat standaard 1.7 GB wordt gereserveerd voor aansluiting van de monitor / windows dekstop. Dit gebeurt bij serverdrivers logischerwijs niet, maar voor alle consumentenhardware kom je daar niet onderuit.

Ik moet zeggen dat ik dat bij de Intel Arc Pro B70 ook niet heb, gewoon de volle 32GB beschikbaar.

De monitor zit op de iGPU maar als er geen LLM modellen geladen zijn kan ik ook gamen op de B70 (al speel ik alleen maar Baldur's Gate 3 en die moet dan op Window mode staan).

[DeNachtwacht]

Felicia schreef op donderdag 20 augustus 2026 @ 20:23:
[...]

Ik moet zeggen dat ik dat bij de Intel Arc Pro B70 ook niet heb, gewoon de volle 32GB beschikbaar.

Ik vrees dat je daarvoor een trapje dieper moet dan windows task manager. Als je "ollama serve" start (en ongetwijfeld zal er ook zo iets zijn als je llama.cpp start, zie je oa dit:

time=2026-08-20T20:25:56.485+02:00 level=INFO source=types.go:32 msg="inference compute" id=0 filter_id=GPU-5e9ba80b-0394-39af-f604-df44b9c13659 library=CUDA compute=12.0 name=CUDA0 description="NVIDIA GeForce RTX 5090" libdirs=ollama,cuda_v13 driver=13.3 pci_id=0000:09:00.0 type=discrete total="31.8 GiB" available="30.3 GiB"

Dit is dan bij een nvidia/cuda device natuurlijk, maar iets vergelijkbaars zal bij een intel kaart te vinden zijn. Je ziet daar dat de max die aan te spreken is door ollama 30.3 GiB is en niet de volle 31.8 GiB die er zijn. Dat is het stukje waar dit over gaat. Het zou kunnen dat intel dit in de drivers anders doet, waardoor jij wel bij de volle vram kan. Ik ben dus ook wel benieuwd naar welke input jij daar ziet. Zou best interessant zijn als Intel dit wel toestaat, maar bij nvidia kun je daar dus alleen bij server gpu's bij (bij mijn weten).

[ Voor 6% gewijzigd door DeNachtwacht op 20-08-2026 20:32 ]

[Felicia]

DeNachtwacht schreef op donderdag 20 augustus 2026 @ 20:29:
[...]

Ik vrees dat je daarvoor een trapje dieper moet dan windows task manager. Als je "ollama serve" start (en ongetwijfeld zal er ook zo iets zijn als je llama.cpp start, zie je oa dit:

[...]

Op Windows met llama.cpp zie ik dit:

code:

0.00.863.768 I common_memory_breakdown_print: | memory breakdown [MiB]                        | total    free     self   model   context   compute    unaccounted |
0.00.863.768 I common_memory_breakdown_print: |   - SYCL0 (Intel(R) Arc(TM) Pro B70 Graphics) | 31906 = 31906 + (30269 = 19902 +    5182 +    5184) +      -30269 |
0.00.863.769 I common_memory_breakdown_print: |   - Host                                      |                   4497 =   272 +       0 +    4224                |
0.00.922.607 I common_params_fit_impl: projected to use 30269 MiB of device memory vs. 31906 MiB of free device memory
0.00.922.614 I common_params_fit_impl: will leave 1636 >= 924 MiB of free device memory, no changes needed

Dan laad ik dus de maximale context +mmproj bestand volledig in het geheugen.
Fun fact, dit is een workstation GPU die ook virtueel splitsen toelaat (niet dat ik dat gebruik)

[DeNachtwacht]

aaahh ja maar dat verklaart het al. met een workstation gpu heb je die ruimte wel (ook bij nvidia)

[max3D]

DeNachtwacht schreef op donderdag 20 augustus 2026 @ 22:10:
aaahh ja maar dat verklaart het al. met een workstation gpu heb je die ruimte wel (ook bij nvidia)

What's in a name. De B70 is door Intel dubbel gepositioneerd. Pro drivers en game drivers. Qua geld meer consument; qua blowers meer pro

[ocf81]

Een tamelijk interessante uiteenzetting op het L1Techs forum over hoe lokale modellen beperkt worden op kleinere systemen en wat je daar aan kan doen: Why your local LLM feels dumber than it is

[ Voor 10% gewijzigd door ocf81 op 21-08-2026 00:06 ]

[eheijnen]

Ook nog een interessant artikel:
https://markets.businessi...to-jane-street-1036471031

[Vishari Beduk]

Ik lees enthousiaste verhalen over Qwen3.8 dus vanochtend zelf de 27B gedownload en opgestart in LM studio. Vervolgens op een andere pc met mijn source code pi opgestart en daarmee verbonden.

En dan eerst even een rant over al die 'testen' op youtube; de meeste geven als input één prompt en dan wordt er een geheel nieuwe app geschreven. Maar dat doe ik bijna helemaal nooit, ik heb bestaande apps die aangepast moeten worden.

Anwyay de eerste test was het aanpassen van C# code, prompt "in ##RequestHandler convert Lambda Expression into Query Expression". Resultaat was code vol fouten die niet eens compileert. Fail.

De tweede test was aanpassen Angular code, prompt "component azure-app-services has a resourceLink column but its content is a very long URL, do you have suggestions to improve visibility?". Resultaat was een nog groter drama; een paar verkeerde regels aangepast en na half uur gaf hij het op. Fail.

Vervolgens precies dezelfde prompt in mijn 20 dollar account aan Claude Sonnet gegeven. Daar was click, click even wachten en prima resultaat.

Dus ik blijf bij mijn eerdere conclusie; die lokale LLM's zijn interessant om mee te experimenteren maar komen niet in de buurt van Claude.

[Felicia]

Vishari Beduk schreef op zondag 23 augustus 2026 @ 10:45:
Dus ik blijf bij mijn eerdere conclusie; die lokale LLM's zijn interessant om mee te experimenteren maar komen niet in de buurt van Claude.

De vraag is natuurlijk, welke quant heb je gebruikt, welke instellingen (temperature, top_p, top_k etc) want die hebben allemaal effect op het uiteindelijke resultaat wat je ziet.

[CT]

Felicia schreef op zondag 23 augustus 2026 @ 11:59:
[...]

De vraag is natuurlijk, welke quant heb je gebruikt, welke instellingen (temperature, top_p, top_k etc) want die hebben allemaal effect op het uiteindelijke resultaat wat je ziet.

Met die 2 videokaarten in de sig zou je 16GB+32GB = 48GB! verwachten, dan kan je makkelijk full context Q8 draaien etv fp16 k/v nog wel context van 200k ofzo.

Hier moet je met pi toch wel zeker prima resultaten krijgen met dat soort vragen.

[vargo]

@Vishari Beduk welke versie draai je, en met welke settings (aanvullend op @Felicia, ook welke context size, thinking level, thinking budget)?

Ik heb dezelfde setup: Qwen 3.8 + pi (/zed IDE) op een linux workstation (96GB / RTX 5090). Mijn ervaringen zijn over het algemeen vrij positief:

• refactoring van kubernetes + kustomize manifests -> uitstekend resultaat op basis van lijstje zaken die ik anders wilde (simpel harnas in ZED, met mijn eigen agent definitie van een k8s devops profiel, eigenlijk geen extensies).
• python applicatie, met Pi harness (custom agents, aantal extensions) -> hierbij ook gebruik makend van TDD (red -> green implementatie) + BDD (in gherkin features vastgelegd), DDD architectuur -> prima code, maar soms (/best vaak) komt het model in een thinking loop vast te zitten. In dat geval laat ik het model een handoff maken en start ik de sessie opnieuw.
• ik heb pi een eigen extensie laten schrijven om de thinking levels voor qwen te supporten: ik draai meestal op low in agentic workflows (geen thinking budget meegegeven)
• Ik draai `Qwen3.8-27B-Q4_k_m.gguf`, 60 TPS (?). Settings: 175K context, verder defaults van lmstudio (oa MTP=on, temp=1, concurrency=4, flash_attention=on). Tijdens inference draai ik de reasoning effort of op extra high (planning, architecting, troubleshooting), of op low (agentic coding / testing implementatie). Doorgaans
• ik heb een NVFP4 geprobeerd (https://huggingface.co/esatapedico/Qwen3.8-27B-NVFP4-MTP-GGUF) maar die was niet sneller dan de `Qwen3.8-27B-Q4_k_m.gguf` -> ik las dat Unsloth ermee bezig is maar er is iets met de vision capability van het model dat dit lastig maakt schijnbaar. Met Qwen 3.6 NVFP4 haalde ik ~120TPS, dus ik hoop dat er snel een goede versie uitkomt.
  (edit) Deze staat op de todo list, maar draait op vllm -> Qwen3.8-27B-NVFP4-RTX5090

Tuurlijk zijn de Anthropic / OpenAI modellen beter, maar op lange termijn is het niet houdbaar: die kosten gaan ze ooit terug moeten verdienen. Het feestje zal een keer ophouden en dan gaan de kosten drastisch omhoog. Bovendien betaal je ook nog eens met je data met deze partijen.

De open source modellen volgen gelukkig heel behoorlijk met zowel grote (Kimi K3, GLM 5.3, Deepseek) als quantised modellen (Qwen, Gemma, Ornith, Nemotron) waarvan die laatste gelukkig op thuis hardware draaien. Met het juiste harness is lokaal ook bijzonder effectief, en dwingt je om efficient te zijn (en je kan altijd nog mixen met de online providers).

Ik zit al lang te kijken om een keer een build bij elkaar te schrapen met 256 tot 512GB VRAM, maar het was al onbetaalbaar, en het wordt alleen nog maar duurder

[ Voor 3% gewijzigd door vargo op 23-08-2026 18:00 ]

[Vishari Beduk]

Felicia schreef op zondag 23 augustus 2026 @ 11:59:
[...]

De vraag is natuurlijk, welke quant heb je gebruikt, welke instellingen (temperature, top_p, top_k etc) want die hebben allemaal effect op het uiteindelijke resultaat wat je ziet.

Ik had gemini advies gevraagd. Nog wat met de temperature zitten spelen maar niet best.
Deze maand heb ik nog dubbel claude budget. Maar wanneer dit feest over is zal ik eens verder expirementeren.

CT schreef op zondag 23 augustus 2026 @ 17:37:
[...]

Met die 2 videokaarten in de sig zou je 16GB+32GB = 48GB! verwachten, dan kan je makkelijk full context Q8 draaien etv fp16 k/v nog wel context van 200k ofzo.

Hier moet je met pi toch wel zeker prima resultaten krijgen met dat soort vragen.

Als je het over mij setup hebt? Die zitten in twee verschillende pc's. Ik heb deze gedaan op de 5060. De 5090 gebruik ik bijna niet.

vargo schreef op zondag 23 augustus 2026 @ 17:55:
@Vishari Beduk welke versie draai je, en met welke settings (aanvullend op @Felicia, ook welke context size, thinking level, thinking budget)?

Ik heb dezelfde setup: Qwen 3.8 + pi (/zed IDE) op een linux workstation (96GB / RTX 5090). Mijn ervaringen zijn over het algemeen vrij positief:

• refactoring van kubernetes + kustomize manifests -> uitstekend resultaat op basis van lijstje zaken die ik anders wilde (simpel harnas in ZED, met mijn eigen agent definitie van een k8s devops profiel, eigenlijk geen extensies).
• python applicatie, met Pi harness (custom agents, aantal extensions) -> hierbij ook gebruik makend van TDD (red -> green implementatie) + BDD (in gherkin features vastgelegd), DDD architectuur -> prima code, maar soms (/best vaak) komt het model in een thinking loop vast te zitten. In dat geval laat ik het model een handoff maken en start ik de sessie opnieuw.
• ik heb pi een eigen extensie laten schrijven om de thinking levels voor qwen te supporten: ik draai meestal op low in agentic workflows (geen thinking budget meegegeven)
• Ik draai `Qwen3.8-27B-Q4_k_m.gguf`, 60 TPS (?). Settings: 175K context, verder defaults van lmstudio (oa MTP=on, temp=1, concurrency=4, flash_attention=on). Tijdens inference draai ik de reasoning effort of op extra high (planning, architecting, troubleshooting), of op low (agentic coding / testing implementatie). Doorgaans
• ik heb een NVFP4 geprobeerd (https://huggingface.co/esatapedico/Qwen3.8-27B-NVFP4-MTP-GGUF) maar die was niet sneller dan de `Qwen3.8-27B-Q4_k_m.gguf` -> ik las dat Unsloth ermee bezig is maar er is iets met de vision capability van het model dat dit lastig maakt schijnbaar. Met Qwen 3.6 NVFP4 haalde ik ~120TPS, dus ik hoop dat er snel een goede versie uitkomt.
  (edit) Deze staat op de todo list, maar draait op vllm -> Qwen3.8-27B-NVFP4-RTX5090

Tuurlijk zijn de Anthropic / OpenAI modellen beter, maar op lange termijn is het niet houdbaar: die kosten gaan ze ooit terug moeten verdienen. Het feestje zal een keer ophouden en dan gaan de kosten drastisch omhoog. Bovendien betaal je ook nog eens met je data met deze partijen.

De open source modellen volgen gelukkig heel behoorlijk met zowel grote (Kimi K3, GLM 5.3, Deepseek) als quantised modellen (Qwen, Gemma, Ornith, Nemotron) waarvan die laatste gelukkig op thuis hardware draaien. Met het juiste harness is lokaal ook bijzonder effectief, en dwingt je om efficient te zijn (en je kan altijd nog mixen met de online providers).

Ik zit al lang te kijken om een keer een build bij elkaar te schrapen met 256 tot 512GB VRAM, maar het was al onbetaalbaar, en het wordt alleen nog maar duurder

Ha OK, ik zal er na deze maand nog eens goed naar kijken.
Ik gebruik cluade overigens ook i.c.m. Azure devops and Azure apps; claude kijkt ook naar commits van anderen en gebruikt dat voor analyze van problemen. Controleert build en release pipelines. En helpt met fouten zoeken in Azure functions die niet op mijn laptop draaien. Doet dus zoveel meer dan alleen coderen. Zou het niet meer willen missen.

[CT]

Vishari Beduk schreef op zondag 23 augustus 2026 @ 21:05:

[...]

Als je het over mij setup hebt? Die zitten in twee verschillende pc's. Ik heb deze gedaan op de 5060. De 5090 gebruik ik bijna niet.


[...]

Ok 16GB dan heb je denk ik een vrij lage quant geprobeert 't model valt wel erg uitelkaar onder de Q8, een Q6 XL zal allicht nog wel wat opleveren maar alles eronder zou ik met een korrel zout nemen en zeker niet vergelijken met een Opus/Sonnet/Sol etc.

[Zsub]

Ik ben een beetje aan het zoeken naar een driver voor m'n oh-my-pi harness. Vandaag maar eens gpt-oss-20b geprobeerd, sodemieter die is rap! Maar niet zo heel slim helaas, zelfs niet met thinking high. Hij kan niet zelf bedenken hoe hij met de home assistant MCP server een lijst sensors kan vinden. Vond ik wel tamelijk tegenvallen.

[DeNachtwacht]

CT schreef op zondag 23 augustus 2026 @ 17:37:
[...]

Met die 2 videokaarten in de sig zou je 16GB+32GB = 48GB! verwachten, dan kan je makkelijk full context Q8 draaien etv fp16 k/v nog wel context van 200k ofzo.

Hier moet je met pi toch wel zeker prima resultaten krijgen met dat soort vragen.

Multi gpu gaat hem helaas niet worden met Qwen 3.8 tenzij je twee identieke kaarten hebt. Het kan wel, maar door het architectuurverschil t.o.v. 3.6 gaat hij op 5060 Ti snelheid draaien, dus lever je echt fors wat in.

Qwen 3.8 heeft de architectuur gewijzigd, het maakt nu gebruik van een Hybrid Attention Layout (ongelijke laagtypen) en daarnaast de bij ons allen wel bekende Multi-Token Prediction (MTP). Het verdelen van deze lagen over twee heterogene kaarten verstoort de rekenlus en zorgt ervoor dat de 5090 constant vastloopt in afwachting van de 5060 Ti (ook door PCIe bottleneck).

@vargo ik zou toch nog eens kijken, ik heb nu in ollama met 170K context op mijn RTX 5090 (ik heb dan wel een setup dat windows daarop niet aangesloten is, dus net iets meer vram beschikbaar door 2e gpu) rond de 85 tokens/sec. Verder echt niks ingesteld dan dat ollama mijn 5060 ti dus niet meer te zien krijgt zodat die ook niet (automatisch) gebruikt wordt. Dus er is nog wel wat snelheidswinst haalbaar.

[Julianvvz]

Probeer ninfer profile van Qwen 3.8 27B; die is speciaal gemaakt voor de 5090. Die haalt bij mij tussen de 114 en 213 tok/s op single sessions. Een stuk sneller dan alle andere opties. Downside is minder context window en geen vision model voor mijn setup t.o.v. de alternatieven zoals benoemd hierboven.

Neroued/ninfer: High-performance single-GPU inference for selected model checkpoints and GPUs.

N.B. elke dag vraag ik Claude om uit te zoeken of er al een betere snellere optie is om te draaien op mijn AI machine. Doet een aantal tests zelfstandig en komt met een mooi rapport. Deze is tot nu toe bij uitstek de snelste en doet niet onder aan kwaliteit.

[ Voor 5% gewijzigd door Julianvvz op 24-08-2026 11:13 ]

[vargo]

@DeNachtwacht op welke backend draai je dat?
Ik zit op CUDA 12 llama.cpp (Linux), v2.29.1.

@Julianvvz dank voor de tip, die ga ik zeker proberen

[ Voor 21% gewijzigd door vargo op 24-08-2026 16:54 ]

[Vishari Beduk]

CT schreef op zondag 23 augustus 2026 @ 21:15:
[...]

Ok 16GB dan heb je denk ik een vrij lage quant geprobeert 't model valt wel erg uitelkaar onder de Q8, een Q6 XL zal allicht nog wel wat opleveren maar alles eronder zou ik met een korrel zout nemen en zeker niet vergelijken met een Opus/Sonnet/Sol etc.

Ha ok.
Ik heb geen zonnepanelen en om de 5090 te gebruiken voor coderen wordt het een dure grap.
Ben wel benieuwd hoeveel de RTX spark (niet te verwarren met de DGX) daadwerkelijk gaat kosten, misschien dat die wel rendabel is.

[Deepflame]

DeNachtwacht schreef op maandag 24 augustus 2026 @ 08:28:
[...]

Multi gpu gaat hem helaas niet worden met Qwen 3.8 tenzij je twee identieke kaarten hebt. Het kan wel, maar door het architectuurverschil t.o.v. 3.6 gaat hij op 5060 Ti snelheid draaien, dus lever je echt fors wat in.

Qwen 3.8 heeft de architectuur gewijzigd, het maakt nu gebruik van een Hybrid Attention Layout (ongelijke laagtypen) en daarnaast de bij ons allen wel bekende Multi-Token Prediction (MTP). Het verdelen van deze lagen over twee heterogene kaarten verstoort de rekenlus en zorgt ervoor dat de 5090 constant vastloopt in afwachting van de 5060 Ti (ook door PCIe bottleneck).

...

Huh? Ik heb hem hier gewoon verspreid draaien over een Nvidia RTX 3090 en een AMD RX 6700 XT hoor.

Draait wel een stuk langzamer dan alleen op de RTX 3090, maar kan wel meer KV cache en een hogere quant.

[Tweakert1990]

-

[ Voor 99% gewijzigd door Tweakert1990 op 24-08-2026 22:23 ]

[Deepflame]

Die Hybrid Attention Layout is sinds Qwen 3.5 geintroduceerd, Qwen 3.6 27b en Qwen 3.8 27b zijn identiek layer voor layer, volgens mij? Goed, de cijfertjes zijn wat beter getuned, maar volgens mij zijn ze architectureel gezien identiek.

[CT]

Vishari Beduk schreef op maandag 24 augustus 2026 @ 17:52:
[...]

Ha ok.
Ik heb geen zonnepanelen en om de 5090 te gebruiken voor coderen wordt het een dure grap.
Ben wel benieuwd hoeveel de RTX spark (niet te verwarren met de DGX) daadwerkelijk gaat kosten, misschien dat die wel rendabel is.

Valt toch ook wel mee, mijn (dual) rtx 3080 staan gecapped op 200watt p/s, dus in echte piek momenten is dat 400watt, maar een inference sessie met agent is best een golf beweging, stel dat ik nonstop changes zou doorvoeren op een werkdag, dan zal die wellicht 4uur in die piek modus staan en dat is 1.6kwh, betaal je 36cent die dag aan stroom..

Die cap. van 400->200watt scheelt je 1-2tk/s trouwens, dus dat zou ik zeker is bekijken met een 5090.

[ Voor 7% gewijzigd door CT op 25-08-2026 07:55 ]

[Zsub]

Ja iig qua verbruik tijdens gebruik kan het wel uit volgens mij, met de hoeveelheid tokens. Maar als je GPU alleen maar idle is weet ik het zo net nog niet.

[DeNachtwacht]

@vargo ik draai hem in ollama met cuda 13.3. De gewone q4 want nvfp wordt nog niet ondersteund door ollama. Ik ga zelf testen met deze voor Blackwell geoptimaliseerde nvfp4 in llama.cpp of dat ook echt iets oplevert. Deze is ook met diverse kwantisaties verbeterd, zodat je tot aan 23gb kan downloaden, maar ook kleiner (tot aan 14.9 gb, dus wellicht interessant voor mensen met single 3090/4090 of 9700 ai pro): https://huggingface.co/esatapedico/Qwen3.8-27B-NVFP4-MTP-GGUF

@Deepflame je hebt idd gelijk dat er op dit punt toch geen verschillen met 3.5 en 3.6 zijn kom ik nu achter. Ik merkte namelijk een enorm snelheidsverschil met 3.6 omdat ik de workload grotendeels op de 5090 kon plaatsen. Bij 3.8 gaat dat niet meer, dus ook in jouw geval geldt dat álles met de snelheid van de langzaamste kaart gaat. Waarom het bij 3.6 dan wel mogelijk was flink te profiteren van die 5090 snelheid ben ik nu niet meer achter maar feit is dat het zo was . Nu hopen dat iemand hier ons met deze kennis kan verlichten .

[Deepflame]

@DeNachtwacht Ik zie geen significant verschil in performance, ik heb het een tijdje zitten analyseren, en heb wat metingen gedaan.

Meting 1: Qwen 3.8 27B Q2 op de RTX 3090 en op de RX 6700 XT apart van elkaar gedraait, zelfde settings, enige verschil was de hardware (en dus driver stack), het resultaat was dat ik merkte dat de RX 6700 XT ongeveer een derde van de RTX 3090 haalde qua snelheid.

Meting 2: Qwen 3.8 27B Q4 op de RTX 3090 gedraait, vrijwel identieke snelheid als Q2 op de RTX 3090.

Meting 3: Qwen 3.8 27B Q6 54 : 10 layer distributie, 54 layers op de 3090, 10 op de RX 6700, het resultaat was ongeveer twee derde van wat ik haalde met Q4.

Deze setup draait ietsjes sneller dan wat de Q2 haalde op de RX 6700 exclusief, waarschijnlijk omdat het MTP model volledig op de RTX 3090 draait en dus de predictive decode sneller is dan op de RX 6700 exclusief. Maar de performance ligt wel in de buurt van de langzaamste kaart, inderdaad.

Meting 4: Qwen 3.6 27B Q6 met dezelfde distributie als 3.8, zelfde performance ook.

Mijn metingen waren een set van 4 prompts met verschillende taken, coding en creative writing, coding haalt wat meer voordeel uit MTP en is consistent ~15% sneller dan creative writing.

[DeNachtwacht]

@Deepflame er is ook nog snelheidsverschil tussen Q2, 4 en 6. Voor de eerlijke vergelijking moet je alles in dezelfde kwantisering draaien (ook de context kwantisering, contextgrootte etc moet gelijk zijn voor een eerlijke vergelijking)

En je draait verder via llama.cpp? Wellicht zit er ook een verklaring in draaien wel of niet met ollama. Die doet veel automatisch (lekker gebruiksvriendelijk) maar mist aan de andere kant optimalisaties, waaronder dit misschien.

[Deepflame]

Ja, daarom heb ik al die verschillende quants gedraait om enigzins gelijke vergelijkingen te kunnen trekken. Helaas heb ik geen kaart waar ik Q6 in zijn volledigheid in kan proppen, anders had ik dat heus wel getest.

Q2 past op beide kaarten individueel, dus daarmee kon ik een onderlinge vergelijking trekken tussen de performance van de twee kaarten.

Ja, ik gebruik idd llama.cpp, die TheTom/TurboQuant variant waar ik het eerder over heb gehad.

Daarnaast heb ik ooit voor de grap Qwen 3.6 27B Q4 op 3 GTX 1070s laten draaien, dat haalde ongeveer 11 tok/s decode. Grappig genoeg haalt DeepSeek V4 Flash Q2 vergelijkbare snelheden op 6 van die krengen (+ 3 3070s en een heleboel custom optimalisaties). Dus er lijkt wel een soort van vergelijkbare trend te zijn in compute tov model size.

[Zsub]

Is Q2 nog zinvol? Gaat de kwaliteit daar niet enorm van onderuit tov f16 of q8?

[Deepflame]

Zsub schreef op dinsdag 25 augustus 2026 @ 15:56:
Is Q2 nog zinvol? Gaat de kwaliteit daar niet enorm van onderuit tov f16 of q8?

Hangt enorm van het model af, en de complexiteit van je taak. Oudere modellen zijn vrijwel onbruikbaar op Q2, Qwen 3.8 27B is nog verrassend functioneel op Q2. DeepSeek V4 Flash op Q2 is uitstekend.

[DeNachtwacht]

Deepflame schreef op dinsdag 25 augustus 2026 @ 15:50:
Ja, daarom heb ik al die verschillende quants gedraait om enigzins gelijke vergelijkingen te kunnen trekken.

Ik snap dit even niet. Als je wil weten of een setup met twee verschillende gpu's geheel op het tempo van de langzaamste gaat draaien of dat het snelheidsverlies alleen op gaat voor het deel dat op de langzaamste kaart draait (en de rest dus sneller is). Dan kun je dat toch alleen draaien door het exact zelfde model, met exact dezelfde kwantisering, met exact dezelfde grootte context, en met exact dezelfde kwantisering van de KV cache?

Ik vind het vreemd dat bij jou Q2 op een 3090 (meting 1) op ongeveer dezelfde snelheid als Q4 op de 3090 draait. Daar zou 15-20% snelheidsverschil moeten zijn, was er een verschil in context oid of snap ik iets niet goed?

Zelf heb ik bij meting 3 (in mijn geval met 5060 ti / 5090) de ervaring dat alles vrijwel naar 5060 ti snelheid gaat. Maar dat is wel met ollama, dus kortom misschien ook dit nog maar eens met llama.cpp op gaan pakken.

[Deepflame]

DeNachtwacht schreef op dinsdag 25 augustus 2026 @ 16:37:
[...]

...

Ik vind het vreemd dat bij jou Q2 op een 3090 (meting 1) op ongeveer dezelfde snelheid als Q4 op de 3090 draait. Daar zou 15-20% snelheidsverschil moeten zijn, was er een verschil in context oid of snap ik iets niet goed?

...

Ja dat vond ik ook apart. De settings waren verder identiek, dus ik snap dat ook niet helemaal. Misschien zit er een inefficiëntie in mijn llama fork voor Q2 quants. Ik zal er eens verder mee prutsen.

[DeNachtwacht]

Sowieso is en blijft het een constant tweaken & nieuwe-dingen-leren-wereld, dat is wat het soms frusterend maakt als het ff vaag is, maar ook juist weer leuk als er iets lukt.

[apollo13]

apollo13 schreef op zondag 2 augustus 2026 @ 20:13:
Vorige week eens begonnen met het zelf hosten van een LLM, dit via Ollama.
Ik ben al een tijdje bezig met AI image generation, ook lokaal, en via Tweakers vond ik Ollama en dit draadje.

Heb nu Qwen 3.6 en Gemma4:e4b draaien. Met deze twee aan het stoeien geweest en heb nu een mooie landingspage/frontpage gemaakt voor mijn boek. Mijn kennis van html is beperkt, dus ik dacht vraag het de AI! Dat is mijn goed bevallen. Soms gaat de LLM wel eens in de mist, maar geen probleem, gewoonweg weer een poging wagen. Kreeg af en toe geen output van mijn prompt, reden waarom is mij niet duidelijk. Dezelfde prompt een dag later weer gebruikt, en voila, een html website gemaakt.
Ook een kleine test gedaan wat betreft de Engelse versie van mijn boek, grammatica, spelling, woordgebruik, flow etc. Verrassende goede suggesties, verbeteringen en fouten gevonden door de LLM. Binnenkort mijn hele boek dus maar eens laten doorspitten en verbeteren. Ik laat mijn boek natuurlijk niet herschrijven.

Iemand nog suggesties wat betreft lokale LLM's die ik kan gebruiken voor wat ik er mee wil doen?

Vandaag echt begonnen om mijn eigen Engelse vertaling, van mijn NL boek, te laten proeflezen door de A.I.
Ik moet zeggen dat bevalt me prima. Gemiddelde voor het proeflezen van een pagina ligt rond de 50 seconden. Dit op een AMD 9 9900X, een RTX 4070 (12GB) en met 16GB intern geheugen.
Gebruikte A.I. is qwen 3.6. Kreeg via Ollama ook nog een melding dat er een update was voor qwen 3.6, die meteen maar gedaan. Voorbeeldje hier onder van wat qwen 3.6. produceert.

[Ozzi]

Ik zag vanmorgen dit langskomen:
https://huggingface.co/Qwen/Qwen3.8-Flash-Next

Ben benieuwd dat dat precies gaat zijn. Zag/hoorde ergens van een 125B MoE A6B model.

[DeNachtwacht]

Woa, ik lees wel "treat it as a rumor". Er is nog nergens officieel dat het ook zo zou zijn, maar het zou wel serieus goed nieuws zijn, dat is niet alleen qua qwen 3.8 een upgrade maar ook doordat het aantal parameters zo fors hoger is. Is iets minder natuurlijk als je maar 12GB vram hebt, maar voor de lucky bastards met wat meer vram heb je dan een stuk meer kwaliteit tegen een prima tokensnelheid (daar waar 3.6 35B vooral redelijk vergelijkbaar met 27B tegen onnodig hoge tokensnelheid was ).

Maar goed, nog maar niet te vroeg juichen, klinkt to good to be true in mijn geval.

[ Voor 17% gewijzigd door DeNachtwacht op 26-08-2026 09:28 ]

[ocf81]

Zo, de geheugenprijzen hakken er wel in zeg. Je ziet in de laatste maand een enorme sprong in de prijzen van GPU's met 32GB aan boord. De B70 is van ca. €1200 naar ca. €1600 gegaan en de 9700 van zo'n €1400 naar €1700.

Wel blij dat ik voor de grote sprong mijn kaarten in huis heb gehaald. Nu de machine nog aan de praat krijgen. (Stedin gaat er 20 weken over doen om de hoofdzekering op te waarderen naar een niveau dat ik nodig heb om die machine op volle toeren te kunnen benutten )

[Puff_Uncle]

ocf81 schreef op woensdag 26 augustus 2026 @ 11:48:
Zo, de geheugenprijzen hakken er wel in zeg. Je ziet in de laatste maand een enorme sprong in de prijzen van GPU's met 32GB aan boord. De B70 is van ca. €1200 naar ca. €1600 gegaan en de 9700 van zo'n €1400 naar €1700.

Wel blij dat ik voor de grote sprong mijn kaarten in huis heb gehaald. Nu de machine nog aan de praat krijgen. (Stedin gaat er 20 weken over doen om de hoofdzekering op te waarderen naar een niveau dat ik nodig heb om die machine op volle toeren te kunnen benutten )

wat heb je binnengehaald? ik heb nu net via mijn werk een RTX ADA 5000 met 32gb vram ben nu de eerste testen aan het doen

[ocf81]

Ik heb ca twee maanden geleden vier ASRock Radeon AI 9700 kaarten gehaald. Maar het kunnen gebruiken van het systeem hangt dus op Stedin.

[DeNachtwacht]

Ozzi schreef op woensdag 26 augustus 2026 @ 07:23:
Ik zag vanmorgen dit langskomen:
https://huggingface.co/Qwen/Qwen3.8-Flash-Next

Ben benieuwd dat dat precies gaat zijn. Zag/hoorde ergens van een 125B MoE A6B model.

Never mind, hij is uit. Het base model is 360GB groot, de FP8 iets van 160. Ben bang dat dit zelfs in de nvfp4 versie alleen leuk is voor mensen met een RTX 6000 Pro of iig vram in die orde van grootte.

[ Voor 4% gewijzigd door DeNachtwacht op 26-08-2026 15:48 ]

[vargo]

DeNachtwacht schreef op woensdag 26 augustus 2026 @ 15:47:
[...]

Never mind, hij is uit. Het base model is 360GB groot, de FP8 iets van 160. Ben bang dat dit zelfs in de nvfp4 versie alleen leuk is voor mensen met een RTX 6000 Pro of iig vram in die orde van grootte.

Het is een MoE en met flink wat RAM (96GB+) en VRAM zou het moeten lukken.
Unsloth heeft deze guide gepubliceerd; een paar quotes:

• 1-bit is 75GB and uses 4-bit for the Ngram / PLE. This is 79% smaller than BF16 (355GB), and retains a top-1% accuracy of 80%.
• 
• We ran KLD for Qwen3.8-Flash quants, and show that 80% top-1% accuracy recovery is possible with 79% less disk space usage. The new architecture uses PLE / Ngrams, and these are not quantized that heavily (4-bit minimum) since they have random access pattern, and quantizing them heavily will damage the model.

Ook deze reddit thread heeft interessante info: de bovenste comments laten screenshots zien met de benchmark resultaten; TLDR - flink betere scores dan 3.8 27B!

[Ozzi]

Zo, UD-Q4_K_XL 111GB

Best fors. Zelf al heb je 4x 32GB, dan heb je al weinig ruimte meer over voor je context.
Maar ik ga evengoed wel even kijken of ik er wat leuks uit kan krijgen

[vargo]

@Ozzi ik zag via V&A dat je AMD Radeon PRO V620 kaarten hebt. Hoe performen deze?

Ik zit zelf op 96GB RAM en 32GB VRAM dus ik zal wel wat moeten tunen om dit draaiende te krijgen.

[ Voor 37% gewijzigd door vargo op 26-08-2026 19:31 ]

[DeNachtwacht]

Ozzi schreef op woensdag 26 augustus 2026 @ 19:11:
Zo, UD-Q4_K_XL 111GB

Best fors. Zelf al heb je 4x 32GB, dan heb je al weinig ruimte meer over voor je context.
Maar ik ga evengoed wel even kijken of ik er wat leuks uit kan krijgen

Het is MoE, ik verwacht dus dat het op zich zelfs wel redelijk zou moeten lukken op een Blackwell 72GB. Ben benieuwd hoe ver iedereen komt .

Kleine aanvulling; op 2x 3090 is het dus net een soort van bruikbaar op Q1, hoewel ik zelf 14t/s echt te traag vindt: https://www.reddit.com/r/LocalLLM/comments/1vz26lx/qwen38_flash_next_iq1_s_unsloth_pelican_on_bicycle/

[ Voor 28% gewijzigd door DeNachtwacht op 26-08-2026 21:14 ]

[Ozzi]

vargo schreef op woensdag 26 augustus 2026 @ 19:30:
@Ozzi ik zag via V&A dat je AMD Radeon PRO V620 kaarten hebt. Hoe performen deze?

Ik zit zelf op 96GB RAM en 32GB VRAM dus ik zal wel wat moeten tunen om dit draaiende te krijgen.

Ik heb eerder in dit topic een paar llama-benches geplaatst. Nu gebruikt llama-bench geen MTP, maar met een enkele kaar en max-draft op 3, doen ze met Qwen 3.8 27b meestal tussen de 25 a 30 tokens/s. Prompt processing start op ca 400 en loopt langzaam af naar mate de context groeit.

[Vishari Beduk]

CT schreef op dinsdag 25 augustus 2026 @ 07:53:
[...]

Valt toch ook wel mee, mijn (dual) rtx 3080 staan gecapped op 200watt p/s, dus in echte piek momenten is dat 400watt, maar een inference sessie met agent is best een golf beweging, stel dat ik nonstop changes zou doorvoeren op een werkdag, dan zal die wellicht 4uur in die piek modus staan en dat is 1.6kwh, betaal je 36cent die dag aan stroom..

Die cap. van 400->200watt scheelt je 1-2tk/s trouwens, dus dat zou ik zeker is bekijken met een 5090.

Ik heb er vandaag een energie meter tussen gehangen; idle 70-80W en op vol vermogen iets meer dan 700W. Als je dan de feitelijke kosten berekend valt het eigenlijk wel mee.
OK, zal dan toch eens verder experimenteren

[Ozzi]

Er wordt ook nog wel echt mer serieus geld gesmeten door de 'ai bedrijven':
nieuws: 'Nvidia neemt AI-platform Hugging Face over voor 12,9 miljard dollar'

[Deepflame]

Binnenkort maar eens uitzoeken of ik Qwen 3.8 Next Flash op mijn 'inference monolith' kan draaien! Ben benieuwd!

[Ozzi]

En nog meer nieuws. Ik zag dat er vandaag ook een glm 5.3 flash uitgekomen is. Veel nieuwe modellen de laatste tijd. Nu wordt deze wel best lastig om al lokaal te draaien met 321B parameters

[Zsub]

Kleine les over hoe je wel een goed harnas wil gebruiken voor je lokale modellen (cq genoeg skills etc wil hebben) mijn Qwen3.8-27B (mlx-community, 64gb MacBook m5 max, 8bit, geen k/v q, thinking xhigh) met het oh-my-pi harnas is sinds anderhalf uur bezig om ‘handmatig’ git patches te maken en toe te passen in plaats van zoals normaal files/chunks stagen en committen. Hij is nu halverwege de tweede van negen commits

Slechts vier uur later en hij heeft alles weten te committen, hot diggity dat was zinloos stroomverbruik zeg.

[ Voor 14% gewijzigd door Zsub op 27-08-2026 18:10 ]

[Ozzi]

Ik heb zojuist unsloth/Qwen3.8-Flash-Next-GGUF UD-Q6_K_XL binnen gehaald en zoals ik hem nu heb draaien gebruikt deze momenteel ca 140GB vram ( ) en 60GB ram.
Zonder optimalisaties of mtp op dit moment met een prompt om te kijken of ie z'n eigen run-parameters kan optimizen, start ie met ca 32t/s om langzaam af te lopen naar 25 t/s voor het eerste prompt.

_{Nee dit draait nu niet op een v620}

[hybride]

Hier Qwen3.5-9B-bartowski-Q4_K_M.gguf draaien op een 4070 Super met Llama. Haalt 80 tokens/sec.
Werkt goed samen met Hermes Nous agent.

[Puff_Uncle]

ik hoop dat ze binnenkort een nieuwe qwen 9b model uitbrengen, zou wel leuk zijn

[CSB]

Inderdaad. En liefst ook een 35B A3B. De huidige 3.6 is prima voor mijn hardware, alleen toch af en toe nog wat foutjes en quirks. Hopelijk zou dat met een upgrade naar 3.8 dan beter zijn.

[R.G]

Welk model is slim voor een 16gb kaart?

Of 11gb vram?

Hoe ver zijn we al? Kan je hier serieus mee werken denk aan het bouwen van een ios, Android app met testen ( technische en functionele) fysieke beschrijvingen.

Werkt dat een beetje of niet aan beginnen en gewoon ai tokens pay?


Dus wat is mogelijk met max 16gb.

Kosten ai tokens vs geen kosten ( stroom alleen)

[Zsub]

De manier waarop je de vraag stelt vind ik een beetje moeilijk. Heb je zelf al ge-googled?

Mijn Qwen3.6-35B-A3B heeft een iOS app gebouwd om mijn versterker aan te sturen. Werkt het net zo snel als cloud-providers? Zeker niet. Werkt het net zo 'goed' (slim?) als frontier modellen? zeker niet.

Je moet zelf blijven nadenken en sturen is mijn ervaring. Niet zoals Opus die je een ruwe prompt geeft en je app one-shot. Overigens is ook het harnas (harness) dat je gebruikt van belang. Ik gebruik oh-my-pi en dat werkt behoorlijk, maar iets hierboven zie je dat een ander model niet doorhad dat het git kon gebruiken en dus handmatig git patches ging genereren. Dat is deels prompting, deels harnessing.

Anders geformuleerd: als je prompts schrijft zoals je post zal lokale AI niet per se super voor je werken. Maar als je lokale AI precies prompt en wat geduld hebt dan vind ik het een zeer geloofwaardig alternatief, zeker voor zaken die je liever niet in de cloud hebt.

[ Voor 17% gewijzigd door Zsub op 04-09-2026 09:27 ]

[kazuka]

Hier ook aan het experimenteren met verschillende lokale AI modellen nadat ik al een poosje bezig was met ComfyUI voor afbeeldingen en videos. Heb nu Qwen3.8 27B draaien in nvfp4 versie op mijn RTX 5090, doet het behoorlijk goed! Mooi om te zien dat de ontwikkelingen best rap gaan, dus ben benieuwd naar toekomstige releases.

Heb het geluk dat mijn werkgever AI volop promoot en pushed voor haar medewerkers dus wij hebben een Hyperspace AI proxy draaien en iedereen krijgt 500 EUR aan tokens per maand. Kan daarmee verschillende modellen en agents gebruiken dus nu bezig met Codex and GPT 5.6 Sol voor het zwaardere werk en Qwen als lokaal model voor de wat eenvoudigere dingen.

Zag toevallig dit net voorbijkomen: https://www.nvidia.com/en-us/ai-on-rtx/personal-ai-router/



Je kunt hiermee je personal computing power over verschillende apparaten (RTX en Macs bijvoorbeeld) combineren voor gebruik met AI modellen. Eens kijken of ik dit aan de praat krijg. Zou hiermee mijn RTX 5090 kunnen combineren met mijn persoonlijke M4 Air en zakelijke M5 Pro.

[Ferrox1]

Ik zat te wachten op de nieuwe mac mini, hij is al even te koop!

Dus ik ben gaan onderzoeken wat te kopen en wat het meeste bang for buck is.

Maar de keuze is niet makkelijk, ik zit nu op een M1 MAX Macbook Pro met 32gb
Qwen 3.8 gaat hem niet worden op Q4, die laad niet vanwege geheugen tekort. Heb nu met Qwen3.6-35B-A3B gespeelt en dat werkt best leuk. Maar is wel redelijk traag en mijn macbook gaat gigantisch in de swap zitten (opzich logisch)

Gezien deze ervaring ben ik gaan zoeken, wat te doen.

Ik kom op de volgende opties uit (allen met een base SSD, voor die meerprijs hang ik er wel een externe aan die ik nog heb liggen):
Mac Mini M5 Pro 15CPU/15GPU 64 GB voor 3119€
Mac Mini M5 Pro 18CPU/20GPU 64 GB voor 3319€
Deze hebben beide 307 GB/s geheugen­bandbreedte

Maarja, met die prijzen kijk ik toch met een schuin oog naar een mac studio in de volgende configs:
Mac Studio M5 Max 18CPU/32GPU 36 GB voor 3019€ (goedkoper, maar ik vind te weinig geheugen)

Dus upgraden we het geheugen naar 48
Mac Studio M5 Max 18CPU/40GPU 48 GB voor 3689€ (flinke verhoging die boefjes, door een andere CPU. Maar 48 is denk ik nog steeds te weinig)
Mac Studio M5 Max 18CPU/40GPU 64 GB voor 4129€
Mac Studio M5 Max 18CPU/40GPU 128 GB voor 5889€
De max chip heeft 460 GB/s geheugen­band­breedte. (al lees ik dat dit meer rond de 600 zou liggen en een foutje is op de website van apple?)

Maar we zitten nu al tegen de 6k aan te schuren. Want 1.2 TB geheugenbandbreedte lonkt dan ook:
Mac Studio M5 Ultra 30CPU/64GPU 96 GB voor 6649€

En dan mijn probleem, ik ben echt op zoek naar een local oplossing vooral vanwege privacy en geen token afrekenen. Maar ik heb echt moeite met de line-up van Apple op dit moment. Want als je voor de duurdere studio gaat dan moet je dat ook weer afzetten tegen subscriptions met modellen die nu nog wel beter zijn dan de lokale oplossingen.

Ik mis eigenlijk een M6 pro mac mini met 128 gb geheugen. Dit is echt des apples om het onmogelijk te maken de juiste machine te kiezen zonder fomo van had ik maar. Het wordt een headless machine bij mijn netwerk spul. Dus is puur voor local AI.

Ik ben heel benieuwd hoe jullie hierover denken. Ik ben menig youtube video verder maar echt een knoop doorhakken lukt me niet. Ik ben zelfs zo ver dat ik toch subscriptions ga proberen met een aantal niet privacy-dingen. Maar dan moet je toch snel per token afrekenen als je met api's wil werken.

Kortom, wat te doen. Waar doe ik goed aan voor agentic coding, koppelen aan Home assistant en n8n en mogelijk nog andere leuke use-cases.

[CT]

@Ferrox1 Maar bijv. een Mac Studio M5 Ultra waar je bijna 7k voor betaald, loopt niet sneller (misschien zelfs trager) kwa token/s als bijv. mijn opstelling (2x 3080) dat mij nog geen 1k heeft gekost (incl pc er omheen) met Qwen 3.8 Q8.

Ik zou dus eerder ook eerst kijken wat je nu precies wilt gaan draaien kwa modellen, en welke snelheid en dan daar je hardware op afstemmen.

[-Jaap-io]

@Ferrox1 je kan natuurlijk ook 2 mac mini's kopen met 32gb en dan via nvidia PAIR koppelen

[Vishari Beduk]

kazuka schreef op vrijdag 4 september 2026 @ 13:40:
Hier ook aan het experimenteren met verschillende lokale AI modellen nadat ik al een poosje bezig was met ComfyUI voor afbeeldingen en videos. Heb nu Qwen3.8 27B draaien in nvfp4 versie op mijn RTX 5090, doet het behoorlijk goed! Mooi om te zien dat de ontwikkelingen best rap gaan, dus ben benieuwd naar toekomstige releases.

Heb het geluk dat mijn werkgever AI volop promoot en pushed voor haar medewerkers dus wij hebben een Hyperspace AI proxy draaien en iedereen krijgt 500 EUR aan tokens per maand. Kan daarmee verschillende modellen en agents gebruiken dus nu bezig met Codex and GPT 5.6 Sol voor het zwaardere werk en Qwen als lokaal model voor de wat eenvoudigere dingen.

Zag toevallig dit net voorbijkomen: https://www.nvidia.com/en-us/ai-on-rtx/personal-ai-router/

[Afbeelding]

Je kunt hiermee je personal computing power over verschillende apparaten (RTX en Macs bijvoorbeeld) combineren voor gebruik met AI modellen. Eens kijken of ik dit aan de praat krijg. Zou hiermee mijn RTX 5090 kunnen combineren met mijn persoonlijke M4 Air en zakelijke M5 Pro.

Nu is het wel off-topic in the zelf host topic, maar ik er ben wel erg verbaasd over jouw 500 euro per maand per persoon. Wat een extreem hoog bedrag.
Ik heb zelf een 20 euro abbo van Claude en krijg het gewoon niet op. Gebruik dan wel eigenlijk altijd 'gewoon' opus maar toch.
En de reden dat ik mijn Claude tokens momenteel niet op krijg is ook de reden waarom ik (nog) niet zelf host.

[Deepflame]

Vishari Beduk schreef op vrijdag 4 september 2026 @ 17:51:
[...]

Nu is het wel off-topic in the zelf host topic, maar ik er ben wel erg verbaasd over jouw 500 euro per maand per persoon. Wat een extreem hoog bedrag.
Ik heb zelf een 20 euro abbo van Claude en krijg het gewoon niet op. Gebruik dan wel eigenlijk altijd 'gewoon' opus maar toch.
En de reden dat ik mijn Claude tokens momenteel niet op krijg is ook de reden waarom ik (nog) niet zelf host.

Ik had een tijdje 20e abbo van Claude en dat was in een dag al op. Ik heb nu de 100e abbo bij OpenAI en ook die krijg ik periodiek wel opgemaakt.

[hybride]

Deepseek V4 flash cloud is momenteel erg goedkoop in de daluren (en erg goed vind ik) Ik vraag me dan een beetje af wat een lokaal draaiend model -met minder kracht- nog aan extra voordelen/functie biedt? Ik kan ze nog niet goed ontdekken.

[scoobs]

Lokaal lijkt vooral een kwestie van flinke pipelines automatisch op de achtergrond hebben draaien, asap nieuwe modellen kunnen proberen, een stukje privacy (eurouter biedt ook maar een beperkte hoeveelheid modellen aan) of gewoon de techniek eronder willen snappen.

[kazuka]

Deepflame schreef op vrijdag 4 september 2026 @ 18:59:
[...]

Ik had een tijdje 20e abbo van Claude en dat was in een dag al op. Ik heb nu de 100e abbo bij OpenAI en ook die krijg ik periodiek wel opgemaakt.

Ja, vooral met de frontier modellen gaat het hard. 500 EUR per maand van de baas vind ik ook wel veel maar he, ik klaag niet Maar het zal niet voor niets zijn dat ze ook kijken naar open en lokale models. Ook op mijn werk evalueren ze nu modellen als Qwen.

hybride schreef op vrijdag 4 september 2026 @ 20:57:
Deepseek V4 flash cloud is momenteel erg goedkoop in de daluren (en erg goed vind ik) Ik vraag me dan een beetje af wat een lokaal draaiend model -met minder kracht- nog aan extra voordelen/functie biedt? Ik kan ze nog niet goed ontdekken.

Privacy. En vooral de snelle ontwikkeling van lokale modellen vind ik interessant. Hoe slimmer ze elke paar maanden worden hoe minder je (hopelijk) hoeft te doen met dure cloud modellen. Ben benieuwd waar we over een jaar staan.

[Deepflame]

Naast privacy, zijn er nog twee punten voor lokaal AI draaien:

Allereerst, on-the-go compute, niet iedereen heeft altijd internet, als je veel in remote locaties werkt, zoals in het midden van de bossen in Finland of de woestijn in Australië, daar heb je meestal geen 5G. Niet echt een probleem hier in het midden van Nederland, tenzij je in de Schiphol tunnel woont. x)

Daarnaast ook het niveau van taak acceptatie. Ik vroeg DeepSeek V4 Flash ooit eens een opvolger voor Carmageddon te designen, het model begon te klagen dat ie niet aan zinloos geweld wilde bijdragen, en stelde een mario kart voor. Toen een abliterated versie van DSV4Flash gepakt, en die had er geen problemen mee.

[CT]

Voor mij is het;

- privacy & censuur (vanzelf sprekend) zolang als ik develop ben ik gewend dat mijn tools in mijn beheer zijn en ik zelf bepaal wat ik 'het web' op stuur en verwacht geen 'mening' terug

- continuiteit ; leuk als een cloud dienst nu 1 euro kost, maar morgen kosten ze misschien 100 etc.

- stabiliteit ; leuk dat een dienst nu model X aanbied, maar morgen kan deze verdwenen zijn..

En uberhaupt het gevoel van dat het nieuwe normaal lijkt te zijn totaal afhankelijk voor development te zijn van iets dat extern beheerd wordt zonder fallback naar lokaal is iets dat mij een enorm unheimlich gevoel geeft dat ik het ook niet zou kunnen..

Maar ik heb ook mijn eigen NAS, host mijn eigen 'Cloud' (hardware) en draai GrapheneOS als enige sane-default (als je nog mee wilt doen met de maatschappij, app verplichting, wat weer een andere discussie is).

Persoonlijk had ik gehoopt dat de overheid, bedrijven en ook individuen veel kritischer zouden zijn, ene kant roept iedereen voor EU alternatieven (en erbij dat we te laat zijn, te blind, te langzaam, teveel meelopen) aan de andere kant is alles naar OpenAI/Anthropics opsturen dood normaal (helaas).

[dmantione]

Voor mij is lokale KI de toekomst, maar geef ik mij even gewonnen aan de cloud: Mijn uitgaven aan KI-diensten tot nog toe €20, dat tegoed is nog lang niet op, en dan is het lastig te verantwoorden duizenden euro's aan een RTX6000, DGX Spark of Ryzen Halo uit te geven. Met minder hoge eisen is ook een RTX5090 allesbehalve gratis. Dat dat het gevolg is van een zeepbel met enorme hoeveelheden durfkapitaal spreekt voor zich, maar zo lang je gratis of laaggeprijsde service kunt krijgen, moet je kijken hoe je dat in je voordeel kunt gebruiken. Lokale KI is voor mij voorlopig wél experimenteren, maar niet investeren. Niet afhankelijk worden, wel je voordeel doen.

Zoals je in mijn bijdrage in het Opencode-draadje kunt lezen probeer ik een manier van werken te ontwikkelen die gratis diensten, betaald en privacyveilig combineert: Dus niet al je data naar één aanbieder sturen, maar per situatie bekijken wel model bij welke aanbieder daarvoor de goed keus is.

Dat gezegd, zodra de hardware nog wat beter wordt, weer wat betaalbaarder wordt, wordt lokale KI hier de standaard. Omdat het de juiste beslissing is om je data in eigen hand te houden en omdat we Tweakers zijn die de kennis hebben om technologisch zelfstandig te zijn. En daarmee hebben we ook een soort morele licht om de weg te verkennen voor de rest van de samenleving.

[eheijnen]

Zoals de hybrid cloud zich ontwikkelt kan het goed zijn dat AI daar een onderdeel in het aanbod van hyper-scalers zal gaan vormen. Daarnaast kan het goed zijn dat er onprem AI oplossingen komen die in het geheel en naar wens af te regelen zijn.

Privacy, geheimhouding en volledige controle zal voor bepaalde spelers een grote rol innemen. Dat zie je op dit moment in relatie tot de "gewone" cloud ook al.

Dat lijkt me een redelijk globaal beeld voor de komende jaren.