M5 Ultra 对双 DGX Spark：256GB 单机对 256GB 双机，预填充慢三倍

一、标题像是单方面碾压，评论区却吵翻了

一台 Mac Studio，装着 256GB 统一内存和 80 核 GPU。对面是两台 DGX Spark，每台 128GB，用一根 200Gbps 的 QSFP 线缆连成一对，靠 RoCE 互相读写对方的内存。海外博主 Alex Ziskind 把这场对决做成了视频，10 月 1 日发布。

结果被劈成了两半：生成速度，Mac 38.7 tok/s 对 34.3 tok/s，单机赢；读提示，32K 的代码提示两台 Spark 17 秒开始吐字，Mac 等了 50 秒，输得干净。

这条帖子被转到 Reddit 本地大模型社区后，踩（46）比赞（43）还多。吵的不是谁赢，是"这种测法算不算数"。

但真正值得看的，是第三个数字。就在视频发布前后，Mac 侧另一个推理引擎 oMLX 发了 0.7.0 版，在同一颗 M5 Ultra 上，4K 输入的预填充被推到 1,926 tok/s。而视频里的 Mac，按 32K 提示等 50 秒换算，等效预填充只有 640 tok/s。同一台机器、同一类任务，差了 3 倍。

这就不只是一场硬件对决了。它更像是两套软件栈成熟度的对照实验，而实验里的变量，比测试者想控制的多得多。

二、这场对决到底比了什么两台机器，两本完全不同的物理账

对比项

Mac Studio M5 Ultra

两台 DGX Spark

芯片

M5 Ultra，36 核 CPU / 80 核 GPU

GB10 两颗，各 20 核 Arm CPU

内存

256GB 统一内存

128GB × 2，合计 256GB

内存带宽

标称 1.2TB/s，GPU 侧实测约 1,039GB/s

每台 273GB/s

互联方式

片内统一内存，权重不用搬运

200Gbps QSFP，实测约 111Gbps

推理引擎

llama.cpp 与 MLX

vLLM 张量并行

软件出身

Metal 与 MLX 新栈

CUDA 老栈

两边跑的模型都是 4bit 量化。DeepSeek V4 Flash 量化后约 150 至 160GB，单台 Spark 装不下，只能两台各扛约 111GB，每一层切一半，每生成一个 token 都要跨机器交换中间结果才能进入下一层。Mac 则把这套权重一次性放进同一个内存池。

一个要来回搬运，一个原地展开，这是后面所有数字的物理底子。

生成打平，读提示被拉开近三倍

测试项

Mac Studio M5 Ultra

两台 DGX Spark

DeepSeek V4 Flash 生成

38.7 tok/s

34.3 tok/s

Qwen3.8 Flash Next 生成

45 tok/s

38 tok/s

32K 提示首 token 等待

约 50 秒

约 17 秒

8K 提示首 token 等待

约 10 秒

约 4 秒

128K 提示

未跑通

72 秒

原因不神秘。生成一个 token，要把当前活跃的权重全部过一遍内存，谁带宽高谁快：M5 Ultra 标称 1.2TB/s，GPU 侧实测约 1,039GB/s；每台 Spark 只有 273GB/s，两台加起来 546GB/s，还不到 Mac 的一半，实际还要再扣掉张量并行的同步成本。

读提示靠的是算力。两台 Spark 顶着两颗 GB10 的 FP4 算力，加上 CUDA 生态里打磨多年的注意力内核，这一侧 Mac 确实追不上，短提示下差距还能忍，提示一长就被放大成三倍。

评论区吵的其实是同一件事

最响的一条批评是引擎不对等。有人指出他测生成用的是 MLX，测首 token 又换回 llama.cpp，两边还不统一，"这样的数字和结论都有误导性"。

这条批评站得住，但影响有多大，视频本身给了答案：同一台 Mac、同一个 DeepSeek，llama.cpp 跑约 40 tok/s，换 MLX 直接跳到 53 tok/s，一个引擎就差 34%。而当两边都用 llama.cpp 时，机器之间的生成差距缩到了 2% 以内。

也就是说，引擎这个变量，比两台机器的硬件差距还大。

第二条是"是不是前半段都在跑 4B 小模型"。这条被视频本身否掉了，他从头到尾跑的都是 Qwen3.8 27B、DeepSeek V4 Flash、gpt-oss-120B 这一档。

第三条争论最有价值：一边说"Mac 还有很大优化空间"，另一边说"CUDA 那边早优化到头了，凭什么只算 Mac 的增量"。这个问题，值得单独拿出来算一遍。

三、Mac 输的不是硬件，是那天的软件

先肯定一句：Spark 赢得不虚，而且赢在了 agent 最难受的地方。长上下文工具调用，每轮都要把几万字的上下文重读一遍，首 token 从 17 秒变成 50 秒，是两个体验层级。

但把"首 token 等待"统一换算成等效预填充速度，账就清楚了：

# 把"首 token 等待"换算成等效预填充速度，再折算成"每读一万字要等多久"cases = [("视频里的 M5 Ultra（32K 代码提示）", 32000, 50.0),("两台 DGX Spark（32K 代码提示）",   32000, 17.0),("oMLX 官方基线 64K 预填充 1716 tok/s", 64000, 64000 / 1716),("MacStories 实测 16K 提示 5.6 秒",    16000, 5.6),for name, tokens, ttft in cases:rate = tokens / ttftprint(f"{name}: 等效预填充 {rate:,.0f} tok/s，每 1 万字等待 {10000 / rate:.2f} 秒")print("32K 口径下两台 Spark 是视频里 Mac 的 %.2f 倍" % (50.0 / 17.0))

实跑输出：

视频里的 M5 Ultra（32K 代码提示）: 等效预填充 640 tok/s，每 1 万字等待 15.62 秒两台 DGX Spark（32K 代码提示）: 等效预填充 1,882 tok/s，每 1 万字等待 5.31 秒oMLX 官方基线 64K 预填充 1716 tok/s: 等效预填充 1,716 tok/s，每 1 万字等待 5.83 秒MacStories 实测 16K 提示 5.6 秒: 等效预填充 2,857 tok/s，每 1 万字等待 3.50 秒32K 口径下两台 Spark 是视频里 Mac 的 2.94 倍

看清楚最后两行的关系：两台 Spark 是视频里 Mac 的 2.94 倍，而 oMLX 官方公布的预填充基线 1,716 tok/s，和两台 Spark 的等效 1,882 tok/s 只差 9%。

这里必须交代口径：两组数字的模型不同、量化格式不同、引擎不同，不能直接相减。但量级摆在这儿——Mac 侧预填充被压到几百 tok/s，不是 M5 Ultra 的上限，是那天那套软件栈的上限。

oMLX 0.7.0 的版本说明写得很直白：预填充提速来自把 QSA 注意力搬到 M5 的张量单元上，M5 上过大的 MoE 调用从 32K 行切片改成一次派发。它不是堆参数，是补课。M5 的神经加速器上笔记本才一年，MLX 这条路线要为每一代新硬件重写内核，版本说明里连"分块从 4096 token、在 M5 GPU 上翻倍到 8192"这种细节都还在往里加。

同一颗 M5 Ultra，社区用户用 oMLX 0.7.0 跑出的数字更能说明问题：4K 输入 1,926 tok/s、16K 1,953、64K 1,922、128K 1,885，对应首 token 2.1 秒、8.4 秒、34 秒、70 秒。注意最后一行，128K 输入下等效预填充仍有 1,885 tok/s，而视频里的 Mac 连 128K 都没跑通。

反过来，另一边说"CUDA 红利已经收完"也不是托词。vLLM 的张量并行、NVFP4、各类融合注意力内核已经磨了多年，Spark 明年再快，大概也就是几个百分点的事。而 MLX 这条路上，一个版本把 4K 预填充从 712 拉到 1,926，翻了一倍半。这种幅度不会一直有，但它说明"今天谁快"是个会过期的答案。

还有一件事被忽略了：加第二台机器，只买到 6.4% 的生成提升。因为生成是带宽问题，两台 Spark 的内存带宽加起来仍不到 Mac 的一半，而张量并行每生成一个 token 都要在两台机器之间来回同步。新加的算力，被线缆吃掉了。这也让"200Gbps 标称只跑出 111Gbps"这个细节更值得紧张——横向堆机器，换不来带宽。

四、落到自己身上：三条判断按你缺的是读还是写来选

你的主要工作

更合适

理由

长文档问答、知识库灌库、批量合成数据

双 Spark 或云端

预填充是算力活，三倍等待会直接卡住整条流程

长上下文 agent、多轮工具调用

先看软件栈

首 token 中位数两三秒已经能用，这类负载更吃上下文留不留得住

装 200B 级 MoE、要求单机安静

Mac

一个内存池，不用切分，没有线缆同步

跑到 400B 以上、要微调、要 nvidia-smi

双 Spark

CUDA 生态和批量吞吐是它的主场

已经在 Mac 上的人，先别急着换硬件

升级引擎比升级硬件便宜得多。同一个 0.7.0 版本，4K 预填充从 712 涨到 1,926 tok/s，生成从 35.0 涨到 57.3 tok/s。如果你的等待发生在首 token，先去看 MLX 和 oMLX 的新版本，再看内存够不够，最后才考虑换机器。

oMLX 是 Apache-2.0 协议的开源项目，Python 写的，最新版给 macOS 26/27 和 macOS 15 各出了一份安装包，项目地址 github.com/jundot/omlx。顺带说一句，这个 2.2 万星的项目创建于 2026 年 2 月，维护者在版本说明里明确写着自己是唯一的维护者，PR 已经多到他一次审不完。这是一条提醒：Mac 侧的性能曲线，眼下握在一个人手里。

想买 Max 还是 Ultra，先算内存账

苹果官方规格写得很清楚：M5 Max 最高 128GB 统一内存，带宽 460GB/s，选配 40 核 GPU 后到 614GB/s；M5 Ultra 从 96GB 起步，可选 256GB 和 512GB，带宽 1.2TB/s。两者是约 2 倍带宽、4 倍内存上限的差距。

评论区有句话很实在：128GB 跑 Qwen3.8-Flash-Next 已经紧了，想同时挂几个 agent 会话就会打架。这类负载要的是容量和并发，不是峰值带宽。买之前先问自己一个问题：是模型装不下，还是一个字一个字吐得慢。前者加内存，后者才轮到换机器。

五、把问题留给你

这场对决真正的结论不是谁赢，而是：两台 Spark 的 17 秒和 Mac 的 50 秒之间，隔着的不只是算力，还有一整套还在长身体的软件。

那么问题来了：如果你是 Mac 用户，会因为"读得慢三倍"换成两台 Spark 吗？还是会先升级引擎，把这三倍讨回来一部分？欢迎在评论区说说你的选择和理由。