DGX Spark六个月实测：营销数字在骗人，真实性能这样算

DGX Spark六个月实测：营销数字在骗人，真实性能这样算 | 前端进阶之旅

Full translation

完整中文译文

去年冬天，我把 NVIDIA 的 DGX Spark 放到了办公桌上。GB10 Grace Blackwell 芯片，128 GB 统一内存，约 4700 欧元，体积大概相当于两本平装书叠起来的大小。我经营一家自动化咨询公司，客户都是德国人，对把文档传到美国云端这件事格外敏感，所以"模型跑在我办公室里"这件事是能直接变现的。

这就是我购买前找不到的那篇测评：这台机器实际擅长什么、为什么规格表骗了我一整晚，以及如何把配置调对——从失望到变成现在承接大部分生产工作负载的主力机器。

那个关键数字不在宣传页上

这里有个陷阱。宣传的核心规格喊着容量：128 GB 统一内存，FP4 算力一个 petaflop。容量决定能装什么，但不说明什么能用。

Token 生成是内存带宽受限的。每生成一个 token，引擎本质上要把所有活跃的模型权重流经芯片。所以天花板就是一个简单的除法：

text
max tokens/sec ≈ memory bandwidth / bytes of active weights

DGX Spark 带宽：~273 GB/s

Dense 70B @ Q4（约 42 GB）：   273 / 42  ≈ 6.5 tok/s 天花板
Dense 70B @ FP8（约 70 GB）：  273 / 70  ≈ 3.9 tok/s 天花板

实际数字落在天花板之下。NVIDIA 自己的 Ollama 基准测试显示，在这台机器上跑 70B dense 模型 FP8 精度只有约 2.7 tok/s。我第一天晚上加载了这样一个模型，输入一条提示词，看着 token 像漏水的水龙头一样一滴一滴出来。对比之下，M3 Ultra 凭借其 819 GB/s 的带宽跑同样的模型能达到 25-30 tok/s。Spark 的实际可跑模型容量是 Mac 的三倍，带宽却只有三分之一。没有哪个产品视频会写这句话。

所以这机器很差吗？不是。是我用错了方式，而且错得很具体。

修复一：别跑 dense 模型

Mixture-of-Experts 模型每个 token 只激活一小部分参数。带宽公式只计算活跃的字节数：

text
MoE，~110B 总参 / ~12B 活跃 @ Q4（约 7 GB 活跃）：

273 / 7 ≈ 39 tok/s 天花板

这下这台机器就合理了。128 GB 能装下完整的专家集合，这是更小机器根本塞不下的，而每个 token 的流量始终很小。大型 MoE 模型正是这台硬件设计来承接的工作负载，而当前开源权重一代（更大的 Qwen MoE 变体、gpt-oss-120b 及其同类）在这里能跑到 30-80 tok/s，具体取决于模型和引擎。这比人阅读的速度还快。

我现在给所有评估这类硬件的人的实际建议是：永远不要相信一个没有三个限定条件的 tok/s 数字。模型架构是什么（dense 还是 MoE）、量化方式是什么、推理引擎是什么。同样的机器根据这三个条件可以跑出 2.7 也可以跑出 60，而且两个数字都是真实的。

修复二：别用默认技术栈来跑大模型

便捷工具（开箱即用的 Ollama）非常适合入门，但在这一特定的 ARM+Blackwell 平台上明显落后。优化路径是 TensorRT-LLM 或带 CUDA 支持编译的最新版 llama.cpp，再加上可用的 NVFP4 量化权重，这些是实实在在的百分比提升。NVIDIA 自发布以来一直在为这个平台稳定推送软件更新，收益颇丰——这是客气的说法，实际上发布日的软件确实把性能留在了桌面上。

我的配置最终沉淀为三层。

第一层：llama.cpp server，每个模型一个。从源码在这台机器上编译（它跑 DGX OS，一个 Ubuntu 的衍生版，所以这没什么稀奇的）。每个模型一个 llama-server 进程，暴露一个 OpenAI 兼容的端点。

第二层：llama-swap 作为交通警。我不想同时驻留五个模型，也不想 SSH 进去切换。llama-swap 是一个小型代理，根据传入请求的 model 字段懒启动和停止模型 server：

models:
  "qwen-big":
    cmd: > /opt/llama.cpp/llama-server -m /models/qwen3-moe-q4.gguf --port ${PORT} -c 32768 -ngl 999
    ttl: 900  # 空闲 15 分钟后卸载

  "gemma-fast":
    cmd: > /opt/llama.cpp/llama-server -m /models/gemma3-27b-q4.gguf --port ${PORT} -c 16384 -ngl 999
    ttl: 900

请求 model: "qwen-big"，代理就把它启动起来，卸掉旧模型，然后路由。从外部看它就像一个托管多个模型的端点，和云服务商一模一样。

第三层：LiteLLM 代理放在所有东西前面。这是我在刀架上也会保住的部分。我所有的 n8n 工作流和脚本都对接一个 API。在背后，LiteLLM 按模型名路由：本地名字走到 Spark，前沿名字走到云 API。这意味着任何工作流只需要改一个字符串就能在本地和云之间迁移，不需要改代码：

model_list:
  - model_name: local-workhorse
    litellm_params:
      model: openai/qwen-big
      api_base: http://spark.local:8080/v1

  - model_name: heavy-thinking
    litellm_params:
      model: anthropic/claude-sonnet-4-6

这种迁移路径才是真正的杀手级功能。我针对云模型原型化一个工作流，一旦提示词稳定了就指向 local-workhorse，看看质量是否能保持。实际情况比预期更经常能保持，大概在所有提取、分类、摘要、转换类的任务上都能。对于真正困难的推理任务就不行了，装作可以的话我会害了客户。

实际上它跑什么生产负载

具体来说，经过六个月的磨合之后：

一个中型 dense 模型（27B 级）保持热状态，处理对延迟敏感的任务：邮件流水线的分类、从文档中提取信息、任何数据离开大楼前的匿名化。对单用户来说基本是即时的。

一个大型 MoE 模型换入用于对质量敏感的批处理工作：报告生成、简报初稿、转录摘要。以舒适的阅读速度运行，零边际成本，我已经不再犹豫在数千份文档上跑实验了，因为流量计没有在转。

一个 embedding 模型永久运行，用于我自己文档存档的搜索。这个负载轻到几乎免费，而这正是"数据从不离开房间"这件事对我最重要的场景。

所有这些的每月电费大概是一箱油的价钱，云 API 账单明显下降了。但说实话：以独立咨询师的用量，这台机器要几年才能摊销，不是几个月。我买的是数据主权和免费实验，成本节省是附带的。

如果你是这种人就买：你需要在小体积静音盒子里跑大模型容量、工作负载是 MoE 形状或批处理形状、需要 CUDA 兼容性、或者"本地化"是一个你可以开账的合规需求。

如果你是这种人就跳过：你主要想要快速的 dense 70B 聊天（Mac Studio 带宽充足，完胜它）、你从没碰过 Linux（它是 Linux，完全地、永远地）、或者你真正目的是学习——这种情况下你现有的笔记本跑一个 8B 模型同样能教会你这些经验，而且免费。

无论你买什么：购买前做带宽除法，不要购买后，不要第一天晚上带着沉甸甸的感觉做，像某个我可以点名道姓的咨询师那样。

评论区开放，我特别好奇其他人在这个平台上用最新版 llama.cpp 和 TensorRT-LLM 分别跑出了多少 tok/s。我的数字随着每次软件更新一直在改善，我已经半途停止相信自己的基准测试了。