CPU推論でLLMを動かすアーキテクチャ判断

月額40ドルのVPS（仮想プライベートサーバー）で、APIコストを70%削減できるとしたら、システム設計の選択肢はどう変わるだろうか。4コアのXeon E5-2696 v4と7.8GBのRAMという、ごく標準的なスペックのサーバーでLlama 3.1 8Bを動かし、実際に本番パイプラインへ投入した事例が報告されている。GPU不要のLLM推論（大規模言語モデルの実行処理）が、アーキテクチャの現実的な選択肢になりつつある。

CPU推論が成立する技術的な背景

CPU上でのLLM推論を実用的にしたのは、llama.cppというC/C++製の推論エンジンだ。GitHubで62,000以上のスターを持つこのプロジェクトは、2年間でCPU推論の効率を約10倍改善したとされる。その中心にあるのがGGUF量子化（モデルのパラメータを低ビット精度に圧縮して体積を小さくする手法）だ。

量子化の基本的な考え方は、モデルの重みパラメータを32ビット浮動小数点から4ビット整数などに圧縮することだ。たとえばQ4_K_Mという形式では、Llama 3.1 8BモデルがRAM約5.2GBに収まり、同じモデルをQ8_0（8ビット量子化）で動かす場合の8.1GBより大幅に軽量になる。精度の低下はパープレキシティ（言語モデルの予測精度を示す指標）でおよそ0.5〜1%程度とされ、多くのバッチ処理タスクでは許容範囲に収まる。

ボトルネックの構造も重要な設計判断材料になる。GPU推論では演算性能（FLOPS）が律速になるのに対し、CPU推論ではメモリ帯域幅とRAM容量がボトルネックになる。そのため、コア数よりもメモリの実装量と帯域幅の方が、実効スループットに対する影響が大きい。

3つのデプロイパターンとそのトレードオフ

同事例では、用途に応じた3つのアーキテクチャパターンが示されている。

1つ目は純粋なCPU量子化推論だ。Mistral 7B Q4_K_Mで毎秒4.5トークンが出るとされ、コード生成やテキスト分類、データ抽出といったバッチ処理に対応できる。GPUへの依存が一切なく、任意のVPSで動作するため、インフラの可搬性が最大になる。

2つ目は投機的デコーディング（Speculative Decoding）を使った高速化だ。小さなドラフトモデルがトークンを先読み生成し、メインモデルがそれを検証するという仕組みで、llama.cppのv3600以降で利用できる。速度は3.2トークン/秒から4.5トークン/秒へと約40%向上するが、ドラフトモデル分のRAMが約0.8GB追加で必要になる。空きメモリとのトレードオフを確認してから採用を判断すべきパターンだ。

3つ目はハイブリッドアーキテクチャ（ローカルCPU推論と外部APIの組み合わせ）だ。これが本番環境で最も現実的な構成といえる。

def infer(prompt, timeout=120):
    result = local_llm.infer(prompt, timeout=timeout)
    if result.timed_out or result.quality < 0.6:
        result = api_llm.infer(prompt)
    return result

上記のように、ローカル推論が一定品質を下回るか、タイムアウトが発生した場合にのみAPIへフォールバック（代替手段への切り替え）する設計だ。報告された3か月間の本番稼働では、リクエストの70%がローカルで処理され、月額のAPIコストが約120ドルから約35ドルに減少した。

設計判断として押さえるべきポイント

この事例から導き出せる設計上の判断軸を整理すると、以下のようになる。

量子化形式はQ4_K_Mを基準に選ぶ。RAMが潤沢でも、Q8_0はスワップ（RAMが不足した際にディスクを一時的なメモリ代わりに使う処理）を誘発しやすく、スループットが大幅に落ちる
スレッド数はコア数マイナス1が実測で最適とされる。コアをフル使用するとハイパースレッディング競合が起き、速度が10〜15%低下する
コンテキストウィンドウ（一度に処理できるトークン数）は4096を上限として運用する。8192に拡張するとメモリが倍になり、速度も約30%低下する
KVキャッシュ（過去の計算結果を再利用する仕組み）の手動管理を活用すると、類似プロンプトが多いパイプラインで計算量を40〜60%節減できる

アーキテクチャ選定の視点では、CPU推論は「常時GPUを必要としないワークロード」に対して有効な選択肢となる。リアルタイム応答が不要なバッチ処理、社内ツール、コスト上限が厳しいプロジェクトがその典型だ。一方で、毎秒4〜5トークン程度の速度はインタラクティブなチャットUIには厳しく、用途によってはGPUインスタンスや外部APIの方が合理的になる。

比較対象として、同カテゴリのツールにはOllama（Goで実装されたGGUFベースの推論サーバー）やvLLM（Pythonベースで主にGPU向けだが実験的なCPUサポートあり）がある。手軽さではOllamaが優れているが、パラメータの細かい制御や量子化形式の選択ではllama.cppが柔軟だ。本番投入を前提にするなら、llama.cppをベースにして監視・フォールバック設計を加える構成が、現時点では安定性の面で有利といえる。

CPU推論の現実的な位置づけは「GPUを補完する選択肢」だ。全ての推論をローカルCPUで賄うことが目的ではなく、コストと品質のバランスをワークロードごとに切り替えられる設計を持てるかどうかが、実際の運用で意味を持つ。