M5 Ultra 确实有点弱啊！ 对比双卡 DGX Spark 集群：你在跑大模型时一直忽视的“致命数字”到底是什么？
-
导读：当拥有 256GB 统一内存的苹果单机怪兽 M5 Ultra Mac Studio，遇上由高速网络桥接的两台 128GB NVIDIA DGX Spark 算力节点，谁才是本地部署超大模型（DeepSeek V4 Flash / Qwen 3.8 Flash Next）的真正王者？实测发现，单纯对比每秒生成多少 Token 具有极大误导性，而“首字延迟与 Prompt 预填充速度”才是拉开数倍体验差距的关键关键维度。本文来自博主Alex Ziskind的评测视频总结。
目录- 一、 硬件规格与集群拓扑对比
- 二、 核心原理科普：“你没关注的那个数字”到底是什么？
- 三、 单用户生成性能实测（Decode 写入速度）
- 四、 提示词预填充速度实测（Prefill / 首字响应时间）
- 五、 KV 缓存与上下文热启动影响（Prefix Caching）
- 六、 多用户高并发吞吐测试（Throughput & Concurrency）
- 七、 满载功耗与温控表现
- 八、 测评总结与选型指南
一、 硬件规格与集群拓扑对比
本次测试对比了当前个人及小型团队在本地运行百亿至千亿级大模型的两种典型方案：一种是单机高集成度的 Apple M5 Ultra Mac Studio，另一种是双节点通过高速网络互联的 双 NVIDIA DGX Spark 集群。
表1：硬件规格、拓扑互联与成本对比硬件配置维度 Apple M5 Ultra (Mac Studio) 双 NVIDIA DGX Spark 集群 (Dual Spark) 内存/显存总量 256 GB 统一内存 (单机集成) 256 GB (128 GB × 2 节点) 理论内存带宽 1.2 TB/s (1200 GB/s) 单节点 273 GB/s (双节点总计约 546 GB/s) 节点间互联 无需跨机通信 (片上统一寻址) 200 Gb QSFP 线缆，跑 RoCE (RDMA over Converged Ethernet) 实测互联带宽 内存总线直连 双向实测数据交换带宽约为 111 GB/s 模型并行策略 单卡完整加载整模 张量并行 (Tensor Parallel = 2)，每层切半跨机同步 软件推理引擎 llama.cpp / MLX (OMLX) vLLM (支持 NCCL / RoCE 调度) / llama.cpp 实测测试模型 DeepSeek V4 Flash (4-bit)、Qwen 3.8 Flash Next DeepSeek V4 Flash (4-bit)、Qwen 3.8 Flash Next 存储配置 8 TB NVMe SSD 4 TB × 2 = 8 TB NVMe SSD 整机参考成本 约 $14,000 美元 (8TB版) 初始发售约 $4,000/台，目前约 $5,000/台 (双机加线缆约 $10,000+)
二、 核心原理科普：“你没关注的那个数字”到底是什么？
很多开发者在评估本地推理性能时，往往只盯着终端输出的 Token/s（每秒生成词数），而忽略了模型推理实际上严格分为两个完全不同的阶段：
- 预填充阶段（Prompt Prefill / Reading）
- 工作机制：模型一次性读入所有输入的提示词并进行矩阵乘法计算。
- 性能瓶颈：算力密集型（Compute-Bound），高度依赖 GPU 的纯算力（Tensor Cores / 矩阵浮点性能）。
- 直观感受：决定了首字生成延迟（Time to First Token, TTFT）——即按下回车到屏幕吐出第一个字之间漫长的等待时间。
- 解码生成阶段（Token Generation / Decoding / Writing）
- 工作机制：自回归生成，每吐出一个 Token 都需要把数十上百 GB 的模型权重完整遍历读取一次。
- 性能瓶颈：显存带宽密集型（Memory Bandwidth-Bound），算力反而经常闲置。
- 直观感受：决定了后续文字流式打印的速度感。
视频核心发现：在很多人只关注的“第二阶段（逐词输出）”中，M5 Ultra 凭借 1.2 TB/s 的带宽能够打平甚至超越双 Spark；然而在第一阶段“提示词预填充（读取长文档/代码库）”中，NVIDIA GPU 算力展现了碾压式优势，而这正是长上下文交互中最致命的体验鸿沟！
三、 单用户生成性能实测（Decode 写入速度）
在短 Prompt、单用户并发场景下，测试两套平台在逐词生成（Writing）上的实际速度表现：
表2：单流解码生成速度对比 (Tokens/s)测试模型 M5 Ultra (llama.cpp) M5 Ultra (MLX) 双卡 DGX Spark (vLLM) 结论与分析 基准测试 (800 Tokens) 38.7 t/s - 34.3 t/s 双方势均力敌，苹果略占上风 DeepSeek V4 Flash (4-bit) ~38 t/s 53 t/s (+34%) ~38 t/s llama.cpp 下平手；Mac 换用原生 MLX 后提速 34% Qwen 3.8 Flash Next 45 t/s - 38 t/s 苹果 1.2 TB/s 统一内存带宽带来约 18% 的解码优势 - 软件引擎红利：在 Mac 上，软件框架对吞吐影响显著。同一 DeepSeek 4-bit 模型从 llama.cpp 切换到 Apple 原生 MLX 框架，生成速度直接从 40 t/s 跃升至 53 t/s。
四、 提示词预填充速度实测（Prefill / 首字响应时间）
当输入的上下文逐渐拉长（从 2K 扩展至 32K 实际代码库甚至 128K），GPU 算力差距开始带来明显的首字响应延迟分水岭：
表3：不同上下文长度下的 Prefill 处理时间与首字延迟Prompt 长度 / 场景 模型 M5 Ultra 处理耗时 双卡 DGX Spark 处理耗时 速度差距 (Spark 领先幅度) 2,000 Tokens (短对话) Qwen 3.8 Flash Next 1.5 秒 0.85 秒 Spark 快 1.76 倍 2,000 Tokens (短对话) DeepSeek V4 Flash 2.5 秒 1.25 秒 Spark 快 2.0 倍 8,000 Tokens (中长文档) DeepSeek V4 Flash ~10 秒 ~4 秒 Spark 快 2.5 倍 16,000 Tokens (长文分析) DeepSeek V4 Flash 21 秒 8.3 秒 Spark 快 2.53 倍 32,000 Tokens (14个Python文件工程) DeepSeek V4 Flash 50 秒 17 秒 Spark 快 2.94 倍（生成开始时 Mac 仍在死读） 32,000 Tokens (常规测试) Qwen 3.8 Flash Next 26 秒 (MLX 下降至 19s) 11.2 秒 Spark 快 2.32 倍 128,000 Tokens (极限长上下文) 大模型全量载入 预估 > 180 秒 (超 3 分钟) 72 秒 Spark 线性维持，苹果算力出现显著积压 - 实测细节：在输入含 14 个 Python 文件的真实代码工程（32K Tokens）时，两台 DGX Spark 仅耗时 17 秒就已经完成了计算并开始连续吐词，而此时 M5 Ultra 还在进行长达 50 秒的预填充计算。
- “翻盘点”计算：虽然 M5 Ultra 在 Qwen 上的逐词输出速度略快一点点（每 Token 节省几毫秒），但在 32K 提示词下 Spark 拥有约 15 秒的起跑领先优势，M5 Ultra 需要连续生成数千个 Token 的超长回答才能抹平这部分等待时间。
五、 KV 缓存与上下文热启动影响（Prefix Caching）
虽然第一次读取长文本时 M5 Ultra 较慢，但在实际日常编程开发（AI Coding Agent）场景中，Prefix Caching（前缀缓存） 能够大幅挽救实际使用体验：
表4：16,000 Tokens 会话下的冷启动 vs 缓存热启动对比交互轮次 M5 Ultra Prefill 耗时 双卡 DGX Spark Prefill 耗时 体验评价与实际工作流分析 第 1 轮提问 (冷启动 / 全量解析) 21 秒 8.3 秒 仅在初次发送代码仓库时承受一次性延迟成本 第 2 轮追问 (命中 Prefix Cache) 3 秒 1.4 秒 历史上下文被复用，两者的首字等待感大幅缩小 - 结论：如果是在单项目的长期会话中持续微调代码，首轮 Prefill 的劣势会被缓存稀释；但若频繁切换代码库、传入巨型新文件或长对话超出缓存区，Prefill 算力瓶颈仍会反复出现。
六、 多用户高并发吞吐测试（Throughput & Concurrency）
如果把这套算力开放给团队多人并发调用，两套方案的调度能力与瓶颈差异显著：
表5：多并发场景下的吞吐量与排队情况测试场景与并发数 评测指标 M5 Ultra (Mac Studio) 双卡 DGX Spark (vLLM) 核心机制差异剖析 DeepSeek (4 并发用户) 总吞吐率 66 Tokens/s (达到峰值) 稳定提升 苹果架构在 4 并发以内调度效率尚可 DeepSeek (8 并发用户) 总吞吐率 46 Tokens/s (严重下滑) 70 Tokens/s (持续爬升) 苹果算力无法兼顾多人同时的 Prefill 与 Decode，吞吐崩塌 DeepSeek (8人各带8K历史) 首字等待时间 (TTFT) > 60 秒 (人均排队极长) ~24 秒 多人插队引发重新计算，苹果排队严重恶化 DeepSeek (8人各带8K历史) 人均输出流速 ~5 Tokens/s (总计 11 t/s) ~7 Tokens/s (总计 25 t/s) Spark 集群借助 vLLM 连续批处理维持更高服务质量 Qwen 3.8 (8 并发用户) 总吞吐率 66 t/s (llama.cpp) / 70 t/s (MLX) 120 Tokens/s Spark 吞吐接近 Mac 的 1.7~1.8 倍 - 并发适用人群：实测印证 Mac Studio 本质上是一台**单人至极少数人（1-2人）**使用的“个人工作站”；而双 DGX Spark 集群更适合支撑 3-4 人乃至 8 人 的小型开发团队内部微服务。
七、 满载功耗与温控表现
过去很多开发者常下意识认为“Mac 极度省电、专业服务器功耗极高”，但在 100% 满载极限跑大模型时，实测数据打破了固有刻板印象：
表6：重载推理下的功耗与发热实测测试维度 Apple M5 Ultra (Mac Studio) 双 NVIDIA DGX Spark 集群 备注与分析 重载峰值整机功耗 434 W 410 W 满载推理时两者能耗基本处于同一水准 机身最热处温度 约 49°C ~ 50°C 约 48°C 机身表面温度相差无几 出风口格栅温度 约 56°C 约 58°C ~ 63°C 双 Spark 后部排风温度略高 待机功耗与日常噪音 待机功耗极低，日常几乎无声 待机功耗较高，风扇全时工作有持续风噪 办公桌面环境摆放体验 Mac 完胜
八、 测评总结与选型指南
1. 核心结论
- “你没关注的那个数字” 就是 Prefill 算力与首字响应时间（TTFT）：如果你的日常工作流包含大量的 大型代码仓库审查、几十页 PDF 文档提取、复杂长 Prompt，DGX Spark 集群凭借 NVIDIA GPU 的矩阵算力优势，能将启动响应速度提高 2 到 3 倍以上。
- M5 Ultra 的绝对长板：在短上下文的单流解码中，依靠 1.2 TB/s 的逆天统一内存带宽，文字吐出速度超越 Spark 集群；加之零门槛的单机部署环境、极致的日常待机静音体验，以及兼顾视频剪辑和日常开发的多功能性，是极具吸引力的全能个人机皇。
- 双 DGX Spark 的专业优势：拥有原生 CUDA / vLLM 云原生生态支持，在多节点 Tensor Parallelism、长文本吞吐及 4-8 人团队并发场景下展现了更强的吞吐后劲。
2. 社区探索与前沿架构：Prefill-Decode 分离部署
测试作者特别提到了近期开源社区正在探索的 分步解耦推理架构（Disaggregated Prefill-Decode）：
- 利用 DGX Spark 专门负责第一阶段的高算力 Prefill 阶段（快速消化万级上下文）；
- 将计算好的 KV 状态转交由 M5 Ultra 进行高内存带宽的 Decode 生成（享受 1.2 TB/s 的高速吐字）。
这种软硬件混编的解耦方案或许是未来突破单机算力瓶颈的终极探索方向。
-
，
J johnnybegood 引用了 此主题
-
-
-
-
，
T terry 引用了 此主题
