DeepSeek V4 Flash 刚刚针对您的 2x DGX Spark 进行升级。每秒 66.6 个令牌，在 6 个并发会话下可达 153.7 个令牌/秒。获取更新后的配方。感谢 @anemll 提供新的 baked vLLM 0.25 镜像。→ https://github.com/MiaAI-Lab/DeepSeek-v4-Flash-DSpark-2x-DGX-Spark…

MiaAI-Lab/DeepSeek-v4-Flash-DSpark-2x-DGX-Spark

来源：https://github.com/MiaAI-Lab/DeepSeek-v4-Flash-DSpark-2x-DGX-Spark

DeepSeek V4 Flash DSpark C12 NVFP4 KV on 2x DGX Spark

独立双节点 DGX Spark 配方，用于使用 vLLM TP=2、DSpark 推测解码和 默认 100 万令牌最大模型长度（使用实验性 nvfp4_ds_mla KV 缓存路径）来服务 DeepSeek-V4-Flash-DSpark。

当前运行时（本检出版本）

默认 Docker 镜像是预构建的 Anemll GX10/DGX Spark 移植版 vLLM 0.25，原生支持 DSpark / NVFP4 DS-MLA / b12x MoE：

ghcr.io/anemll/dspark-vllm-gx10:0.1.1

来源：Anemll/dspark-vllm-gx10 (https://github.com/Anemll/dspark-vllm-gx10)。

在两个节点上首次启动前拉取：

docker pull ghcr.io/anemll/dspark-vllm-gx10:0.1.1

docker-compose.dspark.yml 与该镜像布局对齐：

• entrypoint 被清除；命令使用 /usr/local/bin/vllm serve
• CUDA 位于 /usr/local/cuda（非 Stage-C 的 /opt/env）
• --moe-backend flashinfer_b12x
• DSpark 内置于镜像中（没有将 dspark_proposer.py 通过 Stage-C 绑定挂载到 /opt/env/...）
• 可选的 vllm_patch_gb10/ 挂载保留用于实验性混合 NVFP4
• HF 缓存位于 /cache/huggingface；一旦两个节点都有完整的本地 Hub 缓存，建议设置 HF_HUB_OFFLINE=1（在线重新下载可能会填满工作节点磁盘）

备选方案：设置 DSPARK_VLLM_IMAGE=vllm-dspark-runtime:dspark-nvfp4-stage-c 并运行 ./build-dspark-vllm-runtime.sh 以进行历史性的多阶段 Stage-C 叠加构建。Stage-C 配方和叠加源仍位于 recipe/ 下。本仓库仍包含 Keys 的 DSpark 并发补丁和 Stage-C 叠加源，用于本地镜像构建和文档。使用 Anemll 镜像时，该逻辑内置在镜像内部，而不是作为主机绑定挂载。

默认智能体服务配置文件（.env.dspark.example 和 README 默认值）：

• 镜像：ghcr.io/anemll/dspark-vllm-gx10:0.1.1
• 模型：deepseek-ai/DeepSeek-V4-Flash-DSpark（HF Hub ID；当 HF_HUB_OFFLINE=1 时从缓存离线解析）
• max_model_len=1048576（1M — 保持此为文档默认值）
• max_num_seqs=6
• max_num_batched_tokens=8192
• kv_cache_dtype=nvfp4_ds_mla
• gpu_memory_utilization=0.85
• MTP_NUM_TOKENS=3
• API 绑定地址 0.0.0.0:8888

本地 .env.dspark 可以降低 MAX_MODEL_LEN（例如 512000）以适应特定集群，而不改变配方默认值。

此配置文件旨在用于真正的深度上下文智能体服务：MAX_NUM_SEQS=6 时，每个独立会话最多可达 1M 令牌。KV 缓存是一个共享池，因此六个会话不会各自预先保留 1M 令牌。正常的智能体会话可以同时运行，同时保留异常长请求的 1M 上限。

对于长时间编码任务和大提示，请使用：

MAX_MODEL_LEN=1048576
MAX_NUM_SEQS=4
MAX_NUM_BATCHED_TOKENS=16384
GPU_MEMORY_UTILIZATION=0.87

本仓库记录了经过验证的 1M NVFP4 智能体配置文件、历史 Stage-C 检查点以及当前的 Anemll 预构建运行时：

• 默认 max_model_len=1048576（1M），max_num_seqs=6，kv_cache_dtype=nvfp4_ds_mla
• 默认镜像 ghcr.io/anemll/dspark-vllm-gx10:0.1.1（此集群上约 280 万令牌的 KV 池）
• 历史 Stage-C C12 池：3,225,280 个令牌
• 单流解码在验证过的 C12 门控上保持在 50 tok/s 以上
• 确定性直接提示完成，无中文漂移或重复的垃圾内容
• 2/4/6 并发代码门控提示干净完成（Stage-C C12）
• DSpark 并发补丁在 max_model_len=200000，max_num_seqs=16 下验证（静态 C16 315.1 / 交错 C16 205.0 tok/s 聚合）

如果您已经部署了旧版本并看到智能体乱码、循环、中文漂移或提示/工具 XML 泄漏到回复中，请保留 C12 NVFP4 配置文件并在更改智能体框架设置之前验证直接 API 行为。修复路径不是切换到 fp8 或更小的备用模型。

如果直接 vLLM 提示是干净的，但智能体框架仍然乱码，请检查框架会话重放、备用模型列表以及提示/工具 XML 处理，然后再更改 DSpark 权重或回退到 fp8。

结果

实时 Anemll 镜像通道（本检出版本）

在预构建的 Anemll 镜像和本仓库的 compose/start 脚本（TP=2，两个节点）下验证了工作节点优先启动。运行时：

• 镜像：ghcr.io/anemll/dspark-vllm-gx10:0.1.1
• 模型 ID：deepseek-ai/DeepSeek-V4-Flash-DSpark（HF 缓存位于 HF_CACHE）
• 服务模型名称：可通过 SERVED_MODEL_NAME 配置（例如 deepseek-v4-flash）
• kv_cache_dtype=nvfp4_ds_mla
• 默认配方：max_model_len=1048576，max_num_seqs=6，max_num_batched_tokens=8192，gpu_memory_utilization=0.85，MTP_NUM_TOKENS=3
• --moe-backend flashinfer_b12x
• VLLM_USE_FLASHINFER_SAMPLER=1，VLLM_USE_B12X_WO_PROJECTION=1
• 两个节点都有完整的 Hub 缓存后建议设置 HF_HUB_OFFLINE=1
• 网络：显式 VLLM_HOST_IP / WORKER_VLLM_HOST_IP，以及匹配的 NCCL_SOCKET_IFNAME / TP_SOCKET_IFNAME / GLOO_SOCKET_IFNAME

此集群上的启动证据（Anemll 镜像，1M max-model-len 配置文件）：

Available KV cache memory: 19.03 GiB
GPU KV cache size: 2,826,378 tokens
Maximum concurrency for 1,048,576 tokens per request: 2.70x
Application startup complete.

直接 API 冒烟测试：/v1/models HTTP 200 和兼容 OpenAI 的聊天补全在头节点和工作节点等级上返回非空助手内容。

实际解码速度（首个令牌之后）

在实时 Anemll 通道上使用智能体/文件写入提示（max_tokens=512，温度 0，每个请求唯一 nonce，3 次试验，按聚合取中位数）进行流式解码基准测试。预填充和首个令牌被排除。

试验聚合（解码 tok/s）：C1 [66.5, 69.4, 66.6]，C2 [92.1, 95.6, 93.3]，C3 [89.4, 92.8, 93.5]，C4 [129.1, 123.8, 121.7]，C5 [125.0, 121.1, 111.6]，C6 [153.7, 148.8, 157.0]。

聚合解码是首个令牌之后的整体生成；平均流解码是一个并发会话在令牌开始后感受到的速度（单独约 67 tok/s，C=6 时约 27 tok/s）。在多流争用下，C3 ≈ C2，C5 ≈ C4（聚合），而单流解码下降。

2026-07-02 Keys C12 NVFP4 检查点（历史 Stage C）

之前在 Tony 的 Stage C NVFP4 镜像上使用 Keys 的 C12 服务配置文件的高并发通道（保留用于比较；不是当前默认镜像）。运行时：

• 测试端点：http://100.90.25.78:8888/v1
• 服务模型：deepseek-v4-flash-dspark
• 镜像：vllm-dspark-runtime:dspark-nvfp4-stage-c
• 模型路径：/cache/huggingface/fraserprice/DeepSeek-V4-Flash-DSpark
• kv_cache_dtype=nvfp4_ds_mla
• max_model_len=1048576
• max_num_seqs=6
• max_num_batched_tokens=8192
• gpu_memory_utilization=0.85
• MTP_NUM_TOKENS=3
• VLLM_USE_FLASHINFER_SAMPLER=1
• VLLM_USE_B12X_WO_PROJECTION=1
• VLLM_DSPARK_GPU_REJECTED_CONTEXT_MASK=1
• thinking=false
• --generation-config vllm
• 无 --override-generation-config

启动证据：

GPU KV cache size: 3,225,280 tokens
Maximum concurrency for 1,000,000 tokens per request: ~3.2x
Application startup complete.

代码门控验证：

此次运行的上游检查点说明未导入本检出版本；本仓库保留运行时更改和验证摘要，但没有上游基准测试工件文件夹。不要在此 Stage C 镜像上启用 VLLM_USE_B12X_FP8_GEMM=1。该标志在测试中遇到了 DeepGEMM 布局断言，导致 DSpark 起草器预热期间出错。

2026-06-30 干净智能体服务检查点

先前的保守干净端点在 Asusi/Spark4 上重现，然后将模型发送回 Hermes/OpenClaw 风格的框架。运行时：

• 测试端点：http://100.90.25.78:8888/v1
• 服务模型：deepseek-v4-flash-dspark
• 该通道上使用的镜像：vllm-dspark-runtime:mia-raf-pr1-nvfp4-keys-c
• 模型路径：/cache/huggingface/fraserprice/DeepSeek-V4-Flash-DSpark
• kv_cache_dtype=nvfp4_ds_mla
• max_model_len=1048576
• max_num_seqs=6
• max_num_batched_tokens=8192
• gpu_memory_utilization=0.80
• MTP_NUM_TOKENS=5
• thinking=false
• --generation-config vllm
• --override-generation-config '{"temperature":0.0,"top_p":1.0}'
• 显式的每个节点 VLLM_HOST_IP 值

启动证据：

GPU KV cache size: 1,990,142 tokens
Maximum concurrency for 1,048,576 tokens per request: 1.90x
Application startup complete.

直接验证：

• /v1/models 报告 "max_model_len": 1048576
• 确定性 sanity 提示返回 NVFP4 DSPARK OK
• 五个更长的英文提示完成，无中日韩漂移，无重复垃圾内容
• 代码门控服务器解码平均值：54.22 tok/s
• 2/4/6 并发直接提示全部成功且干净

并发数：

此次运行的上游检查点说明未导入本检出版本。

1M NVFP4 配置文件验证

在 2x DGX Spark 上验证，每个节点一个 GPU，TP=2，单流。

启动日志报告：

GPU KV cache size: 2,044,166 tokens
Maximum concurrency for 1,048,576 tokens per request: 1.95x

API 报告：

{"max_model_len":1048576}

此次运行的上游检查点说明未导入本检出版本。

DSpark 并发配置文件验证

在相同的 2x DGX Spark TP=2 部署上验证，使用 Keys 的 DSpark 并发补丁，kv_cache_dtype=nvfp4_ds_mla，max_model_len=200000，max_num_seqs=16，MTP_NUM_TOKENS=5，以及 VLLM_DSPARK_GPU_REJECTED_CONTEXT_MASK=1。补丁来源：

• drowzeys/Keys-Concurrency-Patch-for-DSpark-DeepSeek-V4-Flash (https://github.com/drowzeys/Keys-Concurrency-Patch-for-DSpark-DeepSeek-V4-Flash)
• 测试的补丁提交：7e4d94bbcec95223550517c0fa9244e59f9f6483

此处记录的实时修复保持 kv_cache_dtype=nvfp4_ds_mla，并用该提交中路径调整后的 Patch 2b 更新本仓库已内置的 Keys 叠加层。在 Patch 2b 中，不规则的 query_start_loc 检测不再依赖 num_rejected_tokens_gpu。仅在内置 OpenAI 兼容聊天冒烟请求和智能体客户端验证都通过后，才应将服务视为已验证。

静态同步批次，一个 TP=2 副本：

交错独立到达，一个 TP=2 副本：

正确性 sanity 检查：确定性受害者输出在波动期间保持字节一致。一个中等波动压缩测试测量到在波动窗口内接受率为 0.529，速度为 99.7 tok/s。此次运行的上游检查点说明未导入本检出版本。

历史 60 tok/s DSpark 基线

较早的约 60 tok/s 数字已被重现，但它是独立的诊断配置文件，不是本仓库默认的 1M NVFP4 部署：

• 从 rafaelcaricio/vllm#1 提交 3519c3b88 重建镜像
• max_model_len=262144
• max_num_seqs=1
• kv_cache_dtype=fp8
• MTP_NUM_TOKENS=5
• thinking=false
• temperature=0.0，top_p=1.0
• 在 code_completion 门控上测得 63.97 tok/s，DSpark 接受率为 67.9%

使用此来诊断镜像/运行时漂移。不要将其与生产 1M NVFP4 路径混淆。此次运行的上游检查点说明未导入本检出版本。

2026-06-29 完整 1M 并发微基准测试

上面的 200K/16 配置文件最大化原始并发性。对于想要完整 1M 上下文上限且同时有并发性的智能体集群，运行 max_model_len=1048576 且 max_num_seqs=6。每个请求仍可以增长到 1M，同时最多 6 个会话同时运行，因为共享的 KV 池（而不是按槽位的预留）才是真正的限制（参见 KV 缓存如何工作）。

已在 2026-06-29 代码完成微基准测试部署（NVFP4，max_model_len=1048576，max_num_seqs=6，VLLM_DSPARK_GPU_REJECTED_CONTEXT_MASK=1，VLLM_USE_B12X_WO_PROJECTION=1）上验证：

• 启动：GPU KV cache size: 1,901,239 tokens，Maximum concurrency for 1,048,576 tokens per request: 1.81x
• 6 个并发请求：6/6 成功，约 182 tok/s 聚合（约 30 tok/s 每流），无 OOM / 无抢占失败
• 同一配置文件上的单流解码：约 67 tok/s（代码）

当大多数会话远低于 1M（典型智能体轮次）但您仍希望保留 1M 上限时，这是正确的形态。上面较新的 2026-06-30 智能体稳定性检查点是更安全的数字，用于 Hermes/OpenClaw 框架验证。

更高的并发性并非免费：在持续压力下，您可能会看到额外的调度器抖动、预填充争用和 KV 碎片化。1M/6 已针对正常长度的智能体流量验证；对于压力下的保证深度上下文工作，1M/2 是保守的，500K/4 是平衡的中间值。

KV 缓存如何工作（为什么 1M + 并发是安全的）

max_model_len 和 max_num_seqs 是上限，而非预留。真正的限制是所有活动请求中存活令牌的总和，必须能够放入共享的 KV 池。 三个独立的旋钮，经常混淆：

池是共享的并按需分配：PagedAttention 在请求生成令牌时分配 KV 块给每个请求，在请求完成时释放它们。max_model_len 和 max_num_seqs 是上限，而非预留——vLLM 不会预先分配 max_num_seqs × max_model_len 的 KV。所以真正的约束是：

所有活动请求的存活令牌总和 <= KV 池

在 1M 上限 / 6 槽位下的示例：

6 个请求 x 5 万令牌 = 30 万：轻松容纳
6 个请求 x 20 万令牌 = 120 万：适合 Anemll / C12 池
6 个请求 x 50 万令牌 = 300 万：接近池容量（取决于镜像）
3 个请求 x 100 万令牌 = 300 万：接近池容量（取决于镜像）