准备您的 GPU 环境及其检查项

1. 选择与项目匹配的起点

当您懂得如何组织自己的软件栈并描述其系统依赖时，Ubuntu 基础环境就很合适。PyTorch 准备可用于标示项目的核心框架。Blender 表示有创作或渲染需求。当您的应用程序已有这些名称难以概括的特定条件时，则使用自定义准备。

这些选择不会自动带上您的代码、权重、数据或授权。请写明哪些必须可用、您自己提供什么，以及启动时您将核验什么。准备方式的名称不应让您免于检查实际运行的版本。

好的请求不是罗列所有已知工具，而是描述有用的路径：读取输入、加载资源、计算并写出结果。这有助于区分必需依赖与便利工具，并诊断缺失的是哪一步。

左右滚动表格即可查看所有列。

对于 Python 项目，请区分系统、解释器、包和应用资源。当某个依赖要求精确版本时，请保留这些版本。当你接受一个版本范围时，请说明用于验证该范围的控制手段。“安装最新版本”很难与参考环境对应起来。

教学示例：你的项目借助一个原生扩展对图像进行分类。你的请求中应说明 Python 版本、所选的 PyTorch 变体、项目引用以及该扩展的前置依赖。它提供三张获准的对照图像，并描述预期的输出形式。未经测试，它不应宣称具有足够的吞吐量或显存。

准备文档可以保持简短：只要步骤和访问方式清晰，一份 README、一个依赖文件和一个代码引用就足够了。请将可修改的参数保存在单独的文件中，以免新的批大小把该请求变成另一次安装。

示例表格，请用你的参考信息补全

目标：对一小批样本图像进行分类
代码：项目仓库与修订版本
Python：应用所要求的版本
PyTorch：所采用的版本及 CUDA 或 ROCm 变体
扩展：版本、来源及编译前置依赖
输入：获准的样本及预期标识符
控制：按标识符输出、格式有效、结果可复读
访问方式提供：单独流程，本表中不含任何密钥

在不断增加包之前，先检查整个计算链路。PyTorch 官方选择器可让你根据平台选择安装方式。CUDA 和 ROCm 并非同一个二进制文件的两个可互换名称。主框架可能正常运行，而某个专用算子或项目扩展却仍不兼容。

如果某个扩展需要编译，其构建过程可能需要额外的工具和库。PyTorch 文档指出，安装 torch 包并不会自动提供所有扩展所需的编译链。请在流程中说明这些前置依赖；一条尝试编译的安装命令并非需要掩盖的异常。

请安排三个独立的检查：导入框架、在设备上做一次小计算，以及使用该扩展执行一次运算。如果前两项通过而第三项失败，你就得到比一句“PyTorch 不工作”更精确的诊断。请记录第一个完整错误及相关版本。

对于 Python 包，使用虚拟环境的重建流程通常是一个简单的基础方案。它针对某个解释器，并将项目依赖分离出来。它并不描述整台机器：请将系统需求保留在 README 中，不要把已安装目录的副本当作可移植的流程来呈现。

如果你的项目已经使用容器，请提供其配方、引用以及启动所必需的参数。标签可能会变化；按摘要的引用能更精确地标识某个具体镜像。尽管如此，仍需安排更新并重新验证项目。容器本身并不能证明可以访问 GPU 或你的数据存在。

请选择你有能力维护的机制。一个非常完整的镜像可能隐藏无用的依赖；一份过于简化的配方则可能把手工安装步骤留在文档之外。无论哪种情况，应用层检查始终是对比的基准。这些说明描述的是你的准备工作，并不预设该服务提供镜像的方式。

Notebook 有助于探索数据和可视化输出。但它的文件与执行其单元格的进程是分开的：旧会话中的变量并不构成有据可查的依赖关系。在移交前，请重启内核并按顺序执行单元格；记录所使用的 Python 版本。

当试验变成常规任务时，请准备一个无需逐个操作单元格的入口点。关于从 notebook 过渡到脚本的指南详细介绍了这一转变。你的准备申请应明确 notebook 需求，但不要将工作界面与程序成功运行混为一谈。

对于 Blender 或其他图形软件，请补充相关资源、扩展以及导出流程。一个能在你本机打开的项目可能依赖位于其他位置的文件。请思考另一台机器将如何找到每一个文件，以及哪个小结果能在完整工作之前验证整条链路。

在交付时，将观察到的版本与你的清单进行对比。先运行诊断，再运行预定的应用案例。对于示例中的三个镜像，请检查每个标识符都有输出、类别有效、生成的文件可重新读取。没有报错的屏幕并不能替代这份总结。

保留有用的差异：版本不同、缺少扩展、输入无法访问、输出写到了别处。区分哪些问题会阻碍你开始，哪些只是需要更新文档。寻求帮助时，请附上订单参考和一个最小片段；无需发送你的全部语料。

样本验证通过并不能保证内存容量，也不能保证所有未来负载的行为。接下来请设定明确目标增加数据量，并检查首先遇到的限制。最后保留修正后的流程：它将成为你下次租用时的参考。