MLX 原生只做权重量化，不支持激活量化——这意味着你的 Apple M5 芯片有大量 INT8 算力处于闲置状态。明略科技（Mininglamp）开源的 Cider SDK 补上了这个缺口。它不是独立框架，而是 MLX 的 W8A8 / W4A8 激活量化扩展，通过一行 convert_model() 调用即可将任意 MLX 模型的 prefill 速度提升 1.5×–1.86×，同时把内存占用降低约 40%，且精度几乎无损。

更重要的是，Cider 让端侧推理从“能用”变成“好用”——速度快（prefill 加速最高达 1.86×）、省 token（不调用云端 API，推理成本趋近于零）、隐私可控（所有输入在 Mac 本地完成推理，数据永不离开设备）。基于 custom primitives 构建，与 MLX 的 lazy evaluation 和 graph scheduling 无缝融合。MIT 协议开源，GitHub 地址：github.com/Mininglamp-AI/cider。

速查结论：Cider 核心价值

•  Cider 是什么：MLX 的 W8A8 / W4A8 激活量化扩展，来自明略科技（Mininglamp），MIT 协议开源
•  解决什么问题：MLX 只做权重量化，Cider 补上激活量化，释放 Apple M5 的 INT8 TensorOps 硬件算力
• 性能表现：Prefill 加速最高达 1.86×（per-channel 模式，长序列场景），相比 FP16 内存降低约 40%，精度几乎无损
• 怎么用：pip install -e . + convert_model(model)，一行代码即插即用
• 硬件限制：需要 Apple M5+ 解锁完整加速；M4 及以下优雅降级，不报错

一、核心概念解析：什么是 MLX 推理加速？

1.1 MLX 的加速困境：为什么芯片有算力却跑不满？

MLX 是 Apple 专为 Silicon 芯片设计的机器学习框架，凭借统一内存架构和自动微分，被视为 Mac 本地跑 AI 的“官方答案”。但开发者很快发现一个现实：MLX 的量化仅限于权重量化——W4A16 和 W8A16 模式下，权重以 INT8 / INT4 存储，但计算时反量化回 FP16，再走 FP16 GEMM。量化省了内存，没有释放算力。

打个比方：权重量化像是把一本厚书压缩成口袋版（省空间），但你阅读时还是得展开成原文一个字一个字看。而激活量化则更进一步——它相当于直接教你速读，让你的眼睛（芯片）一目十行，而不是被教材（框架）逼着逐字逐句念。

更关键的是，MLX 不提供激活量化 pipeline。Apple M5 芯片内置的 INT8 TensorOps 硬件加速单元——通过 Metal 4 的 cooperative_tensor 特性暴露的 mpp::tensor_ops::matmul2d(16, 32, 16) 硬件指令——在 MLX 框架里形同虚设。

这意味着，你的 M5 Mac 明明有硬件级 INT8 加速能力，MLX 却让你绕回 FP16 GEMM 的老路——好比同一条公路，硬件早就修好了四车道不限速，但 MLX 只给你开了一条单车道限速 60。

瓶颈不在芯片，在框架。

1.2 激活量化 vs 权重量化：两个概念，两种天花板

权重量化（Weight Quantization）压缩模型参数的存储体积，计算时反量化到 FP16。W4A16、W8A16 都属于这一类——省内存，不省算力。

激活量化（Activation Quantization）更进一步：把输入激活值也量化到 INT8，让矩阵乘法直接在 INT8 × INT8 → INT32 的硬件单元上执行，最后一次性反量化回 FP16。这条路径同时优化了计算密度和内存带宽，加速潜力远大于权重量化。

MLX 原生不提供激活量化的端到端实现。Cider 的价值就在于此：它不是替代 MLX，而是补齐 MLX 缺失的算子，让 Apple Silicon 的 INT8 硬件能力真正被用起来。

1.3 MLX 和 llama.cpp，谁在 Apple Silicon 上更快？

开发者常问：跑同一个模型，MLX 和 llama.cpp 谁更快？

llama.cpp 的优势在于跨平台兼容性和 GGUF 格式生态，但在 Apple Silicon 上，它的计算路径同样以 FP16 GEMM 为主，且跨架构适配存在额外开销。MLX 的优势在于与 Apple Silicon 的统一内存架构深度耦合，减少数据搬运——前提是能把硬件能力用满。

没有 Cider 的情况下，两者都是 FP16 计算路径，性能差距不大。但引入 Cider 后，MLX + Cider 走的是 INT8 TensorOps 计算路径——这是 llama.cpp 目前不支持的硬件指令集。在 Apple M5+ 上，这意味着 MLX + Cider 在 prefill 阶段拥有结构性的计算路径优势。

二、技术架构：Cider 如何解锁 MLX 缺失的 INT8 能力

2.1 MLX 的原生局限

MLX 的 QuantizedLinear 模块只负责权重存储压缩，底层调用 FP16 GEMM。Apple 的 Metal Performance Shaders 和 Steel NAX 模板理论上支持 INT8 类型（且能达到相同的原始 matmul 吞吐），但 MLX 没有提供从 FP16 激活 → INT8 量化 → INT8 矩阵乘 → 反量化的完整 pipeline。这不是技术不可行，而是工程优先级问题。

2.2 Cider 的补齐方案：基于 custom primitives 的 INT8 扩展

Cider 基于 MLX 的 custom primitives 机制，构建了一套完整的 INT8 激活量化算子，支持 lazy evaluation（可以理解为：像下棋时先想好整盘棋路再一次性落子，而不是走一步算一步），与 MLX 的图调度无缝融合。每个 primitive 都是 mlx::core::Primitive 的子类——不是外挂，是原生扩展。

核心技术实现：

• W8A8：权重 INT8 symmetric + 激活 INT8 per-token，通过 TensorOps matmul2d 加速 prefill（seq_len > 1）

• W4A8：权重 INT4 packed + 激活 INT8 per-token，prefill 时 inline INT4→INT8 unpacking，内存占用进一步降低

Cider 的 Metal kernel 在存储阶段融合了反量化（INT32 × scales → FP16），避免了一次额外的设备内存往返。TensorOps matmul2d(16, 32, 16) 是 Apple M5+ 独有的硬件加速指令——Cider 是目前唯一基于 MLX 调用这条指令的开源实现。

2.3 赛道格局：MLX 推理加速的玩家与壁垒

当前端侧推理加速分为三条路线：

1. 框架层优化：基于现有框架补全缺失算子，如 Cider 之于 MLX。优势是生态兼容、迁移成本低。

2. 模型层压缩：聚焦权重量化和模型格式转换，如 GGUF、GPTQ、AWQ。不触及计算路径。

3. 芯片层定制：如 Apple Neural Engine 专用推理，极致能效但通用性差。

截至 MLX v0.31，Apple 尚未在 MLX 中提供端到端的激活量化实现。Cider 的技术壁垒在于：唯一基于 MLX 解锁 Apple M5 INT8 TensorOps 并开源实现的方案。

三、核心优势：Cider 的三重差异化价值

3.1 释放 Apple M5 被锁住的 INT8 算力

在 Apple M5 Pro 上的实测数据显示：per-channel 模式下 prefill 加速最高达 1.86×（M=8192），per-group（gs=128）模式下最高 1.5×。矩阵规模越大加速越明显——M=128 时约 1.43×，M≥1024 时稳定在 1.5×–1.86× 区间。对比基线为 MLX 原生 W8A16。

这不是软件层面的微调，而是硬件能力的释放——从 FP16 GEMM 到 INT8 TensorOps，计算路径发生了质变。

3.2 兼容任意 MLX 模型，不限于 Mano-P

Cider 是通用 MLX 加速工具。通过 convert_model() API 自动遍历模型中的 Linear 层并替换为 CiderLinear，支持 Qwen3、Qwen3-VL、Llama3 等主流架构。已验证模型清单：Qwen3-8B、Qwen3-VL-2B/4B、Llama3-8B。

3.3 一行代码，不改模型即加速

安装和使用极简——相当于给你的 MLX 模型装了个涡轮增压，车（模型）不用换，发动机（代码）不用改，装上就能跑更快：

from cider import convert_model, is_available

if is_available():
    convert_model(model)  # 自动替换所有 Linear 层

M4 及以下设备优雅降级为标准 MLX 推理，is_available() 返回 False，不报错、不崩溃。

四、Cider 与 Mano-P：端侧 AI 的”引擎”与”大脑”

4.1 产品层级：从芯片到体验的完整链路

明略科技的端侧 AI 产品体系可以简单理解为三层：

• Mano-P = 端侧多模态模型（大脑）——跑在设备上的 AI 大脑，负责理解、推理、决策

• Cider = 推理加速引擎（涡轮）——让 Mano-P 在 Mac 上跑得更快、更省内存

• Mano-AFK = 自主编程工作流（体验）——用户看到的产品体验

三者之间的关系：Mano-P 提供能力，Cider 释放性能，Mano-AFK 交付体验。这个闭环同时实现了三个核心价值——隐私（Mano-P 跑在本地）、速度（Cider 加速最高达 1.86×）、省 token（不需要云端 API）。

4.2 关键澄清：Cider 是通用基础设施

虽然 Mano-P 是 Cider 最深度适配的模型，但 Cider 不是 Mano-P 的专属配件——任何符合 MLX 规格的模型都可以使用。它既是明略科技 Private AI 基建的芯片级组件，也是面向整个 MLX 社区的开源基础设施。

五、深度场景实测：Cider 如何落地？

5.1 Qwen3-8B 端到端 prefill 加速

在 Apple M5 Pro 上，Wikitext2 数据集测试 Qwen3-8B：

配置	Prefill 时间	峰值内存	PPL（↓越好）
FP16（基线）	179.9 s	18.93 GB	9.726
MLX W8A16	221.3 s	12.07 GB	9.707
Cider W8A8 per-channel	123.5 s	11.32 GB	9.756
Cider W8A8 per-group gs=128	165.8 s	11.61 GB	9.727

对比 FP16 基线提速 1.46×，对比 MLX 原生 W8A16 提速 1.79×。相比 FP16 基线内存降低约 40%（18.93 GB → 11.32 GB），精度几乎无损（PPL 差距 < 0.3%）。

Llama3-8B 结果类似：对比 FP16 基线，W8A8 per-channel 模式下 prefill 从 175.8 秒降至 123.3 秒（加速 1.43×），内存从 18.32 GB 降至 10.69 GB（降低 42%）。

5.2 一行代码加速 VLM 服务

Cider 内置 vlm_service/ 模块，提供 OpenAI-style API 的 VLM 推理服务器。配置 w8a8.mode: auto 后，服务器启动时自动调用 convert_model() 启用加速。

Qwen3-VL-2B 实测（对比基线为 MLX 原生 W8A16）：

• MLX W8A16 prefill：2065 tok/s → Cider W8A8：3242 tok/s（提速 1.57×）

• MLX W8A16 decode：107 tok/s → Cider W8A8：104 tok/s（接近原生，无损失）

整个流程不需要修改模型代码、不需要重新训练。pip install -e . 后，convert_model() 一行生效。

六、常见问题解答（FAQ）

Q：MLX 原生支持 W8A8 激活量化吗？

不支持。MLX 的 QuantizedLinear 仅提供权重量化（W4A16 / W8A16），计算时反量化回 FP16 走 GEMM。Cider 通过 custom primitives 补齐了 MLX 缺失的 W8A8 / W4A8 激活量化 pipeline。

Q：Cider 兼容所有 MLX 模型吗？

Cider 是通用 MLX 加速工具，不限于 Mano-P。已验证支持 Qwen3、Qwen3-VL、Llama3 等主流 MLX 架构。

Q：M4 Mac 能用 Cider 吗？

M4 及以下芯片没有 INT8 TensorOps 硬件单元，Cider 安装时自动跳过 C++ 编译，推理回退到标准 MLX 模式，不报错。M5+ 全功能解锁。

Q：激活量化会让模型变笨吗？

实测精度几乎无损。Qwen3-8B W8A8 PPL = 9.756 vs FP16 = 9.726，差距 < 0.3%。

Q：怎么安装和使用 Cider？

pip install -e .
M5+ 自动编译 C++ 扩展，M4 及以下自动跳过。使用时一行 convert_model(model) 即可。

仓库地址：https://github.com/Mininglamp-AI/cider
联系我们：model@mininglamp.com