Solution · 投入与演进
先把三机做成可靠产品,再复制第二套
当前最合理的目标不是追求更长上下文,而是把已验证的 8K 能力变成安全、可监控、可恢复的内部服务。
方案结构
一套最小可用的本地大模型平台
模型留在内网,业务系统只通过统一入口调用;入口负责安全、限流和长文本控制。
方案比较
端侧部署不是全面替代云,而是补上“本地可控”能力
| 选择 | 优势 | 限制 | 适合场景 |
|---|---|---|---|
| 单台 DGX Spark | 部署简单、成本和运维较低 | 本项目 284B 模型权重装不下 | 中小模型、个人研发、原型验证 |
| 三台 DGX Spark当前方案 | 284B 模型本地运行,数据留在内网 | 单实例、吞吐有限、长文本慢 | 内部研发、代码助手、复杂分析 |
| 六台,两套三机 | 可做高可用,整体吞吐接近翻倍 | 设备与运维投入增加 | 生产核心业务、多团队共享 |
| 云端 API / 数据中心 GPU | 弹性更强、并发和高可用更成熟 | 持续费用、数据边界和供应商依赖 | 公网产品、高并发、流量波动大 |
“接近翻倍”指两个独立副本在请求可均衡分配时的总体吞吐方向,不是本项目实测承诺,也不代表单个请求快一倍。
当前实际部署
不是概念图,而是已经落地的三机 Ring
控制面与模型数据面分离,三台共同承载一个 API 服务。
生产 Gate
当前通过项与阻断项
网络与 RDMA
六子网 Ring、12/12 rail、三条链路 183.50–185.22 Gb/s。
容器 NCCL 与模型
NET/IB collective、真实生成、SSE、Reasoning、Tool-call 和 Codex CLI。
8K 能力与容量
Scale8 120/120、Arrival 160/160、Cold-long 10/10、NIAH 6/6。
三机 OTA 对齐
spark-6/7 与 spark-8 的 OS、Kernel、Driver 批次仍有漂移。
模型全量签名
46 个分片数量完整,但生产 SHA-256 manifest 仍待签署。
高可用副本
当前只有一个 PP3 实例,没有无缝接管能力。
分阶段投入
建议分三步走
内部受控试点
限定用户和业务,输入不超过 8K,稳态不超过 0.10 req/s;收集真实问题类型、平均输入长度和排队数据。
目标:证明业务价值生产化补强
统一系统版本,完成模型哈希签署;上线安全网关、监控告警、容量保护和恢复演练。
目标:把“能跑”变成“可运营”第二套三机副本
当真实流量、停机风险或多团队需求超过单实例能力时,再复制完整集群并增加负载均衡。
目标:高可用与横向扩容风险清单
需要管理层知道的五件事
单点故障
当前三台共同组成一个实例,任何一台故障都会中断服务。核心生产业务需要第二套副本。
长文本越界
12K 重复请求已经触发内存压力,不能依据模型标称 1M 上下文进行业务承诺。
三机软件版本漂移
系统、内核和驱动批次不完全一致,升级后必须重新验证网络和性能。
容量被成功率掩盖
高流量下请求仍能成功,但排队时间已经不可接受。
模型输出风险
本地部署不消除幻觉、偏见、错误答案或敏感输出风险。
投入判断
是否扩容,看四个真实指标
不要只看 GPU 利用率,也不要只看请求是否成功。
业务价值
每周活跃用户、节省工时、任务完成率是否持续增长。
排队体验
首字 p95 是否经常超过业务容忍值,0.10 req/s 是否成为常态瓶颈。
停机损失
一次三机重启是否会影响关键业务;若答案是“会”,就需要第二套副本。
数据边界
本地处理带来的合规和数据控制收益,是否高于云端弹性的便利。
最终建议
批准试点,暂不以“高并发生产平台”立项
以三机现有方案承载受控内部场景,明确 8K 输入与低并发边界;用 4–8 周真实使用数据决定是否增加第二套三机副本。不要为了追求标称上下文继续提高内存比例或放宽 12K 上限。
官方资料
外部依据
DGX Spark 采用 GB10、128 GB 统一内存、最高 1 PFLOP FP4 和 ConnectX-7 200 Gbps。
NVIDIA 产品页 ↗NVIDIA SGLang 26.07 明确包含多节点、DGX Spark 和 Blackwell NVFP4 支持。
SGLang 26.07 说明 ↗NVFP4 模型卡给出 284B / 13B 激活、Blackwell 支持和理论 1M 上下文。
NVIDIA 模型卡 ↗