老实说，我很惊讶。当我把两台 DGX Spark 组成集群并运行 DeepSeek-V4-Flash 时，结果显示，其总生成时间（实际挂钟时间）比 Mac Studio M3 Ultra 快了 1.78 倍——也就是说，完成任务的耗时几乎减半。而且，这还是 DGX Spark 运行官方 FP8 模型、未做任何额外量化的情况下实现的。
在记录这些基准测试数据时，我感到我一直以来反复强调的观点再次得到了数据的支持。那就是：
LLM 的性能，不能仅仅通过基于内存带宽的解码速度（每秒 Token 数，TPS）来衡量。
GPU 处理能力、节点间通信、内存层级结构、量化质量、上下文长度、并行处理等等——所有这些因素的“平衡”决定了实际用户体验。而 DGX Spark 的平衡性更好。
使用的基准测试：shi3z 的编码基准测试
在测量中，我使用了 shi3z 的日语 LLM 基准测试中的编码基准。任务是“在一次生成中完成一个运行在 React 上的聊天应用”。生成的代码实际上会在 Docker 中启动，并使用 Playwright 对登录、好友、私信和实时更新功能进行自动测试，功能性评分满分为 80 分。
在 Mac Studio M3 Ultra 上通过 antirez 的 ds4 推理引擎运行 DeepSeek-V4-Flash Q4（4 位量化）的结果，已列在 shi3z 的仓库中。下表将这些结果与本次 DGX Spark 2 单元集群 + 官方 FP8 的结果进行了对比。
基准测试结果
为什么“tok/s 落后，但挂钟时间领先”
如果你看着表格想，“等等，Mac 的 tok/s 更快”，那你是对的。单看吐出 Token 的瞬时速度（解码 TPS），Mac Studio M3 Ultra 快了 1.58 倍。这得益于 Apple Silicon 巨大的内存带宽。
然而，这里有一个陷阱。要完成同一个“80/80 满分”的聊天应用，Mac 生成了 8,036 个 Token，而 DGX Spark 只生成了 2,866 个 Token。 这大约是 2.8 倍的差距。
两者都使用了 DeepSeek-V4-Flash，官方质量没有下降，但合理的解释是：Mac 端量化到了 Q4，导致输出变得冗余；而 Spark 端以全质量的 FP8 运行，保持了输出的简洁。这是常见现象——量化对输出分布的影响不会体现在解码速度上，但会悄然影响生成策略。
因此，计算结果如下：
实际挂钟时间 = （输出 Token 数）÷（tok/s）
Mac：8,036 ÷ 26.2 = 307 秒 我们：2,866 ÷ 16.6 = 172 秒
tok/s 落后但挂钟时间领先，意味着“用更少的步骤达到了相同的正确答案”。在实际使用中，人类体验到的是“完成任务所需的时间”，而不是瞬时的 tok/s。
使用的配置
- 硬件：DGX Spark × 2（NVIDIA GB10，基于 Blackwell，每个 128 GB 统一内存）
- 节点互连：通过 ConnectX-7 200 Gbps RoCE 直接连接（张量并行 = 2，PyTorch 分布式后端）
- 推理引擎：Aiden 的配方，将 b12x（一套 GB10 特定的 CuTe DSL 内核）集成到 vLLM 0.21.1dev 中
- 模型：DeepSeek-V4-Flash 官方 FP8（154 GB，FP8 注意力，MXFP4 MoE——这是 DeepSeek 发布的官方格式）
- 上下文：524,288 个 Token（512K），util 0.82，KV 缓存 19.85 GiB，并发度 3.89×
- 多 Token 预测（MTP）：推测解码，接受率约为 62%（在不牺牲输出质量的前提下提升速度）
性能深度解析
除了本次基准测试的数据，我还分别测量了纯解码和预填充速度：
- 纯解码速度（短文本，不含 TTFT）：稳定在约 39 tok/s
- 预填充速度（大上下文）：1,277 tok/s（比没有 b12x 内核的旧配置的 196 tok/s 快了约 6.5 倍）
- 长上下文解码：即使我将上下文从 8K 增加到 64K → 128K → 256K → 512K → 768K，解码速度也没有急剧下降；实际上反而加速了（在 768K 时达到 106 tok/s）。这是因为 DeepSeek 的稀疏注意力（DSA）在 b12x 内核中得到了原生实现，使得注意力计算几乎与上下文长度无关。
这是“无额外量化，全质量”的结果
我想强调的另一点是，DGX Spark 端没有对模型进行任何额外的量化。我们直接加载了 HuggingFace 上分发的 154 GB 官方模型，并以 DeepSeek 设计的官方量化格式运行：FP8 注意力 + MXFP4 MoE。
在本地 LLM 的世界里，将巨大模型压缩到 IQ2（2 位）或 Q4 以使其运行已成为常识，但这无疑会削减质量。事实上，我之前尝试过 DeepSeek-V4-Flash 的 IQ2XXS（2 位）版本，在同一个基准测试中只得到了 55/80 分，并且出现了 Agent 行为崩溃。量化并不是免费的午餐。
通过两台 DGX Spark 即可获得 256 GB 的统一内存，这种配置首次使“以全质量运行巨大模型”成为可能。我认为这是一个比数据本身更有意义的进步。
为什么 Spark 的“平衡性”有效
分析支撑这一结果的技术要素：
- b12x 内核套件：使用 CuTe DSL 为 GB10 / SM12.x 专门编写的四种内核（NVFP4 融合 MoE GEMM、NVFP4 密集 GEMM、FP8 分页注意力和稀疏 MLA 注意力）。与通用 vLLM 中的 MARLIN 路径不同，这些内核以融合模式直接计算，无需反量化。
- 200 Gbps RoCE 直接连接：虽然 TP=2 的节点间 all-reduce 每层发生两次，但 200 Gbps 的直接连接使有效延迟保持很低，因此不会成为解码的瓶颈。
- 128 GB 统一内存 × 2：这是 Grace Blackwell 的优势，它不区分 HBM 和 DDR。这使得 154 GB 的官方 FP8 模型可以直接拆分到两个单元上，并为 512K 上下文所需的 19.85 GiB KV 缓存留出了充足空间。
- DeepSeek 稀疏注意力（DSA）的原生实现：b12x 内核利用了 GB10 的原生稀疏操作，正确处理了注意力复杂度不依赖上下文长度的设计。这导致了解码速度不随上下文长度急剧下降的结果。
换句话说，如果只有其中一个要素（内存带宽、计算能力、节点通信、长上下文优化或量化质量）突出，这个结果就不会发生。Spark 在所有这些要素上，都比同价位区间的任何单机配置提供了更高水平的表现。这就是其“平衡性”的本质。
实际使用中会带来什么变化？
抛开抽象理论，这里有一些具体的好处：
- 大型文档的摘要和代码分析变得切实可行：凭借 512K 上下文和 1,277 tok/s 的预填充速度，你可以在大约 4 分钟内加载并总结整本书（约 300,000 个 Token）。
- Agent 循环不会卡住：凭借 3.89× 的并发度，你可以同时运行聊天和长篇摘要生成（例如使用 Hermes Agent），而不会导致解码崩溃。
- 不会因量化失败导致“Agent 只会说空话”的问题：这是我在 IQ2 系列模型上多次遇到的陷阱；在全质量下，它根本不会发生。
- 功耗可与 Mac 竞争：两个 GB10 在推理期间的总功耗约为 100W–140W，接近 Mac Studio M3 Ultra 满载时的功耗。考虑到 1.78 倍的性能提升，能效比也不算差。
结论：仅凭 TPS 评判 LLM 性能的时代已经结束
吐出 Token 的瞬时速度——解码 TPS——当然是一个重要的指标。然而，它就像“100 米短跑的顶级速度”。实际需要的是“达到相同正确答案的时间”、“答案的质量”、“能同时运行多少个”、“能处理多长的上下文”以及“Agent 循环是否有效”。这些是综合评分。
这个结果表明，DGX Spark 在这综合评分上开始领先。我们已经进入了一个时代：只需将两台设备组成集群，就能以官方质量、长上下文、保持 Agent 兼容性，并以 Mac Studio 1.78 倍的挂钟速度运行巨大模型。
过去的几年里，人们一直说“LLM 全靠内存带宽”和“解码 TPS 决定一切”，但在真正运行了 Spark 之后，我觉得我“平衡性才是实际性能”的主张终于得到了数据的证实。
RTX Spark 也发布了，感觉事情比预期的更加火热（虽然价格出来后气氛可能会冷却下来……）。我对社区的成长以及更多优化和知识的积累充满期待！
老黄真是太厉害了……他的统治地位会持续很长时间吗？
**
**
**
**
**
附注
细心的读者可能会提出这样的批评：
“那如果在 Mac Studio 上也运行原始的官方 FP8，岂不是更公平的比较？”
“这样的比较不公平吧？Mac Studio 之所以变得冗余，是因为它被量化到了 Q4。如果在 Mac Studio 上运行原始的官方 FP8，在质量方面不就在同一起跑线上了吗？”这是一个合理的问题。
直接说重点：目前，还没有办法在 Mac Studio 上以实际可行的速度运行“原始的官方 FP8 + MXFP4 MoE”。
- 首先，没有兼容的推理引擎。
目前似乎没有一个引擎能在 Apple Silicon 上完全支持 DeepSeek-V4-Flash 的官方格式（FP8 注意力 + MXFP4 MoE + Lightning Indexer + DSA 稀疏注意力）（根据 Claude Code 的搜索结果）。
- MLX（Apple 官方的 Apple Silicon LLM 框架）：没有 MXFP4 MoE 融合 GEMM 的原生实现，没有 FP8 分页注意力，也没有 DeepSeek 的 DSA 稀疏注意力的 MLX 实现。如果尝试运行，很可能需要升格到 bf16。
- llama.cpp：无法直接加载 MXFP4，因此需要重新量化为 GGUF = 最终会被转换为 Q4 / Q5 / IQ2 等，不再是“原始官方”版本。
- vLLM：Apple Silicon 的支持本身就很有限，而且像 b12x 这样的 GB10 特定内核无法在 Mac 上运行。
- antirez/ds4：这是一个基于 MLX 专门为 DeepSeek V4 Flash 编写的专用引擎，假设使用 Q4。它是在 Mac Studio 上运行它的当前最佳方案，但并非为处理“原始 FP8”而构建。
antirez 专门为 DeepSeek V4 Flash 的 Q4 版本编写了专用引擎，这说明了一个现实：目前还没有在 Apple Silicon 上以官方质量运行的可行路径。
- 即使通过 bf16 升格运行，带宽也几乎会完全耗尽。
假设有人创建了一个 MLX 实现，将官方权重升格到 bf16。可以通过粗略的带宽计算来估计会发生什么：
- DeepSeek-V4-Flash 的 MoE 配置约有 300 亿个活跃参数。
- 在 Q4（4 位）下，活跃参数占用约 15 GB，ds4 实现了 26.2 tok/s（实测）。
- 如果同一模型以 FP8（8 位）加载，活跃参数占用约 30 GB = 带宽需求增加 2 倍 = 理论上同一引擎下约 13 tok/s。
- 此外，在 MLX 中升格到 bf16，活跃参数占用约 60 GB = 带宽需求增加 4 倍 = 理论上约 6.5 tok/s。
- 由于 Mac Studio M3 Ultra 的有效内存带宽约为 800 GB/s，每个 Token 读取 60 GB 将会触及带宽上限。
换句话说，在 Apple Silicon 上选择“原始质量”目前是以“牺牲超过一倍的速度”为代价的。使用 ds4 + Q4 以 26.2 tok/s 运行，显然是比使用全质量 bf16 仅获得 6 tok/s 更实际的选择。
- 这就是 Spark 的结构性优势所在。
另一方面，这个 DGX Spark 配置原生运行“原始官方 FP8 + MXFP4 MoE”。这由以下两点支持：
- b12x 套件中的 GB10 特定内核，具有“无需反量化”即可运行 NVFP4 融合 MoE GEMM 和 FP8 分页注意力的实现。
- 这些内核目前尚不为 Apple Silicon 编写。
- 因此，Spark 目前是唯一能同时实现 “官方质量原样运行” 和 “实际可用的速度” 的现实方案。
总而言之，如果只看硬件带宽，Mac Studio 单机的绝对值处于相似水平，但 “运行官方量化格式的内核实现的有无” 造成了决定性的差异。Spark 的优势不仅来自芯片，还来自与 b12x 等 GB10 专用软件栈的完整结合。
如果未来有人为 Apple Silicon 的 MLX 编写了 MXFP4 融合 MoE GEMM、FP8 分页注意力和 DSA 稀疏注意力，这个前提将不复存在。格局将取决于社区的实现。目前的事实是，Spark 在实现“官方质量 × 实际速度”的结合上领先了一步。
以上是 Claude Code 提供的分析结果。
