oMLX vs Ollama - SSD KV 缓存与 Apple Silicon 推理对比¶

对 oMLX 与 Ollama 在极端长上下文场景下的实测对比，揭示 SSD KV 缓存的真实表现、MLX 底层的稳定性隐患，以及各运行时的速度-稳定权衡。

目录¶

• 测试环境
• oMLX 核心特性
• SSD KV 缓存机制
• 实验功能：DFlash、SpecPrefill、TurboQuant
• 基准测试结果
• 稳定性问题：MLX 的致命伤
• SSD 磨损警告
• 运行时对比总结
• 选型决策建议
• 参考资料

测试环境¶

硬件: MacBook Pro M3 Max 36GB
模型: Qwen3.6 35B A3B NVFP4 (MLX 格式)
上下文: 49K (半文件) / 98K (全文件) tokens

oMLX 核心特性¶

oMLX 是韩国开发者 June（jundot/omlx）开发的开源 LLM 推理服务器，基于 Apple MLX 框架，专为 Apple Silicon 优化。

核心卖点：分层 KV 缓存（Tiered KV Cache）

┌─────────────────────────────────────────────┐
│              Cache Stack                     │
│                                              │
│  ┌──────────────────┐  ┌──────────────────┐ │
│  │  Hot Cache (RAM)  │  │ Cold Cache (SSD) │ │
│  │  高频访问，极速响应 │  │  低频访问，持久存储│ │
│  │  Write-Back 策略  │  │  safetensors 格式│ │
│  └────────┬─────────┘  └────────┬─────────┘ │
│           │   LRU 驱逐           │           │
│           └──────────────────────┘           │
│                    │                         │
│         PagedCacheManager                   │
│    (block-based, CoW, prefix sharing)        │
└─────────────────────────────────────────────┘

关键优势： - 重启后 KV 缓存持久化 — 不需要重新计算 - 多模型同时服务（LRU 驱逐 + 手动加载/卸载 + 模型固定） - macOS 菜单栏原生应用（PyObjC，非 Electron） - OpenAI/Anthropic API 兼容 - 内置 Admin Dashboard 和 Chat UI

SSD KV 缓存机制¶

这是 oMLX 与其他运行时最大的差异化功能。

首次请求 (Cold Cache):
  用户 Prompt ──→ 计算 KV ──→ 写入 RAM (Hot) ──→ 驱逐时写入 SSD (Cold)
                                                  │
                                              safetensors
                                              格式持久化

后续请求 (Cache Hit):
  用户 Prompt ──→ 检查 RAM ──→ 命中? ──是──→ 直接使用 (≈1s)
                         │
                        否
                         │
                     检查 SSD ──→ 命中? ──是──→ 加载到 RAM (首次启动后仍有效!)
                         │
                        否
                         │
                      重新计算

实测表现：

对比 Ollama 的行为：

实验功能：DFlash、SpecPrefill、TurboQuant¶

oMLX 内置了多项实验性优化，无需手动编译即可启用：

1. DFlash（投机解码）

原理: 用小模型预测 N 个 token → 大模型并行验证 → 命中则跳过计算
限制: 仅在 4K 上下文内有效，超出后自动禁用
陷阱: 禁用时不会报错，需检查日志确认是否真正启用

2. SpecPrefill（投机预填充）

原理: 小模型扫描上下文 → 筛选重要 token → 主模型只处理子集
目的: 降低长 Prompt 的 TTFT (Time To First Token)
陷阱: 小模型与大模型不兼容时会静默失败（无报错）

3. TurboQuant KV Cache 压缩

原理: 对 KV Cache 进行量化压缩，节省显存
状态: 实验性，实测在 128K 上下文下是否真正生效存疑

[!warning] 关键陷阱 这三个实验功能都有静默失败问题 — 看起来在用，实际可能未生效。必须检查日志确认。

基准测试结果¶

49K 上下文 (半文件) Pre-fill 速度：

缓存一致性：

98K 上下文 (全文件) 测试：

oMLX: 处理到 77K tokens → 内存执行器介入 → API 返回错误
       放宽内存限制后再试 → macOS 粉屏崩溃 (Pink Screen of Death)
       多次尝试，均无法完成

稳定性问题：MLX 的致命伤¶

oMLX 底层使用 Apple 的 mlx-lm Python 运行时 — 和直接运行 MLXLM 完全相同的库版本。

稳定性对比:

  Llama.cpp  ──────── 稳定 ──────── ✅ 128K 通过
  Ollama     ──────── 稳定 ──────── ✅ 128K 通过（自研 MLX runner）
  LM Studio  ── 速度换稳定 ──────── ✅ 128K 通过（限制 MLXLM）
  MLXLM      ── 纯暴力 ─────────── ❌ 49K 以上崩溃
  oMLX       ── 同样的暴力 ──────── ❌ 77K 崩溃 → 粉屏

                    ↓ 根因
            mlx-lm 在大上下文下
            内存管理不稳定
            导致内核级崩溃

关键发现：

• oMLX 没有解决 MLXLM 的根本稳定性问题
• LM Studio 通过"限制"MLXLM 实现了稳定（牺牲速度）
• Ollama 完全自研 MLX runner，避开了 mlx-lm 的 bug
• oMLX + TurboQuant 仍无法加载 128K 上下文（是否真正生效存疑）

SSD 磨损警告¶

⚠️ SSD 磨损风险评估

  oMLX 每次保存新 KV Cache → 写入数 GB 数据到 SSD
  日常编码场景（反复换上下文）→ 频繁大量写入

  风险等级:
  ┌────────────────────────────────────┐
  │ 内置 MacBook SSD   → 🔴 高风险    │
  │ 外接 NVMe SSD      → 🟢 推荐      │
  │ 外接 SATA SSD      → 🟡 可接受    │
  └────────────────────────────────────┘

  建议: 使用外接高速 NVMe 硬盘 + 稳固硬盘盒

实测中观察到首次加载 SSD 缓存时出现明显的 SSD 读取带宽峰值。

运行时对比总结¶

                速度          稳定性       SSD缓存     生态/易用性
           ─────────────  ─────────────  ─────────  ─────────────
oMLX        ████████████   ████░░░░░░░░  ██████████  ███████░░░░
Ollama      █████████░░░   ████████████  ░░░░░░░░░░  ████████████
LM Studio   ██████░░░░░░   ████████████  ░░░░░░░░░░  ████████████
Llama.cpp   ████████░░░░   ████████████  ░░░░░░░░░░  ████████░░░░
MLXLM       ████████████   ██░░░░░░░░░  ░░░░░░░░░░  ██████░░░░░░

选型决策建议¶

需要大上下文 (64K+)?
├── 优先稳定 → Ollama / Llama.cpp
└── 能接受风险 → oMLX (用外接 SSD)

Agent 编码场景 (重复前缀)?
├── 追求极致 TTFT → oMLX (SSD KV Cache 优势明显)
└── 追求可靠性 → Ollama (稳定 + 内存缓存够用)

日常使用?
├── 开箱即用 → Ollama / LM Studio
└── 高级配置 → oMLX (但需监控日志)

作者结论： - oMLX 的 SSD KV 缓存是真创新，Agent 编码场景价值巨大 - 但底层 MLXLM 的稳定性问题是硬伤，可能丢失工作 - 日常使用必须搭配外接 NVMe SSD，避免内置 SSD 磨损 - 等待 MLXLM 本身修复大上下文稳定性问题后，oMLX 将成为最佳选择

参考资料¶

• oMLX GitHub 仓库 — jundot/omlx, Apache 2.0
• oMLX 官网 — 功能介绍与下载
• 前作：Apple MLX vs llama.cpp 性能对比 — 四运行时对比（含 Ollama）
• TurboQuant 详解 — KV Cache 压缩技术
• oMLX Reddit 讨论 — 社区反馈
• oMLX Hacker News 讨论 — 技术讨论

相关笔记¶

• [[Apple Silicon LLM 推理运行时对比]]
• [[MLX 框架入门]]