Apple Silicon 本地 LLM 推理引擎横向评测

马甲三号

2026年6月8日 00:34
江苏

在小说阅读器读本章

去阅读

生命不息、折腾不止

vllm-mlx · rapid-mlx · dflash · omlx 四引擎 × 五维度横评

摘要

本文对 Apple Silicon 平台上 4 个主流本地 LLM 推理引擎进行横向评测，评测维度涵盖吞吐量、延迟、内存占用、OOM 概率、维护活跃度五个核心指标。结合 oai-mlx 项目四个月（2026-02 ~ 2026-06）的工程实践，以\\「短档 < 4K / 中档 4K-30K / 长档 ≥ 30K」\\三档业务画像为主线组织数据。

核心结论：omlx 0.4.1 + dflash 在 ≥ 30K 长上下文场景下系统吞吐量领先 v25 baseline 73%；dflash 不是独立引擎而是 omlx 的子能力；4-bit 量化仍不可替代。

面向读者：正在为 Apple Silicon 选本地推理引擎 / 部署多实例推理网关 / 跑 30B+ MoE 长上下文 / 维护多池多模型多用户的工程师。

1. 背景与动机

1.1 Apple Silicon 上本地推理的三个独特挑战

Apple Silicon（M1/M2/M3/M4）跑本地 LLM 推理的体验与 x86 + CUDA 阵营存在三个本质差异：

1.2 四引擎演进时间线

vllm-mlx (v1.x) → rapid-mlx (0.6.71) → dflash-mlx (0.1.8) → omlx (0.4.1+dflash)
     2026-02              2026-05             2026-05              2026-06

2. 评测方法论

2.1 业务画像三档

oai-mlx 网关服务的三类业务量级分布：

2.2 测试环境

• • 机器：Mac M3 （28 核 CPU / 60 核 GPU / 128GB Unified Memory）
• • 操作系统：macOS 26.5（Build 25E5255f）
• • MLX 版本：mlx 0.31.2 / mlx-lm 0.31.3
• • 后端进程：9 个推理后端（文本池 4 个 / 多模态池 2 个 / compact 池 4 个）
• • 测试模型：Qwen3.6-35B-A3B-8bit

3. 评测结果

3.1 吞吐量

3.1.1 短档（50-500 tokens）

关键发现：

• • omlx + dflash 与 rapid-mlx 在短档几乎打平（差异 < 5%）
• • dflash 推测解码在短上下文无优势，prefill 开销占比大
• • dflash-mlx 单独跑 8bit 比 4bit 慢 6×（4.9 vs 29 tok/s）

3.1.2 长上下文吞吐（≥ 30K）

关键发现：

• • omlx + dflash 30K\_c1 +52% per-req 提升
• • omlx + dflash 30K\_c4 +73% system-wide 提升
• • 30K 字符 ≈ 45.8K tokens（token ratio ~1.5x）

3.2 延迟（TTFT）

关键发现：长档 TTFT omlx 比 rapid-mlx 快 1.8×（1.0s vs 1.8s），得益于 paged SSD cache 部分加载。

3.3 内存占用

3.4 OOM 概率

关键发现：omlx 5-并发 30 轮工具调用 0% OOM，146 个 tool calls 全部成功。

3.5 维护活跃度

4. 核心发现

发现一：vllm-mlx 是被新业务档淘汰的，不是被新引擎淘汰的

到 2026-04，三个新需求出现：

1. 1. Anthropic 协议支持（v2.1.0 用户新增）——vllm-mlx 无原生 endpoint
2. 2. 多轮工具调用（v2.2.0 用户新增）——tool call 序列化有 bug
3. 3. 64K+ 长上下文（v2.2.0 用户新增）——30K+ OOM 8%

根本原因：新业务档的需求超出了 vllm-mlx 维护者的兴趣范围，而非性能问题。

发现二：4-bit 量化不可替代，dflash 8bit 单独使用无意义

dflash-mlx 0.1.8 的 8-bit baseline 4.9 tps + dflash 10.2 tps = 2.1× 加速，但对照 4-bit baseline 29 tok/s，dflash 8bit 慢 6×。

dflash 必须 8-bit+ 才能工作（draft/target 权重精度需匹配），但这使其失去了 4-bit 的内存优势。结论：dflash 只有嵌入 omlx（4-bit + draft 8-bit 混合部署）才有价值。

发现三：dflash 不是独立引擎，是 omlx 的子能力

dflash-mlx 0.1.8 单独使用时是 single-user serial 模式，无法用于多实例网关。oai-mlx 在 2026-06-04 切到 omlx 0.4.1 + dflash 启用，dflash 通过 ~/.omlx/model_settings.json 配置：

{
  \"Qwen3.6-35B-A3B-8bit\": {
    \"dflash_enabled\": true,
    \"dflash_draft_model\": \"z-lab/Qwen3.6-35B-A3B-DFlash\",
    \"dflash_draft_quant_weight_bits\": 8
  }
}

发现四：上游 PR 经常不存在

\"Patch B\"（oai-mlx 给 vllm\_mlx 加的 4 文件 patch，实现 /v1/cache/stats 等端点）在 2026-06-03 升级到 rapid-mlx 0.6.71 时被全部覆盖。

教训：

1. 1. site-packages 内的 patch 应视为\"已交付能力的隐式依赖\"
2. 2. patch 应当是 .diff / .patch 文件，而非文档
3. 3. 升级回归测试矩阵要包含 Patch B

发现五：维护活跃度比性能更重要

vllm-mlx 性能不算差（1-并发 28 tps vs rapid-mlx 33.8 tps），但 commit 频率 5/月 + issue 响应 14 天 = 新需求无法落地。选引擎首先看 commit 频率和 issue 响应，再考虑性能。

5. 结论与推荐

5.1 业务档推荐矩阵

5.2 未来混合架构

客户端请求 → 51973 代理路由
               ↓
短档 (< 4K) → vllm-mlx / rapid-mlx 1-2 实例（成本最低）
               ↓
中档 (4K-30K) → rapid-mlx 0.6.71 4 实例
               ↓
长档 (≥ 30K) → omlx 0.4.1 + dflash + paged SSD 4 实例

实施前置条件：

1. 1. 51973 代理增加 context-length-aware 路由（v2.3.1）
2. 2. vllm-mlx 重新启动 + 重新集成
3. 3. 短档实例独立 paged SSD（如需要）