不是模型慢，是冷启动。70B 模型的 KV cache 要从 SSD 加载到统一内存，30-90 秒的 TTFT（Time To First Token）是常态。这段时间里你就盯着光标闪，怀疑是不是死机了。
第二次问”你好”，秒回——因为 KV cache 已经在内存里了。但你一换话题、一改上下文，又得重来。
oMLX 解决的就是这个问题：把 KV cache 当成热数据，用 SSD 做冷层。TTFT 从 30-90 秒压到 5 秒以内。
它是什么
oMLX 是一个为 Apple Silicon 优化的 LLM 推理服务器，用 Python 写的，从 macOS 菜单栏管理。核心特性：
1. 连续批处理（continuous batching）：多个请求动态拼批，不像 vLLM 那样等批满才发。 2. 分层 KV cache：热层在统一内存，冷层在 SSD。上下文切换时，旧 KV 不丢弃，落盘到 SSD。 3. 菜单栏管理：不用敲命令行，点菜单栏图标就能切模型、看监控、停服务。
但真正有意思的不是这些功能本身，而是设计哲学：它把”KV cache 是一次性资源”这个假设推翻了。
KV cache 的问题
先说背景。LLM 推理时，每个 token 的注意力计算需要前面所有 token 的 Key 和 Value 向量。这些 K、V 向量组成的缓存叫 KV cache。70B 模型、32K 上下文，KV cache 能到 8GB——比模型权重还大。
传统做法是：KV cache 只存在内存里，请求结束就丢弃。下次同一用户来，从头算。这就是为什么”第一次问你好要 47 秒”——那 47 秒不是在算”你好”两个字，是在重新计算之前所有对话的 KV cache。
oMLX 的突破点：KV cache 是可序列化的。既然能算出来，就能存下来。存在 SSD 上，下次直接加载，不用重算。
这和操作系统的虚拟内存是同一个思路：内存不够用就用磁盘，磁盘比内存慢但比”重算”快得多。oMLX 把这个 1960 年代的设计原则用到了 2026 年的 LLM 推理上。
分层缓存的三个关键设计
1. 上下文切换不丢缓存
传统 LLM 服务器：你改一下上下文（比如从”讨论 Rust”切到”讨论 Python”），之前的 KV cache 全部失效，得重算。oMLX 的做法是：旧上下文的 KV 落盘到 SSD，新上下文的 KV 在内存里算。如果之后又切回旧上下文，从 SSD 加载——不用重算。
这对编码场景特别有用。你在 Claude Code 里改 A 文件，问”这个函数怎么调”；切到 B 文件，问”这个 bug 怎么修”；再切回 A 文件——传统服务器要重算 A 文件的 KV，oMLX 直接从 SSD 加载。
2. 跨请求缓存复用
更激进的是：不同请求之间也能复用 KV cache。如果你和同事都在用同一个模型、类似的系统提示词，系统提示词部分的 KV cache 可以共享。这和 vLLM 的 PagedAttention 思路类似，但 oMLX 把它扩展到了 SSD 层。
3. 原生自定义内核
对 GLM-5.2、MiniMax M3、Qwen3.5 这些模型，oMLX 提供原生 Metal 内核。README 里有个数据很惊人：GLM-5.2 的 fused DSA prefill，原生内核比通用路径快 30 倍（845 tok/s vs 29 tok/s，M3 Ultra）。
这不是”优化 10%”——是 30 倍。原因是通用路径用 MLX 的抽象接口，每次操作都要经过一层调度；原生内核直接写 Metal shader，跳过所有中间层。这和”让 Rust 当会计，让 Python 当诗人”是同一思路——把确定性的、性能关键的东西下沉到编译层。
和其他本地推理方案的区别
| 方案 | 平台 | KV cache 策略 | TTFT（70B 冷启动） |
|---|---|---|---|
| Ollama | 全平台 | 内存，请求结束丢弃 | 30-90 秒 |
| LM Studio | 全平台 | 内存，请求结束丢弃 | 30-90 秒 |
| MLX server | Apple | 内存，请求结束丢弃 | 30-90 秒 |
| vLLM | CUDA | PagedAttention（内存分页） | N/A（不支持 Mac） |
| oMLX | Apple Silicon | 内存 + SSD 分层 | <5 秒 |
关键差异：oMLX 是唯一把 SSD 纳入 KV cache 层级的本地推理服务器。vLLM 的 PagedAttention 在内存里分页，oMLX 在内存和 SSD 之间分层——前者解决”内存碎片”，后者解决”内存不够”。
Apple Silicon 的统一内存架构让这个设计特别合理：M3 Ultra 有 192GB 统一内存，SSD 读写 7GB/s，从 SSD 加载 8GB KV cache 只要 1 秒多。这在 CUDA + 独立显存的架构上不成立——PCIe 带宽只有 4GB/s，而且 GPU 不能直接访问系统 SSD。
概念谱系定位：分层存储的回归
从”换层面解决问题”的概念谱系看，oMLX 是第十三个成员：
– 章鱼用 RNA 编辑实现”DNA 预训练 + 推理时计算” – SOPHIA 把不同状态路由到不同出口方向 – Euclid-MCP 把推理外包给 Prolog – ai-memory 把记忆从 Agent 内部搬到文件系统 – oMLX 把 KV cache 从内存扩展到 SSD
共同原则：不强化同一个资源，而是换一个层面调度。内存不够，就用 SSD；SSD 不够，就重算。关键不是”哪个最快”，而是”哪个颗粒度最对”——KV cache 的颗粒度是”可序列化的张量”，那就序列化到 SSD；模型权重的颗粒度是”只读的大文件”，那就 mmap 到内存。
这和操作系统的设计哲学一脉相承：CPU 缓存、内存、SSD、HDD、网络存储——五层存储层级，每层有不同的访问模式和成本。oMLX 做的事情，是把这套成熟的设计模式引入到 LLM 推理这个新领域。
一个被忽视的细节：菜单栏管理
oMLX 的菜单栏设计容易被当成”UI 糖衣”忽略掉。但它其实是个重要的工程信号：本地 LLM 推理应该像系统服务，而不是像命令行工具。
Ollama 和 LM Studio 的体验是”打开终端 → 敲命令 → 等响应”。oMLX 的体验是”菜单栏图标常驻 → 点一下 → 切模型/看监控/停服务”。这和 macOS 的 Time Machine、Spotlight 是一个层级——系统级服务，不是应用。
这个定位差异决定了用户行为：命令行工具是”我要用时才启动”，系统服务是”一直在后台跑，我需要时直接用”。后者才是本地 LLM 的正确使用方式——你不会每次想搜文件都打开终端敲 find /，那为什么要每次想问 LLM 都打开终端敲 ollama run？
诚实评估
不是没有问题：
– 平台锁定：只支持 Apple Silicon，Linux/Windows 用户用不了。这是设计选择——MLX 框架是 Apple 的，Metal 是 Apple 的，统一内存是 Apple 的。但意味着受众有限。
– macOS 15.0+ 要求：Sequoia 以上。老 Mac 用户被排除。
– 自定义内核需要 Xcode：Homebrew 默认装的是通用路径，要 30 倍加速得装完整 Xcode（6GB+）再 --HEAD --with-custom-kernel 重装。门槛不低。
– 单机假设：实验性的 Multi-Mac 推理（Ring/Thunderbolt RDMA）还在 source build 阶段，不是默认功能。
但这些代价是”Apple Silicon 用户的一次性投入”。装好之后，本地 70B 模型的体验从”等 47 秒”变成”等 5 秒”——这是从”不可用”到”可用”的质变。
结语
oMLX 让我想起一个观察：很多技术突破不是”更快”，而是”更对颗粒度”。
KV cache 不是”一次性资源”——它是”可序列化的中间状态”。一旦换这个视角，SSD 缓存就是自然推论。从 47 秒到 5 秒，不是靠更快的芯片，而是靠把存储层级从”内存 only”扩展到”内存 + SSD”。
在 Agent 时代，这个思路有额外启示：Agent 的上下文窗口是有限的，但 Agent 的工作记忆可以外化（ai-memory 做的事）。Agent 的 KV cache 是易失的，但可以落盘（oMLX 做的事）。把易失的变持久，把黑盒的变可读——这是 2026 年本地 AI 基础设施的共同主题。
—
项目地址：https://github.com/jundot/omlx 语言：Python（Metal 内核用 Metal Shading Language） 今日 stars：96 官网：https://omlx.ai 适合人群：Apple Silicon 用户、本地 LLM 跑大模型的开发者、Claude Code/Codex 本地部署用户