前两天有朋友发来一个B站视频问我：MLX Studio、vMLX、oMLX，这几个名字到底是不是同一个东西？
我点开那个视频的评论区，最热的一条就是"和omlx有啥区别"，下面跟着"同问"。还有人说得更直白：“有很多这样的，比如oMLX、vMLX，这些好像都差不多。”
如果你也有一台M芯片Mac，最近半年想跑本地大模型，大概率被这种混乱困扰过：老工具Ollama、LM Studio还在用，新工具扎堆冒出来，一个比一个喊得响——“比Ollama快4.2倍”“1.9万star”“Apple Silicon上最先进的引擎”。
今天把这张地图一次讲清楚。先说结论：这个赛道没有"最强"，只有"你是哪一派"。选错了不是不能用，是难受。
先复盘：半年里到底发生了什么
给没跟上进度的朋友补个时间线，以下都有出处可查：
今年2月，一个叫Rapid-MLX的仓库悄悄创建，5月4日它冲上GitHub Trending第7名，当时只有844个star。它的口号简单粗暴：面向Apple Silicon的本地推理引擎，宣称比Ollama快2-4倍。知乎
几乎同期，另一个叫oMLX的项目走的是完全不同的路子：不拼单轮速度，而是把KV Cache做成了"内存热层+SSD冷层"的分层缓存，主打长上下文反复调用。知乎到今天，它的star数已经达到18935，官方定位是带连续批处理和SSD缓存、由macOS菜单栏管理的推理服务。GitHub
3月底，一个免费的一体化工具MLX Studio在B站火了，一条教学视频拿到9421播放、422收藏——本地跑大模型、Flux生图、还能把接口喂给Claude Code。评论区有人点破：它其实就是vMLX换了个名字，仓库还叫vMLX。哔哩哔哩
然后是重量级变化：3月30日，Ollama官宣在Apple Silicon上预览MLX引擎，直接利用Apple统一内存架构，在M5、M5 Pro和M5 Max芯片上还会调用新的GPU Neural Accelerators同时加速首字延迟和生成速度。Ollama官方博客6月中旬，Ollama又对MLX引擎做了一轮大优化，官方口径是输出速度最高提升20%，还支持了英伟达推出的NVFP4量化格式，官方对比显示其质量损失比常见的q4_K_M大约减少一半。Ollama官方博客
8月10日，Meta新发布的30B多模态模型Muse Glimmer，在Ollama上是通过MLX引擎在Apple Silicon首发支持的。GitHub8月14日，Qwen3.8 27B上架，同样带了一个专门的mlx变体，官方描述是针对Apple Silicon做了最大化性能和输出质量优化，适合重复性任务和coding agent。GitHub
看懂了吗？风向已经变了。上半年大家还在讨论"MLX系新工具会不会革Ollama的命"，下半年Ollama直接把MLX引擎收编了，新模型开始优先走这条路。与此同时，今天知乎上还有个新提问挂着：苹果放着这么好的硬件能力，为什么就是不抓紧好好搞一搞他们的MLX？知乎官方工具mlx-lm的最新版确实还停在4月下旬的v0.31.3，而社区生态已经卷成了这样。
五条路，各自是什么性格
把现在Mac上跑本地大模型的主流路径拆开看，其实就五种性格：
Ollama（MLX引擎）：稳健派。 生态最全、模型上架最快，现在新模型在Mac上基本是"发布即可跑"。换上MLX引擎后，它做了三件关键的事：JIT算子融合提速、支持NVFP4高质量4-bit量化、针对agent场景优化前缀缓存——agent每调一次工具都要重发完整上下文，Ollama用快照系统让模型状态得以保留，这对跑Claude Code这类工具的人是实打实的收益。命令也简单，`ollama run qwen3.8:27b-mlx` 就是走新引擎。
LM Studio：图形界面派。 不想碰命令行的首选，GGUF模型生态成熟，下载、量化、参数调整全有界面。评论区有用户实测，同一台机器跑Qwen3.6 35B 8bit量化，LM Studio是65 tps，vMLX能到90 tps。哔哩哔哩
Rapid-MLX：速度激进派。 3个月从844 star涨到3497 star，README写着"比Ollama快4.2倍、缓存命中时TTFT 0.08秒、100%工具调用支持"，能直接接Cursor、Claude Code、Aider。GitHub但注意它benchmark的测试机是Mac Studio M3 Ultra 256GB——这是顶配中的顶配。而且项目迭代极快，5月4日前后两天就连发v0.6.7到v0.6.9三个版本，功能猛但稳定性还在爬坡。知乎
oMLX：服务化派。 1.9万star不是白来的。它的核心卖点一句话：把KV Cache持久化到"内存+SSD"两级缓存里，配合连续批处理，专门解决"一个项目几万token上下文，每改一行代码都要重新prefill"的痛点。它甚至做成了macOS菜单栏常驻服务。代价是：有用户实测反馈，它暂不支持模型分片，混合专家模型会一次性全部加载进内存——小内存机器要注意。哔哩哔哩
MLX Studio（vMLX）：全能一体派。 聊天、代码、Flux生图全在一个桌面应用里，提供OpenAI和Anthropic兼容接口，背后还有自己的JANG_Q混合精度量化。适合不想装一堆东西、开箱就要"什么都能玩"的人。缺点是项目年轻，评论区有人吐槽刚上手没几分钟就碰到好几个bug，还得再等等。哔哩哔哩
另外还有一条"官方极简路"：mlx_lm命令行工具。研究、微调、写代码的人用它，普通跑模型不推荐优先选它——更新节奏明显慢于社区。
"快4.2倍"这话，你得会打折听
这类工具最爱传播的就是速度数字，但作为一个要帮你做判断的内容，必须把水分说清楚。
第一，看测试机。Rapid-MLX那些漂亮的数字，比如Phi-4 Mini 14B跑到180 tok/s、Qwen3.5-122B还有44 tok/s，全部出自Mac Studio M3 Ultra 256GB。知乎大多数人的Mac是16G、32G统一内存，带宽和内存容量都不是一个量级，体验没法线性平移。
第二，看真实用户怎么说。除了前面提到的65对90 tps，还有用户反馈自己的M5 32G一开始能跑50多，后面掉到14。哔哩哔哩差距是真实存在的，但没有"4倍"那么夸张，这才是普通用户能期待的数量级。
第三，看你的用法。如果你是把本地模型接给Claude Code、Cursor当coding agent，瓶颈往往不是单轮吐字速度，而是上下文反复prefill。上下文越滚越长、缓存不生效时，再快的引擎也会被拖死。这种场景下，oMLX的分层缓存和Ollama的前缀缓存优化，比纸面tok/s重要得多。
对号入座：你该选哪条
只想安安静静跑个模型聊天、查资料： 用Ollama，装完 `ollama run` 一个模型名就完事，生态和模型库没人比它全。
要图形界面、喜欢调参数： LM Studio，GGUF生态熟，上手零门槛。
主力场景是接Claude Code、Cursor干活的coding agent： 优先试oMLX或Ollama的MLX引擎，重点考察长上下文的缓存表现，而不是跑分。判断方法很简单：连续对话十几轮之后，看第一个字的延迟有没有明显变慢。
顶配内存（128G以上）、爱折腾、追求极限速度： Rapid-MLX值得试，它代表了MLX生态当前的速度上限，但要做好版本快速迭代、偶尔踩坑的心理准备。
想一个应用搞定聊天+代码+生图： MLX Studio，但要接受它还在早期。
内存门槛再提醒一次，这是所有Mac本地AI体验的硬约束：16G统一内存安心跑8B以下4-bit量化；32G可以摸到35B左右的MoE模型；想跑27B稠密模型或者更大的，64G起步才从容。别被"Mac能跑70B"的标题骗进去，能跑和好用是两回事。
接下来值得盯的三个信号
一是Ollama MLX引擎的模型覆盖速度。Muse Glimmer和Qwen3.8已经开了头，如果后续新模型都优先走MLX变体，那"Ollama+MLX"就会成为Mac用户的默认答案，其他工具的生存空间会被挤压到细分场景。
二是社区基准的成熟度。GitHub上已经出现了mlx-chronos这种社区驱动的MLX推理引擎基准套件。GitHub以后选工具之前，先查同机型同模型的真实横评，比看README的大字报靠谱。
三是苹果自己的态度。6月苹果CoreAI首批基准流出时，有消息称Qwen3 0.6B大幅领先、8B几乎追平MLX。知乎另有讨论提到M4上Qwen3 0.6b的解码速度可达MLX的2.47倍。知乎苹果在端侧推理上另有布局，MLX更像留给开发者和研究社区的礼物。它会不会持续投入，决定了这个生态的长期天花板。
最后说一句实在的：Mac本地AI已经从"能不能跑起来"的玩具阶段，走到了"跑得舒不舒服"的工具阶段。这五条路都通，但各自的脾气不一样。想清楚自己是哪一派，比追任何"最快"的标题都重要。
你用的是哪个工具、什么配置、跑的哪个模型？评论区报一下数据，凑一份真实用户的横评出来。
