omlx
Apple Silicon 上的一站式 LLM 推理服务器,连续批处理+分层KV缓存,菜单栏管理
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
Apple Silicon 上的一站式 LLM 推理服务器,连续批处理+分层KV缓存,菜单栏管理
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象一个场景: 你是一个独立开发者,手边只有一台 M3 Max MacBook Pro。想用 Claude Code 写代码,但每次都要把上下文上传到云端——网络延迟、数据隐私、API 调用成本,这些问题始终萦绕在心头。有没有一种方案,能让本地大模型推理像云端一样流畅,同时完美融入你的开发工作流?
这就是 oMLX(open MLX)试图回答的问题。
oMLX 由韩国工程师 Jun Kim(@jundot)开发,项目启动的动机非常个人化:"我试过的每个 LLM 服务器都让我在便利性和可控性之间做选择。我想要把常用模型固定在内存中,按需自动切换较重的模型,设置上下文限制——并且从菜单栏管理这一切。"
这不是一个学术实验,而是一个真实开发者的日常工具。作者每天都在用它配合 Claude Code 做实际编码工作,这意味着代码质量和稳定性都有实战背书。
从技术定位看,oMLX 的核心差异化在于 Apple Silicon 原生优化。它基于苹果的 MLX 框架——这是苹果专门为自家芯片开发的机器学习运算库,和 CUDA 对 NVIDIA 的深度优化类似,MLX 能充分发挥 Apple Silicon 统一内存架构(Unified Memory)的优势。相比传统方案在 Mac 上运行 LLM,oMLX 不需要 Rosetta 转译,不需要 Homebrew 通用二进制,而是直接用 ARM NE 指令集和 MLX 算子实现高效推理。
oMLX 的核心技术栈分为两层:推理引擎 和 缓存系统。
推理引擎层(omlx/engine/)采用连续批处理(Continuous Batching)架构。当多个用户请求同时到达时,系统将它们动态打包成批次一起推理,而不是串行处理——这类似于餐厅的"翻台"策略,显著提升 GPU/统一内存的利用率。引擎支持多种模态:
| 模态 | 说明 |
|---|---|
batched.py | 连续批处理核心引擎 |
vlm.py | 视觉语言模型(图文理解) |
embedding.py | 嵌入向量生成 |
reranker.py | 重排序模型 |
stt.py / tts.py | 语音转文字 / 文字转语音 |
dflash.py | DeepFlash 蒸馏模型 |
缓存系统层(omlx/cache/)是 oMLX 最具创新性的部分——混合 KV 缓存(Hybrid KV Cache)。传统 LLM 推理中,每次请求都要重新计算所有 token 的 Key-Value 向量,计算量随上下文长度线性增长。oMLX 实现了热内存层(Hot RAM Tier)和冷 SSD 层(Cold SSD Tier)的分层缓存:
这意味着,即使你切换到不同的对话主题,历史上下文仍然可以被复用。对于需要长程记忆的编程助手场景,这个设计大幅减少了重复计算。
此外,系统还支持 prefix caching(前缀缓存)和 paged attention(分页注意力),前者对共享系统提示词特别有效,后者则借鉴了操作系统虚拟内存的分页思想,避免 KV 缓存的碎片化。
oMLX 还引入了 oQ(Optimizer Quantization)量化技术,通过校准数据对模型权重进行动态量化,在精度和性能之间取得平衡。这对于统一内存有限的 Mac 设备尤为重要——一个 70B 参数的模型,fp16 需要 ~140GB 内存,而量化后可以在 48GB 以内运行。
oMLX 不仅仅是一个本地推理服务器,它还刻意追求 API 兼容性,让自己成为 Claude Code、OpenCode、Codex、Hermes Agent 等 AI 编程工具的"本地替身"。
server.py 暴露的 API 端点包括:
POST /v1/chat/completions — OpenAI Chat Completions APIPOST /v1/messages — Anthropic Messages API(Claude 兼容)POST /v1/responses — OpenAI Responses API(Codex 兼容)GET /v1/models — 模型列表(含加载状态)GET /v1/mcp/tools — MCP 工具发现这意味着,如果你在本地运行 oMLX 并加载了 Qwen、Llama 或其他开源模型,只需要把 AI 编程工具的 API Endpoint 指向 http://localhost:8000/v1,就能用开源模型替代闭源模型做编码辅助。
oMLX 的 omlx/integrations/ 目录甚至为每款工具提供了专门的适配代码:claude.py、codex.py、copilot.py、openclaw.py、opencode.py、hermes.py——覆盖了主流 AI 编程工具生态。
此外,项目还支持 MCP(Model Context Protocol),允许 oMLX 作为 MCP Server,向 AI 工具暴露本地工具能力,实现真正的"AI + 本地工具"联动。
oMLX 的安装体验是它最令人印象深刻的地方。
方式一:DMG 应用(一键安装)
下载 .dmg 文件,拖到 Applications 文件夹,完成。内置自动更新功能,后续升级只需一次点击。没有 CLI 命令,但有完整的图形界面。
方式二:Homebrew(开发者首选)
brew tap jundot/omlx https://github.com/jundot/omlx
brew install omlx
brew services start omlx # 作为后台服务运行
方式三:源码安装(定制化需求)
git clone https://github.com/jundot/omlx.git
cd omlx
pip install -e ".[mcp]" # 含 MCP 支持
无论哪种方式,安装后只需要一条命令就能启动服务器:
omlx serve --model-dir ~/models
服务器启动后,管理界面在 http://localhost:8000/admin,包括:
更方便的是 菜单栏应用:oMLX 在 macOS 菜单栏常驻,所有配置操作都可以在菜单中完成,包括模型下载、服务器启停、参数调整——不需要打开浏览器界面。

图1:oMLX 官网展示的推理性能对比

图2:oMLX 的内存保护机制,防止 Mac 因模型过载而崩溃
最适合的场景:
明显的局限:
从代码结构看,oMLX 保持了较高的工程质量:
pytest.ini 和 tests/ 目录依赖管理使用 pyproject.toml,Python 3.11+ 要求反映了项目对现代 Python 特性的使用。关键依赖包括:mlx、mlx-lm(Apple 官方 LLM 库)、transformers>=5.0.0、fastapi、uvicorn。
oMLX 代表了一个重要的技术趋势:在本地硬件上运行大模型。随着 Apple Silicon 的 GPU 算力和统一内存容量不断提升(最高 192GB 统一内存的 M4 Ultra),Mac 已经从"办公电脑"进化为可以运行 70B+ 参数模型的开发工作站。
oMLX 的 15K+ stars 说明这个需求是真实存在的——不仅是个人开发者,还有很多需要在隐私敏感场景(医疗、法律、金融)使用 LLM 的团队。相比云端方案,oMLX 提供了:
从生态角度看,oMLX 与 AI 编程工具的深度集成(Claude Code、Codex、OpenCode、Hermes Agent 适配器)意味着本地 LLM 已经可以作为生产级编程助手的推理后端——这在一年前还是不可想象的。
总结:oMLX 是一个专为 Apple Silicon Mac 打造的生产级 LLM 推理服务器,通过连续批处理、分层 KV 缓存和 OpenAI 兼容 API,让本地大模型推理真正变得实用。对于有隐私需求、预算考量或技术探索需求的 Mac 用户,这是一个值得关注的项目。