老实说，我挺惊讶的。把两台 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-bit 量化）的结果已列在 shi3z 的仓库中。下表将这些结果与本次 DGX Spark 双机集群 + 官方 FP8 的结果进行了对比。
基准测试结果
为什么“TPS 输了，但挂钟时间赢了”
如果你看着表格想：“等等，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 秒
TPS 输了但挂钟时间赢了，意味着“用更少的步骤达到了同样的正确答案”。在实际使用中，人类体验的是“任务完成所需的时间”，而不是瞬时 tok/s。
使用的配置
- 硬件：DGX Spark × 2（NVIDIA GB10，基于 Blackwell，每台 128 GB 统一内存）
- 节点互联：通过 ConnectX-7 200 Gbps RoCE 直连（Tensor Parallel = 2，PyTorch 分布式后端）
- 推理引擎：Aiden 的配方，将 b12x（一组 GB10 专用的 CuTe DSL 内核）集成到 vLLM 0.21.1dev 中
- 模型：DeepSeek-V4-Flash 官方 FP8（154 GB，FP8 注意力，MXFP4 MoE——这是 DeepSeek 发布的官方格式）
- 上下文：524,288 tokens（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-bit）或 Q4 来运行已成为常识，但这绝对会牺牲质量。事实上，我之前尝试过 DeepSeek-V4-Flash 的 IQ2XXS（2-bit）版本，在同样的基准测试中得到了 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 分钟内加载并总结一整本书（约 30 万 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 也发布了，感觉竞争比预期更激烈（虽然价格出来后气氛可能会降温……）。我对社区的发展以及更多优化和技巧的积累抱有很高期望！
Jensen 真是了不起……他的统治会长久持续下去吗？
**
**
**
**
**
附赠内容
敏锐的读者可能会有这样的质疑：
“那在 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 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 配置约有 30B 活跃参数。
- 在 Q4（4-bit）下，活跃参数占用约 15 GB，ds4 实现了 26.2 tok/s（实测）。
- 如果同一模型保持 FP8（8-bit），活跃参数占用约 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 专用软件栈的完整结合。
如果有人未来在 MLX 中为 Apple Silicon 编写了 MXFP4 融合 MoE GEMM、FP8 分页注意力和 DSA 稀疏注意力，这个前提就会被打破。格局将取决于社区实现。目前，Spark 在实现“官方质量 × 实用速度”的组合上领先了一步。
以上就是 Claude Code 提供的分析结果。
