硬件配置与连接架构对比

本次测试的核心对象是两款具备256GB统一内存的AI硬件方案：单台顶配M5 Ultra Max Studio与由两台DGX Spark组成的集群。M5 Ultra将256GB内存集成在一个机箱内，而DGX Spark方案则是两台各含128GB内存的设备通过一根高速线缆连接。这根被称为QSFP的粗大线缆运行着RoCE（基于以太网的远程直接内存访问）协议，允许两台设备直接向彼此的内存写入数据。在存储方面，M5 Ultra配备8TB SSD，而两台Spark合计也拥有8TB（每台4TB）。价格上，M5 Ultra配置约为14,000美元，而两台Spark目前单价接近5,000美元（原价4,000美元），合计约10,000美元，加上昂贵的线缆成本后仍比M5 Ultra便宜。这种架构差异意味着Spark集群并非简单的“两台电脑拼凑”，而是通过软件层实现内存互通的分布式系统。

模型并行原理与显存分配机制

由于现代大语言模型（如DeepSeek V4 Flash，约150-160GB）体积庞大，无法单台塞入Spark的128GB内存中（即使尝试加载也会失败），因此必须采用张量并行（Tensor Parallel）技术。在这种模式下，模型的每一层被切分为两半，分别存储在两台Spark上。对于每一个生成的Token，两个节点都需要计算各自的一半，并通过线缆交换结果后才能进入下一层。这导致了大量的数据往返通信开销。相比之下，M5 Ultra可以直接将完整模型加载到单一内存空间中。测试中使用的DeepSeek V4 Flash在Spark集群上，每个节点占用约111GB内存（含系统开销），而M5 Ultra则直接加载全部数据。软件层面，Spark主要使用NVIDIA的vLLM引擎进行模型分割与推理加速。

推理性能基准测试：首字延迟与生成速度

LLM的推理过程分为“阅读提示词”（计算密集型，依赖GPU算力）和“生成Token”（内存带宽敏感型）。在测试中，我们观察到了两种不同的性能表现。首先是一个简短提示下的基准跑分：M5 Ultra生成速度为38.7 tokens/秒，双Spark集群为34.3 tokens/秒，两者基本持平。然而，在使用Quen 3.8 Flash Next模型时，差异显现：M5 Ultra达到45 tokens/秒，而双Spark集群仅为38 tokens/秒，Mac胜出。这一结果印证了内存带宽的关键作用：Apple宣称M5 Ultra拥有1.2 TB/s的内存带宽，而单台Spark仅为273 GB/s。尽管双Spark合计理论带宽更高，但跨节点同步的通信开销抵消了部分优势。正如视频中所言：>

内存带宽与推理引擎的选择

在测试中，Mac的内存带宽实测约为 111 GB，虽未达到标称的200 GB，但仍具竞争力。然而，实际性能很大程度上取决于所选的软件引擎。DeepSeek模型在Llama CPP中生成速度约为每秒40个token，而切换到MLX引擎后提升至53 tokens/秒，这一软件切换带来了 34% 的速度提升。在Llama CPP环境下，Mac与Sparks的表现差异仅2%；尽管MLX下的53 tokens/秒快于Spark的38 tokens/秒，但该测试为进程内基准测试而非HTTP服务场景。作者指出：“The engine you pick for the model matters a lot.” 这表明软件优化对硬件潜力的释放至关重要，但需注意测试环境的差异。

Token概念与短上下文下的速度对比

理解Token有助于评估性能，1个Token约等于0.75个单词。常见的32K上下文长度相当于约 24,000个单词，即一份100页的文档。在短提示（2,000 tokens）下，Sparks的处理速度是Mac的两倍。具体数据为：Quen模型在Mac上耗时1.5秒，双Sparks仅0.85秒；DeepSeek在Mac上耗时2.5秒，双Sparks为1.25秒。虽然这种差异在极短提示下几乎不可察觉，但“By the time you wipe your nose, it's done” 暗示了长上下文下的累积效应。随着提示长度增加，Mac的相对劣势逐渐显现。

长上下文预填充：Sparks显著领先

当提示长度增至8,000 tokens时，DeepSeek在Mac上耗时10秒，而在双Sparks上仅需4秒。若增至16,000 tokens，Mac耗时翻倍至21秒。使用包含14个Python文件的真实代码库（32,000 tokens）进行测试时，双Sparks在17秒内开始流式输出，而Mac耗时50秒。作者强调：“Spark 17 seconds to Mac Studios 50 seconds. That's about three times the weight.” 在另一组对比中，M5 Ultra耗时44秒，双Sparks仅16.5秒；Quen模型中Mac为26秒，Sparks为11.2秒。随着提示长度加倍，Mac的处理时间也大致翻倍，而Sparks在处理128,000 tokens时仅耗时72秒。若Mac保持32K的速度比例，处理128K可能需要超过3分钟。

缓存机制与实际应用场景的修正

尽管Sparks在长预填充阶段占优，但实际应用中需考虑上下文缓存（Prefix Caching）。在包含16,000 tokens上下文的会话中，首次提问Mac耗时21秒、Sparks为8.3秒；但后续问题中，Mac仅需3秒，而Sparks需1.4秒。虽然Sparks仍快约2倍，但“you pay for that long read only once per session, not every time”。对于代码助手等场景，服务器通常保留已读取的代码库，后续提问仅增加少量新内容。因此，长等待主要是一次性初始成本。然而，当上下文频繁变化（如更换仓库或模型）导致缓存失效时，Sparks的预填充优势将再次凸显。这种差异催生了“disaggregated prefill decode”（分离式预填充与解码）架构的兴趣，即由Sparks负责预填充，Mac负责解码生成。

多用户并发下的吞吐量与读取瓶颈

在评估大语言模型推理性能时，单用户的读写速度只是基础，多用户并发（Concurrency）才是衡量服务器级能力的真正标准。测试显示，在MLX框架下处理32K上下文时，M5 Ultra耗时约19秒（优于LlamaCPP的26秒），但仍慢于Spark集群的11秒；对于DeepSeek模型，M5 Ultra即使以最佳读取速度也需22至30秒。当引入多用户场景时，总吞吐量（Total Throughput）往往被夸大，因为它将所有用户的生成Token相加，而每个用户实际获得的只是服务器资源的一小部分。随着新用户加入，服务器必须中断写入以读取新提示词，这增加了初始计算的延迟。

"Each person only gets a slice. The server writes for everyone together."（每个人只得到一份切片，服务器为所有人共同写入。）

在M5 Ultra上，当用户数超过4人时，读取时间开始超过写入时间，导致每个用户的Token分配份额缩小。具体数据显示，DeepSeek在4用户时达到峰值66 tokens/秒的总吞吐量，但在8用户时降至46 tokens/秒。相比之下，Spark集群在相同负载下吞吐量持续攀升至70 tokens/秒（16用户数据待测）。这种差异表明，M5 Ultra更适合单人或极少量用户的本地推理，而Spark集群在处理并发请求时具有显著优势。

结论

测试表明，M5 Ultra与双DGX Spark集群各有优劣。在单用户生成速度上，M5 Ultra凭借高内存带宽优势明显；但在长上下文预填充阶段，Spark集群因并行计算能力显著领先。实际应用中需考虑缓存机制：若会话上下文稳定，M5 Ultra的二次响应速度极快；若频繁切换长文档或高并发场景下，Spark集群凭借分离式架构和更高的吞吐量更具优势。M5 Ultra适合单人本地推理及缓存命中场景，而Spark集群更适合多用户并发、长提示处理或需分离预填充与解码的高负载服务器环境。