ローカルLLMの現状（2024～2025年）実際に何が変わったのか？

2023年10月頃、私はLLMをローカルで動作させるためのllama.cpp、Llamafile、Ollamaに関する記事を書きました。その投稿が最もアクセスされた技術記事となったことから、エンジニアやテック起業家のような人々はGPUの使用料金に膨大な費用を払わずにLLMを動作させる方法をまだ探していることを知りました。

それ以来、状況は変わりました。革命とは言えませんが。変化はありました。ツールは成熟し、新しいモデルが登場し、AIをローカルで実行する際の現実的な制約も明確になってきました。そこで2026年の始まりに、前回投稿してから学んだことを更新します。

llama.cppのエンジンは変わらず、操作性が向上

ターミナルで日々を過ごすエンジニアの方々にとって、llama.cppは依然として基盤です。このプロジェクトは、話題に乗ることを追求するのではなく、パフォーマンスと互換性を追求しました。主な進化点は以下の通りです。

• Vulkanバックエンドが成熟: 初めてGPUでLLM（大規模言語モデル）を遊び始めた頃、AMDアーキテクチャの問題に遭遇し、母板とCPUをIntelに変更するために1000ドル近く費やしたことを覚えています。今では、AMD GPUのサポートが「技術的には動作する」から「実際に使える」レベルまで成長しました。llama.cppのVulkanバックエンドは大幅に進化し、RX 6700 XTを含むAMD GPUで信頼性の高いパフォーマンスを提供しています。Q4_0モデルでのベンチマークでは、83-1051トークン/秒（tg128/pp512）のスコアが報告されています。VulkanはCPU（古いCPUベースラインで約10-30トークン/秒）よりも大幅に高速であり、最近のROCm比較では一部のAMD環境で50%高速化されていることが確認されています。（Vulkanバックエンドとは何か？ Vulkanは、様々なハードウェア上で大規模言語モデル（LLM）の推論を加速するために使用されるクロスプラットフォームのグラフィックスおよびコンピュートAPIバックエンドです。）

• Metalの最適化: MetalはNVIDIAのCUDAと同等のものです。Apple Siliconユーザーは、M2/M3チップで特に大きな文脈ウィンドウ（16k以上）の場合に、トークン/秒が20-30%向上したと言われています。Macを使用していない私には確かめられませんが、これらのベンチマークを参照することをお勧めします。

• GGUFが標準になった: 2024年までは、ソフトウェアの更新で古いモデルファイルが使えなくなる「破壊的変更」という問題に悩まされていました（旧GGML形式）。Georgi Gerganov氏によって導入されたGGUF（GPT-Generated Unified Format）は、メタデータをファイル自体に埋め込むことでこの問題を解決しました。2024年時点で業界は事実上、古いGGMLやセカンダリーフォーマットを放棄し、Hugging Faceのネイティブサポートやllama.cpp内での採用によりGGUFを主流に据えました。つまり2025年では全員がGGUF形式を使用しており、ダウンロードしてローカルで実行するだけという状態です。

Ollamaとは、開発者向け体験の勝者かも

前回のブログ投稿以来、直接llama.cppを使ったことはありません。私のワークフローは主にSimon Willisonのllmツール経由で、背景ではOllamaと対話することが多いです。 Ollamaは、モデルのマネージャー役です。ダウンロード、削除、または必要に応じてクラウドベースの強力なモデルを割り当てることもできます。

Ollamaは、ローカルモデルを「動かすだけ」ことに特化しました。ハードウェアが1000億パラメータ（さらには1兆パラメータ）のモデルを処理できない場合でも、クラウドモデルも利用可能です（インターネット接続は必要になります）。

• マルチアダプター構成の構築: 基本モデルとLoRAアダプターを組み合わせて、特定のタスクに対応（例：コード生成＋日本法文書）。
• 事前ロードモデル: モデルをVRAMに温存しておくことで、ollama serve --keep-aliveを使って最初のトークン遅延を秒からミリ秒に短縮。 私の環境では、ワークフローの一部ごとに異なるモデルを使用するため、実際にはこのオプションはオフにしています。
• REST API互換性: APIがOpenAIのものと非常に近いように設計されていますので、多くのアプリケーションではベースURLのみを変更すれば済みます。

パフォーマンス面では、Ollamaは引き続きllama.cpp上に構築されているため、速度差はあまりないと思われます。オンラインの人々の中にはOllamaを使わず直接llama.cppと対話する方もいます（現在、llama.cpp自体にもブラウザ経由でアクセスできるサーバーがあります）。これは魅力的ですが、Ollamaにはクラウドモデルという違いがあると思われます。

新世代モデルの本当に重要なこと

元の投稿を書いた時、Llama 2はローカル環境での最先端でした。世界は進化しました。2025年にディスクスペースに値するものはこちらです。

Llama 3.1/3.2 仕事のプロが進化した

• Llama 3.1 8B：この8Bバージョンは、Llama 2 13Bが目指していたものを実現しています。より小さく、速く、命令に従う能力も向上しました。《Q4_K_M》量子化されており、M2 MacBook Airで約40トークン/秒の処理速度が期待できます。
• Llama 3.2 3B：Raspberry Piでも動作する「モデル」と言われています。創造的なタスクでは品質低下は明らかですが、構造化された抽出や分類には十分だと思います。これがいわゆる「エッジAI」の舞台です。
• 文脈ウィンドウ：3.1の128kトークンでは、製品マニュアル全体を入力できます。実際には、約32k以降は品質が低下しますが、それでも昨年比で4倍になりました。

Mistral Nemo 見過ごされがちな優秀者

Mistralの12Bモデルは甘いポイントにあります：Llama 3.1 8Bより良い推論能力と、70Bよりも速さ。トレードオフはVRAMです。Q4_K_M量子化では約8GB必要なので、消費者向けGPUに収まります。

日本の資金不足企業なら、コードスイッチングを良く扱う二言語訓練により契約分析に使いたいかもしれません。

Google Gemma 2 予想外の挑戦者

GoogleはGemma 2（9Bと27B）を開放し、それは『優秀』です。

9BモデルがベンチマークでLlama 3.1 8Bに匹敵する一方で、量子化がより良好です：Q4_K_Mでは元の能力をより多く保持できます。ただし、キャッチはプロンプトフォーマットへの感度です。システムプロンプトテンプレートに正確に従わないと品質が急速に低下します。

MoonshotのKimi-K2シリーズは、中国からのジョーカーカード

もしローカルLLM空間を追跡しているなら、Moonshot AIやそのKimi K2モデルについて聞いたことがあるかもしれません。

アメリカまたは西ヨーロッパの開発者たちがLlama対Mistralで議論に没頭する一方で、Moonshotは静かにシリーズを発売し、特に多言語および長文タスクでは『より上位の能力』を持つモデルを提供しています。

私は、こう考えます。

Kimi K2の特筆すべき点は？

アリババが出資するMoonshotのKimi K2シリーズ（[2025年7月リリース]](https://www.cnbc.com/2025/07/14/alibaba-backed-moonshot-releases-kimi-k2-ai-rivaling-chatgpt-claude.html）は、長文脈理解と多言語性能（特に中国語、日本語、英語）に最適化されています。西側のモデルとは異なり、Kimi K2はバランスの取れたマルチリンガルデータセットでトレーニングされたため、グローバルな応用において強力な競争相手となっています。

主な特徴：

1. 初期バージョン（2025年7月リリース）では128kの文脈ウィンドウでしたが、9月のアップデート（特にkimi-k2-0905およびKimi-k2 Thinkingモデル）で256kに拡張されました。
2. ネイティブINT4量子化：「量子化認知トレーニング」によって、メモリコストを半分（INT4）に抑えつつ、ほぼ知能の損失なしで生成速度が倍になります。
3. 1兆パラメータ：合計1兆個のパラメータを持ちながら、単一のタスクでは320億個しか使用せず、効率性に優れています。比較として、OpenAIの最大公開モデルは現時点ではgpt-oss-120Bです。
4. 多言語での卓越性：ベンチマークでは、Kimi K2が中国語・日本語でLlama 3.1やMistralを上回り、英語でも競合するパフォーマンスを発揮しています。特にコードスイッチング（例：日本語契約書に英語の技術用語を含める場合）が必要なユースケースには最適です。

Kimi-k2 thinkingモデルは、複数ツール呼び出しや日本語対応など多くのタスクで私のおすすめモデルです。

うまくいかなかった点

• Phi-3：理論上は素晴らしいが、実際のタスクでは小さなモデルサイズが顕著に影響する。分類には適しているものの、生成には向かない。このモデルの使用例をあまり読んだことはないが、私が見る情報源に偏りがある可能性もある。
• Qwen-2：中国語は強みだが、少なくとも私個人の経験からすると、英語や日本語でのLlama/Mistralと比較して性能が劣る。Qwen3の方が改善されているものの、わずかに速度が遅い。
• Mixtral 8x22B：多くのローカル環境ではサイズが大きすぎる。ハードウェアを持っている場合は素晴らしい性能だが、ユーザー全体で見るとほんの一部に過ぎない。

【よくある質問集】皆さんが知りたいこと

私がOllamaやllama.cppについて話す際によく聞かれる質問をまとめました。

「量子化（Quantization）とは何か？どのバージョンをダウンロードすべきか？」

量子化はニューラルネットワークに対するロスレス圧縮です。モデルサイズと正確性の一部を犠牲にして、ハードウェア上で実行可能な能力を獲得します。命名規則は見た目には難解ですが（Q4_K_M, Q5_0, Q8_0）、原理は単純です。

• Q4_K_M: これは汎用的な推奨です。重要性に応じて圧縮された4ビット量子化。フル精度と比較して約2%の正確性低下がありますが、モデルサイズは1/4になります。8GB GPUでは、これがしばしば唯一選択できるオプションです。
• Q5_K_M: 少し高品質で、約20%大きくなります。VRAMの余裕がある場合に、医療や法律など正確性が重要なタスクで最後の精度を必要とする場合はこちらを選んでください。
• Q8_0: フル精度とほぼ区別がつかないほど高品質ですが、サイズも大きくなります。量子化の影響をベンチマークする目的以外では無意味です。
• IQ2_XS: 極端な圧縮。モデルは会話できるようになるものの、意味不明になります。実験用途以外には避けてください。

基本ルール：まず Q4_K_Mをダウンロード してください。特定のユースケースで明らかな品質問題が見られた場合は、Q5_K_Mに移行してください。深く考えすぎないでください。

「インターネット接続なしでこれらのモデルを使うことはできますか？」

はい。それが全てのポイントです。

一度ダウンロードすると、llama.cppもOllamaも完全にオフラインで動作します。私は海上10kmの高度で飛行機内で衛星データ料金を払わずに推論を行うことができました。《まだファインチューンはできません》なぜなら、私のノートパソコンを十分な電力を供給するコンセントに接続する必要があるからです（一部のフライトでは最大ワット数制限があります）。

注意点:

• 初期ダウンロードにはインターネットが必要です（明らかですが）。7B Q4_K_Mモデルは約4GB、70Bモデルは約40GBです。
• Ollamaのモデルライブラリの閲覧にはインターネット接続が必要で、ollama pullコマンドも接続がないと動作しませんが、一度モデルをダウンロードしてしまえば問題ありません。
• 一部の高度な機能（Ollamaのollama_web_fetchやollama_web_searchなど）は外部APIを呼び出しますが、核心となる推論処理はローカルで実行されます。
• クラウドモデルは使わないでください！ それにはインターネット接続が必要です。

実用的なセットアップ（2026年版）

前年からの推奨を更新した、現在私が使用している環境です。

開発/プロトタイピング用 (RTX Ada 2000 GPU 8GB RAM)

• Ollama + Llama 3.1 8B Q4_K_M
• Claude Code
• コード補完、ドキュメンテーション生成、デバッグ説明の作成に使用

現在ThinkPad P1 (96GB RAM, GTX Ada 2000 8GB GPU) 上でUbuntu 24.04を実行しています。コーディングではClaude Code（Anthropic設定）がデフォルトですが、用途に応じてClaude Code Routerで他のモデルと接続します。これらはクラウドモデルで、私のコードプロジェクトにとって最も強力で有用だと感じるからです。

ローカルモデル（gemma3:27b-cloudなど）は、メタディスクリプションや画像・投稿のAltテキストなど、素早い作業には依然として役立ちます。また、qwen3:8bは要約に優れており、日本語や中国語向けにも適しています。

本番環境用 (専用ミニPC, RTX 4060 16GB)

• llama.cpp server mode + Mistral Nemo 12B Q4_K_M
• Nginx リバースプロキシ
• 24時間365日稼働しており、内部ツール（サポートチケット分類、FAQ生成）に使用されています。Kafkaiも同様のセットアップを利用していますが、モデルやロジックは異なります。

実験用 (Raspberry Pi 5, 8GB)

• llama.cpp CPUのみ + Llama 3.2 3B Q4_K_M
• 約8トークン/秒ですが、自動化スクリプトのテストには十分です。

結論

地元のLLMエコシステムが安定化した。ツールはあらゆるものになろうとするのをやめ、信頼性に焦点を当て始めた。モデルは小さくなり、速くなり、より機能的になった。コミュニティは標準（GGUF, Q4_K_M）に収束し、そのまま使えるようになった。

もし元の投稿を読んで「これは有望だが苦痛だ」と思ったなら、今が再訪する時だ。設定にかかる手間は、「週末プロジェクト」から「コーヒーブレーク程度のタスク」に減少した。

エンジニア向けには、重要な洞察として以下がある。地元モデルはすべての用途でクラウドAPIを置き換えるものではないが、レイテンシ、プライバシー、コストが問題となる特定のワークフローでは不可欠になった。それらはRedisやPostgreSQLのように、特別化され、強力であり、理解する価値があるDevOpsキット内の別のツールと考えればよい。

そしてどうか、何よりも美しく優しいもののために、空港ラウンジのWi-Fiでモデルをダウンロードしないように！)