,很多朋友问:这么多量化版本,到底如何选择,本文就展开说说
![]()
先说结论
想让模型跑 Skill、调工具、做多步任务, 4bit 是底线
只是聊天,2bit 也能凑合,1bit 别奢望工具调用了
Q8 没必要强上, Q4 到 Q6 就很好了
24GB 显卡闭眼选
UD-Q4_K_XL,17.56GB27B 跑 Skills 质量够用, 速度是最大的短板
每次开源模型一出,肝神 Unsloth 总能第一时间发出量化版本
我发现这一次 unsloth/Qwen3.8-27B-GGUF 的动态量化技术升级到 3.0 了
它优化了校准数据集,之前是先拿一批语料跑一遍模型,看哪些权重在真实推理里更活跃,然后把宝贵的比特优先分给它们。所以校准语料喂什么,量化出来的模型就擅长什么,Dynamic v3.0 用的校准集是重新做的,专门往 agentic coding、对话、多语言三个方向分配了更多资源
另外 3.0 还加了更多量化技术,同样的磁盘占用,尽量少掉精度。小于 UD-Q2_K_XL 的那几个版本,Unsloth 干脆把 MTP 模块摘掉了,省 500MB,对 1bit 用户来说,500MB 比推测解码重要得多
还有就是, Unsloth 造了个新指标:Divergence-300 @32,用于测试量化后模型能力(看量化版本的输出轨迹和 BF16 能不能一路对齐),相比于之前的 top-1% ,确实更加科学,也更能看出问题
![]()
比如:UD-IQ1_S 只有 6.19GB,比原模型小了 89%,top-1% 还能保住 72% 左右,看着挺能用,换成 Divergence-300 @32,它掉到 8% 上下
量化到底损失了什么
Mean KLD 这张图,是我见过把量化损失讲得最清楚的一张
![]()
KLD 衡量的是量化模型和原模型输出分布的偏离程度,0 表示完全一致
Unsloth 引用了论文《Accuracy is Not All You Need》的观点:报量化误差应该用 KLD,用困惑度是错的,因为 token 之间的偏差会互相抵消
注意纵轴是对数刻度,所以曲线看着平缓,实际落差是量级级别的:
版本
体积
Mean KLD 量级
适用范围
UD-IQ1_S
6.19GB
~0.43
只能问事实
UD-Q2_K_XL
9.83GB
~0.09
聊天可用,工具勉强
UD-Q3_K_XL
13.15GB
~0.026
日常够用
UD-Q4_K_M
16.46GB
~0.010
干活起步线
UD-Q4_K_XL
17.56GB
~0.008
甜点区正中间
UD-Q6_K
21.98GB
~0.0024
追极致
Q8_0
29.05GB
~0.001
交智商税
把相邻两档的「花多少 GB 换多少倍」算出来:
从
UD-Q2_K_XL到UD-Q4_K_XL:多花 7.7GB,KLD 改善约 11 倍从
UD-Q4_K_XL到UD-Q6_K:多花 4.4GB,KLD 改善约 3.3 倍从
UD-Q6_K到Q8_0:多花 7GB,KLD 改善约 2.4 倍
拐点卡在 Q4,再往上,你花的每一 GB 的显存都只能换来越来越薄的收益,而这点收益已经薄到被采样随机性盖住了
我也看了不少测试,有些 Q4/6 甚至效果好过 Q8
你的机器该下哪个版本
Unsloth 给的硬件门槛表,单位是总内存,显存加内存或者统一内存都算:
1bit
2bit
3bit
4bit
6bit
8bit
BF16
7-8 GB
9-11 GB
12-14 GB
16-19 GB
23-26 GB
31 GB
56 GB
结合前面的损失曲线,我做了一张表
机器配置
推荐模型
体积
能干什么
8GB(3060Ti / 4060)
UD-IQ1_S
6.19GB
问事实、写短文,工具调用别想
12GB(3060 12G / 4070)
UD-Q2_K_XL
9.83GB
聊天顺畅,简单代码可以
16GB(4060Ti 16G / 4080)
UD-Q3_K_XL
13.15GB
日常主力,复杂 Skill 会翻车
24GB(3090 / 4090)
UD-Q4_K_XL
17.56GB
甜点区,Skill 能稳定跑
32GB(5090)
NVFP4
23.42GB
比 BF16 快 1.5 倍,Blackwell 专属
48GB+ / RTX PRO 6000
UD-Q6_K 或 NVFP4
21.98 / 23.42GB
想把精度押到顶
Mac 24GB 统一内存
UD-Q4_K_XL
17.56GB
能跑,慢,够用
Mac 32GB+ 统一内存
UD-Q5_K_XL
20.88GB
舒服区间
几个必须提醒的坑
门槛表里不含上下文
Qwen3.8-27B 原生 256K,KV cache 会额外吃掉一大块
24GB 卡跑 17.56GB 的 Q4_K_XL,别指望同时开满 256K,上下文按需给
NVFP4 只有 vLLM 能跑
Unsloth 把 lm_head 也量化成 FP8 了,vLLM 有对应 kernel,SGLang 加载不了
23.42GB 权重,batch=1 从 BF16 的 89.8 tok/s 提到 133.7,1.49 倍
采样参数思考模式和非思考模式是两套
这个特别容易踩
参数
思考模式
非思考模式
temperature
1.0
0.7
top_p
0.95
0.80
top_k
20
20
presence_penalty
0.0
1.5
非思考模式的 presence_penalty 是 1.5,不给它就容易循环输出
思考深度用 reasoning_effort 控制,默认 xhigh,本地跑建议先调到 medium
--chat-template-kwargs '{"reasoning_effort":"medium"}'
下载就一行
hf download unsloth/Qwen3.8-27B-GGUF \
--local-dir unsloth/Qwen3.8-27B-GGUF \
--include "*UD-Q4_K_XL*"
本地 27B 最适合执行 Skills我个人觉得,27B 模型最适合的应用场景是执行 Skills
先读什么文件、调什么工具、遇到错误怎么处理、最后怎么验收,全都提前写死
它约束了模型自由发挥的空间,也让每一步的执行结果都能反复检查
一个 4bit 的 27B,配上写得够细的 Skill,交付质量比我预期高不少
我拿 Qwen3.8-27B 挑了三个难度不低的 Skill(测试驱动的 Bug 修复、复杂 Excel 清洗对账、长视频理解),全在本地跑,都需要多不执行,多次工具调用
代码和业务数据全程不出本地、高频跑也没有 Token 账单,这两条对我来说是硬需求。最严重的缺点:慢!!!
Skills 这类任务的特点是要生成大量中间产物——思考、工具调用、错误重试、验收检查,token 消耗是聊天的好几倍,我测试这几个任务时,Qwen3.8-27B 慢的有点难以忍受
总结
单说 Skills 执行任务,Qwen3.8-27B 这个稠密模型卡在了一个尴尬的位置:质量刚好够交活,速度刚好不够爽
我感觉真正的解法是同等激活量、更大总参数的 MoE,比如,如果这个模型 的 Skills 执行能力真能追上 Qwen3.8-27B,那本地 Agent 的体验会是另一个次元的事情
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.