MoE 模型压缩魔法：2GB 内存跑 Gemma 26B 的权重共享方案

系列第二篇：从“能跑”到“怎么跑”，深入 TurboFieldfare 的工程魔法。

在上一篇教程中，我们体验了 TurboFieldfare 如何在 2GB 内存中运行 Gemma 4 26B MoE 模型。今天，我们将拆开这台“性能魔术机”，看看它背后究竟采用了哪些工程手段，以及为什么这些手段能在 Apple Silicon 上发挥出惊人的效果。

1. Shared Weights 机制：挤干 26B 参数中的“水分”

Gemma 4 26B 是一个 Mixture-of-Experts（MoE）模型。与传统 Dense 模型不同，MoE 的 26B 参数并非全部参与每次推理。它的架构大致如下：

Total Params: 26B
├── Embedding + Output: ~2B
├── Shared Dense Layers: ~1B
└── 64 个 Expert 模块: ~23B
    ├── Expert 1: ~360M
    ├── Expert 2: ~360M
    └── ... (每个 Expert 结构相同)

关键洞察：这 64 个 Expert 的结构完全相同，每个都是拥有 360M 参数的前馈网络（FFN），只是训练得到的权重不同。

TurboFieldfare 的核心创新是：既然 Expert 的结构相同，为什么不共享大部分权重？

# 传统 MoE 存储方式
expert_weights = [expert_1_ffn, expert_2_ffn, ..., expert_64_ffn]  # 23B params

# TurboFieldfare 共享方式
shared_ffn_base = load("shared_ffn_base.bin")  # ~2.1B params
expert_routers = load("expert_routers.bin")     # 64 × 1M params (路由向量)

模型文件的体积直接从约 13GB（FP16）降至约 1.1GB（经过 4-bit 量化后）。

这个设计的理论基础是 LoRA（Low-Rank Adaptation）思想的延伸。MoE 中的 Expert 权重存在大量冗余，它们共享低秩子空间。TurboFieldfare 通过学习一个共享基底以及每个 Expert 的低秩偏移，在保持精度的同时大幅压缩存储空间。

// Metal Shader 中的权重恢复
kernel void load_expert_weights(
    device const float4* shared_base,
    device const float4* expert_offset,
    device float4* output,
    constant uint& expert_id
) {
    uint idx = thread_position_in_grid;
    output[idx] = shared_base[idx] + expert_offset[expert_id * stride + idx];
}

2. SSD 流式加载：让存储成为内存的延伸

MoE 推理具有稀疏性：每个 token 只会激活 2～4 个 Expert（Top-K 路由）。这意味着在 64 个 Expert 中，最多只有 6% 的权重会被实际使用。

推理循环:
1. 加载共享基底 (常驻内存)
2. 接收输入 token
3. MoE Router 决定激活哪些 Expert
4. 从 SSD 流式加载这些 Expert 的偏移量
5. 送入 GPU 计算
6. 计算完成后释放 Expert 权重

Apple Silicon SSD 的速度优势

这里有一个关键数字：M 系列芯片的 SSD 读取速度可达 5～7GB/s。

单个 Expert 偏移量：~360M params × 0.5 bytes = 180MB
加载时间：180MB / 6GB/s ≈ 30ms

GPU 计算单个 Expert 大约需要 50～100ms。SSD 的加载速度比 GPU 的计算速度快 2～3 倍，因此完全不会成为瓶颈。

TurboFieldfare 实现了 LRU 缓存：

缓存容量：8 个 Expert（~1.4GB）
命中率：约 85%（相邻 token 路由到相似 Expert）
SSD 读取次数：减少 85%，平均每 token 仅 0.3 次 SSD 读取

3. 4-bit 分组量化：将内存占用压缩到极限

TurboFieldfare 采用 GPTQ 风格的分组量化（group_size=128）：

原始 FP16 模型：26B × 2 bytes = 52GB（不可行）
4-bit 量化后：26B × 0.5 bytes = 13GB（仍太大）
共享权重 + 4-bit：2.1B × 0.5 bytes = 1.05GB ✅

完整的内存占用如下：

模型权重：1.05GB
KV Cache (4096 context)：~0.7GB
激活值 + 中间缓冲：~0.25GB
总计：~2GB ✅

4. Swift + Metal 引擎：为什么不用 llama.cpp？

llama.cpp 采用 CPU 优先设计，Metal 支持是后续加入的，因此 GPU 利用率不高。

它对 MoE 的优化也不够充分，没有针对稀疏路由进行专门优化。

TurboFieldfare 使用 MPS 矩阵乘法和自定义 MoE Kernel，一次调用即可处理多个 Expert。配合 Metal 向量化指令，其速度比 llama.cpp 快 60% 以上。

┌─────────────────────────────────────────────────────────────┐
│                    TurboFieldfare 架构                       │
├─────────────────────────────────────────────────────────────┤
│  ┌──────────┐    ┌──────────────┐    ┌─────────────────┐   │
│  │   SSD    │    │  Shared      │    │  Metal GPU      │   │
│  │ 存储     │───▶│  Weights     │───▶│  Buffers        │   │
│  │ • 共享基底│    │  Cache       │    │ • 输入嵌入      │   │
│  │ • 专家偏移│    │  (常驻内存)   │    │ • 注意力计算    │   │
│  │ • 路由表 │    │  ~1.05GB     │    │ • FFN 计算      │   │
│  └──────────┘    └──────────────┘    └────────┬────────┘   │
│       │                                       │            │
│       │ 流式加载 (5-7GB/s)                    │            │
│       ▼                                       ▼            │
│  ┌──────────┐    ┌──────────────┐    ┌─────────────────┐   │
│  │ Expert   │    │  MoE Router  │    │  Active Expert  │   │
│  │ Selector │───▶│  (Top-K)     │───▶│  Selection      │   │
│  │ LRU 缓存 │    │              │    │  • 2-4 个 Expert│   │
│  └──────────┘    └──────────────┘    └─────────────────┘   │
│                                                             │
│  推理循环: 嵌入层 → N 层 Transformer (GPU+SSD 流式)         │
│           → 输出投影 → 采样                                  │
└─────────────────────────────────────────────────────────────┘

5. 当前限制

上下文瓶颈：当 context 达到 8192 时，KV Cache 需要 3.75GB，加上模型权重后总计约 4.8GB。

批量推理：仅支持 batch_size=1，这是由流式加载特性决定的。

精度损失：共享权重 + 4-bit 会带来约 2.8% 的精度损失（MMLU 基准）。

6. 未来优化方向

动态量化：重要 token 使用 FP16，普通 token 使用 4-bit。

预测性预加载：提前 1～2 步预加载 Expert。

多设备分布式：构建 SSD + RAM + VRAM 三级存储体系。

稀疏注意力：使用 Sliding Window Attention，将 KV Cache 的复杂度从 O(n) 降至 O(w)。

总结

TurboFieldfare 展示了软件工程的力量：不需要更昂贵的硬件，只需要更聪明的算法。通过共享权重、流式加载、量化优化和原生 Metal 引擎，它在 Apple Silicon 上实现了看似“不可能”的性能表现。

启示：在 AI 推理领域，对存储层级进行智能调度，可能比单纯追求算力更重要。

TurboFieldfare GitHub 仓库

Metal Performance Shaders 文档

如需采取进一步措施，可以考虑屏蔽此人和／或举报滥用行为。