两台 DGX Spark 级设备，一个模型：每台各存一份副本，胜过拆分部署
运维
七周以来，我们的本地语言模型通过张量并行拆分运行在两台 NVIDIA GB10 机器上。10 月 22 日，我们改为在每台机器上部署完整的模型副本，并在前端配置最小连接数代理。吞吐量从约 180 tokens/s 提升至 210 tokens/s，且现在任一机器重启都不会导致模型不可用。
为何当初选择拆分
每台机器有 128 GB 内存，由 CPU 和 GPU 共享。九月份，模型能装进一台机器，但其缓存几乎装不下：我们使用的 vLLM 构建版本无法将该模型的 KV 缓存保持在 FP8 格式，因此缓存为 BF16 格式，而一台机器只能容纳 499,110 个 token 的缓存。这还不到模型完整上下文 262,144 个 token 的两个请求。通过直接网络链路使用张量并行将模型拆分到两台机器上后，缓存增长到超过三百万个 token。我们拆分模型是为了腾出空间，而不是为了速度。
发生了什么变化
同一模型较新的 4-bit 构建版本（NVFP4，通过量化感知蒸馏生成）约占 71 GiB 内存，而面向 GB10 的社区版 vLLM 构建（eugr/spark-vllm-b12x）能以 FP8 格式运行其缓存。现在，一台机器即可容纳整个模型以及 0.76 至 1.08 百万 tokens 的缓存，根据机器分配的内存量，可支持 2.9 至 4.1 个请求在完整上下文长度下运行。两份副本均使用模型自带的推测解码（MTP，四个草稿 tokens）。切换前，我们在新构建版本上运行了工具调用测试：得分为 86，而被替换的旧构建版本得分为 75。
测量结果
| 拆分至两台机器 | 每台机器各存一份副本 | |
|---|---|---|
| KV 缓存 | 超过 300 万个 token | 76 万和 108 万个 token |
| 完整上下文下的请求数 | 约 12 | 2.9 和 4.1 |
| 我们负载下的吞吐量 | 约 180 tokens/s | 210 tokens/s (111 + 99) |
| 启动时间 | 约 20 分钟 | 每份副本 5 至 13 分钟 |
| 一台机器重启 | 模型不可用 | 另一份副本继续服务 |
单份运行，按并发请求数统计：短提示词下，1 个并发请求达到 36 tokens/秒，4 个达到 82，8 个达到 109，16 个达到 150。使用我们邮件智能体的较长提示词时，4 个并发请求达到 81，8 个达到 113，16 个仅为 87：超过 8 个此类请求后，增加并发反而变慢。
在下午的测试中，一份最多同时处理 12 个请求，另一份最多 8 个。前者达到 91 至 93 tokens/秒，每分钟完成 26 至 27 个请求；后者达到 81 至 83 tokens/秒，每分钟完成 22 个请求。现在两者都设为 12。
我们放弃了什么
空间。拆分模型有一个超过三百万 tokens 的缓存；两份副本各有两个较小的缓存，且请求只能使用为其服务的那份副本的缓存。我们的智能体发送大量短和中等长度的请求，因此吞吐量更为重要。如果您同时处理少量极长的上下文，拆分可能仍是更好的选择。我们保留了拆分配置，切回只需一个脚本。
切换期间出了什么问题
- 模型停机十一分钟，随后出现 30 秒的 502 错误。拆分后的模型必须在同一批机器上加载副本之前停止，因此我们的智能体等待了大约十一分钟。当第一个副本启动时，代理又持续返回“502 no live upstreams”约 30 秒：它在后端宕机期间将其标记为失败（
max_fails=3、fail_timeout=30s），直到该时间结束才再次尝试连接。 - 一个绕过代理的客户端。我们的一个批处理作业在配置中硬编码了第一台机器的地址，导致其全部负载都打到一份副本上，而另一份副本仍有空闲容量。现在所有客户端都通过代理访问；机器自身的地址仅用于健康检查。
- 跳动的指标。我们的吞吐量监视器通过代理读取 vLLM 的
/metrics。由于有两个后端，连续读取来自不同的副本，计数器来回跳动，监视器报告模型处于饥饿状态。现在它直接读取每个副本并求和。 - 一个会阻止新副本启动的旧看门狗。拆分设置有一个看门狗，当模型停止响应时会重启其服务。新服务声明与旧服务存在
Conflicts=冲突，因此该重启操作会停止新副本。必须使用systemctl disable --now将其关闭，而不仅仅是停止，因为我们的运维层会重启已启用但未运行的单元。 - 承担其他工作的机器上的内存。一台机器还运行我们的数据库和站点构建。将 vLLM 的
gpu-memory-utilization设置为 0.78 时，仅剩下 5 GiB 供其他所有程序使用，因此我们将其降低到 0.74，并仅重启该副本，而由另一个副本承担负载。在这些机器上，您分配给 vLLM 的份额与其他程序共享同一块内存。
如果您有两台这样的机器
- 如果模型和您需要的缓存能容纳在一台机器上，请在每台机器上运行一个副本，并在其前配置最少连接数代理。仅当单台机器无法容纳您所需的缓存时，才拆分模型。
- 将所有客户端指向代理，包括批处理任务和旧配置。
- 直接从每个副本读取指标。
- 根据每台机器上运行的其他服务，为其分配独立的内存份额。
- 根据您的实际流量设置每个副本同时处理的请求数：对于我们的流量组合，12 优于 8。
- 预期切换过程会导致模型不可用，时长相当于一个副本的启动时间，并为此做好规划。
Factory Floor 提供适用于一台或两台机器的代理和启动配置、健康检查以及我们在切换模型前运行的工具调用测试，还包含用于机器其余部分的看门狗和内存防护机制。