Qwen 3.8 Lost to 3.6 in an NVFP4 Test

What the test actually showed

For me, the main takeaway from this comparison is uncomfortably practical: Qwen 3.8 did not make it into production where Qwen 3.6 already preserves both structure and facts. A field report by user 438528858 described a call-center analytics workflow handled in a single request with thinking disabled. After a week of testing, the author decided not to replace the working version.

The workload was specific: roughly 10,000 input tokens on average, including the transcript and prompt, followed by 400–500 tokens of analytics in JSON. The models were compared on 200 calls using the same prompt. Qwen 3.8 produced 10 malformed JSON outputs, while Qwen 3.6 produced none.

Formatting was not the only issue. According to the test author, 3.8 was more likely to reverse facts or draw conclusions unsupported by the original transcript. For call analytics, this is worse than an ordinary drop in writing quality: valid JSON can be checked automatically, while a confidently distorted fact can easily pass through the pipeline.

There is an important caveat: the comparison was not between original models, but heavily compressed builds: unsloth/Qwen3.8-27B-NVFP4 and sakamakismile/Qwen3.6-27B-Text-NVFP4-MTP. The author's hardware supports native NVFP4 computation, making this format essential for their use case. The source of the weaker result has not yet been separated from the quality of the specific build and the quantization itself.

Thinking was disabled during the test. This matters: any potential advantage Qwen 3.8 may have in thinking mode does not solve the needs of a one-pass pipeline, where predictable latency, factual fidelity, and a strict output structure are required.

Why the update does not yet look like an upgrade

The conclusion is narrow but useful: in this NVFP4 scenario, Qwen 3.6 proved safer as a production component. A validator can catch ten malformed responses, but more frequent factual distortion requires separate content checks and quickly consumes any benefit from changing models.

I would first separate three possible sources of the problem: base-model behavior, NVFP4 quantization quality, and the specifics of the particular repack. This test does not prove that 3.6 is generally better than 3.8, but it clearly illustrates the cost of upgrading too quickly based on a version number.

For now, the key unanswered question is not whether Qwen 3.8 is stronger overall, but whether its advantage remains after compression and after disabling the mode it may rely on.

We previously compared the accuracy and hallucination risks of AI meeting-summary tools in business workflows. Those findings provide useful context for interpreting Qwen 3.8's errors in call center analytics.