A 11 year old dupe, I know. But first time I’ve seen it, and it just added to my admiration for him. And, it’s just as applicable today as it was 24 years ago!

https://news.ycombinator.com/item?id=7567159

Yes, they are listed on huggingface. The instruction trained models have an 'it' in their name.

https://huggingface.co/collections/unsloth/gemma-4

Edit: Sorry, I'm not sure if this is a quant, but it says 'finetuned' from the Google Gemma 4 parent snapshot. It's the same size as the UD 8-bit quant though.

Only the 'it' models seem to have quants. I was really hoping to try a base model.

Basic quantization is easy if you have enough RAM (not VRAM) to load the weights.

They explain it here:

https://unsloth.ai/docs/basics/unsloth-dynamic-2.0-ggufs

For the best quality reply, I used the Gemma-4 31B UD-Q8_K_XL quant with Unsloth Studio to summarize the URL with web search. It produced 4.9 tok/s (including web search) on an MacBook Pro M1 Max with 64GB.

Here an excerpt of it's own words:

Unsloth Dynamic 2.0 Quantization

Dynamic 2.0 is not just a "bit-reduction" but an intelligent, per-layer optimization strategy.

- Selective Layer Quantization: Instead of making every layer 4-bit, Dynamic 2.0 analyzes every single layer and selectively adjusts the quantization type. Some critical layers may be kept at higher precision, while less critical layers are compressed more.

- Model-Specific Tailoring: The quantization scheme is custom-built for each model. For example, the layers selected for quantization in Gemma 3 are completely different from those in Llama 4.

- High-Quality Calibration: They use a hand-curated calibration dataset of >1.5M tokens specifically designed to enhance conversational chat performance, rather than just optimizing for Wikipedia-style text.

- Architecture Agnostic: While previous versions were mostly effective for MoE (Mixture of Experts) models, Dynamic 2.0 works for all architectures (both MoE and non-MoE).

Wow, I just remembered using AES when I wrote an 'accessory' (menu bar app) that converted bitmap to vector for an ST DTP app that supported both. An early form of plugin I suppose. Pretty ahead of the MS mess at the time.

Dongles were a thing, certainly the expensive MIDI programs used them. Cubase, Steinberg and C-LAB Creator were the big ones.

As I recall, there were tons of books about GEM for the Atari ST, at least in Europe.

> As I recall, there were tons of books about GEM for the Atari ST, at least in Europe.

Yes, there were, but compared with the Windows textbooks and Microsoft-supplied documentation for Windows, they were really not good. In the UK, they were translated (not well) from German. At least all the ones I owned were almost completely lacking in examples, and examples are really what you want when learning to use something.

The dongle has already been reverse engineered in the last couple of years and replicas are for sale.

Yes I am aware of this, and read the HDL to understand what they did. But they are hardware only. The point is to run in emulation.

Is the software still attractive to use, after all those years, or why are you going to these extremes? Sounds it's somehow intimately intertwined with the dongle, if the check routines can't simply be patched.

Going down this rabbit hole, I realize that ST hardware for musicians is still huge. And the dongles as still working as intended, apparently.

And then this blew my mind:

https://re-falcon.com

Quite the underground scene:

https://indyclassic.org

I have two Falcons here they're a compelling machine and still fun to play with.

But if I were to ask for a machine repro, a new motherboard, it would be in a different PCB form factor to get it into an ITX or m-ITX case. Because it's the cases and keyboards that go, not the machine.

We almost had something like that with the Medusa and Hades Atari clones.

People attempted to patch the routines decades ago and it never produced a stable result.

Apple sued DRI, which resulted in the crippling of GEM, the glaring one I remember were static windows. You heard that right, windows were not resizable but had fixed screen locations in the PC version.

Thankfully Atari licensed GEM for their 68000 machines before the lawsuit, and wasn't affected by these changes. The Atari ST (Sixteen/Thirtytwo) was very Mac like at the time. It even ran the Mac OS from Apple ROMs (Spectre 128 and Aladin) on its much cheaper hardware.

Windows were only fixed in the desktop application, you could still move and resize them in your own apps.

Didn't know, thanks for pointing that out. Never used GEM outside Atari, just something I read at the time.

I knew viewmax had static windows, but I always wondered why. Now I know.

How much was an Atari plus Spectre/Aladin?

The problem was you also needed to buy a Mac to get the licensed ROMs.

I don't remember where I got them, but I think they could be copied with an EEprom programmer.

When the Mac and Atari ST first hit the market in the 80's, there were Comics created in this 1-bit "ordered-dither" style. For error-diffusion dithering (Floyd-Steinberg etc.), you needed more bits per pixel, to carry the error.

SHATTER:

https://imgur.com/gallery/shatter-1984-was-first-commerciall...

Robot Empire:

https://www.reddit.com/r/atarist/comments/xgs4rh/comicbook_c...

Andrej Karpathy got one from Jensen Huang.

https://blogs.nvidia.com/blog/gtc-2026-news/#dgx-station

Tried to build from source on MacOS, but got this error:

  (base)   unsloth git:(main) unsloth studio setup
  ╔══════════════════════════════════════╗
  ║     Unsloth Studio Setup Script      ║
  ╚══════════════════════════════════════╝ 
   Node v25.8.1 and npm 11.11.0 already meet requirements. Skipping nvm install.
   Node v25.8.1 | npm 11.11.0
   npm run build failed (exit code 2):

  > unsloth-theme@0.0.0 build
  > tsc -b && vite build

  src/features/chat/shared-composer.tsx(366,17): error TS6133: 'status' is declared but its value is never read.

Hey will check ASAP and fix - sorry about that

Apologies on the delay - we fixed it! Please re-try with:

curl -LsSf https://astral.sh/uv/install.sh | sh

uv venv unsloth_studio --python 3.13

source unsloth_studio/bin/activate

uv pip install unsloth --torch-backend=auto

unsloth studio setup

unsloth studio -H 0.0.0.0 -p 8888

Thank you for the follow up! Big fan of your models here, thanks for everything you are doing!

Works fine on MacOS now (chat only).

On Ubuntu 24.04 with two GPU's (3090+3070), it appears that Llama.cpp sometimes uses the CPU and not GPU. This is judging from the tk/s and CPU load for identical models run with US-studio vs. just Llama.cpp (bleeding edge).

Can Unsloth Studio use already downloaded models?

IDK how it did but it detected my LM studio downloaded models I have on a spinning drive (they're not in the default location).