10月30日、Tom's Hardwareが「A primer to key LLM concepts」と題した記事を公開した。「なぜ70BモデルがVRAM 4GBのマシンで動くのか」「コンテキストウィンドウが広いほど賢いのか」——ローカルLLMを実際に動かそうとすると、こうした疑問に直面する。この記事では、LLMを理解・運用する上で押さえておくべき主要概念（KVキャッシュ・量子化・推論の仕組みなど）を体系的に解説している。
NvidiaのRTX Spark（2025年初頭に発表されたGeForce 50シリーズの一角で、ローカルAI推論向けの大容量VRAMを特徴とするコンシューマ向けGPU）をはじめ、ローカルでAIモデルを動かすハードウェアの選択肢が急速に広がっている。それに伴い、LLM関連の専門用語も次々と登場している。以下では、実際にモデルを動かす・選ぶ際に必要になる主要概念を整理する。
KVキャッシュ——「再計算しない」ための仕組み
エンジニアが最も実務的に関わることになるのがKV（Key-Value）キャッシュだ。
LLMはトークンを生成するたびに、会話の先頭から全トークンを解析する。1回の応答で終わる場合はまだいいが、300,000トークンに及ぶ長い会話では、毎回全トークンのKVベクトルを再計算するコストは膨大になる。Transformerのself-attentionはコンテキスト長に対して二次的なコストを持つが、KVキャッシュを活用することで既処理トークンの再計算を省き、デコード段階では線形に近い挙動に抑えることができる。それでも会話が長くなるほど累積するキャッシュサイズ自体は増大し、VRAM圧迫の主因となる。
KVキャッシュはこのコストを抑えるためのデータ構造で、「このセッションにおけるトークン間の関係」を保存・再利用する。ローカルでLLMを動かす場合、このキャッシュのためにVRAMを確保するか、やむを得ない場合は高速SSDに退避させる必要がある。
さらに注意すべき点として、コンテキストウィンドウが大きくなるほど、KVキャッシュがモデル本体のウェイトよりも多くのVRAMを消費するケースが生じる。そのため、現代のモデルはKVキャッシュにも量子化（後述）を適用し、精度をわずかに犠牲にしてVRAM使用量を抑えている。KVキャッシュの詳細な仕組みについては、Hugging FaceのLLM推論解説も参考になる。
量子化——「賢い丸め」でモデルを小さくする
量子化（Quantization）とは、端的に言えば「高精度なウェイトを低精度の数値型に変換する処理」だ。記事では"clever rounding"（賢い丸め）と表現されている。
学習時のモデルはBF16などの高精度フォーマットを使うが、そのまま配布するとモデルサイズが巨大になり、コンシューマ向けGPUでは動作しない。そこで学習後に量子化を施し、INT8やINT4などの低精度フォーマットに変換する。この手法の代表的な実装としてGGUF形式（llama.cppが採用するフォーマット）やGPTQなどが広く使われている。
例として、Llama 3.3 70BはフルのBF16版と量子化済みのINT4版の両方が公開されており、自分のハードウェアに合わせて選択できる。Hugging Face上のモデルには複数の量子化レベルが用意されていることが多い。
精度を下げるほどコンシューマハードウェアで動作しやすくなる一方、応答の精度や推論能力は低下する。どの量子化レベルを選ぶかは、手元のVRAM容量と求める応答品質のトレードオフになる。
コンテキストウィンドウ——LLMの「作業RAM」
コンテキストウィンドウはLLMの作業領域であり、コンピュータのRAMに相当する。現在のフロンティアモデルでは100万トークンが一般的な上限だ。
このウィンドウにはユーザーの質問と回答だけでなく、システムプロンプト、アップロードしたファイル、参照リンクの内容なども全て含まれる。LLMにとって、これら全ては区別のないトークンの塊として扱われる。
注意すべきは、ウィンドウを単純に拡大しても問題が生じる点だ。「lost in the middle」効果と呼ばれる現象として、会話の中盤の情報が軽視され、先頭と末尾だけに注意が向く傾向がある。この問題はStanford大学の研究論文でも報告されており、コンテキスト長を増やすだけでは性能が向上しない理由として広く参照されている。そのため各モデルは、自身のコンテキストウィンドウサイズに合わせて細かく調整されている。
ウェイトと量子化——モデルの「4B」「70B」が意味すること
ウェイト（Weights）はモデル内の各トークン間の接続強度を表す数値で、「4B」「70B」といった表記はそのパラメータ数（単位：十億）を指す。フロンティアモデル（GPT、Claude、Kimiなど）では兆単位になる。
ウェイトの数が多い＝賢い、ではない点は記事でも明示されている。CPUのクロック周波数と同様、数字だけで性能を判断できない。実際、小規模モデルでも特定タスクに特化したファインチューニングを施すことで、より大きなモデルを上回るケースが報告されている。
「オープンウェイト」モデル（Llama、DeepSeek、Kimiなど）はウェイトを公開しており、手元で改変・調整が可能だ。ただし、ウェイトをダウンロードしてもトレーニング手法や計算過程は分からない——フリーのアプリをダウンロードするのとは異なり、ソースコードが手に入るわけではない、という比喩が記事では使われている。
Mixture-of-Experts（MoE）——「専門家の分業」の実態
MoE（Mixture-of-Experts）は、モデル内に複数のサブモデル（エキスパート）を持つ構造だ。各エキスパートはわずかに異なるウェイト初期値から学習を始めるため、異なるトークンパターンを得意とするようになる。DeepSeek-V3やMistralのMixtralなど、近年の主要オープンモデルにも採用されている。
重要な誤解として、「プログラミング担当エキスパート」「絵画担当エキスパート」のようにトピックで分業しているわけではない。あくまでトークン間の関係を学ぶ構造であり、あるエキスパートが風景画について適切に答えられるとすれば、それは偶然の結果だ。
実用上のメリットは、全エキスパートを同時に動かすのではなく、トークンごとにルーターが必要なエキスパートだけを選択して起動する点にある。これにより、通常のLLMより高速に動作する。代償はVRAM消費量の増加だ。全エキスパートのウェイトをメモリに展開しておく必要があるため、同等の応答品質を持つ密なモデルと比べてVRAMを多く要求する傾向がある。
RAGと推論（Inference）——実用面でのポイント
RAG（Retrieval-Augmented Generation）は、チャットアプリが外部検索を行い、その結果をモデルのコンテキストウィンドウに追加してから応答を生成する手法だ。Perplexityはこの手法に重点を置いたサービスとして知られる。RAGの詳細な設計パターンについてはLangChainのドキュメントも参考になる。
強力な反面、取得したWebページのテキストだけで数十万トークンを消費することもあり、VRAM・計算コストの観点で負荷が大きい。
推論（Inference）はモデルが出力を生成するプロセス全体を指す。内部的には「Prefill」（入力トークンの処理とKVキャッシュの構築）と「Decode」（トークンを逐次生成する段階）の2フェーズに分かれている。ここまでに説明した全要素——ウェイト、量子化、KVキャッシュ、コンテキストウィンドウ——が実際に動くのはこのフェーズだ。ローカル推論の実行環境としてはllama.cppやOllamaが広く使われており、量子化モデルとの組み合わせでコンシューマGPU上でも動作させることができる。
詳細はA primer to key LLM conceptsを参照していただきたい。
