sglang-sota-humanize-loop

SGLang SOTA 人間化ループ

概要

ユーザーがモデル名を指定し、同じターゲット環境で設定された比較フレームワーク群の中で、再現可能な最良結果に匹敵するか、それを上回るまでSGLangのサービング経路を自律的に改善し続けることを求めている場合に、このスキルを使用します。

このワークフローには、永続的な要素が2つあります。

1. コードにパッチを適用する前に、一度だけ完了させる固定ベースラインフェーズ。
2. ギャップの判断、プロファイリング、必須のレイヤー／カーネルの詳細分析、SGLangへのパッチ適用、任意のNCU証拠、および実モデルでの再検証を担う1つのHumanize RLCRループ。

キャンペーンを、ループ前のプロファイリングフェーズと後続のパッチ適用ループに分割しないでください。固定ベンチマークが作成された後は、フェーズ2のギャップ判断、フェーズ3のプロファイリング、llm-pipeline-analysis、カーネルの証拠、コード変更はすべて、同じモデル単位のRLCRループに含まれます。

実行環境のルート

このスキルは、Claude Code、Codex、またはその他の互換性のあるスキル実行環境から実行できます。次の順序で関連するルートを解決してください。

1. Claude Codeで実行する場合は、~/.claude/skills 配下にインストールされたClaude Codeスキルを優先します。
2. Codexで実行する場合は、${CODEX_HOME:-~/.codex}/skills 配下にインストールされたCodexスキルを優先します。
3. スキルがシンボリックリンクされている場合や、開発用にローカルに置かれている場合は、チェックアウト済みのリポジトリにフォールバックします。

ローカルパスの例：

Humanize runtime: ${CODEX_HOME:-~/.codex}/skills/humanize
ncu-report-skill: ${CODEX_HOME:-~/.codex}/skills/ncu-report-skill/SKILL.md
Model PR history knowledge: <repo>/model-pr-optimization-history

Claude Codeにインストールされている場合の同等のデフォルトは、通常、次のとおりです。

Humanize runtime: ~/.claude/skills/humanize
ncu-report-skill: ~/.claude/skills/ncu-report-skill/SKILL.md
Model PR history knowledge: ~/.claude/skills/model-pr-history-knowledge

Humanizeの実行環境が見つからない場合は、scripts/setup-rlcr-loop.sh を含むプラグインまたはスキルディレクトリを探してください。ncu-report-skill が利用できない場合でも、torch-profilerやソースコードの証拠に基づいてカーネルの編集を進めることはできます。ただし、通常ならNsight Computeの診断が必要となるカーネル変更については、NCUの証拠を得る経路が利用できないことをブロッカーとして記録してください。

関連スキル

実際の実行前に、以下を読んでください。

• ../llm-serving-auto-benchmark/SKILL.md
• ../llm-torch-profiler-analysis/SKILL.md
• ../llm-pipeline-analysis/SKILL.md
• ../../model-pr-optimization-history/SKILL.md
• SSH、コンテナ、GPU、アーティファクトの規約に対応するホストまたはオペレーターのスキル

アクティブなRLCRラウンドでCUDA、Triton、CuTe、CUTLASS、TileLang、またはtorch.compileのカーネル経路を作成または評価し、Nsight Computeの証拠が必要な場合にのみ、ncu-report-skill/SKILL.md を読んでください。

契約

モデル単位のSGLang SOTAリクエストを受けた場合、個別のベンチマーク、プロファイラー、gen-plan、refine-plan、またはHumanizeのセットアップコマンドをユーザーに実行させないでください。セットアップは自分で行ってください。

モデル、ターゲットGPU環境、または精度／量子化ポリシーが不明で、ローカル設定やアクティブなホストスキルから推測できない場合に限り、ユーザーに確認してください。

RLCRパッチ適用ループの外に置くのは、固定ベンチマークフェーズだけにしてください。固定のフレームワーク横断ベンチマークとモデルのPR履歴メモが揃ったら、Humanizeを開始します。RLCRループ自体で、ギャップが残っているかを判断し、最新のプロファイリング証拠を収集し、レイヤーパイプライン分析を実行し、SGLangにパッチを適用して、再検証する必要があります。

モデル最適化キャンペーンを、単一のターミナルセッションではなく、永続的な作業単位として扱ってください。キャンペーンは、実行アーティファクトのルート、チェックポイントファイル、ベンチマーク／プロファイリングのアーティファクト、NCUダイジェスト、台帳から復旧できます。

フェーズ0：入力と実行ディレクトリ

次の情報を収集するか、推測してください。

• モデルIDまたはチェックポイントのパス、トークナイザー、精度、量子化、信頼ポリシー、最大コンテキスト長
• パッチを適用する対象のSGLangチェックアウト
• GPUの種類／台数、可視GPU ID、コンテナまたはリモートシェル、CUDA／NCCLのバージョン、複数ノードの使用可否
• 対象フレームワーク：常にSGLang
• 比較対象のフレームワーク群：ユーザーが比較対象のフレームワークを明示または除外した場合は、その指定どおりにします。それ以外の場合は、利用可能であればvLLM、TensorRT-LLM、TokenSpeedをデフォルトとします
• 可能であれば、モデルID、チェックポイント、またはホットなフレームワークソースのパスから推測したモデルファミリーの履歴スラッグ
• アーティファクトのルート

実行ディレクトリを1つ作成します。

runs/YYYYMMDD_<model_slug>_sota_humanize/
  manifest.md
  help/
  benchmark/
    fairness/
  profiles/
  analysis/
    root-cause.md
    layer-pipeline.md
    fairness-diagnostics.md
  history/
    model-pr-history-notes.md
  kernel/
    ncu-digests/
  patches/
  humanize/
    model-loop-checkpoint.md
  final_report.md

Hugging Faceのトークンやその他のシークレットをアーティファクトに保存しないでください。

フレームワークの選定

SGLang と比較対象のフレームワークは、別の概念として扱います。

• SGLang は、このループが SGLang にパッチを適用するため、常に対象のフレームワークです。
• comparison_frameworks には競合のみを含め、正式名称の vllm、tensorrt_llm、tokenspeed を使用します。
• ユーザーが「vLLM とのみ比較する」、「comparison_frameworks: [vllm]」、 または「TensorRT-LLM／TokenSpeed は考慮しない」と指示した場合は、SGLang と vLLM のみを実行します。
• 設定やドキュメントが存在するという理由で、TensorRT-LLM や TokenSpeed を暗黙に追加してはいけません。
• 選択した比較対象フレームワークと、ユーザーが除外したフレームワークを manifest.md と benchmark/fairness/diagnostics.md に記録します。
• 選択した比較対象フレームワークのセットについてのみ、競合の履歴を読み込み、競合のベンチマークを実行し、 競合のトレースをプロファイリングします。

フェーズ 0.5：モデル PR 履歴の確認ゲート

固定ベンチマークの実行およびパッチの計画に着手する前に、対象モデルファミリーについて model-pr-optimization-history を検索し、内容を読みます。

ルール：

• スラッグが不明確な場合は、ナレッジルートから scripts/query.py "<model id or family>" を実行し、 最も近いモデルファミリーの履歴を選びます。
• そのファミリーの SGLang 履歴が存在する場合は、必ず読みます。
• 選択した比較対象フレームワークが後に最有力の競合となる場合、またはそのソース／トレースから SGLang に未実装の高速パスがあることが示唆される場合は、競合の履歴も読みます。
• 読み込んだパス、PR 番号、不変のソースヘッド、PR の状態（open、merged、closed-unmerged）、ソースファイル、シンボル、検証の証拠、既知の制約、検証リスク、および各項目が影響する具体的な判断を記載した history/model-pr-history-notes.md を作成します。
• オープン中の PR はベースライン候補としてのみ扱います。完全なヘッド SHA を記録し、記録されたソースヘッドにすでに含まれる動作として記述してはいけません。
• これらのメモは、より適切な SGLang パッチを選ぶためのソースおよび PR の記録として扱います。単独では測定による証拠とはみなしません。

ナレッジルートを利用できない場合は、同じメモファイルにその阻害要因を記録し、ベンチマーク／プロファイルの証拠を用いて作業を続けます。

フェーズ 1：固定公平性ベンチマークのゲート

このフェーズは必須であり、Humanize の開始前にちょうど一度だけ実施します。

候補の生成、結果スキーマ、ワークロード、比較については、llm-serving-auto-benchmark を唯一の情報源として使用します。

必須要件：

• SGLang と、選択した各比較フレームワークについて、対象環境でサポートされている場合は、それぞれ最適なデプロイコマンドを検索します。
• チューニング済みの SGLang を競合のデフォルト設定と比較してはいけません。各フレームワークで、それぞれ独自に範囲を限定した探索を行います。
• 同一のモデル重み、トークナイザー、精度、量子化、GPU の種類と台数、GPU ID、エンドポイントパス、サンプリング設定、SLA を使用します。
• SGLang と、選択したすべての比較フレームワークについて、パッケージバージョンまたは git コミットに加え、サーバーおよびベンチマークの --help スナップショットを記録します。このスキルで確認した 2026-08-23 時点の不変ソースヘッドは、SGLang の eec794bce0808ae26cc1dcb84a56b65d2df82af5、vLLM の bbe8b23e1a2b32a96240b27f63255170d09ef144、TensorRT-LLM の da38c1d2e0dffd073b7dfb6d69e15ee7b45d84a9、および lightseekorg/tokenspeed@2706143a8669d50a8f56466b9d340b86922b8f2d です。ただし、これらのソースノートよりも対象イメージでの --help を優先し、SOTA の長時間実行の前には毎回、オープン PR を再確認してください。
• 対象イメージで現在使われているコマンドを使用します。sglang serve または python -m sglang.launch_server、 vllm serve、trtllm-serve serve --backend pytorch、および選択した場合は tokenspeed serve <model>（または検証済みのイメージエイリアス）を使用します。
• ユーザーが本番ワークロードを明示的に指定している場合を除き、 llm-serving-auto-benchmark のデフォルトの 2 つのデータセットシナリオを使用します。
  • データセット種別は random、num_prompts: 80
  • chat：ランダム入力 1000、出力 1000
  • summarization：ランダム入力 8000、出力 1000
  • 2 つの入力／出力の組み合わせは対応するシナリオとして扱い、直積として扱わないでください。
• 実際の SOTA 判断のために、これらのシナリオをより簡単なスモーク用データセットに置き換えてはいけません。スモーク実行は、フローチェックとして明示する場合に限り許可されます。
• TensorRT-LLM を比較対象として選択した場合は、trtllm-serve serve --backend pytorch を使用します。このスキルでは、PyTorch 以外の TensorRT-LLM サーバーバックエンドは採用しません。
• TokenSpeed を比較対象として選択した場合は、tokenspeed serve <model>、または ts serve など対象イメージでの正確なエイリアスを使用します。正確なバイナリ表記を記録し、tokenspeed serve --help と tokenspeed bench serve --help を検証します。
• TokenSpeed を選択し、そのモデルファミリーに TokenSpeed ネイティブのエージェント型ワークロードが存在する場合は、共通のフレームワーク横断ワークロードに加えて、別レーンとして実行します。ベンチマークの前にユーザーがそのワークロードを SOTA の対象として明示的に選択していない限り、共通シナリオを置き換えてはいけません。
• 失敗、スキップ、または SLA に違反した候補も、ベンチマーク成果物に残します。
• 利用可能な場合は、正規化された行に任意の公平性フィールドも記録します。投機的デコードの受理長、スケジューラー前／スケジューラー時間、キャッシュヒット率、オフロードまたはメモリ常駐状況、エンドポイント、リクエスト形状に関する注記が含まれます。

完了前またはブロッカーを報告する前に停止するのは、この実行で開始したサーバー、ベンチマーク、プロファイラー、ダウンローダー、ログの追跡プロセスだけにしてください。この実行で明示的に作成したモデルスナップショット、ロック、ミラーディレクトリ、実行固有のキャッシュ項目だけを削除します。プロセスと GPU の状態を実行前後で記録してください。他のユーザーのプロセスを強制終了したり、共有モデルキャッシュを削除したりしてはいけません。

以下を作成します。

• benchmark/candidates.jsonl
• benchmark/summary.md
• benchmark/winning-commands.md
• benchmark/fairness/diagnostics.md
• help/ 配下のフレームワークのヘルプ出力
• 各勝者について、正確な起動コマンドとベンチマークコマンド

RLCR の範囲外でコードパッチを選択してはいけません。固定された勝者の表を、モデルループへのベースライン入力とします。

フェーズ 2：Humanize プランを作成する

パッチを適用する SGLang のチェックアウト内に、Humanize プランを作成します。

.humanize/sglang-sota-agent/refined-plan.md

references/refined-plan-template.md をひな形として使い、実際のモデル、ワークロード、ベンチマークの勝者、 アーティファクトのルート、モデルの PR 履歴に関するメモ、対象となる SGLang のチェックアウトを記入します。

プランでは、すべての RLCR ラウンドで以下を必須とします。

• 固定されたベンチマークのワークロードと SLA を維持する
• モデル固有の SGLang ソースパスを選ぶ前に、history/model-pr-history-notes.md を維持し、参照する
• ギャップをコードのボトルネックと判断する前に、benchmark/fairness/diagnostics.md を維持し、参照する
• パッチ適用前に、ループ内でギャップの判断を行う
• SGLang が遅れている場合、または前回のパッチでプロファイル対象のパスが変更された場合は、ループ内で llm-torch-profiler-analysis を実行する
• プロファイラーによるトリアージの後、ソースパス、代表レイヤー、カーネルの対象を選ぶ前に、ループ内で llm-pipeline-analysis を実行する
• ベンチマークパラメーターだけでなく、SGLang のコードにパッチを適用する
• カーネルの編集に Nsight Compute の証拠が必要な場合は、同じループ内で ncu-report-skill を使用する
• パッチを受け入れるたびに、実際のモデルのベンチマークとプロファイルを再実行する
• 1 つのパッチでギャップの一部しか埋まらない場合は、最小限のパッチを複数回適用しながら続ける
• あらゆる試行、失敗した案、部分的な成果、却下したソース案、最終的に選択したパッチをアーティファクトに記録する

フェーズ 3：RLCR を開始する

SGLang のチェックアウトから Humanize を開始する前に、以下を確認します。

• SGLang のチェックアウトが、少なくとも 1 つのコミットを含む Git リポジトリであり、Git で無視される Humanize のランタイム状態のみを除いて、作業ツリーがクリーンであること。
• .humanize* が Git で無視され、RLCR の状態、ラウンドの要約、ローカルのチェックポイントが誤ってステージングされないこと。
• 意図したレビューのベースブランチがローカルに存在すること。Humanize の自動検出で曖昧さが生じる場合は、--base-branch <branch> を渡します。
• SGLang のチェックアウト内に、既存の .humanize/rlcr/*/state.md のうちアクティブなものがある場合、新しいループを開始しないこと。先に、古いモデルループを再開、完了、またはキャンセルします。

SGLang のチェックアウトから、次を実行します。

"$HUMANIZE_RUNTIME_ROOT/scripts/setup-rlcr-loop.sh" \
  .humanize/sglang-sota-agent/refined-plan.md --yolo

クライアント／プラグイン環境で HUMANIZE_RUNTIME_ROOT が設定されていない場合は、まずインストール済みの Humanize ランタイムのパスを解決します。Codex では通常 ${CODEX_HOME:-~/.codex}/skills/humanize、Claude Code では通常 ~/.claude/skills/humanize またはプラグインが提供する Humanize ランタイムです。セットアップがゼロ以外の終了コードで終了した場合は、停止してエラーを報告します。ゲートを迂回しないでください。

セットアップが成功したら、以下を行います。

1. find .humanize/rlcr -maxdepth 2 -name state.md -print を実行し、アクティブな状態ファイルを見つけます。
2. 状態ファイルが存在し、current_round: 0 を含み、--yolo を使用する場合は ask_codex_question: false を含むことを確認します。
3. .humanize/rlcr/<timestamp>/round-0-prompt.md が存在し、生成された Round Contract Setup の指示が含まれていることを確認します。
4. .humanize/rlcr/<timestamp>/round-0-prompt.md を読みます。
5. 現在のラウンドを実行します。
6. SGLang の変更をコミットします。
7. 必須の Humanize ラウンド要約を作成します。
8. 通常どおり停止し、ネイティブの Humanize Stop フックがレビューできるようにします。

アクティブな状態ファイルが存在しない場合、または round-0-prompt.md が見つからない場合は、停止して RLCR が正しく開始されなかったことを報告します。Humanize ループの外で SGLang のパッチ作業を続けないでください。フックが終了をブロックする場合は、生成された次のラウンドのプロンプトに厳密に従ってください。

各 RLCR ラウンド内

ギャップの判定

各ラウンドの開始時に、固定シナリオごとに、現在の SGLang と SLA を満たす選定済み比較フレームワークの中で最良のものとの差を算出します。

デフォルトの安定したノイズ閾値として 1% を使用します。現在の結果が +/-1% 以内の場合は、パッチを選ぶ前に、勝っているコマンドを十分な回数再実行して、ギャップが安定しているかどうかを判断します。

SGLang が選定済みの最良の比較フレームワークより 1% を超えて遅い場合、選定済みの競合フレームワークが SLA を満たす一方で SGLang が SLA を満たさない場合、または固定ワークロードにおいて残るギャップを説明できるプロファイル済みボトルネックがある場合に限り、パッチを適用します。

パッチを適用する前に、現在のベンチマーク行と固定の benchmark/fairness/diagnostics.md に基づいて analysis/fairness-diagnostics.md を更新します。次の項目を確認します。

• GPU 数、可視 GPU ID、モデルの重み、トークナイザー、精度、量子化、エンドポイント、サンプリング設定、リクエスト形状が同じであること
• ドラフター／MTP／EAGLE 形式のパスを有効にしているすべてのフレームワークについて、投機的デコードの状態、アルゴリズム、ステップ数、平均受け入れ長
• サーバーログまたはベンチマーク出力で確認できる場合は、スケジューラー前、スケジューラー、キュー、トークナイザー、デトークナイザーの各処理時間
• 特にプロンプトの繰り返しやマルチターンのワークロードにおける、プレフィックス／KV キャッシュの状態とヒット率
• GPU メモリ使用率、KV のデータ型、オフロード、モデルの重みの常駐状態
• TokenSpeed を選定している場合は、attn_tp_size、moe_tp_size、enable_expert_parallel、バックエンドの選択、通信フュージョンフラグなど、TokenSpeed 固有のサービング設定

現在の首位が、同等でないワークロード、同等でないキャッシュ／投機的デコード設定、異なる常駐重み、またはフレームワーク固有のエンドポイントのショートカットを使ったことで勝っている場合は、まずベンチマークの正規化を修正してから再実行します。この公平性ゲートを通過するまで、SGLang のコードにパッチを適用してはいけません。

SGLang がすでに最良、または安定した閾値以内で同率の場合は、最終レポートを作成し、通常の Humanize レビューパスに従って終了します。

必須のプロファイリング

SGLang が遅れている場合は、現在最良の SGLang コマンドと首位の競合コマンドを llm-torch-profiler-analysis でプロファイルします。

ルール：

• SGLang が遅れている場合は、必ずプロファイルします。
• 少なくとも、現在選定されている最良の比較フレームワークを必ずプロファイルします。
• 安定した結果で SGLang より 1% を超えて速い競合フレームワークが複数ある場合は、トレースを生成できる、先行している競合フレームワークをそれぞれプロファイルします。TokenSpeed では、デプロイメントが出力した既存の torch-profiler トレースまたは実行ディレクトリのトレースを分析します。対象イメージがオフラインのトレースしかサポートしていない場合、ライブのプロファイラーエンドポイントを捏造してはいけません。
• プロファイラーのデフォルトではなく、遅いベンチマークシナリオの長さを使用します。
  • プレフィルのプロファイル：遅い入力長 → 出力トークン 1 個
  • デコードのプロファイル：入力トークン 1 個 → 遅い出力長
• 混合データセットまたは本番データセットでは、ベンチマーク成果物にすでに記録されている、代表的な p50 または p95 バケットのうち最も遅いものを使用します。
• フレームワークが対応している場合は、プレフィルとデコードのエビデンスを別々に取得または分析します。

プロファイルする各フレームワークについて、同じ 3 つの表を保存します。

• カーネル表
• オーバーラップの機会の表
• フュージョンパターン表

その後、現在のフレームワーク横断比較を記載した analysis/root-cause.md を作成または更新します。どのステージが遅いか、どの表の行がその原因を説明するか、どの SGLang のソースパスまたはカーネル群が妥当なパッチ対象かを記載します。

現在のギャップについてこのレポートが存在するまで、SGLang にパッチを適用してはいけません。

レイヤーパイプラインの詳細分析

各 RLCR ラウンドで、プロファイラーによるトリアージの後、パッチ対象を選ぶ前に llm-pipeline-analysis を実行してください。

レポートでは、次の項目を特定する必要があります。

• 選択したフォワードパスと、それが代表的である理由
• 関連するレイヤータイプ。特に、MoE、ハッシュレイヤー、compress_ratios などの異種レイヤー
• パッチ対象を代表するレイヤー
• それらの代表的なレイヤーにおける上位のホットカーネル
• 調査に必要な Perfetto の時間範囲

プロファイリング済みの SGLang トレースと、提供されたモデル設定を使用してください。選択したフォワードパス、レイヤータイプ別のタイミング表、代表的なレイヤー、上位のホットカーネル、および調査に使用した Perfetto の時間範囲を記載した analysis/layer-pipeline.md を作成してください。このレポートを現在のラウンドで作成するまでは、SGLang のパッチ対象を選ばないでください。

カーネルエビデンスの補助

ncu-report-skill は、実行中の RLCR ラウンドで具体的なカーネルまたは小規模なカーネルファミリーのパッチを作成しており、次の編集を選択または検証するのに torch-profiler のエビデンスが不十分な場合に限り使用してください。

適用条件：

• 必須の再実行／プロファイラー確認後も、固定されたベンチマークシナリオにおいて SGLang が選定済みの最良の比較対象フレームワークに 1% を超える差をつけられていないこと。
• 遅いステージに、カーネル表で累積 GPU 時間の割合が少なくとも 1% の、具体的な SGLang カーネルまたは対象を絞ったカーネルファミリーがあること。単独のカーネルの割合が 1% 未満の場合は、共有実装が割合 1% を超える集約ファミリーに影響する場合を除き、カーネル専門の作業に時間を費やさないでください。
• llm-pipeline-analysis によって、現在のラウンドの代表的なレイヤー／フォワードパスと上位のホットカーネルが特定されていること。
• 提案するカーネル対象に、明確な正当性の基準、モデル実行から得られた代表的な形状／データ型／レイアウト、および候補をアクティブな SGLang のサービングコードに組み込む手段があること。

対象となる各カーネルについて：

1. ncu-report-skill/SKILL.md を読み、ハーネスの構築、ncu による収集、レポートの解析、ストールの診断、エビデンスに基づく次の編集の選択について、記載された Nsight Compute のワークフローに従ってください。
2. NCU の出力を kernel/ncu-digests/<version>/ またはホストの同等の成果物ルートに保存してください。各ダイジェストではベースラインと候補を比較し、最後に具体的な次の編集をちょうど 1 つ記載してください。
3. SGLang のチェックアウト内で、SGLang カーネルまたは呼び出しパスに直接パッチを適用し、可能な場合は対象を絞った正当性確認とマイクロベンチマークを行ってください。
4. 候補を、元のプロファイラーの行を生成したアクティブなモデルサービングパスに組み込んでください。
5. 候補の正当性を確認したら、同じ実モデルのベンチマークとプロファイラーを再実行してください。マイクロベンチマークや NCU での改善だけでは成功とはみなしません。

対象を絞ったハーネスがない場合は、モデル由来の形状／データ型／レイアウトを維持する、最小限のハーネスを構築してください。ホストで NCU を実行できない場合は、その阻害要因をダイジェストのパスに記録し、利用可能な torch-profiler、レイヤーパイプライン、ソースコードのエビデンスに基づいて次の編集を選んでください。

カーネル対象について、単独の .humanize/rlcr セッションを開始しないでください。カーネル作業は、実行中のモデル RLCR ループ内で行ってください。

モデルループのチェックポイント

各ラウンドを承認した後、humanize/model-loop-checkpoint.md を更新し、次の情報を記録してください。

• 元のモデル、トークナイザー、精度、量子化、ハードウェア、ワークロード、SLA、成果物ルート、ベンチマーク優勝時のコマンド
• 現在の SGLang ブランチ、コミット、適用済みパッチ、実行したテスト、現在最良の SGLang ベンチマーク結果の行
• 残っている差、プロファイラーの行、モデル PR の履歴メモ、レイヤーパイプラインのメモ、NCU ダイジェストのパス、採用しなかったソースコード上のアイデア、次に予定する SGLang のパッチ

このチェックポイントは、同じモデルレベルのワークフロー内でキャンペーンを復旧するためのものです。ベンチマーク／プロファイルの系譜を失わずにキャンペーンを再開できるよう、十分なコンテキストを記録します。

ループ記録

ホストの慣例に応じて、これらのファイルを実行アーティファクトのルートまたは SGLang のチェックアウト内に保存してください。

humanize/attempt-ledger.md
humanize/optimization-ledger.md
humanize/source-idea-ledger.md
humanize/lineage.jsonl
humanize/profile-digests/

パッチを試みるたびに、試行の行を記録してください。正しく、測定された改善が得られたパッチのみ、最適化の行を記録してください。ソースに関するアイデアには、プロファイラーの行、レイヤーパイプラインのエビデンス、使用した場合は NCU レポートのパス、およびコードの出所を含め、後のラウンドで同じソースを読み直さずに済むようにしてください。パッチに影響したモデルの PR 履歴のエビデンスは、SGLang、選定した比較対象のフレームワーク、NCU のソースアイデアと並べて記録してください。

直前の SGLang の最高結果に対する幾何平均の改善が 1% 未満のラウンドが 2 回連続したら、再度編集する前に、コードを優先した調査の範囲を広げてください。文章のみの記事よりも、SGLang、選定した比較対象のフレームワーク、および関連するカーネルのソースガイドから得られるコードと PR のエビデンスを優先してください。

停止条件

次のいずれかに該当する場合に限り、停止してください。

• 固定ワークロードにおいて、SGLang が SLA を満たす選定済み比較対象フレームワークの最高結果を上回る。
• 反復実行で、SGLang が安定した 1% のしきい値以内で同等となる。
• 残る差が、利用できないハードウェアサポート、欠落しているフレームワーク依存関係、未対応の TensorRT-LLM PyTorch バックエンド、未対応の TokenSpeed ビルド、または公平に読み込めないモデルの重みなど、SGLang の外部要因によるものと証明される。
• プロファイルのエビデンスから、残るホットパスがすでに該当するハードウェアまたはアルゴリズムの限界に近く、リスクの低い SGLang のパッチが残っていないことが示される。

最終レポートには、固定ベンチマーク表、パッチ適用後のベンチマーク表、勝者のコマンドすべて、モデル PR 履歴のパス、プロファイルのパス、使用した場合はレイヤーパイプラインのパスと NCU ダイジェストのパス、SGLang の変更ファイル、テスト、および SGLang がターゲット環境の SOTA に到達したかどうかを含めてください。