CPU cores

概要

CPU cores（CPUコア）は、CPU上に搭載された物理演算コアの数を指します。ローカルLLM運用においては、GPUがAI計算の主力を担う構成であっても、CPUは前処理（トークン化）、メモリ管理、ストレージI/O、システム制御を常時担当しており、システム全体の安定性と効率性を支える重要なコンポーネントです。

GPUを搭載しない、またはVRAM容量が不足する環境では、CPUコアが推論そのものを直接実行する「CPU推論」を担うことになります。この場合、物理コア数・論理スレッド数（ハイパースレッディング/SMT）・SIMD命令拡張（AVX2、AVX-512、AMX等）の有無が推論速度を大きく左右します。

特に大規模モデルや複数モデル同時実行、量子化モデルのCPU推論では、十分なCPUコア数とメモリ帯域幅、クロック性能が全体のパフォーマンスを左右します。「コア数が多いほど常に速い」わけではなく、メモリ帯域幅とのバランスが取れて初めてコア数の恩恵が生きる点に注意が必要です。

ローカルLLMにおけるCPUの役割

主要な処理内容

• 前処理・後処理: トークン化、デトークン化
• メモリ管理: RAM-VRAM間データ転送
• モデル読み込み: ファイルI/O、初期化処理
• システム制御: プロセス管理、スケジューリング
• CPU推論: 小規模モデルの直接実行

GPU連携での重要性

• データパイプライン: GPU待機時間の最小化
• 並列処理: バックグラウンドタスクの実行
• メモリオフロード: VRAM不足時の補完
• マルチモデル: 複数AI処理の並行実行

推奨CPU構成

エントリーレベル

ミドルレンジ

ハイエンド

CPU推論の活用

軽量モデルでのCPU推論

# llama.cppでのCPU推論
./main -m models/llama-2-7b-chat.q4_0.gguf \
       -p "User: Hello!" \
       -t 8 \    # CPU threads指定
       -c 2048   # context length

# CPUコア数を活用
export OMP_NUM_THREADS=16  # OpenMP threads
export MKL_NUM_THREADS=16  # Intel MKL threads

PyTorchでのCPU使用

# CPU推論の設定
import torch
torch.set_num_threads(16)  # PyTorchスレッド数

# CPU-GPU分散処理
device_map = {
    "model.embed_tokens": "cpu",
    "model.layers.0": "cuda:0",
    "model.layers.1": "cuda:0",
    # ... 層の分散配置
    "lm_head": "cpu"
}

model = AutoModelForCausalLM.from_pretrained(
    model_name,
    device_map=device_map,
    torch_dtype=torch.float16
)

モデルサイズ・量子化とCPU推論速度の目安

CPUコアだけで推論する場合、モデルサイズと量子化レベルの組み合わせによって必要メモリ量と体感速度が大きく変わります。GPU環境で語られる「VRAM要件」は、CPU推論では「RAM要件」に読み替えられますが、考え方は同じです。以下はllama.cpp（GGUF形式）での一般的な目安です。

数値はCPUの世代・メモリ帯域幅・スレッド設定により大きく変動するため、あくまで目安として捉えてください。一般に、4bit量子化（Q4_K_M等）はモデルサイズを元のfp16比で約4分の1に圧縮でき、精度低下を抑えつつCPUメモリに収める現実的な選択肢として広く使われています。8bit（Q8_0）は精度を優先する場合の選択肢ですが、メモリ使用量と処理量が増える分、tokens/秒は低下する傾向があります。

実務上の目安として、「1-3 tokens/秒」は人が読むには遅く感じられるライン、「8-15 tokens/秒」でようやくチャット用途として実用的、「15 tokens/秒以上」で快適という体感になることが多いです。CPU推論だけで快適な速度を狙う場合は、7-13B級かつ4bit量子化が現実的な落としどころになります。

主要ツールのCPU対応状況

メリット・デメリット

CPU推論・CPUコア活用のメリット

• 追加投資が不要: 既存PCにGPUがなくても、そのCPUだけで小〜中規模モデルを動かせる
• VRAM容量の制約を受けない: システムRAMは一般にGPUのVRAMより大容量・安価に増設しやすく、大きめのモデルもRAMさえあれば読み込める
• 消費電力・発熱が相対的に低い: 高性能GPUをフル稼働させるのに比べ、電力コストや排熱対策の負担が軽い
• 安定性が高い: GPUドライバやCUDA/ROCmのバージョン依存問題に悩まされにくく、環境構築がシンプル
• バッチ処理・非対話用途と相性が良い: 即時応答が不要なバッチ推論やドキュメント要約のキュー処理では、速度より安定性・コストが優先されることが多い

CPU推論・CPUコア活用のデメリット・注意点

• 推論速度がGPUに比べ大きく劣る: 同一モデル・同一量子化でも、GPU推論はCPU推論の5-20倍程度高速になるのが一般的
• コア数を増やしても頭打ちになる: メモリ帯域幅がボトルネックになりやすく、物理コア数を2倍にしても速度が2倍になるとは限らない。一般に8-16コア程度で伸びが鈍化する傾向がある
• 大規模モデル・長文脈では実用速度に届きにくい: 30B超のモデルや長いコンテキスト長では、tokens/秒が数個程度まで落ち込み、リアルタイム対話には不向きになりやすい
• 他プロセスへの影響が大きい: 推論中にCPU使用率が高止まりし、同じマシン上の他のアプリケーションやOS全体の応答性が低下しやすい
• マルチユーザー・同時リクエストに弱い: GPUのバッチ処理に比べ、CPU推論は複数リクエストの並列処理でスループットが伸びにくい

混同されやすい用語・類似技術との違い

CPU cores（物理コア） vs 論理スレッド（ハイパースレッディング/SMT）

「8コア16スレッド」のように表記される場合、8が物理コア数、16が論理スレッド数（ハイパースレッディング/SMTによる仮想的な倍増）です。OSやタスクマネージャーが表示する「論理プロセッサ数」は物理コア数の2倍になることが多く、両者を混同すると必要なCPU性能を見誤ります。CPU推論のスレッド数指定（-tオプション等）では、物理コア数を上限の目安にし、論理スレッド数まで増やすとかえって速度が落ちるケースもあります。

CPU cores vs CUDA cores

名称は似ていますが役割は大きく異なります。CPUコアは汎用演算用の少数（数〜数十個）の高機能コアで、複雑な分岐処理やシステム制御を得意とします。一方CUDA coresはNVIDIA GPU上に数千〜1万個超搭載される単純な並列演算専用コアで、行列演算（AI推論の中心処理）を大量並列で処理することに特化しています。「コア数」という言葉だけで両者を比較するのは誤りで、CPUの64コアとGPUの1万CUDAコアは単純な優劣比較の対象になりません。

CPU推論 vs GPU推論 vs ハイブリッド推論（レイヤーオフロード）

CPU推論はCPUコアのみでモデルの全層を計算する方式、GPU推論はGPUのVRAMにモデル全体を載せて計算する方式です。VRAMがモデルサイズに対して不足する場合、llama.cppやOllamaでは「レイヤーオフロード」と呼ばれるハイブリッド方式が使われ、一部の層をGPUに、残りをCPU（システムRAM）に配置して分担処理します。この場合CPU-GPU間のデータ転送がボトルネックになりやすく、オフロードする層数の調整が実務上のチューニングポイントになります。

CPU cores vs NPU（Neural Processing Unit）

近年のノートPC・SoCには、AI推論専用の演算ユニットであるNPUが搭載されるようになっています。NPUは低消費電力でのAI推論に特化しており、CPUコアで同じ処理を行うより電力効率が高い場合がありますが、対応モデル形式やソフトウェア対応が限定的で、llama.cpp等のCPU推論エコシステムほど汎用的には使えないのが現状です。CPUコアは「なんでも動くが速度は限定的」、NPUは「対応すれば効率的だが対応範囲が狭い」という住み分けになります。

パフォーマンス最適化

CPUスレッド最適化

• 物理コア数基準: HTない場合はコア数まで
• ハイパースレッディング活用: Intel CPUで有効
• NUMA考慮: マルチソケット環境での配慮
• アフィニティ設定: 特定コアへの処理固定

メモリアクセス最適化

• デュアルチャンネル: RAM 2枚組構成
• 高速メモリ: DDR5-5600以上推奨
• 十分な容量: 32-64GB以上
• 低レイテンシ: CL値の最適化

ボトルネック診断

CPU使用率監視

# Linux/macOS
top
htop
iostat 1

# Windows
Task Manager
Performance Monitor

# Python内での監視
import psutil
print(f"CPU usage: {psutil.cpu_percent(interval=1)}%")
print(f"CPU count: {psutil.cpu_count()}")
print(f"Memory usage: {psutil.virtual_memory().percent}%")

ボトルネック指標

• CPU 100%継続: コア数不足
• 高いI/O wait: ストレージボトルネック
• メモリスワップ: RAM容量不足
• GPU待機: CPU処理遅延

用途別推奨構成

研究・開発用途

商用・プロダクション

個人・学習用途

2025-2026年の最新動向

ARM CPUでのLLM推論がApple Silicon、Qualcomm Snapdragon X、AWS Gravitonで普及し、電力効率の良いCPU推論が注目されています。Apple Siliconは統合メモリアーキテクチャ（Unified Memory）によりCPUとGPU/Neural Engineが同一メモリプールを共有できるため、CPUコア単体のスペック以上に「メモリ帯域幅の高さ」が推論速度に効いてくる点が特徴です。

AMX（Advanced Matrix Extensions）がIntelのXeon系サーバー向けCPUに搭載され、行列演算をCPU上で高速化する専用命令として、CPU推論のスループット向上に寄与しています。コンシューマー向けCore iシリーズでは同様の専用アクセラレーションはまだ限定的で、AVX2/AVX-512による最適化が中心です。

また、NPU搭載ノートPC（Copilot+ PC等）の普及により、「軽い推論はNPU、重い推論はCPU、対応モデルはGPU」という役割分担がクライアント端末で一般化しつつあります。ただし現時点ではllama.cppやOllamaなどオープンソースのローカルLLMツールチェーンの主戦場は依然としてCPU/GPUであり、NPU対応は発展途上という状況です。数値・対応状況は変化が速い分野のため、導入前に各ツールの公式リポジトリで最新情報を確認することを推奨します。

実務での確認ポイント（まとめ）

• まず物理コア数を確認: タスクマネージャーやlscpu（Linux）で論理プロセッサ数と物理コア数を区別して把握する
• SIMD拡張の対応を確認: cat /proc/cpuinfo | grep flags等でAVX2/AVX-512/AMXの対応有無を確認し、llama.cppのビルドオプションと合わせる
• スレッド数は物理コア数を基準に調整: -tやOMP_NUM_THREADSを物理コア数付近から始め、上下に振って実測でtokens/秒を比較する
• メモリ帯域幅を軽視しない: 同じコア数でもデュアルチャンネル未満の構成では速度が頭打ちになりやすい。DDR5・デュアルチャンネル以上を優先する
• GPUが使えるなら基本はGPU優先: CPU推論はGPUのVRAM不足を補う手段、またはGPUがない環境での代替手段と割り切り、可能な限りレイヤーオフロードでGPUを活用する

関連用語

外部リンク

• llama.cpp（GitHub） - CPU/GPU両対応推論エンジン
• Intel oneAPI - CPU最適化ツール
• Ollama公式サイト
• LM Studio公式サイト