文档中心

Appearance

✨费用中心控制台

使用现有容器镜像 ​

极值算力实例基于容器镜像启动。如果平台预置镜像或租户已有自定义镜像已经满足需求，建议优先直接使用，而不是重新构建。这样通常可以更快完成实例创建，也更容易保持环境一致。

极值算力实例可直接使用平台预置镜像和已准备好的自定义镜像。涉及构建、上传、管理自定义镜像时，请前往 AIStudio 镜像中心操作。

检查平台已有镜像是否可直接使用 ​

本节用于判断平台内已有镜像能否直接使用。只有运行环境、镜像标签、可用服务和可用区都匹配当前实例时，才建议直接选用；如果只是还需要把固定软件包或配置写入镜像，改为基于现有镜像构建；如果镜像还在平台外部，先把它迁移到租户镜像仓库，再检查架构、启动组件和登录行为是否适合当前实例。

选用平台预置镜像 ​

如果预置镜像已经包含目标操作系统、框架运行时和 GPU 环境，优先直接使用它。这样可以减少构建等待，也能避免把临时安装步骤带入长期镜像维护。

直接选用前，重点确认：

  • 镜像中是否已经包含实例要使用的操作系统版本，例如 Ubuntu 22.04
  • 镜像中是否已经安装任务要使用的框架、运行时或 CUDA 等 GPU 环境，例如 PyTorch、CUDA、Python 版本
  • 镜像标签是否对应您要创建实例时选择的版本，例如 cuda12.1、py310、v1
  • 是否还需要把长期保留的软件包或配置写入镜像，例如公司内网源、固定 Python 包、系统工具
浏览预置镜像

如果这些条件都满足，可以停在这里并直接创建实例；如果只是少了几个每次都要安装的软件包或配置，不建议每次启动后手工补齐，通常应从该预置镜像出发，构建一次新镜像，把这些软件包或配置写入镜像。

使用租户已有自定义镜像 ​

如果团队已经用某个自定义镜像成功运行过任务，并确认其中的软件版本和业务工具可继续使用，优先复用该镜像。这样比重新选择预置镜像更稳，也能减少同一团队内的环境差异。

使用前重点确认：

  • 镜像标签是否对应正确版本，例如 training-v3、prod-202604
  • 镜像是否已开放给当前使用的极值算力服务；如需修改，参见限制可用服务范围
  • 镜像所在可用区是否与当前资源一致。租户镜像仓库按可用区隔离，跨可用区不会自动同步；参见镜像仓库地址与可用区
  • 镜像维护者是否已经用该镜像启动过实例，并确认 SSH、Jupyter 和入口命令可用

找不到镜像时检查可用服务和可用区 ​

如果在创建或改配流程中找不到预期镜像，不要先重新构建镜像。多数情况下，是镜像没有开放给当前服务，或镜像所在可用区与当前资源不一致。按以下顺序检查：

  • 镜像标签是否对应正确版本
  • 镜像是否已勾选当前要使用的可用服务
  • 镜像所在可用区是否与当前资源一致
  • 当前流程是否选择了正确的实例类型、资源池或服务入口

导入外部镜像 ​

如果您已有外部镜像，不能直接用外部 Registry 地址在平台内运行，建议先将其迁移到租户镜像仓库，再作为平台自定义镜像使用。

导入或跨可用区迁移镜像 ​

外部镜像指尚未存放在租户镜像仓库中的镜像。它可能来自 Docker Hub、企业私有镜像仓库等外部 Registry，也可能是保存在本地机器或企业服务器上的 Docker 镜像，包括历史维护的镜像和当前刚构建出的镜像。

关于迁移方法，请直接参考导入或跨可用区迁移镜像。

检查镜像架构 ​

导入或使用外部镜像前，请确认镜像里实际包含的架构与要运行它的资源池节点一致。linux/amd64 和 linux/arm64 都可能是有效选择，关键是目标资源池能运行镜像清单里的某个架构；如果两者不一致，实例可能在拉取、启动或排障时反复失败。

如果镜像来自本地构建，尤其是在 Apple Silicon Mac 或多架构构建环境中构建，请重点检查镜像清单中实际包含的架构：

language-shell
docker buildx imagetools inspect <image>:<tag>

如果需要为特定资源池构建镜像，可在构建时显式指定平台。例如：

language-shell
docker buildx build --platform linux/amd64 -t <image>:<tag> .
docker buildx build --platform linux/arm64 -t <image>:<tag> .

检查镜像兼容性 ​

外部镜像导入成功后，建议先用测试实例确认平台能拉取并启动该镜像。重点检查：

  • 镜像清单里是否包含目标资源池节点使用的架构
  • 基础系统是否能按平台运行方式启动
  • 镜像中是否已安装平台启动所需组件
  • 镜像中是否保留了登录和排障需要的工具

如需进一步确认镜像能否稳定启动，请继续阅读镜像兼容性要求。

复用现有 Dockerfile ​

如果您已经有一份 Dockerfile，先判断镜像中心能不能直接执行它。若 Dockerfile 只需要拉取平台能访问的基础镜像、执行能在构建环境中完成的安装命令，并且不会长时间编译，通常可以直接交给镜像中心构建；如果它要读取本地文件、完整项目目录、共享存储、受限 Registry 或特殊 docker buildx 参数，通常需要先调整，或改用开发机内构建。

检查 Dockerfile 是否可直接用于镜像中心 ​

先用以下问题判断是否适合直接粘贴到镜像中心：

  • 镜像中心能否拉取 FROM 指向的基础镜像，例如平台预置镜像或已登录的私有镜像
  • 基础镜像里是否包含目标资源池节点能运行的架构，例如 linux/amd64 或 linux/arm64
  • Dockerfile 每一步是否都能自动执行，无需人工确认，例如非交互式 apt-get install -y
  • 构建环境能否下载所需依赖，且下载和安装不会显著拖慢构建，例如可访问的 apt、pip、conda 源
  • 构建完成后的镜像是否包含平台启动、登录和排障所需的基础组件，例如 SSH、sudo、bash、curl

如果以上条件基本满足，再继续确认 Dockerfile 命令能否在镜像中心执行；如果核心依赖来自本地目录、共享存储或当前机器环境，优先改用开发机内构建。

确认 Dockerfile 命令能在镜像中心执行 ​

镜像中心会在受控构建环境中执行 Dockerfile。Dockerfile 语法大多可用，但能否直接复用，取决于构建时能读到哪些文件、能拉取哪些基础镜像、能访问哪些软件源、构建需要多久、镜像架构是否匹配，以及平台最终会用什么方式启动实例。迁移现有 Dockerfile 时，尤其要检查以下写法。

检查 COPY 和构建上下文 ​

如果 Dockerfile 只从前一个构建阶段复制产物，例如 COPY --from=＜stage＞，通常可以保留。如果 Dockerfile 要读取您本地项目目录中的代码、配置文件或模型文件，请不要直接粘贴到镜像中心。例如：

language-dockerfile
COPY ./src /app/src
COPY config.yaml /app/config.yaml

这类 Dockerfile 更适合使用在实例内构建自定义镜像，让 docker build 或 docker buildx build 读取完整构建上下文。

检查 ENTRYPOINT 和 CMD ​

ENTRYPOINT 和 CMD 可以留在 Dockerfile 中，但不要假设原镜像的启动行为一定适合开发机、任务、推理服务或极值算力服务。如果入口脚本启动后台服务后不交还控制权，或忽略平台传入的启动命令，可能导致实例启动、登录或任务执行异常。

如果必须使用入口脚本，建议让脚本完成初始化后执行传入命令。例如：

language-bash
#!/usr/bin/env bash
set -e

# 在这里写入必要的初始化逻辑。

exec "$@"

检查 ENV 写入的值 ​

ENV 适合写入稳定的镜像级环境变量。复用现有 Dockerfile 时，重点检查变量是否写死了本地路径、架构路径、CUDA 小版本路径，或依赖运行时才会注入的变量。

如果原 Dockerfile 使用 ${VAR:-default}、${PATH:+:${PATH}} 这类变量展开，建议先确认最终写入镜像的值；必要时改成明确值，或在提交给镜像中心前生成完整 Dockerfile。

选择后续构建方式 ​

完成检查后，再选择后续路径：