算力容器 FAQ(常见问题解答)
Jupyter 执行过程中报错 Kernel Restarting 是怎么回事?
当 Jupyter Notebook 中的内核(Kernel)崩溃、停止或出现错误时,Jupyter Notebook 会自动尝试重新启动内核。在这个过程中,笔记本中所有的变量和数据都将被清除并且需要重新运行。原因可能包括代码错误、内存问题、资源限制或其他系统问题,建议您检查代码中的语法错误和逻辑错误,并确保内存使用不会超过可用容量。如果问题持续存在,可以尝试使用更高版本的 Python 或者升级相关依赖库等操作解决。
如何找到执行程序的路径?
可以通过 which
命令来查找:
which darknet
返回结果:
/usr/local/bin/darknet
如果文件在非标准路径,可以通过 find
命令查找:
find / -name program
更详细的使用说明请参阅 man which
和 man find
为何工作空间中的 Terminal 终端无法退出 Vim 的编辑模式?
根据用户反馈,如果您在工作空间的 Terminal 终端中使用 Vim 编辑文件时,如果遇到无法退出编辑模式等非常规行为(主要表现为进入插入模式 i
后按 esc
- :wq
无法退出当前模式),建议检查 Google Chrome 浏览器中是否有安装并激活 Vimium、cVim 等 Vim 相关插件/扩展。此类插件的某些设置极有可能与工作空间中的 Terminal 快捷键冲突。
建议:禁用相关插件/扩展,或更换为其他浏览器使用
为什么通过容器的「继续执行」启动后发现原来的内容不见了?
在 为什么要有执行记录 这里介绍了每次容器的执行都是独立的环境,而 从指定执行记录继续执行 解释了「继续执行」做了什么:将上一次执行的输入绑定到新的执行的 /openbayes/home
目录下。而「上一次执行」值得就是用户点击「继续执行」的那个执行了,如果这次执行没有任何的输出内容,那么新的执行内必然也没有相应的数据了。这种情况可能是因为点击「继续执行」的执行本身是没有开启就关闭了,而再上一个容器则是有实际数据的。
例如我创建了一个新的容器 cifar10 并且创建了一个执行:第一次执行,以 Jupyter 工作空间的形式打开了,我写了一个 .ipynb 文件后就关闭了。
一个小时后我点击「第一次执行」的「继续执行」打开这个容器,在这次执行处于「准备中」的状态时我发现我的算力类型选错了,我立即点击了关闭,这个时候我的容器中有了第二次执行。
然后我又在「第二次执行」的页面点击了「继续执行」,当容器开启之后发现我的 /openbayes/home
目录是空的。那是因为第二次执行是异常关闭的,根本没有机会去同步第一次执行的内容,因此正确的做法是在「第一次执行」处点击「继续执行」开启容器。
为什么再次开启容器我原来安装的内容就没有了?
在 为什么要有执行记录 这里介绍了每次容器的执行都是独立的环境,原来手工安装的依赖包会消失。如果希望每次开启容器都有相关的依赖的话,参考 如何添加不在列表中的依赖 。同时,我们也会周期性更新镜像,把越来越多通用的依赖添加进来。
为什么我的容器一直处于「准备中」的状态?
容器启动长时间处于准备中的状态可能有以下可能:
- 将大量的文件绑定到了
/openbayes/home
容器在启动阶段拷贝大量的数据到/openbayes/home
耗费时间,尤其是大量的小文件的拷贝可能会非常的耗时,同时在具体的执行的页面也会看到现实「数据同步」并展示当前数据同步的速度。如果对相应的数据没有写的需求,建议创建为数据集并绑定到/intput0-4
以避免拷贝的过程,在 算力容器的工作目录 - 将工作目录创建为数据仓库版本 可以看到如何从容器的「工作目录」创建新的数据集版本。 - 容器处于冷启动状态,启动容器的机器目前没有容器所需要的镜像,正在拉取镜像。虽然我们已经在集群内增加了镜像节点提升镜像获取的时间,但是在这种冷启动状态依然会有 3 - 5 分钟的时间耗费在镜像拉取上,同时在具体的执行页面也会看到这个执行处于「拉去镜像」的状态。
- 网络问题,由于内部网络抖动导致容器的创建过程出现问题,如果排除了以上两种可能(即自己没有加载大量数据到
/openbayes/home
但是过了 5 分钟 10 分钟容器还没启动起来),那么可以尝试重启容器或者在界面的聊天窗口咨询客服人员。
为什么我的容器一直处于「拉取镜像」的状态?
当您的容器长时间处于「拉取镜像」状态时,这通常与冷启动有关。冷启动是指您所请求的计算节点上尚未缓存您所需的容器镜像,系统需要从镜像仓库下载完整镜像。
这种情况是正常的,特别是对于:
- 首次使用特定类型的环境或框架
- 使用较新版本的镜像
- 使用较大体积的特殊镜像
正常情况下,拉取镜像的过程通常需要 3-5 分钟完成,具体时间取决于镜像大小和当前网络状况。在此期间,请耐心等待系统完成镜像拉取和容器初始化。
异常情况:如果容器超过 10 分钟仍然处于「拉取镜像」状态,可能是由于以下原因:
- 镜像仓库暂时不可用
- 系统资源调度出现问题
此时,建议您:
- 刷新页面查看最新状态
- 尝试重启容器创建流程
- 如果问题持续存在,请联系平台管理员或通过界面聊天窗口与客服人员联系,提供您的容器ID和详细情况
为什么我的容器一直处于「同步数据并关闭」的状态?
这种情况通常和容器打开缓慢是同样的原因,就是将大量的文件绑定到了 /openbayes/home
,当容器在关闭时需要同步大量的数据。大量的数据同步,尤其是大量小文件的同步非常耗时,如果对相应的数据没有写的需求,建议创建为数据集并绑定到 /intput0-4
以避免拷贝的过程。
在 算力容器的工作目录 - 将工作目录创建为数据仓库版本 可以看到如何从容器的「工作目录」创建新的数据集版本。
如果容器内文件不多依然出现了这种情况,那么请在界面的聊天窗口咨询客服人员。
如何上传、查看、预览 .ipynb 文件?
您可以通过两种方式上传:
在算力容器模式中,您可以创建一个新的算力容器,接入方式选择 工作空间 ,然后在容器启动完成后打开工作空间,在工作空间中上传 .ipynb
文件
如果是在预训练模型中,您可以在上传的时候直接将 .ipynb 打包到 Zip 文件中并上传,上传完成后在预训练模型的文件列表中即可访问该 notebook,稍后您也可以通过创建新的容器并绑定该预训练模型,在工作空间中进行交互操作
容器中的存储空间和从「资源使用状况」中看到的空间怎么不一样,他们是什么关系?
容器中的存储空间是开启一个容器后对应的「工作目录」(/openbayes/home
目录)工作空间大小,对于特定的算力资源其空间是固定的,例如「T4」类型的算力资源其工作空间是 50GB。而「资源使用状况」中反应的是用户全局存储空间。容器的存储空间是在用户开启容器的时候所使用的,容器在关闭后其「工作目录」(/openbayes/home
目录)中的数据会被同步到用户全局存储空间并占据相应的额度;另一方面,用户上传数据集也是直接计算在用户全局存储空间额度中。
当用户的全局存储空间超出限额后,用户将不再能够创建容器、上传数据集,可以通过删除执行、删除数据集等方式释放空间。
为什么我的容器卡死了,甚至连 Jupyter 工作空间的页面也打不开?
容器的计算资源(CPU、GPU、内存)都是固定的。如果有程序占满了 CPU 资源,那会导致其他的进程受到严重的影响。比如有些程序会一口气占满所有的 CPU 资源,那么 Jupyter 工作空间自身程序就会变得非常卡顿,甚至导致 Jupyter 工作空间的页面也无法打开。所以如果发现自己的 Jupyter 工作空间页面无法打开,首先检查一下容器的 CPU 是不是在满负荷运行(在容器页面会展示 CPU、内存等重要指标)。
如果容器非常卡顿甚至无法打开 Jupyter 工作空间页面,可以尝试采用 SSH 的方式登录容器。如果依然无法登录,则可以尝试重启容器。
为什么我的「工作空间」没有自动关闭?
「工作空间」自动关闭需要满足两个条件:
- Jupyter 页面被关闭
- CPU 使用率持续接近于 0
注意,如果 Jupyter 的页面在浏览器中并没有关闭,会被系统认为「工作空间」依然是在被使用的,不会触发空闲关闭的。
为什么我的 GPU 利用率非常低,如何提高利用率
在深度学习训练与推理中,GPU 利用率低下是常见问题。根据我们对大量生产环境的分析,超过 80% 的 GPU 低效问题源于 CPU-GPU 协同流水线设计缺陷。下面从三个维度提供优化策略:
数据加载优化
存储读取策略
当训练数据存储于分布式文件系统时,跨城访问延迟可达 50-200ms。以 ImageNet 数据集为例,A100 GPU 的 SM 利用率可能从 95% 跌至 32%。优化方案:
- 本地缓存:在计算节点内存缓存数据,并将小文件合并为 TFRecord 格式读取
- 并行预读:设置
num_workers=CPU核心数×0.8
,prefetch_factor
适当调高
内存传输加速
from torch.utils.data import DataLoader
DataLoader(dataset,
num_workers=8,
pin_memory=True, # 关键参数
persistent_workers=True,
prefetch_factor=2)
该配置可使数据加载延迟降低 75%,GPU 空闲时间大幅减少。
计算调度优化
异步操作设计
模型保存、日志打印等 CPU 操作会阻断 CUDA Stream。优化措施:
# 异步保存模型
with ThreadPoolExecutor(max_workers=1) as executor:
executor.submit(torch.save, model.state_dict(), "checkpoint.pt")
批处理规模调整
过小的 batch size 无法充分利用 GPU 并行能力,过大则可能导致显存溢出。最佳实践:
- 从小批量开始,逐步增加至显存占用 80%
- 使用梯度累积增加等效批量:
loss.backward(); optimizer.step() if (i+1) % accumulation == 0 else None
系统参数调优
以下环境变量对性能影响显著:
# 基础 CUDA 参数优化
export CUDA_DEVICE_MAX_CONNECTIONS=1 # 减少上下文切换开销
export CUDA_CACHE_DISABLE=0 # 启用 CUDA 内核缓存,提高重复计算速度
export CUDA_VISIBLE_DEVICES=0,1,2,3 # 指定要使用的 GPU 设备 ID
# NCCL 通信优化(多卡训练)
export NCCL_P2P_DISABLE=0 # 启用点对点通信
export NCCL_IB_DISABLE=0 # 启用 InfiniBand 传输
export NCCL_DEBUG=INFO # 调试阶段可开启,生产环境建议关闭
export NCCL_SOCKET_IFNAME=eth0 # 指定网卡接口,避免选择错误接口
# 并行计算优化
export OMP_NUM_THREADS=8 # 限制 OpenMP 线程数,避免与 DataLoader 争抢
export MKL_NUM_THREADS=8 # 限制 MKL 线程数,同样避免资源争抢
使用 PyTorch 时,还可通过代码设置以下参数:
# 优化 CUDA 内存分配策略
torch.backends.cudnn.benchmark = True # 对固定输入尺寸有显著加速
torch.backends.cudnn.deterministic = False # 非确定性模式通常更快
torch.cuda.set_per_process_memory_fraction(0.9) # 预留部分显存,防止 OOM
性能诊断工具
采用 PyTorch Profiler 定位瓶颈:
with torch.profiler.profile(
activities=[torch.profiler.ProfilerActivity.CUDA],
schedule=torch.profiler.schedule(wait=1, warmup=1, active=3)
) as prof:
for step, data in enumerate(dataloader):
outputs = model(inputs)
prof.step()
分析时重点关注:
CPU Exec
与GPU Exec
时间差异cudaMemcpyAsync
调用频率- GPU 核心利用率波动情况
最佳的 GPU 利用率应保持在 85% 以上,波谷持续时间少于 50ms,这表明数据处理流水线运行良好。
我的两个容器之间可以相互访问吗
是的,您的容器之间可以相互访问。
-
获取目标容器的 IP 地址:
登录到目标容器(您想要连接的容器),在 Terminal 中执行:
ip a
如果提示命令不存在,先安装网络工具:
apt install iproute2 -y
ip a在输出中找到
eth0
接口对应的 IP 地址(例如10.38.6.87
)。 -
从源容器建立连接:
在另一个容器(发起连接的容器)中,使用 SSH 连接到目标容器:
ssh 10.38.6.87
信息同一个创建人的容器之间已经预配置了 SSH 密钥,无需密码即可直接连接。
-
在容器间传输文件:
# 从当前容器复制文件到目标容器
scp /path/to/local/file 10.38.6.87:/path/to/remote/
# 从目标容器复制文件到当前容器
scp 10.38.6.87:/path/to/remote/file /path/to/local/
# 使用 rsync 同步目录
rsync -avz /path/to/local/dir/ 10.38.6.87:/path/to/remote/dir/
更多详细说明请参考 容器间通讯 文档。
可否使用我自己的镜像
目前平台的普通用户暂时无法直接使用自定义镜像。我们已经预置了多种常用框架和版本的镜像,包括:
- 深度学习框架:TensorFlow、PyTorch、MXNet 等各主流版本
- 大语言模型框架:vLLM、SGLang 等
- 其他框架:PaddlePaddle、Darknet 等
对于自定义镜像的需求,我们提供以下解决方案:
-
针对普通用户:
- 使用
pip install --user
安装 Python 依赖,这些依赖将保存在用户目录下 - 创建自定义 conda 环境并放置在
/openbayes/home
目录 - 在启动脚本中添加必要的依赖安装命令
- 使用
-
专有部署用户:
- 支持完全自定义的镜像定制服务
- 所有自定义镜像必须基于 Ubuntu 操作系统构建
- 可根据企业特定需求定制环境、依赖和配置
-
针对企业用户:
- 我们的企业私有部署服务提供定制化镜像支持
- 企业用户可以基于我们的基础镜像构建自定义 Docker 镜像
- 在模型部署时可以直接指定自定义镜像
如果您有特殊的镜像需求,建议联系客服人员咨询具体解决方案。
遇到 huggingface 无法下载模型该如何解决?
如果您在使用 HuggingFace 相关功能时遇到连接错误,可以通过设置镜像来解决:
- 安装依赖
pip install -U huggingface_hub
- 设置环境变量
export HF_ENDPOINT=https://hf-mirror.com
- 使用示例
huggingface-cli download --resume-download gpt2 --local-dir gpt2
对于数据集下载:
huggingface-cli download --repo-type dataset --resume-download wikitext --local-dir wikitext