Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】When LLM Inference on CPU Beats Waiting for the GPU

2026年10月24日に「Dev.to」が公開したITニュース「When LLM Inference on CPU Beats Waiting for the GPU」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

LLM推論時、GPUが混雑すると処理待ちが生じる。一部の処理、特にキャッシュ利用可能なデコードをCPUに割り振ると、全体の完了時間を約10%短縮できる。CPUとGPUの最適な連携が効率化の鍵となる。

ITニュース解説

大規模言語モデル(LLM)の推論(AIが入力に基づいてテキストなどを生成する処理)を効率的に行うことは、AI活用において非常に重要だ。一般的に、高性能な計算にはGPU(Graphics Processing Unit)が使われるが、この記事では、CPU(Central Processing Unit)とGPUを組み合わせることで、推論速度をさらに向上させる可能性が示されている。

「mini-vllm-rs」というmacOS上で動作するLLM推論エンジンは、CPUとGPU(Apple Mシリーズチップに搭載されているMetal GPU)の両方を利用できる。このエンジンは、AIへのリクエストが来たときに、CPUとGPUのどちらに処理を割り当てるかを判断する「ルーティング」機能を持つ。

これまでの実験では、高速なGPUにほとんどのリクエストを送るのが最速とされていた。しかし、今回の検証では、「CPUに一部のリクエストを割り振ることで、全体の完了時間を短縮できるのではないか」という疑問に焦点を当てている。特に、「ウォームプレフィックス」と呼ばれる、以前に処理された情報の一部がキャッシュ(一時的に保存された高速なメモリ)に残っているリクエストと、GPUに多くの処理待ちが溜まっている状況が、CPUオフロードの有効性を示す鍵となると考えられた。

実験では、Apple M2チップ上でQwen2.5 0.5BというAIモデルを使用し、512個の入力トークンと128個の出力トークンを生成するリクエストを処理した。個々のバックエンド(CPUとGPU)の性能を比較すると、AIが入力文章を読み込む「プリフィル」という最初の段階では、GPUはCPUの約35倍高速だった。しかし、AIが文章を生成していく「デコード」という次の段階では、GPUはCPUの約6.5倍の速さに留まった。この結果は、特に長い文章のプリフィル処理ではCPUが大幅に不利である一方で、デコード処理ではCPUが活用できる余地があることを示している。

実験では、約512トークン分の情報を事前に両方のキャッシュに読み込ませた状態(ウォームプレフィックス)で、リクエストを50ミリ秒間隔で連続して送った。これにより、CPUが苦手とするプリフィル処理の負担を減らし、デコード処理で能力を発揮できる状況を作った。ルーティングの判断は、残りのプリフィルトークン数とデコードトークン数をそれぞれの処理速度で割って合計する「スコア」(推定処理時間)に基づいて行われた。スコアが低い方、つまり処理時間が短いと推定される方にリクエストが割り当てられる仕組みだ。このスコア計算には、既に処理中のリクエストやキュー(処理待ちの列)にあるリクエストも考慮されるため、単に空いているかどうかだけでなく、全体の負荷を見て最適な選択が行われる。

この仕組みの効果を検証したところ、8つのリクエストを処理するバースト実験では、1つのリクエストをCPUに振り分けることで、バースト全体の完了時間が9.8%短縮された。さらに48のリクエストを処理するケースでは、6つのリクエストをCPUにオフロードすることで、全体の出力スループット(単位時間あたりに処理できる量)が12.4%向上するという結果が得られた。

なぜこのような改善が見られたのか。ルーティングの判断プロセスを詳細に見ると、例えば7番目のリクエストが到着した時点では、GPUには既に4つのアクティブリクエストと2つの処理待ちリクエストがあった。それでもこの時点ではGPUのスコアがCPUよりもまだ低かったため、GPUに割り当てられた。しかし、約50ミリ秒後に8番目のリクエストが来たときには、GPUの処理待ちがさらに増え、累積されたデコード処理の負荷によってGPUのスコアがCPUを上回った。この結果、8番目のリクエストはCPUに割り当てられたのだ。ウォームプレフィックスによってプリフィルにかかる時間が短く抑えられ、GPUのデコード処理の累積負荷が判断を左右する重要な要素となったことがわかる。

実際にCPUにオフロードされた8番目のリクエストの処理時間を見ると、GPUのみで処理した場合と比較して、最初のトークンが生成されるまでの時間(TTFT)が大幅に短縮され、リクエスト全体の完了時間も短くなった。そして、バースト全体の完了時間も短縮された。これは、GPUが既存のリクエストの処理を続けている間に、CPUが別のリクエストの処理を並行して開始できたため、システム全体としての効率が向上したことを意味する。

今回の実験で得られた知見は非常に重要だ。CPUの処理速度はプリフィルではGPUに大きく劣るものの、デコードではその差が小さくなる。そして、ウォームプレフィックスによってプリフィル処理の負担が軽減され、さらにGPUに処理待ちが溜まっている状況では、CPUにリクエストの一部を賢く割り振ることで、全体の効率を大幅に改善できることが示された。つまり、リクエストをどこに割り当てるかは、単なる処理装置の速度だけでなく、既存の処理待ちの量や、キャッシュの再利用によってどれだけプリフィル処理を省略できるかといった、より複雑な要素を考慮する必要があるということだ。

もちろん、今回の結果は特定の環境(Apple M2、特定のAIモデル、固定されたGPUアクティブリクエスト数など)に基づいているため、多様な状況で同様の効果が得られるかをさらに検証する必要がある。例えば、リクエストの到着パターンやキャッシュのヒット率(キャッシュされている情報がどれくらい有効に利用できるか)が変化した場合の挙動は、今後の研究課題となる。しかし、今回の実験は、CPUとGPUを協調させることで、AI推論の効率を新たなレベルに引き上げる具体的な方法を示しており、将来のシステム設計に大きなヒントを与えるものだと言えるだろう。

関連コンテンツ

関連IT用語

関連ITニュース