导读：当拥有 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：硬件规格、拓扑互联与成本对比

二、 核心原理科普：“你没关注的那个数字”到底是什么？

很多开发者在评估本地推理性能时，往往只盯着终端输出的 Token/s（每秒生成词数），而忽略了模型推理实际上严格分为两个完全不同的阶段：

1. 预填充阶段（Prompt Prefill / Reading）

• 工作机制：模型一次性读入所有输入的提示词并进行矩阵乘法计算。
• 性能瓶颈：算力密集型（Compute-Bound），高度依赖 GPU 的纯算力（Tensor Cores / 矩阵浮点性能）。
• 直观感受：决定了首字生成延迟（Time to First Token, TTFT）——即按下回车到屏幕吐出第一个字之间漫长的等待时间。

2. 解码生成阶段（Token Generation / Decoding / Writing）

• 工作机制：自回归生成，每吐出一个 Token 都需要把数十上百 GB 的模型权重完整遍历读取一次。
• 性能瓶颈：显存带宽密集型（Memory Bandwidth-Bound），算力反而经常闲置。
• 直观感受：决定了后续文字流式打印的速度感。

视频核心发现：在很多人只关注的“第二阶段（逐词输出）”中，M5 Ultra 凭借 1.2 TB/s 的带宽能够打平甚至超越双 Spark；然而在第一阶段“提示词预填充（读取长文档/代码库）”中，NVIDIA GPU 算力展现了碾压式优势，而这正是长上下文交互中最致命的体验鸿沟！

三、 单用户生成性能实测（Decode 写入速度）

在短 Prompt、单用户并发场景下，测试两套平台在逐词生成（Writing）上的实际速度表现：

表2：单流解码生成速度对比 (Tokens/s)

• 软件引擎红利：在 Mac 上，软件框架对吞吐影响显著。同一 DeepSeek 4-bit 模型从 llama.cpp 切换到 Apple 原生 MLX 框架，生成速度直接从 40 t/s 跃升至 53 t/s。

四、 提示词预填充速度实测（Prefill / 首字响应时间）

当输入的上下文逐渐拉长（从 2K 扩展至 32K 实际代码库甚至 128K），GPU 算力差距开始带来明显的首字响应延迟分水岭：

表3：不同上下文长度下的 Prefill 处理时间与首字延迟

• 实测细节：在输入含 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 缓存热启动对比

• 结论：如果是在单项目的长期会话中持续微调代码，首轮 Prefill 的劣势会被缓存稀释；但若频繁切换代码库、传入巨型新文件或长对话超出缓存区，Prefill 算力瓶颈仍会反复出现。

六、 多用户高并发吞吐测试（Throughput & Concurrency）

如果把这套算力开放给团队多人并发调用，两套方案的调度能力与瓶颈差异显著：

表5：多并发场景下的吞吐量与排队情况

• 并发适用人群：实测印证 Mac Studio 本质上是一台**单人至极少数人（1-2人）**使用的“个人工作站”；而双 DGX Spark 集群更适合支撑 3-4 人乃至 8 人 的小型开发团队内部微服务。

七、 满载功耗与温控表现

过去很多开发者常下意识认为“Mac 极度省电、专业服务器功耗极高”，但在 100% 满载极限跑大模型时，实测数据打破了固有刻板印象：

表6：重载推理下的功耗与发热实测

八、 测评总结与选型指南

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 的高速吐字）。
  这种软硬件混编的解耦方案或许是未来突破单机算力瓶颈的终极探索方向。