PyTorch共同創設者がMetaとPyTorchを去る！AI開発の未来はどうなる？
引用元：https://news.ycombinator.com/item?id=45843948
PyTorchを後から批判するのはフェアじゃないよ。SoumithがPyTorchを立ち上げた頃は、他に良い選択肢がなかったんだ。Jaxもなかったしね。当時のPyTorchはめちゃくちゃ便利で、Andrej Karpathyも「PyTorch使い始めて数ヶ月だけど、調子いい」って言ってたほどだよ。Soumith、長年の努力に感謝する！今後の成功を祈ってるよ。くだらない批判は無視してね。
[a] https://x.com/karpathy/status/868178954032513024
PyTorchのdefine-by-runモデルって、実は日本の小さな会社が作ったChainerが元祖なんだ。PyTorchも初期にChainerから多くを借りたことを認めてるよ。
ありがとう。Chainerはぼんやり覚えてるけど使ってないな。当時、Chainerにはディープラーニングの既存コンポーネントが少なかった気がするんだ。PyTorchを試した時は、torch.nnにたくさんのプレビルドコンポーネントがあったから、すごく始めやすかったのを鮮明に覚えてるよ。記憶はあいまいだけどね。
そう、今じゃChainerを知る人は少ないよね。2016年当時、PyTorchのインターフェースはChainerより劣っていたし、Chainerのデザインは本当に時代を先取りしていたと思うよ。
Chainerを開発した会社はPreferred Networksっていうんだ。今でも存続していて、関連会社もいくつか持ってるよ。
PyTorchはPython Autogradライブラリ（2015年頃）に影響を受けていて、autodiffシステムも「autograd」って呼んでるんだ。JaxはAutogradの後継で、開発者の一部は今もJaxにいるよ。PyTorchの作者Adam Paszkeも今JAXチームにいて、JAXとDexに取り組んでるみたいだね。
[1] https://pypi.org/project/autograd/#history
[2] https://www.cs.toronto.edu/~rgrosse/courses/csc421_2019/read…
[3] https://web.archive.org/web/20170422051747/http://pytorch.or…
うん、PyTorchはAutogradやChainerなどから影響を受けてるよ。でもPyTorchはもっとフレンドリーでPython的だと感じたし、torch.nnにはディープラーニング用の包括的なプレビルドコンポーネントが付属してたんだ。それが使いやすさの秘訣だね。
参照: https://news.ycombinator.com/item?id=45848768
なんでみんなPyTorchに否定的なこと言ってるって思い込んでるんだ？ほとんどの人がPyTorchをめちゃくちゃ愛してるよ。
僕はSoumithがMetaとPyTorchに雇った一人だよ。彼とPyTorchで働けたのは光栄だった。SoumithはPyTorchを常にコミュニティプロジェクトと見ていて、共同制作者やCaffe2チームの貢献を称賛し、コミュニティの成長を重視してたんだ。彼は才能を引き寄せる人で、オープンソースの「バス係数問題」をうまく管理したよ。彼の離脱は時代の終わりだけど、運用上の問題は全くない。PyTorchはコミュニティの力で自立しており、彼の引退はオープンソースの成功の証さ。Soumith、お疲れ様！
Soumithは伝説の男だよ。俺が書いたものを気に入ってくれて、キャリアの道筋を変えてくれたんだ。傲慢さも政治的な駆け引きもなくて、すごく謙虚で落ち着いてるのに、周りのみんなを高めてくれる人さ。彼に最高の未来があることを願う！
この件で一番興味深いのは、MetaのAIには特別なものがないって皆が思ってるってことだよ。人材も計算能力も他で手に入るってことさ。軍事研究が進んでるって話に似てるよね、あれもただの神話って感じだし。BigTechのAI“ラボ”も、結局は同じことの繰り返しで、退屈なんだろうな。
「MetaのAIに特別なものがない」っていう意見は、Soumithが辞めた理由とは違うと思うな。彼はただ変化が欲しかっただけじゃないかな。
多くのAI企業が「AGIはもうすぐだ」って言ってるけど、開発者たちは全然盛り上がってないよね。ただの誇大広告だと思ってるんだろう。Mira Muratiがファインチューニングの会社を立ち上げたり、Karpathyが教育に戻ったり、みんな別の道を進んでるしね。
「変化を求めてた」ってのはさ、「もうここにはいられない、新しい場所の方がきっとマシだから賭けてみるか」ってことの丁寧な言い方だよ。俺も今の仕事は不満だらけだけど、転職するほどじゃないかな。でももし辞めるなら、面接では「変化を求めてたんです」って言うだろうね。
ちょっと深読みしすぎじゃないかな？彼はMetaに11年もいて、経済的にもかなり余裕があるはずだよ。それに新しい子供が生まれたって言ってたし、Metaのワークライフバランスは完璧じゃないからね。さらにMetaがLLMベースのAIにシフトして、PyTorchの伝統的な用途から離れてるってのもあるだろう。これらを総合すると、彼が新しい刺激的な機会を求めるのは自然なことだと思うな。
軍事に関しては、俺の限られた経験だと、ステルスみたいに軍事以外での応用が少ない技術を除けば、民間の最先端よりかなり遅れてるよ。実際、秘密にされてるものは何でも遅れがちだね。秘密主義は大きな負担だし、あらゆる形態のコラボレーションを著しく制限するから。それに、軍事プロジェクトは大規模で政治色が強いから、それに伴うあらゆる非効率性が出てくるんだ。機密扱いってのは、失敗や汚職を隠すのに都合がいいってのもあるしね。
LLMってPyTorchでできてないの？
いや、深読みしすぎってわけじゃないと思うよ？彼は「何か小さなことをやりたい」って言ってるんだ。もし大きなことをやりたいなら、リソースのある大企業にいるべきだろうしね。それに、「新しいこと」がAI関連なのかどうかも全然わからないし。
もし「先進的な軍事グレードの機器」に携わったことがあるなら、それが「実績のある技術」って euphemistically 言われる、最低入札者が比較的未熟な労働力で作ったものだって分かるはずだよ。捕獲されたロシアのドローンが Raspberry Pi を中身に使ってたのはマジで衝撃的だったね。アメリカ版は AliExpress の安物を使ってるだろうし、UK のやつは確実にそうだよ。
Soumithについては何も知らないけど、彼にはもう働かなくてもいいくらいの十分な経済力がある（俺の計算だとね）。
俺たちが得られる人生は一度きりだ。もし可能なら（他の制約を除いて）、名声、実績、一時的な賞賛、影響力、外部からの評価に囚われるべきじゃないよ。別の現実を見るには、自分の殻を破って、例えば誰も君が何をしたかなんて知らない、全く違う文化や環境で過ごしてみるのもいい。そんな決断をする人たちを尊敬するよ。人生って自動操縦で進みがちだからね。でも、成功を軽やかに受け止める人たちは稀だけど、俺の意見ではもっと哲学的に物事を理解しているんだ。彼の幸運を祈るよ！
これを言うのはね、軍事研究に似ている気がするからなんだ。みんな「軍がどれだけ進んでいるか、公共の研究と比べてどれだけ先を行っているか」って夢見てるけど…それは彼らが維持したい繰り返しの神話みたいだよね。
このブログ記事からは全くそう読み取れないんだけど、MetaでのAGI探求が、まるで映画「The Men Who Stare at Goats」の再来みたいだって考えると、ちょっと笑えるな。
別の現実を見るには、自分の殻を破って、例えば全く違う文化で過ごしてみるといい。
俺も今、似たような状況で決断しなきゃいけないんだ。問題は、ITの世界をしばらく離れると、戻るのが難しくなることだよ。人生を完全に変えて、持ってる知識や専門知識を全部捨てることになるだろうね。それは楽しいし、面白いし、視野が広がるだろうけど、もう後戻りはできないだろうな。
俺は米軍の防衛請負業者として様々な場所で12年（未来のR&Dから現在のE3まで）、その後12年間はインターネットスケールやスタートアップのB2Bビジネスで働いた経験があるよ。
配備される軍事技術の大きな違いは、軍事R&Dや商業サイドとは対照的に、それらが概ね信じられないほど頑丈で信頼性が高いことだと思う。もしそうでなければ、実際には使われないからね。そうなるまでには、ものすごい努力が必要なんだ。かつて、俺たちの未来のロボットタンクの試験場で、すぐ隣には屋外のテストコースがあったのを覚えてる。そこで彼らはキッチン・トレーラー（約200人分の食事を作れる、Humveeで牽引できるキッチン）をテストしていたんだ。彼らは3週間ぶっ通しでコースを走行させ、運転手や車両を交換するのに十分な時間だけ停止し、そして1日4回、停車して200人分の食事を作り、また梱包して走行に戻っていた。これは、そのキッチン・トレーラーが実用化されるまでにクリアしなければならない、いくつかの信頼性テストの一つだったんだ。
俺たちのR&Dのものはそこまでじゃなかったけど（常に3〜4人のエンジニアが注意深く監視する必要があった）、2週間の訓練を受けただけの18歳の兵士の手に渡るものは、たとえ一晩に4時間しか寝ていなくても、使えて、定期的なメンテナンスができ、修理できるほど頑丈でなければならなかった。もしそのレベルに達していなければ、部隊はそれを無視して、任務に出かけるときに置き去りにするだろうからね。そして概して、俺が見る限り、彼らが持っているもののほとんどはそのくらい信頼性が高かった。R&Dの分野ではいくつかのクールなことをやっていたけど、そのレベルにはまだまだ遠かったんだ。
それって、前のコメントの人が言いたかったことと全く同じじゃない？もしかしたら俺が彼らのコメントを誤解してるのかもしれないけど、君が言ってることは彼が言ったことの繰り返しに思えるんだけどな。
GP（Grandparent）が言いたいのは多分、最近の「AIで構築する」っていうのは、PyTorchを使って自分でモデルを訓練するんじゃなくて、学習済みのモデルにプロンプトを投げるのが主流ってことなんじゃないかな。
何もユニークなものはない？全くそうは思わないね。無制限の計算資源は文字通りユニークではないけど、そんなものを持ってる場所は世界にほんの一握りしかない。膨大な量のプライベートデータ、特にテキスト通信や画像もそうだ。そんなものを持ってる場所はごくわずかだよ。それに加えて、そのデータにプライバシー保護を全くかけない文化がある。Googleですら正しいことをしてるって思われたいのに、その点でMetaはユニークだと思うね。
ちなみに今チェックしたんだけど…映画「The Men Who Stare at Goats」ってRotten Tomatoesのスコアがめちゃくちゃ低いんだね https://www.rottentomatoes.com/m/men_who_stare_at_goats アイデアは面白そうだけど、映画としても実際良かったのかな
LlamaとCandleは、PyTorch/libtorchよりもモダンな技術だけど、libtorchはまだ事実上の標準だよね。
それに加えて、Metaは多くの大手テック企業と同様に、LLMベースAIに焦点を移し、従来のPyTorchの使い道から離れている。
これは全くの間違いだね。Metaは推薦アルゴリズムの最前線にいて、それは全て従来のMLモデルをPyTorchで作って行われているんだから。
役員レベルだと、専門知識は経営手腕がメインになりがちだよね。でも、個人貢献者（IC）的な立場だと、数年技術の現場から離れると、たまに触ってても戻るのがどんどん難しくなるんだよ。
彼、オフィス政治の犠牲になって、Metaの中で別の部署に飛ばされるくらいなら「もういいや！」って辞めたように見えるな。
もっとコメントを表示（1）
特殊作戦コミュニティには最先端の技術プロジェクトが山ほどあるよ。ハイブリッド暗視・熱探知システム、極秘ヘリ、特注弾薬のライフル、極秘医療技術、特殊固定翼機、先進ダイビングギアとかね。「Big Army」はコストのせいで何十年も、というかほとんど見ることないけどね。極秘潜水艦や核技術、既知の試験施設外で夜間飛行する固定翼ドローンとかは言うまでもない。軍事分野には超先進技術が大量にあるんだ。
仕事辞める決断には年齢がすごく重要だと思うよ。20代から30代前半なら、辞めて再スタートする余裕があるけど、30代後半になると「理想の職場」を見つける希望は薄れていく。40代に入ると、職種にもよるけど、コンサルタントとして自分を再ブランド化しない限り、もう終わりって感じだね。
そう、でもそれが俺の言いたいことなんだ。彼が（他の人が強調してた）お金よりも、そのユニークなものを手放す気でいるのが意味深いんだよ。君や俺がどう思うかじゃなくて、彼がどう思ってるか。彼が何かユニークなものを手放す準備ができてるってことは、彼が内部で知ってる限りでは、彼が留まりたいと思えるほど面白いことが十分な時間枠で予測できないってことだ。
「〜と言う丁寧な言い方」ってのは、必ずしもいつもそうとは限らないよ。俺は将来の計画や特別な問題もなく、ただ「ここはもう楽しくないな、良い職場だけど」って理由で仕事を辞めたことがたくさんあるし、そうしてるのは俺だけじゃないはずだ。
でも、辞める本当の理由を100%正直に言わないで去ったことは一度もない。「ただ変化を求めてたんだ」って理由じゃないなら、そうは言わない。正直に言わない理由なんてないからね。
その通りだね。時代の流れについていく唯一の方法は、少なくとも半分の時間で何かをやり続けることだよ。良いのは、それが前の仕事と同じじゃなくてもいいってこと。ただ脳を動かして学び続けるんだ。
彼が辞めたってことは、次に来るものがAI関連だろうとそうでなかろうと、「小さい」規模だろうと（彼らにとっての「小さい」は数百万人に届くことかもしれない。彼は「全AI業界を動かすソフトウェア層をリードした」って書いてたから、彼らの規模感は俺らとは違うかもね）、Metaの全リソースを使ってもできることよりも、彼にとってよりワクワクするってことだ。
編集：はっきりさせておくと、彼の次のことがAI関連だと示唆したかったわけじゃない。単に、彼らの専門知識からして、MetaのXRよりもMetaのAIについて詳しく知ってるってことだね。
みんな常にファインチューニングしてるけどね。数十億以上のパラメータを持つモデル全体をトレーニングするのは、個人のレベルではほとんど誰もやってないよ。資金が豊富な一握りのグループがPyTorchを使ってそれをやってる。大衆はまだPyTorchを使ってるけど、それは小規模なトレーニングジョブでだよ。AIを構築することと、AIを使って構築すること。
軍隊って信頼性が命だから、リスクは避けるんだよね。効果は低くても実績あるシステムを選ぶんだ（それに、システムごとに膨大な物流サポートも必要だし）。
皮肉なことに、企業は軍隊より失敗のリスクを許容できる（金銭的にもプロジェクト的にも）。なぜなら、企業にとっての失敗は人命に関わらないから。でも、もし人命に関わるようなら、企業でも軍隊みたいなプロセスが出てくるよ。
面白いことに、そういうのが民間に波及すると、さらに過剰になるんだよね。
例えば銃器。軍の標準装備M4A1は十分優れてるけど、民間のARでは、もっと酷使に耐える部品を作るための零細企業が山ほどある。ナイフもそう。普通の軍用フィールドナイフって、素材、特に鋼材で言えば80年くらい時代遅れ。でもそれは悪いことじゃなくて、”十分”使えるし安いんだ。でも民間人は、木をバトニングしてヒゲも剃れるナイフに10倍も金を出すけど、実際そんな使い道ないのにね。
ちょ、待って！
「木をバトニングしてヒゲ剃りできるナイフなんて実用性ない」って？俺、半年間のバックパッキング旅行から帰ってきたばっかりなんだけど、道中で焚き付けを割ってヒゲも定期的に剃る必要があったし、ナイフとカミソリを両方持っていく重さがなかったんだよ！/s
あの男（Soumith Chintala）の情熱って伝染するんだよね。DCGAN論文を読んだ時、Lua TorchコードをOxford flowers datasetで動かそうとして、早くから試したのを覚えてるよ。驚くほど上手くいって、Soumith Chintala自身もSNSでシェアしてくれたんだ、こんな小さなデータセットでこれほど上手くいくなんてって驚いてたね。もちろん当時はモード崩壊の問題をまだよく理解してなかったけど。
Pytorchや古いLua Torchは、当時のTensorFlowと比べて、めちゃくちゃ使いやすくて楽しかった。Soumithのコードはかなり自由にコピーされてたし、クセはあったけど（DCGANのコードはパラメータの渡し方がかなり変だったのを覚えてる）、本当に理解しやすくて、僕みたいな一般人でも突然とんでもなくパワフルなものに出くわしたような気分になれたんだ（実際そうだったんだけどね！）。素晴らしくハックしやすかったよ。
熱心なJAXユーザーとして、彼らが追いつけることを期待してるよ。TensorFlow 1が10ヤードラインでボールをファンブルして以来、PyTorchがAIシーンを席巻しちゃったからね。Matt JohnsonがAutogradをJAXに変えた功績は、Soumithが受けた賞賛と同じくらい評価されるべきだと思ってる。
良い答えは既にあるけど、ここに具体的な例を挙げるね。
大学で両方のライブラリを選ぶ必要があったから、テストとして言語モデルをゼロから書くことにしたんだ。TensorFlowの最初の些細な問題は（僕の記憶が正しければだけど）、ネットワークを”逆向き”に宣言する必要があったこと。つまり「A -＞ B -＞ C」じゃなくて「C(B(A))」ってね。でも最大の障害は、デバッグメッセージを追加する方法がなかったことだった。ネットワークが動くか動かないか、それだけ。さらに悪いことに、Seq2Seqモデルの公式TensorFlowチュートリアルは、ライブラリが変わったせいでコンパイルできなかったんだけど、そのバグ報告には何年もの間「APIを変更中だから、終わったら例を修正する」と返答があったんだ。
PyTorchは対照的に、Pythonベースのインターフェースが強みだった。いつも通りクラスを定義して（デバッグ文も入れられた！）、それらを変数として接続するだけでよかった。だから、僕と初心者の同僚たちがどちらのライブラリを選ぶか決める時、「デバッグが悪夢じゃない方」が「数十億の学習データとクラスタがあれば効率的な方」よりもずっと魅力的に聞こえたんだ。僕と僕の同僚たちはその後プロになって、みんなPyTorchを仕事に持って行ったよ。
僕も同じ経験をしたよ。TensorFlowの、計算グラフを構築してから評価するモデルは、Pythonの原則と合ってなくて、Tensorを簡単に表示できないからデバッグがめちゃくちゃ難しかったんだ！全然Pythonっぽくなかったしね。
それにAPIも常に変更されてたから、ドキュメントやオープンソースのリポジトリの例が動かないこともしょっちゅうだった。
あと、全てのTensorにユニークなグローバル名があるっていう変な仕様もあったんだ。同じスクリプトでDQNネットワークを2回評価しようとしたら、それが原因でエラーになったのを覚えてるよ。
このスレッドで多くの人が僕と同じ不満を共有してるのを見て、ちょっとホッとしたよ。これらのテクノロジーの影響を考えると、TensorFlowがなぜ失敗してPyTorchが成功したのかについてのドキュメンタリーは、すごく面白いだろうね。
TFは隠れ層の次元をprintデバッグで確認できないのが、新人のMSc学生には辛かったな。PyTorchなら普通のPythonのロジックフローを使えたから良かったよ。
2018年に「Don’t use TensorFlow, try PyTorch instead」ってブログ書いたんだけど、TFはAPIが変で複雑だったな。Kerasは良かったけどTFへの統合は遅すぎたんだ。PyTorchは最初Luaからの移植かと思ったけど、開発が進んで完璧な抽象度になったんだよね。NumPyみたいに簡単にテンソル扱えて、nn.Moduleで階層的に組めるのがマジ良かった。2018年からもうPyTorch一筋だよ。
記事: https://news.ycombinator.com/item?id=17415321
記事: https://p.migdal.pl/blog/2017/04/teaching-deep-learning/
記事: https://github.com/stared/thinking-in-tensors-writing-in-pyt…
自分の記事「Teaching deep learning」を読み返したら、進化ぶりに笑っちゃったよ。2017年のEDITではPyTorchが低レベルフレームワークとして最高かもって書いてて、2018年のEDITではKerasとPyTorchのどっちを最初に学ぶか議論してたんだよね。
元々のTFはLua-based Torchみたいに静的グラフだったけど、PyTorchは「define by run」っていう全然違うアプローチで超便利だったんだ。TFも後から「immediate mode」で対応したけど、PyTorchの勢いには勝てなかったね。TFはライブラリが乱立してドキュメントもひどかったけど、PyTorchはしっかりしててオンラインサポートも最高だった。
LuaTorchはeager-executionだったけど、GCに問題があったんだ。でもPyTorchはPythonの参照カウンティングシステムでこれを解決したし、CUDAメモリはシンプルなスラブアロケータで管理してるんだよね。
Lua Torchはeagerだったけど、モデルのグラフは事前に組まなきゃいけなかったんだ。「define by run」じゃなかったのさ。Andrew NgのMLコース修了後、Lua TorchのAPIを真似てC++のNNフレームワーク作ったとき、明示的にグラフを組むとGraphViz DOTで可視化できて良かったな。
あー、nnモジュールとテンソル実行の部分を混同してたわ。PyTorchのnnモジュールにはLua Torchの変なクセが色々残ってるんだよね！
数年前、TFとPyTorch両方使ったけど、開発体験はPyTorchの圧勝だったね。TFは低レベルAPIがひどいか、Kerasが高レベルすぎて使えないかのどっちかで、Googleの内部ツールを投げた感じ。PyTorchは抽象度もちょうどよくてドキュメントもチュートリアルも最高だったよ。MLエンジニアがPyTorchを選んだのは当然だね。TFのドキュメントが常に最新版しかなかったのもイケてなかったな。
8年くらい前だけど、TFはもう肥大化してたし、静的計算グラフのせいでコードが長くなってデバッグも大変だったんだ。みんなKeras使ってたし。次のプロジェクトでは「batteries included」なPyTorchに切り替えたよ。
10年くらい前、初心者が画像分類器をファインチューニングしてて、1万枚の中に1枚だけサイズが違う画像があったとするじゃん？そしたら結合エラーで落ちるのに、どのファイルが悪いか教えてくれないんだよ。経験者ならすぐわかることでも、フレームワークから離れていくのはいつも初心者なんだよな。
経験者ならすぐエラーに気づくけど、初心者はドキュメントが不十分だったり、共通タスクが複雑だったりするとフレームワークから離れるよ。
良いドキュメントや例、最新の状態を保つのは超大変。あと、ライブラリが詳細な構造化ロギングを実装しないせいで、現場でのトラブルシューティングがめっちゃ難しくなってるんだよね。
TF1は初心者にはめちゃくちゃ使いにくかったのを思い出すわ。Googleは「そういうもんだ」って言い張ってたけど、レイヤリングAPIとか関係なく、どこもかしこもトゲだらけだったんだよね。
TF1はコアユーザーのニーズに応えて、効率的な訓練と推論を提供したんだ。学習曲線は急だったけど、使いこなせば超優秀。でも分散型はダメだったな。
数年後、GoogleはTFの学習曲線が急すぎると気づき、PyTorchにユーザーを奪われ始めたんだよ。それでTF2を出したけど、TF1ユーザーは怒り、TF2は未完成。新しい学生は迷わずユーザーフレンドリーなPyTorchを選んだし、昔のTF1ユーザーもPyTorchに乗り換えたってわけ。
まず、2019年の2.0への移行はマジで痛かったね。その後2.7くらいから、後方互換性が壊れまくったんだ。新しいバージョンで古い訓練済みモデルを読み込めないのは、めちゃくちゃ辛いよ。
2015年のTFしか覚えてないけど、「コードを書いて微分したいのに、なんでPythonで計算グラフを組み立てなきゃいけないんだ？」って不思議だったな。
もっとコメントを表示（2）
TF2.Xを新規開発して、1.Xとの互換性を維持しなかったのが問題だね。
JAXは良さそうだけど、Googleがまたいつ捨ててしまうか、あるいは既存コードと完全に互換性のないJAX 2.0に置き換えるか、っていう不安がかなり大きいんだよね。このリスクは無視できないよ。
俺はOPじゃないけど、非AI科学計算ならJAXの方が好きだな。JAXは関数とその勾配を考えるけど、PyTorchは関数で操作しながら勾配を蓄積するテンソルを考えるんだ。JAXの考え方の方がしっくりくるよ。
JAX.jitが副作用なしの「機能的」関数を強制するのも良い。最初は変な感じかもだけど、結果的にコードはクリアで速くなる。PyTorchのJITがあまり注目されないのは驚きだね。大規模ネットワークが主体のPyTorchだと、科学計算ほどインパクトないのかな？
変じゃないよ。俺にとってはそれが一番自然なやり方だね。数式をJAXで書き下すだけで終わりだもん。
JAXって数式みたいに書けて、ベクトルやテンソルの操作には自然なんだ。コンパイル時の最適化で、数学的なコードがコンピュータに優しいコードになるから、Eager-JAXとCompiled-JAXの差はPyTorchより大きいよ。数独みたいに要素を更新するならin-placeの方が自然だし、パフォーマンスのためにもin-placeはよく使われるんだ。
僕はPyTorchの実務経験があって、JAXは趣味で使ってるんだ。JAXは小さなアイデアがレゴみたいに組み合わさってて、原理から性能を考えやすいし、ドキュメントも読みやすいんだよね。TensorFlowもそうだったけど、JAXの思想はGoogleの外から来たから、NumPyやPythonのイディオムに近いのもいい。でも、PyTorchはすごく成功してて、長年のコードが多いから、torch-compileみたいなのは理解が難しいこともあるね。
記事の引用「次は小さくて新しい、まだ完全に理解してないこと。Metaの内部で別のことに移ることもできたけど、Metaの外で何かを試さなかったという後悔はしたくなかった」だって。まさにシッダールタが森に帰るみたいだね。
シッダールタね、ああ、彼が社会の社会的な構造を引き裂く巨大企業で働いてて、しばらく別のことをしたかったって部分をほとんど忘れてたよ。皮肉だね。
彼はそれに全く関わってなかったと思うんだけどな。
彼は関わってたよ。Metaに突然来てPyTorchだけ始めたわけじゃない。製品のいろんな分野で働いてたし、上級技術スタッフのメンバーで、会社の多くのことを知ってたんだ。
興味がある人へ、Torchライブラリってすごく使いやすいんだ。RustにはtchやBurnがあって、どちらもlibtorchで動くよ。PyTorchは動的にデバッグできるのが最高だね。ブレークポイントを設定してターミナルでPyTorchの関数を直接呼び出して動作を調べられた時のことは忘れられないよ。今は「速い」コンパイル済みコードばかりで、それがすごく恋しいな。
昔は本当にひどいコードを書いたもんだけど、あのPyTorchのデバッグ体験は最高だったな。
「AI企業やハードウェアベンダーとの強いコネクションって権力を手放すのは難しいけど、結局は好奇心が勝った」って記事の引用だね。たった一つの感情がこんなにも力を持つなんてすごいよ。
彼が引退する前に、また一つ強力なツールを作れる機会を得られますように。
好奇心が死んだら、全てが崩れ去るんだ。新しいことを見つけられなくなって、充実感も感じなくなる。「もう次へ行く時だ」って最大のサインだよ。この贅沢ができない人の気持ち、すごくわかる。僕も、billsのためとか履歴書のためとかで、何年も不満な仕事を続けてたからね。
Gosh、あなたはどうやってMetaとPyTorchを辞めて、自分の好きなことだけを追求できるようになったの？教えてほしいな。
PyTorchって、シンプルすぎて自分で作れそうって思うくらいだよね。でも、「当然こうなるべき」って思える瞬間一つ一つに、どれだけの開発努力があったか考えるとすごいよな。
PyTorchが成功した要因となった設計上の決定について、技術的な解説をしてくれる人いない？知りたいな。
PyTorchの動的計算グラフがデバッグと実装を楽にして、普及に繋がったんだね。TensorFlowは静的から動的に移る時、全部壊れちゃったし。
Pytorchのコンパイル機能がTensorflowの優位性を消したけど、計算効率はまだ最適じゃないらしい。今のAI開発のスピードだと、PyTorchもあと1、2年で過去のものになるかもって言われてるよ。[1] https://www.geeksforgeeks.org/deep-learning/dynamic-vs-stati…
次の世代のAIアーキテクチャは誰かがプロトタイプを作る必要があるよね。
「PyTorchが1、2年で古いものになる」って意見、どうかな？新しい技術は早いけど、実際のプロジェクトでは古いPyTorchやCUDAが使われがちだよね。RTX 5000 series GPUsで動かすために、PyTorch 2.7.0やCUDA 12.8への更新がめちゃくちゃ大変だったよ。
もしPyTorchを倒すものがあるなら、とっくに名前が知られてるはず。PhDsたちもみんなPyTorchで研究してるし、強力なネットワークロックインもあるから、簡単には倒せないよ。TensorFlowが廃れるのにも何年もかかったんだから。
PyTorchを超えるには、コード移行をゼロにしたり、訓練コストを10倍減らす最適化や、PyTorchじゃできないアーキテクチャで圧倒的な性能を出すことが必要だね。Gaussian SplattingやLLMのキャッシュ戦略みたいな例もあるし。
PyTorchの主要な強みは3つ。GPUの抽象化、自動微分、クラスターオーケストレーションとシリアライゼーションだけど、それぞれに弱点もあるんだ。[2] ”https://docs.pytorch.org/xla/master/features/scan.html”
PyTorchが大事な最適化トリックを実装するのを、何が止めるんだろう？たとえ別のAPIが必要になってもさ。
妨げる要因には、ソフトストップとハードストップの2種類があるよ。
ソフトストップは、動的グラフの計算オーバーヘッドが大きすぎて、手動で書けば10倍速くなるような場合。例えば、ループのアンロールやカーネルフュージョンとかだね。
ハードストップは、最適じゃない計算でメモリが爆発して、そもそも計算ができなくなる場合。物理シミュレーションとか、LagrangianやHamiltonian neural networksで3回微分が必要な時とかが典型的な例だよ。
TensorFlowはC++/CUDAへの素のバインディングって感じだったけど、PyTorchはPythonらしくて、Numpyにすごく近い感覚だったな。
