【ITニュース解説】Two questions before you run a local LLM: does it fit, and how fast is it really?
2026年10月17日に「Dev.to」が公開したITニュース「Two questions before you run a local LLM: does it fit, and how fast is it really?」について初心者にもわかりやすく解説しています。
ITニュース概要
ローカルLLMを動かす前に、必要なメモリ容量が足りるか正確に計算し、実際の実行速度を測定条件(ハードウェア、ランタイム、コンテキスト長など)を明記して確認しよう。ベンダーの数値だけでなく自身の環境で検証し、結果と条件を記録することが重要だ。
ITニュース解説
大規模言語モデル(LLM)を自分のパソコンやサーバーなど、ローカル環境で実行しようとするとき、多くの人が同じ二つの課題に直面しがちである。一つは、モデルとその処理に必要なデータ(コンテキスト)を収容できないハードウェアを選んでしまうこと、もう一つは、全く異なる条件下で測定された「1秒あたりの生成トークン数(tokens/s)」という数値を鵜呑みにしてしまうことだ。これらの失敗を避けるための重要なチェックポイントについて解説する。
まず、メモリにモデルが収まるかどうか(メモリ適合性)と、実際にどれくらいの速度で動作するか(速度)は、それぞれ別の問題として考える必要がある。これらは異なる種類の情報に基づいて判断すべきだ。
メモリ適合性は、自分自身で計算できる算数のようなものだ。基本となるのは、量子化されたモデルの重みの保存サイズである。これに、実際に使いたいコンテキスト(モデルに入力するテキストの長さ)のためのKVキャッシュのサイズを加え、さらにランタイム(モデルを実行するためのソフトウェア)、グラフィックドライバー、そしてデスクトップ環境が占めるメモリの余裕分(ヘッドルーム)を考慮する必要がある。たとえば、一般的な700億パラメータのモデル(70Bモデル)を4ビット量子化(Q4)した場合、重みだけでおよそ40ギガバイト(GB)のメモリが必要になる。したがって、「24GBのグラフィックカードで動く」と謳われている場合、それは通常、グラフィックカードのメモリだけでは足りず、PCのメインメモリ(システムRAM)にデータをオフロードしながら動作する設定を意味する。この場合、メインメモリへのオフロードが発生するため、処理速度は大幅に低下してしまう。
一方、モデルの速度は、非常に具体的な測定条件の下でのみ意味を持つ数値だ。正確なハードウェア構成、使っているモデルのバージョン、量子化の種類、使用しているランタイムとそのバージョン、入力するコンテキストの長さ、プロンプトの長さ、そして同時にどれだけの処理を走らせているか(並行処理)、さらには測定方法(最初の応答までの時間であるプリフィル、または最初のトークンが生成されるまでの時間であるTTFT、あるいは継続的にトークンを生成するデコード)など、全ての条件が明確でなければ、その数値は信頼できない。例えば、たった一つのリクエストで測定されたデコード速度と、同時に8つのリクエストを処理する際のスループット(処理能力)は全く異なる。ベンダーが提示する「最高速度」のような宣伝文句は、実際の測定値ではないことが多い。もしこれらの詳細な条件が示されていない場合、その速度が本当にどれくらいかは「不明」と判断するのが正しい。特に注意すべきは、プリフィル時間と1秒あたりの生成トークン数(tokens/s)は同じではない点だ。もしTTFT(Time To First Token)しか情報がない場合、それはプリフィル時間から推定された数値である可能性が高く、その旨が明記されているべきである。
次に、ハードウェアを選ぶ前に、どのランタイム(モデル実行環境)を使用するかを決めることが重要だ。ランタイムによって、そのハードウェアで何ができるか、そしてどの程度の性能が出るかが決まる。NVIDIAのGPUを使うためのCUDA、AMDのGPUを使うためのROCm、Apple Silicon向けのMetal、汎用的なVulkan、そしてCPUやNPU(ニューラルプロセッシングユニット)など、それぞれが異なる特性を持ち、提供される機能や性能も大きく異なる。あるランタイムで利用できる機能が、他のランタイムでも利用できるとは限らない。例えば、Apple Siliconの場合、MLXというランタイムが最もネイティブで効率的なパスを提供する。NVIDIAのサーバーGPU環境では、vLLMやSGLangのようなランタイムが特に高いスループットを出すために使われることが多い。また、CPUとGPUを組み合わせて利用するPCでは、Mixture-of-Experts(MoE)のような特定のモデル構造に最適化されたオフロード型のランタイムが有効な選択肢となることもある。
Apple SiliconでMLXを使ってモデルを実行する場合に知っておくと便利なのは、mlx-lmというパッケージにmlx_lm.serverという機能が含まれていることだ。これは、OpenAIが提供するAPIと互換性のあるHTTPサーバーとして動作する。これにより、/v1/chat/completionsや/v1/completions、/v1/modelsといったエンドポイントをローカルのMac上で利用でき、既存のOpenAIクライアントを自分のMacに接続してモデルを使えるようになる。デフォルトでは127.0.0.1:8080で起動し、--modelオプションでモデルを指定したり、--hostや--portで接続情報を変更したりできるため、非常に便利だ。ただし、重要な注意点がある。このmlx_lm.serverは基本的なセキュリティチェックしか実装しておらず、本番環境での利用は推奨されていない。単一ユーザーが自分のPCで使う分には問題ないが、もし外部に公開する必要がある場合は、必ず認証やネットワーク制御といった追加のセキュリティ対策を講じるべきであり、それまではlocalhostにのみバインドしておくべきだ。
最後に、どのような数値を測定した場合でも、その数値と同時に測定時の条件を必ず記録しておくことが非常に重要だ。例えば、「42トークン/秒」という数字だけが残っていても、6週間後にはそれが何の環境で測定されたものか分からなくなってしまうだろう。「M5 Max、4ビット量子化、8Kコンテキスト、単一ストリーム、mlx-lmバージョンx.yで42トークン/秒」というように、詳細な条件を付記していなければ、その情報は自分にとっても他人にとっても無意味で、誤解を招く可能性すらある。もし何から記録を始めれば良いか迷う場合は、LocalForgeのようなリファレンスサイトを参考にすると良い。このサイトは、メモリ適合性、実用的なコンテキスト長、実際に測定された速度、ベンダーの主張、不明な点などを分けて整理し、それぞれの情報源にリンクしている。これはベンチマーク結果を独自に公開する場ではなく、ローカルLLM環境を構築する上での意思決定を助けるガイドとして活用できる。