M5 Ultra 把本地 AI 从“能跑”推进到“能长期干活
https://teaikeji.com/data/attachment/forum/rehost/wx20261002b2_1.jpg最近 MacStories 做了一组很有指向性的 M5 Ultra Mac Studio 测试。它没有把篇幅花在传统 CPU 跑分、视频导出或游戏性能上，而是把这台机器放到一个更具体的角色里：桌面级本地 AI 推理服务器。测试内容覆盖大模型运行、长上下文、多 Agent 并发，以及和 iPhone、Codex 的联动，同时把 M5 Ultra 与 M3 Ultra、RTX 5090 放在同一场景里比较。
如果只看“每秒生成多少 Token”，M5 Ultra 的提升已经很直观。但这次更关键的变化，是 Prompt Processing，也就是模型在正式输出前读取并处理整段 Prompt 的速度。对普通对话来说，这个变化可能只是少等几秒；对 Agent 来说，它会影响每一次工具调用、每一轮上下文扩展后的响应节奏。
这次测试的主角是一台 256GB 统一内存的 M5 Ultra Mac Studio。对照组包括一台 512GB 统一内存的 M3 Ultra Mac Studio，以及一台 RTX 5090 PC。
RTX 5090 那台机器的配置是 32GB 显存、Ryzen 9 9950X3D 处理器和 96GB 系统内存。软件侧，macOS 主要使用 oMLX，Windows 侧主要使用 LM Studio。
测试模型也不只是小模型，主要涉及 Qwen3.8 Flash-Next、GLM-5.3-Flash 和 Qwen3.8 27B。上下文长度则从 4K 一路拉到 64K、128K，甚至 256K。
这种测试方式的价值在于，它没有停留在“某个 7B 模型能跑 200 tok/s”这种简单展示，而是尽量贴近当前 Agent 的真实使用方式：长 Prompt、大上下文、多轮对话、工具调用，以及多个子 Agent 同时工作。
从硬件层面看，M5 Ultra 对本地 AI 的几项提升非常直接。
它配备 80 核 GPU，并且每个 GPU Core 都集成 Neural Accelerator。按照苹果的说法，AI 相关的峰值 GPU 计算能力相比 M3 Ultra 最高可提升到约 4.5 倍。
但对本地推理来说，另一个数字可能更关键：统一内存带宽从 M3 Ultra 的 819GB/s 提升到了 1.2TB/s。
这两项能力分别对应本地大模型最常见的两类瓶颈。
第一类是 Prompt Processing。模型拿到一大段上下文后，需要先把整个 Prompt 读进去并做大量矩阵计算，这个阶段非常依赖算力。
第二类是 Token Generation。模型开始逐 Token 输出后，每生成一个 Token 都会频繁访问模型权重和缓存，此时内存带宽往往成为瓶颈。
所以 M5 Ultra 同时提升算力和内存带宽，对本地大模型来说属于比较对症的升级。
真正让人意外的，是 Prompt 读取速度带来的体验变化。
MacStories 使用同一个 Flash-Next 模型、同一版本 oMLX 和相同 Prompt，在 M3 Ultra 与 M5 Ultra 上做了对比。
在 16K 上下文下：
- M3 Ultra 的 Prompt Processing 约为 1,143 tok/s，生成速度约 37 tok/s，首 Token 约 13.9 秒。
- M5 Ultra 的 Prompt Processing 约为 2,887 tok/s，生成速度约 52 tok/s，首 Token 约 5.6 秒。
也就是说，仅仅是“模型读完 Prompt 并开始回答”这个动作，等待时间就从十几秒降到了几秒。
MacStories 给出的结论是，M5 Ultra 的 Prompt Processing 相比 M3 Ultra 平均提升约 150%，也就是大约 2.5 倍。
这个指标为什么对 Agent 特别重要？因为 Agent 每一轮收到的输入，往往远比用户看到的复杂。
表面上用户可能只输入了“帮我继续改这个项目”，但模型实际收到的内容可能包括：
- System Prompt；
- 用户偏好；
- Memory；
- MCP 工具说明；
- Skills；
- 当前项目代码；
- 工具执行结果；
- 历史聊天；
- 子 Agent 返回的信息。
这些内容叠加起来，输入规模可能达到几万甚至十几万 Token。
如果 Prompt Processing 很慢，每次工具调用之后，模型重新接手任务前都要等很久。这也是很多本地模型“单独跑起来不慢，但放进 Agent 后很拖”的主要原因。
到了 64K 左右，M5 Ultra 的优势依然明显。
在约 65K Prompt 下，Flash-Next 的表现是：
- M3 Ultra 读取速度约 1,114 tok/s，首 Token 约 59 秒，生成速度约 39 tok/s。
- M5 Ultra 读取速度约 2,732 tok/s，首 Token 约 24.2 秒，生成速度约 73 tok/s。
同样是一段约 65K 的上下文，M3 Ultra 接近一分钟才真正开始回答，M5 Ultra 则缩短到约 24 秒。
如果这是一个持续工作的 Coding Agent，这种差距会被不断放大。
真正拉开差距的是更长上下文。
MacStories 专门测试了 Flash-Next 在 64K、128K、256K 下的 Time to First Token，也就是从请求开始到第一个 Token 出现需要多久。
冷缓存情况下：
- 64K：M3 Ultra 512GB 约 59.7 秒，M5 Ultra 256GB 约 24.4 秒。
- 128K：M3 Ultra 约 121 秒，M5 Ultra 约 50 秒。
- 256K：M3 Ultra 约 246 秒，M5 Ultra 约 104 秒。
换算一下，256K 上下文时，M3 Ultra 要等大约 4 分 6 秒，M5 Ultra 则缩短到约 1 分 44 秒。
还有一个容易被忽略但很实用的点：同样的 Prompt 如果再次发送，oMLX 可以复用已经缓存的 Prompt Token，第二次速度会快很多。
例如 Flash-Next 256K 测试中：
- M3 Ultra 冷缓存约 246 秒，缓存命中后约 7.1 秒。
- M5 Ultra 冷缓存约 104 秒，缓存命中后约 5.8 秒。
这和实际 Agent 使用非常相关。只要 Agent 每轮能够有效利用 Prompt Cache，就没有必要每次都完整重算几十万 Token。
所以“上下文越来越长”并不意味着每一轮都必然重新做一次完整 Prefill。
另一组更容易理解的数据，是固定生成 512 tokens 时的速度。
MacStories 给 Flash-Next 不同长度的背景上下文，然后让它固定输出 512 tokens。
结果如下：
- 4K：M3 Ultra 59.0 tok/s，M5 Ultra 90.7 tok/s。
- 16K：M3 Ultra 53.5 tok/s，M5 Ultra 87.8 tok/s。
- 64K：M3 Ultra 45.3 tok/s，M5 Ultra 83.8 tok/s。
- 128K：M3 Ultra 37.0 tok/s，M5 Ultra 60.6 tok/s。
- 256K：M3 Ultra 38.6 tok/s，M5 Ultra 74.7 tok/s。
这组结果很有意思。M5 Ultra 在 256K 上下文下的生成速度，竟然还比 M3 Ultra 在 4K 上下文下更快。
对普通聊天来说，256K 当然非常大。但对真正长时间工作的 Agent 来说，256K 并没有想象中那么遥远。
一个 Coding Agent 如果连续工作几个小时，读取大量源代码、日志、终端结果和工具输出，上下文很容易持续上涨。这也是 M5 Ultra 这次升级对 Agent 的意义，可能大于普通聊天。
GLM-5.3-Flash 也有明显提升。
在约 13.6K Prompt 下：
- M3 Ultra 的 Prompt Processing 约 428 tok/s，可见首 Token 大约 32.6 秒，生成约 21 tok/s。
- M5 Ultra 的 Prompt Processing 约 1,107 tok/s，可见首 Token 大约 12.8 秒，生成约 32 tok/s。
到了约 61K Prompt：
- M3 Ultra 读取约 448 tok/s，首个可见 Token 约 138.8 秒。
- M5 Ultra 读取约 1,016 tok/s，首个可见 Token 约 61.6 秒。
提升幅度同样明显。
不过 GLM-5.3-Flash 对内存的压力更大。到了更高上下文时，256GB 版本的 M5 Ultra 会更容易触碰内存极限。
比如 256K GLM 测试中，M5 Ultra 256GB 没能完成。
这也说明，256GB 已经很大，但对今天越来越庞大的本地模型来说，它依然不是“无限显存”。
Flash-Next 到底占多少内存？这对准备买 Mac Studio 跑本地模型的人很重要。
MacStories 分别测试了 Flash-Next 的四种量化：
- oQ4e，大致 4-bit；
- oQ5e，大致 5-bit；
- oQ6e，大致 6-bit；
- oQ8e，大致 8-bit。
需要说明的是，这里的 bit 只是名义上的量化级别。实际每个版本内部还有不同权重分配，不能简单理解成“模型大小严格按 4/5/6/8 比例增长”。
实测 oMLX 进程峰值内存如下：
- oQ4e：M3 Ultra 512GB 约 160GB，M5 Ultra 256GB 约 155GB。
- oQ5e：M3 Ultra 约 179GB，M5 Ultra 约 179GB。
- oQ6e：M3 Ultra 约 198GB，M5 Ultra 约 156GB*。
- oQ8e：M3 Ultra 约 240GB，M5 Ultra 约 187GB*。
带星号的两个版本需要特别说明。
M5 Ultra 256GB 无法把 oQ6e 和 oQ8e 全部正常留在统一内存中。
oQ6e 尝试全内存加载时，macOS 在内存压力下终止了服务。oQ8e 则被 oMLX 直接拒绝加载，因为预计加载时所需内存过高。
最终这两个版本使用了 oMLX 的 SSD offload，把体积很大的 embedding / n-gram tables 放到 SSD，需要时再读取。模型主体仍然跑在统一内存中。
所以，256GB 的甜点量化其实是 5-bit。
MacStories 作者最后更偏向使用 oQ5e。原因很简单：它可以完整放在 256GB 统一内存里，同时比 4-bit 提供更高精度，又不用像 6-bit 和 8-bit 一样把部分大表放到 SSD。
速度方面，散文生成测试结果是：
- oQ4e：M3 Ultra 77.3 tok/s，M5 Ultra 111.6 tok/s。
- oQ5e：M3 Ultra 71.0 tok/s，M5 Ultra 100.0 tok/s。
- oQ6e：M3 Ultra 71.9 tok/s，M5 Ultra 95.2 tok/s。
- oQ8e：M3 Ultra 63.5 tok/s，M5 Ultra 86.8 tok/s。
代码生成速度更快。
在 M5 Ultra 上：
- oQ4e：142.9 tok/s；
- oQ5e：132.6 tok/s；
- oQ6e：122.8 tok/s；
- oQ8e：119.0 tok/s。
如果一台机器主要用于本地 Coding Agent，这些数字已经非常能用了。
那 M5 Ultra 能不能打过 RTX 5090？
很多人最关心的还是这个问题。
MacStories 专门拿 RTX 5090 做了对比。
PC 配置是：
- RTX 5090 32GB；
- Ryzen 9 9950X3D；
- 96GB 系统内存；
- Windows 11；
- LM Studio；
- CUDA 12 runtime。
模型换成了 Qwen3.8 27B。
这里需要先提醒一下：Mac 运行的是 MLX oQ4e，PC 是 GGUF Q4_K_M。虽然基础模型相同，但量化格式和运行时不同，所以这更像“整机使用体验对比”，不能当成纯芯片理论跑分。
在约 6K Prompt 下：
- RTX 5090：Prompt Processing 3,031 tok/s，生成 59 tok/s，首 Token 2.0 秒，完整回答 5.5 秒。
- M5 Ultra：Prompt Processing 1,701 tok/s，生成 48 tok/s，首 Token 4.0 秒，完整回答 8.4 秒。
- M3 Ultra：Prompt Processing 414 tok/s，生成 31 tok/s，首 Token 15.4 秒，完整回答 22.3 秒。
所以只要模型能够完整放入 5090 的显存，5090 还是更快。
长上下文下，5090 仍然领先。
Qwen3.8 27B 在 64K、128K、256K 上下文下的生成速度为：
- 64K：M3 Ultra 23.5 tok/s，M5 Ultra 38.9 tok/s，RTX 5090 49.6 tok/s。
- 128K：M3 Ultra 20.0 tok/s，M5 Ultra 32.4 tok/s，RTX 5090 40.4 tok/s。
- 256K：M3 Ultra 15.0 tok/s，M5 Ultra 24.3 tok/s，RTX 5090 30.0 tok/s。
5090 依然领先。
但这里有个关键前提：5090 必须使用 8-bit Attention Cache，才能让 256K 工作负载塞进 32GB 显存。
如果使用默认 16-bit Attention Cache：
- 64K 约 51.1 tok/s；
- 128K 约 44.4 tok/s；
- 256K 最终没有完成，10 分钟之后 Prompt 只读了大约 3%。
这就是 32GB 显存的限制。
一旦 5090 开始借系统内存，速度会直接掉到个位数。
MacStories 还故意做了一个很有价值的实验：让 5090 无法把全部数据留在显存中，部分模型跨 PCIe 放到系统 RAM。
结果生成速度变成：
- 64K：4.6 tok/s；
- 128K：2.9 tok/s；
- 256K：1.5 tok/s。
这也是 Apple 统一内存架构最有意思的地方。
5090 有 32GB 高速显存和非常高的显存带宽。只要工作负载能塞进去，它非常强。
但模型超过 32GB 之后，局面就完全不同了。
Mac Studio 的 GPU 可以直接访问 256GB 统一内存。虽然带宽比 5090 的显存低，但它不需要在 32GB 这条线附近做那么激烈的取舍。
所以对于大模型，本地 AI 的问题有时候不只是“哪张卡计算更快”，还包括：你的整个模型、KV Cache 和上下文到底能不能完整留在高速内存里。
这也是 Mac Studio 很适合大模型的原因。
把这个逻辑往下推，M5 Ultra 的定位就很特别。
RTX 5090：
- 单卡算力强；
- 显存带宽高；
- CUDA 生态成熟；
- 32GB 显存是硬限制。
M5 Ultra 256GB：
- 单纯计算性能不如 5090；
- 内存带宽也低于 5090 显存；
- 但可以直接给 GPU 使用数百 GB 统一内存；
- 大模型不需要频繁通过 PCIe 和系统内存来回搬运。
如果你跑的是 27B、32B 这类能轻松放进 5090 的模型，我仍然会优先关注 NVIDIA。
如果你想跑的是 100GB、150GB、200GB 级别模型，或者希望在大模型旁边再放很大的 KV Cache，Mac Studio 的优势会越来越明显。
多 Agent 并发可能比单模型跑分更值得关注。
这篇文章里我觉得最有意思的一组数据，其实是并发测试。
MacStories 同时向 Flash-Next 发出 1、2、3 个请求。
每个请求大约：
- 6.5K 输入 tokens；
- 最多 600 输出 tokens；
- 开启低强度 reasoning；
- MTP depth 3。
M5 Ultra 的结果是：
- 1 路请求：综合输出 66.2 tok/s；
- 2 路请求：综合输出 69.6 tok/s；
- 3 路请求：综合输出 81.5 tok/s。
M3 Ultra 的结果是：
- 1 路：38.4 tok/s；
- 2 路：38.1 tok/s；
- 3 路：39.9 tok/s。
M5 Ultra 同时跑 3 路请求时，总吞吐相比单路提高了约 23%。三个请求全部完成需要大约 22.1 秒。
这意味着 GPU 在单路生成时并没有被完全吃满，多请求并发能够更有效利用硬件。
而这恰好符合现在 Agent 的发展方向。
真正的 Agent，不会永远只有一个模型在工作。
现在越来越多 Agent 系统开始采用“主 Agent + 多个子 Agent”的方式。
比如：
- 主 Agent 分析目标、拆分任务、决定谁做什么；
- 子 Agent A 搜索资料；
- 子 Agent B 读代码；
- 子 Agent C 检查错误；
- 最后主 Agent 再统一整合。
在这种情况下，单个请求每秒 100 Token 当然重要，但更重要的是：一台机器能不能同时扛住三四个本地模型会话。
256GB 统一内存给 M5 Ultra 留下了很大的空间。
MacStories 实际测试甚至通过自己的 iOS bridge 同时发出 3 个 HTTPS 请求，最终 1,800 tokens 在大约 22.9 秒内完成。
从这个角度看，Mac Studio 已经不太像一台“本地聊天电脑”，它更像一台桌面级多 Agent 推理服务器。
这篇文章前半部分还有一个值得中文读者注意的案例。
作者为了完成 iOS 和 iPadOS 27 的大型评测，自己做了一个叫 Desk 的内部工具。整个项目最后有 310 份文档。
里面包括：
- 笔记；
- WWDC Session；
- PDF；
- 网页资料；
- 截图；
- Review 章节资料。
作者让一组本地 Agent 持续运行 99 天。
主要任务包括：
- 转录 WWDC Session；
- 从网页、PDF、Session 和笔记中提取功能；
- 在不同来源之间交叉检查；
- 判断不同功能属于文章的哪个章节；
- 从截图中提取功能和 Bug；
- 通过 Notion API 整理多个数据库。
这个案例很好地解释了为什么有人愿意花这么多钱买高内存 Mac 跑本地模型。
如果只是每天问几十个问题，云端模型明显更简单。
但如果任务需要：
- 全天候运行；
- 几十天甚至几个月；
- 重复读取大量资料；
- 不断调用工具；
- 处理私人文档；
- 数百万甚至数千万 Token。
云 API 的成本就会不断累计。
而本地机器的特点是：硬件成本是一次性的，后续不会再按照 Token 持续计费。
当然，电费仍然存在。
本地 AI 还有一个隐藏价值：数据始终在自己的机器里。
如果你的资料包括：
- 私人笔记；
- 公司文档；
- 未公开代码；
- 客户数据；
- 内部 PDF；
- 本地照片；
- 未发布文章。
本地模型就有一个天然优势：数据可以完全留在本机。
MacStories 作者甚至把 M5 Ultra 当成服务器，然后通过 Tailscale 把本地 OpenAI-compatible API 提供给 iPhone 上的 Open Minis。
也就是说，模型跑在家里的 Mac Studio，手机只是客户端。
这其实已经很接近一种“个人 AI 私有云”。
M5 Ultra 还可以直接作为 Codex 的本地子 Agent。
作者还尝试把 Flash-Next 接进 Codex。这样就可以出现一种很有意思的混合架构：
云端的 GPT 模型作为主 Agent；M5 Ultra 上的 Flash-Next 作为本地子 Agent。
复杂任务交给云端大模型。一些简单任务、重复任务或者需要大量读取本地资料的任务交给本地模型。甚至还可以让 Flash-Next 再继续调度自己的子 Agent。
这可能是本地模型近期最实际的方向之一。
本地模型未必要完全替代云端 frontier model。它可以作为云端模型旁边的“免费劳动力”。
为什么我觉得这比单纯 100 tok/s 更重要？
很多本地模型跑分会强调：“某某模型已经跑到 150 tok/s。”这种数字当然好看。
但真实 Agent 工作流关心的东西更多：
1. Prompt 要读多久？
2. 上下文增加之后速度掉多少？
3. 128K、256K 能不能稳定工作？
4. Prompt Cache 能不能有效复用？
5. 多个 Agent 能不能并发？
6. 模型能不能完整放入高速内存？
7. 工具调用之后下一轮启动要等多久？
M5 Ultra 这次真正改善的是一整套 Agent 体验。尤其是 Prefill。
如果模型生成有 100 tok/s，但每轮都要先等 30 秒，它用起来仍然会很难受。
如果 Prefill 足够快，首 Token 只要几秒，Agent 才会让人感觉是在“连续工作”。
当然，这台机器并不适合所有人。
第一，价格高。如果只是为了偶尔跑本地模型，买 256GB M5 Ultra 很难说有性价比。
第二，CUDA 生态依然更成熟。很多新的推理优化、量化格式和研究项目，都会优先支持 NVIDIA。
第三，256GB 也不是无限大。GLM-5.3-Flash 到 256K 已经能碰到内存问题。Flash-Next 的 oQ8e 也需要 SSD offload。
第四，如果模型能完整塞进 5090，5090 依然更快。
所以 M5 Ultra 的真正优势非常明确：超大统一内存。
这篇测试使用的是 256GB M5 Ultra。但 M5 Ultra 还有 512GB 统一内存版本。
如果 256GB 已经可以：
- Flash-Next 5-bit 全内存；
- 6-bit / 8-bit 部分 SSD offload；
- 多个 Flash-Next 会话并发；
- 长上下文跑到 256K；
- 作为本地 Agent 服务器。
那么 512GB 的意义就很直接。
更高精度量化可以直接驻留内存。多个大模型也更容易同时存在。KV Cache 可以放得更大。更大的 MoE、Dense 模型也会进入可运行范围。
真正限制它的，可能慢慢从“能不能装下”转向“速度够不够快”。
看完整篇测试，我更看好一种混合模式。
未来几年很可能会出现一种越来越普遍的个人 AI 工作方式：
本地机器负责：
- 文件；
- Memory；
- 私有资料；
- 长期任务；
- 批量任务；
- OCR；
- 辅助 Agent；
- 普通 Coding；
- 大量低成本 Token。
云端模型负责：
- 高难推理；
- 复杂规划；
- 关键代码 Review；
- 最重要的决策。
M5 Ultra 这种大统一内存设备，很适合承担前面那一大批工作。RTX 5090 这类 GPU 则继续在高性能推理和 CUDA 生态上保持优势。两条路线很可能长期同时存在。
这台机器最吸引我的地方，是 Agent 开始真的能长期跑了。
几年前讨论本地大模型，很多时候还是“能不能跑起来”。后来开始讨论“每秒能生成多少 Token”。现在 M5 Ultra 这类机器让问题又向前走了一步：它能不能作为一个每天 24 小时在线的本地 AI 系统？
从 MacStories 这轮测试看，答案已经越来越接近“可以”。
Flash-Next 的表现是：
- 短上下文超过 100 tok/s；
- 64K 还有 83.8 tok/s；
- 256K 还有 74.7 tok/s；
- Prompt Processing 最高接近 2,900 tok/s；
- 3 路并发总吞吐 81.5 tok/s；
- 5-bit 可以完整放进 256GB 内存。
这些数字单独看，每一个都不算完全碾压 NVIDIA。但把它们放在一起，再加上 256GB 统一内存、低噪音、小体积和 macOS 生态，M5 Ultra 就形成了一个很特别的位置。
它已经可以非常认真地承担本地 Agent 服务器这个角色。
如果苹果继续提高统一内存带宽，同时 MLX、oMLX、Exo、DwarfStar 这些项目继续优化，Mac 在本地 AI 领域可能会越来越有意思。
至少这一次，M5 Ultra 已经证明：在本地 AI Agent 这个场景里，大内存真的可以改变一台电脑的用途。
这组数据的测试环境是：M5 Ultra Mac Studio 256GB 统一内存、M3 Ultra Mac Studio 512GB 统一内存、RTX 5090 PC 32GB VRAM + 96GB RAM；macOS 使用 oMLX 0.7.0.dev2，Windows 使用 LM Studio 0.4.24；主要模型为 Qwen3.8 Flash-Next、GLM-5.3-Flash、Qwen3.8 27B；测试覆盖 4K～256K 上下文、不同量化、Prompt Cache、长上下文和多请求并发。
原始测试来自 MacStories：https://www.macstories.net/stories/m5-ultra-mac-studio-review-the-dream-mac-for-local-ai-agents/
页:
[1]