Qwen3.8-27B Finetunes That Think 37% to 58% Less: Which One Actually Fits Your Mac

A 24GB Mac runs both of the new token-efficient Qwen3.8-27B finetunes, but only through the GGUF route and only at the lighter quantization tiers. BottleCap AI's ThinkingCap ships a 14.41 GiB IQ4_XS file and a 16.24 GiB Q4_K_M file. Meanwhile, UkisAI's Swift 1.5 publishes 22 GGUF tiers, and its own card names Q4_K_M as the pick for 24GB cards. Neither lab's MLX build has been validated on 24GB of unified memory. In short, that is the whole answer for the machine question. The rest of this article is the arithmetic behind it, plus an audit of the two headline claims.

Does it run on your Mac? The short answer

Both finetunes are the full 27,781,427,952-parameter Qwen3.8-27B vision-language checkpoint with new weights, so size is decided by the quantization tier and the context you ask for, exactly as with the base model. In practice, a 24GB Mac is the tier where the answer changes with the file, not with the vendor.

Here is the arithmetic in one place. IQ4_XS is the lightest usable tier, and it needs 14.41 GiB of weights plus 0.87 GiB for the vision projector, which comes to 17.28 GiB once a 32K context adds 2.00 GiB of cache. Q4_K_M is 16.24 GiB of weights, so it lands at 19.11 GiB at the same context and only fits if you keep the conversation short. Q6_K needs 25.09 GiB and Q8_0 needs 29.92 GiB, so neither one fits on a 24GB machine at all. So the vendor question is gone: pick by tier, not by brand. It also explains why the same question gets different answers in different threads. Anyone quoting a single number is describing one row of the table below, and a row is not a model. Our recommendation engine runs this same weight-plus-cache sum for every device it ranks.

First, the file sizes are read from the ThinkingCap GGUF repository through the Hugging Face API on September 27, 2026. Similarly, Swift 1.5's equivalent tiers match to the byte: its own Q4_K_M is 17.44 GB, its IQ4_XS 15.48 GB and its Q8_0 29.05 GB, from the Swift 1.5 GGUF repository. Finally, the vision projector is a separate 0.93 GB file, and it only matters if you send images.

What these two models actually are

Neither lab made the model smaller. Both cut how many reasoning tokens the model spends reaching the same answer, which matters because a 27B thinking model can burn more tokens thinking than answering. So what are these two checkpoints? A token-efficiency finetune is a model that keeps the parameter count and retrains the reasoning behaviour, so the saving shows up in time and cost rather than in memory.

• ThinkingCap-Qwen3.8-27B is BottleCap AI's checkpoint, published September 23, 2026. It carries the same parameter count as the base model, 27,781,427,952, per the Hugging Face API.
• Swift 1.5 Qwen3.8-27B is UkisAI's checkpoint, published September 16, 2026, and it is a direct upgrade of Swift 1.0. Its parameter count is identical.
• Both inherit the qwen3_5 architecture from Qwen/Qwen3.8-27B, a native vision-language dense model at 64 layers with 262,144 tokens of context.

Still, use is not equal. Across every Swift 1.5 27B repository we summed 46,920 downloads, and across every ThinkingCap 3.8 repository 8,866, both over the 30-day window Hugging Face reports. The two Swift GGUF repositories alone account for 43,979 of that, against 6,341 for ThinkingCap's GGUF. Meanwhile, Swift 1.0's GGUF repository sits at 189,413, which is where the installed base currently lives.

The two headlines, audited

Both labs report their own numbers, and we found no independent reproduction of either. So we pulled the published tables and recomputed them ourselves. Three of the five headline figures survive that recount, and two do not.

However, the 37.2% number is honest arithmetic. It is just a mean of ratios rather than a ratio of means, and the gap between the two readings is the difference between a headline and a budget. Notably, ThinkingCap's per-benchmark spread is wide: 65.5% fewer thinking tokens on mmmlu, but only 10.7% on Terminal-Bench 2.1. So if your workload is agentic, the headline saving is not what you will see. Meanwhile, on the Swift side, its Terminal-Bench 2.1 row drops 0.1% at the median, and the card argues the score looks low because the model stops failing loops and runs tasks to completion instead.

Even so, neither lab hides the variance. ThinkingCap's GGUF card says plainly that no quantization file is shown to be lossless, and it publishes intervals that allow losses of up to 9.5 points on AA-LCR. By contrast, Swift's card publishes per-tier KLD so you can pick a tier on evidence rather than on a promise.

Where the context cache goes

Qwen3.8-27B caches KV only on its 16 full-attention layers. The other 48 layers are Gated DeltaNet, a linear-attention layer that keeps a fixed-size state and grows no cache. As a result, the per-token cost is small and exact. The sum is 4 KV heads times a head dimension of 256, times K and V, times 2 bytes at bf16, times 16 layers. So the per-token cost works out to 65,536 bytes, or 64 KB per token. That is the same hybrid architecture effect our VRAM guide describes for the Qwen 3.5 family, and it is the figure our memory calculator applies to those models.

So the tier table above shifts with context, not just with the file. On IQ4_XS you can afford 64K in 19.28 GiB of total memory, or 128K in 23.28 GiB, which is past a 24GB Mac. The native 262K context of the model needs 16 GiB of cache alone. So context is not free, and it is the first thing to cut when a file will not load. Take a 32K agentic session as the worked example: the cache costs 2.00 GiB on top of the weights, which is more than the whole gap between the two 4-bit tiers. That single row is why two readers with the same 24GB Mac get opposite answers about the same file.

Two practical notes. First, LLM runtimes add a compute buffer on top of these sums, so leave a gigabyte or two of slack rather than filling the machine. Second, on Apple Silicon about 4 GB goes to macOS and the desktop before any model loads, which is the convention behind our 24GB Mac Mini guide calling a 16GB Mac a 12GB GPU.

Mac compatibility by memory tier

These are sums of published file sizes, the 64 KB per token cache, and the 0.87 GiB vision projector if you use images. However, no Apple Silicon unified-memory measurement of these GGUF builds has been published by either lab, and we did not run one here. So treat the verdicts as arithmetic, not benchmarks.

Which one should you download

• If you want the smallest working file on a 24GB Mac, take ThinkingCap IQ4_XS at 15.48 GB. It is the lightest tier either lab publishes at usable quality. On top of that, BottleCap's own interval data shows no detected accuracy difference from bf16 for Q4_K_M and Q8_0. That holds on each of the five benchmarks it evaluated.
• If you want to choose your tier on published evidence, take Swift 1.5. It publishes 22 GGUF tiers with KLD at 512 and at 32K, plus top-token agreement per tier, and it states its threshold for long agentic runs at Q6_K or higher. ThinkingCap, by contrast, publishes five text tiers plus the projector.
• If you need the most thinking-token reduction, Swift 1.5's claims are the larger ones. Still, read them against the audit above: the model-wide weighted figure we compute is 29.0% against ThinkingCap's 22.8%.
• If you need vision, both route through the projector file. Swift's MLX quantization path does not implement image or video chat, and its own card says so. ThinkingCap's MLX build, meanwhile, supports vision and MTP through mlx-vlm or oMLX.
• If you are on 24GB and want MLX, neither build is validated for you. Swift's Mac validation used a 48 GiB M4 Pro, and ThinkingCap's card scopes its MLX build to 32 GB.

Runtimes: llama.cpp works, Ollama has no tag

The runtime question is settled for once. Both finetunes load on mainline llama.cpp, which is the opposite of the format wall we covered in our Ternary-Bonsai 2 27B analysis. So which of the four common runtimes actually opens the file?

• llama.cpp is the supported path for both. Upstream registers the qwen35 architecture and its conversion script handles Qwen3_5ForConditionalGeneration, so the family is in mainline rather than a fork. However, the ThinkingCap card requires a build with MTP support for this architecture, named as v0.4.1 or newer, and it warns that older runtimes refuse the file with a missing tensor error. As of September 26, 2026 llama.cpp tags include v0.5.0 and build b11205.
• Ollama has no tag for either finetune. The library returns 404 for thinkingcap and for swift while the base qwen3.8 tag exists, so the working route is to import the GGUF by hand, as covered in our install guide.
• LM Studio works through its own llama.cpp runtime. The ThinkingCap card says LM Studio auto-detects the projector file and enables image input.
• MLX diverges by vendor and by cost. ThinkingCap's MLX 4-bit DWQ build runs with mlx-vlm or oMLX and includes vision and MTP self-speculative decoding, reported at 2.41 accepted tokens per round. UkisAI's MLX builds, by contrast, require a supplied architecture patch and a pinned Python environment. The tested unpatched MLX-LM 0.32.0 loader rejects 501 vision entries, and GUI compatibility is stated as unverified.

Meanwhile, there are published Apple Silicon numbers on the MLX side, and they are not parity claims. UkisAI's validation ran an 86,004-token conversation on an AWS M4 Pro with 48 GiB of RAM. First request took 893.64 seconds for the 4-bit build and 907.00 seconds for the 5-bit build, both including model load. Then two cached follow-ups ran at 1.46 and 1.42 seconds. Peak MLX allocation was 31.57 GiB and 34.79 GiB. Prompt processing at least 96 tokens per second is what those timings imply, and the card states the results do not establish 24 GiB operation. ThinkingCap's own MLX card reports oMLX measuring 34% faster prefill at 32K on an M5 Max, 615 to 827 tokens per second, with generation slightly slower.

For decode speed on a Mac we have nothing. Neither lab publishes tokens per second for these finetunes on Apple Silicon, so any number you see quoted for a 24GB Mac is either extrapolated or measured by whoever is quoting it. The only llama.cpp throughput ThinkingCap publishes is on an H200 with four parallel slots, where MTP self-speculative decoding gave 1.76x on f16, 1.34x on Q6_K, 1.30x on Q4_K_M and 1.21x on IQ4_XS on a 24-question run. That is not a Mac number, and it should not be read as one.

The licences are not simply free

Both are open-weight releases with a revenue gate, and the two gates differ. So check your own revenue line before you ship anything built on either one.

A revenue gate is a licence term that makes the weights free up to a revenue ceiling and paid above it, and both labs use one. ThinkingCap's ceiling is defined by company size as well as by money. PolyForm Small Business 1.0.0 covers a company with fewer than 100 employees and contractors and less than 1,000,000 USD of prior-year revenue, inflation adjusted. On top of that, BottleCap adds a free non-commercial grant for individuals. Swift 1.5 takes the simpler route with the Swift Open License v1.0, which is free for personal, research, educational, evaluation and commercial use up to 1,000,000 USD of gross annual revenue. Above that line, Swift needs an Enterprise License and ThinkingCap needs a licence from BottleCap AI. In both cases the upstream Qwen3.8-27B weights stay Apache-2.0, so the gate applies to the finetune rather than to the base model.

• ThinkingCap is PolyForm Small Business 1.0.0 plus a BottleCap personal-use grant. PolyForm's permitted purpose covers a company with fewer than 100 employees and contractors and less than 1,000,000 USD of prior-year revenue, inflation adjusted. Individuals get a free non-commercial grant on top. Upstream Qwen material stays Apache-2.0. Commercial use outside those limits needs a licence from BottleCap AI.
• Swift 1.5 is the Swift Open License v1.0. Personal, research, educational, evaluation and commercial use are free for individuals and organisations with gross annual revenue of up to 1,000,000 USD. Above that you need a Swift Enterprise License. UkisAI's contribution is covered by that licence, and Qwen3.8-27B itself stays Apache-2.0.

Now, one gating detail contradicts the usual assumption. ThinkingCap's bf16 weights repository is gated with automatic approval and asks for a name, a company and a work email, so you need an account and a form. Its GGUF, MLX and NVFP4 repositories download without an account, and every Swift 1.5 repository including the bf16 checkpoint resolves without an account, even though the Swift card's metadata still carries a gated flag.

What we could not verify

• Any independent reproduction of the 37%, 58.5%, 0.35% and 1.95x claims. Both labs ran their own harnesses.
• Unified-memory behaviour of the GGUF builds on a 24GB Mac, measured. The sums in this article are arithmetic.
• Decode speed on Apple Silicon for either finetune.
• Whether a 24GB Mac survives Q4_K_M at 32K once the compute buffer and the macOS reservation are included. Our sum says 19.11 GiB, which is close enough to the line that we would call it unproven rather than fine.
• Whether Ollama or LM Studio will load these files on their current bundled runtimes at your specific versions. The cards claim compatibility, and no tag exists to test against.

FAQ

Does Qwen3.8-27B ThinkingCap run on a 24GB Mac?

Yes, at the lighter tiers. IQ4_XS is 14.41 GiB of weights plus 0.87 GiB for the vision projector, and a 32K context adds 2.00 GiB, for 17.28 GiB total. Q4_K_M is 16.24 GiB of weights, so it fits at short context and is tight at 32K. Q6_K and Q8_0 do not fit.

Is ThinkingCap or Swift 1.5 free for commercial use?

Conditionally. ThinkingCap uses PolyForm Small Business 1.0.0, which covers companies under 100 people with under 1,000,000 USD of prior-year revenue, plus a free personal grant for individuals. Swift 1.5 is free for commercial use under 1,000,000 USD of gross annual revenue and needs an enterprise licence above that. The underlying Qwen3.8-27B remains Apache-2.0 in both cases.

Can I run these in Ollama?

Not with one command. Ollama's library has no thinkingcap or swift tag, so you import the GGUF file yourself. The base qwen3.8 tag does exist. llama.cpp, LM Studio and MLX all load the finetune files directly.

Which one has fewer thinking tokens, ThinkingCap or Swift 1.5?

On the labs' own published tables, we compute 29.0% fewer thinking tokens for Swift 1.5 against 22.8% for ThinkingCap, both weighted by actual tokens across the benchmarks each lab reports. Swift's advertised 58.5% is the median reduction on one benchmark, GPQA-Diamond, not a model-wide average. Neither figure has been independently reproduced.

Do I need a special llama.cpp build?

Yes for speculative decoding. ThinkingCap's card requires a build with MTP support for this architecture, v0.4.1 or newer, and older runtimes reject the file with a missing tensor error. Plain generation works on mainline llama.cpp, which lists the qwen35 architecture. Swift's GSQ-RCO repository notes its -mtp files need the same MTP support.

Sources

• bottlecapai/ThinkingCap-Qwen3.8-27B and its GGUF repository, read September 27, 2026
• bottlecapai/ThinkingCap-Qwen3.8-27B-MLX-4bit-DWQ
• BottleCap AI, ThinkingCap-Qwen3.8-27B announcement, September 22, 2026
• ukisai/Swift-1.5-Qwen3.8-27b, its GGUF repository and its GSQ-RCO repository
• ukisai/Swift-1.5-4bit-MLX including FULL_MAC_VALIDATION.md, dated September 25, 2026
• Qwen/Qwen3.8-27B model card for the architecture and attention configuration
• llama.cpp src/llama-arch.cpp and conversion/__init__.py on master, read September 27, 2026
• File sizes and download counts from the Hugging Face API, September 27, 2026