FlagOS 多芯片软件栈安装

要解决什么问题

在多厂商 GPU 上跑 FlagOS 相关推理栈时，依赖往往拆成多个 Python/C++ 包，且安装顺序和 wheel 选择强相关。手工在容器里逐个 pip install、make 和 import 验证，容易漏步骤、选错 Triton wheel，或在 vLLM 未就绪时继续装下游导致难以排查的报错。

技能如何工作

本技能面向已在运行的 Docker GPU 容器（需已知容器名；GPU 厂商可传入或由脚本探测）。整体按固定流水线执行：

• Step 0～2：确认容器运行；在容器内执行 collect_env_info.py 采集厂商、Python/glibc、架构与磁盘；运行 detect_network.py 解析 GITHUB_PREFIX 与 PIP_INDEX；磁盘不足 10GB 时告警并询问是否继续。
• Step 3：按依赖链安装五件套：vLLM 0.13.0 → FlagTree → FlagGems → FlagCX → vllm-plugin-FL。vLLM 与 vllm-plugin-FL 为门禁：任一失败则记录并退出；FlagTree 无匹配 wheel 时记录 mismatch 但可继续；FlagGems/FlagCX 失败记录后继续。FlagCX 分两阶段（C++ 库 + PyTorch 插件），厂商相关参数见 vendor-mappings.md；Iluvatar 上 plugin 的 requirements 可回退到 requirements_iluvatar.txt。
• Step 4～6：运行 validate_packages.py 生成 JSON 校验报告；成功安装 FlagCX 时持久化 FLAGCX_PATH；汇总为 PASS / PARTIAL / FAIL 结构化结果。各步骤带超时（如 pip 300s、网络探测 5s）。

若独立调用且未给 --vendor，会在探测未知时向用户确认厂商。

适用边界

• 前置假设：容器内已有 PyTorch 与 GPU 访问（常与 /gpu-container-setup 衔接）；从 /flagrelease 编排调用时可注入容器名与厂商上下文。
• PARTIAL 表示 vLLM 与 plugin 已装但 FlagTree/FlagGems/FlagCX 部分失败；仅当 vLLM 或 plugin 门禁失败时整体为 FAIL。
• 网络直连与镜像均不可达时会直接退出，不会静默降级。