vLLM 在 DGX Spark 上：架构、配置与本地评估

NVIDIA DGX Spark 是一款桌面级 GB10 系统，用于本地运行大模型推理，填补了笔记本级开发与数据中心 GPU 服务之间的空白。vLLM 在 DGX Spark 上提供了一个快速高效的本地推理端点：它将 OpenAI 兼容 API 与运行大型 NVFP4 模型本地所需的内存、批处理、KV-cache 和遥测控制相结合。本文解释了 vLLM 如何映射到 DGX Spark 架构：模型选择、运行时标志、统一内存行为、OpenAI 兼容服务、Prometheus 遥测以及基于 Nemotron-3-Super 部署的本地评估结果。

vLLM 在 DGX Spark 上运行 Nemotron-3-Super，在 Inferact 办公室进行演示。

图 1. vLLM 在 DGX Spark 上的示例服务架构：客户端应用使用 /v1 和 /metrics 接口访问本地官方 vLLM 镜像。

技术总结

• vLLM 在 DGX Spark 上提供了一个快速高效的本地推理端点。 它将 OpenAI 兼容 API 与本地运行大型 NVFP4 模型所需的内存、批处理、KV-cache 和遥测控制相结合。当前的 Nemotron-3-Super DGX Spark 方案使用 vLLM 的官方 OpenAI 兼容服务器镜像，并带有 DGX Spark 特定的运行时标志，为开发者提供了一条从模型下载到本地服务的经过测试的路径。
• DGX Spark 架构决定了服务配置。 sm_121 消费级 Blackwell 芯片、统一的 CPU 和 GPU 内存池以及 Spark 的内存带宽，使得连续批处理、分页 KV cache、NVFP4 内核和 Prometheus 遥测尤为重要。
• vLLM 运行时标志应与 DGX Spark 的统一内存配置文件匹配。 Spark 的 CPU、GPU、操作系统、容器运行时、模型权重和 KV cache 共享一个 128 GB 的内存池，因此服务标志需要为系统其余部分留出空间。--gpu-memory-utilization 应在统一内存池中为操作系统、容器运行时和 KV cache 增长留出余量。--max-num-seqs 应保持较低值，因为 DGX Spark 更适合小批量推理而非高并发服务。
• vLLM 在 DGX Spark 上的性能很大程度上取决于开发者的目标。 当前的 vLLM 构建默认应使用 CUDA graphs，除非特定部署有理由禁用它。通过更新的 FP4 内核、异步调度和 MTP 推测解码，调整后的设置可以提高吞吐量，但内核选择是特定于模型和版本的。

DGX Spark 架构与内存模型

DGX Spark 基于 GB10 Grace Blackwell SoC 构建，具有统一的 CPU+GPU 内存池。Spark 的芯片和系统封装定义了在其上最高效运行的推理工作负载。三个属性至关重要，它们都影响了本文后续部分中的引擎和配置选择。

统一内存扩展了开发者可以在本地处理的模型大小。 DGX Spark 共享的 CPU/GPU 内存池允许开发者使用比固定专用 GPU 内存池更多的系统内存进行推理，使得在单个 Spark 上加载更大的 NVFP4 模型（根据模型架构和运行时配置，参数可达 2000 亿）变得可行。vLLM 非常适合这种架构，因为它提供了 --gpu-memory-utilization、--max-model-len、--max-num-seqs 和分页 KV cache 等控制，帮助开发者在统一内存池内平衡模型大小、上下文长度和并发性。对于更大的部署，多 Spark 配置可以进一步扩展此能力，利用 ConnectX 网络接口的低延迟和高带宽来支持跨系统的高效分布式推理。

Spark 特定的 sm_121 验证。 对于 DGX Spark 部署，开发者应使用专门为 sm_121 验证过的 vLLM 构建、容器镜像标签和运行时设置。如果您正在从更大的 GPU 系统移植 vLLM 配置，请将此比较视为内核支持和内存行为的工程检查清单，而不是对 Spark 的性能期望。

DGX Spark 非常适合 NVFP4 MoE 服务。 NVFP4 通过减少内存压力和改善预填充/模型适配行为提供了最大的实际优势，而解码速度仍受活跃参数数量和当前 vLLM 构建使用的内核路径影响。活跃参数约为 100-150 亿的 NVFP4 混合专家模型非常契合，因为活跃参数集更小，并且更新的混合精度和 FP4 内核路径持续改善解码性能。

DGX Spark 最好被视为大型 NVFP4 模型的本地单用户或小批量推理目标。密集模型和高并发服务可以运行，但它们与系统的内存带宽和统一内存特性不太匹配。

图 2. DGX Spark GB10 用于 vLLM 的统一内存：CPU、GPU、模型权重等共享一个 128 GB 池。

vLLM 与 DGX Spark 相关的功能

在 DGX Spark 上运行 vLLM 服务需要关注单个 Spark 上的本地小批量推理，以及多个 Spark 连接时的多节点扩展。最相关的功能包括内存高效的 KV-cache 管理、动态请求调度、OpenAI 兼容服务、运维指标以及架构感知的镜像/运行时支持。

针对 Spark 统一内存预算的分页 KV cache

经典的推理批处理模式按到达时间对请求进行分组，并同步运行它们。这对于固定长度的补全有效，但对于聊天工作负载效率低下，因为一个请求可能在五个 token 后完成，而另一个可能生成数百个。vLLM 的连续批处理在每个解码步骤接纳和驱逐请求，因此 GPU 无需等待静态批次中最长的请求。结合分页 KV cache，Spark 的内存预算可以支持合理数量的进行中请求，而不会产生过多的碎片。实际上，在服务 120B NVFP4 MoE 模型的 Spark 上，KV-cache 利用率在单用户测试期间通常保持在 5% 以下，在小批量演示流量下保持在 30% 以下。

用于本地 Spark 端点的 OpenAI 兼容流式传输

在 Spark 上，OpenAI 兼容 API 更多是关于保持本地应用程序的简单性，而不是框架的勾选框。与托管式 OpenAI 兼容端点通信的相同客户端代码可以指向本地 vLLM 端点，例如 http://localhost:8000/v1。

流式传输是让 DGX Spark 在本地推理中感觉响应迅速的关键。虽然数据中心 GPU 可能提供更高的解码吞吐量，但 stream=true 允许应用程序在 token 到达时立即渲染，为用户提供即时反馈，并在桌面系统上创造自然的交互体验。这使得 Spark 成为聊天、编码和代理工作流的实用本地端点，在这些场景中，感知延迟与总生成时间同等重要。

通过 Prometheus 获取 Spark 服务指标

在单个 Spark 上，可观测性意味着确认该设备的行为像一个交互式本地设备：提示快速预填充，解码保持稳定，统一内存池有足够的余量。vLLM 的 Prometheus 端点无需添加单独的服务即可暴露这些信号。在演示期间，侧边遥测视图可以从同一台机器轮询 /metrics。

最有用的 DGX Spark 信号是 KV-cache 利用率（vllm:kv_cache_usage_perc）、提示和生成 token 计数器，以及 TTFT / token 间延迟直方图。在健康的交互式代理运行中，提示处理在开始时需要时间，因为代理读取系统提示。在后续轮次中，KV cache 持续增长，但当之前的对话前缀被缓存时，提示处理时间不应激增。生成吞吐量和 token 间延迟稳定在预期的解码速率附近。KV-cache 利用率增长，但总体 KV cache 保持足够低，系统不会耗尽内存。最终，代理应用程序可以在 KV-cache 使用接近上下文限制之前压缩对话。

适用于 DGX Spark 的官方 vLLM 镜像

DGX Spark 最好使用为其 sm_121 目标构建和测试的软件栈。当前的 Nemotron-3-Super Spark 方案使用 vLLM 的官方 OpenAI 兼容服务器镜像。在我们运行时，我们使用了 CUDA 13 夜间构建轨道 vllm/vllm-openai:cu130-nightly，并带有 Spark 特定的解析器、FP4、调度和内存设置。

由于夜间构建标签会随时间变化，请将 cu130-nightly 视为兼容性轨道，而不是可重现的固定版本。对于部署，请根据特定发布镜像、提交特定的夜间构建标签或镜像摘要验证模型方案，然后在您的运行手册中保留该确切的镜像引用。

重要的一点是，Spark 不需要定制的服务接口：它通过 vLLM 的标准 OpenAI 兼容服务器运行。Spark 特定的工作在于模型方案、经过测试的镜像引用以及与 GB10 sm_121 配置文件匹配的运行时标志。

运行时配置与环境变量

本节涵盖了在 DGX Spark 上 vllm serve 的主要部署设置，并解释了每个选项的效果。

首先检查的方案和文档

使用 vLLM Recipes 索引作为模型特定命令的起点，然后交叉参考生成的 vllm serve CLI 参考 和 vLLM Docker 文档，以了解您安装版本中确切的标志和镜像行为。对于应用程序集成和生产可见性，请将 OpenAI 兼容服务器文档 和 vLLM 生产指标文档 放在手边。NVIDIA Spark 指南仍然是 DGX Spark 特定模型方案、解析器插件和内核设置的权威来源。

模型选择

在调整标志之前，模型选择是 Spark 上最大的性能杠杆。图 3 是方向性的模型选择指南，而非性能表格：它总结了代表性模型类别如何映射到 Spark 的内存容量、活跃参数数量和本地交互式服务配置文件。

图 3. 当前模型类别在 DGX Spark 上的方向性模型适配指南，展示了为什么活跃参数约 100-150 亿的 1000-1300 亿 MoE NVFP4 模型非常适合在 Spark 上进行本地 vLLM 服务。

是下面具体的可行示例，因为它是一个非常适合 Spark 的 NVFP4 MoE 模型。对于其他适合 Spark 大小的 NVFP4 MoE 模型，请保持相同的服务原则，但从该模型的方案开始。

预置权重

避免让第一次 vllm serve 调用同时执行大型模型下载。更可预测的模式是，将权重一次性预置到主机挂载的 Hugging Face 缓存中，然后将相同的缓存挂载到长期运行的容器中。特定于模型的下载和启动示例属于 vLLM Recipes；Spark 的原则是“下载一次，随处挂载”。

vllm serve 的重要标志

示例命令使用 vllm serve nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4 加上以下标志。

--gpu-memory-utilization。 vLLM 允许声明的 GPU 可见内存比例。在 Spark 上，这是统一池的一部分，因此该设置应为操作系统、内核页面缓存、容器运行时、KV cache 增长以及任何其他访问同一内存的进程留出空间。从模型方案开始，然后根据观察到的内存余量和工作负载并发性进行调整。

--max-model-len 131072。 服务器接受的最大提示 + 补全长度。在现代推理服务中，131K 是必需的，因为系统提示、工具模式、文件和历史记录很容易超过 20K token。您可以将其提高到模型支持的最大值，或为受限演示降低它，但不应将其视为每个进行中请求的固定最坏情况 KV 预留；vLLM 根据运行请求使用的活动上下文进行调度。

--max-num-seqs 4。 vLLM 将接纳的最大进行中序列数。对于 Spark 上的 Nemotron NVFP4，当前方案保持此值较低。超过四个并发解码流时，每个 token 的带宽开销可能会超过连续批处理的收益，并且首个 token 生成时间会激增。

自动前缀缓存。 vLLM 的自动前缀缓存在共享开头提示的请求之间重用 KV 块。它在 vLLM V1 中默认启用，因此下面的示例没有传递 --enable-prefix-caching。它对于具有长共享系统提示的聊天工作负载很有用，但即使缓存命中率为零，应用程序也应保持正确。

工具和推理解析器标志。 vLLM 可以将模型特定的推理轨迹和工具调用格式解析为结构化的 OpenAI 兼容响应字段。在 Spark 上，这些标志应遵循模型方案而非硬件默认值：仅为发出受支持推理块的模型设置推理解析器，并且仅在您的客户端需要工具调用时设置 --enable-auto-tool-choice 和工具调用解析器。对于当前的 vLLM 构建，Nemotron-3 模型可以使用内置的 --reasoning-parser nemotron_v3 路径；较旧的 Spark 方案可能仍引用外部的 super_v3 解析器插件。

有几个标志值得评估，但未经验证不应复制到演示运行手册中。--kv-cache-dtype fp8 可以减少 KV-cache 内存压力，但可能会影响模型可预测性，并且在 Spark 上对某些工作负载可能带来明显的性能成本；除非内存压力需要且质量检查通过，否则避免使用。--speculative-config 启用推测解码；对于 Nemotron-3-Super，相关路径是模型的 MTP 支持。--tensor-parallel-size 2 仅在两个 Spark 通过 ConnectX-7 端口连接时才有意义；将其用于经过验证的多 Spark 方案，而不是作为单节点调整标志。

何时覆盖 vLLM 默认值

vLLM 的默认启发式方法旨在为已安装版本选择正确的量化线性、MoE 和检查点加载路径。在单 GPU DGX Spark 上，从模型方案和 vLLM 默认值开始，仅当您有意为经过验证的确切模型、镜像和硬件组合添加显式覆盖时，才添加它们。

后端选择。 将量化线性和 MoE 后端选择保留为 auto，除非您测试的方案需要特定后端。正确的 FP4 路径可能随 vLLM 版本和模型架构而变化；最近的 FlashInfer CUTLASS 路径比旧的 Spark 指南所建议的要强大得多。如果您有意固定一个后端，请优先使用 CLI 标志，例如 --linear-backend 和 --moe-backend；此路径的旧环境变量已被弃用。

版本特定的解决方法。 某些 Spark 方案包含针对特定镜像标签的兼容性环境变量。将这些视为版本特定的解决方法，而不是通用的 vLLM 要求。例如，对于不使用张量并行的单 Spark 命令，不需要 FlashInfer allreduce 后端覆盖。

检查点量化。 vLLM 从模型配置中检测检查点量化。对于预量化的 NVFP4 检查点，请勿设置 --quantization；仅当您有意让 vLLM 在加载时应用量化方法时才使用它。

预热 JIT

冷启动行为取决于模型、内核、镜像标签和请求路径。在我们的 Nemotron-3-Super Spark 设置中，vllm serve 启动后的第一个请求会触发 Inductor 和 FlashInfer JIT 代码生成，大约需要 25 秒。避免将该路径暴露给最终用户。在启动时从应用程序发送一个小的 ping，该 ping 执行与真实工作负载相同的客户端路径（相同的模型，相同的 chat_template_kwargs，仅 max_tokens=3）。一旦相关内核预热，在我们的设置中，相同的短提示路径在不到半秒内返回。

初始权重加载是与请求预热不同的问题。如果 10-15 分钟的 safetensor 加载时间对您的部署很重要，请针对您的确切模型、镜像和存储栈评估 vLLM 的 fastsafetensors 或 InstantTensor 加载路径。

可预测性与吞吐量调整

Spark vLLM 配置可以针对简单的演示操作或最大吞吐量进行调整。

对于本文中的测量，--kv-cache-dtype 未设置，推测解码被禁用，CUDA graphs 保持启用。将这些视为针对此模型、镜像和工作负载的测量方案选择，而不是通用的 Spark 默认值。面向吞吐量的运行仍然可以评估 FP8 KV cache、异步调度、推测解码和显式后端选择，但这些设置应针对确切模型、提示形状、批处理模式和 vLLM 版本进行验证。

正确的点取决于工作负载。在这里，我们针对面向公众的演示路径进行优化：可预测的本地服务、清晰的遥测和稳定的响应。

图 4. DGX Spark vLLM 配置滑块，从简单的演示设置到调整后的吞吐量设置，比较了模型特定选项，如 FP4 后端选择、异步调度和推测解码。

示例工作负载：vllm-spark-game

为了测试超出简单 curl 调用的配置，我们构建了 vllm-spark-game。该游戏针对本地 vLLM 端点运行实时的 20 个问题交互，同时一个配套的统计视图从同一 Spark 轮询 vLLM 和 GPU 遥测。该工作负载的目的是端到端地测试服务路径：OpenAI 兼容的聊天请求、流式响应、提示预填充、解码、KV-cache 行为和实时指标。源代码布局和运行命令位于项目 README 中。

vllm-spark-game 在 2026 年 5 月 MLSys 期间的 Inferact 展位演示。

Docker 调用

此示例工作负载的完整 Docker 命令，带有主机挂载的 Hugging Face 缓存，以便在重启之间重用权重。该片段保留了 cu130-nightly 作为经过测试的兼容性轨道；对于可重现的部署，请将其替换为您验证过的确切发布标签、提交特定的夜间构建标签或镜像摘要。

docker run -d --name vllm --ipc=host --restart unless-stopped \
  --gpus all -p 8000:8000 \
  -e HF_TOKEN="$HF_TOKEN" \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:cu130-nightly \
  vllm serve nvidia/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4 \
    --served-model-name nemotron-3-super \
    --trust-remote-code \
    --max-model-len 131072 \
    --gpu-memory-utilization 0.85 \
    --max-num-seqs 4 \
    --reasoning-parser nemotron_v3 \
    --enable-auto-tool-choice \
    --tool-call-parser qwen3_coder

在我们的设置中，使用默认的 safetensor 加载路径，首次加载需要 10-15 分钟。对于启动时间重要的部署，在最终确定运行手册之前，请评估 fastsafetensors 或 InstantTensor。使用 curl -sS http://localhost:8000/v1/models | jq -r '.data[0].id' 验证就绪状态；该命令应返回 nemotron-3-super。

部署形态

图 5. vllm-spark-game 向 /v1 发送聊天请求，而 spark-stats 从同一本地 vLLM 端点轮询 /metrics 和 NVML。

单 Spark 评估结果

我们针对单个 DGX Spark 上托管 Nemotron-3-Super-120B-A12B-NVFP4 的本地 vLLM OpenAI 兼容端点，运行了面向应用程序的五场景评估。这些数字旨在使部署方法具体化，而不是作为排行榜提交。在我们更新的单 Spark 评估中，测量的解码吞吐量在所有场景中保持在 22.7-23.7 tok/s 范围内。每行是单次预热调用后三次运行的中位数。确切的 token 计数来自 stream_options.include_usage，而不是块计数。

场景	提示 token	生成 token	TTFT	总延迟	预填充 tok/s	解码 tok/s
典型判断调用（真实 20Q，嘈杂的 2-token 生成）	58	2	0.42 s	~0.53 s	140	~23
中等提示，短生成	1,834	32	1.12 s	~2.47 s	1,636	23.7
长提示，短生成	7,234	32	3.85 s	~5.26 s	1,877	22.7
中等提示，长生成	1,834	108	1.12 s	~5.74 s	1,639	23.4
长提示，长生成	7,234	124	3.84 s	~9.26 s	1,884	22.9

表 2. 在托管 Nemotron-3-Super-120B-A12B-NVFP4 的本地 vLLM 端点上进行的五场景单 Spark 评估。每行报告预热后三次运行的中位数。

图 6. vLLM 在 DGX Spark 上的单 Spark 评估扫描，显示了 Nemotron-3-Super-120B-A12B-NVFP4 的 TTFT、总延迟、预填充吞吐量和测量的解码吞吐量（22.7–23.7 tok/s 范围）。

评估解读

预填充随提示长度近线性扩展。 当提示长度增加四倍时，TTFT 大约增加三倍。当提示足够大以摊销每个请求的开销时，预填充速率从 140 上升到近 1,900 token/秒。预填充是计算密集型的，并且可以在整个提示上并行化，因此它更直接地受益于可用的 tensor-core 吞吐量。

在这些单 Spark 评估运行中，解码吞吐量保持在 22.7–23.7 tok/s 的狭窄范围内。 判断调用的面向用户延迟比其解码速率更重要，因为它只生成两个 token。解码仍然取决于活跃参数数量、FP4 内核路径、CUDA graph 行为和确切的 vLLM 镜像。将此视为 Nemotron-3-Super 在单个 DGX Spark 上的方案特定结果，而不是 DGX Spark 或 vLLM 的通用上限。

配置说明。 这些测量特定于运行时使用的镜像标签、上下文长度、CUDA graph 状态、后端路径和调度设置。在报告任何重现的评估时，请同时报告这些值。

游戏期间的实时行为。 典型的 20 个问题回合发送大约 1,000 token 的提示（系统提示 + 事实块 + 秘密 + 问题）。端到端感知延迟仍然由 TTFT 和短解码突发主导；对于 5-15 个输出 token，解码在测量的 22.7–23.7 tok/s 范围内大约为 0.2–0.7 秒。KV-cache 利用率在游戏期间很少超过 2%。遥测视图显示 prompt_tps 在每个回合开始后短暂飙升，然后在稳定生成期间 gen_tps 保持在测量的 22.7–23.7 tok/s 范围内，同时答案流式传输。

运维要点

选择正确的模型类别是第一个调整决策：1000-1300 亿 MoE NVFP4 模型非常适合 Spark 的内存容量和活跃参数配置文件，而密集模型通常不太适合交互式本地解码。官方 vLLM 镜像加上经过 Spark 测试的方案可以避免源码构建风险，除非需要自定义内核。--gpu-memory-utilization 应针对统一内存池和共享它的其他进程进行调整。预热 JIT 可以避免将冷启动延迟传递给第一个用户请求。/metrics 暴露了理解负载行为所需的 KV-cache 利用率和 TTFT 直方图。

结论

DGX Spark 是一个用于开发、演示和小批量服务的本地推理系统，其服务配置文件与数据中心 GPU 服务器不同。其统一内存架构、sm_121 目标、模型特定的 FP4 路径和本地解码特性使得工作负载调整尤为重要。通过正确的模型、镜像标签和运行时设置，Spark 为开发者提供了一种在本地服务大型模型的实用方法，同时保留了熟悉的类生产工作流程。

vLLM 是 DGX Spark 的默认选择，因为它将这些选择保留在服务层，同时保留了标准的应用程序接口。一旦模型、镜像标签和标志得到验证，应用程序仍然可以获得 OpenAI 兼容 API、流式传输、连续批处理、分页 KV cache 管理和 Prometheus 指标。

---

由 Inferact 团队在我们办公室持续运行的 Spark 上撰写。