GitLab CI通过标签机制实现GPU构建分流：注册时为GPU服务器Runner指定gpu等标签，作业中用tags: [gpu]声明需求，系统自动调度至匹配的在线Runner。

直接用 tags 实现 GPU 构建分流，核心是“注册带标签的 Runner + 作业指定匹配标签”。这不是靠脚本判断架构，而是 GitLab CI 的原生调度机制。

注册专用 GPU Runner 并打上 gpu 标签

在装有 NVIDIA 驱动和 CUDA 的 Linux 服务器上，执行注册命令时明确指定 --tag-list：

• 运行 gitlab-runner register
• 按提示输入 GitLab 实例 URL、项目或实例 token
• 当问到 Tags 时，输入 gpu（也可加其他语义标签，如 cuda-12.4,ubuntu-22.04）
• 选择执行器：推荐 docker 或 docker+machine，确保容器能访问宿主机 GPU（需挂载 /dev/nvidia* 和安装 nvidia-container-toolkit）
• 完成注册后，该 Runner 在 GitLab 后台会显示为带有 gpu 标签的可用节点

在 .gitlab-ci.yml 中精准匹配 GPU 任务

只需在需要 GPU 资源的 job 中声明 tags，CI 系统自动路由：

Linux Ai Server

Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。

下载

• 例如训练任务写成：

train:
  image: nvidia/cuda:12.4.1-devel-ubuntu22.04
  tags:
    - gpu
  script:
    - python train.py

• 这个 job 不会发给只标了 cpu 或无标签的 Runner；也不会被多个 gpu Runner 争抢——GitLab 自动选一个空闲的
• 可搭配 only 或 rules 进一步限定触发条件（如仅 main 分支 + train/ 目录变更）

多类型硬件共存时的标签设计建议

一台物理机可注册多个 Runner，每个专注一类资源，靠标签隔离：

• gpu-runner-01 → tags: gpu, cuda12, high-mem
• arm64-builder → tags: arm64, cross-compile
• fast-cpu-test → tags: cpu, ssd-cache
• CI 作业里写 tags: [gpu, cuda12]，就只会命中第一个 Runner
• 避免使用模糊标签（如 fast），优先用可验证的硬件/软件特征

验证与排错要点

分流是否生效，关键看三点：

• Runner 页面中，对应 Runner 的 Tags 列是否显示你设定的值（如 gpu）
• Job 详情页的 Runner 字段是否显示该 GPU Runner 的名称
• Job 日志开头是否有类似 Using docker image sha256:... for gpu with gitlab-runner...
• 若 job 一直 pending，检查 Runner 状态是否为 online 且 active，并确认其 tag 拼写与 .gitlab-ci.yml 完全一致（区分大小写）