执行摘要

• 一句话：修复 ARM64 CI 镜像中 pytrec-eval-terrier 构建失败，为测试依赖编译添加 C17 模式。
• 推荐动作：此 PR 是一个针对 CI 构建失败的快速、精确且低风险的修复，值得批准。虽然变更很小（仅 5 行添加），但它有效解决了 GCC 15 升级带来的构建回归。值得注意的设计决策是：修复被严格隔离在测试依赖构建阶段，使用环境变量而非修改全局编译标志，保持了生产构建的纯净性。建议在合并后关注后续 CI 运行，确保整个镜像流水线（包括最终轮子和测试镜像）构建成功。

功能与动机

CPU ARM64 镜像构建失败，具体是在构建 pytrec-eval-terrier==0.5.7 时。如 PR body 所述：'In main build 87636, its bundled trec_eval code uses pre-C23 function declarations; GCC 15's default C23 mode produces incompatible qsort callbacks and conflicting function definitions.' 这是一个功能性的构建回归，不是警告抑制问题，需要修复以确保 CI 正常运行。

实现拆解

1. 变更入口与目标：修改 docker/Dockerfile.cpu，在构建测试依赖的 Docker 阶段（vllm-test-deps 和 vllm-dev）中，为 Python 包编译设置合适的 C 标准。
2. 核心修复逻辑：在安装测试依赖（requirements/test/cpu.txt）的 RUN 指令前，通过 export CFLAGS 环境变量追加 -std=gnu17 编译选项。这确保了包括 pytrec-eval-terrier 在内的所有 C 扩展在安装时使用 GNU C17 标准编译，而非 GCC 15 默认的 C23 标准，从而避免了预 C23 代码的编译错误。环境变量处理使用了 ${CFLAGS:+${CFLAGS} } 模式以兼容已有的 CFLAGS 值。
3. 变更隔离性：此修改仅作用于测试依赖的安装阶段（vllm-test-deps 和 vllm-dev 镜像层），不影响 vLLM 本身的生产构建（vllm-dev 阶段的后续安装步骤）和工具链选择（GCC 15 和 C++ 标志保持不变）。
4. 测试与验证：PR 作者在本地 ARM64 容器中进行了完整验证，包括：
   1) 复现原始错误；
   2) 应用 CFLAGS=-std=gnu17 后成功安装；
   3) 运行 smoke test 验证功能正常；
   4) 通过了 pre-commit 和 git diff 检查；
   5) 最终在完整 CI 环境中构建并验证了 vllm-test-deps 阶段。

关键文件：

• docker/Dockerfile.cpu（模块 部署脚本；类别 infra；类型 infrastructure）: 这是唯一被修改的文件，包含了修复 CI 构建失败的核心 Docker 指令变更。

关键符号：未识别

评论区精华

唯一的 Review 评论来自 claude[bot]，指出这是一个来自 fork 的 PR，自动化审查已禁用，需要仓库维护者手动触发审查。由于 PR 已合并且未有实质技术讨论，讨论内容极少。

• PR 审查流程 (other): 无实质技术讨论。PR 作者在提交说明中详细阐述了修复方案、验证过程和风险分析，可供维护者直接评审。

风险与影响

• 风险：低风险回归修复：
  1. 影响范围：仅影响 ARM64 CPU Docker 镜像的测试依赖构建阶段（vllm-test-deps 和 vllm-dev 的早期步骤）。不触及任何运行时代码、内核或核心逻辑。
  2. 兼容性：使用 -std=gnu17 是向后兼容的，因为 pytrec-eval-terrier 的源码原本就是基于 C23 之前的语法编写的。
  3. 隔离性：修复被精确限制在测试依赖安装步骤，通过环境变量设置实现，不会意外污染后续 vLLM 生产代码的编译（如 AMX FP8 支持等）。
  4. 验证充分性：作者进行了本地复现、功能 smoke test、容器镜像构建验证，覆盖了关键场景。主要不确定性在于最终的 vLLM 轮子/测试镜像和开发镜像尚未在 CI 中完整构建验证（如 PR body 中所述），但核心问题（测试依赖安装）已解决。
• 影响：对用户和系统的影响：
  1. CI/CD：直接修复了 ARM64 CPU CI 管线的构建阻塞问题，使依赖 pytrec-eval-terrier 的检索评估测试得以在 ARM64 环境上运行。
  2. 开发者：确保了 ARM64 开发环境（如 macOS Apple Silicon 开发者）的 Docker 构建流程正常。
  3. 无运行时影响：此变更是纯构建/CI 修复，不改变 vLLM 的任何功能、性能或输出行为。
  4. 团队维护：为未来升级 GCC 或处理类似的 C 标准兼容性问题提供了一个可参考的模式（在 Docker 中为特定依赖设置编译环境）。
     - 风险标记：CI 构建依赖, ARM64 平台兼容性

关联脉络

• PR #55890 [Qwen3.8-Flash-Next] Tune FP8 TP2/TP4 Triton MoE on B200: 此 PR 与 55877 是同一批次的 CI/性能相关提交，虽然领域不同（CPU 构建 vs GPU 内核调优），但都体现了对构建和测试基础设施的持续维护。
• PR #55865 [LoRA] Clarify target module matching logic: 此 PR 与 55877 一起展示了近期仓库中同时进行的代码质量提升（重构）和基础设施修复（CI 构建）工作。