尧图网站建设 
Odysseus Docker 如何启用并验证 AMD ROCm GPU 直通RENDER_GID 与 gpu.amd overlay【免费下载链接】odysseusSelf-hosted AI workspace.项目地址: https://gitcode.com/gh_mirrors/ody/odysseus如果你用 Docker 部署 Odysseus主机上有一块 AMD GPU并想讓容器内的 Cookbook 真正看到这块 GPU就需要把宿主机的 ROCm 设备节点直通进容器并通过docker/gpu.amd.ymloverlay 完成配置。Odysseus 官方对 AMD 的处理方式是“只读诊断 手动改.env”先运行 scripts/check-docker-amd-gpu.sh 拿到宿主机 render 组的数字 GID再把COMPOSE_FILE和RENDER_GID写入.env重启后用一条docker compose exec命令确认容器内能看到/dev/kfd与/dev/dri/renderD*。适用前提是 docs/setup.md 中给出的环境CPU-only 用户可以直接跳过这套配置。前置条件主机 ROCm 驱动与组权限docker/gpu.amd.yml 的文件头注释写明了启用 overlay 的两个硬性前提主机已安装 ROCm 驱动即/dev/kfd与/dev/dri设备节点存在在宿主机上运行 Docker 的用户必须属于video和render两个组。overlay 本身只做一件事把宿主 GPU 直通给odysseus服务——挂载/dev/kfd、/dev/dri两个设备并通过group_add把容器加入video组和${RENDER_GID:-render}指定的组。也就是说RENDER_GID必须是你宿主机 render 组的数字 GID如果不设置overlay 会退回用组名render。另一个要注意的边界slim 版 Odysseus 镜像不打包 ROCm 用户态userspace和推理引擎overlay 只负责设备直通这一层。第一步运行只读诊断脚本拿到 RENDER_GIDscripts/check-docker-amd-gpu.sh脚本自身的定位是只读诊断不安装任何包、不编辑.env、不重启 Docker 守护进程。它做四项检查宿主机/dev/kfd与/dev/dri/renderD*是否存在宿主机 render 组以及 video 组的数字 GID即后续要写进.env的RENDER_GID宿主机上rocminfo是否可见可选项找不到不阻塞直通用一个小型容器做直通冒烟测试docker run --rm挂载/dev/kfd和/dev/dri、带上对应--group-add测试容器内能否列出 render 节点。副作用说明第 4 项会实际启动一个临时容器--rm会立即删除它首次运行可能拉取默认的alpine:3.20测试镜像可用环境变量ODYSSEUS_AMD_TEST_IMAGE换成别的镜像。脚本输出逐项标记[PASS]/[FAIL]/[WARN]最后汇总为一行 Results: N passed, N warnings, N failed 且只有FAIL为 0 时退出码才是 0。常见的 FAIL 项和脚本给出的提示/dev/kfd缺失——宿主机没有 ROCm 内核驱动访问Docker 守护进程未运行或当前用户没有 Docker 权限直通冒烟失败——脚本建议检查 Docker 能否访问/dev/kfd和/dev/dri后重试render 组找不到——提示按发行版实际的组名手动设置RENDER_GIDvideo 组找不到只是 WARN脚本注明部分主机上/dev/kfd与renderD*可能已经够用。诊断通过后脚本会打印一段建议写入.env的值格式为COMPOSE_FILEdocker-compose.yml:docker/gpu.amd.yml RENDER_GID宿主机 render 组的数字 GID第二步把 COMPOSE_FILE 与 RENDER_GID 写入 .envRENDER_GID有两个可靠来源二选一即可脚本输出中的render group GID: NNNNoverlay 文件头注释给出的宿主机命令getent group render | cut -d: -f3拿到数字后写入.env也可以 export 到运行docker compose的 shell 环境中按 docs/setup.md 的示例COMPOSE_FILEdocker-compose.yml:docker/gpu.amd.yml RENDER_GID989其中989是 setup 文档里给出的示例值替换成你自己宿主机上查到的 render 组 GID。配置好 overlay 后建议通读 docker/gpu.amd.yml 中的注释确认 devices 与 group_add 的行为符合你的预期。重启并验证容器内设备节点重启 Odysseus 让新的.env生效compose 会用 overlay 的 devices 与 group 配置重建odysseus容器然后执行 AMD 的验证命令docker compose up -d docker compose exec odysseus sh -lc test -e /dev/kfd test -d /dev/dri ls -l /dev/kfd /dev/dri/renderD*判断方式命令以退出码 0 结束、ls -l列出/dev/kfd与/dev/dri/renderD*节点说明设备直通已经在容器内就位。这里有一条必须记住的边界setup 文档明确强调看到/dev/kfd与/dev/dri只确认了设备直通不代表 ROCm 用户态或 vLLM/llama.cpp 的 ROCm 构建可用。slim 版 Odysseus 镜像内不预期存在rocm-smi或rocminfo所以不要试图在容器里用它们做验证。直通成功之后安装 ROCm 兼容的推理运行时设备直通是 GPU 推理的必要条件而非充分条件。要实际跑 GPU 模型按 overlay 注释和诊断脚本末尾的提示先通过Cookbook → Dependencies或 pip安装 ROCm 兼容版本的 vLLM 或 llama-cpp-python再开始 serve 模型。如果你只是让容器内应用连接远程模型端点则不需要这一步。可选分支堆栈管理 UI 使用单文件 ComposePortainer、Coolify、Dockhand 等工具通常只接受单个 Compose 文件且不能可靠地识别COMPOSE_FILE或多个-foverlay。这种环境下把 stack 指向仓库根目录的 docker-compose.gpu-amd.yml 即可它等价于docker-compose.ymldocker/gpu.amd.yml前置要求相同宿主机 ROCm/kfd/DRI 配置、video/render组成员身份以及需要时的RENDER_GID。文档明确说明基础文件加 overlay 才是权威来源单文件版本只是为单文件部署做的镜像。CLI 用户继续走COMPOSE_FILEoverlay 流程。限制与排查Cookbook 看不到预期的 GPU 时Cookbook 只能检测到 Docker 暴露给容器的 GPU。如果主机运行时或设备直通没配置好Cookbook 看到的是核显、另一块卡或 CPU而不是你预期的 GPU——先回到第一步确认冒烟测试通过。验证命令非 0 退出说明容器内缺少/dev/kfd或/dev/dri的 render 节点对照诊断脚本的 FAIL 项逐项排查宿主机驱动、组权限与 Docker 访问。直通通过但推理仍落到 CPU这与 Docker 直通无关属于运行时问题——vLLM 与 llama.cpp 仍需要 ROCm 兼容构建或 ROCm 专用 Docker 镜像参见上一节的安装步骤。整套流程到此形成闭环诊断脚本给出 GID 与直通冒烟结果.env里两行配置启用 overlaydocker compose exec一条命令完成容器内验证后续再按 Cookbook 安装 ROCm 运行时。【免费下载链接】odysseusSelf-hosted AI workspace.项目地址: https://gitcode.com/gh_mirrors/ody/odysseus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Odysseus Docker 如何启用并验证 AMD ROCm GPU 直通（RENDER_GID 与 gpu.amd overlay）
Odysseus Docker 如何启用并验证 AMD ROCm GPU 直通RENDER_GID 与 gpu.amd overlay【免费下载链接】odysseusSelf-hosted AI workspace.项目地址: https://gitcode.com/gh_mirrors/ody/odysseus如果你用 Docker 部署 Odysseus主机上有一块 AMD GPU并想讓容器内的 Cookbook 真正看到这块 GPU就需要把宿主机的 ROCm 设备节点直通进容器并通过docker/gpu.amd.ymloverlay 完成配置。Odysseus 官方对 AMD 的处理方式是“只读诊断 手动改.env”先运行 scripts/check-docker-amd-gpu.sh 拿到宿主机 render 组的数字 GID再把COMPOSE_FILE和RENDER_GID写入.env重启后用一条docker compose exec命令确认容器内能看到/dev/kfd与/dev/dri/renderD*。适用前提是 docs/setup.md 中给出的环境CPU-only 用户可以直接跳过这套配置。前置条件主机 ROCm 驱动与组权限docker/gpu.amd.yml 的文件头注释写明了启用 overlay 的两个硬性前提主机已安装 ROCm 驱动即/dev/kfd与/dev/dri设备节点存在在宿主机上运行 Docker 的用户必须属于video和render两个组。overlay 本身只做一件事把宿主 GPU 直通给odysseus服务——挂载/dev/kfd、/dev/dri两个设备并通过group_add把容器加入video组和${RENDER_GID:-render}指定的组。也就是说RENDER_GID必须是你宿主机 render 组的数字 GID如果不设置overlay 会退回用组名render。另一个要注意的边界slim 版 Odysseus 镜像不打包 ROCm 用户态userspace和推理引擎overlay 只负责设备直通这一层。第一步运行只读诊断脚本拿到 RENDER_GIDscripts/check-docker-amd-gpu.sh脚本自身的定位是只读诊断不安装任何包、不编辑.env、不重启 Docker 守护进程。它做四项检查宿主机/dev/kfd与/dev/dri/renderD*是否存在宿主机 render 组以及 video 组的数字 GID即后续要写进.env的RENDER_GID宿主机上rocminfo是否可见可选项找不到不阻塞直通用一个小型容器做直通冒烟测试docker run --rm挂载/dev/kfd和/dev/dri、带上对应--group-add测试容器内能否列出 render 节点。副作用说明第 4 项会实际启动一个临时容器--rm会立即删除它首次运行可能拉取默认的alpine:3.20测试镜像可用环境变量ODYSSEUS_AMD_TEST_IMAGE换成别的镜像。脚本输出逐项标记[PASS]/[FAIL]/[WARN]最后汇总为一行 Results: N passed, N warnings, N failed 且只有FAIL为 0 时退出码才是 0。常见的 FAIL 项和脚本给出的提示/dev/kfd缺失——宿主机没有 ROCm 内核驱动访问Docker 守护进程未运行或当前用户没有 Docker 权限直通冒烟失败——脚本建议检查 Docker 能否访问/dev/kfd和/dev/dri后重试render 组找不到——提示按发行版实际的组名手动设置RENDER_GIDvideo 组找不到只是 WARN脚本注明部分主机上/dev/kfd与renderD*可能已经够用。诊断通过后脚本会打印一段建议写入.env的值格式为COMPOSE_FILEdocker-compose.yml:docker/gpu.amd.yml RENDER_GID宿主机 render 组的数字 GID第二步把 COMPOSE_FILE 与 RENDER_GID 写入 .envRENDER_GID有两个可靠来源二选一即可脚本输出中的render group GID: NNNNoverlay 文件头注释给出的宿主机命令getent group render | cut -d: -f3拿到数字后写入.env也可以 export 到运行docker compose的 shell 环境中按 docs/setup.md 的示例COMPOSE_FILEdocker-compose.yml:docker/gpu.amd.yml RENDER_GID989其中989是 setup 文档里给出的示例值替换成你自己宿主机上查到的 render 组 GID。配置好 overlay 后建议通读 docker/gpu.amd.yml 中的注释确认 devices 与 group_add 的行为符合你的预期。重启并验证容器内设备节点重启 Odysseus 让新的.env生效compose 会用 overlay 的 devices 与 group 配置重建odysseus容器然后执行 AMD 的验证命令docker compose up -d docker compose exec odysseus sh -lc test -e /dev/kfd test -d /dev/dri ls -l /dev/kfd /dev/dri/renderD*判断方式命令以退出码 0 结束、ls -l列出/dev/kfd与/dev/dri/renderD*节点说明设备直通已经在容器内就位。这里有一条必须记住的边界setup 文档明确强调看到/dev/kfd与/dev/dri只确认了设备直通不代表 ROCm 用户态或 vLLM/llama.cpp 的 ROCm 构建可用。slim 版 Odysseus 镜像内不预期存在rocm-smi或rocminfo所以不要试图在容器里用它们做验证。直通成功之后安装 ROCm 兼容的推理运行时设备直通是 GPU 推理的必要条件而非充分条件。要实际跑 GPU 模型按 overlay 注释和诊断脚本末尾的提示先通过Cookbook → Dependencies或 pip安装 ROCm 兼容版本的 vLLM 或 llama-cpp-python再开始 serve 模型。如果你只是让容器内应用连接远程模型端点则不需要这一步。可选分支堆栈管理 UI 使用单文件 ComposePortainer、Coolify、Dockhand 等工具通常只接受单个 Compose 文件且不能可靠地识别COMPOSE_FILE或多个-foverlay。这种环境下把 stack 指向仓库根目录的 docker-compose.gpu-amd.yml 即可它等价于docker-compose.ymldocker/gpu.amd.yml前置要求相同宿主机 ROCm/kfd/DRI 配置、video/render组成员身份以及需要时的RENDER_GID。文档明确说明基础文件加 overlay 才是权威来源单文件版本只是为单文件部署做的镜像。CLI 用户继续走COMPOSE_FILEoverlay 流程。限制与排查Cookbook 看不到预期的 GPU 时Cookbook 只能检测到 Docker 暴露给容器的 GPU。如果主机运行时或设备直通没配置好Cookbook 看到的是核显、另一块卡或 CPU而不是你预期的 GPU——先回到第一步确认冒烟测试通过。验证命令非 0 退出说明容器内缺少/dev/kfd或/dev/dri的 render 节点对照诊断脚本的 FAIL 项逐项排查宿主机驱动、组权限与 Docker 访问。直通通过但推理仍落到 CPU这与 Docker 直通无关属于运行时问题——vLLM 与 llama.cpp 仍需要 ROCm 兼容构建或 ROCm 专用 Docker 镜像参见上一节的安装步骤。整套流程到此形成闭环诊断脚本给出 GID 与直通冒烟结果.env里两行配置启用 overlaydocker compose exec一条命令完成容器内验证后续再按 Cookbook 安装 ROCm 运行时。【免费下载链接】odysseusSelf-hosted AI workspace.项目地址: https://gitcode.com/gh_mirrors/ody/odysseus创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考