> Using a GPU has, once, caused a driver reset that took the desktop with it.
Only once? This has happened to me so many times with LLM-assisted development. I was writing an OCR engine and pathological shapes would cause OOM that would take the display out. On other occasions, the LLM would try to load 24GB of bf16 weights onto a 16GB GPU without understanding the consequences.
Have to encode this in logic: keep some space reserved for the display, and check before allocation. But some errors are bound to slip through.
---
Inspired by DwarfStar4 and Strata, I am trying to build my own gemma4-specific inference engine designed to run on gfx1201.
It is a lot of work. You cannot simply vibecode one in two days.
It will be when done. I have a lot of stuff in the works and switch between them based upon my current interest. I like plotting and writing stories and Gemma is one of the nicer writers.
The goal is to get the 31B working on a 16GB card. Which means weights have to be < 4 bits. The 9070 XT has wmma support for int4. Which doubles compute performance on pp compared to i8/fp8. tg is limited by bandwidth.
I have one of my own. My reason for this is that you can get up to 2x performance compared to llama.cpp on the same model weights. It is optimized for single model to serve it well.
I think fits in a RAM is the first step, a real practical question is if in the mean time you can still use the machine for basic tasks like use browser watch YouTube/VS Code etc.
The numbers you povided are for output/generation. Input is around 5-20 thousand for Astra, and 16-60k for Luna. So a few hundred times faster.
Most of the tokens consumed by agents is reading stuff - docs, tool outputs, code etc. Previewing a content of a dumb single page of html is a few thousand tokens.
If you use claude or some other harness you can ask it how many cache writes/input tokens are there in avg session, and how much time it would take if preprocessing speed was just 60 tok/s.
I would guess the assumption is that "agentic work" should be happening asynchronously in the background on a machine that's also used for foreground interactive work, where the slower the inference is, the longer the machine's GPU and [V]RAM are "hogged" by it at a time, and so the more the machine's performance seems to degrade.
I have a couple of V100 and am working on making Flash Next really fast on them. So far I am at like 193 t/s decode on a specialist 3-bit quant. On shorter prompts. Around 109 t/s on a ggml/llama fork at depth before I gave up and started writing the engine from scratch. I guess I will end at about 220-250 t/s at 128k context size with about 3K prefill on these cards.
https://stealthgoat.com/deepswe-flash-next.html (Total AI pile). I benched this quant for 3 days on DeepSWE in a 16GB VRAM gaming PC. It held 90 t/s on avg I think. It’s solid. The authors claims of minimal intelligence loss hold. Sorry it renders bad in mobile will fix it soon.
It feels great to have a local model ripping at these speeds. I now use Flash NeXT as an active agent managing part of the engine build process and let it do some coding on easier chores :)
Not sure if the measurement method used for this is actually valid or reliable enough, but for reference, Codex 6.1 Sol Standard runs at 19.9 tok/s according to a benchmark I recently saw: https://www.reddit.com/r/codex/s/b4mUszSOv1
This could be a game changer for me. The best I've been able to do so far is ~8 tok/s with Qwen 35B A3B, 32GB RAM. But then again I just got an OpenCode Go plan yesterday and have yet to figure if I can even consume my quota on DeepSeek Flash as the need to plan things well is bottlenecking me. Might be a while before I try the local thing again.
Based on how vibe-coded this whole thing is, I’m guessing the newer models weren’t in the training data and the agent just picked what it knew existed.
I wonder when we will start seeing small commercial accelerators integrated with NVMes; could potentially use far more bandwidth than typical NVMe drive can push thru the four lanes.
Given that you'd have probably a lot more capacity just to get to required bandwidth it could be used to switch very quickly between models (as all stored there would essentially be "loaded")
Seems like a useful innovation on the desktop level, but on the server level, isn't it already pretty normal to see machines with 24x high-performance (i.e. individually high-bandwidth) NVMe drives in them, that can then be used in software RAID0 to achieve pretty massive read bandwidth?
There are many of these stream-experts-from-SDDD projects now. What's needed is a guide to all of them and maybe for someone to take the best features of each of them and merge them into one uber project.
My impression based on a cursory look at the research is that the caching algorithm is absolutely vital, non-obvious, model-dependent, and potentially prompt-dependent to make sure you're holding onto the right experts.
> Using a GPU has, once, caused a driver reset that took the desktop with it.
Only once? This has happened to me so many times with LLM-assisted development. I was writing an OCR engine and pathological shapes would cause OOM that would take the display out. On other occasions, the LLM would try to load 24GB of bf16 weights onto a 16GB GPU without understanding the consequences.
Have to encode this in logic: keep some space reserved for the display, and check before allocation. But some errors are bound to slip through.
---
Inspired by DwarfStar4 and Strata, I am trying to build my own gemma4-specific inference engine designed to run on gfx1201.
It is a lot of work. You cannot simply vibecode one in two days.
Is the inference engine open-source?
It will be when done. I have a lot of stuff in the works and switch between them based upon my current interest. I like plotting and writing stories and Gemma is one of the nicer writers.
The goal is to get the 31B working on a 16GB card. Which means weights have to be < 4 bits. The 9070 XT has wmma support for int4. Which doubles compute performance on pp compared to i8/fp8. tg is limited by bandwidth.
Every few weeks, someone stumbles on what llama.cpp has had for years again, and reimplements it. I'm not sure why.
I have one of my own. My reason for this is that you can get up to 2x performance compared to llama.cpp on the same model weights. It is optimized for single model to serve it well.
Because with AI everybody can reinvent the wheel with ease
Qwen 3? (Jumanji) What year is it?
What a waste of time.
Strata already does this with Qwen3.8-Flash-Next: https://github.com/Niko1221/Strata
If it uses different methodology I'd be happy to see it on HN, even if it doesn't include the flavor of the month model.
It lists a bunch of models it supports, including Qwen3.8-Flash
I see zero mention of qwen3.8-flash. only two hits talking about qwen3.8-27b: https://github.com/search?q=repo%3Aprabanta-dev%2Fjanas+qwen...
Are we hallucinating now too, not just the bots?
<50GB/s bit stream? What a waste of time. Buy more DRAM.
I think fits in a RAM is the first step, a real practical question is if in the mean time you can still use the machine for basic tasks like use browser watch YouTube/VS Code etc.
I'm always excited to see more open source apps like this.
If anyone needs to see what 62 tokens/second looks like: https://token.qusai.pro/?speed=62
Which seems sufficient for mortals who are not running gas town, but want a local model.
60 toks/sec may be ok for pure chat or token generation, but not for token preprocessing nor any sort of agentic work.
>.. nor any sort of agentic work.
may I ask why?
oai luna runs at 60-70 toks/s; astra runs around 35-45 , are you just worried that your agentic work can't spread across a lot of parallel work?
The numbers you povided are for output/generation. Input is around 5-20 thousand for Astra, and 16-60k for Luna. So a few hundred times faster.
Most of the tokens consumed by agents is reading stuff - docs, tool outputs, code etc. Previewing a content of a dumb single page of html is a few thousand tokens.
If you use claude or some other harness you can ask it how many cache writes/input tokens are there in avg session, and how much time it would take if preprocessing speed was just 60 tok/s.
I would guess the assumption is that "agentic work" should be happening asynchronously in the background on a machine that's also used for foreground interactive work, where the slower the inference is, the longer the machine's GPU and [V]RAM are "hogged" by it at a time, and so the more the machine's performance seems to degrade.
My self hosted LLM runs at 60-ish tok/s and does great at agentic tasks. I think that’s about the threshold where it stops feeling annoyingly slow.
60tok/s prefill or tok gen? If you use gpu and keep it in vram then I you most likely mean token generation, nit prefill.
I have a couple of V100 and am working on making Flash Next really fast on them. So far I am at like 193 t/s decode on a specialist 3-bit quant. On shorter prompts. Around 109 t/s on a ggml/llama fork at depth before I gave up and started writing the engine from scratch. I guess I will end at about 220-250 t/s at 128k context size with about 3K prefill on these cards.
https://stealthgoat.com/deepswe-flash-next.html (Total AI pile). I benched this quant for 3 days on DeepSWE in a 16GB VRAM gaming PC. It held 90 t/s on avg I think. It’s solid. The authors claims of minimal intelligence loss hold. Sorry it renders bad in mobile will fix it soon.
It feels great to have a local model ripping at these speeds. I now use Flash NeXT as an active agent managing part of the engine build process and let it do some coding on easier chores :)
Not sure if the measurement method used for this is actually valid or reliable enough, but for reference, Codex 6.1 Sol Standard runs at 19.9 tok/s according to a benchmark I recently saw: https://www.reddit.com/r/codex/s/b4mUszSOv1
Good luck when you need to prefill context..
This could be a game changer for me. The best I've been able to do so far is ~8 tok/s with Qwen 35B A3B, 32GB RAM. But then again I just got an OpenCode Go plan yesterday and have yet to figure if I can even consume my quota on DeepSeek Flash as the need to plan things well is bottlenecking me. Might be a while before I try the local thing again.
Then check out those:
https://github.com/prabanta-dev/janas <- this, focuses on Qwen3-Next-80B-A3B.
https://github.com/Niko1221/Strata <- Qwen3.8-Flash-Next. I use this (tuned) and I cannot understate how satisfied I am.
https://github.com/antirez/ds4 <- DeepSeek 4 family + more.
Zoomers discover swap?
Why are the models being used so old (in llm years anyway). Why no Qwen 3.8 ?
Based on how vibe-coded this whole thing is, I’m guessing the newer models weren’t in the training data and the agent just picked what it knew existed.
Qwen 3.6 & 3.8 have the exact same model architecture. In theory, it should just be a drop-in replacement.
https://hfviewer.com/compare/qwen3.6-27b-vs-qwen3.8-27b
I wonder when we will start seeing small commercial accelerators integrated with NVMes; could potentially use far more bandwidth than typical NVMe drive can push thru the four lanes.
Given that you'd have probably a lot more capacity just to get to required bandwidth it could be used to switch very quickly between models (as all stored there would essentially be "loaded")
AMD Radeon Pro SSG, launched ten years ago at SIGGRAPH: https://www.tomshardware.com/news/amd-radeon-ssg-1tb-gpu-mem...
When High Bandwidth Flash comes out, most likely: https://chipsandcheese.com/p/hot-chips-2026-applying-high-ba...
Seems like a useful innovation on the desktop level, but on the server level, isn't it already pretty normal to see machines with 24x high-performance (i.e. individually high-bandwidth) NVMe drives in them, that can then be used in software RAID0 to achieve pretty massive read bandwidth?
I think what we're going to see first is essentially gpus with nvme (or at least flash) bolted on, not sure if that's also what you're saying or not.
There are many of these stream-experts-from-SDDD projects now. What's needed is a guide to all of them and maybe for someone to take the best features of each of them and merge them into one uber project.
My impression based on a cursory look at the research is that the caching algorithm is absolutely vital, non-obvious, model-dependent, and potentially prompt-dependent to make sure you're holding onto the right experts.
It doesn't look like a solved problem yet.
would this work on a virtual disk, say w s3 or dropbox
You could prompt it before going to bed yes
Sure, it’ll just be absurdly slow.
Maybe next you can run an LLM off of some old MFM drives
Not online services. The overhead of TCP and latency I imagine would really lag performance. A SAN over SFP, maybe.
[flagged]
[flagged]
[dead]
I think GitHub repos should have a new tag listing the model used to write it along with the token cost.
I don’t want to bother reading anything sub-Fable, and this one looks sub-Fable.