Comma.ai 創始人兼 tinygrad 機器學習框架建立者 George Hotz 發表了對 Tenstorrent 軟體方法的嚴厲批評。他的評論突顯了人們對這家 AI 晶片公司開發者體驗和過度複雜抽象層的日益擔憂。
由傳奇晶片架構師 Jim Keller 領導的 Tenstorrent 一直將自己定位為 AI 計算領域 NVIDIA 的競爭對手。該公司承諾提供比傳統 GPU 更具可程式設計性的硬體，但 Hotz 認為他們未能向開發者展示這一關鍵優勢。
開發者對多重抽象層的不滿
核心批評集中在 Tenstorrent 的軟體棧擁有過多抽象層。Hotz 特別指出他們的低階核心（Low Level Kernel，LLK）方法存在根本缺陷，將其比作在糞坑沼澤上建造城堡。他主張採用更簡單的三層方法：前端、編譯器和執行時/驅動程式。
社群反饋支援這些擔憂。本應是理想早期採用者的經驗豐富的開發者報告稱，在使用 Tenstorrent 的工具時遇到困難。一位具有豐富系統程式設計經驗的機器學習博士生描述說，儘管閱讀了文件並參加了聚會，但仍無法理解他們的各種抽象概念。
另一位開發者試圖在週末期間在 Tenstorrent 的 Blackhole 硬體上執行最新的視覺語言模型，但進展甚微，被跨越軟體棧多個部分的不支援操作所困擾。
推薦的軟體棧結構：
- Tenstorrent 當前方法： 7+ 個抽象層，包括 LLK（低階核心）
- 提議的簡化方法： 僅 3 層
- 前端（PyTorch、ONNX、tensor.py）
- 編譯器（記憶體放置、操作排程、核心融合）
- 執行時/驅動程式（硬體暴露、編譯、排程、佇列）
ELU 問題作為深層問題的象徵
Hotz 以指數線性單元（Exponential Linear Unit，ELU）啟用函式為例，說明了錯位的複雜性。他認為像 ELU 這樣的基本函式不應該需要在軟體棧的低層進行特殊實現。相反，它們應該由更簡單的操作（如 ReLU 和指數函式）組合而成。
這反映了一個更廣泛的組織問題，即優秀的工程師可能會痴迷於為自己的用例進行調優，而不考慮更廣泛的開發者體驗。結果是一個對內部團隊有效但為外部開發者製造障礙的系統。
已識別的關鍵技術問題：
- ELU 實現： 應該組合為
self.relu() - alpha*(1-self.exp()).relu()而不是在底層硬編碼 - 抽象問題： LLK（低階核心）位於 tt-metalium 之下，阻止了適當的硬體暴露
- 開發者障礙： 複雜的多層抽象使外部開發者難以實現像 Mixtral 或 Pixtral 這樣的模型
NVIDIA 的優勢和前進道路
這一批評對 Tenstorrent 來說正值關鍵時刻。正如 Hotz 指出的，該公司無法在製造協議或智慧財產權許可方面與 NVIDIA 和 AMD 等老牌廠商競爭。他們唯一可持續的優勢在於暴露其硬體的可程式設計性。
「在 API 設計上缺乏產品領導力。只有很多非常優秀的工程師痴迷於為自己的用例進行調優，不願意為了可讀性或可寫性而在效能或表達能力上做出任何權衡。」
社群討論揭示，成功的 AI 硬體平臺需要的不僅僅是技術卓越。它們需要專注於開發者體驗的強有力產品領導力，以及即使意味著犧牲一些效能或內部便利性也要保持清晰抽象的紀律性。
結論
雖然 Tenstorrent 的硬體能力可能令人印象深刻，但開發者社群的困難表明該公司需要從根本上重新思考其軟體方法。來自本應是天然倡導者的經驗豐富開發者的批評表明，僅憑技術卓越還不足以挑戰 NVIDIA 在 AI 計算領域的主導地位。
前進的道路可能需要對簡化軟體棧做出艱難決定，即使這意味著短期的效能權衡。如果不解決這些開發者體驗問題，Tenstorrent 有可能成為另一家未能獲得有意義市場牽引力的有前途的 AI 晶片公司。
參考：tt-tiny