LM Studio lanserar Muse Glimmer 30B – gör minneskontrollen före nedladdning

LM Studio meddelade den 10 augusti att Muse Glimmer 30B går att hämta och köra lokalt i LM Studio Bionic. Innan du startar en nedladdning på tiotals gigabyte behöver du skriva ned exakt vilken variant du tittar på, hur stor filen är och hur mycket minne som faktiskt är ledigt på maskinen. Modellnamnet ”30B” räcker inte som minnesbudget.

Nyheten: en 30B-modell för lokala agentflöden

Muse Glimmer kommer från Meta och modellkortet daterar lanseringen till augusti 2026. Modellen har ungefär 29,6 miljarder parametrar inklusive en bildkodare och är avsedd för bland annat verktygsanrop, bildindata och flerstegsuppgifter. LM Studio har lagt till modellen i sin katalog och beskriver hur den öppnas i Bionic. Licensen anges som Apache 2.0 i både Metas modellkort och LM Studios lanseringstext.

Uppgifterna säger inte hur snabbt modellen går på din dator, om dess svar är tillräckligt bra för din uppgift eller om ett visst agentflöde fungerar stabilt. Sådant kräver ett lokalt prov med angiven variant, runtime, kontext och hårdvara. Den här kontrollen stannar därför före prestandabedömningen: först ska modellen få plats utan att du gissar.

Tre minnessiffror som inte är utbytbara

LM Studios katalog visar posten meta/muse-glimmer med storleken 25,77 GB. På samma sida står att den minsta Muse Glimmer-varianten kräver minst 26 GB RAM. Det är en kataloguppgift om modellen som LM Studio erbjuder och ett angivet golv för systemminne. Den får inte skrivas om till ”26 GB VRAM” eller till ett löfte om att hela arbetslasten ryms bekvämt i 26 GB.

Metas modellkort beskriver andra paket och ett annat mått. Där anges full precision mot 64 GB VRAM, K-Quant-Dynamic mot 32 GB VRAM och K-Quant-17GB mot 24 GB VRAM. Meta skriver också att ungefär fyrabitskvantisering krymper själva språkmodellen till under 20 GB, så att det finns utrymme kvar för KV-cache, bildkodare och den separata DFlash-komponenten inom de angivna minnesramarna.

Skillnaden mellan RAM och VRAM är särskilt viktig på en dator med separat grafikkort. På en maskin med delat minne kan samma fysiska minnespool användas av flera delar av systemet, men operativsystemet och andra program tar fortfarande plats. Jämför därför alltid källans minnestyp med den minnesarkitektur din egen maskin faktiskt har. Hårdvaruguiden visar hur du bygger en budget med vikter, KV-cache, runtime och marginal i separata rader.

Preflight: skriv ned fyra värden före hämtningen

Öppna modellposten i LM Studio men tryck inte på Download ännu. Skapa i stället en kort kontrollrad med fyra fält. Om något fält saknas är beslutet ”stopp” tills du har hittat uppgiften.

1. Exakt variant. Kopiera hela namnet på artefakten eller kvantiseringen, inte bara ”Muse Glimmer 30B”. Skriv också om du tittar på LM Studios katalogpost, Metas K-Quant-Dynamic, K-Quant-17GB eller en annan fil. Kraven från en variant får inte flyttas till en annan.
2. Filstorlek och ledigt diskutrymme. Anteckna den visade nedladdningsstorleken och kontrollera ledigt utrymme på den disk där LM Studio sparar modeller. Lämna utrymme även för andra modellfiler, uppdateringar och temporära data; en fil som precis får plats på disken säger inget om att den får plats i arbetsminnet.
3. Installerat och ledigt minne. Skriv ned installerat RAM, ledigt RAM före start, total VRAM och ledig VRAM. Stäng inte bakgrundsprogram bara för att få en tillfällig grön siffra om de normalt måste vara öppna när modellen används. Provet ska beskriva din verkliga arbetsstation.
4. Planerad kontext och extrafunktioner. Sätt en första kontextlängd innan du uppskattar minnet. Metas modellkort anger stöd för 131 072 token eller mer, men maximal stödd kontext är inte en rekommendation att börja där. Notera också om bildindata och den separata drafter-komponenten ska användas, eftersom de ingår i Metas resonemang om minnesutrymme.

Kontrollraden kan se ut så här: variant: [namn] · fil: [GB] · RAM installerat/ledigt: [GB/GB] · VRAM totalt/ledigt: [GB/GB] · kontext: [token] · bild/drafter: [ja/nej]. Fyll i verkliga värden. Kopiera inte siffrorna ur ett exempel eller från en annan dator.

Använd LM Studios estimator efter nedladdning – före laddning

När en vald variant väl finns lokalt kan LM Studios CLI visa den exakta modellnyckeln och göra en resursuppskattning utan att ladda modellen. Kör först:

lms ls --detailed

Kommandot listar hämtade modeller med bland annat storlek, arkitektur och parametrar. Kopiera modellnyckeln för den fil du faktiskt hämtade. Kör sedan en uppskattning med den kontext du tänker börja med:

lms load --estimate-only MODELLNYCKEL --context-length 8192

Byt MODELLNYCKEL mot värdet från din egen lista. LM Studios dokumentation säger att --estimate-only skriver ut uppskattat GPU-minne och totalt minne utan att ladda modellen, och att bland annat kontextlängd, GPU-offload, flash attention och bildstöd kan påverka uppskattningen. Upprepa därför kommandot med den kontext och GPU-fördelning du faktiskt tänker använda, inte bara med standardvärden.

Estimatorn är ett planeringsvärde, inte ett prestandatest. Spara dess utdata tillsammans med LM Studio-version, modellnyckel och inställningarna. Om modellen senare laddas ska den verkliga minnesanvändningen mätas separat. För modelljämförelser behöver du dessutom ett eget provpaket; modellguiden beskriver vilka resultat som ska dokumenteras.

Beslut: hämta, välj mindre eller stoppa

Hämta den valda varianten först när filen ryms på rätt disk, minnestypen i källan stämmer med din jämförelse och estimatorn lämnar en uttrycklig marginal för operativsystemet och dina normala program. Skriv marginalen i gigabyte i stället för ”det borde gå”.

Välj en mindre variant om den exakta filen eller estimatorn passerar din budget men katalogen erbjuder en annan namngiven kvantisering. Gör då om hela kontrollraden. En mindre fil kan ändra både kvalitet och minnesbehov; den är ett nytt testfall, inte samma modell med en kostnadsfri besparing.

Stoppa om du bara känner till parameterantalet, om RAM blandas ihop med VRAM, om du saknar ledigt utrymme eller om kalkylen kräver att all annan normal belastning stängs. Stoppa också om du tänker börja med lång kontext men bara har kontrollerat modellfilens storlek. Det är billigare att sakna en lokal modell än att ladda ned 25,77 GB för att först därefter upptäcka att arbetsfallet inte ryms.

Det här återstår efter minneskontrollen

En godkänd preflight visar bara att det är rimligt att prova en bestämd variant med en bestämd konfiguration. Den visar inte att Muse Glimmer är snabbare än en annan modell eller bättre på kod, verktygsanrop, svenska eller bildtolkning på din maskin. För en sådan slutsats behöver du ange LM Studio- och runtimeversion, exakt kvantisering, testhårdvara, kontext, promptar och observerade fel.

Behåll därför tre separata poster i testloggen: källans krav, estimatorns värde och det uppmätta utfallet. Om de avviker har du något konkret att undersöka. Om de blandas ihop får du bara en ny siffra utan känt ursprung.

Källor

• LM Studio – Run Muse Glimmer locally, lanseringsdatum, Bionic och licens
• LM Studio – Muse Glimmer, katalogstorlek, RAM-uppgift och dokumenterade funktioner
• Meta – Muse Glimmer-30B Model Card, parametrar, kvantiseringar, VRAM-mål och kontext
• LM Studio CLI – lms load och minnesuppskattning med --estimate-only
• LM Studio CLI – lms ls, modellnyckel och lokala modelluppgifter

LM Studios och Metas dokumentation kontrollerades 16 augusti 2026. LM Studios katalogpost kontrollerades igen 10 september 2026: storleken 25,77 GB, kravet på minst 26 GB RAM och licensen Apache 2.0 var oförändrade. Katalogstorlek, kvantiseringar, runtime och minnesestimator är versionskänsliga. Nästa kontroll sker när någon av de tre produktsidorna ändras eller senast 10 oktober 2026.