Qwen3.8-Flash-Next NVFP4 在双DGX Spark上的配置：解码速度50t/s，预填充速度2,900t/s

折腾了几天后，这是我目前的配置，希望能帮助到其他人。其中一些内容对单个Spark也有价值。基准测试：双Spark TP2，eager + MTP k=3，262k上下文（预热中位数，精确分词器计数）： ┌─────────┬──────────────────┬───────────────────┬─────────────────────────────────┐ │ 流数量 │ 解码总速度 │ 解码单流速度 │ 预填充总速度（10k提示） │ ├─────────┼──────────────────┼───────────────────┼─────────────────────────────────┤ │ 1 │ 45.9 t/s │ 45.9 t/s │ 2,940 t/s │ ├─────────┼──────────────────┼───────────────────┼─────────────────────────────────┤ │ 4 │ 120.2 t/s │ 30.0 t/s │ 2,524 t/s │ ├─────────┼──────────────────┼───────────────────┼─────────────────────────────────┤ │ 8 │ 222.2 t/s │ 27.8 t/s │ 3,098 t/s │ ├─────────┼──────────────────┼───────────────────┼─────────────────────────────────┤ │ 13 │ 265.9 t/s │ 20.5 t/s │ 2,960 t/s │ └─────────┴──────────────────┴───────────────────┴─────────────────────────────────┘ 预填充与提示深度对比（单流，精确令牌）： ┌─────────────┬───────────┐ │ 提示大小 │ 预填充速度│ ├─────────────┼───────────┤ │ 11k │ 2,875 t/s │ ├─────────────┼───────────┤ │ 100k │ 2,655 t/s │ ├─────────────┼───────────┤ │ 200k │ 2,463 t/s │ └─────────────┴───────────┘ 以下是一些AI生成的废话，供你阅读并粘贴到你自己的代理中 :) 技术栈 vLLM PR #53896（release/qwen38next分支）——不是main分支；main分支没有该模型，且配方镜像的vLLM提交不在公共仓库中 sm_121支持是一个2文件补丁（详情见下文）——GB10是架构12.1，NVFP4 E2M1转换需要软件回退 PLE n-gram表通过mmap从内部NVMe提供（48 GB，MADV_RANDOM是必须的——在哈希分散的行查找中，读取放大相差30倍），并有一个节点本地CPU工作者进程通过ZMQ + 固定缓冲区 + CUDA-IPC输出进行收集，使收集在图安全且TP2安全 跨双Spark的TP2：原生venv（不是docker——见死胡同），eager + MTP k=3 数字（TP2，预热中位数，结构化计数-20 / 3段散文）： 配置结构化散文预填充（11k令牌）eager + MTP k=3 49.7 34.8 ~2,875 死胡同 分段图在MTP+TP2下成本约28%的解码。相同的树，相同的条件，开启与关闭图：36 vs 50 tok/s。图对单节点无MTP解码有帮助（+80%，9→16.5），但与MTP在TP2结合时是纯粹的损失——MTP已经摊销了图所消除的启动开销。我们追踪了一天的“树级MTP回归”，才意识到配置本身就是回归。 Docker静默地将NCCL降级为TCP套接字。默认容器没有IB设备 → NET/Socket → TP2预填充速度约为原生的40%。你需要--privileged（或IB设备直通）以及正确的HCA名称——见下一点。 原生venv运行只获取RoCE。RoCE设备名称在重启后不稳定，并且在两个相同机器之间可能不同（我们的：一个是rocep1s0f1，另一个是rocep1s0f0，动态解析）。硬编码NCCL_IB_HCA会在一个节点上静默失败。用ibdev2netdev枚举，匹配port-ACTIVE到你的轨道netdev，并用NCCL_DEBUG=INFO验证你看到NET/IB，而不是NET/Socket。 flashinfer在GB10上必须是0.6.18——0.6.17会崩溃NVFP4 MoE回退内核。 vLLM的MoE shuffleInputRowsKernel有一个未初始化排列的越界读取，显示为假CUTLASS status=7 GEMM失败——一个两行边界保护修复它（已在PR #53896中）。 2文件sm_121补丁（相对于PR #53896基础）： CMakeLists.txt：将12.1添加到CUDA_SUPPORTED_ARCHS、SCALED_MM_ARCHS、CUTLASS_MOE_DATA_ARCHS、FP4_SM120_ARCHS csrc/libtorch_stable/quantization/fp4/nvfp4_utils.cuh：约90行软件E2M1转换，由__CUDA_ARCH__ == 1210保护（GB10没有cvt.rn.satfinite.e2m1x2.f32） 这就是完整的差异。离线构建，使用通常的依赖缓存；CUDA架构121。 启动命令： 头部节点（rank 0）： export VLLM_PLE_MMAP=1 VLLM_PLE_MMAP_WORKERS=64 VLLM_PLE_MMAP_PREWARM=1 export VLLM_PLE_MMAP_DIR=$HOME/ple-table # 表的内部NVMe副本 export VLLM_PLE_CPU_OFFLOAD=1 # 激活IPC CPU工作者收集路径 export NCCL_SOCKET_IFNAME=<your-rail-if> # 仅引导；NCCL自行找到RoCE export GLOO_SOCKET_IFNAME=<your-rail-if> python -m vllm.entrypoints.openai.api_server \ --model <path-to-qwen38-flashnext-nvfp4> \ --host 0.0.0.0 --port 8086 --load-format safetensors \ --tensor-parallel-size 2 --nnodes 2 --node-rank 0 \ --master-addr <head-rail-ip> --master-port 29511 \ --distributed-executor-backend mp \ --max-model-len 262144 --max-num-seqs 13 --gpu-memory-utilization 0.85 \ --no-enable-prefix-caching --enable-chunked-prefill --max-num-batched-tokens 8192 \ --long-prefill-token-threshold 4096 --enforce-eager \ --enable-auto-tool-choice --tool-call-parser qwen3_xml --reasoning-parser qwen3 \ --speculative-config '{"method":"mtp","num_speculative_tokens":3}' 工作节点（rank 1）：相同，但--node-rank 1 --headless，在头部节点后约30秒启动。 注意--enforce-eager——这不是妥协，而是快速路径（见死胡同#1）。