upvote
I hope I'm not the only one who misread it as 292 tokens/s and got excited momentarily
reply
I do think these “run a bigger model than will fit in VRAM” projects are necessary steps, but are they functionally useful or helpful to anyone currently? For example, is anyone out there running a big Qwen for coding on a 16-32GB machine with these techniques?
reply
> but are they functionally useful or helpful to anyone currently?

Yes and no, depend on your expectations. Some/many like to run local LLMs just for the sake of it, so anything will do.

MoE are useful on PC systems, at the condition of having high enough memory bandwidth (and large amounts of RAM) - that is, Threadripper/Pro.

The advantage of MoE is that only a subset of the model's experts is used for each token, so not all weights need to be present in VRAM at once. The remaining weights can reside in system RAM, although moving and accessing them still carries a substantial performance cost (and that's why high memory bandwidth is needed).

reply
Does MoE help with multimodality? Can it in general enable reasoning in imagery (technical drawings, diagrams, schematics) rather than text-based?
reply
MoE has nothing to do with multimodality.

MoE is a concept proposed in 1991, before the deep learning era (which is before what I call the transformers era). You can think of it like sharing.

Contrary to popular belief; 'experts' in MoE LLMs do not specialize. There's no expert trained to be good at maths, or python, or writing, or whatever. It's an inference optimization.

As for reasoning in non-text modalities, you might find this paper interesting :) https://huggingface.co/papers/2502.05171

reply
Wait I thought the router ends up specializing the experts?

Like there is no explicit goal aside from each 'expert' getting roughly equal weight?

And it happens that when you train the router you do end up passing certain classes of problem to each expert - just as a training result nothing as clean as a python expert. But math vs creative writing will tend to rely on different experts over the majority of the inference?

I do not know what I am talking about, this is my limited understanding...

reply
> You can think of it like sharing.

was this meant to read "sharding"?

reply
Are people getting decent tokens/second throughput? Some of these demos crawl at 1 tok/s or worse, which limits their utility.
reply
yes, I average 80-120 tok/s on my RTX 3080 with gemma 4 and faster with Qwen 3.5. The main use-case here is just code-monkey agents. I'm not looking for architectural guidance, but an agent to take a spec and complete it.
reply
And is this using conventional model loading (all in VRAM), or are you streaming it in some way?
reply
in theory, QWEN3.6-35B-A3B should run as fast as a 3B model; and in practice, it can be just as dumb.
reply
> but are they functionally useful or helpful to anyone currently?

I've been building a SaaS that deals with data that can't be distributed to third parties. Some of the useful AI stuff I can add is not time sensitive and can run overnight. Things like this allow me to use higher quality models without selling my house for GPUs.

reply
deleted
reply
I don't need any of these to help with coding. skill issue.
reply
If I could justify wear and tear and electricity, I was willing to do something like this for batch processing. The batches would be a bunch of prompts whose outputs I'd look at the next day. Maybe common operations, like QA or refactoring, on whatever software I wrote.

If so, I could use a larger model than I have real-time hardware for. The largest, well-trained models can often get the output mostly right in one try. I also would be using AI's as a supplement to, not replacement for, my own brain. So, issues with the outputs wouldn't be a problem because I'm just keeping what's helpful.

If I still need to re-generate it all, it might still save money over time by avoiding cloud costs. Also, hardware that's already paid for is a sunk cost that doesn't inflate over time. Glitches in loading or destroying VM's might blow up into a big bill.

reply
at 5 minutes per token, you could look at the results next week
reply
That's way slower than I thought it would be. I struggle to imagine a use case.

If you had a deadly condition, and no diagnosis worked, and a specific model had the answer... past that I wouldn't use it.

reply
one week later: "It says 'You're absolutely right! Let me look at the seams so I'm checking, not guessing—' and I guess that's when my SSD melted."
reply
Turns out the SSD was load-bearing.
reply
At that point, how does this compare with simply running the model on the CPU?
reply
It matches my coding speed...its ok.
reply
Ahaha thank you, I naively assumed the unlabeled graph in the readme was tps, not spt!
reply
Running 292 tps on K3 would make your gpu a money printer.
reply
spt not tps
reply
I wonder what this measures in J/token.
reply
Assuming 30% gpu power utilization because of all the loading and unloading 29.2 kJ per token
reply
Damn 15 AK47 bullets per token
reply
How many is that in tokens per Scaramucci?
reply
It is a bit more than four tokens per millifortnight.
reply
that's 0.003 tokens/second. To get an hour's work done that's normally 30 tokens/second (108k output tokens in an hour) will take 416 days at this rate. And if you're using 100 watts, during that time you will spend $124.61 in electricity, as well as not being able to use your device for something else, plus the noise and heat from your device.

For $124, on Moonshot's official Kimi K3 API rates ($0.30 per 1M cached input, $3 per 1M fresh input, $15 per 1M fresh output), you can purchase 42 million fresh-input tokens, or 8.3 million generated output tokens, in whatever mix you want.

So what you get is 80x more expensive and you wait 416 days to get it.

reply
deleted
reply
Wow, you could do a lot at 292 tokens a sec—oh.

I have all praise for those taking this on and in my idiom would call it *the lord's work."

The image I reliably summon to mind is that compilation video showing the progress of Boston Dynamics bots. The curve between technically functional, to comically slow, to too slow for "real" work, on to, OMFG, may prove a (rough) curve.

It's work like this that moves things forward.

reply
Hah I was looking for it and couldn't work out how many years/token. 292s is pretty good.
reply