NVIDIA 64GB DGX Spark：可以「拼起来」的本地 AI，而不是租来的

NVIDIA 在 2026 年 10 月 2 日的官方博客里发布了 DGX Spark 的 64GB 统一内存版本，并从 10 月 23 日（周五）起由 Acer、ASUS、Dell、Gigabyte、HP 与 MSI 供货。它的定位很直白：随着开源模型越来越能干、体积越来越能塞进设备，本地 AI 正在从「玩具」变成「日常工作流」。这台机器保留了 GB10 Grace Blackwell 超级芯片、DGX OS 与完整的 NVIDIA AI 软件栈，可在设备上本地运行最高 1000 亿参数的模型——私密、不依赖云；而当负载长大时，两台机器可以拼成集群。

GB10 Grace Blackwell 超级芯片、统一内存、ConnectX-7 网络

变的只是一个 SKU，不是芯片

先把官方信息看清：这次没有新芯片。新的 64GB 配置与 128GB 型号共享同一颗 GB10 Grace Blackwell 超级芯片、DGX OS 与完整 NVIDIA 软件栈。变化只在统一内存容量——以及随之而来的价位。这个取舍很聪明：对绝大多数个人开发者和小团队来说，卡住他们的从来不是算力峰值，而是「能不能把想用的模型塞进内存」。把容量做成两档，等于把入门门槛和上限分成两个决定。两档结构还暗含了一条升级路径：你选的不是「买小机器还是大机器」，而是「最终会拥有几台一模一样的机器」。对个人开发者来说，这条成本曲线比一次性大额采购友好得多，也说明为什么集群这件事不是这次发布的注脚，而正是它的核心。

# Before you buy, do the maths. Decode-only weights need roughly
# bytes-per-parameter times parameter count. Quantisation decides it.
def fits_on_device(params_b, bits_per_weight, ctx_tokens, layers, kv_heads, head_dim):
    weights_gb = params_b * (bits_per_weight / 8)          # raw weights
    # KV cache is the number people forget: it scales with context.
    kv_gb = (2 * layers * kv_heads * head_dim * ctx_tokens
             * 2) / (1024 ** 3)                            # fp16 KV
    overhead = 0.15 * weights_gb        # runtime, activations, frag
    total = weights_gb + kv_gb + overhead
    return total, total <= 64

# Example: a 70B model at 4-bit fits; the same model at fp16 does not.
print(fits_on_device(70, 4, 32768, 80, 8, 128))   # (≈41 GB, True)
print(fits_on_device(70, 16, 32768, 80, 8, 128))  # (≈152 GB, False)

# This is why the 64GB SKU exists at all: quantised 70B-class models
# are the sweet spot, and long context is what pushes you to a cluster.

内存怎么算：真正吃内存的是上下文

买之前先把账算清楚。解码只用权重时，显存占用大致是「参数量 × 每权重字节数」，量化位数决定这个系数；但真正让单机爆掉的往往是 KV 缓存，它随上下文长度线性增长，而且很多人第一次部署时根本没把它算进去。所以 70B 级模型在 4 位量化下能舒服地跑，同一模型换成 fp16 就完全装不下——这不是「买大一点」的问题，而是「你打算用什么精度、跑多长的上下文」的问题。先定这两个数，再看配置。

# Two 64GB units connect directly with a QSFP cable and pool their
# memory to 128GB. NVIDIA Sync does the configuration so you do not.
nvidia-sync status
# Expected shape of what Sync reports after connecting two units:
#   node[0]  dgx-spark-64  connected  connectx-7  ok
#   node[1]  dgx-spark-64  connected  connectx-7  ok
#   fabric   200 GbE      validated
#   cluster  memory 128GB pooled
#   models   up to 200B parameters

nvidia-sync cluster init --assistant     # detects units, validates config
nvidia-sync cluster verify               # same software stack on both nodes

# The point: nothing is reconfigured when you go from one unit to
# two. If your setup needs per-node tweaks, you have a maintenance
# problem disguised as a cluster.

随机附带 Agent Toolkit、CUDA-X 库与 Nemotron 开源模型

双机集群：128GB 与 1.7 倍，数字要说清

官方给的数字很具体，也值得逐条读懂：两台 64GB 用 QSFP 线直连，内存合并到 128GB、模型支持扩到 2000 亿参数、内存带宽翻倍、在 Qwen 3.8 27B 测试中性能最高 1.7 倍。两点要留意。第一，1.7 倍是在特定模型上测出来的，不是「任意负载都 1.7 倍」的承诺。第二，「无需重新配置」才是这套设计真正的卖点——每个节点跑同一套软件栈，从一台扩到两台时不用改环境，这才是把集群从「周末项目」变成「点一下」的关键。关于带宽那条声明要加一句提醒，因为它容易被误读：所谓「内存带宽翻倍」指的是两台机器之间聚合起来的总线带宽，而不是每个节点内部的内存速度。它的收益出现在模型被切分到两个节点上运行时——而那种情形恰恰就是你本来就需要第二台的情形。如果你的负载本来就能塞进一台，集群买到的是余量，而不是速度。

# day one is a software story. vLLM with CUDA is supported out of
# the box, and it gives you an OpenAI-compatible endpoint, which
# is what every agent framework already knows how to talk to.
vllm serve Qwen/Qwen3.8-27B \
  --tensor-parallel-size 1 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --port 8000

# then, from any machine on your network:
curl http://dgx-spark.local:8000/v1/models

# Ollama is also supported if you want less ceremony, and PyTorch
# with CUDA if you want to fine-tune rather than just serve.

第一天的重点是软件，不是硬件

官方特意强调它「开箱即用」：NVIDIA Agent Toolkit、CUDA-X AI 库、Nemotron 开源模型，以及对 Ollama、vLLM、带 CUDA 的 PyTorch 的开箱支持。对开发者来说，最有价值的是 vLLM 能给出一个 OpenAI 兼容端点——这意味着所有已经会跟 OpenAI 接口对话的 Agent 框架，改一个 base_url 就能指向本机模型。而月末的 Model Launcher 更进一步：一键拉取并启动 Qwen3.8 27B，并顺手把 OpenCode 配好指向它，让你直接在浏览器里写代码。

# The reason this matters for agents: the endpoint is local, so
# nothing leaves your network, and there is no per-token bill.
import openai

client = openai.OpenAI(
    base_url="http://dgx-spark.local:8000/v1",
    api_key="not-needed-locally",      # local, not a cloud credential
)

def review(diff):
    return client.chat.completions.create(
        model="Qwen3.8-27B",
        messages=[
            {"role": "system", "content": "Review this diff for bugs."},
            {"role": "user", "content": diff},
        ],
        temperature=0.1,
    ).choices[0].message.content

# NVIDIA says the Model Launcher (end of month) will also set up
# OpenCode pointed at the local model, so you can code in a browser.

两台拼一起：128GB 内存、2 倍带宽、最高 1.7 倍性能

官方给的三个用法，以及它们的隐含前提

NVIDIA 列了三种工作方式：一是让编码或研究 Agent 全天候挂在机器上，随时审查代码、分析文档、执行多步任务，集群则提供更大模型、更长上下文或并发 Agent 的余量；二是让 DGX Spark 承担推理，笔记本电脑只负责界面与创作；三是当单个任务超出单机时，两台拼起来继续跑。三者隐含同一个前提：你的任务得真的「本地优先」——涉及私有代码、内部数据，或者对每 token 成本敏感。如果只是偶尔问几个问题，云 API 依然更便宜。

# Plan context, not just weights. Long-context agents are what
# actually run a single unit out of memory, because KV cache grows
# linearly with tokens held in flight.
CONTEXT_PLAN = {
    "system_prompt_and_tools": 6_000,   # static, cache it if you can
    "repo_retrieval":         12_000,   # what the agent actually read
    "conversation":            8_000,   # multi-turn agent trajectory
    "headroom":                6_000,   # one more tool result
}
MAX_MODEL_LEN = sum(CONTEXT_PLAN.values())      # 32,000

def budget_exceeded(tokens_held, max_len=MAX_MODEL_LEN):
    # If this trips constantly, that is your signal: either shrink
    # retrieval, or add a second unit - not 'increase context' blindly.
    return tokens_held > max_len * 0.9

# A cluster does not make retrieval better. It buys you room to
# be sloppier about it. Fix retrieval first.

下手之前该核对什么

第一，算出你要跑的具体模型在目标精度与目标上下文下的实际内存占用，把 KV 缓存算进去再决定是单机还是双机。第二，确认你能接受的量化损失——量化换来的容量是有代价的，评估要在你自己的数据上做。第三，想清楚「扩展」是不是真需求：如果偶尔才需要 2000 亿参数级的模型，先把长上下文任务做小，可能比买第二台更划算。第四，留意时间线：64GB 配置 10 月 23 日起供货，集群助手随机器提供，Model Launcher 在本月末推出。第五，把「本地」的价值算进去——对私有代码与内部数据来说，不出网本身就是一项功能。