执行摘要

• 一句话：Dockerfile.cpu 构建层瘦身：3.46GB 降至 1.44GB
• 推荐动作：值得快速阅读，改动仅 3 行但收益明确。重点关注三点：BuildKit cache mount 将工具链移出镜像层的写法、构建后清理的边界（只删源码树、保留 wheel），以及作者对远程缓存 lazy 拉取机制的解释，这对理解 CI 中“CACHED 但慢”的现象很有帮助。

功能与动机

PR body 说明：vllm-triton-cpu-build 阶段克隆并构建 triton-lang/triton-cpu，但后续阶段和最终镜像只需要构建出的 wheel；克隆的源码/构建树以及 /root/.triton 下的 LLVM/MLIR 工具链被保留在层中，导致该阶段体积膨胀到 3.46GB。同时作者补充了 CI 观察：BuildKit 的 remote cache import 是 lazy 的，被标记为 CACHED 的步骤其 layer blob 仍会在下游阶段按需拉取，大缓存层会让 CI 看起来“未缓存”或长时间等待；瘦身能直接缓解该问题。

实现拆解

1. 变更入口：仅修改 docker/Dockerfile.cpu（+3/-0），作用于 vllm-triton-cpu-build 阶段。
2. 新增 cache mount：在构建 triton-cpu wheel 的 RUN 指令中追加 --mount=type=cache,target=/root/.triton。Triton 源码构建会向 /root/.triton 下载 LLVM/MLIR 工具链，此前这部分会写入镜像层；改为 cache mount 后既不进入镜像层，又能在多次构建间复用，加速增量构建。
3. 清理源码树：在 uv build --wheel --out-dir=../dist 与 sccache --show-stats 之后追加 cd .. 与 rm -rf triton-cpu，删除克隆的源码与编译产物；wheel 已输出至 /vllm-workspace/dist，后续阶段和最终镜像不受影响。
4. 验证与配套：作者在 base 分支与本分支分别执行 docker build --target vllm-triton-cpu-build，通过 docker history/docker save 对比镜像层大小：3.46GB -> 1.44GB；docker run 检查 /vllm-workspace/dist 中 wheel 存在且不变，triton-cpu 源码目录与 /root/.triton 均不在层内；git diff 确认未触碰其他 stage。

关键文件：

• docker/Dockerfile.cpu（模块 构建脚本；类别 infra；类型 infrastructure）: 唯一变更文件，承载两处关键优化：为 Triton 工具链目录新增 cache mount，并在 wheel 产出后删除源码树，使 vllm-triton-cpu-build 阶段镜像层从 3.46GB 降至 1.44GB。

关键符号：未识别

关键源码片段

docker/Dockerfile.cpu

唯一变更文件，承载两处关键优化：为 Triton 工具链目录新增 cache mount，并在 wheel 产出后删除源码树，使 vllm-triton-cpu-build 阶段镜像层从 3.46GB 降至 1.44GB。

# docker/Dockerfile.cpu 中 vllm-triton-cpu-build 阶段的关键 RUN 指令（本 PR 修改后）
# 本 PR 新增两处：① 增加 /root/.triton 的 cache mount，把 LLVM/MLIR 工具链移出镜像层；
# ② wheel 构建完成后删除 triton-cpu 源码树，最终该层从 3.46GB 减至 1.44GB。
# 下方省略号 `...` 代表 git clone 之后的既有配置 / 编译步骤，未在本 PR 中改动
RUN --mount=type=cache,target=/root/.cache/uv \
    --mount=type=cache,target=/root/.cache/ccache \
    --mount=type=cache,target=/vllm-workspace/.deps,sharing=locked \
    --mount=type=cache,target=/root/.triton \
    --mount=type=secret,id=aws-credentials,target=/root/.aws/credentials,required=false \
    if [ "$TARGETARCH" = "amd64" ] || [ "$VLLM_CPU_X86" != "0" ]; then \
        git clone --recurse-submodules "https://github.com/triton-lang/triton-cpu.git" && \
        ... && \
        uv build --wheel --out-dir=../dist; \
        if [ "$USE_SCCACHE" = "1" ]; then sccache --show-stats; fi; \
        cd .. && \
        rm -rf triton-cpu; \
    fi

评论区精华

claude[bot] 提示：该 PR 来自 fork，自动审查被禁用，需要维护者手动触发 @claude review。jikunshang 直接 APPROVED，未提出技术异议。除此之外没有展开的 review 评论；PR body 中关于 BuildKit lazy 远程缓存的解释是本次变更最有信息量的技术讨论点，但未在评论区进一步展开。

• 暂无高价值评论线程

风险与影响

• 风险：
  1. 构建产物生命周期：该阶段对后续阶段的契约是输出 wheel，删除 triton-cpu 源码树不破坏现状；但未来若需要复用源码树（如打包调试符号或重新构建），需重新加入保留逻辑。
  2. cache mount 并发：/root/.triton 未指定 sharing=locked，多个并发构建可能同时写入同一缓存目录，BuildKit 有基础并发保护，但极端情况下可能造成缓存失效或目录损坏，可通过清理缓存重试恢复。
  3. 远程缓存行为：本次只缩小层体积，未根治 BuildKit 远程缓存 lazy 拉取机制，CI 中偶发的“CACHED 但等待时间较长”现象仍可能出现，只是程度减轻。
  4. 平台差异：cache mount 默认按 target 路径与共享模式定位，若不同架构（amd64/aarch64）构建共享同一构建缓存命名空间，工具链内容可能串用，需观察 CI 是否按架构隔离。
     - 影响：影响集中在 CPU 镜像构建链路：vllm-triton-cpu-build 层从 3.46GB 缩小到 1.44GB，减少约 2GB 镜像仓库存储与拉取流量，在 Buildkite 等远程缓存场景下可缩短下游阶段等待时间。最终运行镜像内容不变，wheel 仍在 /vllm-workspace/dist，无运行时行为变化。对团队而言，这是一个可复制的构建层瘦身范例，后续其他构建阶段可参照使用 cache mount 与构建后清理模式。
     - 风险标记：构建层变更, cache mount 并发共享, 远程缓存行为未根治

关联脉络

• PR #52092 [CPU] Ship triton-cpu wheel and fix several hardcoded pin_memory=True: 同一 docker/Dockerfile.cpu 的 triton-cpu wheel 构建链路，本 PR 是对该构建阶段的镜像层瘦身优化，两者共同构成 CPU 镜像构建链路轻量化方向上的连续演进。