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

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

2026年4月29日原文(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の内部動作について大胆な推測をしている例だと思う。

Hacker Newsで議論の続きを見る