---
title: "Qwen 3.8 27B on your Mac: 24 GB or 32 GB?"
description: "Qwen's new 27B agentic model comes in two sizes that matter on a Mac: the standard 4-bit build for 32 GB machines, and a 3-bit build that squeezes the same model into 24 GB. We tested both on MacBook Airs, measured their speed, and picked how much the model should think."
updated: 2026-08-18
canonical: https://holaclaw.ai/blog/qwen-3-8-27b-on-mac
---

Qwen released [Qwen 3.8 27B](https://huggingface.co/Qwen/Qwen3.8-27B) on August 14, 2026. It's a 27B multimodal model with a 262K context window, released under Apache 2.0, and tuned specifically for agentic work: autonomous planning, reacting to environment feedback, and behaving well inside agent harnesses. That's the work an OpenClaw assistant does all day.

We already ship its predecessor, Qwen 3.6 27B, and in [our 6-model test](/blog/running-openclaw-with-local-models) we called it *the bare minimum you can use* to run OpenClaw locally: the smallest model that communicates properly, completes the configuration process, and handles most tasks. A successor at the same size, tuned for agents, was worth testing right away.

But Qwen 3.8 27B raises two questions the previous model didn't:

1. **Can it reach 24 GB Macs?** The standard 4-bit build needs a 32 GB machine. This time, we also tested a smaller 3-bit build that fits where the 4-bit can't.
2. **How much should it think?** This is the first model in our catalog with an adjustable reasoning depth, and the default is the deepest setting.

## One model, two builds

Local models ship in several **quantizations**: compressed versions of the same weights at different precision levels. Smaller means less RAM and faster reading of the weights, at some cost in quality. Our catalog convention is the 4-bit `Q4_K_M` build, the community's default quality/size balance.

For Qwen 3.8 27B we're shipping two:

| Build | On disk | Unified memory | For |
|---|---|---|---|
| [`Q4_K_M`](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/blob/main/Qwen3.8-27B-Q4_K_M.gguf) (4-bit) | 18.0 GB | 32 GB | The standard pick |
| [`UD-Q3_K_XL`](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF/blob/main/Qwen3.8-27B-UD-Q3_K_XL.gguf) (3-bit) | 14.4 GB | 24 GB | Macs the 4-bit can't reach |

Both come from Unsloth's [Qwen3.8-27B-GGUF](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF) repository, together with the vision projector they share.

Why should you consider the 3-bit build? Because many Mac configurations come with 24 GB of unified memory. The model, its context, the OS, and (in HolaClaw's case) the assistant's virtual machine all share one pool. A 27B model at 4 bits, plus the context an OpenClaw assistant needs, doesn't fit in 24 GB. The 3-bit build cuts the weights by about 3.6 GB, and that's enough to make the difference.

This is the first 3-bit quantized model in the HolaClaw catalog, and three-bit is the tier where quality loss starts to show. We tested it ourselves, and a user on r/LocalLLaMA [ran this exact build](https://www.reddit.com/r/LocalLLaMA/comments/1vqrt86/after_pushing_1m_tokens_through_qwen_38_27b_here/) through a multi-hour autonomous coding session with good results. Based on both, we consider it suitable for OpenClaw on 24 GB Macs.

## What we tested on

- **M3 MacBook Air, 24 GB.** Runs the `UD-Q3_K_XL` build.
- **M4 MacBook Air, 32 GB.** Runs the `Q4_K_M` build.[^why-airs]

[^why-airs]: We test on MacBook Airs on purpose. They're fanless, and they're the least powerful machines that fit each build, so the numbers here are the floor: if the model feels responsive on these, it will feel at least as good on the hardware most people already own.

Both builds ran on [llama.cpp](https://llama.app), the engine inside HolaClaw, with the [unsloth/Qwen3.8-27B-GGUF](https://huggingface.co/unsloth/Qwen3.8-27B-GGUF) weights and the vision projector loaded. Qwen 3.8 is multimodal and HolaClaw ships it with image input enabled, so we test it the way we ship it.

These are the flags HolaClaw ships:

```bash
llama-server \
  -m Qwen3.8-27B-UD-Q3_K_XL.gguf \
  --mmproj mmproj-F16.gguf \
  -ngl 99 \
  -c 65536 \
  --flash-attn on \
  -b 2048 -ub 512 \
  --load-mode mlock \
  --keep 512 \
  --cache-type-k q4_0 --cache-type-v q4_0 \
  --jinja \
  --reasoning on --reasoning-effort low
```

The 4-bit KV cache (`--cache-type-k/v q4_0`) is what makes a 64K context fit on a machine this size. `--reasoning-effort` caps how deeply the model thinks before answering.

## The numbers we measured

Two phases matter when a model answers you: **prefill** (the model reading your prompt, which decides how long you wait before the first word) and **generation** (the model writing, which decides how fast the words come). The distinction matters even more for an OpenClaw assistant: in HolaClaw, the assistant's context starts around 14K tokens before your first word, and prefill has to process all of it.

MacBook Airs are also fanless: generation starts fast and slows down as the chassis heats up. So for generation we report two figures, the peak speed at the start and the mean over a sustained session. The mean is the one that matches a long conversation with your assistant.

### The results

On the `UD-Q3_K_XL` build (M3 MacBook Air, 24 GB):

| Metric | Test | Measured | Roofline | Efficiency |
|---|---|---|---|---|
| Generation (peak) | Short prompts | 5.79 tok/s | 7.62 tok/s | 76% |
| Generation (sustained) | Back-to-back session | 3.36 tok/s | 7.62 tok/s | 44% |
| Prefill | Long prompt (4,307 tokens) | 27.5 tok/s | 70 tok/s | 39% |
| Time to first token | Long prompt (4,307 tokens) | 156 s | 62 s | 39% |

The roofline is this machine's ceiling: 102.4 GB/s of memory bandwidth divided by the 13.4 GB the model reads for every token it writes, about 7.6 tokens per second. Hitting 76% of that on generation says the bottleneck is the machine, not the software. We reached the same conclusion with Muse Glimmer.

Prefill has a different ceiling. It's bound by compute rather than memory, and at 39% of its roofline there's headroom left, the kind Apple's M5-generation chips (which add a neural accelerator to every GPU core) are built to use. Prefill is also the phase an agent depends on most, which is why the 156-second wait in the last row matters more day to day than the tokens per second above it.

The two generation rows differ because of heat. Run six generations back to back, the way a real conversation does, and the speed drops:

| Run | 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|---|
| tok/s | 4.82 | 3.15 | 2.94 | 3.10 | 3.06 | 3.08 |

From a 5.79 tok/s peak on a cold chassis to a floor around 3.1, a 47% drop. The first number is what you get on a one-off question; the second is what a working session settles into, and it's the one to plan around.

On the `Q4_K_M` build (M4 MacBook Air, 32 GB):

| Metric | Test | Measured | Roofline | Efficiency |
|---|---|---|---|---|
| Generation (peak) | Short prompts | 4.3 tok/s | 7.01 tok/s | 61% |
| Generation (sustained) | Back-to-back session | 2.5 tok/s | 7.01 tok/s | 36% |
| Prefill | Long prompt (4,307 tokens) | 30.5 tok/s | 78 tok/s | 39% |
| Time to first token | Long prompt (4,307 tokens) | 141 s | 55 s | 39% |

The 4-bit build on the newer, larger machine comes out slower than the 3-bit build on the older, smaller one: 4.3 tok/s against 5.79. The M4 Air moves 120 GB/s against 17.1 GB of weights; the M3 moves 102.4 GB/s against 13.4 GB. The extra weights cost more than the extra bandwidth buys, and the M4 also converts less of its bandwidth into tokens. We saw the same thing testing Muse Glimmer, where the two machines landed within noise of each other despite a generation between them.

**So the 3-bit build isn't just the fallback for smaller Macs: on these two machines, it's the faster option, at some cost in answer quality.**

## What thinking level should you set for Qwen 3.8?

Qwen 3.8 27B is a **thinking model**: before answering, it writes internal reasoning. New in 3.8, the depth is adjustable (`low`, `medium`, or `xhigh`), and the model defaults to `xhigh`, the most thorough setting.

On paper, deep thinking looks great. For a local assistant, it has two costs: the thinking tokens are generated at local-hardware speed before the answer starts, and they consume part of the context window your conversation needs. Early field reports agree the default overthinks: users describe 3.8 spending multiples of its predecessor's time thinking before comparable answers.

HolaClaw picks the reasoning level per model in its catalog, ships that choice, and keeps it out of your way: no dial in the UI to learn. **For Qwen 3.8 27B we ship `low` on the 3-bit build and `medium` on the 4-bit build, and we don't recommend going higher for agent work.** This model already tends to overthink, and if you want better results on your tasks, teaching the agent about them (with instructions and skills) works better than having it guess by thinking harder.

Here is what the levels cost. Same machine, same prompts, same seed; the only change is `--reasoning-effort`:

| Thinking before the answer | `low` | `medium` | `xhigh` (the default) |
|---|---|---|---|
| Short question | 42 to 87 tokens | 52 to 105 tokens | 88 to 219 tokens |
| Agentic task ("rename these files") | 124 tokens | 258 tokens | 497 tokens |
| Wait before the answer starts (agentic task) | 41 s | 82 s | 156 s |

Each step up roughly doubles the cost. On an agentic request as simple as renaming files, the model's default setting spends 497 tokens thinking, and the answer starts after two and a half minutes. At `low`, it starts after 41 seconds.

Thinking tokens also consume context. At `xhigh`, those 497 tokens come out of the window your conversation needs, on every turn, and the model shares that window with an assistant's system prompt, tools, and skills.

## Where this leaves us

Qwen 3.6 27B was our *bare minimum* for local OpenClaw. Qwen 3.8 27B pushes that tier in both directions at once: better agentic behavior for the 32 GB machines that could already run it, and a real 27B assistant on 24 GB Macs that were previously capped at much smaller models.

Both builds ship in the HolaClaw local model catalog in [HolaClaw 1.6.0](/changelog), alongside Qwen 3.6 27B, which stays in the catalog.

If you want to run it yourself, with HolaClaw or with your own Ollama or llama.cpp setup, the tutorial walks through every route: [use Qwen 3.8 27B locally with OpenClaw](/docs/tutorials/use-qwen-3-8-27b-with-openclaw).

And if you try it, bring your results to our [Discord](https://discord.gg/FbxAbS5sGQ). Every report helps the next person choose between the 24 GB and 32 GB routes.