ハクソク

世界を動かす技術を、日本語で。

Show HN: 自動アーキテクチャ: カーパシーのループ、CPUに向けて

1日前原文(github.com)

概要

Karpathy's LoopをCPU設計領域に適用し、自律型リサーチエージェントの汎用性を検証。
自動化された設計最適化ループが、約10時間で人間設計者を上回る成果を達成。
**成果の鍵はループ自体ではなく検証器（Verifier）**である点を強調。
検証器の設計が今後の競争優位性を左右するという示唆。
次世代の生産性向上は、検証器の明確化と自動化にかかっているという結論。

Auto-Architecture: Karpathy's LoopをCPUに適用した実験

  • Andrej Karpathyのautoresearchは、提案・実装・評価・有効化という汎用的なループレシピ
  • これをPython/機械学習領域外であるSystemVerilog製CPU設計に適用
  • 対象は教科書的な5段パイプラインRV32IMコア（キャッシュ・分岐予測・マルチイシューなし）
  • 自律エージェントがYAML形式で仮説提案、実装、評価を繰り返す構成
    • 提案： microarchitecture仮説をYAMLで提出（スキーマチェック有）
    • 実装： isolated git worktree下でrtl/配下のファイルを編集
    • 評価： riscv-formal（53項目形式検証）、Verilator cosim（Python ISSと比較）、FPGA P&R、CoreMark CRC検証
  • 多様性確保のため、各ラウンドで異なるカテゴリ（micro_opt | structural | predictor | memory | extension）を割り当て

実験結果とインパクト

  • ベースライン： VexRiscv同等設定で2.23 CoreMark/MHz、301 iter/s
  • 人間設計者ベンチマーク： 2.57 CoreMark/MHz @ 144MHz
  • 自律ループの成果：
    • 73仮説、9時間51分で10件の有効改善を発見
    • 最終状態： 2.91 CoreMark/MHz、577 iter/s、199MHz、5,944 LUT4
      • ベースライン比+92%、VexRiscv比+56%（iter/s）、LUT40%削減
      • アーキテクチャ効率+13%、Fmax向上が残りの差分
  • ブレークスルー例： DIV/REMユニットの分離によるLUT半減など
  • 失敗事例： 実装ミス、サンドボックス違反、スキーマエラー、回帰（−73%）など多発
    • 73仮説中63件が否定（回帰・壊れ・P&R失敗）

検証器（Verifier）の重要性

  • ループ自体はコモディティ化（モデル・プロンプト・ツール・スロット数を選ぶだけ）
  • 価値の源泉は検証器（Verifier）にある
    • 正しいISA・形式検証プロパティ・パスサンドボックス・P&R多シード・CRC再検証・MMIO区間測定など
    • 検証器がなければ「自信満々で間違った数値」を返す危険
  • 今後の企業競争力： コードを書く人ではなく「検証器を書く人」が勝者
    • ビジネスごとに「正しさ」を厳密に定義・自動化できるかが鍵
    • AI問題ではなく「ドメイン知識をルール化」する問題
    • ルールが明確ならエージェントが人より速く満たす

次の展開と未来展望

  • 現状： ラウンド毎に失敗案を破棄する逐次探索
  • 今後： 上位K件を残して多様なパスを並列的に探索するpopulation-based searchへ
    • モデルコストを抑えつつ探索空間を拡大
  • CoreMark以外での一般化： Embench等他ワークロードへ適用し、真の汎用性を検証予定
  • 本質的問い： すでに「検証器」が明確な業務領域はどこか
    • そこにループを適用すれば、チーム生産性が人数に依存しなくなる
  • 結論： 未来のフロンティアは検証器。
    • 「正しさ」を明文化し自動化した者が勝つ時代

Hackerたちの意見

検証者の価値についての重要なポイントだね。最近の2四半期の経験と一致してる。遭遇した失敗についての詳細もいい感じ。テストスイートに対する自分のループでも似たような経験があったよ。素晴らしい投稿だね。時代のスナップショットみたい。
└
ありがとう！それをハードウェア設計に応用したの？それとも別の分野？
カーパシーのループに不慣れな場合は、これは遺伝的アルゴリズムなんだ。遺伝的「突然変異」は、システムを改善するためにLLMエージェントが生成する賢いけどランダムなアイデアだよ。 (1) LLMにシステムをランダムに変化させる。 (2) システムのパフォーマンスを測定する。 (3a) もし変化がパフォーマンスを改善したら、その変更を維持する。 (3b) そうでなければ、やめる。 (4) 繰り返す。
└
え、これ今名前ついてるの？数ヶ月前に全く同じアイデアを思いついたけど、実験する時間がなかったんだよね。その時は、得られる改善に対してめっちゃ高くつく可能性があるから、あまり真剣に考えなかったんだ。進化アルゴリズムの典型的な落とし穴にもハマるし（進化が生物に車輪を持たせないように、あなたのLLM進化アルゴリズムも、LLMが一歩で変化できる範囲を超えた大きな飛躍を生み出すことはないよね）。それに、遺伝的アルゴリズムは、進化が現実でスパゲッティのようなゲノムを作るのと同じように、短期的な決定の混乱を生むと思う。人々がこのアイデアをどう改善したのか、今実用的かどうかは絶対に調べる必要があるね。
└
実は俺はちょっと違うやり方してるんだ。 > (1) LLMにシステムをランダムに変化させるのを任せるんじゃなくて、LLMに「パフォーマンスが改善される可能性が最も低いのは何か」と聞いて、それを測定するようにしてる。時々、大きな成果は、思ってもみなかったところから来ることがあるんだよね。
└
ちょっと前にLLMを使った最適化やアルゴリズム発見に取り組んでたけど、これは新しいアイデアには見えないな。GoogleのAlphaEvolveは、アイデア生成にLLMを使った進化アルゴリズムで、非常に似たループを使ってるよ。 - https://deepmind.google/blog/alphaevolve-a-gemini-powered-co... - アルゴリズムのオープンソース実装: https://github.com/algorithmicsuperintelligence/openevolve
└
今のところ、これはソフトウェア開発者にとってのイディオクラシーみたいだね。
└
ありがとう、研究者としてカーパシーが関連する論文を含めて引用すると思ってたんだけど、すぐに失望しちゃった。オープンエボルブとACEフレームワークの論文は既に知ってたし、遺伝的アルゴリズムについては今回初めて知ったから、これからの勉強のための明確なロードマップができたよ。
└
遺伝的アルゴリズムは集団を維持して、「交差」操作があるんだけど、カーパシーの提案したスキームにはその両方が見当たらないね。
└
笑、カーパシーにはすごく敬意を表してるけど、これはあまりにも明白なアイデアだから、誰かの名前を付けるのが笑えるよ。次は「カーパシー投資」みたいな感じで、AIがループでポートフォリオを構築するのかな？
└
それは遺伝的アルゴリズムじゃなくて、確率的勾配降下法だよ。遺伝的アルゴリズムになるためには、突然変異（これはあるけど）とクロスオーバー（これはない）が必要だね。
非常に興味深いけど、なぜこれがLLMによって書かれたのか理解できない。フロンティアモデルが自分が思ってた以上に優れているのか、あるいはこの文書を書くのに多くの手作業が必要だったのか。だったら、なぜ自分の声で書かないの？ > エージェントは、それがLUTの数を半分にすることも知らなかった。実際にやってみて、合成器を見ながら気づいたんだ。だから、これはLLMが擬人化して、別のLLMの内部動作について大胆な推測をしている例だと思う。
└
うん、今のLLMの声は読むのがすごく疲れるよ。日々、クロードや他のものとやり取りしてるから十分なんだ。ただ、これを書くのにあまり労力はかからなかったと思うよ。おそらく「研究ログを読んで、素晴らしい結果を示すチャート付きのブログ投稿を書く」というプロンプトだったんじゃないかな。残りはコーヒーでも飲んでる間にできたと思う。それにしても、これの核心的なアイデア—検証がすごく重要—は好評で、実際、結果的には素晴らしいよね。最後に、どれだけこれがベンチマークに対してマイクロチューニングされているのかわからないって言ってるけど、これは多くのCPU会社が喜んで犯してきた罪でもあるから、もっと一般的なベンチマークに関するフォローアップがあれば興味あるな。どちらにしても、すごいよ。
実際にビジネスやプロジェクトのために検証者を書いた人はいる？
└
ここでの「検証者」は、ちょっと緩い表現だと思う。素晴らしいテストスイートも検証者だよ。オブジェクトからトレースログを生成して、再実装が同じログを出力するようなリバースエンジニアリングプロジェクトをやったことがある。厳密な比較を行ったりね。OPの投稿は、確かに他の多くの人が独立して発見したことを指摘しているんだ。あなたのエージェントベースの開発運用は、エージェントに与えるテストの儀式やガードレールの質次第だよ。
└
もう少し質問を詳しく説明してもらえる？ 再帰的エージェントは、決定論的終了条件を満たすための最小値を見つけるんだけど、チートも含まれるんだ。つまり、文字通り正しいけど間違っているってこと。悪意のあるコンプライアンスとも言えるね。学術研究を再現して、モデルをトレーニングしたすべての情報を使って調査することで、取引戦略を見つける再帰的エージェントがいるんだ。それは本当にうまくいくけど、毎行を書き出させて、壁時計の時刻から未来のデータがシステムに入らなかったことを証明する必要がある。たとえそれでも、夏時間のタイムゾーンを変換しないようなバカなことがあると、1時間未来を覗き見できちゃう。こういうバグはほとんど見つけられないんだ。だから、そのコードの行のタイムゾーンが正しかったことを説明するためだけの別のエージェントが必要だね。
└
ちょっと横道にそれるけど、今プロジェクトのバックエンドを書き直してて、検証者は「外部からAPI側で観察した場合、v1の機能を維持する」という指示を基本にしてるんだ。これで、システム内の既存データやフロントエンドがデータをどう期待しているかに基づいて、たくさんのテストができるんだよね。
└
それを使ったよ（同じアイデアに基づいたスキルだけど）UGCからデータを抽出するプロンプトを最適化するためにね。ただ、コードで簡単に定義できる「正しい」答えってのは実際にはないんだ。手動でトレーニングセットをラベル付けすることもできたけど、それは避けたかったから、LLMに結果を自分で分析させて、良くなったかどうかを判断させたんだ。いくつかのことについては決定論的なルールを書いたけど、全体的には各ラウンドの結果を見直して、良くなったかどうかを決めてた。結果のビフォーアフターを見てみると、うん、品質が大きく改善されたと言えるね。それに、プロンプトのサイズも最適化して、入力トークンを25%減らし、より小さくて安いモデルに切り替えたよ。
> 提案、実装、測定、成果を維持する。ほぼこれをやって、Codexにgpt5.4xhighを使わせて、かなり複雑なCUDAカーネルを改善して、20倍のスループット向上を実現したよ。
└
具体的に、そんなに大きな改善を達成するためにどんな面白い変更をしたの？
これってオートリサーチに関係あるの？ https://github.com/karpathy/autoresearch
└
「全然違う、まったく新しいアイデアだね。どうしてそんなことを思いついたの？」（笑）
これ、いろんなことに応用できそうだね。データベースの最適化とか。
└
まさにその通り、今日はFPGAだね…明日は企業全体になるかも。
みんながスタニスワフ・レムの『技術の総合』を読んでくれたらいいのに。1964年に明らかにこれが取り上げられてて、関連する意味合いもあったんだよね。 https://publicityreform.github.io/findbyimage/readings/lem.p...
└
どう思う？「もし読んだら、どのポイントに注意すればいいの？」って言いたいんだ。
これはLLMがコードを書くためのOODAループだね。
遺伝的アルゴリズムが大好きで、それにLLMを使うのがすごく魅力的だと思ってる。フィットネス関数が一番難しい部分だよね。アルゴリズムは、チートするためのちょっとした隙間を利用しようとするから。問題を解くのにバックプロパゲーションが必要ないのが一番の利点だけど、それが逆にランダムウォークの一段階上にしかない解決策になるのが最悪の部分でもある。LLMの拡張が、ランダムな混沌を超えた勾配と知性を与えるのが本当に助けになるね。ハードウェアに応用されるアイデアが好きだよ。
└
> 遺伝的アルゴリズムが好きなんだけど、これって本当に「遺伝的アルゴリズム」なのかな？「最もパフォーマンスの良い実行を選ぶ」以外には、クロスオーバーや突然変異とは全然関係ない気がするし、ただ「ベストを選ぶ」って感じだから、私には遺伝的アルゴリズムって思えないな。もしかしたら、何が「遺伝的アルゴリズム」としてカウントされるのか混乱してるだけかもしれないけど、専門家ってわけじゃないからね。