NVIDIA HORIZON：Gitワークツリーを進化させ、RTLベンチマークで100%達成率を記録するハンズフリーエージェント

NVIDIA ResearchはHORIZONを発表しました。これはハードウェア設計のためのハンズフリーエージェントフレームワークで、ハードウェア設計をリポジトリレベルのコード進化として扱います。各レジスタ転送レベル（RTL）問題はバージョン管理されたリポジトリとしてホストされ、構造化されたMarkdownハーネスがプロジェクトパックにコンパイルされます。その後、自己完結型のエージェントループが隔離されたGitワークツリー上で進化し、実行可能な受入ゲートが通過した場合のみ新しいバージョンがコミットされます。

研究チームは、評価されたすべてのRTLベンチマークスイートで100%の達成率を報告しています。しかし、エージェントベースのハードウェア設計はまだ解決されていないと明確に述べています。

HORIZONとは

単一ターンのコード生成では、実行可能な設計タスクに明確な限界があります。もっともらしいVerilogだけでは実際のハードウェアには不十分で、正しさはサイクルレベルの動作、リセット規則、ビット幅、シミュレータフィードバックに依存します。HORIZONは各設計問題をワンショットプロンプトではなくバージョン管理されたリポジトリとしてホストします。唯一必要な入力は構造化されたMarkdownハーネスであり、これには目標、ドメイン知識の方向性、評価器仕様、受入述語の4つのコンポーネントが含まれます。

ブートストラップエージェントはハーネスをプロジェクトパックにコンパイルします。数学的にはp = (πagent, Ep, Ap, Γp, Ωp)と表され、エージェントポリシー、実行可能評価器、受入述語、バージョン管理ポリシー、ドメインスキルをカバーします。RTLの場合、評価器Epにはコンパイル、シミュレーション、カバレッジ抽出、アサーションまたはテストベンチチェックが含まれます。他のドメインでは、同じスロットに単体テスト、定理証明器、プロファイラ、合成ツールなどが入る可能性があります。したがって、問題は固定リポジトリタイプではなく、Gitワークツリー上で定義されます。

リポジトリレベルのループの仕組み

ブートストラップ後、ループは人間の入力を必要とせずに実行されます。各サイクルでターゲットを計画し、ワークツリーを編集し、ツールを呼び出し、評価器を実行します。その後、受入述語が新しいバージョンをコミットするか、失敗を記録するかを決定します。Gitが基盤となり、差分は提案された状態変更を公開し、コミットは受け入れられたチェックポイントを定義し、ノートは評価器の証拠を添付し、ログは完全な軌跡を回復します。

ループはネイティブGitコマンドに依存して低コストを維持します。ステージングされた編集はgit diff --cachedで検査されます。受け入れられた試行はGitコミットとなり、そのノートには判定と報酬が含まれます。成功したコミットは正の修復例となり、拒否された試行は負の例として記録されます。リポジトリ履歴が経験バッファとなり、別個のデータストアは不要です。

研究チームは、記録されたオブジェクトに名前を付けるためだけに半マルコフ決定過程の語彙を借用しています。「状態」はリポジトリのバージョン管理されたスナップショットであり、「オプション」は2つのチェックポイント間のエピソードです。HORIZONはこの作業でRLポリシーを訓練したり更新したりせず、エージェントのバックボーンはキャンペーン中固定されたままです。

セッションの再利用によりコストが低減されます。HORIZONは反復全体で永続的なモデルセッションを維持します。ハーネス、プロジェクトパック、安定したソースはプロバイダのプロンプトキャッシュから提供されます。新たに課金されるトークンは、現在の差分と最新の評価器出力によって支配されます。

自己進化システムにおけるHORIZONの位置づけ

HORIZONはリポジトリ規模の自己進化システムの系譜を拡張します。初期のシステムはエンジニアが実行するソフトウェアを進化させましたが、HORIZONはエンジニアが作成するハードウェアアーティファクトを進化させます。4つのシステムすべてに共通する原則は、実行可能な証拠がサポートする場合にのみ候補変更が受け入れられることです。

ベンチマーク結果

バックボーンはGPT-5.3で、すべての実験で固定されています。すべての結果は単一エージェント、ハンズフリーモードを使用しています。実験はAMD EPYC 9334 32コアホスト、512 GB RAMで実行されました。

評価範囲はChipBench、RTLLM-2.0、Verilog-Evalに加え、9つのCVDPコードおよび検証生成カテゴリ（CID 002～016）を含みます。CVDPには783の人間作成問題が含まれています。

1イテレーションは自動化された外部ステップです。エージェントがワークツリーを編集し、評価器を実行し、合格をコミットするか拒否を記録します。HORIZONはすべてのスイートで100%の合格率に達します。唯一の残存ミスはChipBench仕様ハーネスの欠陥であり、エージェントの失敗ではありません。

初回イテレーションの合格率は47.8%です。イテレーション0は独立したPass@1測定ではなく、最初のエージェントイテレーション後のリポジトリ状態です。エージェントは設計上、デバッグと修復を後のイテレーションに延期する場合があります。

収束の難しさはカテゴリによって大きく異なります。RTLLM-2.0とVerilog-Evalは2イテレーション以内に100%に達します。チェッカー生成（CID 013）はわずか3.8%から始まりますが、19イテレーションまでに着実に100%に上昇します。コード補完（CID 002）は82イテレーションを必要とし、そのロングテールが最大のトークンコストです。

トークンの行方

正しさが飽和した後、トークン消費がより有益なシグナルとなります。3つのレガシースイートは合計600万トークン、9つのCVDPカテゴリは2億390万トークン（全体の97.1%）を使用します。CID 002だけで5600万トークンを使用します。

全トークンの約91%はキャッシュされた入力であり、APIコストを大幅に削減しました。そのため研究チームは、最終合格率ではなくトークン効率を最も改善が必要な指標と見なしています。

ユースケースの例

評価されたカテゴリは日常のRTL作業に直接対応します：RTLコード補完、自然言語仕様からRTL、修正とモジュール再利用、リンティングとQoR改善、検証生成、デバッグ。チェッカー生成は具体的な例です。単発モデルでは困難であり、低い3.8%から始まりますが、HORIZONは市販EDAシミュレーションに対して反復し、チェッカーが合格するまで続けます。

ハーネスの例

ユーザーが入力するのはコードではなくMarkdownハーネスです。次のスケルトンは4つのコンポーネントを示しています：目標（同期FIFOの実装、深さ16、8ビットデータ）、ドメイン知識の方向性（リセットは同期アクティブハイ、fullとemptyは同時にアサートしない）、評価器仕様（コンパイル、シミュレーション、カバレッジ抽出）、受入述語（シミュレーションがゼロ不一致で合格）。その後、ループはプレーンなGit操作でリポジトリを駆動します。

強みと限界

強み：1つのプロトコルで生成、完了、修復をカバー。フレームワークは基盤となるジェネレータやバックボーンに依存しない。ネイティブGitによりトレースとリプレイがほぼ無料で維持可能。セッション再利用により各イテレーションの限界コストが低い。

限界：報酬フィードバックインターフェースは過解決や報酬ハッキングを許容する可能性がある。これらのベンチマークははるかに広範な工学問題の制御されたプロキシである。フィードバックのターンアラウンドは良好だが、PPA指向のループは数日から数週間かかる場合がある。カバレッジは観測的であり、目標ではない。合成品質（QoR）は最適化されていない。研究チームは将来のベンチマークに2段階プロトコルを提案：修復中に診断フィードバックを公開し、隠れたランダムテストと形式チェックを最終スコアリング用に予約する。

重要なポイント

HORIZONは隔離されたGitワークツリー上でRTL設計をリポジトリレベルのコード進化として管理します。Markdownハーネスはプロジェクトパック（評価器、受入述語、Gitポリシー、ドメインスキル）にコンパイルされます。評価されたすべてのスイートで100%合格率に達します。唯一のミスはベンチマークの欠陥です。トークンの約91%はキャッシュ入力であり、コストはいくつかの困難なCVDPカテゴリに集中します。研究チームはハードウェア設計が解決されたとは主張しておらず、報酬ハッキングと長いターンアラウンド報酬は未解決の課題です。