全体アウトライン

本書は、大規模言語モデル（LLM）のオープン化とローカル実行革命の中心にある技術群「LLaMA」「OpenLLaMA」「llama.cpp」を、基礎から実践まで分かりやすく解説する技術書です。

本書の目的と対象読者

商用 API に依存せず、自身の PC や自社環境で LLM を動かしたいエンジニアや学習者を対象としています。 「LLM の内部でどのような数式や工夫が使われているのか」「なぜ民生用 PC で数十億パラメータのモデルが動くのか」「オープンソース AI はどのように発展してきたのか」という疑問に、数式や専門用語をやさしく噛み砕きながら答えます。

章構成一覧

第1章 LLaMAの概要と登場背景

Meta（旧 Facebook）が 2023 年 2 月に発表した LLaMA の登場背景と、その後のオープンソース AI コミュニティに与えた歴史的インパクトを解説します。プロプライエタリな巨大モデルに対する「小さくて賢いモデル」というパラダイムシフトを概観します。

第2章 LLaMAのモデルアーキテクチャ

標準的な Transformer からの改良点を詳細に解説します。事前正規化（Pre-normalization）と RMSNorm、活性化関数 SwiGLU、回転位置埋め込み（RoPE: Rotary Position Embedding）、推論を支える KV キャッシュの仕組みを解き明かします。

第3章 高速化とスケーリング技術

モデルの大規模化と長文脈対応を支える技術を解説します。マルチヘッドアテンション（MHA）の計算・メモリ負荷を解決する Grouped-Query Attention（GQA）の原理や、コンテキスト拡張の手法、学習データの質とスケーリング則を学びます。

第4章 OpenLLaMAとオープンな完全再現

初代 LLaMA が非商用研究限定ライセンスだったことで生じた課題と、それを解決するために生まれた完全オープンな再現プロジェクト「OpenLLaMA」を取り上げます。オープンデータセット「RedPajama」による学習過程と、再現実装の価値を解説します。

第5章 llama.cppの設計思想と基礎

Georgi Gerganov 氏によって開発された純粋な C/C++ による推論エンジン「llama.cpp」の設計思想を解説します。外部ライブラリに依存しないゼロ依存設計や、ファイルフォーマットの進化（GGML から GGUF へ）の背景を学びます。

第6章 量子化技術と推論最適化

民生用 PC やスマートフォンでモデルを動作させる鍵となる「モデル量子化」の仕組みを解説します。浮動小数点（FP16/FP32）から 8bit/4bit への変換原理、k-quants（Q4_K_M など）の工夫、CPU/GPU ハイブリッド推論の仕組みを理解します。

第7章 llama.cppの実践とエコシステム

実際に llama.cpp を使ってモデルを動かす手順をハンズオン形式で解説します。ソースコードのビルド、GGUF モデルの取得、CLI コマンドでの対話生成、ローカル API サーバーの立ち上げ、Python バインディング（llama-cpp-python）の利用法を紹介します。

第8章 LLaMAエコシステムの発展と今後の展望

LLaMA 2、Llama 3、そして派生するオープンモデル（Mistral、Qwen など）への波及効果と、ローカル AI・エッジ AI が切り拓くプライバシー保護と組み込み応用の未来を総括します。さらに、最新の推論エンジン「Strata」の技術や llama.cpp との違いについても整理します。

1. LLaMAの概要と登場背景

LLaMAとは何か

LLaMA（Large Language Model Meta AI）は、Meta（旧 Facebook）の研究部門が 2023 年 2 月に公開した基底言語モデルのシリーズです。 モデルのパラメータ規模は 7B（70億）、13B（130億）、33B（330億）、65B（650億）の 4 種類が用意され、それまでの標準的な巨大言語モデルよりも比較的小さなサイズでありながら、非常に高い性能を達成しました。

従来の最先端モデルの多くは、何千億もの膨大なパラメータを持ち、巨大なデータセンターでしか動作させることが困難でした。 LLaMA はモデル自体のサイズを抑えつつ、事前学習に投入するデータ量を劇的に増やすことで、家庭用のコンピュータや小規模なサーバー環境でも動作可能な実用性と高性能を両立させました。

巨大モデル競争と「小さくて賢いモデル」への転換

2020 年に OpenAI が GPT-3（1750億パラメータ）を発表して以降、AI 業界では「パラメータ数を大きくすればするほど賢くなる」という方針が主流でした。 しかし、モデルが巨大化するほど、学習コストだけでなく推論（質問に答える処理）に必要な GPU のメモリや電力も跳ね上がります。日常的に実サービスで運用するにはコストが高すぎるという問題が生じていました。

LLaMA はこの課題に対して「モデルサイズを小さく抑えたまま、より多くのデータで徹底的に学習させる」という新しいアプローチを提示しました。 推論時の計算コストはモデルのパラメータ数に比例するため、モデルが小さければ小さいほど、安価なハードウェアで高速に応答を返すことができます。

Chinchillaのスケーリング則とLLaMAの着眼点

2022 年に DeepMind が発表した「Chinchilla（チンチラ）のスケーリング則」と呼ばれる研究成果が、LLaMA の開発に決定的な影響を与えました。 従来の法則（Kaplan の法則）ではモデルサイズと学習トークン数を同等に増やすことが最適とされていましたが、Chinchilla の研究は「既存のモデルの多くは学習データ量が不足しており、パラメータを増やすよりもデータを増やすほうが計算効率が良い」と指摘しました。

LLaMA はこの法則をさらに一歩進めました。 「学習時の最適な計算予算」を超えて、あえて過剰な量のトークン（7B や 13B のモデルに対して 1 兆トークン以上、65B には 1.4 兆トークン）を学習させました。 学習時の計算コストが多少余分にかかったとしても、一度完成したモデルを世界中で何億回も推論させる運用コストを考えれば、小さくて高性能なモデルのほうが圧倒的に経済的だからです。

オープンソースAIコミュニティへの波及効果

LLaMA の登場は、それまで大手テック企業に独占されていた最先端 AI の研究開発を、一般の開発者や学術機関に開放する契機となりました。 7B や 13B のモデルであれば、一般的なゲーミング PC やクラウドの安価なインスタンスでも動作させることができます。

世界中の開発者が LLaMA を土台にして、追加学習（ファインチューニング）や量子化の実験を始めました。 スタンフォード大学が発表した Alpaca（アルパカ）や、Vicuna（ビクーニャ）などの派生モデルが次々と誕生し、指示に従って対話するチャットボット技術が個人開発者の手によって急速に進化しました。

初代LLaMAのライセンスとコミュニティの葛藤

初代 LLaMA の学習済み重み（ウェイト）は、当初は学術研究者向けに限定された申請制で配布されました。商用利用は禁止されており、研究目的のみに利用が制限されていました。 しかし、発表から間もなくトレントファイルなどを通じて重みがインターネット全体に流出し、誰もがダウンロードできる状態となりました。

この事態は、コミュニティに大きな議論を巻き起こしました。 非商用ライセンスの制約があるため、企業がサービスに組み込むことは法的にできませんでした。 この「商用利用の制約」を克服するために、完全にオープンなデータでゼロから学習し直す「OpenLLaMA」プロジェクトが立ち上がることになります。 次章では、LLaMA が採用した先進的な内部アーキテクチャの数々を見ていきます。

2. LLaMAのモデルアーキテクチャ

Transformerデコーダの標準構成とLLaMAの設計方針

LLaMA の内部アーキテクチャは、GPT-3 などと同様の「デコーダ専用（Decoder-only）Transformer」を基本としています。 しかし、オリジナルの Transformer（Attention Is All You Need, 2017）の設計をそのまま使うのではなく、その後の深層学習研究で提案された優れた改良手法を貪欲に取り入れました。

具体的には、学習の安定性を高めるための「RMSNorm」、非線形表現力を高める活性化関数「SwiGLU」、長文脈での位置関係を的確に捉える「RoPE（回転位置埋め込み）」などを組み合わせています。 これらの改良により、モデルのパラメータ数が同じであっても、学習が破綻しにくく、高い予測精度を発揮できるようになりました。

事前正規化（Pre-normalization）とRMSNorm

オリジナルの Transformer では、各層の処理（アテンションや順伝播ネットワーク）の「後」に正規化（LayerNorm）を適用する Post-normalization が使われていました。 しかし、Post-norm は層が深くなるにつれて勾配が爆発または消失しやすく、学習が不安定になる欠点がありました。

LLaMA では、各サブレイヤーの「前」に入力を正規化する Pre-normalization を採用しました。 さらに、標準的な LayerNorm よりも計算が軽量な「RMSNorm（Root Mean Square Normalization）」を導入しました。 LayerNorm が平均と分散の両方を計算するのに対し、RMSNorm は二乗平均平方根（RMS）のみを用いて正規化します。 平均の計算を省略することで計算速度が約 10% から 50% 向上しつつ、学習の安定性は同等を維持します。

import torch
import torch.nn as nn

class RMSNorm(nn.Module):
    def __init__(self, dim: int, eps: float = 1e-6):
        super().__init__()
        self.eps = eps
        self.weight = nn.Parameter(torch.ones(dim))

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        # 入力の二乗平均の平方根を計算して割る
        rms = torch.sqrt(torch.mean(x ** 2, dim=-1, keepdim=True) + self.eps)
        return (x / rms) * self.weight

活性化関数SwiGLUの採用

標準的な Transformer の順伝播ネットワーク（FFN）では、ReLU や GELU といった活性化関数が使われてきました。 LLaMA では、PaLM などでも高い効果が実証されていた「SwiGLU（Swish Gated Linear Unit）」を採用しました。

SwiGLU は、2 つの線形変換の出力のうち一方に Swish（SiLU）活性化関数をかけ、もう一方との要素ごとの積（ゲート処理）を取る構造です。 パラメータ数が通常の FFN より約 1.5 倍増えるため、LLaMA では隠れ層の次元数を元の $\frac{8}{3}d$ から 256 の倍数に調整することで、計算量とパラメータのバランスを最適化しています。

import torch
import torch.nn as nn
import torch.nn.functional as F

class SwiGLU(nn.Module):
    def __init__(self, in_features: int, hidden_features: int):
        super().__init__()
        self.w1 = nn.Linear(in_features, hidden_features, bias=False)
        self.w2 = nn.Linear(hidden_features, in_features, bias=False)
        self.w3 = nn.Linear(in_features, hidden_features, bias=False)

    def forward(self, x: torch.Tensor) -> torch.Tensor:
        # SiLU(w1(x)) と w3(x) の要素ごとの積を w2 で元の次元へ戻す
        return self.w2(F.silu(self.w1(x)) * self.w3(x))

回転位置埋め込み（RoPE: Rotary Position Embedding）

単語の順序をモデルに認識させるため、従来の Transformer は絶対位置埋め込み（各位置に固有のベクトルを足す方式）を使用していました。 しかし、絶対位置埋め込みは未知の長さの文章への汎化が苦手でした。

LLaMA は、2021 年に Jianlin Su 氏が提案した「RoPE（Rotary Position Embedding）」を採用しました。 RoPE は、トークンの埋め込みベクトルを 2 次元ごとの組に分け、その位置インデックスに応じた角度で回転行列を掛ける手法です。 2 つのトークンの内積を計算すると、2 つの単語の「相対的な距離」だけが自然に残る数学的性質を持ちます。 これにより、位置関係の捉え方が極めて柔軟になり、後のコンテキスト拡張（2048 トークンから数万トークンへの延長）でも重要な役割を果たすことになります。

推論を高速化するKVキャッシュの原理

LLM が文章を生成するとき、単語（トークン）を 1 つずつ順番に出力する自己回帰（Autoregressive）の仕組みを取ります。 愚直に計算すると、新しいトークンを 1 つ出すたびに、それまでに生成されたすべての過去トークンの Key と Value の行列を毎回ゼロから再計算することになり、膨大な無駄が発生します。

この無駄を防ぐのが「KV キャッシュ（Key-Value Cache）」です。 過去のトークンについて計算した Key と Value のベクトルをメモリ上に保持しておき、新しいトークンの計算時にはそのキャッシュを再利用して新しい Query とのアテンションだけを計算します。 KV キャッシュにより、1 トークン生成あたりの計算量は文章の長さに比例するだけで済み、高速なテキスト生成が可能になります。 次章では、この KV キャッシュのメモリ消費を劇的に抑えるアテンションの進化について解説します。

3. 高速化とスケーリング技術

マルチヘッドアテンション（MHA）のメモリ課題

従来の Transformer が用いるマルチヘッドアテンション（Multi-Head Attention: MHA）では、Query（質問）、Key（鍵）、Value（値）のそれぞれに同じ個数のヘッドを用意します。 例えば、ヘッド数が 32 個であれば、Query、Key、Value すべてが 32 個のヘッドを持ちます。

推論時に過去トークンの Key と Value を保持する KV キャッシュは、コンテキスト長（文脈の長さ）や同時に処理するバッチ数が増えるにつれて急激に肥大化します。 例えば 70B モデルで 4096 トークン、さらに 32k、128k と長大な文章を処理しようとすると、モデル本体の重みとは別に何十ギガバイトもの GPU メモリが KV キャッシュだけで消費され、メモリ不足（OOM: Out Of Memory）の原因となります。

MQAとGQA（Grouped-Query Attention）の仕組み

この KV キャッシュの肥大化を解決するために開発されたのが、Multi-Query Attention（MQA）と Grouped-Query Attention（GQA）です。

• MHA (Multi-Head Attention): 各 Query ヘッドごとに個別の Key/Value ヘッドが存在する（1対1対応）。表現力は高いが KV キャッシュのメモリ消費が最も大きい。

• MQA (Multi-Query Attention): すべての Query ヘッドで「たった1組」の Key/Value ヘッドを共有する（多対1対応）。メモリ消費は最小になるが、モデルの表現力や回答精度が低下しやすい。

• GQA (Grouped-Query Attention): 複数の Query ヘッドをグループ化し、グループごとに 1 つの Key/Value ヘッドを共有する（グループ対1対応）。例えば 32 個の Query ヘッドを 8 グループに分け、Key/Value ヘッドを 8 個にする。

LLaMA 2 の大型モデル（34B, 70B）や Llama 3 では、この GQA が標準採用されました。 MHA に迫る高い精度を維持しながら、KV キャッシュのメモリ消費量を $\frac{1}{4}$ から $\frac{1}{8}$ に削減し、より長い文脈と大きなバッチサイズを効率的に処理できます。

コンテキスト長の拡張とRoPE補間（RoPE Scaling）

初代 LLaMA の最大コンテキスト長は 2048 トークンでした。 しかし、論文や長文マニュアルの読解、プログラムコード全体の分析を行うには、より長い文脈の処理が求められます。

2048 を超える長さを扱うために、RoPE の回転角周波数を調整する「RoPE スケーリング（位置補間: Position Interpolation）」が考案されました。 位置番号を学習時の範囲（例えば 0 〜 2047）に収まるように一定割合で縮小（補間）して入力することで、少量の追加ファインチューニングだけで 8192 や 16384 トークン以上の長文を扱えるようになります。 Llama 3 では基底周波数（base frequency）を $10,000$ から $500,000$ へ引き上げるなどの工夫により、標準で 8k や 128k トークンの超長文脈処理を実現しています。

学習データセットの品質とスケーリング則

LLaMA の成功を支えた最大の要因の一つは、徹底的に精査された学習データセットです。 初代 LLaMA は、Common Crawl（Web クローリングデータ）、C4、GitHub、Wikipedia、Gutenberg（書籍）、arXiv（論文）、Stack Exchange など、すべて一般公開されているデータソースから収集されました。

単にデータを集めるだけでなく、重複排除（Deduplication）、低品質な文章のフィルタリング、個人情報のマスキングなどの品質クリーニングを徹底しました。 高品質なテキストを 1 兆から 2 兆トークン以上読み込ませることで、モデルサイズが比較的小さくても、より大きなモデルを凌駕する論理的推論力を獲得できることが示されました。

LLaMA 2 と Llama 3 への進化

LLaMA シリーズは世代を重ねるごとに急速に進化しています。

• LLaMA (初代, 2023年2月): 研究用限定ライセンス。最大コンテキスト 2048 トークン。最大 1.4 兆トークン学習。MHA 採用。

• Llama 2 (2023年7月): 月間アクティブユーザー 7 億人未満の企業に商用利用を開放。2 兆トークン学習。コンテキスト長 4096 トークン。70B に GQA 採用。安全性を高めた Llama-2-chat モデルも公式提供。

• Llama 3 / 3.1 / 3.3 (2024年〜): 8B, 70B, 405B のラインナップ。15 兆トークン以上の高品質多言語データで学習。語彙数 128k の Tiktoken トークナイザー採用。全モデルで GQA 採用。最大コンテキスト 128k トークン。

次章では、初代 LLaMA の非商用ライセンスという壁を乗り越えるために生まれた、完全オープンな再現プロジェクト「OpenLLaMA」について見ていきます。

4. OpenLLaMAとオープンな完全再現

OpenLLaMAの誕生背景と目的

初代 LLaMA（2023 年 2 月）は高い性能を示した一方で、モデルの重み（ウェイト）は非商用・研究目的限定のライセンスでした。 そのため、一般企業が自社の製品や業務システムに LLaMA を組み込んで活用することは法的に許されていませんでした。

この課題を解決するため、カリフォルニア大学バークレー校の AI 研究グループ（Berkeley AI Research: BAIR）に所属する Xinyang Geng 氏と Hao Liu 氏らが中心となり、「OpenLLaMA」プロジェクトが立ち上がりました。 その目的はシンプルで明確でした。「初代 LLaMA と完全に同一のアーキテクチャを持ち、完全に公開されたクリーンなデータセットを使ってゼロから事前学習を行い、商用利用可能な寛容ライセンスで一般公開すること」です。

再現の要となったRedPajamaデータセット

LLaMA の論文には学習データの構成比率（Common Crawl 67%、C4 15%、GitHub 4.5%、Wikipedia 4.5% など）が明記されていました。 しかし、実際に Meta がダウンロード・フィルタリングした生データそのものは公開されていませんでした。

この欠落を埋めたのが、オープン AI 団体 Together AI が主導する「RedPajama（レッドパジャマ）」プロジェクトです。 RedPajama チームは、LLaMA 論文に記載されたデータ収集・前処理手順を忠実に再現し、1.2 兆トークンに及ぶオープンデータセット「RedPajama-1T」を構築・一般公開しました。 OpenLLaMA は、この RedPajama データセットを直接用いて、ゼロからの事前学習を敢行しました。

学習フレームワークとアーキテクチャの互換性

OpenLLaMA は、大規模言語モデルの並列学習フレームワークである「EasyLM」（JAX/Flax ベース、Google Cloud TPU 向け）を用いて学習が行われました。 モデルサイズとしては、3B、7B、13B のバリエーションが提供されました。特に 3B モデルは、スマートフォンやエッジデバイスでも扱いやすい手頃なサイズとして重宝されました。

重要な点は、モデルの内部構造（RMSNorm、SwiGLU、RoPE、レイヤー数、ヘッド数など）が初代 LLaMA と完全に一致するように設計されたことです。 重みの形式も Hugging Face の LlamaForCausalLM と互換性を持つように変換・公開されたため、開発者は既存の LLaMA 向けエコシステムや推論ツールをそのまま変更なしで OpenLLaMA に適用できました。

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

# OpenLLaMA 3B モデルのロード例
model_id = "openlm-research/open_llama_3b_v2"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    torch_dtype=torch.float16,
    device_map="auto"
)

prompt = "The primary purpose of OpenLLaMA is"
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)

with torch.no_grad():
    outputs = model.generate(**inputs, max_new_tokens=50)

print(tokenizer.decode(outputs[0], skip_special_tokens=True))

LLaMAとの性能比較と評価結果

OpenLLaMA は、標準的な言語モデル評価ベンチマーク（MMLU、ARC、HellaSwag、PIQA など）において、オリジナルの LLaMA に極めて近いスコアを記録しました。 特に v2（バージョン2）では、トークナイザーの語彙処理や学習スケジュールの改善により、7B モデルにおいて初代 LLaMA 7B と同等クラスの推論性能を達成しました。

学術研究としてモデルの構造と学習レシピが公開されていれば、民間企業や独立した研究チームであっても最先端モデルを再現できることが実証された瞬間でした。

完全オープンライセンス（Apache 2.0）がもたらした意義

OpenLLaMA の最大の功績は、モデルの重みとコードを「Apache 2.0 ライセンス」でリリースしたことです。 これにより、あらゆる企業や個人が以下の恩恵を受けられるようになりました。

• 商用利用の完全な自由: ライセンス違反の法的リスクを恐れることなく、自社のクラウドサービスやオンプレミス環境に組み込むことができます。

• 完全な透明性: どのデータでどのように学習されたかが完全に追跡可能であり、学術的な再現性やコンプライアンスの検証が容易です。

• コミュニティの安心感: Meta が Llama 2 や Llama 3 をより寛容なライセンスで公開するまでの重要な移行期において、真に自由なオープンソース AI の象徴として大きな役割を果たしました。

次章からは、これらの LLaMA 系モデルを一般的な PC で高速に動かす立役者となった「llama.cpp」について詳しく見ていきます。

5. llama.cppの設計思想と基礎

llama.cppとは何か（Georgi Gerganovによる開発）

llama.cpp は、ブルガリアのプログラマである Georgi Gerganov（ゲオルギ・ゲルガノフ）氏が 2023 年 3 月に開発・公開した、純粋な C/C++ による LLaMA モデルの推論エンジンです。 初代 LLaMA が公開されてからわずか数週間後、GitHub 上に突如として現れたこのプロジェクトは、AI 界隈に大きな衝撃を与えました。

これまで LLM を動かすには、Python 実行環境、巨大な PyTorch ライブラリ、そして高価な NVIDIA 製 GPU（VRAM 16GB 以上）が必須とされていました。 llama.cpp は、特別な GPU を持たない一般的な MacBook（Apple Silicon）や、普通のノート PC の CPU だけを使って、LLaMA 7B や 13B を実用的な速度で動作させて見せたのです。

Pythonや重厚な深層学習フレームワークへの依存脱却

従来の深層学習スタックは非常に複雑で重厚でした。 PyTorch や CUDA、cuDNN、数多くの Python パッケージが数ギガバイトものディスク容量を占有し、環境構築のトラブルが頻発していました。また、Python の実行オーバーヘッド（GIL やメモリ管理）も少なからず存在します。

llama.cpp の最大の特徴は、「Python や PyTorch などの外部ライブラリを一切使わず、プレーンな C/C++ だけでゼロから推論パイプラインを実装したこと」です。 コンパイラさえあれば単一の実行可能バイナリ（exeファイルなど）をビルドでき、数メガバイトの極小フットプリントで軽快に動作します。

C/C++によるゼロ依存とハードウェア最適化

llama.cpp は、ハードウェアの性能を限界まで引き出すために、CPU や GPU の低レベル命令を直接活用しています。

• SIMD ベクトル命令の活用: x86_64 アーキテクチャの AVX, AVX2, AVX-512 命令や、ARM アーキテクチャの NEON 命令をフル活用し、行列積計算を CPU 上で並列実行します。

• Apple Silicon（Metal）へのネイティブ対応: Mac の Apple M シリーズに搭載された統合メモリ（Unified Memory）と Metal API を活用し、GPU と CPU が同じ高速メモリを共有する特性を最大限に活かして爆速な推論を実現しました。

• マルチバックエンド対応: NVIDIA GPU（CUDA）、AMD GPU（ROCm / HIP）、Intel GPU（SYCL / oneAPI）、Vulkan など、あらゆるグラフィックボードへのオフロードに対応しています。

ファイルフォーマットの歴史（GGMLからGGUFへ）

llama.cpp では、モデルの重みとメタデータを格納するために独自のバイナリフォーマットが開発・改良されてきました。

• GGML (Georgi Gerganov Machine Learning): 初期に使用されていたバイナリフォーマットです。テンソルの重みデータをフラットに保存するシンプルな構造でしたが、メタデータ（トークナイザーの設定やアーキテクチャ情報）の拡張が難しく、互換性の破綻が課題でした。

• GGJT / GGMF: アライメントやメタデータ追加のために一時的に使われた過渡的なフォーマットです。

• GGUF (GPT-Generated Unified Format): 2023 年 8 月に導入された、現在デファクトスタンダードとなっている統一フォーマットです。 キー・バリュー形式の拡張可能なメタデータヘッダーを備えており、トークナイザー、モデルアーキテクチャ名、量子化方式、ハイパーパラメータなどを単一の .gguf ファイルに完全に自己完結して保持できます。 後方互換性と前方互換性に配慮されており、新しいモデルアーキテクチャが追加されてもフォーマット全体を壊さずに拡張できます。

クロスプラットフォーム対応とエコシステム

llama.cpp の成功は、ローカル AI アプリケーションの爆発的な増加をもたらしました。 Linux、macOS、Windows、Android、さらには Raspberry Pi のような小型シングルボードコンピュータまで、あらゆる環境で同一のモデルファイルを動作させることができます。

Ollama、LM Studio、Jan、LocalAI、text-generation-webui といった人気のローカル LLM アプリケーションの多くは、内部の推論バックエンドとして llama.cpp（またはそのライブラリ）を採用しています。 次章では、llama.cpp を支える核心技術である「量子化（Quantization）」について掘り下げます。

6. 量子化技術と推論最適化

量子化（Quantization）とは何か

深層学習モデルのパラメータ（重み）は、通常 16 ビット浮動小数点（FP16 または BF16）や 32 ビット浮動小数点（FP32）で表現されています。 例えば、70 億パラメータ（7B）のモデルを FP16 で読み込むと、重みだけで $7 \times 10^9 \times 2\text{バイト} \approx 14\text{GB}$ のメモリが必要になります。これに KV キャッシュや処理用ワークスペースを加えると、16GB 以上のメモリが必須となります。

「量子化（Quantization）」とは、重みの数値をより少ないビット数（例えば 8 ビット、4 ビット、あるいは 2 ビット）の整数で近似表現する圧縮技術です。 量子化を行うことで、必要なメモリ容量を $\frac{1}{2}$ から $\frac{1}{4}$ 以下に削減し、一般的な 8GB や 16GB の RAM を持つ PC でもモデルを丸ごとロードできるようになります。

メモリ帯域幅の壁（Memory Bandwidth Bound）

LLM が 1 トークンを生成するとき、モデル全体のすべての重み行列をメモリからプロセッサ（CPU や GPU のコア）へと 1 回読み出す必要があります。 計算自体の演算量よりも、メモリからデータを読み出す転送速度（メモリ帯域幅: Memory Bandwidth）がボトルネックとなる現象を「メモリ帯域幅制限（Memory Bound）」と呼びます。

量子化によって重みのデータサイズが半分になれば、メモリから読み出す転送データ量も半分になります。 その結果、量子化はメモリ消費を抑えるだけでなく、CPU や統合メモリにおけるトークン生成速度（秒間トークン数: tokens/sec）を大幅に向上させる という強力な副次的効果をもたらします。

8bit量子化と4bit量子化の原理

最も基本的な均等量子化（Uniform Quantization）では、浮動小数点の値の範囲 $[-\max, \max]$ を、小さな整数値（int8 なら $-128 \sim 127$、int4 なら $-8 \sim 7$）にマッピングします。

変換式は基本的に以下の通りです：

$$ q = \text{round}\left(\frac{x}{s}\right) $$

ここで $x$ は元の浮動小数点値、$s$ はスケーリング係数（scale）、$q$ は量子化された整数値です。 計算を行う直前に、整数 $q$ にスケール $s$ を掛けて逆量子化（De-quantization）し、浮動小数点に戻して行列積を計算します。 ブロック単位（例えば 32 個の重みごと）に局所的なスケール係数を保持する「ブロック量子化」を用いることで、極端な外れ値による精度劣化を最小限に抑えます。

k-quants（Q4_K_Mなど）による精度向上手法

llama.cpp では、単純な均等量子化を超えて、より高度な「k-quants」と呼ばれる量子化方式が開発されました。 モデルのファイル名で見かける Q4_K_M や Q5_K_S といった記号は、この方式を表しています。

• 重要度に応じた不均一なビット配分: Transformer のすべての層が同じ重要度を持つわけではありません。アテンションの Key/Value 射影層や、出力に近いレイヤーは精度に大きく影響し、中間の一部の FFN 層は多少粗くても耐性があります。 Q4_K_M（Medium）では、重要なテンソルには 5 ビットや 6 ビットを割り当て、影響の少ないテンソルに 4 ビットを割り当てることで、全体の平均サイズを 4.5 ビット程度に抑えつつ、FP16 と肉薄する回答精度を実現します。

CPU/GPUハイブリッド推論とレイヤーオフロード

llama.cpp のもう一つの強力な武器は、柔軟な「レイヤーオフロード（GPU Offloading）」です。 モデルのレイヤー（層）は順番に積み重なっています。例えば 32 層あるモデルにおいて、GPU の VRAM が 4GB しかなくモデル全体（4.4GB）が収まらない場合、GPU を完全に諦める必要はありません。

llama.cpp では、最初の 20 層だけを GPU の VRAM に配置（オフロード）し、残りの 12 層をメインメモリ（RAM）と CPU で処理する、といったハイブリッド推論が可能です。 GPU で処理できる層が増えるほど全体の処理速度が劇的に高速化するため、手持ちのハードウェアの能力を限界まで使い切ることができます。 次章では、実際に llama.cpp をセットアップして動かす実践手順を解説します。

7. llama.cppの実践とエコシステム

ビルド手順（CMake / Make）

llama.cpp を利用する最も基本的な方法は、GitHub リポジトリからソースコードをクローンしてビルドすることです。 Windows、macOS、Linux の各 OS で CMake を使って簡単にコンパイルできます。

# リポジトリのクローン
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

# CMake を使ったビルド（CPU 版の標準構成）
cmake -B build
cmake --build build --config Release

NVIDIA GPU（CUDA）を利用する場合は、CMake のオプションに -DGGML_CUDA=ON を指定します。 macOS（Metal）の場合は、標準で Metal が自動有効化されるため、特別なフラグなしで GPU 加速が有効になります。

GGUFモデルの入手と準備（Hugging Faceからのダウンロード）

推論を実行するには、GGUF 形式に変換・量子化されたモデルファイルが必要です。 AI コミュニティのハブである Hugging Face 上には、様々な開発者（例えば TheBloke 氏や Bartowski 氏、各モデル開発企業）によって事前量子化された .gguf ファイルが大量に公開されています。

例えば、Hugging Face CLI や curl を使ってモデルをダウンロードします。

# 7B または 8B クラスの Q4_K_M モデルをダウンロードする例
curl -L -O https://huggingface.co/bartowski/Meta-Llama-3.1-8B-Instruct-GGUF/resolve/main/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf

自身で PyTorch や Hugging Face 形式のモデルから GGUF を生成したい場合は、llama.cpp リポジトリに含まれる convert_hf_to_gguf.py スクリプトを使用して直接変換・量子化することも可能です。

CLIツール（llama-cli）による対話実行

ビルドが完了すると、build/bin/ 配下に llama-cli（旧名: main）という実行ファイルが生成されます。 このコマンドラインツールを使って、ターミナル上で直接対話を行うことができます。

# 対話（チャット）モードで起動する例
./build/bin/llama-cli \
  -m Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -p "あなたは親切なAIアシスタントです。" \
  -cnv \
  -ngl 33 \
  -c 4096 \
  --temp 0.7

主要なオプションの意味は以下の通りです：

• -m <path>: ロードする GGUF モデルファイルのパスを指定します。
• -cnv: 対話型会話（conversation）モードを有効にします。
• -ngl <N>: GPU にオフロードするレイヤー数を指定します（全層を GPU に載せる場合は大きな数値、例えば 33 や 99 を指定）。
• -c <N>: コンテキスト長（文脈メモリ）のトークン数を指定します（例: 4096）。
• --temp <N>: 生成の多様性・ランダム性（温度パラメータ）を制御します。

ローカルAPIサーバー（llama-server）とOpenAI互換エンドポイント

llama.cpp には、高速な HTTP Web サーバー llama-server（旧名: server）が付属しています。 このサーバーを起動すると、OpenAI の REST API（/v1/chat/completions）と完全互換のエンドポイントがローカル環境に提供されます。

# ローカル API サーバーの起動
./build/bin/llama-server \
  -m Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  --port 8080 \
  -ngl 33 \
  -c 8192

サーバーが起動した状態で、Python の公式 openai クライアントや curl からアクセスできます。

# curl によるテスト呼び出し
curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      {"role": "user", "content": "こんにちは！自己紹介してください。"}
    ]
  }'

この互換性により、OpenAI API 向けに作られた既存の Web アプリケーションやエージェントシステムを、コード変更なしで完全ローカルなプライベート環境に差し替えることができます。

Pythonバインディング（llama-cpp-python）によるプログラム連携

Python から llama.cpp の C++ エンジンを直接呼び出したい場合は、公式バインディングライブラリである llama-cpp-python を利用します。

pip install llama-cpp-python

以下は Python スクリプトから GGUF モデルをロードして推論を行う例です：

from llama_cpp import Llama

# モデルのロード（n_gpu_layers=-1 で全層を GPU にオフロード）
llm = Llama(
    model_path="Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf",
    n_ctx=4096,
    n_gpu_layers=-1,
    verbose=False
)

# チャット補完の実行
response = llm.create_chat_completion(
    messages=[
        {"role": "system", "content": "あなたは簡潔に答える技術アシスタントです。"},
        {"role": "user", "content": "llama.cpp の利点を3つ箇条書きで教えてください。"}
    ],
    temperature=0.7,
    max_tokens=256
)

print(response["choices"][0]["message"]["content"])

このように、llama.cpp は単なる推論バイナリにとどまらず、開発言語やアプリケーションを問わず組み込める柔軟なエコシステムを形成しています。 次章では、LLaMA から始まったオープンモデルエコシステムの広がりと、今後の展望についてまとめます。

8. LLaMAエコシステムの発展と今後の展望

LLaMAアーキテクチャが築いた現代オープンLLMの標準規格

LLaMA の登場は、単に Meta が優れたモデルを公開したという出来事にとどまりません。 LLaMA が採用したアーキテクチャ設計（RMSNorm、SwiGLU、RoPE、そして GQA）は、その後のオープンソース AI モデルにおける事実上の「標準設計図（デファクトスタンダード）」として確立されました。

現在世界中で公開されている主要なオープン LLM のほとんどが、LLaMA アーキテクチャをそのまま、あるいはわずかな調整を加えて踏襲しています。 単一のアーキテクチャが標準化したことで、トークナイザー、学習ライブラリ、量子化ツール、推論ランタイム（llama.cpp や vLLM など）が共通化され、コミュニティ全体の開発スピードが爆発的に加速しました。

派生モデルの爆発的進化（Mistral、Qwen、Gemmaなど）

LLaMA を起点として、さらに新しい工夫を取り入れた強力な派生モデルが次々と誕生しました。

• Mistral AI (Mistral 7B / Mixtral 8x7B): Sliding Window Attention（局所アテンション）や MoE（Mixture of Experts: 専門家混合モデル）を組み合わせ、7B クラスでありながら前世代の 30B クラスを凌駕する驚異的な性能を実現しました。

• Alibaba (Qwen シリーズ): 中国語や日本語を含む多言語対応を大幅に強化し、コーディングや数学推論においてプロプライエタリな商用 API に迫る精度を達成しています。

• Google (Gemma シリーズ): Gemini の研究成果を取り入れ、徹底的に最適化された軽量・高効率なオープンウェイトモデルとして提供されています。

これらのモデルの多くも、llama.cpp や GGUF 形式の推論エコシステムに即座に対応し、ローカル環境で自由に実行できるようになっています。

プライバシー保護とオフライン環境におけるローカルAIの価値

クラウド上の商用 API を利用する場合、機密データや個人情報を外部サーバーへ送信しなければならないというセキュリティ上の懸念が常に付きまといます。 また、API 利用料の従量課金や、ネットワーク遅延、サービスの障害リスクも課題となります。

LLaMA や OpenLLaMA をベースとしたモデルを llama.cpp などのローカル推論エンジンで自社環境・手元端末で動かすことにより、以下の大きなメリットが得られます：

• 完全なデータ主権とプライバシー: 入力データがネットワークの外部へ 1 バイトも送信されないため、医療情報、財務データ、企業の機密ソースコードを安全に扱えます。

• オフライン動作: インターネット接続が遮断された船舶、航空機、閉域網の工場、災害現場でも安定して AI が動作します。

• 予測可能なコスト: 一度ハードウェアを用意すれば、推論回数に応じた追加のクラウド利用料が発生しません。

小型化とエッジAIの未来（組み込みデバイス・モバイル）

LLM の未来は、データセンターの巨大化だけではありません。「より小さく、より省電力に、あらゆる機器へ溶け込む」エッジ AI の進化も急速に進んでいます。

1B〜3B クラスの極小モデルと 4bit/3bit 量子化技術の組み合わせにより、最新のスマートフォンだけでなく、自動車の車載システム、家電製品、産業用ロボットの組み込みチップ上で、リアルタイムに自然言語を理解する AI が稼働し始めています。 推論の最適化を追求した llama.cpp のような低レイヤーのソフトウェア技術は、AI を生活のあらゆる場面に普及させる基盤となっています。

新世代ローカル推論エンジン「Strata」の登場と技術的革新

llama.cpp の登場によって「7B〜13B クラスのモデルを民生用 PC で動かす」という民主化が達成されましたが、100B を超える超巨大モデルは依然としてデータセンター規模のハードウェアを要していました。 その壁を破る新世代の推論技術として登場したのが、オープンソース推論エンジン Strata（Niko1221/Strata）です。

Strata は、125B パラメータの巨大スパース MoE（Mixture of Experts）モデルである「Qwen3.8-Flash-Next」を、VRAM 12GB〜16GB 程度の民生用 GPU（RTX 5070 や RTX 3060 等）と 32GB〜64GB のメインメモリ（RAM）を備えた一般的なゲーミング PC 上で、50〜90+ tokens/s という実用的な速度で動作させることに成功しています。

Strata を支えるコア技術アーキテクチャ

Strata の高速推論は、ハードウェアの記憶階層（VRAM・RAM・SSD）を徹底的に使い分ける独自のハイブリッドパイプラインによって実現されています。

• 3 階層ハイブリッドメモリ管理（VRAM / RAM / SSD）:

  • GPU VRAM（高速キャッシュ層）: 毎トークン必ず通過する Attention や DeltaNet ミキサー、ルーター、共有エキスパート、出力ヘッド、MTP ドラフト層を VRAM に常駐させます。さらに、後述する MoE エキスパートのうち最も頻繁に使われるものを動的キャッシュとして保持します。
  • システム RAM（主記憶層）: 24,576 個のエキスパート重み全体（約 34GB〜50GB）をピン留めメモリ（Pinned Memory）として RAM に常駐させます。
  • NVMe SSD（外部記憶層）: メモリ容量が限られる環境（低 RAM モード）では、OS のファイルキャッシュを活用しながら mmap で必要なエキスパートをオンデマンドで高速読み出しします。

• 動的エキスパートキャッシュ（Dynamic Expert Caching）と適応型スワッピング: MoE モデルでは、1 トークンの生成時に活性化するエキスパートはごく一部（例: 24,576 個中 10 個）です。Strata は会話中のアクセス頻度プロファイルを学習・追従し、ホットなエキスパートを VRAM キャッシュへ自動的に入れ替えます（Hit 率 60〜75% 以上）。これにより、演算の大半を GPU の超高速メモリ帯域内で完結させます。

• CPU / GPU 並列協調計算（Hybrid Co-Execution）: VRAM キャッシュにヒットしなかったエキスパート（ミスした重み）は、待機することなく CPU（AVX-512 / AVX2 に最適化されたマルチトークン並行カーネル）が RAM 上で直接インプレース計算するか、あるいは一部を PCIe 経由で非同期ストリーミングして GPU で処理します。GPU と CPU が同時に稼働することで、ボトルネックを最小化します。

• MTP（Multi-Token Prediction）投機的デコーディング: Qwen アーキテクチャ固有の MTP ドラフト層を組み合わせることで、1 回の検証ウィンドウで複数トークンを同時に提案・検証し、12GB VRAM 環境でも 60〜90+ tokens/s という驚異的な出力スループットを実現します。さらに、多言語対応のドラフト語彙（CJK 語彙等）により日本語などの非英語生成も大幅に高速化されています。

• KV キャッシュの最適化とストリーミング: 長文脈（128K〜262K トークン）の処理時、アテンションが直接参照しない過去の KV キャッシュを RAM 側へ退避し、必要なウィンドウのみを VRAM に保持する「KV ストリーミング」や、4bit/8bit 量子化・ハイブリッド K8V4 キャッシュを採用し、VRAM の消費を最小限に抑えています。

llama.cpp と Strata の違い・比較整理

llama.cpp と Strata は、どちらもローカル環境での推論を可能にするオープンソース技術ですが、その設計思想と最適化対象は大きく異なります。

動作要件と民生用 PC（32GB RAM / 12GB VRAM）での最適構成

Strata を実用的に動作させるためのハードウェア要件と、代表的なミドルハイクラスのゲーミング PC（例: RTX 5070 12GB + RAM 32GB + NVMe SSD 空き 200GB）における最適なモデル選定・設定構成を整理します。

システムメモリ（RAM）の要件と内訳

フルモデル（Qwen3.8-Flash-Next 125B）を通常モードで動作させる場合、システム RAM は 64GB が推奨されます。

• VRAM（GPU 側: 12GB）: Attention、ルーター、共有エキスパート、MTP ドラフト層、および最も頻繁に使われるホットな MoE エキスパートを動的キャッシュとして格納（全体の 60〜75% 以上のアクセスを吸収）。
• システム RAM（CPU 側）: 全エキスパート重み（Q2_0: 約 34GB、IQ2_XS: 約 36GB、IQ3_XXS: 約 43GB）をピン留め保持し、OS や作業バッファ（約 6GB〜10GB）と合わせて合計 40GB〜50GB 程度をコミット。

RTX 5070 (12GB) + RAM 32GB 環境におけるベストプラクティス

多くのゲーミング PC で一般的な「32GB RAM ＋ 12GB VRAM ＋ 高速 NVMe」の環境では、以下の 2 つのアプローチが実用的です。

1. 【最推奨】Qwen3.8-Flash-Next Coder（コード・推論特化版）:

   • 構成: エキスパート数を 256/512 個に厳選した剪定モデル。エキスパート必要 RAM が 約 23GB に抑えられており、OS（約 6GB）と合わせても 32GB RAM 内に完全に常駐します。
   • 性能: SSD のスワップ待ちが発生せず、RTX 5070 の能力をフルに引き出して 約 55 tokens/s（プロンプト処理 約 2,180 tokens/s） の高速レスポンスを維持できます。
   • 適正: プログラミング支援やコーディングエージェントだけでなく、高い論理思考力により一般的な日本語対話や指示追従タスクも極めて高精度にこなせます。

2. 【汎用重視】フルモデル Q2_0 ＋ 低 RAM 常駐モード（Low-RAM Resident Mode）:

   • 構成: 125B フルモデルの知識量をそのまま利用したい場合、Strata の低 RAM モード（--low-ram resident）を適用します。
   • 動作: VRAM に約 16GB 分のエキスパートをキャッシュし、残りのうち使用頻度の高いエキスパートを RAM（約 16GB 枠）に常駐させ、稀にしか使われないエキスパートのみを NVMe SSD からオンデマンドで読み出します。
   • 性能: SSD からの読み出しが発生する場面で若干のレイテンシがありますが、高速な NVMe SSD（空き 100GB〜110GB 程度を使用）があれば実用的な速度を保てます。

推奨実行パラメータ

32GB RAM 環境でメモリ不足を防ぎ、安定して最大パフォーマンスを引き出すための推奨設定です。

• コンテキスト長: 32K（32,768 トークン）〜 64K。コンテキストを 128K 以上に広げると KV キャッシュの RAM 消費が増加するため、日常的な用途では 32K〜64K が最もバランスに優れます。
• KV キャッシュ設定: --kv k8v4（ハイブリッド量子化）。Key を 8bit、Value を 4bit で保持することで KV キャッシュのメモリ消費を約 23% 削減し、GPU 側により多くのエキスパートをキャッシュさせることができます。
• ストレージ配置: モデル本体（約 70GB）とキャッシュファイル群（約 30GB）を同一の高速 NVMe SSD 上に配置します。

ローカル AI の新たな地平

llama.cpp が切り拓いた「ローカル LLM の民主化」は、Strata のような次世代エンジンの登場によって、「商用フロンティア級の巨大モデルすらも手元のコンシューマー PC で日常的に駆動できる」という新たな段階へと突入しました。

汎用性を追求して世界中のモデルを走らせる llama.cpp と、特定のアーキテクチャ特性（巨大スパース MoE）を突き詰めて限界性能を引き出す Strata は、ローカル AI エコシステムにおいて互いに補完し合いながら進化を続けています。

本書のまとめ

本書では、LLaMA の登場から、その内部アーキテクチャ、OpenLLaMA による完全オープンの実現、llama.cpp によるローカル推論技術、そして最新の Strata に至るエコシステムの発展までを体系的に見てきました。

1. 小さく賢いモデルへの転換: 過剰なパラメータ数ではなく、学習データ量の拡充によって実用性と高効率を両立した。
2. 洗練されたアーキテクチャ: RMSNorm、SwiGLU、RoPE、GQA の組み合わせにより、安定性と推論速度を極限まで高めた。
3. オープン化の精神とエコシステム: RedPajama と OpenLLaMA がライセンスの壁を破り、誰でも自由に利用できる基盤を作った。
4. C/C++ と量子化による民主化: llama.cpp と GGUF が高価なハードウェアの制約を取り払い、世界中の開発者の PC に AI を届けた。
5. 次世代 MoE と階層型推論の進展: Strata に見られるように、動的キャッシュと投機的デコーディングを駆使することで、100B 超の最先端モデルすら家庭用ハードウェアで実用速度で動作する時代が到来した。

オープンモデルとローカル推論の進化は今なお続いています。本書で学んだ基礎知識を足がかりに、ぜひご自身の手で最新のローカル AI 環境を構築し、新しいアプリケーションの創出に挑戦してください。