Comma.ai の創設者で tinygrad 機械学習フレームワークの開発者である George Hotz 氏が、 Tenstorrent のソフトウェアアプローチに対する辛辣な批判を発表した。彼のコメントは、このAIチップ企業の開発者体験と過度に複雑な抽象化レイヤーに対する懸念の高まりを浮き彫りにしている。
伝説的なチップアーキテクトである Jim Keller 氏が率いる Tenstorrent は、AIコンピュート分野において NVIDIA の競合として自社を位置づけてきた。同社は従来の GPU と比較してよりプログラマブルなハードウェアを約束しているが、 Hotz 氏は彼らがこの重要な利点を開発者に公開することに失敗していると主張している。
複数の抽象化レイヤーに対する開発者の不満
中核となる批判は、 Tenstorrent のソフトウェアスタックに抽象化レイヤーが多すぎることに焦点を当てている。 Hotz 氏は特に彼らの Low Level Kernel (LLK) アプローチを根本的に欠陥があるものとして批判し、それをクソの沼地に城を建てることに例えている。彼はより単純な3層アプローチを提唱している：フロントエンド、コンパイラ、そしてランタイム/ドライバーである。
コミュニティからのフィードバックもこれらの懸念を支持している。理想的な早期採用者であるはずの経験豊富な開発者たちが、 Tenstorrent のツールで進歩を遂げるのに苦労していると報告している。機械学習の博士課程学生で豊富なシステムプログラミング経験を持つ一人の開発者は、ドキュメントを読み、ミートアップに参加したにもかかわらず、彼らの様々な抽象化を理解することができなかったと述べている。
別の開発者は、週末に Tenstorrent の Blackhole ハードウェア上で最新の Vision Language Model を実行しようと試みたが、ソフトウェアスタックの複数の部分にまたがるサポートされていない操作で行き詰まり、ほとんど進歩を遂げることができなかった。
推奨されるソフトウェアスタック構造：
- 現在の Tenstorrent のアプローチ： LLK（Low Level Kernel）を含む7層以上の抽象化レイヤー
- 提案されたシンプル化アプローチ： 3層のみ
- フロントエンド（ PyTorch 、 ONNX 、tensor.py）
- コンパイラ（メモリ配置、オペレーション スケジューリング、カーネル融合）
- ランタイム/ドライバ（ハードウェア露出、コンパイル、ディスパッチ、キューイング）
より深い問題の象徴としての ELU 問題
Hotz 氏は、Exponential Linear Unit (ELU) 活性化関数を誤った複雑さの例として使用している。彼は、 ELU のような基本的な関数は、スタックの低レベルで特別な実装を必要とすべきではないと主張している。代わりに、それらは ReLU や指数関数のようなより単純な操作から構成されるべきである。
これは、優秀なエンジニアが広範な開発者体験を考慮せずに自分たちのユースケースに夢中になって調整している可能性があるという、より広範な組織的問題を反映している。その結果、内部チームには機能するが、外部の開発者にとっては障壁を作り出すシステムになっている。
特定された主要な技術的問題：
- ELU実装： 低レベルでハードコードするのではなく、
self.relu() - alpha*(1-self.exp()).relu()として構成されるべき - 抽象化の問題： tt-metalium の下に位置する LLK （Low Level Kernel）が適切なハードウェア露出を妨げている
- 開発者の障壁： 複雑な多層抽象化により、外部開発者が Mixtral や Pixtral のようなモデルを実装することが困難になっている
NVIDIA の優位性と今後の道筋
この批判は Tenstorrent にとって重要な時期に来ている。 Hotz 氏が指摘するように、同社は製造取引や知的財産ライセンシングにおいて NVIDIA や AMD のような確立されたプレイヤーと競争することはできない。彼らの唯一の持続可能な優位性は、ハードウェアのプログラマビリティを公開することにある。
「API設計に製品リーダーシップがない。読みやすさや書きやすさのためにパフォーマンスや表現力の低下をトレードオフすることを決して望まない、自分たちのユースケースに夢中になって調整している多くの本当に優秀なエンジニアがいるだけだ。」
コミュニティディスカッションは、成功するAIハードウェアプラットフォームには技術的な優秀さ以上のものが必要であることを明らかにしている。開発者体験に焦点を当てた強力な製品リーダーシップと、いくらかのパフォーマンスや内部の利便性を犠牲にしてでもクリーンな抽象化を維持する規律が必要である。
結論
Tenstorrent のハードウェア能力は印象的かもしれないが、開発者コミュニティの苦労は、同社がソフトウェアアプローチを根本的に再考する必要があることを示唆している。自然な支持者であるはずの経験豊富な開発者からの批判は、技術的な優秀さだけでは AIコンピュートにおける NVIDIA の支配に挑戦するには十分ではないことを示している。
今後の道筋は、短期的なパフォーマンスのトレードオフを意味するとしても、ソフトウェアスタックの簡素化について困難な決定を下すことを必要とする可能性が高い。これらの開発者体験の問題に対処しなければ、 Tenstorrent は意味のある市場牽引力を得ることに失敗する、もう一つの有望なAIチップ企業になるリスクを冒している。
参考: tt-tiny