你在 Mac 上偶尔和本地模型聊几句，问题不大。可一旦多个应用轮流调用、对话越来越长，机器既要留住模型，也要保存大量上下文，很快就会碰到内存和管理上的麻烦。oMLX 想解决的正是这件事：把一台 Apple Silicon Mac 从“临时跑一下模型”的电脑，变成可以长期接收请求的推理服务器——也就是持续加载模型、供其他应用调用的后台程序。
据项目 README，oMLX 把连续批处理、分层 KV cache 和 macOS 菜单栏管理放进了同一套工具。这里的功能与性能说法目前都来自项目方，尚无第三方评测。
不只让模型跑起来
连续批处理，是 oMLX 处理并发请求的办法。传统批处理常要等同一批任务全部结束，再接下一批；连续批处理则能在运行中动态加入新请求。多人使用，或多个本地应用同时调用模型时，它可以减少硬件空等。
更关键的是 KV cache。它是模型处理上下文时保存的中间结果，像一张读书草稿，避免每次生成内容都从头重读。长对话和并发请求会让这张“草稿”迅速占满内存。
oMLX 因此把缓存分成两层：常用部分留在 RAM，也就是速度更快的内存热层；暂时不用的部分以 safetensors 格式移到 SSD 冷层。下次请求遇到匹配的上下文前缀，再把相应内容恢复回来。项目方还宣称，即使对话中途发生变化，过去的上下文仍能跨请求缓存和复用。说白了，它试图用 SSD 的容量，换取更大的上下文保留空间，同时把经常访问的部分留在内存里保证速度。
这也接上了本刊此前对 KV cache 的关注。8 月 16 日我们在 Qwen3.8-27B 报道中讨论过它对内存和长上下文的影响；oMLX 更进一步，把问题放进“Mac 长期提供模型服务”的场景里处理。
菜单栏成了控制台
oMLX 不只提供后台服务器，也提供 macOS 菜单栏应用。用户可以让常用模型常驻内存，需要时再换入更大的模型，还能设置上下文限制、启动或停止服务器。官方 .dmg 可直接拖入 Applications，支持应用内自动更新，并会安装一个轻量的命令行入口，让终端命令和 Apple Shortcuts 控制由应用管理的服务器。
它也支持 Homebrew 或源码安装，并能作为崩溃后自动重启的后台服务运行。MCP（Model Context Protocol，一种让模型连接外部工具和数据的协议）则是可选安装项。运行环境限定为 macOS 15.0 以上、Python 3.11—3.13，以及 M1 至 M4 的 Apple Silicon Mac。
一个容易踩中的性能坑
GLM-5.2、MiniMax M3 和 Qwen3.5 可以使用 native custom kernels——针对特定模型和芯片优化的底层计算程序。但普通的 pip install -e . 不会构建它们；缺失时，系统会静默退回更慢、也更耗内存的通用路径。
项目 README 给出的自测很醒目：在 M3 Ultra 上，GLM-5.2 的 fused DSA prefill 使用定制内核时达到 845 tok/s，通用路径约为 29 tok/s，前者约快 30 倍。这里的 prefill 指模型先读取并处理整段输入的阶段。不过，这个数字只说明特定测试中的差距，不能代表 oMLX 的总体生成速度。
从源码或 Homebrew 构建这些内核，需要完整 Xcode，仅有 Command Line Tools 不够。官方 DMG 已预编译并附带内核，对不想处理编译环境的用户更省事。
为什么值得关注
真正值得看的，不是又多了一个“在 Mac 上跑模型”的安装器，而是本地推理开始出现服务化分工：连续批处理负责安排多个请求，内存和 SSD 共同管理上下文，菜单栏与后台服务负责日常运维。模型是否能跑，正在让位于另一个问题——它能否稳定、长期、低摩擦地留在个人电脑上。
局限与未知
- 所有效果论断均来自项目 README，缺少第三方复现。845 与约 29 tok/s 的测试没有披露模型具体版本、量化方式、输入长度、batch、缓存状态和完整方法。
- “上下文变化后仍可复用全部历史缓存”的边界尚不清楚，包括匹配与失效规则、SSD 占用，以及缓存的隐私处理机制。
- 定制内核支持范围和安装方式可能随版本变化；目前不能把 GLM-5.2 的单项结果推广到其他模型或所有推理任务。