DeepSeek-V4-Flash-0731-2.4bit-mixed是一个面向 Apple Silicon 的 MLX 混合精度量化模型仓库：基于 284B 总参数（含 3 个 MTP 块约 304B）的 DeepSeek-V4-Flash-0731，每个 token 仅激活约13.8B参数，采用 2bit/6bit/8bit 混合量化后整体压到2.44 bit/weight、92.8 GB 磁盘占用，让 32k 长上下文推理在一台 128 GB 内存的 Mac 上跑得起来。🍎

📋 模型速览：一张表看懂 DeepSeek-V4-Flash

它凭什么"瘦"下来？答案藏在四个机制里：MLA 压缩 KV 缓存、稀疏注意力索引器、MoE top-6 路由、混合精度量化。下面逐一拆解。🔍

🧠 MLA 多潜在注意力：KV 缓存不再随层数疯涨

传统多头注意力（MHA）里，每个 token 要为每个注意力头分别保存一份 Key 和 Value，KV 缓存显存随层数和上下文长度线性膨胀。MLA（Multi-head Latent Attention）的做法是：

1. 不把 Key/Value 原样存入缓存，而是先压缩成一个低秩 latent 向量再保存，用时再展开；
2. Query 和 Output 投影走两级低秩分解，进一步砍掉权重体积。

在 config.json 里可以直接看到 MLA 的指纹参数：

• q_lora_rank: 1024、o_lora_rank: 1024：Query 与 Output 投影的低秩秩；
• head_dim: 512、qk_rope_head_dim: 64：每个头的总宽度与其中负责旋转位置编码（RoPE）的维度；
• o_groups: 8：Output 投影按 8 组切分（grouped output projections），用更窄的中间矩阵分摊计算；
• num_key_value_heads: 1：KV 侧只剩 1 个"头"，因为信息已经被 latent 压缩了。

对应的张量命名也印证了这种分解结构：wq_a/wq_b（两级 Query 投影）、wkv（压缩 KV）、wo_a/wo_b（两级 Output 投影），全部可以在 model.safetensors.index.json 中查到。

对显存意味着什么？MLA 把 KV 缓存压得极紧，实测 32k 上下文比 1k 上下文的峰值内存只多1.03 GB——这几乎就是"长上下文不爆内存"的直接原因。📉

⚡ 稀疏注意力索引器：32k 上下文只算 512 个 token

光压缩 KV 还不够，注意力计算本身仍是 O(n²)。DeepSeek-V4-Flash 的解法是稀疏注意力索引器（sparse-attention indexer）：

• 每 2 层配一个索引器（位于第 2、4、6 … 42 层，共 21 个），它用 64 个索引头（index_n_heads: 64、index_head_dim: 128）给历史 token 打分，只选出最相关的512 个（index_topk: 512，见 config.json）进入真正的注意力计算；
• 最近邻信息由滑动窗口兜底：sliding_window: 128，保证局部上下文不丢；
• 配合compress_ratios参数（config.json 中4/128交替、首两层与末三层为0）对各层 KV 做不同倍率压缩，再用 YaRN（rope_scaling.type: yarn，外推 factor 16）把上下文窗口拉到 1M（max_position_embeddings: 1048576）。

效果非常直观：生成速度几乎不随上下文长度衰减——4k 上下文 33.8 tok/s，32k 上下文仍有 31.5 tok/s。🚀 因为不管 prompt 多长，真正参与注意力计算的 token 数量都被index_topk 512封顶了。代价在 prefill 阶段：32k 输入的首 token 延迟约 97 秒，长文档首次提问需要耐心。

🔀 MoE top-6 路由：284B 参数，只算 13.8B

MoE（Mixture of Experts）是这个模型"大参数、小算力"的核心：

每层专家的选择由门控网络完成（对应张量ffn.gate.weight、ffn.gate.tid2eid，见 model.safetensors.index.json），选中后按norm_topk_prob: true对 top-k 权重做归一化。43 层 × 256 个专家就是 284B 总参数的主体，而每个 token 实际流经的只有 6 个路由专家 + 1 个共享专家，激活参数约 13.8B。

一句话理解 MoE 省显存的逻辑：显存要"装下"全部专家，但算力和激活内存只需要服务其中 6 个——总参数越大模型越聪明，单 token 的计算却近乎恒定。🎯

🎚️ 混合精度量化：2bit / 6bit / 8bit / 3bit 分档压缩

权重省显存的最后一道关是量化。这个仓库没有"一刀切"，而是按"使用频率"分档（完整逐层配置见 config.json 的quantization_config）：

思路很简单：每 token 都要读的权重（注意力、词嵌入、输出头）保精度高，读得最少的 256 个路由专家放到最低位宽。整体平均 2.44 bit/weight，把原生 FP8+FP4 的 155 GB 压到 92.8 GB，且输出是标准 MLX affine 量化格式，不需要任何自定义 kernel。

📊 实测效果与运行门槛

作者在MacBook Pro M5 Max 128GB上用 oMLX 基准测试（单请求、128 生成 token）：

几个值得记住的结论：

• 生成端：长上下文几乎不掉速（稀疏注意力立功）；
• 内存端：32k 上下文峰值仅 80.8 GB（MLA 压缩 KV 立功），加上权重后短上下文峰值 84.4 GB，128 GB 内存是硬门槛；
• 精度端：mmlu_pro（n=600）得 0.573，比 bf16 官方 API 的 0.647 低 7.3 分——这是 2.44 bpw 量化应付费用的正常区间，但具体到你的工作负载前请先自行测试；
• 运行方式：需要 oMLX 0.5.7 及以上版本（mlx-lm 尚不支持deepseek_v4架构），模型可直接从缓存加载，使用omlx serve起服务即可。

✅ 总结：显存到底省在了哪里

四层机制叠加，才让一个 300B 级别的 MoE 模型"住进"了一台消费级工作站。如果你正在 128 GB 的 Apple Silicon 上寻找能跑长上下文的开源大模型，这个仓库值得放进你的测试清单。🔥