在 DGX Spark 上运行 vLLM：架构、配置与本地评估
NVIDIA DGX Spark 是一款桌面级 GB10 系统，旨在本地运行大模型推理，填补了笔记本电脑级开发与数据中心 GPU 服务之间的空白。vLLM 为 DGX Spark 提供了快速、高效的本地推理端点：它将兼容 OpenAI 的 API 与在本地运行大型 NVFP4 模型所需的内存、批处理、KV 缓存及遥测控制结合在一起。本文介绍了 vLLM 如何适配 DGX Spark 架构：包括模型选择、运行时标志位、统一内存行为、OpenAI 兼容服务、Prometheus 遥测，以及基于 Nemotron-3-Super 部署的本地评估结果。
技术摘要
- vLLM 为 DGX Spark 提供了快速、高效的本地推理端点。它将兼容 OpenAI 的 API 与本地运行大型 NVFP4 模型所需的内存、批处理、KV 缓存及遥测控制结合在一起。当前的 Nemotron-3-Super DGX Spark 方案使用 vLLM 的官方 OpenAI 兼容服务器镜像以及针对 DGX Spark 的特定运行时标志位，为开发者提供了从模型下载到本地服务的验证路径。
- DGX Spark 的架构决定了服务配置。
sm_121消费级 Blackwell 芯片、统一的 CPU 和 GPU 内存池以及 Spark 的内存带宽，使得连续批处理（Continuous Batching）、分页 KV 缓存、NVFP4 内核以及 Prometheus 遥测变得尤为重要。 - vLLM 运行时标志位应匹配 DGX Spark 的统一内存配置文件。Spark 的 CPU、GPU、操作系统、容器运行时、模型权重和 KV 缓存共享一个 128 GB 的内存池，因此服务标志位必须为系统其他部分留出余量。
--gpu-memory-utilization应为操作系统、容器运行时和 KV 缓存的增长在统一内存池中预留空间。--max-num-seqs应保持在较低水平，因为 DGX Spark 更适合小规模批处理推理，而非高并发服务。 - vLLM 在 DGX Spark 上的性能高度依赖于开发者的目标。除非特定部署有禁用的理由，否则当前的 vLLM 构建版本应默认使用 CUDA 图（CUDA Graphs）。通过较新的 FP4 内核、异步调度和 MTP 推测解码，调优设置可以提高吞吐量，但内核选择是模型和版本特定的。
DGX Spark 架构与内存模型
DGX Spark 构建在 GB10 Grace Blackwell SoC 之上，具有统一的 CPU+GPU 内存池。Spark 的芯片设计和系统封装定义了最适合其运行的推理工作负载。以下三个属性至关重要，它们共同决定了本文后续部分中的引擎和配置选择。
统一内存扩展了开发者本地可处理的模型规模。DGX Spark 的共享 CPU/GPU 内存池使开发者能够利用比固定专用 GPU 内存池更多的系统内存进行推理，从而根据模型架构和运行时配置，在单台 Spark 上加载高达 2000 亿参数的大型 NVFP4 模型变得切实可行。vLLM 非常契合这种架构，因为它提供了诸如 --gpu-memory-utilization、--max-model-len、--max-num-seqs 和分页 KV 缓存等控制手段，帮助开发者在统一内存池内平衡模型规模、上下文长度和并发量。对于更大规模的部署，多 Spark 配置可以通过 ConnectX 网络接口的低延迟和高带宽，进一步扩展此能力，支持跨系统的高效分布式推理。
针对 Spark 的 sm_121 验证。对于 DGX Spark 部署，开发者应使用专门针对 sm_121 验证过的 vLLM 构建、容器镜像标签和运行时设置。如果您正在从更大的 GPU 系统移植 vLLM 配置，请将其作为内核支持和内存行为的工程核对清单，而不是将其视为 Spark 的性能预期。
DGX Spark 非常适合 NVFP4 MoE 推理。NVFP4 通过减少内存压力和改善预填充/模型拟合行为提供了最大的实际优势，而解码速度仍受活动参数数量和当前 vLLM 构建所使用内核路径的影响。在 NVFP4 中具有约 10-150 亿活动参数的混合专家模型（MoE）非常匹配，因为活动参数集较小，且较新的混合精度和 FP4 内核路径不断提升了解码性能。
DGX Spark 最适合被视为用于大型 NVFP4 模型的本地单用户或小批量推理目标。密集模型和高并发服务虽然可以运行，但它们与该系统的内存带宽和统一内存特性匹配度较低。
适用于 DGX Spark 的 vLLM 功能
在 DGX Spark 上运行 vLLM 需要专注于本地单 Spark 的小批量推理，以及多 Spark 互联时的多节点扩展。最相关的功能包括内存高效的 KV 缓存管理、动态请求调度、OpenAI 兼容服务、运维指标以及感知架构的镜像/运行时支持。
用于 Spark 统一内存预算的分页 KV 缓存
传统的推理批处理模式按照到达时间对请求进行分组，并按步同步运行。这适用于固定长度的补全任务，但对于聊天工作负载效率较低，因为可能一个请求在 5 个 Token 时完成，而另一个则需要生成数百个。vLLM 的连续批处理在每个解码步骤都会接纳和剔除请求，因此 GPU 无需等待静态批次中的最长请求。结合分页 KV 缓存，Spark 的内存预算可以在不产生过度碎片的情况下支持合理数量的并发请求。在实际运行 120B NVFP4 MoE 的 Spark 上，单用户测试期间 KV 缓存利用率通常保持在 5% 以下，而在小批量演示流量下保持在 30% 以下。
支持本地 Spark 端点的 OpenAI 兼容流式传输
在 Spark 上，OpenAI 兼容 API 的重点不在于框架核对清单，而在于简化本地应用。与托管的 OpenAI 兼容端点对话的同一客户端代码，可以指向本地 vLLM 端点，例如 https://:8000/v1。
流式传输是让 DGX Spark 在本地推理中感觉响应灵敏的关键。虽然数据中心 GPU 可能提供更高的解码吞吐量，但 stream=true 允许应用程序在 Token 到达时即时呈现，使用户获得即时反馈，并在桌面系统上创造自然的交互体验。这使得 Spark 成为聊天、编码和代理工作流的实用本地端点，在这些场景中，感知延迟与总生成时间同样重要。
通过 Prometheus 进行 Spark 服务指标监控
在单台 Spark 上，可观测性意味着确认该设备表现得像一个交互式本地设备：提示词预填充迅速，解码保持稳定，并且统一内存池有足够的余量。vLLM 的 Prometheus 端点无需添加额外服务即可暴露这些信号。在演示过程中，侧面的遥测视图可以从同一机器轮询 /metrics。
最有用的 DGX Spark 信号包括 KV 缓存利用率（vllm:kv_cache_usage_perc）、提示词和生成 Token 计数器，以及首字延迟（TTFT）/ Token 间延迟直方图。在健康交互式代理运行中，由于代理读取系统提示词，提示词处理在开始时需要时间。在后续轮次中，KV 缓存持续增长，但当前一轮对话前缀被缓存时，提示词处理时间不应激增。生成吞吐量和 Token 间延迟趋向于预期的解码速率。虽然 KV 缓存利用率在增长，但总体的 KV 缓存保持在足够低的水平，使系统不会内存不足。最终，代理应用程序可以在 KV 缓存用量接近上下文限制之前压缩对话。
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 命令行参考 和 vLLM Docker 文档，以确认您所安装版本中的确切标志位和镜像行为。对于应用程序集成和生产可见性，请参考 OpenAI 兼容服务器文档 和 vLLM 生产指标文档。NVIDIA Spark 指南仍然是关于 DGX Spark 特定模型方案、解析器插件和内核设置的事实来源。
模型选择
在进行标志位调优之前，模型选择是 Spark 上最大的性能杠杆。图 3 是方向性的模型选择指南，而非性能表：它总结了代表性模型类别通常如何映射到 Spark 的内存容量、活动参数数量和本地交互式服务配置文件。
Nemotron-3-Super-120B-A12B-NVFP4 是下文中的具体工作示例，因为它是一款非常适合 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 缓存增长以及任何触及相同内存的其他进程留出空间。从模型方案开始设置，然后根据观察到的内存余量和工作负载并发情况进行调优。
--max-model-len 131072。 服务器接受的最大提示词+补全长度。现代推理服务需要 131K，因为系统提示词、工具模式、文件和历史记录很容易超过 20K 个 Token。您可以将其提高到模型支持的最大值，或为了受限的演示降低它，但不应将其视为每个在途请求的固定最坏情况 KV 预留；vLLM 是根据运行中请求实际使用的上下文进行调度的。
--max-num-seqs 4。 vLLM 将接纳的最大在途序列数。对于 Spark 上的 Nemotron NVFP4，当前的方案将其保持在较低水平。超过 4 个并发解码流，每个 Token 的带宽开销可能会超过连续批处理带来的收益，并导致首字延迟（TTFT）激增。
自动前缀缓存。 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 缓存的内存压力，但可能会影响模型的可预测性，并在 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 指南建议的要强大。如果您打算固定后端，请优先使用诸如 --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，执行与实际工作负载相同的客户端路径（相同的模型，相同的 chat_template_kwargs，仅设置 max_tokens=3）。一旦相关内核预热完毕，在我们设置中，相同的简短路径返回时间可控制在 0.5 秒以内。
初始权重加载与请求预热是两个独立的问题。如果 10-15 分钟的 Safetensor 加载时间对您的部署很重要，请对照您的确切模型、镜像和存储栈，评估 vLLM 的 fastsafetensors 或 InstantTensor 加载路径。
可预测性与吞吐量调优
Spark vLLM 配置可以针对简单的演示操作或最大吞吐量进行调优。
对于本文中的测量，未设置 --kv-cache-dtype，禁用了推测解码，并启用了 CUDA 图。请将这些视为针对此模型、镜像和工作负载的测量方案选择，而非通用的 Spark 默认值。面向吞吐量的运行可以评估 FP8 KV 缓存、异步调度、推测解码和显式后端选择，但这些设置应针对确切的模型、提示词形状、批处理模式和 vLLM 版本进行验证。
正确的调优点取决于工作负载。在这里，我们针对面向公众的演示路径进行优化：可预测的本地服务、清晰的遥测和稳定的响应。
工作负载示例：vllm-spark-game
为了测试简单的 curl 调用之外的配置，我们构建了 vllm-spark-game。该游戏在本地 vLLM 端点上运行 20 个问题的实时互动，同时一个配套的统计视图从同一 Spark 轮询 vLLM 和 GPU 遥测数据。该工作负载的目的在于端到端练习服务路径：OpenAI 兼容聊天请求、流式响应、提示词预填充、解码、KV 缓存行为和实时指标。源代码布局和运行命令请参考 项目 README。
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 https://:8000/v1/models | jq -r '.data[0].id' 验证就绪状态；该命令应返回 nemotron-3-super。
部署形态
单 Spark 评估结果
我们针对在单台 DGX Spark 上托管 Nemotron-3-Super-120B-A12B-NVFP4 的本地 vLLM OpenAI 兼容端点运行了一个面向应用程序的五个场景评估。这些数字旨在使部署方法具体化，而非作为排行榜提交。在我们更新的单 Spark 评估中，测量到的解码吞吐量在各场景下均保持在 22.7-23.7 tok/s 的范围内。每一行都是一次预热调用后三次运行的中位数。确切的 Token 计数来自 stream_options.include_usage，而非块计数。
| 场景 | 提示词 Tok | 生成 Tok | TTFT | 总延迟 | 预填充 Tok/s | 解码 Tok/s |
|---|---|---|---|---|---|---|
| 典型判定调用 (真实 20Q, 嘈杂 2-Token 生成) | 58 | 2 | 0.42 秒 | ~0.53 秒 | 140 | ~23 |
| 中等提示词, 短生成 | 1,834 | 32 | 1.12 秒 | ~2.47 秒 | 1,636 | 23.7 |
| 长提示词, 短生成 | 7,234 | 32 | 3.85 秒 | ~5.26 秒 | 1,877 | 22.7 |
| 中等提示词, 长生成 | 1,834 | 108 | 1.12 秒 | ~5.74 秒 | 1,639 | 23.4 |
| 长提示词, 长生成 | 7,234 | 124 | 3.84 秒 | ~9.26 秒 | 1,884 | 22.9 |
表 2. 托管 Nemotron-3-Super-120B-A12B-NVFP4 的本地 vLLM 端点上的五场景单 Spark 评估。每行报告预热后三次运行的中位数。
评估解读
预填充随提示词长度近乎线性扩展。当提示词增长四倍时，TTFT 大约增加三倍。随着提示词足够长以分摊每个请求的开销，预填充速率从 140 爬升至接近每秒 1,900 个 Token。预填充是计算密集型且可在整个提示词中并行化，因此它直接受益于可用的张量核心吞吐量。
解码吞吐量在这些单 Spark 评估运行中保持在 22.7–23.7 tok/s 的狭窄范围内。判定调用的用户感知延迟比其解码速率更重要，因为它仅生成两个 Token。解码仍然取决于活动参数数量、FP4 内核路径、CUDA 图行为以及确切的 vLLM 镜像。请将其视为在单台 DGX Spark 上运行 Nemotron-3-Super 的特定方案结果，而非 DGX Spark 或 vLLM 的通用上限。
配置说明。这些测量结果特定于运行所使用的镜像标签、上下文长度、CUDA 图状态、后端路径和调度设置。在引用任何复现评估时，请同时报告这些值。
游戏过程中的实时行为。一个典型的 20 个问题轮次会发送大约 1,000 个 Token 的提示词（系统提示词 + 事实块 + 秘密 + 问题）。端到端的感知延迟仍然由 TTFT 和短暂的解码爆发所主导；对于 5–15 个输出 Token，解码时间在测得的 22.7–23.7 tok/s 频带内约为 0.2–0.7 秒。在游戏过程中，KV 缓存利用率很少超过 2%。遥测视图显示，每一轮开始后 prompt_tps 会短暂激增，然后当答案流式传输时，gen_tps 会保持在 22.7–23.7 tok/s 的范围内。
运维要点
选择合适的模型类别是第一个调优决定：100-130B 参数的 MoE NVFP4 模型与 Spark 的内存容量和活动参数配置非常匹配，而密集模型通常与交互式本地解码的适配度较低。使用官方 vLLM 镜像加 Spark 测试方案可避免源代码构建风险，除非需要自定义内核。--gpu-memory-utilization 应针对统一内存池和共享它的其他进程进行调优。预热 JIT 可避免将冷启动延迟带给第一个用户请求。/metrics 暴露了理解负载行为所需的 KV 缓存利用率和 TTFT 直方图。
总结
DGX Spark 是用于开发、演示和小批量服务的本地推理系统，其服务配置文件与数据中心 GPU 服务器不同。其统一内存架构、sm_121 目标、模型特定的 FP4 路径以及本地解码特性，使得工作负载调优尤为重要。有了合适的模型、镜像标签和运行时设置，Spark 为开发者提供了一种在本地运行大型模型的实用方式，同时保留了熟悉的类生产工作流。
vLLM 非常适合 DGX Spark，因为它在服务层保留了这些选择，同时维护了标准应用程序接口。一旦模型、镜像标签和标志位经过验证，应用程序仍可获得 OpenAI 兼容 API、流式传输、连续批处理、分页 KV 缓存管理和 Prometheus 指标。
由 Inferact 团队在办公室运行的 Spark 系统上撰写。