📍 真實場景
陳雨薇,一位接案十年的日文自由譯者,長期替科技業客戶處理商業合約與新產品發表稿的翻譯
她想在自己那台8GB記憶體的M1 MacBook Air上,用本地端AI幫忙抓翻譯後的小錯字、順一下語氣,因為客戶簽了保密協議,合約內容完全不能上傳到雲端AI
😖 卡住的地方：只要嘗試在電腦上開啟任何『看起來夠聰明』的大型語言模型,系統就跳出『記憶體不足,應用程式已結束』的警告,逼她要不忍受又貴又不安全的雲端AI,要不就得花七、八萬升級電腦
💡 這堂課會告訴她,有工程師做出一套引擎,能讓一個260億參數的大模型只用2GB記憶體就跑起來——連她那台最陽春的8GB Mac都跑得動,靠的不是硬體變便宜,而是一個很聰明的記憶體管理招數
🧭 這到底是什麼（白話版）
有工程師開源了一套叫TurboFieldfare的引擎,讓一個「參數AI模型裡用來記住規律、判斷答案的一堆數字旋鈕,數量越多通常代表模型腦容量越大」高達260億(26B)個的大型AI模型Gemma 4,可以在只有2GBRAM(記憶體)電腦正在使用中、隨時要抓取資料運算的暫存空間,速度快但容量有限,跟硬碟這種「長期倉庫」不一樣的情況下正常運作,而且連8GB記憶體、最陽春的Apple M系列Mac都跑得動。
這麼大的模型能被塞進這麼小的空間,關鍵在於Gemma 4本身是一種叫做「混合專家模型 MoE不是一個模型從頭到尾都是同一組,而是內部拆成很多個專門的小網路,叫做「專家」,每次只挑其中幾個出來工作,而不是整組一起動」的架構。雖然全部專家加起來高達26B參數,但每次推論讓已經訓練好的AI模型根據你輸入的問題去產生答案的過程,跟「訓練」模型是不同的兩件事,推論只是在使用它生成一個字的時候,其實只真正用到大約3.88B(所以官方叫它26B-A4B,A代表Active啟用)。
TurboFieldfare做的事情,就是把「常用的共用核心」跟負責記住對話內容的「KV快取AI在生成一段話時,把前面已經算過的重點暫存起來,才不用每次都從頭重新計算一遍」放在記憶體裡長駐,剩下沒被選到的專家全部留在硬碟上睡覺,只有輪到某個專家上場時,才用「串流(streaming)不是一次把全部資料搬進記憶體,而是需要用到哪一塊,才臨時去硬碟搬那一小塊過來」的方式現抓現用,用完馬上釋放。另外,所有權重都先做過「量化(quantization)把模型內部的數字用比較粗略、佔用空間更小的方式儲存,像把照片存成低畫質版本,檔案小很多、效果差不了太多」處理,壓縮成4-bit,只有負責挑專家的「路由器」保留8-bit精度,確保它不會選錯人。
結果就是,一台連遊戲都嫌貴要省著買的入門8GB Mac,也能跑起一個原本被認為「一定要32GB以上高階機器才跑得動」的大模型,速度雖然不算快(每秒5-6個字),但重點是「能跑」,而且完全在自己電腦上執行,不用把任何資料傳到雲端。
🔍 程式碼漫遊（點有 ● 的行看白話講解）
用一段簡化過的假想程式碼,示範『路由器』怎麼幫每個字挑專家、以及為什麼記憶體只需要一咪咪就夠用
●all_experts = load_experts_list_from_disk() # 26個(示意)專家清單,並沒有真的讀進記憶體
💬 這裡只讀取『清單』,不是真的把每個專家的參數都搬進RAM——這是省記憶體的第一步。
●shared_core, kv_cache = load_into_ram(shared_core_path) # 約1.35GB,常駐記憶體
💬 共用核心跟KV快取幾乎每個字都會用到,所以乾脆一直留在記憶體裡,不用重複搬運。
●for token in generate_next_tokens(prompt):
💬 以下這段迴圈,每產生一個字就會執行一次。
● chosen_ids = router.pick_top_k(token, k=2) # 用8-bit router選出2個真正要用的專家
💬 路由器決定這個字該找哪幾位專家幫忙,而不是每次都叫全部26個專家出來。
● experts_in_ram = stream_from_ssd(chosen_ids) # 現抓現用,從硬碟臨時搬進記憶體
💬 這一行就是『串流』的關鍵:只把剛剛選中的一兩個專家從硬碟搬進記憶體。
● output = compute(shared_core, experts_in_ram, kv_cache)
💬 用共用核心+剛搬進來的專家+之前的對話記憶(KV快取),一起算出這個字。
● release_from_ram(experts_in_ram) # 用完即丟,騰出空間給下一個字的專家
💬 這行是重點中的重點:專家用完立刻釋放記憶體,才能讓整體用量一直維持在2GB左右。
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 為什麼要把模型拆成很多個『專家』,而不是乾脆把26B參數全部拿來一起用?
這是MoE架構的核心取捨:把模型容量(能記住多少知識)跟推論成本(算一次答案要花多少運算)拆開處理。專家分工讓模型『腦容量』可以做得很大,但每次真正動用的只是一小部分,運算量跟記憶體都能大幅下降。代價是路由器的選擇準不準,直接決定輸出品質——選錯專家,答案就會變差。
🔭 為什麼要把大部分權重壓成4-bit,卻讓路由器保留8-bit精度?
這是典型的『該省的地方省、該花的地方花』的工程判斷。一般專家算錯一點點,頂多讓某個答案稍微不夠精確;但路由器如果因為精度太低而選錯專家,等於整個推論方向就跑偏了。所以作者選擇讓佔記憶體大宗的專家權重狠狠壓縮,但唯獨負責『做決策』的路由器留一手,用比較高的精度換取判斷的可靠性。
🔭 為什麼作者選擇替單一模型量身訂做runtime,而不是包一層通用的MLX或llama.cpp wrapper?
通用框架的優點是彈性大、能跑很多種模型,但也因為要照顧各種情況,很難把某個特定模型的記憶體管理做到極致。作者選擇犧牲『泛用性』(這套引擎目前只服務Gemma 4這個模型),換取針對這個模型的結構去客製化Metal kernel、快取策略跟串流時機,才擠得出2GB就能跑的成果。這是效能與維護成本之間很現實的取捨:新模型出來,可能得重新做一套。
🔭 為什麼作者要花力氣做103筆量測實驗紀錄,而不是直接放一支Demo影片就好?
這反映出『宣稱效能』跟『可驗證效能』之間的差距。單一支Demo影片可能挑最順的那一次錄,但103筆橫跨kernel、快取、I/O、prefill、decode各面向的量測數據,代表作者有系統性地測試不同情境下的表現,並且讓其他人可以照著方法在自己的機器上重現結果。對開源專案來說,這種『可被驗證、可被複製』的透明度,往往比一支漂亮的展示影片更能建立長期信任。
📝 隨堂考（點選答案，立即回饋）
Q1. TurboFieldfare能讓26B參數的Gemma 4模型,壓縮到大約多少記憶體就能執行?
✅ 因為只把共用核心與KV快取留在記憶體裡常駐,其餘專家用完即丟、現抓現用,所以整體只需要大約2GB。
Q2. 這個引擎能省下大量記憶體,核心關鍵技術是什麼?
✅ 關鍵在於MoE架構讓每次只需要用到少數幾個專家,加上串流機制讓沒被選到的專家一直留在硬碟上,不佔記憶體。
Q3. 為什麼路由器(router)用8-bit精度,而不是像其他專家權重一樣壓到4-bit?
✅ 路由器的判斷準確度直接影響整個推論結果,所以即使其他權重都壓縮成4-bit,路由器仍保留較高的8-bit精度來確保選擇正確。
Q4. TurboFieldfare是『模型專屬(model-specific)』的runtime,而不是像llama.cpp那種通用wrapper,這代表什麼樣的工程取捨?
✅ 通用框架要照顧各種模型,難以把單一模型的記憶體管理做到極致;model-specific的做法犧牲了泛用性,換來針對這個模型量身訂做的效能與省記憶體效果。
Q5. Gemma 4「26B-A4B」這個命名裡,「A4B」代表什麼意思?
✅ A代表Active(啟用),意思是雖然模型總共有26B參數,但MoE架構讓每次生成一個字時,真正被動用計算的只有大約3.88B(約4B)個參數。