Val's Homepage

Baking Meat & Deleting LLMs: A Casual Quantization Test

Val Saven (@valsaven) — Mon, 01 Jun 2026 00:00:00 GMT

Important Note: This is not a serious research paper. I wrote this benchmarking notes purely for myself because I wanted to clean up my SSD and purge the weaker models to free up dozens of gigabytes. If you came here looking for charts, code snippets and perfect academic accuracy, do not waste your time. I might do something like that someday, but definitely not today - today was just a casual evaluation while waiting for my meat to bake in the oven😺

So, I just spent a couple of hours on a simple test on my workstation (Ryzen 9 5950X, 128GB RAM, RTX 4080 16GB) to see how local models handle raw logic, strict syntax and context constraints under heavy quantization.

If you are choosing local models based solely on parameter size or default community quants (like Q4_K_M), you might be sabotaging both your speed and output quality. Here is the layout of my personal experiment.

The Testing Framework

I subjected six models to a three-part prompt designed to hit weakness of heavy quantization:

The Cat in the Rooms Riddle: A classic state-tracking logic puzzle requiring a guaranteed catch sequence across 5 rooms in 6 days. I used (2, 3, 4, 4, 3, 2) as the reference solution - sourced from Gemini, which also provided the mathematical justification (I also tested this in Lean 4). Models were evaluated on whether they arrived at a valid catching sequence and could explain why it works.
Concurrent Go Script: Writing a production-ready concurrent worker pool utilizing context for immediate cancellation upon the first error, ensuring zero goroutine leaks, proper channel closure and strictly English comments.
The Coffee Analogy: A rigid formatting test requiring a 4-paragraph explanation of synchronous vs. asynchronous code with specific keywords (inversion and blocking) forced into paragraphs 3 and 4 respectively.

The Pitfall: System-Level Hangs in “Thinking”

Before getting to the results, a massive technical caveat. Three major models completely locked up my workstation during the first logic puzzle:

qwen/qwen3.5-9b Q8_0
google/gemma-4-26b-a4b Q4_K_M
zai-org/glm-4.7-flash Q4_K_M

They entered an infinite, recursive loop during their Thinking process on the parity puzzle, spinning their gears for over 7 minutes until I had to force-stop them and completely disable the Thinking layer.

I also tested mistralai/ministral-3-14b-reasoning Q6_K and it bricked itself in the exact same manner, but because its reasoning architecture cannot be toggled off in LM Studio, it was completely unusable and had to be dropped from the benchmark entirely.

Interestingly, Qwen 3.6 27B Q4_K_M completely avoided this trap. While its MoE (Mixture-of-Experts) brother (Qwen 3.6 35B A3B Q4_K_M) struggled with logic stability, the 27B dense model bypassed any infinite reasoning loops entirely, proving that dense architectures handle state-tracking logic alignment more predictably under standard quants.

If a model’s internal reasoning loop gets stuck on abstract parity tracking, it is a massive red flag for production stability.

The Standings

The Absolute King: unsloth/qwen3.6-35b-a3b Q3_K_XL (18.63 GB)

This model performed flawlessly across all three tasks. It nailed the 6-day riddle with pristine mathematical justification, correctly identifying the parity-inversion structure and arriving at (2, 3, 4, 4, 3, 2) unprompted. More importantly, its Go code was beautiful - utilizing a non-blocking select for error propagation, handling wg.Wait() in a detached goroutine to close channels safely and keeping comments in English. It abided by every single textual constraint.
The Solid Professional: qwen/qwen3.6-27b-instruct Q4_K_M (17.5 GB)

This model was the biggest surprise of the extended test. Unlike the MoE-based 35B models, this is a traditional dense model, and it absolutely shines.
- It nailed the 6-day cat riddle unprompted with the exact (2, 3, 4, 4, 3, 2) sequence and flawless parity justification.
- Its Go code was pretty solid: no deadlocks, a properly buffered error channel, explicit context cancellation and zero goroutine leaks.
- It followed the strict 4-paragraph coffee analogy constraints perfectly, putting inversion in paragraph 3 and blocking in paragraph 4.
And the most important part? It didn’t hang or lock up during the reasoning phase. It just executed raw logic efficiently.
The Surprising Runner-Up: unsloth/qwen3.6-35b-a3b Q2_K_XL (14.08 GB)

Never write off an ultra-low quant if it comes from Unsloth with Unified Embedding (XL) layouts. It held the exact same logical line as its bigger brother on the riddle and respected the strict formatting rules. The Go code had a minor context leak (forgot a defer cancel()) and was slightly bloated, but it remained fully functional.
The Biggest Disappointment: qwen/qwen3.6-35b-a3b Q4_K_M (22.1 GB)

Proof that “heavier is not always smarter”. Despite being a Q4 quant, its code was completely broken. It introduced a terminal deadlock in the main select block if all tasks succeeded and it returned generic context strings instead of the actual error payload. It fell prey to standard quantization damage on high-importance weights.
The Also-Rans (Qwen 3.5 9B, Gemma-4 26B, GLM-4.7-Flash)

With Thinking turned off, they fell apart. Qwen 3.5 failed the logic entirely. Gemma-4 hallucinated a non-existent “trap room” in the riddle and wrote bloated, double-nested goroutine logic. GLM-4.7-Flash failed every single benchmark, writing non-compilable Go code that tried to invoke a non-existent .Cancel() method directly on the context interface.
MoE vs. Dense: Why Quantization Hits Them Differently
- Standard Q4_K_M completely broke the Qwen 3.6 35B-A3B (MoE model), producing broken code and deadlocks.
- Yet the same Q4_K_M worked perfectly on the Qwen 3.6 27B (dense model).
MoE models are highly sensitive to damage in their routing weights (the parts that decide which expert to use). Regular community quants often corrupt these gatekeepers, causing logical failures or loops. Dense models don’t have this weak point, making them vastly more resilient to standard quantization.

Key Takeaways for My Setup

VRAM vs. System RAM Spill: Q3_K_XL only spills about 2.6 GB into my system memory. Q4_K_M spills over 6 GB. Because Q3_K_XL minimizes PCIe bus choking, it runs significantly faster while delivering vastly superior code logic than the broken Q4 community quant.
The Unsloth XL Layout Wins: The intelligent weight distribution in XL formats preserves the routing logic of MoE models even at low bitrates.
Cleanup: Purged Qwen 3.5, Qwen 3.6 35B A3B Q2_K_XL, Ministral 3 and GLM 4.7 Flash from the drive. Keeping Qwen 3.6 35B A3B Q3_K_XL as my main model for local engineering tasks. Sometime later I’ll compare it separately with Qwen 3.6 27b Q4_K_M.

Solving Translation Issues in Nuxt.js After Updating @nuxtjs/i18n

Val Saven (@valsaven) — Tue, 04 Feb 2025 00:00:00 GMT

Introduction

With the update of the @nuxtjs/i18n package from version 9.1.1 to 9.1.2 and beyond, I have encountered new challenges in handling translations. This article explores one such issue related to the langDir parameter and how it was circumvented.

Problem Description

Following the update to version 9.1.2 and above, the use of the $t function for translating keys started to throw errors. When changing languages within the application, keys that were previously translated correctly now resulted in errors like index.vue:6 [intlify] Not found 'home.p1' key in 'ja' locale messages.

Analysis

Upon investigation, it became clear that the issue was linked to the langDir parameter, which is responsible for loading translations from a specified directory. After the update, the system could no longer load translations from external JSON files properly, despite the correct setup of langDir in nuxt.config.ts.

Solution

The solution was unexpected but effective. Instead of loading translations from separate JSON files in the directory specified by langDir, the translations were moved directly into the i18n configuration file, i18n.config.ts.

In i18n.config.ts, all necessary translations for English and Japanese were added, structured within objects:

export default defineI18nConfig(() => ({
  legacy: false,
  locale: 'en',
  messages: {
    en: {
      welcome: 'Welcome',
      home: {
        p1: 'Hello!',
      },
      // ... other translations ...
    },
    ja: {
      welcome: 'ようこそ',
      home: {
        p1: 'こんにちは!',
      },
      // ... other translations ...
    },
  },
}));

In nuxt.config.ts, the langDir configuration was removed along with the file fields for each language, since translations are no longer loaded from external files:

i18n: {
  locales: [
    { code: 'en', iso: 'en-US' },
    { code: 'ja', iso: 'ja-JP' },
  ],
  defaultLocale: 'en',
}

Conclusion

Although the exact reason why changes to langDir stopped working remains unclear, this solution allows for continued internationalization support in Nuxt.js applications. Future updates to @nuxtjs/i18n might resolve this issue, but for now, moving translations into the configuration file serves as a reliable workaround.

Electron + Vite: Issues with Using Node Modules

Val Saven (@valsaven) — Sat, 08 Apr 2023 00:00:00 GMT

When using Vite to build Electron (which currently does not support the "type": "module" option in package.json), there may be a problem using Node.js modules such as path, fs, and others.

An error Error: Module "path" has been externalized for browser compatibility. Cannot access "path.sep" in client code will appear.

However, this can be easily fixed by installing the vite-plugin-electron-renderer polyfill (npm i -D vite-plugin-electron-renderer) and declaring it in the vite.config.ts like this:

import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';
import renderer from 'vite-plugin-electron-renderer';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [vue(), renderer()],
  base: './',
});

Install Haskell on macOS Monterey 12.6

Val Saven (@valsaven) — Thu, 06 Oct 2022 00:00:00 GMT

brew install ghc

brew install cabal-install

cabal update

brew install haskell-stack

brew install haskell-language-server

Overheating Issues with AMD Graphics Cards on Linux

Val Saven (@valsaven) — Thu, 06 Oct 2022 00:00:00 GMT

The solution to the problem was quite simple: checking the monitor’s frequency. At 144 Hz, the video card shows 100% Memory Clock in radeontop.

Command that shows your GPU utilization, both for the total activity percent and individual blocks.

Install for arch-based distros: sudo pacman -S radeontop

Lowering the frequency to 60Hz brings everything back to normal.

Another issue is that the fans of the video card may not spin. This can lead to the video card overheating and failing. Without manual temperature monitoring, you might not realize the card is overheating until it’s too late.

The amdgpu-fan utility can help to solve this problem.

https://github.com/zzkW35/amdgpu-fan - the most relevant fork

Fan controller for amdgpus

For arch-based distros, the sequence of actions will be as follows:

yay -S amdgpu-fan

sudo systemctl enable amdgpu-fan

sudo systemctl start amdgpu-fan

The settings are in the file /etc/amdgpu-fan.yml. If the defaults don’t satisfy you, you can configure the cooling scheme yourself.

With this setup, the fans will start spinning when the video card is under load.

YubiKey 5 NFC: Guarding Your Information

Val Saven (@valsaven) — Sat, 31 Aug 2019 00:00:00 GMT

YubiKey 5 NFC: A Hardware Key

What’s new in the 5th model? It now supports FIDO2 and, directly, NFC.

Delivery

YubiKey does not ship their products to China, Afghanistan, Russia, Ukraine, North Korea, Iran, Sudan, and Syria, so alternative methods must be sought.

I received my key by ordering it to a hostel address in Britain, where I was at the time. I think various forwarding services can handle this too.

Cost

One key cost me $62.50 ($45 for the key, $5 for shipping, $12.50 in taxes).

You can order 1, 2, 10, or 50 pieces. A discount appears on orders of 10 or more (though it’s quite modest).

Applications

There is a Yubico Authenticator app available for the following platforms: Windows, Linux, Mac, Android, iOS.

https://www.yubico.com/products/yubico-authenticator/#h-download-yubico-authenticator

What I Learned Writing a Small Page in Dart One Evening

Val Saven (@valsaven) — Tue, 05 Feb 2019 00:00:00 GMT

It has a high entry barrier for a JS developer, as it involves mastering both the standard library (for many elements like input and select, Dart has its own types) and the old “new” types (for example, an array, by default, can only contain numbers. For everything else, you need to explicitly specify. It’s a small thing, but there are many such details).
However, the language itself is quite clear and simple (the syntax resembles a mix of JS, Python, Go, and C/C#), as are its tools - the package manager pub and the project generator stagehand. One can quickly grasp the basics and start coding.
Compared to pure JS, it tends to lose out (especially with ES2016+). The final file size of JS will be smaller, as will the amount of code lines.
Following from point 3, using Dart without frameworks is a highly questionable pleasure.
The same with them, as Dart can only be used for AngularDart, which has diverged so much from other Angular versions that it has essentially become a separate project. There are also 1.5 bindings for React and Vue, which are hardly updated… In short, everything is not great.
It looks very interesting in combination with Flutter, which, according to some parameters, already outperforms ReactNative (and Electron, even more so).

Conclusion: Dart is an interesting language, but learning it without combining it with Flutter and focusing on mobile development doesn’t make much sense. It won’t add much value to your career either. A search on Indeed for Moscow shows 3 vacancies for Dart and 121 for TypeScript (for comparison, there are 2 vacancies for Haskell 😏).