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

A 24GB Mac can run both new token-efficient Qwen3.8-27B finetunes through GGUF, but only at lighter quantization tiers. BottleCap AI's ThinkingCap and UkisAI's Swift 1.5 each publish a range of GGUF files, and Swift's card names Q4_K_M as its pick for 24GB cards. Neither lab has validated its MLX build on 24GB of unified memory. In short, that is the whole answer for the machine question. The rest of this article explains the tier trade-offs and audits 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.

The practical distinction is the quantization tier, not the vendor. The lighter GGUF files leave more room for context and runtime buffers; heavier tiers consume more of a Mac's unified-memory pool. A single file-size figure cannot answer whether a model fits, because context, vision input, and runtime allocations also use memory. Our recommendation engine accounts for those costs when ranking devices.

The byte counts come from the Hugging Face ThinkingCap GGUF repository API, checked September 27, 2026. The equivalent Swift tiers are listed in the Swift 1.5 GGUF repository. Both repositories also provide a separate vision projector; it is needed only for image input.

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 on its full-attention layers, while its Gated DeltaNet layers keep a fixed-size state. This hybrid design makes cache growth smaller than a model that stores KV for every layer. The exact runtime footprint still depends on cache dtype and implementation, so we do not convert the architecture into a universal memory promise. Our VRAM guide explains the same hybrid-attention trade-off.

The memory picture shifts with context as well as with the file. Longer conversations consume more cache, and vision input adds its own component. Because those costs vary by runtime and configuration, treat the tier guidance as a starting point rather than a guaranteed fit.

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 lightest working file on a 24GB Mac, take ThinkingCap IQ4_XS. BottleCap's card reports no detected accuracy difference from bf16 for Q4_K_M and Q8_0 across its evaluated benchmarks.
• 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, UkisAI's raw Mac validation log reports a long-context test on an M4 Pro. The run includes model load, cached follow-ups, and peak MLX allocation; it is not evidence that the same build fits on 24GB. ThinkingCap's own MLX card reports a prefill comparison on an M5 Max, but it does not establish parity on smaller Macs.

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 long context once compute buffers and the macOS reservation are included. The vendor guidance is a starting point, not a measured fit guarantee.
• 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?

The GGUF vendors identify lighter tiers for 24GB machines, but the final fit depends on runtime buffers, context, and whether you use vision. Start with the vendor's recommended tier and test your actual workload.

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