Which Qwen 3.8 27B Build Should You Run?

Six packages on my drive all claimed to be the same model. Each one said Qwen 3.8 27B on the label, they came from three publishers, two of whom ship the same model at several sizes, and the ones I measured ran from about 16 to about 28 gigabytes on disk. There was no sense in keeping them all, so in the middle of September I put five of them through the same set of tasks on one 64 GB MacBook Pro and kept the one that gave me the least to worry about.

That one is the Youssofal Optimized-Quality package, which I call Youssofal Q8 MTPLX for the rest of this article. It answered every question in the test set correctly, in both rounds of testing, and it finished every writing prompt I gave it. What that buys you is a laptop that does structured work offline: invoice arithmetic with discounts and refunds applied in the right order, a small scheduling problem, a SQL join that must not double count, two short Python functions, a policy decision full of awkward edge cases. It got all of those right, and the code it wrote ran.

Youssofal Q4 MTPLX, the same publisher’s smaller package, is the one to take if memory is tight. It stores each weight in half the space, takes about eight and a half gigabytes less room on disk, and in the first round of testing it got every answer right in almost the same total time.

Swift Q8, from a different publisher, is a close peer. It was quicker than Youssofal on most of the work, more than twice as slow on the SQL query, and the two were level on writing.

The hosted 27B is the same model called over the network instead of run on the laptop. It was about 2.8 times faster on the six tasks both it and the local Q8 got right, but it got two tasks wrong that every local build here got right, and your prompts leave the machine to use it.

The Cold Fusion builds are a fine-tune of the same model, meaning a version somebody retrained on top of Qwen’s, and they showed no advantage in these tests. The 8-bit one took noticeably longer to reach the same answers, and the 4-bit one ran out of room on one task and delivered nothing at all.

These results come from one attempt per task on one machine, with the evidence frozen on 17 September 2026, so it is my pick from what I tested rather than a ranking of the field. And “Qwen 3.8 27B” is a family name: these packages differ in more than how many bits they store a weight in, which is why none of this is a clean experiment about quantization. The recommendation I am running today lives in the living model guide; this article stays at the September evidence.

Which build to choose

• My default: Youssofal Q8. Published as Youssofal/Qwen3.8-27B-MTPLX-Optimized-Quality. It completed every task with a checkable answer and every writing prompt, and is the build I kept. I later compared it with the Splash build on a longer SEO audit in Splash! A Test of Real Work.
• Smaller package: Youssofal Q4. Published as Youssofal/Qwen3.8-27B-MTPLX-Optimized-Speed. It passed the same eight tasks in the first round and takes a third less disk, but I never put it through the longer second round or the writing prompts, so those comparisons are still missing.
• Alternative Q8 build: Swift. KrossKinetic/Swift-Qwen3.8-27B-MTPLX-Q8. In this trial it was quicker on the two Python tasks and slower on SQL. Those differences are more useful when choosing a build than the small gap in total time.
• Hosted option: the 27B on OpenRouter. It was faster on shared passing tasks, but failed two tasks the local builds passed. Prompts are sent to the provider.

The Flash alternative, a much bigger model trimmed down to fit, is a separate decision: see Battle of the Qwens. For what a 64 GB machine can hold in the first place, start with the field guide.

Why one model name covers six different downloads

Qwen 3.8 27B is a dense model from Qwen, meaning every parameter is used for every token, with about 27 billion of them. Qwen publishes the weights in a 16-bit format, and none of the packages here is that release. Each is somebody’s repackaging, quantized: stored in fewer bits per weight so it takes less room and runs faster on a laptop. Q8 stores a weight in 8 bits, Q4 in 4. The “27B” is the parameter count and does not change with the bit width, so none of these is an 8-billion-parameter model.

Nobody in this comparison ran the original full-precision weights on the Mac. The field guide explains why the working baseline in this series is a Q8 repackaging rather than Qwen’s own release.

Bits are not the only thing that varies. Group size — how many weights share one scaling factor — differs between packages. So does which parts of the model are kept at higher precision, how the prompt is wrapped before the model sees it, and whether the publisher retrained the model on anything of their own. The multi-token-prediction head has its own precision setting as well: that head proposes several tokens at a time — tokens are the word-pieces a model writes — and the main model verifies them. It is written MTP in the tables. None of the comparisons below isolates the effect of quantization on its own. They compare packages as you would actually download them.

In this article, “original” means Qwen’s own upstream release and nothing else. The two packages from the same publisher are Youssofal Q8 MTPLX and Youssofal Q4 MTPLX, after their Optimized-Quality and Optimized-Speed labels. The others are Swift Q8, Cold Fusion, and the hosted 27B. None of them is mine: the checkpoint is Qwen’s, the conversions belong to their publishers, and the runtime features they lean on were already in MTPLX. MTPLX is the runtime I ran them all on — the program that loads a model file, does the arithmetic on the Mac’s graphics cores and produces the answer. My part was running them.

How I tested them

I tested the builds in two rounds with different timing scopes and output limits. On 14 September I ran the two Youssofal packages and the two Cold Fusion builds through eight objective tasks from the command line, starting a fresh process for every single answer, with a small cap on how much the model could write. On 17 September I ran the two 8-bit packages and the hosted service again, this time with the model loaded once and left resident in a local server — running in the background, ready for the next request — a far larger cap on how much it could write, and four writing prompts added. The rounds also used different runtime versions. Numbers from one round cannot be set against numbers from the other, and I have marked which round every table belongs to.

The eight objective tasks are the same ones used across this series: five want JSON back, two want a Python function and one a SQL query, and the evaluator runs the code and checks the JSON afterwards. Each task passes or fails as a whole. With eight tasks, a single task moves the result by 12.5 percentage points. Eight prompts in a single trial are too few to establish a general ranking.

I judge a build on how long it takes to produce an answer that is actually right, not on the tokens-per-second counter the runtime prints. Download size measures disk space, not runtime memory. Timings need the same setup to be comparable. I also test my own prompts: these eight tasks reward exactness, while much of my everyday use involves prose.

What the clock said

Round one: the Youssofal packages against Cold Fusion

Two clocks matter in this round. The runtime’s own clock covers reading the prompt, reasoning and writing the answer. The command wall adds loading the model and setting up, which happened eight times over, because every answer started a new process. The exact settings are in the specification at the end.

Both Youssofal packages passed everything, and their full command times are half a second apart: 576.33 s for Q8, 575.82 s for Q4. On the runtime’s own clock the Q4 package was slightly slower, 513.21 s against 501.06 s, even though its weighted decode rate was higher, 31.39 tokens per second against 28.30. The reason is how much each one wrote: Q4 generated 15,864 tokens across the eight answers and Q8 generated 13,972, about 13.5% more work for Q4. The diagram below separates token count, decode rate and decode time.

Cold Fusion Q8 also passed 8 of 8, but it took 661.81 s of native generation, so Youssofal Q8 used 24.3% less generation time to reach the same result. Cold Fusion Q4 passed 7 of 8: on the dependency-batching task it spent all 4,096 tokens still reasoning and delivered no function at all. That is an incomplete answer under this allowance, not a wrong implementation, and its 155.80 s of generation stay in the totals. Youssofal Q4 used 31.0% less native generation time than Cold Fusion Q4. Both percentages are for native generation, not full command time: each command also carried loading, setup and the runner’s polling delay, and that overhead was not smaller for the faster packages.

Cold Fusion’s Q6 build exists, and I ran a short MTP-depth calibration on it with a coding prompt and thinking off, but it never went through the eight tasks, so it has no grade. On quality this suite could not separate the two 8-bit packages: both passed every check, so the only measured difference was time, and with one scored attempt per task the half-second between the two Youssofal packages is not a ranking.

Round two: Swift against Youssofal Q8

This round has a different clock, so do not read its numbers against the table above. The model stayed loaded in a local MTPLX HTTP server, each task was one request, and load time is therefore outside the measurement. One trial each.

Both passed all eight. Swift’s total is 2.55% lower, a 19-second gap in one trial that is too small to establish a speed ranking. Each build was faster on different tasks.

Swift was faster on six of the eight tasks. Its clearest gains were the two Python tasks: 49.94 s against 71.97 s on interval union and 57.60 s against 96.12 s on dependency batching. Youssofal Q8 was much faster on the SQL task, 68.07 s against 139.99 s, where Swift wrote 2,727 tokens to Youssofal’s 1,202, and it was also ahead on the cache simulation, 151.28 s against 174.75 s. That SQL result is why the arithmetic mean of the ratios sits at 98.34% while the geometric mean sits at 91.41%: the plain average is pulled back to even by the one task that took twice as long, and the geometric mean is less swayed by it. Both are on the chart because they answer different questions. One trial per task will not rank these two builds.

If the tasks that matter to you look like the Python ones, Swift is a reasonable pick. If they look like SQL, Youssofal Q8 was much faster in this one trial.

The four writing tasks

Round two added four writing prompts as a secondary check: a 220–280-word briefing compressed from supplied sources, a 450–600-word explainer written from the model’s own knowledge, a 220–280-word memo from a small dataset with a trap in it, and a 160–220-word rewrite of a customer email. One assistant scored each answer on a weighted rubric and recorded any factual error it found, with a quote and a correction. The labels were shuffled, but the reviewer had prior exposure to related material, and no human read the answers blind, so these are one assistant’s judgments rather than a measured human preference.

Both builds finished all four. The model-judge means over four tasks are 87.50/100 for Swift and 86.75/100 for Youssofal Q8, and I treat that as a tie: the rubric is coarse, the reviewer is one assistant, and there is no significance test to be had from four answers. Time is the clearer difference. Swift’s four answers took 1,182.95 s in total and Youssofal’s 1,627.96 s, and Youssofal wrote more tokens on every one of the four tasks, 6,904 against 2,613 on the data memo alone.

Both builds made factual errors in the knowledge explainer. The model judge rated both 75/100, both got 3 of 5 for factual accuracy, and the reviewer flagged two errors in each. The prompt asked for an article on the urban heat island. From Youssofal Q8’s answer:

The urban heat island is a micro-scale, immediate effect: it happens every summer evening in virtually every city, regardless of whether the planet's average temperature is rising.

The reviewer’s recorded correction: “Urban-rural temperature differences vary with weather, geography, surface cover and time. Calm clear conditions strengthen the effect; the universal evening claim is too strong.” From Swift’s answer:

Planting a tree in a yard or community garden is one of the most effective individual actions, because leaves shade the ground and their roots release moisture that cools the air.

The recorded correction: “Roots take up water; transpiration releases water vapor mainly through leaves. The physiological mechanism is wrong even though the overall cooling recommendation is sound.”

Both articles read well, and both needed factual corrections before publication. On the summary, memo and rewrite, where the facts were supplied in the prompt, neither build had an error flagged. I would use their source-grounded writing as a first draft and fact-check their knowledge articles before publication.

The hosted 27B

The hosted condition was qwen/qwen3.8-27b on OpenRouter, served by DeepInfra at what the provider advertises as BF16, a 16-bit floating-point format. I did not verify the precision independently; “provider advertised BF16” is as far as the evidence goes.

The hosted run passed 6 of 8, failing the scheduling task and the SQL query that every local build in this article passed. Both failures came back in under a minute using a small fraction of the allowance, so they are recorded as graded failures rather than budget exhaustion; the export does not say what the two answers contained. On the six tasks both passed, the hosted service took 35.44% of the local time by geometric mean, a paired speed of 2.82×, and its full eight attempts took 273.82 s against 743.10 s locally.

The hosted 27B finished all four prompts with a model-judge mean of 86.5/100 in 495.31 s, against 86.75/100 in 1,627.96 s for the local Youssofal Q8. The reviewer flagged factual errors in three of the four hosted answers, including a moderate one in the explainer, and in one of four for the local package.

The serving backend, prompt rendering and reasoning controls differ, so this is a comparison of a local workflow against a provider workflow, not of two copies of one model. The trials say nothing about whether Q8 weights are better or worse than BF16 weights. They do show that the hosted run failed two tasks the local Q8 passed, that it was about 2.8 times faster on the six both passed, and that using it sends your prompts off the machine. The field guide covers the local-versus-cloud choice more generally.

Why the two rounds do not line up

The same Youssofal Q8 package took 576.33 s in round one and 743.10 s in round two, with almost the same token count, 13,972 against 13,661, and a recorded weighted decode rate of 28.30 tok/s there against 18.67 tok/s here. The two runs used different versions of the runtime, a different configured context, a different allowance and a different clock, and I did not run the experiment that would separate those causes. Do not read the pair as a before-and-after.

The four builds, with their numbers

Neither Cold Fusion build showed a measured advantage over the Youssofal packages in these runs. That is an observation about two packages under one set of settings, not a verdict on fine-tunes in general. Future recommendations will appear in the living guide.

The full specification

What is in each package

Exactly how each round was configured

Round one, 14 September 2026: the MTPLX command-line tool, version 2.11.2, one fresh process per answer, reasoning on at requested medium effort, temperature zero with a fixed seed, MTP depth 3, and an allowance of 4,096 tokens for reasoning and answer together. Round two, in the 17 September 2026 snapshot: the model resident in a local MTPLX HTTP server, one request per task, the effort level verified as medium in the prompt, MTP on, a total output allowance of 64,000 tokens and a configured context of 131,072 tokens. The hosted condition was requested with a 64,000-token reasoning allowance and 72,000 total. Writing answers were scored 0–5 per rubric dimension, weighted and scaled to 100, with factual errors recorded as a quote plus a correction. The rubric was written before the answers were produced, and each of the four writing tasks has its own set of weights.

The words the tables use

Q4 / Q8, group size

Weights stored in 4 or 8 bits instead of 16. Group size is how many weights share one scale factor; a smaller group keeps more precision and costs more bytes.

MTP

Multi-token prediction: a small extra head proposes several tokens and the main model verifies them, which can raise the decode rate. Every local objective run here used MTP at depth 3; the local writing runs are recorded as MTP with no captured depth, and the hosted runs’ decoding is provider-controlled and not measured.

BF16

A 16-bit floating-point format. It is the precision these weights are normally published in, before anyone quantizes them to 8 or 4 bits.

Native generation vs command wall

The runtime’s own clock covers prompt evaluation, reasoning and the answer. The command wall adds loading the model, setup and teardown, because round one started a fresh process for every answer.

Resident HTTP

The model stays loaded in a local server and each task is one request, so load time is not in the clock. Round two was measured this way.

Total output allowance

The cap on reasoning and answer tokens together. 4,096 in round one, 64,000 in round two. Hitting it without a final answer is a failure with its elapsed time kept.

What this does not show

Public sources