她已經用ChatGPT用了一年，但每個月的API帳單越來越心疼，也擔心把客戶資料傳到雲端不安全，於是想把AI「搬回」自己的電腦
想像一下,你口袋裡的手機或桌上的筆電,竟然能跑動一個原本得靠整排伺服器機櫃才撐得住的巨型AI模型——這正是這門課要帶你認識的「AI瘦身革命」。過去兩年,雲端上的AI模型越做越大、越聰明,但也越來越貴、越來越慢;於是整個業界忽然轉向,開始拼命把這些巨獸「搬回」你我手邊的裝置。這一單元,我們先建立大圖像:這股「AI本地化」浪潮到底在瘋什麼、靠的是哪兩把關鍵武器。
要讓一個原本活在雲端資料中心的AI模型塞進手機或筆電,得同時解決兩個問題:「裝得下」跟「跑得動」。裝不下,是因為模型的參數(可以想成它腦中儲存知識的無數個數字)動輒幾百億個,直接存起來就是幾十、上百GB;跑不動,則是因為就算裝得下,逐字生成回答的運算量還是太大,普通裝置的晶片撐不住反應速度。這波浪潮裡,業界剛好練出了兩把對症下藥的武器:一把專門負責「把模型變小」,叫量化(Quantization)把模型內部用來計算的數字,從精細但佔空間的格式,換成比較粗略但省空間的格式儲存,類似把相片存成品質降低但檔案小很多的JPG;另一把專門負責「把生成過程變快」,叫推測解碼(Speculative Decoding)先讓一個小model快速「起草」猜接下來一整段可能的內容,再交給正牌大model一次驗證整段對不對,省下逐字慢慢算的時間。
開源社群工具 Unsloth 在這場瘦身賽裡跑在前面。他們最新推出的 Dynamic v3.0 量化技術,鎖定的正是「瘦身但不失智」這個難題——同樣的檔案大小下,準確度比市面上其他家的量化版本平均高出超過10%。做法上,他們沒有重新訓練模型,而是靠更講究的imatrix校準資料集量化前用來「彩排」的一批範例題目,讓演算法知道模型裡哪些數字特別重要、動不得,哪些可以放心壓縮,校準做得細,瘦身後的模型才不會變笨,再搭配更聰明的「哪一層該多留一點細節、哪一層可以狠狠壓縮」的判斷。效果具體到什麼程度?他們最激進的1-bit壓縮版本,體積只剩原本的11%(6.2GB),卻還保留了七成左右的準確度;而其中一款9.83GB的版本,甚至能穩定寫出一個能動的HTML小程式——原本同尺寸的舊版量化模型會在這種任務上直接寫壞。
光是「裝得下」還不夠快,這時候就輪到 DFlash 2 登場。它的前身 DFlash 已經被 NVIDIA、Google TPU、Meta、Poolside 等一線大廠採用,實測能把生成速度拉快3到15倍不等,甚至有雲端服務商直接把它當成預設加速引擎。DFlash 系列的關鍵突破,在於把「起草」這個步驟從過去一次只能猜一個字,改成一次平行猜出一整個區塊的所有位置,再讓正牌大model一口氣驗證整段——猜對就整段收下,猜錯的部分才丟掉重猜。DFlash 2 在這個基礎上再進化:同一次驗證能多產出超過20%的內容,而且幾乎不增加額外延遲(大約只多1%),同時保證最終輸出結果和沒加速時完全一樣,不會因為求快而犧牲正確性。
把這兩把武器放在一起看,你會發現「AI本地化」浪潮並不是靠某個單一天才技術突破,而是「變小」跟「變快」兩條路線同時成熟、彼此互補的結果:量化負責讓巨型模型塞得進你的硬碟和記憶體,推測解碼負責讓它塞進去之後還能即時對答。接下來幾個單元,我們會一層層拆開這兩把武器的引擎蓋,看看它們實際上是怎麼運作的,以及這一切最終會如何落到你自己的裝置上。
| 武器 | 解決的問題 | 這次認識的代表技術 | 具體成果 |
|---|---|---|---|
| 量化 Quantization | 模型檔案太大,裝置裝不下 | Unsloth Dynamic v3.0 | 同尺寸下準確度提升逾10%;1-bit版本縮至6.2GB仍保留約72%準確度 |
| 推測解碼 Speculative Decoding | 生成速度太慢,裝置跑不動 | DFlash 2 | 較前代再提升16~25%輸出量,延遲只多約1%,結果與未加速時完全一致 |
上一集我們認識了「AI本地化」這股浪潮——想辦法把巨大的AI模型塞進你口袋裡的手機、桌上的筆電。但這裡有個問題：這些巨頭手上明明握有全世界最頂級的運算資源，為什麼NVIDIA、Google、Meta卻反而卯足全力在研究「怎麼讓AI回答問題的速度更快」？答案藏在AI生成答案的方式裡。
AI在「一個字一個字往外吐」答案的時候，其實最花時間的不是算數學，而是記憶體頻寬瓶頸每吐一個字，都要把整個模型幾十億個參數從記憶體搬到運算晶片裡跑一遍，就像每次只搬一件行李卻要來回跑一趟樓梯，真正卡住的是走道太窄，不是你力氣不夠。這代表就算換更強的晶片，只要還是「一次一個字」，速度天花板就在那裡。
於是業界想出一招叫推測解碼先找一個小小的「草稿模型」，讓它大膽一次猜出接下來好幾個字，再讓真正的大模型一口氣核對整串猜測對不對；猜對的地方直接採用，等於省下大模型重新算一次的時間，猜錯的地方大模型照樣會自己補上正確答案，所以最終答案完全不會變。素材裡的DFlash，就是把這個「猜」的動作也改成同時（平行）猜好幾個位置，而不是猜一個字又等一下再猜下一個字。
這一招的效果好到讓各大廠搶著跟進：NVIDIA用它在Blackwell GPU上量到最高15倍的處理速度，Google在自家TPU上測出3倍的每秒生成字數，CoreWeave拿它跑Kimi K2.7 Code的正式服務。連Meta（Muse Glimmer）、Poolside（Laguna）、小米（MiMo-V2.5-Pro）、NVIDIA自己（Nemotron 3.5 Lightning）都直接推出自家專屬的「草稿模型」搭配使用，DFlash相關模型在Hugging Face上被下載超過350萬次。接著登場的DFlash 2，在幾乎不增加等待時間（約多1%）的情況下，又多擠出超過20%的產出——這已經不是單一公司的技術突破，而是整條生態系一起在拼「同樣的算力，誰能榨出更多字」。
LFM團隊的DSpark則是把這場競賽再往前推一步：除了DFlash式的平行猜測，還加了一個「序列頭」讓猜出來的字前後接得更順，再加一個「信心排程驗證器」——猜到後面沒把握時乾脆提早喊停，省下白做的驗證。結果是GPU上最高3.18倍加速、裝置端最高2.87倍，而且特別針對手機、筆電這種邊緣裝置優化「函式呼叫」（也就是AI要指揮工具、下指令的能力），把延遲砍了57%。這正好呼應了本集的重點：手機沒有資料中心等級的記憶體頻寬，反而是逼出這些精巧加速技巧的最大推力。
| 方式 | 怎麼運作 | 速度表現 |
|---|---|---|
| 傳統一字一字生成 | 大模型自己一個字一個字慢慢吐，吐完才吐下一個 | 基準速度（1倍） |
| DFlash（平行草稿＋一次驗證） | 小模型同時猜好幾個字，大模型一次驗證整串 | GPU上最高15倍，TPU上3倍 |
| DSpark（平行＋銜接順暢＋提早喊停） | 在DFlash基礎上加「字與字接得順」與「沒把握就先不驗證」兩道機制 | GPU最高3.18倍、裝置端最高2.87倍，函式呼叫延遲降57% |
上一堂我們看到各大廠為什麼卯足全力想讓AI跑更快、更省——這堂課就來打開引擎蓋，看看檯面下到底是哪些技術在撐著這股「瘦身競賽」。這次要拆解的三個技術，剛好對應AI要塞進你電腦時的三大關卡：模型本身要瘦身、每次回話要加速、還要有辦法在本機建立自己的知識庫。
Unsloth團隊發布的Dynamic 3.0，解決的就是第一關「怎麼瘦身還不失準頭」。要理解這件事，先要知道量化把模型裡每個數字改用更少的位元儲存，就像把一張高畫質照片壓縮成較小的檔案這個動作。過去量化最怕的是「壓縮完AI變笨」，Dynamic 3.0的做法不是對整個模型「雨露均霑」平均壓縮，而是先用一批多樣化的imatrix校準資料集拿一批具代表性的範例句子先跑過模型，觀察哪些部分的數字對輸出影響大、哪些影響小，再針對「動刀不能太深」的關鍵層少壓一點、其餘層多壓一點。官方號稱整體準確度比其他方案高出10%以上，其中UD-Q2_K_XL這個版本檔案只有9.83GB，準確度卻比第二名再高出約8%，甚至連原本會整個寫壞的網頁小程式，現在也能做出一個能動、只剩一個小瑕疵的版本。
光是模型變小還不夠快，因為AI每吐一個字，都要把整個模型的參數從記憶體搬到運算晶片上算一次——這個「搬資料」的時間，往往比真正計算的時間還久，這正是LFM團隊要用推測解碼先讓一個小的「草稿模型」快速猜接下來好幾個字，再讓正式的大模型一次驗證這些猜測對不對，而不是一個字一個字重新算（DSpark）解決的問題。DSpark比較特別的地方是同時用了三招：一個小草稿模型平行預測好幾步、一個負責抓「這個字和下個字關聯性」的小模組讓猜測更準、再加上一個會自己判斷「這段猜測值不值得驗證」的信心把關機制，猜不準就提早放棄省時間。而且因為猜錯的字最後都會換回大模型自己算出來的答案，最終結果跟完全不用推測解碼時一模一樣，只是速度在GPU上最快可到3.18倍、裝置端也有2.87倍，手機筆電這類裝置呼叫工具的等待時間平均還能再降57%。
第三關是「AI要怎麼在你的電腦裡有一個自己的知識庫」，答案是向量搜尋把文字轉成一串數字（向量），再靠比對這些數字的相似程度找出意思相近的內容，是打造「問AI關於我自己資料」系統的核心技術，這也是RAG（讓AI先查資料再回答）能夠成立的基礎。Google研究團隊的TurboQuant演算法被寫成Rust函式庫turbovec後，同樣的量化精神也用在向量上：一千萬筆文件原本要吃掉31GB記憶體，壓縮後只要4GB，而且在4位元設定下平均還比業界常用的FAISS快3.4倍。更關鍵的是它「不用訓練」，資料丟進去馬上就能查，跟著資料庫一起成長也不用整個重建索引。
把這三件事放在一起看，你會發現它們其實是同一種思路的三次應用：不是靠堆更多硬體去換效能，而是想辦法把「不重要的細節」榨出去，把省下來的空間和時間留給真正影響結果的部分。下一堂就要接著問：這些實驗室裡打磨出來的技術，實際落到你的手機和筆電上，能讓你做到哪些以前做不到的事。
| 技術 | 解決的問題 | 關鍵效果 |
|---|---|---|
| 動態量化（Unsloth Dynamic 3.0） | 模型檔案太大、壓縮後容易變笨 | 檔案大小不變，整體準確度號稱高10%以上（UD-Q2_K_XL單一版本達+8%、9.83GB） |
| 推測解碼（LFM2.5-DSpark） | 每個字都要重新搬一次模型參數，速度慢 | GPU最快3.18倍、裝置端2.87倍，工具呼叫延遲平均降57% |
| 向量量化搜尋（turbovec） | 本地知識庫的索引太佔記憶體、搜尋慢 | 1000萬筆文件從31GB壓到4GB，4-bit下平均比FAISS快3.4倍 |
turbovec的官方範例展示了怎麼在本機建立一個向量索引、加入資料、搜尋，完全不用另外跑一個訓練步驟。
from turbovec import TurboQuantIndexindex = TurboQuantIndex(dim=1536, bit_width=4)index.add(vectors)scores, indices = index.search(query, k=10)index.write("my_index.tv")上一堂課我們把AI的引擎蓋掀開,看了量化把模型內部數字的精細度降低、讓體積跟著變小的壓縮技巧這類讓AI能塞進手機的工程手法。這一堂課要換個角度,直接看兩個真實案例:一個是一個人在家用MIDI鋼琴做出來的接龍AI,另一個是效能比肩Claude Opus的Ornith-1.5,兩者剛好站在本地化浪潮的兩端,卻通往同一個地方——你手上的裝置。
第一個案例是開發者做的「RollTab」:一台1.25億參數的AI,能即時接續你在鋼琴上彈的旋律,在iPhone 15上每秒能生成約108個音符。它的原始資料是MIDI檔案一種只記錄「哪個琴鍵在什麼時候被按下、力道多大、何時放開」的樂譜格式,不是像MP3那樣直接錄下聲音,光是要讓AI讀懂這種格式,開發者就得先把彈奏拆成一連串事件,再token化把資料切成AI看得懂的小單位,讓模型能一步步預測「接下來會是什麼」。
如果每個音符事件都直接拿「音高×力道」組合成一個token,光是按鍵這一項就有128×128+128=16,512種可能,資料一下子變得又稀疏又難學。開發者後來改用文法規則拆開:先決定是「按下」「放開」還是「經過多久時間」,再各自決定音高、力道、時長,生成時還會強制擋掉不合文法的選項(例如按下之後只能接音高,不能亂跳)。這個做法加上前後總共14次實驗的反覆調整、狠狠清掉非鋼琴音軌的雜訊資料,最後再用DPO(直接偏好優化)讓AI直接從「這個接續版本比較好」的示範裡學習,而不是單純硬記規則做最後微調,才做出聽起來夠自然的接龍效果。
第二個案例站在光譜的另一端。Ornith-1.5是一個開源基礎模型,一口氣推出397B、35B、9B三種規模,設計目標是同時顧到推理、多步驟代理任務跟寫程式。旗艦版397B在Terminal-Bench 2.1拿下86.1分、DeepSWE拿下56.0分,幾乎打平Claude Opus 4.8的85.0分與59.0分,也贏過同量級的GLM-5.2和DeepSeek-V4-Flash-0731。最小的9B版本另外做出一個量化壓縮的「9B-Mobile」版本,可以直接裝進iPhone、Android,實測還贏過參數量更大的Gemma 4-31B、Qwen 3.6-35B。
Ornith-1.5真正的重點不是分數,而是它怎麼練出來的。它不是靠人工整理好的固定題庫,而是啟動一個自我提升迴圈(self-improvement loop)AI自己出題目、自己想辦法搭配解題流程、再用解題過程產生的資料反過來訓練自己進步的機制:模型自己提出比上一輪更難的任務、自己搭建解這道題要用的鷹架,再自己跑出解題過程的資料餵給強化學習讓AI靠「做完拿分數、再依分數調整行為」持續進步的訓練方式。換句話說,連「找什麼題目來練習」這件事,Ornith-1.5都不再假手他人。
把這兩個案例放在一起看,你會發現本地化AI浪潮已經不是實驗室裡的展示品:一個人靠公開的技巧跟一支iPhone就能做出堪用的鋼琴AI;一個對標頂尖商業模型的巨獸,也會特地再壓縮出一個能塞進你口袋的版本。無論你是想自己動手做點小東西,還是只想在手機上用到最新的AI能力,這股浪潮這次是真的走到你手上了。
| 案例 | 模型規模 | 要解決的任務 | 怎麼落地到你的裝置 | 你能不能自己動手做 |
|---|---|---|---|---|
| RollTab | 1.25億參數(125M) | 即時接續你彈的鋼琴,秒接下一段旋律 | 模型本身就做得夠小,直接跑在iPhone上,每秒可生成約108個音符 | 能,是開發者一個人從零打造,資料處理與訓練心得都公開分享 |
| Ornith-1.5 | 397B / 35B / 9B三種規模(MoE與稠密) | 推理、多步驟代理任務、寫程式,效能比肩Claude Opus 4.8 | 9B版本另外做出量化壓縮的Mobile版,可直接裝進iPhone、Android | 難,需要實驗室等級的自我提升訓練迴圈才能練出來,但練好的成果你能直接下載到手機用 |