驚きの速さ AIが生成したカーネルが高速すぎた まだ公開するつもりじゃなかったのに！
引用元：https://news.ycombinator.com/item?id=44139454
この投稿の作者のAIエージェントの考え方、めっちゃ面白い！多くの人は人間従業員みたいに、限られた数で直列処理って考えるけど、LLMは無限にエージェントを作れるんだ。並列でもコスト変わんない。これに気づけば、タスクに応じてエージェントをどんどん増やす（フォークする）やり方がわかる。作者はこれをやってるね。エージェントは「タスク」みたいに考えて、Celeryとかの知見使う方がいいと思うよ。
エージェントだけでビジネス作れるかやってみたんだ。175のpythonファイル（従業員）と役割（タスク）で、互いに出力渡して作業を理解・完了できる。これ週末だけで一人で作ったんだよ。VCの友達に見せたら、同じやり方で25MMドル調達してるスタートアップがいた！1ヶ月とデザイナーとエンジニアいれば40kドルくらいで誰でも使えるMVPできそう。時代は変わったね。こんな感じ: https://s.h4x.club/9ZuO4XQR / https://s.h4x.club/jkuB8ZED
＞理解するLLMは理解してないよ。技術業界の大部分がそう考えてるのが信じられないね。持ってないものを atribuer (帰属させる) しないで。理解してるふりをするのはめっちゃ得意だよ。勘違いしないでほしいんだけど、多くのタスクではそれで十分なんだ。でも、この全部に根本的な限界があるってこと。それがないって信じ込んじゃダメだよ。
＞あいまいな指示に明確化を要求する
理解してるわけじゃないよ。これはパターンを複製してるだけ。
＞あいまいな指示に明確化を要求する
理解してるわけじゃないよ。これはパターンを複製してるだけ。
この手のAI批判は、人間にも跳ね返る致命的な欠陥があるよ。人間だって理解してないふりしてるし、人間にも限界がある。数ヶ月前のOpenAIのAIはすごかったけど、今は人工的に制限されてるのかも。プライベートではもっと良いはず。理解してるかは言えないけど、多くの人間よりずっと上だよ。Bloom’s taxonomyで言えば、創造性以外は人間並みかそれ以上だと思う。AIで「すごい」と思ったことがないなら、ちゃんと試してないかも。一般の人と比べたら、LLMの方が理解してるって感じるはずだよ。
違いは何？実際の理解ってどんな感じに見えるんだろう？
うーん、ゴールの移動じゃない？LLMは理解するって主張だった。それに対する反論は、いや、理解しない。でもうまくふりできるよ、だった。君の主張は今や、まあ人間だってよくふりしてるよ、だね。それはLLMが理解力を持ってるって主張してもOKだって意味合いなの？色々なことで人間より優れてるかもしれない。それはすごいことだ！20年前の僕のポケット電卓だってそうだったし、それもすごかった。でもどちらも自分が何をしてるか理解してないでしょ。
どうやって知ってるの？
なんで議論してるフリ？『LLMs don’t understand』って意見言っただけで、論拠ゼロじゃん。
『信じられない』とか『そう思うな』とか、全部個人的感想か行動の促しで、議論に値しないね。中身なくて感情的。なんでそう思うかも説明なし。反論しようがないよ、何も主張してないんだから。
あなたが理解してないって言うLLMとの方がよっぽど議論になるわ。考え直してほしい。
Extraordinary claim requires extraordinary proof。俺にはわからんけど、主張してるのは俺じゃないしね。（それにさ、LLMが何やってるかは知ってるじゃん。統計モデルで、理解を示してるわけじゃないんだよ。）
全く新しいルールのゲームを作れるとするじゃん。
それをLLMに説明する。
そしたらLLMはそのルール通りにゲームをプレイできた。
これでも理解してないって言えんの？
これってまさしく『Faster horse』シナリオって感じで、元のコメントのポイントを完全に外してるよね。なんで人間の働き方を模倣することに縛られなきゃいけないわけ？
＞新しいプログラミング言語の文法を定義して、LLMに例を一切与えずに食わせたら、その言語でコードを書けるか？
普通の人間だってできないでしょ。それがあなたの言いたいこと？
あなたのメッセージだと、その175人の従業員だけで具体的に何ができるのかハッキリしないな。例えば、チームにSEO専門家がいても、それだけで検索エンジンランキング上位を保証できるわけじゃないでしょ。 human だろうとAIだろうと、ツールはたくさんいるし、最高のものを持ってても根本的なビジネス競争は消えない。LLMsも他のツールと同じで、その根本問題は解決しないよ。
現実世界で従業員が一人で何かを成し遂げるなんてないよ、みんなチームの一員。だから俺はビジネス戦略と分析レイヤー（半分以上ね）を設計して、ウェブツールや insight システムへの接続をコードで定義したんだ。 digitalocean でやったのと同じ。 digitalocean も俺のLLMシステムもうまく動いてるよ。システム全体は自己学習、 insight 収集、洗練をしていく。競争なんて敗者がすること、最高のチームが最高の insight で勝つんだ。
人間が時間をモデル化したんだよ。それで朝と夜は現実のものになった。
＞新しいプログラミング言語の文法を定義して、LLMに例を一切与えずに食わせたら、その言語でコードを書けるか？
もちろんできるよ。人間と同じように実験して学ぶからね。Hacker news の人たちってまだLLMは統計モデルでなんか推測してるだけだと思ってんだな。
それが今の基準なの？平均的な人間より下手なら、その技術はすごいってこと？
LLMは訓練データで似たようなのを見てないとできんよ。そうじゃないって言うなら証明してくれ。
組織構造とかタスク分担を細かく決めなかったら、どんな創発的な特性が出てくるか考えたことある？
じゃあ、ただ意見を言う”だけ”はダメってこと？あなたもそうでしょ。自分の基準クリアするの？このスレッドで議論たくさんしたの見てない？考え直してよ。
なんで175？50億人とか2万社並列とかじゃないの？地球5個分の歴史シミュレートするとかさ。なんかSNSで寝る時間マウント取って「毎日2時に起きて瞑想ワークアウト」とか言う奴らみたいだね。
この実験ってなんか役に立つの？それともただ投資家のお金を吸い上げてるだけ？まぁ、後者でも別にいいんだけどさ。
＞タスクこなすのに必要なだけサブエージェントにフォークする
フォークはタダ。でも実行は線形コストで、一番高いのは応答をまとめる結合部分だよ。結合役はパース・要約が必要で情報損失するし、単一線形エージェントより計算量がかかるんだ。
＞Hacker newsの連中はまだLLMをただの統計モデルが推測してるだけだと思ってる
まさにその通りだよ。それがLLMの定義なんだ。もしそれが違うことをしてるなら、それはLLMじゃないね。
文脈によって色々な基準があるよね。でも平均的な人間より優れてる、っていうのは大体高い基準の一つだよ。
投資家は俺だけだよ。週末に一人で、自分で作ったんだ。できるってこと、だから存在するってことを確認したかっただけなんだ。個人的には、俺は年取ってて怠け者だから、a16zとかSequoiaが出資してるAdderall漬けのティーンエージャーとは競争したくないんだ。だから追求しないことにした。
＞ただ意見言う”だけ”はダメ？
そんなこと言ってない。他人に押し付けて議論のフリするのがダメってこと。お前は「〜と思う」を意図的に抜いて、論拠あるかのように語り始めた。それが問題。私のコメントは基準満たすよ。お前が議論たくさんしたの見たけど、相手が考慮したか不明だから俺は論点にしない。気が変わったらまたサブスレッドで。
ビジネス向けに何か設計したんだけど、リアルなビジネスみたいに4つの主要なサブシステム（insight/data, cognition, meta cognition, execution）が必要だって分かったんだ。この4つ全部を定義しないと、システムはゴミだよ。
もっとコメントを表示（1）
”FP32は最近のML作業ではあまり一般的じゃなくて、最新のハードウェアでもFP16とかBF16に比べて最適化されてないことが多いんだ。これがFP32カーネルでPyTorchより性能アップしやすい理由の一つかもね。”
みんな、FP32版のカーネルは何年も最適化に時間をかけてないんだよ。もし開発者が力を入れてて、実際に使われてるカーネルを改善できたら、もっと面白くなるだろうね。
AIが高速なカーネルを作れたのは、NVIDIAがGPUの詳細なドキュメントを出してないからだと思うんだ。ドキュメントがしっかりしてるプロセッサだと最適なプログラムを書きやすいけど、NVIDIAみたいに情報が少ない場合、AIが過去の例から未公開の挙動を見つけ出して改善できるのかもしれないね。
AIが新しいアルゴリズムを作ったとか、既存の解決策がなかったなんて誰も言ってないよ。言いたかったのは、FP32版のカーネルはより人気のバージョンに比べて遅れてたってこと。他のカーネルの進歩をこっちに翻訳する機会があったんだ。何が正確にやられたのかは詳しく見る必要があるけど、「新しいアルゴリズム」とか「既存の解決策なし」なんて言うのは早計だよ。
でも、これはLLMの良い使い方だね。僕もよく、一番使うものに改善を加えて、そのパターンをコードの他の似た部分に翻訳してもらうのにLLMを使うことがあるよ。
＞マイクロアーキテクチャがちゃんと文書化されてて、プログラマーやコンパイラが決定的に最適なプログラムを書けるプロセッサ
そもそも最適なアルゴリズムすら分かってないんだよ！ AlphaEvolveが最近「Strassenの1969年のアルゴリズムより改善された、4x4の複素行列を48回のスカラー乗算で掛けるアルゴリズム」を見つけたんだって。 - https://www.nature.com/articles/s41586-022-05172-4
＞マイクロアーキテクチャがちゃんと文書化されてて、プログラマーやコンパイラが決定的に最適なプログラムを書けるプロセッサ
君はこれらのカーネルの実装の可能性の広がりをかなり過小評価してるね。行列乗算を実行する方法はたくさんあって、 underlying system の完璧な知識があっても、全部実行せずにどれが一番性能が良いか予測するのは簡単じゃないんだよ。これは完全に間違った見方だね、元インサイダーとして言わせてもらうとさ。
最適なプログラムを作るのはすごく難しいんだよ。特に命令スケジューリングとかはNP-hardで、コンパイラも最適解を出そうとしない。時間かかりすぎるからね。クラスター使えばできるかもしれないけど、今は誰もやってないみたい。AIがこの辺で何かやってるのかも？
ターゲットプロセッサで動かさずにアルゴリズムの実行時間を予測できないなら、定義上そのプロセッサのドキュメントは不完全ってことになるよ。完全にドキュメント化されてるなら、複雑なプロセッサでも簡単な方法で実行時間を計算できないときは、シミュレーションモデルを動かして実行時間を出すことができなきゃダメだね。古いNVIDIA GPUにはそういうシミュレーションモデルもあるけど、GPUベンダーの協力なしにリバースエンジニアリングで作られてるから、部分的にしか正確じゃないんだ。
CUDAカーネルの実行時間は、実験と測定でしか決定できないみたいだし、非決定論的かもしれないね。それに比べて、より典型的なCPUの場合は、アセンブリ出力を確認できるコンパイラがあって、各命令のサイクルタイミングを教えてくれるプロセッサマニュアルがあるから、少なくともキャッシュに収まるインナーループとか、そういう種類の実行時間を計算できるんだ。
一般的に最適なプログラムを生成するのはすごく難しかったりほぼ不可能だったりするってのは正しいけど、最適なプログラムが達成できるケースもたくさんあるよ。後者は、アルゴリズムにハードウェアが決める支配的なボトルネックが一つあるときに起こるんだ。例えば、特定の命令（乗算やメモリロード）の最大スループットとかね。実装されたプログラムがその絶対的な限界に近いスループットに達したら、その最適性を確信できるんだ。
投稿主はコンパイルプロセスが非決定論的だとは言ってないと思うけど、もし本当にそうでも驚かないな。たくさんのアルゴリズムやデータ構造は、パフォーマンスやセキュリティのために（デフォルトで）非決定論に依存してるよ。偶発的に非決定論を導入するのも簡単だし、それをアルゴリズムを高速化するために使いたくなる誘惑もあるんだ。あと、浮動小数点に依存してるなら、異なるマシンや環境で結果が違うかもしれないし（libmやハードウェア実装によるけど）、それはある意味、非決定論的だね。
＞たくさんのアルゴリズムやデータ構造は、パフォーマンスやセキュリティのために（デフォルトで）非決定論に依存してるよ。偶発的に非決定論を導入するのも簡単だよ。
何言ってるかわかってないね。まともなコンパイラエンジニアなら、意図的にコンパイラにランダムなアルゴリズムを使うなんてことは絶対しないよ。それは毎回バグだし、すぐ潰されるんだ。
記事を読みたくない人向け：以前のベストはスカラ乗算49回だったってさ。
＞「ちょっと最近頭の回転が鈍いから、これ理解するの手伝って…」
もし僕が sed ’s/f32/f16/g’ kernel.cu ってやったら、これはAIってカウントされるわけ？ 最近みんながLLMになんでも結びつけるバカげたことに関して、ちょっと頭が鈍いから理解するの手伝ってよ…。
うん、その場合、普通はメモリバウンドなんだろうね？ メモリバウンドのときは、スケジューリングとかあんまり気にしないよね。
アルゴリズム設計の話をしてたんじゃなくて、特定のプロセッサ上でのアルゴリズム実装の話をしてたんだよ。レジスタ割り当てとか、マシン命令選択とか、静的命令スケジューリングとか、そういうことね。
こういうマシンで高性能コード書いてる人は、そんなドキュメント持ってないよ。でも大抵うまくやってる。サイクルカウントの時代はもう遠い昔の話だし、今のゲームのルールはキャッシュ効果とか同期とか、個別にはすごく推論しにくいけど、全体で見るとはっきり見えることにかかってるんだ。命令10個の時間を正確に測れてもご褒美はもらえないけど、1億個の行列乗算が1%速くなったらもらえるんだ。
言いたいのはね、実際の現場じゃ全部試して最速見つけるなんて無理ってこと。
時間がかかりすぎるからね。
だからたくさんの候補から良いのをアルゴリズム的に選ばなきゃいけないんだ。
それもすぐにね。
パラメータが多すぎて事前に全部計算しとくのも無理だよ。
これはシステムを完璧に知ってるプロがちゃんとやってることなんだ。
普通のCPUならコンパイラの出力とかマニュアルで命令のサイクル数わかるけど、GPUはSASSはダンプできても、OOOだからいつ実行されるか全然わかんないんだ。
だから単一命令のサイクル数なんて意味ないんだよね。
これはAMDGPUもNVもどっちもそうだよ。
CPUはすごいOOOだから、GPUより考えるのがずっと難しいんだよ。
要点はね、ただ動かすんじゃなくて、確実に一番最適なプログラムが書けるかって話だったんだ。
もしかして、fp16とかbf16のカーネルで知られてる改善点が、fp32にも使えるようになってるのかな？
たとえ全部の情報があったとしても、普通は（ていうか実際）一番良いプログラムを書くなんてできないんだよ。
んで、人間がそれを47まで落としたんだっけ？
＞最適化されたFP32版のカーネルはもうあったってこと？
もしその議論で自分の元の意見を主張しようとしてるなら、”新しいアルゴリズム”とか”既存の解決策がない”って言葉の定義がめちゃくちゃだよ。
行列乗算ってのはだいたい計算律速なんだけど、Nvidiaがアクセラレーターを提供してるから、それ以外の方法だと遅くなっちゃうんだ。
だから、実際のアルゴリズムを改善するっていう選択肢はそんなにないんだよね。
この記事とか Google’s AlphaEvolve 、あと o3 が Linux kernel でゼロデイ見つけたって話から思うのは、Gemini Pro 2.5 とか特に o3 がさ、新しいレベルになったってことだよ。
他のモデルでうまくいかなかったアイデアが、急にうまくいくようになったんだよね。
個人的にはさ、急にうまくいくようになったってよりは、人間より断然速く試したり試行錯誤したりできて、すぐに使える情報も圧倒的に多く理解できるようになった結果だと思うな。
だから情報と進歩と賢く使われた総当たり攻撃の組み合わせが、特定の用途で成功してるって感じかな。
良い点だね。
僕としてはさ、o3 は以前のモデルよりコードの中の色んなパスについて深く推論できるんじゃないかと思ってるんだ。
それが特にこういう作業（カーネル最適化とか）に役立ってるのかもね。
o3 でデバッグした結果にマジでビビって、それ以来ずっと使ってるんだ。
特に驚いたのは、何層もの影響から問題の原因見つけたこと。
普通デバッガで追うやつ。
この能力は抽象的なシステム設計とか、設計の遠い影響を考え抜く能力と重なると思うよ。
o3 をデバッグにどう使ってるか、もっと詳しく知りたいな。
もっとコメントを表示（2）
o3 をデバッグに使う一番のコツは、問題のコンテキストをどう作るかだよ。
同僚にバグ説明するみたいに、会話形式でソースコードと詳細な情報を混ぜるんだ。
効果的に使うには、詳細なコンテキストを全部与えて、モデルに過度に指示しないこと。
”ジーニー”みたいで、気をつけてないと literal にバカみたいな回答くるからね。
LLM の話でさ、「推論」って何のこと？
LLM の推論ってどう見えて、どうやってわかるの？
もっと大事なのは、どうやったらそれ（推論）を引き出せるの？
LLM に論理的な問題を解かせるの、あんまりうまくいったことないんだよね。
Chain of thought は多少懐疑的になるけど、あれは正確には推論じゃないし。
みんな「推論」って言うとき、何を指してるんだろうって気になるんだよね。
僕の理解ではさ、LLM の出力はコンテキストの結果としてのネットワークの状態に直接関係してる。
思考（Thinking）は、学習したパターンを使ってさ、もっと良い結果になりそうな方向へネットワークを誘導するために、中間予測を使う方法。
推論（Reasoning）は、そのプロセスをさらに正確な出力にするための戦略で、大体、予測の正確性に積み重なる効果があるんだ。
＞ 推論ってのはもっと正確な出力出すための戦略らしいけどさ、矛盾もまともに見つけられないのにどうやって正確さなんて評価すんの？
AIは推論を分析じゃなくて、学習したパターンで精度を上げてんだよ。数学の計算も理解してるわけじゃなくパターン予測。AIの思考や推論ってのは、パターン予測を正しい答えに導くための制御みたいなもんだね。
みんな、あるものの近似値がそれそのものだと思っちゃってるんだよね。
その可能性高いね。LLMは長い文脈をちゃんと見れるのがすごいメリット。まるでテスト中に教科書全部読めるみたい。2年前は数章分くらいだったのに。
君が言ってたことと今回の話、似てるね。記事からもわかるけど、これはLLMの能力を、明確な評価関数がある問題で解空間を狭めるのに応用できたって話だと思う。特定のモデルが他よりすごいとかじゃなくて、LLMの能力の使い方を学んだんだね。
Gemini Pro 2.5が初めて翻訳以外でまともに使えるAIだけど、まだギリギリって感じ。成功率20%以下の時もあるし。でも3.0が出たら…正直ちょっと怖くなるかもね。
僕の経験だとo3の方がもっと良い時もあるけど、遅いしレート制限あっていつもは使えないんだよね。
SRE / DevOps、Azure/.NET系の開発分野だよ。誰も答えを知らない難しい問題ばっかだからAIも苦手なんだけど、得意な「ちょっとした作業」で使えるようになった。例えば、他の言語でベンチマークコード書いたり、クラッシュダンプ解析したり、RoslynでASTリライター作ったりとか。
＞ 『簡単だけど自分でやるよりずっと速い』ってのが大事だよね。開発は新しい発明より設計の実行が多いし、簡単な作業が速くなるだけでマジで人生変わる。AIはLinuxカーネルをRustで書き直すとかじゃなくても、普通の開発者にとって超価値あるんだよ。
「”Vibe debugging”」って表現良いね！最新AIモデルで新しいことができるようになって，自分でツール作る気持ちわかるわー．GPT-3.5の頃から”agent”とか書いてたけど，最近のモデルは手書きコードじゃ無理だったこともできるようになってて凄いね．
面白そうな仕事，共有ありがとう！
面白いね．その主張を裏付けるもっと強い証拠ある？サンプルサイズ1は全然説得力ないよ．
待って，何言ってるの？これLinux kernelとは全く関係ないじゃん，GPUプログラミングでの”kernels”だよ．コメントまるごと幻覚でも見たの？
「”the reference code is in the default FP32， and given a tolerance threshold （1e-02）”」って，それめちゃくちゃ大きな許容誤差じゃん．fp16演算で”fp32”カーネルを置き換えることを許してるってことだよね．
これって結果が役に立たないってことじゃん．相対誤差は全然チェックしてないの？float32の演算をfloat16に置き換えるのも無意味だよ．float32の精度メリットが無くなるんだから，アルゴリズムのそのバージョンを使う一番重要な理由がなくなってるじゃん．
GitHubのコードを自分のRTX 3060M GPUで動かしてみたよ．平均二乗誤差が0.056くらいで，FP32と呼ぶには誤差大きすぎ．
あと，性能向上も僕の環境ではなかった（PyTorchより遅い3.8 GFLOPS vs 5.3）．多分Tensor Coreがないからかな．
でもコードは読みやすかったのは良かったよ．
それAmpereチップだったはずだから，Tensor Coreあるはずだよ．
