この記事の日付について。 2026-09-26に調査・執筆し、公開日の2026-10-04に、Ollama公式ライブラリのタグ別サイズ(gemma4・qwen3.6・qwen3・qwen3.8・qwen3-next)、Ollama公式FAQの ollama ps の説明、筆者環境の ollama list / ollama show の表示を再確認して更新しました。本文中の「2026-09-26確認」は執筆時、「2026-10-04確認」は公開前の再確認の日付です。筆者環境の計測値は、断りがない限り2026-09-26の記録です。
この記事でわかること
- 手元のメモリが8GB・16GB・24GB・32GB以上のとき、Ollamaでそのまま使える日本語向けの候補がどれか
- 候補をモデル名の「B数」ではなく、Ollamaで落ちてくる実ファイルのサイズで選ぶ理由
- DGX Spark(統合メモリ128GB)で実際に使い続けているモデルと、品質不足でやめた構成の記録
- Gemma 4・Qwen3.6・Qwen3のライセンスと、商用利用の根拠URL
- 今日中に動かし始めるための最短のコマンドと、コンテキスト長の落とし穴
結論から書きます。32GB以上のメモリがあるなら、筆者が日常運用している qwen3.6:35b-a3b(23〜24GB)が最初に試す候補です。24GBなら gemma4:26b(16〜19GB)か qwen3.6:27b(18〜19GB)、16GBでは gemma4:12b(7.7〜8.0GB)か qwen3:14b(9.3GB)、8GBでは qwen3:8b(5.2GB)か qwen3:4b(2.5GB)が現実的な線です。サイズはいずれもOllama公式ライブラリの表示値です(2026-10-04確認)。
ただし、ファイルサイズがメモリより小さいことは動作の保証になりません。実行時にはKVキャッシュや作業用のバッファも必要で、短いコンテキストから試して ollama ps で配置を確かめる前提の候補です。筆者が実機で品質まで確かめたのは32GB以上の帯だけで、8〜24GB帯の候補は公式サイズから選んだ段階です。どこまでが実測で、どこからが公式値からの逆算かは、表ごとに明記します。
1. 選び方の基準──「何B」ではなく「何GB」で決める
ローカルLLMの紹介記事は、モデルを「7B」「27B」のようなパラメータ数で並べがちです。しかし、手元のPCに載るかどうかの大部分を決めるのは、量子化したあとのファイルサイズと、会話中に増えるKVキャッシュの合計です。これに実行時のバッファや、画像入力を使う場合の処理分が加わります。同じ「26B」でも、16ビットなら57.7GB、4ビット(Q4_0)なら14.4GBと4倍の開きがあります(Google AI for Developers『Gemma 4 model overview』最終更新2026-07-08)。
この記事では、次の4点で候補を絞りました。
- メモリに載るか: Ollama公式ライブラリに表示されるタグ別サイズが、手元のメモリより十分小さいこと
- 日本語が使えるか: 開発元のモデルカードが多言語対応を明記していること。実測できたものは実測結果を優先
- Ollamaで1コマンドで取れるか: 公式ライブラリにタグがあり、
ollama pullだけで始められること - 商用で使えるか: ライセンスが開発元の一次資料で確認でき、商用利用を妨げる独自条項がないこと
「量子化」は、モデルの重みを16ビットから8ビットや4ビットに丸めて小さくする処理です。Ollamaの標準タグは多くが4ビット前後に量子化済みで、q8_0 や bf16 の付いたタグはより大きく、元の精度に近い版です。たとえば qwen3.6:27b は標準で18〜19GB、q8_0 で30GB、bf16 で56GBです(Ollama library qwen3.6 tags 2026-10-04確認)。
2. 一次資料の対応表
この記事の数字は、次の一次資料と筆者の作業記録から取っています。
| 主張 | 一次資料 | 種別 | 確認日 |
|---|---|---|---|
| gemma4の各タグのサイズ(e2b 4.6〜7.5GB、e4b 6.6〜9.5GB、12b 7.7〜8.0GB、26b 16〜19GB、31b 19〜20GB)とコンテキスト長 | Ollama library gemma4 tags | 公式ライブラリ | 2026-10-04 |
| qwen3.6の各タグのサイズ(27b 18〜19GB、35b-a3b 23〜24GB、q8_0/bf16版を含む) | Ollama library qwen3.6 tags | 公式ライブラリ | 2026-10-04 |
| qwen3の各タグのサイズ(4b 2.5GB、8b 5.2GB、14b 9.3GB) | Ollama library qwen3 | 公式ライブラリ | 2026-10-04 |
| Gemma 4の5サイズと、BF16・SFP8・Q4_0別の重みのメモリ量 | Google AI for Developers『Gemma 4 model overview』 | 公式ドキュメント | 2026-09-26 |
| Gemma 4はApache 2.0、事前学習140超・そのまま使える35超の言語 | Hugging Face google/gemma-4-26B-A4B-it、Google Open Source Blog 2026-04-02 | モデルカード・公式ブログ | 2026-09-26 |
| Qwen3.6-35B-A3B・Qwen3.6-27BはApache 2.0 | Hugging Face Qwen/Qwen3.6-35B-A3B、Qwen/Qwen3.6-27B | モデルカード | 2026-09-26 |
| Qwen3-8BはApache 2.0、100超の言語と方言に対応 | Hugging Face Qwen/Qwen3-8B | モデルカード | 2026-09-26 |
| Ollamaの既定コンテキスト長はVRAM量で4k/32k/256kに変わる | Ollama docs: Context length | 公式ドキュメント | 2026-09-26 |
| llama.cppはMITライセンス、1.5〜8ビットの整数量子化に対応 | GitHub ggml-org/llama.cpp | GitHub | 2026-09-26 |
| DGX Sparkでの速度・品質の実測、登録モデルとサイズ、ローカルLLMでの記事生成をやめた経緯 | 筆者の作業記録(2026-04-03、2026-07-14、2026-08-04、2026-09-08) | 実測・運用記録 | 2026-09-26 |
Ollamaのqwen3.6のページには、ライセンスの記載がありませんでした(2026-09-26確認)。ライセンスはHugging Faceのモデルカードで確認しています。
3. メモリ量別の候補一覧
まず全体像です。「実測」列が「あり」のものだけが、筆者が日本語の出力品質まで確かめたモデルです。
| 名前(Ollamaタグ) | 種別 | サイズ(公式表示、2026-10-04確認) | 目安のメモリ帯 | ライセンス | 費用 | 実測 | 向く人 |
|---|---|---|---|---|---|---|---|
qwen3:4b | 密モデル 4B | 2.5GB | 8GB | Apache 2.0(Qwen3系) | 無料 | なし | 8GBのノートでまず動かしたい人 |
qwen3:8b | 密モデル 8B | 5.2GB | 8GB〜 | Apache 2.0 | 無料 | なし | 8GB機で少しでも質を上げたい人 |
gemma4:12b | 密モデル 12B | 7.7〜8.0GB | 16GB | Apache 2.0 | 無料 | なし | 16GB機で画像入力も試したい人 |
qwen3:14b | 密モデル 14B | 9.3GB | 16GB | Apache 2.0(Qwen3系) | 無料 | なし | 16GB機で文章処理を中心に使う人 |
qwen3.6:27b | 密モデル 27B | 18〜19GB | 24GB | Apache 2.0 | 無料 | なし | 24GB GPUでコーディング用途も狙う人 |
gemma4:26b | MoE 総25.2B/活性3.8B | 16〜19GB | 24GB | Apache 2.0 | 無料 | なし(別の4ビット版を128GB機で運用) | 24GB以上で速さと質の両立を狙う人 |
qwen3.6:35b-a3b | MoE 総35B/活性3B | 23〜24GB | 32GB以上 | Apache 2.0 | 無料 | あり(128GB機) | 32GB以上で翻訳・要約を日常的に回す人 |
「Apache 2.0(Qwen3系)」は、同じQwen3系列のQwen3-8Bのモデルカードで確認した表記です。4Bと14Bの個別カードは今回開いていません。
メモリ帯は「モデルファイルのサイズ+OSやブラウザが使う分+KVキャッシュ」がメモリに収まるかで判断しました。KVキャッシュは会話の長さに比例して増えます。この記事ではコンテキスト長別のメモリ量を測れていないため、ファイルサイズに対して数GBの余裕を残す帯に振り分けています。数GBの余裕があればロードできるという保証ではなく、短いコンテキストで試し始めるための目安です。GPU専用のメモリ(VRAM)と、OSやアプリと共有するメインメモリは別に数えます。たとえば8GBのVRAMと8GBのメインメモリでは、モデルに回せる量が異なります。
サイズの幅について補足します。2026-09-26の確認時は各タグに1つの値が表示されていましたが、2026-10-04の確認では gemma4:26b などが「16GB - 19GB」のような幅で表示されていました。gemma4:26b のページには mlx と llamacpp の2種類が並んでおり、16GBが前者、19GBが後者です(Ollama library gemma4:26b 2026-10-04確認)。費用の欄は重みの利用料で、電気代や機材費は含みません。
4. DGX Sparkでの検証環境と実測結果
検証環境
| 項目 | 内容 |
|---|---|
| 機材 | NVIDIA DGX Spark |
| GPU | NVIDIA GB10(Blackwell) |
| メモリ | CPUとGPUで共有する統合メモリ128GB(専有VRAMなし) |
| OS / アーキテクチャ | Linux / ARM64(aarch64) |
| Ollama | 0.32.0(筆者の作業記録では2026-07-14に0.13.5から更新。更新日は記録非公開のため外部からは検証できません) |
| ドライバ | 作業記録に版の記載なし |
| 検証日 | 速度・品質は2026-07-14、登録モデルとサイズは2026-08-04、校正比較は2026-09-08 |
登録モデルと実サイズ(2026-08-04の記録)
| モデル | 用途 | サイズ(筆者環境での記録値、記録非公開) |
|---|---|---|
gemma4の26B 4ビット版(筆者環境での登録名 gemma4-qat:26b) | 知識抽出・文章生成 | 14GB |
| qwen3.6:35b-a3b | 翻訳・要約・分類 | 23GB(Ollama公式の表示は23〜24GB、Ollama library qwen3.6 tags 2026-10-04確認) |
| qwen3-next:80b | 大型の汎用モデル | 50GB |
| deepseek-ocr | 論文PDFの図表OCR | 6.7GB |
gemma4-qat はOllama公式ライブラリに同名のページがありません(2026-09-26確認、2026-10-04確認とも404)。筆者の環境で付けた登録名で、14GBという値はGoogleの表にあるGemma 4 26B A4BのQ4_0(14.4GB)に近い大きさです。2026-10-04に ollama show gemma4-qat:26b で確認すると、量子化はQ4_0、パラメータ数は25.2Bと表示され、画像入力(vision)の機能は表示されませんでした。公式タグ gemma4:26b のllama.cpp版は19GBで、その内訳はQ4_K_Mの本体17GB、画像処理用のprojector 1.2GB、投機的デコード用のdraftモデル462MBです(Ollama library gemma4:26b 2026-10-04確認)。同じ26Bでも5GBほどの差があり、量子化の方式に加えて同梱物の違いも含みます。公式には gemma4:26b-a4b-it-qat(16GB)というタグもありますが、筆者の登録名とは別物です。
2026-10-04の再計測(ollama list)では、gemma4-qat:26b 14GB、qwen3.6:35b-a3b 23GB、deepseek-ocr 6.7GBで、上の記録と同じでした。qwen3-next:80b は現在は登録されていません。ollama show qwen3.6:35b-a3b の表示は、量子化Q4_K_M、パラメータ数36.0Bです。
5. メモリ量別のおすすめ
32GB以上: qwen3.6:35b-a3b を主力に
筆者が2026年7月から翻訳・要約・分類に使い続けているのがこのモデルです。現在も記事候補の分類器として、コンテキスト長49,152トークンに設定して動かしています(筆者の設定ファイル config/editorial.json)。筆者の運用記録(入出力のログは非公開で、第三者による再現はしていません)では、日本語訳と要約の品質、校正での数値保持の両方で問題が出ませんでした。この評価はDGX Spark(128GB)上のもので、32GB機で同じコンテキスト長が使えることは確かめていません。
注意点は2つです。思考モデルなので、筆者の環境ではAPIから使うときに "think": false を付けないと、思考だけで出力枠を使い切って応答が空になることがありました。また、筆者の環境ではOllama 0.13.5で unknown model architecture: 'qwen35moe' と出て読み込めず、0.32.0に更新したあとは読み込めるようになりました(いずれも筆者の作業時の記録による。ログは非公開で、0.32.0のリリースノートにqwen35moeへの言及は見当たりません)。
64GB以上あるなら、8ビット版の qwen3.6:35b-a3b-q8_0(39GB)も選択肢に入ります(Ollama library qwen3.6 tags)。筆者は8ビット版と4ビット版の品質差を測っていません。
24GB: gemma4:26b か qwen3.6:27b
24GBのGPU(またはメモリ)では、16〜19GBの gemma4:26b と18〜19GBの qwen3.6:27b が、ファイルサイズの上では収まる候補です。残りは5〜8GBなので、短めのコンテキストで試す前提になります。Ollama公式ライブラリは gemma4:26b を活性4BのMoEと説明しています(Ollama library gemma4)。Hugging Faceのモデルカードでは総25.2B、活性3.8Bです。
Gemma 4のモデルカードは、そのまま使える言語を35超、事前学習の言語を140超としています(Hugging Face google/gemma-4-26B-A4B-it)。
qwen3.6:27b は密モデルで、Hugging Faceのモデルカードはエージェント的なコーディングと推論を強みに挙げています(Hugging Face Qwen/Qwen3.6-27B)。筆者はこのタグを使っていません。qwen3.6:35b-a3b(23〜24GB)は24GBの枠にほぼ満杯で、会話を伸ばす余地がないため、この帯では外しました。
16GB: gemma4:12b か qwen3:14b
16GBでは、7.7〜8.0GBの gemma4:12b と9.3GBの qwen3:14b が候補です。どちらもOllama公式のサイズ表示で半分前後に収まり、会話を伸ばす余地を残せます。
gemma4:12b は画像入力に対応しています。コンテキスト長はOllama上で256Kと表示されています(Ollama library gemma4)。qwen3:14b のコンテキスト長は40Kと表示されています(Ollama library qwen3)。
この帯の2本は、筆者は日本語品質を実測していません。Ollamaの qwen3.8:27b(4ビット)は18GBで、16GBカードではVRAMに収まりきりません。Unslothは4ビット版を16〜19GBとし、RTX 5080(16GB)でも動作すると説明しています(Unsloth docs『Qwen3.8』、Ollama library qwen3.8 tags 2026-10-04確認)。詳しくは別記事で扱いました。16GB機で27B級を無理に載せるより、この帯のモデルで始めるほうが確実です。
8GB: qwen3:8b か qwen3:4b
8GBでは、5.2GBの qwen3:8b と2.5GBの qwen3:4b を挙げます(Ollama library qwen3)。Qwen3-8Bのモデルカードは、100を超える言語と方言への対応を明記しています(Hugging Face Qwen/Qwen3-8B)。
8GB機ではOSやブラウザも同じメモリを使うため、7GB以上のモデルは避けました。Ollamaの gemma4:12b(7.7〜8.0GB)は、ファイルだけで8GBの9割以上を占めます。gemma4:e2b は2026-09-26の確認では7.2GBでしたが、2026-10-04の確認では4.6〜7.5GBの幅表示に変わっていました。小さいほうの4.6GBであれば8GB帯でも試す余地がありますが、この記事では幅の上限(7.5GB)を基準にして候補から外しています。
6. 動かなかった構成と、やめた構成
上位ページに少ない「失敗の記録」をまとめます。
| 構成 | 何が起きたか | 対処・判断 | 時期 |
|---|---|---|---|
| Ollama 0.13.5 + qwen3.6:35b-a3b | ollama pull は成功するが、読み込みで unknown model architecture: 'qwen35moe' | Ollamaを0.32.0に更新して解決 | 2026-07-14 |
| qwen3.6:35b-a3bをAPIで利用 | 応答が空になる | 思考だけで出力枠を使い切るため、"think": false を付与 | 2026-07-14 |
| vLLM + Qwen3-32B-NVFP4で記事を自動生成 | 品質が足りず、毎回手動のファクトチェックと修正が必要 | 記事生成をクラウドのClaude Codeに移行。vLLMはGPUメモリを128GB中約60GB使っていた | 2026-04-03 |
最後の行は、このサイト自体の運用記録です。筆者は2026年4月まで、DGX Spark上のvLLMでQwen3-32B-NVFP4を動かし、記事の下書きを自動生成していました。品質が足りず、毎回の修正に手間がかかったため、記事生成からローカルLLMを外しました(筆者の移行記録 2026-04-03)。
現在ローカルLLMに任せているのは、翻訳・要約・分類・OCRのように、出力を機械的に検証しやすい作業です。長文を一から書かせる用途と、出力を突き合わせられる用途では、同じモデルでも評価が変わります。
7. 今日中に動かし始める手順
Ollamaを入れたあと、メモリ帯に合わせて1本を取得して試します。16GB機なら次の3行で始められます。
ollama pull gemma4:12b
ollama run gemma4:12b
ollama ps
ollama ps の CONTEXT 列で、割り当てられたコンテキスト長を確認できます。PROCESSOR が「100% GPU」ならGPUだけで動いています(Ollama docs: Context length)。Ollama公式FAQによると、この列はモデルがどのメモリに読み込まれたかを示します。「100% CPU」はすべてシステムメモリ、「48%/52% CPU/GPU」のような表示はGPUとシステムメモリの両方に分けて読み込まれた状態です(Ollama docs: FAQ 2026-10-04確認)。CPUの割合が出る原因はGPUメモリの不足に限らず、GPUが認識されていない場合などもあるため、表示は配置の確認に使い、原因は別に調べます。
見落としやすいのが既定のコンテキスト長です。Ollamaの公式ドキュメントによると、VRAMが24GiB未満なら4k、24〜48GiBなら32k、48GiB以上なら256kが既定になります(Ollama docs: Context length 2026-09-26確認)。
16GB機の既定4kでは、長いPDFや議事録を渡すと入力がコンテキスト長を超えることがあり、その場合は文書の一部が読み込まれない可能性があります。逆にGPUが使えるメモリを48GiB以上と認識する環境では既定が256kになり、KVキャッシュが大きく確保されます。DGX Sparkのような大容量機でも、実際の割り当ては ollama ps の CONTEXT 列で確かめてください。筆者が分類器のコンテキスト長を49,152に固定しているのはこのためです。変更は環境変数で行います。
OLLAMA_CONTEXT_LENGTH=32768 ollama serve
コンテキスト長を広げるほどメモリ消費は増えます。広げたあとは ollama ps で、まだGPUに収まっているかを確認してください。
8. 商用利用とライセンス
この記事で挙げた候補は、いずれも開発元がApache 2.0で公開しています。Apache 2.0は、ライセンス表示などの条件を守れば、商用利用・改変・再配布を認めるライセンスです。
| モデル | ライセンス | 根拠 |
|---|---|---|
| Gemma 4(E2B〜31B) | Apache 2.0 | Google Open Source Blog 2026-04-02、Hugging Face google/gemma-4-26B-A4B-it |
| Qwen3.6-35B-A3B | Apache 2.0 | Hugging Face Qwen/Qwen3.6-35B-A3B |
| Qwen3.6-27B | Apache 2.0 | Hugging Face Qwen/Qwen3.6-27B |
| Qwen3-8B | Apache 2.0 | Hugging Face Qwen/Qwen3-8B |
| llama.cpp(Ollamaの推論基盤) | MIT | GitHub ggml-org/llama.cpp |
Googleは公式ブログで、Gemma 4をApache 2.0で公開したと述べています。以前のGemmaは独自の利用規約でした。旧世代のGemmaを使っている場合は、ライセンスが異なる点に注意が必要です。
Googleの『Gemma 4 model overview』ページ末尾にある「Creative Commons Attribution 4.0」の表記は、ドキュメントのページ内容に対するものです。モデルの重みのライセンスとは別物です。
Ollamaのライブラリページはライセンスを表示しないモデルがあります。社内で使う前に、Hugging Faceなど開発元のモデルカードで版ごとに確認してください。ライセンスが許しても、出力内容の正確さや第三者の権利侵害は利用者側の責任です。
9. 選ばなかったもの
- qwen3-next:80b(50GB): 2026-08-04の記録では筆者の環境に登録していました(2026-10-04の確認では登録していません)。ファイルだけで50GBあり(Ollama library qwen3-next tags 2026-10-04確認)、GPUとシステムメモリに分けて読み込む構成なら小さいGPUでも動かす余地はありますが、全体を1つのメモリに収めるなら64GB級以上が目安です。この記事の対象読者のメモリ帯から外れるため、おすすめには入れていません
- qwen2.5:7b: 実測で誤読と未翻訳語が出たため外しました。同サイズならQwen3の8Bを優先します
- gemma4:e4b(6.6〜9.5GB): 2026-09-26の確認では9.6GBと
gemma4:12bより大きい表示でしたが、2026-10-04の確認では6.6〜9.5GBの幅表示に変わっていました。8GB帯には余裕が少なく、16GB帯なら総パラメータの大きい12bを優先するため外しました - 日本語特化の国産モデル: 今回は一次資料の確認と実測ができていません。確かめていないものは候補に入れていません
10. この記事の限界
企画段階では、全候補を同じ条件で動かし、ロード時・8Kコンテキスト時・32Kコンテキスト時のメモリ使用量を測る予定でした。この記事の公開時点では、その横断測定は済んでいません。
メモリ帯の振り分けは、Ollama公式のファイルサイズとGoogle公式のメモリ表から逆算したものです。KVキャッシュの実測値は含みません。日本語品質の実測は32GB以上の帯に偏っています。横断測定の結果が出たら、この記事を更新します。
よくある質問
MacBookの統合メモリでも同じ目安で選べますか
同じ考え方で選べます。DGX Sparkと同様に、CPUとGPUが同じメモリを共有するため、OSやアプリが使う分を差し引いた残りに収まるかで判断します。Ollamaには gemma4:26b-mlx(18GB)のようなMLX向けタグもあります(Ollama library gemma4)。筆者はMacでの実測をしていません。
「26B」なのに「12B」より速いことがあるのはなぜですか
gemma4:26b や qwen3.6:35b-a3b はMoE型で、1トークンを出すたびに動くのは全体の一部だけだからです。Gemma 4 26B A4Bは総25.2Bのうち活性3.8Bです。ただしメモリには全体を載せる必要があるため、重みのサイズは活性ではなく総パラメータと量子化で決まり、そこにKVキャッシュなどが加わります。実際の速さはメモリ帯域や実装にも左右されます。
量子化すると日本語の質はどれくらい落ちますか
筆者は同じモデルの4ビット版と8ビット版を比べていないため、数字では答えられません。サイズの差は大きく、qwen3.6:35b-a3b は4ビット相当の標準タグが23〜24GB、q8_0 が39GB、bf16 が71GBです。メモリに余裕があれば8ビット版を試し、自分の用途で出力を比べるのが確実です。
クラウドのChatGPTやClaudeの代わりになりますか
筆者の運用では、長文の記事生成は代わりになりませんでした。2026年4月にローカルLLMでの記事生成をやめ、クラウドに移しています。一方、翻訳・要約・分類のように出力を検証しやすい作業では、qwen3.6:35b-a3bを日常的に使えています。
関連記事
- Qwen3.8-27Bの推奨4bitが17〜19GBで16GBカードに載らない話 ── 16GB帯で27B級を狙う前に読んでおきたい、サイズとGPUメモリの具体例です
- Muse Glimmer 30Bの24GB動作とUnsloth 4bit ── 24GB帯で30B級を量子化して載せる構成を扱っています
- DGX Sparkで動画生成AIを動かす手順 ── 同じDGX Spark(統合メモリ128GB)で、LLMと動画生成がメモリを取り合った記録を含みます
まとめ
- ローカルLLMは、モデル名のB数ではなく、Ollamaで落ちてくる実ファイルのサイズで選びます
- 32GB以上なら
qwen3.6:35b-a3b、24GBならgemma4:26bかqwen3.6:27b、16GBならgemma4:12bかqwen3:14b、8GBならqwen3:8bかqwen3:4bが起点です - 筆者が日本語品質まで確かめたのは32GB以上の帯で、それより下は公式サイズからの逆算です
- 挙げた候補はいずれもApache 2.0ですが、版ごとに開発元のモデルカードで確認してください
- 長文生成をローカルLLMに任せるのは筆者の運用では失敗し、検証しやすい作業に絞って使い続けています