@0xkeenz: Today I verified something I've been pondering for a long time. The official Qwen3.6 27B model has BF16 weights, but some quantized versions, like cyankiwi / Unsloth, convert some key weights to FP16 instead of keeping BF16. BF16 and FP16 have the same storage footprint, so why not just keep the original BF16 weights...?

X AI KOLs Timeline News
qwen bf16 fp16 quantization model-weights huggingface machine-learning

Summary

The author verified that converting the Qwen3.6 27B model weights from BF16 to FP16 does not cause numerical overflow, and pointed out that FP16 has higher mantissa precision, explaining why quantized versions use FP16 instead of keeping BF16.

Today I verified something I've been pondering for a long time The official Qwen3.6 27B model has BF16 weights, but some quantized versions, like cyankiwi / Unsloth, convert some key weights to FP16 instead of keeping BF16. BF16 and FP16 have the same storage footprint, so why not just keep the original BF16 weights...? I've been puzzled. I occasionally saw people mention this on Huggingface and Reddit. One claim is that FP16 is more friendly to some inference backends and older hardware, but I couldn't find discussions comparing the numerical ranges of these two formats. So I decided to look into it myself. Comparison of BF16 and FP16: BF16: 8-bit exponent + 7-bit mantissa, range approximately ±3.4×10³⁸ FP16: 5-bit exponent + 10-bit mantissa, range approximately ±65504 In terms of precision, FP16 has about 8 times more mantissa precision than BF16. In terms of numerical range, the maximum finite value of BF16 is about 2¹¹² times that of FP16, meaning BF16's range is vastly larger. So I wondered: could some of the original BF16 weights fall outside the ±65504 range? If so, converting BF16 to FP16 would cause numerical overflow and irreversible information loss. Instead of worrying, I decided to verify it myself. I downloaded the original Qwen3.6 27B model and checked all weights with a script. It turned out that all weights are within the FP16 numerical range; the maximum absolute value is only about 25.5... far from the FP16 limit of 65504. So my previous concern about BF16-to-FP16 conversion causing overflow was completely unnecessary! Since the actual weights never hit the FP16 range limit, FP16's higher mantissa precision actually makes it more suitable for storing key weights. This may be one reason why quantized versions like cyankiwi / Unsloth convert some key weights to FP16. Haha, another day of feeling foolish.
Original Article
View Cached Full Text

Cached at: 07/09/26, 09:40 AM

Today I verified something I’ve been纠结 about for a long time.

Qwen3.6 27B’s official original model uses BF16 weights. However, some quantized versions, like cyankiwi / Unsloth, convert some critical weights to FP16 instead of keeping them in BF16. BF16 and FP16 have the same storage footprint, so why not just keep the original BF16 weights…?

I’ve been puzzled. I saw occasional mentions of this issue on Hugging Face and Reddit. One explanation says FP16 is more friendly to some inference backends and older devices, but I couldn’t find discussions comparing the numerical ranges of the two formats. So I decided to look into it myself.

Comparison of BF16 and FP16

  • BF16: 8-bit exponent + 7-bit mantissa, range approximately ±3.4×10³⁸
  • FP16: 5-bit exponent + 10-bit mantissa, range approximately ±65504

From a precision perspective, FP16’s mantissa has about 8 times higher precision than BF16.
From a numerical range perspective, BF16’s maximum finite value is about 2¹¹² times larger than FP16’s — its numerical range is vastly larger than FP16’s.

So I started wondering: could some original BF16 weights fall outside the ±65504 range? If so, converting BF16 to FP16 would cause numerical overflow and irreversible information loss.

Instead of just worrying, I decided to verify. I downloaded the original Qwen3.6 27B model, ran a script examining all weights, and found that all weights were well within the FP16 numerical range. The maximum absolute value was about 25.5… far from the FP16 upper limit of 65504. So my earlier concern about BF16→FP16 conversion causing numerical overflow was completely unnecessary!

Since the actual weights never hit the FP16 range ceiling, FP16 — with its higher mantissa precision — is actually more suitable for storing critical weights. That might be one reason why quantized versions like cyankiwi / Unsloth convert some key weights to FP16.

Haha, another day I outsmarted myself into being foolish.

Similar Articles

Boole-1.7B: A 1-bit Qwen3-1.7B model that outperforms Bonsai-1.7B

Reddit r/LocalLLaMA

Precision Numerics 发布 Boole-1.7B，一个基于 Qwen3-1.7B 的 1-bit 量化模型，权重仅 247 MB（比 BF16 小 13.9 倍），在 10 项任务评测中达到 BF16 模型 85.9% 的平均分，超越 1-bit 的 Bonsai-1.7B 并接近 1.58-bit 的 Bonsai-1.7B。模型支持浏览器本地运行、vLLM 与 llama.cpp。