不是三台各跑一份；任何一台退出，整个实例都需要重启。
每台 128 GB，模型被切成三段；并不是一块可任意使用的共享内存。
模型标称 100 万 token，但本设备组合的安全上限由内存决定。
约每 10 秒进入 1 个典型请求；适合团队助手，不适合大众高并发入口。
按角色阅读
一套网页，三种深度
老板先看结论，业务负责人看体验，技术负责人可以一路追到原始 JSON。
一句话讲清楚
三台机器主要解决“装得下”，不是让速度变成三倍
DeepSeek V4 NVFP4 权重约 168 GB，单台只有 128 GB 统一内存，无法容纳完整模型和运行开销。三台通过流水线并行，各负责模型的一部分。
用户问题
→
→
模型回答
为什么不是两台？
两台合计容量从账面上可能放得下权重，但还要给操作系统、推理缓存、长文本处理、通信和峰值波动留空间。本项目没有验证两机方案；三机是目前跑通且有安全余量的配置。
端侧部署上限
设备数量决定的是模型容量、可用性和并发
NVIDIA 官方对单台 DGX Spark 的定位是可运行最高约 2000 亿参数模型；具体能否运行仍取决于量化精度、模型结构和软件支持。
个人研发与中型模型
官方规格：128 GB 统一内存、最高 1 PFLOP FP4，适合桌面原型、微调和较小模型。
本项目 284B 模型：装不下账面容量增加
理论容量变大，但运行余量、稳定性和软件路径没有完成本项目验证。
不建议直接用于本项目当前验证方案
模型按 14 / 14 / 15 层切分，网络、推理、工具调用和 8K 输入均已实测。
当前最小可靠组合两套三机副本
更适合做高可用和吞吐扩容：一套故障时另一套接管，或两套分担请求。
建议的下一阶段方向说明：“6 台双副本”是基于当前三机验证结果的架构建议，尚未在本项目实测；它主要增加并发和可用性，不会把单次请求的安全上下文自动扩大一倍。
业务价值
适合哪些事，不适合哪些事
这套方案的价值是“超大模型本地可用”，而不是替代所有云端推理服务。
适合
- 代码辅助、复杂分析、内部知识助手
- 有数据不出内网要求的业务
- 小团队、低到中等请求量
- 可接受十几秒到几十秒完成一次长回答
不适合
- 面向公众的大规模并发服务
- 要求毫秒级实时响应的场景
- 单次超过 8K 的稳定长文本处理
- 没有停机容忍度、却只有一套三机集群
项目成熟度
已经完成什么，还差什么
方案可运行
- 三机网络和模型推理通过
- 聊天、流式输出、推理与工具调用通过
- 8K 输入和典型并发完成验证
- 约 83 分钟混合负载无硬件故障
生产补强
- 三台系统、驱动和固件版本统一
- 46 个模型分片做全量哈希签署
- 增加入口网关、TLS、用户限流
- 按组织标准补做恒定负载稳定性测试
没有高可用
- 任何一台故障都会影响整个模型
- 12K 重复长输入触发内存压力
- 单个后端密钥不等于多用户安全体系
- 不应直接把 8000 端口暴露公网
建议决策
先作为内部能力平台使用，再按真实业务量决定是否复制第二套
当前不建议继续把一套流水线拉得更长。更稳妥的投入顺序是：完成生产补强 → 接入真实内部业务 → 观察排队和使用率 → 如果需要高可用或更多并发，再增加第二套三机副本。
- 现在批准受控试点，生产输入限制为 8K，稳态按 ≤0.10 req/s 管理。
- 上线前完成版本统一、模型校验、安全网关和稳定性复测。
- 扩容时优先新增一套三机副本，换取高可用和近似线性的总吞吐提升。
数据口径
官方规格与本项目实测分开看
官方规格
单机 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 三机实测；不是厂商承诺值。
查看性能口径 →