omlx

用了 omlx 一周后，我卸载了 LM Studio

omlx 把本地 LLM 的 KV Cache 持久化到 SSD，让长上下文在重启后仍能快速恢复。本文比较它与 LM Studio，并介绍安装、API、MCP 和多模型服务。

Leo Pang

— 9 min read
Share
Apple Silicon MacBook、本地 LLM 服务器界面和 NVMe SSD 组成的 omlx 中文封面图。

本文为翻译转载，原文作者 Sarath S，发布于 s10n.dev / Medium，原文链接：I deleted LM Studio after a week with omlx。本文保留原文结构、观点、命令与代码示例；性能数字来自原作者和 omlx 项目，请结合自己的机型、模型与上下文长度验证。

那是一个星期二的深夜，已经过了午夜。我正让本地 coding agent 帮我进行一次大规模重构：五个文件同时打开，经过两个小时的来回对话，累计上下文已经达到 7 万 token。这个 agent 终于像一位入职三周的新员工那样理解了我的项目。

然后，我的 MacBook 睡眠了。

我点亮屏幕时，对话仍然显示在那里，看起来一切正常。我让 agent 应用下一项修改。它先思考了一下，然后是十秒、三十秒。LM Studio 的进度条又开始逐 token 处理整个前缀，仿佛之前从来没有见过这些内容。

事实也的确如此。KV Cache 原本让对话中的第二条消息比第一条快得多，但我去泡茶的时候，它已经被悄悄清掉。四分钟后，第一个 token 终于返回。我坐在那里，看着这台昂贵的 MacBook 重新阅读自己的短期记忆。

那一刻，我开始寻找替代方案。两天后，我发现了 omlx。又过了一周，我卸载了 LM Studio。下面就是原因。

用两句话说明 omlx 是什么

omlx 是一款面向 Apple Silicon 的开源 LLM 服务器，构建在 MLX 之上，可以通过 Homebrew tap 安装，也提供一个很小的 PyObjC 菜单栏应用。它和 LM Studio 或 Ollama 做的是同一类工作：把兼容 OpenAI 的请求路由到本地模型，但它做出了一个其他工具没有采用的设计决定。

这个决定就是整件事的核心。

不会消失的缓存

你在 Mac 上运行过的本地 LLM 服务器，通常都会把 KV Cache 放在内存里。LM Studio、Ollama、llama.cpp 都是如此。缓存可以让一段对话的第二轮比第一轮快 50 到 100 倍。但进程退出、Mac 重启，或者 macOS 在内存压力下回收资源时，缓存就会消失。下次打开同一段对话，模型必须从头重新处理整个前缀。

omlx 把缓存写入 SSD

就是这么简单，这就是它的关键技巧。omlx 和其他服务器一样，在内存中保留一个热缓存层。当这一层装满时，缓存块会以 safetensors 文件的形式换出到 ~/.omlx/cache。下一次请求的前缀与旧缓存块匹配时，这些块会从磁盘流式读回。它的块布局借鉴了 vLLM，因此两段使用相同 system prompt 的对话，也可以共享同一组磁盘页面。

根据项目自己的基准测试，在长上下文工作流中，前缀进入持久化缓存层后，首 token 时间可以从 30 至 90 秒降到 1 至 5 秒，接近一个数量级的提升。而实现方式，本质上只是把缓存写成文件。

它会在三类场景中明显改变体验：

  • 基于代码仓库工作的 coding agent。8K token 的 system prompt 和 30K token 的项目上下文可以跨重启保留。第二天早上回来时，agent 仍然处于“热”状态。
  • 对个人知识库做 RAG。你反复提问时经常检索到的前 20 个片段会留在磁盘缓存中。笔记本重启以后，再问相似问题，答案仍可能在一秒左右开始返回。
  • 长期文档工作。上周五与你对话的那份 6 万 token PDF，到周一早上仍然可以保留缓存。

如果你只是把本地模型当成聊天玩具，这一切并不重要，因为你从不重复使用同一段大前缀，缓存对你来说是隐形的。但当脚本、agent 或产品多次用同一段大型前缀调用模型时，其他服务器会让你重复支付预填充的计算成本，omlx 则不会。

这套方案能在 Mac 上工作，是因为 M 系列机器的 NVMe SSD 足够快。从磁盘读取注意力状态，比让模型重新计算一遍快得多。Apple 已经提供了硬件，而 omlx 是 macOS 上最早真正利用这项能力的服务器之一。我也不明白为什么以前没有人这么做。

只需要三条命令

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

这些命令会安装二进制文件、注册一个 launchd 服务，并在 8000 端口启动服务器。把任何兼容 mlx-lm 的模型放入 ~/models，例如 Qwen3、Gemma 3、gpt-oss、DeepSeek 等，就可以开始使用。Hugging Face 上 mlx-community 组织中的模型都可以使用。

更喜欢菜单栏应用？可以从 Releases 下载 .dmg。它是原生 PyObjC 菜单栏应用，不是 Electron，因此不会让一套 Chromium runtime 常驻菜单栏并持续消耗电量。

第一天不一定需要，但很快会用到的功能

持久化缓存是最醒目的卖点，下面这些功能则让 omlx 更像一台真正的服务器，而不是简单的模型包装器。

  • 多模型服务。在同一个进程中加载 LLM、VLM、Embedding 模型和 Reranker。它支持 LRU 淘汰、按模型设置 TTL，并可从仪表板手动固定或取消固定模型。你的 RAG 技术栈不再需要四个容器。
  • 管理仪表板。访问 localhost:8000/admin，可以查看实时模型列表和内存占用，使用聊天测试区，还可以在指定并发下运行吞吐量测试。无需先写客户端代码，就能挑选合适的量化级别。
  • 兼容 OpenAI 和 Anthropic。POST /v1/chat/completions 可以工作，POST /v1/messages 也可以。只需把两种 SDK 的 base URL 指向 omlx，无需修改调用结构。
  • 内置 MCP 支持。传入 --mcp-config mcp.json，服务器就能通过 Model Context Protocol 连接你的工具服务器。
  • Apache 2.0 许可证。你可以阅读、修改、fork，甚至把它集成到自己的产品中。

用代码感受持久化缓存

下面的客户端示例展示了持久化缓存的实际体验。一个摘要工具先读取文档并请求摘要，然后再提出一个复用相同上下文的后续问题。重点在于第二次调用，以及退出服务器再重新启动后会发生什么。

import { readFile } from 'node:fs/promises';
import OpenAI from 'openai';

const client = new OpenAI({
  baseURL: 'http://localhost:8000/v1',
  apiKey: 'omlx-local',
});

const MODEL = 'Qwen3-8B-4bit';

type AskResult = { text: string; elapsedMs: number };

async function ask(systemPrompt: string, userPrompt: string): Promise<AskResult> {
  const started = performance.now();
  const response = await client.chat.completions.create({
    model: MODEL,
    messages: [
      { role: 'system', content: systemPrompt },
      { role: 'user', content: userPrompt },
    ],
    temperature: 0.2,
    max_tokens: 300,
  });
  const elapsedMs = Math.round(performance.now() - started);
  const text = response.choices[0]?.message?.content?.trim() ?? '';
  return { text, elapsedMs };
}

const path = process.argv[2];
if (!path) {
  console.error('usage: bun cache-demo.ts <large-doc.md>');
  process.exit(1);
}

const doc = await readFile(path, 'utf8');
const systemPrompt =
  'You are a careful technical reader. Use the document below as the source of truth.\n\n' +
  '<DOCUMENT>\n' + doc + '\n</DOCUMENT>';

const first = await ask(systemPrompt, 'Give me the document in three bullets.');
console.log('first call ms: ' + first.elapsedMs);
console.log(first.text);
console.log('---');

const second = await ask(
  systemPrompt,
  'List the three biggest open questions the doc leaves unanswered.'
);
console.log('second call ms: ' + second.elapsedMs);
console.log(second.text);

用一份 5 万 token 的文档运行。第一次执行时，在任何服务器上都可能得到类似结果：

first call ms: 41200
second call ms: 1850

第一次调用需要为整份文档完成 prefill。第二次很快，是因为缓存仍然在内存中。现在退出 omlx，运行 brew services restart omlx，然后再次执行脚本。其他服务器的两项数字通常都会回到冷启动水平，而在 omlx 上，示例结果是：

first call ms: 3100
second call ms: 1780

第一次调用之所以仍然很快，是因为前缀缓存从磁盘回来了。这个差距，就是 omlx 的全部卖点。

omlx 与 LM Studio：不绕弯子的比较

LM Studio 对它所服务的场景来说完全不错。它的模型浏览器更漂亮，新手引导也更友好。设计师同事可以自己安装它，与本地模型聊天，不需要向你求助。这样的场景可以继续使用 LM Studio。

但从代码开始调用模型的那一刻起，omlx 往往才是你真正想要的工具。这是最诚实的比较：它们并不是在争夺同一份工作。LM Studio 是聊天应用，omlx 是服务器。

谁应该今晚就安装它

如果你正在构建本地 agent、面向个人笔记的 RAG pipeline，或者常驻终端的 coding 助手，今晚就可以安装 omlx。如果你每天使用本地 LLM 的方式，只是在一个窗口里输入问题并阅读回答，那么无需折腾，继续使用现有工具即可。

合上笔记本以后仍然不会消失的缓存，是本地 AI 从有趣玩具变成可靠基础设施的分界线。一旦体验过重启后仍能快速恢复一段 5 万 token 前缀，你就很难再愿意回到过去。我至少不愿意。

原文参考资料

原文：Sarath S：I deleted LM Studio after a week with omlx，2026 年 7 月 16 日。

Read more