两台DGX Spark加旧3090，预填充超2600 tok/s
来自那位拥有 V100 服务器的律师的更新。我搞了两台 DGX Spark——因为我当然会这么干。中年危机依然按计划进行。
和之前一样：我仍然是律师，整个过程依然通过 Claude Code 驱动，Claude Code 也负责跑基准测试、生成这些表格并帮我写这篇文章。我是 Nick Mermiges，Esq.，PLI Labs 的创始人。下面的仓库是我们的。
硬件配置
DeepSeek-V4.1-Flash-1017，2.75 bpw（每权重比特数）EXL3 量化，vLLM 张量并行跨两台 Spark。关键在于第三台机器——我的 EPYC 加 3090 那台——为 Spark 干两件事：
- 把 Engram 表放在系统内存里，并通过 RDMA（远程直接内存访问）对外提供；
- 在一对 NVLink 连接的 3090 上运行 DSpark 推测解码器。
Spark 上空出来的内存全部用于 KV 缓存：大约 193 万 token 的池子。Spark 的 NVMe 上还有一个前缀缓存，所以 15 万 token 的提示词在服务器重启后依然保留。首 token 返回时间从冷启动的 58.6 秒降到 2.58 秒。
性能数据
我重新实现了 MiaAI 的 sparkDash 协议，这样就能和最流行的 2x Spark 配置做直接对比。Spark 运行在 2300 MHz，3 次重复取中位数，今天的数据如下。
| 测试 | 1 流 | 4 流（总计） |
|---|---|---|
| 结构化输出（JSON） | 138 tok/s | 322 tok/s |
| 代码 | 110 tok/s | 192 tok/s |
| 散文，温度 0，关闭思考 | 66 tok/s | 130 tok/s |
| 散文，开启思考（温度 0.7） | 56 tok/s | 105 tok/s |
预填充（sparkDash 方法）：
| 提示长度 | tok/s |
|---|---|
| 4K | 2,827 |
| 32K | 2,667 |
| 128K | 2,650 |
| 256K | 2,618（首 token 100 秒） |
作为对比：
- MiaAI 公布的预填充为 2,065–2,155，bertholomus 为 2,439–2,568（8K 到 128K），所以预填充正是这套构建的优势所在。
- 4 流代码为 192，对比 MiaAI 的 166。
不足之处
我不会假装什么都好：
- MiaAI 在纯散文上更快：单流 80.7，我只有 66。
- 128K 提示后的解码速度是 62 tok/s，对比 bertholomus 的 99。
- 一个短请求排在冷启动的 93K 提示后面，要等 34 秒。这比 bertholomus 在同一测试上的 38.6 秒略好。MiaAI 在不同版本上报告 3.8 秒，这是我最想解决的问题。
推测解码器喜欢代码和 JSON（每轮接受 4–5 个 token），讨厌散文（大约 2 个）。
准确性
因为我真的拿它干活：在 sudoingX 的 KLD 面板上，真实工具调用回合与原始模型 top token 的一致性达到 95.9%（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 如果你感兴趣。这就是全部推销。）