Qwen3.8-27B: seven endpoints, one name, two prices

A model name is a label on a menu. What arrives at your API call is one specific dish: a particular quantization of the weights, served with a particular context window, by a particular host, at a particular version. This week’s Qwen3.8-27B traffic makes the gap unusually easy to see, because the same checkpoint has been sliced every way at once. One Apache-2.0 checkpoint, released on 2026-08-14, now exists as more than twenty GGUF files from 6.19 GB to 54.7 GB (GGUF is the single-file format llama.cpp loads for local inference), as seven API endpoints whose context windows range from 65,500 to 1,000,000 tokens — which decides whether a long prompt is accepted at all — and, once you follow one dated build across two hosts, at two prices for a file that has not changed. The name is not the product. The product is the tuple (weights, quantization, context window, version), and a router that cannot see that tuple is routing blind. The rest of this post reads the quantization data carefully, because it is good data, and then shows where the name stops telling you anything.

The ladder

On 2026-08-19 Unsloth published Dynamic v3.0, an update to its post-training quantization recipe, with Qwen3.8-27B as the first model shipped on it. The Hugging Face repository lists the result as a ladder: two 1-bit builds (6.19 GB and 6.73 GB), three at 2-bit, three at 3-bit, a cluster at 4-bit, and on up through 5-, 6- and 8-bit to the BF16 reference at 54.7 GB. Unsloth reports 5.1 million downloads in five days. Read that as what it is: Hugging Face counts file pulls, not unique users, and the figure spans every Unsloth Qwen3.8 repository, not just the 27B.

Two details in the release notes matter more than the headline size. A word on the file names first: in Unsloth’s scheme UD marks its dynamic recipe, the digit after Q or IQ is the bit-width, and the suffix (S, XL…) is a variant within that width. First, for every build at UD-Q2_K_XL (8.37 GB) and below, Unsloth removed the multi-token-prediction (MTP) module — the head that lets the model draft several tokens per step for speed — to save roughly 500 MB. So the small files are not just lower precision; they are missing a component the larger ones have, and the fast decoding path that depends on it is unavailable unless you load the separate Q4_0 MTP module Unsloth ships alongside. Second, the documentation is explicit that the 1-bit builds should not be used for agentic work: they loop without a presence_penalty of 1.5 or higher, return empty responses unless thinking is enabled, and “will either fail to call tools, keep calling tools or not even call them.” General knowledge survives; the ability to act does not. That is an honest note from a quantization vendor, and it is also a product specification. A 6.19 GB file that answers trivia and a 54.7 GB file that runs an agent loop are not the same thing wearing different sizes.

What the eval says — and what it cannot

The chart above is the one making the rounds, and it deserves a careful reading rather than a fast one. Its y-axis is the top-1% accuracy defined in the caption: a single-step, next-token agreement rate against BF16 on a held-out prompt set. By that measure the 6.19 GB UD-IQ1_S keeps about 72% agreement while being 89% smaller than the 54.7 GB BF16 file, and Unsloth reports its curve sitting up to roughly ten points above the next provider’s at equal size. Both claims come from Unsloth’s own benchmark. Neither has been independently reproduced as I write this, and the documentation does not pretend otherwise.

Top-1% is an argmax on a single step. It tells you whether the quantized model would have started the same sentence; it tells you nothing about whether it finishes it the same way. Unsloth knows this, which is why the release introduces a second metric, Divergence-300 @32: three hundred prompts from agentic-coding, math and non-Latin long-document benchmarks, decoded greedily for 32 tokens and compared against the BF16 trajectory. Agreement on that metric is low for every quant — BF16 agrees with itself by definition, and even good builds sit in the twenties — and the cliff is visible. Between UD-Q2_K_XL and UD-IQ2_S, one rung on the ladder, 32-token agreement drops from around 25% to single digits. Unsloth’s own example makes the gap concrete: a build can report a 77% top-1 recovery and an 8% Divergence-300 @32 at the same time, and in its words the single-step number “is not a replacement” for the trajectory number.

There is a third thing the chart cannot tell you, and it is the one that should inform a routing decision. Post-training quantization decides which weights keep precision by watching activations on a calibration set. Dynamic v3.0’s was, per the documentation, “refined for agentic coding, chat, and multilingual performance.” A quant tuned on coding prompts can hold up on coding prompts and degrade somewhere the calibration set did not go. Unsloth publishes its calibration statistics and an overfitting analysis on unseen Wikitext and code, which is more than most vendors do. It still means the curve is a statement about those workloads. Yours may live on a different curve, and the only way to find out is to run yours.

So: the eval says that file size and single-step agreement are tightly related, that the relationship breaks hardest below 2-bit, and that one recipe currently does better than three others on its own test. It cannot say which rung your workload tolerates. That is a per-caller question, which is exactly why the caller needs to be able to ask it.

Seven products behind one name

Now leave the local-inference world and look at the same model as an API. OpenRouter lists Qwen3.8-27B as a single model with seven providers behind it. Its public endpoints API exposes, for each one, the quantization the host runs, the context window it actually serves, and the maximum completion length. I pulled the snapshot on 2026-08-21; an excerpt:

{
  "data": {
    "name": "Qwen: Qwen3.8 27B",
    "endpoints": [
      { "provider_name": "AkashML", "quantization": "bf16",
        "context_length": 262144, "max_completion_tokens": 131072,
        "pricing": { "prompt": "0.00000045", "completion": "0.0000032" } },
      { "provider_name": "Io Net",  "quantization": "fp8",
        "context_length": 65500,  "max_completion_tokens": 65536,
        "pricing": { "prompt": "0.00000048", "completion": "0.0000034" } },
      { "provider_name": "Alibaba", "quantization": "unknown",
        "context_length": 1000000, "max_completion_tokens": 131072,
        "pricing": { "prompt": "0.000000575", "completion": "0.00000345" } }
    ]
  }
}

Lay the whole table out and the point makes itself. Prices and the two right-hand columns are from OpenRouter’s model page on the same day. Treat the last two as weather, not specification: the benchmark is a rolling 32-day window with a sample floor, the error rate is a rolling average over real traffic, hosts differ in sampling settings, thinking mode and system prompts as well as precision, and all of it will have moved by the time you read this.

† GPQA Diamond (graduate-level science questions; higher is better) from the AutoExacto Benchmarks card on the model page: OpenRouter’s own harness, run per provider endpoint, aggregated over a rolling 32-day window with a minimum sample floor. ‡ Rolling average from the Performance tab, measured on real traffic, as captured on 2026-08-21; the page lists the three shown. ”—” means not reported.

Read the columns one at a time. Five hosts serve FP8 (8-bit floating point), one serves BF16 (the 16-bit reference precision), one is listed as unknown. Five serve the model’s native 262,144-token window; one serves a quarter of it at 65,500 tokens, which means a long-context request that works on six providers fails on the seventh with the same model string; one serves 1,000,000, which is the YaRN-extended configuration (a trick for stretching context beyond the length the model was trained on) that Qwen’s own model card describes as an extension rather than the native length. Maximum output spans 65,536 to 262,144 tokens — a four-fold difference in how long an agent can think before the host cuts it off. And on the AutoExacto card, the same benchmark scored against the same named model comes back between 76.8% and 83.3% depending on who answered. I would not read much into any single one of those numbers, for the reasons above the table. I would read a great deal into the spread. Seven hosts, one name, and the observable behaviour differs on every axis the name does not encode. The cheapest line and the most expensive line differ by about 44% on input, and nothing in the string qwen/qwen3.8-27b tells you whether the gap buys you precision, context, or only a logo. To be clear about where the fault lies: OpenRouter publishes all of this, in the API and behind a filter control on the page. The problem is not that the data is hidden. It is that the industry’s default key — the one in your config file — is still the name.

The date suffix is a fork too

There is a fourth axis, and it is the one most likely to show up on an invoice. Take one dated build and follow it across two hosts. On Together’s price list the model is called DeepSeek V4 Flash 0731 and costs $0.14 per million input tokens and $0.28 per million output. On DeepSeek’s own pricing page the alias deepseek-v4-flash currently maps to the same DeepSeek-V4-Flash-0731 build and, since 2026-08-16, costs $0.22 / $0.66 off-peak and $0.44 / $1.32 at peak. Two things are true here, and they are separate. The price gap is the host axis from the previous section — two hosts, two price lists — and note that Together’s entry does not state a precision, which by this post’s own rule makes it an unknown. The version axis is the other thing: 0731 on Together’s list is a frozen, auditable build, while deepseek-v4-flash is an alias the vendor has already repriced once and can repoint to a newer build without the name changing. We covered the peak/off-peak mechanics in When your provider makes time a pricing variable; the point here is narrower. 0731 is information. A name without it is a promise the host can change underneath you.

What a router owes you

Put the three sections together and the data model writes itself. A model name is a display string. The identity of the thing you are calling is at least four fields. The general rule is the easy part: whatever the host declares, route on it and echo it in the response, so the caller can pin and audit it. The table is about what to do when a field is missing — ✓ marks a safe default, ⚠ a value to route on with caution, ✗ a gap that must not be filled by guessing.

A router that has these fields can do three things a name-keyed router cannot. It can let the caller pin: “this model, FP8 or better, at least 200K context.” It can let the caller float with a floor: “cheapest host that meets the floor, and if the floor cannot be met, fail loudly rather than silently downgrade.” And it can be honest about ignorance — a host that does not declare its quantization is not disqualified, but it sorts after those that do, and the caller can see why.

Some of this exists today, and credit where due. OpenRouter’s request body already takes a provider object that filters by quantization and pins hosts:

{
  "model": "qwen/qwen3.8-27b",
  "provider": { "quantizations": ["bf16", "fp8"], "order": ["parasail", "akashml"], "allow_fallbacks": false }
}

That covers two of the four fields from the caller’s side. What that field list does not include is a context or max-output floor, or a rule for unknown — today you get those by pinning the host and reading its row yourself. Those gaps are what PiRouter’s catalog is designed around: all four fields as first-class, filterable metadata on every endpoint, with undeclared values surfaced as unknown rather than guessed. That is a description of the design, not a promise about any host’s data on any given day.

So, two moves available now, whatever gateway you use. Where the gateway accepts a quantization filter, write the floor you need into the request. Where it does not, pin the provider explicitly — a pinned host is a known product; a bare model name is a lottery ticket. And if you need to know whether a host’s declared precision is real, the only self-service check is the one Unsloth itself uses: sample your own prompts against a reference you trust and measure the divergence.

Back to the curve

Unsloth’s chart is a good piece of work, and the honest reading of it is modest: for one recipe, on one calibration distribution, file size and single-step agreement trade off smoothly until somewhere below 2-bit, and where your workload sits on that curve is something only your prompts can tell you. Every column in the OpenRouter table and the 0731 on Together’s list are the same kind of fact — true of a specific product, silent about the name. Choose by the tuple, and make your router show it to you, because if the router cannot see the difference, the only party that can is the host, and the host is the one sending the bill.