flagrelease-entrance-flagos

FlagRelease パイプラインオーケストレーター

マルチチップ GPU バックエンド向けの、LLM のデプロイとテストをエンドツーエンドで実行するパイプラインです。 4 つのサブスキルを順番にオーケストレーションし、最終レポートを作成します。

スキルの構成要素

flagrelease/
├── SKILL.md                            # This file — orchestration flow
└── references/
    └── pipeline-state.md               # Pipeline state schema, gate logic, data flow

サブスキル（それぞれ個別に呼び出し可能）：

../install-stack/                       # Step 2: Install 5 packages
│   ├── SKILL.md
│   ├── scripts/
│   │   ├── detect_network.py           # Probe GitHub/PyPI, return mirror config
│   │   ├── collect_env_info.py         # Python/glibc/arch/vendor/disk info
│   │   ├── select_flagtree_wheel.py    # Match vendor+python+glibc → wheel
│   │   └── validate_packages.py        # Import-test all 5 packages
│   └── references/
│       ├── vendor-mappings.md          # FlagCX make flags, adaptor names
│       └── network-mirrors.md          # Mirror config rules

../env-verify/                          # Step 3: Qwen3-0.6B smoke test
│   ├── SKILL.md
│   ├── scripts/
│   │   ├── run_offline_inference.py    # Phase A: offline inference test
│   │   └── test_serve_mode.py          # Phase B: serve + health + chat test
│   └── references/
│       └── error-classification.md     # Layer-based error classification

../model-verify/                        # Step 4: Target model ± multi-chip
│   ├── SKILL.md
│   ├── scripts/
│   │   └── diff_analysis.py            # Compare Run A vs Run B results
│   └── references/
│       └── multichip-errors.md         # Multi-chip error patterns

../perf-test/                           # Steps 5+6: Accuracy + Performance
│   ├── SKILL.md
│   ├── scripts/
│   │   ├── run_benchmark.py            # Run single benchmark profile
│   │   └── run_all_benchmarks.py       # Run all profiles + summarize
│   └── references/
│       └── benchmark-profiles.md       # Profile definitions and metrics

パイプラインの概要

[Prerequisite: /gpu-container-setup already done by another team]
       │
       ▼
  install-stack   →  Install 5 packages (vLLM, FlagTree, FlagGems, FlagCX, plugin)
       │                scripts: detect_network, collect_env_info, select_flagtree_wheel
       │
       │  GATE: vLLM + plugin must succeed
       ▼
  env-verify      →  Smoke test with Qwen3-0.6B (FlagGems/CX OFF)
       │                scripts: run_offline_inference, test_serve_mode
       │
       │  Verify Layers 0-3
       ▼
  model-verify    →  Target model test (OFF then ON), diff analysis
       │                scripts: run_offline_inference, test_serve_mode, diff_analysis
       │
       │  Determine which stack works (full vs base)
       ▼
  perf-test       →  Accuracy (placeholder) + Performance benchmarks
       │                scripts: run_benchmark, run_all_benchmarks
       ▼
  Final Report

前提条件

以下の条件を満たす Docker コンテナーが実行中であること：

• PyTorch がインストールされ、GPU にアクセスできる
• コンテナー名がわかっている（例：flagrelease-worker）

このコンテナーは、別のチームが管理する /gpu-container-setup によって作成されます。

実行フロー

状態スキーマとゲートロジックの詳細については、references/pipeline-state.md をお読みください。

Step 0：初期コンテキストの収集

コンテナー名をユーザーに尋ねます（または実行中のコンテナーを検出します）：

docker ps --format '{{.Names}}' | head -10

コンテナーが実行中であることを確認します：

docker inspect --format='{{.State.Status}}' <CONTAINER> | grep -q running

パイプラインの状態を初期化します（references/pipeline-state.md を参照）。

Step 1：ソフトウェアスタックのインストール

../install-stack/SKILL.md を読み、その手順に従います。

install-stack スキルでは、以下を実行します：

1. scripts/collect_env_info.py をコンテナーにコピーして、ベンダー、Python、glibc の情報を取得
2. scripts/detect_network.py をコンテナーにコピーして、ミラー設定を取得
3. scripts/select_flagtree_wheel.py を使用して FlagTree 用のパッケージを選択し、5 つのパッケージを順番にインストール
4. コンテナー内で scripts/validate_packages.py を実行して、最終ステータスを取得

ゲートチェック： gate_passed が false（vLLM またはプラグインのインストール失敗）の場合、パイプラインを停止します。 インストールエラーを報告し、FAIL とします。

結果をパイプラインの状態に保存します。

Step 2：環境の検証

../env-verify/SKILL.md を読み、その手順に従います。

env-verify スキルでは、以下を実行します：

1. Qwen3-0.6B をダウンロード（キャッシュにない場合）
2. scripts/run_offline_inference.py をコンテナーにコピーして、フェーズ A を実行
3. scripts/test_serve_mode.py をコンテナーにコピーして、フェーズ B を実行
4. references/error-classification.md を使用してエラーを分類

判断： 致命的なエラーがある場合は停止します。致命的でない場合は記録して続行します。

結果をパイプラインの状態に保存します。

Step 3：モデルの検証

../model-verify/SKILL.md を読み、その手順に従います。

このステップは対話形式です — ユーザーにモデルのパスを尋ねます。

model-verify スキルでは、以下を実行します：

1. ユーザーからモデル情報を取得（AskUserQuestion）
2. Run A と Run B で run_offline_inference.py と test_serve_mode.py を再利用
3. scripts/diff_analysis.py を実行して結果を比較
4. recommended_stack（full/base/none）を判定

判断： recommended_stack が none（Run A が失敗）の場合は停止します。

結果を（model_path、tp_size、recommended_stack を含めて）パイプラインの状態に保存します。

Step 4：パフォーマンステスト

../perf-test/SKILL.md を読み、その手順に従います。

perf-test スキルでは、以下を実行します：

1. 推奨スタックで vllm serve を起動
2. scripts/run_all_benchmarks.py をコンテナーにコピーして、5 つのプロファイルを実行
3. メトリクスを収集し、サマリーテーブルを作成

結果をパイプラインの状態に保存します。

Step 5：最終レポート

パイプラインの状態からすべての結果をまとめ、最終レポートを作成します：

{
  "status": "PASS | PARTIAL | FAIL",
  "pipeline": "flagrelease",
  "container": "<name>",
  "vendor": "<vendor>",
  "model": "<path>",
  "tensor_parallel_size": 8,
  "steps": {
    "install_stack": { "status": "...", "packages": {...} },
    "env_verify":    { "status": "...", "phase_a": "...", "phase_b": "..." },
    "model_verify":  { "status": "...", "run_a": "...", "run_b": "...", "recommended_stack": "..." },
    "perf_test":     { "status": "...", "profiles_passed": "5/5", "summary_table": "..." }
  },
  "errors": [...],
  "conclusion": "Pipeline completed. ..."
}

以下の項目を明確にまとめてユーザーに提示します：

1. インストールに成功／失敗したパッケージ
2. ベーススタックが動作するかどうか
3. マルチチップスタックが動作するかどうか（動作しない場合は失敗したコンポーネント）
4. パフォーマンスの数値（サマリーテーブル）
5. レイヤー分類を含むすべてのエラー

全体ステータス：

• PASS — すべてのステップに成功し、完全なマルチチップスタックが動作
• PARTIAL — スタックを縮退させるとモデルが動作する、または一部のパフォーマンスプロファイルが失敗
• FAIL — モデルをサーブできない（ゲート失敗または Run A の失敗）

設計ルール

• すべての操作にタイムアウトを設定する — ハングを許可しません
• すべてのエラーを捕捉する — ステップ、フェーズ、レイヤー、原因を正確に記録します
• 成功または構造化エラーレポートを伴って、パイプラインを必ず完了する
• サブステップの失敗によって、無関係なステップをスキップしない（ゲート失敗の場合を除く）
• 直接アクセスに失敗した場合は、ネットワークでミラーを使用する
• スクリプトは JSON を出力する — 構造化され、解析可能で、実行間で比較できます