01 · 一页结论 · 管理层先看

三台 DGX Spark,
能做什么、不能做什么

方案已经跑通:适合内部试点、研发辅助和敏感数据本地处理。它首先解决“超大模型装得下”,不是高并发云服务,目前也没有高可用。

2026-08-17 · 内网实测当前服务在线,性能仍待复验“服务健康”证明现在能响应,不等于旧性能数字已经自动迁移到新配置。
三机 SGLangPP Rank 0 / 1 / 2 健康只有 Rank 0 提供用户 API
当前缓存配置mem=0.57 · KV 1,579,520mem 来自运行记录;KV 由三 Rank 指标确认
入口与监控HTTPS / Web UI / Prometheus / Grafana 在线节点与 GPU 均为 3 / 3 UP
验收状态Chat 健康,完整矩阵待重跑Tool-call 当前配置待复验
本页解决什么5 分钟判断是否可以试点、边界在哪里、下一步投什么结论优先,不要求技术背景
3 台组成一个模型实例

不是三台各跑一份;任何一台退出,整个实例都需要重启。

384 GB三节点内存总量(非共享池)

每台独立 128 GB,模型被切成三段;不能把它当成一块透明共享内存。

8K当前沿用的受控准入 cap

来自 mem=0.50 历史验收;当前大 KV 配置尚未重跑完整 8K 矩阵。

≤0.10历史基线的稳态建议

仅对应已测的 256→128 合成请求;当前配置和真实业务必须重新压测。

全站阅读顺序

六个页面,各回答一个问题

只看当前页可以做初步决策;需要深入时,沿 01 → 06 顺序阅读,不再来回寻找重复内容。

01 · 当前方案

三台机器主要解决“装得下”,不是让速度变成三倍

DeepSeek V4 NVFP4 权重约 168 GB,单台只有 128 GB 统一内存,无法容纳完整模型和运行开销。三台通过流水线并行,各负责模型的一部分。

用户问题
第 1 段DGX Spark 1处理 14 层
第 2 段DGX Spark 2处理 14 层
第 3 段DGX Spark 3处理 15 层
模型回答
i
为什么不是两台?

两台合计容量从账面上可能放得下权重,但还要给操作系统、推理缓存、长文本处理、通信和峰值波动留空间。本项目没有验证两机方案;三机是目前跑通且有安全余量的配置。

02 · 设备与能力上限

设备数量决定的是模型容量、可用性和并发

NVIDIA 官方对单台 DGX Spark 的定位是可运行最高约 2000 亿参数模型;具体能否运行仍取决于量化精度、模型结构和软件支持。

1 台

个人研发与中型模型

官方规格:128 GB 统一内存、最高 1 PFLOP FP4,适合桌面原型、微调和较小模型。

本项目 284B 模型:装不下
2 台

账面容量增加

理论容量变大,但运行余量、稳定性和软件路径没有完成本项目验证。

不建议直接用于本项目
6 台

两套三机副本

更适合做高可用和吞吐扩容:一套故障时另一套接管,或两套分担请求。

建议的下一阶段方向

说明:“6 台双副本”是基于当前三机验证结果的架构建议,尚未在本项目实测;它主要增加并发和可用性,不会把单次请求的安全上下文自动扩大一倍。

03 · 适用边界

适合哪些事,不适合哪些事

这套方案的价值是“超大模型本地可用”,而不是替代所有云端推理服务。

适合

  • 代码辅助、复杂分析、内部知识助手
  • 有数据不出内网要求的业务
  • 小团队、低到中等请求量
  • 可接受十几秒到几十秒完成一次长回答
×

不适合

  • 面向公众的大规模并发服务
  • 要求毫秒级实时响应的场景
  • 单次超过 8K 的稳定长文本处理
  • 依赖 strict / required schema 工具调用的生产流程
  • 没有停机容忍度、却只有一套三机集群

04 · 项目成熟度

已经完成什么,还差什么

当前在线

服务与可观测性

  • 三 Rank health 与真实 forward 健康
  • Rank 0 API 需要认证,Worker 不提供独立模型 API
  • HTTPS Web UI、Nginx/admission proxy 在线
  • Prometheus/Grafana、节点 3/3、GPU 3/3 在线
历史证据

mem=0.50 验收基线

  • Scale8 120/120、Arrival 160/160
  • 4K/8K Cold-long 10/10、NIAH 6/6
  • 基础 Function-call 曾通过
  • 约 83 分钟为混合观察,不是恒定满载 soak
当前缺口

新配置未完整签署

  • 大 KV 配置尚未重跑并发、Arrival、8K 与 NIAH
  • Tool-call 当前待复验;strict / required / schema 暂不支持
  • 系统版本与全量模型哈希仍待对齐
  • 单实例没有高可用,逐用户治理与完整告警仍需补强

05 · 建议决策

先作为内部能力平台使用,再按真实业务量决定是否复制第二套

当前不建议继续把一套流水线拉得更长。更稳妥的投入顺序是:完成生产补强 → 接入真实内部业务 → 观察排队和使用率 → 如果需要高可用或更多并发,再增加第二套三机副本。

  1. 现在批准受控试点,沿用 8K 输入 cap;≤0.10 req/s 仅作为历史基线的保守起点。
  2. 上线前完成当前配置性能回归、Tool-call 边界复验、版本统一、模型校验和稳定性复测。
  3. 扩容时优先新增一套三机副本,换取高可用和近似线性的总吞吐提升。

06 · 数据口径

官方规格与本项目实测分开看

官方规格

单机 128 GB 统一内存、最高 1 PFLOP FP4、ConnectX-7 200 Gbps,以及“最高约 200B 参数”定位。

NVIDIA DGX Spark 产品页 ↗
模型规格

DeepSeek V4 Flash 为 284B 总参数、13B 激活,NVFP4 版本支持 SGLang / vLLM 和最高 1M 上下文。

NVIDIA 模型卡 ↗
历史性能实测

8K、吞吐、延迟、内存压力和到达率来自 2026-08-15/16 的 mem=0.50 配置;当前运行状态单独标注,不能混用。

查看双口径说明 →