观潮 · 模式预报与气象 AI 观察
mradermacher 的 GGUF 量化合集：把天气垂域模型压成可在本地跑的推理文件，Q2_K 到 IQ4_XS 六档可选
Hugging Face 上有一个专门做 GGUF 量化发布的账号，mradermacher。他在 2026 年 9 月 21 日把 qwen3-0.6b-weather-geo-specialist 量化成了一整套 GGUF 文件。同一个账号下还有一个 DeepSeek-R1-Weather-control-COT-GGUF，最后更新时间是 2025-07-11。
这类仓库不是模型本身，而是模型的分发渠道——原始训练在别人的仓库上，mradermacher 做的是把权重转成 GGUF 格式并按不同量化级别出一整套。理解这一点很重要：模型的能力边界由基座模型决定，量化只影响体积、速度和精度损失。
天气垂域 GGUF 仓库清单
当前能看到的这类仓库：
仓库 · 基座模型 · 最后更新 · 近30天下载
`mradermacher/qwen3-0.6b-weather-geo-specialist-GGUF` · oopere/qwen3-0.6b-weather-geo-specialist · 2026-09-21 · 566
`mradermacher/DeepSeek-R1-Weather-control-COT-GGUF` · atzuke/DeepSeek-R1-Weather-control-COT · 2025-07-11 · 225
qwen3-0.6b-weather-geo-specialist 的规格
从模型卡标签能读出的信息：
项 · 值
基座 · oopere/qwen3-0.6b-weather-geo-specialist
许可证 · apache-2.0
训练/评测数据集 · Salesforce/xlam-function-calling-60k
近 30 天下载 · 566 次
点赞 · 0
标签里有一组词值得单独看：function-calling、tool-calling、lora、peft、sft、trl。
function-calling 和 tool-calling 加上训练数据集 Salesforce/xlam-function-calling-60k（xLAM 是 Salesforce 的函数调用数据集）说明：这个模型的训练目标是让模型学会调用外部工具/API，而不是直接给出答案。
其他标签 lora/peft/sft/trl 表明基座是用 LoRA 微调的，trl 是 TRL（Transformer Reinforcement Learning）库，训练流程走的是 SFT（监督微调）。small-language-model 标签与 0.6B 的参数量一致。
这一点对使用者的含义是：这个模型大概不是用来"聊天气"的，而是用来把自然语言请求转成对气象 API 的函数调用参数。它能不能调通，取决于你手上有没有可调的 API——模型本身不产生数据。
提供哪些量化档位
仓库里提供的 GGUF 文件（按体积从小到大）：
```
qwen3-0.6b-weather-geo-specialist.IQ4_XS.gguf
qwen3-0.6b-weather-geo-specialist.Q2_K.gguf
qwen3-0.6b-weather-geo-specialist.Q3_K_L.gguf
qwen3-0.6b-weather-geo-specialist.Q3_K_M.gguf
qwen3-0.6b-weather-geo-specialist.Q3_K_S.gguf
qwen3-0.6b-weather-geo-specialist.Q4_K_...
```
DeepSeek 那个仓库的档位一致：
```
DeepSeek-R1-Weather-control-COT.IQ4_XS.gguf
DeepSeek-R1-Weather-control-COT.Q2_K.gguf
DeepSeek-R1-Weather-control-COT.Q3_K_L.gguf
DeepSeek-R1-Weather-control-COT.Q3_K_M.gguf
DeepSeek-R1-Weather-control-COT.Q3_K_S.gguf
DeepSeek-R1-Weather-control-COT.Q4_K_...
```
IQ 和 K 两类量化命名对应 GGUF 生态里两套不同的量化方案，Q3_K_S / Q3_K_M / Q3_K_L 是同一量化级别下的小/中/大三个变体（K-quant 系列的 L/M/S 后缀表示同级别里不同的权重与激活量化配比）。
模型卡里有一条选型提示：表格按体积排序，不按质量排序；并且指出同体积下 IQ 量化通常优于非 IQ 量化。
这一点值得记一下：如果你只想下一个文件，不要按表格顺序拿第一个。
这张图解释了上面那条提示的含义。横轴是 bpw（bits per weight，每权重比特数），纵轴是 PPL(Q)/PPL(fp16) (%)，即量化后困惑度相对 fp16 原版的百分比——数值越小越好。图上四组分别是：Pre-imatrix k-quants（黑）、Pre-imatrix legacy quants（蓝）、imatrix i- and k-quants（红）、imatrix legacy quants（品红）。红色虚线是拟合曲线 1062exp(-1.66463bpw)。
图上最值得读的一点：同样bpw 下，红色（imatrix）曲线整体位于黑色（pre-imatrix）曲线的左下方，也就是同样的体积下困惑度更低——这就是"同体积下 IQ 量化更优"的实际依据。图上把 IQ4_XS 单独用青色标出，位置在 bpw 约 4.25 处，困惑度已经落到 1% 附近，是这张图上唯一进入"几乎无损"区间的 IQ 档位。
*代价也在图上：imatrix 需要额外的矩阵计算步骤（所以叫 imatrix），而且最激进的档位已经不可用——IQ2_XXS 和 IQ2_XS 的困惑度都超过 10%，IQ2_S、IQ2_M 也在 5%~10% 之间。这条边界很清楚：bpw 低于 2.5 的档位，量化后的模型已经不是原模型了。
另外注意黑线的非单调性：Q2_K（bpw 约 3.35）到 Q3_K_S（约 3.6）之间困惑度上升，之后才继续下降。所以同一族K-quant 里，档位命名顺序和体积顺序不完全等价，Q2_K 并不是"最差的"。
怎么用
模型卡指向 TheBloke 的 README 作为 GGUF 使用指南，包含多文件拼接（concatenate multi-part files）的说明：
https://huggingface.co/TheBloke/KafkaLM-70B-German-V0.1-GGUF
实际使用流程是三步：
- 从仓库里挑一个量化档位的
.gguf文件下载； - 用 llama.cpp 或支持 GGUF 的推理框架加载；
- 如果模型是多文件分片（split files），按README 里的拼接方式合并成一个文件再加载。
关键点是第1 步挑哪个文件。0.6B 的模型即使最大的档位也不到 1.5 GB，本地跑没有体积压力，所以应该优先挑保真度更高的档位（Q4_K 或 IQ4_XS 以上），而不是为了省几百 MB 去用 Q2_K——按图里的曲线，IQ2_XS 的困惑度已经超过原版的 10%，属于不可用区间；而 IQ4_XS 落在困惑度接近 1% 的位置，是这张图上唯一进入"几乎无损"区间的 IQ 档位。
怎么用图来选，而不是靠命名猜。 图里给出了各档位在 bpw—困惑度平面上的相对位置，可以直接读出三条经验规则：
第一，红线（imatrix）整体在黑线（pre-imatrix）的左下方，所以同体积下选 imatrix 档位更优。这也解释了模型卡为什么特意提示"同体积下 IQ 通常更好"。
第二，bpw 低于 2.5 的档位已经不可用。图上 IQ2_XXS 和 IQ2_XS 的困惑度都超过 10%（IQ2_XXS 是全图最高点），IQ2_S 和 IQ2_M 落在 5%–10% 之间。这条边界很清楚：再往下压，量化后的模型已经不是原模型了。
第三，同族里档位不是单调的。黑线上 Q2_K 到 Q3_K_S 之间困惑度是上升的，所以不能按"名字里的数字越大越好"来选——Q3_K_S 在图上比 Q2_K 略差，要到Q3_K_M 才明显好转。命名和体积顺序不完全等价。
另外Q4_0 和 Q4_1（蓝色 legacy quants）在图上几乎水平叠在一起，困惑度相当，但横跨了 4.4 到 5.0 的 bpw 区间。拿 0.6 bpw 的体积换几乎相同的精度，这笔交易不划算——除非可用内存刚好卡在这两个数之间。
还有一个实践上的点：imatrix 档位（红色和品红）需要额外的矩阵计算步骤才能生成，所以不是所有工具链都能直接产出。你在本地转换权重时，如果工具不支持 imatrix，就只能拿到黑线和蓝线那两组，精度上限也就是 1% 附近那一档。
同批抓到的另外几个天气垂域模型
当天素材里一共抓到五个 Hugging Face 天气相关模型卡，性质不完全一样：
仓库 · 性质 · 最后更新
`mradermacher/qwen3-0.6b-weather-geo-specialist-GGUF` · 第三方量化，本文主体 · 2026-09-21
`mradermacher/DeepSeek-R1-Weather-control-COT-GGUF` · 同一方量化，命名与档位一致 · 2025-07-11
`weathermanj/NVIDIA-Nemotron-Nano-9B-v2-gguf` · 另一量化方，主体是 NVIDIA Nano 9B 变体 · 2025-08-29
`lschaffer/ministral-3b-weathersensorsmcp-ollama` · 另一量化方，主体是 Ministral 3B变体 · 2026-06-07
`prithivMLmods/Weather-Image-Classification` · 图像分类模型，不是量化件，单独成篇 · 2025-05-07
后两个的命名风格和档位体系与mradermacher 的不一样，不能直接横向对比体积。第五个不是语言模型的量化件，是天气图像分类模型，另有一篇。
作者承认的限制
- 模型卡的 About 段落只有一句："static quants of https://huggingface.co/oopere/qwen3-0.6b-weather-geo-specialist"——这明确说明是第三方量化，不是自己训练的模型。
- 量化表格里没有给出任何精度损失评测（没有 perplexity、没有 benchmark）。模型卡只说明"这是量化版本"，没有说明量化前后模型的指标差异。
- 模型卡里没有说明原始模型的评测指标——它只是引用了基座模型的链接，没有复述基座的性能数据。
- 模型卡没有说明这些 GGUF 是用什么工具、什么量化配置（bit 分配、重要性矩阵来源）生成的。
另外需要注意的一点：DeepSeek-R1-Weather-control-COT-GGUF 的最后更新是 2025-07-11，距今已有一年多。GGUF 格式和量化工具都在演进，这个时间点生成的量化文件可能用的是较早的格式版本。
一句话判断
这类仓库的价值是让垂域小模型能在本地 CPU 上跑起来——0.6B 的模型量化后体积很小，适合做本地推理或嵌入到边缘设备。但因为量化方不评测、也不复述基座性能，选型时应该直接去基座模型仓库看评测数据和训练数据说明，别把量化仓库的模型卡当成技术文档看。