Meta knows how to win back developer's hearts .... let's see if they have the goods
Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows
21–30 of 678 posts
Re: Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows
#22Re: Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows
#23Still needs 32-64GB memory to run it locally. 64GB Macbook pro with an M5 chip costs more than 4k Euros in Germany. A more practical model would be a language specific (e.g Python or JVM language) and excellent at tool calling and reasoning. Maybe that way they can shrink it even more.
Even if you had a 64GB machine: Are you willing to reserve 90% of your memory to run a LLM? With dirt cheap models like deepseek-v4-flash that will run "forever" on $10, the answer for me is clearly: no.
When it's free, you are the product.
Re: Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows
#24What I think would be perfect is a model that could run on a single DGX spark and be competitive with DSV4 Flash 731. Flash is already a game changer. Hopefully meta plans on this, like the old 70b. V4 flash is smart enough for any use but slightly too big. 27b-30b isn’t intelligent enough.
It's a dense model, not MoE like e.g. Qwen 35b or Gemma 4 26B A4B. On a Spark it will be memory bandwidth limited
I haven't tried yet (working on it) but back of the napkin estimate puts it at around 15tok/s even after converting to NVFP4. Prefill would be much higher though. That 15tok/sec is pretty typical for dense models of this size:
NVFP4 Q/K/V/O and MLP projections: ~13 GB/token
BF16 attention gates: ~3 GB/token
BF16 LM head: ~2.5 GB/token
Total: ~18.9 GB/token
At 273 GB/s, that gives a bandwidth-only ceiling of about 14.5 tok/s; actual performance would be lower.
Re: Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows
#25Still needs 32-64GB memory to run it locally. 64GB Macbook pro with an M5 chip costs more than 4k Euros in Germany. A more practical model would be a language specific (e.g Python or JVM language) and excellent at tool calling and reasoning. Maybe that way they can shrink it even more.
There have been discussions on language specific not really being a relevant change to reduce size.
On the other hand, at the GTC was a talk about coding in different lanugage (like spanish) and explaining that the quality between spanish and english is relevant different.
But i have not found a good article about the impact of learning data with practical experiments or even if the order of the learning data matters.
At least I think i remember that Meta mentioned having better and less data can be better than more data with lower quality.
As long as these models can explain to you facts about any other topics, its still overfitted for the task though.
Re: Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows
#26Still needs 32-64GB memory to run it locally. 64GB Macbook pro with an M5 chip costs more than 4k Euros in Germany. A more practical model would be a language specific (e.g Python or JVM language) and excellent at tool calling and reasoning. Maybe that way they can shrink it even more.
Re: Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows
#27Still needs 32-64GB memory to run it locally. 64GB Macbook pro with an M5 chip costs more than 4k Euros in Germany. A more practical model would be a language specific (e.g Python or JVM language) and excellent at tool calling and reasoning. Maybe that way they can shrink it even more.
Even if you had a 64GB machine: Are you willing to reserve 90% of your memory to run a LLM? With dirt cheap models like deepseek-v4-flash that will run "forever" on $10, the answer for me is clearly: no.
Its not just that you send a sentence to an API endpoint, you always send EVERYTHING to that agent as a context.
You want to analyse your spending history? You now send everything to someone.
Either no one cares but understands this implication on how easy it is to really capture you or no one really things about it.
But i'm a lot more diligent on what I send. I disabled the gemini activity feature for example because google started telling me that my stuff could be reviwed by humans.
Re: Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows
#28Optimizing speed is really the way to go. Yet 24GB is not what everyone can afford. Maybe we could take some of those 56tk/s and transfer into some free RAM space using MoE loading ? I'd be glad with a less than 10GB and more than 6tk/s model.
MoE will be faster because it will read less memory for sure, you still have to have it though.
Re: Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows
#29Still needs 32-64GB memory to run it locally. 64GB Macbook pro with an M5 chip costs more than 4k Euros in Germany. A more practical model would be a language specific (e.g Python or JVM language) and excellent at tool calling and reasoning. Maybe that way they can shrink it even more.
I'm sooo happy I pulled the trigger on upgrading and getting a new laptop (with 64 GB RAM) last summer. Feels like it was just in time before the exponential price jumps.
Re: Muse Glimmer: 30B-parameter model optimized for always-on local agent workflows
#30Optimizing speed is really the way to go. Yet 24GB is not what everyone can afford. Maybe we could take some of those 56tk/s and transfer into some free RAM space using MoE loading ? I'd be glad with a less than 10GB and more than 6tk/s model.