LM Studio Bionic 1.1.10 接入 oMLX 引擎：Mac 本地模型可用内存加 SSD 两级 KV 缓存，并支持 MLX 投机解码

核心背景与行业痛点

在 Mac 上跑本地模型做编程，最大的痛点不是生成速度，而是长上下文的预填充：Claude Code、OpenCode 这类 agent 每轮都会带上很长的系统提示和对话历史，上下文一变，很多本地服务器就要从头重算，等待时间动辄几十秒。oMLX 正是为这个问题而生，作者在 README 中直说做它是为了让本地模型能真正用于编程工作。今年 3 月就有用户在 LM Studio 的 mlx-engine 仓库提需求，希望引入 oMLX 的缓存能力，现在 LM Studio 以可下载引擎的形式落地了。

架构亮点与底层机制

oMLX 借鉴 vLLM 的块式 KV 缓存，支持前缀共享和写时复制，并分为两级：常用块留在内存（热层），内存满了就以 safetensors 格式卸载到 SSD（冷层），下次遇到相同前缀直接从磁盘恢复，服务器重启后也有效。它还基于 mlx-lm 的 BatchGenerator 做连续批处理，支持多模型同时服务、按最近最少使用自动卸载和按模型设置空闲超时。LM Studio 这边的做法是把 oMLX 做成一个可单独下载的引擎，与现有 MLX 引擎并列，用户已下载的 MLX 模型无需重新转换。

权威 Benchmark 与实测跑分对比

LM Studio 官方未公布 oMLX 引擎与其原有 MLX 引擎的速度对比。oMLX 官网有社区提交的跑分表，例如 10 月 30 日一条 M3 Ultra 96GB 跑 Qwen3.8-Flash-Next 4bit、8k 上下文的记录为预填充约 1,050 tok/s、生成约 56 tok/s，但这属于社区自报数据，不同芯片、量化和上下文差异很大，不能当作 LM Studio 内的官方成绩。

开发者实战落地与开箱指南

升级到 Bionic 1.1.10 后，在运行时设置中下载 oMLX 引擎，再用它加载已有的 MLX 模型即可。最适合的场景是用本地模型配合编程 agent 的长会话，重复前缀越多，SSD 冷缓存的收益越明显；注意 SSD 缓存会占用磁盘空间。发布当天已有用户反馈「重启以应用更新」失败，LM Studio 正在排查，遇到问题可先手动重启应用。