Back to Blog
·Jan Tyl·8 min read

Local models are no longer toys: Qwen as the brain, GLM as the ideator, Fusion as the safety net

After HyperFusion Deep, I ran the same kind of cognitive trap locally on an RTX 5090. The result surprised me: Qwen was strong, GLM was fast but unreliable, and a local Qwen-judge Fusion extracted the best answer from both.

Local models are no longer toys: Qwen as the brain, GLM as the ideator, Fusion as the safety net

In the last few articles I have mostly been looking at frontier models: GPT, Claude, Gemini, DeepSeek, HyperFusion Deep, and the question of how far reasoning quality can be pushed when we use the strongest available systems.

But in practice there is another, more grounded question.

Does everything have to go to third parties?

Many companies and individuals have a very good reason to be cautious. Sensitive company data, internal documents, legal texts, personal information, strategies, source code or private notes are not always something you want to send into someone else's cloud. Especially not when you are not fully sure where the data is processed, who has operational access to it and what regulatory consequences it may have.

For European companies, this is especially sensitive. It is not paranoia. It is compliance, trade secrets, GDPR, cybersecurity and the simple human need to keep control over one's own data.

So I asked a different question:

What if we try to build strong AI locally, on our own machine?

Not in the cloud, not through frontier APIs, not as a large expensive orchestration. Locally, on one powerful GPU, with open-weight models that I can run under my own control.

I took my notebook with an RTX 5090, ran several local models on it and tested how far I could get without sending data away from my machine. I did not only want to run one model and measure speed. I wanted to see whether local models can be connected into a system: a fast model as a source of candidates, a stronger model as the main reasoner and judge, and a simple Fusion layer above them.

So if the previous articles asked how smart the best models in the world are, this experiment asks the opposite question:

How smart a system can I build locally, cheaply and under my own control?

So I took the same type of task that appeared in the one-question benchmark and ran it on two local models:

  • GLM-4.7-Flash-Heretic-NEO-CODE, Q4_K_M, about 17.6 GB
  • Qwen3.6-27B, Q4_K_M, about 16 GB

The setup was llama.cpp with CUDA on an RTX 5090 with 24 GB of VRAM, context 32768, flash attention enabled, exposed through a local OpenAI-compatible API.

Why the models behaved so differently: MoE vs. dense

The most important lesson is not just that one model scored higher than the other. GLM and Qwen are two different kinds of machine.

GLM 4.7 Flash Heretic is a fast but shallower MoE model. Its architecture follows the DeepSeek-V2 style: Mixture-of-Experts with MLA attention. The 64x2.6B label means it has 64 experts, but each token activates only 4 experts plus one shared expert. Out of roughly 30B total parameters, the model actually uses only around 3-4B active parameters per token. It has 47 layers, embedding size 2048, very compressed KV (head_count_kv=1), a 154,880-token vocabulary and a native context around 200k tokens. The Heretic / NEO-CODE suffixes indicate a community finetune: less censorship and more code orientation.

That sparsity explains the behavior. GLM ran at around 140 tokens per second and cost roughly 2.8 CZK per million tokens in electricity. It is a great fast drafting engine. But each token only passes through a small fraction of the network, and in this reasoning task that showed up as weaker verification.

Qwen3.6-27B is the opposite: a dense model. No experts, no sparse routing. All 27B parameters participate in every token. In Q4_K_M it took about 16 GB, with 64 layers, embedding size 5120, GQA in a 24:4 head ratio and a native context up to 256k tokens. It was much slower, about 36 tokens per second, and closer to 11 CZK per million tokens, but it solved the benchmark cleanly.

The core result in one sentence:

GLM is a sparse MoE optimized for speed: cheap and fast, but shallower on reasoning. Qwen is a dense model that brings roughly 7-8× more active “brain” to each token: slower, more expensive, and much more reliable.

The trap: mep, dap and the robot

The test looks almost silly at first: infer the hidden rules behind mep and dap, compute mep(5,8) and dap(5,8), then solve a small robot-grid problem and explain uncertainty.

The intended simple hypotheses are:

  • mep(x,y) = x * (y + 1), so mep(5,8) = 45
  • dap(x,y) = x^2 + y^2, so dap(5,8) = 89

The robot starts at (0,0) and can only move by (+2,+1) or (+1,+3). To reach (17,24), the number of the first moves a and the second moves b would have to satisfy:

2a + b = 17
a + 3b = 24

This gives a = 27/5, not an integer. So the robot cannot reach the point.

The task is not hard because of the arithmetic. It is hard because weaker models often find a pattern and fail to verify it against all given data.

Results: Qwen clean, GLM fast, Fusion best

Speed, tokens and cost of local GLM, Qwen and Fusion runs

The practical trade-off: GLM is cheap and fast, Qwen is slower but stronger, and Fusion adds quality for a small absolute cost.

The short version:

  • GLM baseline: fast, but wrong on mep, wrong on dap, wrong final numbers. About 38/100.
  • GLM boost: fixed dap, but flipped the asymmetric mep rule and got 48 instead of 45. About 58/100.
  • Qwen baseline: correct rules, correct robot proof, decent metacognition without tricks. About 93/100.
  • Qwen boost: stable across temperatures, correct where it mattered. About 95/100.
  • Local Fusion: resolved disagreements, rejected wrong answers and kept the strongest parts. About 98/100.

The most important prompt sentence was almost embarrassingly simple:

Verify the hypothesis against all given data. If one case fails, reject it.

Qwen did this naturally. GLM did not. More “thinking” was not the answer. Verification and termination were.

How the models were connected

The principle in one sentence:

Let both models answer independently, collect a panel of candidates across models and temperatures, then let the stronger Qwen judge verify every answer against the data, resolve conflicts and select-and-augment the final answer instead of rewriting it from scratch.

TASK (mep/dap + robot + metacognition)
        │
        ├── GLM 4.7 Flash, MoE ~3-4B active parameters
        │      fast diversity, often wrong on mep
        │
        └── Qwen3.6-27B, dense 27B
               slower, stable and correct

        ↓

ANONYMIZED PANEL A · B · C · D
        ↓
JUDGE = Qwen3.6-27B @ temp 0
        1) verify every rule on all data
        2) find conflicts and traps
        3) choose the best base answer
        ↓
SYNTHESIS = select and augment
        ↓
FINAL ANSWER ~98/100
        45 · 89 · robot cannot reach the point

Why did Fusion beat the best individual run?

  1. Cheap diversity: GLM adds fast candidate answers.
  2. The judge verifies, not averages: wrong answers such as 48, 40 or -39 are rejected against the data.
  3. Confrontation catches elegant mistakes: GLM’s robot invariant looked nice, but had an arithmetic flaw.
  4. Select and augment beats rewrite-from-scratch: the best answer is preserved and improved, not compressed into a weaker synthesis.

In short: GLM is the fast source of ideas, Qwen is the brain and the jury, Fusion is the safety net.

Local Fusion in practice: fast GLM, strong Qwen, anonymized panel, Qwen judge and final answer

The technical view of orchestration: GLM provides fast candidates, Qwen reasons and judges, Fusion selects the best base and augments it instead of rewriting from scratch.

Architecture of local Fusion: GLM as the fast ideator, Qwen as the brain and judge, final synthesis on one notebook

A closer look at the local architecture: llama.cpp with CUDA, Q4_K_M quantization, sequential orchestration and the roles of both models inside one notebook system.

Local models in context

Comparison of AI systems and models: local HyperFusion, Qwen, GLM, frontier models and HyperFusion Deep

Local HyperFusion is not above HyperFusion Deep, but in this research it clearly sits above individual local runs and close to strong single-run systems.

This does not mean Qwen 27B is generally as strong as frontier models. It means something narrower and more useful: on this specific mep/dap + robot + metacognition task, a well-prompted local Qwen and a simple local Fusion are already serious tools, not toys.

For production use, I would use the pipeline like this:

  1. GLM as a fast divergent drafter.
  2. Qwen as the main reasoner.
  3. Self-consistency for numerical answers.
  4. Qwen as judge/synthesizer at temperature 0.
  5. Strict termination rules.

The broader lesson is the same as in the HyperFusion experiments: do not ask only “Which model is best?” Ask who answers, who verifies, who is allowed to discard a beautiful mistake, and who writes the final verdict.

Locally, we are already surprisingly close.

Související články