PowerInfer：把熱神經元放進 GPU、冷神經元丟給 CPU 的本地推論引擎

它解決的是 VRAM 不夠、又不想整顆模型塞進 CPU 的處境

單張消費級 GPU 的 VRAM 通常落在 24GB 上下，而 40B 級別的 FP16 權重遠超這個數字。常見的兩條路都不理想：全部放 CPU，速度慢；全部想辦法塞進 GPU，就得量化到犧牲精度，或直接放棄。PowerInfer 走的是第三條路，把模型按神經元切成兩群，各自放到最適合的裝置上。

它的目標讀者很明確：在個人電腦上做本地推論、手上有 NVIDIA 消費卡、而且願意配合特定模型格式的人。README 的摘要寫得很直接，這是一台配備單張消費級 GPU 的個人電腦上的高速推論引擎。它不是雲端服務框架，也不是多卡分散式方案，設計起點就是「一張卡」。

活化局部性：熱神經元與冷神經元的分工依據

整個設計建立在一個觀察上：LLM 推論時的神經元活化呈現冪律分布。少數神經元在多數輸入下都會被觸發，README 稱之為 hot neurons；其餘多數則隨輸入而異，稱為 cold neurons。

分工於是變得自然。熱神經元被預先載入 GPU，推論時直接取用；冷神經元留在 CPU 上計算。這樣做的效果是雙重的：GPU 記憶體需求下降，因為不必容納全部權重；CPU 與 GPU 之間的資料搬移也減少，因為常態性被觸發的那部分不需要來回傳。

README 另外提到兩個配套元件：adaptive predictors 與 neuron-aware sparse operators。前者負責預測哪些神經元會被活化，後者負責在稀疏條件下有效率地執行運算。這兩者不是裝飾，而是讓「只算該算的」這件事在實際執行時站得住腳的關鍵。少了預測，稀疏性就只是靜態事實，無法轉成執行期的節省。

稀疏不是選項，是入場門檻

這是整篇文章最需要讀者留意的一點。PowerInfer 的加速來自活化稀疏，而活化稀疏來自模型本身的 ReLU 結構。README 列出的可用模型是 Falcon-40B、Llama2 家族、ProSparse Llama2 家族與 Bamboo-7B。其中 ProSparse Llama2 被描述為約 90% 稀疏率的 ReLU 模型，並稱其表現可對齊原始 Llama 2。

換句話說，這不是一個「裝好就能加速任何模型」的引擎。README 在向後相容那一段寫得相當坦白：PowerInfer 支援以 llama.cpp 的模型權重做推論以維持相容性，但不會有效能增益。這句話值得反覆讀。它意味著如果你手上是一般的稠密 GGUF 權重，你得到的是相容性，不是速度。

社群這邊也有相應的產出。TurboSparse 系列把 Mistral 與 Mixtral 稀疏化到接近 90%，README 稱 Mixtral 級別的模型只活化約 4B 參數。這條路線的意義在於：想要 PowerInfer 的加速，往往得先接受它的模型生態，而不是反過來。

建置與啟動：從 CMake 到 server 的實際路徑

前置條件在 README 的 Pre-requisites 段落列出，第一項是 CMake。後續內容在提供的材料中被截斷，因此完整的建置指令、具體的 cmake 旗標與相依套件清單無法從這裡確認，需要讀者自行到 repository 的 Setup and Installation 章節對照。這一點必須說清楚，不應該靠推測補齊。

可以確認的是啟動路徑。README 的 Getting Started 分成三段：Installation、Model Weights、Inference，模型權重是獨立的一步，不是安裝完就自動具備。它同時指出 examples/ 目錄下的用法與 llama.cpp 大致相同，包括 server 與 batched generation，這對已經熟悉 llama.cpp 工作流程的人來說，遷移成本主要落在模型轉換與權重準備，而不是服務介面的重新學習。

平台支援方面，README 列出已測試的組合：Linux 與 Windows 上的 x86-64 CPU 搭配 AVX2 指令集，有或沒有 NVIDIA GPU 皆可；macOS 上的 Apple M 系列晶片僅支援 CPU。文中明說對 Mac 沒有做最佳化，目前的效能提升並不顯著。macOS 的 Metal 稀疏推論後端被列在「即將推出」而非現況。AMD 裝置的 ROCm 支援在 2024 年 5 月加入，這點在版本歷程中有記載。

冷神經元走 CPU 的代價，與 Mac 上的尷尬位置

把冷神經元交給 CPU 並非免費。這部分的計算速度取決於 CPU 與記憶體頻寬，而冷神經元雖然個別不常被觸發，總量卻是模型的多數。當輸入恰好落在不常見的活化模式上，或者任務本身讓活化分布偏離訓練時觀察到的冪律，CPU 這一側就會成為瓶頸。這是混合架構的固有取捨，不是可以靠調參消除的東西。

Mac 的處境更直接。README 把 Apple M 晶片的支援定位為 CPU only，並且明言沒有針對 Mac 最佳化、目前改善不顯著。對於期待在 M 系列晶片上得到類似 RTX 4090 效果的人，這是一條明確的否定線。Metal 後端還在待辦清單上，不是現在能用的東西。

另一類不適用的情境是稠密模型。若你的模型沒有 ReLU 稀疏結構，熱冷分離就失去依據，整個設計的前提不成立。此時 PowerInfer 不會比一般推論引擎快，只會多一層模型轉換的麻煩。

與 llama.cpp 的差異不只在速度數字

README 的展示段落描述了一個對照：在單張 RTX 4090（24G）上跑 Falcon(ReLU)-40B-FP16，PowerInfer 相對 llama.cpp 有 11 倍加速，並註明兩者跑在同一硬體、都充分利用了 VRAM。摘要段落則給出平均 13.20 tokens/s、峰值 29.08 tokens/s 的數字，並稱與伺服器級 A100 相比只低約 18%。這些數字來自專案自身的評估，不是第三方複現結果，閱讀時應當這樣理解。

真正的方法差異在於：llama.cpp 是以通用推論為目標，盡可能支援多種模型格式與量化方案，並透過 CPU 與 GPU 的層切分來分配工作；PowerInfer 則把分配粒度下沉到神經元層級，前提是模型具備可被利用的活化稀疏。前者換來的是通用性，後者換來的是在特定模型上的速度。

這也解釋了為什麼 PowerInfer 選擇相容 llama.cpp 的權重。相容性是為了降低嘗試門檻，不是為了取代 llama.cpp 的定位。兩者在多數情況下是互補而非競爭：先確認模型是否落在稀疏那一側，再決定用哪一個。

授權、維護與版本狀態

專案採用 MIT 授權，這對商業整合相對寬鬆。不過授權只涵蓋程式碼本身，模型權重各自有各自的授權條款，Falcon、Llama2、ProSparse 與 Bamboo 系列並不統一，實際部署前需要逐一確認，這裡不提供法律意見。

維護節奏方面，從 README 的版本歷程可以看到專案持續有動作：2023 年 12 月正式釋出，2024 年陸續加入 Windows GPU 推論、ProSparse Llama2 支援、ROCm 支援，並在 6 月發表 PowerInfer-2 與 TurboSparse；2025 年 7 月釋出 SmallThinker 系列模型與對應的裝置端推論框架；2026 年 1 月則有 Tiiny AI Pocket Lab 的發表訊息。專案另設有 Kanban 看板，README 請讀者參考該看板了解當前開發重點。

需要留意的是，這份材料沒有檢索到任何正式 release 條目。這代表版本管理可能以分支為主，升級時缺乏明確的版本號可對照。對於要把 PowerInfer 放進長期維護流程的團隊，這是一個需要在導入前確認的實際問題：你要追的是 main 分支的哪個時點，以及如何鎖定它。

編輯結論

如果你的模型是 Falcon-40B、Llama2 系列、ProSparse Llama2 或 Bamboo-7B 這類 ReLU 稀疏權重，而且手上只有一張消費級 GPU，PowerInfer 的 CPU/GPU 分工值得實測；若你要跑的是稠密模型或通用 GGUF 權重，README 已明說用 llama.cpp 權重推論不會有加速效果，此時改用 llama.cpp 反而少一層轉換成本。動手前先確認三件事：模型是否在支援清單內、CPU 是否具備 AVX2、以及你的平台是否落在 Linux、Windows 或 macOS 這三個已測過的組合中。

官方來源

1. Issues
2. License: MIT
3. README
4. Tiiny-AI/PowerInfer on GitHub