The public Qwen 3.8 local options with hard sizing numbers today are 16-19 GB for 4-bit GGUF, 23-26 GB for 6-bit GGUF, 31 GB for 8-bit GGUF and 56 GB for BF16, while SGLang separately documents BF16, FP8 and NVFP4 checkpoints for the base Qwen3.8-27B.
If you need the short answer, the choice is narrower than most roundups suggest. Qwen3.8-27B is the reference model, GGUF is the broadest local deployment path, NVFP4 is a Blackwell-specific checkpoint branch, and Swift-Qwen3.8-27B is a reasoning-efficient derivative rather than a published low-memory build.
The evidence is uneven. SGLang publishes the strongest public measurements in the public record for the base model and NVFP4 on local Blackwell-class hardware, Unsloth publishes the clearest memory table for GGUF, and UkisAI publishes Swift benchmark tables and server commands. What is still missing is a neutral, matched benchmark set across GGUF, NVFP4 and Swift on the same local machine.
The decision table shows which Qwen 3.8 path fits each machine
| Option | Exact figures you can plan around | What it changes | Best fit | Evidence tier |
|---|---|---|---|---|
| Qwen/Qwen3.8-27B BF16 base | 27B language model with vision encoder, 262,144 native context and 56 GB total memory guidance | Reference behaviour and full documented multimodal path | Servers and high-memory workstations | Primary vendor and runtime docs |
| Unsloth GGUF 4-bit for Qwen3.8-27B | 16-19 GB total memory, plus 1-2 GB extra if you want MTP | Lowest documented mainstream local memory band in the public record | 24 GB consumer GPU, 24 GB unified-memory Mac, mixed RAM+VRAM setups | Vendor documentation with exact requirement table |
| Unsloth GGUF 6-bit for Qwen3.8-27B | 23-26 GB total memory | More precision than 4-bit without jumping to BF16 | Systems that can spare more than 23 GB total model memory | Vendor documentation with exact requirement table |
| Unsloth GGUF 8-bit for Qwen3.8-27B | 31 GB total memory | Higher-memory GGUF path | Large shared-memory systems and bigger GPUs | Vendor documentation with exact requirement table |
| RadixArk or NVIDIA NVFP4 Qwen3.8-27B exports | 21.9 GB on disk; the BF16-head RadixArk variant is ~1.7 GB larger on disk and ~3.2 GB larger at runtime; Unsloth reports 1.49x total throughput at batch 1 versus BF16 on 24GB VRAM | Hardware-specific quantized branch for NVIDIA’s Blackwell stack | RTX 50X, DGX Spark, B200, B300 users | Primary size data / vendor throughput table |
| ukisai/Swift-Qwen3.8-27b BF16 derivative | 28B params, BF16; GPQA-Diamond mean tokens fall from 15,014 to 8,855; Terminal-Bench 2.1 mean tokens fall from 37,086 to 27,272; the card also includes W4A16 and AWQ INT4 evaluation rows, but no exact RAM or VRAM requirement | Changes reasoning behaviour and token use, not the base family | Users who can already serve BF16-class Qwen and want shorter reasoning traces | Derivative model card, no published memory table |
| “Wait for Qwen3.8-Flash-Next” | No official model card, repo, memory table or release details appear in the public record; posters in the NVIDIA thread say they couldn’t find a reliable source | Nothing you can size or buy against yet | Nobody today | Forum speculation only |
The practical distinction is the one marketing pages usually skip: Swift is a derivative model, GGUF is a packaging and quantization route, and NVFP4 is a checkpoint family tied to specific NVIDIA hardware and runtimes.
The base model documentation confirms what the reference checkpoint is
The cleanest baseline remains the Qwen3.8-27B deployment page in SGLang. It describes the model as a dense hybrid Gated Delta Networks vision-language model, with a 27B causal language model paired with a vision encoder, 64 layers, and a 262,144-token native context that is extensible to 1,000,000.
That page also says the model runs single-GPU on H200, RTX PRO 6000, RTX 5090 and DGX Spark. For local planning, that matters more than architecture detail. It tells you which cards SGLang has actually documented for the reference checkpoint, rather than which ones a vendor thinks should work.
The same SGLang page publishes a benchmark sweep that is stronger than most launch posts. It says every cell across RTX 5090, RTX PRO 6000 and DGX Spark, over all five checkpoints and every serving combination, was measured on v0.5.19, and that the cells were scored on the full 1319-question GSM8K with results in the 93.18-95.15% range. Those measurements are not a full quality review, but they are at least repeatable runtime evidence rather than a hand-picked chart.
Memory still decides whether the reference route is realistic. Unsloth’s Qwen3.8 requirements table puts the BF16 requirement for Qwen3.8-27B at 56 GB. That is why the base BF16 model is the quality reference, not the mass-market local default.
SGLang also adds an operational warning that many simplified guides skip. It says the checkpoint ships with an MTP head trained with multiple steps, and it warns that –mamba-full-memory-ratio is the critical sizing flag for throughput on these hybrid GDN models. That means “base model” is not just a file format decision. The runtime has to understand the model’s serving geometry as well.
GGUF gives the broadest local route, but the public evidence is mostly about memory bands
If your actual question is “what can I run on one workstation or one Mac,” the most useful public document is still Unsloth’s Qwen3.8 guide. It publishes a full memory ladder for Qwen3.8-27B in 7-8 GB at 1-bit, 9-11 GB at 2-bit, 12-14 GB at 3-bit, 16-19 GB at 4-bit, 23-26 GB at 6-bit, 31 GB at 8-bit and 56 GB at BF16, with units stated as total memory across RAM and VRAM or unified memory.
Those numbers matter because they map to real hardware classes. The same page says 4-bit quants work on 16-19GB VRAM like RTX 5080, 4090 or a Mac with 24GB RAM, and it adds that you should reserve 1-2GB extra headroom if you want MTP. For a buyer with a 24GB machine, that is more actionable than generic claims that a model “runs locally.”
What the public record does not provide is a neutral performance comparison for Qwen3.8-27B across those GGUF levels. Unsloth says its 27B GGUFs now use Dynamic V3.0 for 10% more accuracy at the same size, but that is a vendor claim and not a published third-party test. There is no matched public chart here showing 4-bit, 6-bit and 8-bit Qwen3.8-27B on the same prompts, same runtime and same hardware.
The earlier draft overstated one point. the public record does not justify saying that 4-bit GGUF is the universal “sensible floor” for Qwen3.8-27B. What it does justify is narrower. 4-bit at 16-19 GB is the lowest Qwen3.8-27B memory band in the public record that comes with a mainstream-hardware note for RTX 5080, RTX 4090 or a Mac with 24GB RAM. Below that, the evidence shifts away from direct Qwen3.8-27B comparisons.
The low-bit warnings that do exist come from format-level work rather than direct Qwen3.8-27B tests. In Unsloth’s llama.cpp pull request for new sub-2-bit IQ types, the author says “below IQ1_S is the start of a cliff” and shows Kimi-K3 perplexity worsening from 2.578876 at IQ1_S to 4.488796 at IQ1_XXXS, while AVX-512 inference is measured at 6.5x to 8.8x slower per weight for the new types because there is no SIMD kernel. Those are useful cautionary signals, but they are not direct Qwen3.8-27B head-to-heads.
That leaves a more careful conclusion. GGUF is the most flexible local route in the public record because it has the clearest sizing ladder and the widest hardware story. But the public record still does not settle the quality trade-off between 4-bit, 6-bit and 8-bit for Qwen3.8-27B under matched local conditions.
SGLang provides the strongest public numbers for NVFP4 on Blackwell-class hardware
NVFP4 is the easiest option to misread because it looks like “just another quant.” SGLang’s Qwen3.8-27B page shows that it is a separate checkpoint family. The page lists a Qwen3.8-27B-NVFP4 (FP4 head), a Qwen3.8-27B-NVFP4 (BF16 head) and an NVIDIA ModelOpt export. It also states that the NVIDIA export has the same quantized-layer map, the same tensor set and the same 21.9 GB on disk as the FP4-head RadixArk export.
For fit and runtime, SGLang gives harder numbers than most model cards. It says the BF16-head RadixArk export is ~1.7 GB larger on disk and ~3.2 GB larger at runtime than the FP4-head version. That is the sort of detail a buyer can actually budget around.
SGLang also publishes checkpoint-specific quality ranges on local Blackwell hardware. It says the NVIDIA NVFP4 export was re-measured on RTX PRO 6000 and DGX Spark on v0.5.19, and that all 16 overlay combinations per card served and scored 94.01-95.00% on RTX PRO 6000 and 94.16-95.07% on DGX Spark over the full 1319-question GSM8K. The same page says the RTX 5090 was also measured, with 15 overlay combinations scoring 93.93-94.92%.
Unsloth adds throughput numbers, but you should read them as vendor evidence, not neutral benchmarking. Its Qwen3.8 page says its dynamic NVFP4 Qwen3.8-27B quants run ~1.5× faster than BF16 and includes a table showing batch-1 total throughput rising from 89.8 tokens/s in BF16 to 133.7 tokens/s in NVFP4 on 24GB VRAM. It also says NVFP4 requires Blackwell GPUs like RTX 50X, DGX Spark, B200 and B300.
There is one runtime wrinkle. Unsloth says its NVFP4 quants run in vLLM only for now and that SGLang is not supported, while SGLang separately documents and measures RadixArk and NVIDIA NVFP4 checkpoints. So “NVFP4 support” depends on which checkpoint and tooling path you mean, not just on the quantization label.
Swift’s own model card confirms shorter reasoning traces, but not exact memory sizing
UkisAI’s Swift-Qwen3.8-27B model card is clear about what Swift is. It says Swift-Qwen3.8-27B is a derivative of Qwen3.8-27B, reports 28B params, labels the tensor type BF16, and provides launch examples for both vLLM and SGLang at a 262,144 context length. The same card says the published weights also include the base model’s MTP head.
The performance story in that card is about token use, not lower memory. On GPQA-Diamond, the card shows mean tokens falling from 15,014 for the base model to 8,855 for Swift, while score shifts from 88.38% to 88.28%. On Terminal-Bench 2.1, the card shows mean tokens falling from 37,086 to 27,272, while score shifts from 66.74% to 65.84%. The card summarises that as 58.3% fewer thinking tokens, <1% loss and a x1.95 speed-up on several tasks.
The Swift card also goes further than many derivative releases by publishing quantized evaluation rows. It reports GPQA-Diamond results for mixed-precision quant W4A16, where base accuracy is 88.69% and Swift accuracy is 88.38%, with mean thinking-token reduction of 32.1%. It also reports AIME 2026 under AWQ INT4, where base accuracy is 82.67% and Swift accuracy is 84.00%, with mean completion-token reduction of 22.8%.
That is useful, but it still does not answer the hardware-sizing question cleanly. The same model card tells users to adjust tensor parallelism and context length to your GPU memory, and it does not publish an exact RAM or VRAM requirement in gigabytes. It also does not provide an independent local benchmark against GGUF or NVFP4 on the same machine. So Swift is a credible behavioural variant on the evidence here, but it is not a published low-memory alternative in the way GGUF or NVFP4 are.
What the release details do confirm is narrower. The card says the model is available as a GGUF version, is served through an OpenAI-compatible API, and is free for commercial use only up to organizations with US$1,000,000 in annual revenue under the Swift Open License v1.0. That makes Swift more constrained than the Apache-licensed base Qwen3.8-27B, which matters if “local variant” also means “weights I can deploy without extra licensing work.”
The app layer changes workflow, not the underlying memory math
Some readers are really choosing a local workflow rather than a checkpoint. Unsloth’s repository says its desktop app runs on Windows, Linux, WSL and macOS, supports NVIDIA, AMD, Intel GPUs and CPUs, and exposes an OpenAI compatible API. It also says Unsloth can export or deploy models in GGUF, NVFP4 and FP8.
The same repository includes a concrete Qwen3.8 local-agent example with unsloth/Qwen3.8-27B-GGUF:UD-Q4_K_XL. That supports a practical reading of the market: many people asking about “Qwen 3.8 local variants” are really asking whether they want a raw runtime such as SGLang or vLLM, or a wrapper that also handles download, API serving, tooling and chat.
What the app layer does not do is repeal the sizing numbers above. The published figures for 16-19 GB, 23-26 GB, 31 GB and 56 GB still govern what the hardware underneath can host. A better wrapper can reduce setup friction. It cannot turn a BF16-class model into a 16 GB model.
What we could not verify from the public the public record?
We could not verify a neutral, apples-to-apples benchmark suite for Qwen3.8-27B across GGUF, NVFP4 and Swift on the same local hardware. SGLang gives real measurements for the base model and NVFP4 on Blackwell-class cards, and UkisAI gives detailed model-card benchmarks for Swift, but the public record does not contain one shared test bed that lets you rank all three routes directly.
We also could not verify an exact memory requirement for Swift-Qwen3.8-27B in gigabytes. The card confirms BF16, 28B params and 262,144 context in its server examples, but it does not publish a RAM or VRAM table. For that reason, the safest statement is that Swift is documented as a BF16-served derivative, not that it needs any specific number of gigabytes.
For any “Flash-Next” variant, the gap is larger. The only source in the public record is an NVIDIA forum thread where posters say they couldn’t find a reliable source. We found no official model card, release repo, sizing guide or attributable benchmark. If that changes, the useful signal will be an official release or a runtime page with hardware guidance, not another forum post.
Sources
- https://docs.sglang.io/cookbook/autoregressive/Qwen/Qwen3.8-27B
- https://github.com/unslothai/llama.cpp/pull/61
- https://github.com/unslothai/unsloth
- https://huggingface.co/ukisai/Swift-Qwen3.8-27b
- https://unsloth.ai/docs/models/qwen3.8
- https://forums.developer.nvidia.com/t/qwen3-8-flash-next/381228
- https://www.yottalabs.ai/post/qwen-3-8-vs-qwen-3-8-max-differences-which-to-use-2026
