这是一篇事故复盘，不是操作手册。
前提很简单：严格照着 NVIDIA 官方教程做，走热点方式初始化------结果卡在第一次系统更新上，界面不报错，后续所有操作连崩，最后被迫重装系统。重装完又踩了一轮坑，网络换了三种方案才彻底跑通。
下面按事情发生的顺序还原，最后给根因和"如果重来"的措施。
一句话概括
DGX Spark 的首启向导只要网络一通，就会立刻开始下载完整系统镜像并升级；如果网络访问 NVIDIA 仓库受限，这一步会失败但不报错，机器从此处于"看起来正常、实际半残"的状态。 我们在这个状态下继续配了远程访问、装了软件，全部失败，只能重装------而重装的坑（外设、UEFI、启动盘）一个比一个硬。
一、为什么会走到重装这一步（因果链）
把它画成一条链，比看十个现象都清楚：
网络能上网 ≠ 能连 NVIDIA 仓库 → 首启向导通网即触发自动更新 → 更新中途失败 → 界面不提示 → 机器停在"半初始化"状态 → 后续 SSH / 服务 / NVIDIA Sync 全部异常 → 判断系统已损坏 → 重装 → 重装后网络问题依旧 → 换网络方案 → 才真正跑通。
这条链上真正的开关只有一个：升级那一步失败且无声。后面所有事都是它的下游。
二、第一现场：一次"看起来正常"的初始化
当时做对了什么
- 只接了电源，按下开机键（这机器不会通电自启），用自带的 Wi-Fi 热点方式初始化------干净、不用摆显示器键盘。
- 热点 SSID 和密码就在包装里 Quick Start Guide 的贴纸上，连上去后浏览器弹出配置页，一路顺利。
这一步走完，主观感受是"很顺"。
埋雷的地方
官方 First Boot 把"下载并安装完整软件镜像"写成了向导的一个步骤，容易让人以为它和前面选时区、建账号是同一性质的事。实际上它是整个流程里唯一有风险的一步：
- 走热点方式时，网络一配通（Wi-Fi 连上）就立刻开始，没有"先测一下网络再更新"的确认；
- 这一步开始后不可中断，官方明确警告断电可能损坏系统；
- 而它的失败不会在界面上体现。
最要命的组合
热点方式初始化意味着：机器没接显示器、没有键盘，你看不见它。升级悄悄失败时，你没有任何本地途径察觉------只能靠远程行为反推。
现在回头看，这就是那次事故的全部前提：把有风险的一步，放到了一个看不见的过程里，并且没有事先验证网络。
三、事故扩大：从"有点怪"到"全面异常"
升级失败后的症状不是一次性爆发，而是逐步蔓延的，所以特别容易被误判成"某个配置没做对"：
| 现象 | 当时的第一反应 | 真实原因 |
|---|---|---|
| 某些命令/软件缺失 | 以为要手动装 | 完整镜像没装上 |
| SSH 行为异常 | 以为密钥/账号问题 | 系统状态不完整 |
| 服务起不来 | 以为服务配置写错 | 同上 |
| NVIDIA Sync 连不上 | 以为网络不通 | 设备端进程根本没正常跑起来 |
这里最值得记住的一条：NVIDIA Sync 连不上，是系统状态异常的信号，不只是网络问题。同样操作在正常机器上是秒连的。
另外还有一个当时没意识到的点：热点方式下机器没接显示器，等于放弃了唯一一个"能直接看到报错"的通道。等到怀疑系统有问题时，已经没有任何本地可见性。
四、判定：为什么最后选择重装
半初始化状态的系统，排查成本极高：你不知道缺了什么、也不知道哪一层坏了。当时的判断是：
- 更新过程本身不可中断，失败后留下的状态不可信；
- 逐项修补的收益远低于重来一次；
- 官方本来就把 System Recovery 列为兜底路径。
于是决定重装。
事后看这个决定是对的，但有一个前提没做到：重装前没有先解决网络。 这直接导致重装后同一堵墙又撞了一次。
如果只能给一条建议：判定"系统坏了"之后，先解决"当初为什么会坏"，再动手重装。 否则只是把同一个失败重演一遍。
五、重装过程：坑全集中在这一天
重装是这次事故里最耗时的部分，而且所有外设相关的坑都爆发在这个阶段------因为首启时根本没接过外设。
1. 恢复介质不是"最新系统"
官方 First Boot 建议"没有稳定连接就先下载恢复介质，用 System Recovery 装最新系统"。这条不能照字面信：
- 官方 System Recovery 文档写的是恢复到出厂状态；
- 恢复介质是出厂镜像，不保证最新，装完照样要联网再更新一轮。
所以恢复介质只能救"系统坏了"，治不了"网络连不上 NVIDIA"------重装完还是同一堵墙。
2. 4 个 USB-C 口，重装时刚好占满
首启只需一个电源口，毫无压力；重装要同时接电源、U 盘、显示器、键盘，正好塞满 4 个 C 口，一个余量都没有。
建议显示器优先走 HDMI 2.1a，能省出一个口应急。
3. 进不去 UEFI：键盘"启动慢半拍"
重装必须先改 UEFI 启动项，而按 Esc/Del 死活进不去------因为高级键盘自身有启动过程，按下开机键那一刻它还没准备好，键值没被捕获。
两条出路，第二条是救命的：
bash
sudo systemctl reboot --firmware-setup--firmware-setup是systemctl reboot的选项，作用是让固件下次启动进 setup 界面；- 它不是
systemctl firmware setup这种子命令（网上流传的写法是错的）； - systemd v220 起提供，但并非所有固件都支持 ------不支持就退回"普通 USB 键盘直插 + 按下开机键瞬间按
Esc/Del"。
4. 启动盘做完，还是进了原系统
按官方流程做启动盘（恢复镜像解压后用自带脚本：Windows CreateUSBKey.cmd、Linux CreateUSBKey.sh、macOS CreateUSBKeyMacOS.sh），UEFI 里 Restore Defaults → Boot Override 选 U 盘，结果仍然进了原系统。
原因是 Secure Boot 。处理：Security → Secure Boot 设为 Disabled → 保存重启 → 再进 UEFI 用 Boot Override 引导。
这里有个容易记反的地方：系统重装完成后，Secure Boot 会自动重新打开 ，不需要你手动去开。反过来说------下次想再从 U 盘引导，就得再关一次。也就是说"关 Secure Boot"不是一次性动作，而是每次走恢复介质前的固定前置步骤。
5. 重装 ≠ 结束
装完系统出来的是出厂状态，还得再跑一轮更新------也就是又回到了那个"通网即自动更新"的环节。网络问题没解决之前，这一步依然是雷。
六、重装之后：以为结束了，其实没有
重装完成、系统能进，问题看起来解决了。但接下来是一段更长的拉锯。
第一轮：Tailscale 打通 + exit node
思路很自然：用 Tailscale 把网络打通，设置 exit node 走能访问 NVIDIA 仓库的出口。
结果：基础访问恢复了，但安装 AI Workbench 这类软件仍然不顺利。
为什么 exit node 不够
- exit node 只接管设定走该出口的流量 ；容器拉镜像（
nvcr.io）、fwupdmgr、Dashboard 更新服务可能走不同路径，或走不同 DNS； - 大体积镜像对链路稳定性极敏感，间接链路的抖动和超时 会让
docker pull反复失败； - 结论："能打开网页"不等于"能完成一次干净的软件安装"。
第二轮：把出口下沉到路由器级别
最后把出口下沉到路由器级别：不作设备级分流，整机所有流量统一走一条能稳定直连 NVIDIA 官方仓库的线路------AI Workbench 等软件终于顺畅装完。
这是整件事里投入产出比最高的一步：与其在设备上折腾各种分流，不如让出口对整机一致。
七、根因复盘
1. 把"能上网"当成了"能连 NVIDIA"
这是最根本的误判。DGX 的初始化、更新、恢复、镜像拉取，全部依赖 NVIDIA 自有域名和 nvcr.io。办公室网络日常上网毫无问题，但访问这些源受限------而这在初始化界面上完全看不出来。
2. 官方文档有两处会误导人
- "设备一通电就会启动"------实际要按开机键 ，而且机身没有指示灯，从外观根本判断不出开没开机；
- "没有稳定连接就先下恢复介质装最新系统"------恢复介质是出厂镜像，不是最新版，装完还得联网更新。
官方文档也需要交叉验证：First Boot 和 System Recovery 两页自相矛盾，前者说"装最新"，后者说"恢复出厂"。
3. 有风险的一步没有前置检查
向导把"下载完整镜像"包装成一个普通步骤，用户没有任何"先验证网络"的介入点。而这一步不可中断、失败无声。
4. 放弃了本地可见性
热点方式初始化很优雅，但代价是没有显示器。一旦出问题，连"看一眼屏幕"这个最基本的排查手段都没有。
5. 重装前没先解决根因
这是流程上的失误：系统坏了就重装，但**"为什么会坏"没动**，所以重装后立刻又撞上同一个问题。
八、如果重来一次
- 先验证网络，再按开机键。 在任意同网段电脑上测：
docs.nvidia.com、developer.nvidia.com、nvcr.io/v2/、archive.ubuntu.com。任一项不通，先解决出口，不要开始初始化。 - 把"最近能上网的办公室网络"当成高风险环境。 初始化、更新、装软件这三件事对出口的要求比浏览网页高得多。
- 首启阶段就想好失败后的可见性。 至少要有一个能 SSH 进去的通道；热点方式初始化后，第一时间确认 SSH 可用，而不是等配完一堆东西才发现连不上。
- 看到 NVIDIA Sync 连不上，先怀疑系统状态。 那是"改坏了"的信号，不是"网络差"的信号。
- 重装前先修根因。 恢复介质是出厂镜像，重装完仍要联网更新，网络这一关躲不掉。
- 出口尽量做成整机一致。 路由器级最省心；设备级分流（exit node 之类）只能解决部分流量，容易在容器和大文件下载上翻车。
- 外设提前想清楚。 重装需要电源 + U 盘 + 显示器 + 键盘，正好 4 个 C 口；显示器改走 HDMI 留余量，键盘用最普通的 USB 有线键盘（高级键盘可能来不及响应
Esc/Del）。
九、官方流程怎么走（对照用）
事故之后重新捋了一遍官方路径，它本身没问题，问题在于隐式前提：
| 官方步骤 | 隐含前提 | 我们踩的坑 |
|---|---|---|
| 选择接入方式（本地 / 网络设备） | 无 | 选热点方式 → 失去本地可见性 |
| 通电、按开机键启动 | 有指示灯？没有 | 无指示灯，不知道开没开 |
| 配置网络 | 网络能访问 NVIDIA | 能上网，但访问 NVIDIA 受限 |
| 下载并安装完整镜像 | 网络稳定且可达 | 中途失败，界面无提示，不可中断 |
| 完成后用 NVIDIA Sync / Dashboard 接入 | 系统处于完整状态 | 系统半残，NVIDIA Sync 连不上 |
| 系统更新（Dashboard 优先） | 能访问 NVIDIA 源 | 系统无国内镜像，Ubuntu 源不能顶替 |
| 出问题走 System Recovery | 恢复后即可用 | 恢复介质是出厂镜像，仍需联网更新 |
另外几条官方细节，事后看都很关键：
- 更新优先用 DGX Dashboard ；手动更新是
sudo apt update→sudo apt dist-upgrade→sudo fwupdmgr refresh→sudo fwupdmgr upgrade，不是裸apt upgrade（我们一开始就用了apt upgrade，把系统更新搞出了问题）。 - DGX OS 没有国内镜像，docker / HuggingFace 有，系统层没有，也不能简单换成 Ubuntu 源。
- NVIDIA Sync 配置的 Tailscale 会出现两个实例，生成一次性 token 要准备两个；手动给 SSH 配的 Tailscale 也遇到过网络不通。
十、后记：最终跑起来的样子
网络彻底理顺之后，后面的部署反而很平淡：
- 先单机用 Ollama 部署小模型，验证通过；
- 再用 vLLM 部署 Qwen3.8-27B ，可正式使用：内存占用约 85/128 G ，GPU 使用率约 96%；
- 推荐模型是 DeepSeek V4.1 Flash 量化版；
- 组网时注意：QSFP 线缆直连只能连 3 台 ，4 台官方推荐用交换机；4 台用线缆成环也能跑，但对角需中转，社区实测性能损失约 5%，交换机价格约 2～3 万元，可发挥 100% 性能。
回头看，整件事的教训可以用一句话收尾：
DGX Spark 的初始化，真正的前置条件不是"有没有显示器""会不会敲命令"，而是"这台机器能不能干净地连上 NVIDIA"。这一条不成立，后面每一步都会以你看不见的方式失败。