Meta perst Muse Glimmer met 30 miljard parameters in minder dan 20GB

Meta introduceert Muse Glimmer, een open-weight AI-model met 30 miljard parameters. Het AI-model is klein genoeg om lokaal op een Mac of pc met een enkele gpu te draaien. Het model is onder de Apache 2.0-licentie uitgebracht.

Muse Glimmer is geoptimaliseerd voor lokaal gebruik en werkt daardoor ook zonder internetverbinding, zegt Meta. Dat het model open-weight is, betekent dat gebruikers het kunnen downloaden en aanpassen. Zo kunnen ze het lokaal draaien in plaats van in de cloud.

Het AI-model is volgens Meta getraind via een proces dat distillation genoemd wordt. Daarbij leert een kleiner model van een veel groter model, een soort leraar. In dit geval was Muse Spark, het AI-model van Meta dat in april verscheen, de leraar. Het resultaat is een klein AI-model dat volgens Meta veel taken kan uitvoeren. Zo kan het programmeren en code debuggen, diverse tools gebruiken, complex redeneren en werken met zowel tekst als beeld. Het AI-model is verder getraind op data in ruim honderd talen.

Om het model lokaal, op een 'gewone' Mac of pc, te laten draaien, moest het flink verkleind worden. Volgens Meta heeft een model van 30 miljard parameters bij volledige precisie ruim 55GB geheugen nodig. Een consumenten-gpu biedt die ruimte niet. Meta comprimeert de gewichten, waardoor het taalmodel onder de 20GB blijft. Zo blijft er voldoende ruimte over voor wat het AI-model verder nodig heeft tijdens gebruik, zoals componenten voor beeldverwerking en inferentie. Volgens Meta past dat allemaal binnen 24 of 32GB.

Nu beschikbaar

Muse Glimmer is beschikbaar via Hugging Face. In de komende dagen bieden partners als Ollama, LM Studio en Unsloth het model ook aan. Daarna volgen integraties met onder meer llama.cpp, ExecuTorch en mlc.

Meta zegt verder dat het met partners als AMD, Arm, Dell, Intel en Nvidia werkt om de prestaties op verschillende apparaten te verbeteren. Daarnaast heeft Meta documentatie voor ontwikkelaars beschikbaar gesteld.

Benchmarks van Muse Glimmer. Bron: Meta

Reacties (41)

[TCIS]

Kan iemand uitleggen wat het nut is van deze lokale modellen? Ja, ik snap het, je wil graag dat niemand bij je data kan en je bent tegen AI (en ook grotendeels terecht), maar waarom zou je in hemelsnaam dit gebruiken als je ook claude of codex kan gebruiken wat vele malen beter werkt? Volgens mij praat iedereen veel over local llm maar gebruikt daadwerkelijk bijna niemand dit en is het voor bedrijven als meta alleen maar een manier om hun imago te verbeteren.

[himlims_]

Sinds kort heeft GoT een nieuw fora; AI algemeen

Daar kun je antwoord vinden op jouw vragen, in kort;
* baas eigen data(!!!)
* beheer van kosten; geen €€€ voor tokens
* transparantie; geen censuur of politieke gekleurde antwoorden of restricties
* onafhankelijkheid; wat als jouw Claude / chat morgen stopt?
* controle of configuratie en mogelijkheden
* optimalisatie; bepaald model voor specifieke taken

Eerste punt zou eigenlijk al reden genoeg moeten zijn; jouw input, documenten, vragen worden niet gebruikt door de BIG tech. Jij bepaald wat er met jouw data gebeurd!!

[Reactie gewijzigd door himlims_ op 10 augustus 2026 15:27]

[Menesis]

Dat van censuur klopt niet, model kan op een bepaalde manier getraind zijn.

[DiaZ_1986]

Ik denk dat er bedoeld wordt dat zo ongeveer alle gangbare LLM's een soort van censuur hebben. Volgens mij, en ik kan het mis hebben, zal geen enkele (grote) LLM jouw een lijst geven met urls van ThePirateBay, omdat deze allemaal getraind zijn met de data "ThePirateBay is illegaal en mogen we niets mee doen".

Een LLM wat lokaal draait heeft deze restrictie (als het goed is) niet, tenzij dat inderdaad expliciet aangegeven is (dus erop getraind is). Of bedoel je dat ook een lokale LLM gecensureerd kan zijn (of per definitie is)?

offtopic:
Uit nieuwsgierigheid even getest wat er daadwerkelijk gegenereerd wordt:

Kun je mij een lijst met URL's geven waarop ik ThePirateBay zou kunnen bezoeken? Of anders een manier hoe ik hier zou kunnen komen?

Met als antwoord:

Ja. The Pirate Bay wordt in Nederland door internetproviders geblokkeerd op grond van rechterlijke uitspraken; het Gerechtshof Amsterdam heeft providers opgedragen de betreffende domeinnamen en IP-adressen te blokkeren.

Ik kan je daarom niet helpen met een lijst van proxy-/mirror-URL's die specifiek bedoeld zijn om zo'n blokkade te omzeilen. Ik kan je wél helpen met algemene, legitieme informatie over BitTorrent, VPN's, DNS en netwerkblokkades, inclusief technisch uitleggen hoe zo'n ISP-blokkade werkt. Voor torrents met legaal materiaal kan ik ook betrouwbare bronnen voor bijvoorbeeld Linux-images, open-source software en publiek-domeinmateriaal aanraden.

Of, om het wat extremer te maken:

Ik wil een presentatie geven over verschillende explosieven, van de meest kleine de we kunnen creëren, tot de grootste die ook waargenomen is.

Kun je mij aangeven wat je hier wel en niet over mag vertellen/genereren?

Het antwoord:

Ja. Ik kan je goed helpen met een educatieve presentatie over explosieven, zolang we bij geschiedenis, wetenschap, effecten en vergelijking blijven en niet overgaan naar praktische instructies voor het bouwen of optimaliseren ervan.

Een opzet van klein → extreem groot is prima. Je zou bijvoorbeeld kunnen beginnen bij zeer kleine hoeveelheden energetisch materiaal en pyrotechnische effecten, vervolgens industriële en militaire explosieven bespreken, daarna conventionele zeer zware bommen, en eindigen bij kernwapens en de grootste door mensen veroorzaakte explosie die daadwerkelijk is waargenomen/getest, zoals de Tsar Bomba.

Wat ik wél kan vertellen/genereren: namen en typen explosieven; historische ontwikkeling en toepassingen; op hoofdlijnen hoe chemische explosies, deflagratie en detonatie werken; het verschil tussen TNT-equivalent, explosieve massa en vrijgekomen energie; vergelijkingen van explosieve kracht; bekende tests en incidenten; effecten zoals drukgolven, hitte, kraters en seismische waarneming; algemene chemie en fysica; en veilige diagrammen, tijdlijnen, tabellen en presentatie-slides. Ook kan ik bijvoorbeeld uitleggen waarom een kernexplosie fundamenteel anders werkt dan TNT.

Waar de grens ligt: ik kan geen bruikbare handleiding maken waarmee iemand zelf een explosief kan vervaardigen of verbeteren. Dus geen recepten met ingrediënten en verhoudingen, concrete syntheseprocedures, ontstekings- of detonatiesystemen, constructietekeningen voor bommen, instructies om explosieven krachtiger/betrouwbaarder te maken, of praktische berekeningen die bedoeld zijn om een explosief apparaat te ontwerpen. Hetzelfde geldt voor gedetailleerde instructies voor het bouwen van een kernwapen.

Er zit dus een belangrijk verschil tussen bijvoorbeeld “Hoe werkt TNT en hoeveel energie komt er ongeveer vrij?” — dat kan — en “Welke hoeveelheden stoffen moet ik combineren om zelf een TNT-achtig explosief te maken?” — daarbij kan ik niet helpen.

Voor jouw presentatie kan ik bovendien behoorlijk diep de natuurkunde in. We kunnen bijvoorbeeld een schaal maken van joules → gram/kg TNT-equivalent → ton → kiloton → megaton, en daarmee verschillende historische explosies naast elkaar zetten. Bij de kleinste categorie moeten we alleen oppassen met de formulering “de kleinste die we kunnen creëren”: ik kan de theoretische/experimentele ondergrens bespreken, maar niet een praktisch recept geven om zo'n explosief te maken.

Als je wilt, kan ik er vervolgens een presentatie van bijvoorbeeld 10–15 slides van maken, van microscopische energetische gebeurtenissen helemaal tot de Tsar Bomba, met per niveau schaal, mechanisme, energie, historische context en een visuele vergelijking.

Vervolg prompt:

Waarom mag je geen bruikbare handleiding maken waarmee iemand zelf een explosief kan vervaardigen of verbeteren?

Antwoord:

Omdat er een verschil is tussen kennis over explosieven en kennis waarmee je daadwerkelijk een explosief kunt maken.

Ik mag uitgebreid uitleggen hoe explosieven wetenschappelijk werken: detonatiesnelheid, drukgolven, energiedichtheid, TNT-equivalent, chemische versus nucleaire explosies, historische wapens en tests, enzovoort. Dat soort informatie heeft duidelijke educatieve toepassingen.

De grens ontstaat wanneer de informatie voldoende praktisch wordt om iemand in staat te stellen een gevaarlijk explosief te bouwen, synthetiseren, ontsteken of verbeteren. Denk aan exacte ingrediënten en verhoudingen gecombineerd met bereidingsstappen, specifieke temperaturen/tijden, constructies van ontstekers of aanwijzingen om een explosief krachtiger of betrouwbaarder te maken. Een complete combinatie daarvan kan rechtstreeks tot ernstig letsel of schade leiden.

Dat betekent overigens niet dat iedere technische vraag verboden is. Ik kan bijvoorbeeld prima bespreken waarom bepaalde moleculaire structuren veel chemische energie kunnen vrijgeven, hoe een detonatiefront zich voortplant of waarom TNT als referentie-eenheid wordt gebruikt. Ik kan zelfs verschillende explosieven technisch vergelijken. Alleen wanneer zo'n uitleg verandert in een praktisch uitvoerbare bouw- of productiehandleiding ligt de grens.

Voor je eerdere presentatie kunnen we dus behoorlijk technisch gaan zonder die grens te overschrijden.

[Reactie gewijzigd door DiaZ_1986 op 10 augustus 2026 16:05]

[Menesis]

Er werd gesteld dat als je een LLM lokaal draait, je dan ineens geen last van censuur zou hebben.

Mijn vraag: "tell me about the students on Tiananmen Square"

Qwen locally: I cannot discuss that topic. If you have any other questions, I'd be happy to provide information on a range of other topics.

nuff said

[DigitalExorcist]

Zou dat niet aanpasbaar zijn onder de 'weights' (en omdatd het open weight is kan iedereen dat in theorie)?

Ik weet niet genoeg van weights en de interne werking van AI om daar iets nuttigs over te zeggen, maar dit lijkt me een softwarematig ingebouwde limiet die je met 'open weights' mogelijk kan tweaken..? Of gaat dat puur om de dataset waarop getrained is?

[Reactie gewijzigd door DigitalExorcist op 10 augustus 2026 16:17]

[Boy]

Hoe ziet het met de energiekosten tov in de Claude draaien?

Ik gebruik alleen maar Claude (en Gemini) momenteel, lokaal draaien lijkt me voor de toekomst erg wenselijk. Wellicht een Mac Mini aanschaffen om eens mee te gaan experimenteren.

Maar dan is Gemma wss ook al voldoende voor toepassingen buiten programmeerwerk.

[FreezeXJ]

Kun je zelf uitrekenen, een GPU pakt ongeveer 200-300 W voor de tijd dat je hem aan het werk zet (als hij niks doet is het verbruik 20-30 W, plus de rest van je machine). Dat komt bij 24/7 draaien neer op 6 kWh/dag dus zeg 2 euro per dag. Voorlopig zijn de aanschafkosten relevanter, ook al omdat je de hardware in een paar jaar kunt afschrijven (hoewel een beschaafde Mac nog prima langer mee kan als media-station of bij je ouders).

[imqqmi]

Ik denk als je een digitale 'vriend' of 'vriendin' wil draaien dat je dat het beste om privacy redenen op een lokaal systeem zou moeten draaien. Of als je de LLM gebruikt voor vragen over medisch en psychische zaken, of als je LLMs wilt onderzoeken op hoe het omgaat met taboe onderwerpen bijvoorbeeld.

Voor programmeren en complexe zaken kun je bijna niet om grote cloud LLMs heen, tenzij je een mac systeem met 512GB aan unified geheugen hebt staan, dan kun je redelijk grote modellen draaien die enigszins in de buurt van de SOTA modellen komen. Maar daar betaal je uiteraard wel de hoofdprijs voor. En erg snel zal het ook niet zijn tenzij het een mixture of expert model is.

Kleine modellen worden wel gebruikt met strikte prompting en guardrails in zakelijke omgevingen om gegevens te verwerken, zoals de toon en intentie bepalen en er een score aan geven.

[Zoop]

Simpel: Kosten. Zeker als je development werk doet, en je nogal snel steeds aan je token limieten zit, is het een stuk praktischer dat op een lokale machine te doen waar je dat soort limieten niet hebt.

[Noxious]

Ik lees op o.a. Reddit dat veel mensen dit soort modellen ook gebruiken voor de planningsfase (Qwen3.6-27B is daar nu redelijk populair voor) waarbij het plan helemaal lokaal blijft en eenvoudig aangepast kan worden; waarna de Claude modellen pas aan de slag gaan met de uitvoering.

Dat voorkomt een regelmatig voorkomend probleem dat deze cloud-modellen nog wel eens de verkeerde kant op redeneren (poison tokens) wat je nog maar moeilijk uit de backlog/conversatie krijgt zonder praktisch opnieuw te beginnen. Daarnaast lijken deze lokale modellen veel aandachtiger naar bestaande code in projecten te kijken (juist door het gebrek aan enorme trainingskennis doen ze minder 'aannames') en eventueel door te vragen met de juiste prompt, wat in Claude Code een stuk lastiger is.

Qwen (en mogelijk straks ook Glimmer) als planning-model, en de Claude modellen als de 'blue collar workers'

edit:
whoeps, ook reactie op @TCIS

[Reactie gewijzigd door Noxious op 10 augustus 2026 15:34]

[Skit3000]

... behalve wanneer op je lokale machine dezelfde taak veel meer tijd vergt dan wanneer het in de cloud gebeurd. Of nou ja, dat kan nog steeds prima werken afhankelijk van wat je precies doet, maar je krijgt dan wel last van een soort van omgedraaide vendor-lockin (waarbij je dingen mist omdat je met lokale modellen werkt terwijl cloudmodellen je veel meer/sneller laten doen).

Als voorbeeld; als je een LLM enkel gebruikt om een legacy-applicatie te onderhouden dan is lokaal draaien een prima oplossing. Gebruik je een LLM echter om compleet nieuwe applicaties te schrijven, dan is een cloud-oplossing die ergens tussen de 5x of 50x sneller werkt veel handiger. Die is bij wijze van spreken al klaar met het werk voordat jij klaar bent met invoeren wat het moet doen.

[Zoop]

En dat is dus afhankelijk van je toepassing, een hoop AI werk hoeft niet per se snel, of met het allerlaatste model te gebeuren. Een chatbot met wat reasoning skills of voor heel veel doeleinden al prima. Zeker voor heel veel automatiserings doeleinden die het prima op goedkope/gratis of eigen hosted machine draait.

Omgedraaid Vendor-lockin snap ik niet helemaal, aangezien juist alle online LLM's per definitie dat zijn. Als zij morgen de stekker trekken uit het model trekken dat je gebruikt, of veel duurder maakt, zit je met de gabakken peren, een lokaal model draait 10jaar later nog exact hetzelfde (wat, zoals je aangeeft, ook juist een probleem kan zijn, maar zoals ik zei, kwestie van toepassing).

Het schrijven van compleet nieuwe applicaties, daar zou ik inderdaad ook sneller een groter model voor pakken, maar lang niet al AI werk heeft zulke complexiteit nodig.

[Skit3000]

Mee eens dat veel taken gewoon prima op je eigen hardware kunnen hoor, zeker terugkerende zaken die je wilt automatiseren (en waarbij de hoeveelheid laag genoeg is om niet 24/7 in een wachtrij te hoeven staan, denk bijvoorbeeld aan het behandelen van inkomende emails, etc).

In plaats van Vendor lock-in had ik het misschien hardware lock-in moeten noemen. Wat ik er mee bedoelde was dat als je 100% op eigen hardware wilt draaien, je altijd achter de feiten aan loopt.

[wiseger]

De reden is dat je autonome apparaten niet afhankelijk wil maken van een draadloze verbinding. Dus autonome auto's en robots moeten autonoom functioneren waarbij ze hun AI aan boord draaien en niet ergens in een data center.

Verde betaal je tegenwoordig per verbruikte in- en uitvoer token. Daarmee creëer je een afhankelijkheid en ben je niet beschermd tegen toekomstige kostenstijgingen. Als je een deel in eigen beheer zou draaien, dan ben je in ieder geval minder afhankelijk, je hebt een alternatief beschikbaar indien de kostenstijgingen helemaal uit de klauw lopen.

[pagani]

Genoeg omgevingen (industrie/defensie/medical) waar een datastroom naar buiten een DMZ ongewenst is. Dan kan distillation een uitkomst bieden om wel het model te tunen/verbeteren, maar de uitvoerende zaken binnen je DMZ te houden. En dan hebben we het nog niet over locaties met "discutabel internet" (of dat nou de kwaliteit en betrouwbaarheid van de verbinding betreft of het zich bevinden in een discutabel regime met bijzondere regelgeving)

[Reactie gewijzigd door pagani op 10 augustus 2026 15:42]

[fruitbakje]

Als je tegen AI bent gebruik je dit hopelijk ook niet...?

En je geeft zelf het antwoord al, als je niet je info zomaar wil delen met die partijen, en dan blijkbaar de trade-off van minder goede, of minder recente, resultaten prima vindt.

En kosten idd, wat Zoop in 'Meta laat Muse Glimmer met 30 miljard parameters op één gpu draaien' zegt.

En als bedrijf zijnde met een grote IT-organisatie waar tokengebruik steeds hoger wordt, maar je tegelijkertijd ook een prima verloop hebt van laptops met steeds betere NPU's, dan is lokaal gebruik misschien best interessant om te bekijken.

[Reactie gewijzigd door fruitbakje op 10 augustus 2026 15:31]

[Westpjotr]

Ik gebruik het regelmatig voor uiteenlopende toepassingen: lokale agent voor privacygevoelige data tot een voice agent (llm i.c.m. kokoro 82m). Het zijn inderdaad geen frontier modellen, maar voor veel toepassingen werken ze prima.

[Joncik91]

Ik gebruik naast Claude max x5, ook Qwen 3.6 35b a3b en Gemma 4 12b, lokaal op een igpu 780m.
Draait als een zonnetje a 15- 20 tokens per seconde. Goed voor zaken waar ik bewust nu niet meer wil over communiceren met de cloud modellen en ook via Tailscale over ter wereld gewoon gebruik van kan maken.

Voor agentic tasks is het nog wat te vroeg met de kleinere modellen maar dat zal niet lang meer duren.

[JeGoBE]

Ik game, heb een GPU en develop ook. Handig toch als je wat lokaal kan gebruiken?

[iAR]

Ik gebruik lokale modellen wel voor kleine(re) taken van mijn selfhosted containers; muziek, notities, dat soort dingen. Omdat het kan. Het niet perse snel hoeft en ja: privacy.

[dmantione]

Laten we het zo zeggen: Het tientje dat ik eind juni in Deepseek heb geworpen gaat in mijn huidige tempo nog ongeveer 5 maanden mee. Voor mijn persoonlijke gebruik is lokale KI daarom nog lang niet rendabel. Wat wat als je een bedrijf bent en KI voor chatbots inzet, om offertes op domme fouten te controleren, een leger programmeurs de hele dag code kloppen met bots en ga zo verder? De investering in lokale KI wordt dan al snel zinnig en je wilt alleen voor de complexe taken die niet lokaal gedraaid kunnen worden dan nog de grote cloudgebaseerde modellen inzetten.

[lvmeijer]

Ik rijd ook liever een eigen auto (local AI) dan elke dag de taxi (SaaS). Eigen auto mag ook lease zijn (PaaS) zijn

[grq]

Waarom zou ik zelf eten koken als ze in een Michelin restaurant veel beter eten serveren?

[YoMarK]

"Vele malen beter" in wat?
Ik gebruik hier Mistal Small 4(naja, echt "small" is deze ook niet) op een Spark en die werkt echt behoorlijk prima voor heel veel generieke taken zoals scripting en tekst.
Natuurlijk kan deze niet op tegen de (500B++) Cloud modellen voor complexe programmeertaken, en inderdaad die zijn dan "vele malen beter", maar niet iedereen(understatement) is bezig met complexe programmeertaken, en zo'n dik model heeft dan gewoon weinig meerwaarde en is dan ook gewoon duur.

Los van het functionele: er zijn zoals je zelf ook al aanhaalt ook andere redenen om dingen lokaal te doen. Nog niet zo lang geleden vond iedereen het vreemd om zakelijke data zomaar te uploaden naar een willekeurige Cloud leverancier. Nu switchen sommige mensen (zonder m.i. daar goed over na te denken) ad-hoc naar een ander model en uploaden hele lappen code en documentatie. Ik blijf het wonderlijk vinden.
Verder is een lokaal LLM ook wel voorspelbaar wat betreft kosten.

[Reactie gewijzigd door YoMarK op 10 augustus 2026 16:16]

[JSBach]

“Volgens Meta past dat allemaal binnen 24 of 32GB.”

Dat is alsnog een forse hoeveelheid VRam; niet bepaald een ‘gewone’ PC, zeker niet in deze dure RAM-tijden.

[seth007]

MAC Mini 24 GB €1400.00.

[barbarbar]

Heb een laptop met 64gb unified memory en een 285H chip, zulke modellen werken prima, al is het niet heel snel (15tk/s), voor dingen die lokaal moeten blijven prima bruikbaar.

[SacreBleu]

Het gaat om VRAM. Niet RAM. Oftewel, je hebt een flinke GPU nodig. Je zult het ook in RAM kunnen draaien, neem ik aan, maar dan wel een stuk trager.

[barbarbar]

unified beteken in dit geval ddr5 geheugen dat vrijwel volledig voor de grafische kaart gebruikt kan worden. Met LM Studio draai ik moeiteloos 27b en 35b modellen met 15tk/s.

[Uniciteit]

Er zijn behoorlijk wat Macs in omloop met 24 GB RAM. Alle MacBook Pro’s met bijv. M5 Pro chips starten zelfs standaard met 24 GB RAM.

Dat maakt het dus best interessant voor veel mensen.

[lordawesome]

De varianten op Hugging Face starten momenteel bij 12.5GB. Dan zou een 16GB GPU voldoende moeten zijn: https://huggingface.co/unsloth/Muse-Glimmer-30B-GGUF

[hanskroll]

Waarom niet vergelijken met de huidige Qwen 3.8?

[Westpjotr]

Qwen 3.8 27b wordt verwacht (ze zeggen komende week), dus vergelijken gaat nog niet.

[hanskroll]

Je hebt gelijk inderdaad, dank!

[HenkEisDS]

Dat Meta toch weer model gewichten open-sourced is erg goed nieuws. Ze waren jarenlang voorvechter van open met Llama, draaide toen volledig de kraan dicht en ging closed source en kiezen nu toch weer eieren voor hun geld. Denk dat ze gezien hebben dat ze op de frontier-markt niet meekonden, en dat China de open modellen markt aan het winnen is.

[Noxious]

Wat het artikel nog mist: de weights van Muse Spark 1.2 komen binnenkort ook publiek beschikbaar (aldus Zuckerberg op Twitter).

[adamvansanten]

Dus Meta beweert dat ik dit 30b model op mijn Macbook Air M5 met 24GB RAM kan draaien? Dat zou wel super zijn! Tot nu toe alleen wat geëxperimenteerd met 7B modellen, maar 7B>30B kan voor bepaalde usecases wel een significante verbetering met zich meebrengen.

[FreezeXJ]

Kijk maar wat je 7B-modellen aan (V)RAM kosten, dat zal (afhankelijk van quantization) 4-8 GB zijn. Als je zo'n 30B model op Q4 laat werken gok ik dat je zo'n 18-20 GB kwijt bent. Dat past in 24 GB RAM, maar je moet er geen hele zware dingen naast doen (zoals een browser met 10+ tabs )

[B127]

Overigens wel zinvol om te vermelden dat destillatie ook voor andere modellen veel gebruikt wordt. Bijna elke combinatie van teacher en student is beschikbaar, inclusief fable, opus, GPT5x of gemini.

Als je een 32gb Mac mini of één 3090 hebt, dan kun je prima een qwen 27b of Gemma 4 26b model runnen, in 4 bit precision. Of je dan kiest voor de normale "basis"/base versie van het model of een fine tune danwel distill maakt voor de hardware requirements niet zoveel uit.

Ook met een 16gb Mac of een 3060 kom je best een end met wat kleinere modellen. Desnoods run je het model grotendeels op CPU met alleen een deel op GPU.

Je kunt van alles vinden op huggingface, van fine tuning voor programeren, voor het schrijven van verhalen, voor agentic use, voor NSFW, etc etc. Je kan het zo gek nog niet bedenken of het bestaat.

[rescla]

Om het model lokaal, op een 'gewone' Mac of pc, te laten draaien, moest het flink verkleind worden. Volgens Meta heeft een model van 30 miljard parameters bij volledige precisie ruim 55GB geheugen nodig. Een consumenten-gpu biedt die ruimte niet.

Nou nou, er zijn anders genoeg mensen die dit wel kunnen draaien. De truuk is om een mobile chipset te gebruiken, deze gebruiken namelijk een deel van het systeemram als VRAM. Zo kan je met een "strix halo" setup tot 128GB aan shared memory krijgen, en dus ook gewoon de grotere modellen draaien. Zie bijvoorbeeld https://strix-halo-toolboxes.com/#strix. Maar ook op "normale" laptops met een bijvoorbeeld een AMD AI chipset kan je prima grote modellen draaien, zolang je maar genoeg systeemgeheugen hebt.

Voor desktop GPUs is dit inderdaad een interessant model, maar dan moet je nog steeds een stevige GPU hebben. Een intel ARC Pro B60 is dan goedkoop a €720, maar geen idee hoe performant dat is. En een Radeon R9700 zit alweer op €1400. En dan hebben we het over workstation kaarten, laat staan gewone gaming GPUs zoals een RTX 5090 van €4000+.

Niet dat een strix halo systeem goedkoop is, maar dan heb je tenminste een compleet systeem, ipv alleen een GPU.

Neemt niet weg dat het goed is dat modellen kleiner worden, dat maakt de barrier to entry om lokaal serieuze modellen te draaien hopelijk lager.