三台 DGX Spark 部署 DeepSeek V4 Flash NVFP4：从零到可用教程

伟大的大威2026-08-27 11:26

适用对象：第一次接触多机大模型、Docker、RoCE 或 NCCL 的管理员。

目标模型：DeepSeek-V4-Flash-NVFP4。

目标结果：三台 DGX Spark 共同提供一个 OpenAI-compatible API，而不是三份模型副本。

当前验证日期：2026-08-16（Asia/Shanghai）。

本文是按当前三台机器和仓库内已有脚本编写的可执行教程。简明的事实记录见 部署总览，网络细节见 三节点 Ring 记录，性能和容量边界见 性能与 Agent 验收报告。

1. 先理解最终方案

1.1 最终拓扑

text 复制代码 
客户端 / Agent
       │
       │ HTTP :8000，OpenAI-compatible API
       ▼
spark-6 / 192.168.1.128 / rank 0 / PP stage 0 / 14 层
       │
       │ ConnectX-7 RoCE Ring，NCCL 模型通信
       ▼
spark-7 / 192.168.1.228 / rank 1 / PP stage 1 / 14 层
       │
       ▼
spark-8 / 192.168.1.168 / rank 2 / PP stage 2 / 15 层

控制面、SSH、TCPStore、Gloo、NCCL bootstrap：
enP7s7 / 192.168.1.0/24

模型数据面：
三条 ConnectX-7 200 Gb/s 直连组成的 RoCE Ring

节点固定映射如下。不要交换 rank，也不要把 dist-init 地址改为 RoCE 地址：

节点 管理 IP Rank Pipeline stage 层数 对外职责
spark-6 192.168.1.128 0 0 14 rendezvous、API :8000
spark-7 192.168.1.228 1 1 14 worker
spark-8 192.168.1.168 2 2 15 worker、输出层

这是一个 TP=1、PP=3、nnodes=3 的分布式实例。模型有 43 层，因此分成 14,14,15。任意一台退出，整个实例都不完整；启停必须协调三台一起进行。

1.2 新手术语表

术语 含义 本方案中的取值
Rank 分布式任务中节点的唯一编号 spark-6/7/8 分别为 0/1/2
TP Tensor Parallel，把同一层拆到多 GPU 1，本方案不跨节点拆一层
PP Pipeline Parallel，把不同层放到不同节点 3，每台一个 stage
NCCL NVIDIA 的 GPU 集合通信库 负责三节点模型通信
RoCE 在以太网上承载 RDMA 走 ConnectX-7 Ring
Gloo/TCPStore 进程发现与控制面通信 走管理网 enP7s7
OOB/bootstrap NCCL 建立连接时的小流量控制通信 走管理网，不代表模型数据走普通 TCP
NVFP4 NVIDIA 的 4-bit 浮点量化格式 MoE 专家权重使用的主要格式
SM121 DGX Spark GB10 的 GPU compute capability (12, 1)
Context 一次请求中输入、输出、模板和工具信息的总 token 空间 Server 硬窗口 12288
MRR SGLang 同时运行的最大请求数 8
CUDA Graph BS 预捕获的 decode batch 上限 4
PSI Linux Pressure Stall Information 用来判断内存压力是否已影响系统

1.3 已验证的安全运行边界

生产配置不是模型理论上限，而是这组三机实测后的安全边界：

text 复制代码 
TP=1
PP=3
PP_LAYER_PARTITION=14,14,15
CONTEXT_LENGTH=12288          # Server 硬窗口
生产输入 cap=8192            # 必须由客户端或网关执行
MEM_FRACTION_STATIC=0.57
MAX_TOTAL_TOKENS=1579520
MAX_RUNNING_REQUESTS=8
CUDA_GRAPH_MAX_BS_DECODE=4
CHUNKED_PREFILL_SIZE=4096
MAX_PREFILL_TOKENS=4096

12288 不是推荐输入长度。它还要容纳输出、Chat template、reasoning 和 tool schema。生产输入最多 8192 tokens；长请求建议并发 1。12K 重复冷请求和 16K 请求已触发系统内存压力门槛，因此不要宣传或开放 12K、16K、32K、64K、128K、256K 或 1M 输入能力。

2. 硬件、软件和权限条件

2.1 必需硬件

  • 三台 NVIDIA GB10/SM121 机器，每台一颗 GPU 和统一内存。
  • 每台至少两个物理 ConnectX-7 端口；当前端口会暴露四个逻辑 RoCE HCA。
  • 三根合规 QSFP 线，每对节点一根，组成三角 Ring。
  • 原装合规 240W 电源和良好散热。持续高负载时不要让同一供电链路再承担高功耗 USB-C 外设。
  • 每台本地磁盘上都有完整模型；当前权重分片总计约 168 GB。
  • 管理网三台互通，且 rank 0 的 192.168.1.128:25001 可被另外两台访问。

2.2 必需软件与权限

  • DGX OS、可识别 GB10 的 NVIDIA Driver、RDMA/mlx5 用户态组件。
  • Docker Engine、Docker Compose plugin、NVIDIA Container Toolkit。
  • bash、python3、curl、rsync、openssl、zstd、iproute2、ethtool 和 RDMA 工具。
  • 三台同名部署用户，当前为 nvidia。
  • spark-6 到 spark-7、spark-8 的 key-based SSH；脚本默认读取 /home/nvidia/.ssh/id_ed25519_shared。
  • nvidia 用户能够执行 Docker，或者能够无密码执行 sudo -n docker。不要把不可信用户加入 docker group，因为 Docker 权限等同宿主 root 权限。

不要把 SSH 密码、API key 写进本教程、脚本、Compose、Git 或命令行参数。部署只使用密钥认证；聊天或历史记录中出现过的密码应轮换。

2.3 当前环境与升级决定

项目 spark-6 spark-7 spark-8 当前决定
DGX OS / Kernel 7.2.3 / 6.11 7.2.3 / 6.11 7.4 系列 / 6.17 存在漂移，生产签字前完整 OTA 对齐
Driver 580.82.09 580.82.09 580.126.09 随整机 OTA 对齐，不单独替换
Docker 28.3.3 28.3.3 29.1.3 已通过容器门禁，无需为本部署单独升级
Compose 2.39.1 2.39.1 5.0.1 当前 Compose 文件兼容
Container Toolkit 1.17.8 1.17.8 1.18.2/CDI GPU/RDMA 注入已通过，随 OTA 规范化

正确策略是在维护窗口按设备供应商支持的整机流程完成 OS、Kernel、Driver 和固件 OTA，然后重启并重新验收。NVIDIA 的 OS 更新文档面向 NVIDIA Founders Edition；合作厂商的 GB10 设备应遵循该厂商的更新渠道。不要单独 apt install 新 Driver/CUDA，也不要在容器里执行 pip install -U torch sglang flashinfer。

官方参考：

3. 为什么选择 Docker 和固定版本

3.1 固定软件栈

本方案冻结 NVIDIA SGLang 26.07 的整套兼容栈：SGLang 0.5.14、FlashInfer 0.6.14、Torch 2.13/CUDA 13.3、NCCL 2.30.7。不要把"更新"误当成"优化"；单独升级其中一个组件会失去已经验证的 ABI 和 kernel 组合。

对象 固定标识
官方基础镜像 RepoDigest nvcr.io/nvidia/sglang@sha256:4e2c6f610dca57dd26af9c3045d1935a11d185903cec060d11cec061de2b62f0
官方基础镜像 config ID sha256:4f5f4cade001a28b44f3e6289f49eb6e2e3e941e284fa95ee67a53c3d17745a1
三机当前派生镜像 config ID sha256:43e76a532b12365232231d0bff2f63b79744f0042a016f04b8d5f7c27bf20386
平台 linux/arm64
兼容补丁 SHA-256 ceb5ac6536e25e4ce786dd99bbe09d4c2890cf645b74794425c952a1b976c3dc

派生镜像只给 SGLang Responses 完成事件补充 cache_write_tokens: 0，以满足镜像中 openai-python 2.48.0 的 schema。它不升级或替换任何 CUDA/Python 依赖。细节见 派生镜像说明。Codex 使用 Responses API，因此生产接入 Codex 时应使用这个派生镜像。

3.2 SM121 必须保留的设置

text 复制代码 
--moe-runner-backend flashinfer_cutlass
--fp4-gemm-backend flashinfer_cutlass
--disable-flashinfer-autotune
SGLANG_OPT_FLASHMLA_SPARSE_PREFILL=0
SGLANG_SM120_TRITON_FLASHMLA=1
SGLANG_FP8_IGNORED_LAYERS=lm_head

lm_head 在 checkpoint 中是 BF16 且没有 FP8 scale。若把它强行套用 FP8，API 可能返回 HTTP 200 却生成空内容或 BOS。CUTLASS 两项则防止 GB10/SM121 误入不适用的 TRT-LLM routed kernel。

3.3 Docker 最小权限

Compose 文件使用：

text 复制代码 
network_mode: host
ipc: host
gpus: all
/dev/infiniband device 注入
memlock=-1
stack=67108864
模型目录只读
cache 目录单独可写
容器日志轮转
restart: no

明确不使用：

text 复制代码 
--privileged
seccomp=unconfined
Docker socket 挂载
模型目录读写挂载
宿主 CUDA/NCCL 注入
Ray、SGLang Gateway、Docker overlay network

restart: no 是有意设计。单个 rank 自动重启会制造"一个容器看似健康、整个 PP 集群不可用"的假象；外部运维必须协调三台一起停止和启动。

4. 部署前安全准备

以下操作在三台分别完成。先不要启动模型。

4.1 记录基线

bash 复制代码 
hostname
cat /etc/dgx-release 2>/dev/null || true
uname -a
nvidia-smi
docker version
docker compose version
ip -br addr
ip -4 route
ibdev2netdev
rdma link show
sudo fwupdmgr get-devices

核对点：

  • hostname 必须准确为 spark-6、spark-7 或 spark-8。
  • enP7s7 必须拥有表格中的管理 IP。
  • nvidia-smi 必须识别 NVIDIA GB10。
  • ibdev2netdev 应看到至少四个处于 Up 的 ConnectX 逻辑接口。
  • 管理网的 SSH 不能依赖密码交互。

4.2 检查专用推理模式

当前三机已经持久化为无桌面模式。下面的 system user-service 检查必须登录为 nvidia 用户执行；若当前 shell 是 root，systemctl --user 查到的是 root 自己的 user manager，并不能代表 nvidia。以下命令只检查，不会开启服务：

bash 复制代码 
systemctl get-default
systemctl is-active display-manager || true
systemctl --user is-enabled openclaw-gateway.service || true
systemctl --user is-active openclaw-gateway.service || true
systemctl --user is-enabled gnome-remote-desktop.service || true
systemctl --user is-active gnome-remote-desktop.service || true

期望结果：默认 target 为 multi-user.target，OpenClaw、display manager、GNOME remote desktop 均为 disabled/inactive。它们不会开机启动，部署回滚也不要自动恢复。

必须保留 NetworkManager、SSH、Docker/containerd、NVIDIA/RDMA、nvidia-persistenced、时间同步、journald、udev、logind、rasdaemon、smartmontools 和必要的安全代理。不要为了跑分批量禁用不了解的 systemd 服务。

4.3 建立 key-based SSH

从 spark-6 验证：

bash 复制代码 
ssh -i /home/nvidia/.ssh/id_ed25519_shared \
  -o BatchMode=yes nvidia@192.168.1.228 hostname

ssh -i /home/nvidia/.ssh/id_ed25519_shared \
  -o BatchMode=yes nvidia@192.168.1.168 hostname

输出应分别是 spark-7、spark-8。这里没有任何密码参数；若命令要求输入密码，先完成公钥分发和 host key 核验，再继续。

5. 配置和验收三节点 RoCE Ring

这是部署中最容易出错、也最不能跳过的一步。管理网和模型数据网承担不同职责：

  • 192.168.1.0/24：SSH、TCPStore、Gloo、NCCL bootstrap、API。
  • 10.200.0.0/24 至 10.200.5.0/24：RoCE 模型数据。

5.1 当前物理连线

text 复制代码 
spark-6 p0 <-> spark-7 p0
spark-7 p1 <-> spark-8 p1
spark-8 p0 <-> spark-6 p1

每个物理端口暴露两个逻辑 rail。当前六个不重叠子网如下：

子网 端点 A 端点 B
10.200.0.0/24 spark-6 enp1s0f1np1=10.200.0.1 spark-8 enp1s0f0np0=10.200.0.2
10.200.1.0/24 spark-6 enP2p1s0f1np1=10.200.1.1 spark-8 enP2p1s0f0np0=10.200.1.2
10.200.2.0/24 spark-6 enp1s0f0np0=10.200.2.1 spark-7 enp1s0f0np0=10.200.2.2
10.200.3.0/24 spark-6 enP2p1s0f0np0=10.200.3.1 spark-7 enP2p1s0f0np0=10.200.3.2
10.200.4.0/24 spark-7 enp1s0f1np1=10.200.4.2 spark-8 enp1s0f1np1=10.200.4.1
10.200.5.0/24 spark-7 enP2p1s0f1np1=10.200.5.2 spark-8 enP2p1s0f1np1=10.200.5.1

现场已应用的参考文件位于：

text 复制代码 
deploy/network/spark-6-99-nvidia-sync-cluster.yaml
deploy/network/spark-7-99-nvidia-sync-cluster.yaml
deploy/network/spark-8-99-nvidia-sync-cluster.yaml

不要在未知线缆拓扑的新集群直接复制这些 YAML。新环境应使用 NVIDIA Sync Cluster Assistant 检测线缆、生成地址计划并验证链路。官方教程：Connect Three DGX Spark in a Ring。

5.2 Ring 硬门禁

三台分别检查：

bash 复制代码 
sudo test -r /etc/netplan/99-nvidia-sync-cluster.yaml
sudo netplan get
ip -br addr
ip -4 route
ibdev2netdev
rdma link show

通过条件：

  • 不再有多个重叠的 169.254.0.0/16 connected route。
  • 六个 RoCE 子网不与管理网或 Docker 网段冲突。
  • 每台四个预期 RoCE 逻辑接口均 Up。
  • 使用中的物理链路协商 200000Mb/s。
  • Assistant 的链路测试达到官方门槛；若结果在边界附近，按同一版本、同一参数复测并保留原始报告。
  • 只要求网络计划中的直连对端可达；不要求任意 RoCE 地址跨两跳互通。

当前现场三条物理链双 rail ib_write_bw 已分别测得 183.50、185.08、185.22 Gb/s；第一条处于门槛边缘，因此生产签字仍以 OTA 后同条件复测为准。详见 RDMA 链路验证记录。这只证明链路层，不替代 NCCL collective。

5.3 网络回滚保护

当前旧 Netplan 备份在每台：

text 复制代码 
/root/dsv4-net-backup-20260814-1807/netplan/

网络回滚可能导致 SSH 断开。必须先准备本地控制台或保持一条已验证的管理连接，再进行：把 99-nvidia-sync-cluster.yaml 移出 /etc/netplan，恢复备份的 40-cx7.yaml，依次执行 netplan generate、netplan try，确认管理 SSH 和路由正确后才正式应用。不要在只有一条远程 SSH 时删除网络配置。

6. 先验收主机 NCCL

主机 NCCL helper 只用于网络验收，不挂入 SGLang 容器。为保证复现，下面固定到 2026-08-16 审阅过的 playbook commit，而不是执行浮动的 main。helper 会交互读取每台机器的 sudo 密码，但不会把密码放到命令行；运行前仍应人工审阅下载的脚本。

官方 helper 通过普通 ssh 调 worker，因此先把本方案的非默认 key 加进临时 ssh-agent：

bash 复制代码 
set -Eeuo pipefail
mkdir -p /home/nvidia/workspaces/nccl-validation
cd /home/nvidia/workspaces/nccl-validation

PLAYBOOK_COMMIT=1fb66f059ee427c5a3678b3117ef73aab042b458
curl -fsSL "https://raw.githubusercontent.com/NVIDIA/dgx-spark-playbooks/${PLAYBOOK_COMMIT}/nvidia/nccl/assets/setup.sh" -o setup.sh
curl -fsSL "https://raw.githubusercontent.com/NVIDIA/dgx-spark-playbooks/${PLAYBOOK_COMMIT}/nvidia/nccl/assets/launch.sh" -o launch.sh

printf '%s  %s\n' \
  32665e12b12c9a3eb3f9ac043993f442df9215e47b42d0b93f511e113c1b5cc7 setup.sh \
  a6c2e69b234f3455283f354b9f21b13cd2665d69a563e69aa2f51f49a31c00f3 launch.sh \
  | sha256sum -c -

eval "$(ssh-agent -s)"
trap 'ssh-agent -k >/dev/null 2>&1 || true' EXIT
ssh-add /home/nvidia/.ssh/id_ed25519_shared

bash setup.sh 192.168.1.228 192.168.1.168

bash launch.sh --topology ring \
  192.168.1.128 \
  192.168.1.228 \
  192.168.1.168

ssh-agent -k
trap - EXIT

固定 playbook commit 只固定 helper 本身；当前 setup.sh 会固定 NCCL v2.30.7-1，但会克隆 nccl-tests 的当时默认分支。验收报告必须记录 ~/nccl 和 ~/nccl-tests 的实际 commit。若这两个目录已存在，helper 会拒绝继续；先审计其用途，再移动到带时间戳的明确备份目录，绝不要按错误提示直接删除未知内容。launch.sh 的 MPI SSH 参数会关闭严格 host-key 检查；仅在已隔离、已核验的管理网使用。组织若禁止该设置，应先审阅并按其 SSH 基线修改 helper，而不是直接照跑。

Ring helper 会使用：

text 复制代码 
NCCL_IB_SUBNET_AWARE_ROUTING=1
NCCL_NET_PLUGIN=none

首轮不要自行设置 NCCL_IB_HCA、NCCL_IB_GID_INDEX、NCCL_CROSS_NIC、NCCL_IB_TC、NCCL_IB_SL 或 GDR 参数。DGX Spark 不支持 GPUDirect RDMA，跨节点 RoCE 使用 host staging 是平台预期行为。

通过条件：三 rank 完成、不 hang、数值正确，日志没有 unknown event type (18)、mlx5 fatal/reset、AER、link reset。当前宿主 helper 仍是生产待办项；不能用历史容器 NCCL PASS 冒充本项完成。

7. 准备模型并做完整性检查

三台必须使用相同路径：

text 复制代码 
/home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4

7.1 结构检查

三台分别执行：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4

du -sh .
find . -maxdepth 1 -type f -name 'model-*.safetensors' | wc -l
test -r model.safetensors.index.json

再让 index 自己检查被引用的分片：

bash 复制代码 
python3 - <<'PY'
import json
from pathlib import Path

root = Path(".")
with (root / "model.safetensors.index.json").open(encoding="utf-8") as f:
    index = json.load(f)
files = sorted(set(index["weight_map"].values()))
missing = [name for name in files if not (root / name).is_file()]
empty = [name for name in files if (root / name).is_file() and (root / name).stat().st_size == 0]
print(f"shards={len(files)} missing={len(missing)} empty={len(empty)}")
raise SystemExit(1 if len(files) != 46 or missing or empty else 0)
PY

正确结果为 46 个 shard、无 missing、无空文件。三机 index、shard 数和总字节已由部署脚本比较；当前总字节为 168281985176。

7.2 如果 worker 尚无模型

从 spark-6 使用管理网同步。首次拷贝很慢，可以在确认 RoCE 直连地址和 host key 后使用对应直连链路；新手优先使用稳定的管理网：

bash 复制代码 
ssh -i /home/nvidia/.ssh/id_ed25519_shared \
  -o BatchMode=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes \
  nvidia@192.168.1.228 \
  'mkdir -p /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4'
ssh -i /home/nvidia/.ssh/id_ed25519_shared \
  -o BatchMode=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes \
  nvidia@192.168.1.168 \
  'mkdir -p /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4'

rsync -aH --partial --info=progress2 \
  --exclude='deploy/' --exclude='.image-staging/' --exclude='._____temp/' \
  --exclude='.msc' --exclude='.mv' \
  -e 'ssh -i /home/nvidia/.ssh/id_ed25519_shared -o BatchMode=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes' \
  /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/ \
  nvidia@192.168.1.228:/home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/

rsync -aH --partial --info=progress2 \
  --exclude='deploy/' --exclude='.image-staging/' --exclude='._____temp/' \
  --exclude='.msc' --exclude='.mv' \
  -e 'ssh -i /home/nvidia/.ssh/id_ed25519_shared -o BatchMode=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes' \
  /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/ \
  nvidia@192.168.1.168:/home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/

这些排除项确保模型同步不会复制 deploy/nodes/*.env、部署 artifact 或镜像 staging。不要删除排除项，也不要一边 rsync 一边启动模型。

7.3 生产必做：46 个 shard 全量 SHA-256

结构完整不等于内容逐字节一致。spark-6 生成 manifest：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4
(
  sha256sum model.safetensors.index.json
  find . -maxdepth 1 -type f -name 'model-*.safetensors' -print0 \
    | sort -z \
    | xargs -0 sha256sum
) > /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4.sha256

scp -i /home/nvidia/.ssh/id_ed25519_shared \
  -o BatchMode=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes \
  /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4.sha256 \
  nvidia@192.168.1.228:/home/nvidia/workspaces/models/
scp -i /home/nvidia/.ssh/id_ed25519_shared \
  -o BatchMode=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes \
  /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4.sha256 \
  nvidia@192.168.1.168:/home/nvidia/workspaces/models/

spark-7、spark-8 分别验证：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4
sha256sum -c /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4.sha256

这会完整读取约 168 GB，需要较长时间。当前集群尚未完成这项生产 Gate。

8. 分发部署包并准备固定镜像

8.1 同步非秘密部署文件

在 spark-6 执行：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4

rsync -a \
  --exclude='nodes/*.env' --exclude='artifacts/' \
  --exclude='benchmarks/results/' --exclude='benchmarks/snapshot-*' \
  --exclude='benchmarks/*.json' --exclude='**/__pycache__/' \
  -e 'ssh -i /home/nvidia/.ssh/id_ed25519_shared -o BatchMode=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes' \
  deploy/ \
  nvidia@192.168.1.228:/home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy/

rsync -a \
  --exclude='nodes/*.env' --exclude='artifacts/' \
  --exclude='benchmarks/results/' --exclude='benchmarks/snapshot-*' \
  --exclude='benchmarks/*.json' --exclude='**/__pycache__/' \
  -e 'ssh -i /home/nvidia/.ssh/id_ed25519_shared -o BatchMode=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes' \
  deploy/ \
  nvidia@192.168.1.168:/home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy/

nodes/*.env 是秘密文件，不能用通配同步到错误节点。artifacts/、历史 benchmark 结果、snapshot 和诊断也可能包含敏感主机或业务信息，因此一并排除；只同步运行代码、模板和非秘密文档。

8.2 验证 Docker 能力

三台分别执行：

bash 复制代码 
docker version
docker compose version
docker info
nvidia-smi

若普通用户无权限，按既定管理员策略使用 sudo。不要为了省事改变安全边界，也不要在已通过的系统上临时升级 Docker、Compose 或 Container Toolkit。

8.3 拉取固定基础镜像

至少在 spark-6 拉取精确 digest：

bash 复制代码 
docker pull \
  nvcr.io/nvidia/sglang@sha256:4e2c6f610dca57dd26af9c3045d1935a11d185903cec060d11cec061de2b62f0

docker image inspect \
  nvcr.io/nvidia/sglang@sha256:4e2c6f610dca57dd26af9c3045d1935a11d185903cec060d11cec061de2b62f0 \
  --format 'id={{.Id}} platform={{.Os}}/{{.Architecture}}'

期望基础 config ID 是 sha256:4f5f4cade...45a1，平台为 linux/arm64。不要只使用会漂移的 26.07-py3 tag。

8.4 构建并分发 Responses 兼容派生镜像

脚本只在 spark-6 构建一次，通过直接 RoCE 链路传给两台 worker，并校验 archive 与最终 image ID。它不会上传或扫描 168 GB 模型目录。

注意：这个构建脚本直接调用 docker，不使用其他部署脚本里的 sudo -n docker 自动选择。必须由同时能直接执行 Docker、能读取共享 SSH key、且能写 .image-staging/derived 的受信账户运行。先检查：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4
docker info >/dev/null
test -r /home/nvidia/.ssh/id_ed25519_shared
mkdir -p .image-staging/derived
test -w .image-staging/derived

当前现场该 staging 由 root 管理，因此应继续用受控 root shell 构建；不要为了绕过权限执行宽泛 chmod 777 或改变整个模型目录 owner。

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4
bash deploy/image/build-and-distribute.sh

通过条件：

  • spark-7、spark-8 都打印 PASS: ... loaded ...。
  • 最终打印的 DERIVED_IMAGE_ID 在三台相同。
  • 当前预期 ID 为 sha256:43e76a532b12365232231d0bff2f63b79744f0042a016f04b8d5f7c27bf20386。

三台可只读复核：

bash 复制代码 
docker image inspect \
  sha256:43e76a532b12365232231d0bff2f63b79744f0042a016f04b8d5f7c27bf20386 \
  --format 'id={{.Id}} platform={{.Os}}/{{.Architecture}}'

如果重建结果不是预期 ID，不要直接修改 .env 接受它；先检查基础 digest、补丁 SHA、Dockerfile 和构建上下文差异。

9. 创建每台自己的 .env

9.1 安全原则

  • 三台使用同一个 API key，但每台保留自己的 rank、hostname、管理 IP 和 cache 路径。
  • API key 至少 32 字符，建议在可信终端用 openssl rand -hex 32 生成一次并存入密码管理器。
  • 不要把真实 key 写在 Shell 历史、聊天、Git 或文档中。
  • .env 必须位于 deploy/nodes/，不能是 symlink，权限必须为 0600，owner 必须为可信的 root 或 nvidia。
  • dotenv 每行采用 KEY=value，单行且不加引号。

9.2 创建文件和 cache

三台分别执行：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
umask 077
node_env="nodes/$(hostname).env"
test ! -e "${node_env}" || {
  echo "REFUSE: ${node_env} already exists; review and edit it in place" >&2
  exit 1
}
install -m 600 "${node_env}.example" "${node_env}"
mkdir -p /home/nvidia/workspaces/cache/deepseek-v4/$(hostname)

如果实际 .env 已存在，不要重跑创建命令或覆盖它；先确认 owner/mode，再用可信编辑器只修改计划中的字段。

然后用可信的交互编辑器打开本机文件：

bash 复制代码 
${EDITOR:-nano} nodes/$(hostname).env

只把模板中的 API key 占位符替换为三台相同的真实 key。不要把 key 粘贴到本教程示例中。

9.3 最终公共参数

三份 .env 的这些值必须一致：

dotenv 复制代码 
COMPOSE_PROJECT_NAME=deepseek-v4-pp3
MGMT_IFNAME=enP7s7
SERVER_PORT=8000
DIST_INIT_ADDR=192.168.1.128:25001
SGLANG_IMAGE=sha256:43e76a532b12365232231d0bff2f63b79744f0042a016f04b8d5f7c27bf20386
SGLANG_API_KEY=REPLACE_WITH_A_SECRET_VALUE
SERVED_MODEL_NAME=deepseek-v4-flash
MODEL_DIR=/home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4
PP_LAYER_PARTITION=14,14,15
MEM_FRACTION_STATIC=0.57
MAX_TOTAL_TOKENS=1579520
CONTEXT_LENGTH=12288
CHUNKED_PREFILL_SIZE=4096
MAX_PREFILL_TOKENS=4096
MAX_RUNNING_REQUESTS=8
CUDA_GRAPH_MAX_BS_DECODE=4
WATCHDOG_TIMEOUT=1800
NCCL_DEBUG=INFO
REQUIRE_SYNC_CLUSTER=1
MIN_MEM_AVAILABLE_GIB=100

节点专属字段：

节点 EXPECTED_HOSTNAME NODE_RANK MGMT_IP / SERVER_HOST CACHE_DIR
spark-6 spark-6 0 192.168.1.128 .../cache/deepseek-v4/spark-6
spark-7 spark-7 1 192.168.1.228 .../cache/deepseek-v4/spark-7
spark-8 spark-8 2 192.168.1.168 .../cache/deepseek-v4/spark-8

实际模板已经包含正确的节点字段：spark-6 模板、spark-7 模板、spark-8 模板。不要从 spark-6 复制整份 .env 覆盖 worker。

10. 执行三层预检

10.1 单机预检和镜像冒烟

三台分别执行：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
./scripts/preflight.sh nodes/$(hostname).env
./scripts/container-smoke.sh nodes/$(hostname).env

它们会检查 hostname/rank/IP、Docker/Compose、固定镜像、API key 是否设置但不显示内容、46 个模型分片、cache、可用内存和 swap、时间同步、Ring、HCA、200 Gb/s、RDMA device，以及容器内 GB10 (12,1)、CUDA/NCCL 和 DeepSeek V4 hook。

任何 [FAIL] 都是阻断项。不要用 REQUIRE_SYNC_CLUSTER=0 跳过正式网络验收。

10.2 三机一致性门禁

只在 spark-6 执行：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
./scripts/cluster-preflight.sh

期望最后输出：

text 复制代码 
PASS: ranks are unique and all common image, secret-hash, runtime, and model-index fields match

脚本只显示 api_key=matched-hidden，不会输出 key 或其 hash。它比较三机镜像、秘密一致性、运行参数、index hash、shard 数和总字节。

10.3 最终容器 NCCL Gate

模型启动前，从 spark-6 使用协调脚本。该 smoke 会在三张 GPU 上另起 512 MiB collective；绝不能与已经加载的模型或其他 GPU 任务并行。若模型曾启动过，先协调停止，并在三机确认没有 compute process：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
./scripts/cluster-down.sh
nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv
ssh -i /home/nvidia/.ssh/id_ed25519_shared -o BatchMode=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes \
  nvidia@192.168.1.228 \
  'nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv'
ssh -i /home/nvidia/.ssh/id_ed25519_shared -o BatchMode=yes -o IdentitiesOnly=yes -o StrictHostKeyChecking=yes \
  nvidia@192.168.1.168 \
  'nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv'
./scripts/cluster-nccl-smoke.sh

脚本会同时启动三个 rank，使用相同 run ID，对每个 rank 做 512 MiB tensor、5 轮预热、20 轮 all-reduce 和数值校验。

通过条件：

text 复制代码 
CLUSTER_NCCL_SMOKE PASS ranks=0,1,2 transport=IB ...

同时每个日志必须包含 NET/IB HCA 选择，不能出现 Socket 数据面、unknown event type、NCCL ERROR、Traceback 或数据错误。NCCL 2.30.7 在本平台每个 HCA 可能有一条固定的 ibv_query_port_speed ... errno 93 能力查询 warning；验收器只允许这一条精确 warning，其他 warning 仍会失败。

当前容器 NCCL 功能/NET-IB Gate 已通过，但曾观察到约 6.4 ppm 已恢复 adaptive retrans；严格零增量 production clean burn-in 仍待完成。证据见 NCCL 验收记录。

11. 启动三节点模型

11.1 协调启动

生产部署先在 spark-6 安装一次开机协调单元：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4
sudo deploy/systemd/install.sh --now

以后开机由 deepseek-v4-pp3.service 等待三台节点和 RoCE 就绪后整组启动；

Prometheus/Grafana 与 WebUI 分别由 dsv4-monitoring.service、dsv4-ui.service

确认健康。详细边界见 systemd 开机协调说明。手工维护时才在

spark-6 执行：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4
bash deploy/scripts/cluster-up.sh

脚本先执行集群一致性门禁，再并发调用三台 node-up.sh。每个节点又会重新运行单机预检和容器冒烟；任意节点失败时，控制器会请求停止整个 PP group。

不要手工启动三份互不相关的 docker run，也不要只重启一个 rank。

11.2 等待真正就绪

首次加载约 168 GB 权重、建立 DSV4 内存池和捕获 CUDA Graph 需要数分钟。"容器 Running"不等于模型 Ready。在 spark-6 执行：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
./scripts/wait-ready.sh nodes/spark-6.env

默认最多等待 3600 秒。成功会输出：

text 复制代码 
Rank 0 API is ready: http://192.168.1.128:8000

11.3 检查状态和脱敏日志

在各节点：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
./scripts/node-status.sh nodes/$(hostname).env
./scripts/node-logs.sh nodes/$(hostname).env --no-follow

node-logs.sh 会脱敏 API key。不要直接对外复制原始 docker logs，SGLang 的启动参数可能包含服务凭据。

12. 验证 API 和模型语义

12.1 一键 API 验收

在 spark-6 执行：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
./scripts/verify-api.sh nodes/spark-6.env

它会检查：

  • /health 和执行真实 forward 的 /health_generate；
  • /v1/models 中的 deepseek-v4-flash；
  • 确定性数值语义，不只检查 HTTP 200；
  • Chat Completions SSE 流式结束标记；
  • DeepSeek V4 reasoning_content；
  • function tool-call 解析。

最后必须看到：

text 复制代码 
PASS: all DeepSeek V4 API verification gates

测试响应写入权限为 0700 的临时目录，脚本退出时删除。不要把 prompt、生成内容或 Authorization header 写入长期日志。

12.2 Agent 协议验收

在 spark-6 安全加载本机 .env，再运行协议探针：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4
source deploy/scripts/lib.sh
load_env nodes/spark-6.env
python3 deploy/integrations/verify_agent_endpoints.py

期望：

text 复制代码 
PASS chat-completions
PASS responses-sse-completed
PASS anthropic-messages
PASS all-agent-endpoints

脚本不会把 prompt、输出、header 或 /server_info 写入磁盘。

13. 接入 Codex、OpenClaw 和 DeepSeek Harness

通用后端信息：

text 复制代码 
Base URL: http://192.168.1.128:8000/v1
Model: deepseek-v4-flash
API key: 从 SGLANG_API_KEY 环境变量读取
Server context: 12288
生产输入 cap / compact threshold: 8192
客户端配置允许的输出上限: 4096（不能与 8192 输入同时吃满）

硬规则是 实际序列化后的 prompt tokens + max_output_tokens <= 12288，其中 prompt 已包含 chat template、system、tool schema、工具结果和历史消息。网关应使用服务 tokenizer 计数后再准入，并额外保留模板/协议余量；若输入接近 8192，就必须相应降低最大输出。

13.1 Codex

参考 Codex 配置模板，把其中片段合并进 Codex 配置，而不是覆盖已有的无关配置。关键项：

toml 复制代码 
model = "deepseek-v4-flash"
model_provider = "spark_sglang"
model_context_window = 12288
model_auto_compact_token_limit = 8192

[model_providers.spark_sglang]
base_url = "http://192.168.1.128:8000/v1"
env_key = "SGLANG_API_KEY"
wire_api = "responses"

先在启动 Codex 的受控 shell 或 credential manager 中提供 SGLANG_API_KEY。不要把值写进 TOML。Codex 需要 Responses API，因此必须使用本文的派生兼容镜像。

13.2 OpenClaw

参考 OpenClaw 配置模板。当前经过验证的 provider 是：

text 复制代码 
api: openai-completions
contextWindow: 12288
maxTokens: 4096
apiKey: ${SGLANG_API_KEY}

复制模板不会、也不应该自动启动 OpenClaw。当前三台 OpenClaw service 均保持 disabled/inactive；只有用户以后明确要求在指定主机运行时，才另行启用。若 OpenClaw 部署在别的 Agent 主机，只需让该主机能访问受保护的 API。

13.3 DeepSeek Harness

DeepSeek Harness 模板仅供实验室评估。官方项目仍是 Developer Preview，没有稳定发布版，因此当前不安装、不作为生产依赖。若以后评估，必须固定准确 RC 或 commit，仍从 SGLANG_API_KEY 读取秘密，并单独完成功能和资源验收。

13.4 多 Agent 的生产入口

当前后端 key 是服务凭据，不是多租户权限系统。端口 8000 只应暴露在可信管理网。多用户或跨网访问时，在 API 前增加独立 TLS 反向代理或网关，并实现：

  • 每客户端身份认证和独立凭据；
  • 最大输入 8192 token；
  • 默认并发 4、后端总在途不超过 8；
  • 长上下文请求并发 1；
  • 请求速率和排队上限；
  • 超时、取消和审计日志脱敏；
  • /health、/metrics 和管理端点的网络 ACL。

当前 <=0.10/0.20/0.30 req/s 结论只来自 256 input / 128 output 合成请求：该形状建议从 <=0.10 req/s 的交互稳态开始，0.20 req/s 只用于允许短队列的流量，0.30 req/s 已进入明显的尾延迟拐点。真实 tool schema、8K prefill、reasoning 或长输出必须按代表性请求重测，不能直接套用这些 rate。

14. 日常运维

14.1 状态检查

各节点：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
./scripts/node-status.sh nodes/$(hostname).env

重点观察：容器是否 running、OOMKilled=false、restart/exit、可用内存、swap、GPU 温度和功耗、四个 RoCE 接口是否 Up。

14.2 安全查看日志

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
./scripts/node-logs.sh nodes/$(hostname).env --no-follow

需要持续跟随时去掉 --no-follow。生产稳态可在经过一次重启验收后把 NCCL_DEBUG=INFO 调整为 WARN，但参数变更必须三台一致并协调重启。

14.3 收集诊断

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
./scripts/collect-diagnostics.sh nodes/$(hostname).env

脚本会采集 OS、Docker、GPU、内存/PSI、路由、RDMA、链路计数、模型结构、Compose、容器和日志，并尽力脱敏 API key。诊断包仍可能包含主机、网络、prompt 或其他敏感信息；发送给第三方前必须人工审阅。

14.4 变更参数

一次只改变一个变量，三台 .env 同步修改，先停止整个集群，再重启并重跑 API、资源和 benchmark Gate。不要同时改 context、mem fraction、MRR 和 CUDA Graph，否则无法判断收益或故障来源。

以下最终参数未经新的隔离测试不得提高：

text 复制代码 
MEM_FRACTION_STATIC=0.57
MAX_TOTAL_TOKENS=1579520
CONTEXT_LENGTH=12288
MAX_RUNNING_REQUESTS=8
CUDA_GRAPH_MAX_BS_DECODE=4
CHUNKED_PREFILL_SIZE=4096
MAX_PREFILL_TOKENS=4096

只有 Graph4 是当前冻结配置完成过最终验收的值；未经新的隔离 A/B，不要提高到 Graph8。这不妨碍 Server 接受最多 8 个在途请求，C5--C8 只是不能保证命中已捕获的 Graph batch。

15. 停止、重启和回滚

15.1 协调停止

只在 spark-6 执行：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4
bash deploy/scripts/cluster-down.sh

脚本并发停止三台并保留脱敏日志。不要只停止或重启一个 rank。

15.2 协调重启

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4
bash deploy/scripts/cluster-down.sh
bash deploy/scripts/cluster-up.sh
bash deploy/scripts/wait-ready.sh nodes/spark-6.env
bash deploy/scripts/verify-api.sh nodes/spark-6.env

最后两条若从模型根目录运行，路径均有效；脚本会安全解析 deploy/nodes/spark-6.env。

15.3 应用层回滚

部署失败时：

  1. 用 cluster-down.sh 停止三 rank。
  2. 保留 deploy/artifacts/、诊断和镜像，不执行 docker system prune。
  3. 模型是只读挂载，容器失败不会修改权重。
  4. 保持 OpenClaw、display manager、GNOME remote desktop 为 disabled/inactive。
  5. 恢复上一个已经验收的三机同一 .env 和 image ID，再协调启动。
  6. 旧 MiniMax 镜像与配置可以单独保留，但不要把它的模型参数混入本部署。

15.4 网络回滚

网络回滚与应用回滚不同，存在远程失联风险。参照第 5.3 节，只能在有管理 SSH 保护或本地控制台时操作，并优先使用 NVIDIA Sync UI。不能执行宽泛删除命令，也不能把模型目录、工作区根目录作为清理目标。

16. 常见故障排查

现象 最可能原因 正确处理
preflight 报多个 169.254/16 旧重叠 IPv4LL 路由仍在 回到 Cluster Assistant/Netplan Ring，不用手写 HCA 绕过
TCPStore No route to host 管理网、端口或 dist-init 错误 确认 enP7s7 和 192.168.1.128:25001
NCCL 只有 Socket RoCE 没有被最终容器发现 停止部署，查 Sync 计划、HCA、/dev/infiniband 和日志
unknown event type (18) 旧 NCCL/旧镜像或 RDMA 异常 核对派生 image ID、NCCL 2.30.7、mlx5 日志
no kernel image / SM121 unsupported 镜像依赖被覆盖 核对固定镜像，移除 pip overlay；保留日志后上报
trtllm_batched_gemm_runner.cu:305 SM121 误入 TRT-LLM routed backend 恢复两个 flashinfer_cutlass 参数并三机协调重启
API 200 但内容为空/BOS BF16 lm_head 被错误量化 恢复 SGLANG_FP8_IGNORED_LAYERS=lm_head，重跑语义 Gate
提高 CUDA Graph BS 后启动失败 新 batch graph/kernel 路径未通过本机验收 回滚 CUDA_GRAPH_MAX_BS_DECODE=4，保留三 rank 日志
启动时 OOM、持续 swap 或 PSI context/mem/并发过高或后台应用占内存 停三 rank，恢复最终参数，确认无后台负载再启动
rank 0 /health 不就绪 某 worker 卡住或退出 同时查看三机 status 和脱敏日志，不只重启 rank 0
工具调用未解析 parser、客户端 schema 或模型配置错误 保持 deepseekv4 tool parser，运行 verify-api.sh
Codex 收不到 response.completed 使用了未打补丁的基础镜像 核对派生 image ID，运行 Agent 协议探针
AER、Xid、HCA reset、link flap 供电、线缆、固件或硬件风险 立即停止压测，保留诊断，检查电源/线缆并安排维护

遇到问题先保存：

bash 复制代码 
cd /home/nvidia/workspaces/models/DeepSeek-V4-Flash-NVFP4/deploy
./scripts/node-status.sh nodes/$(hostname).env
./scripts/node-logs.sh nodes/$(hostname).env --no-follow
./scripts/collect-diagnostics.sh nodes/$(hostname).env

不要以增大 timeout、关闭错误检查、强制 Socket、禁用 RDMA 或提高 swap 的方式把故障"隐藏"为成功。

17. 生产上线前仍未完成的 Gate

当前模型服务和 Agent 协议已经通过受控验收，但以下事项仍需完成才能签署完整生产就绪：

  • 三机在维护窗口完成同一批次 DGX OS、Kernel、Driver 和固件 OTA，并全部重启。
  • OTA 后重新验证管理 IP、Netplan、12/12 rail、三条 200 Gb/s 链路、RDMA、最终容器 NCCL 和模型 API。
  • 执行并验收官方宿主 NCCL 2.30.7-1 helper。
  • 46 个权重 shard 和 index 的全量 SHA-256 manifest 在三台全部通过。
  • 完成严格的零新增硬错误/链路错误生产 burn-in；当前少量已恢复 adaptive retrans 不能称为 clean Gate。
  • 把 API 放在可信管理网 ACL 或 TLS 反向代理后，实施每客户端认证、限流和 8192 token 输入上限。
  • 生产稳态把 NCCL_DEBUG=INFO 调为 WARN，协调重启并重新跑一次 API Gate。
  • 若组织要求恒定负载 soak，另做 30--60 分钟持续代表性负载；现有约 83 分钟记录是多阶段混合监控，不是恒定满载。

生产限额必须保持：

text 复制代码 
输入 cap：8192 tokens
交互默认并发：4
后端最大在途：8
长上下文并发：1
256→128 合成形状建议稳态到达率：<=0.10 req/s
同一形状 0.20 req/s：仅允许短暂排队
同一形状 0.30 req/s：SLA WARN，不作为交互默认
其他真实工作负载：必须重新压测 arrival 曲线

18. 最短验收清单

如果已经完成前面的详细学习，可以用这张表快速复核：

  • 三机 hostname、管理 IP、rank 一一对应。
  • key-based SSH 无交互通过，真实凭据没有进入 Git/文档。
  • 三机模型路径相同，index 引用 46 个 shard。
  • 六子网 Ring 无重叠 IPv4LL，四个逻辑 HCA/node Up，物理链路 200 Gb/s。
  • 宿主 NCCL helper 通过。
  • 三机拥有相同派生 image ID sha256:43e76a...20386。
  • 三份 .env 权限 0600，公共运行参数和秘密匹配，rank 字段不同。
  • 单机 preflight、container smoke、cluster preflight 全部通过。
  • cluster-nccl-smoke.sh 三 rank 为 NET/IB 且数据正确。
  • cluster-up.sh 成功，wait-ready.sh 返回 Ready。
  • deepseek-v4-pp3、dsv4-monitoring、dsv4-ui 均为 enabled/active；三机 Docker 均 enabled，模型 rank 的 Docker restart policy 仍为 no。
  • verify-api.sh 和 verify_agent_endpoints.py 全部 PASS。
  • Gateway/客户端限制生产输入 8192、默认并发 4、最大在途 8。
  • OpenClaw、桌面和 GNOME remote desktop 仍为 disabled/inactive。
  • OTA、全量 shard hash、TLS/ACL 和生产 clean burn-in 已完成。

19. 相关资料索引

仓库内资料：

上游资料：

完成本教程不代表可以跳过变更管理。任何 OTA、网络、镜像、模型、context、内存比例、并发或 CUDA Graph 变更，都会使相关历史 PASS 失效，必须按对应 Gate 重新验证。

相关推荐
starzy19901 小时前
SparkStreaming 之 updateStateByKey 算子详解及代码实现
大数据·spark
爱吃面的猫1 小时前
大数据Hadoop之——集群环境搭建（了解）
大数据·hadoop·flume
故七月1 小时前
生成式引擎优化（GEO）的底层逻辑与产业实践
大数据·人工智能·机器学习
阿里云云原生2 小时前
企业级实时数据平台建设：利用存算分离 Kafka 实现低成本、高可靠入湖
分布式·阿里云·云原生·kafka
国科安芯2 小时前
星载CANFD总线通信网络中抗辐射微控制器MCU的失效机理与容错设计研究
网络·人工智能·分布式·单片机·嵌入式硬件·架构·抗辐射加固
zcmodeltech2 小时前
污水处理设备沙盘模型控制系统设计与实现：多单元协同联动方案
网络·分布式·stm32·单片机·嵌入式硬件·交互
KKKlucifer2 小时前
异构融合与大规模割接——某电信运营商融合4A平台建设实践
大数据·网络·人工智能·安全
GIR7202 小时前
重构全球关节腔内注射物行业竞争格局：市场占有率、销量排名及主要竞争对手分析
大数据·人工智能
故七月2 小时前
让AI“看见”好服务——生成式引擎优化（GEO）的底层逻辑与产业实践
大数据·人工智能·机器学习
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点032026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？04历年考研数学一、数学二、数学三真题试卷及答案PDF05微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新06Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费07AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路08VSCode+CodeX扩展，无法启动09如何新建文件夹？ 电脑新建文件夹的4种方法102026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片