Alibaba's 2.4-trillion-parameter Qwen3.8-Max got the coverage. Qwen3.8-27B is the one most teams will actually deploy, and almost nothing about it has been published.
Here is the honest state of play as of 4 August 2026. Alibaba announced both checkpoints on 3 August and confirmed that open weights ship for both, with release described as "next week" and no firm date attached. Neither model is on Hugging Face yet. No licence has been named for either. Qwen3.8-27B has no spec sheet, no benchmark table and no pricing. What exists is a commitment and a parameter count.
That is thin enough that most write-ups would wait. The reason to write now is that the preparation work does not depend on the numbers. VRAM arithmetic, quantisation discipline and serving configuration are the same regardless of what the benchmarks eventually say, and the teams who have that ready will be running evaluations the day weights land rather than starting procurement conversations.
What is actually confirmed
Worth separating hard from soft, because a lot of coverage is blending the two.
Confirmed by Alibaba: a second checkpoint named Qwen3.8-27B exists, it is slated for open-weight release alongside the flagship, and it is positioned as the on-premise option in contrast to the multi-node flagship.
Not confirmed: the licence, the context window, whether it is dense or sparse, the modalities, any benchmark result, and the release date beyond "days".
Reasonable inference, labelled as such: it will follow the shape of Qwen3.6-27B, meaning a dense 27B, because that is what the family has done at this size for two generations. Plan around that and adjust when the model card appears.
One caution worth taking seriously. Alibaba has published no licence for either checkpoint, and the assumption that it will be Apache 2.0 rests on precedent that does not cover this case. Smaller Qwen models have shipped Apache 2.0, but the Max-class models went the other way: Qwen3.6-Plus, Qwen3.7-Max and Qwen3.7-Plus were all closed and API-only. Separately, at least one prominent open-source developer has publicly flagged what they read as a geographic prohibition in draft terms covering the United States, the EU, the UK and Korea. That may be a misreading, and it may not survive to the published licence. Either way, if your deployment depends on permissive terms, wait for the actual licence file rather than budgeting against an assumption.
The VRAM arithmetic
This part does not need a spec sheet, because it follows from the parameter count.
Weights consume roughly two bytes per parameter at 16-bit, one byte at 8-bit, and a little over half a byte at 4-bit. On top of that sits the key-value cache, which scales with context length and batch size and is what catches people out.
| Precision | Weights | KV cache (32K, batch 8) | Total | Fits on |
|---|---|---|---|---|
| BF16 | ~54 GB | ~12 GB | ~66 GB | 1x H100 80GB |
| FP8 | ~27 GB | ~12 GB | ~39 GB | 1x L40S 48GB |
| INT4 | ~15 GB | ~12 GB | ~27 GB | 1x RTX 5090 32GB |
The cache figure assumes a 32K context at batch 8 and a broadly typical attention configuration. Treat it as an order-of-magnitude planning number rather than a precise one, since the real value depends on head count and whether the model uses grouped-query or multi-head latent attention, neither of which has been published.
Three things follow.
The cache does not shrink when you quantise the weights, unless you quantise the cache separately, which most stacks now support and most teams forget to enable. At long context and high batch it can exceed the weights entirely. If your VRAM maths worked on paper and failed in practice, this is nearly always the reason.
At FP8 the model fits on a single mid-range data-centre card, which puts it inside the budget of any team that can approve a cloud instance. At INT4 it fits on a consumer card.
And if the model turns out to be sparse rather than dense, the weights figure stays the same while the compute drops, because a mixture-of-experts model still has to hold every parameter in memory even though it activates a fraction per token. Sparsity helps throughput, not footprint. That distinction is the most common planning error at this size.
Quantisation: measure the right thing
Whatever the benchmarks eventually say, one piece of guidance holds across every model family that has been measured properly, and it is the piece most quantisation write-ups get wrong.
Published comparisons almost always report single-turn accuracy, which is the measurement least likely to detect the failure that matters. A model quantised to 4-bit typically gives up a few points on a knowledge or reasoning benchmark, which reads as an acceptable trade. The same model can lose far more on multi-step agentic work, and the reason is compounding rather than anything mysterious.
A trajectory succeeds only if every step succeeds. At fifteen steps, a per-step reliability of 99% gives you 0.99 to the fifteenth, about 86% end to end. Drop per-step reliability to 97% and you get about 63%. A two-point degradation that looks like noise on a single-turn benchmark has taken twenty-three points off task completion, and no short-form evaluation will show you that.
The rule this produces: quantise aggressively for single-shot work such as classification, extraction and summarisation, where 4-bit is usually fine and halves your hardware bill. Stay at 8-bit or better for anything agentic or tool-using. Teams that quantised once, tested on a classification benchmark and rolled it out everywhere are the ones filing mysterious reliability tickets three weeks later.
We documented the same effect in detail in the 1-bit quantisation analysis, and it has generalised to every family we have measured since.
One Qwen-specific cost to plan for
There is a quirk in this family that materially affects cost modelling and rarely appears in comparisons.
Qwen models tend to emit substantially more output tokens per task than peers. On the Artificial Analysis Intelligence Index, Qwen3.5-27B consumed roughly 98 million output tokens against about 56 million for MiniMax-M2.5 covering the same evaluation. That is close to a 1.75x multiplier on the side of the bill that costs most.
For a self-hosted deployment this shows up as throughput rather than invoice: more tokens per task means fewer tasks per GPU-hour, so your effective cost per completed request is higher than a tokens-per-second figure suggests. If you are comparing Qwen3.8-27B against another open model, normalise on tokens per completed task rather than tokens per second, or you will systematically overstate its advantage.
Whether 3.8 inherits this is unknown. Assume it does until measured.
Running it, once weights land
Three deployment shapes cover almost everyone.
A laptop, for evaluation. An Apple machine with 48 GB of unified memory will run a 27B at 4-bit through llama.cpp or LM Studio at single-digit to low double-digit tokens per second. Too slow for a product, entirely adequate for the thing you should do first, which is running the model against fifty of your own real prompts to find out whether it is worth deploying at all. Most teams skip this and deploy on a benchmark score instead.
A single workstation card, for development. A 32 GB consumer card at 4-bit gives you a fast local endpoint to build against, with the caveat above that 4-bit is not the precision to ship agentic work on. Develop against it, evaluate at the precision you intend to serve.
One data-centre card at FP8, for production. This is the configuration that matters. A single L40S or H100 serves a 27B at full quality with room for a working batch, as one instance rather than a cluster. No tensor parallelism to configure, no interconnect to tune, no multi-node failure modes. The step from one card to two is far larger operationally than the step from nothing to one.
vLLM is the sensible default. SGLang is faster on workloads with heavy prefix sharing, which means anything with a large fixed system prompt, and the gap can be substantial. The comparison is in the serving frameworks piece.
Four settings decide whether a deployment is good or merely functional. Continuous batching should be on, and is by default in modern stacks; the mechanics are in the continuous batching explainer. KV cache quantisation to FP8 roughly halves cache memory at negligible quality cost, which either doubles your batch size or doubles your usable context, and most teams leave it off because it is not the default. Max model length should be set to what you actually use rather than the model's maximum, since vLLM pre-allocates against it. Prefix caching matters enormously if your requests share a preamble and not at all if they do not, so check before tuning it.
The evaluation to have ready before weights land
This is the part worth doing this week, because it is the part that does not depend on anything Alibaba has yet to publish.
Assemble fifty to two hundred real prompts from your own traffic, covering the categories you actually run rather than the ones a benchmark covers. Include the awkward ones: the ambiguous tickets, the malformed inputs, the requests that sit on a classification boundary. A held-out set built from production is worth more than any public benchmark, because it measures the distribution you serve rather than the one a lab optimised against.
Score against your incumbent rather than an absolute threshold. "82% accuracy" means nothing without knowing what you are running now scores on the same set. This sounds obvious and is skipped constantly, which is how teams end up unable to say whether a migration was an improvement.
Evaluate at the precision you intend to deploy, and on the shape of work you actually run. If your workload is multi-step and tool-using, a single-turn accuracy number will not detect the failure that matters, for the compounding reason set out above. Run trajectories, not questions.
And write down the licence conditions your deployment requires before you look at any scores. If the answer is that you need to embed the model in a commercial product sold into the EU, and the published licence turns out to prohibit that, the benchmark result is irrelevant. Deciding what you need first stops a good number from talking you into a bad position.
Teams with that harness in place will have a defensible answer within a day of release. Teams without it will spend three weeks building one while the window of attention closes, which is the more common outcome and the reason this post exists before the model does.
Does self-hosting save money
Only above a volume line, and the line is higher than enthusiasm suggests.
An H100 instance runs somewhere around $2.20 an hour on demand, roughly $1,600 a month kept up continuously. A 27B at FP8 on one card, at a realistic average utilisation well below saturation, works out to a per-million-token cost in broadly the same range as hosted small-model APIs.
That comparison is uncomfortable and worth stating plainly. At moderate volume, self-hosting a 27B costs roughly what calling an API costs, and you also pay an engineer to run it. Break-even sits past several billion tokens a month, where utilisation climbs and the fixed cost spreads.
So the honest reasons to self-host this model are usually not cost. They are data residency, latency control, the ability to serve a fine-tuned variant, and freedom from a provider's deprecation schedule. Those are excellent reasons. Cost becomes one at scale, and the full model is in the cloud versus on-premise analysis.
Why the 27B is the more interesting release
A closing thought on why the smaller checkpoint deserves the attention the flagship is getting.
Almost nobody can run a 2.4-trillion-parameter model. It is a multi-node datacentre artifact, and for the overwhelming majority of organisations an open-weight release at that size functions as a price signal rather than a deployment option. It pushes down what everyone above it can charge, which is a real benefit you collect without buying a single GPU, but it is not something you install.
A 27B is different in kind. It runs on one card you can requisition, it fine-tunes in an hour, and it can be embedded in a product that ships to customers on their own hardware. The gap between "this exists" and "this is running in our stack" is a fortnight rather than a procurement cycle.
That is the pattern worth watching across the whole open tier. The enormous models set prices and generate headlines. The 20-to-30 billion parameter checkpoints are where the actual deployment happens, and they improve on a shorter cycle because they inherit from the flagship above them through distillation. Each generation of small model is roughly as good as the previous generation's large one, at a fraction of the serving cost, which is the mechanism quietly doing most of the work in the efficiency race.
What to do with it
A 27B model's best use is usually not as a general model. It is as a base to specialise.
Small enough that a LoRA run finishes in under an hour on one GPU, and capable enough that a tuned result beats a frontier general model on the narrow task you tuned it for. The pattern that works is keeping a frontier model for the hard slice, running the tuned 27B for the volume, and routing between them on confidence rather than category. The fine-tuning guide covers building the dataset from traffic you already have.
All of which is contingent on the licence permitting it, which is the one thing nobody can confirm today.
In the meantime, the open-weight options you can download right now are Qwen 3.6, GLM 5.2 and Kimi K3. Build your evaluation harness against one of those. When Qwen3.8-27B lands you will be running numbers on your own data within a day, which is worth considerably more than any benchmark table Alibaba eventually publishes.
Related: the Qwen3.8-Max deep dive, LLM serving frameworks compared, and open source LLM cost savings.