执行摘要
本 PR 对 vLLM 仓库的 requirements/ 目录进行了结构性重构，将构建和测试需求文件分别迁移到 requirements/build/ 和 requirements/test/ 子目录，并统一了跨设备（如 XPU）的依赖管理处理。此变更涉及 40 个文件的更新，旨在减少目录噪音、提升维护一致性，对用户无直接影响，但为团队未来的依赖管理奠定了基础。
功能与动机
当前 requirements/ 目录中混杂了构建、测试和用户需求文件，导致管理混乱。根据 PR body 描述，本 PR 的目标是“减少 noise 并改善跨设备依赖管理的一致性”。具体来说，通过分离 build-only 和 test-only 文件，并为 XPU 设备添加 pip compile hook，确保所有 requirements/test/<device>.in 文件被标准化处理，从而简化维护流程。
实现拆解
实现方案按模块拆解如下：
- 文件重组模块：重命名并移动关键文件，例如：
requirements/build.txt → requirements/build/cuda.txtrequirements/test.in → requirements/test/cuda.in- 类似处理 ROCm、XPU、CPU 等设备文件（如
requirements/rocm-test.in 移至 requirements/test/rocm.in）。
- 引用更新模块：更新所有相关配置文件，包括：
- CI 配置：
.buildkite/ci_config.yaml 等文件中修改触发模式。
- Dockerfiles：
docker/Dockerfile 和 docker/Dockerfile.cpu 等调整安装路径。
- 文档：
docs/ 下的安装指南更新路径引用。
- 工具集成模块：在
.pre-commit-config.yaml 中新增 pip-compile hook 用于 XPU，代码片段如下：
```yaml
- id: pip-compile
alias: pip-compile-xpu
args: [
requirements/test/xpu.in,
-c, requirements/xpu.txt,
-o, requirements/test/xpu.txt,
--index-strategy, unsafe-best-match,
--torch-backend, xpu,
--python-platform, x86_64-manylinux_2_39,
--python-version, "3.12",
]
```
此更改确保所有设备测试需求文件被统一编译，提升一致性。
评论区精华
Review 中无争议，但 Issue 评论揭示了关键讨论点：
- CI 失败处理：mergify[bot] 多次报告合并冲突和预提交检查失败，作者 hmellor 回应“Since this PR just moves requirements files around all failures should be unrelated”。
- 团队协作：评论者 jikunshang 指出“intel ci is breaking due to known issue, will be fixed by #39296 #37947 we can ignore and move forward”，体现了团队对基础设施问题的共识处理。
- 结论：基于讨论，决定忽略无关失败并推进合并，强调本 PR 的机械变更本质。
风险与影响
技术风险：
- 文件路径变更可能导致构建或测试脚本引用错误，例如 Dockerfile 中遗漏更新路径会引发安装失败。
- 新增的 pip-compile hook 可能因平台差异（如 XPU 的 Python 平台设置）引发依赖解析问题。
- 由于广泛的文件移动，可能引入拼写错误，但通过多次提交合并已缓解。
影响评估：
- 用户影响：无直接影响，这是内部目录结构调整。
- 系统影响：改善依赖管理结构，使未来添加新设备或测试需求更便捷，提升可维护性。
- 团队影响：简化开发体验，减少
requirements/ 目录混乱，但需要工程师适应新路径。影响程度中等，涉及 40 个文件更新。
关联脉络
从近期历史 PR 分析看，本 PR 是基础设施演进的一部分：
- 关联 PR 39523（修复 pre-commit 触发系统）和 38455（添加 AMD GPU 设备 ID），都涉及 CI 和设备依赖管理，体现了仓库向多设备支持迈进时对依赖管理标准化的需求。
- 本 PR 为 future PR（如添加新模型或设备）提供了清晰的目录结构，可能减少后续变更的复杂性。总体而言，这反映了 vLLM 项目在维护大型代码库时对基础设施整洁度的持续投入。
参与讨论