Win98 跑起 LLM，離產品可用還有多遠？

Win98 跑起小模型證明了極限相容性，但能執行不代表能撐起日常工具

看到 Windows 98 也能執行語言模型，你可能會想：手邊這台電腦，能不能拿來做自己的 AI 工具？

這個念頭很合理，但在投入資源前，要先把展示本身看清楚。EXO 團隊公布的實驗，是把一支修改過的推論程式 llama98.c 放進一台搭載 Pentium II、安裝 Windows 98、只有 128MB 記憶體的老機器裡，執行兩個極小的語言模型。速度分別是每秒 39.31 個 token 與每秒 1.03 個 token（以下速度均以 token/s 表示）。

它跑的是哪一種模型、跑得多快、能不能撐起一個你願意天天用的工具，這三個問題需要分開看。把模型規模和速度單位看清楚，才看得出這個展示回答了什麼，又有哪些落差還沒跨過去。

EXO 實測小模型可達 39 token/s，但 1B 模型推估僅 0.0093 token/s 遠未達產品標準

EXO 公布的 llama98.c 測試結果，列了兩個小模型：stories260K 與 stories15M，分別跑出 39.31 token/s 與 1.03 token/s。這是 EXO 自己公布的實測數字，在那台 Pentium II、Windows 98、128MB 記憶體的機器上完成。

EXO 的部落格另外列出 Llama 3.2 1B 的推估速度：0.0093 token/s。換算下來，產生一個 token 要超過 100 秒。這個推估來自可放入記憶體的模型分片與磁碟讀取測試，尚非完整模型實跑，必須與前兩筆實測分開看。

兩個小模型的實測，是一個有價值的相容性結果。但能產生文字，還不足以判斷能否完成真實任務。展示回答的是能不能執行，產品還需要任務品質與等待時間各自的驗收標準。

BitNet 用 1.58 位元三值權重以加減取代乘法，但需從頭訓練並搭配專用推論框架

EXO 的展示解決的是「這支程式能不能在這台機器上跑起來」。另一個方向的工作，則是從模型權重本身下手，讓整個模型需要搬移的資料變少、運算變簡單。這就是 BitNet 要回答的問題，和 EXO 的展示是兩條獨立路線，Win98 的那次展示並沒有用上 BitNet。

BitNet 的論文提出三值權重設計，藉此簡化相應矩陣乘加運算，減少權重搬移的頻寬負擔。

原論文的 BitNet b1.58 採從頭訓練的設計，評估時要把這個前提算進去。1.58 表示三值權重的位元意義，不能據此認定整個模型檔案或推論系統都以 1.58-bit 儲存與運作。三值權重的簡化範圍，也限於相應矩陣運算。

微軟的 bitnet.cpp 是 BitNet 推論框架，提供 CPU 推論實作。模型權重重新設計之後，仍需要對應的推論軟體，才能評估它在指定硬體與任務上的真實表現。

llama.cpp 靠整數量化與多硬體後端釋放部署彈性，但成效仍須回歸指定硬體驗證

EXO 的展示解決極限環境的相容性，BitNet 從權重設計改變運算方式，第三個案例 llama.cpp 則從部署工具切入，讓開發者能自由組合部署選項。

llama.cpp 的專案說明列出多種硬體後端、整數量化與 CPU／GPU 混合推論，也提供本地執行與伺服器模式的服務入口。這些工具讓開發者能大幅降低硬體門檻，但實際速度與產品成效，仍要放回指定硬體與任務上實測。

三個案例各自回答了不同的工程問題：EXO 展示受限環境的相容性，BitNet 探索底層權重運算，llama.cpp 則提供量化與跨硬體支援。三條路線擴大了工程師的選型光譜，但推論能跑，依然不等於產品落地。

推論端改善不等於算力全面平權，決定本地部署必須通過品質、等待時間與總成本三道驗收

看完三個案例，有兩個極端的推論需要分開處理。

若因為展示沒有直接產品用途，就認為相關工程不值得理解，會忽略各條路線的探索價值。相容性、權重設計與部署工具各有要解決的底層問題，值得分別理解。

但若從這些案例直接跳到「算力已經全面平權」，也超出了證據能支持的範圍。推論端的改善，不足以證明前沿模型的訓練能力與算力資源已經普及。

要決定一個任務值不值得投入本地推論，我的判斷是至少要同時通過三道驗收：

這三項標準需要放回真實的業務場景驗證。模型能在你的電腦上執行，但產品必須在使用者的條件下成立。

結論：有離線或資料隱私限制才值得投入本地推論，先用小原型驗證品質與等待時間

回到開場的那個念頭：手邊這台電腦，能不能拿來做自己的 AI 工具？先看任務本身有沒有明確的限制條件。

如果工具需要離線運作，或者資料不能離開裝置，本地推論就具備不可替代的價值。在投入大量工程前，我建議先把品質下限、等待時間與維護總成本寫下來，拿一個小範圍的任務做原型驗證：先用現有工具跑一次，看輸出品質在不在接受範圍內，等待時間使用者受不受得了，再估算長期維護要花多少時間。把這次驗證的數據，作為下一步選型的依據。

硬體限制即使放寬，問題定義、資料品質、驗證方法與長期維護，仍然要由人來承擔責任。

換成你自己手上的任務，哪一項驗收標準會最先不成立？品質、等待時間，還是維護成本？

要把原型交給真正的使用者檢查，可以接著讀〈一個人用 AI 能做出整個產品嗎？Solo Builder 最缺的是會否決你的人（2026）〉。

延伸閱讀

• 一個人用 AI 能做出整個產品嗎？Solo Builder 最缺的是會否決你的人（2026）——原型能執行之後，下一個問題是誰來否決它。
• Token 概念——延伸理解速度單位。
• 評估設計——選型時，避免只看單次最好成績。

參考資料

• EXO, llama98.c（GitHub README）.
• EXO, Running Llama on 25 Year Old Hardware（部落格，含 Llama 3.2 1B 推估方法的註記）.
• Ma et al., The Era of 1-bit LLMs（論文全文）.
• Microsoft, BitNet（GitHub README；bitnet.cpp 推論框架）.
• ggml-org, llama.cpp（GitHub README）.