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?
pizza234 4 hours ago [-]
> 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).
ddevnyc 3 hours ago [-]
Does MoE help with multimodality? Can it in general enable reasoning in imagery (technical drawings, diagrams, schematics) rather than text-based?
dannyw 3 hours ago [-]
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.
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...
bensyverson 3 hours ago [-]
Are people getting decent tokens/second throughput? Some of these demos crawl at 1 tok/s or worse, which limits their utility.
reactordev 3 hours ago [-]
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.
bensyverson 3 hours ago [-]
And is this using conventional model loading (all in VRAM), or are you streaming it in some way?
1 hours ago [-]
nickpsecurity 3 hours ago [-]
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.
parineum 1 hours ago [-]
at 5 minutes per token, you could look at the results next week
bensyverson 27 minutes ago [-]
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."
aaroninsf 11 minutes ago [-]
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.
xnorswap 4 hours ago [-]
I wonder what this measures in J/token.
throwawayffffas 3 hours ago [-]
Assuming 30% gpu power utilization because of all the loading and unloading 29.2 kJ per token
donquichotte 2 hours ago [-]
Damn 15 AK47 bullets per token
jackb4040 4 hours ago [-]
Ahaha thank you, I naively assumed the unlabeled graph in the readme was tps, not spt!
throwawayffffas 3 hours ago [-]
Running 292 tps on K3 would make your gpu a money printer.
meneton 1 hours ago [-]
spt not tps
4 hours ago [-]
logicallee 3 hours ago [-]
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.
mring33621 3 hours ago [-]
How many is that in tokens per Scaramucci?
exe34 2 hours ago [-]
Hah I was looking for it and couldn't work out how many years/token. 292s is pretty good.
roger_ 4 hours ago [-]
Seeing a lot of these “run 1TB models with 1GB RAM” projects recently. Most seem vibe coded and probably won’t be maintained.
Hoping a winner emerges with some real momentum behind it.
hiramwen 4 hours ago [-]
You don't really need a maintainer when codex or claude code can set it up for you; thats how I got Trellis2 working on windows and tiny VRAM despite Microsoft recommending you have 24GB VRAM and Linux. Models are pretty disposable now.
tecleandor 1 hours ago [-]
So, instead of having one or two maintained projects that work super well, now we have hundreds or thousands of people half-assing it locally each time they need it? Doesn't sound efficient.
esafak 18 minutes ago [-]
I have the same objection to forking open source projects; changes should be upstreamed when possible.
titularcomment 3 hours ago [-]
This is complete dependency on LLM tools all the way from development to usage, and is risky as well as prone to failure
hiramwen 3 hours ago [-]
Local inference without access to internet and tools is pretty safe, worst you get is a slop output, best case it solves your prompt.
akie 4 hours ago [-]
No no, don't just say "vibe coded", say "Fable and $500 of credits"
Foobar8568 3 hours ago [-]
Opus 4.6 was already enough to tackle these projects vibe coding.
gwerbin 2 hours ago [-]
Incidentally I think I was more productive with Opus 4.6 than with any subsequent Anthropic model.
Lalabadie 3 hours ago [-]
"This one is made with premium vibes"
classified 4 hours ago [-]
How a patchwork of Python modules constitutes an API(?) or whatever(?) and how to use it (does anyone?), is beyond me. There is nothing that I would call documentation, let alone concrete usage examples. I know more amusing ways to waste my time. When I want to play with models, I use llama.cpp.
mrwaip 42 minutes ago [-]
What device do I need and how much will it cost to install one at home so that it works as quickly as the Claude Code answer (and it answers quite slowly)?
cpfohl 5 hours ago [-]
I’m still slightly confused on what this adds.
Let’s say I wanted to run a full size open weight model. I have a 128GB m3 max laptop.
Does this basically load layers in and out on demand? So I still have to download the full model to disk, but the RAM requirements go way down? The readme calls out that one still needs to connect HuggingFace, which leads me to believe that maybe you don’t even need to download the full model?
dofm 4 hours ago [-]
If you point it at a huggingface model identifier, it will download it, I assume. No way around that.
It reads like it is keeping only the core and the active layer loaded at any one point, and streams layers from disk; there are several other solutions like this and if my understanding is right, this is probably better than an mmap implementation or just streaming experts in.
pvtmert 4 hours ago [-]
Not an expert in this field, but the "expert" is consisting of multiple layers. To keep it small in terms of memory print, this project streams each layer (dividing even further).
It also requires extra space because of decomposition of the layers. Normally the file format optimized for compute intense workloads. But here the bottleneck is the memory capacity.
Also guessing that you need to be able to hold at least 3-layers at once in the memory, given M x N = R operation, M is the previous layer, N is next, and R is the result. on the next "layer", the R (result) becomes M, gets computed against the next layer, N, yielding the further result R'. And so on, until all layers are processed.
I assume it's horribly slow, but can be put in a non-intrusive background task...
cpfohl 4 hours ago [-]
Obviously needs downloading eventually :).
It seems like this tool saves on both disk space and RAM, then. Classic trade off: speed vs space.
jedbrooke 2 hours ago [-]
I mean, if you had fast enough internet connection, you could just stream it over https
ilaksh 4 hours ago [-]
I guess the use case is something like: you have a slightly obsolete Mac or PC or a whole bunch of them, and just need to compose one or more convincing spam emails, but it's fine if it takes a full week to do it?
speedgoose 4 hours ago [-]
And you don’t pay for the electricity.
book_mike 4 hours ago [-]
We will see if this project has legs. This is the kind of efficiency we desperately need. Now if we can address efficiency with llm training.
myshapeprotocol 3 hours ago [-]
Running 70B on a 4GB GPU is wild. Really impressive engineering feat for resource-constrained environments.
IIUC, Kimi K3 on RTX 6000 Ada (48GB) takes 292 s/token
https://github.com/lyogavin/airllm/releases/tag/v3.1.0
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).
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
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...
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.
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.
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.
Hoping a winner emerges with some real momentum behind it.
Let’s say I wanted to run a full size open weight model. I have a 128GB m3 max laptop.
Does this basically load layers in and out on demand? So I still have to download the full model to disk, but the RAM requirements go way down? The readme calls out that one still needs to connect HuggingFace, which leads me to believe that maybe you don’t even need to download the full model?
It reads like it is keeping only the core and the active layer loaded at any one point, and streams layers from disk; there are several other solutions like this and if my understanding is right, this is probably better than an mmap implementation or just streaming experts in.
It also requires extra space because of decomposition of the layers. Normally the file format optimized for compute intense workloads. But here the bottleneck is the memory capacity.
Also guessing that you need to be able to hold at least 3-layers at once in the memory, given M x N = R operation, M is the previous layer, N is next, and R is the result. on the next "layer", the R (result) becomes M, gets computed against the next layer, N, yielding the further result R'. And so on, until all layers are processed.
I assume it's horribly slow, but can be put in a non-intrusive background task...
It seems like this tool saves on both disk space and RAM, then. Classic trade off: speed vs space.