README could clearly make use of a cleanup, seems to be more like a session log dump now than a good introduction to the project for a new user. Maybe try something like "Remove anything from the README.md that wouldn't be helpful to someone who sees this project with zero context, for the first time. Rewrite all paragraphs and sections to be concise and remove all fluff, leave only important details new users must know before using the project".
I used similar prompts before. Now I simply say to "remove historical cruft" and results are good enough. It's the model itself that first used this wording, I found it concise.
I hate this AI style writing because since it doesn’t really understand flow, it’s being inserted in irrelevant places and it is extremely irritating to read.
For what it’s worth, this comment was not targeted at you, but rather the model kinda forcing it. I get the sense that Anthropic did not think much of this, but it seems to have gotten worse with recent models and it really comes off as a kind of nails on the chalkboard writing style.
I have to image whatever style of writing this was trained on is a lot more pleasant to read and I feel bad for whoever writes like this now being associated as bad AI writing.
most of this stuff isn't really possible at this point _without_ models, so pissing and moaning about people publishing work and not humanizing is really silly.
I have a 48GB M5. I don't need to run larger models. I want more context. I've managed to set the context window at 71,680 using Qwen3.8-27B-oQ4e-fp16-mtp. But I want more. Is anybody, with similar specs, able to set their context window higher?
I love these efforts to get proper models running on lower cost hardware and I think this is where the next real breakthrough will come from. The more efficient this sort of thing can be done the bigger the chance to democratize this tech, 'good enough' is what you need and as long 'top of the line' gives a competitive edge even if it is at a cost there is a substantial risk of the door closing on general computing at some point in the near future. Keep in mind that there is no guarantee that the pendulum has to swing back, it can swing one way and get stuck, and then you're going to have to beg for crumbs from the haves.
Yes, but also 12 tok/s versus Claude is so far from comparable. I know that it’s not exactly 1:1, but it’s a long way from an easy trade-off, especially considering hardware prices for high levels of RAM.
yes! I'm bullish on this. there is a lot of work to do. I've been experimenting with pruning, distillation, and retraining too. I'm sure your 32gb m6 will run a badass local model!
As someone who is just looking at the theoretical benchmarks of each of these models I'm curious if anyone could share what are the problems (maybe around code) that flash-next was able to solve which 27b was not able to
It's hard to believe 16GB unified memory will give you 5 tok/sec unless you are ignoring the thermal warnings. I am running Qwen3.6-35B-A3B on my 16GB M3 and get 7-8 tokens/sec with all the optimizations while keeping the peak memory and thermal warnings at check. https://github.com/deepanwadhwa/samosa-chat
Now I'm feeling pretty good about getting 10-11 tokens/sec running Qwopus 3.6-35B-A3B Q6_K on an old Mac Pro 2013 (trashcan) with 128GB RAM (DDR3), 12 core Xeon, dual D700s. Arch Linux and llama.cpp.
Reading causes insignificant wear ("read disturb") that likely isn't a problem, but I don't think it's possible to issue pure reads to modern SSDs. The NVMe spec mandates tracking the amount of data read, and this has to be written to the drive. I'd hope the firmware buffers this and writes it at low frequency, but on the other hand, I doubt the firmware was tested in extreme random-read regimes. Unexpected failures from excessive statistics recording could be possible.
There are already a handful of repos doing essentially exactly this: `mlx-moe-offload`, `streamlx`, `mlx-moe`, `mlx-flash`, and `deepseek-v4-flash-mlx` - i.e. keep the resident parts of an MoE in unified memory and page/stream routed experts from SSD on Apple Silicon.
At this point I'd much rather see people collaborate on one of these implementations, benchmark against them, or upstream the useful bits into MLX/MLX-LM instead of producing yet another near-identical repo.
The local-LLM ecosystem really does not need every implementation idea rediscovered five times and wrapped in a new README. AI-assisted coding makes producing a new repo cheap; maintaining, benchmarking, and integrating one is the actually valuable part.
I think multiple people working on the same thing is great.
Everyone comes at it from a different point of view, and some approaches work, some don't. And when people do this themselves they learn. Existing projects have their mistakes worked out already.
Maybe one of these people is going to come up with the thing that nobody else thought of because of their experience working the problem from scratch. You may not get that from someone working from an existing project, because existing projects have their approach "baked in."
What all these projects are showing so far is that it's possible to stream from disk, but that the performance isn't ideal. But I'm sure you could take this approach with smaller models and get better performance.
In addition, it's a given that when you work with large data sets performance means organizing the data to take advantage of caches, both disk and cpu. It's not clear how that would work, exactly, given that each run is a not-quite-random walk through the data. The Big Data way is to prebuild all of that as much as possible, which is probably impossible with a big model. But what about a smaller model?
This is one of the aspects of this year that I've been finding very grating and wasteful. Collaboration still happens among people with the ability to do so and the technical skills, but everyone else is taking their own helicopter to the top of the mountain, "putting it out there", and there's just a ton of redundant projects that do the same thing.
I see your point. As an oss defender myself, I agree, however, the spirit of this is to see how fast I can make it. I'm sharing this with the community, which I think is aligned with the original oss spirit.
It's an experiment for myself but I am committing to maintain it. I've been an oss person for a loooong time, way before AI was a thing. Think about it as a new, from-scratch take at it, not as a re-reproduction.
Hey carloslfu, kudos from the other side of the internet, don't get down on people nitpicking everything here, experimenting and discovering is part of learning so keep going!, remember this is the place that said dropbox was dumb and could be replaced by a script.
I'm only joking anyway — it's more a comment on the whole AI-accelerated trend of everyone having their own version of a thing.
I do agree that, ultimately, combining your efforts with others working in this whole area is probably really worth it, but I can see how there's an ease of pushing forward on your own these days.
I do not have fast internet so I am not sure when I'll really be able to download the weights but I do have an M1 Max to try this on, so I will at some point!
I see! yes, downloading the weights part is painful. I tried a couple fixes and it is as fast as it can get downloading from HuggingFace. I think the field is heading toward smaller, more capable models soon, so you won't have to wait that long!
I mostly use Muse Glimmer, which runs quite well on my M1 Max as it is 30B but it also reasons very efficiently. I have tried the Qwen 3.8 27B which is also usable if quite slow to reason, but I guess like everyone the idea of the Flash-Next model holds some intrigue, because the 35B-A3B is pretty good.
I'm sorry this makes it seem like I didn't do my research. I did a TON. To fix it I'll add a benchmark/comparison table. Also, I wouldn't call it market research since this is not commercial AT ALL.
> Hugging Face is the bottleneck, not your link.
README could clearly make use of a cleanup, seems to be more like a session log dump now than a good introduction to the project for a new user. Maybe try something like "Remove anything from the README.md that wouldn't be helpful to someone who sees this project with zero context, for the first time. Rewrite all paragraphs and sections to be concise and remove all fluff, leave only important details new users must know before using the project".
I used similar prompts before. Now I simply say to "remove historical cruft" and results are good enough. It's the model itself that first used this wording, I found it concise.
I hate this AI style writing because since it doesn’t really understand flow, it’s being inserted in irrelevant places and it is extremely irritating to read.
I feel you! fix incomming
For what it’s worth, this comment was not targeted at you, but rather the model kinda forcing it. I get the sense that Anthropic did not think much of this, but it seems to have gotten worse with recent models and it really comes off as a kind of nails on the chalkboard writing style.
I have to image whatever style of writing this was trained on is a lot more pleasant to read and I feel bad for whoever writes like this now being associated as bad AI writing.
most of this stuff isn't really possible at this point _without_ models, so pissing and moaning about people publishing work and not humanizing is really silly.
thanks! I'll do!
I have a 48GB M5. I don't need to run larger models. I want more context. I've managed to set the context window at 71,680 using Qwen3.8-27B-oQ4e-fp16-mtp. But I want more. Is anybody, with similar specs, able to set their context window higher?
I love these efforts to get proper models running on lower cost hardware and I think this is where the next real breakthrough will come from. The more efficient this sort of thing can be done the bigger the chance to democratize this tech, 'good enough' is what you need and as long 'top of the line' gives a competitive edge even if it is at a cost there is a substantial risk of the door closing on general computing at some point in the near future. Keep in mind that there is no guarantee that the pendulum has to swing back, it can swing one way and get stuck, and then you're going to have to beg for crumbs from the haves.
I'm hoping to see progress in this space.
Folks talking about how 32G is not enough for local use, but then there's been work like this to empower it.
My hope is that the new 32G M6 will be "useful" locally, possibly because of work like this.
Yes, but also 12 tok/s versus Claude is so far from comparable. I know that it’s not exactly 1:1, but it’s a long way from an easy trade-off, especially considering hardware prices for high levels of RAM.
yes! I'm bullish on this. there is a lot of work to do. I've been experimenting with pruning, distillation, and retraining too. I'm sure your 32gb m6 will run a badass local model!
As someone who is just looking at the theoretical benchmarks of each of these models I'm curious if anyone could share what are the problems (maybe around code) that flash-next was able to solve which 27b was not able to
For a local non-coding agent, instruction following and tool use are the most important gains
This is the best I could find: https://huggingface.co/Qwen/Qwen3.8-Flash-Next?utm_source=ch...
About the specifics, I have only anecdotal evidence, but I guess this info can be found somewhere
It's hard to believe 16GB unified memory will give you 5 tok/sec unless you are ignoring the thermal warnings. I am running Qwen3.6-35B-A3B on my 16GB M3 and get 7-8 tokens/sec with all the optimizations while keeping the peak memory and thermal warnings at check. https://github.com/deepanwadhwa/samosa-chat
Now I'm feeling pretty good about getting 10-11 tokens/sec running Qwopus 3.6-35B-A3B Q6_K on an old Mac Pro 2013 (trashcan) with 128GB RAM (DDR3), 12 core Xeon, dual D700s. Arch Linux and llama.cpp.
haha, good for you.
interesting! Yes, thermal is important. Pretty cool project man! Starred and checking it out!
Next help us normies run GLM 5.3 on our potato computers. Wouldn't that be nice!
how much energy does it consume?
Good one! I haven't measured this. I'll include it!
It seems we could use a new kind of memory that streams the weight data in, like GDDR in reverse.
High Bandwidth Flash? https://www.sandisk.com/company/newsroom/blogs/2025/scaling-...
interesting!
yes! I guess future hardware designs will have something like that!
"Disk is the gate that bites first"
AI;DR
Ha! AI;DR is a great phrase. Had not seen that before
The never ending gate bites.
How I have come to detest certain phrases.
Load bearing gate bites.
...the seam.
Interesting! You're absolutely right, I'll check
Is this going to destroy my SSD?
no it's reading, not writing
By reading it?
Reading causes insignificant wear ("read disturb") that likely isn't a problem, but I don't think it's possible to issue pure reads to modern SSDs. The NVMe spec mandates tracking the amount of data read, and this has to be written to the drive. I'd hope the firmware buffers this and writes it at low frequency, but on the other hand, I doubt the firmware was tested in extreme random-read regimes. Unexpected failures from excessive statistics recording could be possible.
I don't know actually. I'll check haha. My best guess is it isn't.
I hope not! this is a new macbook lol!
I swear the models are named by the beatbox aliens from the post office in MiB
There are already a handful of repos doing essentially exactly this: `mlx-moe-offload`, `streamlx`, `mlx-moe`, `mlx-flash`, and `deepseek-v4-flash-mlx` - i.e. keep the resident parts of an MoE in unified memory and page/stream routed experts from SSD on Apple Silicon.
At this point I'd much rather see people collaborate on one of these implementations, benchmark against them, or upstream the useful bits into MLX/MLX-LM instead of producing yet another near-identical repo.
The local-LLM ecosystem really does not need every implementation idea rediscovered five times and wrapped in a new README. AI-assisted coding makes producing a new repo cheap; maintaining, benchmarking, and integrating one is the actually valuable part.
I think multiple people working on the same thing is great.
Everyone comes at it from a different point of view, and some approaches work, some don't. And when people do this themselves they learn. Existing projects have their mistakes worked out already.
Maybe one of these people is going to come up with the thing that nobody else thought of because of their experience working the problem from scratch. You may not get that from someone working from an existing project, because existing projects have their approach "baked in."
What all these projects are showing so far is that it's possible to stream from disk, but that the performance isn't ideal. But I'm sure you could take this approach with smaller models and get better performance.
In addition, it's a given that when you work with large data sets performance means organizing the data to take advantage of caches, both disk and cpu. It's not clear how that would work, exactly, given that each run is a not-quite-random walk through the data. The Big Data way is to prebuild all of that as much as possible, which is probably impossible with a big model. But what about a smaller model?
This is one of the aspects of this year that I've been finding very grating and wasteful. Collaboration still happens among people with the ability to do so and the technical skills, but everyone else is taking their own helicopter to the top of the mountain, "putting it out there", and there's just a ton of redundant projects that do the same thing.
It's horrible. Every 20-something working on a load-bearing inference engine on GitHub.
I see your point. As an oss defender myself, I agree, however, the spirit of this is to see how fast I can make it. I'm sharing this with the community, which I think is aligned with the original oss spirit.
It's an experiment for myself but I am committing to maintain it. I've been an oss person for a loooong time, way before AI was a thing. Think about it as a new, from-scratch take at it, not as a re-reproduction.
Hey carloslfu, kudos from the other side of the internet, don't get down on people nitpicking everything here, experimenting and discovering is part of learning so keep going!, remember this is the place that said dropbox was dumb and could be replaced by a script.
Vouched especially since OP might have a perspective on this. And readers may want to look up those other repos and compare for themselves.
Thanks for the feedback! I'll create a section with a benchmark and comparisons. This will hold the project accountable and speed things up imo
Why should they do that? For you? You could merge those projects and see if they get traction.
And there are `Mference` and `SwiftLM` too, I think they are doing the same use case.
AI NIH
Sorry, I don't get "NIH". what's that?
Not Invented Here.
Ah! Yeah, I didn't invent anything (yet!). The goal is to see how far I can take it in terms of speed without consuming that much RAM.
I'm only joking anyway — it's more a comment on the whole AI-accelerated trend of everyone having their own version of a thing.
I do agree that, ultimately, combining your efforts with others working in this whole area is probably really worth it, but I can see how there's an ease of pushing forward on your own these days.
I do not have fast internet so I am not sure when I'll really be able to download the weights but I do have an M1 Max to try this on, so I will at some point!
I see! yes, downloading the weights part is painful. I tried a couple fixes and it is as fast as it can get downloading from HuggingFace. I think the field is heading toward smaller, more capable models soon, so you won't have to wait that long!
I mostly use Muse Glimmer, which runs quite well on my M1 Max as it is 30B but it also reasons very efficiently. I have tried the Qwen 3.8 27B which is also usable if quite slow to reason, but I guess like everyone the idea of the Flash-Next model holds some intrigue, because the 35B-A3B is pretty good.
> every implementation idea rediscovered five times and wrapped in a new README
That's open source since forever, unfortunately.
I agree with the sentiment, but have you seen those videos in which all men say other men are gay? This feels like the same, so much AI paranoia!
I genuinely want to contribute. And hey! I was doing oss this since 2014 so waay before AI was cool.
It's what happens when you don't do market research.
I'm sorry this makes it seem like I didn't do my research. I did a TON. To fix it I'll add a benchmark/comparison table. Also, I wouldn't call it market research since this is not commercial AT ALL.
Hey Carlos, thanks for sharing with the community! Appreciated
thanks!
Does a painter check to make sure that a portrait hasn't been painted? What a dismissive comment.
Half the people on here are using Ollama. No one is doing market research.