PowerInfer: 活性の局所性でCPUとGPUを分業させるローカル推論エンジン
High-speed Large Language Model Serving for Local Deployment
ひと目でわかる
- これは何？
- PowerInferは、ニューロン活性がべき乗則に従うという観察を出発点に、よく使われるhotニューロンをGPUに、coldニューロンをCPUに割り当てる推論エンジンである。MITライセンスのC++実装で、対応モデルとハードウェアの範囲はREADMEに明示されている。
- 誰に向いている？
- ReLU系のスパースモデル（Falcon-40B、ProSparse Llama2、Bamboo-7Bなど）を、AVX2対応x86-64 CPUと単一のコンシューマGPUで動かしたい場合、PowerInferは検討に値する。逆に、denseなモデルやGGUF形式の量子化モデルをそのまま高速化したいのであれば、README自身が「llama.cppの重みでは性能向上はない」と書いている通り、目的に合わない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 128 日前です。
- 何の言語で書かれている？
- 主に C++ です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
このエンジンが埋めようとしている穴
コンシューマ向けGPUを1枚積んだPCでLLMを動かそうとすると、まずVRAMの壁に当たる。70B級のモデルをFP16で載せようとすれば、24GBのGPUでは足りない。量子化すれば載るが、精度とのトレードオフが発生する。PowerInferが狙うのはこの隙間である。READMEの要約によれば、同プロジェクトは「アクティベーションの局所性」を利用するCPU/GPUハイブリッド推論エンジンであり、対象は単一のコンシューマGPUを搭載したPCである。想定読者は、サーバ機材を用意せずに手元のマシンでモデルを動かしたい開発者、あるいはローカル推論のレイテンシを測りたい評価者だ。クラウドAPIの代替というより、機材の制約下でどこまで速度を引き出せるかに関心がある層に向く。
hotとcoldを分けるという発想
PowerInferの中心にあるのは、ニューロンの活性がべき乗則に従うという観察である。READMEのAbstractでは、入力によらず一貫して活性化する少数のニューロンをhot、入力ごとに変わる多数をcoldと呼び、この分布を前提に設計すると説明されている。実装上の分岐は明快で、hotニューロンはGPUに事前ロードして高速にアクセスし、coldニューロンはCPU側で計算する。これによりGPUメモリの要求量とCPU-GPU間のデータ転送を抑える。加えてadaptive predictorsとneuron-aware sparse operatorsを組み合わせ、活性と計算のスパース性を扱う。ここで注意したいのは、この分業が成立する前提である。活性がべき乗則に従わないモデル、つまりdenseなモデルではhotとcoldの切り分けが意味を持たず、CPU側に落とす計算量が増えて逆効果になりうる。READMEが対応モデルとしてFalcon-40B、Llama2系、ProSparse Llama2系、Bamboo-7Bを挙げ、ReLUスパース系のモデルへのリンクを示しているのは、この前提を満たすモデルが限られるためだ。
llama.cppとの互換性はどこまで効くか
PowerInferはllama.cppとは別実装だが、READMEは後方互換について踏み込んだ記述をしている。examples/配下の多くをllama.cppと同じように使えるとされ、serverやバッチ生成がその例として挙げられている。さらにllama.cppのモデル重みでの推論もサポートする。ただし、その直後に「性能向上はない」と明記されている点が重要である。つまり互換レイヤは移行の摩擦を下げるためのもので、速度面の利点はスパースモデルを使ったときに初めて現れる。この一文は、PowerInferを「llama.cppの高速版」と誤解して導入しようとする読者に対する、事実上の警告として読める。既存のGGUFワークフローをそのまま持ち込んでも、期待した加速は得られない。
ビルドとモデル配置の実際
入手経路はソースからのビルドである。READMEのSetup and Installationは、依存としてCMakeを挙げ、以降でインストール手順、モデル重み、推論の3段階に分けて案内する構成になっている。前提条件として明示されているのは、AVX2命令を備えたx86-64 CPUだ。GPUは必須ではなく、NVIDIA GPUの有無にかかわらずLinuxとWindowsで動作するとREADMEは述べている。Apple MチップはmacOSでCPUのみの対応となる。対応プラットフォームの記述はこの3系統に限られており、ARMサーバやその他のアクセラレータについては言及がない。AMDデバイス向けのROCmサポートは2024年5月のニュース項目として追加されている。提供されているモデル群はHugging Face上のPowerInfer組織やSparseLLM配下にあり、TurboSparse-MixtralやSmallThinkerといった派生も同じ系列で公開されている。
向かない場面と、代わりに選ぶもの
最も分かりやすい不向きな用途は、denseモデルをそのまま速くしたい場合である。前述の通り、llama.cppの重みを使えば互換動作はするが性能向上はない。もうひとつの制約はプラットフォームだ。macOSはCPUのみで、README自身が「Mac向けに最適化していないため性能改善は現時点で大きくない」と書いている。Metalバックエンドは「近日公開」としてカンバンに記載されている段階で、現行版では使えない。比較対象としてllama.cppを挙げるなら、違いは明確である。llama.cppは量子化によってモデルをGPUに収める方向でメモリ問題を解くのに対し、PowerInferはモデル構造のスパース性に依存して計算そのものをCPUとGPUに振り分ける。前者はモデルの選び方を問わないが、後者はReLUスパース系という条件を満たす必要がある。汎用性を取るか、条件を満たした上での速度を取るかの選択になる。
数字の出所と、測っていないことの扱い
READMEには具体的な数値が並ぶ。RTX 4090上でFalcon(ReLU)-40B-FP16を動かした比較でllama.cppに対して最大11.69倍、Abstractでは複数モデルにわたり平均13.20トークン毎秒、ピーク29.08トークン毎秒、A100比で18%低いという値が示されている。これらはプロジェクト側が公表した測定結果であり、本稿が独自に再現したものではない。同じハードウェアで両者を走らせ、VRAMを fully に使ったという注記が付いているが、測定条件の詳細はこの材料からは確認できない。導入判断に使うなら、自分のモデルと機材で測り直す必要がある。READMEが示す数値はあくまで著者らの環境における結果である。
ライセンスと保守の見取り図
ライセンスはMITで、リポジトリのバッジにもその旨が表示されている。MITは商用利用を含めて制約が少ない部類に入るが、同梱モデルの重みは別ライセンスであり、PowerInfer本体のMITがモデルの利用条件を左右するわけではない。モデルごとの条件は配布元で確認する必要がある。保守面では、更新の中心が研究発表とモデル公開に置かれている点を押さえておきたい。PowerInfer-2はスマートフォン向け、TurboSparseはモデルのスパース化、SmallThinkerはオンデバイス推論フレームワークと、関心の対象が広がっている。開発の現在の焦点はプロジェクトのカンバンに集約されており、機能追加の予定を確認する場所としてREADMEが案内している。リリースは取得できておらず、バージョン番号に基づくアップグレード計画は立てにくい。追従するならmainブランチの更新を追う形になる。
編集部の結論
ReLU系のスパースモデル（Falcon-40B、ProSparse Llama2、Bamboo-7Bなど）を、AVX2対応x86-64 CPUと単一のコンシューマGPUで動かしたい場合、PowerInferは検討に値する。逆に、denseなモデルやGGUF形式の量子化モデルをそのまま高速化したいのであれば、README自身が「llama.cppの重みでは性能向上はない」と書いている通り、目的に合わない。導入前に確認すべきは、手持ちのモデルがReLUスパース系かどうか、そしてCPUがAVX2を備えているかである。macOSのApple MチップはCPUのみの対応で、READMEも「最適化していないため性能改善は大きくない」と明記している。
コミュニティノート