Skip to main content
Last verified: 2026-08-14
Qwen3.8-27B is released. The weights went live on 2026-08-14 at Hugging Face and ModelScope under Apache-2.0, alongside an official FP8 build. It is a dense 27B native vision-language model — text, image, and video input — with a switchable thinking mode, tunable reasoning depth, and a 262K-token native context extensible to about 1M. This page covers its download, hardware requirements, and local deployment.
GGUF builds landed the same day: unsloth/Qwen3.8-27B-GGUF publishes the full quantization ladder plus the vision projector, also under Apache-2.0. Qwen has not published its own GGUF, and there is still no Ollama tag.

​
Qwen3.8-27B release date and status

The originally announced window — the week beginning 2026-08-10 — passed with only the 2.4T flagship shipping; the 27B followed on 2026-08-14. Qwen3.8-27B is the local successor to Qwen3.6, and its Apache-2.0 license carries over. If you need a path this site has already verified end-to-end with Tokios, Qwen3.6 remains that model until the tested Qwen3.8 commands land here; if you are comfortable with vLLM or SGLang, nothing blocks running Qwen3.8-27B today.

​
Qwen3.8-27B hardware requirements

Every figure below is a measured file size, not an estimate. The BF16 release weighs 55.6 GB and the official FP8 build 30.9 GB; the Unsloth GGUF supplies the quantized ladder, where Q4_K_M lands at 17.11 GB. Add 0.93 GB for the mmproj projector if you want image and video input — see vision in llama.cpp below.

​
Fit by device

Every verdict below assumes a Q4_K_M build.

​
Can a DGX Spark run Qwen3.8-27B?

Yes, with room to spare — a DGX Spark pairs 128 GB of unified memory with a Blackwell GPU, so even the unquantized 55.6 GB BF16 release fits outright, and the official 30.9 GB FP8 build leaves roughly 90 GB for KV cache, which is what long context and concurrent sessions actually consume. You now have a choice of format. FP8 through vLLM or SGLang keeps the most quality, while the 17.11 GB Q4_K_M GGUF through llama.cpp leaves over 100 GB of the pool for KV cache. NVFP4 would be more efficient still, but no NVFP4 build has been published for this model. See DGX Spark model compatibility for per-machine tuning.

​
Can Strix Halo run Qwen3.8-27B?

Yes. AMD Strix Halo can allocate up to 96 GB to the GPU, so even the 55.6 GB BF16 release fits, and the 17.11 GB Q4_K_M GGUF leaves plenty for context. The binding constraint here is memory bandwidth rather than capacity. The weights load fine, but decode trails a discrete GPU holding the same model, and prompt processing trails it further. Serve it through ROCm or Vulkan — running vLLM on Strix Halo and Strix Halo model compatibility cover setup and measured behaviour.

​
Can a 24 GB GPU run Qwen3.8-27B?

Yes, and this is the size class the model was built for. An RTX 3090 or 4090 holds the 17.11 GB Q4_K_M GGUF with roughly 7 GB spare for KV cache — fine for everyday context lengths, tight beyond that. Neither official safetensors release fits a 24 GB card directly, since FP8 is 30.9 GB, so the GGUF is the path here. A 16 GB card also works now, at Q3_K_M (13.82 GB) or IQ4_XS (15.71 GB), with little room left for context or the vision projector. Below that, offloading costs throughput; see memory and offloading. For two or more cards, an 8-bit build across 48 GB is comfortable and keeps more quality than a single-card Q4. Model sharding covers how runtimes split weights.

​
Context is a separate budget

The weight figures above cover the model only. KV cache is added on top and grows with context length and concurrency, so a long context can cost more memory than the weights. Size it with what size model fits your GPU? and see KV cache and context for the mechanics.
These are published file sizes, so size from them directly. What they do not include is the KV cache, which grows with context length and concurrency, or the 0.93 GB projector if you need vision.
For device-by-device comparisons, see the hardware reference. For how weight formats map to hardware, see quantization and hardware.

​
Qwen3.8-27B download and Ollama

The official downloads are live in two precisions: Both are mirrored on ModelScope. The model card documents serving through Transformers, vLLM, SGLang, and TokenSpeed. Thinking is switchable per request (enable_thinking), with reasoning_effort accepting xhigh, medium, or low; Qwen recommends temperature=1.0, top_p=0.95, top_k=20 with thinking on, and temperature=0.7, top_p=0.8, top_k=20, presence_penalty=1.5 with it off.

​
GGUF for llama.cpp and LM Studio

Qwen did not publish a GGUF, but unsloth/Qwen3.8-27B-GGUF shipped the same day under Apache-2.0 with the full ladder from IQ2_XXS (9.01 GB) to Q8_0 (29.05 GB), plus BF16. Unsloth publishes the run commands for their build:
That tag is the 17.92 GB dynamic build they recommend; plain Q4_K_M at 17.11 GB is the conventional choice. LM Studio can load the same files.
There is no Ollama tag yet. A guessed command such as ollama run qwen3.8:27b will not work. Use llama.cpp or LM Studio with the GGUF above until an Ollama build appears.

​
Vision needs the mmproj file

Image and video input is not part of the main weights file. The GGUF repository publishes a separate mmproj-F16.gguf (0.93 GB) projector, and llama.cpp needs it loaded alongside the model for any multimodal request — without it you get a text-only model. Budget that extra gigabyte on top of whichever quantization you pick, and note that the official FP8 and BF16 safetensors releases carry the vision encoder inline instead, so they need no separate file.

​
Set up a local deployment

  1. Check that your machine has room for the weights plus context memory — 55.6 GB BF16, 30.9 GB FP8, or 17.11 GB at Q4_K_M, plus 0.93 GB if you need the vision projector.
  2. Choose a runtime: vLLM, SGLang, TokenSpeed, or Transformers for the safetensors releases, or llama.cpp and LM Studio for the GGUF. Ollama has no tag for this model yet.
  3. Pair the Tokios connector with your local OpenAI-compatible endpoint after the model is running.
  4. Register a deployment name in the dashboard. API clients use that deployment name, not the upstream model id.

​
Qwen3.8-27B vs Qwen3.8-Max

The same announcement covered a second, far larger model — and that one has now shipped. Qwen3.8-2.4T-A95B, the open-weight model behind the hosted Qwen3.8-Max, is live on Hugging Face and ModelScope with a model card, BF16 safetensors, and an official FP8 variant. The model card settles what community reporting could only estimate: a mixture-of-experts model with 2.4T total parameters and 95B activated, a 262K-token native context extensible to about 1M, and — unlike the 27B — text-only input with thinking always on. Vision input, a non-thinking mode, and 1M default context are features of the hosted Qwen3.8-Max API, not of the open weights. The license is Qwen’s custom qwen3.8-max license, not Apache-2.0, so read its terms before commercial use. That makes it the first open-weight release at Qwen’s Max tier, after Qwen3.7-Max and Qwen3.6-Max-Preview both shipped API-only. It does not make it a homelab model. The split matters for how you size each one. A dense model loads every parameter for every token, so the 27B behaves predictably: memory tracks its parameter count, and decode speed tracks it too. The 2.4T is the opposite case — only 95B of it activates per token, which keeps compute manageable while the full weight set still has to be resident. Alibaba also serves the model through its hosted Token Plan, Qoder, and QoderWork products — see Alibaba’s WAIC announcement. Hosted access is not a Tokios deployment; Tokios fronts a model you run.

​
Can a DGX Spark or Strix Halo run Qwen3.8-Max?

No — not a single machine, and not a small cluster either. In a MoE model every expert weight must stay resident even though only a fraction activates per token — here 95B of 2.4T — so memory scales with total parameters rather than active ones. At 4 bits, 2.4T parameters need roughly 1.2 TB for weights alone. Those are weight-only floors. KV cache, runtime buffers, and system reservation all come on top, so treat the marginal rows as unusable in practice. If you want a Qwen3.8 you can actually serve at home, that is the 27B.
Want the largest Qwen you can serve on one machine today? Qwen3.6-35B-A3B is a released MoE that fits a single 128 GB unified-memory box. Size it from total weight size, not active parameters.

​
What is still pending

The release supplied the model card, license, repositories, and file sizes, and the community GGUF filled in the quantized ladder within hours. Two gaps remain:
  • an Ollama tag, which is the easiest on-ramp for most local setups;
  • Tokios-tested runtime commands and connector examples, which will be added once verified.

​
FAQ

Depends on the format. The Unsloth GGUF is 17.11 GB at Q4_K_M, which a 24 GB card holds with room for everyday context, and 16 GB cards can run Q3_K_M (13.82 GB) or IQ4_XS (15.71 GB). The official safetensors releases are larger: 30.9 GB at FP8 and 55.6 GB at BF16. Add 0.93 GB for the vision projector when using GGUF.
Both are out. The 2.4T flagship (Qwen/Qwen3.8-2.4T-A95B, plus FP8) shipped first, in the week of 2026-08-10. Qwen3.8-27B followed on 2026-08-14, with BF16 and FP8 repositories live on Hugging Face and ModelScope.
Size, and therefore who can run it — but also modality and licensing, in the direction you might not expect. The 27B is a dense vision-language model (image and video input, switchable thinking) under Apache-2.0, sized for a single desktop GPU or unified-memory machine. The open-weight Max-class model, Qwen3.8-2.4T-A95B, is a mixture-of-experts model at 2.4T total parameters (95B active) that is text-only with thinking always on, released under a custom license, with a 4-bit weight floor around 1.2 TB — cluster hardware, not homelab. Vision input and 1M default context on the big model belong to the hosted Qwen3.8-Max API built on it.
The 27B ships under Apache-2.0 — the same permissive license as Qwen3.6, fine for commercial use. The 2.4T flagship instead uses Qwen’s custom qwen3.8-max license with scale-tiered terms, so read it before commercial deployment. Same generation, two different licenses — check the model you actually plan to run.
No — ollama run qwen3.8:27b will not work at the time of writing. GGUF files do exist via unsloth/Qwen3.8-27B-GGUF, so llama.cpp and LM Studio can run the model today, and Qwen’s own releases run on vLLM or SGLang. If you specifically want Ollama, use Qwen3.6 until a Qwen3.8 tag lands.
Serve it locally on any OpenAI-compatible runtime, then pair the Tokios connector so the machine holding the GPU needs no inbound ports. You call https://api.tokios.com with an sk-tok-… key from any OpenAI- or Anthropic-compatible client, sending your deployment name in the model field rather than the upstream model id.

Qwen3.6

Run a verified local Qwen model today.

Model fit

Estimate the model and context size your hardware can hold.

Quickstart

Pair the connector and register a local deployment.

Quantization and hardware

Learn what a model’s release formats mean for your hardware.