Yes, I understand the principle, but will it be usable? E.g. in my personal opinion border of usefulness starts somewhere at 7-10 tok/s. I currently have 192GB and 24GB VRAM, and I can run Qwen-Flash-Next (4 bit) and GLM5.3-Flash (4 bit) at 25 tok/s and 7 tok/s respectfully (with quantized cache on beellama). Parallel queries worsen result significantly but can push aggregate to around 50 tok/s.
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!)
> in my personal opinion border of usefulness starts somewhere at 7-10 tok/s.
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.