Ervaringen met zelf gehoste AI assistenten

[Felicia]

CSB schreef op zaterdag 5 september 2026 @ 18:54:
[...]

Ik draai Qwen 3.6 35B A3B op mijn 12 GB RTX4070S i.c.m. Hermes. Is goed te doen met 32GB DDR5 hoor, zolang je niet hoger gaat dan Q8 en 128k context. Het is echter wel het maximale wat ik kan bereiken waarschijnlijk. Tenzij er een significante softwarematige upgrade gaat plaatsvinden, want hardware upgraden zit er voorlopig gewoon niet in.

Ik ben benieuwd wat je performance dan is, kan me niet voorstellen dat decode meer dan 20 tp/sec is?

[hybride]

CSB schreef op zaterdag 5 september 2026 @ 18:54:
[...]

Ik draai Qwen 3.6 35B A3B op mijn 12 GB RTX4070S i.c.m. Hermes. Is goed te doen met 32GB DDR5 hoor, zolang je niet hoger gaat dan Q8 en 128k context. Het is echter wel het maximale wat ik kan bereiken waarschijnlijk. Tenzij er een significante softwarematige upgrade gaat plaatsvinden, want hardware upgraden zit er voorlopig gewoon niet in.

Interessant! Welke build gebruik je precies? Niet alle builds van een model draaien goed met Hermes heb ik gemerkt. Je krijgt soms vraagtekens ????????? Als output.

[Ferrox1]

CT schreef op vrijdag 4 september 2026 @ 15:00:
@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.

Hmm, klinkt interessant. Ik ben daar ingedoken. Maar tegenwoordig kost zo'n systeem ook behoorlijk wat en is tegenwoordig niet persee goedkoper dan een mac. Wanneer heb je dit systeem gekocht? voor de ram verhogingen? Zeker als je stroomverbruik van 4 jaar meeneemt is het niet persee goedkoper meer. Ik ga dit namelijk zakelijk aanschaffen en dat maakt de keuze wat beperkt, en moet het op basis van retailprijzen.

Inmiddels ben ik er ook achter waar het verschil zit bij de M5 Max modellen. Als je op de bestelpagina klikt op de "Hulp nodig bij het kiezen van een chip" zie je dat het als volgt is:

Mac Studio M5 Max 18CPU/32GPU (460 GB/s geheugen­bandbreedte) 64 GB voor 4129€
Mac Studio M5 Max 18CPU/40GPU (614 GB/s geheugen­bandbreedte) 128 GB voor 5889€

Dan ga ik toch denken, wellicht is de mac mini m5 pro 18CPU/20GPU en 64GB gewoon voldoende voor mij (€ 3.339). Maar ik vind dit zo lastig inschatten omdat je niet even ervaring op kan doen met de machine. Er even mee werken of het voor mij werkbaar is.

Overigens kwam deze ook omhoog als goede kanshebber met deze prijzen: https://tweakers.net/pric...ascent-gx10-gg0003bn.html
Alleen maar 273GB/s geheugen bandbreedte, dat doet apple dan weer beter...

[ Voor 7% gewijzigd door Ferrox1 op 06-09-2026 11:30 ]

[CT]

@Ferrox1 ja als je het zakelijk gaat gebruiken en niet hobby is het een ander verhaal, ik heb mijn kaarten "2e hands" gekocht en zijn nu denk ik wel 150euro p/s duurder dan toen, maar dit is zonder echt nuttige garantie etc.etc.
Tevens kan je Nvidia kaarten prima kwa gebruik halveren als het om Inference gaat, de specs van bijv. 400 of 700watt zijn gehalveerd net zoveel als een M5 op volle toeren, dus stroomgebruik is niet 1op1 te vergelijken.

Over stroom gebruik gesproken, als je het hebt over 4 jaar full-load zakelijk gebruik, weet ik niet of een M5 gemaakt is voor deze workload, nvidia heeft niet voor niks bijv. de ADA lijn kaarten die je in een rack kan plaatsen met constante cooling weg van je buro en geschikt is voor lange workloads, ik zou dan eerder naar zo'n oplossing uitwijken maar dan hebben we het al wel weer over 5k+ prijskaartjes.

[Ferrox1]

@CT Klopt inderdaad wat je zegt. Waar ik vooral op zoek naar ben is een sweet-spot. Hoeveel geheugen hebben jouw kaarten nu bij elkaar?

Waar ik mee zit, ik heb gepoogd de Q4 versie te laden op mijn macbook pro M1 Max 32GB. Maar dat vond hij niet zo leuk. de 3.6 Q4 laadde wel en was traaaaaaag. Maargoed, het is ook M1 die daar nog niet voor geoptimaliseerd was. Tevens heeft deze macbook wel 400GB/s Geheugen bandbreedte. Dat is mijn referentie op dit moment.

Ik ben op zoek naar iets snellers (hoeft niet monsterlijk snel want terwijl hij bezig is kan ik gerust wat anders doen), kan de 3.8 laden met flinke context. Als 64GB geheugen voldoende is, neig ik heel snel naar de mac mini. Is dit echt onvoldoende, dan zal ik naar een studio gaan.

Ja, helaas is het niet mogelijk om 2e hands te gaan shoppen in dit geval. Een echte rack server voel ik niet zoveel voor omdat ik ook kijk naar eventueel 2e hands waarde. Van de mac zijn deze redelijk oke omdat ze ook prive nog goed in te zetten zijn i.t.t. een rack server, dat is meer niche markt.

Hij zal niet 24/7 stampen. Maar wel 24/7 aan. Dus idle verbruik is ook belangrijk en daar lopen de 2 oplossingen wel flink uiteen. Hij staat altijd klaar voor 10 watt/uur. Een samengestelde build zit snel op het veelvoudige daarvan. Niet een dealbreaker maar dan moet de prijs ook daarnaar zijn en dat is op dit moment niet.

Ik kan ook nog wachten op benchmarks, wellicht dat het mijn keuze dan vergemakkelijkt. want ik denk dat die er genoeg zullen komen.

[R3m3d7]

Ik zou mij comfortabel voelen om een mac studio 24/7 LLM load te geven zolang je maar de fancurve aanpast, daar is een app voor (kost een paar euro). Standaard gaat hij pas bij hele hoge temps echt blazen, dat geeft mij een wat minder fijn gevoel. Ik verwacht dat de M5 ultra een heel erg leuke llm bak gaat worden, tot (ik geloof) 4x de prefil snelheid tov de M3 ultra maakt hem echt goed bruikbaar als dat in de praktijk ook echt zo uitpakt. Op inference gaat hij iig rap worden met z'n 1,2TB/s.

[ocf81]

DeNachtwacht schreef op zaterdag 5 september 2026 @ 15:55:
[...]

Ik denk dat alles staat of valt bij de ontwikkeling van de kleinere modellen. Als je ziet wat nu al met Qwen 3.8 27B mogelijk is, en 3.6 ook al heel goed werkbaar was, zou het best weleens kunnen zijn dat je met kleine gespecialiseerde modellen een heel eind moet kunnen komen met een 32GB videokaart. Gezien die ontwikkelingen bij kleine modellen zou het mij niet verbazen dat we langzaam met Qwen 5 ofzo ontdekken dat je voor 1 specifieke taak ook gewoon geen groot cloudmodel nodig hebt. 27B getraind op puur en alleen programmeren zou best weleens voldoende kunnen zijn. En voor je dagelijks gebruik heb je dan weer een ander 35B A3B model dat specifiek voor 'standaard zoekwerk' is oid.

Maar goed, die 32GB is inderdaad ook velen niet gegeven en de prijzen zijn daar echt belachelijk geworden de laatste tijd. Toen ik mijn 5090 kocht klaagden we hier allemaal hoe belachelijk het was dat nvidia er €2100 voor vroeg (nu is de 5K al gepasseer), en de komende tijd gaat dat waarschijnlijk niet veranderen.

Ben dus ook benieuwd of deze mooie droomtoekomstvisie dus ook werkelijkheid wordt. Maar even algemeen verzoek: is het een idee niet ook dit topic weer vol te laten lopen met toekomstvoorspellingen/gedachtes? Best interessant, en gelukkig blijft het hier wat technischer (en laten de mensen die reageren duidelijk zien daadwerkelijk verstand van zaken te hebben) maar ik vind het zelf wat jammer dat ook het AI subforum helemaal overloopt van de discussie- en meningstopics over AI in plaats van daadwerkelijke ervaringen met AI uitwisselen.

Wat de huidige situatie betreft heb je gelijk dat het nu nog kan. Voor de toekomst kan dat wel eens anders zijn. Je ziet nu dat steeds meer KI-bedrijven aan eigen chips gaan doen. Die trend is nu al een tijd lang zichtbaar. Google doet het al zo'n 10 jaar, maar o.a. Meta en OpenAI zijn nu ook van de partij. De modellen die wij gebruiken zitten in het kielzog van de meest vooruitstrevende modellen en maken over het algemeen gebruik van dezelfde technische grondslagen. De de vooruitstrevende modellen houden geen rekening met lokaal gebruik. Op een gegeven moment zou je dan dus een splitsing kunnen zien in modellen die nog op een GPU kunnen draaien en modellen die alleen nog kunnen werken als de hardwarematige versnellingen die in die KI chips verwerkt zitten aanwezig zijn.

[CT]

@Ferrox1 ik zou gewoon eerst data verzamelen, zo ben ik ook begonnen, met wat wil ik bereiken (usecase, welke quant + model) en met welke snelheid vind ik dat acceptabel (hoeveel time-to-first token en output tk/s verwacht ik uit mijn agent).

Dan een lijst met hardware oplossingen die reeel zijn om die usecase te vullen + snelheid van dat bepaalde model (incl context size e.d.) haalt door benchmarks te zoeken van dat specifieke model met quant.

Bij mij viel Mac als snel af omdat de input tokens enorm langzaam zijn (dus je wacht enorm lang (soms minuten..) tot de eerste output tokens eindelijk beginnen) en de output ligt ook significant lager (rond de 10 - 20 tk/s) dan een gelijkwaardig Nvidia alternatief (vaak 500-1000 input en 60 - 100 tk/s output).

[Zsub]

Ferrox1 schreef op zondag 6 september 2026 @ 12:02:
[...]

Ik heb een MacBook Pro met een M5 Max met 64GB en dat werkt. Is langzaam maar functioneel. Ik merk wel dat ik sneller naar Claude grijp als ik wil dat iets zeker ge-oneshot wordt of als het snel moet (en ik wil wel vaak snel, stiekem).

Draai nu Qwen3.8-27B erop en dat is gewoon best langzaam. Een MoE model zoals gps-oss-20b is beter, maar het blijft worstelen. Ik overweeg zelfs vrij serieus om deze MacBook te verkopen en daarvan GPUs te halen...

[DeNachtwacht]

Ik zou dat niet te snel doen in deze tijden. Dikke kans dat er binnenkort weer een MoE model uitkomt. Draai je wel het nvfp4 mlx formaat? Ollam heeft die iig en dat draait op de mac sneller.

[Zsub]

Het is de lm-studio 4bit quant in mlx vorm, dus ik denk het? In omp kan ik rollen aan modellen geven, dit is nu het plan, vision en slow model. De agentic loop draait op 3.6-35b-a3b op m'n 5070ti 16gb (waarvan alsnog de helft op de CPU draait) en die is echt significant sneller. Op m'n MacBook draait ook gpt-oss-20b als nvfp4 mlx in de advisor rol. Dus omp stuurt iedere turn daar nog een keer heen ter verificatie en bijsturen. best een mooi systeem zo.

[Salvatron]

Ik heb jan.ai gevonden, een open source alternatief voor lmstudio, werkt prima op linux, windows versie heb ik niet getest. Iemand hiermee bekend?

https://www.jan.ai/

In combinatie met gemma4 van google op de CPU (er zit geen aparte GPU in deze computer) geeft die prima antwoorden, scheelt niet veel met gemini zo te zien, kan alleen wel een paar minuten duren voordat het antwoord komt omdat die dus alleen op de CPU draait bij mij: 8 tokens/sec op een ryzen 5600g. Met een GPU zal het ongetwijfeld veel sneller gaan (30-40 tokens/sec of zo).

https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/

[CSB]

Felicia schreef op zaterdag 5 september 2026 @ 21:41:
[...]

Ik ben benieuwd wat je performance dan is, kan me niet voorstellen dat decode meer dan 20 tp/sec is?

Ik zou weer eens een testje moeten doen. Laatste keer haalde ik iets van 40/50 token/s in llama.cpp, maar dat zakt vrij snel in zodra de context volloopt.

Ik gebruik overigens Qwen3.6-35B-A3B-Uncensored-Genesis, speciaal getuned voor Hermes van LuffyTheFox op HF, met Llama.cpp op Windows. Heb wel een avondje zitten finetunen om hem zo te krijgen hoor.

[Ferrox1]

Zsub schreef op zondag 6 september 2026 @ 21:11:
[...]

Ik heb een MacBook Pro met een M5 Max met 64GB en dat werkt. Is langzaam maar functioneel. Ik merk wel dat ik sneller naar Claude grijp als ik wil dat iets zeker ge-oneshot wordt of als het snel moet (en ik wil wel vaak snel, stiekem).

Draai nu Qwen3.8-27B erop en dat is gewoon best langzaam. Een MoE model zoals gps-oss-20b is beter, maar het blijft worstelen. Ik overweeg zelfs vrij serieus om deze MacBook te verkopen en daarvan GPUs te halen...

Ik heb hier nu de q3 variant draaien op een M1 max. Maar dat is op zich wel te doen. geen monstersnelheden maar gewoon lekker pruttelen.

Overigens hadden mijn 2 browsers (Arc en Safari) beiden samen ruim 14 gig geheugen in gebruik inmiddels. Dus dat kan ook een bottleneck zijn geweest voor de Q4 variant.

Ook gespeeld met Chatgpt codex met astra 6. (nu tijdelijk een maand gratis voor nieuwe gebruikers) Maar die bouwt gewoon direct wat ik wil. Echt indrukwekkend. Nu hoeft het geen one-shot te zijn als lokaal wat langer duurt. Maar ik denk dat opencode met Qwen voor mij nog niet helemaal doet wat het moet doen. (of ik ben niet goed gestart, ben nog lerende daarin). Maar hij bouwt wel iets werkends.

[Ferrox1]

Ik kwam deze tegen: https://www.theaibridges.com/tools/llm-sizer

Hierin kun je alle mac's zetten en een DGX spark. Leuk tooltje om uit te rekenen wat er past kwa LLM's en context. En plotseling wordt de Mac Studio Ultra 96 GB toch wel interessant.

[R3m3d7]

Ferrox1 schreef op dinsdag 8 september 2026 @ 10:37:
Ik kwam deze tegen: https://www.theaibridges.com/tools/llm-sizer

Hierin kun je alle mac's zetten en een DGX spark. Leuk tooltje om uit te rekenen wat er past kwa LLM's en context. En plotseling wordt de Mac Studio Ultra 96 GB toch wel interessant.

Die idd wel handig, naar welke modellen kijk jij die goed passen met de 96GB?

[Ferrox1]

De reden dat hij interessant wordt is vooral zijn zeer snelle geheugen bus en het dat modellen steeds slimmer/beter worden voor hun grootte. Je kunt vrij snel met het tooltje zien wat er past. Ik kan ook nog een memory stretch doen omdat hij headless zal gaan draaien. Dus dan worden Q8 modellen ook mogelijk. Deze passen:

Qwen 3.8 27B Q8_0 · 256K
Qwen3-Coder-Next Q8_0 · 256K (maar net, dus waarschijnlijk moet ik hier wel naar Q6 toe)
Qwen 3.8 Flash Next UD-Q2_K_XL · 32K (dit is wel even afwachten of dit wel verbetert tegenover de 27B variant).

Ik zoek eigenlijk nog een goede agentic coder voor die grootte. Hopelijk komt er nog een goede qwen4-coder uit. Ik weet niet of iemand anders nog een goede weet voor de grootte.

De M5 Max met 128 GB is ongeveer net zo duur, alleen de helft van de snelheid. Dus als je de modellen kiest die in 96GB passen draait hij wel bijna 2x zo snel voor bijna hetzelfde geld.

[R3m3d7]

Ferrox1 schreef op dinsdag 8 september 2026 @ 14:44:
De reden dat hij interessant wordt is vooral zijn zeer snelle geheugen bus en het dat modellen steeds slimmer/beter worden voor hun grootte. Je kunt vrij snel met het tooltje zien wat er past. Ik kan ook nog een memory stretch doen omdat hij headless zal gaan draaien. Dus dan worden Q8 modellen ook mogelijk. Deze passen:

Qwen 3.8 27B Q8_0 · 256K
Qwen3-Coder-Next Q8_0 · 256K (maar net, dus waarschijnlijk moet ik hier wel naar Q6 toe)
Qwen 3.8 Flash Next UD-Q2_K_XL · 32K (dit is wel even afwachten of dit wel verbetert tegenover de 27B variant).

Ik zoek eigenlijk nog een goede agentic coder voor die grootte. Hopelijk komt er nog een goede qwen4-coder uit. Ik weet niet of iemand anders nog een goede weet voor de grootte.

De M5 Max met 128 GB is ongeveer net zo duur, alleen de helft van de snelheid. Dus als je de modellen kiest die in 96GB passen draait hij wel bijna 2x zo snel voor bijna hetzelfde geld.

Ik zou het lastig vinden om voor 96GB te gaan ipv 128GB want ik zie veel van de wat grotere modellen richting moe architecturen gaan en dan lijkt mij de snelheid van de M5 pro wel voldoende voor mij en geef mij maar dan iets meer context of wellicht zelfs een iets hogere quant. Het blijft een lastige keuze.

[Ferrox1]

R3m3d7 schreef op dinsdag 8 september 2026 @ 17:35:
[...]

Ik zou het lastig vinden om voor 96GB te gaan ipv 128GB want ik zie veel van de wat grotere modellen richting moe architecturen gaan en dan lijkt mij de snelheid van de M5 pro wel voldoende voor mij en geef mij maar dan iets meer context of wellicht zelfs een iets hogere quant. Het blijft een lastige keuze.

Klopt, maar dan moet je eigenlijk naar 256GB. Het verschil tussen 96 en 128 is niet zo groot en maakt kwa model lijkt het minder uit. Ik weet niet of je voorbeelden hebt? Wat op 128 wel draait en niet op 96? (Let wel op dat als je de veiligheidsmarge moet pakken omdat het ook de machine is waar je op werkt dit wel een verschil maakt)

Edit: Na wat uitzoeken denk ik dat je toch wel gelijk hebt. Ik zie nu voorbeelden van de M5 Max Macbook Pro, met qwen3.8 flash. Het zou wel kunnen op 96 gb maar dan moet je het model en de context erg knijpen. Terwijl hij echt wel beter presteert dan de 27B. Op een 128GB draait het wel prima.

[ Voor 16% gewijzigd door Ferrox1 op 08-09-2026 22:02 ]

[_Apache_]

Als je generic reasoning wilt, (Gemma4, deepseek), dna heb je flinke hardware nodig.

Dan gaat het op mijn 1080Ti (11gb), niet zo vlot. Maar als je het juiste model kiest voor de juiste taak, vliegt het opeens vooruit.

Als ik wil vertalen, had deepseekR1:8b, ruim 2u nodig. En Gemma4 nog langer.

Maar translategemma4 (notabene obv gemma3), was in 10min klaar met 1200 regels.

[Zsub]

_Apache_ schreef op dinsdag 8 september 2026 @ 18:29:
Als je generic reasoning wilt, (Gemma4, deepseek), dna heb je flinke hardware nodig.

Dan gaat het op mijn 1080Ti (11gb), niet zo vlot. Maar als je het juiste model kiest voor de juiste taak, vliegt het opeens vooruit.

Als ik wil vertalen, had deepseekR1:8b, ruim 2u nodig. En Gemma4 nog langer.

Maar translate Gemma4 (notabene obv gemma3), was in 10min klaar met 1200 regels.

1080Ti gang! Ja je moet met die oude kaarten goed oppassen dat je model helemaal in vram past, dat je quant bij de hardware past, etc etc.

[_Apache_]

Zsub schreef op dinsdag 8 september 2026 @ 18:47:
[...]

1080Ti gang! Ja je moet met die oude kaarten goed oppassen dat je model helemaal in vram past, dat je quant bij de hardware past, etc etc.

Ja man, maar of het in een 1080Ti past, kan een frontier model mij dan weer prima vertellen (ja zo ben ik dan weer wel).

Ik gebruik de 1080Ti bijv ook om films van ondertitels te voorzien. Eerst van gesproken engels naar Engelse ondertitels. Het whisper model past net (~10GB), en werkt een film af in 4-5x de afspeelsnelheid. En dan maakt translategemma er in een paar minuten een Nederlandse van.

[Zsub]

Ooooh whisper is ook een hele goeie! Nooit aan gedacht, was veel te veel op llms gefocust.

[apollo13]

Vanavond eens aan het spelen geweest met Omnivoice, een TTS tool. Wauw, wat een verschil met de Qwen TTS versie.
Heb het eerste hoofdstuk van mijn boek, de Engelse versie, laten omzetten naar spraak. Ominivoice deed dat in iets meer dan 5 minuten.De totale output van de audio lengte van het hoofdstuk was 21 minuten en 20 seconden.

Ik had eerst een stem gecloned, die van Stephen Fry. Hij is dus de verteller van hoofdstuk 1. Neem wel de regels van Omnivoice in acht: als je stemmen van bekende personen gebruikt, mag je dit alleen lokaal doen en zonder commerciële doeleinden.
Het uiteindelijke resultaat is echt behoorlijk natuurlijk. Geen robot stem, maar eentje met wat emoties en een goede cadans.

Daarna een test gedaan met de NL versie van mijn boek. Dit met een BN'r. Dit resultaat was minder. Geen robot stem, maar wel een stuk vlakker dan de Engelse versie. Het lijkt erop dat de NL-spraak nog wat finetuning nodig heeft in het model van Omnivoice.
Oh, en Omnivoice heeft meer dan 600 talen in zijn gereedschapskist zitten. En omnivoice draait al soepel op een 8GB videokaart of eentje met meer natuurlijk.

Heb ook de stem van Stephen Fry gebruikt voor de NL-versie, hij krijgt dan een sterk Zuid-Afrikaans accent

Gebruikte hardware:AMD 9 9900X, 16GB intern geheugen en een Nvida 4070 OC.

Edit: Hoofdstuk 1 is 3458 woorden lang.

[kazuka]

apollo13 schreef op dinsdag 8 september 2026 @ 22:34:
Vanavond eens aan het spelen geweest met Omnivoice, een TTS tool. Wauw, wat een verschil met de Qwen TTS versie.
Heb het eerste hoofdstuk van mijn boek, de Engelse versie, laten omzetten naar spraak. Ominivoice deed dat in iets meer dan 5 minuten.De totale output van de audio lengte van het hoofdstuk was 21 minuten en 20 seconden.

Ik had eerst een stem gecloned, die van Stephen Fry. Hij is dus de verteller van hoofdstuk 1. Neem wel de regels van Omnivoice in acht: als je stemmen van bekende personen gebruikt, mag je dit alleen lokaal doen en zonder commerciële doeleinden.
Het uiteindelijke resultaat is echt behoorlijk natuurlijk. Geen robot stem, maar eentje met wat emoties en een goede cadans.

Daarna een test gedaan met de NL versie van mijn boek. Dit met een BN'r. Dit resultaat was minder. Geen robot stem, maar wel een stuk vlakker dan de Engelse versie. Het lijkt erop dat de NL-spraak nog wat finetuning nodig heeft in het model van Omnivoice.
Oh, en Omnivoice heeft meer dan 600 talen in zijn gereedschapskist zitten. En omnivoice draait al soepel op een 8GB videokaart of eentje met meer natuurlijk.

Heb ook de stem van Stephen Fry gebruikt voor de NL-versie, hij krijgt dan een sterk Zuid-Afrikaans accent

Gebruikte hardware:AMD 9 9900X, 16GB intern geheugen en een Nvida 4070 OC.

Ha, toevallig was ik deze week ook aan het spelen met een aantal TTS modellen voor een projectje. ben zelf uiteindelijk uitgekomen op Chatterbox: https://huggingface.co/sp...erbox-Multilingual-TTS-V3

De lokale TTS modellen zijn best goed geworden moet ik zeggen.

[_Apache_]

apollo13 schreef op dinsdag 8 september 2026 @ 22:34:
Vanavond eens aan het spelen geweest met Omnivoice, een TTS tool. Wauw, wat een verschil met de Qwen TTS versie.
Heb het eerste hoofdstuk van mijn boek, de Engelse versie, laten omzetten naar spraak. Ominivoice deed dat in iets meer dan 5 minuten.De totale output van de audio lengte van het hoofdstuk was 21 minuten en 20 seconden.

Ik had eerst een stem gecloned, die van Stephen Fry. Hij is dus de verteller van hoofdstuk 1. Neem wel de regels van Omnivoice in acht: als je stemmen van bekende personen gebruikt, mag je dit alleen lokaal doen en zonder commerciële doeleinden.
Het uiteindelijke resultaat is echt behoorlijk natuurlijk. Geen robot stem, maar eentje met wat emoties en een goede cadans.

Daarna een test gedaan met de NL versie van mijn boek. Dit met een BN'r. Dit resultaat was minder. Geen robot stem, maar wel een stuk vlakker dan de Engelse versie. Het lijkt erop dat de NL-spraak nog wat finetuning nodig heeft in het model van Omnivoice.
Oh, en Omnivoice heeft meer dan 600 talen in zijn gereedschapskist zitten. En omnivoice draait al soepel op een 8GB videokaart of eentje met meer natuurlijk.

Heb ook de stem van Stephen Fry gebruikt voor de NL-versie, hij krijgt dan een sterk Zuid-Afrikaans accent

Gebruikte hardware:AMD 9 9900X, 16GB intern geheugen en een Nvida 4070 OC.

Edit: Hoofdstuk 1 is 3458 woorden lang.

Kokoro al eens geprobeerd?

[R3m3d7]

Ferrox1 schreef op dinsdag 8 september 2026 @ 18:06:
[...]

Klopt, maar dan moet je eigenlijk naar 256GB. Het verschil tussen 96 en 128 is niet zo groot en maakt kwa model lijkt het minder uit. Ik weet niet of je voorbeelden hebt? Wat op 128 wel draait en niet op 96? (Let wel op dat als je de veiligheidsmarge moet pakken omdat het ook de machine is waar je op werkt dit wel een verschil maakt)

Edit: Na wat uitzoeken denk ik dat je toch wel gelijk hebt. Ik zie nu voorbeelden van de M5 Max Macbook Pro, met qwen3.8 flash. Het zou wel kunnen op 96 gb maar dan moet je het model en de context erg knijpen. Terwijl hij echt wel beter presteert dan de 27B. Op een 128GB draait het wel prima.

Ik zit ook te puzzelen hoor en ben er nog niet uit. Ik wil heel graag thuis met llm's spelen maar worstel met de keuze voor de hardware. Ik wil niet te beperkt zijn in model keuze en merk dat als ik modellen via openrouter gebruik ik pas echt het gevoel heb dat het aansluit bij wat ik zoek als ik rond de deepseek /GLM flash modellen zit, dat voelt als volwaardig. Ik laat gpt Sol mij interviewen voor een idee en het spec doc schrijven en in stuken knippen en vervolgens kan een van die flash modellen en prima mee uit de voeten. En wat blijkt, de nieuwe 4.1 flash van deepseek vraagt weer meer (v)ram, 256GB is niet meer voldoende. Als ik dan een 256GB mac zou hebben gekocht zou ik daarvan balen. Maar aangezien die voor mij teveel geld kost zal dat probleem zich niet gaan voordoen.

[CSB]

R3m3d7 schreef op zaterdag 12 september 2026 @ 09:00:
[...]

Ik zit ook te puzzelen hoor en ben er nog niet uit. Ik wil heel graag thuis met llm's spelen maar worstel met de keuze voor de hardware. Ik wil niet te beperkt zijn in model keuze en merk dat als ik modellen via openrouter gebruik ik pas echt het gevoel heb dat het aansluit bij wat ik zoek als ik rond de deepseek /GLM flash modellen zit, dat voelt als volwaardig. Ik laat gpt Sol mij interviewen voor een idee en het spec doc schrijven en in stuken knippen en vervolgens kan een van die flash modellen en prima mee uit de voeten. En wat blijkt, de nieuwe 4.1 flash van deepseek vraagt weer meer (v)ram, 256GB is niet meer voldoende. Als ik dan een 256GB mac zou hebben gekocht zou ik daarvan balen. Maar aangezien die voor mij teveel geld kost zal dat probleem zich niet gaan voordoen.

Ja zo blijf je natuurlijk altijd afwachten tot er iets nieuwers of beters uitkomt. Uiteindelijk zul je de knoop moeten doorhakken.

Ik begrijp je worsteling hoor. Ik heb hetzelfde, maar meer met "wil ik 2000+ euro uitgeven aan een machine puur voor inferencing die trager gaat zijn dan mijn huidige PC/GPU maar meer VRAM heeft dus grotere modellen kan draaien?" Op dit moment; nee. Maar het hangt erom want sinds Nous Hermes erbij is gekomen is het hobbyprojectje wel echt naar een hoger niveau getild.

Ben wel benieuwd naar jullie ervaring of keuzes hieromtrent.

[R3m3d7]

CSB schreef op zondag 13 september 2026 @ 10:01:
[...]

Ja zo blijf je natuurlijk altijd afwachten tot er iets nieuwers of beters uitkomt. Uiteindelijk zul je de knoop moeten doorhakken.

Ik begrijp je worsteling hoor. Ik heb hetzelfde, maar meer met "wil ik 2000+ euro uitgeven aan een machine puur voor inferencing die trager gaat zijn dan mijn huidige PC/GPU maar meer VRAM heeft dus grotere modellen kan draaien?" Op dit moment; nee. Maar het hangt erom want sinds Nous Hermes erbij is gekomen is het hobbyprojectje wel echt naar een hoger niveau getild.

Ben wel benieuwd naar jullie ervaring of keuzes hieromtrent.

I know I know, maar ik vrees dat 256-512GB is waar ik op dit moment wil zitten voor het niveau van Deepseek flash 4.1 / GLM Flash. Ik vond deepseek 4.0 al goed maar dan moest ik nog naar GPT Sol grijpen voor wat lastigere problemen en dat hoeft met 4.1 niet meer met wat ik doe. Ik gebruik GPT Sol alleen nog mij te interviewen en op basis daarvan een spec doc te schrijven, daarin is Deepseek flash niet zo goed (minder creatief imho), maar al het programmeren kan nu 100% door deepseek worden gedaan. Balen dat dit niet meer past in 256GB want daar was ik mij een beetje op aan het richten. Het zou natuurlijk kunnen dat de volgende qwen 4 release dit weer binnen 128GB weet te doen door ngram'se etc en dan heb ik weer teveel geld uit gegeven . Maar het begint bij het bepalen van wat je verwacht van je model en de hardware moet dat ondersteunen en deepseek flash 4.1 is het eerste opensource model wat enigsinds binnen handbereik ligt voor thuis draaien waarvan ik zeg dat het voor mij echt goed genoeg is met programmeren. Wat ik denk dat er gaat gebeuren is dat ik deepseek via de API blijf gebruiken voor 3-4 tientjes per maand tot een kleiner model op dat niveau zit en ik dat op een 128GB mac kan draaien, en dan schieten de prijzen hiervan verder omhoog en baal ik dat ik hem niet eerder heb gekocht.

[Ferrox1]

Haha @R3m3d7 , zo herkenbaar dit. En inderdaad @CSB , je moet ergens een knoop doorhakken, helemaal mee eens. Probleem is alleen dat nagenoeg niet in te schatten is wat de hardware prijzen gaan doen. Als je dezelfde machine voor de prijs van 2 jaar geleden kan kopen was het echt een no-brainer geweest. Er gaan ook geruchten te ronde dat dit expres wordt gedaan door AI boeren om te voorkomen dat je lokaal gaat. Iets wat China dus wel als ambitie heeft en meer ziet (zo lijkt hun strategie) in het verkopen van hardware voor de modellen.

Wat ook nog te ronde gaat is natuurlijk de AI bubbel. Wanneer gaat die knappen want ik gebruik nu voor 20€ per maand de GTP astra en andere modellen. Maar je gaat mij niet wijs maken dat er überhaupt verdiend wordt op mijn gebruik. En dan heb je nog de verhalen van het uitbreken, AGI en tijdelijk sluiten van nieuwe accounts. In mijn optiek is dit allemaal voor de Buhne om geld aan te blijven trekken. Ook is China bezig om zelf machines te bouwen om meer RAM te kunnen produceren (zie het gedoe rondom ASML).

Het blijft lastig te voorspellen wat het gaat doen. We hebben het wel vaker gehad met bijvoorbeeld de aardbeving bij Taiwan dat de fabrieken even dicht moesten. Dit gaf ook een spike in de prijzen maar daar zat een duidelijk einde aan. Het geld zit nu ook vooral in een aantal grote Amerikaanse bedrijven. Ook dat kan niet goed blijven gaan. Als er 1 gaat, gaan ze met z'n allen.

Mijn grootste zorg is wel privacy en data eigenaarschap. En wat mag dat kosten? Wat gebeurd er als zo'n AI boer met mijn idee gaat wandelen? Ik denk dat dit onbetaalbaar is. Maarja, ik zit dan ook in die hoek en hecht daar heel veel waarde aan.

[Felicia]

Ferrox1 schreef op zondag 13 september 2026 @ 11:09:Mijn grootste zorg is wel privacy en data eigenaarschap. En wat mag dat kosten? Wat gebeurd er als zo'n AI boer met mijn idee gaat wandelen? Ik denk dat dit onbetaalbaar is. Maarja, ik zit dan ook in die hoek en hecht daar heel veel waarde aan.

Nouja, zie de rel van een Anthropic onderzoeker die uit z'n eigen research funds aan een probleem aan het werken is met OpenAI modellen. Vervolgens lijkt OpenAI daar lucht van te krijgen en gaat aan het zelfde probleem werken (Navier Stokes millenium problem) maar zegt in de publicatie expliciet dat ze geen user data van anderen hebben gebruikt voor het model en de oplossing

Het is dat je met AI geen lineage hebt waardoor je van a tot z kan bewijzen hoe je van bron tot eindproduct komt. Maar dat wil zo'n AI bouwer natuurlijk ook niet want dan weten de concurrenten precies wat ze als input hebben gebruikt om tot een model te komen

[CSB]

Ja dat is inderdaad het pijnpunt; met de prijzen van nu denk ik wel 2x na voordat ik overga tot aanschaf. En het zal ongetwijfeld zo zijn dat men wil voorkomen dat je lokaal gaat draaien want dan is het verdienmodel om zeep. Ik ben bang dat op korte termijn (lees: 1 a 2 jaar) niet veel zal veranderen in de prijzen, behalve nog meer stijgingen...

[gibraltar]

Een paar weken geleden heb ik een Framework Desktop (Strix Halo, 128GB) aangeschaft voor lokaal draaien van een LLM. Ik ben software engineer en had besloten dat ik niet langer om een lokaal model heen kan (ja ik weet dat cloud goedkoper is).

In de zoektocht had ik al snel bedacht dat je kan kiezen uit twee van drie: kwaliteit, snelheid en prijs. Een enorme investering zag ik niet direct zitten en kwaliteit is belangrijk genoeg dus ga ik snelheid inleveren. Resultaat is unified memory. Ik wil dat de aankoop later ook bruikbaar is en ik wil niet vastzitten aan Apple silicon, al geef ik graag toe dat die sneller en beter is.

Ondertussen draai ik met veel plezier Qwen3 Coder 30B in Q4 en sinds kort Qwen 3.8 Flash Next ook in 4 bits (via Halogen). Voorlopig is die laatste het maximum wat ik uit mijn 128GB ga kunnen persen.

De snelheid is een ding. Een paar weken geleden was het langzaam, ondertussen is het een stuk sneller dankzij aanpassingen in llama.cpp en nu Halogen. De winst zit vooral in optimalisatie gegeven de hardware (dat is wat Halogen doet) en dus is het aannemelijk dat deze verbeteringen uiteindelijk ook in de grotere inference engines komen.

Naast het model speelt de rest van je tooling minstens een zo grote rol. Context is een ding en voor mijn toepassing (agentic coding) zijn er allerlei manieren om de context klein en nuttig te houden. Neem je bijvoorbeeld Hermes of OpenCode op hetzelfde model dan krijg je hele andere ervaringen.

Het efficient omgaan met dit stuk gereedschap wordt dus een stuk belangrijker als je lokaal gaat werken. Zo kun je 20 iteraties vervangen door een tool-call.

[DeNachtwacht]

@gibraltar best slimme en redelijk betaalbare optie. Maar hoe krijg je Qwen 3.8 Flash Next in 128GB met context? Dat model is toch in Q4 al zo'n 120 GB? Heb je een Q4_S oid?

[gibraltar]

DeNachtwacht schreef op zondag 13 september 2026 @ 18:07:
@gibraltar best slimme en redelijk betaalbare optie. Maar hoe krijg je Qwen 3.8 Flash Next in 128GB met context? Dat model is toch in Q4 al zo'n 120 GB? Heb je een Q4_S oid?

Q4C-P om helemaal exact te zijn. Het klopt dat dit kantje boord is. Je kan er letterlijk niets naast draaien en het werkt alleen onder Linux vanwege dat laatste zetje. Ik gebruik nu Halogen als server vanwege de HIP kernels specifiek voor de Strix Halo geschreven. Dat maakt 'm bijzonder snel en geschikt als vervanging voor cloud-alternatieven. Ik heb ook een poosje recente versies van llama.cpp gebruikt en Halogen is toch een stuk sneller.

Voor mij is het geschikt als daily driver omdat ik relatief kleine taken heb en mijn sessie ruim past in de context.

[DeNachtwacht]

Huh, maar dan heb je toch helemaal geen ruimte meer voor je context? misschien 6 GB naast het OS zelf. Dat is voor programmeerwerk toch veel te weinig? (ik doe dat er niet mee, maar dat lees ik altijd).

[gibraltar]

DeNachtwacht schreef op zondag 13 september 2026 @ 20:07:
Huh, maar dan heb je toch helemaal geen ruimte meer voor je context? misschien 6 GB naast het OS zelf. Dat is voor programmeerwerk toch veel te weinig? (ik doe dat er niet mee, maar dat lees ik altijd).

Dat klopt normaal, maar je kan er ook voor kiezen een deel op de SSD te laten staan:

code:

memory: 68.0 GiB of weights locked in RAM, 14.4 GiB of KV pool, 21.3 GiB of working memory, 103.7 GiB in all
memory: the model's 47.7 GiB lookup table is NOT held in RAM. It is read from disk through the file cache as each request needs it, which is why this server holds less than the checkpoint is large

De lookup table is wat 'm normaal buiten de grenzen zou duwen. Linux cached dat welliswaar, maar dat zal niet geheel lukken. Dat zie ik ook terug. Daarom is er ook letterlijk geen ruimte voor wat anders.

[DeNachtwacht]

@gibraltar dank, dit is voor mij ook weer nieuw. Is dat voor dit model specifiek? En ik begrijp dus dat er 47.7GB niet in het DDR zit, maar op de SSD? Want dan zou je dus juist wél meer dan genoeg moeten hebben voor 256K context.

[gibraltar]

DeNachtwacht schreef op zondag 13 september 2026 @ 20:15:
@gibraltar dank, dit is voor mij ook weer nieuw. Is dat voor dit model specifiek? En ik begrijp dus dat er 47.7GB niet in het DDR zit, maar op de SSD? Want dan zou je dus juist wél meer dan genoeg moeten hebben voor 256K context.

Niet echt model specifiek, meer de aanpak van de inference server. Je moet wel een model topologie hebben die dit heeft, en dat is hier het geval. Een deel van die 47.7GB staat overigens wel in RAM gecached. Er zijn andere inference engines die aan iets vergelijkbaars werken (https://github.com/JustVugg/colibri). Vanzelfsprekend dodelijk voor de snelheid.

In tijden van RAM schaarste zul je meer zien dat mensen een weg uit "alles moet in VRAM" zoeken. Dan kom je weer op die kwaliteit, snelheid, prijs keuze. Omdat iedereen nu de prijs component begint te voelen ga je vanzelf de snelheid inleveren als je kwaliteit wil houden.

Ik heb heel specifiek de Strix Halo route gekozen met de insteek dat er wel iemand met een Claude abonnement een inference engine zou schrijven. Dat blijkt juist.

[ Voor 7% gewijzigd door gibraltar op 13-09-2026 20:23 ]

[DeNachtwacht]

Hmmm, ik zou misschien als ik jou was toch eens hiermee kijken hoe ver je komt:
https://huggingface.co/unsloth/Qwen3.8-Flash-Next-GGUF/tree/main

Met Q3/Q2 lever je wat performance in maar ik ben dan wel benieuwd of de snelheidswinst dat niet waard is.

Ik wil zelf nog een keer kijken hoe ver je met een RTX 5090 komt met de Q1, her en der is te lezen dat je toch wel 40-50 Tokens eruit kan krijgen.

Stiekem blijf ik echter hopen op een Qwen 50B/60B MoE model (5B ofzo) dat zou voor de 5090 bezitters echt top zijn.

[gibraltar]

DeNachtwacht schreef op zondag 13 september 2026 @ 20:47:
Hmmm, ik zou misschien als ik jou was toch eens hiermee kijken hoe ver je komt:
https://huggingface.co/unsloth/Qwen3.8-Flash-Next-GGUF/tree/main

Met Q3/Q2 lever je wat performance in maar ik ben dan wel benieuwd of de snelheidswinst dat niet waard is.

Ik wil zelf nog een keer kijken hoe ver je met een RTX 5090 komt met de Q1, her en der is te lezen dat je toch wel 40-50 Tokens eruit kan krijgen.

Stiekem blijf ik echter hopen op een Qwen 50B/60B MoE model (5B ofzo) dat zou voor de 5090 bezitters echt top zijn.

Normaalgesproken zou je een goed punt hebben, maar bij Q4 heb je token prediction met snelheidswinst. Die MTP is er niet bij Q3 (ik weet niet waarom). En Q4 past op deze manier en de kwaliteit is echt heel goed te noemen. Langere taken voert hij kwalitatief goed uit en tool calls zijn indrukwekkend. En de snelheid die ik ervaar is vergelijkbaar met Gemini in Antigravity.

[zx9r_mario]

_Apache_ schreef op woensdag 9 september 2026 @ 07:13:
[...]

Kokoro al eens geprobeerd?

Nederlands klink beter met Omnivoice, kokoro klinkt met een buitenlands accent. Chatterbox klinkt ook best goed met Nederlands

[ Voor 10% gewijzigd door zx9r_mario op 13-09-2026 22:49 ]

[R3m3d7]

DeNachtwacht schreef op zondag 13 september 2026 @ 20:15:
@gibraltar dank, dit is voor mij ook weer nieuw. Is dat voor dit model specifiek? En ik begrijp dus dat er 47.7GB niet in het DDR zit, maar op de SSD? Want dan zou je dus juist wél meer dan genoeg moeten hebben voor 256K context.

De nieuwe deepseek flash 4.1 gebruikt het ook, het is een manier om eenvoudige zaken te offloaden naar SSD, hij kijkt alleen naar de laatste paar woorden volgens mij dus hij kan dan zonder veel werk te doen van new york -> new york city maken, dat soort simpele dingen. Ik las ook al over mensen die deze data vervangen/aanvullen met andere data en daar wat succes mee hebben, krijgen we een soort swappable SSD-based LLM extenties hiermee in de toekomst? Het maakt inference weer wat goedkoper bovenop moe's en mtp. heel erg gaaf.

[apollo13]

zx9r_mario schreef op zondag 13 september 2026 @ 22:40:
[...]

Nederlands klink beter met Omnivoice, kokoro klinkt met een buitenlands accent. Chatterbox klinkt ook best goed met Nederlands

Thanks voor de info, vanavond die twee eens gaan testen. Moet zeggen dat Omnivoice tot nu toe goed bevalt.
Ben wel aan het stoeien geweest met VoiceStudio. VoiceStudio
Die gaat bij mij met het maken van een audioboek de mist in, maar in de voice design module van VoiceStudio heb je meer mogelijkheden dan in Omnivoice.

[_Apache_]

Zsub schreef op dinsdag 8 september 2026 @ 20:59:
Ooooh whisper is ook een hele goeie! Nooit aan gedacht, was veel te veel op llms gefocust.

Ik moet wel zeggen, het was wel een avontuur om GPU acceleration aan de praat te krijgen. Want hoewel de 1080Ti nog best kan meekomen qua performance, heeft Nvidia de support van de 1xxx serie laten vallen een tijdje terug.

Maar ook daar kwam ik met copilot wel uit, want - I kid you not - heb specifieke drivers gedownload (toen er nog support was) en 2 dll's overgebracht naar mijn huidige python env. En de code zo laten instellen dat hij geen requirements check meer doet (want dan gaat ie af op de 1xxx serie gpu). Maar hij vuurt de commands zonder te kijken af, en voila, de GPU reageert. Voelt nogal hacky slacky, maar hee, het werkt. Het ging van de helft van de afspeelsnelheid (op de CPU, Core i7 7700k) naar 4-5x de afspreelsnelheid.

De uitdaging was namelijk, dat ik wel moderne drivers wilde voor de games die ik speel, maar OOK gpu acceleration voor whisper wilde.

[ Voor 7% gewijzigd door _Apache_ op 14-09-2026 10:45 ]

[Zsub]

_Apache_ schreef op maandag 14 september 2026 @ 10:44:
[...]

Ik moet wel zeggen, het was wel een avontuur om GPU acceleration aan de praat te krijgen. Want hoewel de 1080Ti nog best kan meekomen qua performance, heeft Nvidia de support van de 1xxx serie laten vallen een tijdje terug.

Maar ook daar kwam ik met copilot wel uit, want - I kid you not - heb specifieke drivers gedownload (toen er nog support was) en 2 dll's overgebracht naar mijn huidige python env. En de code zo laten instellen dat hij geen requirements check meer doet (want dan gaat ie af op de 1xxx serie gpu). Maar hij vuurt de commands zonder te kijken af, en voila, de GPU reageert. Voelt nogal hacky slacky, maar hee, het werkt. Het ging van de helft van de afspeelsnelheid (op de CPU, Core i7 7700k) naar 4-5x de afspreelsnelheid.

De uitdaging was namelijk, dat ik wel moderne drivers wilde voor de games die ik speel, maar OOK gpu acceleration voor whisper wilde.

Ik weet het. Ik heb het opgelost door onder Linux een extra virtuele machine aan te maken, de 1080 naar de vm door te geven en op de host de moderne driver te installeren en in de vm dan de oudere versie. En als ik wil gamen reboot ik wel naar Windows met alleen de nieuwe driver van m’n 5070

[Jan121]

Wie een Strix Halo heeft, het zijn gouden tijden. LLM Modellen zijn 3x zo snel geworden de laatste maanden.

Als alternatief voor de closed source Halogen server:
https://github.com/peonist-ai/halogen-flash-server

Is er nu ook een open source llama.cpp fork voor Qwen3.8-Next-Flash met veel betere prestaties: pp/s > 1000 en t/s ~ 35-40:
https://pwilkin.github.io/strix-halo/

Draai daarmee Signal Next (https://huggingface.co/ag...-GGUF/tree/main/AP-IQ4_XS) op mijn Bosgame M5 96GB (94GB VRAM) met bovenstaande snelheden.

Zie ook:
https://strix-halo-toolboxes.com/

[R3m3d7]

Jan121 schreef op maandag 14 september 2026 @ 14:19:
Wie een Strix Halo heeft, het zijn gouden tijden. LLM Modellen zijn 3x zo snel geworden de laatste maanden.

Als alternatief voor de closed source Halogen server:
https://github.com/peonist-ai/halogen-flash-server

Is er nu ook een open source llama.cpp fork voor Qwen3.8-Next-Flash met veel betere prestaties: pp/s > 1000 en t/s ~ 35-40:
https://pwilkin.github.io/strix-halo/

Draai daarmee Signal Next (https://huggingface.co/ag...-GGUF/tree/main/AP-IQ4_XS) op mijn Bosgame M5 96GB (94GB VRAM) met bovenstaande snelheden.

Zie ook:
https://strix-halo-toolboxes.com/

Mooi man, ik lees dat er een kans is dat de echte qwen 4.0 release waar 3.8 flash next een preview van is mogelijk deze maand nog gaat komen maar dan (verwacht ik) met betere RL. Ik ben zeer benieuwd wat voor stap dit model gaat maken, het zou zomaar een flinke kunnen zijn en ik denk dat het een perfecte match is voor systemen als de strix/gorgon halo.

[CSB]

R3m3d7 schreef op dinsdag 15 september 2026 @ 16:38:
[...]

Mooi man, ik lees dat er een kans is dat de echte qwen 4.0 release waar 3.8 flash next een preview van is mogelijk deze maand nog gaat komen maar dan (verwacht ik) met betere RL. Ik ben zeer benieuwd wat voor stap dit model gaat maken, het zou zomaar een flinke kunnen zijn en ik denk dat het een perfecte match is voor systemen als de strix/gorgon halo.

Duimen voor een nieuw MoE model

[Deepflame]

Voor de mensen onder ons met een 24GB GPU (RTX 3090, etc)

Check https://github.com/Neroued/ninfer (of https://github.com/Don-Chad/ninfer-3090 als je een RTX 3090 hebt)

Ik ben van llama.cpp's 900 tok/s prefill + 40 tok/s decode naar 990 tok/s prefill + 77 tok/s decode gegaan, bijna een verdubbeling van decode! Super nice!

[BasHouse]

Ik heb hiermee gespeeld maar mijn conclusie is totaal duidelijk, nog liever een flash modelletje van gemini dan zelf hosten, het loont echt niet de moeite om een GPU rig aan te schaffen om lokaal modelletjes te draaien, gewoon een abbo van 20 euro per maand en je kan los met je api key.

[DeNachtwacht]

BasHouse schreef op woensdag 16 september 2026 @ 18:44:
Ik heb hiermee gespeeld maar mijn conclusie is totaal duidelijk, nog liever een flash modelletje van gemini dan zelf hosten, het loont echt niet de moeite om een GPU rig aan te schaffen om lokaal modelletjes te draaien, gewoon een abbo van 20 euro per maand en je kan los met je api key.

Dat hangt heel erg van je werk af. En natuurlijk van wanneer je kocht, pakweg een jaar geleden was de hardware prijs/kwaliteitverhouding een stuk beter idd. Maar feit is dat je voor heel veel (agent/programmeer)werk met een $20/maand abonnementje letterlijk niks kan, dan ben je op dag 2 al door je tokens heen. Juist voor die zware groep mensen die een $200/maand of zelfs meer abonnement hebben, kan lokale AI wel degelijk heel interessant zijn. Naast natuurlijk dat je je data geheel in eigen beheer houdt.

[ocf81]

BasHouse schreef op woensdag 16 september 2026 @ 18:44:
Ik heb hiermee gespeeld maar mijn conclusie is totaal duidelijk, nog liever een flash modelletje van gemini dan zelf hosten, het loont echt niet de moeite om een GPU rig aan te schaffen om lokaal modelletjes te draaien, gewoon een abbo van 20 euro per maand en je kan los met je api key.

Ik vraag me dan wel af wat voor soort werk je hebt gebruikt om de vergelijking te doen en met welke hardware je dat dan hebt gedaan. Zoals @DeNachtwacht al zegt hangt het erg af van wat je er mee wil doen of het loont. Maar met de juiste hardware en voor bepaalde gebruiksscenario's kan het zeker wel lonen om lokaal te werken.

[Deepflame]

Qwen 3.8 27b werkt, voor zover ik getest heb, op vergelijkbaar niveau als GPT 5.6 Luna, maar dan goedkoper dan API. Ik heb een pakket aan taken uitgevoerd, tokens en tijd gemeten, die vertaald naar Luna API kosten en elektriciteitsrekening, en ik was ongeveer 50% goedkoper uit met Qwen lokaal dan met Luna, met als enige nadeel dat het allemaal ietsjes langer duurde.

[ocf81]

In de onderstaande video geeft Donato Capitella, weliswaar gesponsord door, en gericht op, Framework, mooie intro over het gebruik van Strix Halo machines met diverse geheugencapaciteiten voor AI doeleinden.

[R3m3d7]

En over het lokaal draaien van een LLM. Ik denk dat het spelen met de tools en modellen erg leuk en leerzaam is om te doen, we zitten hier niet voor niets op tweakers.net. Het is vaak een uitbereiding op een bestaand homelab, als je al iets hebt draaien en mogelijk nog een gpu hebt liggen of niet meer gamed is het een leuke hobby, je kan er heerlijk me pioneeren en expirimenteren maar het ook daadwerkelijk gebruiken, dat zijn de leukste hobbies imho. Voor mij voelt het een beetje als de begintijd van de pc en ook de begintijd van het internet, er is een iets bijzonders gaande en als je er thuis mee speelt ben je er echt een onderdeel van.

We kunnen intelligentie downloaden en inzetten als hulpjes voor van allles, hoe bizar is dat?

Voor mij is het een kwestie van wachten op iets betere hardwareprijzen of een deal waar ik geen nee tegen kan zeggen en dan sla ik toe, tot die tijd gebruik ik deepseek flash via de API, dan is het echt hard werken om meer dan 3-4 tientjes per maand uit te geven.

[Jan121]

R3m3d7 schreef op dinsdag 15 september 2026 @ 16:38:
[...]

Mooi man, ik lees dat er een kans is dat de echte qwen 4.0 release waar 3.8 flash next een preview van is mogelijk deze maand nog gaat komen maar dan (verwacht ik) met betere RL. Ik ben zeer benieuwd wat voor stap dit model gaat maken, het zou zomaar een flinke kunnen zijn en ik denk dat het een perfecte match is voor systemen als de strix/gorgon halo.

De modellen worden beter, maar ook de hardware van de Strix Halo wordt steeds beter benut.
Token generation t/s zit nu wel op zijn max, voornamelijk afhankelijk van geheugenbandbreedte. MTP heeft hier voor een verdubbeling gezorgd.

De laatste maand is de prefill (pp/s) verdrievoudigd, en die zou met meer optimalisaties nog wel verder moeten kunnen stijgen.

[GarBaGe]

Ik heb Ollama draaien op een RTX3090 met 24GB.
Ik gebruik bij voorkeur Qwen 3.8 27B.
Dat neemt dan (met context?) 20-21GB in beslag.
Als ik wat speel met OpenCode met deze backend, dan ervaar ik dat na een handje vol requests OpenCode ineens niet meer reageert.
Een nieuwe sessie werkt dan weer wel.
Ik denk dat de context vol raakt, alhoewel ik me niet kan voorstellen dat de context standaard zo klein is.
Ik ga proberen de context te quantiseren op 8 bit (ipv standaard 16 bits) zodat ik meer tokens kwijt kan.

Edit:
volgens AI zou ik door deze aanpassing van 32k tokens naar 64k tokens moeten kunnen.
Echter, ik kan me haast niet voorstellen dat OpenCode met die paar requests al 32k tokens nodig heeft....
Kan ik ergens (interactief?) zien hoeveel tokens er gebruikt worden in een specifieke sessie?

Dus ik wil van de standaard f16 naar q8_0 (Ollama KV cache type).
zodat ik daarna de num_ctx kan vergroten op dezelfde hoeveelheid VRAM

[ Voor 18% gewijzigd door GarBaGe op 17-09-2026 13:23 ]

[DeNachtwacht]

@GarBaGe context loopt inderdaad heel snel op. Met qwen 3.8 kan ik op mijn 32gb vram 175K context draaien zonder te offloaden. Aangezien Windows ook zo’n 2gb wil hebben, heb je naast de 18Gb van het model dus maar zo’n 4gb over voor context.

Je vermoeden dat de context vol raakt klopt dus, maar ik ben dus ook bang dat je zo weinig contextruimte hebt dat je niet echt aan een lekkere grootte komt, zelfs niet met Q4. Voor programmeren wil je volgens mij minstens 128K (misschien dat de programmeurs hier dat kunnen bevestigen?) want het loopt gewoon snel vol. Ik zie iig in openclaw dat 3-4 opdrachten die niet eens complex zijn al snel leiden tot zo’n 50-60K context gevuld. Het probleem van een kleine context is dat het zichzelf ook negatief versterkt, omdat er allerlei basale info snel vergeten wordt, moet je die dus ook steeds opnieuw toevoegen, waardoor je nog minder ruimte hebt voor je aanvulling/aanpassing.

[ Voor 32% gewijzigd door DeNachtwacht op 17-09-2026 15:12 ]

[GarBaGe]

DeNachtwacht schreef op donderdag 17 september 2026 @ 15:09:
@GarBaGe context loopt inderdaad heel snel op. Met qwen 3.8 kan ik op mijn 32gb vram 175K context draaien zonder te offloaden. Aangezien Windows ook zo’n 2gb wil hebben, heb je naast de 18Gb van het model dus maar zo’n 4gb over voor context.

Je vermoeden dat de context vol raakt klopt dus, maar ik ben dus ook bang dat je zo weinig contextruimte hebt dat je niet echt aan een lekkere grootte komt, zelfs niet met Q4. Voor programmeren wil je volgens mij minstens 128K (misschien dat de programmeurs hier dat kunnen bevestigen?) want het loopt gewoon snel vol. Ik zie iig in openclaw dat 3-4 opdrachten die niet eens complex zijn al snel leiden tot zo’n 50-60K context gevuld. Het probleem van een kleine context is dat het zichzelf ook negatief versterkt, omdat er allerlei basale info snel vergeten wordt, moet je die dus ook steeds opnieuw toevoegen, waardoor je nog minder ruimte hebt voor je aanvulling/aanpassing.

Bedankt voor de informatie.
Zou de Ridge variant (qwen 3.8 27b Ridge GGUF) dan beter zijn?
Deze is kleiner, ongeveer 12GB, waardoor er meer context ruimte overblijft.
dan kan ik mogelijker wel 128k tokens kwijt

[Zsub]

DeNachtwacht schreef op donderdag 17 september 2026 @ 15:09:
@GarBaGe context loopt inderdaad heel snel op. Met qwen 3.8 kan ik op mijn 32gb vram 175K context draaien zonder te offloaden. Aangezien Windows ook zo’n 2gb wil hebben, heb je naast de 18Gb van het model dus maar zo’n 4gb over voor context.

Je vermoeden dat de context vol raakt klopt dus, maar ik ben dus ook bang dat je zo weinig contextruimte hebt dat je niet echt aan een lekkere grootte komt, zelfs niet met Q4. Voor programmeren wil je volgens mij minstens 128K (misschien dat de programmeurs hier dat kunnen bevestigen?) want het loopt gewoon snel vol. Ik zie iig in openclaw dat 3-4 opdrachten die niet eens complex zijn al snel leiden tot zo’n 50-60K context gevuld. Het probleem van een kleine context is dat het zichzelf ook negatief versterkt, omdat er allerlei basale info snel vergeten wordt, moet je die dus ook steeds opnieuw toevoegen, waardoor je nog minder ruimte hebt voor je aanvulling/aanpassing.

Ja ik merk dat je zeker niet minder dan 128k wil voor programmeren. 64k zit echt zó vol, zeker als je een paar MCP servers erbij hebt.

[DeNachtwacht]

GarBaGe schreef op donderdag 17 september 2026 @ 15:16:
[...]

Bedankt voor de informatie.
Zou de Ridge variant (qwen 3.8 27b Ridge GGUF) dan beter zijn?
Deze is kleiner, ongeveer 12GB, waardoor er meer context ruimte overblijft.
dan kan ik mogelijker wel 128k tokens kwijt

Dat model is zo te zien Q2 en dus wel weer wat minder accuraat, maar het geeft je iig meer headroom, waarschijnlijk in ieder geval genoeg voor 128K context. Zoals gezegd heb ik 175K context in 32GB-18gb(model)-2gb(windows/driver)=12GB. In jouw geval zit je op 24gb-2gb(windows)-12gb(model)=10GB dus ergens rond de 150K zou moeten lukken.

Ik zou echter ook Qwen3.6-35B-coder eens gaan proberen. Die kun je op Q4 wel draaien denk ik op flink forsere snelheid omdat dat een MoE model is. Is iets ouder model maar dus wel Q4 ipv Q2, en als de kwaliteit voldoende voor je is is het iig een stuk sneller.

[vargo]

Het draaien van een ruimte context size is 1 ding (128K is denk ik wel een ondergrens voor programmeren), maar hoe je dat gebruikt speelt ook een belangrijke rol:
- het filteren van input en output noise op het model
- je workflow: een "one-shot" opdracht is anders dan het in stukken opknippen
- het gebruik van sub-agents (kleinere taken = kleinere context voor die taak), en hoeveel "concurrent" sessies je aankan
Bij beperkte hardware (m.n. VRAM) zal je keuzes moeten maken: welk model, welke quant size, wel/niet quantisizen van je context, MoE of Dense model, etc.

Edit: een ander model welke je zou kunnen proberen is Ornith 1.5 - ik heb de vorige 1.0 versie getest en was daar best tevreden over, en razendsnel.

[ Voor 15% gewijzigd door vargo op 17-09-2026 19:57 ]

[rinkel]

vargo schreef op donderdag 17 september 2026 @ 19:22:
Het draaien van een ruimte context size is 1 ding (128K is denk ik wel een ondergrens voor programmeren), maar hoe je dat gebruikt speelt ook een belangrijke rol:
- het filteren van input en output noise op het model
- je workflow: een "one-shot" opdracht is anders dan het in stukken opknippen
- het gebruik van sub-agents (kleinere taken = kleinere context voor die taak), en hoeveel "concurrent" sessies je aankan
Bij beperkte hardware (m.n. VRAM) zal je keuzes moeten maken: welk model, welke quant size, wel/niet quantisizen van je context, MoE of Dense model, etc.

Edit: een ander model welke je zou kunnen proberen is Ornith 1.5 - ik heb de vorige 1.0 versie getest en was daar best tevreden over, en razendsnel.

Ik ben wat aan t experimenteren met verschillende, niet al te grote (max 27B) modellen, maar jee, die 9B is best goed ja.

Niet zo snel als een MoE, bv Qwen3-Coder-30B-A3B, maar die 9B komt daar serieus is de buurt kwa kwaliteit, vooralsnog, moet nog even verder testen.

[ Voor 7% gewijzigd door rinkel op 17-09-2026 22:04 ]

[Deepflame]

GarBaGe schreef op donderdag 17 september 2026 @ 13:19:
Ik heb Ollama draaien op een RTX3090 met 24GB.
Ik gebruik bij voorkeur Qwen 3.8 27B.
...

Probeer NInfer eens ipv ollama of llama.cpp: https://github.com/Don-Chad/ninfer-3090

Deze fork is speciaal voor de RTX 3090, ik ging van 900 t/s prefill en 40 t/s decode naar 990 t/s prefill en bijna 80 t/s decode, bijna een vedubbeling van decode!

Nadeel is wel dat het geen TurboQuant ondersteunt, dus toen ik van mijn llama.cpp fork afstapte heb ik wel flink in moeten leveren qua context window size. (256k naar 192k))

Dus ik twijfel nog of ik weer terug na naar llama.cpp's TheTom/TurboQuant of dat ik NInfer aanhoud (Die 2x snellere decode merk je wel)

[zx9r_mario]

Er is een variant op Qwen3.8-27b uitgekomen die slechts 8,6GB gebruikt.

[Tijmen007]

Leuk om al jullie ervaringen te lezen, ik ben zelf nu een aantal maanden aan het experimenteren met lokale LLMs en de potentie vind ik erg tof. Ook de ontwikkeling van nieuwe modellen gaat hard, de sprongen die gemaakt worden zijn indrukwekkend.

Ter referentie lijkt het mij handig om te beginnen met hoe ik het draai. Ik gebruik llama.cpp, versie "version: 0.4.1-dev (build 10964, commit b29c606e28)" op Arch Linux. De videokaart waar ik de modellen op draai is een AMD RX6900XT (16GB). Voor de meeste zaken wissel ik tussen Google's Gemma 4, Qwen 3.5 en Ornith 1.5. De configuratie ziet voor deze modellen er zo uit in mijn llama-server-config.ini:

[unsloth/gemma-4-12b-it-GGUF:Q4_K_XL]
context = 262144
spec-draft = draft-mtp
spec-draft-n-max = 4
temp = 1.0
top-p = 0.95
top-k = 40
repeat-penalty = 1.08
repeat-last-n = 4096

[ornith-ai/Ornith-1.5-9B-GGUF:Q8_0]
context = 262144
temp = 0.6
top-p = 0.95
top-k = 20
min-p = 0.00
presence_penalty = 0.0
repetition_penalty = 1.0

[unsloth/Qwen3.5-9B-GGUF:Q8_0]
temp = 0.6
top-p = 0.95
top-k = 20
min-p = 0.00
reasoning = on
presence_penalty = 0.0
repetition_penalty = 1.0
jinja = on
reasoning-format = deepseek
fa = on

Gemma 4 vind ik persoonlijk erg sterk op gebied van natuurlijke taal, dus dingen als vertalingen of teksten opstellen gaan hier erg goed mee (voor een lokale LLM). Daarnaast wissel ik af tussen Qwen 3.5 en Ornith 1.5 voor programmeer experimenten, de laatste kan verrassend goed uit de hoek komen maar soms ook compleet de plank mis slaan, Qwen is voorspelbaarder maar een stuk dommer.

Eigenlijk zit ik al een aantal weken in hetzelfde schuitje als wat anderen hier: zou upgraden naar een 32 GB kaart of zelfs een 128 GB machine zoals de Framework Desktop het geld waard zijn? Ik gebruik het nu vooral om erachter te komen hoe capabel ze zijn en voor programmeren vind ik het zo zo. Scripting daarentegen is echt fantastisch, even wat bash scriptjes opstellen om het leven makkelijker te maken is echt een game changer wat mij betreft.

Ik vind de 4.000 euro voor de Framework Desktop (128GB) toch wel erg duur voor het pielen wat ik ermee doe, maar eigenlijk zijn alle alternatieven gewoon erg duur (R9700 AI is 1.700 euro inmiddels?). De desktop is in dat geval dan in het ergste geval een vervanging voor mijn thuisservertje. Moeilijk!

Compleet terzijde, des te meer ik uitprobeer met LLMs hoe beter ik begrijp dat sommige mensen zichzelf er helemaal in verliezen. Het zijn echt hele geniepige ja knikkers, bijzonder irritant hoe subtiel ze vaak naar je mond praten. En soms minder subtiel.

[R3m3d7]

@Tijmen007 Mijn advies om een paar tientjes tegen openrouter.com te gooien en daar modellen uit te proberen die je dan op eigen hardware lokaal zou willen draaien. Ik zou vanuit het model waar je echt tevreden over bent terugredeneren naar hardware en niet vanuit hardware naar modellen kijken. Reken dan wel eerlijk dus met context en als het om een heel systeem gaat zoals een amd halo of mac ook het OS + runtime mee qua gebruik wat van het geheugen af gaat. Context is voor sommige modellen duur en voor andere heel goedkoop, helaas is (denk ik) context het goedkoopst voor een model wat prijzig is om thuis te draaien.

[Tijmen007]

R3m3d7 schreef op zaterdag 19 september 2026 @ 12:51:
@Tijmen007 Mijn advies om een paar tientjes tegen openrouter.com te gooien en daar modellen uit te proberen die je dan op eigen hardware lokaal zou willen draaien. Ik zou vanuit het model waar je echt tevreden over bent terugredeneren naar hardware en niet vanuit hardware naar modellen kijken. Reken dan wel eerder dus met context en als het om een heel systeem gaat zoals een amd halo of mac ook het OS + runtime mee qua gebruik wat van het geheugen af gaat. Context is voor sommige modellen duur en voor andere heel goedkoop, helaas is (denk ik) context het goedkoopst voor een model wat prijzig is om thuis te draaien.

Zeker een interessante optie. Waar je suggestie mij ook goed bij kan helpen is een beeld krijgen bij het aantal parameters in relatie tot de "prestaties". Mijn ervaring tot noch toe is dat benchmarks een _heel_ grof beeld schetsen en dat werkelijk gebruik blijkbaar zo divers is dat het lastig is te vergelijken. Zelf even wat dingen knutselen die je werkelijk zou willen gaan doen geeft vaak een veel beter beeld.

Ook de quantization blijft wat gissen, vooral ook omdat ik lokaal niet altijd alle niveaus kan draaien, dus dat is ook wel interessant.

[Felicia]

Tijmen007 schreef op zaterdag 19 september 2026 @ 12:05:
Eigenlijk zit ik al een aantal weken in hetzelfde schuitje als wat anderen hier: zou upgraden naar een 32 GB kaart of zelfs een 128 GB machine zoals de Framework Desktop het geld waard zijn? Ik gebruik het nu vooral om erachter te komen hoe capabel ze zijn en voor programmeren vind ik het zo zo. Scripting daarentegen is echt fantastisch, even wat bash scriptjes opstellen om het leven makkelijker te maken is echt een game changer wat mij betreft.

Ik vind de 4.000 euro voor de Framework Desktop (128GB) toch wel erg duur voor het pielen wat ik ermee doe, maar eigenlijk zijn alle alternatieven gewoon erg duur (R9700 AI is 1.700 euro inmiddels?). De desktop is in dat geval dan in het ergste geval een vervanging voor mijn thuisservertje. Moeilijk!

Ik heb daarom een Intel Arc Pro B60 gekocht en later een B70 (á 700 en 1300 euro respectievelijk met 24 en 32GB Vram) en daar kan ik best leuke dingen mee doen. Met Qwen 35b a3b Q4_K_M en max context beschikbaar gaat er best wel heel veel goed op een redelijk tempo.

Heel af en toe val ik nog terug op Opencode's gratis modellen (Big Pickle is ook wel leuk) maar ik heb geen creditcard dus ook geen zin om een tegoed daar af te nemen.

[R3m3d7]

Tijmen007 schreef op zaterdag 19 september 2026 @ 13:01:
[...]

Zeker een interessante optie. Waar je suggestie mij ook goed bij kan helpen is een beeld krijgen bij het aantal parameters in relatie tot de "prestaties". Mijn ervaring tot noch toe is dat benchmarks een _heel_ grof beeld schetsen en dat werkelijk gebruik blijkbaar zo divers is dat het lastig is te vergelijken. Zelf even wat dingen knutselen die je werkelijk zou willen gaan doen geeft vaak een veel beter beeld.

Ook de quantization blijft wat gissen, vooral ook omdat ik lokaal niet altijd alle niveaus kan draaien, dus dat is ook wel interessant.

Benchmarks zijn okay om onderling modellen te vergelijken maar je moet ze idd met een korreltje zou nemen zeker omdat benchmaxxing een ding is bij LLM's.

Je eigen gesloten benchmarks maken is een onderdeel van de oplossing, die kan je het beste laten maken door een frontier model imho (ik heb Astra wat laten maken). Daarnaast krijg je op een gegeven momten een bepaalde vibe bij een model. Sommige kunnen goed schrijven, andere zijn zeer handig met tooling, sommige gebruiken extreem veel tokens voordat ze ook maar iets van echt werk verzetten, andere zijn zeer gewillig om voor je te werken en beginnen al met werken wanneer je alleen maar vraagt of iets mogelijk is, andere komen vaker met bullshit terug dan andere, etc. Het is subjectief maar ik denk dat het belangrijk is als je gaat kiezen waar je qua model uitkomt. Helaas is het voor mij op/rond het niveau van Deepseek 4.1 flash en die is voor mij niet betaalbaar voor thuis, ik heb de hoop dat het moe qwen 4.0 hier dicht genoeg bij in de buurt gaat komen. We gaan het zien.

[rbrtb]

[quote]
Tijmen007 schreef op zaterdag 19 september 2026 @ 12:05:

Gemma 4 vind ik persoonlijk erg sterk op gebied van natuurlijke taal, dus dingen als vertalingen of teksten opstellen gaan hier erg goed mee (voor een lokale LLM). Daarnaast wissel ik af tussen Qwen 3.5 en Ornith 1.5 voor programmeer experimenten, de laatste kan verrassend goed uit de hoek komen maar soms ook compleet de plank mis slaan, Qwen is voorspelbaarder maar een stuk dommer.

Eigenlijk zit ik al een aantal weken in hetzelfde schuitje als wat anderen hier: zou upgraden naar een 32 GB kaart of zelfs een 128 GB machine zoals de Framework Desktop het geld waard zijn? Ik gebruik het nu vooral om erachter te komen hoe capabel ze zijn en voor programmeren vind ik het zo zo. Scripting daarentegen is echt fantastisch, even wat bash scriptjes opstellen om het leven makkelijker te maken is echt een game changer wat mij betreft.

Ik vind de 4.000 euro voor de Framework Desktop (128GB) toch wel erg duur voor het pielen wat ik ermee doe, maar eigenlijk zijn alle alternatieven gewoon erg duur (R9700 AI is 1.700 euro inmiddels?). De desktop is in dat geval dan in het ergste geval een vervanging voor mijn thuisservertje. Moeilijk!

Heel herkenbaar. Ik heb ook lang getwijfeld of de stap naar meer VRAM het geld (en de herrie in geval van sommige server achtige GPUs) het waard is. Ik ben zelf niet ontevreden wat mogelijk is met 16 GB VRAM (AMD RX 9070).

Voor generieke vragen, beetje toegepaste wiskunde (meeste lineair algebra) vind ik Gemma4-26B A4B erg fijn. Gemma4-26B A4B is snel (45 tokens/s) en de stijl van antwoorden bevalt me wel. Subjectief prefereer ik die boven de 12B variant die je hierboven noemt.

Voor programmeren in (C++, voornamelijk HPC-achtig spul) ben ik onder de indruk wat je kan met Qwen 3.6 A35B A3B (45 tokens/s) of Qwen 3.8 27B in de IQ3_XS GSQ-RCO variant (~35 token/s). Ik gebruik de llm assistent vooral bij zoeken naar bugs in mijn code en voor reviews voor ik een commit doe. Spaart een hoop tijd zelf bugs te zoeken. Een beperking is alleen wel dat je zelfs op deze quants al wat krap zit in maximale context window.

Alhoewel ik dus best tevreden ben, zou ik als ik opnieuw zou mogen kiezen toch voor de 9700 AI Pro gaan. Niet zozeer om dat ik niet met 16 GB uit de voeten kan, maar met 32 GB kun je modellen met duidelijk meer context kunt draaien, dat is wel zo comfortabel.

[DeNachtwacht]

gibraltar schreef op zondag 13 september 2026 @ 20:56:
[...]

Normaalgesproken zou je een goed punt hebben, maar bij Q4 heb je token prediction met snelheidswinst. Die MTP is er niet bij Q3 (ik weet niet waarom). En Q4 past op deze manier en de kwaliteit is echt heel goed te noemen. Langere taken voert hij kwalitatief goed uit en tool calls zijn indrukwekkend. En de snelheid die ik ervaar is vergelijkbaar met Gemini in Antigravity.

Nou, ik ben eens aan het testen gegaan met Q2_K_XL en Q4_M vanavond (alhoewel... ik heb vooral zitten wachten met meer dan 210 GB te downloaden ). Samenvatting: ik zie die MTP snelheden bij de Q4 toch nog niet zo (het lijkt namelijk of die ook met Q2 gewoon al werkt).

Alles gedaan met 32K context, thinking medium, KV cache F16 op een pc met 64GB DDR-3200. Daarnaast dus ook MTP aangezet in unsloth, dat geeft ook bij Q2 geen foutmeldingen als ik het model daarmee laad. Prompt is steeds weer "Schrijf een essay van 2000 woorden over Beethoven" en vervolgens "Leuk, maar schrijf nu iets vergelijkbaars in 2000 woorden over Bach". De snelheid is steeds in outputtokens.

Q2_K_XL:
Single RTX 5090 in unsloth: 45 tokens/s.
RTX 5090 + 5060 Ti in unsloth: 60 tokens/s.

Q4_K_M:
RTX 5090 + 5060 Ti in ollama: 20 tokens/s
RTX 5090 + 5060 Ti in unsloth: 23 tokens/s
RTX 5090 + 5060 Ti in unsloth met Q4_1 KV cache: 24 tokens/s

Beduidend lagere snelheid dus en ik moet ook zeggen dat bij het laden unsloth ook een waarschuwing geeft dat het niet in het vram past (bij Q2 krijg ik die melding niet).

Vervolgens nog een test met Q2_K_XL gedaan met volle 256K context:
RTX 5090 + 5060 Ti in unsloth: 40 tokens/s
Single RTX 5090: 30 tokens/s

MTP heb ik wel uitstaan, want aanzetten kost meer ram offloading en maakt het bij mij dus juist trager lijkt het?

Overweging om niet voor Q1_M te gaan: dit model is 74,5GB groot, Q2_K_XL 79GB. Voelt dus meer als een sweet spot. Moet zeggen dat zelfs een single RTX 5090 mij meevalt, ik denk inderdaad dat OpenClaw een nieuwe hersenpan krijgt en 27B vaarwel wordt gezegd. Ik ga nog wel even twijfelen of ik de 5060 Ti er ook voor ga gebruiken, 30 tokens/s is eigenlijk net niet lekker werken met een bot, 40 tokens/s is nog net acceptabel maar ja het kost ook wel weer een sloot extra energie :P. Maar voor de programmeurs hier die de boel 's nachts aan het rekenen kunnen zetten en snelheid minder belangrijk is, dus goed nieuws dat je met 32GB Vram de Q2 prima kan draaien. Ik merk in de kwaliteit van die essays ook sowieso weer een kwaliteitsslag, stuk minder rommeligheden/foutjes dan 27B. Voor wie hem kan draaien is het dus zeker een aanrader.

[ Voor 6% gewijzigd door DeNachtwacht op 22-09-2026 15:50 ]

[Felicia]

Ik weet niet of hier de hype over Jev (van Typesafe AI) ook voorbij is gekomen?

Kort gezegd een AI model wat niet als LLM input beoordeeld en beantwoord maar als een statistische berekening op basis van een definitie. Het voordeel is dat het bijvoorbeeld een inkomende email veel sneller en makkelijker kan classificeren als bijvoorbeeld spam, inkoopvraag, supportvraag e.d.
Ik had mezelf voor de wachtlijst aangemeld en binnen een dag toegang gekregen. Maar, voor werk mag ik natuurlijk niet zomaar gegevens erin stoppen. Dus, korte blik op Huggingface en dan zie je al 5-6 vergelijkbare oplossingen op basis van het stukje was Typesafe AI gedeeld heeft

Dus aan het spelen geweest met: https://github.com/jaredpalmer/kev
En daar wordt ik toch wel vrolijk van. Niet dat deze versie zo geweldig werkt, maar het principe dat je op basis van een json schema input aanlevert en output krijgt die repeteerbaar is (en ook nog veel sneller) maakt het interessant om deze theorie in geautomatiseerde workflows te kunnen gebruiken.

[Tijmen007]

rbrtb schreef op maandag 21 september 2026 @ 20:14:
Voor generieke vragen, beetje toegepaste wiskunde (meeste lineair algebra) vind ik Gemma4-26B A4B erg fijn. Gemma4-26B A4B is snel (45 tokens/s) en de stijl van antwoorden bevalt me wel. Subjectief prefereer ik die boven de 12B variant die je hierboven noemt.

Voor programmeren in (C++, voornamelijk HPC-achtig spul) ben ik onder de indruk wat je kan met Qwen 3.6 A35B A3B (45 tokens/s) of Qwen 3.8 27B in de IQ3_XS GSQ-RCO variant (~35 token/s). Ik gebruik de llm assistent vooral bij zoeken naar bugs in mijn code en voor reviews voor ik een commit doe. Spaart een hoop tijd zelf bugs te zoeken. Een beperking is alleen wel dat je zelfs op deze quants al wat krap zit in maximale context window.

Alhoewel ik dus best tevreden ben, zou ik als ik opnieuw zou mogen kiezen toch voor de 9700 AI Pro gaan. Niet zozeer om dat ik niet met 16 GB uit de voeten kan, maar met 32 GB kun je modellen met duidelijk meer context kunt draaien, dat is wel zo comfortabel.

Ja, best prima wat er op 16GB kan. Ik heb voor de gein eens het Gemma 4 26B A4B gedownload om te proberen, maar ik krijg het niet stabiel werkend. Gok dat het wat meer configuratie nodig heeft gezien het niet domweg in het VRAM gegooit kan worden.

Heb zelf de afgelopen paar avonden veel zitten klooien om een beter beeld te krijgen bij context grootte in verhouding tot (V)RAM gebruik. Moet zeggen, ben er niet heel veel wijzer van uitgekomen anders dan dat Gemma 4 out of the box echt bizar goed functioneert op 16 GB.

llama-server --host 0.0.0.0 --port 8001 --models-max 1 --spec-type draft-mtp --spec-draft-n-max 4 --parallel 1 -fa 1

met het unsloth/gemma-4-12B-it-qat-GGUF:Q4_K_XL model is echt 100 t/s vliegen. Kwaliteit in code is wel matig. Zit nu veel te rommelen met Qwen modellen, vooral met Vue 3 frontends werkt dat een stuk beter.

@Felicia Als ik het goed begrijp klinkt dat ook toepasbaar om applicatie logging doorheen te gooien en wellicht wat meer gecureerde samenvattingen / aanbevelingen te kunnen opbouwen. Interessant!

[kazuka]

Felicia schreef op dinsdag 22 september 2026 @ 20:06:
Ik weet niet of hier de hype over Jev (van Typesafe AI) ook voorbij is gekomen?

Kort gezegd een AI model wat niet als LLM input beoordeeld en beantwoord maar als een statistische berekening op basis van een definitie. Het voordeel is dat het bijvoorbeeld een inkomende email veel sneller en makkelijker kan classificeren als bijvoorbeeld spam, inkoopvraag, supportvraag e.d.
Ik had mezelf voor de wachtlijst aangemeld en binnen een dag toegang gekregen. Maar, voor werk mag ik natuurlijk niet zomaar gegevens erin stoppen. Dus, korte blik op Huggingface en dan zie je al 5-6 vergelijkbare oplossingen op basis van het stukje was Typesafe AI gedeeld heeft

Dus aan het spelen geweest met: https://github.com/jaredpalmer/kev
En daar wordt ik toch wel vrolijk van. Niet dat deze versie zo geweldig werkt, maar het principe dat je op basis van een json schema input aanlevert en output krijgt die repeteerbaar is (en ook nog veel sneller) maakt het interessant om deze theorie in geautomatiseerde workflows te kunnen gebruiken.

[Afbeelding]

Ja, de clones schoten als paddestoelen uit de grond toen Jev veel aandacht kreeg. Schijnbaar had iemand een jaar geleden al eens zoiets gemaakt maar vloog het helemaal onder de radar. Ik ben benieuwd of de frontier boeren dit dadelijk zelf gaan inbouwen in hun modellen, hopelijk levert dat ook een besparing van tokengebruik op.

[Felicia]

Tijmen007 schreef op dinsdag 22 september 2026 @ 21:00:@Felicia Als ik het goed begrijp klinkt dat ook toepasbaar om applicatie logging doorheen te gooien en wellicht wat meer gecureerde samenvattingen / aanbevelingen te kunnen opbouwen. Interessant!

De logging was inderdaad een van de voorbeelden die Typesafe er zelf ook tegenaan gooide. Hangt of staat natuurlijk wel met of het model voldoende bekend is met de materie (want hoe weet ie of het een prio 1 is als ie niet eens kan inschatten was voor software het is).

Ook wat interessante video's:
https://www.loom.com/share/1e722354363e467e82929eb9983f7abc
https://docs.typesafe.ai/demos/smart-home

[JJ Le Funk]

neonite schreef op dinsdag 11 augustus 2026 @ 19:19:
[...]

Ik zit zelf ook in de security hoek, en heb onlangs 2 DGX Sparks aangeschaft voor o.a. het uitvoeren van security testen & analyses icm. het nieuwe Deepseek Flash model. Ik ben niet helemaal onder de indruk van de snelheid, maar het Deepseek model draait verder goed, levert resultaat en het is fijn om alle data in eigen beheer te blijven houden. Daarnaast werkt de oplossing fijn als 'persoonlijke assistent' met Hermes, waarbij ik het meer toegang tot gevoeligere data durf te geven.

Morgen komt het nieuwe Qwen model uit, ik ben benieuwd hoe dat zich gaat verhouden tegen Deepseek.

is de performance (wachten op resultaat na een code prompt vs dezelfde prompt direct aan deepseek v4.1 flash api bijvoorbeeld) beter in andere configuraties die de dual spark setup goed kan benutten?

ik zie dat bol voorraad heeft voor 6000 euro per stuk. maar moeilijk te rechtvaardigen aanschaf als de terugverdientijd 100 jaar is o.i.d.

[ Voor 7% gewijzigd door JJ Le Funk op 23-09-2026 18:56 ]

[Tijmen007]

Tijmen007 schreef op dinsdag 22 september 2026 @ 21:00:
[...]

Ja, best prima wat er op 16GB kan. Ik heb voor de gein eens het Gemma 4 26B A4B gedownload om te proberen, maar ik krijg het niet stabiel werkend. Gok dat het wat meer configuratie nodig heeft gezien het niet domweg in het VRAM gegooit kan worden.

Poeh, na wat geklooi omdat sommige settings niet via het llama.cpp ini configuratiebestand kunnen, heb ik Gemma 4 26B draaiende gekregen, haal rond de 60 tokens per seconde, werkt dus wel lekker vlot. Commando voor de volledigheid:

llama-server --host 0.0.0.0 --port 8001 --models-max 1 --parallel 1 \
 -hf unsloth/gemma-4-26B-A4B-it-qat-GGUF:UD-Q4_K_XL \
 -c 136704 --cache-type-k q4_0 --cache-type-v q4_0 -fa 1 \
 -ngl 24 \
 --spec-type draft-mtp --spec-draft-n-max 4 \
 --temp 1.0 \
 --top-p 0.95 \
 --top-k 64

VRAM usage zweeft dan rond de 15.6 GB. Ik gebruik de videokaart ook voor mijn monitor, dus denk dat er wel meer uit te persen is als je de videokaart helemaal dedicated kan gebruiken.

Lang verhaal kort: ik ben het met je eens dat het 26B model van Gemma 4 een stuk beter nadenkt bij programmeertaken. Nog steeds vliegt hij soms een beetje uit de bocht, maar de echt maffe keuzes bleven achterwege. Als benchmark heb ik met Vue3 en Shadcn een gepagineerde tabel geklust met dingen als een zoekfunctie om de tabel te filteren. Best leuk resultaat. Nog wel veel handmatig werk eraan, dus het zelfstandig laten opereren zie ik nog niet gebeuren. Bugjes, reviews en andere klusjes met duidelijke kaders kan zeker wel.

Merk wel dat Visual Studio Code best wel beroerd werkt met agents, de gevechten tussen de LLM en de tools zijn hilarisch om terug te lezen. Het vragen om code snippets om zelf te plakken werkt vaak veel beter...

[R.G]

Tijmen007 schreef op woensdag 23 september 2026 @ 20:55:
[...]

Poeh, na wat geklooi omdat sommige settings niet via het llama.cpp ini configuratiebestand kunnen, heb ik Gemma 4 26B draaiende gekregen, haal rond de 60 tokens per seconde, werkt dus wel lekker vlot. Commando voor de volledigheid:

llama-server --host 0.0.0.0 --port 8001 --models-max 1 --parallel 1 \
 -hf unsloth/gemma-4-26B-A4B-it-qat-GGUF:UD-Q4_K_XL \
 -c 136704 --cache-type-k q4_0 --cache-type-v q4_0 -fa 1 \
 -ngl 24 \
 --spec-type draft-mtp --spec-draft-n-max 4 \
 --temp 1.0 \
 --top-p 0.95 \
 --top-k 64

VRAM usage zweeft dan rond de 15.6 GB. Ik gebruik de videokaart ook voor mijn monitor, dus denk dat er wel meer uit te persen is als je de videokaart helemaal dedicated kan gebruiken.

Lang verhaal kort: ik ben het met je eens dat het 26B model van Gemma 4 een stuk beter nadenkt bij programmeertaken. Nog steeds vliegt hij soms een beetje uit de bocht, maar de echt maffe keuzes bleven achterwege. Als benchmark heb ik met Vue3 en Shadcn een gepagineerde tabel geklust met dingen als een zoekfunctie om de tabel te filteren. Best leuk resultaat. Nog wel veel handmatig werk eraan, dus het zelfstandig laten opereren zie ik nog niet gebeuren. Bugjes, reviews en andere klusjes met duidelijke kaders kan zeker wel.

Merk wel dat Visual Studio Code best wel beroerd werkt met agents, de gevechten tussen de LLM en de tools zijn hilarisch om terug te lezen. Het vragen om code snippets om zelf te plakken werkt vaak veel beter...

Werkt dit een beetje hetzelfde als claude code op sonnet model of beter?

Daarnaast als ik een github opensource project download in een map zet en zeg tegen gemma 4 leg mij dit project uit en voeg deze feature toe, werkt dat? Hoe kan gemma4 de hele repo / project doornemen welke tools gebruiken jullie daarvoor?

Ik merkte met tools addons in visual studio code dat het meestal maar 1-5 files zijn die ingelezen kunnen worden met een prompt. Het kan neit de hele source code lezen ofwel?

[eheijnen]

Zag laatst iets over Typesafe Jev langskomen.
Laya is weer een andere ontwikkeling op dit gebied.
https://news.lavx.hu/article/laya-offers-open-source-alternative-to-proprietary-ai-decision-engines-hitting-32ms-latency

[CT]

@R.G gebruik pi.dev met een dense model zoals qwen 27b dan heb je een vergelijkbare ervaring als wat je omschrijft

[walletje-w]

eheijnen schreef op donderdag 24 september 2026 @ 05:19:
Zag laatst iets over Typesafe Jev langskomen.
Laya is weer een andere ontwikkeling op dit gebied.
https://news.lavx.hu/article/laya-offers-open-source-alternative-to-proprietary-ai-decision-engines-hitting-32ms-latency

Ja interessant. En ook interessant is hoe (sociale) media bepaalde modellen meer aandacht geeft. Dit is blijkbaar door 1 persoon een jaar geleden al gebouwd. https://laya.convaiinnovations.com/

[prutser001]

Ben blij dat ik unsloth gevonden heb, geweldig. Eenvoudig en alles lokaal.

Vroeg me alleen af of dat andere unsloth gebruiken, vroeg me ook af of ik op een ander systeem het model kan draaien en vanaf een andere pc bedienen?

[CT]

prutser001 schreef op vrijdag 25 september 2026 @ 00:07:
Ben blij dat ik unsloth gevonden heb, geweldig. Eenvoudig en alles lokaal.

Vroeg me alleen af of dat andere unsloth gebruiken, vroeg me ook af of ik op een ander systeem het model kan draaien en vanaf een andere pc bedienen?

jazeker, handige tool is https://github.com/mostlygeek/llama-swap die gebruik ik al erg lang en met Wake-on-lan zet ik dan mn remote pc aan als het nodig is, de (open)api compatibility is direct in elke tool /agent / ide te gebruiken die je maar kan bedenken

[prutser001]

CT schreef op vrijdag 25 september 2026 @ 07:18:
[...]

jazeker, handige tool is https://github.com/mostlygeek/llama-swap die gebruik ik al erg lang en met Wake-on-lan zet ik dan mn remote pc aan als het nodig is, de (open)api compatibility is direct in elke tool /agent / ide te gebruiken die je maar kan bedenken

Kom net tot de conclusie dat Unsloth gewoon ingebouwde web access heeft. Desktop UI method: Open Unsloth, go to Settings → API → Remote & LAN, locate the LAN access card, and press Start.
Vandaag wat te doen.

[prutser001]

Ben al een paar dagen aan het klooien om het zomaar te zeggen.

Met 'doomscrollen' door youtube kwam ik een video tegen.

YouTube: Colibrì vs llama.cpp: Running DeepSeek V4 284B on CPU

Hij heeft het over de -nr (-no-repack) flag.
Nu heb ik qwen-coder-30B-A3B-Instruct-GGUF 30B 18GB (UD-Q4_K_XL) gestart met de -rn flag en hij laad gewoon.
Ook is de performance helemaal niet slecht. Dit is natuurlijk niet te vergelijken met het 169GB model wat hij gebruikt in de video. Maar zonder de flag doet hij niets en crashed/stopt het laden.

Heb er al flink wat op losgelaten, hele websites laten bouwen