/tags/nvidia/ Recent content in NVIDIA on Hugo -- gohugo.io en Fri, 17 Apr 2026 18:00:00 +0800 /posts/qwen36-vllm-gateway-benchmark/ Fri, 17 Apr 2026 18:00:00 +0800 /posts/qwen36-vllm-gateway-benchmark/ TL;DR 两台 DGX Spark 各自独立运行 vLLM 推理 Qwen3.6-35B-A3B-FP8，前置一层 FastAPI 写的 LLM Gateway 做路由/负载均衡，实测结果： 单请求解码吞吐：机器本地 curl 稳定在 ~50 tok/s，客户端经 Tailscale 访问约 ~45 tok/s（差的是网络往返时间） Gateway 代理开销：serial 场景下相对直连差异 <5%，几乎无额外开销 单机并发饱和点：N≈8 时单机聚合吞吐 ~300 tok/s（6× 单流） 双机聚合上限：经 Gateway round-robin 在 N=16 下 ~485 tok/s，接近这组测试里两台机器各自饱和时的合计 结论：在这组测试里，如果想更充分地利用两台机器，还是要走 Gateway，且客户端并发度也要跟上；低并发时 Gateway 与直连差异不大。 环境背景 两台机器都是 NVIDIA DGX Spark，GB10 Grace Blackwell Superchip + 128GB LPDDR5X 统一内存。通过 Tailscale 组网，内部 200-subnet 做机器间低延迟直连： ┌──────────────────────────────────────────────────────────┐ │ DGX Spark 集群 │ │ │ │ Server 1 (100. /posts/bifrost-load-balancing-dgx-spark/ Tue, 14 Apr 2026 11:30:00 +0800 /posts/bifrost-load-balancing-dgx-spark/ TL;DR 将两台 DGX Spark 从 vLLM TP=2 跨节点部署（RPC 超时、频繁崩溃）迁移到 每台独立运行 vLLM + Bifrost 负载均衡网关后： ✅ 稳定性：至少在这轮测试里没有再复现崩溃，P95 延迟大约在 1,400ms（20 tokens） ✅ 吞吐：单机 ~15 tok/s，双机并发 ~56 tok/s（Bifrost 开销 <1ms） ✅ 可用性：双机独立 + 自动故障转移，不再有单点故障 ✅ 可扩展：水平加节点即可，不受 TP 上限约束 背景：为什么放弃 TP=2 跨节点 之前的实践中，我在两台 DGX Spark 上尝试了 vLLM 的 TP=2（跨节点张量并行）部署： 《vLLM TP=2 跨节点部署实践》 《Nemotron EP2 vs TP2：两台 DGX Spark 的实际对比》 这次测试里最直接的观察是：TP=2 跨节点能跑通但不稳定，日志里反复出现： TimeoutError: RPC call to sample_tokens timed out. No available shared memory broadcast block found in 60 seconds. /posts/nemotron-ep2-dgx-spark/ Tue, 14 Apr 2026 02:10:00 +0800 /posts/nemotron-ep2-dgx-spark/ 结论先行 在同一份 Nemotron 3 Super 120B A12B NVFP4、同一镜像、同一保守 profile 下，我这轮测试里 TP2 明显好于 EP2。 我这里做的是 clean-room 对比：清掉两台机器上所有其他 vLLM 实例后，分别跑 EP2 和 TP2，再额外用 max_tokens=32 做一次长输出探针。 测试条件 镜像：vllm/vllm-openai:gemma4-cu130 模型目录：/home/admin/models/NVIDIA-Nemotron-3-Super-120B-A12B-NVFP4-aria2 公共参数：gpu_memory_utilization=0.75、max_model_len=32768、kv_cache_dtype=fp8、quantization=fp4、mamba-ssm-cache-dtype=float32 EP2：TP=1 + DP=2 + --enable-expert-parallel TP2：tensor-parallel-size=2 结果对比 拓扑 短输出 benchmark 成功数 成功 case 平均 tok/s 最慢 case 延迟 32-token 探针 结论 EP2 TP=1 + DP=2 + --enable-expert-parallel 2/4 2.44 301.64 s 第 3 个 case 即把服务打死，后续探针 connection refused 可启动，但不稳定 TP2 tensor-parallel-size=2 4/4 4.68 23. /posts/dgx-spark-benchmark-2026/ Sun, 12 Apr 2026 10:00:00 +0800 /posts/dgx-spark-benchmark-2026/ 概述 本文记录在两台 DGX Spark 上首次以 vLLM TP=2（跨节点张量并行）方式部署 Qwen3.5-35B-A3B 的完整过程。这次实验先得到几条比较初步的观察： TP=2 跨节点推理可以跑通，短请求成功完成 成功样本吞吐约 21–31 tok/s，与单机 TP=1（~29 tok/s）基本持平 稳定性不足：代码生成 case 在约 300 秒后返回 HTTP 500 按这轮实验结果看，如果是追求更稳妥的生产方案，我目前更倾向于两台节点各自独立运行 TP=1，再通过 LiteLLM / Nginx 做负载均衡 技术背景 DGX Spark 与统一内存 DGX Spark 搭载 NVIDIA GB10 Grace Blackwell Superchip，其关键特征是 128GB LPDDR5X 统一内存（CPU+GPU 共享），带宽 273 GB/s。 与独立显存的传统 GPU 不同，统一内存没有独立的 VRAM 分区。这意味着： --gpu-memory-utilization 不能像常规设置那样给到 0.9，需要保守设为 0.7，为内存碎片留出余量 按我这轮实验里的环境约束，最好关闭 swap，否则系统在内存压力下很容易出现明显卡顿甚至失去响应 模型权重、KV cache、推理中间态都在同一块 128GB 池子里分配 vLLM 与 Tensor Parallel vLLM 是一个高性能 LLM 推理引擎，提供 OpenAI 兼容 API、PagedAttention 显存管理、持续批处理等特性。它原生支持 Tensor Parallel（张量并行）：将模型的计算图按张量维度切分到多个 GPU 上执行，各 GPU 之间通过 NCCL（NVIDIA GPU 间通信库）进行 all-reduce 通信同步中间结果。