llama.cppのマルチスロットは速度を改善するのか?

Reddit r/LocalLLaMA / 2026/4/26

💬 オピニオンDeveloper Stack & InfrastructureTools & Practical Usage

要点

  • 投稿では、llama.cppの「マルチスロット」(--parallel > 1)によって推論速度が上がるかどうかが議論され、vLLMの並列性能との比較が行われています。
  • 著者は、vLLMでデコードスループットが大きく伸びると報告しており(例:llama.cppで1スロットあたり約150〜170 tok/sから、vLLMで4スロットで約400 tok/sまで)、全スロットを使い切る前提で効果が出ることを示しています。
  • 一方で、vLLMはCPUオフロードやGGUFとの相性などで実運用上の制約があり、その結果、選べる量子化が実質的にint4/int8中心になってしまうため、llama.cppより不利だと主張しています。
  • 著者は1スロット時にベンチマーク1回あたり数時間以上かかっているため、llama.cppでマルチスロットを使えばベンチ完了までの時間を短縮できるのか、それともボトルネックにより大きくは変わらないのかを疑問に思っています。
  • 全体として、速度の改善はハードウェアや設定に依存するため、「スループット向上」と「オフロード挙動・量子化対応」といった制約のトレードオフが重要だという問題提起になっています。

llama.cpp で複数スロットを使うこと(--parallel > 1)については、主に悪い評価ばかり聞いてきました。vLLMと比べると、この点ではさらに悪いのかもしれませんが、最近 vLLM を4スロットで試したところ、確かに全体の速度が大幅に向上しました(もちろん、4つのスロットすべてを使用しているときです。1スロットの llama.cpp でデコード 150〜170tps に対して、4スロットの vLLM では 400tps)。

ただし、vLLM は CPU オフロードをあまりうまく扱えません(あるいは、正しく使い方が分かっていないだけかもしれません)し、聞いた話では GGUFS にもあまりうまく対応できていないようで、その結果、利用可能な量子化が基本的に int4/int8 に限られています。そして多くのモデルでは、llama.cpp なら Q6 を簡単に回せて良い速度が出ますが、vLLM だと int4 の量子化まで落とさないといけないでしょう。

ということで本題… 最近いくつかベンチマークを回していて、1スロットの llama.cpp では、1回の実行に簡単に2時間以上かかります。複数スロットを使えば、ベンチマーク完了までの時間が実際に短くなるのか、それともむしろ同程度のままなのか気になっています?

submitted by /u/Real_Ebb_7417
[link] [comments]