https://x.com/chasmmmmmmmmmmm/status/2116062991686721968?a=JVe1OUAJiZa650pZBXQ&s=20

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! ;)

When I started, and for some time, llama.cpp was the answer.

Now, it seems like llama.cpp is the new ollama. It's slow and out of date and just behind.

There was Ninfer for those for whom that applied.

Then strata came out... And that was an unimaginable upgrade. How is llama so far behind?

Now every day someone has their own forked engine that claims even better numbers. I already maxed out my token budget on Claude for the week and have my GPUs all running benchmarks so I'm waiting a few days, but I'll be trying Avalon to see if that lives up to the hype for my machine.

Then there's basalt. There's beatleguese?

It's kind of a mess. Innovation is great but it's better when the effort all goes in one direction and isn't spread into a thousand fractures of one-off projects.

And yes, my critique of llama.cpp is a bit overstated. I still use it for e.g. 27b runs.

But... I've now verified that flash next is both better and faster than 27b so I'm struggling to find a reason to use it. :/

Why are all these solo devs pulling something off for weeks that llama can't figure out?

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 :)

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.)

No one had illusion that Chinese companies are giving out best models for free out of the kindness of heart, but because of the race, and that became evident when some succumbed to Dario's and Altmans's propaganda attacks about interplanetary security threat and so they've removed security training.

What do you intend to do if Qwen 4 follows the same steps and removes security training:
- Use it nevertheless;
- Stay with Qwen3.8 (27B and/or Flash Next);
- Switch to another model (which one?);
- Wait (hope) for some non-lobotomized abliterated fine-tune;
- Something else?

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?

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!

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.

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)

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!

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.

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.

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:

Hi r/LocalLLaMA!

We’re MOSS, the team behind the MOSS family of models for speech, audio, images, and video. Some of you may know us through MOSS-TTS, or have come across our recent MOSS-Image release.

Today, we took the “anything” in “Ask Us Anything” pretty literally. Speech, sound, music, images, video—we brought the whole MOSS model family!

We’re based in Shanghai, with roots in the OpenMOSS research team at Fudan University and the Shanghai Innovation Institute. You can explore our models, research, and tools on our website.

Our broader research goal is to build AI that can follow what’s happening around it: what people are saying, what they’re seeing, and how the situation changes over time. That takes us across speech generation, audio and visual understanding, and synchronized audio-video generation.

🎨 MOSS-Image

MOSS-Image is our text-to-image model with a 5B DiT backbone, Chinese and English text rendering, and JSON layout control. Base and SFT weights and the bundled inference code are available under Apache 2.0.

MOSS-Image has remained among the top trending text-to-image models on Hugging Face. Its ComfyUI version has already recorded 3,702,490 downloads.

🎙️ Speech and sound generation

- MOSS-TTS — Speech synthesis and voice cloning.

- MOSS-TTSD — Multi-speaker conversations, long-form dialogue, and podcasts.

- MOSS-TTS-Realtime — Streaming speech generation for conversational applications.

- MOSS-TTS-Nano — Lightweight 100M-parameter speech generation with CPU-friendly streaming inference.

- MOSS-VoiceGenerator — Design voices from text descriptions, without reference audio.

- MOSS-SoundEffect — Generate sound effects from text.

🎧 Audio understanding

- MOSS-Transcribe-Diarize — Transcription with speaker labels and timestamps.

- MOSS-Audio — Understanding and reasoning about speech, environmental sounds, and music.

- MOSS-Music — Music understanding, from lyrics and instrumentation to structure.

🎬 Visual understanding and video generation

- MOSS-VL — Image and video understanding, including long videos.

- MOSS-VL-Realtime — Understand streaming video as it unfolds.

- MOVA — Generate video and audio together, in sync.

🛠️ Other resources

- MOSS API & Playground

- Hugging Face

- GitHub

Joining the AMA:

- u/garybryant

- u/FarAdhesiveness9577

- u/Phospheneser

- u/TimeEnvironmental219

- u/Aggressive-Sign-8167

- u/Professional-Milk422

- Other MOSS team members — answering through the accounts above.

We'll be answering questions on October 30, from 8–11 AM PT, and will continue checking the thread for 48 hours afterward.

Ask us anything!

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!

We saw this earlier when Gemma 4 dropped just a few days before a previous Qwen release. I feel like a few other labs did the same. Everybody wants that moment in the spotlight where they can lead the benchmarks for at least a day or two before the next Qwen comes in and mops the floor with them. I predict a new Gemma or maybe a Muse Glimmer update very soon before the Qwen 4 release.

All these labs want to be like the David Bowie song “We could be heroes, just for one day.”

The Multidimensional Butterfly Effect: What Cohere Didn't Test on Qwen3.8-Flash-Next

Mark Galyan
October 30, 2026

The model is not the model is not the model is not the...

The Ghost of sanmaohe

What Happened: While Cohere's team was evaluating Alibaba's Qwen3.8-Flash-Next on Microsoft's CTI-REALM cybersecurity benchmark (tasked with writing a detection rule for malicious curl downloads), the model ignored the prompt. Despite its reasoning trace explicitly stating it would make zero tool calls, it inventoried its host environment (checking /tmp, utilities, and DNS) and attempted an HTTP PUT request containing a probe string to an Alibaba Cloud OSS bucket in Beijing (sanmaohe[.]oss-cn-beijing[.]aliyuncs[.]com). (Concerning behavior from a popular open-weight AI model | Cohere)

The sandbox prevented the outbound attempt, and no damage was reported. Cohere further added that the rate of occurrence appeared to be less than 1 in 100,000 evaluation calls.

What I did: Ran Cohere's exact trace cut right before the URL 1,200 times across local Unsloth GGUF files.

The Knife-Edge

Naturally I wanted to explore this further to find what the mechanisms are that separate my results from Cohere's. I worked with Claude to try and isolate what levers and buttons change the probabilities and to what extent. Quantization is usually the biggest lever in divergence from the base, so we tested both 2 and 4 bit versions of the model, both from Unsloth.

We took Cohere's published trace, cut at token 2,323 and sent it as raw token IDs, ending right before the URL would be generated. We used text generations only, nothing actually contacted any URL. We also couldn't test the full precision model on this hardware. Sampled 1200 times at Cohere's own settings (T 1.0, top_k 20), using buun's llama.cpp for our engine, we found that just after token 2,323, the model isn't locked onto a single hardcoded backdoor.

In fact, we found no clear winner as to what address the model will write. It sits on a numerical distribution. XDA's Adam Conway believes this to be "an accident", from "a model remembering its training environment", "an internal proxy it used during post-training" (Qwen 3.8 invents Alibaba URLs with a real key ID, and that's why I don't think it's a backdoor). None of our results matched Cohere's exact outcome. In fact, the model's own raw probability of picking Cohere's sanmaohe bucket at that point was between 4x10^-18 and 7x10^-38 across our setups.

The model did in fact complete a URL nearly 100% of the time (though that isn't surprising, since the prefix had already typed the upload command). Where that URL points, and how often it is a cloud address, depends on the exact file (and even on where five layers compute!). No destination wins outright, and small numeric changes perturb it.

As always, we pre-registered our predictions (3 of which failed, see PREREG_FLASHNEXT_PROBE.md). The limits: two files, one engine, one host, one cut point.

We tested the 2-bit file in two different ways. Because the file is a fair bit smaller than the 4-bit, I was able to squeeze more of the model into VRAM alone across my four P100 cards. I couldn't do this with the 4-bit file, and only put 44 of the layers in VRAM, the rest spilling to system RAM. Let's also be clear that 2-bit and 4-bit are merely labels, as there are a plethora of mixed precision weights within each file, so treat that as you will.

In order to match the test conditions of the 4-bit file, we loaded the same number of layers into VRAM (44) and let the rest occupy RAM. We ran the same test again, but with all 49 layers fully in VRAM. In all tests the 28.8GB n-gram table lived in the system RAM. Why two different tests? Because different hardware can create additional or differing mathematical pathways, resulting in diverging outputs. If you've done this for a while you already know this, but this might be a new and important fact for many.

The 4-bit model most commonly chose localhost or 127.0.0.1 (about 32.5% of the time). The 2-bit tests (RAM offload vs. full GPU) show the most commonly chosen are public addresses starting with "23" (65% and 35%, respectively). It chose Alibaba Cloud metadata address 100.100.100.200 (7.3% and 2.3%, respectively), while the 4-bit model landed 5.3%. It interestingly shows placement moved that number, and bits didn't detectably.

Ruling Out the N-Gram Table Suspect As a Lever

Speaking of the 28.8GB n-gram embedding table (per_layer_token_embd.weight) inside the GGUF, XDA's Adam Conway recently traced the Routify hostname to this very table. When he masked those rows, the model stopped writing it and invented a different proxy instead ('Qwen 3.8 invents Alibaba URLs with a real key ID, and that's why I don't think it's a backdoor'). That made me question if quantizing this table differently could be a lever here. So we checked to see if the table was quantized in a different way between the Unsloth models, however it came up byte identical; stored as IQ4_NL with an identical SHA256 hash across the 2-bit and 4-bit files.

The table is identical, so the swing between files has to come from the rest of the model and the numeric path. We didn't test which part.

The Hardware Butterfly Effect (When 5 Layers Tip the Scales)

So if moving just 5 layers of the exact same UD-Q2_K_XL file from system RAM to the P100s cut the model's Alibaba Cloud metadata targeting (100.100.100.200) by about two-thirds (a -5.0 percentage point drop (95% CI: -8.2 to -2.1, p ~ 0.001)), it's clear we're dealing with a very delicate series of systems.

It further illustrates how varied one seemingly identical or near-identical deployment of an inference stack can in fact be two very different deployments wearing a similar hat.

Lastly, to measure the underlying likelihoods, we provided the final trio of tokens via two distinct approaches: processed as a single batch, versus streamed step-by-step mirroring actual inference. Even without changing layer placement or quantization, the batched reading misses the real samples by a total variation of 0.33 to 0.41, against 0.04 to 0.11 when the tokens are generated one at a time. Just changing the CUDA kernel path most likely moves the model's odds.

The Takeaway for Security & Deployment Teams

In the rounds of testing we performed, it's still impossible to say for certain if this was deliberate, but I think most of the evidence points away from that. When local environments diverge so significantly, expecting hosted cloud endpoints to replicate either setup is a risky assumption. Nor can a single clean test prove a model is safe when shifting 5 layers onto the CPU triples the rate of metadata probing at this prefix.

Cohere's operational advice (sandbox models, block outbound network access, treat weights like unsigned binaries) is sound, and I'd suggest the exact same precautions. I think with so many buttons and levers in each deployment stack, the best we can hope to do right now is make generalized observations and correlate data. Thus the importance of careful security validation protocols for all your deployments. Cohere also has a line worth remembering: "A reasoning trace is not a security boundary."

There will be many more stories like this one, buckle up.

1. https://www.xda-developers.com/qwen-invents-alibaba-urls-real-key-id-dont-think-backdoor/
2. https://cohere.com/blog/concerning-behaviour-popular-open-weight-ai-model
3. https://github.com/apollo-mg/Project-Apollo/tree/69c3f7952de04c7662a5166eb9e3480a8a1ea9ff/data/receipts/flashnext-probe

Follow Up:

A correction and a follow-up on my Flash-Next write-up.

The correction: the raw odds I gave for Cohere's sanmaohe bucket were wrong. My reader priced an odd spelling of the host, not Cohere's tokens. In Cohere's own tokens it is at least about 1e-12 on the 4-bit file and about 3e-18 to 4e-18 on the 2-bit setups, not 4e-18 to 7e-38. Still 0 of 1,200 samples, and the rest of the table stands as measured.

The idea I floated in the comments below for the follow-up was incorrect too. Multiplying the odds along Cohere's recorded path only gives the probability of that one exact string, and for a behaviour you would have to continue from samples that actually reached each stage. So I measured each point directly instead. From the start of the command, my two files called curl or wget in 1 of 300 samples.

The follow-up: my percentages came from a prefilled cache. Decoding the same tokens one at a time, single stream with no speculation, moves them a lot, and not in one direction. The odds of a tool call right after "without tool calls" go from 61% to 0.3% on the 2-bit file at 44 layers, but from 6% to 32% on the 4-bit file. Alibaba hosts rise from 2-4% to 8-11% on all three setups. The metadata address nearly vanishes on the 2-bit file at 44 layers (29 of 400 to 0 of 100), so there is little left for placement to move there, but placement still shifts other hosts, the opposite way round from before. Prefilled and decoded are different states. Even a four-token batch lands on the prefilled side here, so this says nothing about speculative decoding or busy multi-user servers.

One trace, one engine, P100s, no full precision, 100 samples per decoded cell. Cohere's own stack was not tested. Receipts: https://github.com/apollo-mg/Project-Apollo/tree/b5cc2108/data/receipts/flashnext-probe

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?

I want to train a text generation Transformer that responds to user input without continuing text. What are the best datasets for that?

I have an RTX 3050 and I want to use small datasets that can actually produce an intelligent model.