开源模型

这个 2 万 Star 的 Mac 大模型服务器，把 Codex 的模型塞回本机了。

2026 年 8 月 25 日

oMLX 是一个专为 Apple Silicon Mac 设计的本地大模型服务器应用，提供菜单栏管理、Hugging Face 模型下载器、OpenAI/Anthropic 兼容 API、两级 KV 缓存及基准测试功能。截至 2026 年 8 月 21 日获约 20.2K Star，要求 macOS 15+，仅支持 Apple Silicon。

把 Apple Silicon 变成本地大模型服务器

很多人买 Mac 的时候，内存咬着牙往上加。32GB、64GB，甚至 128GB。结果机器买回来，最勤快的还是浏览器，真正干活的大模型全在云端。

不是大家不想在本地跑。而是以前这件事太像伺候服务器：下载权重、找量化版本、启 API、算内存、盯日志。模型一多，还得手动把旧的卸掉。

最近我在 GitHub 上看到一个项目，准备把这套东西收进 Mac 菜单栏里。它叫 oMLX。

一句话概括：把 Apple Silicon 变成一台有管理后台、模型下载器和标准 API 的本地大模型服务器。

截至 2026 年 8 月 21 日，它在 GitHub 上已经拿到约 20.2K Star、1.7K Fork，半年左右堆了 2400 多次提交。更新速度快得有点凶。

不用先学运维，三步把服务跑起来

oMLX 最讨巧的地方，不是又造了一个命令行服务器。它直接做了一个原生的 macOS App。不是套壳网页，也不是 Electron，而是 Swift、SwiftUI 写的菜单栏应用。

第一次打开只做三件事：选模型目录、启动服务、打开后台。端口默认 8000。API Key 也能在这里顺手设好。原来散在终端里的参数，被收成了一张普通设置页。

平时也不用一直开着后台。菜单栏能直接看服务状态、内存、GPU、功耗、温度和模型负载。服务崩了可以自动拉起，应用升级也在里面完成。

找模型这件事，它也给你包了

本地模型最劝退新手的一步，通常不是运行，而是下载。同一个模型，原版、MLX、GGUF、4bit、8bit 排成一片。下错一个格式，几十 GB 流量先交学费。

oMLX 在后台里塞了一个 Hugging Face 模型下载器。可以搜索 MLX 模型、看模型卡、文件大小和下载风险，再点一下把它放进模型目录。

它不只认聊天模型。文本 LLM、视觉语言模型、OCR、Embedding 和 Reranker 都能放进同一套服务里。你可以固定常用模型，也可以给冷门模型设一个空闲时间，过期自动卸载。

内存不够时，它还会按 LRU 把最久没用的模型赶出去，尽量避免整台 Mac 被直接顶爆。

每个模型还可以单独改采样参数、聊天模板、别名、TTL 和模型类型。设置改完立即生效，不用把服务停掉重来。

我觉得比较实用的是配置档案。同一个基础模型，可以保存“快速”“深度思考”“严格 JSON”几套参数，再用不同的模型名暴露给客户端。底层还是同一份权重，不需要为了换一组参数再占一遍内存。

Codex 不用改半天配置，选模型就能启动

模型跑起来只是第一步。真正好不好用，还要看你原来的工具能不能接上。

oMLX 暴露了 OpenAI 和 Anthropic 兼容接口。OpenAI 客户端可以连到 http://localhost:8000/v1，Anthropic Messages API 也有对应入口。

更省事的是，它给 Codex、OpenCode、OpenClaw、Hermes Agent、Copilot 和 Pi 都做了集成页。选一个已经下载的模型，后台会生成启动命令。Codex 那一栏甚至直接写着 OpenAI Codex CLI。

这意味着写代码时，仓库内容、提示词和模型输出可以留在本机。断网环境也能继续工作，不需要按 Token 结账。

管理后台的前端依赖也被一起打包，没有偷偷去 CDN 拉脚本。模型已经下载好的情况下，聊天、监控和设置页面都能离线打开。

如果模型本身支持，oMLX 还能处理函数调用、JSON Schema 校验和 MCP 工具。对 Agent 来说，这比“能聊两句”更重要：Codex 不只要补代码，还要稳定地读文件、跑命令、返回结构化结果。

不过本地不等于能力自动追平云端。Codex 最终好不好用，仍然由你选的模型、量化精度、上下文长度和工具调用能力决定。

它真正想解决的，是长对话反复算前缀

本地跑一次短对话不难。真正折磨人的是 AI 编程这种长会话。

项目规则、源码、历史对话越堆越长，每次请求都从头预填充，风扇和等待时间一起起飞。

oMLX 做了一套两级 KV 缓存。热缓存放内存，冷缓存放 SSD。 常用前缀留在 RAM 里快速复用；内存满了，缓存块会以 safetensors 格式转存到磁盘。

下次再命中相同前缀，可以直接从 SSD 恢复，不必从头计算。按照项目说明，服务器重启以后冷缓存也不会跟着消失。

这套设计对普通闲聊没有那么戏剧化。你每次都问完全不同的问题，缓存也变不出多少收益。

但 AI 编程的前缀恰好很稳定：系统提示词、工具定义、项目规则和大量历史代码反复出现。缓存命中以后，真正需要重新算的往往只是后面新增的那一截。

它还支持连续批处理。多个请求进来后，不用老老实实排成一条单人队伍，可以合并调度，提高整台机器的吞吐。

单人聊天未必能立刻感到翻倍，但当 Codex、知识库和其他 Agent 同时找一个本地模型时，这套东西就开始值钱了。

别先信跑分，先让自己的 Mac 跑一遍

本地模型最容易出现的一种错觉，是看别人 M3 Ultra 的数字，看着看着就觉得自己的 16GB MacBook Air 也行。

oMLX 干脆在后台里做了基准测试。预填充速度、生成速度、首 Token 时间、峰值内存和连续批处理都能测。

同一个模型，还可以用不同上下文长度跑一轮。这样你看到的不是项目方一句“飞快”，而是这台 Mac、这个量化、这个上下文下的真实结果。

项目现在还在试验多 Mac 推理，能把一个模型拆到不同内存大小的 Mac 上。不过官方也把它标成了 Experimental，暂时别当生产方案看。

安装很短，硬件门槛一点都不短

最简单的安装方式，是去 Releases 下载 DMG，拖进 Applications。

喜欢 Homebrew 的话，三行就能起服务：

brew tap jundot/omlx https://github.com/jundot/omlx
brew install jundot/omlx/omlx
omlx start

需要注意的是，oMLX 的 App 面向 Apple Silicon 的 Mac，要求 macOS 15 或更高版本。Intel Mac、Windows 用户先别兴奋。

统一内存还是那条最硬的天花板。下载器能帮你找模型，不能把 16GB 变成 64GB。模型权重、KV 缓存和系统都要抢同一池内存，大模型还会吃掉大量 SSD 空间。

工具调用也依赖模型的聊天模板支持 tools 参数。服务端接口兼容，不代表随便找个模型就会稳定调工具。

另外，本文截稿时 GitHub 的 latest 是 v0.6.3rc2，仍然是发布候选版。项目更新很猛，拿工作主力机部署前，备份配置和模型目录不会吃亏。

这不是给所有人的 Ollama 替代品

oMLX 的边界特别清楚。它不追求 Windows、Linux、Mac 全平台通吃，而是盯着 Apple Silicon，把 MLX、本地 API、多模型调度、两级缓存和 macOS 菜单栏揉成一套。

如果你只有一台 8GB 或 16GB Mac，只想偶尔和小模型聊两句，现成工具已经很多，没必要专门养一套服务器。

但如果你手上是一台大内存 Mac，想让 Codex、OpenCode、知识库和自动化脚本共用本地模型，这个项目确实把麻烦收拾得挺干净。

以前买大内存 Mac，是怕不够用。现在终于有人认真研究，怎么把它用满了。

JOTO 企业落地观察

企业若计划将 Codex 类编程智能体部署于本地 Mac 工作站，oMLX 提供了开箱即用的模型调度与 API 封装能力，但需同步评估 Apple Silicon 统一内存对多任务并发的承载极限，尤其当嵌入 RAG 知识库或长期运行 Agent 时，LRU 卸载策略可能引发上下文断裂风险。
该工具将模型下载、缓存管理、API 兼容性等工程细节封装进图形界面，降低了智能体开发团队在 macOS 环境下的原型验证门槛；但其未抽象出标准化的模型注册中心与元数据描述机制，不利于企业构建跨设备、跨用户的模型资产治理流程。
两级 KV 缓存设计直指 AI 编程场景中前缀重复计算的痛点，对企业构建低延迟、高吞吐的本地化代码辅助服务具有参考价值；但冷缓存依赖本地 SSD，未提供加密或访问控制机制，在涉及敏感代码的 FDE 驻场共创场景中需额外加固。
oMLX 对 OpenAI/Anthropic 接口的兼容性为企业已有工具链（如 Copilot、Pi）提供了平滑迁移路径，但其不支持模型微调与训练闭环，意味着企业若需持续优化领域专用能力，仍需对接独立的训练基础设施。