你在 Mac 上同时跑几段长对话，常会遇到两难：把模型读过的内容都留在内存里，空间很快吃紧；清掉它们，下一轮又得重新计算。oMLX 想做的是给这些“临时笔记”分冷热区，再把模型调度和日常管理装进同一套服务端。它面向 Apple Silicon——Apple 的 M 系列芯片平台——让本地大模型更适合多会话和长对话场景。
需要先说明：目前性能数据和功能描述主要来自项目作者，缺少论文、第三方基准和完整复现实验；一则 M2 Ultra 提速反馈则只有 Reddit 标题。因此，这更像一个值得跟踪的工程项目，而不是已经得到充分验证的性能结论。
把等待空位变成动态排队
oMLX 支持 continuous batching（连续批处理）。普通批处理像等一桌人到齐再发车；连续批处理则会动态接纳不同时间到达、长度不同的请求，只要计算位置空出来，就把新请求补进去。它主要改善多人或多个 Agent 同时调用模型时的总吞吐，而不等于每一句回答都会按同样比例加速。
项目作者称，oMLX 最初从 vllm-mlx 0.1.0 出发，后来逐渐加入多模型服务、分层 KV 缓存、管理后台和 macOS 菜单栏应用。用户可以从菜单栏管理模型、上下文上限、自动换入换出和服务器，也能把常用模型固定在内存中，需要时再加载更重的模型。
SSD 成了第二层“草稿纸”
KV Cache 是模型读过上下文后留下的中间计算结果，好比一张临时草稿纸，续写时不必从头再读。问题是，对话越长、会话越多，这张草稿纸越占内存。
oMLX 的做法是分层保存：常用缓存留在 RAM（内存）的热层，不常用的块移到 SSD 冷层；下次请求若匹配相同前缀，再从 SSD 恢复。作者还宣称，即使对话中途上下文发生变化，既有上下文缓存仍可保留，并跨请求复用。不过“全部既有缓存都可复用”是项目方的绝对化表述，现有材料没有交代缓存失效条件、恢复延迟和容量边界。
这项设计源于很具体的使用需求。据 oMLX GitHub，作者用本地模型做真实编码工作时，不希望每轮对话都重读漫长提示词。于是，一个推理引擎分支逐渐变成了可以从菜单栏照看的 Mac 桌面工具。
一个醒目的数字，但别急着外推
项目给出的最突出数据来自 GLM-5.2：在 M3 Ultra 上，fused DSA prefill（把输入内容先读入并计算的融合路径）使用原生自定义内核时达到 845 tok/s，而通用回退路径约为 29 tok/s，相差约 30 倍。
但这个数字只说明一条特定路径。材料没有披露模型规模、量化方式、上下文长度、批大小和完整测试方法，不能据此外推 oMLX 的整体推理速度。GLM-5.2、MiniMax M3 和 Qwen3.5 的原生内核目前还要求 HEAD 构建；普通源码安装会静默退回更慢、也更占内存的通用路径。官方 DMG 则预编译了这些内核。
另有 Reddit 标题称，新版让 M2 Ultra 上的“Qwen3.8 Flash”明显提速，但没有正文、版本号、数字或测试方法，而且模型名与项目材料中的 Qwen3.5 不一致。这条反馈只能视作待核实的用户线索。
为什么值得关注
oMLX 有意思的地方，不是单独发明了某一种缓存，而是把连续批处理、RAM 与 SSD 的分层缓存、模型自动换入换出，以及菜单栏和网页管理放进同一套 Apple Silicon 服务端。它要求 macOS 15.0 以上、Python 3.11–3.13，并支持 M1 至 M5 系列芯片。对不想把本地模型当作一次性命令行实验的用户来说，这种整合本身就有价值。
局限与未知
- “补上 SSD 缓存”不宜理解为此前整个 Apple 芯片推理生态都没有这项能力；现有材料只能证明 oMLX 提供了 SSD 冷层 KV Cache。
- 缓存会把内存压力转移到磁盘。据 oMLX GitHub Issues，一名 24GB M4 Pro Mac mini 用户把 SSD 缓存上限设为 64GB，不到一小时却增长到 83GB；该开放问题说明容量控制仍需观察。
- 缓存正确性同样关键。据项目 Issues，2026 年 7 月曾有缺陷漏掉不足 2048 token 的末尾分块，导致模型忽略新消息等异常；问题后来关闭处理，但也提醒我们：缓存不仅影响速度，还会直接影响模型是否“记得”完整上下文。