🚨 AI-LECTURER 快訊速報|2026-08-02|5 分鐘速讀

🚨 29GB 記憶體跑 2.78 兆參數 AI:一台筆電辦得到,代價是慢到心痛

取材:Run Kimi K3 using 29 GB of RAM at 0.50 tok/s(Hacker News(AI 高人氣))|完整課同日跟進,見書架
📍 真實場景
在小公司身兼多職的工程師,平常最愛追新模型評測

手上只有公司配發的 64GB MacBook Pro,卻很想親自跑跑看網路上吵翻天的 2.78 兆參數模型 Kimi K3,而不是只看別人貼的評測截圖

😖 卡住的地方:雲端 GPU 算力太貴,租一次動輒好幾百美金,租來也未必扛得動這種等級的模型;但又不甘心只當旁觀者
💡 讀完你會知道,不用買新顯卡、不用課金雲端主機,只要騰出約 1TB 硬碟空間,今晚就能在自己電腦上讓兆級模型真的「動起來」——只是它會慢到像老式簡訊一個字一個字跳出來

⚡ 一句話講清楚

現在的大型語言模型,能力常常跟 參數模型裡用來儲存「知識與判斷力」的數字,數量越多通常代表模型讀過的東西、抓得到的細節越多 數量成正比,而這次主角 Kimi K3 有 2.78 兆個參數,正常需要好幾台伺服器等級的機器、上兆位元組的記憶體才裝得下。但有工程師寫了一套叫 WASTE 的 推理引擎讓訓練好的 AI 模型實際「回答問題」的幕後程式,負責把你打的問題轉成模型看得懂的格式,再把算出的結果轉回文字,成功讓一台一般人買得到、64GB 記憶體的 MacBook Pro,也扛得動這隻參數巨獸。

關鍵在於 Kimi K3 是一種 專家混合模型(MoE)把一個大模型拆成很多個小的「專家」模組,每次回答問題只挑其中一小部分專家出來運算,不用整顆模型同時動起來 的架構,每次答題大概只會動用全部參數的 4%。WASTE 抓住這一點:把大家共用、每次都會用到的「主幹」留在記憶體裡,其餘用不到的「專家」平常乖乖待在硬碟上,真的被點名要用才臨時讀取,剩下的記憶體則拿來當 快取把最近用過、之後可能還會再用到的資料先暫存在讀取速度快的地方(這裡是記憶體),下次要用就不必再跑一趟硬碟,省下時間,於是不用把兩兆多個參數全部塞進記憶體才能開機。

結果代價很清楚:正確性沒問題(每一層的計算結果都拿 PyTorch 官方版本核對過,誤差小到 3.6e-06),但速度只有每秒 0.5 個 tokenAI 處理文字的最小單位,可能是一個字、半個詞或一個標點符號,「幾 token 幾秒」就代表它吐字的速度,問一句「義大利首都是哪裡」要等 26 秒。這篇文章真正有意思的地方不是「跑得快不快」,而是證明了「兆級模型能不能在一般人的電腦上跑」這件事,答案已經從「不可能」變成「可能,只是還要靠工程慢慢優化」。

🏃 快速上手三步(今天就能做)

1
先量自己電腦的硬體門檻檢查你電腦的可用記憶體(這篇實測最低要 29.05GB,建議 32GB 以上比較保險)和硬碟可用空間(至少要騰出 982GB,強烈建議用外接 NVMe SSD 而非傳統硬碟或隨身碟,因為讀取速度差很多倍)。判斷標準:低於這個門檻就先別碰 K3,改拿文中提到的小模型 Kimi-Linear 48B 練手,容器只要 19GB、最低 1.87GB RAM 就能跑,速度還快上將近 20 倍(10.7 tok/s)。
2
到 GitHub 抓 WASTE 原始碼實際跑一次到 GitHub 搜尋 sqliteai/waste 這個專案,照 README 步驟下載並「轉換」模型檔(轉換是把原始 1.42TB 的模型檔壓成 982GB 的專用容器格式,這步很花時間,建議睡前跑、隔天早上再看結果)。轉換完成後用指令啟動,格式跟文中範例一樣:waste run ~/models/k3.waste '你的問題',把路徑換成你實際存放的位置。
3
帶著懷疑心態驗證結果,看懂它印出的數字先問幾個你自己知道答案的簡單問題(像文中示範的「義大利首都是哪裡」),確認模型真的有在正常運作。同時留意終端機印出的 tok/s(每秒吐出幾個字)和 experts hit/miss(這次答題,原本就在記憶體裡的專家模組命中了幾次,沒命中就要多花時間去硬碟撈)。判斷標準:如果 miss 率明顯偏高,代表這次問題動用的專家組合比較分散,速度會更慢,這是正常現象、不是你的機器故障。

🧠 工程思維透鏡(資深工程師看到的是什麼)

🔭 犧牲速度換取「裝得下」,這筆交易在工程上划算嗎?
開發者測過兩個直覺上最該優化的方向——「每次少讀一點資料」和「多留一點在記憶體裡當快取」——結果雙雙宣告無效:這個模型家族的路由機制沒有「可以直接跳過的冷門專家」能省,而快取只要留不住(下一輪問題用到的專家組合一換,舊快取就得被換掉),砸再多記憶體也買不到加速。真正有效的反而是「把硬碟讀取跟其他運算重疊起來做」,不讓 CPU 在等硬碟資料回來時整個閒置。這說明有時候效能瓶頸不在「量」而在「時序安排」,值得任何做效能優化的工程師記住。
🔭 作者敢說「沒看過同等規模的先例」,這句話可信嗎?
作者自己承認這只是「搜尋沒找到」而非「做過完整文獻調查」——沒附參考書目、也沒有對照表,等於自己承認舉證責任還沒盡到,是邀請別人來踢館而非蓋棺定論。這是很好的工程文化示範:敢把「兆級模型可以在消費機上跑」這個原本大家覺得不可能的假設,用可驗證的方式(logit 誤差控制在 3.6e-06)攤開來給人挑戰,比起自吹自擂的行銷文,可信度反而更高。