Show HN: Auto-Architecture — Karpathyループ、CPUに向ける

· coding ai-agents devtools · Source ↗

TLDR

  • Karpathy流の「提案→実装→計測」ループを5段パイプラインのRV32IM SystemVerilogコアに適用した結果、10時間未満でCoreMarkが+92%向上し、LUT使用量は40%削減。

Key Takeaways

  • 9時間51分で73件の仮説を実行:10件採用、50件はリグレッション、9件はformal/cosimで破綻、4件はGowin GW2A-LV18ターゲットへのFPGA配置に失敗。
  • 最終結果:Fmax 199MHzで2.91 CoreMark/MHz(ベースライン2.23から向上)、LUT4数を40%削減しつつVexRiscvの公表値2.57 CoreMark/MHzを上回った。
  • 各ラウンドの流れ:3並列スロットがYAML仮説(スキーマ検証済み)を受け取り、独立したgit worktreeでrtl/編集を行い、riscv-formal BMC + Verilator cosim + nextpnr P&Rフィットネスで評価。
  • 最大の突破口はDIV/REMをシングルサイクルALUパスから切り離したこと。LUT半減は合成器の挙動を観察して発見されたものであり、事前予測ではない。
  • 検証器こそが真の強みだ:73件中63件の仮説が失敗し、riscv-formal・Verilator cosim・パスサンドボックスがベースラインを汚染する前に検出した。

Hacker News コメントレビュー

  • 自前のエージェントループを運用しているコメント投稿者たちが、検証器の重要性を実体験から支持:ゲートなしの失敗はループに誤った学習をさせるか、ベースラインをサイレントに破壊するという指摘はまさにその通りだと述べた。
  • このループの構造はLLMが突然変異を生成する遺伝的アルゴリズムとして認識されており、オーケストレーター自体よりも、formal属性スイート・CRC再検証・パスサンドボックスが新規性の核心だという見方が共有された。
  • ブログ記事自体がLLM生成ではないかという懐疑論も出た。また「エージェントは知らなかった」といった表現がメカニズムの記述ではなく擬人化ではないかという指摘も上がった。

注目コメント

  • @osti:同様の提案/計測ループを複雑なCUDAカーネルにCodexとgpt5.4xhighで独自実施し、スループット20倍向上を報告。
  • @mordae:Stanislaw Lemの『Summa Technologiae』(1964年)が、この種の進化的自己改善とその含意をすでに扱った先行文献として指摘。
  • @thin_carapace:規制産業への応用における転換点を提起——検証器が契約となるなら、FDA周辺領域ではループを合法的に動かす前に「検証器の検証器」が必要になる。

オリジナル | HNで議論


英語版: Show HN: Auto-Architecture: Karpathy’s Loop, pointed at a CPU · Original source