AI 的模型壓縮：為什麼手機也能跑 AI
量化（Quantization）：從 FP32 到 INT4
量化是把模型參數與啟動值（activation）從高精度浮點數，轉換成低位元整數的過程。最常見的路径是 FP32 → FP16 → INT8 → INT4。它的原理並不複雜：神經網路的權重分佈通常集中在某個區間，只要找到合適的縮放因子（scale）與零點（zero point），就能用整數近似浮點數，同時把誤差控制在可接受範圍。
量化的效益非常直接。一個 7B 模型從 FP16（14 GB）壓到 INT4（約 3.5～4 GB），體積縮小四倍，記憶體頻寬需求也同步下降四倍——這往往就是「能不能跑得動」的分水嶺。實務上又分為兩條路線：訓練後量化（Post-Training Quantization, PTQ）不需重新訓練，成本低、速度快，適合 INT8；量化感知訓練（Quantization-Aware Training, QAT）則在訓練時就模擬量化誤差，能支撐到 INT4 甚至更低，但需要原始訓練流程與資料。
精度格式
每參數位元
7B 模型約略大小
常見用途
FP32
32 bit
約 28 GB
訓練、雲端高精度推論
FP16 / BF16
16 bit
約 14 GB
雲端推論、GPU 加速
INT8
8 bit
約 7 GB
桌機、筆電、部分旗艦手機
INT4
4 bit
約 3.5～4 GB
手機端 LLM、嵌入式裝置
近年還出現了更激進的方向，例如 1.58 位元的三元量化（BitNet 系列），把權重限制在 -1、0、1 三個值，理論上能把矩陣乘法簡化成加法與位移。這類研究目前仍在早期階段，但它揭示了量化的極限遠比我們想像的更深。
剪枝（Pruning）：剪掉不重要的神經元
剪枝的概念來自一個觀察：訓練完成的神經網路往往過度參數化（over-parameterized），裡面有大量權重接近於零、對輸出幾乎沒有貢獻。剪枝的做法就是把這些「多餘」的連結或通道移除，讓模型變得更稀疏、更精簡。
剪枝分為非結構化與結構化兩類。非結構化剪枝把個別權重設為零，壓縮率高，但產生的稀疏矩陣在一般硬體上不一定跑得快，需要有稀疏加速支援。結構化剪枝則是整條通道、整個注意力頭（attention head）或整層移除，雖然壓縮率較保守，但能真正縮小矩陣維度，對行動裝置更友善。另一個有趣的理論是「樂透假說」（Lottery Ticket Hypothesis）：一個隨機初始化的網路中，存在一個子網路，只要單獨訓練就能達到接近完整網路的表現。這暗示了大型模型中可能存在大量「冗員」。
知識蒸餾（Knowledge Distillation）：大模型教小模型
如果說量化與剪枝是「把大模型變小」，知識蒸餾就是「讓小模型學會大模型的本領」。做法是準備一個已經訓練好的大型「教師模型」，以及一個參數量少得多的「學生模型」，讓學生模型不僅學習真實標籤，還要模仿教師模型輸出的機率分佈（軟標籤，soft label）。
為什麼軟標籤有用？因為教師模型的輸出包含了類別之間的相似性資訊。例如在手寫數字辨識中，一個「7」被教師模型判定為「7 的機率 0.9、1 的機率 0.08」，這種「看起來像 1」的資訊，是 one-hot 標籤無法提供的。學生模型透過學習這些細緻的分佈，往往能在同樣的參數量下，取得比直接訓練更好的泛化能力。蒸餾也是現代小型語言模型（如各種 1B～3B 版本）能夠追上大模型部分能力的關鍵原因之一。
低秩分解（Low-Rank Factorization）：用更少的參數表達同樣的訊息
低秩分解背後的數學假設是：大型權重矩陣往往是「低秩」的，也就是說，它的大部分資訊可以壓縮到少數幾個維度上。透過奇異值分解（SVD）等手法，一個 m×n 的矩陣可以近似成兩個較小的矩陣相乘，參數量從 m×n 降到 m×r + r×n（其中 r 遠小於 m、n）。
這個思路在近年衍生出一個非常熱門的應用：LoRA（Low-Rank Adaptation）。LoRA 不改變原始模型權重，而是在旁邊加上兩個低秩矩陣作為「微調補丁」，讓開發者可以用極少的參數與記憶體，把通用模型客製化成特定領域的助手。這對裝置端 AI 特別重要——因為它意味著手機上的模型可以透過小型補丁持續進化，而不必重新下載整個模型。
三、手機端跑 AI 的硬體與軟體生態
演算法壓縮只是其中一半的故事。如果沒有對應的硬體與軟體支援，壓縮後的模型依然跑不動。幸運的是，過去五年手機晶片與推論框架的進步，正好與模型壓縮技術形成了完美的配合。
NPU 崛起：手機晶片裡的 AI 引擎
現代行動晶片早已不是單純的 CPU + GPU 組合。Apple 的 A 系列與 M 系列晶片內建 Neural Engine，高通 Snapdragon 有 Hexagon NPU，聯發科天璣系列有 APU，Google Tensor 則有專屬的 TPU 單元。這些 NPU 的設計目標非常明確：以極低的功耗執行大量的矩陣乘法與卷積運算。
NPU 的關鍵優勢在於「每瓦效能」。CPU 通用性強但效率低，GPU 平行能力好但耗電，NPU 則是為神經網路量身打造，常常能在不到 1 瓦的功耗下提供數十 TOPS 的算力。對於手機這種靠電池運作的裝置，這幾乎是唯一的答案。此外，NPU 通常支援 INT8 甚至 INT4 的原生運算，與量化技術相輔相成。
行動端推論框架：TensorFlow Lite、ONNX Runtime、Core ML、NCNN
硬體之下，還需要軟體框架把模型「翻譯」成硬體看得懂的指令。目前主流的選擇包括：Google 的 TensorFlow Lite（現已整合進 LiteRT）與 MediaPipe，跨平台的 ONNX Runtime Mobile，Apple 的 Core ML，以及開源社群常用的 NCNN、MNN 與 llama.cpp。這些框架負責模型格式轉換、算子融合、記憶體規劃，並在執行時自動選擇最適合的後端（CPU、GPU 或 NPU）。
以 Core ML 為例，它會把模型編譯成 Apple 晶片專屬的中間表示，並盡可能把運算卸載到 Neural Engine。而 llama.cpp 則以高度優化的量化核心聞名，能在多種裝置上執行 4-bit 量化的語言模型，是許多手機端 LLM 實驗的起點。框架的成熟，大幅降低了開發者「把模型搬上手機」的門檻。
記憶體頻寬才是真正的瓶頸
很多人以為手機跑不動 AI 是因為「算力不夠」，但實際測試往往顯示，真正的瓶頸是記憶體頻寬。前面提過，生成式模型每產生一個 token，都要把整個模型權重讀取一次。對一個 INT4 量化的 3B 模型來說，權重約 1.5～2 GB，若每秒要產生 10 個 token，就需要 15～20 GB/s 的持續頻寬——這已經逼近中階手機的極限。
這也解釋了為什麼量化對手機 LLM 如此關鍵：它同時解決了「裝不下」與「搬太慢」兩個問題。相對地，影像辨識、語音喚醒這類模型較小、計算密集的任務，則更仰賴 NPU 的算力。不同的 AI 應用，瓶頸位置不同，優化策略也必須跟著調整。
四、模型壓縮的實務流程與常見陷阱
理論講起來漂亮，實際動手卻常常踩坑。模型壓縮最大的風險，是「壓過頭」導致精度崩壞，或是壓縮後的模型在特定硬體上根本沒有加速效果。以下整理實務上最常遇到的流程與陷阱。
從訓練到部署的壓縮管線
一個典型的壓縮管線大致長這樣：首先訓練或取得一個基準模型，並建立完整的評估集與指標；接著進行敏感度分析，找出哪些層對量化或剪枝特別敏感；然後依序套用量化、剪枝、蒸餾等技術，每一步都重新評估精度；最後匯出成目標框架的格式，在真實裝置上測量延遲、記憶體與功耗。
順序很重要。常見的做法是先蒸餾（得到較小的學生模型），再剪枝（移除冗餘結構），最後量化（降低位元數）。如果把量化放在最前面，後續的訓練與微調會變得非常困難，因為低位元的數值表示不利於梯度更新。此外，評估不能只看整體準確率，還要看長尾案例、特定語言、特定雜訊條件下的表現。
壓縮後精度掉太多怎麼辦？混合精度與敏感層保護
如果量化後精度明顯下降，第一個手段是「混合精度」：把大部分層壓到 INT4，但保留少數敏感層（例如第一層、最後一層、注意力輸出層）為 INT8 或 FP16。經驗顯示，這種選擇性保護往往能用很小的體積代價，換回大部分的精度。
第二個手段是「分組量化」與「更好的校正資料」。同一層內若權重分佈差異大，可以切成多個群組各自縮放（group-wise quantization），減少離群值造成的誤差。第三個手段則是回頭做少量微調（例如 QLoRA），讓模型適應量化後的數值環境。實務上，4-bit 量化對多數語言模型只會造成極小的品質損失，但對數學推理、程式碼生成這類需要精確性的任務，影響會比較明顯，需要特別驗證。
五、實際案例：手機上的 AI 應用
講了這麼多技術，回到使用者最有感的問題：手機上到底跑得動哪些 AI？答案是——比你想像的多很多，而且很多你早就在用了。
語音助理與即時翻譯
「Hey Siri」、「OK Google」這類喚醒詞偵測，多年來一直是在裝置端執行的。它需要一個極小的模型持續監聽麥克風輸入，功耗必須低到不影響待機時間。這類模型經過大量壓縮與蒸餾，參數量可能只有幾十萬到幾百萬，卻能在嘈雜環境中維持可用的準確率。
即時語音轉文字與翻譯，則是近幾年的新戰場。Google 的 Pixel 系列與 Apple 的 iOS 都已經支援離線語音輸入與部分語言的即時翻譯。這背後是壓縮後的語音辨識模型加上輕量化翻譯模型，在 NPU 上協同運作。離線執行的好處不只是速度，更是在沒有網路、或是對隱私極度敏感的場景下，依然能提供服務。
影像處理：夜景模式、人像分割、即時去背
手機攝影是模型壓縮最成功的商業案例之一。夜景模式需要在一瞬間完成多幀對齊、降噪、HDR 合成與色彩還原；人像模式需要精準分割人物與背景；視訊通話的去背與美顏，更是每秒要處理數十幀。這些任務對延遲極度敏感，不可能送到雲端，只能靠裝置端的輕量模型即時完成。
這些模型通常採用「小而專」的設計：針對單一任務、使用深度可分離卷積（depthwise separable convolution）等高效結構、再經過 INT8 量化與通道剪枝。它們的參數量可能只有幾百萬，卻能在專用 NPU 上達到每秒數十幀的處理速度。這正是「壓縮＋專用硬體」組合威力的最佳展示。
手機端 LLM：3B、7B 模型的落地
2024 年之後，手機端語言模型開始成為現實。Google 在 Pixel 上展示了 Gemini Nano，Apple 在 iOS 18 中導入 Apple Intelligence 的裝置端模型，高通與聯發科則積極展示在旗艦晶片上執行 3B～7B 量化模型的能力。這些模型多半採用 4-bit 量化，並針對行動晶片的記憶體階層做了大量優化。
目前手機端 LLM 的能力邊界大致是：文字摘要、改寫、分類、簡單問答、裝置內指令控制（例如「幫我把這張照片設為桌布」）。它們還不適合處理複雜推理或長篇生成，但對於「不該上雲」的日常任務，已經足夠好用。隨著模型架構（如混合專家 MoE、狀態空間模型）與硬體的同步演進，這條邊界只會不斷往外推。
六、未來趨勢與挑戰
模型壓縮不是終點，而是一條持續演進的路。未來的發展，大致可以從三個方向觀察。
硬體與演算法共同設計
過去演算法與硬體是分開發展的：模型訓練好之後，再想辦法塞進硬體。現在越來越多的研究採取「共同設計」（co-design）的思路——在設計模型架構時，就考慮目標硬體的記憶體階層、算子支援與量化特性。例如 MobileNet 系列就是為行動裝置量身打造的架構，而新一代的 NPU 也開始針對 Transformer 的注意力機制提供專門的加速單元。
這種協同設計能帶來遠超單點優化的效益。當模型知道硬體擅長什麼、硬體知道模型需要什麼，壓縮的空間與效率都會大幅提升。
壓縮的極限在哪裡？
壓縮終究有極限。過度量化會讓模型失去推理能力，過度剪枝會讓模型遺忘罕見但重要的知識，知識蒸餾再怎麼做，學生也很難完全複製教師的能力。目前的共識是：壓縮能保留模型的「知識」，但對於需要多步驟推理、長上下文理解的能力，損失會比較明顯。
另一個挑戰是評估。一個壓縮後的模型在標準基準測試上可能只掉了 1～2 分，但在真實使用中卻可能出現明顯的退化，例如回答變得模板化、對指令的遵循度下降。如何建立更貼近實際使用情境的評估方法，是這個領域亟待解決的問題。
對開發者與使用者的意義
對開發者而言，模型壓縮意味著 AI 應用的門檻正在下降。你不再需要昂貴的 GPU 叢集才能提供 AI 服務，一支手機、一台筆電就能承載完整的推論流程。這會催生出更多強調隱私、離線可用、低延遲的應用形態，例如個人化的健康助理、完全離線的寫作工具、不需要網路的學習輔具。
對使用者而言，最直接的感受是：AI 變得更快、更私密、更隨時可用。你不再需要擔心照片上傳到哪裡、語音被誰錄下，也不必因為網路不穩而看著轉圈圈。當然，這也帶來新的課題——裝置端模型的品質參差不齊、更新機制不如雲端即時，以及「哪些資料留在本機」的透明度問題，都需要產品設計者誠實面對。
七、結語：壓縮，讓 AI 真正走進日常
回顧整個脈絡，手機能跑 AI 這件事，本質上是一場「效率革命」。模型壓縮透過量化、剪枝、知識蒸餾與低秩分解，把原本需要資料中心才能承載的運算，壓縮到一顆指甲大小的晶片上；而 NPU 與行動推論框架的成熟，則提供了讓這些壓縮模型真正跑起來的舞台。兩者缺一不可。
更值得關注的是，這場革命改變的不只是技術參數，而是 AI 與人的關係。當模型不再住在遙遠的雲端，而是住在你的口袋裡，AI 就從一種「服務」變成一種「能力」——一種隨時隨地、不需連線、不必出賣隱私就能使用的能力。這才是「手機也能跑 AI」真正重要的意義。
如果你也對裝置端 AI、模型壓縮或邊緣運算有興趣，歡迎在雅寶社區 · 頂客論壇的 AI 趨勢版繼續交流。無論你是想在自己的手機上跑一個量化模型，還是想討論壓縮技術的取捨，這裡都有一群同樣熱愛折騰的人，等著跟你一起把模型塞進更小的盒子裡。
```