Agent Lightning v1.0：実際のハーネスとの接続、GPUの共同利用

1. 訓練用の複製ではなく実際のハーネスを使う

ハーネスは、エージェントのコンテキスト管理とツール実行を調整する実行の枠組みだ。従来のエージェント強化学習システムでは、訓練フレームワークが環境とのやり取りを管理していたため、この枠組みを訓練環境内に再実装する必要があった。

Agent Lightningは、エージェントとモデルの間に言語モデルの中継器を置く。開発者は既存のモデル呼び出し先を中継器に変更し、エージェントは通常どおり実行する。フレームワークは呼び出しと応答を記録し、訓練に活用する。v1.0は、配備に使うエージェントのハーネスが強化学習にも直接参加するアプローチを「ハーネス型エージェント強化学習」と位置付けた。

2. 3つの構成要素がエージェントの実行と訓練をつなぐ

同社によると、複数の機能を組み合わせて開発を支援する基盤であるフレームワーク全体は約3,500行だ。モデル呼び出しを記録するAPIゲートウェイ、エージェントを実行するコントローラー、実行結果を学習データに変えるトレーナーで構成される。コントローラーはローカルプロセスや標準のKubernetesジョブでエージェントを実行し、verlベースのトレーナーは結果を受け取って学習サンプルを構成する。

開発者が接続先を変えるのは、既存ハーネスのモデル呼び出し先だ。これをゲートウェイに変更することで、おおむね訓練に接続できる。実行と学習を分離しているため、ハーネス自体を訓練フレームワーク内に移す作業を減らす設計だ。

3. ハーネスが分割するサンプルを訓練単位として扱う

ハーネスが実行フローを担うと、訓練システムにはモデルへのリクエストと応答が順に入る。1回のタスクが複数のサンプルに分かれるため、サンプル数の多いタスクに学習の比重が偏らないよう、タスク単位でまとめて扱うことが重要だ。

研究チームは、行動が基準よりどれだけ良かったかを評価する「アドバンテージ計算」と、学習誤差の比重を調整する「損失の正規化」をタスク単位で適用した。同社の発表によると、Qwen3.5-9BのSWE-smith検証セットの結果を示す学習200ステップのグラフでは、両手法を併用した方式の検証報酬が約0.37と、比較した方式の中で最も高かった。

アドバンテージ計算だけをタスク単位に変えた方式では、応答選択の不確実性を表す方策エントロピーが約0.65まで上昇した。両手法を併用した方式では、この値がより低く安定していたというのが同社の説明だ。

4. 同じGPUで実行と更新を続ける

エージェントごとの実行時間の差が大きいと、同期学習では最も遅い実行を待つ間、GPUが遊休状態になり得る。完全非同期方式は利用率を高める代わりに、実行と学習に別々のGPU資源を割り当てる。Agent Lightning v1.0の「同居型非同期強化学習」は、1つのGPU群でエージェントの実行とモデル更新を交互に処理する。

実行結果が十分に集まると、新規リクエストを一時停止し、進行中のリクエストを完了してからモデルを更新する。その後に実行を再開するため、外部のハーネスがこの切り替えを直接管理する必要はない。

同社の発表によると、全体の処理速度は同期強化学習より約2倍速く、従来の非同期方式より少ないGPUを使用した。原文の資源配置図は、同期方式と同居型方式にそれぞれGPUを4基、非同期方式にGPUを8基配置した例だ。

5. 性能向上と運用負担を併せて見る

同社は、公開データセットSWE-smithとコーディングエージェントmini-SWE-agentを用い、データの精製から環境構築、報酬操作への対策、強化学習までを含むパイプライン、つまり複数の処理段階をつなぐワークフローを構築した。

同社の発表によると、Qwen3.5-9Bに約6,000件のサンプルで強化学習だけを適用すると、SWE-bench Verifiedで最初の試行で問題を解決した割合が41.8%から56.4%に上昇した。原文が示す上昇幅は14.6%ポイントだ。

標準のKubernetesジョブへの対応により、自前のクラスター、つまり複数のコンピューターをまとめて運用する環境や、クラウド、ローカルインフラを活用できる。これにより、コードを隔離して試す環境を提供する商用サンドボックスサービスへの依存を減らせる。一方、複数のエージェントを同時に実行するにはCPUやメモリなどの計算資源が必要で、自前での運用を選ぶチームはインフラ管理の負担を担う。

Agent Lightning v1.0は、訓練用に複製したエージェントの代わりに実際のハーネスを接続して学習と配備の隔たりを縮める一方、実行インフラの運用はチームに委ねる。