TScale，一個用 C++ 和 CUDA 編寫的新型 transformer 訓練和推理框架，引發了開發者們對其程式碼質量和實現選擇的討論。該專案旨在使大型語言模型（LLM）訓練在消費級硬體上更加accessible，但早期社群反饋表明它可能過早釋出。
該程式碼庫承諾最佳化 transformer 架構，實現更快的收斂速度和降低注意力機制成本，其雄心勃勃的訓練能力宣告引起了人們的關注。根據其文件，TScale 可以使用幾個配備 NVIDIA 4090 GPU 的競價例項，以約 500 美元的成本訓練一個 1.5B 引數的模型。它還引入了一種有趣的 1T 索引技術，據報道可以使用更小的模型實現顯著的困惑度降低。
TScale 主要特點：
- 最佳化的 Transformer 架構，具有更快的收斂速度和約 2 倍降低的注意力計算成本
- 支援 fp8 和 int8 模型權重和啟用精度
- 針對消費級 NVIDIA GPU 最佳化，支援快速的降低精度訓練
- CPU 解除安裝以減少 GPU 記憶體需求
- 在相同配置主機上進行同步分散式訓練
- 用於常規乙太網互連的 1 位元梯度壓縮
- 在任意主機上進行非同步分散式訓練，網路流量最小化
效能宣告：
- 1.5B 模型訓練：使用 4090 GPU 的競價例項，2 天內完成，成本 500 美元
- 具有 1T 索引的 125M 模型：困惑度從 19.02 降低到 2.28
構建系統挑戰
社群成員提出的最直接問題之一是文件中提到的構建系統檔案缺失。一位使用者報告說，設定說明中描述的輕量級解決方案/構建檔案生成器 fo.cpp 實際上並不存在於程式碼庫中，這使得無法按照概述的方式進行構建過程。
「我嘗試執行這個專案，但 fo.cpp 在程式碼庫中不存在。我已經提交了一個問題，請參見 https://github.com/Foreseerr/TScale/issues/1」
這種差異表明該專案可能在完全準備好公開使用之前就釋出了，一些開發者推測這可能是一個過早分享的週末專案。
重新發明輪子
開發者們爭論的另一個焦點是 TScale 實現了基本元件，如鍵值配置檔案解析器，而許多人認為這是不必要的，因為已經有成熟的庫可用。這引發了關於 C/C++ 專案中依賴管理的更廣泛討論。
一些開發者認為，自己開發工具而不是使用現有庫的傾向深深植根於 C/C++ 文化中，這不一定是由於技術限制，而是文化偏好。雖然像 CMake 這樣的現代工具已經使依賴管理變得更容易，但最小化外部依賴的做法仍然很普遍。
一位開發者表示這種方法可能受到對依賴鏈的擔憂影響：
「依賴往往有它們自己的依賴（而這些依賴又有自己的依賴...）。讓我儘量減少依賴到最低限度的不是這樣做的難度，而是對這種情況的認識。」
其他人推測，一些程式碼模式可能是 LLM 輔助編碼的症狀，其中 AI 工具有時會為可以用現有庫解決的問題實現複雜的解決方案。
神秘的 1T 索引
專案中提到的 1T 索引技術引起了好奇。TScale 聲稱這種方法允許在家中訓練 1T 模型，方法是構建一個具有 1T 索引的模型，我們為每個標記查詢該索引，以使用更小的模型進行預測。根據文件，這種構建在對數損失和困惑度方面取得了出色的結果，據報道，使用帶有索引的 125M 引數模型時，困惑度降低了 8 倍。
社群成員表示有興趣更好地瞭解這種技術，一些人推測它可能涉及類似於自動推理學術文獻中描述的術語索引方法，可能實現為一種字首樹結構，有助於識別泛化。
 |
|---|
| 這張折線圖展示了可能與 TScale 的 1T 索引技術性能宣告相關的資料趨勢 |
分散式推理中的網路瓶頸
討論還涉及分散式推理的挑戰，特別是關於網路瓶頸。雖然 TScale 提到了分散式訓練功能，包括在地理上分離的主機上進行非同步分散式訓練，但社群指出，網路限制仍然是任何分散式 LLM 系統的重大挑戰。
正如一位評論者簡潔地表述的那樣：任何足夠先進的 LLM 訓練或推理管道最終都會發現真正的瓶頸是網路！
總之，雖然 TScale 提出了有趣的想法，使 LLM 訓練在消費級硬體上更加accessible，但早期社群反應表明，它可能需要進一步開發才能實現其承諾。這些討論突顯了建立高效 LLM 訓練框架的技術挑戰以及 C/C++ 生態系統中軟體開發的文化方面。
參考：TScale