SGLang におけるエージェント支援開発の初期探索

SGLang の開発は、もはや単一箇所のコード修正にとどまらない。現在、同一コードベースが LLM serving、distributed runtime、GPU kernels、diffusion pipelines、モデル固有の実行パス、そして本番環境のインシデント対応を同時にカバーしている。かつて多くのワークフローは開発者個人の経験に依存していた。あるモデルの起動方法、profile trace の読み解き方、CUDA クラッシュ時に最初に追加すべきログの種類、性能 PR に含めるべき benchmark の内容などがそれにあたる。エージェントツールの成熟に伴い、こうした経験は実行可能な SKILL.md、スクリプト、benchmark contract、そして review loop へと転換されつつある。

SGLang を取り巻くエージェント支援開発において、コミュニティは LLM および diffusion ワークロードを対象としたスキル体系を形成してきた。

• SGLang .claude/skills：SGLang メインリポジトリで管理されており、CUDA クラッシュデバッグ、カーネル統合、テスト、CI、プロファイリング、本番トリアージ、ソースツリー規約などのリポジトリレベルのプロセスをカバーする。
• SGLang diffusion .claude/skills：diffusion 固有のワークフローに特化しており、新しい diffusion モデルの追加、benchmark/profiling denoise パス、性能オプションのチューニング、および量子化パイプラインの検証を含む。
• BBuf/AI-Infra-Auto-Driven-SKILLS：クロスフレームワーク serving benchmark、キャパシティプランニング、プロファイル・パイプライン分析、モデルコンピュートシミュレーション、SGLang ヒューマンスタイルレビュー、本番インシデントトリアージ、および SGLang やその他オープンソース推論フレームワーク向けの SOTA ループをカバーする。
• kernel-design-agents：KDA プロジェクトであり、MLSys 2026 FlashInfer Kernel Contest の優勝ソリューションでもある。
• BBuf/KDA-Pilot：KDA スタイルのエージェントカーネルワークフローを SGLang に適用したもの。公開されている B200 diffusion サマリーは現在 10 件の SGLang カーネルタスクを追跡しており、多くの結果は KDA-Pilot の公開 benchmark ledger に基づく。residual_gate_add については、元のタスクベースラインが変更されたため、SGLang integration PR へのマージ後に報告された B200 スピードアップを使用している。KDA-Pilot の派生成果はすでに 3 件の SGLang integration PR に反映されている。

これらの取り組みはひとつの方向性を示している。エージェントの真の価値は、開発者が「感覚でコードを書く」ことを代替するのではなく、工程プロセスにおけるプログラム化された知識――実行可能なステップ、再現可能な実験、審査可能な証拠――を蓄積することにある。

1. TL;DR：エージェントが SGLang で最も適している用途

• 明確に定義されたワークフローに沿って継続的に推進できる場合に、エージェントの価値が最大化される。Benchmarking、profiling、カーネル API ロギング、新しい diffusion パイプラインの追加、本番インシデントリプレイ、SOTA ループはいずれもスキルとして体系化できる。
• SGLang スキルの本質は、実行可能な開発プロセスのセットである。debug-cuda-crash、sglang-diffusion-benchmark-profile、llm-torch-profiler-analysis などのスキルにおいて重要なのはプロンプト自体ではなく、preflight checks、hard failure gates、artifact contracts、再現コマンド、および結果フォーマットである。
• Profile エビデンスは性能最適化の核心である。SGLang profiler スキルは固定カーネルテーブル、オーバーラップ機会テーブル、フューズパターンテーブルを出力する。KDA-Pilot はさらにこれを拡張し、同一 ABI での baseline/candidate 比較、実際のワークロード、正確性ゲート、NCU エビデンス、および shape ごとの結果を提供する。
• 長期最適化は Loop Engineering フェーズへと移行しつつある。SGLang SOTA Performance Loop は「SOTA に追いつく」というタスクを、fair benchmarking、ギャップ判断、プロファイリング、パッチ適用、再検証に分解する。Humanize/RLCR は外部レビューを提供し、Codex Goal はより低い調整コストで同様のループを実行できる。
• レビューの重要性はむしろ高まる。エージェントはより多くの実験を実行できるが、それによって「もっともらしく見える」変更も多く生成される。開発者の役割は問題の定義、エビデンスの選択、プロセスの設計、そして結果が本番パスに進むのに十分かどうかの判断へとシフトする。

2. なぜ SGLang はエージェント支援開発に適しているのか

SGLang は LLM およびマルチモーダルモデル向けの高性能 serving フレームワークである。モデルファミリーとハードウェアパスが拡張し続けるにつれ、開発において繰り返し発生するいくつかの問題が存在する。

LLM パスの複雑さ

ある性能問題が Python runtime、スケジューラ、CUDA graph、Triton/CUDA カーネル、FlashInfer/FlashAttention、distributed collectives、モデル固有のラッパーにまたがることがある。局所的な観察だけでは、ボトルネックがどの層にあるかを判断することは難しい。

Diffusion パスも同様に複雑

低速な denoise パスの原因は、pipeline/stage パーティショニング、DiT ブロック、attention バックエンド、torch.compile のグラフブレーク、CFG/SP 並列性、VAE、あるいはカスタムフューズカーネルにある可能性がある。モジュール間の相互影響がトラブルシューティングの難度をさらに高める。

検証コストが高い

多くの変更は、H100、H200、B200、RTX 5090 などの実際のハードウェア上で、実際のモデルと実際のワークロードを使って検証しなければならない。ローカルのユニットテストだけでは通常、問題を十分に説明できない。

Profile の人手による再利用が困難

単一の trace に数百回のカーネルランチが含まれることがある。Perfetto を手動で読むと、カーネルから Python ソースへのマッピングを見落としたり、prefill と decode を混同したりしやすい。開発者は長期的な分析を通じて、どのカーネル名がどのモデルロジックに対応するか、どのランチパターンがグラフブレークを示唆するか、どの NCCL・attention・MLP レイアウトが正常かといった経験を積む。そうした知識が個人の頭の中だけに留まっていると、次のタスクでは再利用できない。

性能の結論は文脈に強く依存する

GPU の種類、shape、バッチサイズ、並列性、精度、バックエンド、コンパイル状態のすべてが結果を変える。孤立したマイクロベンチマークでは実際のモデルレベルの効果を証明できないことが多く、固定ワークロードの下でスループット、レイテンシ、メモリ、精度、安定性を繰り返し検証するエンドツーエンドの長期テストプロセスが必要となる。このプロセスは人的コストも時間コストも高い。

これらの問題はエージェントの参加に適している。サービスの起動、ワークロードの固定、trace の収集、profile 行の分析、テストの補充、実験結果の記録は、いずれも明確な入力と出力を持ち、スクリプト化と繰り返し実行に適している。開発者がすべきことは境界の設定、すなわち benchmark セットアップの統一、profile 解釈ルールの統一、精度ゲートの統一、そしてエージェントがどの条件でコード修正を停止すべきかの規定である。

したがって、ここでのエージェントは自由に動く「自動プログラマー」ではなく、工程ワークフローによって制約された executor である。SGLang の繰り返し発生する開発プロセスはスキルとして蓄積でき、エージェントが反復作業の実行、エビデンスの収集、状態の維持を担う。開発者は引き続き目標の設定、エビデンスの判断、そして変更が実際の serving パスへの導入に適しているかどうかのレビューを担当する。

3. Prompt Engineering から SKILL へ：工程プロセスのプロトコル化

SGLang フレームワークにおいて、有用なスキルは少なくとも 5 種類の問いに答える必要がある。

SGLang 関連のスキルは複数の層をカバーする。デバッグ、テスト、diffusion モデルの追加、benchmark/profile ワークフローのようにソースコードの変更に近いものもあれば、クロスフレームワーク benchmarking、キャパシティプランニング、コンピュートシミュレーション、本番インシデントトリアージ、PR 最適化知識、SGLang ヒューマンスタイルレビュー、Humanize/RLCR などより上位のワークフローに向けたものもある。

4. 現在の Skill Stack：クラッシュデバッグから性能ループまで

現在よく使われる SGLang エージェント関連スキルは以下のグループに分類できる。

これらのスキルに共通するのは、エージェントに「何をすべきか」を伝えるだけでなく、「どのように開始するか、どのように失敗するか、どのように記録するか、どのように再現するか、どのように納品するか」を明確に規定していることである。これにより、エージェントの出力は一度限りの回答ではなく、審査可能な工程エビデンスに近いものとなる。

5. KDA-Pilot：カーネル最適化を検証可能なプロセスへ

KDA-Pilot は KDA スタイルのエージェントカーネルワークフローを SGLang diffusion シナリオに導入するものであり、重点はカーネルの生成だけでなく、baseline/candidate 対照の確立、実際のワークロード検証、正確性ゲート、NCU エビデンス、shape ごとの結果の構築にある。公開されている B200 diffusion カーネルの結果はすでに 10 件の SGLang カーネルタスクをカバーしており、関連する成果が複数の SGLang integration PR に取り込まれている。

こうしたプロセスが示すのは、性能エンジニアリングにおけるエージェントの核心的な価値が「魔法のような最適化を自動発見する」ことではなく、反復実験・結果整理・エビデンス維持のコストを削減することだという点である。ハードウェア、shape、ABI に強く依存するカーネル最適化のようなタスクでは、一度の生成品質よりもプロセスの制約の方が重要である。

6. 結論：エージェントは工程経験を実行可能にし、開発者は依然として判断を担う

SGLang の実践が示すのは、エージェント支援開発の核心が開発者をループから外すことではなく、開発者が長期にわたって積み上げてきたプログラム化された経験を、実行可能・再現可能・審査可能な工程資産へと変換することだという点である。LLM serving、distributed runtime、GPU カーネル、diffusion パイプライン、本番インシデント対応を同時に扱う SGLang のような複雑なシステムでは、エージェントは反復実行、エビデンス収集、状態追跡を担うのに最も適している。

一方で、レビューの重要性はむしろ高まる。エージェントはパッチ、benchmark、profile をより速く生成できるが、それらの結果には依然として、文脈の不足、指標の選択ミス、本番リスクの過小評価といった問題が含まれている可能性がある。今後の開発者の役割は、問題の境界の定義、スキルワークフローの設計、信頼できるエビデンスの選択、停止条件の設定、そしてある最適化が本当に本番パスへの導入に適しているかの判断に、より重点を置いたものへと変化していくだろう。