DeepSeek-V4-Flash 在双 DGX Spark 上跑出 75 tok/s：社区实测与排坑全记录

一名社区开发者用两台 NVIDIA DGX Spark 桌面 AI 工作站，通过一根 QSFP DAC 铜缆互联，部署了 DeepSeek-V4-Flash-0731（284B 总参数 / 13B 激活，FP4/FP8 原生权重，上下文 1M）的生产级推理服务。整套脚本、压测数据与环境变量已开源在 GitHub 仓库 raullenchai/twinspark，整体吞吐、单流延迟与长时间上下文稳定性均明显优于单节点方案。

关键性能数字

基于 TP=2、vLLM 0.25 + DSpark 推测解码 + NVFP4 MLA KV 缓存的配置，主要结果如下：

单流推理 74.8 tok/s（真实编码 prompt），推测解码相对带宽上限 27.3 tok/s 提速约 2.74×；
预填充约 1.7–1.9k tok/s，64k prompt 首 token 延迟（TTFT）约 42 秒，长上下文下解码稳定在 50 ms/tok；
KV 容量 2.74M tokens，使 1M 上下文真正可用；
断电重启后约 9 分钟自动恢复服务，零人工介入（自愈容器已实测）。

踩坑与解决方案

仓库 README 列出了完整的 gotcha 表格，以下为几项对部署影响较大的发现：

QSFP 笼位背接双 ConnectX-7 控制器：单根 400G 线缆可激活 2×200G 链路，但每路仅 PCIe Gen5 ×4，单路 RDMA 上限约 109 Gb/s。需通过 NCCL_IB_HCA 同时暴露两条链路，总线带宽可达 21.7 GB/s。
Ray 内存监控误杀 worker：DGX Spark 的 GB10 统一内存使 vLLM 的 GPU 分配计入宿主 RAM，触发 Ray OOM。需设置 RAY_memory_monitor_refresh_ms=0 关闭监测。
中文乱码来自缺失 DSpark 环境变量：并非模型损坏。需配置 VLLM_DSPARK_GPU_REJECTED_CONTEXT_MASK=1 与 VLLM_USE_BREAKABLE_CUDAGRAPH=0；期间 /v1/completions 始终可用，容易误导排查方向。
推测解码在高并发下翻转：单流下 spec7 最佳（74.8 tok/s），4 路并发下 spec3 更优（聚合 105.7 tok/s）；在带工具调用的真实 agent 流量中，draft 接受率从 75% 降到约 40%。仓库同时发布两套启动 profile。
随机 token 基准严重低估推测解码：vllm bench serve --dataset-name random 仅得 33.8 tok/s，而真实 prompt 跑出 74.8，社区对比 Spark 数字时需注意这一偏差。

Codex CLI 集成与 agent 评测

Codex CLI 0.147 已移除 wire_api="chat"，需改用 Responses API（vLLM 0.25 内置 /v1/responses），并通过未公开的 model_catalog_json 注册自定义模型。仓库提供可直接使用的 config 示例。

在更贴近生产的 agent 评测中，Codex 配合该模型在一个 1,831 文件 / 17k 测试的代码库中，端到端完成了一个涉及多文件并发的功能（lazy-load model pool），仅需一轮 CI 报告迭代即可收敛。

环境与版本

当前快照基于 DGX OS 7.2.3、CUDA 13.0、镜像 ghcr.io/anemll/dspark-vllm-gx10:0.1.1（vLLM 0.25.2 + sm_121 内核）以及 Ray 2.57，作者明确版本已固定，后续可能出现漂移；原始 benchmark JSON 同样随仓库公开，便于社区复核。