ローカル LLM の負荷要因に関するまとめ

はじめに

色々なモデルの設定だったり、研究室のGPUサーバ環境の構築をしてきた中で、快適に動かせるモデルとそうではないモデルがあったので、知識整理も兼ねてローカルLLMの負荷要因についてまとめていきます。

厳密生に欠ける部分があると思いますのであくまで個人のメモとしてご覧ください。

ローカル LLM にまつわる 「重さ」の正体と向き合い方

「生成 AI をクラウドではなく手元のマシンで動かしたい」というニーズはプライバシー保護とコスト削減を両立できる点から急速に高まっています。最近は中国のDeepSeek-R1というモデルがホットな反面、プライバシーに関する問題も懸念されています。

DeepSeek-R1はオープンウェイトモデル（オープンソース）であり、ローカルで動かせれば最新の高性能なLLMを安全に使うことができます。私の研究室でもDeepSeek-R1を動かしてみようとなりましたがOllamaのdeepseek-r1のページではモデルのサイズが 404 GBと莫大なサイズになっています。

このようにサイズからして「VRAM が足りない」という問題や、サイズが十分でも「応答が遅い」といった問題に直面しがちです。本記事では負荷要因について初心者向けにまとめています。

3つの負荷要因

負荷を決める要因として主に3つの要因に分類分けしました。「モデルそのものが抱える負荷要因」「推論時パラメータが招く負荷要因」「推論手法による負荷要因」です。

1. モデルそのものが抱える負荷要因

1.1 モデルサイズ

LLM の重みとバイアスは VRAM 上に常駐します。たとえば DeepSeek-R1:671B は 404 GBもの莫大なサイズです。モデルのサイズが 671B となっているのはモデルが 671 Billion（6710億個）もの重みやバイアスから構成されているという意味になります。NVIDIA H100（80 GB）なら 6 枚差しでもギリギリという世界です（正確には1.3TBものVRAMが必要みたいです[1]）。このモデルのサイズが全てではありませんが、高性能モデルほど VRAM を多く消費する傾向があります。

1.2 アーキテクチャで軽くする（MoE）

Mixture of Experts（MoE）は「質問の分野ごとに専門家を呼び出す」発想で、フルモデルを毎回動かさずに済むため計算量を抑えられます。Mistral などのモデルがよく採用しているアプローチです。

MoE ではたとえば数学の専門家であったり、コーディングの専門家がモデル内に存在しています。通常はモデル全体の重みを使って計算していかなければならないのですが、専門家領域を設けることでモデル全体を動かなくて良くなり、計算コストも抑えることができます。

1.3 量子化（Quantization）

重みを少ないビット幅で表現し VRAM と計算量を削減する手法です。代表的な形式を整理します。

量子化による精度低下は避けられませんが、精度低下以上にVRAMを削減できるという大きなメリットがあります。Llama.cpp などの推論フレームワークでは量子化手法がかなり多いですが、精度低下しにくい方向に改善されている印象です。

2. 推論時パラメータが招く負荷

2.1 コンテキスト長 N

入力トークン数＋出力トークン数を合わせた値が コンテキスト長 N です。

Transformer の自己注意機構では**計算量が O(N²d)、メモリ使用量が O(N²) **になります。たとえばコンテキスト長を 100 から 1000 トークンに伸ばすと、計算量の差は 100倍 にもなります。VRAM に制限があるローカル環境では、長文要約や長文生成タスクは制限がかかる場合があります。

行列計算のイメージ [2]

• コンテキスト長が 100K トークンなら行列のサイズは100K × 100K = 10B（100億）
• 16bit 浮動小数点型なら 10B × 2byte = 20GB もの VRAM が追加で必要

普段から Claude を使用している人ならわかると思うんですが、チャットが長くなるとこんな感じのメッセージが表示されます。モデルには今までの質問内容や出力内容を入れて計算をさせているので、回答が長引けば長引くほどコンテキスト長が長くなってしまいます。計算量的に見ると、Nの二乗のオーダーで計算量が増えていくので、長くなれば長くなるほどリソース消費が激しくなっていきます。一度区切りがついたらチャットを作り直すのがおすすめです。

2.2 バッチサイズ B

一度に捌くプロンプト数を表す B を大きくすると GPU の並列計算性能をフル活用でき、スループットは向上します。一方で VRAM 使用量は バッチサイズ B に線形に比例します。

個人利用では、同時に一つのプロンプトしか計算しない（常にB = 1な）ので、特に気にする必要が無いパラメータです。しかし一つのプロンプトしか同時に計算しないというのは、GPUの並列計算能力をフルに使えていないとも言えます。大きなモデルを読み込むことで VRAM はマックスに近くなっているかもしれません。ですが、それはメモリ（VRAM）にデータが沢山あるだけで、GPU の計算能力を存分に活かし切れてません。

基本的に同時にいくつものプロンプトを処理するのは、サービスを提供している側の話なので、ローカルLLMの規模で最大限使うのは難しい話です...。B = 1だからと言ってCPU推論に負けるわけでないのでそこは安心してください！

3. 推論手法で賢く削る

PagedAttention（vLLM）

vLLM が実装する PagedAttention は、キー・バリューキャッシュをページ単位で管理し、断片化によるメモリ浪費を抑えることができます。論文では 使用可能メモリの 96.3 % を有効活用 したと報告されています。長いコンテキストを扱う際も VRAM 上のスキマが原因でエラーになる、そんな事態を防げる頼もしい手法です。

vLLM は メモリの 96.3%を有効に活用できている [3]

おわりに

本記事は理論値について調べてまとめたものです。実態とはかけ離れているかもしれませんが、基本的な部分は変わらないと思うので、負荷要因の相場感を掴むのに参考になると嬉しいです。

GPU サーバを選定する際は、クラウドサービスプロバイダなどでGPUを沢山積んだサーバをレンタルすれば最適なスペックを選べそうです。レンタルをして負荷試験を行うことで実用可能なのかなどを把握することができます。

参考文献

[1] GPU System Requirements for Running DeepSeek-R1(https://apxml.com/posts/gpu-requirements-deepseek-r1?utm_source=chatgpt.com)

[2] Transformer とは？数学を用いた徹底解説：Encoder 編(https://qiita.com/mantis522/items/b45494f4378b066d0432)

[3] Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L., Yu, C. H., Gonzalez, J. E., Zhang, H., & Stoica, I. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. arXiv preprint arXiv:2309.06180. https://doi.org/10.48550/arXiv.2309.06180