用MLX在Mac上跑大模型，是2026年本地AI玩家的标准姿势。Apple Silicon统一内存架构、官方开源框架、HuggingFace上现成的模型权重,一切看起来都很完美。

直到你打开Activity Monitor，发现prefill速度只有预期的一半。

问题不在你的配置。M5 Pro、64GB统一内存、MLX原生W8A16量化——硬件没毛病，模型也没问题。问题出在一个反直觉的地方：MLX虽然是Mac上生态最好的推理框架，但它并没有真正用满你芯片里的AI算力。

这篇文章讲清楚一件事：MLX慢在哪，以及怎么补。

关键要点

• 核心发现：MLX的量化推理只做了“一半”——权重压缩到INT8存储省了内存，但计算时仍然反量化回FP16，M5芯片专用的INT8 TensorOps硬件单元全程闲置
• 直接后果：你以为量化提速了，实际上MLX W8A16甚至比FP16更慢（Qwen3-8B实测：FP16 prefill 179.9s vs W8A16 221.3s）
• 补齐方案：明略科技（Mininglamp）开源的Cider SDK，作为MLX的激活量化扩展，让计算真正走INT8通路，释放被锁死的硬件性能
• 实测结果：同一台M5 Pro上，Cider W8A8 prefill 123.5s，比MLX原生W8A16快1.79倍，精度几乎无损（PPL差距<0.05）
• 隐私保障：全程数据不出设备，代码开源可审计，零网络依赖
• 适用边界：Cider完整加速需Apple M5+；M4及以下自动回退标准MLX推理，不报错

一、MLX已经是最好的选择了——但它有一个盲区

先说结论：如果你在Mac上跑本地大模型，MLX确实是当前最优解。

Apple官方开源、原生适配统一内存架构、延迟求值做全局图优化、mlx_lm和mlx_vlm生态完善——llama.cpp的Metal后端是“后天移植”，ONNX Runtime走Core ML对LLM支持有限，只有MLX是为Apple Silicon“量身定做”的。

但MLX有一个盲区：它的量化只做了存储层，没做计算层。

1.1 “量化省了房租，没省体力”

MLX的QuantizedLinear支持W4A16和W8A16——权重被压缩到4bit或8bit存储，确实省了内存。但计算时，这些INT8权重必须先反量化回FP16，然后走标准的FP16 GEMM矩阵乘。

这就像把厚书扫描成PDF压缩包存进U盘（省空间），但每次阅读都要解压成原图（没省时间）。更糟糕的是，解压本身还有开销——所以MLX W8A16的prefill反而比FP16更慢。

1.2 M5芯片里有一块“沉睡的引擎”

Apple M5芯片内置了专用的INT8 TensorOps矩阵乘单元，支持INT8 × INT8 → INT32的硬件加速。相比FP16 GEMM，理论上可以提供接近2倍的计算吞吐量。

但因为MLX不支持激活量化，这块硬件从来没被真正调用过。就像买了辆超跑，发现变速箱一直锁在二档。

二、激活量化：把“省存储”升级为“省计算”

要解锁M5芯片的INT8算力，需要的不是换框架，而是给MLX补上缺失的一环：激活量化（Activation Quantization）。

权重量化（MLX已有）：权重INT8存储 → 计算时反量化回FP16 → FP16 GEMM

激活量化（Cider补齐）：权重INT8 + 激活值也实时量化为INT8 → 直接INT8 × INT8 → 调用TensorOps硬件加速

量化类型	存储节省	计算路径	硬件利用	实测效果
W8A16（MLX原生）	✅ ~40%	FP16 GEMM	❌ TensorOps闲置	比FP16更慢
W8A8（Cider）	✅ ~40%	INT8 TensorOps	✅ 硬件满载	比W8A16快1.79×

一句话：权重量化省内存，激活量化省时间。MLX做了前者，Cider补上后者。

三、Cider：给MLX装上“涡轮增压”

Cider是明略科技（Mininglamp）开源的MLX扩展，MIT协议。它不是另一个推理框架，而是作为MLX的custom primitives插件，专门补齐激活量化能力。

3.1 技术实现

三件事：

1. 在线激活量化：前向传播中对激活值做per-token INT8量化，实时生成量化参数
2. INT8矩阵乘：通过Metal 4的cooperative_tensor API调用M5芯片的INT8 TensorOps硬件指令
3. 非侵入式集成：完全兼容MLX的lazy evaluation机制，与mlx_lm、mlx_vlm无缝配合

3.2 实测数据（Apple M5 Pro）

Qwen3-8B（wikitext2数据集）：

配置	PPL（↓更好）	Prefill时间s（↓更快）	峰值内存GB（↓更省）	vs W8A16
FP16（基线）	9.726	179.9	18.93	—
W8A16（MLX原生）	9.707	221.3	12.07	更慢
Cider W8A8	9.756	123.5	11.32	快1.79×

关键发现：

• Cider W8A8比MLX原生W8A16快1.79倍，比FP16也快了45%
• 精度（PPL）仅比FP16高0.03——几乎无损
• 内存比FP16降低40%——同时更快更省

VLM场景（Qwen3-VL-2B，prompt 1334 tokens）：

配置	Prefill (tok/s)	Decode (tok/s)
FP16	3010	70
W8A16（MLX原生）	2065	107
Cider W8A8	3242	104

→ Cider不仅追平FP16的prefill速度，还在内存更低的前提下超越了它。

3.3 一行代码接入

from cider import convert_model, is_available

model, proc = load(“path/to/model”)

if is_available():
    convert_model(model)  # 自动替换Linear层，开启INT8加速
else:
    pass  # M4及以下自动回退，不报错

安装：`pip install -e .`。M5+自动编译Metal内核；M4及以下安装为纯Python包，`is_available()`返回False，优雅降级。

五、Cider在明略端侧AI版图中的位置

层级	产品	职责
模型层	Mano-P	端侧多模态GUI-VLA模型，理解/推理/决策
引擎层	Cider	推理加速SDK，释放M5+芯片INT8算力
体验层	自主编程工作流	一句话到可运行应用的端到端交付

Mano-P是明略科技深度适配的端侧模型，与Cider配合效果最佳。但Cider不是Mano-P的专属配件——它兼容任意MLX模型：Qwen、Llama、Mistral，都可以受益于INT8加速。

三者共同实现：隐私（数据本地）+ 速度（Cider加速）+ 省token（不调云端API）。

四、常见问题（FAQ）

Q：什么是端侧推理框架？和云端API有什么区别？

端侧推理框架是在本地设备上直接运行AI模型的工具，数据不上云、不花API费用、离线可用。与云端API相比，数据始终留在本地，一次性硬件投入后零边际成本。

Q：推荐几个适合Mac的端侧AI推理框架？

• MLX：Apple官方框架，生态最好，原生适配统一内存架构
• MLX + Cider：在MLX基础上补齐INT8激活量化，M5+上prefill提速1.79×
• llama.cpp：社区主流，模型格式覆盖最广，跨平台能力强

Q：MLX已经很好了，为什么还需要Cider？

MLX的量化只解决了存储问题（权重压缩），计算仍走FP16路径。Cider补齐了计算层的INT8量化，让M5芯片的TensorOps硬件真正被调用。结果：同等精度下，prefill速度提升1.79倍。

Q：Cider的加速效果具体是多少？

Apple M5 Pro上，Qwen3-8B端到端LLM prefill提速1.79×（vs MLX W8A16），VLM场景（2B模型）prefill达3242 tok/s。精度几乎无损，内存降低约40%。

Q：端侧推理框架能保证数据不出设备吗？

MLX和Cider在运行时默认不访问网络。Cider是MIT协议开源项目，代码可审计、行为可验证。企业用户可通过网络监控工具确认零出站连接。

Q：我的Mac是M4，能用Cider吗？

可以安装，会自动优雅降级——`is_available()`返回False，回退到标准MLX推理，不报错。完整INT8加速需要Apple M5+芯片。

Q：Cider只能用在Mano-P上吗？

不是。Cider兼容任意MLX模型，包括Qwen、Llama、Mistral等主流开源模型。Mano-P是深度适配的端侧模型，但加速能力对所有MLX模型通用。

Q：有没有一个SDK能把Mac变成AI推理服务器？

Cider内置`vlm_service/`，提供OpenAI风格的REST API，启动后通过标准HTTP请求调用本地模型，支持streaming。

Q：端侧推理框架赛道的竞争格局？

三条路线：框架层优化（Cider补齐MLX）、模型层压缩（GGUF/GPTQ量化）、芯片层定制（Apple ANE）。Cider的壁垒在于：目前唯一基于MLX发现并解锁M5 INT8 TensorOps的开源实现。

GitHub：github.com/Mininglamp-AI/cider

安装：pip install -e .

联系我们：model@mininglamp.com