LMSYS、SGLang を活用した推論最適化フレームワーク「Infer-forge」を公開

1. イントロダクション

推論最適化はコード上では局所的な作業に見えるかもしれませんが、その有効性はグローバルな視点で判断されなければなりません。カーネルの改良や通信経路の変更、スケジューリングの見直しといった変更が意味を持つのは、モデル、ワークロード、SLO（サービスレベル目標）、サービングトポロジ、ランタイムバージョン、アクセラレータプラットフォームによって定義された特定のデプロイポイントにおいてです。同じパッチでも、ある環境では性能向上をもたらしても、別の環境では逆効果になる可能性があります。エージェント支援による探索はより多くの環境や実験、測定結果、そして却下されたパスを生み出しますが、これらすべてが再現可能でなければなりません。

したがって、最初の要件は「信頼性の高い実行」です。デプロイポイントを再現するためには、モデルの能力だけでなく、ツール、環境、文脈、メモリ、検証（Verification）、安全バウンダリといった要素も安定している必要があります。「ハルネスエンジニアリング」は、これらの周辺条件を再現可能で検査可能な実行システムへと変換するものであり、これが「エージェント = モデル + ハルネス」という抽象化の基盤となります1,2,3,6。

信頼性の高い実行は、時間経過に伴って一貫性を保つ必要があります。推論エンジニアリングのタスクは、調査、実装、デプロイ、評価（Evaluation）、失敗、回復といった反復的なラウンドにまたがることがよくあります。「ループエンジニアリング」は連続する実行を結びつけ、あるタスクがその契約を保ちつつ、新たな証拠を取り込み、検証された成果物（Deliverable）または信頼できる次の工程への引き継ぎ（Follow-up Handoff）を生み出すことで、終了基準を満たせるようにします4,5,7。

プロジェクト規模の作業は、単一のタスクの範囲を超えます。複数のタスクを並行して進め、成果物を交換し、状態を共有し、再作業をトリガーし、証拠が蓄積されるにつれて方向転換する必要があります。グラフ・エンジニアリングは、独立して収束するタスク・ループを進化するタスク・グラフに整理します。このグラフでは、リリースされたパスや却下されたパスも、依存関係、制約条件、および関連する証拠と接続されたまま保たれるため、プロジェクトの意思決定は常に説明可能になります10,11,12,13。

Infer-forgeはこのアプローチを、SGLang を中心とした推論エンジニアリングに応用しています。その範囲は、カーネルや通信ライブラリからエンジン統合・デプロイメント、そして評価とオンライン診断に至るまで、推論スタック全体に及ぶ変更を扱います。この一貫したエンドツーエンドの経路を支えるのは、1 つの共有ワークスペースと 3 つの蓄積型実行構造です。

• MonoRepo：リポジトリ間でのエンジニアリングを可能にする再現可能なワークスペースを提供します。
• Harness：再利用可能な実行機能、メモリ管理、検証機能、および安全境界を備えています。
• Task Loop：終了基準に達するまで、1 つの長期実行タスクを継続させます。
• Task Graph：独立して収束するタスクを結合し、プロジェクト納品や機能進化といったより大きな目標を実現します。

1.1 実装状況と利用可能性

Infer-forge は SGLang を中心に独自に開発された内部エンジニアリングシステムであり、公式の SGLang や LMSYS のコンポーネントではありません。

Infer-forge は現在、オープンソース化されていません。その核心コンポーネントが、当社の内部リポジトリ、インフラストラクチャ、ワークフロー、および安全制御と深く結合されているためです。そのため、現状のコードベースは、当社の環境外での移植性は限定的となります。

代わりに、本記事では構築手法を公開します。チームや個人がこの方法を AI コーディングツールに提供し、自社のシステムコンテキストを追加することで、それぞれの環境に適応した Infer-forge の実装を迅速に構築できることを目指しています。

Infer-forge は、単なるワークフロー設計の段階から、持続的なエンジニアリング運用へと移行しました。あるエンジニアが 4 月から 7 月にかけて記録したデータでは、同時に進行中のタスク数（Tasks in flight）のピークが 2 から 9 に増加しました。また、DeepSeek-V4-Pro のサービングプロジェクトでは、7 つの異なるタスクタイプにわたる 38 個の独立して検証可能なタスクノードを、タスクグラフとして調整・運用しました。これらの記録は、Infer-forge が 4 ヶ月にわたるエンジニアリング運用と、プロジェクト規模のタスクグラフの両方で持続的に使用されていることを示しています。

有能なエージェント（Agent）が一度の実行を成功させることはできますが、エンジニアリングシステムは「成功した作業」を再現可能に設計されるべきものです。Infer-forge は、すべてのタスクがより速く完了することを約束するものではありません。しかし、各デプロイメントポイントの履歴（プロベナンス）を保存し、長期実行中のタスクにおいて検証可能な作業を維持し、タスク間の境界を超えて証拠を調整するための構造を提供します。

2. インフラとしての推論

**

*図 1：推論デプロイメントポイント背後の制約チェーン。

**

図 1 は、前述のデプロイメントポイントを具体的な制約の連鎖へと変換します。まず「モデル（Model）」が対応するモダリティとモデル固有の実行パスを決定します。「サービングシナリオ（Serving Scenario）」はモダリティとトラフィック形状を基に SLO を導出し、これが「サービングトポロジ（Serving Topology）」を制約します。このトポロジでは、「デプロイメントアーキテクチャ」と並列化戦略が組み合わされます。その後、特定のサービスリビジョンに対してエンジン設定とコンテナイメージを固定する「バージョン管理されたランタイムプロファイル」を通じてトポロジが実現されます。最後に、完全なランタイムは「アクセラレータプラットフォーム（Accelerator Platform）」上で構築・検証される必要があります。デプロイメントポイントとは、この連鎖全体を通る完全な経路であり、単一の層を孤立して捉えたものではありません。

文脈に依存しない推論最適化というものは存在しません。異なるサービング目標や SLO は、Colocated PD、PD Disaggregation、EPD Disaggregation など、根本的に異なるデプロイメントパスを必要とします。各アーキテクチャはステージの境界、通信経路、リソースバランス、そして実行可能な並列化戦略のセットを変化させます。これらの判断は、検証が必要なランタイムプロファイルやアクセラレータ固有の実装へと波及します。カーネルレベルの改善がサービング結果となるのは、完全なデプロイメントポイントでそれが再現され、スループット、レイテンシ、正しさ、安定性の各ゲートを通過したときだけです。デプロイメントポイントを伴わない性能主張は、再現も比較も、次の展開も不可能です。

Infer-forge は、この組み合わせ空間を排除するものではありません。むしろ、その中を移動するすべての動きを明確かつ検証可能にします。

「DeepSeek-V4-Pro を最適化せよ」とエージェントに指示を出すのではなく、現在のデプロイメント地点を記録し、変更可能な次元のサブセットに範囲を定め、実行前に検証ゲートを固定したTask（タスク）を定義します。例えば、MoE バックエンドを置き換えつつ、サービングシナリオやトポロジー、アクセラレータは一定に保つといった Task が可能です。その結果として、承認された改善案か、文書化された却下かのどちらかが得られます。どちらの成果も、次の Task に向けた不確実性を低減します。

ただし、これらを実行可能にするためには、デプロイメント地点を支えるクロスリポジトリ間のコード状態を正確に固定する必要があります。その役割を果たすのがMonoRepoです。

3. MonoRepo

3.1 なぜ MonoRepo か

推論最適化はリポジトリの境界を跨ぐものですが、一つの整合性のあるシステムとして提供されなければなりません。変更がカーネルライブラリで始まり、通信バックエンドに依存し、エンジン統合を通じて SGLang に流入し、最終的には対応するデプロイ構成を必要とするケースがあります。

これらのリポジトリが別々のワークスペースに存在する場合、それらの関係性はエンジニアやエージェントが繰り返し再構築しなければならない一時的な知識になってしまいます。ブランチの欠落一つ、あるいは互換性のないリビジョン一つで、結果が無効化されてしまうのです。

Infer-forge は、その依存関係マップを共有ワークスペースへと変換します。Git サブモジュールを使用することで、関連するリポジトリを一つのルート下に配置しつつも、それぞれの独立した履歴、ブランチポリシー、アクセス制御、リリースプロセスは維持されます。このルートにより、エンジニアとエージェントは推論スタックの安定した地図を持ち、また、リポジトリ間での作業を開発・検証するための単一のエントリーポイントを得ることができます。

この構造は、リポジトリ間の作業を以下の 3 つの側面で変化させます。

• 全体像が維持される。リポジトリの境界線は明確なままですが、その工学的な関係性は一つのワークスペースから可視化されます。
• コンテキストが制限される。エージェントは完全なリポジトリマップをナビゲートできますが、現在のタスクに必要なリポジトリのみを読み込みます。
• 統合が現場で開始される。関連するブランチは、リポジトリの再探索や記憶からの関係構築を繰り返すことなく、開発・結合・検証を行うことができます。

ワークスペースの座標系は変化しますが、Task レコードによってその状態は永続化されます。各 Task は、作業に使用されたブランチ、コミット、実行状態を記録し、完了後は Journal がその記録をアーカイブします。これにより、リポジトリは継続的に進化できますが、すでに検証・納品済みの作業の出自（プロベナンス）が消去されることはありません。

3.2 リポジトリマップ

**

*Figure 2: Infer-forge MonoRepo.*

一つのワークスペースが、単一のまとまりきったコードベースを意味するわけではありません。 Infer-forge では、エンジニアリングにおける役割に応じてリポジトリを分離しています。 Built-in Workspace は複数にまたがる作業の調整役を務め、Inference Stack Repos には変更を加えるサービングシステムが含まれ、Harness Repos** がその変更を実行から検証された証拠へとつなげます。

Built-in Workspace

Built-in Workspace は、infer-forge の調整層であり、実装用のリポジトリではありません。 コードは所有するリポジトリ内に残ります。ルートディレクトリには、リポジトリの境界を跨いで動作する仕組みのみが含まれています：

• Task System は、タスクに必要なワークスペースを実体化します。関連するリポジトリ、環境のエントリーポイント、記録場所、そして隔離が必要な場合は専用の worktree と Agent セッションです。

• Cross-lib Management は、リポジトリのグラフを運用可能にします。リポジトリの場所、デフォルトブランチ、変更を同期・統合するための操作を管理します。実際の作業に使用されるブランチやコミットは Task レコードに所属し、Journal へアーカイブされます。

スキルは、その本来の範囲で能力を公開します。ルートにはタスクライフサイクルやリポジトリ間調整のためのスキルが提供され、各リポジトリにはそれぞれのドメイン固有のスキルが保持されます。

推論スタックのリポジトリ

推論スタックのリポジトリは、実際にはサービング動作とパフォーマンスが変化します。 SGLang がスタックの中核を担い、Dynamo が SGLang インスタンスを分散サービスとして整理します。また、DeepGEMM、FlashMLA、FlashInfer、Humming が専門的な計算カーネルを提供します。さらに、DeepEP と Mooncake はエキスパート並列通信やノード間 KV 転送を担います。これらのリポジトリはそれぞれ独立して進化しますが、一つのサービング結果には複数のリポジトリにまたがる変更が影響することがあります。

ハーネスのリポジトリ

エージェントがコードを編集できるからといって、それがすぐにエンジニアリング成果になるわけではありません。Harness Repos は、変更が生じた後のライフサイクル全体を支える機能を提供します。具体的には、計算リソースの確保、環境の準備、サービスのデプロイ、パフォーマンスと正しさの評価（Evaluation）、障害やオンライン動作の診断、長期記録の保存、そして安全境界の強制などです。これにより、本来バラバラだった運用ステップが、コード変更から検証済みのデリバブル（Deliverable）に至る反復可能な道へとつながります。

この 3 つのグループは一体となって一つのエンジニアリングパスを形成します。Built-in Workspace が作業の準備と調整を行い、Inference Stack Repos が変更対象となるシステムを提供し、Harness Repos がその変更を検証まで運びます。Infer-forge はこれらを一つのワークスペースに統合しますが、単一のリポジトリ履歴や所有モデル、リリースプロセスに無理やり縛りつけるものではありません。

4. Task Loop

MonoRepo が作業の場（ワークスペース）を提供し、Task Loop が時間の経過とともにどのように作業を進めるかを構造化します。推論エンジニアリングでは、研究、実装、デプロイ、評価、回復といった複数のラウンドを繰り返すことがよくあります。Task Loop は、検証済みのデリバブルが得られるか、あるいは信頼できる後続の引き継ぎ（Follow-up Handoff）が行われるまで、それらの実行を一つの目標とタスク契約に整合させます。

「すべてがタスクになり得る」という原則は、独立して検証可能な作業単位に適用されるものであり、すべての行動に当てはまるわけではありません。タスクには、独自のゴール、スコープ、受入基準、検証パス、そして終了条件が必要です。コマンドや中間的な実験は、ループブロックのインスタンスまたはツール呼び出しとしてその内部に留まります。ある作業単位が独立して完了するか、次の段階へ引き渡すことができるようになった時点で、それはより大きなタスクグラフ内のノードとなり得ます。

4.1 概要

**

*Figure 3: Task Loop Overview.*

タスクループは、実行パスを柔軟に調整しつつも境界を安定させます。タスク定義では、タスクの種類、開始時の文脈、契約内容、終了条件を設定します。メインループは、一連のループブロックインスタンスを通じて作業を進め、「タスクゴール達成？」という判断基準に基づいて、終了するか継続するかを決定します。タスクメモリは、現在の状態、次のサブターゲット、実行記録、そして各反復間の引き渡し情報を保持します。

ハネス（Harness）はループの内部にある別の工程ではなく、ループを取り囲むように機能します。 実行中に必要なリソース、メソッド、メモリシステム、検証のエントリーポイント、そして安全境界を提供するのがハネスの役割です。異なるタスクでは、これらの機能を固定されたパイプラインに縛られず、順序を変えて利用することが可能です。

4.2 タスク定義

図 4: タスク定義。

タスクループは、活動を開始する前に「検証可能なコミットメント」から始まります。エージェントがコードベースの検索やデプロイの実行、評価リソースの消費を行う前には、まずそのタスクが何を達成しようとしているのか、そして結果をどう評価するのかを明確に示す必要があります。タスク定義は、以下の 4 つの重要な要素（アンカー）を設定します。

• タスクタイプ: デフォルトのプレイブックを選択します。
• 開始コンテキスト: 実行が開始される時点の状態を記録します。
• タスクリスト: 目標、範囲、受入基準、検証方法を確定させます。
• 終了条件: 実行によって生み出さなければならない永続的な成果物か、次の工程への引き継ぎを定義します。

4.2.1 タスクタイプ

プレイブックとは、過去の成功事例を即座に活用するためのものです。各タスクタイプに対して、軽量かつ柔軟なテンプレートが用意されています。これにより、「どのリポジトリが重要になりそうか」「関連するスキルやツール・CLI、検証の入り口はどこか」「適用すべき安全境界線は何か」などを事前に特定できます。これによって、エージェントが実際に有益な作業を開始する前に探索する必要のある範囲を大幅に縮小できます。

プレイブックは、開始アプローチを標準化するものであり、実行パス全体を規定するものではありません。 エージェントは、タスク契約や新たな証拠に応じて、手法を変更したり、新しいループブロックインスタンスを追加したり、テンプレート外の機能を活用したりできます。これは、再発見の繰り返しを減らす一方で、エンジニアリングにおける判断力を代替するものではないのです。

各タスクタイプは、推論工学における検証可能な作業の固有単位を捉えています：

• Plan（計画） は、目的・制約・分解方法を定義し、下流のタスク向けに実行可能なプランを提供します。

• Research（調査） は、限定された不確実性を調査し、利用可能な証拠を評価した上で、明確な制限条件付きで結論を導き出します。

• Code（コード） は、スコープ内のあらゆるコード変更を実装し、その変更内容と検証証拠の両方を提供します。

統合（Integration）は、複数のアップストリームタスクからの変更をまとめ、リポジトリやコンポーネントを超えた結合システムを検証します。

評価（Evaluation）では、機能、パフォーマンス、精度、負荷、安定性に関するアセスメントを実行し、受入基準に対する証拠を提供します。

リリースでは、検証済みの候補を承認、カナリア展開、拡大、またはロールバックへと進め、その結果を記録します。

オンライン診断では、読み取り専用範囲内で本番環境の問題を調査し、必要な変更事項を下流のタスクへ引き継ぎます。

「Capability」は、Add、Update、Merge、Retire、または No Change の操作を通じて、バージョン管理された「Skills & Tools」セットを維持します。

カスタムタスクは、再利用可能なプレイブックが存在しない場合でも、検証可能な作業を処理しつつ、同じタスク定義を維持します。

タキソノミーは反復練習によって獲得されるものです。特定の活動が組み込みの「タスクタイプ」として確立するのは、その開始時の慣習、受容境界（Acceptance boundary）、および成果物が、将来の作業を導くのに十分なほど安定した状態になってからです。標準化は実証された実践に続くものであり、すべての経路を事前に予測しようとするものではありません。

4.2.2 開始コンテキスト

開始コンテキスト（Starting Context）は、「既知の状態」と「仮定」の境界線を引くものです。 タスクは空白の状態から始めることもあれば、用意された環境や上流工程からの結果を起点とすることもできます。重要なのは、その状態のソースと検証ステータスが明確に示されていることです。

• カスタムセットアップ（Custom Setup）: 現在のタスクのために準備された条件（モデル、コンテナイメージ、デプロイメントプロファイル、リポジトリバージョン、データセット、実験のエントリーポイントなど）を記録します。

• インポート済みコンテキスト（Imported Context）: 上流の環境、中間結果、またはフォローアップハンドオフ（Follow-up Handoff）を引き継ぎます。これには、その出自（プロベナンス）と検証ステータスも含まれます。

4.2.3 タスク契約

タスク契約（Task Contract）は、実行が適応する間も目標を固定し続ける役割を果たします。 「ゴール（Goal）」は意図した成果を、「スコープ（Scope）」は作業の範囲を定義します。「受容基準（Acceptance）」は成功のための観測可能な条件を示し、「検証（Verification）」はそれらを判断するために必要な証拠を定義します6。この境界線がなければ、エージェントは結果を見てから問題を勝手に変更することで、あたかも成功したかのような振る舞いをしてしまう可能性があります。

推論最適化のタスクでは、モデルと重みの形式、ハードウェア配置、サービングトポロジ、ランタイムバージョン、ワークロードグリッド、ベンチマークなど契約条件を事前に固定します。その上で、精度や安定性を損なうことなく、スループット、TTFT（Time to First Token）、TPOT（Time Per Output Token）などの性能向上が求められます。結果を確認した後にトポロジや GPU クラス、ワークロードを変更することは、最適化の結果ではなく契約の変更とみなされます。

エビデンスはメインループの方向転換を促すことがありますが、ゴールラインを黙って動かしてはいけません。 目標、スコープ、受入基準に実質的な変更がない場合でも、その明確化は明示的に行われ記録されなければなりません。これらのいずれかに実質的な変更が生じれば、それは新たなタスクの開始を意味します。

4.2.4 エグジットクリテリア（完了条件）

活動が停止したからといってタスクが終わるわけではありません。 タスクが終了するのは、その状態を検証可能になったり、安全に継続できたりした場合です。

• デリバラブルは、タスク契約の完了を証明する十分なエビデンスと共に、完成した成果物をパッケージ化したものです。
• フォローアップハンドオフは、完了した作業と現在のステータス、未解決の質問、そして別のタスクが引き継ぐべき次の入り口を保持します。

エグジットクリテリアとは、実行を永続的なエンジニアリング状態へと変換するものです。 すなわち、検証可能な成果物か、次のタスクへの信頼できる出発点のいずれかを確立することです。

4.3 ループ実行

Figure 5: Loop Execution.

タスクの規模は、ランタイムセッションの継続時間ではなく、その工学的な目的によって決まります。Task Contract（タスク契約）が完全な目標を定義し、Main Loop（メインループ）は証拠が得られるたびに1つ以上のLoop Block（ループブロック）インスタンスを通じてそれを実現します。タスクを定義する際、ユーザーがそのタスクを単一の持続的なランタイムループ内で完了できるかどうかを予測する必要はありません。

連続性の単位はタスクであり、実行の単位はループブロックです。 各ループブロックは、1 つのサブ目標、1 つの終了条件、1 つのルーティング判断、そして一連の実行記録を所有します。Claude Code の /loop や Codex の /goal は現在のエントリポイントですが、これらがタスクの範囲を決定するわけではありません。

4.3.1 Main Loop

メインループは、未定義のタスクを実証的なループブロックの連続へと変換します：

• Define Loop Block（ループブロックの定義）では、現在のサブ目標と終了条件を選択します。

• Execution Routing（実行ルーティング）では、そのサブ目標に対応するモデルティアとエージェントトポロジーを選択します。

• Execute Loop Block（ループブロックの実行）では、利用可能な持続実行エントリポイントを通じてブロックを実行します。

「Task Goal Met?」は、蓄積された状態とタスク契約を比較し、終了するか次のブロックを定義するかを決定します。

ループブロックの完了は、タスク全体の完了とは異なります。あるブロックが仮説を確認したり、アプローチを拒否したり、新たな制約を明らかにしたりする可能性があります。そのブロックの「Exit Condition」はその局所的な作業単位を閉じますが、「Task Goal Met?」は蓄積された証拠がタスク契約全体を満たすかどうかを判断します。「Yes」の場合は終了基準へ進み、「No」の場合は既に生成された証拠に基づいて次のループブロックを定義します。

4.3.2 Task Memory

「Task Memory」により、ループブロックのシーケンスは永続化され、追跡可能になります。完了したループブロックとアクティブな現在のループブロック（サブターゲットと終了条件を含む）が保存されます。次のループブロックの記録は、現在のブロックが終了し、「Task Goal Met?」によってタスクを継続する必要があると判断された後にのみ行われます。

「Execution Records」は、エージェントが各ステップで何を行い、どのような結果を生み出したかを記録します。これにより、実行の監査可能性、追跡性、再現性が確保されます。

ループブロック間のハンドオフは一つのタスク内の状態を転送しますが、グラフレベルのハンドオフエッジは独立したタスクノードインスタンス間を接続します。

4.3.3 Execution Routing

「Execution Routing」では、現在のループブロックに対して2つの直交する選択が行われます。

• Model Tier は推論の難易度に基づきます。不確実性、推論の深さ、必要な専門性が判断基準となり、そのブロックがLower-tier、Mid-tier、あるいはStrongest Availableのいずれを使用するか決定されます。

エージェントトポロジーは、コンテンツの量と予想されるコンテキスト長に応じて決定されます。1 つのコンテキスト内で確実に処理できるタスクには「Single Agent」を、複数のコンテキストに分割して処理する必要があるタスクには「Multi-Agent」を採用します。

困難だがコンパクトな問題に対しては、「Strongest Available」モデルを「Single Agent」構成で利用できます。一方、大規模かつ定型的な評価マトリックスでは、「Lower-tier」または「Mid-tier」モデルを「Multi-Agent」構成で運用するのが適切です。モデルのティア（階層）が推論能力を提供し、エージェントトポロジーがコンテキスト負荷を管理します。

図 5 は、可能な「Multi-Agent」トポロジーの一例を示しています。ここでは「Coordinator」が Infra、Code、Eval と連携し、「Reviewer」がメインの実行チェーンの外側から結果を検査します。これらの役割は例示であり、実際の分解方法は現在の Loop Block が抱えるコンテンツとコンテキスト要件に基づいて決定されます。

モデルティアの選択やサブエージェントの利用ができない場合でも、Loop Block はランタイムが提供する機能で処理を継続し、そのフォールバック対応は実行記録に明記されます。

4.4 ハーネス

タスクループが進展を維持できるのは、ハーネスが実行を安定して支えられる場合に限られます。 安定したハーネスが存在しない場合、各 Loop Block は毎回マシンを再発見し、環境を再構築し、コマンドの場所を探し出し、証拠を回復し、安全境界の再交渉を行わなければなりません。これに対し、Infer-forge は「Node Registry」、「Skills & Tools」、「Journal」、そして「Safety Guard」から構成される実行基盤を提供します。

価値は単一の機能ではなく、それらを組み合わせることにあります。タスク定義の後、エージェントはリソースの状態を確認し、環境を準備し、ワークロードを展開し、システムを変更・評価し、必要に応じて別のノードで回復を行うことができます。ノードの状態、運用方法、実行履歴、そして安全制約はプロセス全体を通じて一貫して接続されているため、人間が各ステップ間の経路を再構築する必要はありません。

4.4.1 ノードレジストリ

図 6: ノードレジストリ。

リソースの自律性は、推測ではなく証明可能な所有権から始まるべきです。ノードレジストリは Git を基盤とした台帳であり、すべてのタスクからノードへの請求（claim）を記録します。コレクターは定期的にランタイムプロセスと GPU 活動の観測データをレジストリに書き込み、継続的で監査可能な履歴を作成します。GPU のテレメトリは一つの信号に過ぎず、単一のサンプルだけでタスクが完了したと断定することはできません。

クリーンアップは失敗時にクローズド（安全側）で動作します。 請求がクリーンアップの対象となるのは、新鮮で欠損のない観測データにより、ランタイムと GPU の両方の活動が設定されたポリシーの期間中、継続的にアイドル状態にあることが示された場合のみです。データの欠落、古さ、欠損、または矛盾する証拠はクリーンアップをブロックします。ランタイムはアクティブだが GPU はアイドルというノードについては、手動でのレビューが必要です。

「利用可能であること」と「実行すること」は別物であり、「クリーンアップ」も「再利用」を意味しません。クリーンアップは明示的にトリガーされ、レジストリ上の請求（claim）のみを削除するものであり、ワークロードの停止やタスク完了の確約にはなりません。ノードを再利用する前に、その現在のマシン状態を再度検証する必要があります。

ノードレジストリはスケジューラではなく、ワークロードを起動する役割も持ちません。その役割はより限定的かつ基盤的なものです：クリーンアップ、割り当て、デプロイメントの判断に頼れる監査可能なリソース状態を維持することです。

4.4.2 スキルとツール

図 7：スキルとツール。

有能なエージェントが、すべてのタスクで同じエンジニアリング作業を毎回再発見する必要はありません。スキルは、SGLang Upstream、Cross-lib、Task、Ops にわたって再利用可能なアプローチを保存します。ツールと CLI は、デプロイメント、ビルド、重みとコードの同期、評価、プロファイリング、オンライン診断、監視のための安定した記録可能なインターフェースを提供します。

プレイブックは、現在のタスクタイプに関連するサブセットを選択します。スキルは意思決定の範囲を絞り込み、ツールと CLI は選択された意思決定を実行可能なアクションに変換し、その入力と出力は実行レコードに格納されます。エージェントは固定された経路を強制されることなく、蓄積された実践からスタートします。

スキルとツールは、バージョン管理された能力の基準線であり、単に積み重なった指示の山ではありません。 通常のタスクでは現在の基準線が使用されます。一方、能力タスクでは、モデルやランタイムの変更後にジャーナルのエビデンスと再検証を行い、何を追加・更新・統合・廃止するか、あるいはそのまま維持するかを決定します。

4.4.3 ジャーナル

**

*Figure 8: Journal.*

エビデンスが蓄積するのは、次のタスクでそれを発見して再利用できる場合だけです。 タスクメモリは単一のタスクの実行状態を保持しますが、ジャーナルはタスク間を超えてエビデンスを引き継ぎます。 LLM-wiki は各タスクの記録を知識ネットワークとして結びつけ、多次元インデックス** はモデル、タスクタイプ、GPU といった次元で整理します。これらを組み合わせることで、各タスクが同じ事実を再発見する必要なく、「検索」「比較」「絞り込み」が可能になります。 （原文の技術表記: Model or runtime change）

SGLang の OpenAI 互換チャットベンチマークハンドラーの以前のバージョンでは、ストリーミングされる delta.reasoning_content が TTFT（Time To First Token）や出力集計に含まれていませんでした（sgl-project/sglang#23954 で修正済み）。非ストリーミング処理については #25298 で別個に対応されています。ジャーナルはこの歴史的記録を後のタスクで取り上げ、測定誤差がエンジンの回帰と誤認されるのを防ぎました。

ジャーナルは証拠を保存しますが、証拠を直接実行可能な機能へと昇華させることはできません。 スキルとツールのベースラインに対する変更は、必ず Capability Task と検証プロセスを経る必要があります。

4.4.4 セーフティガード

**

*Figure 9: Safety Guard.*

エージェントの実行が長期化し、並列処理が増えるにつれて、是正されないミスはより広範囲に波及する可能性があります。そのため、Safety Guard（セーフティガード） は、プレイブックやループブロックが迂回できない制約を適用します。

• Push Guard と Traceable Path がコード変更の移動経路を制限します。
• Env Isolation と Production Read-only Access が環境と本番運用を制限します。
• Secrets と Data が認証情報や管理対象データセットへのアクセスを制限します。

高リスクなアクションにはHuman Gate（人間によるゲート）の承認が必要です。

また、Cross-Model Adversarial Review（異モデル間敵対的レビュー）では reviewer ≠ coder のルールを適用し、自己レビューで見落としが生じる盲点を減らします6。

「Safety Guard」はアクションに制約をかけ、「Verification」は主張に制約をかけます。あるカーネル最適化のタスクにおいて、候補が 72.30 TFLOPS を達成し、比較対象より 5.7% の改善が見られるように思われました。しかし、後の検証で競合状態（レース）が発覚しました。集計統計は安定しているように見えたものの、個々の要素は破損していたのです。この候補は統合前に却下されました。

信頼性の高い自律性は、何を実行できるかだけでなく、何を推進しないよう拒否できるかによっても測られます。推論エンジニアリングにおいて、誤った性能向上を止めることは、さらにパッチを生み出すことよりも価値がある場合があります。

5. Task Graphs

**

*Figure 10: Task Graph: Elements, Handoff, and Edge Types.*

プロジェクトは、単にタスクを増やすだけではスケールしません。依存関係、共有状態、制御決定が明示されたときに初めてスケールします。Task Loop は各タスクに収束への独立した経路を与え、Task Graph はそれらの収束するユニットを接続しつつ、検証の境界を崩すことなく結びつけます。

タスクグラフは、固定されたワークフローテンプレートや閉じた分類体系ではありません。 複数のタスクに明示的な依存関係、検証済みのハンドオフ、共有状態、あるいは制御関係が必要となる場合、それらをタスクグラフとして整理できます。このグラフは、単一のプロジェクト、特定の調査、一つのリリース、あるいは単一タスクの境界を超えるあらゆる目的のために機能します。

デリバリーグラフとキャパビリティグラフは、頻出する 2 つの例に過ぎず、唯一の有効な構造ではありません。 これらを用いるのは、推論システムを共同で変更するタスクの調整や、将来のタスクが利用する能力の維持といった、一般的な 2 つの状況において、同じグラフ言語を示すためです。

グラフの正しさを担保するには、実行と状態、そして外部制御を分離することが出発点となります。 作業を実行し、タスクループを回すのはタスクノードのみです。永続的な状態を保存するのは共有リポジトリであり、ループは実行しません。外部システムとは、infer-forge の外側からこのグラフと関わる人間やプラットフォームを指します。

各境界を横断するエッジの種類は以下の通りです。

• ハンドオフエッジ: 検証済みのデリバブルまたはフォローアップのハンドオフを運び、後続タスクにとってインポートされたコンテキストとなります。
• ステートエッジ: 共有リポジトリからの読み取りまたは書き込みを表します。タスクの完了や検証を意味するものではありません。
• コントロールエッジ: 作業のトリガー、修正のための返却、あるいは方向転換を引き起こしますが、検証済みの結果を運ぶわけではありません。

書き込みはハンドオフではなく、トリガーはデリバブルではありません。単なる接続性だけで、検証された進捗があるわけではありません。

5.1 Delivery Graph

**

*Figure 11: Delivery Graph: The Delivery Lifecycle.*

推論のデリバリーはチェックリストをこなす作業ではなく、収束させる問題です。Plan Task は目標を「Prefill」「Decode」「カーネル」「通信」「デプロイメント」といったワークストリームに分割します。その後、Research と Code の各タスクが独立して、かつ並列で進みます。それぞれのタスクは独自の契約（Task Contract）に基づいて成果物（証拠）を生み出していきます。

統合は、並行して進められた作業を一つの運用可能なデプロイポイントにまとめる工程です。ここではエンジン、ライブラリ、イメージ、そしてデプロイ設定全体の変更点を組み合わせていきます。こうして完成した候補は、モデル、サービングシナリオ、ハードウェア構成、パフォーマンス、精度、安定性といった条件を固定した上で評価フェーズへと進みます。もし結果が失敗に終わった場合は、部分的な成功で先へ進むのではなく、Rework（再作業）のループに戻って修正を行います。

リリースは図の最後のボックスではなく、検証済みの状態遷移です。フォローアップハンドオフを通じてリリースに到達できるのは、評価を通過した候補のみです。外部からのシグナルがオンライン診断を引き起こすことがありますが、その結果はフィードバックとして戻るか、ホットフィックスとしてコードタスクを開始します。これらの制御エッジは作業の方向転換が可能ですが、統合や評価を迂回させることはできません。 （原文の技術表記: Signals、Feedback、Hotfix）

「配送グラフ（Delivery Graph）」は、すべての経路が証拠を通じて収束することを強制することで、並列処理の有用性を高めます。

5.2 キャパビリティグラフ

図 12: キャパビリティグラフ – キャパビリティの進化

Delivery Graph は推論システムそのものを変革し、Capability Graph は作業を実行するシステム自体を変えます。Task Execution では、現在のスキルとツールの基準に基づいて処理が行われ、実践的な証拠がジャーナルに記録されます。タスク間では、反復される手順や再利用可能なコマンド、ワークフローのパターン、そして実証済みの修正策が、Capability の維持・強化のための候補となります。

ジャーナルは権威ではなく、証拠である。Journal commit event、Scheduled trigger、そして Model or runtime change は Capability Task を起動させる要因にはなり得るが、それらが実行可能な挙動の変更を証明するものではない。

Task はジャーナルの差分をスキャンし、現在のベースラインを読み取った上で、検証プロセスを経て「追加」「更新」「統合」「廃止」、あるいは「変更なし」のいずれかを出力します。 （原文の技術表記: Add、Update、Merge、Retire、No Change）

すべての機能には維持コストと有効期限が存在します。一部のスキルはプロジェクトの永続的な知見を保存しますが、他のスキルは特定のモデルやランタイムへの対応に過ぎません。システムが改善されるにつれて、古い足場はコンテキストを消費したり、新しい挙動と競合したり、判断を制約したりする可能性があります。Claude Code チームは、より新しいモデル向けにシステムプロンプトの 80% 以上を削除しましたが、コーディング評価の結果には測定可能な低下は見られませんでした15。Boris Cherny もまた、定期的に CLAUDE.md ファイル、スキル、フックを整理するよう提唱しています16。

したがって、モデルやランタイムの変更は、現在のベースラインの再検証をトリガーします。機能の削除とは、証拠に基づいたアブレーション手法であり、安易な削除ではありません。安全境界と検証済みの不変条件は、それらを変更する根拠がない限り維持されます。「追加」機能のみをサポートする能力セットは進化せず、負債が蓄積されるだけです。

候補に実装、評価、またはリリース作業が必要となる場合、Capability Task は対応するタスクへのフォローアップ引継ぎを生成します。Capability Graph は、生きた経験が実行可能な挙動を変化させるのを防ぎつつ、検証済みの経験がジャーナル内に閉じ込められたままになることも防ぎます。

6. One Engineer, Multiple Loops

この章では、持続的なタスク実行から並行作業、そしてプロジェクト規模の調整に至るまで、一人の AI インフラエンジニアを追跡します。

6.1 From Execution to Judgment （原文の技術表記: Model or runtime change、Add）

![一人の人間と四人のエージェントが、左から右へ並ぶ単一のタイムラインを共有しています。各者は独自のレーンに配置されています。人間のレーンは「タスク A の定義」「タスク B の定義」「タスク C の定義」の連続したトラックで構成され、その後にラベルのない灰色のブロック（無関係なエンジニアリング作業）が続き、「証拠 A のレビュー」「タスク D の定義」と続きます。各「タスク定義」ブロックは、開始するエージェントの色で塗りつぶされており、同じ色の点線がその右下隅から下へ伸び、対応する「実行タスク」バーの左上隅へとつながります。この線がまだ進行中のバーと交差する場合は、可読性を保つために白いチャネルの上に描かれます。四人のエージェントのレーンはそれぞれ「エージェント」というラベルのみを持ち、文字はエージェントではなくタスクに属します。色によって区別されます。

「実行タスク A」は定義完了から始まり、人間がさらに二つのタスクを定義して他の作業に移る間の全体期間を通じて継続し、そのバーの右端（完了時）から緑色の矢印が上がり、「証拠 A のレビュー」へとつながり、一つのループを閉じます。一方、「実行タスク B」「実行タスク C」「実行タスク D」はすべて時間軸の右端まで続き、図が終わる時点でもまだ進行中です。

薄く表示された「さらに多くのエージェント」というレーンには点線のプレースホルダーバーが配置されており、より多くのエージェントを開始できることを示しています。](https://www.lmsys.org/images/blog/infer-forge-loop/fig-13-parallel-task-loops.svg)

**

*図 13: 一人のエンジニアが複数の持続的なタスクループを指揮する様子。

</article>

AI インフラエンジニアリングのあり方は、実行中にエンジニアが別の場所にいられることで変化します。一度タスク定義を完了し、必要な人間によるゲートを設定すれば、エージェントは環境構築からデプロイ、評価、回復、そして数時間や数日にわたる反復までを担うことができます。この「タスクループ」は、実行プロセスをタスク契約とその証拠、そして次の意思決定へとつなぎ止めます。

図 13 は、その結果として生まれる作業モードを示しています。あるタスクループが実行中の間、エンジニアは別のタスクの定義を行ったり、完了した証拠を確認したり、あるいは無関係なエンジニアリング業務に戻ったりできます。エンジニアはもはやすべてのコマンドシーケンスを個人的に進める必要はありません。限られた注意資源は、実行から判断へとシフトします。具体的には、制約の設定、証拠の評価、トレードオフの解決、そして次に何を進めるべきかの決定です。

つまり、1 人のエンジニアが複数のタスクループを同時に指揮しても、各タスクの境界線が曖昧になることはありません。 ハーネスが実行を前進させ、エンジニアはプロジェクトの方向性を変える重要な地点に集中力を注ぐのです。

6.2 進行中の観測タスク

**

*Figure 14: Tasks in Flight, April–July 2026.*

Figure 14 shows how the engineer's Tasks in flight changed over four months.** Each bar spans from a Task's creation timestamp to its archive timestamp, and the peak is the maximum number of these intervals that overlap at any instant. Of the 90 Tasks created during the observation window, 86 archived Tasks had valid timestamps and are included; three were still open at the cutoff, and one record was excluded because its archive timestamp preceded its creation timestamp.

4 月から 7 月までの記録では、アーカイブされたタスクの中央値寿命は月を追って上昇しました。具体的には、4 月は約10 時間、5 月は14 時間、6 月は20 時間、そして 7 月は28 時間でした。同時に、飛行中の（処理中の）タスク数の月別ピークは、それぞれ2、2、6、9でした。

6.3 プロジェクト規模での調整

**

*図 15: プロジェクト規模のサービス提供を調整するタスクリスト*

あるエンジニアが、*DeepSeek-V4-Pro の限界に挑む*18というプロジェクトを推進しました。このプロジェクトでは、7 つのタスクタイプにわたる 38 の独立して検証可能なタスクリストノードが活用されました。このグラフは、短文脈 Prefill、長文脈 Prefill、低遅延 Decode、高スループット Decode という 4 つのサービスワークストリームを整理し、それぞれが独立して進捗できる一方で、1 つのリリースに必要な意思決定、制約条件、検証エビデンスを共有できるように設計されています。これら 4 つのワークストリームは、単一の普遍的な最適解に収束するのではなく、4 つの異なるデプロイポイントで合流しました。

**

あるデコードタスクは、グラフ内の他の作業流が進行する間も9日間開いたまま残っていました。このグラフ構造のおかげで、長期化するタスクがプロジェクト全体をブロックすることはありませんでした。

単一のエージェントやタスクがプロジェクト全体の文脈を保持する必要はありませんでした。各作業流は独自の「タスク契約」に対して収束し、検証済みの成果物をより大きなリリースに貢献するだけでよかったのです。

このプロジェクトでは、4 つのリリース済みサービングプロファイルが作成され、最終リリースには採用されなかった 7 つのパスも記録されました。これらパスはエンジニアリングの結果の一部であり、何が評価されたか、なぜ進展しなかったか、そして下流のタスクで再検討する必要のない情報が何であるかを記録しています。

これが運用モデルのスケーリング方法です。1 人のエンジニアが複数の持続的なタスクリープを指揮し、タスグラフを通じてそれらを収束させ、リリースされたシステムとその背後にある意思決定の両方を維持することができます。

7. レイヤーは蓄積する