文章总结： 本文对AppleSilicon平台4个主流本地LLM推理引擎进行横向评测，涵盖吞吐量、延迟、内存占用、OOM概率和维护活跃度五个维度。核心发现omlx0.4.1+dflash在长上下文场景系统吞吐量领先73%，dflash需作为omlx子能力使用，4-bit量化不可替代。建议短档用rapid-mlx，中长档优先选omlx+dflash配置pagedSSD。 综合评分： 87 文章分类： 解决方案,技术标准,其他
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 阵营存在三个本质差异：
| 挑战 | 说明 | 影响 | | — | — | — | | 统一内存（Unified Memory） | CPU 和 GPU 共享同一块内存池（最大 192GB on M3 Ultra），KV cache 无需 CPU/GPU 间搬运 | 多实例推理时每个实例直接占用 ~35GB GPU 内存 | | 没有 CUDA 只有 MLX | 必须使用 Apple 自家 MLX 框架，PyTorch CUDA kernel 无法直接运行 | vllm / TGI / TensorRT-LLM 等主流框架被淘汰 | | 多实例 = 多进程内存分配 | 无 CUDA MPS 机制，每个推理实例独立分配内存 | 4 个实例 = 140GB，M3 Ultra 512GB 剩余 ~370GB |
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
| 阶段 | 时间 | 主引擎 | 关键事件 | | — | — | — | — | | 起步期 | 2026-02 ~ 2026-04 | vllm-mlx | 项目启动，OpenAI 兼容 API 完善 | | 过渡期 | 2026-05-12 ~ 2026-05-22 | rapid-mlx 0.6.71 | vllm-mlx 维护停滞，8 项 workaround 清理 | | 探索期 | 2026-05-31 ~ 2026-06-03 | dflash-mlx 0.1.8 | 8bit baseline 4.9→10.2 tps，4-bit 被拒 | | 生产期 | 2026-06-04 ~ | omlx 0.4.1 + dflash | 30K_c1 46.93 tps (+52% vs v25) |
2. 评测方法论
2.1 业务画像三档
oai-mlx 网关服务的三类业务量级分布：
| 业务档 | 上下文长度 | 请求量占比 | 典型场景 | 关键性能诉求 | | — | — | — | — | — | | 短档 | < 4K | 60% | 聊天 / 单轮问答 / 简短摘要 | TTFT < 1s + 高 1-并发 tok/s | | 中档 | 4K-30K | 30% | 长文档摘要 / 文档问答 / 多轮工具调用 | KV cache 复用 + 长上下文稳定 | | 长档 | ≥ 30K | 10% | 多轮 agent / 长 RAG / 64K 上下文 | OOM 0 容忍 + paged SSD 兜底 |
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）
| 引擎 | 50 tok | 200 tok | 500 tok | | — | — | — | — | | vllm-mlx 0.x | ~28 | ~65 | ~45 | | rapid-mlx 0.6.71 | 33.8 | 77.0 | 50.9 | | dflash-mlx 0.1.8 (8bit) | 4.9 | — | — | | omlx 0.4.1 + dflash | 35+ | 77+ | 52+ |
关键发现：
- • omlx + dflash 与 rapid-mlx 在短档几乎打平（差异 < 5%）
- • dflash 推测解码在短上下文无优势，prefill 开销占比大
- • dflash-mlx 单独跑 8bit 比 4bit 慢 6×（4.9 vs 29 tok/s）
3.1.2 长上下文吞吐（≥ 30K）
| 引擎 | 30K_c1 (1-并发) | 30K_c4 (4-并发) | 系统总吞吐 | | — | — | — | — | | vllm-mlx 0.x | ~25 | 8% OOM | — | | rapid-mlx 0.6.71 (v25 baseline) | 30.87 | 55 | 179.5 tps | | omlx 0.4.1 + dflash (v26) | 46.93 | 95.15 | 220 tps |
关键发现：
- • 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）
| 引擎 | 短档 (50tok) | 中档 (10K) | 长档 (30K) | | — | — | — | — | | vllm-mlx | ~0.4s | ~1.2s | ~2.5s | | rapid-mlx 0.6.71 | ~0.4s | ~1.0s | ~1.8s | | omlx 0.4.1 + dflash | ~0.4s | ~0.8s | ~1.0s |
关键发现：长档 TTFT omlx 比 rapid-mlx 快 1.8×（1.0s vs 1.8s），得益于 paged SSD cache 部分加载。
3.3 内存占用
| 引擎 | 模型权重 | KV cache L1 | KV cache L2 | 总占用 | | — | — | — | — | — | | vllm-mlx / rapid-mlx | 35GB | 8GB | ❌ 无 | ~43GB | | dflash-mlx 0.1.8 | 53GB (含 draft) | 8GB | 20GB SSD | ~81GB | | omlx 0.4.1 + dflash | 53GB (含 draft) | 4-32GB | 8-92GB SSD | ~53-145GB |
3.4 OOM 概率
| 引擎 | 1-并发 30K | 5-并发 30K | 5-并发 30 轮工具调用 | | — | — | — | — | | vllm-mlx | 2% | 8% | 15% | | rapid-mlx 0.6.71 | 1% | 5% | 10% | | omlx 0.4.1 + dflash | 0% | 0% | 0% |
关键发现：omlx 5-并发 30 轮工具调用 0% OOM，146 个 tool calls 全部成功。
3.5 维护活跃度
| 引擎 | Commit 频率（90天） | Issue 响应时间 | pip 发布频率 | | — | — | — | — | | vllm-mlx | 5/月（↓70%） | 14 天 | 0.x | | rapid-mlx | 12/月 | 3 天 | 2 月 3 发 | | dflash-mlx | 18/月 | 1 天 | 0.1.7→0.1.8 | | omlx | 8/月（新项目） | 2 天 | 0.4.0→0.4.1 |
4. 核心发现
发现一：vllm-mlx 是被新业务档淘汰的，不是被新引擎淘汰的
到 2026-04，三个新需求出现：
- 1. Anthropic 协议支持（v2.1.0 用户新增）——vllm-mlx 无原生 endpoint
- 2. 多轮工具调用（v2.2.0 用户新增）——tool call 序列化有 bug
- 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. site-packages 内的 patch 应视为”已交付能力的隐式依赖”
- 2. patch 应当是
.diff/.patch文件，而非文档 - 3. 升级回归测试矩阵要包含 Patch B
发现五：维护活跃度比性能更重要
vllm-mlx 性能不算差（1-并发 28 tps vs rapid-mlx 33.8 tps），但 commit 频率 5/月 + issue 响应 14 天 = 新需求无法落地。选引擎首先看 commit 频率和 issue 响应，再考虑性能。
5. 结论与推荐
5.1 业务档推荐矩阵
| 业务档 | 推荐引擎 | 关键配置 | 反例 | | — | — | — | — | | 短档 (< 4K, 60%) | rapid-mlx 或 omlx | 1-2 实例，4/8bit 均可 | dflash 8bit 单独使用（慢 6×） | | 中档 (4K-30K, 30%) | omlx + dflash （最佳） | 4-8 实例，paged SSD 必备 | vllm-mlx（5-并发 OOM 5%） | | 长档 (≥ 30K, 10%) | omlx + dflash + paged SSD 92GB | 4+ 实例，0% OOM 目标 | rapid-mlx（生产每周 OOM 触发重启） |
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. 51973 代理增加 context-length-aware 路由（v2.3.1）
- 2. vllm-mlx 重新启动 + 重新集成
- 3. 短档实例独立 paged SSD（如需要）
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：马甲三号 《Apple Silicon 本地 LLM 推理引擎横向评测》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论