ハクソク

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

Tinygradの5年間

108日前原文(geohot.github.io)

概要

  • tinygradは2020年10月17日に最初のコミット
  • 現在6人のチーム、約18,935行のコードベース
  • NVIDIAと競うための独自ソフトウェアスタック構築
  • 他社の巨大なコードベースと比較し、圧倒的に小規模
  • 目標はペタフロップのコモディティ化

tinygrad開発の歩みと哲学

  • tinygradは2020年10月17日に最初のコミット
  • 資金調達から約3年が経過
  • 現在のチームは6人構成
  • テストを除くコードベースは18,935行
  • 5年間で18,935行に注力し、他のメンバーも数年を費やす
  • 今後さらに5年の開発期間を見込む
  • NVIDIAと競合するための正しいプロセス重視
  • 最初からチップ（ASIC）設計に着手するのは非効率と主張
  • ソフトウェアスタックの完成が最優先
    • SOTAモデルを訓練可能な完全な主権ソフトウェアスタック
    • 完成後はチップ設計が容易になるという見解
  • AMD, Amazon, Tesla, Groqもチップを設計したが
    • GoogleとNVIDIAのみが本格的な訓練に利用されている理由はソフトウェア
  • LLVM依存排除を進行中
    • pure Python以外の依存をゼロにしてAMD GPUを駆動
  • フロントエンド、グラフコンパイラ、ランタイム、ドライバを完備
  • 既にPyTorchを上回るワークロードも存在
  • 最終的に約20,000行で完成予定

ソフトウェア設計に対する批判とtinygradのアプローチ

  • ソフトウェア設計の多くが誤った考え方に基づくと指摘
  • ほとんどのコードベースには他の部分の問題へのワークアラウンドが存在
    • その多くは深層的かつ構造的で、コードを読んでも気付きにくい
    • ソフトウェアの**98%**がこのようなワークアラウンドで構成されていると主張
  • Elon Musk流の「要件を愚かにしない」アプローチを採用
    • 「最良の部品は部品がないこと」を重視
    • ほとんどの要件は他の抽象化との互換性維持のために存在
  • LLMサーバーの例
    • 本質的要件は「OpenAI互換APIでLLMを高速実行」
    • 実際のコードベースは何百万行にも膨れ上がっている
    • tinygradは1/1000の規模
    • 他のコードは目標よりも他コードとの整合性に注力しているため非効率
  • 同様の非効率性が組織にも存在と指摘

tiny corpの組織形態と運営

  • tiny corpは分解型（deconstructed）企業
    • 高級シェフが料理を分解するように、会社の構造も分解
  • プライベートな要素はほとんどなく、DiscordとGitHubが主な運営基盤
  • 資金調達手段
    • コンピュータ販売部門で年間約$2Mの売上
    • AMDとの契約でMI350XをMLPerf上でLlama 405B訓練に利用
      • 交渉は主にTwitter上で公開
  • 採用はリポジトリへの貢献によって決定
  • 自律性の高い職場、週1回のミーティング、目標はtinygradの改善
  • ミッションはペタフロップのコモディティ化

Hackerたちの意見

tinygradがこのまま進んだら、何を置き換えるんだろう？
└
おそらくPyTorchとTensorFlowかな。
└
エッジシステムでの展開に大きな可能性があると思う。
「エロンのソフトウェアプロセスにサブスクする」っていうのは、ちょっと変だよね。毎年DefconのCTFでGeohotのPlayStationラップ動画を壁に映してたのを思い出す。
└
「インスピレーショナル」な名言が、元のアイデアを考えた人じゃなくて、一番多くのフォロワーがいる人に帰属されるのが嫌なんだよね。今回のケースだと、ロッキードのスカンクワークスのエンジニアたちなのに。
>「人はリポジトリに貢献することで雇われる。週に1回のミーティングがあって、tinygradを良くすることが目標の、自主的な仕事だ。こういう組織構造は魅力的だと思う。週に100%の生産性に近づける一番の方法かもしれない。」
└
ジョージの「みんなサンディエゴに移動するべし」っていう古い方針はどうなったんだろう？
└
貢献者を雇うことに反対するのは難しいけど、スキルのある開発者に対して市場価値の何分の一かしか払わない報酬システムだけが面接の道じゃない方がいいよね。ちょっと搾取的な感じがする。
本当に「複雑」なの？それとも「ややこしく」しちゃっただけ？ - https://www.youtube.com/watch?v=ubaX1Smg6pY
└
2025年にGPUをプログラミングするのは複雑だね。多分、わざと複雑にされてるからかもしれないけど、どっちにしてもこのプロジェクトがコントロールできる複雑さじゃないよ。TinygradがPyTorchと競ってるのがこんなに少ない行数で済むってことは、ほんとに余計な複雑さが少ないってことだね。
└
もし自分の方が良いことができると思うなら、コードはそのままあるから試してみて！もしそれをシンプルにできれば、虹の終わりには大金が待ってるよ。（この話好きだけどね）
>「運営資金を確保するために、年間約200万ドルの売上を上げるコンピュータ販売部門がある。それの利益率はどれくらい？5人のソフトウェアエンジニアが年間200万ドルのハードウェアの利益で本当に生活できるの？」
└
ジョージは2023年にTinygradのために510万ドルを調達したよ。
└
彼らのボックスを見て、労働コストを考えなければ20%くらいかな。ジョージは給料を取ってないと思うし、少なくとも少ない額だろうね。AMDとも契約があるし。会社はそこそこ利益が出てるんじゃないかな。
Tinygradのリスクは、PyTorchがInductorのために新しいバックエンドを作って、AMDのコード生成を組み込んで、結局PyTorchがまだ王様ってことだね。彼らも新しいMLフレームワークやADエンジンに手を出さずに、そのルートを簡単に選べたはずだし。99%の作業はコンパイラのAMDコード生成部分だしね。どっちにしても、すごくクールなプロジェクトだし、成功を祈ってるよ。
└
主なリスクは、LLMが自分自身を書き換えて、プログラマーが必要なくなることだね。ちょっとTinygradを触ってみたけど、すぐに動かせたし、タスクの一つを修正することもできた。でも、拒否されるのが怖くてコミットしないことにした。例えば、タスクが変だよね：H.265の最適化で2ヶ月で500ドルとか、世界中のほんの一部の人しかできないことだし。SVはGeoに会えて510万ドルを得られるユニークな場所で、たくさんのハードウェアを維持して、2万行のコードでフレームワークを作って、すべてがうまくいくんだ。
└
tinygradにはPyTorchのフロントエンドがあって、フロントエンドがPyTorchのままでtinygradをどのレベルでも統合することを全力で推奨してるよ。私たちのミッションはペタフロップを商品化することで、全てのフロントエンドを歓迎してる。ONNXのフロントエンドもかなり完成度が高いよ。
└
> walala これは「voila」とかそういう感じ？
「たったの18,935行のコード」のPythonコードを見たけど、目が痛くなりそうだった。こんな極端なコードゴルフの意味がよくわからないな。
└
ほんとにクレイジーだよね。もし誇張してると思うなら、これを見てみて: https://github.com/tinygrad/tinygrad/blob/master/tinygrad/co... コード行数にこだわるのが最も逆効果な指標の一つだと思う理由の一つは、いつもこんなコードを生み出すからなんだ。
└
これは素晴らしい実験だと思う。PyTorchのコードベースを見れば、小さなローカル関数をすぐに理解できるけど、もしPyTorchの全カーネルコードや低レベルコード、CUDAの全コードベース、LLVMのコンパイルコードを深く理解する必要があるなら、Tinygradを選ぶね。コードは難しそうに見えるけど、やってることが難しいからなんだ。でも、全てのレイヤーはデバッグできるよ。
└
大きな行数はもういらない！LLMsは私たちに二つのことをもたらした：コード行数を商品化したこと、そしておそらくもっと重要なのは、任意の行数のコードを理解することも商品化したこと。これを手に入れた今、昔の人間の理解を必要とするような大規模コードベースは恥ずかしいほど時代遅れだよ。「うーん、これは何を意味するの？」→ 右クリック → AIで説明 → 「わかった」。 "LLVMの削除に取り組む"って見たとき、思わずreddit-soyjackedしちゃった。LLVMは今でも存在する中で最もよく考えられた、よく設計されたソフトウェアだと思うけど…AIの時代に入った今、誰が気にするだろう？「よく考えられた」と「よく設計された」というのは人間の目の文脈での話だけど、もっと強力なコンピュータの目がある今、人間の目なんて必要ないよね。コンピュータは私たちよりもずっと速く、ずっと上手にコードを理解できるから。今やLLVMやLinux、Chromeのようなプロジェクトの膨大な行数は、コードの再利用の文脈で正当化するのが難しくなってきた。何百万行のコードを引きずり込む必要がある？必要な部分だけをLLMに書かせればいいじゃん。LLVMにはたくさんの最適化があるけど、それがHPCプラットフォームで実際にどれだけ効果をもたらすのかは疑問だよね。もともと命令の再配置や再スケジュールをたくさんやってるのに。私たちが「必要な部分だけ」を実現するためにコードベースの5%で済むかもしれない？昔は「まあ、そうだけどまだたくさんの（手動の）コーディングが必要だよね」って答えが返ってきたかもしれないけど、今は…なんでダメなの？デザインドキュメントにLLMを解き放って、ギャップを埋めてもらおう！
tinygradで人々は何を作ったの？
└
Comma ai
ergonomicsはPyTorchと比べてどうなの？ 研究がスムーズに進むことも採用の要因になりうるし（例えばtorchとtfの対比が思い浮かぶ）、初期のユーザー向けの適切なドキュメントが欠けてると思うんだよね。
tinybox red (v1)はどうなったの？ red v2よりもずっと良いスペックだったのに。