你在想我想的事吗？这些边缘太锋利了。你不应该让你的孩子玩它们，盒子上甚至都这么写了。我这里有M5 Ultra Max Studio，256GB内存和两个DGX Spark。开始吧！它们运行起来了。好的，两者都生成了恰好800个token。M5 Ultra的速度是每秒38.7个token，双DGX Spark集群是每秒34.3个。这基本上是不相上下。但我们会发现这里有很多差异，这也是本视频剩余时间里这两者最接近的一次表现了。
这边是我们有的东西：这是全新的M5 Ultra，目前顶级的配置，256GB内存集成在一个盒子里。而在这一角，我们有两个DGX Spark，每个都有128GB内存，加起来也是256GB。它们通过一根粗壮的200Gbps线缆连接。这根线缆运行着一种叫做RoCE的东西（不是那个Rocky），即基于以太网的RDMA。这就像是一个缩写里的缩写，R代表RDMA（远程直接内存访问）。基本上，它们可以直接写入彼此的内存。
这里的Mac配置价格为14,000美元，因为它里面装有8TB的SSD驱动器。Spark每个有4TB存储，加起来也是8TB。Spark刚推出时每台售价约为4,000美元，现在接近5,000美元。所以两台加起来是10,000美元，仍然比这个便宜，再加上那根昂贵的线缆。如果你是本地运行大模型的开发者，或者想为小团队提供服务，你应该看这个视频。如果你不是，你也应该看，因为内容很酷。
Merlin AI是一个全能的AI工具，他们给我的观众提供了大幅折扣。我保留多个AI工具是因为每个都在特定方面表现出色，但这真的很贵，而且切换标签页会打断我的专注力。Merlin AI将ChatGPT、Claude、Gemini等整合在一起，让我可以根据当下需求（无论是编码、研究还是为视频写作）选择最佳工具。
看这个，我点击Merlin AI扩展程序，与网页聊天以总结我正在阅读的内容并提取重要部分。我甚至可以直接在指尖选择模型。如果需要更深入的信息，我会开启深度研究功能。它会从多个来源构建清晰、结构化的报告。它还有快速模式，如网页搜索、学术搜索和Reddit搜索。
如果你单独付费：ChatGPT是20美元，Claude是20美元，Gemini也是20美元。这加起来很快。Merlin AI更便宜是因为他们批量购买AI API访问权限，API成本低于20美元的套餐。而且大多数人甚至一个月都用不到价值20美元的API额度。
这是折扣信息：我点击定价，继续，跳转到Stripe页面。输入促销代码后，年度总价降至60美元。这基本上相当于每月5美元。我不知道这个优惠会持续多久，所以尽快行动吧。链接在描述中。
现在，两个Spark并不会神奇地变成一个大型计算机。VLLM是一个针对大语言模型的高吞吐量和内存高效推理及服务引擎，这是大多数NVIDIA设置运行的软件，它将模型拆分到两台设备上。在这种情况下称为张量并行（Tensor Parallel）。还有其他类型的并行化，我在其他视频中讨论过这一点，但今天我们做的是张量并行。
这意味着模型的每一层都被切成两半，每块Spark各占一半。对于每一个生成的token，两个盒子都执行各自的一半计算。然后在下一层开始之前，它们通过线缆交换结果。所以这涉及大量通过此类线缆的数据往返传输。这是一根QSFP线缆，就是那里那个标准接口。
那么为什么要用两个呢？因为现代模型非常适合使用两台设备。例如DeepSeek V4 Flash，大约150-160GB大小，无法装入单个128GB的Spark中。是的，我试过加载它一次，结果并不理想。此外，你还需要额外的空间来存储上下文数据。一旦跨两台设备加载它，每个节点仅持有略超过100GB的数据。
我现在已经在两者上都成功加载了它，占用111GB（当前只显示其中一个节点的数据，总容量为128GB）。这也包括正在运行的额外系统进程。所以每个设备获得模型的一半以及一点工作空间。而Mac只是将整个模型加载到一个盒子上。
注意一下，我在两台机器上运行的是同一个模型，但不是相同的文件。每个文件都向下舍入到4位量化（quantized），所以更小、更快。Spark运行的是VLLM，就像我之前提到的，Llama CPP这个流行工具也可以在那里工作。但VLLM是NVIDIA在这种拆分场景下的首选方案。在Mac上，我测试了Llama CPP和MLX。有时一个胜出，有时另一个胜出，我会随着进展指出这一点。
因此，我将运行DeepSeek V4 Flash和Qwen 3.8 Flash Next（这是另一个相当新的模型，需要两个Spark因为它足够大）。每次生成token时，实际上分两步发生。我知道你们中的一些人已经知道这一切了，但这是给新手的：首先，模型一次性读取整个提示词。这纯粹是数学运算，即矩阵乘法。
因此，拥有更多计算能力的盒子获胜。通常这些操作发生在GPU上，所以更强大的GPU能更快地完成任务。这段时间就是你的首token延迟时间（time to first token），即等待GPU进行数字计算的时间。然后它获取答案并逐个写入token。每个新token都意味着模型权重需要再次经过内存访问。
权重基本上就是一个巨大的数字集合，许多千兆字节的数字集合文件，也就是你下载的那些模型文件。因此，因为每使用一个token就要访问内存，所以答案的写入取决于内存速度。换句话说，推理的第二部分是token生成，它依赖于显存带宽（memory bandwidth）。
让我们来看看写入部分，也就是第二部分。这是从一开始的赛跑结果，也是我在开头展示给你的那个版本（虽然略有不同，但数字非常接近，因为我多次运行了测试）。使用简短提示和一个用户输入：我指向这边是因为我的图表在这里。在DeepSeek模型中，M5 Ultra的速度约为每秒38个token，双Spark集群也约为每秒38个token。这基本上是个平局。两者的速度都相当不错，考虑到这是一个大模型，表现已经很好了。
使用Qwen时则有一些差异：Mac上为每秒45个token，双Spark集群为每秒38个token。这一局我投给Mac。为什么会这样？根据我的猜测，原因是内存带宽。苹果表示M5 Ultra拥有1.2TB/s的显存带宽，这非常高。每个Spark标称仅为273GB/s，显著较低。而且除此之外，它们还要通过线缆进行同步。
测得约为111GB，虽未达到标称的200GB，但表现依然不错。不过我没测试这根线缆实际拖慢了多少速度，所以请对此持保留态度。但Mac还有另一招：为模型选择的引擎至关重要。例如，DeepSeek在Llama CPP上运行速度约为每秒40个token，但如果使用相同的模型并改用MLX引擎，则能达到每秒53个token。仅通过切换软件就提升了34%的速度。
在Llama CPP以完全相同方式服务的情况下，Mac和Spark集群的表现相差仅2%。因此，是的，这比Spark每秒38个token的速度更快，但我仅在进程内测试了MLX上的DeepSeek。这意味着基准测试直接与引擎通信，而非像真实聊天服务器那样通过HTTP提供服务。总之，我正在收集信息。
我尽力完成所有能做的测试。虽然有很多测试可以做，但到目前为止，Mac的表现看起来相当不错。现在简单科普一下token的概念：一个token大约相当于四分之三个单词左右。因此，你常会听到“32K”或32,000个token的说法，这大致相当于现代模型典型的起始点。从那里开始，上下文大小可以向上扩展。
32,000个token大约对应24,000个单词，这大致是一份100页文档的篇幅。读完这份100页的文档需要多长时间呢？我敢打赌，肯定不是30秒或者几秒钟就能读完。我们稍后就会知道结果了。现在来看读取或提示词处理，这是GPU全力运转的阶段。
记得我之前是从小规模测试开始的。在2,000个token时，两者起步都很快，但Spark集群的速度是Mac的两倍。Quen模型在Mac上耗时1.5秒，而在双Spark集群上仅需0.85秒。DeepSeek模型在Mac上耗时2.5秒，而在双Spark集群上仅需1.25秒。
你可能不会在意这些差异，因为这只是2,000个token的提示词。你可能打个喷嚏的时间都还没用完，它就已经处理完了。但到了后面你可能会在意这一点，我们稍后再讨论。在Quen模型上，即使写入速度更快的一方在几百个token后也能赢回优势。
如果我们将提示词稍微加长到8,000个token，DeepSeek在Spark集群上耗时约4秒，而在Mac上则需10秒。如果我们将提示词加倍至16,000个token，Mac的处理时间也翻倍增至21秒。这时候你可能需要打几个喷嚏并擦几次鼻子了，对吧？是的，这次你会注意到差异。
让我们加大规模测试吧。我知道你们中有些人会说：“哦，32,000不算大。”那我们一步步来。这次我使用了一个真实的代码库，包含32,000个token。看，里面有14个Python文件。啊，DGX Spark集群已经开始流式输出了，这意味着它们正在生成token。
现在我们已经超过了计算阶段，而Mac仍在读取提示词并进行处理。双DGX Spark集群在17秒时已完成任务，而我们还在等待Mac完成思考并读取提示词。耗时50秒。我能听到它在生成内容了，是的，这里存在显著差异：生成了300个token，提示词为32,000个。
如果看下面的图表，Spark集群耗时17秒，Mac Studio耗时50秒，大约是三倍的处理时间。但先别急着跑去买Spark集群。你们中有些人可能仍然想选择Mac，我稍后会告诉你们原因。
在这张图表上，我使用了稍微短一点的提示词，但比例大致相同。M5 Ultra耗时44秒，双Spark集群为16.5秒；Quen模型在Ultra上耗时26秒，在Spark集群上为11.2秒。速度快了约2.4倍，差距悬殊。此后情况大致如此：提示词加倍，处理时间也加倍。
对于Spark集群，我将其推高至128,000个token。我没有让Mac运行128,000个token，因为我看到了其中的规律：如果它保持32k的速度节奏，等待时间将超过3分钟。因此，随着提示词变长，Mac只会越来越慢。Spark集群在72秒内完成，仍远快于M3 Ultra（注：此处原文口误应为M5或指代前文机型，按原意翻译）。
好吧，我不打算找借口。我只是说我们整体仍有改进空间。让我们回到那个代码库竞赛吧：DeepSeek配合32k提示词，Spark集群获得了约30秒的领先优势。此后在Llama CPP上，写入速度持平；Quen则不同：Spark集群领先约15秒开始，但Mac在每个token上能追回几千分之一秒。
根据我的计算，将两者相除后，Mac需要数千个token才能追上进度。我没有计时这一过程，这只是估算，但这数量相当可观，基本上相当于一个新文件的大小。因此，大输入有利于Spark集群；而大输出则有利于Mac（至少在Quen模型上）。
这就是为什么我们对使用Spark集群和Mac进行解耦的预填充（prefill）和解码（decode）如此感兴趣的原因：Spark集群负责预填充，Mac负责解码。我之前做过一个关于此的视频，介绍几个月前的早期原型，链接在下方供你查看，非常有趣。
但这是Ash Hart的一个新项目，你也可以去看看他目前在推特上发布了很多相关内容。不过有一件事会削弱这种优势：你总会在演示中看到，当这些系统刚启动时提示词处理速度差异巨大。但这并非现实世界中的情况。
在真实场景中，同一会话内服务器会保留已读取的内容。缓存中有16,000个token的上下文。第一次提问在Mac上耗时21秒，在Spark集群上为8.3秒。好的，这部分我们已经见过了，但后续问题在Mac上仅需3秒，Spark集群为1.4秒。
是的，Spark集群仍然稍快一些，但你只需在每次会话中支付一次长读取的代价，而非每次都付。我最近为频道会员制作了一期视频，详细讲解了不同的加速技术，包括前缀缓存（prefix caching）。感谢频道的会员们，真的很感激你们。
有时当我有机会录制时，他们会获得额外的视频内容。感谢大家的支持。总之，这就是编码工具的实际工作方式：你的智能体发送一次代码库，服务器将其保留，每个新问题仅在此基础上增加少量内容。因此，漫长的等待主要是初始首次提问的成本，而非每次提问的成本。
最受影响的情况是上下文不断变化时：显然是新的代码库、大型新文件或超出缓存容量的长会话。这些都是可能的情况。另一个我在运行前沿模型时发现的现象是：当你切换模型时（例如从Opus 5切换到Opus 5.5或Fable 1.1），你必须重新计算所有内容，且初始延迟通常更长。
但我们现在讨论的不是前沿模型，而是本地部署。不过同样的理念依然适用：MLX能否拯救Mac的读取速度呢？在Quen模型上，情况有些分裂。Llama CPP……
写入速度更快，而 MLX 读取速度也更快。MLX 在大约 19 秒内就能处理完 32K，而不是原来的 26 秒。但这仍然落后于 Spark 的 11 秒。对于 DeepSeek，即使在 MLX 的最佳读取速度下，32,000 个令牌也至少需要 22 秒，可能更接近 30 秒。是的，这也比 Spark 慢至于 MLX 是否能让 Mac 赢得这场竞赛，我还不知道。我还没有在更长的提示或用户的情况下深入测试 MLX。
之前说过还有很多测试要做，我正在逐一处理这些测试。多个用户的情况有时被称为并发数（concurrency），你通常会看到一个较大的数字被引用，那是所有令牌生成的总吞吐量速度。但要小心这个数字，因为它显示的是每个人的总和。这是每个人令牌的累加值。每个用户只得到其中的一份份额服务器为所有人一起写入当有新的人加入时，服务器必须停下来读取他们的提示，这会增加初始计算的时间。
在 Mac 上，当用户超过四人时，读取速度会变慢它花费更多时间在读取而不是写入。因此，在那一点上，每个人的份额都会缩小一些你可以在 Mac 上看到这一点，DeepSeek 在四名用户时达到峰值为每秒 66 个令牌这是总数。然后对于八名用户，它下降到每秒 46 个令牌但是 Spark 继续攀升到每秒 70 个令牌，我还没有测试过十六名用户所以我不确定它在哪里下降待定。
现在给每个人 8,000 个令牌的聊天历史，在八名用户时，Mac 大约每秒产生 11 个令牌。Spark 则是 25，这是总数但真正的痛苦在于等待在 Mac 上每个人等待第一个词超过一分钟然后每秒获得大约五个令牌。而在 Spark 上是大约 24 秒的等待然后是每秒约七个令牌所以是的，共享这些机器时保持私密。好吧你可以做到但也许使用较小的模型或者确实有办法分割这些机器，但不要对很多人使用大模型结果不会太好。
查看 Quen 在八名用户时的情况，Spark 总共输出每秒 120 个令牌。这相当不错是的，那比 DeepSeek 好得多Mac 在 Llama CVP 中为 66，在 MLX 中为 70。为此我使用了 OMLX这是一个新的工具比较新就在这里没有再等待你的 Mac 了
好吧，还是有一些等待。真的Mac是一台适合一个人的机器也许两个人Spark对于小团队来说稍微好一点，也许是四个人八个人你就在勉强了。起初我没有从两个 Spark 开始我去了四个然后八个那是一个更大的项目那实际上是实验性的更像是带有 breakout 电缆和我必须购买的额外交换机我为此制作了一个完整的视频。
相比之下，两个 Spark 是一种完美的设置它只是一根电缆Nvidia 的开发者网站 build.envidia.com/spark 有一些非常有趣的食谱，超级容易遵循而且大多数时候都能正常工作。它展示了如何连接两个 Spark 以及如何运行多个工作负载，vlm 等等相当简单你仍然需要对齐事物。我匹配两台机器上的操作系统、内核、驱动程序和固件然后你必须设置 VLM 和多节点以及一堆环境变量。
之后，你必须检查通过 RDMA 连接传输的流量你所得到的是 CUDA 和 VLM所以基本上，这是你在云中运行的相同类型的堆栈。但在 Mac 方面这台机器不仅仅是用于 AI它也擅长 AI，例如我的日常主力机是 M5 Max MacBook Pro。我在那台机器上做的所有事情，我都可以在 M5 Ultra 上做而且速度更快其中包括运行大模型和日常工作在 Mac 上是零设置基本上我可以卸载很多东西给它，比如渲染我的视频例如用于这个频道。
有时 Mac 会有点卡顿我在上面运行了很多东西目前我使用了 88 GB 的内存是的，即使有 128 GB 的内存它也有点卡顿所以能够轻松卸载东西是很好的。还有另一件事在那里它们两台机器上的 GPU 利用率都是满的或者是的，你在这里只看到一个但它们都在 Spark 上工作Mac 也使用了 100% 的 GPU。
天哪在我第一次看 M5 Ultra 时，我注意到那台机器相当烫是的Spark也以发热著称。我们并不孤单这里。目前我正在对这里的集群和 Mac Studio 进行非常重的负载这是我看到的这太疯狂了好吧，我不想跳闸但我可能会M5 Ultra 使用了 434 瓦Spark Cluster 使用了 410 瓦。所以我们非常接近我应该说在空闲时情况截然不同它们现在相当温暖而且我听到到处都是噪音就像到处都有噪音一样。实际上感觉差不多是的，它们都挺热的Mac Studio 最热点大约在 49°到 50°Spark 上约为 48°让我们看看背面哦，Mac Studio背面的格栅上是 56°哇Spark里我看到了 58、60、63。所以是的，两者都相当烫对于 Mac 上的 AI，根据你想要的堆栈有一些设置Llama CPP 或 MLX。OMLX相当容易也有像 native without the E这样的新东西还有启动画面这些有些太新了我甚至还没试过它们。基本上这些都是 homebrew 安装
256 GB分布在两个盒子里与在一个盒子中的 256 GB相同吗？好吧，它容纳相同的模型。只是读取速度快得多但在你出去花 10,000 美元或更多购买这些设置之前，看看你自己的工作你的提示有多大？你对提示的回答有多长？你想更多关于集群 Spark 的信息吗？观看这里的视频。集群 Mac Studios，观看这里
的视频感谢观看我们下次见。