@0xkeenz: 今天验证了一个纠结很久的事情 Qwen3.6 27B 官方原模型是 BF16 权重，但一些量化版本，比如 cyankiwi / Unsloth，会把部分关键权重转换成 FP16 而不是保持 BF16。BF16 和 FP16 在存储占用上是…

今天验证了一个纠结很久的事情 Qwen3.6 27B 官方原模型是 BF16 权重，但一些量化版本，比如 cyankiwi / Unsloth，会把部分关键权重转换成 FP16 而不是保持 BF16。BF16 和 FP16 在存储占用上是相同的，那为什么不直接保持原始 BF16 权重呢···？ 我一直很疑惑，我看 Huggingface 和 Reddit 偶尔也有人提到这个问题，有一个说法是 FP16 对部分推理后端和老设备更友好，但我没找到这两种格式数值范围相关对比的讨论内容。于是我自己研究了一下 BF16 和 FP16 的对比： BF16：8位指数 + 7位尾数，范围约 ±3.4×10³⁸ FP16：5位指数 + 10位尾数，范围约 ±65504 从精度上来看，FP16 尾数精度比 BF16 高 8 倍左右。 从数值范围来看，BF16 的最大有限值约是 FP16 的 2¹¹² 倍，其数值范围远远大于 FP16。 所以我在想，BF16 原权重会不会有部分数值在 ±65504 之外的情况？如果确实存在，那 BF16 转换成 FP16 就会发生数值溢出，导致不可逆的信息丢失。 光纠结没有用，我决定自己验证下，我下了 Qwen3.6 27B 原模型，用脚本检查了所有权重，最后发现所有权重都在 FP16 的数值范围内，最大绝对值也就 25.5····离 FP16 的 65504 范围上限差的老远了，所以我之前老纠结 BF16 转换成 FP16 会导致数值溢出的担心完全没必要！！ 由于实际权重根本没碰到 FP16 数值范围上限，FP16 反而因为尾数精度更高，更适合用来保存关键权重，这可能也是 cyankiwi / Unsloth 这类量化版本会把部分关键权重转换成 FP16 的原因之一吧。 哈哈，又是被自己蠢哭的一天