ローカルLLMを動かそうと思った時、AWSで運用する機会がある。
AWSだとGPUインスタンスを使用した際の料金が高い。一方でGPUを使わないとLLMの推論やPrefillが遅くなる。
今回はそのジレンマをどのように改善するのかという視点で書く。
初めに
ローカルLLMとは、文字通りローカル環境で動かすことができるAIである。一般的なChatGPTやClaude Codeなどと比較して、外部に情報を置かずに動かせるメリットがある。しかしながら、一般的にはクラウド型の有名モデルより性能が劣ったり、動かすための環境構築が大変であるというデメリットも知られている。
しかしながら最近のモデル進歩のおかげで、2026年登場のAIはかなり高性能になっている。例えばQwen3.6のオープンウェイトモデルは、Claude Sonnet 4.5相当の性能があるとされている。Claude Sonnet 4.5は2025年9月30日に発表されたクラウド型のモデルである。少し前のClaude codeの定番モデル相当の性能が、現在はローカルで動く状態である。
これは言い換えれば、ローカルAIの課題であった性能面のギャップが埋まっていることを示す。実際自分も半年前に、ローカルAIを動かしたことがあるが、現在のモデルに比べると明らかにツール呼び出しの精度が悪いなどの実用面で課題があった。今ではそのような初歩的不具合はローカルでもだいぶ落ち着き、安定して動くモデルが増えている。
そのため、ローカルLLMを導入する価値が徐々に出ているフェーズとなっている。今回は、ローカルLLMを運用する際のPC選定や、モデルの選び方を中心に解説をする。
ローカルLLMのモデルの決め方
ローカルLLMのモデルは多数あり、どれを決めればよいのか判断する必要がある。基本的には新しめのモデルを選ぶのが鉄則ではあるが、今回はより詳細に解説を進めていく。
基本的にはLLMがどれくらいの性能を必要とするのかを決め、そのあとにモデルサイズや対応するツール呼び出し機能を決めていくことで、採用モデルを決定する。
決定観点1.性能
最近のローカルLLMは、ChatBOTのような会話での運用の場合、概ねどのモデルでも動く程度に成熟している。
一方で、AIコーディングといったエージェント運用を考えると向き不向きがまだまだ明確に出る。
たとえば、AIにファイルを読み書きさせる際に、AIが生成するJSONのフォーマットが正しくないためにアプリ側でエラーを発生させる頻度が高いモデルが存在する。また、純粋にコーディングをさせる時であっても、正しくコードが生成できないなどの課題がある。
LLMの性能を調べる際にはベンチマークの結果を比較することが一般的とされている。しかし、一部AIモデルではベンチマークに最適化する形で、モデルが優秀であるとアピールするケースが散見される。このケースだと、ベンチマークの性能が実運用で発揮されないことがある。このためAIモデルを動かす場合、実際に手で触って動かす確認が重要である。
AIモデルの動作確認であれば、OllamaやLMStudio等の簡単な方法でモデル立ち上げて動かせばよい。現在はGUI上で最新モデルを簡単に試すことができる。そのためまずは動かしてみることをお勧めする。
決定観点2.モデルサイズ
賢いAIほど、モデルサイズが大きくなる傾向がある。実際にローカルLLMの上位モデルを確認すると、100B（1兆）パラメータ以上のモデルが多い。一般的には10Bあたり無圧縮で約20GBのパラメータを持つ。つまり100Bのモデルを無圧縮で動かす場合、およそ200GBのメモリが必要になる。市販のPCではこのサイズのメモリを搭載することは容易ではない。そのため、モデルサイズの上限を事前に把握することが重要である。
また、量子化技術を活用することも重要である。一般的には推論の場合、4ビット量子化してもオリジナルと比較して推論精度に差がほとんど出ないことが知られている。4ビット量子化では、無圧縮（16ビット）と比較して1/4～1/3程度のサイズになる。つまり10Bあたり6GB～7GB程度まで小さくできる。さらに、一部GPUでは4ビットや8ビット精度で直接計算できるものもあり、対応するものを使用することで量子化モデルの計算速度を早くできる。
また、アクティブパラメータが全体の一部になるケースもある。モデルが大きいと推論が遅くなるため、パラメータの一部のみを適宜有効化しながら動かすMoEアーキテクチャを採用するモデルがある。このモデルの場合、モデルサイズが大きくてもある程度高速に動作し、アクティブパラメータのサイズ次第でCPU推論も可能になる。
決定観点3.付帯機能
AIによっては画像を読み込む機能やツール呼び出しなど特定の機能を備えるケースがある。そのため、「事前にどの機能を使うのか」の視点でモデルをフィルタリングすることが重要である。最近のトレンドで重要な機能を以下に示す。
ツール呼び出し(tools_calling)
エージェント機能を使用する際に必須である。ツール呼び出し機能に対応すると、Clineなどのエージェントソフト経由で自律的にPC内部を操作できるようになる。例えばファイルの作成読み込みや、コマンドの実行、対応していればブラウザの表示なども可能である。最近のモデルはツール呼び出しに対応するケースが多いが、まれに対応していない場合があるので気を付けること。
画像認識・音声認識
画像や音声に対してAIを動かす際に必要である。例えば人型ロボットを作る場合には、音声認識やカメラの画像で情報を入力し、会話をする用途でこの機能を用いる。モデルによっては音声もしくは画像だけに対応する場合もある。Web開発等でUIのスクショをLLMに伝え、見た目の改善で使用する等の用途にも使える。対応するかどうかはモデル次第である。これらの機能を省略してコーディングなど特定の性能に注力するモデルもあるため、必要に応じて取捨選択することも必要である。
PCの選定方法
LLMを動かすためのPCのパターンとして次の候補がある。
ノートPC（開発端末上で完結）
サーバー（自前で基盤を持つ）
EC2インスタンス（インフラ管理が楽だがGPUインスタンスは高額）
ここで重要になるのはモデルサイズである。簡単な作業であれば現在、7Bなどの小型モデルで動かすことが可能である。一方である程度のサイズになるとサーバーやEC2インスタンス上で動かすことになる。極論、H100などの高性能GPUが複数あれば大きなモデルも動かせる。しかしかなり高額である。例として、EC2インスタンスでは1GPUインスタンスを1か月起動するだけで10万円以上になる。さらに、オンデマンドで起動ができないほど人気のGPUインスタンスも多く、手軽に試しづらい。
そのため、用途やモデルによりCPU推論も検討することがおすすめである。先ほど記載したMoEアーキテクチャでアクティブパラメータが数B程度であれば、CPU推論でもある程度の速度が出せる。
ただしCPU推論の場合、「プロンプト→トークン変換（Prefill）」で課題がある。
LLMの処理には、Prefill とDecode（トークン→出力ワードの変換）の2つのプロセスがあるが、一般的にPrefill の方がDecodeよりも並列度の高い計算となっている。チャットであれば入力した文章をPrefill するだけであるが、エージェントの場合、エージェント動作向けのプロンプトがチャット文章に加えて含まれている。その結果、Prefillに要するトークン数が多くなる。例えば入力は数万トークンで出力は数百トークンのテキストになる場合がある。GPUを用いることでこのPrefillを高速化できるが、CPUではプロンプトを入れてからPrefillに時間がかかるため、明らかなレスポンスの悪さを感じられる。
その結果として、GPUがないとエージェント運用に関しては現状厳しい状態である。
トークン生成効率
トークン生成はトークナイザーによって決定される。トークン生成をする際にはなるべく効率よく文字をトークンにするような設計にする。この際、よく用いられる言語として英語や中国語があげられる。そのため多くのモデルでは英語や中国語といった言語で、トークン生成を最小に抑えるようにトークナイザーを設計する。
しかしながら、日本人の多くは日本語を使用するため、日本語のトークン効率が実際の場面では重要になる。トークナイザーは辞書型符号化（Dictionary Coding）などと同じく、1トークンによく出る文字列を割り当てる方式である。例えば、"you","because"のようなよく出る文字を複数文字で1トークンとして扱うことができる。ただし語彙サイズが固定のため、すべての単語を割り当てることはできない。ゆえに、英語や日本語すべての効率を同時に高くすることは厳しい。
結果として、日本語は世界的にみるとマイナー言語であるため、符号効率が悪くなる傾向がある。符号化効率をよくするために、日本語に最適化されたトークナイザーを使用するモデルを採用すると、アプリの実行効率がよくなる場合がある。
具体例として、一般的なトークナイザーを持つGemma4 と日本語に最適化されたトークナイザーをを持つLLM-JP4のトークン生成数を比較した。
トークナイザーの日本語効率については、同じ文章を実際のトークナイザーで分解させることで比較できる。少ないトークンになるほど効率が良い。
表1 トークン生成効率と生成速度の比較
結果としては、LLM-JP4の方がGemma4よりも良い結果となった。アクティブパラメータの差もあるが、トークン生成効率が良いこともあり、結果的な日本語の生成速度はトークナイザーの最適化で変化することが分かる。
このため、日本語のトークン生成効率についてはLLM-JP4の方が高く、同じ日本語を少ないトークンで表現できる。
ただし、日本語特化型のLLMは現在発展途上であり、ほかのモデルより純粋な実行能力が劣る場合が多い。例えばJP-LLM4はGPT-4世代相当の性能であるが、Gemma4であればGPT-5世代の性能になる。
このようなことを踏まえると、現状はまだ日本語特化のLLMについて、性能不足感は否めないものの、トークン生成効率も今後はモデル選定に影響すると考えられる。
ローカルLLMでコーディングはどれくらい可能か？
最近登場したQwen3.6やGemma4であれば、エージェント性能がずいぶん改善されており、ローカルLLMではコーディングが厳しいという状況が変わり始めた。
1年前のモデルでは例えばLlama4があった。こちらのモデルは100Bクラスの大きさで実行環境の要求も高かった。しかしながら実際にコーディングをさせようとすると、ファイルの読み書きのコマンドを正しく出力せずにエラーを出すなど、エージェント性能が不足しており、実用的ではなかった。
その後GPT-OSSが登場し、コーディング作業を自動でするだけのエージェント性能を持ったモデルが登場したが、120Bのパラメータのため、一般的なローカル環境で動かすことが困難である状態が続いた。
GPT-OSSの登場から半年以上この状態が続いていたが、Gemma4とQwen3.6の登場によりこの状況が大きく変わった。両者の大きな特徴としては、エージェント性能に重要なJSONオブジェクトの正確な生成精度の高さである。フォーマットエラーやコマンド実行の形式エラーの頻度が格段に減少した。また、従来のローカルモデルによく見られた思考ループ（思考トークンを無制限に消費し、永遠に答えが出ない現象）もあまり見られない。このため、最近ではローカル環境でコーディング作業が現実的になり始めたといえる。
まとめ
今回はローカルLLMを動かすにあたり必要な、モデルの選定やマシンスペックの考え方をまとめた。端的にあらわすと以下のようにまとめられる。
・新しいモデルほど賢い傾向がある
・LLMのベンチマークは、結果の数字がよくなるように最適化されることが多く、実際の使用感を確認することが重要
・エージェント運用する場合、ツール呼び出しとGPU搭載マシンが必須
・チャットボットであればCPUインスタンスでもある程度使用可能
・用途によっては日本語特化のトークナイザー搭載モデルが有効になる
・最新のLLMモデルであれば、高額なマシンでなくともエージェント運用がある程度可能
今後も新しいモデル登場に伴い、ローカルでできることは増える見込みである。この知識を参考に、今後のローカルAI導入に役立てていただきたい。