vLLMのArm CPU最適化：LLM推論を「動く」から「使える」へ

導入

LLM推論においてCPUは依然として重要な選択肢だ。専用アクセラレータほどのピーク性能を狙うものではないが、入手性が高く、運用が比較的単純で、既存のクラウドや企業データセンターに組み込みやすい。Arm Neoverseベースのサーバーが広がるなか、vLLMのArm CPU対応を強化する意味は大きい。vLLM Blogは、vLLM、PyTorch、oneDNN、KleidiAIなどとの協力による数カ月の改善内容を公開した。

主なポイント

• まず使いやすさを改善：Arm CPU向けに事前ビルド済みwheelとDockerイメージが用意され、クラッシュ、精度、スレッド、CPU使用率に関する問題が修正された。chunked prefill、prefix caching、INT8 W8A8 / W4A8推論、GPT-OSS、Whisper、Qwen 3.5 / 3.6などのモデル対応も進んだ。
• GEMMだけが原因ではなかった：2025年10月時点の測定では、モデル実行時間の約80%がdense layerに費やされ、そこでは最適化済みのBF16 GEMMが使われていた。しかし単体GEMMはすでに期待効率に近く、真の問題はアロケータ、ランタイム同期、フレームワークのオーバーヘッド、attention、量子化実行の組み合わせにあった。
• メモリ確保の改善が大きい：PyTorchのglibc malloc利用では、大きなメモリ領域の再利用が不十分で、ページフォルトやスレッド競合が発生していた。Arm CPU上でmimallocをデフォルトにした結果、Llama 3.1 8Bのオフラインスループットは2.3倍、低並列のサービングでは約7倍の改善が報告されている。
• 高コア数では同期が壁になる：paged attentionの時間の74%がOpenMP動的スケジューリングに使われるケースが観測された。Neoverse V2はLSEによるハードウェアアトミック命令を備えるが、従来のランタイムはそれを十分に使っていなかった。LSEアトミック対応のlibgompにより、Llama 3.1 8Bのオフラインスループットは9%向上し、低並列TPOTは15%低下した。
• BF16重みの事前パッキング：高性能GEMMは、カーネルに適したブロック化レイアウトを好む。毎回レイアウト変換を行うと、とくに低並列時にコストが目立つ。oneDNNとCompute Library for Arm Architectureを使う経路では、warmup時にBF16重みをパックして推論中に再利用できる。これによりオフラインスループットは16%向上し、低並列TPOTは60%削減された。
• paged attentionをArm向けに最適化：従来のCPU paged attentionでは、QK、PV、softmaxの指数計算が参照実装に頼っていた。新しい実装はArm BFMMLA Advanced SIMD命令を使ったカスタムGEMMと、ベクトル化された三次多項式近似によるsoftmax exponentialを採用した。paged attentionは最大4倍高速化し、Llama 3.1 8Bのオフラインスループットは12%向上した。

意義

この取り組みは、Arm CPUでvLLMを単に動かす段階から、実際の推論基盤として評価できる段階へ近づけるものだ。企業にとっては、低並列、コスト重視、既存サーバー活用といった場面でCPU推論の選択肢が広がる。

同時に、LLM推論の性能は単一の行列積カーネルだけでは決まらないことも明確になった。メモリ管理、スレッドランタイム、重み配置、attention実装、量子化パスが積み重なって、エンドツーエンドの性能を左右する。Arm CPUが推論基盤として存在感を増すには、このようなスタック全体の最適化が不可欠だ。

出典：vLLM Blog