Qwen 3.8 27B vs Qwen 3.6 27B

Analysis

Qwen 3.8 27B replaces Qwen 3.6 27B directly: same org, same 27B-class dense weight class, released about four months apart in 2026. What makes this worth more than a version-number skim is how little actually moved architecturally — Qwen kept the exact hybrid attention stack unchanged, layer for layer — while the benchmark scores it publishes moved by a lot, especially on coding and agentic tasks.

The two models' config.json files are identical on every dimension that drives VRAM math: 64 layers, 16 repeats of three Gated DeltaNet layers (linear attention, fixed-size recurrent state) followed by one Gated Attention layer (4 KV heads, 256 head dim), the same 5,120 hidden size, and the same 262,144-token native context. Both repos' safetensors indexes report the exact same 55,562,855,904-byte total, since neither model's architecture differs at all — Qwen's own model card rounds both to "27B." Since the KV-cache math depends only on that shape, not on training, Qwen 3.8 27B's KV cache at any context length is identical to Qwen 3.6 27B's — 17.2 GB at the full 262,144-token window on both — and the weights are identical too: 16.4 GB at Q4_K_M either way. Upgrading costs nothing extra in hardware terms — literally the same weights size, not just close. What changed is capability: on the benchmarks Qwen's own Qwen3.8-27B model card reports for both models side by side, Qwen 3.8 27B leads on every shared metric — GPQA Diamond 89.2 vs 87.8, LiveCodeBench v6 90.3 vs 83.9, SWE-bench Pro 61.7 vs 53.5, and Terminal-Bench 2.1 73.0 vs a re-evaluated 63.4 for Qwen 3.6 27B on the same 2.1 harness (Qwen 3.6 27B's own originally published Terminal-Bench number, 59.3, was measured on the older 2.0 suite, not directly comparable to either 2.1 figure). The SWE-bench Pro and Terminal-Bench gaps are the largest, 8.2 and 9.6 points respectively, suggesting the bulk of this generation's work went into agentic coding rather than general knowledge, where the GPQA gap is a more modest 1.4 points. Vision setup is unchanged: both models' upstream checkpoints embed a native vision encoder (config.json's vision_config), and both still ship their GGUF quants with a separate mmproj projector file to load alongside the main weights — a llama.cpp packaging convention that applies to both releases equally, not something this generation fixed. License is unchanged, Apache 2.0 on both with no usage restrictions. Tooling is the one place Qwen 3.8 27B currently trails: at launch it has no Ollama tag yet, the same rough patch Qwen 3.6 27B's own day-one GGUFs reportedly hit, so llama.cpp, vLLM, or SGLang remain the dependable route for both models rather than just the newer one.

Bottom line: If you're already running Qwen 3.6 27B, upgrading to Qwen 3.8 27B costs nothing extra in hardware terms — the real weight size and the KV-cache math are both unchanged — for real gains on every shared benchmark, the largest on agentic coding tasks (SWE-bench Pro, Terminal-Bench). There's no hardware-tier reason to hesitate: whatever GPU held Qwen 3.6 27B holds Qwen 3.8 27B. The only reason to stay on Qwen 3.6 27B for now is tooling that specifically depends on Ollama, since neither model has a working day-one Ollama path — check current Ollama library status before switching either way.