镜像包含 CUDA 库，不表示容器自动获得 GPU，宿主机驱动和运行接口需配套。
容器使用宿主机内核与驱动接口，镜像提供用户态依赖。版本兼容、架构和设备选择决定应用条件。
一、问题的范围与前提
镜像、容器、网络和数据卷是不同对象。镜像定义运行产物，容器执行进程，网络决定可达关系，卷管理跨容器生命周期的数据。把它们分别列出来，有助于判断重建究竟改变了什么；单个容器显示 Up，只能说明相关入口进程仍然存在。
二、技术分析与方案取舍
宿主驱动提供访问硬件的底层能力，容器带应用需要的用户库。容器 CUDA 版本与驱动兼容关系先按 NVIDIA 说明核对，不把镜像内装了 CUDA 当作已有设备访问。设备发现、简单运算和目标模型依次测试；nvidia-smi 正常只覆盖较小范围。
容器运行参数、运行时配置与镜像架构一起记录，修改创建参数以后要重建并检查实际配置。不要把宿主内核驱动当普通依赖复制进镜像。测试结果还需包含实际所需的编码、推理或外设路径，避免基础 GPU 访问成功却业务依赖缺失。
先固定基础镜像、应用版本和必要配置，再检查最终容器的实际参数。Compose 文件只是期望描述，已经创建的容器可能仍带旧环境。涉及端口、设备和挂载等创建参数时，需要按差异重建；普通 restart 不会重新读入全部创建配置。重建前确认数据所在位置和现有卷身份。
三、实现与排查的顺序
- 先验证宿主机 GPU。
- 核对运行时设备暴露。
- 查看镜像依赖。
- 运行真实目标请求。
按这个顺序保留中间结果，可以区分输入条件、处理过程和最终输出。前一阶段的条件不成立时，先解释对应错误，再继续后面的试验；单次返回成功不足以覆盖整条链路。
最小示例
1
nvidia-smi --query-gpu=index,name,memory.total,memory.used,memory.free --format=csv
每块卡的资源单独记录，总容量不能直接满足任意单卡分配。模型加载、缓存和临时缓冲峰值分别检查，进程占用公开时去除身份信息。
四、验证和结果解释
可以将配置解析结果、容器实际状态和一次业务请求放在一起观察。配置有效说明语法和部分引用成立，镜像构建有效说明产物生成，真实请求才进一步说明依赖链可用。将这些结果分开记录，能避免一个阶段的成功遮住另一个阶段的失败。
| 需要验证的结果 | 保留的对照 | 不能由此推出的结论 |
|---|---|---|
| 每层错误可定位 | 固定输入与配置、对应输出 | 一次成功代表所有条件成功 |
| 目标设备正确 | 中断前后状态与错误阶段 | 没有报错代表结果正确 |
| 资源没有并发争用 | 恢复后的同条件复测 | 临时恢复代表根因已经消失 |
容器异常不一定需要重建整套服务。先定位受影响对象，再确认是否有状态需要保留。数据卷独立于容器并不等于有独立备份，健康检查也不等于自动重启。恢复策略需要与退出、网络失联、数据损坏等具体条件对应。
五、适用边界与结论
容器内部重装驱动不能替代宿主机治理，不默认所有镜像都支持旧 GPU。
这条路径把“先验证宿主机 GPU”与“运行真实目标请求”连在一起，中间保留可复查的条件。实施时优先确认“每层错误可定位”，再检查“资源没有并发争用”；两者都满足，才能在当前样本与配置范围内评价方案。设备、数据或软件版本改变以后，相关假设需要重新验证。
