Llama系を1から解説 — オープンLLMの本流
MetaのLlamaはなぜオープンLLMの本流になったのか。Llama 1の逆張り設計からLlama 3.xまでの系譜、llama.cpp・GGUF・Ollamaのエコシステム、そして商用利用前に必ず読むべきライセンスの罠を、前提知識ゼロから解説する。
要点
- オープンLLMは、学習済みニューラルネットの数十億個のパラメータ数値である重み(weights)を配布するモデルである。
- Llama 1は7B〜65Bの4種を最大1.4兆トークンで学習し、13BモデルがGPT-3を多くのベンチマークで上回ると報告された。
- LlamaはRMSNorm・SwiGLU・RoPEを備えたデコーダ専用Transformerで、以後のオープンLLMの事実上の標準形になった。
- llama.cppとGGUFにより、重みを4bit前後まで量子化したモデルがGPUのないノートPCでも動くようになった。
- Llamaのライセンスは独自で、OSI定義のオープンソースではなく、月間アクティブユーザー7億超の企業は別途ライセンスが必要である。
レシピを公開したレストラン
ChatGPTのような「閉じたLLM」は、高級レストランに似ています。料理(応答)は食べられますが、レシピ(モデルの中身)は門外不出。厨房を借りることも、味を自分好みに変えることもできません。
これに対してオープンLLMは、レシピ——正確には、学習を終えたニューラルネットの数十億個のパラメータ数値である重み(weights)——を配布するモデルです。重みが手に入ると、自分のPCやサーバーで動かす、社内データで追加学習する、中身を解剖して研究する、といったことがすべて可能になります。
そして2023年以降、このオープンLLMの世界の中心にいたのがMetaのLlama(ラマ)系列です。Llamaの系譜を一度押さえると、Mistral・Qwen・Gemmaといった他のオープン系モデルのニュースもすらすら読めるようになります。多くがLlamaの設計を出発点にしているからです。
Llama 1(2023年2月): 「小さく作って、長く学習する」という逆張り
当時の常識は「性能はパラメータ数で決まる」でした。GPT-3は175B(1750億)パラメータで、各社はより大きなモデルを競っていました。ところがDeepMindのChinchilla研究(2022年)が「同じ計算予算なら、モデルを小さくして学習データを増やすほうが得」と示します。
Llama 1はこの知見をさらに一歩進めました。「学習時のコスト効率では多少損をしてでも、推論時に安く動く小さめのモデルを、できるだけ大量のトークンで学習する」という方針です。サイズは7B・13B・33B・65Bの4種類、学習データは最大1.4兆トークン。論文は、13Bモデルが多くのベンチマークで(10倍以上大きい)GPT-3を上回ると報告しました。「大きさがすべてではない」を実証した瞬間です。
ライセンスは研究用途限定の申請制でしたが、公開されて間もなく重みファイルがネット上に流出します。皮肉なことに、この流出が歴史を動かしました。数週間のうちにStanfordのAlpaca(Llama 7Bを指示応答データで追加学習したもの)やVicunaなどの派生モデルが次々に生まれ、「土台(基盤モデル)さえ誰かが作れば、少ない計算資源で味付け(ファインチューニング)できる」という現在のオープンLLM文化の原型ができたのです。
系譜を追う前に: LLMは「次の一語の確率」を出す機械
すべてのLlamaに共通する動作原理を1つだけ押さえておきます。LLMは、文章の続きとして「次のトークン(単語の断片)が何になるか」の確率分布を出力する機械です。そして、その分布の尖り具合を制御するつまみが温度 です。
言い換えると、モデルが各候補トークン に付けた素点 (ロジットと呼びます)を温度 で割ってから、softmax(合計が1になるような正規化)で確率 に変換する、という式です。 を小さくすると1位の候補に確率が集中して出力は固く安定し、大きくすると候補間の差が均されて多様でランダムになります。
このあと登場するローカル実行ツールの --temp オプションは、この をそのまま触っています。
中身をのぞく: 堅実な改良Transformer
Llamaのアーキテクチャは、Attention機構を何層も積み重ねたデコーダ専用Transformerです。発明的な新機構はほとんどなく、当時すでに効果が確認されていた改良を堅実に全部載せしたのが特徴で、代表は3つあります。
1つ目はRMSNorm(事前正規化)。各層に入る前のベクトルを、その「典型的な大きさ」で割って揃えます。
言い換えると、 次元の入力 を、成分の2乗平均のルート(=ベクトルの典型的な大きさ)で割って長さを揃え、学習可能な倍率 を成分ごとに掛け直す、という操作です( はゼロ除算を防ぐ微小値、 は成分ごとの積)。平均を引かない分、標準的なLayerNormより計算が軽く済みます。
2つ目はSwiGLUという活性化まわりの改良で、同じ規模ならReLU系より性能が出やすいことが経験的に知られています。3つ目はRoPE(回転位置埋め込み)。単語の位置情報を「ベクトルを回転させる」形で埋め込む方式で、後の世代でコンテキスト長を大きく拡張できたのは、この設計の素性が良かったおかげです。
この「RMSNorm + SwiGLU + RoPE のデコーダ専用Transformer」という組み合わせは、以後のオープンLLM(Mistral、Qwenなど)の事実上の標準形になりました。Llamaを学ぶことが他モデルの理解に直結するのは、これが理由です。
Llama 2(2023年7月): 商用解禁とチャット化
Llama 2の変化は2つです。第一に商用利用が解禁され、企業が自社製品に組み込める最初のLlamaになりました。第二に、素の基盤モデルに加えて、対話用に調整済みのLlama 2-Chatが同梱されました。人間のフィードバックで応答を磨く工程(SFTとRLHF)を経ており、この工程の中身は指示チューニングとRLHFの記事で分解しています。
規模は7B・13B・70B、学習データは2兆トークンに増え、コンテキスト長は4096トークンへ倍増。最大の70BにはGQA(グループ化クエリ注意)——KeyとValueのヘッド数を減らして推論時のメモリを節約する仕組み——が導入されました。
Llama 3.x(2024年): データ量の徹底と系譜の完成
Llama 3(2024年4月、8B・70B)の設計上の目玉は2つ。語彙を約12.8万種に拡張した新しいトークナイザ(同じ文章をより少ないトークンで表せるため、同じコンテキスト長でも実質的に長く読める)と、全サイズへのGQA採用です。学習トークンは15兆超と、Llama 2の7倍以上。「小さめのモデルに大量データ」というLlama 1以来の哲学の徹底です。以後は小刻みに更新が続きます。
- 3.1(7月): 405Bを追加(公開重みとして最大級)、コンテキスト長を128Kへ拡張
- 3.2(9月): 端末向けの1B・3Bと、画像も読める11B・90B(vision)を追加
- 3.3(12月): 70Bの改良版。大型モデル級の使い勝手を70Bの推論コストで狙う調整
ただしコンテキスト128Kは「タダ」ではありません。注意機構の計算は文長の2乗で増えるからです。
なお、その後のLlama 4(2025年)はMoE(専門家の混合)構造へ舵を切りました。本記事が扱うLlama 1→3.xの「密な(dense)Transformer」の系譜は、3.3でひとつの完成を見たといえます。
エコシステム: llama.cpp・GGUF・Ollama
Llamaの影響力は、モデル本体と同じくらい「周辺に育った道具」にあります。中心はllama.cpp。Georgi Gerganov氏が2023年3月に公開したC/C++製の推論エンジンで、GPUのないノートPCでもLlamaが動くことを示して流れを変えました。鍵は量子化——重みを16bitから4bit前後まで圧縮してメモリを数分の1にする技術で、原理は量子化の記事で解説しています。
llama.cppが定義したファイル形式GGUFは、量子化済みモデルを配布する事実上の標準になりました。Hugging Faceで「GGUF」と検索すると、有志が変換した各モデルの量子化版が大量に見つかります。
# Ollama(llama.cpp系エンジンの使いやすいラッパー)で動かす
ollama run llama3.2
# llama.cpp本体を直接使う場合
./llama-cli -m Llama-3.2-3B-Instruct-Q4_K_M.gguf \
-c 8192 --temp 0.7 -ngl 99
ファイル名の Q4_K_M は量子化方式の名前(重み1個あたり約4bit)、-c はコンテキスト長、-ngl はGPUに載せる層数、--temp は前半で見た温度です。
ライセンス: 「オープン」だが「オープンソース」ではない
最重要の注意点です。Llamaのライセンス(Llama Community License)はMeta独自のライセンスで、OSI(Open Source Initiative)が定義する「オープンソース」の条件を満たしません。実務で効く条項を挙げます。
- 月間アクティブユーザー7億超の製品を持つ企業は、別途Metaからライセンスを得る必要がある(事実上、巨大テック企業を除外する条項)
- Llamaを組み込んだ製品・サービスには "Built with Llama" の表示義務がある
- Llamaを使って別のAIモデルを作る場合、そのモデル名の先頭に「Llama」を含める義務がある
- 利用規約(Acceptable Use Policy)で用途が制限される
- 条項はバージョンごとに異なる。たとえばLlama 2では出力を他モデルの改善に使うことが制限されていたが、Llama 3.1では条件付きで緩和されるなど、細部が動き続けている
「無料で落とせる=何をしてもよい」ではありません。商用組み込みの前に、自分が使うバージョンのライセンス原文を必ず確認してください。
現場ではこう使う
どの職種が、いつ: 社外にデータを出せない案件(医療・金融・社内文書の検索や要約)を持つMLエンジニアやバックエンドエンジニアが、「APIではなくオープンモデルで」と決めた瞬間から、この記事の内容がそのまま仕事になります。順番は、モデル選定 → 量子化レベル選定 → サービング構成です。
触るパラメータ・ツール: モデル選定ではまず「パラメータ数 × 量子化ビット数」でメモリを見積もります(Q4なら重みだけでパラメータ数×約0.5バイト、そこにコンテキスト分が乗る)。手元検証は llama.cpp / Ollama で --temp(温度)、top_p(確率上位からだけ選ぶ)、-c / num_ctx(コンテキスト長)、-ngl(GPU層数)。本番サービングではvLLMなどのサーバーを使うのが定石です。
知らないと事故になる落とし穴:
- チャットテンプレートの不一致。対話の書式(特殊トークンの並び)は世代ごとに違います。間違えてもエラーにはならず、「なんとなく品質が低い」状態で動き続けるのが最悪の性質で、原因調査が数日単位で溶けます
- 量子化のかけすぎ。4bit級までは実用になることが多い一方、極端に削ると小さいモデルほど壊れやすい。公開ベンチマークではなく自分のタスクで必ず検証する
- ライセンス確認漏れ。派生モデルの命名義務や "Built with Llama" 表示は忘れやすく、リリース後に製品名や画面の変更を迫られる事故につながります
面接で問われる形: 「なぜ70Bではなく8Bを選んだのですか」という問いに、Chinchilla以来のデータ量とモデルサイズの配分の話、そして推論コスト(メモリ・応答速度)の概算を添えて答えられれば、この記事の内容は身についています。
まとめ
- Llamaの本質は「小さめのモデルに大量トークン」という計算配分の逆張りと、重みを配るという配布戦略の掛け算
- アーキテクチャ(RMSNorm + SwiGLU + RoPE)はオープンLLM全体の標準形になり、系譜はLlama 3.xの密なTransformerでひとつの完成を見た
- 実務では llama.cpp / GGUF / Ollama という道具立てと、OSI定義外の独自ライセンスの読み込みが必須
次は、ローカル実行の品質とメモリを直接左右する量子化の中身(上でリンクした記事)を数式から追ってみてください。Llamaを「動かせる人」から「調整できる人」に変わる近道です。
コメント
コメントにはログインが必要です