拥有太多 GPU 的律师,第 3 部分:在 2 台 DGX Spark + 一台老旧的 3090 主机上运行 DeepSeek-V4.1-Flash。上下文长度达 256K 时,预填充速度超过 2,600 tok/s,结构化输出速度达 322 tok/s,完整技术栈和原始数据均已公开
摘要
一位律师兼 PLI Labs 创始人公布了完整的基准测试数据:在两台 DGX Spark 上运行 DeepSeek-V4.1-Flash-1017(2.75 bpw EXL3),并由一台搭载 3090 的主机负责通过 RDMA 提供的表以及推测解码草稿模型,在上下文长度高达 256K 时实现超过 2,600 tok/s 的预填充速度,结构化输出速度达到 322 tok/s。所有代码、启动脚本和原始 JSON 均已公开,作者也坦率指出了自己的配置在哪些方面不如其他双 Spark 配置。
那位拥有 V100 服务器的律师又来更新了。我跑去买了两台 DGX Spark,毕竟这才像我会干的事。中年危机仍在按计划推进。还是老样子:我依然是律师,依然靠 Claude Code 操作整套系统,基准测试也是 Claude Code 跑的,这些表格是它做的,这篇文章也是它帮我写的。我是 Nick Mermiges 律师,PLI Labs 的创始人。下面的仓库是我们的。配置:DeepSeek-V4.1-Flash-1017,2.75 bpw EXL3,使用 vLLM 在两台 Spark 上做张量并行。特别之处在于第三台机器——我那台装着 3090 的 EPYC,它为两台 Spark 承担两项任务:- 将 Engram 表存放在系统内存中,并通过 RDMA 提供访问;- 在一对通过 NVLink 互联的 3090 上运行 DSpark 推测解码草稿模型。Spark 上腾出来的内存用于 KV 缓存:缓存池容量约为 193 万 token。Spark 的 NVMe 上还有前缀缓存,因此一个 15 万 token 的提示词在服务器重启后仍能保留。首个 token 的返回时间为 2.58 秒,而冷启动时需要 58.6 秒。来看数据。我重新实现了 MiaAI 的 sparkDash 测试协议,以便与最受欢迎的双 Spark 配置进行同条件比较。Spark 频率为 2300 MHz,重复 3 次,取中位数,今天测的。测试 1 路流 4 路流(合计)结构化输出(JSON)138 token/秒 322 token/秒 代码 110 token/秒 192 token/秒 普通文本,温度 0,关闭思考 66 token/秒 130 token/秒 普通文本,开启思考(温度 0.7)56 token/秒 105 token/秒 预填充(sparkDash 方法):提示词长度 token/秒 4K 2,827 32K 2,667 128K 2,650 256K 2,618(首个 token 在 100 秒后返回)作为对比:- 在 8K 至 128K 范围内,MiaAI 公布的预填充速度为 2,065–2,155,bertholomus 为 2,439–2,568,因此预填充是这套配置的优势所在。- 4 路流下的代码生成速度为 192,MiaAI 为 166。我落后的地方也说说,毕竟我不打算装:- MiaAI 在普通文本生成上更快:单路流为 80.7,我是 66。- 128K 提示词之后的解码速度为 62 token/秒,而 bertholomus 为 99。- 短请求如果排在一个冷缓存的 93K 提示词后面,就要等 34 秒。这比 bertholomus 在同一测试中的表现(38.6 秒)略好。MiaAI 在该测试的另一个版本中报告为 3.8 秒,这是我最想解决的问题。草稿模型喜欢代码和 JSON(每轮接受 4–5 个 token),却不喜欢普通文本(约 2 个)。至于准确性,毕竟我要拿它干实际工作:在 sudoingX 的 KLD 测试集上,真实工具调用轮次中,有 95.9% 的情况下与原始模型概率最高的 token 一致(KLD 0.018)。bertholomus 在其自己的工具调用测试集上公布的结果为 79.4%,而 MiaAI 没有公布这项数据。sudoingX 更新的 2.8 bpw 量化版本在同一测试集上比我的略微更接近原始模型(0.0175 对 0.0184),该给的肯定必须给。权重基于 HeNryous 的 2.75 bpw 版本,采用了偏重法律任务的分配方案。量化方面的功劳全归他们。代码、启动脚本、基准测试工具,以及表格中每一项结果的原始 JSON 都已公开。唯一的例外是前缀缓存代码,会在下一次推送时上传。- 仓库:https://github.com/ProprietaryLegal/DeepSeek-V4.1-Flash-2xDGX-Spark-x86-offload - 原始数据:仓库中的 runs/ 文件夹 后续还会有:- 完整的 100 万 token 上下文测试;- 不同深度下的 llama-benchy 测试表格;- BFCL 工具调用测试;- 在同一 KLD 测试上与其他量化版本正面对比。100 Gb 线缆周一装上,届时 Spark 到 3090 的链路也会更快。告诉我哪里做错了。认真的。(PLI Labs 是我的副业团队,围绕律所自身的工作成果,构建私有、本地部署的 AI。如果你对这个感兴趣,可以看看 proprietarylegal.ai。广告就这些。)
相似文章
Reddit r/LocalLLaMA
一位 Reddit 用户分享了在双华硕 GX10 DGX Spark 配置上运行 DeepSeek V4 Flash 的经验,详细介绍了性能指标、配置和功耗,并提供了不同上下文长度下的吞吐量基准测试结果。
Reddit r/LocalLLaMA
sudoingX 的一项独立基准测试显示,在澄清官方 INT4 量化确实可用之后,Ling-3.0-flash 模型在单台 DGX Spark 上的运行速度为 38.7 tok/s,比同硬件上的 DeepSeek V4 Flash 快 2.4 倍。
Reddit r/LocalLLaMA
技术文章:详细介绍如何使用自定义Triton内核和vLLM在两块Nvidia 4090d GPU上运行DeepSeek V4 Flash,在262k上下文环境下实现约105 tokens/秒的推理速度。
Reddit r/LocalLLaMA
DeepSeek V4 Flash在双GH200工作站上的详细基准测试,比较了SGLang和vLLM在1M上下文长度下使用DSpark投机解码的表现,发现SGLang更快,约为317 tok/s对比276 tok/s。
X AI KOLs Timeline
MiaAI Lab 发布了一项升级方案,用于在两台 DGX Spark 节点上使用 vLLM 结合 DSpark 推测解码和 NVFP4 KV-cache 来部署 DeepSeek V4 Flash,在六个并发会话中实现了高达 153.7 tokens/秒 的吞吐量。