Qwen3.8-27B is the model I had been waiting for. The community immediately celebrated it as the local class leader. Finally the answers felt well-rounded, it reads context correctly, and almost always delivers the expected result. Only one thing is annoying in everyday use: achieving that result requires a long thinking phase with a lot of token output, and when speed matters, that costs time. And when something bothers me, I look for a fix.
The desire to optimize
This story started with a simple observation. My new everyday model was running on my Asus GX10 (Spark supercomputer) with an initial peak of around 20 to 24 tokens per second. That's not fast, but acceptable given the quality of the results. The catch is that those results require a substantial thinking phase with high token output. So I waited for the next vLLM update and hoped for more speed.
And something did happen. On a patched version 0.28.1-rc1, the peak briefly shot up to as high as 40 tokens per second — a genuine outlier on the upside. With the current stable 0.29.0, the peak settles at 34 to 38 tokens per second. Noticeably better than at the start, but slightly below that brief intermediate high. Not every update to the vLLM engine or the NVIDIA drivers brings improvement. This time it was more of an up and down.
And even those 34 to 38 tokens per second are only the peak value. My dashboard averages over a 5-second window anyway, so the real average across an entire thinking phase is noticeably lower. Given Qwen3.8-27B's thinking output, the perceived speed gain remains moderate. All the more welcome, then, was the news of the first fine-tune with optimized token consumption — an optimization designed to address exactly this weakness without degrading quality.
Three candidates, one hope
First I tried the Uncensored Quant from OrcaRouter, an abliterated version of Qwen3.8-27B with the refusal mechanisms deliberately removed from the weights. I wanted to know whether such an alignment intervention would incidentally change the token behavior as well. Load the model, optimize for my environment, test. The result wasn't convincing enough to switch.
My next big hope was Signal 3.8 27B from AgentionAI, explicitly marketed as a reasoning-efficiency fine-tune of Qwen3.8-27B. Others had noticed the problem too and were working on a solution. I loaded the model, optimized it for my hardware, and measured the results. Again, the hoped-for leap didn't materialize.
A week later, Swift-Qwen3.8-27B-NVFP4 from UkisAI caught my eye on HuggingFace. The quantizers were talking about over 50 % fewer thinking tokens and correspondingly faster response times, backed by an impressive chart. In their X posts they celebrated the model with their community, almost like a liberation from Qwen's overthinking problem. Enough motivation for a third attempt. That result brought no progress either. All that remained was the realization that loud marketing on X at least generates attention.
My setup for context
Now the question is how I arrive at my results. Before I pass any judgment, every new model goes through the same procedure. On my Asus GX10, my Hermes agent handles the complete setup with vLLM (or alternatively llama.cpp), fully automated. It runs smoke tests, systematically varies parameters such as temperature, MTP speculative-decoding values, and batch sizes, and measures the achieved tokens-per-second rate against answer quality. The goal is always the same: find the highest TPS number at consistent quality.
Hermes gets the measurements from my dashboard, which outputs various machine and inference values at runtime. This lets him optimize model settings while simultaneously monitoring the effects on the LLM and the environment. A complete tuning run realistically takes between half an hour and three quarters of an hour. With more complex architectures like Swift's hybrid-attention setup, it takes considerably longer, because individual sweep stages with a cold cache can take over 900 seconds before the watchdog intervenes.
For Swift-Qwen3.8-27B-NVFP4, the tuning ran across four sweep stages: speculative tokens, maximum parallel sequences, batch size, and GPU memory utilization. The best find: num_speculative_tokens=5 instead of Qwen3.8-27B's default value of 3. This setting produced a 6 % TPS gain over the lowest tested value in the sweep.
The first setback
Then came the first A/B test against my daily driver Qwen3.8-27B, an Unsloth quant. The result was underwhelming. Sure, a model performs differently on a Spark processor than on an RTX PRO 6000 Blackwell. Still, the heavily advertised performance gain should have been noticeable somehow.
In my test, the TPS rate compared to the Unsloth quant dropped sharply — no sign of any improvement. In single-stream mode, Swift-Qwen3.8 was 15.8 % slower on short prompts and 30.5 % slower on long prompts than my regular setup. Even under load with four parallel streams — my typical Hermes/KiLo everyday workload — Swift-Qwen3.8-27B fell almost 38 % behind on medium-length prompts.
But TPS rate is only one side of the coin. Over 50 % token savings could still have compensated for the speed loss. The result was sobering: across all prompt classes, the model produced only 3.8 % fewer tokens — far too little to offset the drop in TPS rate. One result was still missing: the quality measurement in the benchmark.
The second setback
No surprise there either. In the CrucibleMark Leaderboard, Swift landed at rank 14 in the Silver tier, while my daily driver sits at rank 3 in the Gold tier after vLLM optimization. Only 2.27 points behind in the total score, but a quality drop I'm not willing to accept on top of the speed drop. The gap is also unevenly distributed. In the ToolUse module of all places — one of the most important capabilities for agentic workflows in this weight class — Swift-Qwen3.8 loses almost 13 points compared to the Unsloth-Qwen3.8. The fact that it also falls noticeably behind in Code Quality and Logical Reasoning barely registers at that point.
There is one category where Swift-Qwen genuinely outshines my daily driver: the CLI test. Here it scores 95 out of 100 points, well above Qwen3.8-27B's 79.67 points. But 80 points already certifies a model as having solid CLI capability, so even this advantage is put in perspective.
My conclusion after the three attempts: neither the uncensored model, nor Signal 3.8 27B, nor Swift-Qwen3.8 could deliver on the promise of replacing Qwen3.8-27B in this weight class. The barely perceptible trimming of the thinking marathon couldn't offset the loss of substance in the other categories. At least not on my hardware.
One model, two worlds
And that brings us to the heart of the matter. UkisAI developed and optimized Swift on an NVIDIA RTX PRO 6000 Blackwell, a workstation card with 96 GB of dedicated GDDR7 memory and around 1.8 TB/s of memory bandwidth. My Asus GX10, by contrast, runs on NVIDIA's GB10 Superchip: 128 GB LPDDR5x as unified memory, shared between CPU and GPU, with just around 273 GB/s of memory bandwidth.
That's not a small difference — that's a factor of 6.5. An RTX PRO 6000 can push model weights and KV cache through memory fast enough that additional speculative-decoding drafts (Swift's MTP=5) pay off in a completely different way. Validating the extra tokens costs almost no time there, because enough bandwidth remains. On the Spark, that bandwidth is exactly the bottleneck. Every additional draft-validation cycle competes for the same narrow data pipe as the actual decoding. What saves time on the workstation card costs additional time on the Spark.
This also explains why UkisAI's numbers — up to 58 % fewer tokens and a 1.95× speed gain — not only fail to materialize on my hardware but reverse entirely. This isn't a marketing bluff. It's a hardware context that simply doesn't carry over to my processor class. My takeaway: for future fine-tune promises, I'll ask first on which hardware the result was measured, and whether my setup can actually benefit from it.
What remains in the end
After this excursion, the lesson is to be satisfied with what I'm already using. Qwen3.8-27B is a little more verbose when thinking, but ultimately reliable in exactly the categories that matter to me. The Alibaba engineers have clearly already brought their 27B model very close to the optimum for this weight class. The thinking overhead is not a design flaw. It is the price for a comparatively small model performing at the level of Opus 4.6 — a significantly larger, proprietary Frontier model from the previous year.