社区实测：双 DGX Spark 跑 Qwen3-Flash-Next，聚合吞吐达 181 tok/s
Reddit 用户用 2× DGX Spark + NVFP4 量化部署 Qwen3-Flash-Next，借助 NVM…
一位 Reddit 用户在 r/LocalLLaMA 板块分享了其在 2 节点 NVIDIA DGX Spark 集群上部署「Qwen3-Flash-Next」的实测结果，宣称聚合吞吐达到 181 tok/s（峰值曾触及 195 tok/s），单流解码则在 30–50 tok/s 区间。该成绩来自约 9 个并发智能体会话共享同一推理引擎，属于多智能体场景下的总产出，而非单用户体感速度。
硬件配置
- 2× NVIDIA DGX Spark，单机搭载 GB10 Grace Blackwell SoC，统一内存 128 GB，CPU 为 20 核 ARM。
- 两节点通过直连 ConnectX-7 缆线互联，NCCL 走 RDMA（RoCE，200 Gb），张量并行度 TP=2 跨两机。
- 作者特别提醒，需要在 NCCL 日志中确认走的是 IB（InfiniBand）路径，而不是回落到 TCP——后者会让速度损失近半。
模型与量化
- 模型为「Qwen3-Flash-Next」，采用 RadixArk 出品的 NVFP4 量化：路由专家 4-bit，n-gram 表保留为 FP8。
- 架构上属于混合注意力：约 3/4 为线性注意力 + 1/4 稀疏全局注意力，激活 512 专家 MoE；并启用 MTP 推测解码 k=3，验收率约 40%。
- 原生上下文 262K，借助 YaRN factor 2.0 拉伸至 512K，作者称已在 487K 深度做 needle 验证。
关键优化：把 47.7 GiB n-gram 表搬到 NVMe
模型附带一张 3.2 亿行的 n-gram 嵌入表，FP8 下占 47.7 GiB，每个 token 只触及约 16 行（≈2.5 KB）。作者没有把它整体加载进内存，而是直接 mmap 到 NVMe 上：单节点权重占用从 65 GiB 降到 41 GiB，省出的内存全部进了 KV 缓存池，最终池容量达 2.89M tokens（约为 5.5 倍完整上下文），固定占用 40.6 GiB。
要让 NVMe 上的 mmap 真正跑得动，作者做了两件事：
- 对映射区调用
madvise(MAD\_V\_RANDOM)，并配合内核预读——一次 405K token 的 prefill 在修复前要从磁盘读 603 GB，修复后只读 19 GB，降幅约 30 倍。 - 启用 64 条 gather 线程分摊缺页延迟，因为瓶颈是缺页串行化而非磁盘带宽。
vLLM 部署要点
使用 vllm/vllm-openai 官方 Day-0 镜像，关键参数如下：
--kv-cache-memory 40600000000：手动 pin KV 池。作者强调，这个参数会忽略--gpu-memory-utilization，应按实测剩余内存设置。--max-num-batched-tokens 8192、--long-prefill-token-threshold 4096：避免冷 prefill 拖垮 decode 延迟。--enforce-eager：必须开启。当前构建在 GB10 / SM121 上 CUDA graph 会崩溃，torch.compileAOT 在 rank 1 直接挂掉。--enable-prefix-caching：在智能体流量下命中率达 99%，是「真实世界单点最大收益」。--speculative-config '{"method":"mtp","num_speculative_tokens":3}'。- 额外补了一个调度补丁：限制并发冷长 prefill 的上限（admission gate），防止 N 个智能体同时 prefill 时统一内存被瞬态吃光。
服务栈与稳定性
- 前端用 llama-swap 做模型热切换（同一时刻只有一个模型驻留），API key 鉴权；外层 nginx 提供 TLS。
- 守门进程只用 earlyoom，并设置绝对内存下限。作者警告：在统一内存机型上，剩余 RAM 低、大模型常驻是常态，按百分比触发的 OOM killer 会误杀健康进程。
评价
该方案在 DGX Spark 这种统一内存、超大 KV 缓存友好但内存又并非无限的平台上，给出了一套相对完整的调优路径：mmap 替代加载、手动 pin KV、关闭 CUDA graph、限制并发 prefill。其中 NVMe mmap n-gram 表 + MADV_RANDOM 的组合，是本帖对类似架构模型推理较有借鉴价值的一条经验。但需注意，所有数字均为单一作者在其自有环境下的口径，且「Qwen3-Flash-Next」这一具体型号命名与官方 Qwen3-Next 系列的公开命名并不完全一致，吞吐数据尚待独立复现验证。