A 27B Model in 10GB, From an Account With 1,543 Followers

Escha Labs published a 2-bit quantized build of Qwen3.8-27B on August 20, 2026. Their claim: 10.15GB on disk, 82.6 tokens per second on a single RTX 5090 through a custom SGLang runtime, averaging roughly 100% of FP8 performance across eight benchmarks. The Hugging Face repo went live about three hours before this was written, alongside a new runtime called escha-runtime-qwen3dense. Behind it sits an account with 1,543 followers and a verifiable track record, having shipped the same treatment for Qwen3.6-35B-A3B three weeks earlier with per-card benchmarks plus published launch recipes. The speed number needs context though, because SGLang’s own NVFP4 build hits 206 tokens per second on the same card. This is a size play, not a speed play. Best for people with 12GB or 16GB cards. Not ideal for anyone chasing peak throughput.

Alibaba released the open weights for Qwen3.8-27B on August 13. Within a week, at least a dozen groups had quantized it.

Qwen’s own team ran 16 files against 20 community builds on one machine. Unsloth shipped theirs. lmstudio-community shipped theirs. So did ggml-org.

Then yesterday an account with 1,543 followers posted a 2-bit build claiming near parity with FP8, at 10.15GB.

That claim is either the most interesting local inference result of the month or it does not survive contact with a real workload. Both are worth taking seriously, because the people making it have done this before and documented it properly.

What Escha Actually Claims

Straight from their announcement, posted August 20.

The Hugging Face model page went up roughly three hours before this piece, published by an account called yzhwang, alongside a companion repo named escha-runtime-qwen3dense. The dense in that name matters, because it is a different runtime from the one they built for their previous release.

They also said in the post that they wanted to get it into people’s hands as soon as possible, which reads as an admission that the documentation is still catching up to the release.

Why Two Bits Is Supposed to Be Impossible

Some background, because the claim only lands if you know what it is arguing against.

Quantization shrinks a model by storing its weights at lower precision. FP8 uses eight bits per weight, 4-bit uses four. Each halving roughly halves the file. The tradeoff is accuracy. Fewer bits means coarser rounding, then that error compounds through dozens of layers.

Four bits is where most local inference sits, because it is the point where models stay useful. Below that, things degrade fast.

There is academic work on exactly this. A paper from Beihang, Xidian and ETH Zürich titled An Empirical Study of Qwen3 Quantization tested five post-training quantization techniques across bit widths from 1 to 8. Their finding was that Qwen3 holds up at moderate bit widths but suffers notable degradation in linguistic tasks under ultra-low precision. They call extreme compression an unsolved problem.

So the default expectation for a 2-bit 27B is that it produces fluent nonsense.

Escha is claiming it does not. That is the whole story.

They Have Done This Before, With Receipts

The reason to take this seriously rather than dismissing it is the previous release.

On August 1 the same account shipped Escha-W2 for Qwen3.6-35B-A3B, a mixture-of-experts model with 256 experts. Their claimed figures were 12.3GB on disk and 225 tok/s on a single RTX 4090, averaging roughly 100% of FP8 across 12 benchmarks: MMLU-Pro 80.9, MATH-500 93.8, GPQA-Diamond 77.8, LiveCodeBench v6 62.6, BFCL tool use 88.9, RULER 8K to 128K 89.9, Commonsense-6 76.1.

What makes that credible is the model card rather than the tweet. The Hugging Face page documents measurements across five consumer cards, taken on 2026-07-27, with the exact launch command for each. It names the engine every number came from. Decode speed is distinguished from peak throughput. There is even a context-window measurement showing SGLang allocated 159,480 tokens at the shipped memory fraction and 234,796 at a higher one.

Then it does something almost nobody does. It notes that SGLang still had 1.38GB of VRAM free at that setting, so it would very likely reach the full cap at a higher memory fraction. Then it states plainly that they did not test it.

Admitting an untested configuration in your own favour is not what marketing looks like.

The card also carries a warning that reads like it was written after somebody got burned: if generation looks like fluent nonsense, check your transformers version first, because below 5.8 the server does not fail. It logs one warning then serves with the wrong architecture parameters.

How They Say They Did It

Their previous announcement described the method in more detail than most quantization releases bother with, which is the best available guide to what the new one probably does.

Compressing a 35B model that far without collapsing it required more than a standard quantization pass, by their own account. What they built was an end-to-end compression system combining low-bit quantization with model-aware fine tuning plus a recovery step, aimed specifically at preserving the capabilities most vulnerable to low-bit error.

That last phrase carries the whole idea. Not all weights matter equally. Some layers tolerate brutal rounding, while others control behaviour that falls apart when nudged. A naive 2-bit pass treats everything the same, which is why naive 2-bit produces nonsense.

The full run took about ten hours from base model to deployable checkpoint on the 35B.

They also had to write the runtime. Their weights need a custom weight loader, custom low-bit decoding kernels, plus serving integration, because no standard engine knows how to execute their format. That is why the runtime lives in its own repository and why the new dense model needed a new one rather than reusing the mixture-of-experts version.

Which explains a lot about why extreme quantization is rare. It is not one clever trick. It is a compression pipeline, a fine tuning stage, custom CUDA kernels, plus a forked serving engine. Each piece has to work for any of it to matter.

What This Means If You Have a Normal Graphics Card

Practical translation, since the numbers above assume you already follow this stuff.

The base model is 28 billion parameters. At full precision that is roughly 56GB of weights, which needs datacenter hardware. Every quantization level below that is somebody trading accuracy for the ability to run it on hardware you can buy.

Most people reading this have a card between 8GB and 24GB. At 4-bit, Qwen3.8-27B needs roughly 14 to 18GB before the KV cache, which puts it on a 4090 or 5090 and nothing cheaper. That is a card costing well over a thousand dollars.

At 10.15GB it moves into range for a 12GB card, which covers a very large population of gaming machines bought in the last four years.

The caveat is that weights are not the whole story. Context length eats VRAM through the KV cache, so a model that technically loads may not hold a useful conversation. Escha’s previous card was explicit about this, noting that on a 16GB card you trade concurrency or context, but not both.

So the honest answer for anyone with 12GB is that it might work, nobody has confirmed it yet, plus the setup is not simple. Which is roughly where local inference always is about a week after a model release.

The Number They Left Out

Here is where the tweet needs a correction. It matters for anyone deciding what to download.

82.6 tokens per second on a 5090 sounds fast in isolation. It is not fast for this model on this card, though.

SGLang shipped day-zero support for Qwen3.8-27B and reported 206.1 tok/s decode on a single RTX 5090 using NVFP4 plus their DSpark drafter. Qwen’s own account amplified that number. A separate NVFP4 build with a speculative drafter reports going from 88.5 to 180.3 tok/s.

So the fastest available route on that card is roughly two and a half times quicker than the Escha build.

That does not make Escha’s release pointless. It makes it a different product. Their NVFP4 competitors sit somewhere between 14.6GB and 18.3GB on disk. Escha is at 10.15GB.

Which means the actual pitch is not speed. It is that a 27B model fits on a 12GB card at all.

Anyone with a 3060, a 4070, or a 16GB laptop GPU cannot run the fast builds. The question for them was never 82 versus 206 tokens per second. It was whether the model loads.

The Size Class Is Already Crowded

This is the part that will decide whether Escha’s claim holds. It is happening in public right now.

Fifteen hours before this piece, a quantization group posted their own comparison in the Qwen3.8-27B discussion thread. They quantized from the original weights into 16 files ranging from Q8_0 at 28.9GB down to IQ1_M at 8.5GB, then ran 20 community files from unsloth, lmstudio-community and ggml-org through one test rig on one machine.

Their methodology is the right one. They saved the logits from their own BF16 conversion once, 88GB of them, then scored every quant against that same file rather than quoting numbers measured on different corpora plus different hardware.

Their result: between 12 and 21GB their curve beats everyone else’s. But below 11GB, which is exactly where Escha’s 10.15GB build sits, unsloth’s 2-bit files edge theirs.

Nobody in that comparison has measured Escha yet, because it did not exist fifteen hours ago.

So there are now at least three serious contenders under 11GB, all claiming different things, none measured against each other. That gets resolved within days rather than months, which is one of the better features of this corner of the industry.

What You Would Actually Have to Do

Assume you want to try it. The honest version of the setup, based on how their previous release worked.

Two repos, not one. The weights live in the model repo and the runtime lives separately in escha-runtime-qwen3dense. You download both.

Their previous runtime shipped two engines. SGLang handles concurrency, tool calling, structured output plus a reasoning parser. A second option called ZML runs as a single binary with no Python at all, installs in about fourteen seconds, then wins on long single-user generations while losing on short replies. Their own advice was to use SGLang unless you have a specific reason not to, because it is the engine every published number was measured with.

The traps

There are traps documented in the older card that probably carry over. Transformers must be 5.8 or higher or the output silently degrades. Their previous MoE build needed prefix caching disabled, since the standard cache interfered with the internal scheduler, making things slower rather than faster. Memory fraction and context length are set per card through environment variables.

For Mac users, their previous release had a separate MLX runtime that read the same weights with no conversion step. Whether that exists for the dense model is not yet clear.

None of this is one-click. Anyone who read our coverage of h3.c, the C inference engine for running video models on Apple Silicon, will recognise the shape: real capability, real setup cost, documentation written for people who can read a shell script. Our roundup of GitHub repos worth pairing with Claude Code covers the gentler end of that spectrum.

What Would Make This Verifiable

Being clear about the evidence, since every number above comes from the people who made the thing.

Eight benchmarks are claimed and none are listed in the tweet. Their previous release named all twelve with scores, incidentally. Until the new model card lists which eight and what the numbers were, ~100% of FP8 is a summary statistic with no working shown.

The comparison baseline is unstated. FP8 of what, measured by whom, on which setup? The quantization group above published 88GB of reference logits precisely because this ambiguity makes cross-repo numbers meaningless.

And nobody independent has run it. That is not a criticism at three hours old, it is just where things stand. The people who will settle this are already benchmarking every Qwen3.8 quant on one rig. They will get to it.

There is one specific question worth watching for, raised by a reply to their previous announcement and never answered: token efficiency. Low-bit quants sometimes reach the same benchmark score while using far more tokens to get there, which erases the speed advantage in practice. Nobody has published that comparison for Escha.

Why a 1,543 Follower Account Matters Here

Step back from the specifics.

Alibaba spent enormous money training Qwen3.8-27B and released it under Apache 2.0. Within seven days a dozen groups had compressed it in different ways, published methodology, then started measuring each other. Qwen’s own team joined the comparison thread rather than ignoring it.

None of that happens with a closed model. Nobody is quantizing GPT-5.6 for a 12GB card, because there is nothing to quantize.

The account that may have produced the best sub-11GB build has 1,543 followers, no press coverage, plus a second model shipped three weeks after the first. Our Fresh Commits roundup exists because that pattern keeps repeating. Star counts always arrive after the work does.

Whether this particular claim survives testing is almost secondary. The system where strangers can test it within days, then correct it in public, is the real argument for open weights. It is a better argument than any blog post from a lab.

Why This Keeps Happening in a Week

One structural point, because the timeline here is the thing worth internalising.

Alibaba released Qwen3.8-27B on August 13. By August 20 there were GGUF conversions, NVFP4 builds, EXL3 quants, MLX conversions for Apple Silicon, abliterated variants, a speculative decoding drafter called DFlash 2, plus at least three serious contenders under 11GB.

Seven days. None of those groups asked permission or coordinated with each other.

The reason is the licence. Apache 2.0 permits commercial use, modification, plus redistribution, so nobody has to negotiate anything. A person with a 4090 and a weekend can compress somebody else’s frontier model, publish the result, then have their numbers checked by strangers on Monday.

That produces a lot of junk alongside the good work. Placeholder and fork repositories squatted on the Qwen3.8-27B name for weeks before release. Some are still around, which is why checking the publisher matters before downloading anything.

But it also produces the thing that happened here. The best build for a specific unusual constraint, a 12GB card, may well come from a two-person operation nobody has heard of rather than from Alibaba, SGLang, or any lab with a communications team.

That is the part closed models cannot replicate at any budget. Not the capability, the compression ecosystem around it.

The Part Worth Keeping

The academic literature says a 27B model at 2 bits should produce fluent nonsense.

An account nobody follows says theirs does not, backed by a model card from three weeks ago detailed enough to check.

Within about a week, people running every Qwen3.8 quant through a single test rig will publish where it actually lands. If the claim holds, a 27B model runs on a card that costs a few hundred dollars. If it does not, that will be documented too, in a discussion thread anybody can read.

Neither outcome requires trusting anyone. That is the whole point.

Check back in a week. Somebody will have run it.

Charts and Blocks

Size against speed on one RTX 5090

What fits on your card

FAQ