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

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

vLLM 在 NVIDIA DGX Spark 上实现快速、高效的本地推理，弥合了笔记本规模开发与数据中心 GPU 服务之间的差距。通过将兼容 OpenAI 的 API 与先进的内存、批处理和遥测控制相结合，vLLM 使开发者能够在 DGX Spark 独特的硬件架构上本地运行大型 NVFP4 模型。

DGX Spark 架构与内存模型

NVIDIA DGX Spark 基于 GB10 Grace Blackwell SoC 构建，采用统一的 CPU 与 GPU 内存池。这种架构对推理工作负载的配置和执行方式产生了重大影响。

统一内存与模型容量

共享的 CPU/GPU 内存池使开发者能够加载比固定专用 GPU 内存池更大的 NVFP4 模型。根据模型架构和运行时配置，这使得在单个 Spark 上运行参数量高达 2000 亿的模型成为可能。vLLM 使用诸如 --gpu-memory-utilization、--max-model-len 和 --max-num-seqs 等标志来管理此统一池，并结合分页 KV 缓存，以平衡模型规模、上下文长度和并发性。

硬件特定验证

在 DGX Spark 上的部署必须使用针对 sm_121 目标验证的 vLLM 构建、容器镜像标签和运行时设置。从更大 GPU 系统改编的配置应视为内核支持的工程检查清单，而非性能基准。

NVFP4 MoE 优化

DGX Spark 特别适合 NVFP4 Mixture-of-Experts（MoE）服务。NVFP4 减轻了内存压力并提升了预填充行为。约 10-15 亿活跃参数的 MoE 模型非常契合，因为较小的活跃参数集能够优化系统内存带宽上的解码性能。

vLLM 本地服务能力

vLLM 提供了若干关键特性，以优化 DGX Spark 本地小批量推理的表现。

分页 KV 缓存与连续批处理

为避免聊天工作负载中静态批处理的低效，vLLM 使用连续批处理在每个解码步骤接收和驱逐请求。结合分页 KV 缓存，DGX Spark 能够在不产生过度内存碎片的情况下支持多个并行请求。在使用 120B NVFP4 MoE 模型的测试中，KV 缓存利用率对单用户通常保持在 5% 以下，对小批量演示流量则低于 30%。

兼容 OpenAI 的流式传输

Spark 上的 vLLM 端点使用兼容 OpenAI 的 API（例如 http://localhost:8000/v1），可复用现有客户端代码。使用 stream=true 对本地响应性至关重要，它在令牌到达时即时渲染，以最小化聊天、编码和代理工作流中的感知延迟。

通过 Prometheus 进行可观测性

vLLM 的 Prometheus 端点（/metrics）让开发者监控本地设备的健康状态。DGX Spark 的关键信号包括：

  • KV 缓存利用率 (vllm:kv_cache_usage_perc)
  • 提示和生成令牌计数器
  • TTFT（首令牌时间）和令牌间延迟直方图

运行时配置与部署

在 DGX Spark 上成功部署需要将运行时标志与系统的统一内存配置以及特定模型配方相匹配。

模型选择指南

模型选择是主要的性能杠杆。参数量为 100-130B、活跃参数为 10-15B 的 MoE NVFP4 模型最适合 Spark 的内存容量和解码速率。

关键 vllm serve 标志

  • --gpu-memory-utilization：必须进行调优，以在统一内存池中为操作系统、容器运行时和 KV 缓存增长留出余量。
  • --max-model-len 131072：设置最大提示和完成长度。vLLM 基于活跃上下文进行调度，而不是为每个请求预留完整长度。
  • --max-num-seqs 4：保持并发解码流数量低，以防止每令牌带宽费用导致 TTFT 激增。
  • 自动前缀缓存：在 vLLM V1 中默认启用，它在共享相同开头提示的请求之间复用 KV 块，对长系统提示非常有益。

JIT 预热与加载

冷启动延迟是一个重要因素；启动后第一次请求会触发 Inductor 和 FlashInfer 的 JIT 代码生成，对 Nemotron-3-Super 大约需要 25 秒。开发者应在启动时发送一个小的 “ping” 请求以预热内核。此外，虽然初始权重加载可能需要 10-15 分钟，但可以评估 fastsafetensors 或 InstantTensor 等路径以缩短此时间。

本地评估结果：Nemotron-3-Super

在单个 DGX Spark 上对 Nemotron-3-Super-120B-A12B-NVFP4 模型的评估显示，在各种场景下解码吞吐量保持在 22.7–23.7 token/秒 区间。

场景 提示 token 生成 token 首令牌时间 总延迟 预填充 token/秒 解码 token/秒
典型评估调用 58 2 0.42 s ~0.53 s 140 ~23
中等提示，短生成 1,834 32 1.12 s 1.12 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

关键性能洞察

  • 预填充扩展：随着提示变长，预填充吞吐量提升，从 140 增至接近 1,900 token/秒，因为开销在更多 token 上被摊销。
  • 解码稳定性：解码吞吐量保持稳定，无论提示长度如何，受活跃参数数量和 FP4 内核路径决定。
  • TTFT：当提示大小增加四倍时，首令牌时间大约增加三倍。

运营概述

要在 DGX Spark 上优化 vLLM，开发者应优先选择 100-130B MoE NVFP4 模型，使用针对 sm_121 验证的官方 vLLM 镜像，并为统一内存池调优 --gpu-memory-utilization。预热 JIT 并利用 /metrics 端点可确保可预测、交互式的本地推理体验。

Sources