【免费下载链接】Ming-Image-0.1-Design-Layer-4bit项目地址https://ai.gitcode.com/hf_mirrors/mlx-community/Ming-Image-0.1-Design-Layer-4bit点击查看免费下载为什么4bit量化几乎不损失画质答案藏在Ming-Image-0.1-Design-Layer-4bit的混合量化策略里它并非把整个模型无脑压到4bit而是大头压4bit、敏感层保8bit、关键小部件保留全精度。这套模型是 inclusionAI 分层拆解设计模型 Ming-Image-0.1-Design-Layer 的 MLX 预量化版本专为 Apple Silicon 的 Mac 优化——能把 49.8 GB 的 bf16 版本压缩到 20.5 GB在 36 GB 内存的 Mac 上就能流畅运行而图层还原结果与 bf16 基准几乎一致误差在 0.2 dB 以内Ming-Image 分层拆解模型是什么先用一句话说清楚这个模型是干什么的图像分层拆解layer decomposition。你可以把它理解为一台设计稿拆解机输入一张海报、招牌或宣传图等设计稿它会输出多个独立的 RGBA 图层文字层、图形层、背景层……设计师可以直接拿去修改而不必在一张死板上重新做图。这正是仓库标签里image-to-image、layer-decomposition、graphic-design的含义完整说明见 README.md。模型由五个部分组成目录角色mllm/MoE 多模态大模型MLLM负责看懂设计稿connector/Qwen2-1.5B 连接器桥接视觉与语言空间transformer/DiT 扩散主干负责画出各图层vae/变分自编码器负责像素与潜空间互转mlp/f32 全精度的投影头生成最终条件信号混合量化全景谁被压到4bit谁被豁免了这是全文最核心的一张表。4bit 版本中每个组件被分配了不同的精度档位组件精度量化细节为什么这样选mllm/ MoE 大模型注意力、共享专家 MLP、256 个路由专家4bit权重量化group size 64参数最多约 17B是省显存的绝对大头connector/ Qwen2-1.5B 连接器8bit权重量化group size 64规模不大8bit 收益已足够transformer/ DiT 注意力与前馈8bit权重量化group size 64直接决定画质4bit 会造成真实损伤MoE 路由器、embedding、LayerNorm、Qwen2.5 ViT、mlp/ 投影头f32、vae/bf16 / f32 全精度不量化数值敏感或体量太小量化只会花钱不见效对应的配置文件都可以直接查证mllm/config.json 中bits: 4、transformer/config.json 中bits: 8、connector/config.json 中bits: 8三者都写着group_size: 64。4bit为什么在这里行得通3个关键设计决策1. 4bit 只给最不怕压的 MoE 大模型MoE混合专家结构里256 个专家每次前向只激活其中 8 个见 mllm/config.json 的num_experts: 256、num_experts_per_tok: 8。这意味着大量专家参数对单次推理的贡献稀疏即使单个权重精度降低错误也被稀释了。17B 参数量压到 4bit是整体压缩比49.8 GB → 20.5 GB的主要来源。2. DiT 绝不跌破 8bit——README 里写得很直白The DiT never goes below 8 bits: weight-only int4 on a DiT is real quality damage that buys no speed.扩散主干 transformer 是像素级画图的执笔者权重量化到 int4 会给图像带来肉眼可见的画质损伤却换不来任何速度提升——因为 Mac 上这类推理是内存带宽瓶颈8bit 和 4bit 的单步耗时差别不大。保 8bit是典型的花钱买不到东西那就别花。3. 小部件保留全精度路由器、ViT、VAE 与 f32 投影头MoE 路由器决定哪个 token 去哪个专家哪怕轻微扰动都会改变激活路径Qwen2.5 视觉编码器ViT负责最前端的图像理解VAE 负责最后的像素还原mlp/ 里的投影头以 float32 精度运行见 mlp/config.json。它们的共同点是参数少但对误差极其敏感全精度保存成本极低属于必须守住的底线。量化是怎么落盘的group size 64 的 affine 量化所有量化层都采用权重 affine 量化weight-only affine quantization、分组大小 64每 64 个权重共享一组缩放因子量化权重旁就存着对应的.scales和.biases张量。这一点在 mllm/model.safetensors.index.json 里一览无余——每个被量化的权重如attention.query_key_value.weight都有相邻的.scales和.biases条目未被量化的 norm 层则只有纯.weight。 一个很硬核的细节这套预量化权重与加载 bf16 快照后即时量化的每一个参数逐位一致bit-identical已经全参数验证过。也就是说Mac 端永远不必持有 49.8 GB 的 bf16 权重就能得到确定性的等效模型。画质与性能实测数据说话下面是官方门控测试GATE-RESULTS的关键结果测试内容为 5 张 512 分辨率 1 张 1024 分辨率的真实招牌静帧与 bf16 使用相同噪声指标bf168bit4bit图层重合成 PSNR相对输入24.4–33.7 dB与 bf16 差 0.1 dB与 bf16 差 0.2 dB每个用例都达标图层覆盖率—相同相同文字层外溢字符数最难用例263035内存与速度M5 MaxMLX buffer cache 上限 2 GB加载后常驻内存7.6 GB1024 分辨率、4–12 图层时峰值进程占用 20.0–20.6 GBMLXEngine 申报 7.9 GB 常驻 15.6 GB 激活内存 →36 GB 的 Mac 可以完整跑通请求上限为 12 图层速度12 步、CFG 2.0、512 桶4bit 为 134 秒bf16 为 131 秒——基本持平印证了量化主要解决的是内存问题不是速度问题。如何在 Mac 上使用这个4bit模型该仓库配合 Swift/MLX 移植版 ming-image-swift 加载核心是选定 int4 档位后直接load()let package MingImageLayerPackage(configuration: MingImageLayerConfiguration(quant: .int4)) try await package.load() let response try await package.run(LayerDecomposeRequest(image: design, spec: spec, resolution: 1024))获取仓库权重体积较大需 LFS 拉取真实文件git clone https://gitcode.com/hf_mirrors/mlx-community/Ming-Image-0.1-Design-Layer-4bit去噪流程由 scheduler/scheduler_config.json 定义的 FlowMatchEuler 调度器驱动shift: 6.0与 bf16 版本共用同一套推理管线无需任何额外配置。总结4bit不损失画质的3条启示量化不是开关而是分配把最重的参数MoE 专家压到 4bit把最敏感的环节DiT、路由器、VAE留在 8bit/全精度画质自然稳如泰山先想清楚瓶颈在哪内存受限的 Mac 上省 29 GB 权重是刚需而速度收益有限——所以宁可保守一点保住画质可验证的承诺量化参数与即时量化逐位一致、门控测试给出逐例对比让几乎不损失画质成为可复现的结论而不是一句口号。如果你有一台内存不太充裕的 Mac又想用上 Ming-Image 的设计稿分层拆解能力这个 4bit 档位就是为它准备的 ✅赞分享【免费下载链接】Ming-Image-0.1-Design-Layer-4bit项目地址https://ai.gitcode.com/hf_mirrors/mlx-community/Ming-Image-0.1-Design-Layer-4bit点击查看免费下载相关推荐为什么4bit量化几乎不损失效果Fara1.5-4B-OptiQ-4bit混合精度量化原理深度解析为什么4bit量化几乎不损失效果Fara1.5 4B OptiQ 4bit混合精度量化原理深度解析 为什么 4bit 量化模型几乎不损失效果本文以 Fara大模型多模态本地部署模型量化AI AgentMing-Image-0.1-Design-4bit量化策略深度解析为什么MLLM压到4-bit而DiT绝不低于8-bitMing Image 0.1 Design 4bit量化策略深度解析为什么MLLM压到4 bit而DiT绝不低于8 bit Ming Image 0.1 D为什么4-bit量化几乎不损失精度gemma-3-12b-it-unsloth-bnb-4bit的NF4与Unsloth动态量化原理揭秘为什么4 bit量化几乎不损失精度gemma 3 12b it unsloth bnb 4bit的NF4与Unsloth动态量化原理揭秘 想让 120创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
阅读完成 · 觉得有帮助?