Windows98也能跑AI,26年前的“老古董”玩轉大模型Llama,每秒生成39個token
被淘汰的“古董電腦”不一定非得走上“被賣掉換臉盆”的命運。有時稍加改造,它不僅能繼續用,還能運行時下前沿的大模型!
最近,一個名為 EXO Labs 的團隊發布了一段視頻,展示了在一臺有著 26 年歷史的 Windows 98 Pentium II PC 上運行強大的 LLM 的經歷。令人驚訝的是,這一過程成功了,而且大模型生成速度相當不錯,每秒能有 39.31 個 token 的輸出速度!
EXO Labs 表示,前沿 AI 并不一定非要依賴數據中心運行。他們這一次讓 Llama 在一臺運行 Windows 98 的奔騰 II 電腦上復活,這意味著——“如果它能跑在 25 年前的硬件上,那就說明它可以跑在任何地方!”
那么他們究竟是怎么實現的?我們將通過下文一起來了解一下~~
硬件設置
為了詳細地說明,EXO Labs 還發布了一篇主題為《在 Windows 98 上運行 Llama》的博客文章進行了步驟解析與痛點難點分享。
首先在硬件方面,EXO 在 eBay 上花費了 118.88 英鎊(約 1087 元)購買了一臺 Windows 98 Pentium II PC 作為實驗基礎設備,其配備 128MB RAM,正如下圖所示:
不難想象,5 年前的手機和電腦今天使用時還會遇到不少問題:一方面運行非常卡頓,另一方面許多設備也可能不兼容,更別提這臺 26 年前的老舊設備了。
正因此,在把這臺設備收到手后,EXO 就發現了現代 USB 鍵盤和鼠標根本無法與這臺電腦配合使用,這是需要解決的首要難題。
經過一番思考,EXO 提出了一個解決方案——放棄現代 USB 外設,回歸使用 PS/2 外設。畢竟,在那個年代,PS/2 接口是標準配置,Windows 98 與這類硬件天然兼容。
然而,使用 PS/2 鍵盤和鼠標時,該團隊還遇到了一個有趣的“限制”:必須將鼠標插入 PS/2 的端口 1,鍵盤插入端口 2,否則系統無法正確識別這些外設。
文件傳輸:回歸老舊的 FTP 協議
上面這個問題解決之后,接下來的挑戰是將文件傳輸到這臺老舊機器上。因為想要在這臺 Windows 95 設備上運行大模型,就必須要傳輸模型權重、標記器配置(tokenizer configs)和推理代碼等。
然而,該團隊嘗試了之后,現代解決方案全都失敗了,其中:
系統無法識別可重寫磁盤(RW disks)
4TB 的 USB 硬盤因 FAT32 文件系統限制而無法使用
沒有其他辦法,EXO 團隊成員最終選擇了經典的 FTP。
事實證明,FTP 在這些年里始終保持了向后兼容性。EXO 團隊通過在一臺 M4 MacBook Pro 上運行 FileZilla FTP 服務器,通過 USB-C 轉以太網適配器的方式將其連接到 Windows 98 機器,設置靜態 IP 后,可以直接通過命令行傳輸文件。
為了讓 MacBook 的 USB-C 以太網適配器與 Windows 98 通信,該團隊將其 IP 地址手動設置為 192.168.1.1,并驗證了連接是否正常。
一個簡單的 ping 測試證明兩臺設備可以成功互相通信:
Windows 98 命令提示符顯示 ping 成功
Windows 98 與 MacBook 的延遲小于 1 毫秒
網絡連接建立后,現在終于可以通過 FTP 傳輸文件。不過其中還有一個關鍵問題:可執行文件無法運行。
該團隊發現,它們需要以二進制模式傳輸。解決方法也很簡單——只需在 FTP 命令行中輸入 binary 即可:
通過二進制模式成功傳輸 stories260K.bin 文件
編譯挑戰
讓現代代碼在 Windows 98 上進行編譯想想都是一項非常棘手的任務。
最初,該團隊希望嘗試 mingw,這是一個用于在 Windows 操作系統上開發原生應用程序的開發工具集。它包含了一些 GNU 工具(如 GCC 編譯器),使得開發者可以使用類似 Unix 的開發環境來編譯和構建 Windows 應用程序,據稱也可以為 Windows 98 和奔騰 II 編譯現代 C++。
令人遺憾是,這條路行不通——可能是因為 CMOV(條件傳送)指令不被奔騰 Pro 之前的處理器支持。因此,早期的奔騰 II 處理器(即奔騰 Pro 之前的版本)不支持這一指令。當編譯器嘗試在不支持 CMOV 的舊處理器上使用這一指令時,程序可能會出現錯誤或無法編譯。
于是該團隊繼續采取了復古方案:使用 26 年前的 Borland C++ 5.02,這是一個可以直接在 Windows 98 上運行的 IDE 和編譯器。
不過,這個 IDE 只支持非常老舊的 C/C++ 版本,無法支持現代 C++。好在 C 語言在近幾十年間變化不大,要說最大的一次變更還是 1999 年的 C99 標準。這種舊版本的 C 主要限制是無法在函數中任意位置聲明變量——所有變量都必須在函數開頭聲明。
盡管老舊,但 Borland C++ 5.02 依然“能干活”
感謝 Karpathy 的助力
為 Windows 98 編譯現代代碼,該團隊最終選擇了曾擔任 Tesla 的 AI 總監、也是 OpenAI 的創始團隊成員之一 Andrej Karpathy 開發的 llama2.c。此前,我們也曾報道過,llama2.c 是一個僅有 700 行的純 C 代碼的推理引擎,可以運行基于 Llama 2 架構的模型推理。
雖然這一項目非常合適作為此次實驗運行的模型,但 EXO 團隊成員認為,仍需要針對奔騰 II 和 Windows 98 進行一些調整:
將 long long 替換為 DLONGWORD(通過 typedef 實現)
將所有變量聲明移動到函數開頭
簡化了磁盤到內存的加載(內存映射會導致段錯誤)
用 GetTickCount() 替換了 clock_gettime 解決時間戳問題
因此,他們將 llama2.c 進行優化調整之后得到了一個 llama98.c 項目,并將其完成的代碼在 GitHub 上開源出來:https://github.com/exo-explore/llama98.c。
借助這些資源,該團隊成功地將代碼編譯為可在 Windows 98 上運行的可執行文件。
260K 參數的 Llama 模型在 Windows 98 上運行,生成了一個關于 Sleepy Joe 的故事
運行結果
最終成功了!以下是在奔騰 II CPU(無需 GPU)上運行的測試結果如下:
對此,EXO 的成員之一 Alex Cheema 表示,在運行一個 260K 參數量的 Llama 架構模型時,這套系統在 Windows 98 上達到了每秒 39 token 的生成速度。當然,260K 的模型規模相對較小,但在一臺 350 MHz 單核古董 PC 上,這樣的運行速度已經相當可觀了。
根據上述結果顯示,當升級到 15M 參數量的 LLM 后,生成速度降到了略高于 每秒 1 token。然而,當嘗試運行 Llama 3.2 的 1B 參數量模型時,速度則降到了極其緩慢的每秒 0.0093 token。
雖然速度遠不及 ChatGPT,但能讓現代 AI 模型在 25 年前的 CPU 上運行是一個重要里程碑。
未來更多的可能性
EXO Labs 之所以做這樣的試驗,也并非沒有緣由。這家略顯神秘的組織成立于今年 9 月成立,主要成員來自牛津大學的研究人員和工程師,他們希望“讓每個人都能平等地獲取 AI 技術。”
簡單來說,EXO 認為,由少數幾家巨頭公司掌控 AI 技術對文化、事實真相以及社會的其他基本方面是極其不利的。因此,EXO 的愿景是“構建開放的基礎設施,用于訓練前沿模型,并使任何人能夠在任何地方運行它們。”
通過這種方式,普通人也有希望在幾乎任何設備上訓練和運行 AI 模型。而這次看似瘋狂的 Windows 98 AI 實驗,正是有限資源下 AI 能力的標志性演示。
對此,在博文中,EXO 表示,希望通過 BitNet 實現 AI 的普惠化。
BitNet 是一種新的人工智能模型架構,旨在通過使用三元權重(ternary weights)來實現更高效的模型運行。與傳統的深度學習模型使用浮點數(如 32 位或 64 位)表示權重不同,BitNet 的權重值只使用三個可能的值:0、-1 和 1,每個權重僅需 1.58 比特存儲空間(log?(3) ≈ 1.58)。這種簡化的權重表示可以顯著減少模型的存儲需求和計算量,從而使得模型能夠在硬件資源有限的設備上運行。
EXO 稱,利用這種架構:70 億參數的 BitNet 模型僅需 1.38GB 存儲空間。
這對一臺 26 年前的奔騰 II 來說可能仍然是巨大的負擔,但對于現代硬件,甚至是十幾年前的設備而言,已經相當輕量了。
它以 CPU 優先為設計理念,微軟的 BitCPP 可以在 M2 Ultra CPU 上實現 52 tokens/秒的生成速度,在 Intel i7 上生成速度為 18 tokens/秒
更令人驚嘆的是,100B 參數的 BitNet 可以在單個 CPU 上以 5-7 tokens/秒的人類閱讀速度運行
它比全精度模型能效高 50%以上
“雖然目前還沒有大型開源 BitNet 模型,但我們相信三值模型是實現普惠 AI 的未來”,EXO Labs 說道,其也希望看到更多的努力致力于在老舊硬件上運行 AI 模型,因為這方面還有大量的工程工作要做——從優化內存使用到探索可以高效運行于受限硬件的新架構。
對于這一嘗試,面對有人質疑其實用性,EXO Labs 在社交平臺 X 上再次強調,「這是硬件非常受限的一個例子。因此,結論是:如果我們能在此基礎上實現,那么幾乎可以在任何地方運行語言模型。」
參考:
https://blog.exolabs.net/day-4/
https://x.com/unwind_ai_/status/1873574158485111110
- 免責聲明
- 本文所包含的觀點僅代表作者個人看法,不代表新火種的觀點。在新火種上獲取的所有信息均不應被視為投資建議。新火種對本文可能提及或鏈接的任何項目不表示認可。 交易和投資涉及高風險,讀者在采取與本文內容相關的任何行動之前,請務必進行充分的盡職調查。最終的決策應該基于您自己的獨立判斷。新火種不對因依賴本文觀點而產生的任何金錢損失負任何責任。