美国GPU服务器上的A100 80GB重启后，物理显卡仍能被识别，业务却报“找不到CUDA设备”，此时GPU利用率为零并不能证明硬件故障。如果nvidia-smi -q显示MIG模式已开启，而GI、CI列表为空，应优先检查systemd是否执行了实例恢复，而不是反复开启MIG模式。

A100属于Ampere架构，MIG模式通常可以跨重启保持，但GI、CI实例布局需要在重启后重新创建。对于由systemd管理的Linux主机，排查入口是：用nvidia-smi区分模式与实例状态，检查恢复服务的启动配置和本次启动日志，再通过一次不手工补建实例的重启验收自动恢复链。

先判断丢失的是模式、实例，还是业务设备绑定

MIG模式、GI和CI不是同一个验收对象：GPU Instance（GI）划分GPU资源，Compute Instance（CI）在GI内划分计算资源。模式开启只是前提，预期GI、CI存在且业务能够访问，才算恢复完成。

以下只读检查适用于已安装NVIDIA驱动、采用systemd的Linux美国GPU服务器，无须先停止业务：

command -v nvidia-smi
nvidia-smi --query-gpu=index,uuid,name,pci.bus_id --format=csv
nvidia-smi -L

确认设备确为目标A100 80GB，记录物理GPU UUID。后续不要仅依赖GPU索引，避免多卡主机重启后索引变化导致操作错卡。将GPU-xxxxxxxx替换为实际值：

nvidia-smi -i GPU-xxxxxxxx -q
nvidia-smi mig -i GPU-xxxxxxxx -lgi
nvidia-smi mig -i GPU-xxxxxxxx -lci

Current为Enabled才表示当前模式已开启；Pending与Current不一致，表示存在待生效变更。nvidia-smi -L显示MIG设备只能证明设备枚举结果，不能证明业务有权访问，也不能证明性能达标。

验收前还应保存目标布局：GI、CI数量、Profile及对应关系。Profile以当前设备和驱动实际提供的列表为准：

nvidia-smi mig -i GPU-xxxxxxxx -lgip
nvidia-smi mig -i GPU-xxxxxxxx -lcip

CI Profile查询依赖GI上下文；尚未创建GI时，不能把无法列出CI Profile直接判断为硬件异常。需要限定GI时，可通过nvidia-smi mig --help核对当前版本的-gi用法。不要直接套用其他型号或历史配置中的Profile数字ID。

检查systemd：服务启用不等于实例恢复成功

典型故障是管理员手动创建过实例，却没有启用恢复服务；或者服务执行成功，但脚本只包含-mig 1，没有创建GI、CI。

先查找实际恢复入口：

systemctl list-unit-files --type=service | grep -Ei 'mig|nvidia'
sudo grep -RInE 'nvidia-smi|mig-parted' \
  /etc/systemd/system /usr/lib/systemd/system /lib/systemd/system \
  /etc/rc.local /etc/cron.d /usr/local/sbin 2>/dev/null

部分系统没有上述某些目录，不代表MIG异常；名称搜索也可能遗漏自定义服务，应结合部署记录核对。找到服务后，以下以mig-restore.service为例：

systemctl cat mig-restore.service
systemctl is-enabled mig-restore.service
systemctl status mig-restore.service --no-pager -l
systemctl show mig-restore.service \
  -p FragmentPath -p DropInPaths -p ExecStart \
  -p After -p Before -p Result -p ExecMainStatus
sudo journalctl -b -u mig-restore.service --no-pager -o short-iso

重点检查实际加载的单元文件、drop-in覆盖项及ExecStart指向的脚本：

• disabled且本次启动无日志：可能没有进入启动链，但还要确认是否由其他单元间接拉起。
• 成功退出，脚本只有-mig 1：仅完成模式设置，不能证明实例恢复。
• 设备不存在或驱动未就绪：检查启动顺序和设备就绪检测。
• 资源不足或布局冲突：检查既有实例、Profile组合及重复恢复入口。
• 服务成功但布局不符：检查GPU索引硬编码、遗漏创建步骤，以及|| true等是否掩盖失败。

active (exited)不是MIG布局验收结果。 对Type=oneshot、RemainAfterExit=yes服务，它只表示启动命令成功退出，不会持续监测实例。After=也只约束相关单元的先后顺序，不能单独保证驱动已可接受MIG管理命令。

若已有管理组件负责布局，应修复其启动链，不要再叠加第二个创建服务。

修复空布局恢复：让设备等待和创建失败可见

以下修改可能影响目标GPU业务。先安排维护窗口，停止相关任务、保存检查点，并备份服务文件、脚本、业务依赖及现有布局。不要直接覆盖已有同名配置，也不要在承载任务的GPU上重置设备或删除GI、CI。

如果Current为Disabled，可在维护窗口执行：

sudo nvidia-smi -i GPU-xxxxxxxx -mig 1
nvidia-smi -i GPU-xxxxxxxx -q

设备被占用或平台不支持所需重置时，模式可能不能立即生效。以命令提示和Current、Pending复查为准，必要时计划重启，不能仅凭命令退出成功判定完成。

下面是仅用于重启后空布局恢复的最小示例：创建一个1g.10gb GI，并同时创建CI。使用前确认-lgip列出了该Profile，并将布局改为实际目标。它不检查已有布局是否匹配，不是可反复执行的幂等协调脚本。

用command -v nvidia-smi确认路径；示例假设为/usr/bin/nvidia-smi。将脚本保存为/usr/local/sbin/restore-a100-mig.sh：

#!/bin/bash
set -eu

SMI=/usr/bin/nvidia-smi
GPU='GPU-xxxxxxxx'
PROFILES='1g.10gb'

ready=0
for ((attempt=1; attempt<=30; attempt++)); do
    if "$SMI" -i "$GPU" \
        --query-gpu=uuid --format=csv,noheader >/dev/null 2>&1; then
        ready=1
        break
    fi
    sleep 2
done

if [ "$ready" -ne 1 ]; then
    echo "Target GPU is not ready: $GPU" >&2
    exit 1
fi

mode="$("$SMI" -i "$GPU" \
    --query-gpu=mig.mode.current --format=csv,noheader)"

if [[ "$mode" != *Enabled* ]]; then
    echo "MIG mode is not enabled: $mode" >&2
    exit 1
fi

"$SMI" mig -i "$GPU" -cgi "$PROFILES" -C
"$SMI" mig -i "$GPU" -lgi
"$SMI" mig -i "$GPU" -lci

30次检查、每次间隔2秒只是示例等待配置，不是驱动加载时间或服务承诺，应按实际启动日志调整。-C用于创建GI时一并创建CI；脚本不会删除实例或自动重置GPU，管理命令失败会使服务失败。

先检查语法：

sudo /bin/bash -n /usr/local/sbin/restore-a100-mig.sh

创建/etc/systemd/system/mig-restore.service：

[Unit]
Description=Restore A100 MIG instances after boot
After=systemd-modules-load.service

[Service]
Type=oneshot
ExecStart=/bin/bash /usr/local/sbin/restore-a100-mig.sh
RemainAfterExit=yes
TimeoutStartSec=180

[Install]
WantedBy=multi-user.target

脚本由/bin/bash调用，无须额外赋予执行权限。服务与脚本应由root管理，不能允许普通业务账户修改；超时值也是可调整配置，不是性能指标。

sudo systemd-analyze verify /etc/systemd/system/mig-restore.service
sudo systemctl daemon-reload
sudo systemctl enable mig-restore.service

这里不使用--now：当前已有实例时，立即启动可能增加实例或因冲突失败。确认业务已停、恢复目标为空布局后，再进行计划重启。

若业务也由systemd启动，应在其实际服务的drop-in中配置：

[Unit]
Requires=mig-restore.service
After=mig-restore.service

保存后执行sudo systemctl daemon-reload。这能建立启动依赖，但不会持续验证MIG状态；业务使用的设备标识也必须有效。

重启验收：状态、启动记录和业务任务分别留证

重启后不要先手工补建，否则会掩盖自动恢复故障。保存本次启动现场：

GPU='GPU-xxxxxxxx'
OUT="$HOME/mig-check-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUT"

date -Is > "$OUT/time.txt"
cat /proc/sys/kernel/random/boot_id > "$OUT/boot-id.txt"
nvidia-smi -i "$GPU" -q > "$OUT/gpu-query.txt" 2>&1
nvidia-smi -L > "$OUT/device-list.txt" 2>&1
nvidia-smi mig -i "$GPU" -lgi > "$OUT/gi-list.txt" 2>&1
nvidia-smi mig -i "$GPU" -lci > "$OUT/ci-list.txt" 2>&1
systemctl cat mig-restore.service > "$OUT/unit.txt" 2>&1
systemctl status mig-restore.service --no-pager -l \
  > "$OUT/service-status.txt" 2>&1
sudo journalctl -b -u mig-restore.service --no-pager -o short-iso \
  > "$OUT/service-journal.txt" 2>&1

同时保存恢复脚本副本和目标布局。文件存在不代表检查成功，应确认内容中没有查询失败。Boot ID区分重启轮次，服务日志说明执行过程，实例列表证明采集时的状态，三者不能互相替代。

业务验证应保存实际执行命令、运行身份、输出和退出状态，不要只保留宿主机上的nvidia-smi截图。

GI编号或MIG UUID跨重启不变，不应作为通过条件。 实例重建后应重新核对标识；业务绑定旧MIG UUID时，即使宿主机列表正确，也可能找不到设备。

利用率、显存占用和任务耗时只能用于恢复后的业务验证。空闲实例利用率为零并不异常；不同Profile或负载下的耗时，也不能直接用来判断恢复前后的性能变化。

停止重试与再次验收的边界

出现已有实例、资源不足或部分创建成功时，不要反复restart上述服务。它不是幂等脚本，再次运行可能新增实例或继续失败。应先留证，再核对重复服务、手工操作和其他管理组件。

需要回滚新增启动项时：

sudo systemctl disable mig-restore.service

随后恢复已备份的服务、脚本和业务依赖配置，并执行sudo systemctl daemon-reload。尤其要撤销本次新增的业务依赖：disable只取消开机启用关系，其他单元仍可能拉起该服务。

禁用或停止服务不会撤销已经创建的MIG实例。运行中布局如需恢复，应另在维护窗口确认无任务后处理，不能把删除实例视为无影响操作。

驱动升级、恢复脚本变更、GPU更换或业务绑定方式改变后，都应重新完成一次“无手工补建”的重启验收。只有当前实例布局、该次启动日志和实际业务任务相互印证，才能确认这台A100 80GB服务器的MIG自动恢复链已经通过检查。