Not a trolling question, genuine interest.
Usually there are some static experts in each attention layer, plus a whole bunch of dynamically-routed experts. Typically some form of LRU cache is used for the dynamic experts.
So you can keep only the static expert(s) and routing layers in memory and then stream the dynamic experts from SSD, at a modest inference speed cost driven by the latency required to load layers from SSD when they aren’t already in the memory cache.
The LRU cache works reasonably well because a given task will often hit the same experts on each iteration of the forward pass.
For example, on a Mac Studio, Qwen3.8-flash-next (180b total parameters) with 50% of experts in memory and n-gram offloading has about 1/4 to 1/3 the inference speed of everything in memory. That requires 32GB of vRAM for the weights (plus a little extra for context, obviously)
I can't, however, run DS4.1-1017, for example, but maybe I didn't find proper options and quantization yet.
So I'm really interested how to be sure what can/cannot fit in specific hardware (for example, I want to buy a Mac Studio with 64 or 128 GB RAM, what MoE model it would run at comfortable speed? Will it be qwen-flash-next or something bigger? And so on). So far websites with "benchmarks" were really terrible in that regard (and huggingface calculator even worse!)
This is expected if you're actively steering the agent, but what about running unattended tasks - perhaps multiple such tasks in parallel, such that you can stay engaged by "attending" to each of them in turn? Then you're not restricted to such a requirement, and can benefit from much slower (individually, not wrt. total throughput) inference streams.
> I currently have 192GB and 24GB VRAM
I'm not familiar with beellama, but this seems like it could be the perfect setup for Strata which people are saying good things about, including for running DS4.1F (at least quantized). The whole point of it is to effectively leverage heterogenous RAM/VRAM setups. Of course llama.cpp itself is doing a good job of trying to catch up, but they've yet to support efficient SSD streaming (mmap doesn't quite cut it) in the main branch.
This depends on how you plan to use the machine... but Qwen-flash-next is right at the top of what a 128GB Apple Silicon can do.
QFN with 4bit quantization will run "comfortably" with all weights in memory and a 128k context on a 128GB machine. On M5 Max w/ 128GB, that will give about 75 tok/sec (using oMLX with MTP enabled). It spits out text much faster than I can read.
However, this truly uses all the RAM. You'll have like 8-12GB left for the OS and apps, which isn't really enough to actually use the machine as a workstation while the model is loaded. But it would work fine as an inference server with Opencode running on your laptop. (Hence, "how you plan to use it?")
Alternatively, you can offload QFN's n-gram table to SSD (this is just a settings option in oMLX), which drops generation speed on the same machine to ~60-65 tok/sec (assuming the model lives on the internal SSD) and reduces memory usage to ~90GB with even a large context. That leaves plenty of RAM to use the Studio as your main workstation. Also, you may run much longer contexts because of the extra memory headroom.
Second alternatively, you can use oMLX's expert offloading feature to keep 50% of experts in memory (with n-gram offloading also). This reduces the RAM footprint to a little over 32GB + context. Offloading the experts drops generation speed to around 20-25 tok/sec on the same machine as above, but it would allow you to comfortably run on a 64GB machine, while still using it as a workstation.
I have tested the 50% expert offload case on an M1 Max / 64GB, and the inference speed is only a little slower (more like 18-20 tok/sec) than M5 Max / 128GB because in both cases the bottleneck is SSD read bandwidth and the GPU is spending a lot of time idle.
One last thing: GLM 5.3-flash doesn't use an n-gram table, so you can't use that trick to reduce memory footprint. You'd need to use expert offloading to make it fit a 128GB machine. Since it has over twice as many active parameters as QFN (which doubles the required SSD read bandwidth), my guess is that a 128GB Studio would not be much faster than your current setup for that model.