执行摘要
cu134 镜像改用 kernel 构建节点
PR 描述中指出,arm-docker-build-node 包含一些较弱的节点,而 cu134 镜像构建过程中需要从源码重新编译 CUDA wheel,因此需要使用更强的 labubu 节点(即 arm-kernel-build-node)来确保构建成功和效率。
该 PR 为简单的 CI 配置调整,值得快速浏览以了解构建节点选择策略,但无需精读。
无 review 讨论,仅 Fridge003 批准合并。
PR 描述中指出,arm-docker-build-node 包含一些较弱的节点,而 cu134 镜像构建过程中需要从源码重新编译 CUDA wheel,因此需要使用更强的 labubu 节点(即 arm-kernel-build-node)来确保构建成功和效率。
该 PR 为简单的 CI 配置调整,值得快速浏览以了解构建节点选择策略,但无需精读。
无 review 讨论,仅 Fridge003 批准合并。
.github/workflows/release-docker-cu134-nightly.yml 工作流文件。build-arm64 作业的 runs-on 从 arm-docker-build-node 改为 arm-kernel-build-node,并添加注释说明原因。| 文件 | 模块 | 状态 | 重要度 |
|---|---|---|---|
.github/workflows/release-docker-cu134-nightly.yml |
CI 工作流 | modified | 3.05 |
.github/workflows/release-docker-cu134-nightly.yml
infrastructure
修改 cu134 nightly 镜像构建的 runner 节点,影响构建效率和稳定性。
# .github/workflows/release-docker-cu134-nightly.yml 片段
jobs:
build-arm64:
if: github.repository == 'sgl-project/sglang'
# Use kernel builder node since we need to build wheels from source.
runs-on: arm-kernel-build-node
environment: ${{ (github.event_name == 'schedule' || !inputs.build_only) && 'prod' || null }}
# Cold builds recompile three CUDA wheels from source.
timeout-minutes: 360
当前评论区没有形成足够清晰的争议点或结论,后续有更多讨论时会体现在这里。
风险较低。改动仅影响 CI 构建节点选择,可能影响构建环境的一致性(如依赖版本差异),但由于明确指定了 kernel 构建节点,且注释说明了原因,风险可控。
影响范围限于 cu134 nightly 镜像的构建流程,可能改善构建稳定性和速度,对用户和系统无直接影响。
当前没有检测到明确关联的 Issue 链接,后续同步到相关引用后会出现在这里。
参与讨论