企业官网建设流程全解析

Hemmingway-1-OptiQ-4bit 是一个面向 Apple Silicon 的混合精度 MLX 量化模型：它基于写作向的 Qwen3.5 27B 变体 Hemmingway-1，用敏感度分析决定哪些层保留 8-bit、哪些层压到 4-bit，把约 50.9 GB 的 bf16 权重压进 18 GB。本文讲清楚它的 KL 散度敏感度扫描、跨模型"配方迁移"以及验证结论的来龙去脉，适合想在 Mac 上本地跑写作模型的新手阅读。

Hemmingway-1-OptiQ-4bit 是什么：一张混合精度量化表

先说结论：这不是一个普通的"全 4-bit"量化包，而是一份逐层位宽分配表——219 个张量用 8-bit，279 个用 4-bit，共 498 个量化张量。

它由 MLX 生态的 OptiQ 工具链构建，目标是不需要 PyTorch、不需要云，直接在 Apple Silicon 上本地量化、加载和推理。完整的量化参数可以在 config.json 的quantization块里查到。

为什么混合精度值得做？把所有层"一刀切"压到 4-bit 最简单，但有些层天生对精度损失更敏感。敏感度分析要回答的正是：给每一层"分诊"，敏感层配 8-bit，耐造层配 4-bit，用尽量小的体积保住输出质量。

敏感度扫描：KL 散度如何给 498 个张量分级

这里要澄清一个容易误读的点：这份逐层位宽分配并不是在本模型上实测出来的。它来自基础同架构模型的 KL 散度敏感度扫描，再由本仓库"迁移"过来（下一节细讲）。

扫描的做法可以这样理解：

1. 准备一份覆盖 6 个领域的校准数据——prose（散文）、reasoning（推理）、code（代码）、agent（智能体）、tool-call（工具调用）、instructions（指令）；
2. 对每一层，把它压到 4-bit 后，用 KL 散度（KL divergence）衡量"量化前后输出分布差了多少"；
3. 差得越狠，说明这一层对精度越敏感，配方里就给它 8-bit。

也就是说，敏感度衡量的是"这一层在架构中的角色"能扛多少精度损失。这个配方最终落到了两处文件：

• optiq/metadata.json：recipe_reused_from和recipe_note字段直接写明了"配方是复用而非重测"；
• config.json：运行时真正读取的位宽分配。

分配出来的模式：哪些层是"重点保护对象"

对照 optiq/metadata.json 的per_layer表，可以归纳出清晰的规律：

几个值得记住的信号：

• 门控与读出通路被完整保护：线性注意力层的in_proj_a、in_proj_b、out_proj和全注意力层的v_proj、o_proj是 100% 8-bit，说明这些"信息出口"最经不起压缩；
• 第一层和最后一层全 8-bit：model.layers.0与model.layers.63的所有张量都是 8-bit，相当于给"入口"和"出口"加了两道保险；
• MLP 的 up_proj 最混合：约 1/3 是 8-bit，是整张表里最不均匀的角色，也最体现"逐层分诊"而非"一刀切"。

这个 48 + 16 的层数拆分不是巧合：config.json 里model_type为qwen3_5_text、64 层、full_attention_interval: 4，即每 4 层里 3 层线性注意力（linear attention）+ 1 层全注意力（full attention）。

配方迁移：为什么能"拿来就用"

这是本仓库最有意思、也最需要讲明白的部分。README 里原话很直白：逐层分配没有在本模型上测量，而是从同架构模型的 OptiQ 量化迁移过来的（见 README.md）。

迁移之所以成立，依赖两个条件同时满足：

条件一：架构逐位一致。两个模型共享完全相同的结构——qwen3_5_text、64 层、24 个注意力头、4 个 KV 头、head_dim 256、hidden 5120、词表 248,320。于是配方里的每一层，在本模型里都有一个"同角色、同形状"的对应层。

条件二：张量匹配零缺口。验证结果是498/498 张量全部命中配方，0 个未匹配。这一步才是真正要命的检查：只要有哪怕一个张量没匹配上，它会静默回退成扁平 4-bit，整包就变成"顶着混合精度名字的均匀量化"——表面看不出来，质量却已经打折。

optiq/metadata.json里的recipe_note也解释了复用逻辑：同架构变体的逐层敏感度结构相同，重跑一遍扫描也会得到这份分配。

迁移的诚实边界：它不能保证什么

README 同样坦诚地划了线：敏感度衡量的是"层在架构中的角色"，它无法知道本模型自己的训练是否已经把敏感度挪了位置。如果你拿它当基准、量化的是自己微调出来的模型，建议直接跑optiq convert让扫描重新测一遍——配方迁移是"同架构下的合理假设"，不是"免检通过"。

验证了什么：498/498 匹配与正确性抽查

发布前的检查清单（详见 README.md）包含三块：

注意抽查的标准是**"正确"而不只是"通顺"**——量化模型最常见的翻车方式不是胡言乱语，而是数字悄悄算错。

另外两点同样重要：

• 没有跑六指标 Capability Score。已发布的分数属于 Qwen3.5-27B 那个量化模型，描述的是它而不是本模型，所以这里不作主张；
• 写作风格的实测小探针（同一组提示词、同一组采样参数，对比基础 Qwen3.5-27B 量化版）：

句长才是区分人机文风的那根标尺：基础版落在 AI 中位数上，Hemmingway-1 落在人类中位数上。README 也提醒这是"小探针，不是基准测试"。

一键部署：在 Mac 上跑起来

最简路径只有两行命令（见 README.md）：

pip install mlx-optiq optiq serve --model mlx-community/Hemmingway-1-OptiQ-4bit

不想用服务方式的话，也可以直接用mlx-lm：load加载模型后，用apply_chat_template拼好提示词再调用generate，十几行就能出文。

采样参数建议沿用 generation_config.json 的设定：temperature: 1.0、top_k: 20、top_p: 0.95。

硬件方面：磁盘权重约 18 GB，加上 KV cache 和运行时开销，建议24 GB 及以上统一内存的 Apple Silicon 机型，16 GB 的机器会偏紧张。

仓库文件地图：每个文件在干什么

常见问题（FAQ）

Q1：叫 "4bit" 为什么还有一多半 8-bit 张量？命名取"主要精度"（predominant precision）。279 个 4-bit 张量是主体，219 个 8-bit 是敏感度扫描筛出来的"重点保护对象"，混合后体积仍比 bf16 小约 65%。

Q2：配方迁移和自己重新扫描，差别在哪？迁移省掉整轮扫描，代价是假设"训练没有改变各层的敏感度分布"——对同架构变体通常成立；但量化自己的微调模型时，跑一次optiq convert让 KL 散度扫描对着你的权重重新分级，才是严谨做法。

Q3：怎么确认这个包没有"静默回退"成均匀 4-bit？看两个数：n_quantized_layers: 498与layers_per_bit_width: {4: 279, 8: 219}（optiq/metadata.json），再抽查per_layer表里是否同时存在 4 和 8。全 4 就回退了。

Q4：为什么文章和 README 都不引用"六指标 Capability Score"？因为那组分数测的是同架构的另一个量化模型，直接拿来用属于张冠李戴——这也是这个仓库在文档上比较值得称道的一点：它把"验证了什么"和"没验证什么"分得很清。

小结

Hemmingway-1-OptiQ-4bit 的价值不在某个单点，而在一套可复现的方法论示范：用 KL 散度敏感度扫描给 498 个张量分级、用"架构一致 + 498/498 零缺口匹配"给配方迁移兜底、用正确性抽查而非流畅度来验收，并在文档里明确标出"没测的东西"。如果你在 Mac 上本地跑写作模型，或者想给自己的微调模型做混合精度量化，这套流程本身就是最值得抄走的部分。