为什么每个 Mac 用户都需要这款全新的 AI 模型运行器 (oMLX)

中文العربية Deutsch English Español Français हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский

Computing/SoftwareConsumer ElectronicsInternet Technology

Transcript

00:00:00这是 OMLX。这是一个非常令人兴奋的项目，它本质上是一个专门的推理

00:00:06引擎，旨在压榨出 Apple Silicon 的最后一滴性能。

00:00:11如果你是 Mac 用户，你一定会对此感到非常兴奋。OMLX 本质上是在

00:00:16尝试解决我们在本地硬件上遇到的最大瓶颈，即“内存税”。

00:00:21在这段视频中，我们将了解 OMLX，看看它是如何工作的，并进行一次测试运行，将其

00:00:27与重量级选手 LM Studio 进行对比，看看这款新工具是否真的能成为在 Mac 上

00:00:33运行本地 AI 模型的未来。这将非常有趣，让我们开始吧。

00:00:39那么，OMLX 到底是什么？从核心上讲，它是一个直接构建在 Apple 的

00:00:49MLX 框架之上的运行时，与那些试图支持所有 GPU 的通用工具不同，

00:00:55MLX 是由 Apple Silicon 团队专门构建的，旨在利用驱动 Mac 的

00:01:02统一内存架构。在传统的 PC 中，你的 CPU 和 GPU 拥有独立的内存池，

00:01:09这意味着模型权重之类的数据必须不断地通过 PCI 总线来回拷贝。

00:01:16但 MLX 完全消除了这种拷贝。因为 CPU 和 GPU 共享完全相同的物理

00:01:22内存，MLX 使用了零拷贝数组。当 GPU 完成计算时，CPU 可以立即

00:01:29读取结果，而无需移动任何一个字节。它还使用了延迟计算，这意味着它

00:01:36直到需要输出的最后一秒才会真正执行数学运算，

00:01:41这允许它实时优化整个计算图。但 OMLX 与你标准的

00:01:47LM Studio 设置的不同之处在于它管理 KV 缓存的方式。在典型的 LLM 会话中，你

00:01:54对话历史的每一个字都必须记住在你昂贵的 RAM 中。但 OMLX 引入了一个两层

00:02:01系统。它将即时上下文保存在统一内存中以保证速度，但它会冻结

00:02:07对话中较旧的部分，比如那些庞大的系统提示词和工具定义，并将它们

00:02:12交换到你的 SSD 上。当你将其与 LM Studio 相比时，差异是立竿见影的。是的，

00:02:19它非常稳定且兼容，但问题是它想把整个

00:02:23内存历史记录保持在热状态。OMLX 更像是一个现代操作系统。它足够聪明，知道

00:02:30哪些数据现在需要在大脑中，哪些可以分页到磁盘。所以，让我们启动 OMLX

00:02:36并亲自动手尝试一下。界面非常直观。一开始，我们会看到这个

00:02:41窗口，在这里我们可以指定服务器的目标位置并立即启动它。之后，

00:02:47系统会提示我们提供 API 密钥。让我们输入它。最后，我们进入了这个

00:02:53仪表盘，它是你 OMLX 服务器的主要入口。从这里，我直接

00:03:00下载了 Qwen 2.5 350 亿参数的 4-bit 模型，我们将用它进行测试。

00:03:07我还设置了一个空的仓库，里面有一个 agents.md 文件，我会要求模型

00:03:13创建一个简单的 Web 应用，在这里你可以搜索不同的电影、将它们加入愿望单并使用

00:03:19你的 Movie DB API 密钥进行评分。这次演示没有什么花哨的东西，只是一个简单的编码测试，

00:03:24看看它在处理现实世界编码任务时的潜在表现。在仪表盘页面上，

00:03:31我们可以看到这个部分，它为我们提供了可直接用于不同 AI Agent 框架的

00:03:37代码片段。在这次演示中，我将使用 Codex CLI 来进行这些测试。

00:03:42现在，你可能会纳闷为什么我不直接使用官方的 Claude Code CLI。嗯，

00:03:47现实情况是在 MacBook M2 上，每一个 Token 都至关重要。如果你看看 Claude 的上下文统计，

00:03:54在完全空白的状态下，Claude Code 仅为了自身的系统提示词和工具定义

00:04:02就消耗了大约 16.2K 个 Token。在 32K 的窗口中，这只剩下 16K 个 Token 用于

00:04:09实际项目，当你构建一个全栈应用时，这实在是太小了。但另一方面，

00:04:14我发现 Codex 要精简得多。它不会让对话的基础重量膨胀，

00:04:20这给了我们一个更充裕的跑道来实际编写代码，然后才达到上下文上限。

00:04:26好了，现在我要用这里提供的简单命令启动 Codex。

00:04:31然后我会给它一个简单的启动提示词，解释我们的任务并让它运行。

00:04:36当它在右边运行（烹饪）时，你可以实时看到这个会话的表现，

00:04:42正在生成多少 Token，其中有多少被缓存了，

00:04:46以及整体的缓存效率百分比。能看到平均每秒处理多少

00:04:51Token 也是非常方便的。总的来说，这个运行在我 M2 MacBook Pro 上的

00:04:57350 亿参数 Qwen 2.5 模型花了大约 20 分钟才完成这项任务。这也是

00:05:04预料之中的，因为对这个模型来说这是一项非常繁重的任务。期间有两三次，

00:05:10我遇到了 400 错误，因为提示词超过了我 M2 MacBook 上 30K 的上下文限制。

00:05:17在任何其他工具中，这都会是整个项目的终结者。通常情况下，如果我运行 /clear，

00:05:24它会抹掉 AI 的短期记忆，通常会导致幻觉，因为模型会

00:05:29忘记它刚刚写的代码。但这就是 OMLX 的持久化 SSD 缓存让我折服的地方。

00:05:37尽管我在 Codex 中清除了会话，但我项目的实际计算状态

00:05:42仍然存储在我的 SSD 上。所以当我给 Codex 一个新的提示词让它从中断处继续时，

00:05:48OMLX 识别出了前缀，并立即从磁盘中恢复（水合）了模型的大脑。它没有

00:05:56产生幻觉或从头开始，而是从上次中断的地方直接继续。因此缓存效率

00:06:02在这种情况下真的很有帮助。到任务结束时，我们可以看到在 OMLX 的帮助下，

00:06:08Qwen 2.5 通过产出 178 万个 Token 完成了任务，其中大约 159 万个

00:06:16是被缓存的。所以我们最终获得了 89% 的缓存效率，这非常巨大。至于

00:06:22应用本身，看起来挺不错的。我们可以搜索电影，将它们添加到看单，

00:06:28并进行评分。但是一旦刷新页面，看单就会重置。所以我猜它没有

00:06:33正确实现数据库存储方案，但总体而言仍是一次扎实的努力。现在，这一切

00:06:40看起来令人印象深刻，但我想弄清楚，这种表现与 LM Studio 这样的

00:06:46重量级模型运行器相比如何。所以我决定使用相同的 Qwen 2.5 模型运行相同的任务，

00:06:52使用相同的上下文窗口和约束，看看表现如何。老实说，我

00:06:58没料到会这样，但我实际上在 LM Studio 上得到了更差的表现。任务本身

00:07:04花了大约 35 分钟才完成。这已经比在 MLX 上多了 15 分钟。我还注意到，

00:07:11在运行此任务时，LM Studio 几乎榨干了我的 MacBook。以至于我甚至

00:07:17无法在第二个显示器上观看视频，因为它由于严重的 RAM 短缺而卡顿。

00:07:23而在使用 OMLX 时我没有遇到同样的问题，因为在 OMLX 上运行时，我能够

00:07:30轻松浏览网页、观看视频或做任何其他任务，而 Codex 仍在

00:07:35后台运行。但这在 LM Studio 上几乎是不可能的。看看这些统计数据。让我

00:07:41更震惊的是，LM Studio 的平均每秒 Token 速度是 16 个。而在

00:07:47OMLX 上，速度大约是 47 个。这实际上解释了为什么任务多花了 15 分钟才完成。

00:07:55然而，我必须给予应有的赞赏。LM Studio 没有像 OMLX 那样抛出任何由于

00:08:01上下文限制瓶颈导致的 400 错误。所以 LM Studio 的上下文管理非常稳定且

00:08:08运行完美。如果我们看最终结果，两者非常相似。这次我没有

00:08:13做任何花哨的动画，但老实说，这感觉就像是用不同的

00:08:18种子值对比同一个模型对同一个任务的输出。所以我不会在这里匆忙下结论。

00:08:25这是同一个 Qwen 2.5 模型。你可以亲自评判 Qwen 模型的输出。那么，

00:08:33最终结论是什么？嗯，我必须说 OMLX 的表现让我留下了非常深刻的印象。如果你使用的是

00:08:39内存有限的 MacBook，并且你想在后台运行本地 AI Agent 的同时实际使用你的电脑，

00:08:45那么 OMLX 是一个完美的工具。它通过利用你的高速 SSD，结合那甜美的

00:08:52MLX 框架，让我们在 Apple Silicon 上更流畅地运行模型，实际上为你提供了 RAM 扩展。

00:08:58但是，是的，偶尔的 400 错误意味着你必须更多地进行手动干预，

00:09:05也许偶尔需要执行一下 clear 命令。但这是为了获得快三倍的

00:09:10生成速度而做出的权衡。但我认为在这种情况下是非常值得的。所以，这些

00:09:16像 OMLX 这样的项目证明了我们并不一定需要 128GB 的 RAM 来运行

00:09:23强大的 Agent。我们只需要一种更聪明的方法来管理我们 MacBook 上已有的内存。

00:09:29几个月前我们进行了一项调查，发现我们的大多数观众都是 Mac 用户。

00:09:34所以我很好奇。你是否在自己的机器上尝试过 OMLX？到目前为止，

00:09:40体验如何？请在下方的评论区告诉我们。这就是

00:09:45简而言之的 OMLX。朋友们，如果你喜欢这种类型的技术分解，请通过

00:09:50猛击视频下方的点赞按钮让我知道。也别忘了订阅我们的

00:09:55频道。我是来自 Better Stack 的 Andris，我们下期视频再见。

Key Takeaway

oMLX 通过 MLX 框架和 SSD 缓存交换技术，使内存在 32GB 左右的 MacBook 能够以每秒 47 个 Token 的高速运行 350 亿参数模型，同时保持系统日常任务的流畅度。

Highlights

oMLX 构建在 Apple 的 MLX 框架之上，利用零拷贝数组实现 CPU 与 GPU 之间无延迟的数据共享。
该工具引入两层 KV 缓存系统，将即时上下文保留在统一内存中，而将较旧的对话历史和系统提示词交换到 SSD 存储。
在 M2 MacBook Pro 上测试 Qwen 2.5 35B 模型时，oMLX 的生成速度达到每秒 47 个 Token，比 LM Studio 快 3 倍。
oMLX 的缓存效率达到 89%，在 178 万个 Token 的生成任务中，有 159 万个 Token 成功从缓存恢复。
与 LM Studio 耗尽系统资源导致电脑卡顿不同，oMLX 在后台运行 35B 参数模型时仍可流畅浏览网页和播放视频。

Timeline

Apple Silicon 专属的推理架构优势

oMLX 利用 Apple Silicon 团队专门构建的 MLX 框架来优化统一内存架构。
零拷贝数组技术消除了传统 PC 中数据在 CPU 和 GPU 之间通过 PCI 总线进行拷贝的需求。
延迟计算模式确保数学运算仅在输出前的最后一刻执行，从而实时优化计算图。

传统的本地 AI 运行瓶颈在于内存管理和数据传输效率。通过直接建立在 Apple 官方 MLX 框架之上，oMLX 能够压榨出硬件的极限性能。这种架构允许 GPU 计算结果被 CPU 立即读取，无需移动任何字节，大幅提升了推理效率。

两层缓存系统与内存管理机制

oMLX 将庞大的系统提示词和工具定义等静态内容冻结并分页存储至 SSD。
这种分层系统模仿现代操作系统的内存分页机制，仅将活跃数据保留在 RAM 中。
相比将整个历史记录保持在热状态的传统工具，该方案大幅降低了对物理内存的占用。

在处理大型语言模型会话时，KV 缓存往往会迅速占满昂贵的统一内存。oMLX 通过智能识别数据优先级，将不常用的长对话历史或背景信息转移到高速 SSD 上。这种方法有效解决了 Mac 用户的“内存税”问题，让有限的硬件能够承载更大规模的上下文。

实测表现：Qwen 2.5 35B 模型编码任务

在 M2 MacBook Pro 上运行 350 亿参数模型完成 Web 应用开发任务耗时约 20 分钟。
持久化 SSD 缓存允许在遇到上下文溢出错误并清除会话后，立即从磁盘恢复项目计算状态。
整个任务产出 178 万个 Token，其中 159 万个被成功缓存，整体效率为 89%。

测试过程中使用 Codex CLI 代替 Claude Code，因为后者自身消耗约 16.2K 个 Token，会大幅压缩 32K 的上下文窗口。尽管任务期间因硬件限制出现了 400 错误，但 oMLX 识别出前缀并直接从磁盘水合（hydrate）模型大脑，避免了模型产生幻觉。最终生成的电影搜索应用具备搜索、添加愿望单和评分功能。

oMLX 与 LM Studio 的性能对比

LM Studio 完成相同任务耗时 35 分钟，比 oMLX 慢了 15 分钟。
oMLX 的平均生成速度为 47 tokens/s，而 LM Studio 仅为 16 tokens/s。
LM Studio 在运行过程中会榨干系统内存，导致第二显示器视频播放出现严重卡顿。

对比测试显示，LM Studio 在上下文管理上虽然表现得更为稳定且没有报错，但对系统资源的消耗极高。由于缺乏 oMLX 那样的智能内存交换，LM Studio 运行时无法进行多任务处理。速度差异是决定性的，oMLX 的生成效率几乎是行业重量级选手的 3 倍。

小内存机器运行强大 Agent 的可能性

通过利用高速 SSD 作为内存扩展，低内存 MacBook 用户也能后台运行 AI Agent。
高速生成能力足以弥补偶尔需要手动清除缓存的人工干预成本。
更聪明的内存管理策略比单纯追求 128GB 的巨量 RAM 更具实际意义。

oMLX 证明了软件层面的优化可以弥补硬件内存的不足。对于大多数 Mac 用户而言，这种利用 SSD 扩展 RAM 性能的方案提供了极高的性价比。即使在后台运行 350 亿参数的重型模型，用户依然可以正常进行网页浏览等日常工作。

Community Posts

Write about this video