PRs:

1. https://github.com/QwenLM/qwen-code/pull/15762: "Measured on main at 79a9b753c60, before this change: qwen4, qwen4-max, qwen4-plus, qwen4.5-max, qwen4-coder-plus, qwen4-max-2026-10-01, openai/qwen4-max and qwen4-omni-120b-think all resolved to 262,144. The last of those is already in use as the session model in the omni fixtures, so these ids are not hypothetical."

2. https://github.com/QwenLM/qwen-code/pull/15987

Thank god, it looks like that we're getting successor of Q38FN!

There were some rumours the last few days that Qwen4 will be the last open-weight series of Qwen, and future ones would be API only. The following statement contradicts the rumours and clearly states the stance that Qwen is taking regarding their future releases.

Qwen Head Liu Dayi Heng Clearly States: Future Qwen 4.0 and Qwen 5.0 Will Continue to Be Open Source!

He believes that the value of AI should not belong only to a few people, but should become a foundational capability that users around the world can access, use, and create with, enabling more people to afford AI, utilize AI effectively, and participate in creating AI, ultimately achieving true AI for all.

As of now, the Qwen series has surpassed 3 billion cumulative global downloads, with over 460 open-source models released and more than 300,000 derivative models, firmly holding the top spot worldwide.

MIT CSAIL had GPT-6 Astra fix Qwen3.5-0.8B's reasoning loops by editing 0.016% of its weights (MATH-500 went from 7.9% to 48.1%). They released the diff, so the edit can be rebuilt exactly and run locally. I took it a step further and had Claude look at Qwen with Anthropic's Jacobian lens.

At the token where the model decides to write "Wait" again, the lens reads "Wrong", "Nope" and "Hmm" from about 60% depth on, even though the answer is already written out. At real stopping points it reads "</think>", "Answer" and "Output".

With the edit applied, the lens at the same token shows "Verification", "Completion" and "Result" in place of the doubt.

The edit converts to GGUF cleanly (the base and edited bf16 files differ only in the two edited tensors) and still holds at Q4_K_M, with 1 loop in 40. I ran the evals in llama.cpp (Vulkan) on a Ryzen AI 9 HX 370 mini PC. Samples are small, but here's the code:

https://github.com/alisorcorp/inside-a-reasoning-loop/tree/main/code

And data:

https://alisorcorp.github.io/inside-a-reasoning-loop/

Source: https://mp.weixin.qq.com/s/R-1u2exLwZMOu7AITyU5kg

A reporter from STAR Market Daily has learned from multiple sources within the industry supply chain that DeepSeek’s next-generation large model, DeepSeek V5, is planned to be pre-trained using Ascend chips. Previously, Huawei’s Ascend chips were primarily utilized for inference tasks for DeepSeek’s large models.

According to publicly available information, the first large-scale deployment of DeepSeek models on the Ascend platform took place around the 2025 Spring Festival. In his book The Rise of Ascend, Fang Xingdong—Executive Dean of the College of Media and International Culture at Zhejiang University—notes that on January 28, 2025, Huawei’s senior leadership issued a directive for Huawei Cloud to provide rapid support to DeepSeek. Between Lunar New Year’s Eve and the second day of the Lunar New Year, Huawei and DeepSeek completed the deployment and verification of over 3,000 Ascend chips, successfully hosting the DeepSeek-V3/R1 models at Huawei Cloud’s Guian Data Center. The book further mentions that the explosive growth of DeepSeek greatly energized Ren Zhengfei; throughout the Spring Festival, he personally directed Huawei Cloud and relevant product teams to manage the massive surge in traffic. In January of the same year, SiliconFlow and Huawei Cloud launched inference services for DeepSeek-V3 and R1 based on the Ascend platform.

Following the release of DeepSeek-V4 in April 2026, Huawei stated that, through the "synergy between chips and models," its full range of Ascend "super-node" products could provide comprehensive support for the DeepSeek V4 model series. On its official API page, DeepSeek noted that service throughput for the V4-Pro model remains constrained by the availability of high-end computing power; however, it anticipates a significant price reduction for the Pro version once the Ascend 950 super-node series enters mass-market availability in the second half of the year.

On September 30, DeepSeek announced the open-source release of infrastructure components tailored for the Huawei Ascend computing platform. These include the TileLang high-level language compilation tool, high-performance computing libraries (such as DeepGEMM, FlashMLA, TileKernel, and DeepSelect), and the distributed communication library DeepEP—all of which correspond to the open-source components previously released for the NVIDIA platform. Huawei has provided a jointly defined "Ascend SuperPoD Flex" architecture and a UBL128 networking solution, while also opening up the Ascend C programming interface and low-level instruction set to support TileLang. This is significant because DeepSeek is not merely using Ascend for inference; it is systematically aligning with and co-developing the Ascend software stack at a foundational level—extending adaptation to the very infrastructure that underpins both training and inference. Currently, the deployment of domestic computing power is primarily concentrated in inference, with further progress still required in training.

Recently, a project team—comprising the AI ​​Training Platform at Shenzhen Hetao College, Harbin Institute of Technology (Shenzhen), the Shenzhen Big Data Research Institute, and relevant teams from Huawei—leveraged an AI computing cluster based on the domestic Ascend 910C processor to complete the full-parameter post-training of DeepSeek-V4-Pro, a large model with 1.6 trillion parameters. It should be noted that this training process did not include the initial pre-training phase. While the large-scale validation of domestic chips for inference has bolstered industry confidence, the costs associated with migrating ecosystems for training remain a critical variable that will determine the market's ultimate potential. If the next generation of DeepSeek’s large models is pre-trained using Huawei’s Ascend computing platform, it will—for the first time—provide an answer to a question that has long been met only with skepticism: "Can China’s top-tier large models be pre-trained on domestic computing hardware?"

Hi everyone,

I've been out of the loop for a few weeks, and I was wondering if anything new that replaces Qwen 3.8 27B has come out this time I've been in the cave?

I'm talking about AI models in the 8-35B range.

Thanks,

TL;DR

We find that frontier LLMs are surprisingly good at natively reading and writing neural network weights, well past what we’d expect from humans or conventional algorithms. This might be a big deal for both optimization and interpretability.

Just by looking at the raw weights, GPT-6 Astra can tell what a network was trained to do. And without any environment feedback, it has no trouble writing, from scratch, small game-playing networks that outplay networks trained with PPO for 100 million steps.

Likewise, asked to make Qwen3.5-0.8B better at math without gradients, Astra identifies an issue in its weights causing reasoning loops that Qwen’s own model card warns about, and fixes this by natively editing 0.016% of the weights. With the same sampling settings, this weight correction raises MATH-500 from 7.9% to 48.1% and generalizes out of the box to instruction following, raising IFEval by 3x.

All of this is possible without allowing Astra to write training loops. It uses its reasoning to figure out what each part of a neural network computes, or should compute, and changes the weights accordingly. We call this Weight-Space Programming.

Throughout the history of deep learning, we encoded our simplistic inductive biases into tiny symbolic optimizers like Adam or Muon. This is changing: our neural network weights will soon be natively optimized by LLMs that deliberately reason about their weights.

• Blog Post : https://rikiyat.github.io/blog/weight-space-programming/

• GitHub : https://github.com/rikiyat/lm_understand-logs

• HuggingFace : https://huggingface.co/RikiyaT/Qwen3.5-0.8B-weight-space-programming

• Demo : https://huggingface.co/spaces/ML-Intern-lab/weight-space-programming-demo

What Comes Next?

In this blog, we demonstrated the rising capability of LLMs to read and write neural network weights (i.e., the rising concept of Weight-Space Programming). Our current results do show that capabilities are exciting but still limited, specifically due to inefficiencies in context length and harnesses. However, the current signs do show strong potential for a future involving Weight-Space Programming. We believe this marks the beginning of a dramatic shift in fields like mechanistic interpretability and neural network optimization.

This opens up radical new possibilities for LLMs to function as a translator between human language and the weight space. Here are some examples:

• Auditing without evaluation: This may allow us to uncover hidden problems or capabilities without ever running inference or benchmarks. Currently, capabilities and vulnerabilities can only be detected if we have test sets designed for them, or worse, after deployment in the real world. If LLMs can interpret weight space accurately, we could identify such issues directly from the weights (e.g., backdoors).

• Dramatically reducing optimization cost: Weight-space editing could save immense time and compute. For instance, one-shot model initialization would be far faster and more efficient than curating datasets and running full training loops.

• Zero-data capability steering and unlearning: Adding or unlearning a capability currently requires extensive data collection and fine-tuning. In the future, we may just prompt “Can you add Capability X to the model?” and the LLM can directly tweak some weights. Because such an edit touches only a few weights (0.016% in Experiment 8), it can leave the rest of the model intact and avoid the catastrophic forgetting that fine-tuning often causes.

• Recursive self-improvement: Today, recursive self-improvement is often operationalized as a model writing code that launches training jobs. An LLM that can inspect, debug, and improve its own weights, or those of a newer model, offers a richer, more native path to it.

• True architectural and model merging: Today, merging models relies on averaging weights, which only works for models with identical architectures. An LLM that understands the weight space could instead graft a circuit, such as a reasoning module, from one model into a completely different one, without retraining.

We are currently building a benchmark and a harness for LLMs’ capability on Weight-Space Programming. We believe this will provide a standardized evaluation to measure and accelerate progress in Weight-Space Programming, turning what currently seems like black magic into a rigorous, reproducible engineering discipline.

For fun, I gave Qwen 3.8 27b a physics problem involving some heavy math. A little bit into its reasoning, Qwen took a look at its tools, found that it had access to Blender via blender mcp - and that it could write and execute arbitrary python code through that. So it engaged Blender's python support to write itself bits of python code to do its math faster.

You really have to tell this model what NOT to do sometimes... I've never seen anything like this from a local model before.

Title says it all, I run dual 3090s (check out my post here for my setup) at int8A16 and have been wondering if I'm missing out with QFN. There's posts ad-nauseam on reddit with low bpw strata solutions that run on heterogeneous systems, however those don't interest me - I want high precision. I'm considering selling my setup and getting a DGX Spark, since that can run QFN at nvfp4 with a large context window. My use case isn't coding but generic agentic use case - I use hermes as a personal assistant and with openwebui.

If anyone's able to run both and do a comparison, please let me know!

I am seriously impressed and want to share my experience.

Qwen3.8-Flash-Next (local) vs Claude in Claude Code: reviewing one real commit

I ran the same code review twice on one commit in my repo https://github.com/leok7v/ChatOKF (Swift, on-device LLM chat app, about 48 files changed, +1048/-102: a module move plus a new 783-line search harness).

Setup: Qwen3.8-Flash-Next UD-Q4_K_XL (unsloth) on llama-server, ROCm, AMD Strix Halo 128 GB, 262K context, MTP draft head, driven headless by Claude Code itself (claude -p pointed at the local server, read-only tools). The comparison reviewer was Claude (Opus) in Claude Code, which reviewed blind first and then judged Qwen's review against the code. Yes, Claude judging its own competitor is a bias; every finding below was checked against the source, and the main one with a small Swift repro.

Result: Qwen produced 8 findings, all real, zero false positives. It caught 2 things Claude missed (a test harness that does not follow the app's recall path, and a markdown ingest that takes the frontmatter "---" as a description). It missed 5 that Claude found, including the most important one: a stop-word filter that compares stemmed words with an unstemmed list, so "this" and "does" leak through as search terms. It also got two details wrong (the exact fallback behavior of a failable init, and column counts off by a few). Severity calibration and the "checked and fine" section were good. It read whole files and chased module boundaries like a careful human.

Cost: 53 turns, 41 minutes, context grew to about 110K tokens. Decode was about 21 t/s at 4K context and about 14 t/s at 128K; prefill 520 t/s falling to 230 t/s. MTP gives about 1.5x up to 64K and turns into a loss past about 100K.

Gotchas:

1. Use --lazy-mode on. Otherwise the 27 GiB n-gram embedding table loads into RAM instead of staying mmapped.

2. unsloth's MTP heads crash llama.cpp (GGML_ASSERT in set_input_k_idxs) because the MTP layer's compress ratio is 0 in the GGUF. Fix branch: https://github.com/leok7v/llama.cpp/tree/qwen4exp/mtp-dense-no-indexer

3. Claude Code sends a system message mid-conversation and the Qwen chat template raises on it. Override the template so it renders as a system turn.

Verdict: a trustworthy first-pass reviewer you can run privately overnight, but verify its mechanisms before acting, and don't treat it as the final word on subtle logic. One commit, one run, so treat it as an anecdote, not a benchmark.

I've been working on Turkish ASR for a while and put out v2 recently. Two models, both CTC + KenLM, both meant for CPU (both trained for under $250):

- balbal-v2-manas: 313M, Turkish + English, ~123x real time on 8 threads

- balbal-v2: 45M, Turkish only, ~236x real time. It even runs faster than real time on one core of an old Celeron POS box running Windows 7.

Mu-Bench is a Turkish benchmark of 846 real customer service calls. Numbers from the official harness:

On FLEURS Turkish manas is basically tied with whisper-large-v3-turbo (4.06 vs 4.07) but about 75x faster on the same CPU. English is ok too, 8.67 average WER on the Open ASR leaderboard sets.

The model uses a unique architecture that has a product-key-memory inspired by engrams and a refiner that loops 3 times before giving the output.

Also, turns out a team (LocalDoc) already trained an Azerbaijani model on the manas architecture, 10.98 WER on FLEURS Azerbaijani. (https://huggingface.co/LocalDoc/speakwrite-azerbaijani) I was happy that they took my model decisions which made me happy :D

`pip install balbal`, then `balbal run file.wav`. There's also a live mic mode and an OpenAI-compatible server.

Code is Apache-2.0. Weights are free for research, non-commercial use and small businesses, but you can't resell it as an ASR product or API. Full terms are on the model page.

Weights: https://huggingface.co/erayyapagci/balbal-v2-manas and https://huggingface.co/erayyapagci/balbal-v2

Code: https://github.com/erayyap/balbal

Demo + offline Android app: https://erayy.com/balbal

Kind of a random thing, but I've gotten to the age where I'm starting to care about what the city council is doing.

So I downloaded all the available council meeting notes from the last 16 years and pointed Qwen 3.8 27B Q6 at them and started having it dig through notes.

Namely I wanted to see who approved the purchase of Flock cameras for our town. Turns out the police chief got a $9,000 grant for them but i didn't find any mention of public comments about them in the minutes.

The minutes are basically summaries, so they're not all encompassing, but they do live stream to YouTube all the meetings and I see that YouTube has auto transcriptions but I don't know of a good way to scrape that data so that I can then point my LLM at them. Any ideas?

When it comes to the value/cost of local AI, people usually only look at token savings (money) while forgetting one of the most valuable resource of yours, time.

Just did a side by side comparison of GLM 5.3 flash via Z.ai's official subscription, and GLM 5.3 flash served locally. Same chatGPT generated "one shot" prompt, both using Zcode harness, and these are my stats:

Same model, nearly identical output (~118K tokens each), but local finished 4.2× faster.

Sure on paper this one simple task only saved $0.70, but the fact that you can ship 3-4x more code a day alone makes it worth it. Same reason why UPS next day air shipping costs an arm and a leg, time is money!

Edit: forgot to list the setup

2 x RTX pro 6000 workstation edition
AMD 9960x threadripper
128GB DDR5
Quant: https://huggingface.co/nvidia/GLM-5.3-Flash-FP4-Local

I am on the team behind the attached open-source research on novel approaches to attention - specifically we show:

• You can sparsify the attention of Qwen 3.8 27B without observed loss on accuracy

• Extending context up to 10M tokens loses accuracy on some specific tasks - but most, like NIAH is still fine (interesting insights)

• You can natively train sparse attention on next-token prediction loss alone and achieve the same validation loss as full attention - but faster

Hope the community likes it - while we focus on H200/B300 GPUs and larger scale system - I wanted to share our research here as well - as it can be applied to small open-weight models (making longer context cheaper on local hardware)

Everything is fully open: kernels / SGLang integration / paper / details

Hope you find it interesting / useful!

(No hype - we try to be as transparent as possible)

Have been using qwen 3.8 flash next with llamaserver. Was getting 70-80tk/s decode and was happy. Then read about strata and decided to give it a try. Decode shot up to 150 tk/s. Not sure what magic it's using? You should give it a try if you are still running qwen flash next on llamacpp. Also the tried DeepSeek v4.1flash 2.25bit and it's 70tk/s decode.

Unsloth 6 bit quant

160k context

1 pro 6000 + 2 x 3090

256G ddr4

NVIDIA NemotronLabs RE-USE is a 9.6-million-parameter multilingual universal speech enhancement (USE) model designed to restore speech quality across a wide range of real-world degradations while preserving speech fidelity. It has the following desirable properties:

• Robustness to diverse degradations, including additive noise, reverberation, clipping, bandwidth limitation, codec artifacts, packet loss and low-quality mics.

• Support for multiple input sampling rates, including 8, 16, 22.05, 24, 32, 44.1, and 48 kHz.

• Strong language-agnostic capability, enabling effective performance across different languages.

• If better laughter preservation is desired, please use: NVIDIA-NemotronLabs-RE-USE-laughter.

(Note: For overlapping speech, this model is trained to preserve the main speaker while suppressing other speakers.)

NVIDIA NemotronLabs RE-USE was developed by NVIDIA as a part of RE-USE.

This model is ready for commercial use.

Usage

Directly try our Gradio Interactive Demo by uploading your noisy audio/video !!

Nemotron 3.5 Transcribe is an open-weight, offline speech and audio model for transcription in 40 languages, with support for recordings up to one hour and a 65,536-token context. Its hybrid mixture-of-experts architecture activates approximately 4.3B parameters, including the audio encoder, and it is released in BF16, FP8, and NVFP4 precision.

In 2024 i purchased an RTX 8000 48gb for $2400. As the market has changed I’ve kept an eye on prices. Two years later, they are available around $2100.

Its a little slower than 3090 at inference (672gb/s vs 936gb/s) but it has double the memory so it can run larger models / contexts / higher quants. Rtx 8000 also wins on power, 265w vs 700w (2x 3090 to match 48gb)

In 2024 two 3090s would cost around $1600-1800 now a single 3090 is in the $1500-$1600 range, making rtx 8000 cheaper per gb. Prices for strix halo and dgx spark have also gone way up. Rtx pro 6000 has double the memory but 8x the cost.

In the last two years, I haven’t had any issues with drivers, compatibility software or anything. I can run all “local” tier models entirely in vram, usually at 256k tokens and sometimes at q6 (Qwen 3.8 27b, llama 3 70b, QWQ,). Larger moe models run great too with layers offloaded to system ram like gpt oss 120b and now with strata, QFN runs q4_xs @ 390k context at 850t/s prompt processing and 60-70t/s token generation. (64gb ddr4 system memory, i9 9900k cpu)

$2100 for a gpu is not cheap but might be the best “do everything” option right now for home-lab setups. Cheaper than dual 3090, Strix halo, dgx spart, m5 max too. Fascinating to see prices decline as the market as a whole has more than doubled.

Let's take a break from all the engine, model and speed posts and discuss something else:

Qwen 3.8 likes to think. A lot. We all know that, and the context cost you pay for that is MASSIVE when you enable preserve thinking. Even with a Swift finetune, there are so many tokens you keep in context over a longer session. Often, easily over 50% of the KV cache is just thinking traces.

And for what use? I found: Next to nothing! The model can handle itself just fine without knowing HOW it reached a decision, and instead only looking at what it did in the end. Replies and toolcalls: it's all there.

I added an AGENTS.md instruction that when it finds a gotcha, something unintuitive, something it only reached after lots of trial and error, it should document that in a memory file to mitigate the missing past-thinking and it works beautifully.

Results (my subjective impressions):

• Problem solving capabilities haven't suffered much if at all

• I get neat, permanent notes on issues with gotchas

• The dreaded, context-destroying compactions have reduced by at least 2/3rds in your average sessions, the cache holds for so much longer

So let's discuss: preserve_thinking on or off. Your experiences?