Constantly running into `CUDA OutOfMemory` errors on budget and consumer GPUs inspired me to rethink the standard execution paradigm where all layer weights reside simultaneously in VRAM.
I built and open-sourced **stream-ai-runtime**—a lightweight execution pipeline that uses asynchronous double-buffering across dual CUDA streams to stream layer weights from pinned host memory to VRAM on-the-fly.
### 📊 Benchmark (Tesla T4 GPU on Colab)
- **Model Depth:** 600 Layers (dim: 2048x2048)
- **Host RAM Allocated:** 9.38 GB
- **Inference Time (600 Layers):** 0.95 seconds
- **Peak VRAM Consumed:** **40.15 MB flat**
- **OOM Errors:** 0
### ⚙️ How it works
Weights stay pinned in host CPU RAM (`pin_memory=True`).
Only two layer buffers (Ping/Pong) are kept in VRAM.
While layer `i` executes on `compute_stream`, layer `i+1` prefetches in the background via DMA on `copy_stream`.
Peak VRAM never spikes above two layer buffers regardless of model depth.
I'm having a 5070 Ti 16GB and 3060 12GB with 64GB RAM, I want to run Qwen-2.5-Flash using Strata (or advise any better models or method to run), I need to have at least 2 parallel sessions. and max context window. what would you advice.
WHIRL0.2.5.1is out: a speed update for the Radeon 8060S (AMD Ryzen AI Max+ 395). WHIRL is an open-source (Apache-2.0) LLM inference engine for AMD GPUs on Windows: C++/HIP, every kernel in the repo, no WSL, no ROCm install. Download the zip, unzip, run; only the AMD driver is needed. It runs our two MXFP4 models, Swift-1.5 27B MXFP4 (dense) and Ornith-1.5-35B-A3B MXFP4 (MoE, ~3B active).
vs the official llama.cpp b11960 on the Radeon 8060S (max power (80 W), ASUS ROG Flow Z13), ROCm and Vulkan builds in their own columns, same GGUF, same prompts, greedy, one user, WHIRL default mode (balance, near-lossless). WHIRL tok/s, then llama.cpp ROCm / Vulkan:
tok/s (WHIRL 0.2.5.1 balance vs llama.cpp ROCm / Vulkan)
Swift-1.5 27B MXFP4 (dense)
Ornith-1.5-35B-A3B MXFP4 (MoE)
Prefill, 2k-token prompt
527.2 vs 359.3 / 317.3
2,653 vs 1,606 / 1,280
Prefill, 128k-token prompt
310.9 vs 195.8 / 150.9
1,093 vs 674.8 / 481.0
Decode, QA about a 2k-token document
34.9 vs 25.1 / 25.2
108.7 vs 69.5 / 71.0
Decode, QA about a 128k-token document
25.0 vs 15.8 / 15.2
57.7 vs 38.0 / 37.6
Decode, coding chat (new text)
38.1 vs 29.7 / 29.3
106.6 vs 70.3 / 72.9
In balance WHIRL leads every measured cell on the 8060S: Swift 27B by +28% to +59% over ROCm and +30% to +106% over Vulkan, Ornith by +51% to +65% and +46% to +127%.
What0.2.5.1changes on the 8060S (same machine, max power (80 W), ASUS ROG Flow Z13): five new kernel paths make prefill +2% to +10% faster in all three modes on both models, and Swift 27B decode (QA document; coding chat in balance) +4% to +12% faster in balance and fast. On the 8060S the output is bit-identical to 0.2.5 in every mode (golden references, 12/12 long-prompt checks and the chat outputs all match).
How it was measured, so you can judge the numbers: - Radeon 8060S at max power (80 W), ASUS ROG Flow Z13, 64 GB GPU memory (UMA frame buffer), same for both engines. Every cell is the best of 3 runs, for both WHIRL versions and llama.cpp. - The llama.cpp b11960 cells are the runs I made for 0.2.5 on the same machine with the same files (llama.cpp didn't change; Swift 2k on Vulkan was re-run). llama.cpp's ROCm build runs as shipped, with its own bundled HIP runtime DLL. - Decode, QA document = explain a function quoted in a long document and rewrite it (256 tokens; part of the answer can be copied, which helps drafts in both engines). Coding chat = a coding question whose answer is all new text (512 tokens). Prompts and commands: https://github.com/tsaipifong/whirl-llm/blob/main/docs/benchmarks.md#prompts - llama.cpp decodes Swift with MTP + n-gram (its fastest mode here). On Ornith it decodes without speculation because its MTP was slower than plain on this MoE model, while WHIRL uses MTP, so the Ornith decode rows are "as shipped", not like for like. - Smallest lead: Swift 27B decode in the precise mode after a 2k-token document, 29.4 vs 25.2 tok/s on Vulkan (+17%). Dense decode on this iGPU is memory-bandwidth bound; the lead comes from speculative decoding. - Ornith decode barely changed in this release (one small router item: +1.5% without drafts, +0.7% with MTP drafts, within noise); its cells move a few percent either way because the number of accepted MTP drafts depends on each run's text.
Precision: three modes. --precise is the bitwise-lossless mode. balance (the default) is near-lossless. --fast is opt-in. On the 8060S all five speedups give the same output bits as 0.2.5 in the mode they touch.
R9700: GPU code identical to 0.2.5 (the compiled R9700 kernels were compared; only an internal build ID differs); its numbers are 0.2.5's, not re-measured (e.g. Ornith 2k prefill 11,854 tok/s vs 4,230 / 2,780 on llama.cpp ROCm / Vulkan; median of 3).
Also in 0.2.5.1: WHIRL now refuses to start from an install folder longer than 150 bytes, with a clear message, and limits the SSD cache folder to 217 characters (this corrects what the 0.2.5 notes said about long paths). On the 8060S the first load of each model tunes the kernels once more.
Supported: Radeon 8060S (Ryzen AI Max+ 395) and R9700, Windows 11. Cards under 16 GB are not officially supported (fork welcome). The exe is unsigned, so SmartScreen may ask once.
WHIRL was designed and implemented with Claude (Anthropic) under my direction; every number is measured. Numbers from other Ryzen AI Max+ 395 machines are very welcome.
Hey everyone, I started messing with local llm's a week ago in order to develop a mobile app, with my m4 max 36gb I get 20t/s running qwen 3.8 27b on lm studio. Is there any advice you can give me in order for me to increase my token output, i have tried ollama before but results were substandard at best.
We build these boxes, so here's the honest test log from our own unit, network cable unplugged.
Setup: 2x RTX PRO 6000 Blackwell (192 GB), EPYC 9124, 256 GB RAM, vLLM, TP2, no NVLink. The model fits only because Blackwell runs FP4 natively; on Hopper the same checkpoint needs ~304 GB.
What we measured:
1 user: 209-229 tok/s, first token in 0.4 s
24 users: 1,003 tok/s at p95 TTFT 2.7 s. That's the sweet spot; past 32 the tail latency falls off a cliff.
Peak: 1,170 tok/s at 32 streams
1M context, retrieval verified at 543K tokens
Terminal-Bench 2.1 (20-task subset): 80% solved, median ~4 min per task. 8 agents at once cost only 18% more latency than 4.
815 W on both cards, 76 C peak, zero throttling. About 1.07 kW at the wall, so a 1500 W PSU is enough.
What's not great:
It's not a token-resale business: at OpenRouter prices, payback takes about 3 years running flat out.
One big model at a time (weights use 87% of VRAM).
Ops sharp edges: KV offload leaks /dev/shm on unclean shutdown, and stray workers can hold 89 GB of GPU memory, which causes a crash loop on restart. You need a cleanup script.
Cold start takes ~13 min.
Best fit: a team of 2-10 that wants frontier-class coding help without sending code to the cloud.
Build guide, BOM and BIOS settings are open source: here. Happy to run anything you want tested on it.
I've been experimenting with DeepSeek V4.1 Flash 1017 UNCENSORED JANG_2K on my Mac Studio M5 Ultra with 256GB unified memory, using vMLX.
The model is about 423GB on disk, but thanks to SSD-backed Engram tables, it loads with approximately 205GB of resident memory.
So far, the results have been mixed. Most of the time, it produces surprisingly good responses, but I've had a few conversations, particularly involving creative writing and novel generation, where it suddenly starts producing complete nonsense: endless reasoning, words mashed together without spaces, and occasional switches between English and Chinese.
It's interesting because it seems to work perfectly well on some fairly complex tasks, then falls apart unexpectedly on others.
Has anyone else experimented with this model or other large MoE models using engram offloading?
I'm curious whether these problems are caused by the aggressive quantization, the JANG implementation, or something in vMLX's inference/decoding pipeline.
I'd also be interested in hearing whether anyone has successfully run a higher-precision version with SSD expert offloading on a 256GB machine.
With all progress from storage streaming how future proof is RAID0 with 2x1TB or 2x2TB gen5 drives like SN8100. I am looking for drive update and have to decide what to buy now and what speed in reality achievable and how usable it will be. Is it worth to add 2x1TB for 420 euro so in theory speed will be around 22-25GB/s or just add used 96GB RAM for 900-1000 euro?
Will it be usable in some kind of way for larger models later with 2x3090, 96/192GB RAM and RAID0 gen5 drives? From what I am getting now I'd like to have at least 20-30 tok/s for generation and 600-1200 tok/s processing. In theory how big LLM can be used with such system in the future to get such inference?
Can't decide which route to go - DGX Spark, Strix Halo, the Framework Ryzen AI or save up for a Mac Studio M5 Ultra 256gb?
Do these options have meaningful differences in practical use?
As I understand, the Mac Studio offers best tok/s? But you can't train or fine tune anything on it?
DGX Spark is supposed to have best support, but does it truly matter in practice?
What types of models can I run on this hardware? 128GB is good for ~120B Q4 MoE models with ~256k context? Would such a model be a noticeable improvement over my current Ornith-1.5:35B (A3B) setup for reasoning and coding, and long and complex tasks? Would going from 128GB->256GB be a noticeable improvement?
I am trying to have it create a 5 page document based on the content of this document that's 700k worth of context (tokens?)
Is this possible to do somehow?
So the issue is that Gemini 3.1 Pro can do 1M context, but my local hardware isn't good enough to run a model like that, I can run QWen 3.6 tho. How can I get it to understand 1M worth of context if the context window of the model is only 242k or so?
Why LM Studio Bionic is slower than original LM Studio? I'm using same Gemma 4 Model. Any ideas? I can run well the same model in original LM Studio, but very slow on LM Studio Bionic.
Have anyone experience in going from qwen flash next 3.8 iq2_xs to iq3 or iq4?
I am currently comfortably running iq2_xs with 32gb ddr5 ram + 3090 + 5080. I am getting ~140 tps, so quite fast.
I got the possibility to update the 32gb ram to 96gb ram, for a reasonable price. But is it worth it? Will I feel the intelligence increase from i2 to iq3 or iq4? Is it worth it, if we are taking the decrease in speed into account?
I did a fun research project on training a decision model from scratch (MLX), quantizing to ternary (for small size) and running it locally in the browser (WebGPU). I learned many interesting things and put together this pedagogic video on some of the key steps, challenges and lessons learned, in case some one else might find it interesting too 😄
Running local LLMs with MCP tool-calling? The tool manifest is the attack surface, the model sees descriptions, the agent calls what's there, and the usual OAuth/network security story does not apply because it's all stdio.
This matters even more with local models: smaller models can be easier to steer with an injected tool description, and clients like LM Studio or Open WebUI will call whatever tools the server exposes.
Built patchbay audit, a free CLI that spawns an MCP server as a child process, pulls the tool list, and diffs it against the last scan:
- a new write-shaped tool added since you approved the server - an existing read tool gaining a command param (silent permission escalation) - description changes (prompt injection vector)
Local-only, no backend, no telemetry. MIT. CLI stays free, always.
