LLM 入門：実践ガイド（2026 年版）

まずループから始めましょう。テキストはトークンに変換され、トークンは Transformer を通過します。Attention がどの過去のトークンが重要かを決定します。ランタイムは KV キャッシュを保持するため、モデルは毎回会話全体を再計算する必要がありません。そしてモデルは次のトークンを選択し、これを繰り返します。

LLM の仕組み、モデルが 1 トークンずつ思考する方法、そしてローカルで実行する方法に関する実践的なガイド。

このループを理解すれば、ハードウェアとソフトウェアの選択についても、より合理的に考えることができるようになります。VRAM、量子化、コンテキスト長、チャットテンプレート、デコーディング、RAG、推論エンジン、モデル選択は、すべて同じメカニズムから導き出されます。

ループから始めよう：トークンが入力され、確率が出力され、一度に 1 つの次のトークンが生成される。重みはモデルが学習したパターンを示す。コンテキストはモデルが現在見ているものを示す。KV キャッシュはループを使いやすくするワーキングメモリである。ハードウェア、ランタイム、モデル選択は、モデルが従っているメモリ、コンテキスト、フォーマットルールを理解して初めて意味を持つ。

目標は、まずローカル LLM のメカニズムを直感的に理解し、その後、ハードウェア、ランタイム、推論、および 2026 年 5 月 21 日時点の最新 LLM 研究への実践的な道筋を提供することです。

焦点

これはモデルファーストのガイドです。メカニズムから始めます：推論、トークン、Transformer、アテンション、KV キャッシュ、プリフィル、デコード、デコード制御、モデルパッケージ、チャットテンプレート、モデルタイプ、ロングコンテキスト、RAG、エージェント、ファインチューニング、マルチモーダルモデル。

その後、ローカルデプロイメント層に移ります：ローカルが実際に意味するもの、量子化、VRAM 計算、ハードウェア層、ランタイムの選択、サービングモード、ライセンス、モデル選択、プライバシー、トラブルシューティング、ベンチマーク、セットアップパス、実用的なユースケース。

この順序は重要です。長いプロンプトがメモリを消費する理由を理解してから GPU を選ぶべきです。チャットテンプレートが重要な理由を理解してからモデルを評価するべきです。デコードが逐次的である理由を理解してからトークン / 秒を気にするべきです。

より深いハードウェアとソフトウェアのパスについては、セルフホスト LLM / ローカル AI を教える 3 部作シリーズがあります：

パート 1：LLM の GPU メモリ計算（2026 年版）
パート 2：ローカル AI ハードウェアのメモリ帯域幅（2026 年版）
パート 3：LLM およびローカル AI ハードウェアの推論エンジン（2026 年版）

最初の 2 つの記事では、ハードウェアの容量と帯域幅の計算について説明します。3 つ目では、そのハードウェアを使える推論に変えるソフトウェア層について説明します。この記事では、まずモデル側の基礎を提供し、メカニズムが明確になった時点で、それらのデプロイメント層を参照します。

LLM が実際に行うこと

モデルを実行することを推論と呼びます。標準的なデコーダーのみの LLM の場合、推論は同じループを何度も繰り返します：

テキストをトークンに変換する。
それらのトークンをモデルに入力する。
可能なすべての次のトークンのスコアを計算する。
デコードポリシーを使用して 1 つのトークンを選択する。
そのトークンをシーケンスに追加する。
モデルが停止するか、ユーザーが停止するか、トークン制限に達するまで繰り返す。

モデルは一度に全体の回答を書いているわけではありません。一度に 1 トークンずつ生成しています。新しいトークンはすべて、次のトークンに影響を与えるシーケンスの一部になります。

数学的には、モデルは学習された関数です：

f(θ, シーケンス) -> next_token の確率分布

ここで：

θ はモデルの重みを意味します。
シーケンスは、プロンプトとこれまでに生成されたトークンを意味します。
Logits はソフトマックス前の生のスコアです。
確率はソフトマックス後の正規化されたスコアです。
デコーディングはそれらの確率を 1 つの選択されたトークンに変換します。

これが、ローカル生成速度がトークン / 秒で測定される理由です。システムは、フォワードパスを繰り返し実行し、トークンを選択またはサンプリングし、KV キャッシュを更新し、続行します。

ここでは知覚が重要です。プリフィルが長いと、最初の単語が表示されるまでに長い待ち時間が発生します。デコードが遅いと、回答のストリーミングが遅くなります。ローカルビルダーはよくデコード速度にこだわります。なぜなら、それがユーザーが感じるものだからです。しかし、10K トークンのドキュメントを貼り付けたときに痛いのはプリフィル時間です。

トークン

LLM は生のテキストを単語として認識しません。トークンとして認識します：内部で整数 ID として表現されるテキストの小さなチャンクです。

トークンは次のようになります：

単語全体："hello"
単語の断片："inter"、"national"、"ization"
句読点
空白が接頭辞として付いた文字列
バイトレベルのフォールバック
特別な制御マーカー：<|user|>、<|assistant|>、、または

トークナイザーは、テキストをトークン ID に、トークン ID をテキストにマッピングします。一般的なトークナイザーファミリには、BPE スタイルのトークナイザーと SentencePiece スタイルのトークナイザーがあります。モデルファミリによって異なるトークナイザーを使用しており、これは重要です。4,000 語のドキュメントは、あるトークナイザーでは 5,000 トークン、別のトークナイザーでは 7,500 トークンになる場合があります。

語彙サイズも重要です。語彙サイズが大きいトークナイザーは、一部のテキストをより少ないトークンに圧縮できますが、埋め込みと出力射影のサイズも変更します。これが、トークン / 秒がモデルファミリ間で完全に比較可能ではない理由の 1 つです。

トークンが重要なのは、次のものを決定するからです：

コンテキストウィンドウに収まるテキストの量。
KV キャッシュのサイズ。
プロンプト処理中に発生するレイテンシ。
多言語またはコードが多いテキストが効率的かどうか。
モデルが特別なチャットマーカーを正しく認識するかどうか。

モデルのコンテキストウィンドウは、モデルが一度に処理できる最大トークン数です。2026 年現在、一般的なローカル対応モデルのコンテキストは、8K および 32K から、128K、256K、さらにはサーバークラスシステムでは 1M トークンまでさまざまです。

ただし、サポートされているコンテキスト長は、安価、高速、または同等に正確なコンテキストと同じではありません。技術的には 128K トークンを処理できるモデルでも、64K では速度が大幅に低下し、100K では一貫性が失われる可能性があります。実際に使用する予定のコンテキスト長は常にテストしてください。

トークンは作業単位です。これを理解すれば、ロングコンテキストは魔法のように見えなくなり、見積もり可能な請求書のように見え始めます。

役立つ演習：トークナイザーデモアプリを試して、テキストがリアルタイムでどのようにトークンに分割されるかを確認してください。

Transformer

最新の LLM のほとんどは、Transformer アーキテクチャに基づいています。ローカルチャット LLM のほとんどは、デコーダーのみの Transformer です：過去のトークンを参照しながら、次のトークンを予測します。

これより上のすべて、トークン、重み、設定、チャットテンプレートは、その下にある実際のエンジンのセットアップです。Transformer は数値を移動する骨格です。

簡略化された Transformer 層には以下が含まれます：

トークン埋め込み：トークン ID がベクトルになります。
位置情報：モデルにはトークンの順序が必要です。多くの最新の LLM は RoPE（Rotary Position Embeddings）を使用しており、表現を回転させて位置をエンコードします。
セルフアテンション：各トークン表現は、以前のトークン表現を参照し、何が重要かを決定します。
MLP / フィードフォワードブロック：表現を拡張および圧縮する高密度な非線形計算です。パラメータの大部分はここにあります。
層正規化と残差接続：これらは深いネットワークを安定させ、多くの層を通じて情報の流れを助けます。
出力射影：最終的な隠れ状態が語彙に対するロジットになります。

このレシピを数十回または数百回積み重ねると、言語モデルが得られます。

Transformer の要約：トークンはベクトルになり、アテンションがシーケンスを接続し、MLP が表現を再形成し、RoPE が位置を正確に保ち、最終的な射影が最後の隠れ状態を次トークンのロジットに変換します。

アテンション

アテンションとは、トークンが次の予測のためにどの過去のトークンが重要かを決定する方法です。また、ローカル推論がメモリに非常に敏感である理由の 1 つでもあります。

従来の MHA（マルチヘッドアテンション）は、多くのヘッドに対して個別のキー / バリュー状態を保存します。モデルに柔軟性を与えますが、KV キャッシュが大きくなります。

最新のローカルモデルでは、より効率的なアテンション設計がよく使用されます：

MQA：複数のクエリヘッドが 1 つのキー / バリューヘッドを共有します。メモリ効率は良いですが、表現力が低くなる可能性があります。
GQA：クエリヘッドのグループがキー / バリューヘッドを共有します。多くの最新のローカルモデルで一般的な中間点です。
MHA：フルマルチヘッドアテンション。強力ですが、ロングコンテキストではすぐにコストが高くなります。

FlashAttention や SDPA スタイルの実装などの最新カーネルは、アテンションメモリトラフィックを削減し、GPU のビジー状態を維持します。適切なアテンションカーネルを備えたランタイムは、同じモデルとハードウェアでも、そうでないものよりも劇的に高速になります。

これが、2 つの 7B モデルがロングコンテキストでまったく異なる動作をする可能性がある理由です。パラメータ数だけがすべてではありません。128K コンテキストの 7B MHA モデルは 24 GB GPU を圧迫する可能性がありますが、同じ宣伝コンテキストの 7B GQA モデルは余裕を持って収まる場合があります。

モデルを比較するときは、パラメータ数だけでなく、アテンションタイプ、KV ヘッド数、コンテキスト長、ランタイムサポートを確認してください。

KV キャッシュ

KV キャッシュは、生成中のモデルのワーキングメモリです。以前のトークンのキー / バリアテンション状態を保存するため、モデルは生成されたトークンごとに履歴全体を最初から再計算する必要がありません。

KV キャッシュがないと、生成は非常に非効率になります。KV キャッシュがあれば、生成は使用可能になりますが、キャッシュは次のものに比例したメモリを消費します：

トークン数 x 層数 x kv_heads 数 x head_dim 数 x 精度 x 2

x 2 はキーとバリューのためです。

古い Llama のような 7B MHA モデルの実用的な目安は、FP16 KV キャッシュでトークンあたり約 0.5 MiB です。つまり、4K トークンでは KV キャッシュだけで約 2 GiB のコストがかかる可能性があります。32K トークンでは、KV キャッシュだけで 16 GiB になる可能性があります。

新しい GQA / MQA モデルはこれを大幅に削減します。一部のランタイムは FP8 または INT8 KV キャッシュもサポートしています。2026 年のローカルユーザーには、これが実用的な圧縮の下限となることがよくあります。

8 ビット未満の KV キャッシュをデフォルトとして扱わないでください。KIVI、KVQuant、および新しい圧縮キャッシュカーネルなどの研究システムは、注意深いアルゴリズム、キャリブレーション、およびカスタムカーネルを使用すれば、2 ビットから 4 ビットの KV が機能することを示しています。これは、デスクトップランタイムで気軽に Q4 KV トグルを切り替えるのとは同じではありません。8 ビット未満では、特にコーディング、ツール呼び出し、JSON、ロングコンテキスト検索、および正確な過去のトークンが重要となるタスクについては、徹底的にベンチマークを行ってください。

また、KV キャッシュの量子化と投機的デコードを混同しないでください。DFlash および DDTree（非公式に DTree と略されることが多い）は、将来のトークンをドラフトして検証することで、デコードレイテンシを改善します。速度は向上しますが、KV キャッシュのメモリコストがなくなるわけではありません。

これが、モデルが空のプロンプトでは収まっても、長いドキュメントをロードするとクラッシュする理由です。重みは収まります。ワーキングメモリが収まらなかったのです。

プリフィルとデコード

LLM 推論には、プリフィルとデコードという 2 つの異なるパフォーマンス領域があります。

プリフィルは、モデルに与えたプロンプトを処理します。20,000 トークンのドキュメントを貼り付ける場合、モデルは最初の回答トークンを生成する前に、これらの 20,000 トークンを処理する必要があります。プリフィルは比較的並列化が可能なため、GPU は効率的に処理できますが、それでもコストがかかる可能性があります。

最初のトークンが表示されるまでの待ち時間は、通常、プリフィル時間です。

デコードは、新しいトークンを一度に 1 つずつ生成します。生成された各トークンはこれまでのシーケンスに依存するため、デコードははるかに逐次的です。ここでストリーミングのタイピング効果が発生し、通常、モデルが高速か低速かを決定するフェーズです。

長いプロンプトはプリフィルに悪影響を及ぼします。長い回答はデコードに悪影響を及ぼします。長い会話は KV キャッシュが増大するため、両方に悪影響を及ぼします。

チャットセッションでは、ターンごとにキャッシュが追加されます。会話を 16K トークンまで実行させると、生成された新しいトークンごとに 16K トークンすべてのメモリコストを支払うことになります。これが、無限の履歴を保持するチャット UI が最終的に遅くなったりクラッシュしたりする理由です。

デコーディング

モデルがロジットを生成した後、まだ何も書き込まれていません。可能なすべての次のトークンをスコアリングしただけです。デコーディングは、それらのスコアを 1 つの実際のトークンに変換し、そのトークンをコンテキストに追加し、ループを繰り返すポリシーです。

ランタイム、または推論エンジンは、いくつかの方法でトークンを選択できます。毎回最も確率の高いトークンを選択できます。可能性の高いトークンの絞り込まれたセットからサンプリングできます。繰り返しをペナルティできます。デリミタで停止できます。固定シードを使用して、同じプロンプトが再現可能な動作をすることもできます。

これらの選択はモデルの重みを変更しませんが、モデルの声、決定論、創造性、リスクプロファイル、およびループ傾向を変更します。

重要なノブは、3 つの実用的な質問に答えます：

ランダム性：どの程度の変動が許容されるか？
テールリーチ：サンプラーはどの程度低確率のトークンまで到達できるか？
境界：ループ、乱談、スキーマ違反、または暴走出力を防ぐものは何か？

正確な作業の場合は、狭く始めてください：低い温度、短い最大トークン制限、明示的な停止シーケンス、および出力が JSON やスキーマに一致する必要がある場合の制約付きデコード。クリエイティブな作業の場合は、より高い温度、top-p、および後でランク付けされる複数の候補を使用して、サンプラーにより多くの余地を与えてください。コーディングの場合は、最初のパスは控えめに保ち、意図的に探索する場合にのみ代替案をサンプリングしてください。

貪欲デコードが常に正確であるとは限りません。多くの場合、もろいです。貪欲デコーダーは、代替案を探索しないため、ループにはまったり、一般的な回答を生成したりする可能性があります。評価には、決定論的な設定を使用してください。アイデア出しには、モデルに息継ぎをさせてください。

モデルパッケージに含まれるもの

実行可能なローカル LLM は、1 つの大きな重みファイルだけではありません。モデルパッケージには通常、以下が含まれます：

アーキテクチャ / 設定：層数、隠れサイズ、アテンションタイプ、RoPE 設定、語彙サイズ、特殊トークン、コンテキスト長。
重み：学習されたパラメータ。多くの場合、safetensors、GGUF、GPTQ、AWQ、EXL2、またはその他のランタイム固有の形式で保存されます。
トークナイザー：テキストをトークン ID に、トークン ID をテキストに変換するルール。
チャットテンプレート：システム、ユーザー、アシスタント、ツール、推論メッセージの正確なマークアップ。
生成設定：温度、top-p、停止トークン、繰り返しペナルティ、最大トークンのデフォルト。
ライセンスとモデルカード：モデルの使用方法に関する法的および運用上の指示。

重みは最も大きなファイルですが、モデル全体ではありません。トークナイザー、設定、またはチャットテンプレートが間違っている場合、同じ重みでも壊れているように感じられます。

パッケージセクションは、一緒に移動する必要があるものを示しています。次のセクションでは、チャットテンプレートが人々が最も頻繁に壊す部分である理由を説明します。

チャットテンプレート

チャットモデルは、特定の会話形式でトレーニングされています。たとえば、次のような形式を期待する場合があります：

<|system|> あなたは役立つアシスタントです。<|user|> KV キャッシュについて説明してください。<|assistant|>

別のモデルは、次のような形式を期待する場合があります：

[BOS] [INST] KV キャッシュについて説明してください。[/INST]

また、ChatML スタイルのマーカーを使用するものもあります。特別な推論トークンを必要とするものもあります。ツール呼び出しの XML または JSON ラッパーが必要なものもあります。

間違った形式を使用すると、意味不明な出力、役割の混乱、システムプロンプトの無視、プロンプトの繰り返し、拒否の奇妙さ、ツール呼び出しの破損、ベンチマーク結果の悪化、そしてモデルが実際にはテンプレートにバグがあるのに、モデルが愚かであるという結論を引き起こす可能性があります。

ベストプラクティス：

Transformers を使用する場合は、トークナイザーの apply_chat_template を使用してください。
Harbor 対応のフロントエンド、llama.cpp、LM Studio、vLLM、または SGLang では、モデル固有のテンプレートを使用してください。
モデルが base、instruct、chat、reasoning、tool-tuned のいずれであるかを確認してください。
BOS / EOS トークンが正しいことを確認してください。
長くする必要がない限り、システムプロンプトは短くしてください。
ツールを使用する場合は、モデル / ランタイムが期待する正確なスキーマに従ってください。

ユーザーがモデルを切り替えられるアプリケーションを構築している場合は、テンプレートの切り替えも必要です。1 つのテンプレート形式をハードコーディングしてから、別の形式を期待するモデルをロードすることは、ローカルモデルの評価が悪くなる一般的な原因です。

テンプレートを API コントラクトとして扱ってください。間違えると、実際にテストしていると思っているモデルをテストしていることにはなりません。

モデルタイプ

<payload-platform id="blk_7" type="upload" />

すべての LLM が同じ動作に調整されているわけではありません。

ほとんどのユーザーにとって、デフォルトの出発点は、メモリに快適に収まるサイズの、最近の instruct / chat 調整済みモデルであるべきです。

理由がわからない限り、ベースモデルから始めないでください。ベースモデルは質問に答えるのではなく、プロンプトを完成させます。これらは、研究者、ファインチューナー、およびカスタムパイプラインを構築する人々に役立ちます。他のすべての人にとってはイライラするものです。

ベースモデルに「フランスの首都はどこですか？」と尋ねると、「パリの人口は？」と答える代わりに、「そしてパリの人口は？」と続ける可能性があります。

実用的な分割は簡単です：

ベースモデル：事前学習研究、ファインチューニング、カスタムパイプラインに適しています。
Instruct モデル：直接的な指示追従に適しています。
チャットモデル：ロールフォーマットを使用したマルチターン対話に適しています。
推論モデル：追加の思考トークンと検証がタスクに役立つ場合に適しています。
ツール調整モデル：構造化された呼び出し、JSON、または関数の使用が重要な場合に適しています。

ローカルが実際に意味するもの

ローカル LLM とは、その重みと推論ランタイムがユーザーの制御下にあるモデルです。どのモデルを実行するか、どのように実行するか、どのデータを参照するか、出力をどうするかをユーザーが決定します。

その自由には作業が伴います。あなたは運用チームになります。ダウンロード、アップデート、互換性、メモリ制限、セキュリティを処理します。何かが壊れたとき、提出するサポートチケットはありません。あるのはあなた、ログ、そしてドキュメントだけです。

ローカルは、次のことを意味する場合があります：

電話で実行される 2B パラメータモデル。
コンシューマー GPU で実行される 7B ～ 14B モデル。
ハイエンドワークステーションで実行される 30B ～ 70B モデル。
1 つ以上のデータセンター GPU で実行されるスパース MoE モデル。
vLLM、SGLang、TensorRT-LLM、llama.cpp、Harbor、LM Studio、またはカスタム PyTorch スタックを使用したプライベートデプロイメント。

重要な点：ローカルは、自動的にオフライン、プライベート、安全、安価、またはオープンソースを意味するわけではありません。それは、ユーザーが自分でモデルを実行していることだけを意味します。ローカルアプリでも、ホームに電話をかけることができます。モデルはウェイトがオープンでもオープンソースではない場合があります。モデルはローカルでも、ロードしても安全でない場合があります。量子化されたモデルはメモリに収まっても、回答が不十分な場合があります。

プライバシー、低レイテンシ、カスタム動作、オフライン運用、または大規模なコスト制御が必要な場合、このトレードオフには価値があります。絶対的に最高のモデル品質が必要で、それに合うハードウェアがない場合は、価値がありません。その場合、ホスト型 API が適切なツールです。

ローカル LLM は、1 つの方程式を理解したときに実用的になります：

ローカル LLM の成功 = モデル適合 + 正しいプロンプト形式 + 優れたランタイム + 現実的な評価

その他はすべて詳細です。詳細は重要です。

量子化

量子化は、メモリを削減し、場合によってはスループットを向上させるために、重みをより低い精度で保存します。

2026 年のローカルユーザー向けの経験則：

FP16 / BF16：メモリが豊富な場合の最高品質。評価のベースラインとして使用します。
Q8 / INT8：多くのタスクでほぼロスレスですが、まだ大きいです。VRAM があり、品質低下を最小限に抑えたい場合に適しています。
Q6 / Q5：適度な節約で優れた品質。強力な中間点です。
Q4：多くのチャットおよびドキュメントワークフローにおけるデフォルトのコンシューマースイートスポット。
Q3 / Q2：より大きなモデルをどうしても収める必要がある場合のみ。数学、コード、構造化出力、ツール使用が最初に低下します。

重みの量子化は KV キャッシュの量子化と同じではありません。重みの量子化はモデルを縮小します。KV キャッシュの量子化は、ライブコンテキストメモリを縮小します。

KV キャッシュについては、FP16 / BF16 をクリーンなベースラインとして扱い、FP8 / INT8 を実用的なローカル圧縮の下限として扱います。8 ビット未満は研究色が強く、ワークロードに依存します。実際のプロンプトで品質を測定した後にのみ使用してください。

量子化の失敗は、最初に数学、マルチステップ推論、コードの正確性、ツール使用の信頼性、JSON / スキーマ準拠、微妙な指示追従、ロングコンテキスト検索に現れます。

より高い精度の小さいモデルが、あまりにも少ないビットに押し込められた大きいモデルを打ち負かす可能性があります。パラメータ数にこだわらないでください。Q6 の 7B モデルは、Q2 の 13B モデルよりも推論タスクで優れており、メモリ使用量が少なく、実行速度が速い場合があります。

ファイル形式とロードの安全性

safetensors は、Python の pickle 動作なしでテンソルを保存するように設計された安全なテンソルシリアル化形式です。可能な場合は、特に PyTorch / Transformers モデルでは、safetensors を使用してください。

信頼できないソースからのランダムな .bin ファイルは避けてください。PyTorch の pickle ベースのロードは、逆シリアル化中に任意のコードを実行する可能性があります。ローカル AI セキュリティのルールその 1：見知らぬ人のモデルファイルを見知らぬ人のコード実行にさせないでください。

GGUF は、llama.cpp エコシステムのバイナリモデル形式です。llama.cpp、CPU 推論、Apple Silicon 推論、シンプルなローカルサーバー、ポータブル量子化モデル、または LM Studio などのデスクトップツールを使用する場合は、GGUF を使用してください。

ONNX は、標準化されたデプロイメントとハードウェア固有の高速化、特に通常の PyTorch スタック以外で役立ちます。Intel NPU、ARM デバイス、またはカスタムアクセラレータにデプロイする場合、ONNX は多くの場合、最も抵抗の少ないパスです。

TensorRT-LLM は、本番 GPU デプロイメントのための NVIDIA の高性能推論パスです。強力ですが、llama.cpp や Harbor よりも複雑です。通常、チェックポイントを TensorRT エンジンに変換する必要があり、時間と GPU メモリを消費しますが、構築されると優れたスループットを発揮します。

EXL2 / GPTQ / AWQ 形式は、特に大きなモデルを 1 つの GPU に詰め込むために、GPU に焦点を当てたローカル推論コミュニティで一般的です。

ファイル形式の選択は外見的なものではありません。どのランタイムがモデルをロードできるか、どの量子化を使用できるか、そしてどれだけ高速に実行されるかを決定します。

ランタイムとサービングモード

ランタイムは、モデルをロードして推論を実行するソフトウェアです。2026 年現在、ローカル LLM ランタイムエコシステムは成熟しており、有用で、断片化されています。

ローカルで実験している個人の場合、Harbor、LM Studio、または llama.cpp から始めてください。Harbor は、フロントエンド、バックエンド、およびサポートサービスが配線された完全なローカルスタックが必要な場合に最適です。LM Studio は、最も簡単なデスクトップファーストのパスです。llama.cpp は、ポータブルな低レベルの主力製品です。

チームまたはプライベートサービスの場合は、vLLM または SGLang を検討してください。最大の NVIDIA 本番パフォーマンスを得るには、TensorRT-LLM を調査してください。ブラウザまたはモバイルへのデプロイメントには、MLC または WebLLM を検討してください。

ランタイムの選択は、多くの場合、形式エコシステムにロックされます。llama.cpp は GGUF を意味します。vLLM と SGLang は通常、safetensors または Hugging Face チェックポイントを意味します。TensorRT-LLM は ONNX または最適化されたエンジンを意味します。最初にランタイムを選択し、次に適切な形式のモデルを見つけてください。

3 つの実用的なサービングモードがあります。

シングルユーザーローカルとは、1 人のユーザー向けのデスクトップアプリ、CLI スタック、またはコマンドラインサーバーを意味します。Harbor、LM Studio、llama.cpp サーバー、ExLlama / TabbyAPI、および小規模な Transformers スクリプトはすべてここに該当します。目標は迅速な反復です：運用プラットフォームを構築せずに、動作、速度、メモリ使用量、プロンプト形式を比較します。

チームまたはプライベート API とは、ワークステーションまたはサーバー上の OpenAI 互換エンドポイントを意味します。vLLM、SGLang、TensorRT-LLM、および llama.cpp サーバーはすべて、モデルサイズとスループットのニーズに応じてここに登場します。複数の人やジョブがモデルを共有するようになると、監視、プロンプト / バージョン管理、ルーティング、および現実的なレイテンシ測定が必要になります。

本番運用は別物だ。会話には、連続バッチ処理、プレフィックスキャッシュ、投機的デコード、ページ化アテンション、テンソル並列化、パイプラインマルチ GPU、量子化による推論、構造化出力、負荷分散、GPU 利用率、レイテンシのパーセンタイル、プロンプトキャッシュ、アドミッションコントロール、ログ取得、フェイルオーバー、プライバシー、そしてコスト管理が含まれる。

本番規模では、「モデルをロードできるか？」は簡単な問いだ。難しいのは、「実際のトラフィック下で、それを安定して提供できるか？」である。

ローカルモデルの VRAM 計算

主要なメモリ消費は三つある：

モデルの重み
KV キャッシュ
ランタイムオーバーヘッド

おおよその重みメモリの計算式は以下である：

weight_memory ~= parameters x bytes_per_parameter

便利な近似値：

FP16/BF16：パラメータあたり約 2 バイト。
INT8/Q8：パラメータあたり約 1 バイト。
Q4：パラメータあたり約 0.5 バイトに、フォーマットのオーバーヘッドが加わる。

次に、以下を加算する：

ランタイムオーバーヘッド：フレームワークバッファ、CUDA オーバーヘッド、メモリ断片化、一時的なテンソル。
KV キャッシュ：アクティブなコンテキスト内のトークンごとに増加する。
バッチ/並行処理用メモリ：各同時リクエストは独自のキャッシュを必要とする。
ビジョンエンコーダメモリ：画像もトークンになる。
投機的デコード用メモリ：ドラフトモデル、ドラフトヘッド、追加の検証構造は無料ではない。
アダプタメモリ：LoRA アダプタは小さいが、それでも現実的なメモリを消費する。

MoE モデルはさらに複雑な要素を加える。モデルはトークンごとにパラメータの一部のみを活性化するかもしれないが、通常は非アクティブなエキスパートもどこかでメモリに保持する必要がある。アクティブなパラメータは計算コストに影響する。総パラメータ数は依然としてローディングとキャパシティ計画に影響を与える。

現実的な見積もりは以下のようになる：

total_memory = quantized_weightsKV_cache_for_context runtime_overhead batch_or_concurrency_overhead safety_margin

ここに落とし穴がある：13B モデルを Q4 にした場合、8K コンテキストでは簡単に収まるが、KV キャッシュが 4 倍になる 32K では収まらなくなる。重みは変わっていない。コンテキストが変わったのだ。

10～20％のヘッドルームを残しておくこと。VRAM 使用率 99％での運用は、メモリ不足エラーや断片化による障害を招くこと間違いなしだ。

実践的なハードウェアの階層

以下は、量子化推論と妥当なコンテキスト長を前提とした、2026 年における実用的な目安である。正確な結果は、ランタイム、量子化方式、モデルアーキテクチャ、アテンションタイプ、コンテキスト長、OS/ドライバのオーバーヘッドに依存する。

2026 年の本格的なローカルユーザーの大半にとって、16 GB は快適に使える最小限の GPU グレード、24 GB はコストパフォーマンスに優れたエンスージアスト向けグレード、そして 48 GB 以上で、より強力なローカル環境の世界が広がる。

パフォーマンスは、メモリ帯域幅、GPU FLOPs、VRAM 容量、KV キャッシュサイズ、アテンション実装、量子化、バッチサイズ、プロンプト長、生成長、そしてランタイムの成熟度に依存する。

デコードは、多くの場合、メモリ帯域幅に制約される：GPU は、1 バイトあたりの計算が比較的少ない状態で、重みを繰り返しストリーミングする。プリフィルは、プロンプトを並列処理できるため、より計算負荷が高くなる。これが、同じ VRAM 容量を持つ 2 枚の GPU カードでも、メモリ帯域幅に大きな差があれば、トークン速度が大きく異なる理由である。

最も厄介なローカルセットアップは、モデルがほぼ収まるが、レイヤーを CPU にオフロードせざるを得ない場合である。技術的には動作するかもしれないが、トークン速度が劇的に低下する可能性がある。CPU オフロードは実験には許容できる。しかし、パフォーマンス戦略としてはならない。

収まるモデルを選ぶ

実際の問いは、「最良のモデルは何か？」ではない。「あなたのハードウェアで、実際のワークロードに勝てる最小のモデルは何か？」である。

まずは、実際に必要なコンテキスト長で快適に収まる、最近の instruct/chat モデルから始めよう。VRAM またはユニファイドメモリが 8 GB～12 GB なら、小さいモデルから始める。16 GB～24 GB なら、まずは 7B～14B クラスのモデルをテストする。48 GB 以上なら、より大きな Dense モデルや MoE モデルが現実的になる。

特定のチェックポイントに惚れ込む前に、このメモリゲートを使用すること：

weights + KV cache + runtime overhead <= 80 to 90 percent of available memory

その後、候補のモデルに対して同じ 20～50 のプロンプトを実行する。実際のタスクを含めること：コード編集、ドキュメント Q&A、JSON 出力、要約、ツール呼び出し、長いコンテキスト、その他必要なもの。回答品質、レイテンシ、メモリ使用量、テンプレートの信頼性、障害モードを測定する。

実用的なモデルの選択は、通常、5 つのチェックに集約される：

タスクへの適合性：チャット、コーディング、ドキュメント、エージェント、マルチモーダル、エッジ、またはファインチューニング。
メモリへの適合性：重み、KV キャッシュ、ランタイムオーバーヘッド、安全マージン。
インターフェースへの適合性：トークナイザー、チャットテンプレート、ストップトークン、ツールスキーマ、推論モード。
ランタイムへの適合性：あなたのランタイムが、このアーキテクチャ、量子化、コンテキスト長、サービングモードを適切にサポートしているか？
ライセンスへの適合性：実際に、あなたが使いたい場所で使用できるか？

リーダーボードは発見に役立つ。しかし、それはあなた自身の評価の代わりにはならない。あなたのワークロードこそが、重要なベンチマークである。

シンプルなローカルアシスタントには、最近の 7B～14B instruct モデル、Q4/Q5 量子化、正しいチャットテンプレート、8K～32K コンテキスト、そして Harbor、LM Studio、または llama.cpp を選ぶ。巨大なサイズよりも応答性を優先すること。

ローカルコーディングアシスタントには、十分な VRAM があるなら、コードに特化した 14B～32B モデルを選ぶ。低温度、リポジトリ検索、テスト実行、パッチベースのワークフローを使用する。ツールのないコードモデルは、半分の製品である。

プライベートドキュメントアシスタントには、強力な instruct モデル、ローカルな埋め込みモデル、リランカー、RAG パイプライン、引用強制、そして中～長コンテキストを選ぶ。200 ページの PDF を貼り付けて、うまくいくことを期待してはいけない。

推論セットアップには、推論用にチューニングされたモデル、余分なトークンの予算確保、低～中程度の温度、検証の追加、数学・コード・検索のためのツール使用を選ぶ。推論モデルはより多くのトークンを消費する。それに応じて予算を計画すること。

低リソース環境には、1B～4B モデル、Q4/Q5、短いプロンプト、構造化タスク、検索またはツール、タイトな出力スキーマを選ぶ。小規模モデルは、タスクが制約されている場合に有用になる。

速度を左右するもの

トークン/秒は、単一の要素で決まるわけではない。それは、モデルサイズ、メモリ帯域幅、計算能力、アテンションカーネル、コンテキスト長、量子化、バッチ処理、そしてランタイムの品質の結果である。

主なレバーは以下の通り：

メモリ帯域幅：デコードは多くの場合、モデルの重みを繰り返しストリーミングするため、帯域幅が単一ユーザーのトークン速度を支配する。
GPU FLOPs：プリフィルと大規模バッチは、より多くの並列計算を使用するため、そこでは FLOPs がより重要になる。
VRAM 容量：モデルまたは KV キャッシュが CPU にあふれると、パフォーマンスが劇的に低下する可能性がある。
アテンション実装：FlashAttention、SDPA、ページ化アテンション、ランタイム固有のカーネルは、速度とメモリ動作の両方を変える。
量子化：より小さな重みはメモリ転送を減らすが、過度な量子化は品質を損ない、場合によっては逆量子化のオーバーヘッドを追加する可能性がある。
バッチサイズと並行処理：バッチ処理はスループットを向上させるが、各アクティブシーケンスは KV キャッシュを必要とする。
プロンプト長：長いプロンプトはプリフィル時間を増加させる。
生成長：長い回答はデコード速度を露呈させる。
投機的デコード：EAGLE スタイルの手法、MTP、DFlash、DDTree は、サポートされている場合、ターゲットパスあたり 1 つ以上のドラフトトークンを検証できる。

厄介なセットアップは、「ほぼ収まる」セットアップである。モデルがレイヤーやキャッシュを CPU にあふれさせる場合、技術的には動作するかもしれないが、トークン速度は実用的なレベルから悲惨なレベルに落ち込む可能性がある。

使用を予定している正確なランタイム、量子化、コンテキスト長、プロンプト形状、ワークロードでベンチマークを取ること。BF16 のリーダーボードの数値は、あなたの Q4 ローカルスタックがどのような体感になるかを教えてはくれない。

長いコンテキスト

長いコンテキストは魔法のように聞こえる：128K、256K、あるいは 100 万トークンを 1 つのプロンプトに詰め込める。これは便利だが、現実的なコストが伴う。

コンテキストが増えるということは、より多くの KV キャッシュメモリ、より遅いプロンプト処理、より多くのアテンション計算、より困難な評価、そして無関係なテキストがモデルを混乱させる可能性が高まることを意味する。距離が離れるにつれて品質も低下する可能性がある。モデルは長いドキュメントの終盤をうまく処理できても、冒頭近くに埋もれた重要な詳細を見逃すかもしれない。

長いコンテキストは、ドキュメント全体の分析、コードベースの一部、法的または技術的なレビュー、文字起こしの要約、複数ファイルにわたる推論、そして検索が見逃したコンテキストに対する RAG のフォールバックに使用する。

長いコンテキストを検索の代わりとして扱ってはならない。それは補完的なものである。大規模なコーパスには RAG を使用し、最終的に選択された証拠には長いコンテキストを使用する。

実用的な習慣が役立つ：

重要な指示は冒頭と終盤に配置する。
セクションヘッダーと区切り文字を使用する。
ソースチャンクに紐づいた引用を要求する。
無関係な履歴を圧縮する。
無限のチャット履歴の代わりにサマリーメモリを使用する。

長いコンテキストは、無料のノート代わりではなく、高価なアテンションと考えること。

マルチモダリティ

マルチモーダルローカルモデルは、テキストに加えて、画像、場合によっては音声や動画も受け入れる。最新のオープンウェイトのエコシステムには、これらのモデルがますます含まれている。

隠れたコストは、テキスト以外の入力もトークンになることだ。ビジョンエンコーダはメモリを追加消費する。画像パッチはコンテキストを消費する。音声や動画は、入力予算を爆発的に増加させる可能性がある。また、マルチモーダルテンプレートは、テキストのみのテンプレートよりも誤りが発生しやすい。

単一の高解像度画像は、コンテキストウィンドウ内で数千ものトークンを消費する可能性がある。ローカルでマルチモーダルモデルを実行する場合、画像トークンをテキストトークンと同じようにカウントすること。どちらも同じ予算から消費される。

小型の VLM は、視覚的な詳細を幻覚することがある。OCR の信頼性は様々である。グラフや表は依然として難しい。本格的なドキュメントや画像のワークフローでは、実際のサンプルで評価すること。簡単な写真のデモを見て、請求書抽出の品質を信用してはいけない。

2026 年のローカルモデル事情

モデル事情は急速に変化する。2026 年 5 月 21 日現在、ローカル LLM ユーザーは、「たった一つの最良のモデル」ではなく、ファミリーとエコシステムの観点で考えるべきである。

Qwen 3.5 / Qwen 3.6 は、主要なオープンウェイトファミリーである。なぜなら、スタック全体をカバーしているからだ：ラップトップ向けの小型モデル、ワークステーション向けの Dense 中規模モデル、マルチ GPU サービング向けの MoE モデル、FP8 バリアント、長いコンテキスト、多言語対応、コーディング、ツール、そしてエージェントワークフロー。実用的な要点は単純だ：ラップトップでの実験から本格的なローカルサービングまでをカバーする単一のエコシステムを求める場合、Qwen は強力なデフォルトのファミリーである。

Gemma 4 が重要なのは、Google DeepMind がこのファミリーを実用的なローカルデプロイメントに向けて推し進めているからである：効率的なエッジモデル、より大規模な Dense モデルと MoE オプション、マルチモダリティ、大規模モデルでの長いコンテキスト、幅広い言語サポート、強化されたコーディング/エージェント動作、Apache 2.0 ライセンス。この組み合わせにより、商用利用やデバイス側へのデプロイが重要な場合に、テストする価値がある。

Kimi / Moonshot AI、GLM / Z.ai、DeepSeek、MiniMax、そして Mistral も追跡すべきコアファミリーである。Kimi は、長期間のコーディング、マルチモーダル推論、ツール使用、エージェントワークフローに関連する。GLM は、コーディングエージェント、長期間タスク、MoE システム、デプロイメント指向のモデルリリースにおいて重要である。DeepSeek は、大規模 MoE システム、Multi-head Latent Attention、DeepSeekMoE、FP8 サービングパス、スパースアテンション、高スループットのセルフホスティングにより、影響力を持ち続けている。MiniMax は、実用的なエージェントワークロードと推論効率の高い MoE モデルで注目に値する。Mistral は、そのラインナップがジェネラリスト、コーディング、推論、マルチモーダル、専門的なユースケースを強力なデプロイメントサポートとともにカバーしているため、依然として重要である。

Nemotron 3 は、NVIDIA ハードウェア上でプロダクショングレードのエージェントシステムを実現するための、NVIDIA によるオープンモデルファミリーである。このファミリーには、Nano、Super、Ultra サイズが含まれ、ハイブリッド Mamba-Transformer MoE 設計を採用し、TensorRT-LLM、NIM、Dynamo、Blackwell NVFP4/FP8 パス、そしてエンタープライズエージェントデプロイメントと密接に関連している。これをカジュアルなデスクトップチャットファミリーというよりも、NVIDIA がオープンウェイトのサービングスタックをどこに向かわせたいかというシグナルとして捉えること。

オープンウェイト AI は、もはや Llama 対その他すべて、ではない。あなたはエコシステムを選んでいるのだ：重み、ライセンス、トークナイザー、テンプレート、量子化、ランタイムサポート、サービングパス、コミュニティツール、そして障害モード。

Qwen 27B Dense モデル

Qwen 3.5 / 3.6 27B（Dense）は、コーディング、多言語対応、ツール使用、思考/非思考モード、長いコンテキストに関心のあるローカルユーザーにとって、最も実用的なパブリックウェイトオプションの一つである。Qwen 3.5 27B および Qwen 3.6 27B のモデルカードには、OpenAI 互換のサービングパス、思考モードのデフォルト、ツール使用、最大 262,144 トークンのコンテキスト長、そしてサポートされているフレームワークでの YaRN によるより長いコンテキスト拡張について記載されている。

Qwen は、2x RTX 3090 セットアップにおいて、ランタイムがコーディング、エージェント、または多言語カバレッジ向けに正しく構成されている場合、強力なデフォルトとなる。

推論研究

2026 年のフロンティアは、モデルの品質だけではない。推論効率も同様に重要である。PagedAttention は、サービングにおける KV キャッシュメモリの無駄を攻撃する。FP8 KV キャッシュは、vLLM などのシステムにおいて、現在では実用的なランタイム機能となっている。DFlash と DDTree は、ブロック拡散ドラフトモデルとドラフトツリーを用いた投機的デコードを探求している。NVFP4 も、NVIDIA ハードウェア上では注目に値する。なぜなら、サポートされているスタックにおける実用的なデプロイメントの議論を変えるからである。

これらの一部はプロダクションレディである。一部はまだ研究段階である。一部は、あなたのランタイムがそれをクリーンにサポートしている場合にのみ意味を持つ。論文上の高速化を、デスクトップアプリのチェックボックスとして扱ってはならない。

障害モードとその修正

ローカル LLM の障害のほとんどは神秘的なものではない。通常、メモリ適合性、フォーマット、ランタイムサポート、デコード設定、または検索品質に起因する。

メモリ不足：重み、KV キャッシュ、ランタイムオーバーヘッド、またはバッチサイズが収まらない。より小さなモデルを使用する、コンテキストを減らす、バッチ/並行処理を減らす、より良い量子化を選ぶ、またはより多くのヘッドルームを残す。

支離滅裂な出力や役割の混乱：チャットテンプレート、トークナイザー、BOS/EOS トークン、推論モード切り替え、またはツールスキーマが間違っている。モデル品質のせいにする前に、モデルカードとランタイムテンプレートを確認すること。

最初のトークンが遅い：プリフィルにコストがかかる。プロンプトを短くする、プレフィックスキャッシュを使用する、検索を改善する、コンテキストを減らす、またはより高速なランタイムを使用する。

ストリーミングが遅い：デコードがボトルネックである。メモリ帯域幅、量子化、CPU へのスピル、アテンションバックエンド、投機的デコードのサポート、そしてモデルが単にハードウェアに対して大きすぎるかどうかを確認する。

ドキュメントへの回答が悪い：おそらく検索が失敗している。解析されたテキスト、チャンク境界、メタデータ、上位 k 件の検索、リランキング、引用の根拠を検査する。

JSON やツール呼び出しがうまくいかない：より低い温度、制約付きデコード、より厳密なスキーマ、より良い例、そしてツール使用にチューニングされたモデルを使用する。

繰り返しループ：温度や top-p を下げる、繰り返しペナルティを追加する、ストップトークンを確認する、テンプレートが原因でモデルが自身の回答を新しいプロンプトとして認識していないか確認する。

まずは基本的なチェックから始めること。それらはモデルを変更するよりも多くの問題を解決する。

スタックの成長させ方

初級者：最も簡単で便利なセットアップ

Harbor または LM Studio、最近の 4B～9B instruct モデル、Q4 量子化、8K～32K コンテキスト、そして内蔵のチャット UI を使用する。同じサイズクラスの 2～3 つのモデルをダウンロードし、同じプロンプトで比較する。

目標：プロンプティングを学び、モデルを比較し、速度とメモリを理解し、最初はカスタムコードを避ける。

中級者：開発者セットアップ

llama.cpp または Transformers、GGUF または safetensors、OpenAI 互換のローカルサーバー、シンプルな RAG パイプライン、そして小さな評価セットを使用する。チャット UI だけではなく、実際のアプリケーションやスクリプトからローカルサーバーを呼び出す。

目標：ローカルアプリを構築し、検索をテストし、品質を測定し、localhost からサービスを提供する。

上級者：プライベートサービングセットアップ

vLLM または SGLang、1 台以上の GPU、OpenAI 互換の API、監視、プロンプト/バージョン管理、評価スイート、リランキングを伴う RAG、そしてツールサンドボックスを使用する。

目標：実際のユーザーまたは内部ワークフローにサービスを提供し、スループットとレイテンシを最適化し、安全性と可観測性を維持する。

エキスパート：カスタム最適化

TensorRT-LLM、カスタムカーネル、特殊なランタイム、量子化実験、投機的デコード、マルチ GPU 並列化、ファインチューニング、蒸留、そして本番評価を使用する。

目標：エンジニアリング時間を推論効率と引き換えにし、コストを削減し、大規模での品質を向上させる。

プライバシーは自動的ではない

ローカル LLM はプライバシーを向上させる。なぜなら、プロンプトと出力を自身のハードウェア上に留めておくことができるからだ。しかし、ローカルであることが自動的にセキュアであることを意味するわけではない。

脅威には、悪意のあるモデルファイル、pickle ベースの重み読み込み、信頼できない trust_remote_code、取得したドキュメントへのプロンプトインジェクション、ツール呼び出しの悪用、ログによる機密情報の漏洩、デスクトップアプリからのテレメトリ、ブラウザ拡張機能やプラグイン、重要な設定におけるモデルの幻覚、ライセンス違反、そしてファインチューニング中のデータ汚染が含まれる。

実行可能なローカル AI セキュリティのベースラインには、4 つの習慣がある：

慎重にロードする：信頼できるソースからの safetensors または GGUF を優先し、信頼できない .bin ファイルを避け、安易に trust_remote_code を有効にしない。
境界を設定して実行する：非特権ユーザー、エージェント用のコンテナまたはサンドボックスを使用し、オフラインプライバシーが重要な場合はネットワークアクセスを無効にする。
機密情報を保護する：クレデンシャルをプロンプトや RAG インデックスに含めず、デスクトップアプリのテレメトリ設定を確認し、ツール呼び出しを実行前に検証する。
重要なものをバージョン管理する：モデル、プロンプト、アダプタ、ランタイム、量子化のバージョンを追跡し、プライバシー上の大惨事を引き起こさない範囲でデバッグに十分なログを記録する。

ローカル AI のセキュリティは、ほとんどが退屈な運用上の規律である。それは同時に、ランダムなチェックポイントをダウンロードし、それを root で実行し、ローカル AI をローカルな侵害に変えてしまうことを避ける方法でもある。

重要なベンチマーク

実際に実行するスタックをベンチマークすること。モデルの BF16 リーダーボードスコアは、あなたの Q4 ローカル環境の現実ではない。

品質、レイテンシ、メモリ、信頼性、運用適合性を測定する：

品質：一般的なベンチマークだけでなく、実際のタスクにおける正しさ。
レイテンシ：最初のトークンまでの時間、デコードのトークン/秒、エンドツーエンドの時間。
メモリ：重みメモリ、KV キャッシュの増加、ピーク VRAM、負荷時のヘッドルーム。
フォーマット：チャットテンプレートの正確性、JSON/スキーマの成功率、ツール呼び出しの信頼性、ストップトークンの動作。
検索：引用の忠実性、回答の根拠付け、証拠欠落時の動作、リランカーの影響。
運用：起動時間、ウォームアップ動作、クラッシュリカバリ、ログ記録、プライバシー、バージョン追跡。

30～100 の代表的なプロンプトからなる小さな評価セットを作成する。期待される回答や採点基準、レイテンシとメモリの測定値、障害カテゴリ、RAG 固有の根拠チェック、関連する場合の JSON 準拠チェック、そして曖昧なタスクのための人間によるレビューを含める。

そしてモデルを比較する。リーダーボードにあなたのローカルスタックを選ばせてはいけない。

ローカルモデルによるコーディング

コーディングはローカル LLM の最良のユースケースの一つである。なぜなら、プロンプトにはプライベートなコードが含まれることが多く、レイテンシが重要であり、イテレーションが頻繁であり、API コストが急速に増加する可能性があり、ローカルモデルはエディタ、シェル、grep、テストランナー、パッチワークフローと統合できるからだ。

最も強力なローカルコーディングセットアップは、裸のチャットボットではない。それは、対象を絞ったリポジトリコンテキスト、コードベースの検索、ファイルパス、関連スニペット、テスト実行、そしてパッチループに接続された、コード処理可能な instruct モデルである。

デコードは決定論的または低温に保つこと。曖昧なアドバイスではなく、パッチを要求すること。テストを自動的に実行すること。実際のバグやタスクの小さな評価セットを維持し、新しいモデルが実際に優れているかどうかを判断できるようにすること。

ローカルモデルに、レビューなしで大規模なコードベースを書き換えさせてはいけない。ローカルだからといって、コーディングエージェントが賢くなるわけではない。コンテキストがプライベートになり、ループが安価になり、統合を制御しやすくなるだけである。

ローカルエージェントにはガードレールが必要

ローカル LLM は、ツールを使用できるようになると、はるかに有用になる：ファイル検索、シェルコマンド、ブラウザ自動化、データベース、コード実行、カレンダー、チケットシステム、内部 API、ベクトルデータベース、ホームオートメーション、ロボティクス、エッジデバイスなど。

ツール使用はセーフティモデルを変える。幻覚を見るチャットボットは厄介だ。ファイルシステムにアクセスできるエージェントはものを削除できる。ブラウザアクセスを持つエージェントは機密情報を漏洩させる可能性がある。シェルアクセスを持つエージェントは、あなたがログを読むよりも速くマシンを破損させることができる。

ローカルエージェントの安全性には4つの層がある。エージェントに、実際に必要なディレクトリ、API、ネットワークアクセス、クレデンシャルだけを与えることで、エージェントを厳密にスコープする。サンドボックス、コンテナ、最小権限ユーザー、破壊的なアクションへの確認、スキーマ検証されたツール引数を用いて実行を制約する。取得されたドキュメント、ウェブページ、チケット、メールにはプロンプトインジェクションが含まれる可能性があるため、入力を敵対的なものとして扱う。ツール呼び出し、モデルバージョン、プロンプト、承認を、機密情報をログにダンプすることなく記録することで、監査証跡を維持する。

構造化出力は役立つが、セキュリティの境界にはならない。JSON スキーマ、制約付きデコード、関数シグネチャは、ツール呼び出しの検証を容易にする。しかし、それらはモデルがリクエストを理解したこと、安全なアクションを選択したこと、または注入された命令を回避したことを証明するものではない。

本格的なツール使用には、モデルの外部にポリシーチェックを配置すること。

RAG は巨大なプロンプトに勝る

RAG とは Retrieval-Augmented Generation（検索拡張生成）の略である。すべての情報をプロンプトに詰め込む代わりに、ナレッジベースから関連するチャンクを取得し、それらのチャンクだけをモデルに与える。

優れたローカル RAG システムは、通常、ドキュメント取り込み、解析、チャンキング、埋め込み、ベクトルインデックス、検索、リランキング、プロンプト構築、回答生成、根拠チェック、そして評価から構成される。各段階が障害点となる。

解析が悪ければ、テーブルはゴミになる。チャンキングが悪ければ、回答が境界をまたいで分割される。検索が悪ければ、無関係な段落が返される。リランキングが悪ければ、正しい答えが 20 位に埋もれる。優れたモデルでも、受け取ったことのない証拠から確実に回答することはできない。

ほとんどの悪い RAG システムの原因は LLM ではない。チャンキング、検索、リランキング、そして評価が悪いのだ。

チャンキング戦略は静かな殺し屋である。オーバーラップのない固定サイズのチャンクは、文を分割し、コンテキストを失う可能性がある。セマンティックチャンキングや、親ドキュメント検索を用いた階層的チャンキングは、しばしばより効果的だが、普遍的な解はない。実際のドキュメントでチャンクサイズ、オーバーラップ、分割ルールを評価する必要がある。

優れたリランカーは、まずまずの検索結果を救済できる。しかし、取り込み中に回答を失ったチャンクを、リランカーが修正することは決してない。

ドキュメントとナレッジワーク

プライベートドキュメントにおいて、ローカル LLM は輝く：会議の文字起こしの要約、契約書レビュー、技術文書 Q&A、研究ノートの統合、メールの下書き、ポリシー検索、社内サポートアシスタント、コンプライアンスワークフローはすべて、ソース資料をそれを所有するマシンまたは組織の近くに保つことで恩恵を受ける。

ワークフローは単純だが、容赦がない。ドキュメントを注意深く解析し、ページとセクションのメタデータを保持し、セマンティックにチャンクし、埋め込みとリランカーを使用し、引用を要求し、回答をソースから、そして一般的な推論から分離し、引用の忠実性を評価する。

モデルがあなたのドキュメントの内容を知っていると想定してはいけない。モデルが知っているのは、あなたがプロンプトに入れたり、コンテキストとして取得したりした情報だけである。

会議の文字起こしでは、発言者ラベルとタイムスタンプを保持する。契約書レビューでは、任意のトークン数ではなく、条項やセクションごとにチャンクする。技術文書 Q&A では、モデルが正確にソースを引用できるように、取得したチャンクにページ番号やセクションアンカーを含める。

ドキュメント作業では、パーサーと検索モデルは、モデル自体と同じくらい重要である。

エッジデプロイメント

小型モデルは、スマートフォン、ラップトップ、ロボット、IoT ゲートウェイ、工場デバイス、車両、医療機器、オフラインの現場機器、そしてブラウザアプリでますます有用になっている。エッジは、単にワークステーションの小型版ではない。異なる制約条件のセットを持つ。

エッジデプロイメントの現実

エッジデプロイメントは、低メモリ、低電力、熱制限、断続的な接続、プライバシー要件、リアルタイムレイテンシ、小さなコンテキストウィンドウ、そして予測可能なフォールバック動作によって支配されています。そうしたデバイスでは、小型で信頼性の高いモデルが、大型で脆弱なモデルよりも優れています。

実用的なエッジセットアップでは、多くの場合、0.5B から 4B のモデル、アグレッシブな重み量子化、小さなプロンプト、固定スキーマ、ツール連携ワークフロー、ローカル埋め込み、キャッシュを使用し、不要なチャット履歴は保持しません。

接続が切れたとき、動作し続けるローカルモデルは、失敗する大規模モデルよりもはるかに価値があります。ローカル AI の未来は、巨大なワークステーションモデルだけではありません。データの近くで有用な作業を行う小型モデルもその未来の一部です。

ローカル LLM 運用マニュアル

このセクションを、ローカルモデルを実際の作業で信頼する前の最終確認として使用してください。

選択と適合：タスクに適したモデルファミリを選び、ライセンスを読み、ハードウェア要件を確認し、量子化レベルを選択し、総メモリ使用量を見積もります。重みのサイズだけで止まらないでください。KV キャッシュ、ランタイムオーバーヘッド、バッチ/同時実行数、および安全マージンを含めてください。

読み込みとフォーマット：信頼できるソースからの Safetensors または GGUF を優先し、信頼できない pickle ベースのファイルを避け、トークナイザとチャットテンプレートを確認し、コンテキスト長を意図的に設定し、タスクに適したデコードパラメータを選択します。テンプレートが間違っていると、評価は無効になります。

評価と運用：代表的なプロンプトでテストし、最初のトークンまでの時間とデコード速度を測定し、ピークメモリを追跡し、RAG 追加前に検索を評価し、エージェント追加前にツールをサンドボックス化し、より単純な方法が失敗した場合にのみファインチューニングを行います。

重要なものすべてをバージョン管理：モデル、量子化、ランタイム、プロンプト、チャットテンプレート、アダプタ、埋め込みモデル、リランカ、評価セット、ハードウェアプロファイル。ローカルシステムは、実行した内容を再現できる場合にのみ、制御が容易になります。

ファインチューニング

ファインチューニングは、追加データでトレーニングすることでモデルの動作を変更します。ローカルユーザーにとって最も重要な手法は、LoRA と QLoRA です。

LoRA はベースモデルを凍結し、小さな低ランクアダプタの重みをトレーニングします。これにより、トレーニング可能なパラメータが減少し、複数の軽量アダプタを維持できます。QLoRA はこれを拡張し、凍結された 4 ビット量子化モデルを介して LoRA アダプタにファインチューニングします。

ファインチューニングは、一貫したライティングスタイル、ドメイン固有の出力形式、反復的な分類または抽出動作、ツール呼び出し形式の信頼性、専門的なアシスタントペルソナ、RAG では解決できないドメイン適応、または狭いタスクにおける小型モデルのパフォーマンス向上が必要な場合に行います。

最初にファインチューニングをしてはいけません。次の順序を試してください：正しいチャットテンプレート、より良いプロンプト、より良いモデル、より良いデコード、RAG、リランキング、少数ショット例、そしてファインチューニング。

「モデルが私のドメインを理解していない」ように見える問題のほとんどは、実際には「プロンプトが曖昧」、「テンプレートが間違っている」、または「検索が機能していない」ことが原因です。

適切なファインチューニング計画には、クリーンなデータ、トレーニング/検証/テスト分割、ベースライン評価、明確なターゲット動作、安全性レビュー、過学習チェック、回帰評価、アダプタのバージョン管理、ライセンスレビュー、およびロールバック計画が含まれます。

オープンウェイトがオープンソースを意味しない

2026 年において、「オープンモデル」という言葉はしばしばいい加減に使われます。オープンウェイト、ソースアベイラブル、オープンソース、ローカル互換性を区別する必要があります。

オープンウェイトは通常、重みをダウンロードできることを意味します。自動的に、そのモデルを商業的に使用できる、自由に変更できる、その出力でトレーニングできる、任意の規模でデプロイできる、または帰属表示要件を無視できるということを意味するわけではありません。

ソースアベイラブルは、コードまたは重みが閲覧可能であることを意味します。必ずしもライセンスがオープンソースであるとは限りません。

オープンソース AI モデルは、より強力な主張です。OSI の Opensource AI Definition は、AI システムにアーキテクチャ、パラメータ/重み、推論コード、およびパラメータの導出に使用された十分なデータ情報とコードを含めることを求めています。これは、「重みが Hugging Face にある」という基準よりもはるかに高いハードルです。

一見寛容に見えるライセンスでも、以下のような制限が含まれている場合があります：競合利用の禁止、出力でのトレーニングの禁止、一定規模以上のデプロイメントの禁止、地理的除外、帰属表示要件、特許条項、派生物に対するコピーレフト的な義務。

ルール：モデルを商業的に使用する前に、モデルカードとライセンスを必ず読んでください。モデルが優れており、ダウンロード可能で、ローカルで実行可能であっても、法的またはデプロイメントの制約に適合しない可能性があります。

用語集

モデルとチューニング用語

アクティブパラメータ: MoE モデルでは、特定のトークンに対して一部のパラメータのみが使用されます。モデルは数千億の総パラメータを持ちながら、トークンあたりのアクティブパラメータははるかに少ない場合があります。
アダプタ: LoRA などを通じてベースモデルに追加される、トレーニング可能な小さなモジュール。
ベースモデル: チャットや指示追従のために特別にチューニングされていない、事前トレーニングされたモデル。
ファインチューニング: ターゲットドメインや出力スタイルに合わせてモデルの動作を変更する追加トレーニング。
インストラクトモデル: 指示に従うようにチューニングされたモデル。
LoRA / QLoRA: 低ランクアダプタを使用する効率的なファインチューニング手法。QLoRA は量子化されたベースモデルを介してトレーニングします。
MoE: Mixture of Experts。選択されたエキスパートサブネットワークのみがトークンごとに活性化されるスパースアーキテクチャ。
重み / パラメータ: モデル内部の学習された数値。

推論メカニクス

BOS / EOS: シーケンス開始トークンとシーケンス終了トークン。
チャットテンプレート: システム、ユーザー、アシスタント、ツールメッセージを表現するためのフォーマット。
コンテキストウィンドウ: モデルが一度に処理できる最大トークン数。
デコード: モデルが新しいトークンを 1 つずつ生成するフェーズ。
DFlash: ブロック拡散を使用して並列ドラフトを行う、2026 年の投機的デコード手法。
DDTree / DTree: ブロック拡散分布からドラフトツリーを構築し、効率的に検証する投機的デコード手法。
GQA / MQA: KV キャッシュサイズを削減し、推論効率を向上させるアテンションのバリエーション。
推論: モデルを実行して出力を生成すること。
KV キャッシュ: 過去のトークンに対するキー/バリューアテンション状態の保存。
プリフィル: モデルが生成前に入力プロンプトを処理するフェーズ。
RoPE: 最新の LLM で一般的な位置エンコーディング手法。
投機的デコード: より安価なドラフターがトークンを提案し、ターゲットモデルが検証する高速化手法。
トークナイザ: テキストをトークン ID に変換し、また逆に変換するコンポーネント。
Top-p / Top-k / 温度: トークン生成のためのサンプリング制御。

検索、ファイル、およびサーバ

AWQ: アクティベーション対応の重み量子化。
埋め込みモデル: テキストを検索/取得用のベクトルに変換するモデル。
FP8 KV キャッシュ: 一部のランタイムでサポートされる実用的な 8 ビット KV キャッシュ圧縮モード。
GGUF: llama.cpp で多用されるモデルファイル形式。
PagedAttention: vLLM スタイルのサーバで使用される KV キャッシュメモリ管理手法。
量子化: メモリを節約し効率を向上させるために数値精度を低下させること。
RAG: Retrieval-Augmented Generation。関連する外部コンテキストを取得し、モデルに提供します。
リランカ: 取得されたパッセージを関連性で再順序付けするモデル。
Safetensors: pickle ベースの実行リスクを回避する、より安全なテンソルシリアライゼーション形式。

最後に

ローカル LLM エコシステムには、コンパクトなエッジモデル、高性能な 7B から 32B のコンシューマモデル、大規模な MoE オープンウェイトシステム、マルチモーダルモデル、長期コンテキストモデル、ローカル推論モデル、成熟した推論ランタイム、そしてますます高性能になるプライベートサービングスタックが含まれています。

しかし、基本は変わりません。モデルは一度に 1 トークンを予測すること、トークンは単語ではないこと、重みだけがモデル全体ではないこと、チャットテンプレートが重要であること、KV キャッシュが隠れたメモリコストであること、量子化はトレードオフであること、長期コンテキストは無料ではないこと、RAG の品質は検索に依存すること、ファインチューニングには評価が必要であること、そしてローカルプライバシーにもセキュリティの規律が必要であること。

ローカルモデルをうまく実行するために神話は必要ありません。必要なのは、何がメモリに収まるか、モデルがどのテンプレートを期待するか、ランタイムがどのように動作するか、そして評価があなたの重視する作業に合致しているかを知ることです。

ローカル LLM は、主にメモリ計算とフォーマットと評価です。これらを正しく理解すれば、スタックの残りの部分をはるかに簡単に推論できるようになります。

それでは、また次回お会いしましょう。

-Ahmad