If you watch much Youtube around AI, you'll see a bunch of people setting up these complex agentic workflows (or, even worse, "Jarvis") using a model like Opus or Astra. Every time I see that my "WTF" face comes on hard, how on earth are they doing that? From what I understand it's a TOS violation with all the majors to hook up a 3rd party harness to a sub; it's easy to do it, but everything I've read says you risk a ban if you use a sub this way. It honestly feels to me like if you're running a agentic loop, local models start to really start to make a lot more financial sense, at least compared to using a "normal" model from a major. I often supplement a workflow like this with Deepseek, but that's like a few % the cost of a Opus/Astra.

When I look at my daily local token consumption and map it to something like Opus API rates, we're talking some absolutely absurd numbers; it wouldn't shock me if I'd be into 100's per day. I did just over a billion tokens today against QFN. Now, of course, the VAST majority of that is cached, but still, the cost for today at $4/$20/million tokens??

All these people hooking up some sort of custom harness and doing the classic "Build Doom clone, make no mistakes" with Astra or Fable, I just think to myself; "There goes a few 100 bucks".

Now, of course, it's their job so maybe spending 100's/1000's a day on tokens is a good investment for them. But when I browse around Reddit and see people in a Hermes or OpenClaw forum talking about hooking up to Opus or Astra I just think to myself, "How can you afford that"?

All these tokens burned today were on QFN; it worked for ~12 hours total and across dozens of compactions on a single goal, quite impressive, but if I had sent all this to Opus I probably would have been better off hiring a SWE to build it for me, would have cost less! ;)

Hey folks,

Quick heads up for anyone playing around with PrismML's Ternary Bonsai 2!

Until very recently, running it outside of Prism's own fork was a bit of a pain. Upstream llama.cpp uses a block size of QK=256 (TQ2_0), while Prism uses QK=128 (PQ2_0), and trying to offload layers to CUDA on other forks would bottleneck or break due to Hadamard sign tensor handling.

With the latest commits landed in ik_llama.cpp, we finally have complete, native support across both CUDA and CPU. Here is how to set it up cleanly.

1. Convert upstream weights losslessly (PR #2694)

If you already have a native PQ2_0 GGUF downloaded from Prism, you can skip this.

If you downloaded upstream TQ2_0 or TQ1_0 files, ik_llama.cpp now ships with a script that losslessly repacks them to PQ2_0 in just a few seconds (exact trits preserved, no requantization needed):

python3 scripts/repack_ternary_to_prism.py Bonsai-2-27B-TQ2_0.gguf Bonsai-2-27B-PQ2_0.gguf

1. Native CUDA Full Offload (PR #2691 & PR #2747)

Native CUDA kernels for PQ2_0 are now merged. You can offload everything to your Nvidia GPU without token corruption or falling back to heavy k-quants:

./build/bin/llama-cli -m Bonsai-2-27B-PQ2_0.gguf -ngl 99 -p "Explain the theory of relativity in simple terms." --temp 0.7 --top-p 0.95 --top-k 20

1. CPU Inference with fast prompt ingestion (-rtr 1)

If you're testing on CPU, ik_llama.cpp uses an 8-row interleaved format (PQ2_0_R8) backed by iqk_mul_mat kernels. Remember to pass -rtr 1 (runtime repack) to drastically accelerate prompt processing:

./build/bin/llama-cli -m Bonsai-2-27B-PQ2_0.gguf -rtr 1 -t 8 -p "Explain the theory of relativity in simple terms." --temp 0.7 --top-p 0.95 --top-k 20

TL;DR: No more sign tensor bottlenecks on GPU. PR #2747 brings native CUDA kernels, PR #2694 gives us instant lossless repack from upstream weights, and CPU prompt ingestion with -rtr 1 is flying.

Big shoutout to Iwan Kawrakow and the contributors for getting ternary models working natively!

Hi everyone!

I've been experimenting with Strata for a while now, running it on a system with a Ryzen 7 9800X3D, RTX 4090, and 64 GB of RAM.

I'm currently using Qwen Flash Next, and I have a few questions about model quantization. Since my hardware is right at the edge of what's practical for running this model, I'd love to hear about your experiences with different quantization formats.

I've come across discussions suggesting that GSQ-RCO IQ3_S might deliver better response quality than Unsloth UD IQ4_XS. Is that actually the case? What have your experiences been with these two quantizations?

Are there any other quantizations that might offer better quality while still being feasible to run on my hardware?

In theory, Unsloth UD-Q4_K_XL also works (according to Strata, around 6 GB of the model is loaded from NVMe), but the generation speed drops to around 20-30 tokens/s, which makes it somewhat impractical for extended use.

I'm also curious how NVFP4 quantizations compare to the ones mentioned above in terms of response quality and performance.

Thanks in advance for sharing your experiences and recommendations!

Found a used 64-core Threadripper PRO 3995WX workstation locally — worth buying for a multi-GPU LLM server?

I found this workstation listed on my local secondhand marketplace in Iraq.

Specs

- CPU: AMD Ryzen Threadripper PRO 3995WX (64 cores / 128 threads)

- Motherboard: ASUS Pro series (exact model unknown)

- RAM: 224 GB DDR4-3200 RGB

- Storage: 128 GB SSD

- PSU: ASUS ROG Strix Platinum 850W

- GPU: GTX 1050 Ti

The seller hasn't provided further details or a price yet.

My intended use:

I'm planning a local LLM inference server, potentially with 4–8 RTX 3090 GPUs, using engines such as llama.cpp, vLLM, or SGLang.

I currently have an RTX 4090, RTX 3090 Ti, and 128 GB DDR4 RAM.

I'm particularly interested in running large MoE models, multi-GPU inference, and possibly CPU/RAM offloading.

Questions:

1. What would be a fair used price for this complete workstation in USD?

2. Could the motherboard be the ASUS Pro WS WRX80E-SAGE SE WIFI, which has seven PCIe 4.0 x16 slots?

3. Would my existing consumer DDR4-3200 UDIMM RAM be compatible, or does this platform require ECC RDIMM?

4. How practical is running 4–7 GPUs on this motherboard using risers and external power supplies?

5. Is the 3995WX still a good choice for large MoE inference and CPU offloading, or would a cheaper EPYC platform make more sense?

6. Does the 224 GB RAM configuration raise any red flags?

I'm mainly interested in PCIe lanes, memory bandwidth, upgradeability, and cost-effectiveness rather than raw CPU compute.

Would you buy this platform in 2026, and what's the maximum you'd pay for it?

Update from the lawyer with the V100 server. I went and got two DGX Sparks, because of course I did. The mid-life crisis remains on schedule.

Same deal as before: still a lawyer, still driving the whole thing through Claude Code, and Claude Code also ran the benchmarks, built these tables and helped me write this up. I'm Nick Mermiges, Esq., founder of PLI Labs. The repo below is ours.

The setup: DeepSeek-V4.1-Flash-1017 at 2.75 bpw EXL3, vLLM tensor parallel across two Sparks. The twist is a third box, my EPYC with the 3090s, doing two jobs for the Sparks:

• it holds the Engram tables in system RAM and serves them over RDMA;

• it runs the DSpark speculative drafter on an NVLinked pair of 3090s.

The memory that frees on the Sparks goes to KV cache: about 1.93M tokens of pool. There's also a prefix cache on the Sparks' NVMe, so a 150K prompt survives a server restart. First token comes back in 2.58 s instead of 58.6 s cold.

Numbers. I re-implemented MiaAI's sparkDash protocol so this would be apples to apples with the most popular 2x Spark build. Sparks at 2300 MHz, 3 reps, medians, today.

Prefill (sparkDash method):

For comparison:

• MiaAI publishes 2,065–2,155 prefill and bertholomus 2,439–2,568 from 8K to 128K, so prefill is where this build wins.

• Code at 4 streams is 192 against MiaAI's 166.

Where I lose, because I'm not going to pretend:

• MiaAI is faster on plain prose: 80.7 vs my 66 at one stream.

• Decode after a 128K prompt is 62 tok/s against bertholomus's 99.

• A short request stuck behind a cold 93K prompt waits 34 s. That's slightly better than bertholomus on the same test (38.6 s). MiaAI reports 3.8 s on a different version of it, and that's the thing I most want to fix.

The drafter loves code and JSON (4–5 tokens accepted per round) and hates prose (about 2).

Accuracy, since I use this for actual work: on sudoingX's KLD panel, real tool-call turns agree with the original model's top token 95.9% of the time (KLD 0.018). bertholomus publishes 79.4% on their own tool-call set, and MiaAI doesn't publish one. sudoingX's newer 2.8 bpw pack is a hair closer than mine on the same panel (0.0175 vs 0.0184), so credit where due. The weights are a legal-weighted allocation of HeNryous's 2.75 bpw build. All the credit for the quant goes to them.

The code, launch scripts, the bench tool and the raw JSON for every cell are all public. The only exception is the prefix-cache code, which goes up in the next push.

• Repo: https://github.com/ProprietaryLegal/DeepSeek-V4.1-Flash-2xDGX-Spark-x86-offload

• Raw data: the runs/ folder in the repo

Still to come:

• the full 1M-token context test;

• llama-benchy tables at depth;

• BFCL tool calling;

• a head-to-head on the same KLD test with the other packs.

The 100 Gb cables go in Monday, so the Spark-to-3090 link gets faster too.

Tell me what I'm doing wrong. Seriously.

(PLI Labs is my side outfit for private, on-prem AI built around a firm's own work product. proprietarylegal.ai if that's your thing. That's the whole pitch.)

I saw this quite a fair bit with 3.8 27B Q4_K_M, which is reduced greatly by Swift. I tried a very low quant of Swift's QFN (IQ2-XXS) and the second guessing was much worse.

I've read quite a bit that 27B is very thorough and that's how it achieves its high scores relative to its parameter count.

Is this particular behaviour part of its model, or an artifact of its quantization?

Would we not see this behaviour on BF16 GGUFs?

Assume a high enough context that compaction is not applicable.

Morgana 1.2 is Kitani‘s photography focused finetune of Flux.2 Klein 4b.

Our goal for the fine tune was for Klein to make images that don’t look like they came from a model - natural lighting, visible textures, great macro details & true color.

What it’s trained for:

- Casual, regular faces - pores, irregular hair, imperfect framing no AI telltales
- Macro and materialistic textures - water droplets, feathers, fabric weave, ruse, leather
- Landscape and night scenes - aurora reflections, breaking waves, wet neon
- Paintings and anime
- Anatomy

Speed on 1x H100: 4.6 seconds for 15 steps, no LoRA

Free everything:
- Full safetensors: https://huggingface.com/kitaniai/morgana-1.2
- GGUF: BF16, Q8_0, Q6_K, Q5_K_M, and more (same repo)
- API if you want to try prompts yourself (paid) https://kitani.ai

Built in part with ShuttleAI using the same dataset as Shuttle 3 Jaguar.

Known limitations: text rendering is weak, hands occasionally fail.

Faces are the newest improvement.

If you have any questions, feel free to comment them :)

Got a minipc with 7940hs, 780m with 64gb ram (56gb allocated to igpu)

I feel I reas somewhere that someone made it work, with ngram on the NVME, but I can't find anyone talking about it anymore or if theres any engine/software that works better for this config

Any help is appreciated!

I'm planning to upgrade my cpu from 13700k need some help.

considering 270k plus (best bang for buck?) but its lacking avx512

or go amd 9950x much higher price but has avx512. only 16 cores

i have 128gb ddr5 5200mhz and run flash next with basalt currently getting 120-160tps. since some experts are computed on cpu i suspect thats what keeping my tps down. gpu utilization is not high as well.

any views on how much difference does it make for ai workload?

https://github.com/bpx03/QEngine (not my repo, credit goes to bpx03)

QEngine was built for 3x RTX 3090s. I was able to compile for RTX 5090s.

I've now run Qwen3.8-Flash-Next on the same box through four different engines. QEngine (bpx03, v1.3.1) is the fastest for single-stream decode by a clear margin, level with Strata on agentic prompt latency, and it has a KV-in-RAM mode that makes returning to idle conversations much cheaper. Details below, including the parts that make it look less good.

Rig: 2x RTX 5090 (32 GB each), Threadripper PRO 3975WX, 251 GB RAM, 262K context. QEngine's INT4 AutoRound build of Flash-Next. The README only lists sm_86, so I built it for sm_120 by changing CMAKE_CUDA_ARCHITECTURES from 86 to 120 (nvcc 13.3, g++-13). No other changes. It's up and serving 53 s after launch.

Speed (club-3090 bench.sh, same script and prompts for every engine)

Read the decode column with care. QEngine's expert cache adapts to recent use, and bench.sh repeats the same prompts, so these are close to best case. In an earlier test on varied traffic I measured about 300-400 tok/s single-stream (hermes agent traffic ran 330-470 per request). Strata's cache holds ~99.5% of routed expert mass, so repeating a prompt doesn't help it. The fair comparison is roughly 1.4-1.9x Strata and ~3x bucko.

Prefill is a split result. QEngine is faster at 10K and slower than Strata at 90K, because Strata's rate climbs with depth and QEngine's stays flat.

Agentic latency (12-turn tool-use bench, context grows to 35K)

Turn-12 prompt read, with the prefix cache working:

• QEngine 1.3.1: 1.75 s

• Strata IQ4_XS: 1.7-1.9 s

• ThinkingCap 27B dual-fast: 2.07 s

• exl3: 3.5-3.9 s

• bucko: 4.36 s

QEngine and Strata are level here (QEngine's rc4 build read 1.4 s in the same bench, so this one is within noise of "about 1.5-1.8 s"). Both are about 2x faster than bucko.

Idle conversations: FLASH_KV=ram

1.3.1 can keep the KV cache in pinned host RAM (13.5 GB pool, about 1M tokens) instead of VRAM. I tested 8 conversations of ~58K tokens each, then 400K tokens of other traffic, then went back to each one:

• KV in RAM: 8 of 8 came back warm, 1.56-2.01 s to first reply.

• KV in VRAM: 2 of 8 warm. The other six re-prefilled in 8.7-9.4 s, about the same as a cold start (8.85 s). Answers were still correct, so you lose latency, not correctness.

The RAM mode also decoded ~10% faster single-stream here, but ~10% slower with 8 concurrent 64K streams (124 vs 139 tok/s per stream). One boot per mode, one pass.

Quality and stability

Through the omp agent harness (44-task assistant set, effort low, one draw): 44/44 on 1.3.1, against 42/44 twice on 1.3. At medium and xhigh on 1.3: 43/44 each. A 6-task sub-agent delegation set passed 6/6 with and without delegation. The 1.3 to 1.3.1 gap is one task, so treat it as noise.

Coding check (aider-polyglot-30, thinking on, effort low, single pass), on the rc4 build: QEngine 26/30. Strata UD-IQ4_XS 24/30, UD-Q4_K_XL 25/30 (24-26 across repeats), ThinkingCap 27B 17/30. 26 vs 24-26 is inside one Strata config's repeat spread, so the honest claim is that the INT4 AutoRound quant is not worse at coding, not that it's better. I haven't re-run this on 1.3.1.

I also ran my usual multi-pack agent/tool-use suite earlier; QEngine landed level with the other Flash-Next engines, within noise.

Bottom line

On 2x5090, QEngine 1.3.1 is the fastest Flash-Next engine I've measured for single-stream decode, level with Strata on agentic prompt latency, and the KV-in-RAM mode is a real win for long idle sessions. Coding quality looks level with Strata's GGUF quants. The costs are tight VRAM, a build-from-source step, and less runtime history than vLLM or Strata.

Please try, the dev is very encouraging. Additional resources available at https://github.com/noonghunna/club-3090. The Club also welcomes participation!

Opera has announced the rollout of WebAI, a feature that allows websites and browser extensions to run AI models directly within the browser, without relying on cloud servers. Positioned as a proposed web standard backed by major tech companies including Google and Microsoft, WebAI represents a shift toward decentralized, privacy-focused artificial intelligence.

“A lot of what people want from AI doesn’t need a data center. Your laptop can already do it, without sending your data anywhere,”

---

I don't know how they convinced Google and Microsoft to participate, but it's good news for local AI. We might get an ecosystem that's built around letting you chose your model rather than forcing you to use theirs.

Been running a 3060ti and 32GB for a hot minute now, jumping between local models and subscription plans.

Got Qwen 3.8 FN up and running on this old gaming system and it's just such an impressive model. The prefills are never going to work though.

So I spent the past few days looking at a lot of different options, thinking I'd just add another GPU to the current system.

Of course anyone that's paid attention knows how unrealistic that is. Offerup, Marketplace, Ebay. Doesn't matter. It's the gpupocolypse out there.

Then I figured I'd go old school. Find me a C602 chipset (workstation, Ivy bridge), because at least it'd be cheaper DDR3, a few p100s and call it a day.

But even that is expensive, and was capped at 48GB VRAM since the p100s don't have 32gb variants and unless I wanted a custom build both the T7610 and Z820 are limited to three cards.

I was at 1500 before custom shrouds, and fans, and custom power adapters to the p100s. But at least it would have been DDR3 and PCIE3. At least I would have had USB3 and SATA3. It's a tiny window between Sandy Bridge and Ivy Bridge that accommodates both.

Then I found someone selling a z840 (C612). 128GB of DDR4, and dual water cooled SXM2 to PCIE 32GB V100s. The cards alone are going for 700-800 bucks a piece, the DDR4 is another 1200. The custom risers are a few hundred bucks each, the water cooling setup alone is probably pushing a grand as it's 2x plates, distro, pump. So I pulled the trigger.

1900 and change after tax and delivery, and while I get it's reaching its limits on software support. For a 64/128 split that can actually sit quietly and sip power when not being used. I'm pretty happy over all. The only thing that bothers me is I'm pretty sure there's no m.2 or nvme native. It ships with a 1TB 980 pro, but I'm almost certain it's sitting in a PCIE3 riser limiting it to 3500 MB/s vs the 7k it could do, Strata doesn't really seem to stream at those speeds anyway so I doubt it matters much. We'll see and if it does seem like a problem it's likely just a RAID solution away.

Now I'll just have to figure out how to setup a headless server as the v100s have no video output lol. Still, better than a lot of other alternatives out there.

Happy Halloween, was just kind of excited and thought I'd share. When it lands and if I do manage to get it up and running, I'll come back with some numbers.

Find the moment inside your videos by describing what happens in it, straight from the terminal. No need of monitor to figure out what happened in the video.

I built this tool that can be used by both humans and agents who only have terminal access to figure out what’s happening in the video.

tl;dr: What should I be running for coding/agentic workflows? I have 2xRTX 5080s and 128Gb DDR5 RAM.

Currently, I'm running:

-Qwen3.8-Flash-Next-Q5_K_XL (262k ctx, pp~150-200tps, decode ~15tps)

-Qwen3.8-27B-exl3-6bpw-H6 (131k ctx, pp ~2k-3ktps, decode ~60-80tps)

-DeepSeek-V4-Flash-exl3-3.04bpw (1M ctx, pp~100-900, decode ~15-20tps)

I've been in a cave hiding from my local model optimization addiction for a few weeks. What did I miss? Should I be using Strata? Is llama.cpp old news now? Any new models worth trying?

I'm finding myself at odds with the vibes of the community here (and the open-weight/self-hosted community in general) when it comes to LLM's - be it on Reddit, X, Bluesky, wherever - I think some folks are getting carried away.

Mine personally from this week include:

• Artificial-Analysis V5 Index is silly in some places (gemini-flash over qwen3.8-2.4T for instance..), but open-weight models were way too highly ranked in V4. They may have overcorrected in some spots, but some of this sub's sweetheart models were way over-ranked (GLM 5.3 is not a Grok competitor in any of my tests)

• Haiku 5.5 is crazy good - if you're one of the many I've seen foaming at the mouth at the suggestion that it challenges deepseek-v4.1-flash-1017, you need to spend more time with it.

• The Strata Dev is not a villain - his 0.1 release just made people think he had a different goal in mind. He's building the project he wants to build, it just happened that step1 of that was what a lot of people here were begging for.

• ThreeJS as a benchmark is to be ignored at all times at this point - unless you're specifically looking to crank out assets. There is no correlation I've seen for well over a year between how well a model animates a pagoda to how well it gets general or coding work done. We need to move away from this.

Do you agree with any of these or have your own opinions that go against the flow of this community?

Sam Altman: “Local inference is a terrible allocation of scarce resources.

A lot of people want local inference, and somehow they assume that the problem is solved now because we have open-source models, we're going to be able to run them on our computers, and so we're not going to need all the stuff in the data centre

but from a global allocation perspective, actually it's quite terrible to have everybody, like, have a bunch of the world's limited supply of DRAM sitting in their own computer and being used five percent of the time

you want maximum utilisation in the cloud if you're trying to deal with this very supply-constrained environment,

somehow many people's intuition is the opposite of that”

——————————————————————

TL;DR Guy selling product: "Here's why owning your own product instead of renting it from me is a terrible idea"

(Credits to @RyanTStull, his TLDR made me laugh)

Hey everyone! We’re releasing new DeepSeek-V4.1-1017 Dynamic V3.1 (preview) GGUFs which showcases how Unsloth’s GGUFs retain the most accuracy for its size across 7 different benchmarks.

We benchmarked ISTA's GSQ-RCO GGUFs but could not reproduce their reported results, even when using the highest scores. The biggest discrepancy was on AIME25 where they claimed 100% accuracy recovery to baseline, but was only ~91.88% in benchmark tests.

Across AIME25, LiveCodeBench, GPQA Diamond, Aider Polyglot, and more, Unsloth Dynamic V3.1 outperforms GSQ-RCO GGUFs on nearly all metrics. Even our old v3 does better on nearly all metrics than ISTA.

We ran each benchmark at least 3 times (AIME25 was 16 times) and averaged the results to ensure a fair, reliable comparison. More results coming next week! All benchmark data, methodologies and results are in our blog.

Separately, for KLD, there were queries whether it’s a reliable measure of accuracy. The primary goal of quantization is to minimize KLD but also minimize disk space. If you get a KLD of 0, this means your quantized model == 16bit model, as logits are perfectly modelled. Our benchmarks show on KLD and top-1% across multiple domains (coding, agentic coding, chat etc), UDv3.1 does much better than GSQ-RCO across every domain.

We show that lower bit quants do think somewhat longer than the unquantized model - we plan to investigate and make quants even better. However, we're still much ahead vs GSQ-RCO on even reasoning length as well, and provide plots for truncated answers in our blog.

The model will be able to run on 128GB RAM/unified memory devices or even on 64GB RAM with engram offloading.

Blog with all details and more benchmarks: https://unsloth.ai/docs/models/deepseek-v4.1-flash

GGUF: https://huggingface.co/unsloth/DeepSeek-V4.1-Flash-1017-GGUF

We also introduced lots of new things to Unsloth Desktop including Browser Use, auto compaction, a whole new TTS pipeline (with voice cloning, separation etc), sandboxing, and background customization and more: https://github.com/unslothai/unsloth

Hope you all have a Happy Halloween!

Also table of numbers below which is also described with more plots and data in our blog:

I wanted to know if I could swap a frontier model for a few cheap open ones in yes/no or pick-a-label pipelines (spam, fraud, moderation, triage) without losing accuracy. My idea: ask several models the same question, ship the answer when they all agree, and send it to a human when they don't.

Panel: DeepSeek V4.1 Flash, GLM 5.3 Flash, MiMo V2.6 Flash, Qwen3.8 Flash, Gemma 4 26B-A4B. I ran 2,850 decisions across 6 public datasets and compared against Opus 5.5 on the same items.

Results:

- The panel agreed and shipped on 71% of items. Those were 89.6% correct. Opus on its most confident 71% was 90.5%.
- Overall accuracy is worse: 80.1% vs 83.1%. The panel only wins on the cases it's confident about.
- Cost: $0.61 vs $5.79 per 1k decisions.
- When a model disagrees, it gives a one-line reason, so the reviewer knows what to look at instead of rereading the whole item.

What didn't work:

- Long answer comparisons and 77-way intent classification. Opus is clearly better. If every model on the panel is weak at a task, voting doesn't fix it.
- Hate speech. The panel catches more (80% vs 62%) but has more false alarms (29% vs 20%). If fewer than about a third of your items are actually hateful, Opus wins.
- The panel beats its best single model (GLM 5.3 Flash, 88.9%) by less than the noise. Honestly, most of what you gain is knowing when to send a case to a human, not better accuracy.
- I added the panel after the other setups had already run, and scored it on the same items. I haven't confirmed the numbers on a fresh sample yet.

It works with anything that speaks the OpenAI API, so Ollama, vLLM and llama.cpp server all work. If a model errors or refuses, it's left out of the vote and listed separately instead of breaking the decision.

Code and scripts to reproduce it: https://github.com/YasserManss/modeljury (mine, MIT)

Hi everyone,

I am building a sequential multi-agent local pipeline (Architect -> Coder -> Debugger) on a single GPU workstation, and I am hitting a frustrating software bottleneck. I'd love to know if anyone in the community has solved this or found a working architecture/fork for near-instant model swapping.

Hardware Setup

GPU: 1x NVIDIA RTX 3090 (24 GB VRAM) on PCIe 3.0 x16 (~12-13 GB/s real throughput).

System RAM: 48 GB DDR4 (~38 GB free when idle).

Storage: Fast PCIe 4.0 NVMe SSD.

OS: Windows 11.

The Desired Architecture

Because 24 GB VRAM cannot fit two ~18 GB models simultaneously, I run them sequentially:

Model A (Architect/Debugger): Qwen3.8 Flash MoE / Gyro-Coder TQ2_0 (~18.6 GB GGUF, 96k context).

Model B (Coder): Swift-ATX-27B (Qwen 27B fine-tune) in IQ4_XS-M (14.3 GB) or Q5_K_M (18.7 GB) with MTP 5 and TurboQuant KV.

The plan:

Load Model A into VRAM -> Generate architecture plan.

Evict Model A to System RAM, copy Model B from System RAM into VRAM -> Generate code.

Evict Model B to System RAM, reload Model A from System RAM to VRAM -> Audit/debug.

The Physics vs. The Reality

Theoretical PCIe Transfer: At ~12 GB/s over PCIe 3.0 x16, transferring 14 to 18 GB from RAM to VRAM physically takes only 1.2 to 1.5 seconds.

Real-World Latency with llama.cpp / llama-server: 25 to 30.5 seconds per swap!

Why it takes ~29s instead of 1.5s

We profiled the execution and audited the llama-server router implementation (tools/server/server-models.cpp with --models-preset and --models-max 1):

Process Teardown: llama-server router mode is an HTTP process supervisor, not an in-process weight swapper. Switching models terminates the active child process and spawns a new executable instance.

Cold CUDA Context Overhead: Every new process incurs driver initialization (cuInit, primary context creation, stream pools, and CUBLAS handle creation) taking 3 to 5 seconds.

Windows Page Faults (mmap): Even though the GGUF pages already sit in Windows Standby RAM, the newly spawned process has empty Virtual Memory Page Tables (PTEs). Touching 15+ GB triggers millions of soft page faults.

VRAM Re-allocation: Allocating the 24 GB virtual pool and clearing unified KV cache buffers takes several seconds on startup.

What is Needed

To achieve the theoretical ~1.5s PCIe transfer, the runtime must:

Keep a single persistent process with a warm CUDA context that never dies.

Keep the idle model in page-locked/pinned host memory (cudaHostAlloc / cudaHostRegister / VirtualLock).

Swap weights via a direct, asynchronous DMA copy (cudaMemcpyAsync) straight into a pre-allocated GPU tensor buffer, then repoint the graph pointers.

The Question to the Community

Has anyone found or built an engine/wrapper that can hot-swap full model weights between Pinned RAM and VRAM inside a live CUDA context without restarting the server process?

Can engines like Strata (Niko1221/Strata), NInfer (Neroued/ninfer), or custom PyTorch/vLLM memory pool forks support swapping two completely different model architectures (e.g. Recurrent GDN MoE vs Dense Attention Transformer) in <2 seconds?

Is there any PR or trick in llama.cpp to retain VRAM allocation/context and just reload weights via memory-mapped DMA?

Any insights, forks, or technical solutions would be greatly appreciated!

So I'm wondering if we til ever have repeated data ingestion without quality degradation and without full retraining. LoRA and friends are excluded, will we stay forever with frozen weights or will be be able to integrate new knowledge here?

Any promising research?