Llama 3.1は、Metaが2024年7月23日に公開した大規模言語モデルです。公開から2年が経ち、Metaの開発の主軸は別のモデル系列へ移りましたが、Llama 3.1の重みは今も配布が続いており、手元のマシンで動かせるモデルとしての価値は落ちていません。ここでは公式のモデルカードと発表資料をもとに、仕様・Llama 3との違い・ローカル実行の手順、そして2026年8月時点で選ぶ価値があるかどうかまでを整理します。
まとめ
Llama 3.1は8B・70B・405Bの3サイズで、いずれもコンテキスト長は128Kトークン。15兆トークンを超えるデータで学習され、知識のカットオフは2023年12月です。アーキテクチャはデコーダーのみの自己回帰型Transformerで、推論効率のためにGQA（Grouped-Query Attention）を採用しています。入力はテキストのみで、画像を扱えるようになったのは後続のLlama 3.2からです。
実務上いちばん影響が大きいのは、公式の対応言語8種に日本語が含まれない点。日本語のタスクが主目的なら、Llama系を日本語で追加学習した派生モデルを選ぶほうが結果は安定します。また、MetaがホストしていたLlama APIは2026年7月6日に終了しており、現在Metaの開発者ドキュメントに載っているのはMuse Spark系のモデルです。Llama 3.1を使うということは、実質的にローカルまたは第三者ホストで動かすという選択になります。以下、各項目を数値と出典つきで見ていきます。
Llama 3.1の3サイズと128Kコンテキストの仕様
Llama 3.1は同時に3つのサイズで公開されました。Ollamaでの配布サイズを併記すると、手元の空き容量から選べるモデルが判断できます。
| モデル | パラメータ数 | Ollama配布サイズ | コンテキスト長 |
|---|---|---|---|
| Llama 3.1 8B | 約80億 | 4.9GB | 128K |
| Llama 3.1 70B | 約700億 | 43GB | 128K |
| Llama 3.1 405B | 約4,050億 | 243GB | 128K |
個人のPCで現実的に動くのは8Bだけです。70Bは43GB、405Bは243GBあり、後者は複数GPUを積んだサーバー用途になります。Metaは405Bを「最先端の能力という点でトップのAIモデルに匹敵する初のオープンに利用可能なモデル」と位置づけ、16,000基を超えるH100 GPUで学習させ、150を超えるベンチマークデータセットで評価したと発表しています。
デコーダーのみの自己回帰型Transformerという構造
Llama 3.1のアーキテクチャは、公式モデルカードの記述では「最適化されたTransformerアーキテクチャを用いる自己回帰型言語モデル」。ここを誤解した解説が少なくありませんが、Llamaにエンコーダー層は存在しません。入力トークンから次のトークンを1つずつ予測していくデコーダーのみの構成です。翻訳モデルなどで使われるエンコーダー・デコーダー型とは設計が違うため、「エンコーダーが特徴を抽出してデコーダーが出力する」という説明はLlamaには当てはまりません。
推論効率の面ではGQAを採用しています。アテンションのKey/Valueヘッドを複数のQueryヘッドで共有する方式で、KVキャッシュのメモリ使用量を抑えられます。128Kという長いコンテキストを現実的なメモリ量で扱えるのは、この仕組みによるところが大きいです。
対応8言語に日本語が入らないという制約
公式モデルカードが挙げる対応言語は、英語・ドイツ語・フランス語・イタリア語・ポルトガル語・ヒンディー語・スペイン語・タイ語の8つ。日本語は入っていません。日本語を入力しても応答は返りますが、それはMetaが品質を保証している範囲外の使い方です。
日本語での利用が前提なら、Llamaを日本語データで追加学習した派生モデルを検討したほうが確実です。ELYZAが公開した8BモデルについてはLlama-3-ELYZA-JP-8Bとは？日本語特化LLMの性能・Ollamaでの使い方を解説で、東京科学大学情報理工学院の岡崎研究室・横田研究室と産業技術総合研究所の研究チームが開発したSwallowについてはSwallowとは？Llama 3.3 Swallowの特徴・日本語性能・商用利用を解説で扱っています。
Llama 3.1 Community Licenseで課される3つの条件
ライセンスはLlama 3.1 Community Licenseという、Meta独自の商用ライセンスです。Apache 2.0やMITと同じ感覚で扱えないのは、次の条件が付くためです。
まず、直前の暦月における月間アクティブユーザーが7億人を超える製品・サービスで利用する場合、Metaへ別途ライセンスを申請する必要があります。次に、配布時にはWebサイト・UI・ブログ・製品ドキュメントのいずれかへ「Built with Llama」を目立つ形で表示することが求められます。さらに、Llamaを使って作った派生モデルを配布する場合、そのモデル名の先頭に「Llama」を含めなければなりません。7億MAUの条件に触れる日本企業はほぼありませんが、後ろ2つは自社サービスへ組み込む際に実務上そのまま効いてきます。
Llama 3からLlama 3.1への変更点
Llama 3の公開は2024年4月18日、Llama 3.1は同年7月23日。3か月差のマイナーバージョンアップですが、中身の差は小さくありません。
最大の変更はコンテキスト長で、Llama 3の8Kから128Kへと16倍に拡張されました。長い仕様書やソースコード一式をまとめて投入できるようになった差です。次に405Bの追加。Llama 3は8Bと70Bの2サイズでしたが、3.1で初めて数千億パラメータ級が加わりました。さらに公式の対応言語が8言語へ拡張され、多言語モデルとして明示されたのもこの版からです。
同じ8Bどうしの精度差は、公式モデルカードのベンチマークに出ています。MMLU（CoT、0-shot）はLlama 3 8B Instructの65.3に対しLlama 3.1 8B Instructが73.0、コード生成のHumanEval（0-shot）は60.4に対し72.6。マイナーバージョンの表記に反して、同じサイズのまま実用上の差が付いています。
なお「Llama 3.0」という表記を見かけることがありますが、Metaの公式な呼称はLlama 3です。その後の系譜は、画像入力に対応したLlama 3.2が2024年9月25日、70B単体のLlama 3.3が2024年12月6日、MoE構成に切り替わったLlama 4が2025年4月5日と続きます。
OllamaとLlamaの違い（実行ツールと学習済み重み）
名前が似ているため混同されがちですが、この2つは種類の違うものです。Llamaはモデルそのもの、つまり学習済みの重みファイル。Ollamaはそのモデルをローカルで動かすための実行ツールで、Metaではなく別の開発チームが提供するオープンソースのソフトウェアです。
関係としては、動画ファイルと動画プレイヤーに近い構図。Ollamaはモデルのダウンロード、量子化済みファイルの管理、APIサーバーとしての起動をまとめて引き受けます。Ollamaで動かせるモデルはLlamaに限らず、他社のオープンモデルも同じ手順で扱えます。逆にLlama 3.1はOllama専用ではなく、Hugging Faceから重みを直接取得して別のランタイムで動かすこともできます。
Ollamaを起点に構成を広げる話は、OllamaとOpen WebUIでファイルをアップロードしRAGチャットを実現する方法とOllama Web Searchとは？使い方・APIの設定・料金とPython実装をわかりやすく解説で具体的に扱っています。
Llama 3.1 8Bのローカル実行に必要なリソースと手順
llama3.1:8b 4.9GBに必要なディスクとメモリの目安
Ollamaが配布するllama3.1:8bは4.9GBです。これは4bit量子化（q4_K_M）された状態のサイズで、ディスクにこの容量が要ります。GPUへモデル全体を載せて動かすなら、VRAMがこの4.9GBを上回っている必要があります。VRAMに収まらない分はシステムメモリ側で処理されるため動作自体は継続しますが、生成速度は落ちます。GPUを使わずCPUだけでも動きます。
128Kのコンテキストをフルに使う場合、KVキャッシュがモデル本体とは別にメモリを消費します。長文を扱う予定がないなら、実行時にコンテキスト長を絞ったほうがメモリ面では有利です。
ollamaコマンドでの起動
Ollamaを導入済みなら、モデルの取得と対話の開始は1コマンドで完了します。
ollama run llama3.1:8b初回はモデルのダウンロードが走り、完了後にそのまま対話プロンプトへ入ります。タグを省いてollama run llama3.1と書いた場合も8Bが選ばれます。70Bを試すならollama run llama3.1:70bですが、43GBの取得と展開が先に必要です。
ファインチューニングと転移学習の使い分け
この2語はしばしば同じ意味で使われますが、指す範囲が違います。転移学習は、あるタスクで学習した知識を別のタスクに流用するという考え方そのもの。ファインチューニングは、その考え方を実装する手法の一つで、学習済みモデルのパラメータを新しいデータで更新する作業を指します。つまりファインチューニングは転移学習の一部です。
Llama 3.1のような基盤モデルを業務に合わせる場面では、全パラメータを更新するフルファインチューニングは8Bでも相当のGPUメモリを要求します。実務ではLoRA（Hu et al., 2021で提案された低ランク適応）のように、元の重みを凍結して追加した小さな行列だけを学習する手法が使われます。更新対象のパラメータ数が数百分の1以下に減るため、必要なメモリも大きく下がります。
判断の目安として、モデルに新しい知識を覚えさせたいのか、出力の形式や口調を揃えたいのかを先に切り分けてください。後者はプロンプトの設計やfew-shotの例示だけで足りることが多く、学習を回すコストに見合わない場合があります。社内文書の内容を参照させたいだけなら、ファインチューニングよりRAGのほうが更新も容易です。
2026年8月時点でLlama 3.1を選ぶ判断基準
Meta公式のLlama API終了とMuse Sparkへの移行
MetaがホストしていたLlama APIは、パブリックプレビューのまま2026年7月6日に終了しました。現在Metaの開発者ドキュメントに掲載されているモデルはmuse-spark-1.1、muse-spark-1.2、muse-spark-1.2-contributorで、コンテキスト長は1,048,576トークン、モデル表に記載された入力はテキスト・画像・動画・PDFです。Muse SparkはMeta Superintelligence Labsが2026年4月8日に公開したモデルで、発表時点では選ばれたパートナー向けにAPIのプライベートプレビューとして提供される形でした。Llamaの名前はモデル一覧から消えており、llama.comへアクセスするとdeveloper.meta.comへ301リダイレクトされます。
ただし、これはLlama 3.1が使えなくなったという話ではありません。重みの配布は続いており、ローカル実行や第三者のホスティングサービス経由での利用に影響はない状態です。Llama 4以降のMetaの基盤モデル再構築の経緯はLlama 4の失敗を経てMetaが一から再構築した次世代基盤モデルAvocadoの全貌で整理しています。
同クラスのローカルモデルとの選び分け
8B前後でローカル実行できるモデルは複数あり、Llama 3.1 8Bが常に第一候補になるわけではありません。用途で切り分けるのが実際的です。
日本語の読み書きが中心なら、Llama-3-ELYZA-JP-8BやLlama 3.3 Swallowのように日本語データで追加学習された派生モデルが有利です。ベースはLlama系のままなので、Ollamaでの扱い方はほぼ変わりません。一方、英語中心の処理や、海外製ツールとの組み合わせで検証済みの構成をなぞりたい場合は、素のLlama 3.1 8Bのほうが情報量の面で有利になります。より新しいMeta製モデルを求めるならLlama 4がありますが、MoE構成で最小サイズでも109B級のため、8Bと同じ感覚ではローカルに載りません。
Llama 3.1を選ぶ価値が残る条件
2年前のモデルを今あえて選ぶ理由があるとすれば、次の条件に当てはまる場合です。
- データを外部に出せず、ローカル完結が要件になっている
- 4.9GBのファイル1つで完結する、依存の少ない構成を優先したい
- 提供元の都合でAPIが終了するリスクを避けたい
- 英語中心のタスクで、8B級の精度で足りることが確認できている
3つ目の「終了リスクを避けたい」は、今回のLlama API終了がそのまま実例になりました。手元にある重みファイルは、提供元の事業判断で消えることがありません。ローカルLLMを選ぶ動機として、この点は精度の議論とは別の軸で効いてきます。
Llama 3.1を選ぶべきでない場面
逆に、次のケースでは他の選択肢を採るべきです。
日本語が主な用途なら、Llama 3.1をそのまま使う理由はありません。公式の対応8言語に日本語が入っていない以上、日本語性能はMetaが調整の対象にしていない領域です。日本語データで追加学習された派生モデルのほうが、同じパラメータ数でも実用的な出力を返します。
最新の知識が必要な場合も外れます。知識のカットオフは2023年12月で固定されており、それ以降の出来事はモデル内部に存在しません。2024年以降の情報を扱うなら、RAGで外部データを与えるか、新しいモデルへ切り替えるかのどちらかが必要です。
画像やPDFを読ませたい場合も対象外。Llama 3.1はテキスト専用で、画像入力に対応したのは後続のLlama 3.2です。公式モデルカードでもLlama 3.2-Visionは「Llama 3.1のテキスト専用モデルの上に構築」され、別途学習されたvision adapterを組み合わせたものと説明されています。3.1に画像認識や音声認識の機能を期待すると前提を誤ります。
よくある質問
Llama 3.1は日本語に対応していますか？
公式に対応が明示されているのは英語・ドイツ語・フランス語・イタリア語・ポルトガル語・ヒンディー語・スペイン語・タイ語の8言語で、日本語は含まれません。日本語を入力しても応答自体は返りますが、品質が保証された使い方ではありません。日本語が主用途なら、日本語で追加学習された派生モデルを選ぶほうが安定します。
OllamaとLlamaは何が違いますか？
Llamaは学習済みモデルの重みそのもの、OllamaはそのモデルをローカルPCで動かすための実行ツールです。開発元も別で、OllamaはLlama以外のオープンモデルも同じ手順で扱えます。Llama 3.1の側も、Ollamaを使わずHugging Faceから重みを取得して他のランタイムで動かせます。
Llama 3.1 8Bを動かすにはどのくらいの容量が必要ですか？
Ollamaで配布されるllama3.1:8bは4.9GBです。ディスクにこの容量を確保したうえで、GPUに載せきるならVRAMが4.9GBを上回っている必要があります。70Bは43GB、405Bは243GBで、後者2つは個人のPCでは現実的ではありません。
ファインチューニングと転移学習はどう違いますか？
転移学習は既存の学習成果を別タスクへ流用する考え方の総称で、ファインチューニングはその実現手法の一つです。学習済みモデルのパラメータを新しいデータで更新する作業がファインチューニングにあたります。包含関係としては、ファインチューニングが転移学習の中に含まれます。
Llama 3.1は今も無料で使えますか？
重みの配布は続いており、Llama 3.1 Community Licenseの条件下でダウンロードして利用できます。ただしMetaがホストしていたLlama APIは2026年7月6日に終了したため、Metaのクラウド経由で呼び出す使い方はできません。ローカル実行か、Llamaを提供している第三者のホスティングサービスを利用する形になります。ライセンスの具体的な条件は本文の該当節で挙げたとおりです。
