oMLX — Mac 上的本地 LLM 推理服务器

> 一句话版本：一个让你在 MacBook 上跑本地 AI 大模型的服务器软件，能同时管多个模型、自动把用过的上下文缓存到硬盘上加速下次使用，从菜单栏就能控制，非常适合配合 Claude Code 这类编程工具在本地跑模型。

核心内容

oMLX 是一个专为 Apple Silicon Mac 设计的 LLM 推理服务器，基于 Apple 的 MLX 框架。它的核心卖点是分层 KV 缓存：

• 热缓存（RAM）：高频访问的上下文块常驻内存
• 冷缓存（SSD）：内存满了自动溢出到硬盘，以 safetensors 格式存储
• 即使切换对话、甚至重启服务器，之前的上下文还能从 SSD 恢复，不用重新计算

这解决了本地跑 LLM 的核心痛点：长上下文场景下重复计算太慢。配合 Claude Code 做编程工作时，这个特性尤其有价值。

主要功能

1. 连续批处理：基于 mlx-lm 的 BatchGenerator，支持并发请求

2. 多模型管理：LRU 自动驱逐、手动加载/卸载、模型固定、每模型 TTL

3. API 兼容：OpenAI + Anthropic API 兼容，streaming 支持

4. 多模态：LLM、VLM（视觉）、OCR、Embedding、Reranker

5. 菜单栏 App：原生 PyObjC（非 Electron），轻量

6. Web 管理面板：实时监控、聊天、基准测试、模型下载（支持 HF mirror）

7. 一键集成：OpenClaw、OpenCode、Codex 直接配置

8. MCP 支持：Model Context Protocol 工具调用

9. 广泛模型支持：Llama、Qwen、DeepSeek、Gemma、GLM、MiniMax、Kimi K2 等工具调用格式

分层 KV 缓存详解

背景：LLM 推理为什么慢？

LLM 生成文本是逐字吐出的（自回归），每吐一个字都要重新看一遍之前所有内容。虽然中间计算结果可以缓存（这就是 KV cache），但长对话的 KV cache 会变得非常大，占用大量内存。

传统引擎（Ollama、LM Studio）的问题是：切换对话或重启服务时，KV cache 直接清空，下次得从头重算。

oMLX 怎么解决的？

把 KV cache 分两层：

• 热缓存（RAM）：高频访问的上下文常驻内存，读取极快
• 冷缓存（SSD）：内存不够时，不常用的 KV 块自动溢出到硬盘（safetensors 格式）

关键优化：

1. Prefix sharing — 多段对话共享相同前缀（如 system prompt）时只存一份

2. Copy-on-Write — 修改缓存时只改变化的部分，不复制整个块

3. 重启持久化 — KV cache 存在 SSD 上，重启服务后可恢复

4. 跨请求复用 — 对话 A 用过的上下文，对话 B 前缀匹配时直接从 SSD 读取

实际效果

用 Claude Code 本地编程，上下文 50k+ tokens 时：

• 没有 oMLX：每次发消息，前面的上下文都要重新计算（prefill），等待时间长
• 有 oMLX：之前的上下文大部分在缓存里（RAM 或 SSD），只算新增部分，瓶颈从重复计算降到 SSD 读取速度

注意：不能跑装不下的模型

SSD 缓存只存 KV cache（已计算的上下文），模型权重本身必须完全装入 RAM。想跑大模型还是得靠量化压缩（4bit/2bit）或更大内存的机器。

架构

FastAPI Server (OpenAI/Anthropic API)
 ├── EnginePool (多模型, LRU, TTL)
 │   ├── BatchedEngine (LLM, 连续批处理)
 │   ├── VLMEngine (视觉语言模型)
 │   ├── EmbeddingEngine
 │   └── RerankerEngine
 ├── ProcessMemoryEnforcer (内存限制)
 ├── Scheduler (FCFS, 可配置并发)
 └── Cache Stack
     ├── PagedCacheManager (GPU, block-based, CoW)
     ├── Hot Cache (内存层)
     └── PagedSSDCacheManager (SSD 冷层)

与竞品对比

分析

优势：

• 分层 KV 缓存是真正的差异化特性，对长对话和编程场景意义重大
• 纯 macOS 专注，深度优化 Apple Silicon
• 原生菜单栏 App，非 Electron，资源占用低
• 支持 Claude Code 的 context scaling（让小上下文模型也能用）
• 一键集成 OpenClaw、Codex 等工具

风险：

• 仅支持 macOS，Linux 用户无法使用
• 个人项目，社区虽活跃但长期维护存疑
• 作者为个人开发者，长期维护存疑
• 需要 macOS 15.0+，老系统不支持

与 Jay 的关联：

• Jay 在用 OpenClaw，oMLX 直接支持 OpenClaw 集成
• 如果 Jay 有 Mac，这是目前 Mac 上跑本地模型的最优方案之一
• 可以配合 OpenClaw 做本地推理，减少 API 费用

评分

实际使用建议

M3 Air 24GB 推荐模型

系统占用约 6-8GB，实际可用约 16-18GB：

首选 Qwen3.5-Coder-9B 4bit — 占用小、编码强、配合 oMLX 的 SSD 缓存跑长对话很舒服。32B+ 不建议上，长上下文一开容易炸。

模型下载

Web 管理面板内置 HuggingFace 模型下载器，支持搜索、浏览模型卡片、查看文件大小、一键下载。还支持 HuggingFace 镜像端点（--hf-endpoint https://hf-mirror.com），国内网络可用。

技术栈

• 后端：Python（FastAPI），占比 98%+
• 推理引擎：Apple MLX（C++ + Metal GPU）
• 菜单栏 App：PyObjC（Python 绑定 macOS 原生 Cocoa 框架，非 Electron）
• 前端：HTML/JS/CSS（Web 管理面板）
• 打包：venvstacks（便携 Python 环境分层）

分层关系：Python 负责"调度"（缓存策略、LRU、CoW、prefix sharing），MLX 负责"干活"（张量计算、GPU 操作、内存管理）。性能瓶颈在 Metal GPU 和 SSD I/O，不在 Python 层。