Llama 3.1は、Metaが2024年7月23日に公開したオープンウェイトの大規模言語モデルです。8B・70B・405Bの3サイズがあり、重みは2026年11月時点でもHugging FaceとOllamaから取得できます。一方でMetaが運営していたLlama APIは終了し、Amazon Bedrockでも提供終了が決まりました。この記事では、公式モデルカードの数値をもとに3サイズの性能差と必要メモリ、日本語でどこまで使えるか、Ollamaとtransformersでの動かし方を整理し、今からLlama 3.1を選ぶべきかを判断できるようにします。Metaの現行モデルを知りたい場合はMeta Avocadoとは?正体はMuse Spark|Llama 4からの転換と現行モデル【2026年10月】を参照してください。
まとめ
Llama 3.1は、128Kトークンのコンテキストを持つテキスト専用のデコーダー型モデルです。知識のカットオフは2023年12月。個人のPCで現実的に動くのは8Bで、Ollamaの4bit版なら4.9GB、元の精度(bf16)では重みだけで約16GBを要し、実行にはKVキャッシュなどの追加メモリも必要です。
8B Instructの性能は、同じ8BのLlama 3からMMLU(CoT)が65.3→73.0、HumanEvalが60.4→72.6へ上がりました。ただし公式の対応8言語に日本語は入っていません。日本語の会話品質を測るJapanese MT-Benchでは、Llama 3.1を日本語で継続学習したLlama 3.1 Swallow 8B Instruct v0.5が0.719、元のLlama 3.1 8B Instructが0.519と大きな差があります。日本語が主用途なら、派生モデルを選ぶのが筋です。
提供面では、MetaのLlama APIが2026年7月6日に終了し、Amazon Bedrockの8B・70Bは2026年9月30日にLegacyへ移ってEOLが2027年3月30日です。クラウドAPIで長く使う前提なら、Llama 3.1は選びにくくなりました。手元のマシンで重みを持ち続ける使い方なら、提供元の都合で止まらない点がむしろ利点になります。
Llama 3.1の3サイズの仕様と必要メモリ
3サイズとも、コンテキスト長128K・学習データ約15兆トークン・知識カットオフ2023年12月は共通です(Meta公式のLlama 3.1モデルカード)。違うのはパラメータ数と、それに比例する必要メモリです。
| モデル | パラメータ数 | Ollama配布サイズ(4bit) | bf16の重み容量 | コンテキスト長 |
|---|---|---|---|---|
| Llama 3.1 8B | 約80億 | 4.9GB | 約16GB | 128K |
| Llama 3.1 70B | 約700億 | 43GB | 約140GB | 128K |
| Llama 3.1 405B | 約4,050億 | 243GB | 約810GB | 128K |
配布サイズはOllamaのllama3.1ページ、bf16の重み容量はHugging FaceのLlama 3.1公開時の解説ブログの値です。同ブログは、70Bを4bitで読み込むと約34GBで動くとしています。405Bは4bitの配布ファイルでも243GBあり、実行にはさらにKVキャッシュの分のメモリが要るため、個人のPCでは現実的ではありません。
デコーダーのみの自己回帰型という構造
モデルカードの記述は「最適化されたTransformerアーキテクチャを用いる自己回帰型言語モデル」です。入力から次のトークンを1つずつ予測するデコーダーのみの構成で、翻訳モデルのようなエンコーダー層はありません。推論ではGQA(Grouped-Query Attention)を使い、Key/Valueのヘッドを複数のQueryヘッドで共有してKVキャッシュを小さくしています。入力はテキストのみで、画像を読めるのは後続のLlama 3.2のVisionモデルからです。
ベンチマークで見る8B・70B・405Bの性能差
公式モデルカードのinstruct(対話調整済み)モデルの評価から、用途の判断に効く項目を抜き出しました。比較のため、同じサイズのLlama 3も並べています。
| ベンチマーク | Llama 3 8B | Llama 3.1 8B | Llama 3 70B | Llama 3.1 70B | Llama 3.1 405B |
|---|---|---|---|---|---|
| MMLU(CoT・0-shot) | 65.3 | 73.0 | 80.9 | 86.0 | 88.6 |
| MMLU-Pro(CoT・5-shot) | 45.5 | 48.3 | 63.4 | 66.4 | 73.3 |
| HumanEval(0-shot) | 60.4 | 72.6 | 81.7 | 80.5 | 89.0 |
| GSM-8K(CoT・8-shot) | 80.6 | 84.5 | 93.0 | 95.1 | 96.8 |
| MATH(CoT・0-shot) | 29.1 | 51.9 | 51.0 | 68.0 | 73.8 |
| GPQA(0-shot) | 34.6 | 30.4 | 39.5 | 46.7 | 50.7 |
| BFCL(ツール呼び出し) | 60.3 | 76.1 | 83.0 | 84.8 | 88.5 |
8Bで伸びが大きいのは数学(MATH 29.1→51.9)とツール呼び出し(BFCL 60.3→76.1)で、3.1から関数呼び出しを前提にした使い方が現実的になりました。逆にGPQA(大学院レベルの理科問題)は8Bで34.6→30.4と下がっており、難しい推論を8Bに任せる設計は避けるべきです。70Bと405Bの差はMMLUで2.6ポイントですが、HumanEvalでは8.5ポイント開きます。コード生成の精度が要件なら、70Bで足りるかを先に自社の課題で試してください。
Llama 3.1の日本語性能と日本語派生モデル
モデルカードが挙げる対応言語は、英語・ドイツ語・フランス語・イタリア語・ポルトガル語・ヒンディー語・スペイン語・タイ語の8つです。同じカードは、対応外の言語での利用を「対象外の使い方(Out-of-scope)」と明記し、ファインチューニングとシステム側の制御を入れないまま対応外の言語で対話させることを強く非推奨としています。日本語を入力すれば応答は返りますが、Metaが品質を調整した範囲の外です。
どの程度の差になるかは、Llama 3.1を日本語で継続学習したLlama 3.1 Swallow 8B Instruct v0.5のモデルカードが同じ条件で並べた数値で確認できます。
| 評価 | Llama 3.1 8B Instruct | Llama 3.1 Swallow 8B Instruct v0.5 |
|---|---|---|
| Japanese MT-Bench平均 | 0.519 | 0.719 |
| 日本語タスク平均 | 0.470 | 0.533 |
| JMMLU(5-shot) | 0.509 | 0.581 |
| 英語タスク平均 | 0.627 | 0.604 |
会話の品質を見るJapanese MT-Bench(gpt-4o-2024-08-06による採点を0〜1に正規化し、5回の評価を平均)で0.2の差があり、英語タスクの平均は0.023しか下がっていません。ただし英語のコード生成(HumanEval)は0.624から0.554へ下がるため、英語でのコーディング補助にも使うなら、置き換える前に自社の課題で比べてください。Swallow v0.5は2025年6月25日公開の8Bで、モデルカードによるとgemma-3-27b-itの振る舞いを手本に会話能力を学習しており、ライセンスはLlama 3.1 Community LicenseとGemma Terms of Useの両方に従います。
Llama系の日本語モデルはほかにもあります。ELYZAのLlama-3-ELYZA-JP-8Bとは|性能・必要スペックとGGUFのダウンロード、Ollamaでの使い方はLlama 3(3.1ではない)が土台です。Swallowの系列全体と、Llama以外を土台にした新しい版はSwallow LLMとは?最新のGPT-OSS Swallow・Qwen3 Swallow v0.2とモデル一覧・選び方【2026年10月】で扱っています。
Llama 3・3.2・3.3・4とLlama 3.1の違い
Llamaは3から4までの約1年で5回の版が出ています。3.1の位置づけは、版ごとの公開日とサイズを並べると分かります。
| 版 | 公開日 | サイズ | 主な違い |
|---|---|---|---|
| Llama 3 | 2024-04-18 | 8B・70B | コンテキスト8K |
| Llama 3.1 | 2024-07-23 | 8B・70B・405B | 128K・8言語・405B追加 |
| Llama 3.2 | 2024-09-25 | 1B・3B・11B・90B | 軽量版と画像入力(Vision) |
| Llama 3.3 | 2024-12-06 | 70B | 70Bのみの改良版 |
| Llama 4 | 2025-04-05 | Scout(総109B)・Maverick(総400B) | MoE構成・画像入力 |
3から3.1への変更は、コンテキストが8Kから128Kへ16倍になったこと、405Bが加わったこと、多言語対応を明記したことの3つです。3.2は3.1の上に作られた版で、1B・3Bはスマートフォンなど端末向け、11B・90BはLlama 3.1のテキストモデルに画像用のアダプターを足したものです。テキストの8Bより小さいモデルが要るなら3.2、70Bを使うなら同じサイズで後に出た3.3を選ぶのが基本で、8Bのテキストモデルとしては3.1が最後の版になります。「Llama 3.0」という表記を見かけますが、Metaの正式な名前はLlama 3です。
OllamaによるLlama 3.1 8Bの起動とAPI設定
Llamaは学習済みの重み、Ollamaはその重みをローカルで動かす実行ツールで、開発元も別です。Ollamaはモデルの取得・量子化済みファイルの管理・APIサーバーの起動をまとめて引き受けるため、Llama 3.1を手元で試す最短の方法になります。llama3.1はOllamaのライブラリで1億2,000万回以上ダウンロードされており、ツール呼び出し(tools)にも対応しています。
ollama runでの起動とコンテキスト長の設定
Ollamaを入れてあれば、取得から対話の開始までは1コマンドです。タグを省いたllama3.1は8Bと同じファイルを指します。
ollama run llama3.1:8b
注意したいのはコンテキスト長です。Ollamaは公式ドキュメントのとおり、VRAMが24GiB未満の環境では既定で4K(4,096トークン)しか割り当てません。Llama 3.1の128Kは自動では使われないので、長い文書を読ませるときは対話中に次のように広げます。
>>> /set parameter num_ctx 32768
割り当て済みのコンテキストとGPU・CPUの分担はollama psのCONTEXT列とPROCESSOR列で確認できます。コンテキストを広げるとKVキャッシュの分だけメモリが増え、VRAMからあふれた分はCPU側で処理されて生成が遅くなります。
OllamaのREST APIによるLlama 3.1の呼び出し
Ollamaは起動中、127.0.0.1:11434でAPIを受け付けます。アプリから呼ぶときは/api/chatに投げ、optionsでコンテキスト長も指定できます。
curl http://127.0.0.1:11434/api/chat -d '{
"model": "llama3.1:8b",
"messages": [
{"role": "user", "content": "Summarize the Llama 3.1 license in three bullet points."}
],
"options": {"num_ctx": 32768},
"stream": false
}'
Ollamaでファイルを読ませるRAG構成はOllamaでファイルをアップロード・読み込む方法|公式アプリとOpen WebUIのRAG設定【2026年10月】、ローカルLLM全般の構築はローカルLLMとは?クラウド型との違い・必要スペック・Ollamaでの構築手順を解説で扱っています。
Hugging FaceとtransformersによるLlama 3.1の実行手順
量子化しない元の精度で評価したい、ファインチューニングの土台にしたいといった場合は、Hugging Faceから重みを取ります。リポジトリはライセンスへの同意が必要なゲート付きで、meta-llama/Llama-3.1-8B-Instructのページでフォームを送り、承認後にアクセストークンでログインして取得します。
transformersは、Hugging Faceの公開時の解説が4.43.2以上を指定しています(モデルカードの記載は4.43.0以上)。Llama 3.1は128Kへ伸ばすためにRoPE(位置埋め込み)のスケーリングを変えており、それ以前の版では正しく読み込めません。
pip install "transformers[torch]>=4.43.2" huggingface_hub --upgrade
hf auth login
from transformers import pipeline
import torch
pipe = pipeline(
"text-generation",
model="meta-llama/Llama-3.1-8B-Instruct",
model_kwargs={"torch_dtype": torch.bfloat16},
device="cuda",
)
messages = [{"role": "user", "content": "What changed from Llama 3 to Llama 3.1?"}]
outputs = pipe(messages, max_new_tokens=256, do_sample=False)
print(outputs[0]["generated_text"][-1]["content"])
このコードはbf16で読み込むため、8Bの重みだけで約16GBを要し、推論時にはKVキャッシュや実行用バッファの容量も必要です。GPUがそれより小さい場合は、bitsandbytesで8bitか4bitに量子化して読み込むか、GGUF形式のファイルをOllamaやllama.cppで動かします。形式の違いはGGUFとは?量子化モデルフォーマットの仕組みとGPTQ・AWQとの違い・採用判断を解説【2026年版】にまとめています。
Llama 3.1 Community Licenseの3条件と商用利用
Llama 3.1は商用利用できますが、Apache 2.0やMITと同じ扱いにはなりません。ライセンス本文で実務に効くのは次の3点です。このほか、重みを再配布するときは所定の帰属表示を書いた「Notice」ファイルを同梱し、利用全体でAcceptable Use Policyを守る必要があります。
- 配布や製品への組み込みでは、ライセンス文の写しを添え、Webサイト・UI・ブログ・製品ドキュメントのいずれかに「Built with Llama」を目立つ形で表示する
- Llamaの重みやその出力・結果を使って作成・学習・改良したAIモデルを配布または利用可能にする場合は、モデル名の先頭に「Llama」を付ける
- Llama 3.1の公開日(2024年7月23日)の時点で、直前の暦月の月間アクティブユーザーが7億人を超えていた事業者は、Metaへ別途ライセンスを申請する
7億人の条件は、公開日時点で直前の暦月の利用者数を、関連会社が提供する製品・サービスも含めて数えて判定します。公開後に利用者が増えても、この条件に新たに当たることはありません。効いてくるのは2点目です。Llama 3.1の出力を合成データにして別のモデルを学習させること自体はライセンスが認めていますが、そのモデルを配布または利用可能にする場合は、名前を「Llama」で始める必要があります。Llama 3.1 Swallowが「Llama」で始まり、モデルカードに「Built with Llama」と書いているのはこのためです。
2026年11月時点のLlama 3.1の提供状況
MetaがホストしていたLlama APIは、パブリックプレビューのまま2026年7月6日に終了しました。2026年11月1日時点のMeta開発者ドキュメントのモデル一覧はMuse Wonder・Muse Spark・Muse Image・Muse Voice Transcribe・SAM・Muse Glimmerの6系統で、Llamaは載っていません。同ドキュメントのヘルプも、Llamaは自分でダウンロードしてホストするモデルで、MetaのModel APIでは動かさないと説明しています。旧サイトのllama.comにアクセスすると開発者サイトへ転送されます。Muse Sparkの性能や重みの公開状況はMuse Sparkとは?1.3の性能・API料金とMuse Spark OpenをOllama・SageMakerで動かす条件【2026年10月】で扱っています。
クラウド経由の提供も縮小しています。Amazon Bedrockのモデルライフサイクルでは、Llama 3.1の各モデルが次の扱いです。
| Bedrockのモデル | Legacy移行日 | EOL日 |
|---|---|---|
| Llama 3.1 8B Instruct | 2026-09-30 | 2027-03-30 |
| Llama 3.1 70B Instruct | 2026-09-30 | 2027-03-30 |
| Llama 3.1 405B Instruct | 2026-01-07 | 2026-07-07(終了済み) |
Legacyに入ったモデルは新規の利用者が使い始められず、既存の利用者も15日間呼び出しがないとアクセスを失う場合があります。Bedrock上でLlama 3.1を新しく採用する余地はもうありません。
一方で、重みの配布は続いています。2026年11月1日に確認したHugging Faceの8B Instructの「Downloads last month」は約462万回で、ローカルや自社サーバーで動かす使い方には影響がありません。
Llama 3.1を選ぶ条件と選ばない場面
2年以上前のモデルをあえて選ぶ理由は、性能より運用の側にあります。次の条件がそろうなら、Llama 3.1 8Bは今でも妥当な選択です。
- 英語中心の処理で、8B級の精度で足りることを自社の課題で確かめてある
- データを外部に出せず、ローカルや閉域で完結させる必要がある
- 検証済みの構成や論文の再現など、Llama 3.1を前提にした資料に合わせたい
- APIの提供終了に左右されず、同じ重みを長く使い続けたい
4点目は、Llama APIとBedrockの終了がそのまま実例になりました。手元に置いた重みファイルは、提供元の事業判断では消えません。
逆に、日本語が主な用途ならLlama 3.1をそのまま使う理由はありません。先の表のとおり、同じ8Bでも日本語で継続学習したSwallowのほうが会話品質で0.2高く出ます。2024年以降の知識をモデル単体で答えさせる用途にも向きません。RAGで外部データを渡すか、新しいモデルへ移ってください。画像やPDFのページ画像を直接読ませる用途も対象外で、Llama 3.2のVisionか画像に対応した別のモデルを選びます。PDFでも、抽出したテキストならLlama 3.1に入力できます。
業務の文書や口調に合わせたいときも、いきなりファインチューニングに進まないほうが安全です。社内文書を参照させたいだけならRAGのほうが更新しやすく、出力の形式を揃えるだけならプロンプトの例示で足りることが多いためです。どちらを選ぶかの判断はファインチューニングとは?LLMの追加学習の仕組み・RAGとの違いと使い分けを解説で整理しています。オープンモデルの選定から社内への組み込みまでを相談したい場合は、生成AI導入支援で承っています。
よくある質問
Llama 3.1は日本語に対応していますか?
公式の対応言語は英語・ドイツ語・フランス語・イタリア語・ポルトガル語・ヒンディー語・スペイン語・タイ語の8つで、日本語は含まれません。入力すれば日本語で応答しますが、Japanese MT-Benchでは日本語で継続学習したLlama 3.1 Swallow 8B Instruct v0.5の0.719に対し、元の8B Instructは0.519です。日本語が主用途なら派生モデルを選んでください。
Llama 3.1は今も無料で使えますか?
重みはLlama 3.1 Community Licenseの条件のもとで、Hugging FaceやOllamaから無料で取得できます。MetaのLlama APIは2026年7月6日に終了し、Amazon Bedrockの8B・70Bも2027年3月30日にEOLとなる予定です。今後はローカル実行か自社サーバーでの運用が中心になります。
Llama 3.1 8Bを動かすにはどのくらいのスペックが必要ですか?
Ollamaの4bit版(llama3.1:8b)はファイルが4.9GBですが、GPUだけで実行するには重みに加えてKVキャッシュや実行用バッファを収める空きVRAMが必要です。足りない分はCPUで処理されるため、遅くはなりますがGPUなしでも動きます。量子化しないbf16では重みだけで約16GBを要し、推論にはKVキャッシュなどの追加容量も必要です。
Llama 3.1とLlama 3.3はどちらを使うべきですか?
70Bを使うなら、同じサイズで後に出たLlama 3.3が基本です。Llama 3.3は70Bしかないため、8Bや405Bが必要な場合はLlama 3.1を使います。8Bより小さいモデルが欲しい場合は、1B・3BがあるLlama 3.2が候補になります。
OllamaとLlamaは何が違いますか?
Llamaは学習済みモデルの重み、Ollamaはその重みをローカルで動かすための実行ツールで、開発元も別です。OllamaはLlama以外のオープンモデルも同じ手順で扱え、Llama 3.1もOllamaを使わずにHugging Faceから取得してtransformersなどで動かせます。