r/Qwen_AI • • 59m ago

Discussion My thoughts with Qwen-Flash-Next vs Qwen-27B (v3.8)

• Upvotes

The following feedback is going to be highly subjective, I’m not going to compare them in different benchmarks for the 100-th time, instead I’ll just share the vibes I get from both

After using 27B for over a month and Qwen-Flash-Next for 3–4 days, here are the main differences I’ve noticed:

1. General Knowledge
Flash-Next seems to be significantly more educated, it knows more libraries, nuances and edge cases, which sometimes helps it navigate projects better, 27B is by no means ignorant buy the difference is quite noticeable

2. Context Retention & Steering
27B can hold context and accept corrections, but I’ve learned not to steer it. I prefer giving it a large prompt and letting it finish without interrupting. It can handle a correction or two but I just avoid doing it instinctively after having felt the model’s overall “vibe”

Flash-Next is another story. Its performance makes me treat it like a full-fledged cloud model. I constantly steer it, add context, correct it or change the original spec on the fly and it handles all of this easily and never forgets anything so instead of waiting for it to one-shot a spec, I freely guide it along the way and that’s honestly a pretty big deal, I haven’t realised how comfortable it is until I tried it

Conclusion
Both models are great, but Flash feels closer to the cloud and it’s exceptionally strong in long horizon agentic tasks for its size


r/Qwen_AI • • 6h ago

News Koboldcpp v1.123 released

Thumbnail
github.com
6 Upvotes

This release includes added support for Qwen Image 2.1, among other improvements/fixes.


r/Qwen_AI • • 1h ago

Experiment Qwen 3.8 flash next running at 12vram/32gb ram

• Upvotes

Running 125B MoE models on a mid-tier 12GB gaming GPU

I've been spending hours getting this model running on a 4070 Super with a full 256K context window, and speeds turned out surprising after 6 hours of optimizing.

Hardware and config:
GPU: RTX 4070 Super (12GB)
RAM: 32GB
Engine: upstream Strata with my own source patches
Models: Gyro-M and Gyro-S
Context: 262,144 tokens
KV cache: Q4, 32K tokens GPU-resident
MTP: off for both

Approach: experts are tiered across memory. Hot experts stay in VRAM, 16 GiB sit in RAM, and the rest stream from SSD. I tuned CPU workers, GPU scheduling, SSD reads, and suffix speculation. For Gyro-M, I patched the source to overlap SSD fetches with RAM-expert compute. Raising the prefill chunk size from 7,168 to 8,192 tokens gave an 8-15% prefill gain.

Vision and MTP: adding vision to Gyro-M hurt performance noticeably, so only Gyro-S has it. Gyro-S runs the vision encoder on GPU and frees it afterward. MTP also reduced speed in my tests, so it stays off.

Speed Results (prefill / decode tok/s, averaged over 3 runs):

Gyro-M
8K: 947 / 33.2
32K: 1,512 / 36.7
64K: 1,689 / 35.6
128K: 1,616 / 36.6
192K: 1,748 / 35.9
256K: 1,717 / 36.1

Gyro-S
8K: 879 / 40.8
32K: 1,613 / 41.0
64K: 1,762 / 39.8
128K: 1,810 / 41.9
192K: 1,779 / 41.1
256K: 1,779 / 41.2

I am working on making this a recipe so others can reuse it and get similar speeds . I will share it in this post when it’s released.

Huge appreciation for the community for making it possible to run a model of this intelligence and comparable to last year’s Opus 4.6 running in a gaming gpu and thanks to Qwen for releasing this model and giving us these models for free and at a size the people can run.


r/Qwen_AI • • 1d ago

Model Qwen 3.8 Flash Next Q3 S - Benchmark creation

Enable HLS to view with audio, or disable this notification

84 Upvotes

After running a benchmark test on Exo in Opencode and being amazed by the result, I thought I'd try other models on Opencode. Many were surprisingly terrible. Especially some mid level models.

Earlier posts:
https://www.reddit.com/r/opencode/comments/1wzm1ah/exo_free_frontier_level_wow/
https://www.reddit.com/r/opencode/comments/1ww5o7y/animated_horse_space_bunny/

Today I installed Strata on https://github.com/Niko1221/Strata

I connected up my AMD R9700 32gb with 64gb RAM and used the model Qwen3.8-Flash-Next IQ3_S. Admittedly I was expecting terrible results considering it's a small Q3. It acheived 90 tk/s decode approximately 3x compare to 27b

I tried the usual prompt from the other posts, but the output wasn't great. So I tried iterating with a few more prompts in the hope it would improve it. The major leap was when I asked it for a plan, then asked it to build it and when I said "low poly" style but with many polygons. FYI I'd done similar with other models and the result would get worse rather than better.

Anyway I thought I'd share the output.
Qwen 3.8 Flash Next IQ3 S - https://web.esuyo.com/horse-strata-qwen-3.8-q3-s-1/

Qwen 3.8 Max - https://web.esuyo.com/horse-qwen-3.8-max/


r/Qwen_AI • • 23h ago

Discussion Qwen now picks from 4B+ Taobao products and can check out inside the chat. How does it decide what to recommend?

5 Upvotes

Most of the Qwen discussion here is about the models, and fair enough: Flash-Next as the Qwen4 preview, the 2.4T open weights, the 27B under Apache 2.0. But the part of the Qwen story I keep coming back to is the consumer app, because it has turned into something much closer to a shopping agent than a chatbot.

Over the past few months Alibaba has:

- connected the Qwen app to the full Taobao and Tmall catalogue (4B+ products by their count), with agents handling orders, logistics and after-sales

- opened the app to third-party brand agents (KFC was the first restaurant on it), which plug into Qwen's own payments, accounts and order system

- launched Qwen Intelligence for phones with HONOR, using an API-first, GUI-fallback agent that works across apps

So a request like "find me an electric toothbrush for sensitive gums" can now go from question to shortlist to paid order without a search results page ever appearing. The Lunar New Year numbers (120M+ orders in six days) show the plumbing works at scale, though that ran on roughly RMB 3B of incentives, so it says more about capacity than habit.

What I can't work out from the outside is the recommendation step. What is Qwen actually grounding on when it picks? Taobao listing data and reviews only, or outside sources like Zhihu and Xiaohongshu too? Do Tmall flagship stores get an edge over smaller sellers? Alibaba also says it uses your order history, so two people asking the same question probably won't see the same picks.

I spend a lot of time looking at how AI assistants choose which brands and products to mention (hence the username). With ChatGPT or Perplexity you can at least see the cited sources. In a closed loop where one company owns the model, the catalogue, the payments and the delivery, I'm not sure anyone outside Alibaba can see why one product wins.

If you've used Qwen's shopping features, especially in mainland China, what have you noticed? Does it show you where its picks come from? Does it feel neutral, or does it lean toward certain sellers?


r/Qwen_AI • • 17h ago

Benchmark enable_thinking: false is silently ignored by some providers, and it tanks Qwen3.6-35B to 0% goodput

1 Upvotes

I run a weekly benchmark of open models on HF Inference Providers at 1, 25 and 100 concurrent users. Nine Qwen models are in it. Posting the Qwen results here because one of the findings is a config gotcha rather than a model property, and it took me a couple of weeks to spot. https://huggingface.co/spaces/Infergauge-load/llm-performance-and-load

20 prompts, 3 repeats, 60 requests per figure, one provider pinned per model, no client-side retries. Goodput is the share of requests meeting every threshold at once: first token under 2s, finished under 15s, inter-token latency p95 under 80ms, format score at or above 0.8, no error. Correct but slow still counts as a miss.

Qwen3.8-27B on deepinfra — 47 output tokens, format score 1.00, goodput 100%

Qwen3.5-9B on deepinfra — 49 tokens, format score 0.90, goodput 36.7%

Qwen3.6-35B-A3B on scaleway — 159 tokens, format score 0.00, goodput 0%

All three at 1 concurrent user, same enable_thinking:false setting.

DeepInfra honours it. Scaleway accepts the request and ignores the flag, so the model thinks, spends 159 output tokens on average against about 48 for its siblings, and never lands a parseable answer inside the budget. Qwen3.6-35B-A3B posts 0% goodput with a 0% error rate. Every single request succeeds. OVHcloud at least fails loudly: HTTP 400, "feature is not currently supported", 60 out of 60.

Also worth knowing: the older `no_think` parameter still works on Qwen3-0.6B, 3-4B and 3-8B, but the 3.5/3.6/3.8 generation ignores it and wants the `chat_template_kwargs` form.

Qwen3-Coder-30B-A3B was the only model out of all 23 in the benchmark, Qwen or otherwise, that held 100% goodput at every level. 3.3B active parameters, sub-half-second TTFT with 100 concurrent users on it. Qwen3.8-27B is just behind and is dense rather than MoE.

Qwen3.5-9B fails for a different reason than Qwen3.6 does. Thinking is genuinely off, output length is normal, zero errors at every level. It streams unevenly: ITL p95 of 131ms at one user, 165ms at 25, 466ms at 100, against an 80ms gate. Time to first token stays around a second throughout, so a TTFT-only benchmark would call this model healthy.

Caveats: Shared public endpoints carrying traffic I don't control. Run-to-run variance is large and a few points is noise. Two 1-user runs two hours apart once gave me 4 vs 6 models clearing 90% across the full board. The featherless-ai rows at 25 and 100 users are measuring my account's concurrency cap as much as the model. That provider allows 10 concurrent units per user and 429s above it, which is most of the error rate on Qwen3-0.6B and Qwen3-4B. Discount those. Provider is pinned per model and not held constant across models, so part of what you see is the host and not the weights. Deliberate, since it's what you get calling these through hosted inference, but it isn't a clean model-to-model comparison. Every run is archived as its own CSV if you want to check a trend instead of one Monday.


r/Qwen_AI • • 1d ago

Discussion Qwen 3.8 Flash Next on 24gb GPU and 64GB RAM with 2500 tps prefill.

Post image
176 Upvotes

Holy crap, this is amazing. I'm fairly new to local AI, and came across Strata. My daily driver is Qwen 3.8 27b, but the thinking can sometimes frustrate the hell out of me. I was also only getting around 40 - 50tps, so I decided to test out Qwen Flash Next on my 24gb graphics card with 64gb of ram - it has no business even running it.

Guys, I'm literally getting between 2500 and 3000 tokens/second prefill, with decode between 100 and 130tps routing the model through Hermes. This is insane. Definitely try it out if you want to run Qwen Flash locally.

Edit: I'm running a RTX 5090 Mobile with the ISTA's DASlabs Qwen3.8-Flash-Next-GSQ-RCO-IQ3_XXS with a full context window of 262k tokens.


r/Qwen_AI • • 1d ago

Discussion I built an inference engine that only runs Qwen3.8 (27B and Flash-Next) on one RTX 5090

35 Upvotes

Hi all. I've been building ignis, an open-source inference engine from scrtach that runs one thing: Qwen3.8, on one Blackwell card (RTX 5090 or RTX PRO 6000). No GGUF, no other models, no multi-GPU. Giving that up is what lets every kernel and every scheduling decision be shaped around these two models.

I built it because I daily use Qwen as the backend for coding agents (opencode, qwen-code, pi), and that load is a bit odd: one main agent plus a few subagents hitting the same card at once, all sharing the same long system prompt and tool list. A general server re-reads that prefix for every subagent. ignis keeps the conversation state between requests and reuses the shared part, so subagents skip most of the prefill instead of redoing it.

What it runs today:

Qwen3.8-27B: NVFP4 weights with a DFlash2 draft model grafted in. On one 5090 it does ~170 tok/s on average for a single stream, with peaks around 370 on predictable code, and ~1,065 tok/s across 8 streams at once. Up to 512K context with YaRN, images work too (1M works too, but not heavily tested; IMHO 512k is enough ). Abliteraded model available.

Qwen3.8-Flash-Next (the 125B MoE, 6B active), on the same 32 GB card. The experts are re-quantized to ~2.5 bits on average, the hot ones stay in VRAM and the rest stream from system RAM. ~90-105 tok/s on one stream on my PCIe 3.0 board. It needs 64 GB of RAM in the box.

It also switches between the 27B and Flash-Next when a request names the other model, and after 5 minutes idle it unloads the model so the GPU is free for other things (the next request loads it back, ~11 s for the 27B).

/v1/decide (systemone) extended with "visual" capabilities (eg. Where is....?)

OpenAI-compatible API (chat completions and Responses), a Playground built in, Windows (native, no WSL) and Linux, Apache-2.0.

Repo: https://github.com/gpillon/ignis

Happy to share thoughts.

EDIT: PLEASE let's keep it about inference engines, not team colors.


r/Qwen_AI • • 1d ago

Help 🙋‍♂️ Limit Reset Time

Post image
7 Upvotes

how long it would take to reset the limit? Or I should wait for tomorrow?


r/Qwen_AI • • 22h ago

Experiment Qwen3.8-Flash on Alibaba Cloud Model Studio Virginia: API compatibility passed 3/3, but streaming TTFT ranged from 1.5s to 10.1s

0 Upvotes

I ran a small, endpoint-specific compatibility check against qwen3.8-flash on Alibaba Cloud Model Studio’s Virginia (us-east-1, international deployment scope) endpoint.

The question was not simply whether the model was reachable. I wanted to see which OpenAI-compatible API surfaces worked in actual requests—and whether a capability PASS told the whole engineering story.

Test setup

  • Date: October 13, 2026
  • Test origin: Shanghai, China
  • Network: mobile hotspot / cellular data
  • Runtime: ApiWells 0.2.3
  • Runs: 1 Basic + 3 Deep
  • Hidden retries: none

What was observed

The Basic run reported:

  • Endpoint health: PASS in 1/1
  • Model listing: PASS in 1/1

Across the three Deep runs:

  • Chat Completions: PASS in 3/3
  • SSE Streaming: PASS and SUPPORTED in 3/3
  • Tool Calling: PASS and SUPPORTED in 3/3
  • Structured Output: PASS and SUPPORTED in 3/3
  • Streaming-probe provider usage data: AVAILABLE in 3/3

Streaming latency observations

TTFT:

  • 10,094 ms
  • 1,516 ms
  • 2,610 ms
  • Median: 2,610 ms

Total latency:

  • 10,500 ms
  • 2,000 ms
  • 2,969 ms
  • Median: 2,969 ms

Engineering interpretation

For this specific endpoint, test window and runtime contract, all four tested API surfaces completed successfully in all three controlled Deep runs.

The latency observations are a separate issue. A capability can work correctly while its observed response time still varies enough to matter for interactive applications.

However, this test cannot attribute the variation specifically to the model or provider. The requests travelled from Shanghai to Virginia over a cellular connection, so network path, transient conditions and the remote service could all have contributed.

The practical takeaway is that compatibility and performance should be evaluated independently.

If I were considering this endpoint for an application, I would:

  1. Verify the exact regional endpoint rather than generalizing from the model name.
  2. Test from the intended deployment region.
  3. Use the application’s real prompts, schemas and tool definitions.
  4. Run a larger latency sample under controlled network conditions.
  5. Test concurrency, rate limits, retry behaviour and failure handling separately.

What this test does not prove

This small test does not establish:

  • Long-term reliability or uptime
  • An SLA or production success percentage
  • General latency performance
  • Performance from other client regions or networks
  • Compatibility with every schema, tool definition or workload
  • Superiority over another model, provider or regional deployment

This post reports observed runtime behaviour only. It does not use provider documentation to extend the conclusions beyond what was directly tested.

If you are evaluating Qwen through Model Studio, which workload would be most useful to test next: multi-turn tool loops, difficult JSON schemas, concurrency, long context, or retry behaviour?


r/Qwen_AI • • 1d ago

Experiment Local assistant based on qwen3.5 4b with skills, tts, stt, no dedicated GPU, 15gb RAM

Enable HLS to view with audio, or disable this notification

50 Upvotes

STT: Voxtral
TTS: Pocket
Longer video: https://www.youtube.com/watch?v=1WmvMO-f-24

-- UPDATE --
Sonia is now opensource https://github.com/grigio/sonia-assistant


r/Qwen_AI • • 14h ago

LLM Qwen3-Coder-Next (80B) running on a 16 GB Mac mini at 11.5 to 13.4 tok/s, fully offline, with a ready-squeezed 29 GB GGUF on Hugging Face

0 Upvotes

That GIF is real time: the 80B Qwen3-Coder-Next writing a TypeScript groupBy on a Mac mini M4 with 16 GB, 13 tok/s on the page's own speed line.

I've been building Coachwhip, an engine for mixture-of-experts models that are bigger than your memory. The coder picks a few of its 512 experts per word, so the engine reads exactly those from the SSD, keeps the recently used ones on the GPU, and guesses the next layer's picks while the GPU is busy. The model never fully loads.

Measured by our tester, three runs each, on the Mac mini M4 16 GB: 12.8 to 13.4 tok/s on short prompts, 11.5 tok/s with a 13,000-token prompt, 3 GB left for macOS at the tightest point. That is the fast mode, which stands in light experts with ones already in memory; it changes the answers, and the release notes say how much (on our test prompt it scored 4.5 of 5 against the plain file's 5). Every expert read exactly is about 5 tok/s.

No squeezing on your Mac this time: the squeezed file is on Hugging Face (29 GB, sha256 in the README), made with the same tool that ships in the install, and reproducible byte for byte. Download it, download the tokenizer, one start line, the chat opens in your browser. It also speaks the OpenAI API on localhost, so Aider and friends work.

One line installs it, no Rust, no compile. It listens only to programs on your Mac and sends nothing anywhere. gpt-oss-120b, Qwen3.5-122B and the 35B run too.

Repo, with every number and how it was measured: https://github.com/1picassoai/coachwhip

I'd really like to hear from anyone with a different Mac, especially M1 to M3 or macOS 15. Slow, hot, fan going, install fell over: say so and I'll fix it.


r/Qwen_AI • • 1d ago

Discussion Qwen Help?

Post image
0 Upvotes

Hey there! Quick question - what are the daily usage limits for the Go, Plus, and Pro plans on Qwen?


r/Qwen_AI • • 17h ago

Discussion Solo owners, how many AI subscriptions are quietly renewing on your card this month?Vresk is my company's answer to that, and yes, I'm the marketing director, so factor that in. It's one workspace for open models. Your notes, history and memory live in your workspace, not inside whichever model an

0 Upvotes

Solo owners, how many AI subscriptions are quietly renewing on your card this month?

Vresk is my company's answer to that, and yes, I'm the marketing director, so factor that in. It's one workspace for open models. Your notes, history and memory live in your workspace, not inside whichever model answers, so switching doesn't mean re-explaining your business from scratch. On Plus it also does research runs and decks you can export to PowerPoint.

Free to try. Anyone who gives it a go on real work, we'd be so grateful. What would a one-person business need from it that I haven't mentioned?

https://vresk.ai


r/Qwen_AI • • 1d ago

Help 🙋‍♂️ Image generation via Qwen Image 3 is not working

Post image
1 Upvotes

I use Qwen (formerly Qwen Studio) daily and haven't had any issues. They introduced paid tiers, and I purchased the Plus plan. For the past three days, I’ve only been able to generate images using Qwen Image 2, while Qwen Image 3 triggers an error.

As you can see in the screenshot, the prompt is completely safe. I’ve already emailed support.

Is anyone else experiencing this problem?


r/Qwen_AI • • 1d ago

Help 🙋‍♂️ I’m doing testing for an open-weight model aggregator and looking for help

1 Upvotes

Hey guys,

I'm working on an ad-supported tool that lets you use open-weight models completely free, with no usage caps. It’s still very early in development, so things will be rough around the edges, and I'd love feedback.

I’ve incorporated:

Laguna XS 2.1
Laguna S 2.1
MiniMax M3
GLM 5.3 Flash
GLM 5.3
Qwen3 32B

If you're up for trying it and sharing your thoughts on bugs, speed, output quality, or which models you'd want added, send me a DM and I'll get you access.

Thanks!


r/Qwen_AI • • 2d ago

News The Silicon Hippocampus: We Built Persistent AI Memory with Physical KV Cartridges, a RAM Recall Engine, and SSD Storage [Frozen Qwen2.5-7B]

Thumbnail
gallery
11 Upvotes

We built a memory architecture in which a frozen language model can write its own internal attention states to disk, find them later through a RAM-based recall engine, and use them to answer questions without reading the original information again.

Not a saved conversation. Not a text database. Not fine-tuning.

A physical memory system built around the model's own internal representations.

We call it AKBASCORE MAM v1.3.0 — The Silicon Hippocampus.

The basic idea is straightforward: the model forms the memory, the SSD stores it, RAM finds it, and the frozen model recalls it.

The four figures above document the complete process, from memory formation to measured retrieval.

Fig. 1 — The Silicon Hippocampus: the complete memory architecture

Figure 1 shows the relationship between three components.

WRITE converts information into the frozen model's own attention key/value states.

SSD preserves those states as independent physical memory cartridges.

READ uses a geometric addressing engine in RAM to locate the appropriate cartridge and restore it to the model's attention cache.

The distinction matters. The SSD does not hold a collection of text passages waiting to be pasted into a prompt. It holds the model's previously generated K/V states. RAM does not need to load all 1,453 cartridges into memory; it maintains the address index and native representations required to find the relevant file.

Think of the SSD as a long-term memory archive: it preserves experiences even when the model is no longer actively processing them. The RAM-based engine plays the role of associative recall — given a cue, it finds which stored memory should be brought back into active use. In this implementation, roughly 399 MB of index and native-vector data support that search across 1,453 physical memories. This is a functional analogy, not a simulation of brain anatomy.

The model's weights remain unchanged throughout.

Fig. 2 — WRITE: turning information into a physical memory cartridge

This is where the memory is formed.

The frozen Qwen2.5-7B-Instruct model reads a fact once. Its lower-layer attention states are captured, and the layer-3 hidden state is used in a second forward pass to construct the remaining K/V states.

The resulting CUT3 cartridge contains 56 bfloat16 tensors across 28 transformer layers.

Each cognitive cartridge is the computational equivalent of a stored memory trace: not a sentence to reread, but a preserved internal state that can be reactivated. In the human-memory analogy, the cartridge is the memory trace, while the SSD is the archive that keeps it.

That cartridge is saved as an independent .pt file, with a SHA-256 entry in the storage manifest.

In the published experiment, the system created 1,453 physical cartridges occupying 3,973,450,961 bytes, approximately 3.97 GB.

Figure 2 also shows something important: during the live demonstration, the system reconstructed one cartridge from its original fact and compared the resulting 56 tensors against the previously stored file.

All 56 tensors matched bit for bit.

The model reproduced the same physical memory representation without modifying its weights.

Fig. 3 — READ: RAM finds the memory, SSD supplies it, the model answers

Now comes the other half of the architecture.

The model receives a question, not the original fact.

Its native layer-3 question representations are projected into a PCA128 address space. FAISS IVF128 searches the indexed positions, TOP2 narrows the candidates, and the locked PEAK50 rule selects the best cartridge.

In the live example:

1,453 physical cartridges → 103 touched cartridges → 16 candidates → one selected file.

The selected cartridge is verified against its SHA-256 manifest, loaded from the filesystem and installed into the frozen model's attention cache.

This is the recall moment: a question acts as the memory cue, the RAM engine identifies the relevant trace, and the SSD supplies it for reactivation inside the model. The system does not search for a written answer; it searches for the internal state from which the frozen model can generate one.

The model then answers using the question template and the restored K/V state. The original fact text is not inserted into the prompt again.

Figure 3 shows the actual ranking of all 16 candidates, including the winning cartridge #0292.

A negative control was also performed: the same question was answered using the second-ranked cartridge instead. It did not produce the expected answer.

This demonstrates that the selected memory state matters to the observed response, rather than the question alone being sufficient in that test.

The live run measured 27.9 ms for addressing, 19.4 ms for verified loading and 249 ms for answer generation on an NVIDIA A100 40 GB. These are separately measured stages, not a claimed end-to-end latency.

Fig. 4 — RESULTS: what the system actually achieved

Figure 4 separates three different evidence sources: the current runtime's startup acceptance, the archived TEST627 record and the newly executed live demonstration.

The startup acceptance evaluated 48 synthetic facts with two question formulations:

Original wording: 48/48 correct cartridge selections and 48/48 correct answers.

Alternative wording: 48/48 correct cartridge selections and 48/48 correct answers.

96/96 correct selections and answers across the two formulations.

The live demonstration independently re-executed the WRITE operation for its selected case, verified the physical cartridge, reproduced the READ selection, loaded the correct file and generated the expected answer.

The complete audited live pipeline took 2.787 seconds, including integrity verification, memory reconstruction and a negative control. This is not a normal inference-throughput measurement.

The panel is a confirmation test using two formulations of the same 48 synthetic facts, not an independent blind holdout. PEAK50 was selected after the preceding calibration experiment. New-fact blind validation is the next research step.

Why this architecture matters

Most retrieval systems store information outside the model as text and return that text to the prompt when needed.

AKBASCORE MAM explores a different boundary.

The persistent object is the model's own K/V state.

The retrieval address is derived from the same frozen model's internal representations.

The selected memory is restored directly to the attention cache.

This separates memory formation, persistent storage, associative addressing and memory-conditioned generation into distinct operations.

The architecture does not require modifying the model's learned weights, training an external embedding model or running a separate vector-database service. It does use an in-process FAISS index and native-vector data in RAM.

The current implementation is a measured proof of this architecture on Qwen2.5-7B-Instruct, not a claim that all forms of AI memory have been solved.

Reproduce the experiment

The complete implementation, live logs and technical report are public.

(DOI: https://doi.org/10.5281/zenodo.23311350)

AKBASCORE MAM v1.3.0 — The Silicon Hippocampus

[Complete Source Code (Single-Cell Version): https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/HIPPOCAMPUS_full.py

Original Execution Log: https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/Hippocampus.log

Three-Part Version (For Users Running the Demo from a Phone):

Part 1: https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/HIPPOCAMPUS_part1.py

Part 2: https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/HIPPOCAMPUS_part2.py

Part 3: https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/HIPPOCAMPUS_part3.py

The report contains the mathematical definitions, physical cartridge construction, storage measurements, retrieval algorithm, source integrity checks and the four technical figures.

The next experiments will address preregistered blind retrieval, additional fact types, consumer hardware and larger cartridge pools.

The central engineering result is already observable: a frozen language model formed a physical memory, the system stored it outside the model, located it through RAM-based associative addressing, and restored it to answer a question without replaying the source text.


r/Qwen_AI • • 1d ago

LLM Qwen3.8_27b on 8gb vram and 48gb ram?

0 Upvotes

Hi, I have bee. Trying to run different quantization of Qwe n3.8_27b from different sources/repo and am successful in that but the issue i am facing is:

  1. Extremely low tok/s which is ~ 3-4 tok/s at max after tuning different model loading parameters.

  2. Onlt highly diluted model are able to run on my laptop (btw gpu is Nvidia RTX 4060 8gb vram)

I am curious to know, Does anyone with similar system config been able to run Qwen3.8-27b ? If yes, what quant did you use and what output/decode tok/s you are achieved?


r/Qwen_AI • • 2d ago

Discussion IMO Qwen3.8-Flash-Next/Strata/Pi is the best local agent today.

87 Upvotes

EDIT.: Someone pointed be to Basalt (Thanks): https://github.com/jesdga95/basalt
And if you are on linux, it's even better than Strata. 1.8x faster on my setup with no loss on quality.
-----------

I'm using Qwen3.8-Flash-Next on Strata with pi as the harness. I'm testing it's quality and speed on the airbench test suite.

I'm curious if someone has tryed something similar and reached similar conclusions.

MORE DETAILS:

Hardware needed to reproduce:

One NVIDIA GPU with 24 GB or more, about 64 GB of system RAM or more, and 90 GB of free disk. RAM is the real limit: the IQ3_S quant keeps about 50 GB of experts in RAM. On my 64 GB machine it works but is tight: about 5 GB stayed free during the runs, with a little swap use. Strata's own estimate for IQ3_S at a 256k context is about 78 GB.

Model server setup (Strata)

Model: ISTA-DASLab GSQ-RCO quantization of Qwen3.8-Flash-Next, IQ3_S (3.5-bit). Strata downloads it (about 84 GB) on first start.

  1. Build the image once (I used commit 99f3dbd; CUDA_ARCHITECTURES is 120 for a 5090, 86 for a 3090):git clone https://github.com/Niko1221/Strata cd Strata git checkout 99f3dbd docker build -t strata:99f3dbd --build-arg CUDA_ARCHITECTURES=120 .
  2. Run it with the IQ3_S quant and a 256k context:docker run -d --gpus all --net=host --shm-size=8gb --ulimit memlock=-1 -v /path/to/strata-data:/data -e HOST=127.0.0.1 -e PORT=9000 -e FAMILY=qwen -e MODEL=IQ3_S -e CONTEXT=262144 -e VISION=yes --name strata strata:99f3dbd

It serves an OpenAI-compatible API at http://127.0.0.1:9000/v1, model id qwen3.8-flash-next-iq3_s. Everything else is Strata's default. The engine flags its setup picked:

--expert-cache auto --prefill auto --spec 4 --spec-min-p 0.5 --mtp /data/mtp/rt --max-context 262144 --kv int8 --vision --vram-reserve-mib 700

Harness setup (pi)

pi version 0.73.1 (npm package u/mariozechner), run in a node:22-bookworm-slim container, non-interactive:

pi -p --mode json --model qwen3.8-flash-next-iq3_s "<the airbench checkup prompt>"

pi's config directory (PI_CODING_AGENT_DIR) has two files.

models.json:

{"providers": {"local": {"baseUrl": "http://127.0.0.1:9000/v1", "api": "openai-completions", "apiKey": "sk-local", "compat": {"supportsDeveloperRole": false, "supportsReasoningEffort": false}, "models": [{"id": "qwen3.8-flash-next-iq3_s", "reasoning": true, "input": ["text", "image"], "contextWindow": 262144, "maxTokens": 32768}]}}}

settings.json:

{"defaultProvider": "local", "defaultModel": "qwen3.8-flash-next-iq3_s", "quietStartup": true, "compaction": {"enabled": true, "reserveTokens": 65536, "keepRecentTokens": 20000}}

Two settings differ from pi's defaults: a 32k output cap, and a 64k compaction reserve (with pi's default 16k, one image result could push the prompt past the window).

Running the benchmark

I've compared this setup with >100 config, testing both quality of the output and speed.
(I didn't found the config initially someone share it with me on my benchmark website, reproduced the results and can confirm it's a good one)


r/Qwen_AI • • 2d ago

Resources/learning Flash-Next found the upstream PR that GLM's 753B missed. On a tablet

Post image
29 Upvotes

tldr: a 125B decoding every token on a tablet found the upstream PR that a cloud 753B missed, at both effort levels. It covers about 95% of my cloud calls. Receipts in the repo.

One real timeshift error, eight runs, six of them cloud. The only model to find the already open upstream PR was the local Flash-Next. Both times it ran.

It's a joy to use and underrated. The hardest few percent still goes to GLM 5.3 or Opus, and I'm fine with that split.

What daily driving it taught me, in the order each lesson bit:

  • Thinking budget is everything. The rap on Flash-Next is that it thinks too much and won't stay steered. Its chat template ships at the highest effort by default, so some of that is people running the default. At medium it outhunts bigger models at max, and max just buys more source-level proof for the same conclusion.
  • The taste check. Eight runs, one real timeshift error, all healthy. Same harness, cloud at max: flashx 2m41s, the 753B 8m30s, flash 9m09s. Mine: 2m55s at medium, 8m31s at max.
  • A GLM model picked the qwen answer. When I had flashx rate both results, it went qwen. (I did not argue.) All eight runs side by side.
  • My harness pays its rent. My 194k session compacts on a tiny sidecar in 50s. Search lands the right file first try. Crash recovery survives a killed server.

I expected cloud to lap it, and twice something did. In opencode, flashx finished in 1m30s at ~150 t/s next to my 45-50, and its answer was still the shallow one: no repro, no PR. The other opencode run was faster and wrong. Matched harness, GLM at max: 14 seconds over my medium run, one over my max. A 125B on a 70W tablet holding a 753B to that still impresses me. The PR was not a tie: mine found it both times, nobody else found it at all.

Honest numbers: 64 tok/s best case, 45-50 sustained at 70W, a couple less at 50W and under 75C. MTP draft acceptance 90-100% across counting, code and reasoning work. First token in ~0.03s.

All of this runs on a pi coding harness I built and open-sourced: one command installs it, uninstall undoes it. No Strix Halo? setup.sh --no-halogen wires it to your own providers, any model, cloud or local.

Has Flash-Next beaten your cloud model on anything yet? Mine's the weird tablet, a Flow z13 with 128GB.


r/Qwen_AI • • 2d ago

Benchmark A CUDA megakernel built for Qwen3.8-27B: 140 tok/s on one RTX 3090, KL divergence 0.0009 vs llama.cpp

31 Upvotes

I've been using Claude Opus 5.5 to speed up Qwen3.8-27B on my PC (RTX 3090). It wrote a CUDA megakernel built for this one model that is 1.4-1.9x faster than llama.cpp, depending on the task and context length.

Code and full benchmarks: https://github.com/L-Forster/open-jet/tree/master/megakernel

How it uses the model

Qwen3.8-27B ships with an MTP block for speculative decoding. The megakernel runs each whole speculative-decoding cycle in one kernel launch: the main model over the drafted tokens, verification, then the next MTP drafts. Checking 4-5 drafted tokens costs about the same as checking one.

Speed (same 3090, megakernel vs llama.cpp with MTP)

  • Writing code: 140 vs 73 tok/s
  • Reasoning mode: 78 vs 51 tok/s
  • With 30K tokens of code in context: 73 vs 52 tok/s
  • Prompt processing (prefill): ~1,600 vs ~1,100 tok/s
  • With speculative decoding off they are about equal (42.9 vs 40.4). llama.cpp ran at 2 drafts, the megakernel at 4.

Accuracy vs llama.cpp

No measurable loss in quality:

Context Positions MK top token MK KL LC top token LC KL
1K 13,299 99.08% 0.0009 98.68% 0.0019
30K 1,999 99.65% 0.0007 99.35% 0.0009
96K 1,999 99.60% 0.0008 99.45% 0.0014

MK = megakernel, LC = llama.cpp batched. Top token = how often the top token matches the reference. KL = mean KL divergence in nats.

  • Perplexity (1K run only): megakernel 2.4274, llama.cpp batched 2.4283, reference 2.4263.
  • Speculative decoding is exact: greedy output is the main model's greedy choice, and sampling keeps the same distribution as without drafts.

Quantisation support

This table details the quantisation support, with unsloth Q4_K_M being the native model and what I benchmarked, lmstudio and mradermacher being semi-compatible, not fully benchmarked, tentative results show similar speed to native after type conversions. Other quants fall back to llama.cpp

Qwen3.8-27B file Runs on
unsloth's original Q4_K_M (what openjet setup downloads) megakernel
Q4_K_M from lmstudio-community, mradermacher megakernel, semi-compatible
Other quants (unsloth UD-*, bartowski, GSQ-RCO and others) llama.cpp

Limits

  • Single GPU. RTX 30/40/50 series with 24 GB or more. It has only been tuned on a 3090.
  • 147K context runs on a 3090 (fp16 KV cache to ~80K, using q8 above).

Contributions that would help

  • Support for other quantisations of Qwen3.8-27B.
  • Tunes for specific hardware: RTX 4090, 5090 and other 24 GB+ cards.
  • Please include benchmarks with the PR: your GPU, and bench/bench.py or bench/code_bench.py numbers before and after.

Comment the quant you use for Qwen3.8-27B so I know what to add support for next! (also planning for Qwen 4 when that drops).


r/Qwen_AI • • 2d ago

Discussion PXA for Qwen on old Teslas: faster than mainline and ik on P100/V100, Flash-Next bigger than your VRAM, PXQN quants, and a browser control panel

Thumbnail
gallery
6 Upvotes

I'm the dev of PXA. It started as a fork, and it's now its own engine built for Pascal and Volta cards: Tesla P100, V100, P40, 1080 Ti. Here's what you get over mainline llama.cpp and ik_llama, with Qwen as the main target.

Speed where old cards are weak

  • Prompt reading on 2x P100 at 3K tokens: 338 t/s, vs 209 for mainline and 133 for ik (our quant against their MXFP4; part of that is the quant, and our repo documents the same-quant comparison too).
  • P100 kernels that use its fast FP16 instead of falling back to slow paths, and V100 attention that skips masked work.
  • Tensor split on by default for matched card pairs, with a fused reduce, so two cards scale instead of taking turns.
  • MTP speculative decoding, on by default, tuned per model and per card.

Run models bigger than your VRAM: Overdrive

  • Mixture-of-experts models keep their hot experts on the GPU and stream the rest from RAM. It learns which experts you actually use.
  • Qwen3.8 Flash-Next: about 31 t/s on one P100, 38-40 on two, 35-39 on one V100, 55-58 on two V100s. Same single P100 vs Strata: faster on prose and on prompt reading, a tie on code.
  • The exact 32 GB Flash-Next file we benchmark is free on Hugging Face: https://huggingface.co/poisonxa/Swift-1.5-Qwen3.8-Flash-Next-PXQN-32GB

PXQN quants: the same quality in fewer bytes

  • PXQN2 behaves like a classic 3-bit file at 2-bit size; PXQN4 matches 6-bit quality at 15.7 GB; PXQN5 matches Q6_K in 84% of the space (Qwen3.8-27B).
  • Measured as drift from the original model on the assistant's own replies.
  • Standard GGUF quants still load and run fine.

PXA Control: your whole rig in a browser tab

  • Pick cards and a model, press Start. It chooses the split, batch sizes, context, KV cache and speculation from real measurements, and tells you why.
  • Live speeds and draft acceptance, per-card VRAM, temperature and power, plus a built-in chat assistant with tools that asks before anything risky.
  • One-click "benchmark my rig" to the community leaderboard, a model encoder, and Home Assistant / MQTT sensors.
  • Works on your phone. Run it bare-metal, in Docker or on Unraid.

Get it: step-by-step setup at https://setup.pxanetwork.com · free download on GitHub: https://github.com/poisonxa16/pxa · Discord: https://discord.pxanetwork.com

Numbers are from our own bench (16 GB cards on PCIe 3.0 x4 risers). Yours will vary, so post them, good or bad.


r/Qwen_AI • • 3d ago

Image Gen I quantized Qwen-Image 2.1 Turbo and Uncensored it

Post image
320 Upvotes

Qwen released Image-2.1-Turbo this week and the first GGUFs on the hub were plain conversions, so I made AD (Atomic Dynamic) quants for stable-diffusion.cpp and checked how far each one drifts from the original picture

every file renders the same 48 prompts and seeds as the BF16 weights on an A100, then gets compared with LPIPS, where lower means closer to the original

file size LPIPS vs BF16
Q8_0 7.59 GB 0.037
AD-Q6_K 6.71 GB 0.044
AD-Q5_K 5.40 GB 0.076
AD-Q4_K 4.20 GB 0.147
AD-Q3_K 3.60 GB 0.206
AD-Q2_K 2.55 GB 0.359

Q8 and AD-Q6 stay very close to the original, the difference starts to be noticeable at 4 bits, but not by much, a plain llama.cpp Q4_K sits at 0.187 so AD-Q4_K is 21% closer for 150 MB more

I also uncensored the text encoder by removing its refusal direction, it now refuses 1.2% of filtered prompts instead of 88.9%, it comes in the same AD sizes from 3.3 GB to 16.4 GB here https://huggingface.co/AtomicChat/Qwen-Image-2.1-Turbo-Uncensored-GGUF

files, renders and scores are all here Quants on Hugging Face

setup: stable-diffusion.cpp on an A100 80GB, I work on atomic.chat and these are our quants, so any feedback is cool


r/Qwen_AI • • 2d ago

Resources/learning Qwen3.8-Flash-Next on DGX Spark: 86 tok/s single stream at default settings on 2x Spark (TP=2), 195 tok/s at 8 concurrent

5 Upvotes

I've been running Qwen3.8-Flash-Next (NVFP4) on two DGX Sparks as my daily coding model, and I packaged it as two open sparkrun recipes, one for 1x Spark and one for 2x Spark (TP=2).

Numbers, all on my boxes, mean of 3 boots per setup (1x: 3 boots on each of my two Sparks), sd between boots in brackets. "Defaults" is what the server ships with: T=1.0, top-p 0.95, top-k 20, thinking on, reasoning effort medium, llama-benchy ISL/OSL 2048/512. "T=0 coding" is 36 coding prompts (Python, C++, Rust, Go) with thinking off, which is the best case for MTP.

x 2x Spark TP=2 (v2.0.0) 1x Spark (v2.2.0)
TG c1, defaults 86 tok/s (2.4) 60 tok/s (3.2)
TG aggregate c8, defaults 195 tok/s (5.1) 137 tok/s (3.3)
TG c1, T=0 coding 113 tok/s 75 tok/s
TG aggregate c8, T=0 coding 317 tok/s 192 tok/s
TTFT, ISL 16K, cold prefix 5.6 s 8.2 s
Context 262K 262K
Hardmode tool-use score (pass >= 88) 90/100 93/100

For comparison, the model publisher's own vLLM image for DGX Spark (karmic-kraken-beta-spark-20261007) with its two-Spark preset unchanged, on the unmodified NVFP4 checkpoint, same cells, also 3 boots:

Publisher image, 2x Mine, 2x TP=2 Ratio
TG c1, defaults 51.8 86.3
TG aggregate c8, defaults 96.6 195.3
TG c1, T=0 coding 63.1 112.8
TG aggregate c8, T=0 coding 226.4 317.4

Plain upstream vLLM v0.31.0 did not boot this model on GB10 in my test.

Quality: the checkpoint is my own requant of the NVFP4 release (GDN projections re-quantized with an MSE scale search) plus a retrained MTP drafter. IFEval (all 541 prompts, served settings, thinking on), mine vs the publisher's image above: prompt-level strict 87.4% vs 87.1%, loose 90.2% vs 89.8%, no significant difference (paired McNemar p = 0.88 and 0.87). Same result against the original GDN tensors inside my own stack (88.9% vs 87.6% strict, p = 0.35). So the speed does not cost instruction-following quality. Every release also passes a fixed gate: tool-use hardmode >= 88, 20/20 long-context retrieval at every depth up to 128K, no stragglers at c8-c16. Every number in the README links to its raw files.

If you run many agents rather than one chat, the README also covers the other way to use two Sparks: two independent 1x replicas behind a small router (DP=2). It wins at c8 and above (241 tok/s at c16, agent replays 29-37% faster). TP=2 wins at c1 to c4 and on KV capacity.

Under the hood:

  • vLLM with b12x kernels for GB10, NVFP4 experts, MXFP8 for the dense layers at large batch, plus my own kernel changes (deferred GDN checkpoints on the speculative path, an M-dispatch for MXFP8 at large batch).
  • MTP with 4 probabilistic drafts. I retrained the drafter against the quantized model that actually serves; the second round (v2.2.0) adds about 2% on top of the first.

Two Sparks:

sparkrun registry add https://github.com/ursuciprian/qwen3.8-flash-next-dgx-spark-tp-2
sparkrun run qwen3.8-flash-next-2x-dgx-spark

One Spark:

sparkrun registry add https://github.com/ursuciprian/qwen3.8-flash-next-1x-dgx-spark
sparkrun run qwen3.8-flash-next-1x-dgx-spark --hosts <spark> --solo

First start downloads about 140 GB per Spark; after that a start takes about 3 minutes. The very first boot on a new host takes about 5 minutes (298 s measured) because some compiled kernels are rebuilt once. Prerequisites (kernel version, linger) are in the README quick start. OpenAI-compatible endpoint, so OpenCode, Continue and other OpenAI clients work.

If you have a Spark or two, run it and tell me your numbers, your workload, and anything that breaks (tool calls, clients that send reasoning_effort values the template rejects, long-context problems). GitHub issues or comments here both work. Numbers from boxes with a different kernel or driver than mine help the most.

Qwen4 is coming, and I plan day-0 recipes for it as well.

Repos:


r/Qwen_AI • • 3d ago

News AKBASCORE MAM: Breaking the Text-Context Paradigm Third Model, DeepSeek-V2-Lite-Chat (MLA)

Thumbnail
gallery
4 Upvotes

Zenodo doi https://zenodo.org/records/23287752

AKBASCORE MAM has now been implemented on three different Transformer model families. The principle is simple: read information once, write it into numerical memory, consolidate it, and answer questions later without feeding the original source text back into the model (source-free numerical memory, append-only consolidation).

This is the third experiment. I recommend following the first two in order, because understanding how we got here makes the DeepSeek implementation much easier to follow.

Mistral — mistralai/Mistral-7B-Instruct-v0.3 (DC6): https://www.reddit.com/r/Qwen_AI/s/cPpOODl3FP

Qwen — Qwen/Qwen2.5-7B-Instruct (DC3): https://www.reddit.com/r/Qwen_AI/s/p2G71rqG8u

DeepSeek — deepseek-ai/DeepSeek-V2-Lite-Chat (MLA, DC3): this post.

Each experiment includes its own numerical memory heatmap. You can compare all three by opening the posts in sequence. I'll also add a Markdown comparison table in the comments.

Here is what changed between the three models:

Mistral: 32 layers, 93 memory tokens, 11.62 MiB, 72/72 correct. Numerical intervention at layer 6 (H6 injection), with consolidation through layers 7–31.

Qwen: 28 layers, 82 memory tokens, 4.48 MiB, 72/72 correct. Intervention at layer 3 (H3 injection), with consolidation through layers 4–27.

DeepSeek: 27 layers, 87 memory tokens, 2.58 MiB, 69/72 correct. Intervention at layer 3 (H3 injection), with consolidation through layers 4–26.

The biggest architectural difference is DeepSeek's Multi-head Latent Attention (MLA).

Mistral and Qwen use conventional key/value attention caches (K/V). DeepSeek stores a compressed 512-dimensional latent component (c_KV) and a separate 64-dimensional rotary key (k_R). Its heatmap therefore looks different because we're measuring different internal representations.

The dark blue vertical bands in DeepSeek's heatmap appear inside the shared 28-token instruction prefix, not at cartridge boundaries. They represent relatively low numerical norms, not evidence of broken memory.

DeepSeek answered 69 of 72 questions correctly. The three failures are documented and reproduced in TEST597. We haven't established a verified fix, and the heatmap alone doesn't explain those failures.

The 2.58 MiB footprint is also worth noting, but it reflects DeepSeek's compressed MLA cache architecture, not a directly measured compression gain produced by MAM.

Three models, three architecture-specific implementations, and the same underlying mechanism. Model weights remain frozen throughout.

The results don't establish universal compatibility. They demonstrate that the numerical-memory consolidation principle can operate across three different Transformer implementations under the tested conditions.

Full executable DeepSeek code: https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/Deepseek_full_code_demo.py

Actual DeepSeek execution log: https://github.com/ceceli33/titan-cognitive-core-v2/blob/main/Deepseek_demo.log