ローカルLLM on KnightLiブログ

llama.cpp b9196アップデート：Windowsプリビルド版がCUDA 13.1、Vulkan、HIP、SYCLに対応

Mon, 18 May 2026 23:20:00 +0800

llama.cpp の最近のWindows版は、ローカルLLMユーザーにとってかなり扱いやすくなりました。以前WindowsでGGUFモデルを動かすとき、多くの人が環境問題でつまずいていました。CUDAバージョンの不一致、DLL不足、ドライバー非互換、CMakeビルド失敗、環境変数の誤り、Vulkan / HIP / SYCL設定の複雑さなどです。

現在は公式Releaseで複数のWindowsプリビルドパッケージが提供されています。多くの場合、ソースからビルドする必要はありません。対応するバージョンをダウンロードし、展開し、モデルファイルを置けば、そのままローカル推論サービスを起動できます。

llama.cppは何に向いているか

llama.cpp は、現在もっともよく使われているローカルGGUFモデル推論フレームワークのひとつです。軽量でクロスプラットフォーム、CPUでもGPUでも動作し、GGUFエコシステムには多くのモデル資源があります。

よく使われるモデル系統は次の通りです。

Qwen
Llama
DeepSeek
Gemma
Mistral
Mixtral
Hermes

GGUF量子化モデルが普及するにつれて、多くのオープンソースモデルがローカル展開向けのGGUF版を提供するようになりました。一般ユーザーにとって、llama.cpp の価値は明確です。複雑な推論フレームワーク一式を構築しなくても、自分のPCで使えるチャットサービスを動かせます。

Windowsプリビルド版の選び方

Windowsユーザーは、ハードウェアに応じて次のビルドを選べます。

Windows x64 CPU
Windows x64 CUDA 12.4
Windows x64 CUDA 13.1
Windows x64 Vulkan
Windows x64 HIP Radeon
Windows x64 SYCL
Windows ARM64 CPU

NVIDIA GPUなら、通常はCUDA版を優先します。RTX 3060、4060、4070、4080、4090のようなカードはCUDAルートに向いています。

AMD GPUなら、HIPまたはVulkanを試せます。実際には、完全なROCm環境を整えたくない場合、Vulkanのほうが扱いやすいこともあります。

Intel内蔵GPUやArc GPUなら、SYCLまたはVulkanを試せます。性能はNVIDIA CUDAには及ばないことが多いですが、中小規模のGGUFモデルを試すには十分です。

CPU版は、単体GPUがないユーザーや、小さなモデルを検証したいユーザーに向いています。速度は速くありませんが、導入はもっとも簡単です。

通常のGGUFモデルを起動する

llama.cpp のWindowsプリビルドパッケージをダウンロードし、モデルを models ディレクトリに置いたとします。展開した llama.cpp ディレクトリに入り、次のように起動できます。

`1`	`llama-server.exe -m models\your-model.gguf -ngl 999`

ここで -m はGGUFモデルファイルを指し、-ngl 999 は可能な限りモデル層をGPUに載せる指定です。実際にどれだけ載るかは、VRAM容量、モデルサイズ、量子化形式によって変わります。

起動に成功したら、ブラウザで次を開きます。

`1`	`http://127.0.0.1:8080`

これでローカルWebチャット画面に入れます。

VRAMが足りない場合は、より小さいモデルか、Q4やQ5など低めの量子化GGUFに切り替えます。パラメータ数だけでなく、量子化形式とコンテキスト長設定も確認してください。

マルチモーダル視覚モデルを起動する

マルチモーダル視覚モデルでは、通常メインモデルファイルだけでなく、mmproj 視覚投影ファイルも必要です。起動時にはメインモデルと mmproj を同時に指定します。

`1`	`llama-server.exe -m "models\main-model.gguf" --mmproj "models\mmproj-model.gguf" -ngl 999`

主な用途は次の通りです。

OCR認識
スクリーンショット理解
Webページスクリーンショット解析
画像Q&A
簡単な視覚内容判定

たとえば Qwen2-VL / Qwen2.5-VL 系の視覚モデルは、中国語スクリーンショット理解、OCR、画像とテキストのQ&Aで実用的です。メインモデルと mmproj ファイルが対応しているか必ず確認してください。バージョン不一致は読み込み失敗や異常な結果につながりやすいです。

batスクリプトで複数モデルを管理する

ローカルに複数モデルを置く場合、簡単な .bat スクリプトでメニュー切り替えできます。以下は例です。パスとモデル名は自分の環境に合わせて変更してください。

@echo off
chcp 65001 >nul
cd /d C:\path\to\llama-b9196-bin-win-cuda-13.1-x64

echo 请选择模型：
echo 1. Gemma
echo 2. Qwen VL 多模态
echo 3. DeepSeek

set /p choice=输入数字：

if "%choice%"=="1" llama-server.exe -m "models\gemma.gguf" -ngl 999
if "%choice%"=="2" llama-server.exe -m "models\qwen-vl.gguf" --mmproj "models\mmproj.gguf" -ngl 999
if "%choice%"=="3" llama-server.exe -m "models\deepseek.gguf" -ngl 999

pause

保存時はUTF-8エンコーディングを推奨します。その後、拡張子を .bat に変更します。ダブルクリックすると数字でモデルを選べます。

モデル選びで見るべき3点

第一にハードウェアです。VRAMが大きいほど大きなモデルを動かせます。VRAMが足りない場合、大きなモデルを無理に使わず、7B、8B、または低めの量子化版から始めるのが安全です。

第二に用途です。日常的なQ&A、要約、書き換えなら、小型モデルや中程度の量子化で十分なことが多いです。コード、長文書解析、マルチモーダル理解をしたいなら、より強いモデルとより多いVRAMが必要です。

第三にライセンスと安全境界です。ネット上には多くのコミュニティ改変モデルがありますが、能力、制限、ライセンスはそれぞれ異なります。ダウンロード前に、出所、ライセンス、適用場面、リスクを確認してください。出所不明のモデルに本番タスクを直接任せるのはおすすめしません。

よくある問題

起動時にDLL不足が出る場合は、まずダウンロードしたパッケージとGPUルートが合っているか確認してください。NVIDIAユーザーがHIP版を誤って落としたり、AMDユーザーがCUDA版を落としたりしないようにします。

モデル読み込みが遅い場合、モデルが大きすぎる、ディスクが遅い、またはVRAM不足で一部レイヤーがCPUに戻っている可能性があります。

Webページが開かない場合は、コマンドラインでサービスが正常に起動しているかを先に確認し、ポートが 8080 かどうかも見ます。ポートが使われている場合は、llama-server のパラメータでポートを変更できます。

マルチモーダルモデルの結果がおかしい場合は、プロンプトを変える前に、mmproj ファイルがメインモデルと対応しているかを確認します。

まとめ

今回のWindowsプリビルドパッケージの価値は、ローカルAIの入口を下げたことです。以前は多くのユーザーがビルドや依存関係でつまずいていましたが、今は「モデルをダウンロードし、サービスを起動し、結果を試す」段階に早く入れます。

Windowsユーザー向けには、ルート選択を簡単にまとめると次の通りです。

NVIDIA：CUDAを優先。
AMD：まずVulkanを試し、その後HIPを見る。
Intel：SYCLまたはVulkanを試す。
単体GPUなし：CPU版で小型モデルを動かす。

実際に使う前には、モデルの出所、ライセンス、VRAM要件、実際の出力を確認してください。ローカルAIの利点は制御しやすく、オフラインで、低遅延なことです。ただしコストがないわけではありません。モデル管理、ハードウェア資源、出力品質は自分で面倒を見る必要があります。

参考元：https://www.freedidi.com/24211.html

DeepSeek 4 をローカルで動かす：Apple Silicon Mac における Antirez ds4 の試み

Mon, 11 May 2026 08:51:37 +0800

Antirez が新しいプロジェクト ds4 をオープンソース化しました。これは汎用 LLM フレームワークではなく、DeepSeek V4 Flash 向けのローカル推論エンジンで、Apple Silicon と Metal バックエンドに重点を置いています。

プロジェクト URL：https://github.com/antirez/ds4

ds4 とは

ds4 の目的は明確です。Mac 上で DeepSeek V4 Flash をローカル実行することです。

現在は、次の 3 つの使い方が用意されています。

対話型 CLI。
HTTP server。
実験的な Agent モード。

位置づけとしては、llama.cpp、Ollama、vLLM のような汎用ツールを置き換えるものではなく、特定のモデルに深く最適化した推論プロジェクトに近いものです。

なぜ注目に値するのか

この種のプロジェクトが注目に値する理由は主に 3 つあります。

第一に、作者が Redis の作者である Antirez であることです。彼は長く低レイヤーのシステム、性能、シンプルなツールに関心を持っており、プロジェクトの作風も比較的ストレートです。

第二に、DeepSeek V4 Flash は効率的な推論を指向するモデルです。ローカル実行の体験が十分によければ、Mac ユーザーにとってかなり魅力的です。

第三に、ds4 は Apple Metal を直接ターゲットにしています。最初にあらゆるプラットフォームをサポートしてから徐々に最適化する路線ではなく、明確な 1 つの場面を深く掘るプロジェクトに見えます。

誰に向いているか

ds4 は、次のようなユーザーに向いています。

Apple Silicon Mac を使っている。
DeepSeek V4 Flash をローカルで動かしたい。
Metal 推論性能に関心がある。
alpha 段階のプロジェクトを試すことに抵抗がない。
軽量な推論エンジンやモデル実行の細部を調べたい。

安定したデプロイ、クロスプラットフォーム実行、OpenAI API 互換のエコシステムが目的なら、現時点では第一候補ではないかもしれません。実験用ツール、または技術的な観察対象として見るのがよさそうです。

使い方

プロジェクト README にある基本的な流れは、まずビルドしてから実行するというものです。

1
2
3

git clone https://github.com/antirez/ds4.git
cd ds4
make

対話的に実行する場合：

./ds4

HTTP server を起動する場合：

`1`	`./ds4 --server`

Agent モード：

`1`	`./ds4 --agent`

具体的なパラメータやモデルファイルの準備方法は、プロジェクトがまだ速いペースで変化しているため、リポジトリの README を確認するのが確実です。

現時点のリスク

ds4 はまだ初期段階のプロジェクトなので、使う前に次の点を想定しておく必要があります。

機能が完全ではない可能性があります。
パラメータ、モデル形式、コマンドラインの挙動が変わる可能性があります。
互換性は主に Apple Silicon と Metal を中心にしています。
Agent モードは実験的な性格が強く、本番フローに直接使うには向いていません。
問題が起きた場合、自分で README、issue、ソースコードを読んで調べる必要があります。

つまり、現時点では一般ユーザー向けのワンクリックツールというより、試してみる価値のあるオープンソース実験です。

汎用推論ツールとの違い

汎用推論ツールは通常、モデル形式、プラットフォーム、バックエンド、API の広い互換性を目指します。ds4 の方向性はもっと狭く、DeepSeek V4 Flash と Metal によるローカル実行に絞られています。

この選択には利点と代償があります。

利点は、実装を集中させやすく、性能や体験を単一の目標に合わせて最適化しやすいことです。代償は、適用範囲が限られることです。さまざまなモデルを動かすための道具ではなく、完全なデプロイ基盤の置き換えにも向いていません。

すでに llama.cpp や Ollama を使っているなら、ds4 は既存のワークフローをすぐ置き換えるものではなく、補助的なテストツールとして見るのが自然です。

まとめ

ds4 の見どころは、「また 1 つローカル大規模モデルツールが増えた」ことではありません。DeepSeek V4 Flash、Apple Silicon、Metal、ローカル推論という狭い範囲に絞っている点です。

手元に適した Mac があり、初期段階のプロジェクトを触ることに抵抗がないなら、今後の性能、モデル対応の方法、server/agent 機能の進化を追う価値があります。本番環境については、インターフェイスと使い方が安定してから評価するのがよいでしょう。

参考

GitHub プロジェクト：https://github.com/antirez/ds4

llama.cpp のマルチ GPU 性能を実測する考え方：2x V100 16GB は単体 32GB より速いのか？

Sat, 09 May 2026 15:05:41 +0800

大まかな結論は、llama.cpp のマルチ GPU offload は「2 枚目を足せば性能がそのまま増える」ものではない、ということです。モデルが最初から 1 枚の 32GB GPU に完全に収まるなら、2x V100 16GB は単体 32GB より扱いにくく、場合によっては遅くなります。逆に、モデルが 1 枚の 16GB に収まらないなら、2 枚構成の主な価値は「モデルを GPU に載せられること」で、その効果はかなり大きくなります。

まず split mode を分けて考える

llama.cpp のマルチ GPU 利用では、主に --split-mode と --tensor-split が関係します。性能を考えるときは、まず次のモードを分けて見ます。

layer：層ごとに別の GPU へ分割する方式。互換性が高く、多くの場合は最初に試す選択肢です。
tensor：テンソル計算を複数 GPU に分割する方式。より並列計算に近い一方で、GPU 間の帯域とバックエンド対応に強く依存します。
row：古い行分割方式です。今でも見かけますが、新規構成で最初に選ぶ方式ではありません。

簡単に言えば、layer は「階ごとに別のカードへ置く」ようなものです。単一 token 生成時には、2 枚のカードを同時に常に使い切れるとは限りません。tensor は「同じ層を 2 枚のカードで一緒に計算する」形に近く、理論上は並列性がありますが、カード間通信がボトルネックになります。

単体 32GB に収まるなら、双 16GB が速いとは限らない

モデルと KV cache が 1 枚の 32GB GPU に完全に収まるなら、単体カードのほうが安定し、速いことも多いです。1x V100 32GB と 2x V100 16GB のような同世代ハードウェアでは、後者が必ず勝つとは言えません。

保守的に見ると、2x V100 16GB は単体 V100 32GB より 10% から 40% 遅くなることがあります。特に、一人でのチャット、Continue Agent、コード Q&A のように、1 回のリクエストで主に 1 つの回答を生成する用途ではそうなりやすいです。

理由は単純です。マルチ GPU は VRAM を単純に 1 つの高速なプールへ合体するわけではありません。layer 分割では推論が GPU 間を移動し、token 生成時に片方の GPU がもう片方を待つことがあります。tensor 分割では 2 枚で同時に計算できますが、中間結果の同期が必要になり、帯域と遅延がスループットに直接効きます。

つまり選択肢が次の 2 つなら、

1x V100 32GB
2x V100 16GB

対象モデルがすでに 1 枚の 32GB に完全に収まる場合、単体 32GB のほうが使いやすいことが多いです。

単体 16GB に収まらないなら、双カードの価値は大きい

一方で、モデルが 1 枚の 16GB に収まらず、2 枚の 16GB なら収まる場合は話が変わります。

このとき双カードの価値ははっきりしています。

1 枚の 16GB：大量の CPU offload が必要になり、速度が大きく落ちる可能性があります。
2x 16GB：重みをできるだけ GPU に残せるため、CPU/GPU 混在実行よりかなり速くなる可能性があります。

この場面では、2x V100 16GB が単体 32GB より速いとは限りません。それでも「1 枚 16GB と大量のシステムメモリ offload」より数倍速いことはあります。つまり双カードの第一の価値は加速ではなく、モデル重みを遅いシステムメモリへ落とさずに済むことです。

V100 PCIe と V100 SXM2 は大きく違う

マルチ GPU 推論で見落としやすいのがインターコネクトです。

V100 SXM2 で、マシンに NVLink がある場合、GPU 間通信帯域はかなり高くなります。NVIDIA の V100 資料では、NVLink の相互接続帯域は最大 300GB/s とされています。この環境なら、tensor や大きめの batch を使う場面で、単体カードに近い性能、あるいはそれを超える性能を狙いやすくなります。

V100 PCIe の場合は、もっと保守的に見るべきです。V100 PCIe の相互接続は主に PCIe Gen3 で、資料上の interconnect bandwidth は 32GB/s です。NVLink とは桁が違うため、PCIe 双カードでは「VRAM は足りるが速度は 2 倍にならない」ことがよくあります。

そのため 2x V100 16GB が価値ある構成かを判断するときは、VRAM を足して 32GB と見るだけでは足りません。PCIe 版なのか、SXM2/NVLink 版なのかも確認する必要があります。

実際にはどう選ぶか

モデルが 1 枚の 32GB GPU に収まるなら、まず単体カードを優先します。遅延、安定性、調整コストの面で有利なことが多いです。

モデルが 1 枚の 16GB には収まらず、2 枚の 16GB なら収まるなら、双カードは使う価値があります。この場合の目的は、重みをできるだけ GPU に残すことであり、性能が線形に倍増することを期待することではありません。

V100 PCIe の双カードなら、まず --split-mode layer を試し、「安定して動くこと」と「CPU に落とす量を減らすこと」を目標にします。

V100 SXM2/NVLink なら、tensor 関連のモードを試す価値が高くなります。特に prefill、大きい batch、同時リクエストの場面で有効です。

いつ 2x16GB を買い、いつ 1x32GB を買うか

一人で使い、主にチャット、コード補完、Continue Agent、長文コンテキスト Q&A を行い、対象モデルが 32GB に収まるなら、1x32GB のほうが一般的にはおすすめです。GPU 間スケジューリングがなく、遅延が安定し、問題切り分けも簡単です。

すでに 16GB カードを 1 枚持っていて、低コストで 30B、32B、または高めの量子化モデルを動かしたいなら、2x16GB には意味があります。token/s が倍になるとは限りませんが、本来 CPU offload が必要だった重みを GPU に残せます。

新規に購入するなら、優先度は次のように考えられます。

単一モデル、単一ユーザー、応答遅延重視：1x32GB を優先。
モデルが単体カードに収まらず、予算が限られる：2x16GB を検討。
NVLink または SXM2 マシンがある：2x16GB の有用性は通常の PCIe 双カードよりかなり高い。
将来さらに長いコンテキストを使いたい：重みサイズだけでなく、KV cache 用の VRAM も残す。

layer split と tensor split の実用的な使い方

実用上のおすすめは、まず layer、次に tensor を測ることです。

layer は出発点に向いています。モデルを層単位で分配し、互換性が高く、PCIe 双カードにも比較的向いています。欠点は、生成段階がパイプラインのようになり、ある時点では片方のカードだけが忙しく、もう片方が待つことがある点です。

tensor は、V100 SXM2/NVLink のように相互接続帯域が高いマシンに向いています。同じ層の計算の一部を複数 GPU に分けるため、理論上は並列性があります。ただしカード間同期が増えます。PCIe 双カードでは、通信コストが利益を食いつぶす可能性があります。

実際のテストは、まず次のような組み合わせから始めます。

1
2
3

llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1
llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,0

3 つ目は長期運用向けではありません。単体カードの参照値を取るためです。これにより、双カードが本当に速いのか、それとも単に VRAM 圧力を分散しているだけなのかを見分けられます。

prefill と decode で性能が違う理由

ローカル LLM の性能は、通常 2 つの段階に分けて見るべきです。

prefill：入力 prompt を処理します。代表的な指標は pp512 のような prompt processing スループットです。
decode：回答を token ごとに生成します。代表的な指標は tg128 のような token generation スループットです。

prefill は大きな batch の行列計算に近く、GPU を使い切りやすく、マルチ GPU 並列化の恩恵も受けやすいです。decode は 1 token ずつ生成するため、batch が小さく同期が頻繁です。そのためカード間通信とスケジューリング遅延が表に出やすくなります。

そのため、双カードで pp512 は良くなるのに、tg128 はほとんど改善しない、あるいは遅くなることがあります。チャットや Agent の体感は tg128 に近く、長文投入、batch prefill、同時リクエスト処理では pp512 も重要になります。

KV cache は第 2 の VRAM ボトルネックになるか

なります。多くの人はモデル重みだけを計算し、KV cache を忘れます。

モデル重みは「モデルをロードできるか」を決めます。KV cache は「必要なコンテキスト長を使えるか」を決めます。コンテキストが長く、同時実行が多く、batch が大きいほど、KV cache の占有は目立ちます。モデル本体は 32GB に収まるのに、32K や 64K コンテキストを開くと VRAM が足りなくなることがあります。

少なくとも次の分の VRAM 余裕を残して考えるべきです。

KV cache
CUDA graph またはバックエンドのランタイムオーバーヘッド
prompt batch と ubatch
デスクトップ、ドライバ、他プロセスの使用量

2x16GB を使う場合、VRAM は完全に等価な 32GB の大きなプールではありません。一部のバッファ、KV cache、中間テンソルは、単一カードの残り VRAM に制限される場合があります。長文コンテキストを測るときは、モデルが起動するかだけでなく、実際の --ctx-size と同時実行数でテストするのが安全です。

llama-bench で双カードを自分で測る

llama-bench は、直接チャットするよりハードウェア比較に向いています。prompt processing と token generation を分けて比較できるためです。公式 README の基本例は次の通りです。

`1`	`llama-bench -m model.gguf`

双 V100 なら、少なくとも次の組み合わせを測ります。

# Single-card baseline
CUDA_VISIBLE_DEVICES=0 llama-bench -m model.gguf -ngl 99

# Dual-card layer split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode layer --tensor-split 1,1

# Dual-card tensor split
CUDA_VISIBLE_DEVICES=0,1 llama-bench -m model.gguf -ngl 99 --split-mode tensor --tensor-split 1,1

特に見るべき列は 2 つです。

pp512：prompt processing。長い入力や batch prefill に関係します。
tg128：token generation。単一ユーザーのチャットや Agent の体感に関係します。

テスト時は、モデル、量子化形式、コンテキスト長、batch、ドライババージョン、llama.cpp バージョンを固定します。各組み合わせを複数回実行し、一度だけの結果ではなく中央値で比べるほうが信頼できます。最後に、Continue Agent、OpenAI-compatible server、自分の RAG リクエストなど、実際のワークフローでも確認します。benchmark が良くても、対話体験が必ず良くなるとは限らないためです。

一言でまとめると

2x V100 16GB の強みは主に VRAM 容量であり、生成速度が必ず上がることではありません。モデルが単体カードに収まるなら、単体 32GB のほうが速く安定しやすいです。モデルが 1 枚 16GB に収まらないなら、双 16GB の価値は大きくなります。大量の CPU offload を避けられるためです。実際に速くなるかは、split mode、batch、モデルサイズ、そして 2 枚の V100 が PCIe でつながっているのか NVLink なのかで決まります。

参考資料：

RTX 5090 / 5080 AI推論ベンチマーク：ローカルLLM、4K動画、リアルタイム3Dの選び方

Fri, 08 May 2026 10:07:19 +0800

RTX 50シリーズがローカルAIユーザーにとって魅力的なのは、ゲーム性能だけが理由ではない。Blackwellアーキテクチャ、GDDR7メモリ、第5世代Tensor Coreによって、デスクトップAIワークステーションとしての可能性が広がったからだ。ローカルLLM、画像生成、動画補正、リアルタイム3Dを扱う人にとって、GPUは単なる描画装置ではなくなっている。

RTX 5090とRTX 5080の差は、型番だけでは判断できない。どちらもBlackwellで、DLSS 4、第5世代Tensor Core、FP4をサポートする。ただしローカルAI推論の体験を決めるのは、多くの場合VRAM容量、メモリ帯域幅、ソフトウェア対応、モデルとの相性だ。

結論から言えば、RTX 5090は単体GPUでローカルAIを本格的に動かすための旗艦に近い。大きなモデル、長いコンテキスト、画像生成、動画AIに向く。RTX 5080は予算を抑えたい場合や、16GB VRAMに収まる小中規模モデルとワークフローに向く。どちらも前世代より進歩しているが、すべてのAIアプリがすぐにBlackwellの新機能を使い切れるわけではない。

まずハードウェア差を見る

RTX 5090の主な仕様は、32GB GDDR7、512-bitメモリバス、21760基のCUDA Core、3352 AI TOPSだ。Puget Systemsの公開テストでも、約1.79TB/sのメモリ帯域幅が強調されている。RTX 4090の24GB、約1.01TB/sと比べると、AIワークロードでは意味のある差になる。

RTX 5080はより控えめで、16GB GDDR7、256-bitメモリバス、10752基のCUDA Core、1801 AI TOPSとなる。帯域幅は約960GB/sでRTX 4080系からは大きく伸びたが、VRAM容量は16GBのままだ。

つまり両者の役割はかなり明確だ。

RTX 5090は32GB VRAMと高帯域幅により、大きなモデル、長いコンテキスト、重いマルチモーダル処理に向く。
RTX 5080は価格と消費電力を抑えやすく、小中規模モデル、画像生成、軽い動画処理、開発検証に向く。
すでにVRAMで詰まる処理では、RTX 5080の計算性能だけでは16GBの制約を埋めにくい。
ソフトウェア最適化がボトルネックなら、RTX 5090でもRTX 4090との差が理論値ほど広がらないことがある。

ローカルAI推論では「まずVRAMが動くかどうかを決め、次に帯域幅が快適さを決める」ことが多い。これが、RTX 5090がローカルLLMユーザーに強く刺さる理由だ。

ローカルLLMでは32GB VRAMが重要

LLMを動かすとき、VRAMは主にモデル重み、KV cache、ランタイムのオーバーヘッドに使われる。モデルが大きいほど、コンテキストが長いほど、同時実行が多いほど、VRAMの圧力は高くなる。

RTX 5080の16GBでも、7B、8B、14B級モデルの多くは動かせる。4-bit量子化を使えば一部のより大きなモデルも試せる。しかし30B級モデル、長いコンテキスト、WebUI、RAG、音声、ツール呼び出しを同時に扱うと、16GBはすぐに上限になりやすい。

RTX 5090の32GBは、ローカル推論にかなり余裕を与える。特に次の用途に向く。

30B前後の量子化大規模モデルを動かす。
7B、14Bモデルで長めのコンテキストを維持する。
ローカルコード助手、ナレッジベースQ&A、Agentの検証を行う。
埋め込みモデル、reranker、マルチモーダル部品を同時に読み込む。
単体マシンでモデル切り替えやコンテキスト削減の手間を減らす。

ただし32GBも万能ではない。70B級モデルは4-bit量子化でも、コンテキスト、実行パラメータ、VRAM断片化に注意が必要になる。高い同時実行を狙うなら、複数GPUやサーバー向けGPUのほうが適している。

個人利用では、RTX 5090の価値は「悩む場面が減る」ことにある。選べるモデルが増え、長いコンテキストを取りやすく、GUIや周辺ツールも同時に動かしやすい。

FP4は可能性であり、すべてのアプリで即効くわけではない

Blackwellの大きな変化の一つが、第5世代Tensor CoreによるFP4サポートだ。NVIDIAのTensorRT関連資料では、FP4によりモデルのメモリ使用量とデータ移動を減らし、FLUXなどの生成モデルのローカル推論を最適化できると説明されている。

これは画像生成と将来のLLM推論にとって重要だ。低精度はVRAM使用量を減らすだけでなく、帯域幅の圧力も下げる。RTX 5090のような高帯域GPUでは、フレームワークとモデルが十分対応すれば利点はさらに大きくなる。

ただしFP4の効果はソフトウェア経路に依存する。

モデルに適切なFP4量子化版があるか。
推論フレームワークが必要な演算子をサポートしているか。
TensorRT、ComfyUI、PyTorch、ONNX、プラグインが対応済みか。
精度低下をそのタスクで許容できるか。
ユーザーが性能のためにワークフローを調整できるか。

そのため、RTX 50シリーズのAI性能はFP4のピーク値だけでは評価できない。BlackwellはFP4の土台を提供したが、実際の体験はアプリ側の更新速度に左右される。早期ユーザーは一部の恩恵を先に得られるが、一般ユーザーはエコシステムの成熟を待つ場面もある。

画像生成と4K動画：帯域幅とVRAMの両方が効く

Stable Diffusion、FLUX、動画超解像、フレーム補間、ノイズ除去、切り抜き、生成動画はいずれもVRAMに敏感だ。解像度が高いほどVRAM使用量は増え、ノードが多いほどランタイムの負荷も増える。ControlNet、LoRA、高解像度修復、バッチ生成を同時に使うとさらに重くなる。

RTX 5080は16GBの範囲で多くの画像生成タスクをこなせる。1024px級の画像、軽いLoRA、一般的なComfyUIワークフローなら十分速い。問題は、より大きなキャンバス、複雑なノードグラフ、高いbatch、長いシーケンスを持つ動画生成で出やすい。

RTX 5090の利点は4K動画関連でより明確になる。

32GB VRAMは高解像度フレーム、長いシーケンス、複雑なノードグラフに向く。
約1.79TB/sの帯域幅はデータ移動のボトルネックを減らしやすい。
3基の第9世代NVENCは書き出し、トランスコード、制作フローに有利だ。
FP4とTensorRT対応が成熟すれば、画像生成モデルの伸びも期待できる。

一方で、公開されている動画AI実測は注意点も示している。Puget SystemsはDaVinci Resolve AIやTopaz Video AIのテストで、RTX 5090が常にRTX 4090を大きく上回るわけではなく、RTX 5080もRTX 4080系と常に大差をつけるわけではないと報告している。動画AIは仕様だけでは決まらず、プラグイン、ドライバ、モデル実装も重要だ。

つまり、ワークフローがすでにBlackwell、TensorRT、FP4を明確にサポートしているならRTX 50シリーズは期待しやすい。まだ最適化されていない商用ソフトに依存するなら、アップグレード効果はバージョン次第になる。

リアルタイム3DとAIモデリング：RTX 5090は重いシーン向け

リアルタイム3Dモデリング、ニューラルレンダリング、3Dアセット生成、ビューポートAI加速では、CUDA、RT Core、Tensor Core、VRAMを同時に使うことが多い。純粋なLLMと違い、token生成速度だけでなく、シーンの複雑さ、材質、ジオメトリ、レイトレーシング、AIノイズ除去、ビューポートのフレームレートも重要になる。

RTX 5080は4Kゲーム、リアルタイムプレビュー、中規模の制作プロジェクトに十分対応できる。個人クリエイターにとっては現実的な高性能選択肢だ。

RTX 5090は次のような場面により向く。

複雑な3Dシーンのリアルタイムプレビュー。
高解像度材質と大規模アセット。
AIノイズ除去、超解像、生成支援モデリングの同時利用。
D5 Render、Blender、Unreal Engineなどの重い作業。
モデリングしながらローカルAI助手や参考画像生成を動かす。

NVIDIAはRTX 50シリーズが制作アプリで生成AI、動画編集、3Dレンダリングを改善すると説明している。ただし実際のプロジェクトでは、ソフトウェアが新しいハードウェア経路を使っているかを確認する必要がある。本番環境では、自分のプロジェクトファイルで試すのが最も確実だ。

どう選ぶか

ローカルLLMが目的なら、まずVRAMを見る。RTX 5080の16GBでも軽量モデルは多く動くが、「高性能な入門ローカルAIカード」に近い。RTX 5090の32GBは「単体GPUローカルLLMワークステーション」に近い。

画像生成が目的なら、RTX 5080でも日常的なワークフローはかなり覆える。高解像度、多ノード、バッチ生成、FLUX、動画生成をよく使うなら、RTX 5090のVRAM余裕が重要になる。

4K動画AIが目的ならRTX 5090のほうが安定しやすい。ただしTopaz、DaVinci Resolve、ComfyUI、TensorRTプラグイン、ドライバのバージョンで結果は変わる。

リアルタイム3DならRTX 5080でも多くの制作需要を満たせる。RTX 5090は重いシーン、複数アプリの同時利用、長時間制作に向く。

すでにRTX 4090を持っているなら、アップグレードは慎重に考えたい。RTX 5090はVRAMと帯域幅で強いが、現行AIソフトの一部はBlackwellの利点をまだ完全に使えていない。32GB、より高い帯域幅、新しいエンコーダが明確に必要でなければ、エコシステムの成熟を待つ選択もある。

RTX 30シリーズ以前からの更新なら、RTX 50シリーズの差はかなり分かりやすい。特に8GB、10GB、12GBから16GBまたは32GBへ移ると、ローカルAIで動かせる範囲が直接広がる。

まとめ

RTX 5090とRTX 5080は、どちらもコンシューマーGPUをローカルAI時代へさらに進める製品だ。ただし向いているユーザーは異なる。

RTX 5090の価値は、32GB GDDR7、非常に高いメモリ帯域幅、より充実した制作向けハードウェア構成にある。単体マシンで大きなモデル、複雑な画像生成、重い動画AI、リアルタイム3Dを扱いたい人に向く。

RTX 5080の価値は、より低いコストでBlackwellに入れることだ。16GBに収まる中小モデル、日常的な画像生成、開発テスト、高性能な制作作業に向く。

購入判断はシンプルだ。まず自分のモデルとプロジェクトがVRAMに収まるかを見て、次にソフトウェアがBlackwellに最適化されているかを確認し、最後に理論上のAI TOPSを見る。ローカルAIでは、ピーク値より安定して最後まで走ることのほうが重要だ。

参考資料

DeepSeek V4のローカル私有化デプロイ：国産チップとコンシューマーGPUクラスターの選び方

Fri, 08 May 2026 09:39:35 +0800

DeepSeek V4の公開後、多くの企業が一つの問題に注目し始めた。外部APIを使わず、自社のデータセンター、プライベートクラウド、専用クラスターにモデルを配置できるのか、という問題だ。

この需要は非常に現実的だ。金融、医療、政府・企業、製造、法務、研究開発チームは、社内文書、コード、契約書、チケット、顧客データをそのままパブリッククラウドのモデルへ送れないことが多い。こうした場面でDeepSeek V4が魅力的なのは、モデル能力だけではなく、企業に「制御可能なLLMインフラ」に近い選択肢を与える点にある。

ただし、DeepSeek V4のローカルデプロイは、モデルをダウンロードしてGPUを数枚用意すれば動く、という話ではない。特にProのような超大規模MoEモデルでは、総パラメータ規模、アクティブパラメータ、コンテキスト長、KV cache、同時実行数、推論フレームワークがそのままハードウェアコストを左右する。企業が本当にやるべきことは、フルスペック版を盲目的に追うことではなく、まず業務に必要なデプロイ形態を確認することだ。

まずデプロイ目標を明確にする

企業がローカル私有化デプロイを行う目的は、主に三つある。

データを域外に出さない：社内文書、コード、顧客資料、ログ、ナレッジベースを企業環境の外へ出さない。
安定して制御できる：モデルサービス、権限、監査、ログ、アップグレードのペースを企業自身が管理する。
長期コストを下げる：高頻度に呼び出す場合、ローカル推論は外部APIを長期購入するより制御しやすい可能性がある。

少数の従業員がたまに質問するだけなら、ローカルデプロイは必ずしも割に合わない。私有化に本当に向いているのは、高頻度で、安定していて、データが敏感で、フローが明確な場面だ。例えば次のようなものがある。

社内ナレッジベースQ&A。
コードレビューと開発アシスタント。
カスタマーサポートチケットの要約。
契約書、カルテ、レポートなどの文書分析。
データベース問い合わせアシスタント。
Agentワークフロー自動化。

これらの共通点は、データが敏感で、呼び出しが安定しており、権限とログを通じて企業ガバナンスに組み込めることだ。

最初からフルスペックのProを追わない

DeepSeek V4の一般的なバージョンにはProとFlashがある。公開資料では、Proはより強い推論や複雑なAgentタスク向け、Flashはコストと応答速度を重視するものとされている。企業が選定するとき、すべての業務をProに載せる前提にすべきではない。

タスクの複雑度に応じて分けるとよい。

簡単なQ&A、要約、分類、タグ生成：Flashまたはより小さいモデルを優先する。
社内ナレッジベースの検索拡張：Flashで多くの場面をカバーできる。むしろRAG、権限、検索品質が重要だ。
コードAgent、複雑な推論、長文コンテキスト分析：その段階でProを評価する。
高価値・低頻度タスク：Proを使ってよいが、高い同時実行数が必要とは限らない。
一般的なオフィスアシスタント：最も高価な推論リソースを長時間占有する必要はない。

MoEモデルの利点は、各推論で一部のパラメータだけをアクティブにすることだ。しかし、それはハードウェア負荷が小さいことを意味しない。重みの保存、エキスパート並列、ネットワーク通信、コンテキストキャッシュ、同時実行スケジューリングは依然として重い。特に1M token級の長文コンテキストでは、単一の回答よりも、長いコンテキスト、多人数同時利用、継続セッションがリソースを消費しやすい。

国産チップ路線：企業向けプライベートクラウドに向く

企業がすでに国産計算資源プールを持っている場合、または信創、コンプライアンス、サプライチェーン要件がある場合は、Ascend、Cambriconなどの国産チップ路線を優先的に評価できる。

この路線の利点は次の通りだ。

国産化とサプライチェーン制御の要件に合いやすい。
企業データセンター、専用クラウド、政府・企業向けプロジェクトに入りやすい。
権限、監査、リソース分離、運用を統一しやすい。
長期的に安定したサービスに向いている。

ただし、国産チップ路線では三つの現実的な問題を見る必要がある。

第一に、フレームワーク適配だ。モデルが動くかどうかは、チップの計算力だけでは決まらない。推論フレームワーク、演算子、通信ライブラリ、量化形式、MoEエキスパート並列、長文コンテキスト最適化が成熟しているかも重要だ。

第二に、エンジニアリング経験だ。企業が必要とするのは「起動に成功した」だけではなく、安定したサービスだ。マルチテナント、レート制限、監視、障害復旧、段階的リリース、ログ監査、権限分離をすべて補う必要がある。

第三に、エコシステム差だ。同じモデルでも、NVIDIA、Ascend、Cambriconなどのプラットフォームでは、性能、精度、量化対応、デプロイツールが完全には一致しない。本番投入前には、名目上の計算力だけでなく、実際の負荷テストが必要だ。

したがって、国産チップは、予算が明確で、コンプライアンス要件が高く、プラットフォームエンジニアリングに投資できる企業に向いている。最も手軽な路線ではないが、長期ガバナンスには最も合う可能性がある。

コンシューマーGPUクラスター：試験導入と中小チームに向く

まず業務価値を検証したいなら、コンシューマーGPUクラスターの方が始めやすい。RTX 4090、RTX 5090、RTX 3090、RTX 3060 12GBなどのGPUは、コミュニティツール、量化モデル、ローカル推論フレームワークの情報が多く、試行錯誤のコストが低い。

コンシューマーGPU路線が向くのは次のような場面だ。

研究開発チームの社内試験導入。
中小企業のナレッジベースQ&A。
低同時実行のコードアシスタント。
オフライン文書処理。
SLA要求が高くない社内ツール。

ただし、制約も明確だ。

VRAMが小さく、完全な大規模モデルを直接載せにくい。
マルチGPU通信が弱く、複数マシン間通信はさらに面倒になる。
コンシューマー向けハードウェアは、長期フルロード時の安定性がサーバー方案に劣る。
ケース、電源、冷却、ドライバ、運用が隠れたコストになる。
最初から企業級の高可用性を約束する用途には向かない。

より現実的なのは、まずコンシューマーGPUでFlash、蒸留版、量化版、小規模モデルを動かし、業務フローを通すことだ。その後、呼び出し量、効果、データガバナンスを検証してから、サーバーGPUや国産計算基盤へ移行するかを決める。

想定されるデプロイ構成

比較的安定した企業向け私有化構成は、六つの層に分けられる。

モデル層：DeepSeek V4 Pro、V4 Flash、またはタスクに応じて選ぶ小さな蒸留モデル。
推論層：SGLang、vLLM、llama.cpp、ベンダーNPU推論スタック、または企業の自社サービス。
ゲートウェイ層：統一認証、レート制限、監査、モデルルーティング、呼び出しログ。
ナレッジ層：ベクトルDB、全文検索、文書解析、権限フィルタリング、RAG。
アプリケーション層：カスタマーサポート、コードアシスタント、文書分析、レポートQ&A、Agentワークフロー。
運用層：監視、アラート、コスト集計、段階的リリース、ロールバック、セキュリティ監査。

ここで最も過小評価されやすいのは、ゲートウェイ層とナレッジ層だ。多くのプロジェクトが失敗するのは、モデルがまったく使えないからではなく、権限、検索、ログ、コンテキスト管理、プロンプトテンプレート、業務フローが整っていないからだ。

企業内でLLMをデプロイするときは、モデルを孤立したチャットページではなく、基礎能力として扱うべきだ。本当の価値は、モデルがフローに入り、企業自身のデータとタスクを安定して処理できるようになったときに生まれる。

ハードウェア選定の考え方

ハードウェアは「動くか」だけでなく、「安定してサービス提供できるか」も見る必要がある。

段階ごとに選ぶとよい。

検証段階

目的は、その業務に取り組む価値があるかを証明することだ。

1-4枚のコンシューマーGPUを使う。
Flash、小モデル、蒸留モデル、量化モデルを優先する。
同時実行要求は低くし、タスク完了率を見る。
高可用性は約束しない。

この段階で大規模ハードウェアを早く買いすぎない。まず従業員が本当に使うか、業務が本当に時間を節約できるか、回答がフローに入るかを確認する。

試点段階

目的は、一つの部門または一つの業務ラインで安定して使うことだ。

4-16枚のGPU、または国産NPUノード一式を使う。
統一ゲートウェイ、ログ、権限制御を追加する。
RAG、文書解析、モデルルーティング、キャッシュを作る。
token、同時実行、遅延、失敗率を記録し始める。

この段階では運用が重要になる。モデル効果は一部にすぎず、安定性、コスト、データガバナンスも同じくらい重要だ。

本番段階

目的は企業級サービスに入ることだ。

サーバーGPU、国産計算クラスター、またはプライベートクラウド資源プールを使う。
複数レプリカ、レート制限、フェイルオーバー、容量計画を整える。
タスクごとにモデルをルーティングする。簡単なタスクは軽量モデル、複雑なタスクはProに送る。
企業IDシステム、監査システム、セキュリティポリシーと接続する。

本番段階では、すべてのリクエストを最強モデルに送るべきではない。適切なモデルルーティングは、ハードウェアを積み増すよりもコストを抑えやすい。

推論フレームワークの選び方

DeepSeek V4のようなモデルは、推論フレームワークへの要求が高い。特にMoE、長文コンテキスト、スパースアテンション、量化、マルチGPU並列が関わる場合、フレームワークの成熟度が速度と安定性に直結する。

一般的な選択肢は次のように理解できる。

SGLang：高性能推論、Agent、多ターンのツール呼び出し、複雑なサービス編成を重視するチームに向く。
vLLM：エコシステムが成熟しており、汎用LLMサービスに向く。ただし具体的な対応はバージョンとモデル適配の進捗を見る必要がある。
llama.cpp：小モデル、量化モデル、エッジデプロイに向く。フルスペックの超大規模MoEを直接載せる用途には向かない。
国産NPU推論スタック：信創や国産計算環境に向くが、演算子、量化、長文コンテキスト対応を重点的に検証する必要がある。

フレームワーク選びではbenchmarkだけを見ない。企業は自社の実データで試すべきだ。社内文書の長さ、同時実行数、平均出力長、RAG命中率、Agentのツール呼び出し回数、失敗時のリトライ回数を見る必要がある。

データ安全性はモデルの外側で作る

私有化デプロイは自動的に安全になるわけではない。モデルをローカルで動かすことは、「データが企業の外へ出るか」という問題の一部を解決するだけだ。

さらに次を補う必要がある。

アカウントと権限：部門ごとに自分のナレッジベースだけを参照できるようにする。
ログ監査：誰が何を聞き、どのモデルを呼び、どの文書にアクセスしたかを記録する。
データマスキング：顧客情報、身分証番号、電話番号、契約金額などの機微情報を処理する。
プロンプト安全性：ユーザーがプロンプトで権限を回避したり、システムプロンプトを漏らしたりしないようにする。
出力レビュー：重要な場面では人手レビューまたはルールレビューを入れる。
データライフサイクル：アップロード文書、ベクトルインデックス、キャッシュ、会話記録を削除できるようにする。

企業がローカルLLMを作るとき、アルゴリズムチームだけに任せてはいけない。セキュリティ、法務、運用、業務責任者も参加する必要がある。そうしないと、リリース後にリスクが一気に露出する。

コストはGPUだけではない

ローカルデプロイのコストは過小評価されがちだ。GPUやNPU以外にも、次のものを計算に入れる必要がある。

サーバー、ラック、電源、冷却、ネットワーク。
ストレージとバックアップ。
推論フレームワーク適配とエンジニアリング開発。
運用監視と障害対応。
モデルアップグレード、ロールバック、互換性テスト。
セキュリティ監査と権限システム。
業務側のプロンプト、RAG、ワークフロー構築。

呼び出し量が少ないなら、外部APIの方が安い可能性がある。呼び出し量が多く、データが敏感で、フローが安定している場合に、ローカルデプロイはコストを薄めやすい。

比較的合理的なのはハイブリッド構成だ。

高機密データはローカルモデルへ送る。
低機密の汎用タスクは外部APIを使ってもよい。
簡単なタスクは小モデルへ送る。
複雑なタスクはDeepSeek V4 Proへ送る。
高頻度タスクでは、キャッシュ、検索、モデルルーティングを優先して最適化する。

推奨される導入手順

企業は次の順序で進めるとよい。

まず高価値な場面を2-3個選び、全社展開しない。
コンシューマーGPUまたは小規模計算資源でPoCを行う。
まずFlash、蒸留モデル、量化モデルを動かし、RAGと権限をつなぐ。
複雑なタスクにProを導入して比較テストする。
実際の呼び出し量、遅延、失敗率、人手削減時間を記録する。
その後、国産チップクラスターまたはサーバーGPUを調達するか決める。
本番前にゲートウェイ、監査、監視、レート制限、ロールバックを補う。

この手順は、最初から大規模クラスターを買うより安定している。企業にとって最も怖いのは、モデルが弱いことではなく、多くの費用を使った後で、業務フローがモデル能力を受け止められないと分かることだ。

まとめ

DeepSeek V4は、企業のローカル私有化デプロイに大きな想像余地を与えた。しかし、それは単なる「ローカル版ChatGPT」ではない。本当の難点はエンジニアリングにある。ハードウェア、フレームワーク、モデルルーティング、権限、RAG、監査、監視、コスト制御をまとめて考える必要がある。

国産チップ路線は、コンプライアンス要求が高く、長期的にプライベートクラウドを構築する企業に向く。コンシューマーGPUクラスターは、試験導入や中小チームの迅速な検証に向く。Proは複雑な推論とAgentに向き、Flashや小モデルは大量の一般タスクに向く。

一文だけ覚えるなら、DeepSeek V4の私有化デプロイはハードウェア調達から始めるべきではない。業務シーン、データ境界、呼び出し規模から始めるべきだ。まずシーンを通し、その後で大モデルを使うか、どれくらいの規模にするか、どの計算基盤に載せるかを決める。

参考資料

RTX 3060 で動かしやすいローカル LLM モデルおすすめ

Fri, 08 May 2026 09:25:24 +0800

RTX 3060 で最もよく見かけるのは 12GB VRAM 版だ。最上位の AI GPU ではないが、ローカル LLM を動かすにはかなり実用的で、特に 7B、8B、9B、12B クラスのモデルに向いている。

すぐ選びたいなら、まず次の一文を覚えておくとよい。

RTX 3060 12GB では、8B 前後のモデルを Q4_K_M または Q5_K_M 量子化で選ぶ。安定重視なら Q4、品質を少し上げたいなら Q5 を試す。

最初から 32B や 70B を追う必要はない。低ビット量子化や CPU offload で動かせる場合もあるが、速度と体験は日常利用向きではないことが多い。

まず VRAM の上限を見る

RTX 3060 12GB でローカル LLM を動かすとき、本当の制約は VRAM だ。

モデル規模	推奨量子化	3060 12GB の体験
3B / 4B	Q4、Q5、Q8	とても軽く、速い
7B / 8B / 9B	Q4_K_M、Q5_K_M	最もおすすめ。品質と速度のバランスがよい
12B / 14B	Q4_K_M	試せるが、コンテキストを大きくしすぎない
30B 以上	Q2 / Q3 または一部 offload	試せるが、日常利用には非推奨
70B 以上	極低量子化または大量の CPU/RAM	実験に近い

ローカル LLM はモデルファイルだけが VRAM を使うわけではない。コンテキスト長、KV cache、バッチサイズ、推論フレームワーク、GPU ドライバもリソースを使う。

そのため、12GB VRAM があるからといって、12GB のモデルファイルをそのまま安全に読み込めるわけではない。システムとコンテキスト用に余裕を残すほうが安定する。

おすすめ1：Qwen3 8B

主に中国語を使うなら、Qwen3 8B は RTX 3060 で最初に試す価値が高い。

向いている用途：

中国語の質問応答。
要約とリライト。
日常的な知識アシスタント。
簡単なコード解説。
ローカル RAG。
軽量 Agent フロー。

おすすめ：

1
2
3

Qwen3 8B GGUF
Q4_K_M：最初のおすすめ
Q5_K_M：品質は上がるが、VRAM負荷も上がる

Qwen 系列は中国語に強く、日常の文章作成、資料整理、中国語指示の理解が比較的安定している。最初の中国語ローカルモデルに迷うなら、ここから始めるとよい。

おすすめ2：Llama 3.1 8B Instruct

Llama 3.1 8B Instruct は安定した汎用モデルで、英語能力とツールエコシステムが成熟している。

向いている用途：

英語の質問応答。
軽量なコード支援。
一般チャット。
文書要約。
プロンプトテスト。
推論ツールの比較。

おすすめ：

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M：速度とVRAMの安定性重視
Q5_K_M：回答品質重視

英語資料を主に扱う場合や、チュートリアルが多く互換性の高いモデルが欲しい場合、Llama 3.1 8B は今もよい基準モデルになる。

おすすめ3：Gemma 3 12B

Gemma 3 12B は RTX 3060 12GB の実用上限に近い選択肢だ。

8B モデルより VRAM を使うが、Q4 量子化なら 3060 12GB でも動かせる可能性がある。単一 GPU でもう少し大きいモデルを試したい人に向いている。

向いている用途：

より高品質な一般質問応答。
英語コンテンツ処理。
やや複雑な要約と分析。
8B モデルに物足りなさを感じたときの試行。

おすすめ：

1
2
3

Gemma 3 12B GGUF
Q4_K_M または公式 QAT Q4
コンテキストを大きくしすぎない

VRAM 不足になる場合は、まずコンテキスト長を下げるか、8B モデルに戻す。3060 にとって 12B は「試せる」選択肢であり、常に最初に選ぶモデルではない。

おすすめ4：DeepSeek R1 Distill Qwen 8B

ローカルで推論系モデルの雰囲気を試したいなら、DeepSeek R1 Distill Qwen 8B のような 8B 蒸留モデルが候補になる。

向いている用途：

簡単な推論問題。
段階的な分析。
推論モデルの出力スタイル学習。
低コストなローカル実験。

おすすめ：

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

この種のモデルは推論過程を長く出力することがあり、普通の指示モデルより速度やコンテキスト使用量が重く感じられる場合がある。日常チャットでは Qwen3 8B のほうが使いやすいこともあるが、推論実験には向いている。

おすすめ5：Phi / MiniCPM / 小型モデル

RTX 3060 が 8GB 版だったり、PC のメモリが少なかったりする場合は、3B、4B クラスのモデルから試すとよい。

向いている用途：

高速な質問応答。
簡単な要約。
ローカル小型ツールへの組み込み。
低遅延チャット。
古い PC でのテスト。

これらのモデルは 8B や 12B ほどの品質ではない場合もあるが、軽く、速く、導入しやすい。

量子化の選び方

ローカルモデルでは GGUF 形式がよく使われ、Q4、Q5、Q6、Q8 などの量子化がある。

量子化	特徴	向いている人
Q4_K_M	小さく速い。品質も十分	3060 の第一候補
Q5_K_M	品質が上がるが、使用量も増える	8B モデルで試す
Q6 / Q8	元品質に近いが大きい	小型モデルや VRAM に余裕があるとき
Q2 / Q3	VRAM を節約するが品質低下が大きい	大型モデルの実験

RTX 3060 12GB では、実用的には次の選び方になる。

1
2
3

8B モデル：Q4_K_M または Q5_K_M
12B モデル：Q4_K_M 優先
それ以上：日常主力には非推奨

どのツールで動かすか

初心者は Ollama から始めるとよい。インストールと実行が簡単だからだ。

よく使うコマンド例：

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

GGUF ファイル、GPU layers、コンテキスト長を細かく制御したい場合は、llama.cpp や llama.cpp ベースの GUI ツールを使う。

主な選択肢：

Ollama：最も簡単。初心者向け。
LM Studio：GUI が使いやすく、モデルのダウンロードと切り替えが簡単。
llama.cpp：細かい制御ができ、性能調整向け。
text-generation-webui：機能が多く、バックエンド比較向け。

ローカルチャットと簡単な質問応答だけなら、Ollama か LM Studio で十分だ。

コンテキストを大きくしすぎない

多くのモデルは長いコンテキスト対応をうたっているが、RTX 3060 では最大値まで上げないほうがよい。

コンテキストが長いほど KV cache の使用量が増え、VRAM 負荷も高くなる。モデルが読み込めても、長いコンテキストでは生成速度が落ちることがある。

目安：

1
2
3

普通のチャット：4K から 8K
文書要約：8K から 16K
長文書 RAG：まず分割し、全文を一度に詰め込まない

3060 は「中程度のコンテキスト + 良いモデル + 良い検索」に向いており、数十万 token を一度に入れる用途には向かない。

用途別の選び方

主に中国語を書く場合：

1
2

優先：Qwen3 8B Q4_K_M
候補：DeepSeek R1 Distill Qwen 8B

主に英語を書く場合：

1
2

優先：Llama 3.1 8B Instruct Q4_K_M
候補：Gemma 3 12B Q4_K_M

速度重視の場合：

1
2
3

3B / 4B モデル
8B Q4_K_M
コンテキストは 4K から 8K

品質重視の場合：

1
2
3

8B Q5_K_M
12B Q4_K_M
速度低下は受け入れる

コード用途の場合：

1
2

8B コードモデルは解説や小さな修正に使える
複雑なエンジニアリング作業はクラウドの強いモデルを使う

ローカル 3060 モデルは、コード解説、関数補完、小さなスクリプト生成、オフライン支援に向いている。大規模リファクタリング、難しい bug、ファイル横断の Agent タスクでは、Claude Sonnet や GPT-5 レベルを期待しないほうがよい。

RTX 3060 ローカル LLM への現実的な期待

RTX 3060 12GB は、ローカル LLM を「おもちゃ」から「日常的に使える道具」に近づけるカードだ。ただし、自宅で最上位クラウドモデルを再現するものではない。

強み：

コストが低い。
8GB カードより VRAM に余裕がある。
8B モデルの体験がよい。
オフライン利用できる。
プライバシーに敏感な資料をローカル処理できる。

制約：

大型モデルは滑らかに動かしにくい。
長いコンテキストは VRAM を消費する。
推論速度は上位 GPU に劣る。
小型ローカルモデルの複雑推論は限界がある。
マルチモーダルや Agent ワークフローはさらに重い。

安定した使い方は、8B モデルを日常ローカル助手にし、12B モデルを品質確認用に試し、複雑な作業はクラウドモデルへ任せることだ。

まとめ

RTX 3060 12GB でおすすめのローカル LLM は次の通り。

中国語汎用：Qwen3 8B Q4_K_M
英語汎用：Llama 3.1 8B Instruct Q4_K_M
高品質の試行：Gemma 3 12B Q4_K_M
推論実験：DeepSeek R1 Distill Qwen 8B Q4_K_M
低 VRAM 高速体験：3B / 4B 小型モデル

量子化はまず Q4_K_M を選び、8B モデルなら Q5_K_M も試せる。ツールは Ollama または LM Studio から始めるのがよい。

3060 を大規模モデルサーバーとして扱わないほうがいい。ローカル知識助手、プライバシー文書処理、軽量コード支援、モデル実験用カードとして使うほうが、実際の能力に合っている。

参考リンク

Qwen3 8B GGUF：https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF：https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF：https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp：https://github.com/ggml-org/llama.cpp
Ollama：https://ollama.com

Hermes + Qwen3.6：ローカル Agent の低コスト構築案

Mon, 04 May 2026 06:40:30 +0800

この記事は、ローカル Agent の構築案を整理したものだ。WSL2 上で llama.cpp を使って Qwen3.6 GGUF モデルを動かし、Hermes Agent をローカルの OpenAI-compatible API に接続する。これにより、自分の PC 上で長時間動作するローカル AI アシスタントを用意でき、オンラインサービスの Token 消費に縛られにくくなる。

この構成は、ローカル AI Agent を試したい人、データのプライバシーと長期的な管理性を重視する人に向いている。日常の質問応答、執筆、コード補助、資料整理、簡単な自動化タスクに使える。ただし、モデルが大きいほど VRAM 要件も高くなる。原文の例では Qwen3.6-27B を使っており、24GB VRAM のほうが安定しやすい。VRAM が少ない場合は、小さいモデルや低い量子化版を選ぶ。

構成

全体の流れはシンプルだ。

Windows に WSL2 と Ubuntu 24.04 をインストールする。
WSL2 内に CUDA Toolkit を入れ、llama.cpp をビルドする。
Qwen3.6 GGUF モデルをダウンロードする。
llama-server でローカルモデルサービスを起動する。
Hermes Agent をインストールし、http://localhost:8080/v1 に接続する。
任意で起動スクリプトを書き、WSL2 起動時にモデルサービスを自動起動する。

Hermes は Agent 機能を担当し、Qwen3.6 はローカル LLM 機能を担当する。組み合わせることで、PC をローカルのプライベート AI アシスタントにできる。

WSL2 と Ubuntu のインストール

Windows PowerShell を管理者として開き、次を実行する。

1
2

wsl --install
wsl --set-default-version 2

再起動後、Ubuntu 24.04 をインストールする。

`1`	`wsl --install -d Ubuntu-24.04`

インストール後、Ubuntu がユーザー名とパスワードの設定を求める。Ubuntu に入ったら、まず NVIDIA GPU が WSL2 から見えているか確認する。

`1`	`nvidia-smi`

GPU が認識されない場合は、Windows 側の NVIDIA ドライバを更新する。WSL2 は Windows ドライバを継承するが、CUDA Toolkit は WSL2 内に別途インストールする必要がある。

Python と基本ツールのインストール

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

続いて、ビルドツール、Git、CMake も必要になる。

`1`	`sudo apt install -y cmake build-essential git`

llama.cpp のビルド

まずソースコードを取得する。

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

WSL2 内で CUDA が使える状態なら、そのままビルドできる。

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 は RTX 40 シリーズなど Ada アーキテクチャ向けだ。別の GPU では実際のアーキテクチャに合わせて変更する。

CUDA Toolkit がないというエラーが出る場合は、先に WSL2 内で CUDA Toolkit をインストールする。

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

環境変数を設定する。

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

その後、再ビルドする。

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

Qwen3.6 GGUF モデルのダウンロード

原文の例では、unsloth/Qwen3.6-27B-GGUF の Qwen3.6-27B-UD-Q4_K_XL.gguf を使っている。

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

このファイルは約 17GB。Hugging Face のダウンロードが遅い場合は、ModelScope などのミラーを使う。VRAM が足りない場合は 27B を無理に使わず、小さいモデルか低い量子化版を選ぶ。

ローカルモデルサービスを起動する

自分のモデルファイル名に合わせて llama-server を起動する。

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

起動後、Windows のブラウザで次を開く。

`1`	`http://localhost:8080`

Hermes Agent や他の OpenAI-compatible クライアントから呼び出す場合、API アドレスは通常次になる。

`1`	`http://localhost:8080/v1`

Thinking モードの使い分け

Qwen3.6 はデフォルトで Thinking モードが有効になる場合がある。複雑な推論、難しいコード問題、多段階分析には向いているが、速度は遅くなる。

Thinking モードを無効にしたい場合は、サービスを停止して --chat-template-kwargs を追加する。

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

Thinking を無効にすると、簡単な Q&A、執筆、コード補完、コード説明は速くなる。一方、複雑なアルゴリズム設計、難しい Debug、アーキテクチャ分析では Thinking を有効にするほうがよい。

Hermes Agent のインストール

llama-server を動かしたまま、新しい WSL2 ターミナルを開いて Hermes Agent をインストールする。

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

インストールスクリプトは Python、Node.js、ripgrep、ffmpeg などの依存関係を処理する。モデル endpoint の設定では custom endpoint を選ぶ。

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: 自動認識

ローカルの llama-server では、API Key は任意のプレースホルダでよい。設定後は Telegram、WeChat、QQ、Discord などのチャットツールと接続し、Hermes Agent からローカルモデルを呼び出してタスクを実行できる。

モデルサービスの自動起動

WSL2 ターミナルを開いたときにモデルサービスを自動起動するスクリプトを用意できる。

スクリプトを作成する。

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

.bashrc に追記する。

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

これで WSL2 ターミナルを開くたびに、llama-server が動いていなければ自動起動する。すでに動いている場合はスキップされ、重複起動を避けられる。

注意事項

27B モデルは VRAM 要件が高い。24GB VRAM のほうが安定しやすく、VRAM が少ない場合は小さいモデルにする。
--ctx-size 65536 は VRAM と RAM の負荷を大きく増やす。不安定な場合は 32768 かそれ以下に下げる。
WSL2 内の CUDA Toolkit と Windows 側の GPU ドライバの両方が正常である必要がある。どちらかが問題を起こすと、CUDA のビルドや実行に失敗する。
Hermes Agent がローカルサービスへ接続する仕組みは OpenAI-compatible API 呼び出しであり、重要なのは http://localhost:8080/v1 が正常に応答すること。
スマホや他の端末からアクセスする場合は、Windows Firewall、LAN アドレス、セキュリティ分離を追加で扱う。ローカルモデルサービスを直接インターネットへ公開しない。

NVIDIA、Nemotron 3 Nano Omni を発表：エージェント向けのオープンな全モーダル推論モデル

Fri, 01 May 2026 12:07:15 +0800

NVIDIA は Nemotron 3 Nano Omni を発表した。これはエージェントワークフロー向けに設計された、オープンな全モーダル推論モデルである。重点は単なるテキスト問答ではなく、言語、視覚、音声を同じ推論フレームワークに入れ、実際の作業フローに近い入力を扱えるようにすることにある。

位置付けとして、Nemotron 3 Nano Omni は AI Agent のための基盤モデルに近い。画面、文書、画像、音声、動画に含まれる情報を理解し、それを実行可能な推論結果へ変換できる。この能力は、コンピューター操作、文書インテリジェンス、動画理解、音声対話、カスタマーサポート、教育、企業プロセスの自動化に向いている。

モデル仕様

Nemotron 3 Nano Omni は MoE アーキテクチャを採用している。 NVIDIA が示している主な仕様は次の通り。

項目	情報
モデル名	`Nemotron 3 Nano Omni`
アーキテクチャ	MoE
パラメータ規模	30B total / 3B active
モダリティ	テキスト、画像、音声、動画
コンテキスト長	256K token
ライセンス	Apache 2.0
主なデプロイ方向	AI Agent、マルチモーダル推論、企業向けエージェント

ここで最も注目したいのは 30B-A3B だ。これはモデル全体では約 30B パラメータを持つが、各推論では約 3B パラメータだけを有効化するという意味である。能力と推論コストのあいだで折り合いを付ける設計であり、大きなエキスパート容量を保ちながら、実行時にはその一部だけを使う。

ただし、MoE の active params は、VRAM を 3B モデル相当で見積もってよいという意味ではない。完全にデプロイするには、エキスパート重み、KV cache、視覚/音声エンコーダーモジュール、コンテキスト長、推論フレームワークのオーバーヘッドを考慮する必要がある。

解決しようとしているのは単一モーダルの問題ではない

従来の大規模言語モデルは主にテキストを処理する。マルチモーダルモデルはそこからさらに画像理解をサポートする。一方で Nemotron 3 Nano Omni の狙いはもっと広く、テキスト、画像、音声、動画をまとめて推論に取り込む全モーダル入力を重視している。

これは Agent にとって重要だ。実際のエージェントタスクは、「ある文章を受け取って別の文章を生成する」だけではないことが多い。たとえば次のようなものだ。

画面上のボタン、表、ウィンドウを見る。
PDF、スクリーンショット、グラフ、Web ページを読む。
音声の説明や会議録音を聞く。
動画内の動作、場面、時系列を理解する。
それらの情報を統合して次の操作に変換する。

モデルが単一モーダルしか扱えない場合、Agent は複数の専用モデルを追加でつなぎ合わせる必要がある。全モーダルモデルの価値は、この接続コストを減らし、同じモデルでより複雑な環境入力を直接処理できる点にある。

コンピューター操作と文書インテリジェンス向け

NVIDIA は、Nemotron 3 Nano Omni がコンピューター操作に関連するタスクに使えることを特に挙げている。この種のタスクでは、モデルがユーザーインターフェースを理解する必要がある。

画面上にどのようなコントロールがあるか。
現在のウィンドウがどの状態にあるか。
次に対象となるボタンやメニューはどれか。
表、ダイアログ、入力欄の内容が何を意味するか。

これは、現在の AI Agent が実際に使われる場面で避けて通りにくい能力でもある。エージェントがオフィスソフト、ブラウザ、企業向け管理画面、開発ツールの操作を支援するなら、API ドキュメントを読むだけではなく、画面を理解できなければならない。

文書インテリジェンスも同じ発想に近い。企業資料には、テキスト、表、画像、スキャンページ、グラフが混在していることが多い。全モーダルモデルはそれらを同じコンテキストに入れて理解できるため、契約書レビュー、レポート分析、請求書処理、ナレッジベースQA、プロセス自動化に向いている。

音声と動画が Agent をより現実の場面に近づける

音声と動画の入力は、Agent の応用範囲を大きく広げる。

音声の場面には次のようなものがある。

会議録音の要約。
カスタマーサポート通話の分析。
音声指示の理解。
教育・研修コンテンツの整理。

動画の場面には次のようなものがある。

教学動画の理解。
セキュリティや産業点検。
画面録画の分析。
操作フローの振り返り。
複数ステップのタスクにおける時系列判断。

これらのタスクを文字起こしだけで処理すると、多くの視覚情報や時系列情報が失われる。全モーダルモデルなら、音声、画面、テキストの手がかりを直接組み合わせ、Agent により完全な環境認識を与えられる。

デプロイとエコシステム

NVIDIA は Nemotron 3 Nano Omni をオープンなエコシステムに置いており、モデルは Apache 2.0 ライセンスを採用している。これは開発者や企業にとって重要だ。実験、統合、二次開発のライセンス上のハードルを下げるからである。

NVIDIA の説明を見ると、このモデルは同社の推論エコシステムとも強く結び付いている。企業ユーザーが実際にデプロイする際には、通常次のような点が気になる。

NVIDIA GPU 上で効率よく推論できるか。
長いコンテキストとマルチモーダル入力をサポートするか。
既存の Agent フレームワークに接続できるか。
社内文書、音声・動画、UI スクリーンショットを処理できるか。
プライベート環境にデプロイできるか。

NVIDIA はこのモデルのスループット面での優位性を強調しており、同種のオープンな全モーダル推論モデルに対して最大 9 倍に達するとしている。この数字の実際の価値は、具体的なハードウェア、コンテキスト長、入力モダリティ、推論フレームワークとあわせて見る必要がある。ただし方向性は明確だ。 NVIDIA はオープンなマルチモーダルモデルと自社の推論インフラを組み合わせ、企業向け Agent の場面へ押し出そうとしている。

向いている用途

Nemotron 3 Nano Omni は、次のようなタスクにより向いている。

テキスト、画像、音声、動画を同時に理解する必要がある Agent。
企業内の文書インテリジェンスとナレッジベースQA。
スクリーンショットや Web インターフェースに基づくコンピューター操作。
会議、カスタマーサポート、教学コンテンツのマルチモーダル分析。
動画理解、ワークフローの振り返り、時系列判断。
オープンライセンスとプライベートデプロイを必要とするチーム。

すべての一般ユーザーに向いているとは限らない。ローカルチャット、コード補完、簡単なQAだけなら、単一モーダルの言語モデルのほうが軽く、速く、省リソースである可能性が高い。 Nemotron 3 Nano Omni の価値は、主に複雑な入力とマルチモーダルな Agent ワークフローにある。

AI Agent にとって何を意味するのか

AI Agent が本当に仕事の現場に入っていくには、文字を書けるだけでは足りない。インターフェースを理解し、音声を聞き取り、文書を読み、動画内の変化を把握し、それらを次の行動へ変換する必要がある。

Nemotron 3 Nano Omni の意味はそこにある。単にモデルのパラメータを大きくしたのではなく、Agent が直面する複数種類の入力を一つの推論モデルに統合している。これにより、開発者はチャットウィンドウ中心のアプリではなく、現実のタスクに向いたエージェントを作りやすくなる。

この角度から見ると、NVIDIA がこのモデルを発表したポイントは「また一つマルチモーダルモデルが出た」ということだけではない。オープンモデル、GPU 推論、企業向け Agent、プライベートデプロイを引き続き接続しようとしている点にある。今後本当に注目すべきなのは、具体的な Agent フレームワーク、企業ワークフロー、ローカルデプロイの中でどのような実力を見せるかだ。

参考ソース：

NVIDIA 技術ブログ：NVIDIA Nemotron 3 Nano Omni

Qwen3.6 をローカルで動かす：27B と 35B-A3B の量子化版に必要なVRAM

Fri, 01 May 2026 12:02:00 +0800

Qwen3.6 でローカル部署の対象として特に重要な公開重み版は、主に次の2つです。

Qwen3.6-27B：27B の dense モデル。
Qwen3.6-35B-A3B：35B total / 3B active の MoE モデル。

Qwen3.6-Plus や Qwen3.6-Max のようなオンライン製品名や API モデル名もあります。ただし、完全な公開重みと安定した量子化ファイルがないモデルは、ローカルVRAM表には向きません。この記事では、Hugging Face の重みと GGUF 量子化ファイルをもとに部署できるバージョンだけを扱います。

/05/10 の Gemma 4 表と同じように、まず次の2つを分けて考える必要があります。

GGUF ファイルサイズ：モデル重みファイルそのものの大きさ。
実際のVRAM使用量：重み、KV cache、コンテキスト長、ランタイムバックエンド、マルチモーダルモジュール、バッチサイズで決まる。

Qwen3.6 は標準のコンテキストが非常に長く、公式モデルカードでは 262,144 tokens をネイティブでサポートし、1,010,000 tokens まで拡張可能とされています。そのため、表の「最低VRAM」は短い、または中程度のコンテキストを前提にした目安です。 128K、256K、またはそれ以上のコンテキストを本当に使う場合は、KV cache 用にかなり多くの余裕が必要です。

まず結論

VRAM	比較的向く選択	避けたい選択
8GB	27B / 35B-A3B の 2-bit 極限テスト。品質リスクは高い	Q4 以上
12GB	27B Q2/Q3、35B-A3B Q2/Q3 の短コンテキスト	27B Q4 の長コンテキスト
16GB	27B Q3/Q4、35B-A3B Q3/IQ4_XS	35B-A3B Q4 の長コンテキスト
24GB	27B Q4/Q5/Q6、35B-A3B Q4	35B-A3B Q8、BF16
32GB	27B Q8、35B-A3B Q5/Q6	BF16
48GB	35B-A3B Q8、27B の長めのコンテキストをより余裕を持って実行	35B-A3B BF16
80GB+	27B / 35B-A3B BF16	通常のローカルチャットで BF16 を追う必要はない

24GB GPU なら、重点的に見るべきなのは次の3つです。

Qwen3.6-27B Q4_K_M
Qwen3.6-27B Q5_K_M
Qwen3.6-35B-A3B UD-Q4_K_M

16GB VRAM しかない場合は、低ビット幅版から始め、いきなり超長コンテキストを使わないほうが安全です。

公式重みサイズ

以下は、公式 Hugging Face リポジトリの model.safetensors.index.json から確認できる BF16 重みサイズです。元のモデル規模を見るための参考になります。

モデル	アーキテクチャ	公式 BF16 重みサイズ	公式コンテキスト
`Qwen3.6-27B`	27B dense	55.56GB	ネイティブ 262K、1,010K まで拡張可能
`Qwen3.6-35B-A3B`	35B total / 3B active MoE	71.90GB	ネイティブ 262K、1,010K まで拡張可能

35B-A3B は各ステップで約 3B パラメータだけを有効化しますが、完全な MoE 重みを読み込む必要があります。そのため、3B 小型モデルのようにVRAMを見積もることはできません。

Qwen3.6-27B VRAM表

Qwen3.6-27B は dense モデルで、安定した挙動が強みです。一方で推論コストは従来の 27B モデルに近くなります。ローカル部署の観点では、35B-A3B より計算量は重いものの、VRAM要件は見積もりやすいです。

量子化版	GGUF ファイルサイズ	最低VRAM	安全なVRAM目安	向く用途
`UD-IQ2_XXS`	9.39GB	12GB	16GB	極限低VRAMテスト
`UD-IQ2_M`	10.85GB	12GB	16GB	低VRAMでの可用性優先
`UD-Q2_K_XL`	11.85GB	14GB	18GB	低ビット幅の折衷案
`UD-IQ3_XXS`	11.99GB	14GB	18GB	VRAMを抑えた 3-bit
`Q3_K_S`	12.36GB	16GB	20GB	3-bit 入門
`Q3_K_M`	13.59GB	16GB	20GB	3-bit の一般的な折衷案
`IQ4_XS`	15.44GB	20GB	24GB	Q4 に近い省VRAM選択
`IQ4_NL`	16.07GB	20GB	24GB	品質とサイズのバランス
`Q4_K_M`	16.82GB	20GB	24GB	27B の標準的なおすすめ
`Q5_K_M`	19.51GB	24GB	32GB	より高品質な量子化
`Q6_K`	22.52GB	28GB	32GB	品質優先
`Q8_0`	28.60GB	32GB	40GB	原精度に近い実行
`BF16`	53.80GB	64GB	80GB	研究、評価、精度比較

普通のローカルコーディングやチャットなら、Q4_K_M が最もおすすめしやすい出発点です。 24GB GPU なら Q4_K_M は比較的快適に動かせますが、長いコンテキストを使う場合は量子化サイズかコンテキスト長を下げるほうが安全です。

Qwen3.6-35B-A3B VRAM表

Qwen3.6-35B-A3B は MoE モデルで、35B total、各ステップで約 3B パラメータを有効化します。速度と能力のバランスがよく、特にローカル Agent、ツール呼び出し、コード作業に向いています。

ただし、MoE の 3B active は主に計算量に効くものであり、VRAMが 3B モデル相当で済むという意味ではありません。完全に動かすには専門家重みを読み込む必要があります。

量子化版	GGUF ファイルサイズ	最低VRAM	安全なVRAM目安	向く用途
`UD-IQ2_XXS`	10.76GB	12GB	16GB	極限低VRAMテスト
`UD-IQ2_M`	11.52GB	14GB	16GB	低VRAMでの可用性優先
`UD-Q2_K_XL`	12.29GB	14GB	18GB	低ビット幅の折衷案
`UD-IQ3_XXS`	13.21GB	16GB	20GB	VRAMを抑えた 3-bit
`UD-Q3_K_S`	15.36GB	18GB	24GB	3-bit 入門
`UD-Q3_K_M`	16.60GB	20GB	24GB	3-bit の一般的な折衷案
`UD-IQ4_XS`	17.73GB	20GB	24GB	品質とサイズのバランス
`UD-IQ4_NL`	18.04GB	20GB	24GB	Q4 に近いおすすめ選択
`UD-Q4_K_M`	22.13GB	24GB	32GB	35B-A3B の標準的なおすすめ
`UD-Q5_K_M`	26.46GB	32GB	40GB	より高品質な量子化
`UD-Q6_K`	29.31GB	32GB	48GB	品質優先
`Q8_0`	36.90GB	48GB	64GB	原精度に近い実行
`BF16`	69.37GB	80GB	96GB	研究、評価、精度比較

24GB VRAM なら UD-Q4_K_M が有力ですが、コンテキストは上げすぎないほうがよいです。 128K 以上のコンテキストに余裕を残したい場合、UD-IQ4_XS、UD-IQ4_NL、または 3-bit 版のほうが現実的です。

27B と 35B-A3B の選び方

目的	よりおすすめ
dense モデルの安定性	`Qwen3.6-27B`
速い応答、Agent、ツール呼び出し	`Qwen3.6-35B-A3B`
24GB VRAM での日常ローカル利用	`35B-A3B UD-Q4_K_M` または `27B Q4_K_M`
16GB VRAM での試用	どちらも 2-bit/3-bit。長コンテキストは避ける
長コンテキスト優先	低ビット量子化にして KV cache の余裕を残す
32GB+ VRAM で品質優先	`27B Q5/Q6` または `35B-A3B Q5/Q6`

コードを書いたり、Agent を動かしたり、ツール呼び出しを使うなら、35B-A3B を先に試す価値があります。 dense モデルの安定性や一貫性を重視するなら、27B のほうがわかりやすい選択です。

長コンテキストが大量のVRAMを使う理由

Qwen3.6 のモデルカードでは、複雑なタスクで長めのコンテキストを保つことが推奨されており、128K 以上のコンテキストが思考能力に役立つとも述べられています。しかしローカル部署では、長コンテキストは大きな KV cache を意味します。

実際のVRAM使用量に影響する要素は次の通りです。

KV cache：コンテキストが長いほど使用量が増える。
視覚入力を有効にするかどうか：Qwen3.6 は視覚エンコーダを持つため、マルチモーダル利用では追加コストがある。
--language-model-only を使うかどうか：vLLM などでは、視覚部分をスキップすると KV cache 用のメモリを一部空けられる。
バッチサイズと並列性：並列性が高いほどVRAM要求も高くなる。
KV cache 量子化：q8_0、q4_0 などはVRAMを節約できるが、細部に影響する場合がある。
ランタイム差：llama.cpp、vLLM、SGLang、KTransformers、LM Studio の使用量は完全には同じではない。

そのため、GGUF ファイルサイズだけを見てはいけません。ファイルがすでにVRAM上限に近い場合、モデルは読み込めても、長い出力や長コンテキスト生成で OOM になる可能性があります。

どう選ぶか

ローカルで Qwen3.6 を試したいだけなら：

12GB VRAM：27B UD-IQ2_M または 35B-A3B UD-IQ2_M。コンテキストは短くする。
16GB VRAM：27B Q3_K_M または 35B-A3B UD-IQ3_XXS。
24GB VRAM：27B Q4_K_M、35B-A3B UD-IQ4_NL、35B-A3B UD-Q4_K_M を優先。
32GB VRAM：27B Q5/Q6 または 35B-A3B Q5/Q6 を検討。
48GB 以上：Q8_0 を試すか、長コンテキスト用に余裕を残す。

多くのユーザーに BF16 は不要です。 Qwen3.6 のローカル部署で重要なのは、ファイルサイズの大きさではなく、VRAM、コンテキスト長、速度、出力品質のバランスです。

参考元

DeepSeek V4 をローカルで動かす：Pro、Flash、Base 版のVRAM使用量見積もり

Fri, 01 May 2026 11:55:25 +0800

DeepSeek V4 と Gemma 4 は、ローカル実行の難度がまったく違います。 Gemma 4 の 26B や 31B なら、24GB や 32GB のGPUでどの量子化版を選ぶかをまだ議論できます。DeepSeek V4 は巨大な MoE モデルであり、完全なローカル実行では多GPUワークステーションやサーバー級のVRAMが必要になります。

公式の DeepSeek V4 Preview には、主に2つの推論モデルがあります。

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

Hugging Face の公式 collection には、さらに2つの Base モデルも含まれています。

DeepSeek-V4-Pro-Base
DeepSeek-V4-Flash-Base

この記事では、モデル重みを完全に読み込む場合のおおまかなVRAM要件だけを扱います。 MoE の active params は主に各 token の計算量に効くものであり、その分のパラメータだけを読み込めばよいという意味ではありません。専門家のオンデマンド読み込み、CPU/NVMe offload、分散推論、専用ランタイム最適化がない場合、VRAMは基本的に完全な重みサイズを基準に見積もる必要があります。

まず結論

VRAM規模	比較的現実的に試せるもの	期待しないほうがよいもの
24GB	DeepSeek V4 の完全実行は不可。小型蒸留モデルまたはAPI向け	V4-Flash / V4-Pro の完全ローカル読み込み
48GB	まだ完全読み込みには不向き。小型モデルやリモートAPIクライアント向け	V4-Flash Q4 の安定実行
80GB	理論上 V4-Flash Q2/Q3 や強い offload を試せる	V4-Pro
128GB	V4-Flash Q4 が比較的現実的。Q5/Q6 はまだ厳しい	V4-Pro Q4
192GB	V4-Flash FP8/Q6 は余裕が出る。Pro Q2 は実験範囲	V4-Pro Q4
256GB	V4-Flash FP8 はかなり安定。Pro Q2/Q3 は実験可能	V4-Pro Q5 以上
512GB	V4-Pro Q4 が議論できる範囲に入る	V4-Pro FP8
1TB+	V4-Pro FP8、Pro-Base の低ビット幅がより現実的	低コスト単体マシン運用
2TB+	Pro-Base FP8 クラス	普通のワークステーション運用

個人PCでローカル実行することが目的なら、DeepSeek V4 は適切な対象ではありません。より現実的な選択肢は次の通りです。

DeepSeek 公式 API または互換サービスを使う。
安定したコミュニティ製 GGUF/EXL2/MLX 量子化と推論サポートを待つ。
より小さな DeepSeek 蒸留モデルを使う。
Qwen、Gemma、Llama などの 7B〜70B 級ローカルモデルを使う。

公式重みサイズ

以下は Hugging Face 公式リポジトリの model.safetensors.index.json から確認できる重み総量です。これは現在公開されている重みファイルのサイズであり、長いコンテキスト実行時の完全なVRAM使用量ではありません。

モデル	パラメータ規模	公式重みサイズ	説明
`DeepSeek-V4-Flash`	284B total / 13B active	159.61GB	推論版。この中では最小
`DeepSeek-V4-Pro`	1.6T total / 49B active	864.70GB	推論版。より強力だが非常に大きい
`DeepSeek-V4-Flash-Base`	284B total	294.67GB	Base 版。全量 FP8 重みに近いサイズ
`DeepSeek-V4-Pro-Base`	1.6T total	1606.03GB	Base 版。約 1.6TB クラス

最小の V4-Flash でも、公式重みはすでに約 160GB あります。そのため、13B active params だからといって 13B 小型モデルのようには扱えません。

DeepSeek V4 Flash のVRAM見積もり

V4-Flash は DeepSeek V4 の中では最もローカル実験に近いモデルです。ただし、それは Pro と比べた場合の話であり、消費者向け単体GPUモデルではありません。

以下では、公式の 159.61GB 重みサイズを基準にしています。 Q4/Q3/Q2 はビット幅からの推定であり、安定した公式 GGUF 版が存在することを意味しません。

版 / 量子化	推定重みサイズ	最低VRAM	安全なVRAM目安	向く用途
`FP8 / 公式重み`	159.61GB	192GB	256GB	多GPUサーバー、推論サービス
`Q6`	120GB	160GB	192GB	品質優先の量子化実験
`Q5`	100GB	128GB	160GB	品質とサイズのバランス
`Q4`	80GB	96GB	128GB	Flash ローカル化の比較的現実的な出発点
`Q3`	60GB	80GB	96GB	大容量VRAM単体GPUまたは多GPU実験
`Q2`	40GB	48GB	64GB	極限低ビット実験。品質リスクは大きい

将来、成熟した V4-Flash Q4 が出たとしても、24GB GPU向けのモデルにはなりにくいです。より現実的な出発点は、96GB〜128GB 級の総VRAM、または速度を犠牲にした CPU/offload 構成です。

DeepSeek V4 Pro のVRAM見積もり

V4-Pro は旗艦推論版で、公式重みサイズは約 864.70GB です。 4-bit 量子化をしても、完全な重みは数百GB級のままです。

版 / 量子化	推定重みサイズ	最低VRAM	安全なVRAM目安	向く用途
`FP8 / 公式重み`	864.70GB	1TB	1.2TB+	多ノードまたは多GPU推論サービス
`Q6`	648GB	768GB	1TB	高品質な量子化サービス
`Q5`	540GB	640GB	768GB	品質とコストのバランス
`Q4`	432GB	512GB	640GB	Pro ローカル化で現実的な最低品質ライン
`Q3`	324GB	384GB	512GB	低ビット実験
`Q2`	216GB	256GB	320GB	極限実験。品質と安定性のリスクが高い

個人ユーザーにとって、V4-Pro は API 経由で使うほうが現実的です。完全なローカル実行を目指すなら、4090、5090、RTX PRO 単体GPUではなく、多GPUサーバーモデルとして考えるべきです。

DeepSeek V4 Flash-Base のVRAM見積もり

Base 版は通常、研究、微調整、継続学習向けであり、普通のチャット用途の第一候補ではありません。 V4-Flash-Base の公式重みサイズは約 294.67GB です。

版 / 量子化	推定重みサイズ	最低VRAM	安全なVRAM目安	向く用途
`FP8 / 公式重み`	294.67GB	384GB	512GB	研究、前処理、評価
`Q6`	221GB	256GB	320GB	高品質量子化研究
`Q5`	184GB	224GB	256GB	品質とサイズのバランス
`Q4`	147GB	192GB	224GB	低コストな Base 版実験
`Q3`	111GB	128GB	160GB	低ビット実験
`Q2`	74GB	96GB	128GB	極限実験

DeepSeek V4 の能力を使いたいだけなら、Base 版から始めることはおすすめしません。 Base 版はデプロイと調整のコストが高く、通常のアプリケーションには推論版または API のほうが向いています。

DeepSeek V4 Pro-Base のVRAM見積もり

V4-Pro-Base は最も重いバージョンで、公式重みサイズは約 1606.03GB です。これはすでに 1.6TB クラスのモデルファイルです。

版 / 量子化	推定重みサイズ	最低VRAM	安全なVRAM目安	向く用途
`FP8 / 公式重み`	1606.03GB	2TB	2.4TB+	大規模研究クラスタ
`Q6`	1205GB	1.5TB	2TB	高品質量子化研究
`Q5`	1004GB	1.2TB	1.5TB	研究と評価
`Q4`	803GB	1TB	1.2TB	低ビット研究
`Q3`	602GB	768GB	1TB	極限低ビット研究
`Q2`	402GB	512GB	640GB	極限実験

この種のモデルは、「家庭用GPUで動くか」という枠組みで考える対象ではありません。 Q4 であっても、ほとんどの単体ワークステーションの快適な範囲を超えています。

active params だけを見てはいけない理由

DeepSeek V4 は MoE モデルです。 MoE では各 token が一部の専門家だけを有効化するため、計算量は総パラメータ数よりかなり小さくなります。しかし、それはVRAMに active params だけを載せればよいという意味ではありません。

完全なローカル推論では、次の要素も考える必要があります。

すべての専門家重みをGPUに常駐させる必要があるか。
専門家のオンデマンド読み込みに対応しているか。
CPUメモリとGPU VRAM間のデータ転送コスト。
NVMe offload の遅延。
長コンテキストで増える KV cache。
1M context 実行時の追加ランタイムコスト。
多ノード・多GPU通信コスト。

したがって、49B active の V4-Pro を 49B モデルとして扱ってはいけません。 13B active の V4-Flash も、13B 小型モデルとして扱うべきではありません。

どう選ぶか

普通の個人ユーザーなら：

DeepSeek V4 を完全にローカル実行することはおすすめしません。
DeepSeek V4 の能力が必要なら、まず公式 API を使う。
ローカル私有化が必要なら、成熟した推論サービス基盤や社内多GPUサーバーがあるかを先に確認する。
24GB〜48GB VRAM しかない場合は、7B、14B、32B、70B 級の量子化モデルのほうが現実的です。

128GB〜256GB の総VRAMがある場合：

V4-Flash Q4/Q5 の安定したコミュニティ実装を注視する。
V4-Pro を主力ローカルモデルとして扱うのはおすすめしません。

512GB 以上の総VRAMがある場合：

V4-Pro Q4 がようやく工学的な検証対象になります。
それでも推論フレームワーク、専門家スケジューリング、KV cache、スループット、並列性を確認する必要があります。

DeepSeek V4 のローカル部署で重要なのは、「どの量子化ファイルをダウンロードするか」ではありません。「このモデルを支えるだけのシステムレベルの推論能力があるか」です。これはデスクトップモデルというより、サーバーモデルに近い存在です。

参考元

Gemma 4 をローカルで動かす：E2B、E4B、26B、31B の量子化版に必要なVRAM

Fri, 01 May 2026 11:42:34 +0800

Gemma 4 には、ローカル実行向けに主に E2B、E4B、26B A4B、31B の4サイズがあります。 E2B と E4B は軽量・エッジデバイス向け、26B A4B は MoE アーキテクチャ、31B はより大きな dense モデルです。

ローカル実行で混同しやすい数字は次の2つです。

GGUF ファイルサイズ：モデル重みファイルそのものの大きさ。
実際のVRAM使用量：モデル重み、KV cache、ランタイムのオーバーヘッド、コンテキスト長、マルチモーダル投影ファイルの有無で決まる。

以下の表は、GGUF ファイルサイズをもとにVRAM要件を見積もったものです。前提は llama.cpp、LM Studio、Ollama などで、主にテキスト推論を行い、短〜中程度のコンテキストを使うローカル環境です。長いコンテキスト、画像/音声入力、並列リクエストを使う場合は、さらにVRAMの余裕が必要です。

まず結論

VRAM	比較的向く選択	避けたい選択
4GB	E2B の低ビット量子化	E4B 以上
6GB	E2B Q4/Q5、E4B の低ビット量子化	26B、31B
8GB	E2B Q8、E4B Q4/Q5	26B Q4、31B Q4
12GB	E4B Q8、26B/31B の 2-bit/3-bit 実験	26B Q4 の長コンテキスト、31B Q4
16GB	26B 低ビット量子化、31B 低ビット量子化	31B Q4 の長コンテキスト、26B Q5 以上
24GB	26B Q4/Q5、31B Q4	31B Q8、BF16
32GB	26B Q6/Q8、31B Q5/Q6	BF16
48GB	31B Q8 をより余裕を持って実行、26B Q8 の長めのコンテキスト	31B BF16
80GB+	26B/31B BF16	一般的なコンシューマーGPU単体での運用

まずローカルで使えるものを動かしたいなら、E4B Q4_K_M または E2B Q4_K_M から始めるのが現実的です。 24GB VRAM があれば、26B A4B Q4_K_M と 31B Q4_K_M がようやく使いやすい範囲に入ります。

Gemma 4 E2B VRAM表

E2B は最も軽量なバージョンで、ノートPC、ミニPC、モバイル端末、低VRAM環境でのテストに向いています。動かしやすい一方で、複雑な推論、コード生成、長いタスクの安定性には限界があります。

量子化版	GGUF ファイルサイズ	最低VRAM	安全なVRAM目安	向く用途
`UD-IQ2_M`	2.29GB	4GB	6GB	極限の低VRAMテスト
`UD-Q2_K_XL`	2.40GB	4GB	6GB	低VRAMでの可用性優先
`Q3_K_M`	2.54GB	4GB	6GB	軽いチャット、要約
`IQ4_XS`	2.98GB	6GB	8GB	品質とサイズのバランス
`Q4_K_M`	3.11GB	6GB	8GB	E2B の標準的なおすすめ
`Q5_K_M`	3.36GB	6GB	8GB	Q4 より少し安定
`Q6_K`	4.50GB	8GB	10GB	小型モデルで品質優先
`Q8_0`	5.05GB	8GB	10GB	軽量運用で原精度に近づけたい場合
`BF16`	9.31GB	12GB	16GB	デバッグ、比較、研究

日常的な体験なら E2B Q4_K_M で十分です。 4GB VRAM しかない場合は 2-bit や 3-bit も試せますが、出力品質は不安定になりやすくなります。

Gemma 4 E4B VRAM表

E4B は、より実用的な軽量版です。 E2B よりも日常的な文章作成、資料要約、軽いコード補助、ローカルアシスタント用途に向いています。

量子化版	GGUF ファイルサイズ	最低VRAM	安全なVRAM目安	向く用途
`UD-IQ2_M`	3.53GB	6GB	8GB	低VRAMテスト
`UD-Q2_K_XL`	3.74GB	6GB	8GB	低VRAMでの可用性優先
`Q3_K_M`	4.06GB	6GB	10GB	軽量ローカルアシスタント
`IQ4_XS`	4.72GB	8GB	12GB	品質と速度のバランス
`Q4_K_M`	4.98GB	8GB	12GB	E4B の標準的なおすすめ
`Q5_K_M`	5.48GB	8GB	12GB	より安定した日常利用
`Q6_K`	7.07GB	10GB	16GB	品質優先
`Q8_0`	8.19GB	12GB	16GB	原精度に近い実行
`BF16`	15.05GB	20GB	24GB	研究、評価、精度比較

8GB VRAM のGPUなら、E4B Q4_K_M が現実的な出発点です。 12GB または 16GB VRAM があるなら、E4B Q8_0 も候補になります。

Gemma 4 26B A4B VRAM表

26B A4B は MoE 版で、総パラメータ数は大きいものの、推論時には一部の専門家だけを有効化します。より複雑なQ&A、コード、ツール呼び出し、Agent ワークフローに向いています。

量子化版	GGUF ファイルサイズ	最低VRAM	安全なVRAM目安	向く用途
`UD-IQ2_M`	9.97GB	14GB	16GB	16GB GPUでの限界テスト
`UD-Q2_K_XL`	10.55GB	14GB	16GB	低VRAMで 26B を動かす
`UD-Q3_K_M`	12.53GB	16GB	20GB	品質を少し上げつつVRAM節約
`UD-IQ4_XS`	13.42GB	16GB	24GB	品質とサイズのバランス
`UD-Q4_K_M`	16.87GB	20GB	24GB	26B の標準的なおすすめ
`UD-Q5_K_M`	21.15GB	24GB	32GB	より高品質な量子化
`UD-Q6_K`	23.17GB	28GB	32GB	品質優先
`Q8_0`	26.86GB	32GB	40GB	原精度に近い実行
`BF16`	50.51GB	64GB	80GB	一般的な単体コンシューマーGPUでは非現実的

26B A4B を快適に使う分岐点は 24GB VRAM です。 16GB GPU でも低ビット版は試せますが、コンテキスト長、並列性、マルチモーダル入力は控えめにする必要があります。

Gemma 4 31B VRAM表

31B はより大きな dense モデルです。総合能力が高い一方で、VRAM負荷は 26B A4B より直接的に効いてきます。

量子化版	GGUF ファイルサイズ	最低VRAM	安全なVRAM目安	向く用途
`UD-IQ2_XXS`	8.53GB	12GB	16GB	極限低VRAMテスト、品質低下は大きい
`UD-IQ2_M`	10.75GB	14GB	18GB	低VRAMテスト
`UD-Q2_K_XL`	11.77GB	16GB	20GB	16GB GPUでの実験
`Q3_K_S`	13.21GB	16GB	24GB	VRAMを抑えた 3-bit
`Q3_K_M`	14.74GB	20GB	24GB	3-bit の一般的な折衷案
`IQ4_XS`	16.37GB	20GB	24GB	Q4 に近い折衷案
`Q4_K_M`	18.32GB	24GB	32GB	31B の標準的なおすすめ
`Q5_K_M`	21.66GB	28GB	32GB	より高品質な量子化
`Q6_K`	25.20GB	32GB	40GB	品質優先
`Q8_0`	32.64GB	40GB	48GB	原精度に近い実行
`BF16`	61.41GB	80GB	96GB	サーバーまたは大容量VRAMワークステーション

31B の低ビット版は 16GB GPU でも実験できますが、日常利用には 24GB VRAM から始めるのが無難です。 Q4_K_M はバランスのよい選択で、Q5_K_M 以上は 32GB 以上のVRAMでより現実的です。

実際の使用量がファイルサイズより増える理由

GGUF ファイルサイズは重みの大きさにすぎません。実行時には次のような追加コストがあります。

KV cache：コンテキストが長いほど使用量が増える。
バッチサイズと並列性：一度に処理する token やユーザー数が増えるとVRAMも増える。
マルチモーダル部品：画像、音声、動画入力では通常 mmproj や追加モジュールが必要。
ランタイムバックエンド：CUDA、Metal、ROCm、CPU/GPU 分割ロードで占用が変わる。
KV cache 量子化：q8_0、q4_0 などでVRAMを節約できるが、細部に影響する場合がある。

そのため、表の「最低VRAM」は「起動して短いコンテキストで動く」目安として見るべきです。 32K、64K、128K、さらに 256K コンテキストを使う場合、必要VRAMは大きく増えます。

どう選ぶか

ローカルで Gemma 4 を試したいだけなら：

4GB〜6GB VRAM：E2B Q3_K_M または E2B Q4_K_M。
8GB VRAM：まず E4B Q4_K_M。E2B Q8_0 も選択肢。
12GB VRAM：E4B Q8_0、または 26B/31B の低ビット版を試す。
16GB VRAM：26B A4B UD-Q3_K_M または 31B Q3_K_S を試せるが、長いコンテキストは期待しすぎない。
24GB VRAM：26B A4B UD-Q4_K_M と 31B Q4_K_M が本命。
32GB 以上：Q5_K_M、Q6_K、またはより長いコンテキストを検討。

多くのユーザーに BF16 は不要です。ローカル部署で重要なのは、ファイルサイズの大きさではなく、VRAM、速度、コンテキスト長、出力品質のバランスです。

参考元

8GB VRAM で llama.cpp をどう調整するか: 32K の方が安定しやすく、64K では KV Cache 量子化が重要

Thu, 23 Apr 2026 12:13:04 +0800

8GB の VRAM でローカル LLM をスムーズに動かせるのか、特に長いコンテキストで速度を維持できるのかは、llama.cpp を使う人がよく直面する問題です。

まず覚えておきたいポイントは 3 つあります。

8GB VRAM では、32K コンテキストの方が安定したバランスになりやすい
どうしても 64K を使いたいなら、KV Cache の量子化がほぼ必須になる
フル GPU 推論では、CPU スレッド数をむやみに増やすとかえって遅くなることがある

1. まず、32K・64K・KV Cache とは何か

この手の調整記事で最初につまずきやすいのが、この 3 つの用語です。

32K と 64K はコンテキスト長を意味し、モデルが一度に処理できる token 数の上限を表します。ここでの K は千なので、32K は約 32000 token、64K は約 64000 token です。コンテキストが長いほど、モデルは一度により多くの過去情報を見られるため、長文読解、長い対話、複数段階の分析に向いています。

KV Cache は、連続生成を高速化するためにモデルが保持する中間結果のキャッシュです。すでに読んで計算済みの部分を毎回最初から計算し直すのではなく、重要な中間情報を保存して再利用する仕組みだと考えるとわかりやすいです。K と V は Transformer の Key と Value を指します。

この 3 つがいつも一緒に出てくるのは、次の関係があるからです。

32K と 64K は、一度にどれだけの内容を記憶させたいかを決める
KV Cache は、その記憶を維持するためにどれだけ追加の VRAM が必要かを決める
コンテキストが長くなるほど KV Cache は大きくなり、VRAM の負担も増える

そのため、長コンテキストで速度が落ちる原因は、モデルの計算能力不足というより、キャッシュが大きくなりすぎて VRAM が限界に近づくことにある場合が多いです。

2. なぜ 32K と 64K で速度差が大きくなるのか

たとえば《三体》の約 3 万字を使って負荷テストを行い、32K と 64K のコンテキストを比較すると、文章量が近くても 64K の方が大きく遅くなり、総処理時間もかなり長くなることがあります。

原因はモデルが急に遅くなったからではなく、VRAM の境界にぶつかったからです。

32K では、モデルの重みとキャッシュがまだ 8GB VRAM の中にほぼ収まり、データは主に GPU メモリ帯域の中で処理されます。ところが 64K にするとキャッシュがさらに増え、総使用量が VRAM 上限に近づくか超えてしまい、一部データが共有メモリやシステムメモリに押し出されます。

このとき落ちるのは演算性能そのものではなく、帯域です。

つまり、「コンテキストを倍にしたら急に遅くなった」という現象の本質は、データ経路が VRAM からより遅いメモリへ落ちたことにあります。

3. 64K を使うなら、KV Cache 量子化が重要

8GB VRAM 環境で特に重要なのが、KV Cache の量子化です。

モデル本体を変えず、キャッシュだけを量子化すると、長コンテキスト時のキャッシュ使用量を直接削減できます。すると、もともと VRAM からあふれていた一部のデータを 다시 VRAM 側に戻しやすくなります。その結果、64K は依然として 32K より重いものの、最も遅い領域に落ち込みにくくなります。

要するに、

32K は 8GB VRAM における実用的な標準レンジ
64K も不可能ではない
ただしキャッシュ量子化なしでは、「使える」から「かなり厳しい」へ一気に落ちやすい

長コンテキストを安定して使いたいなら、優先順位は次のようになります。

まず VRAM が上限に近づいていないか確認する
次に KV Cache 量子化を有効にするか判断する
その後で、より攻めたスループット設定を試す

4. GPU 使用率が低くても、GPU が遊んでいるとは限らない

これは直感に反しやすいポイントです。

タスクマネージャーで GPU 使用率が 20% や 30% しか見えないと、多くの人は次のように考えます。

パラメータ設定が間違っているのではないか
モデルが本当に GPU 上で動いていないのではないか
GPU を使い切れていないのではないか

しかし llama.cpp の推論では、ボトルネックがコア演算ではなくメモリ読み書きにあることがよくあります。

つまり、GPU コアはあるバッチの計算をすぐ終えても、次の重みやキャッシュデータが届くまで待たされる、という状態です。

その結果、

コア使用率はそれほど高くない
それでも全体の速度は伸びない

という現象になります。

これは GPU が怠けているのではなく、データ経路が狭いだけです。

そのため、ローカル LLM の速度を見るときは GPU Usage だけで判断してはいけません。VRAM 容量、メモリ帯域、キャッシュのあふれ方の方が重要なことが多いです。

5. スループット関連パラメータは効くことがあるが、VRAM 余裕が前提

GPU コアが完全には埋まっていないなら、スループット関連の設定を上げて一度に処理するデータ量を増やし、GPU の並列性をもっと引き出せるのではないか、という考え方があります。

これは実際に速度向上につながることがあります。

ただし前提条件があります。VRAM にまだ余裕があることです。

スループット関連の設定を上げると、VRAM 使用量も増えることが多いからです。すでに 64K、大きなキャッシュ、VRAM ぎりぎりという状態でさらに押し上げると、次のような結果になりがちです。

そのままクラッシュする
クラッシュしなくても、より遅い共有メモリモードに落ちる

したがって、より安全な順番は「最初に全部最大化する」ことではなく、

まず VRAM の境界を守る
次にスループット最適化を試す
変更のたびに速度と安定性を確認する

という流れです。

6. CPU スレッドは多ければ多いほどよいわけではない

これも覚えておきやすい落とし穴です。

スレッドが多いほど速いはずだ、と考えるのは自然です。しかし、モデルがすでに主に GPU で動いている場合、CPU スレッド数を無理に増やすとかえって性能が落ちることがあります。

理由は単純です。

フル GPU 推論では、CPU は主力の計算機というより、スケジューラや前処理補助の役割に近くなります。この状態でスレッドを増やしすぎると、CPU 側のスレッド競合、スケジューリング負荷、コンテキストスイッチのコストが大きくなり、本来スムーズであるべきデータの流れを乱してしまいます。

結果として、

CPU はより忙しそうに見える
それでも全体は遅くなる

ということが起きます。

この種の構成では、デフォルト設定や低めのスレッド数の方が、全部を最大化するより安定しやすいです。

7. 8GB VRAM 向けの、より実用的な考え方

ここまでの結論を実行しやすい形にまとめると、だいたい次のようになります。

1. まず 32K を標準目標にする

8GB GPU なら、最初から 64K を狙いにいかない方が無難です。32K の方が、速度・安定性・メモリ使用量のバランスが取りやすいことが多いです。

2. 64K を使いたいなら、まずキャッシュを見る

「あと少し速くできるか」より先に、KV Cache が量子化されているか、VRAM がすでに限界付近ではないかを確認すべきです。

3. GPU 使用率だけで判断しない

使用率が低いからといって設定ミスとは限りません。単にメモリ帯域が本当のボトルネックかもしれません。

4. スループット最適化は有効だが、VRAM 境界を越えない

これらの設定は確かに効くことがありますが、前提は VRAM に余裕があることです。

5. CPU スレッドは保守的に始める

モデルがほぼ GPU 上で動いているなら、CPU スレッド数は高ければよいわけではありません。まずはデフォルトか低めで試し、必要なら少しずつ調整します。

結論

この話の価値は、いくつかのベンチマーク数字そのものより、ひとつの見落とされがちな事実をはっきりさせてくれる点にあります。

ローカル LLM の調整で本当に大事なのは、すべての設定を最大にすることではなく、ボトルネックが演算性能なのか、VRAM 容量なのか、メモリ帯域なのか、それとも CPU のスケジューリングなのかを見極めることです。

8GB VRAM ユーザーにとって、より安全な方針は「最長コンテキストを無理に追う」ことではなく、まず VRAM の境界を守り、そのうえでどこまで伸ばすかを判断することです。

ひとことでまとめるなら、こうです。

32K は 8GB VRAM でより安定しやすい作業レンジであり、64K も不可能ではないが、その前提として KV Cache と VRAM 使用量をしっかり管理できている必要がある。

16GB GPUでも35Bモデルは動かせる: LM StudioでMoEモデルのVRAMを圧縮する考え方

Wed, 22 Apr 2026 21:47:34 +0800

16GB VRAM というと、ローカルで大規模モデルを動かす場合はせいぜい 12B〜14B あたりが限界で、それ以上は量子化してもかなり厳しい、というイメージを持つ人が多いと思います。その見方は完全に間違いではありませんが、16GB GPU の本当の上限でもありません。

モデル選定とパラメータ設定がうまく噛み合えば、16GB GPU は必ずしも「小さめのモデル」に留まる必要はありません。その代表的な考え方のひとつが、LM Studio で MoE モデルを使い、適切なアンロード戦略によって 35B 級モデルを実用的な速度で回すというものです。

01 なぜ16GB GPUが12B〜14Bに固定されるわけではないのか

ここでの核心はシンプルです。VRAM 容量は重要ですが、モデルのアーキテクチャも同じくらい重要です。

標準的な dense モデルを 16GB GPU に無理やり押し込もうとすると、すぐに限界に当たります。こうしたモデルは推論時に基本的にすべてのパラメータ計算へ関与するため、VRAM と帯域の負荷が一気に上がるからです。

しかし MoE モデルは違います。総パラメータ数は大きくても、1 回の推論で実際に有効化される専門家パラメータはその一部だけです。35B 級モデルを例にすると、総量は大きくても、1 回の推論で実際に計算に参加するパラメータはずっと少ないため、実際の VRAM 要求は想像ほど極端ではありません。

だからこそ、16GB GPU にもまだ工夫の余地があります。

02 実測上のポイント: 35BのMoEモデルはかなり速く動く

代表的な例として挙げられるのが、Qwen 3.5 35B A3B のような MoE モデルの量子化版です。16GB GPU と LM Studio の組み合わせで設定を調整すると、Q6 量子化で 30 tokens/s を超える水準に届き、Q4 ではさらに高い速度が出ることもあります。

この結果に価値があるのは、単に「動く」からではありません。速度がすでに「明らかに実用的」と言える水準に入っているからです。

比較として、同じくらい大きな規模でも MoE ではないモデルを 16GB GPU で無理に回そうとすると、VRAM あふれや大幅な速度低下が起こりがちです。つまり結果を決めるのは、総パラメータ数だけではなく、推論時にそのパラメータをどう使うかです。

03 LM Studioでは、見るべきパラメータが1つではない

16GB GPU でこうしたモデルを安定して動かすには、運任せではなく、2 つのパラメータを正しく調整する必要があります。

GPU Offload
一部の expert layer を CPU メモリへ強制的に載せるための設定

前者は比較的わかりやすく、GPU Offload は基本的に可能な限り高く設定し、GPU 側での計算を優先させます。

後者こそが重要です。これは「VRAM があふれてからシステムメモリを借りる」という昔ながらのやり方ではなく、あらかじめ一部の expert layer を CPU メモリへ逃がして VRAM 使用量を下げる方法です。MoE モデルはそもそも毎回すべての expert を有効化するわけではないため、専門家層の一部をメモリ側へ回しても、推論速度への影響は多くの人が思うほど大きくありません。

実際には、まず一定の範囲から試し、手元のマシンに合わせて少しずつ調整するのが安全です。

関連値を 20〜35 あたりから始める
VRAM 使用量とメモリ圧力を見ながら微調整する

本質的には、システムメモリを使って VRAM の余裕を買う方法です。

04 128Kコンテキストでも動き、さらに縮めればVRAMをもっと減らせる

もうひとつ面白いのは、コンテキスト長を 128K に引き上げた状態でも、35B 級 MoE モデルが比較的高い速度を保てることです。

ここからわかるのは、16GB GPU の限界は思っているほど固定的ではない、ということです。特に LM Studio のようなローカル推論ツールでは、「動くか動かないか」の二択ではなく、実際には次のようなトレードオフになります。

より多くのシステムメモリを使ってでも VRAM を節約するか
コンテキスト長を短くするか
量子化ごとの能力差を受け入れるか

もしコンテキストを 128K から 64K や 32K に縮めれば、VRAM 圧力はさらに下げられます。つまり、35B 級の MoE モデルの中には、より少ない VRAM の GPU でも何とか動くものが出てくる可能性があります。ただし、その分だけ速度とメモリ負荷のバランスは再調整が必要になります。

05 この方法の代償: RAMと仮想メモリへの要求が高くなる

もちろん、この方法はタダで性能が増えるわけではありません。

注意すべきなのは、VRAM 圧力をさらに圧縮すると、システム RAM の使用量が目立って増え、仮想メモリの負荷も上がることです。つまり、コストが消えるのではなく、GPU から RAM とディスクスワップへ圧力が移るだけです。

そのため、実際に試すなら、先にいくつか確認しておくべきです。

システム RAM が十分あるか
仮想メモリを十分に確保しているか
バックグラウンドで重いソフトがたくさん動いていないか

こうした条件が揃っていないと、「35B が速く動く」どころか、マシン全体が遅くなる可能性があります。

06 量子化は攻めればいいというものでもない

ここにはもうひとつ実務的な判断があります。より低ビットの量子化はたしかに VRAM をさらに節約しやすいですが、それが最善とは限りません。

実際には、Q4 のほうが速度は高くても、元の能力が落ちやすいモデルもあります。その点、Q6 は速度と能力保持のバランスが取りやすいことが多いです。結局は、自分がどちらを優先するかです。

とにかく速く、VRAM に収めたいのか
それともモデル本来の能力をより多く残したいのか

この優先順位によって、選ぶ量子化は変わってきます。

07 試す価値があるモデルの考え方

この観点で見ると、やるべきことは「とにかく大きいモデルを追うこと」ではなく、この戦略に合うモデルを先に探すことです。

MoE アーキテクチャのモデル
LM Studio での対応が良く、量子化版が揃っているモデル
長いコンテキストや instruction following に明確な強みがあるモデル

そして、この考え方は 1 つの 35B MoE モデルだけに限りません。長文脈記憶に強い実験的モデル、命令追従が優秀なモデル、あるいは軽量量子化で速度が出るモデルなどにも自然に広げられます。

つまり重要なのは、まず「メモリで VRAM を補う」戦略に合うアーキテクチャを見つけ、そのうえで調整に入ることです。最初に総パラメータ数だけ見て判断するべきではありません。

08 まとめ

もし手元に 16GB GPU があり、ローカル LLM はせいぜい 12B〜14B までだと思っていたなら、その前提は少し更新してよさそうです。

より正確に言えば、次のようになります。

16GB GPU でも大きめのモデルが完全に無理なわけではない
dense モデルと MoE モデルは分けて考える必要がある
LM Studio の GPU Offload と expert layer の CPU メモリ移動は、VRAM 使用量を大きく変えられる
実際には、より大きいモデル規模とより高い実用速度を得るために、より高いメモリ圧力を受け入れている

この方法がすべてのマシンに向くわけではありませんが、少なくともひとつ確かなことがあります。ローカル LLM 運用では、VRAM 上限だけが唯一の制約ではなく、モデルアーキテクチャと推論設定も同じくらい重要です。

Ollama マルチ GPU メモ：VRAM の合算、GPU 選択、よくある誤解

Sun, 19 Apr 2026 00:18:00 +0800

Ollama でローカル推論を試していると、よく次のような疑問が出てきます。今 1 枚 GPU があり、マザーボードに空き PCIe スロットがある場合、GPU を追加すると Ollama に効果があるのか。複数 GPU は同じ型番でなければならないのか。VRAM は合算できるのか。学習フレームワークのようにマルチ GPU で推論速度が大きく上がるのか。

この記事では、Ollama のマルチ GPU 動作を整理します。先に結論を書くと次の通りです。

Ollama は複数 GPU をサポートします。
複数 GPU の主な価値は、より大きなモデルを合計 VRAM に載せやすくすることであり、token/s が線形に伸びることではありません。
デフォルトでは、モデルが 1 枚の GPU に完全に収まる場合、Ollama は単一 GPU に載せる傾向があります。
モデルが 1 枚の GPU に収まらない場合、Ollama は利用可能な GPU にモデルを分散できます。
異なる型番の GPU も Ollama から見える場合がありますが、性能や配置が理想的とは限りません。
SLI / NVLink は必須ではありません。
Ollama が使う GPU を制限したい場合は、CUDA_VISIBLE_DEVICES、ROCR_VISIBLE_DEVICES、GGML_VK_VISIBLE_DEVICES を使います。

公式の挙動：まず単一 GPU、入らなければ複数 GPU

Ollama FAQ では、マルチ GPU のロードロジックが比較的明確に説明されています。新しいモデルをロードするとき、Ollama は必要な VRAM を見積もり、現在利用可能な VRAM と比較します。モデルがどれか 1 枚の GPU に完全に収まる場合、その GPU にロードします。1 枚に収まらない場合、利用可能なすべての GPU に分散されます。

この戦略の理由は性能です。単一 GPU に載せることで、推論時の PCIe バス越しのデータ転送を減らせるため、通常はそのほうが速くなります。

そのため、Ollama のマルチ GPU を「GPU が増えれば自動で数倍速くなる」と考えないほうがよいです。より正確には次のように理解できます。

小さいモデルが単一 GPU に入る：通常は単一 GPU で動く。
大きいモデルが単一 GPU に入らない：複数 GPU に分層ロードされる。
それでも VRAM が足りない：一部がシステムメモリに落ち、速度が大きく低下する。

モデルがどこにロードされたかは、次のコマンドで確認できます。

`1`	`ollama ps`

出力の PROCESSOR には、たとえば次のように表示されます。

1
2
3

100% GPU
48%/52% CPU/GPU
100% CPU

48%/52% CPU/GPU と表示される場合、一部がすでにシステムメモリにあります。この場合、CPU/RAM に頼り続けるより、GPU を増やすか、より大容量 VRAM の GPU に替えるほうが有効なことが多いです。

マルチ GPU は単純な計算力の合算ではない

ローカル LLM 推論は、ゲームにおける SLI とは別物です。Ollama のマルチ GPU では、モデルの異なる層やテンソルを別々のデバイスに置く形が一般的です。これにより複数 GPU の VRAM を使って大きなモデルを載せられますが、推論中にはデバイス間でデータを渡す必要が出る場合があります。

したがって、マルチ GPU の利点は通常 2 種類です。

VRAM 面の利点：大きなモデルを載せやすくなり、CPU/RAM への退避を避けやすくなる。
性能面の利点：単一 GPU に入らない、または CPU との混在が深刻な場合に目立ちやすい。

8B や 14B のモデルが 1 枚の RTX 3090 に完全に入る場合、それを 2 枚の GPU に無理に分割しても速くなるとは限りません。むしろ GPU 間転送で遅くなる可能性があります。Ollama のデフォルトの「入るなら単一 GPU」戦略は、この不要な PCIe コストを避けるためのものです。

SLI や NVLink は不要

Ollama のマルチ GPU は SLI に依存しません。通常の PCIe GPU が複数あり、ドライバと Ollama が認識できれば、スケジューリング対象になります。

NVLink やより高い PCIe 帯域は、一部の GPU 間分散シナリオで役立つ可能性がありますが、前提条件ではありません。中古 GPU サーバーやワークステーションでも、普通の PCIe マルチ GPU で動かせます。

本当に注意すべきなのは PCIe 帯域です。x1、x4、x8、x16 の差は、モデルを VRAM にロードする速度に影響します。大きなモデルを頻繁に切り替える場合、PCIe リンクはボトルネックになりやすくなります。モデルのロード後、生成時の影響は通常小さくなりますが、GPU 間分散には追加コストが残る可能性があります。

無難な考え方は次の通りです。

可能なら x16 / x8 を使い、マイニング用 x1 riser は避ける。
大きなモデルを頻繁に切り替えるなら、PCIe 帯域はより重要。
モデルを長時間 VRAM に常駐させる場合、PCIe 帯域の影響は相対的に小さくなる。
マルチ GPU 機では、マザーボードの PCIe トポロジーと CPU 直結レーンを確認する。

Ollama が使う NVIDIA GPU を制限する

NVIDIA のマルチ GPU 環境では、CUDA_VISIBLE_DEVICES で Ollama から見える GPU を制御します。

一時的に実行する場合：

`1`	`CUDA_VISIBLE_DEVICES=0,1 ollama serve`

2 枚目の GPU だけを使う場合：

`1`	`CUDA_VISIBLE_DEVICES=1 ollama serve`

NVIDIA GPU を使わせない場合は、無効な ID を指定できます。

`1`	`CUDA_VISIBLE_DEVICES=-1 ollama serve`

公式ドキュメントでは、数値 ID の順序は変わる可能性があるため、GPU UUID のほうが信頼できるとされています。まず UUID を確認します。

`1`	`nvidia-smi -L`

出力例：

1
2

GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
GPU 1: NVIDIA GeForce RTX 3070 (UUID: GPU-yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy)

その後、UUID を指定します。

`1`	`CUDA_VISIBLE_DEVICES=GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ollama serve`

Linux の systemd サービスとして Ollama をインストールしている場合は、サービス環境変数に書きます。

`1`	`sudo systemctl edit ollama.service`

追加内容：

1
2

[Service]
Environment="CUDA_VISIBLE_DEVICES=0,1"

再読み込みして再起動します。

1
2

sudo systemctl daemon-reload
sudo systemctl restart ollama

AMD と Vulkan の選択変数

AMD ROCm 環境では、ROCR_VISIBLE_DEVICES で見える GPU を制御します。

`1`	`ROCR_VISIBLE_DEVICES=0,1 ollama serve`

ROCm GPU を使わせない場合も、無効な ID を指定できます。

`1`	`ROCR_VISIBLE_DEVICES=-1 ollama serve`

Ollama の GPU ドキュメントでは、実験的な Vulkan サポートも触れられています。Vulkan GPU を選ぶには GGML_VK_VISIBLE_DEVICES を使います。

`1`	`OLLAMA_VULKAN=1 GGML_VK_VISIBLE_DEVICES=0 ollama serve`

Vulkan デバイスで問題が出る場合は無効化できます。

`1`	`GGML_VK_VISIBLE_DEVICES=-1 ollama serve`

AMD のマルチ GPU は、NVIDIA よりもドライバ、ROCm バージョン、GFX バージョンの互換性問題に遭遇しやすいです。公式ドキュメントでも Linux の ROCm ドライバ要件や HSA_OVERRIDE_GFX_VERSION などの互換性設定が説明されています。異なる世代の AMD GPU を混在させる場合は、まず各カードが単独で動くことを確認してからマルチ GPU を試すのが安全です。

Docker で複数 GPU を見せる

Docker で Ollama を動かす場合、NVIDIA 環境では通常 nvidia-container-toolkit を入れ、--gpus でデバイスを公開します。

すべての GPU を公開：

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

指定した GPU だけを公開：

docker run -d \
  --gpus '"device=0,1"' \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

環境変数と組み合わせることもできます。

docker run -d \
  --gpus=all \
  -e CUDA_VISIBLE_DEVICES=0,1 \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

コンテナ内で nvidia-smi が GPU を見られない場合、Ollama も GPU を使えません。まず Docker の GPU passthrough を確認し、その後 Ollama を確認します。

`OLLAMA_SCHED_SPREAD` とは

マルチ GPU 設定では、OLLAMA_SCHED_SPREAD=1 や OLLAMA_SCHED_SPREAD=true を見かけることがあります。これは Ollama のスケジューラに関係する設定で、モデルやリクエストを複数 GPU により分散させたい場面で使われることがあります。

設定例：

`1`	`OLLAMA_SCHED_SPREAD=1 ollama serve`

systemd の場合：

1
2

[Service]
Environment="OLLAMA_SCHED_SPREAD=true"

ただし万能ではありません。有効にしても token/s が線形に増えるわけではなく、複数モデルの同時ロード、VRAM 見積もり、コンテキスト長、KV cache の増加によって OOM になることもあります。公式 FAQ の基本方針は変わりません。1 枚の GPU にモデルが完全に入るなら単一 GPU のほうが効率的なことが多く、1 枚に入らないときに複数 GPU 分散が有効になります。

そのため、OLLAMA_SCHED_SPREAD はマルチ GPU 必須設定ではなく、高度なスケジューリング実験項目として扱うのがよいです。まずデフォルト挙動を理解し、ollama ps、ログ、nvidia-smi の結果を見ながら調整します。

複数 GPU が本当に使われているか確認する

よく使う確認コマンド：

`1`	`ollama ps`

`1`	`watch -n 0.5 nvidia-smi`

Ollama サービスログ：

`1`	`journalctl -u ollama -f`

Docker の場合：

`1`	`docker logs -f ollama`

確認したい点：

Ollama が対応 GPU を検出しているか。
モデルが 100% GPU または CPU/GPU 混在で表示されているか。
各 GPU に VRAM 使用量があるか。
モデルロード時に複数 GPU の VRAM が増えるか。
生成時の token/s が CPU/RAM 退避より明らかに改善しているか。
OOM やモデルのアンロードが頻発していないか。

GPU 使用率だけを見ると誤解しやすいです。LLM 推論では、特にマルチ GPU、低 batch、小さいコンテキスト、遅い CPU、遅い PCIe 環境では、GPU 使用率が常に高いとは限りません。

よくある誤解

誤解 1：12GB GPU 2 枚は 24GB GPU 1 枚と同じ

完全には同じではありません。複数 GPU にモデルを配置できますが、デバイス間アクセスには追加コストがあります。「入らない」問題は解決できますが、単一大容量 VRAM GPU と同じ速度や安定性になるとは限りません。

誤解 2：異なる型番の GPU は混在できない

必ずしもそうではありません。ドライバ、計算能力、ランタイムライブラリが対応していれば、Ollama は複数 GPU を認識できます。ただし混在構成では、遅いカード、小さい VRAM、PCIe トポロジーに制約されやすくなります。最も予測しやすいのは、同じ型番、同じ VRAM、同世代でサポートの良いドライバ構成です。

誤解 3：マルチ GPU は必ず単一 GPU より速い

必ずしも速くありません。モデルが 1 枚の高速 GPU に完全に入る場合、単一 GPU のほうが速いことがあります。マルチ GPU は主に、大きなモデル、長いコンテキスト、単一 GPU の VRAM 不足に向いています。

誤解 4：NVLink / SLI が必須

不要です。普通の PCIe マルチ GPU システムでも Ollama は利用できます。NVLink は前提条件ではありません。

誤解 5：GPU を追加したらサービス再起動は不要

必ずしもそうではありません。Linux systemd サービス、Windows のバックグラウンドアプリ、Docker コンテナは、デバイスや環境変数を再検出するために再起動が必要な場合があります。

GPU 選びの目安

Ollama のローカル推論では、おおよその優先順位は次の通りです。

単一 GPU の VRAM が大きいほど扱いやすい。
同一 GPU 複数枚は、混在 GPU よりトラブルシュートしやすい。
PCIe レーンが十分あるほど、大きなモデルのロードが快適。
古い GPU は CUDA compute capability または ROCm 対応を先に確認する。
マルチ GPU では電源、冷却、筐体エアフローを事前に計算する。

中古予算重視の場合：

RTX 3090 2 枚は、今でもよく使われる大容量 VRAM 構成です。
P40 / M40 のような古い Tesla は VRAM が大きい一方、消費電力、冷却、ドライバ、性能のトレードオフがあります。
RTX 4070 / 4070 Ti などは効率が良いですが、単一 GPU の VRAM 容量が制約になりやすいです。
古い 8GB GPU を複数枚使う構成は実験としては面白いですが、大きなモデルを長期運用する用途にはあまり向きません。

まとめ

Ollama のマルチ GPU は、「性能加速より先に VRAM 拡張」と理解すると分かりやすいです。モデルが 1 枚の GPU に完全に入るなら、デフォルトの単一 GPU 経路のほうが速いことが多いです。1 枚に入らない場合、複数 GPU に分散することで CPU/RAM への大きな退避を避け、大きなモデルを実用的にできます。

実際の設定では、まず ollama ps でモデルのロード先を確認し、nvidia-smi や ROCm ツールで VRAM 使用量を観察します。GPU を制限する場合、NVIDIA は CUDA_VISIBLE_DEVICES、AMD ROCm は ROCR_VISIBLE_DEVICES、Vulkan は GGML_VK_VISIBLE_DEVICES を使います。Docker で動かす場合は、まずコンテナから GPU が見えているか確認します。

マルチ GPU は魔法ではありません。より大きなモデルを載せる助けにはなりますが、線形加速は保証されません。安定して使うなら、大容量 VRAM の単一 GPU、または同一型番のマルチ GPU を優先し、ドライバ、PCIe、電源、冷却、モデル量子化をまとめて考えるのが現実的です。

参考連結

Ollama FAQ：How does Ollama load models on multiple GPUs?：https://github.com/ollama/ollama/blob/main/docs/faq.mdx
Ollama GPU ドキュメント：Hardware support / GPU Selection：https://github.com/ollama/ollama/blob/main/docs/gpu.mdx
Ollama Docker Hub：https://hub.docker.com/r/ollama/ollama
NVIDIA Container Toolkit：https://github.com/NVIDIA/nvidia-container-toolkit

llama-quantize の使用方法: GGUF モデル量子化の概要

Sun, 12 Apr 2026 09:42:36 +0800

llama-quantize は、llama.cpp の量子化ツールで、高精度 GGUF モデルをより小さい量子化バージョンに変換するために使用されます。

最も一般的な用途は、F32、BF16、FP16 などの高精度モデルを、ローカル操作に適した Q4_K_M、Q5_K_M、Q8_0 などの形式に変換することです。量子化後、モデルのサイズは大幅に小さくなり、通常は推論が速くなりますが、精度はある程度低下します。

基本的な使い方

一般的なプロセスでは、通常、最初に元のモデルを準備し、次にそれを GGUF に変換し、最後に定量化を実行します。

# install Python dependencies
python3 -m pip install -r requirements.txt

# convert the model to ggml FP16 format
python3 convert_hf_to_gguf.py ./models/mymodel/

# quantize the model to 4-bits (using Q4_K_M method)
./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M

量子化が完了したら、llama-cli を直接使用して新しい GGUF ファイルをロードできます。

1
2

# start inference on a gguf model
./llama-cli -m ./models/mymodel/ggml-model-Q4_K_M.gguf -cnv -p "You are a helpful assistant"

共通パラメータ

--allow-requantize: すでに定量化されたモデルの再定量化が可能ですが、品質が大幅に低下する可能性があるため、通常は推奨されません。
--leave-output-tensor: 量子化せずに出力レイヤーを保持します。ボリュームは大きくなりますが、場合によっては品質が向上する場合があります。
--pure: 混合量子化をオフにして、より多くのテンソルが同じ量子化タイプを使用できるようにします。
--imatrix: 重要度マトリックスを使用して量子化効果を最適化します。通常は優先順位を付ける価値があります。
--keep-split: 単一ファイルにマージするのではなく、入力モデルのシャード構造を保持します。

単に始めたい場合は、最も現実的な出発点は次のとおりです。

`1`	`./llama-quantize ./models/mymodel/ggml-model-f16.gguf ./models/mymodel/ggml-model-Q4_K_M.gguf Q4_K_M`

定量化の選び方

まず、さまざまな定量化レベルを「体積、速度、質量の間の交換」として理解することができます。

Q8_0: サイズは大きくなりますが、一般に品質がより安定しています。
Q6_K / Q5_K_M: 共通のバランス型オプション
Q4_K_M: 非常に一般的なデフォルトファイル。通常、音量とエフェクトは比較的バランスが取れています。
Q3 / Q2: リソースが非常に不足しているが、品質の低下がより明らかになるシナリオに適しています。

与えられたデータ例から判断すると、通常、量子化レベルが低いほど、モデルは小さくなります。実際の推論では、精度が高いほど必ずしも高速であるとは限りません。そのため、通常、選択の焦点は「大きいほど良い」ではなく、「ハードウェア上で十分に安定しており、十分に経済的で、効果が許容範囲である」ことに重点を置きます。

実践的なアドバイス

Q4_K_M または Q5_K_M から優先順位を付ける
品質がより重要な場合は、Q6_K または Q8_0 にアップグレードしてください。
マシンリソースが不足している場合は、Q3 または Q2 を試してください。
異なる量子化バージョンを比較するには、常に同じバッチのテスト問題を使用することが最善です

一文の要約: llama-quantize の中心的な価値は、単にモデルを小さくすることではなく、GGUF モデルをローカルデバイス上で実行しやすくすることです。

llama.cpp Hugging Face から GGUF モデルを取得する方法

Sun, 12 Apr 2026 09:31:38 +0800

llama.cpp は、Hugging Face の GGUF モデルで直接使用できます。最初にファイルを手動でローカルにダウンロードする必要はありません。

モデルウェアハウス自体が GGUF ファイルを提供している場合は、次のようにコマンドラインで -hf パラメーターを直接使用できます。

`1`	`llama-cli -hf ggml-org/gemma-3-1b-it-GGUF`

デフォルトでは、このパラメータは Hugging Face からモデルをダウンロードします。
Hugging Face API と互換性のある別のモデルホスティングサービスを使用している場合は、環境変数 MODEL_ENDPOINT を通じてダウンロードエンドポイントを切り替えることもできます。

llama.cpp は、GGUF 形式のみを直接使用できることに注意してください。
他の形式でモデルファイルを取得した場合は、まずウェアハウス内の convert_*.py スクリプトを使用して、それを GGUF に変換する必要があります。

Hugging Face は、llama.cpp に関連するいくつかのオンラインツールも提供します。一般的な用途には次のようなものがあります。

モデルを GGUF に変換します
モデルを定量化し、サイズを縮小する
LoRA アダプターを変換する
GGUF メタデータをオンラインで編集する
llama.cpp 推論サービスを直接ホストする

最も実用的な結論だけを覚えておきたい場合は、まず GGUF をすでに提供しているモデルウェアハウスを探し、次に llama-cli -hf <user>/<model> を直接使用します。これが通常は最も簡単な方法です。

Gemma-4-31B ではどういう意味ですか?

Sat, 11 Apr 2026 20:45:34 +0800

gemma-4-31B-it という名前の it は、「命令微調整」バージョンである Instruction Tuned の略称です。

ほとんどの人にとって、これは次のように理解できます。このモデルは、チャット、Q&A、コードの作成、および明示的なタスクの実行により適しています。

`it`とは

モデルには通常、次の 2 つの一般的なバージョンがあります。

基本/事前トレーニング済み: 元のテキスト予測子に近い基本モデル。
it: コマンドを微調整した後、「何をしてもらえますか?」などの入力をよりよく理解できるようになりました。

「これを翻訳してください」または「この Python コードを書いてください」と入力した場合、通常、it バージョンの方が安定しており、より会話的です。

`31B`とは

31B は、このモデルに約 310 億のパラメーターがあることを意味します。

一般的に言えば:

パラメーターの数が増えるほど、モデルの機能と知識の範囲が強化される傾向があります。
同時に、ビデオメモリやメモリの要件も高くなります。

そのため、31B は比較的大規模なモデルとなり、動作閾値が高くなります。

`Gemma-4` とはどういう意味ですか?

Gemma-4 はモデルシリーズと世代を表します。

Gemma: Google のオープンソースモデルシリーズ
4: シリーズの第 4 世代バージョン

選び方

チャット、Q&A、翻訳、またはコードの作成が目的の場合は、通常、-it を備えたバージョンが推奨されます。

下位レベルの調査、微調整、またはカスタムトレーニングタスクを実行している場合は、基本バージョンをチェックアウトする可能性が高くなります。

一文の要約

gemma-4-31B-it は、Gemma 4 シリーズ、310 億のパラメーター、ダイアログおよびコマンドタスクに適したバージョンとして直接理解できます。

Llama の GGUF モデルを選択するときの量子化の選択方法: Q8 から Q2 までの実践的な提案

Sat, 11 Apr 2026 20:07:29 +0800

Hugging Face で Llama の GGUF モデルを選択する場合、まず量子化レベルを「解像度」として理解できます。解像度が低いほど使用する VRAM/RAM は少なくなりますが、品質は徐々に低下します。

まずは32、16、Qシリーズについて理解しましょう

32: 最高品質のオリジナルの非圧縮バージョンとして理解できますが、ハードウェア要件は非常に高くなります。
16: 元の品質に近く、サイズは 32 の約半分で、より実用的です。
Q8: ここから量子化バージョンが来ます。通常は Q8_0 または Q8 と書かれます。
Q6、Q5、Q4、Q3、Q2: 数値が小さいほど、リソースの使用量が低くなり、目に見える品質の低下が発生しやすくなります。

`K_M` / `K_S`とは

K_M および K_S は、ハイブリッド量子化戦略を表します。

ほとんどの重みは現在の量子化レベルを使用します
一部の主要部品はより高い精度を維持

したがって、同じレベルでは、Qx_K_M または Qx_K_S は、通常、純粋な Qx よりもわずかに優れています。

実用的な選択の提案

十分なハードウェア: 優先順位 Q8。
ビデオメモリまたはメモリが不足しています: Q6 / Q5 / Q4 まで段階的にダウンします。
下限の提案: Q4 を下回らないようにし、Q4_K_M を優先します。
Q3 以下: 品質の低下がますます顕著になります。

品質の勾配 (高から低)

32
16

– この点を超えると、品質は同じですが、ハードウェア要件が非常に高くなります –

Q8
Q6_K_M
Q6_K_S
Q6
Q5_K_M
Q5_K_S
Q5

– これが古典的なスイートスポットです –

Q4_K_M
Q4_K_S
Q4

– この点を下回ると、品質の低下が顕著になります –

Q3_K_M
Q3_K_S
Q3
Q2_K_M
Q2_K_S
Q2

単純な結論が必要な場合: ほとんどのシナリオでは、Q8 または Q6_K_M から開始するだけでは十分ではなく、通常は Q5 または Q4_K_M にダウングレードする方が安全です。

Windows LAN Access Ollama API セットアップガイド

Sat, 11 Apr 2026 16:43:52 +0800

LAN 内の他のデバイスがローカル Ollama API にアクセスできるようにする場合は、次のように設定できます。

リスニングポートを設定する

まず、Ollama リスニングアドレスをすべてのネットワークカードに変更します。

OLLAMA_HOST=0.0.0.0:11434

ファイアウォールを開く

詳細なファイアウォール設定を開いた後、新しい受信ルールを作成し、ターゲットポート (8080 など) を許可します。

Win + S を押して、「Windows Defender ファイアウォール」を検索して開きます。
「詳細設定」をクリックします。
「受信ルール」→「新しいルール…」を選択します。
ルールの種類として「ポート」を選択し、「次へ」をクリックします。
プロトコル（通常はTCP）を選択し、「特定のローカルポート」に開放するポート番号（例：8080）を入力し、「次へ」をクリックします。
「接続を許可する」を選択し、「次へ」をクリックします。
「プロファイル」の「ドメイン」「プライベート」「パブリック」にチェックを入れて「次へ」をクリックします。
ルールに名前を付けて (OpenPort8080 など)、「完了」をクリックします。

ラン・オラマ

オラマランモデル

API経由でモデルにアクセス

curl http://192.168.x.xxx:11434/api/generate -d '{
  "model": "gemma4",
  "prompt": "这个是什么模型?"
}'

Gemma 4 ローカル通話ガイド: ワンクリック実行から開発統合まで

Fri, 10 Apr 2026 22:54:17 +0800

Gemma 4 (2026 年に Google がリリースした新世代のオープンソースモデル) をローカルで呼び出したい場合は、ニーズに応じてこれら 4 種類のソリューションから選択できます。

1) 最も早く始める: Ollama (推奨)

これは最も障壁の低いアプローチであり、簡単なテスト、日常会話、ローカル API 呼び出しに適しています。

`1`	`ollama run gemma4`

特徴：

Win/Mac/Linux で利用可能
ハードウェアアクセラレーションを自動的に処理します
OpenAIスタイルに対応したネイティブAPIを提供

2) グラフィカルインターフェイス: LM Studio / Unsloth Studio

デスクトップ GUI (ChatGPT に似たもの) に慣れている場合は、これら 2 種類のツールの方が便利です。

LM Studio:Hugging Face で Gemma 4 量子化モデル (4 ビット、8 ビットなど) を直接検索してダウンロードし、リソースの使用状況を表示できます。
Unsloth Studio: 推論に加えて、低メモリ微調整もサポートしています。 6GB～8GBのビデオメモリを搭載したマシンにさらに優しい。

3) 低構成と究極の制御: llama.cpp

古いマシン、純粋な CPU シナリオ、または推論パラメーターを詳細に制御したいユーザーに適しています。

量子化バージョンで .gguf モデルファイルを使用すると、より低いハードウェアしきい値で Gemma 4 を実行できます。

4) 開発統合: Transformers/vLLM

Gemma 4 を独自のアプリケーションに統合したい場合:

Transformers: Python プロジェクトにモデルを直接ロードするのに適しています
vLLM: 高性能 GPU シナリオおよび高スループット推論サービスに適しています

クイック選択

需求	推荐工具	硬件门槛
我只想马上跑起来	Ollama	低（自动适配）
我更喜欢图形界面	LM Studio	中
显存很紧张（6GB-8GB）	Unsloth / llama.cpp	低
我要做本地 AI 应用开发	Ollama / Transformers / vLLM	中到高
我要做微调训练	Unsloth Studio	中到高

モデルの推奨サイズ

Gemma 4 はさまざまなサイズで利用できます (E2B、E4B、31B など)。

通常のオフィスのラップトップの場合は、定量化された E2B/E4B が推奨されます。
ビデオメモリに余裕がある場合は、より大きなバージョンを試してください。

Ollama クラウドモデルとは何か、そしてその使用方法

Thu, 09 Apr 2026 18:42:32 +0800

普段 Ollama を使用してローカルモデルを実行している場合は、クラウドモデルを簡単に理解できるはずです。

主要な相違点は 1 つだけです。
ローカルモデルはユーザーのコンピューター上で推論され、クラウドモデルは Ollama のクラウド上で推論され、結果が返されます。

クラウドモデルとは何ですか

Ollama クラウドモデルは、Ollama の呼び出し方法を保持しますが、コンピューティングの場所をローカルからクラウドに変更します。

これを行うことの利点は次のとおりです。

ローカルハードウェアへの負担が軽減される
ローカルマシンでは実行できない大規模なモデルを使いやすくする
使い慣れた Ollama ワークフローを引き続き使用できます

現地モデルとの違い

对比项	本地模型	云模型
运行位置	本机	云端
硬件要求	高	低
延迟	更低	受网络影响
隐私性	更强	请求会发送到云端

プライバシー、低遅延、オフライン使用を重視する場合は、ローカルモデルの方が適しています。
ローカルのハードウェアでは十分ではないが、より大規模なモデルを体験したい場合は、クラウドモデルの方が便利です。

クラウドモデルを特定する方法

現在の Ollama クラウドモデルには通常、サフィックス -cloud が付いています。次に例を示します。

`1`	`gpt-oss:120b-cloud`

利用可能なモデルのリストは変更される可能性があります。Ollamaの公式ページを参照してください。

使用方法

まずログインしてください:

`1`	`ollama signin`

ログイン後、クラウドモデルを直接実行します。

`1`	`ollama run gpt-oss:120b-cloud`

コードから呼び出している場合は、API キーを構成することもできます。

`1`	`export OLLAMA_API_KEY=your_api_key`

Python の例:

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

messages = [
    {"role": "user", "content": "为什么天空是蓝色的？"}
]

for part in client.chat("gpt-oss:120b-cloud", messages=messages, stream=True):
    print(part["message"]["content"], end="", flush=True)

まとめ

Ollama クラウドモデルは、次の一文で理解できます。

コマンドは基本的に同じままですが、モデルはローカルで実行されなくなります。

コンピューターで大規模なモデルを実行できないが、引き続き Ollama を使用してモデルを呼び出したい場合、クラウドモデルは非常に簡単なソリューションです。

Hugging Face から GGUF モデルをダウンロードし、Ollama にインポートします。

Thu, 09 Apr 2026 11:00:07 +0800

モデルの公式 Ollama ライブラリに既製バージョンがない場合、または Hugging Face で特定の GGUF ファイルを使用したい場合は、手動でダウンロードして Ollama にインポートできます。

ステップ 1: Hugging Face から GGUF ファイルをダウンロードする

まず、Hugging Face で対象モデルに対応する GGUF ファイルを見つけます。次のような複数の量子化バージョンが表示されるのが一般的です。

Q4_K_M
Q5_K_M
Q8_0

どのバージョンを選択するかは、ビデオメモリ、メモリ、速度と品質の選択によって異なります。ダウンロード後、.gguf ファイルを固定ディレクトリに置き、後で Modelfile で直接参照します。

ステップ 2: モデルファイルを作成する

モデルファイルと同じディレクトリに新しい Modelfile を作成します。最も基本的な書き方は次のとおりです。

`1`	`FROM ./model.gguf`

ファイル名が異なる場合は、次のように実際のファイル名に変更します。

`1`	`FROM ./gemma-3-12b-it-q4_k_m.gguf`

最初に実行したいだけの場合は、通常、FROM 行で十分です。

ステップ 3: Ollama にインポートする

次に、以下を実行します。

`1`	`ollama create myModelName -f Modelfile`

myModelName は、Ollama で使用するローカルモデル名です。
-f Modelfile は、この構成ファイルからモデルを作成することを意味します

作成が成功すると、この GGUF ファイルは直接呼び出すことができるローカルモデルになります。

ステップ 4: モデルを実行する

作成後に直接実行します。

`1`	`ollama run myModelName`

以降の使い方は基本的にollama pullのモデルと同じです。

既存のモデルのモデルファイルを表示する方法

Modelfile の書き方がわからない場合は、既存のモデルの構成を直接表示できます。

`1`	`ollama show --modelfile llama3.2`

このコマンドは、参照に適した llama3.2 の Modelfile コンテンツを出力します。

FROMの書き方
テンプレートとシステムプロンプトはどのように構成されていますか?
パラメータの宣言方法

このルートを使用するのが適切なのはどのような場合ですか?

次のシナリオは、Hugging Face からの手動インポートに適しています。

必要なモデルは、公式 Ollama ライブラリではまだ利用できません。
特定の量子化バージョンを使用したい場合
GGUF ファイルを手動でダウンロードしました
モデルのパッケージ化方法をよりきめ細かく制御したい

公式ライブラリに既製のバージョンがある場合は、通常、pull を直接使用する方が簡単です。ただし、特定の量子化やカスタムパッケージングが必要な場合は、GGUF + Modelfile の方がより柔軟です。

共通の注意点

FROM の後のパスは、実際の .gguf ファイルの場所と一致している必要があります。
ファイル名にスペースや特殊文字が含まれている場合は、最初に簡単な名前に変更することをお勧めします。
GGUF の量子化バージョンが異なると、メモリと速度に大きな影響を与えます。インポートが成功しても、操作がスムーズに行われるとは限りません。
モデルがチャットモデルの場合、効果がより安定するように、後でその形式に応じてプロンプトテンプレートを調整する必要があります。

結論は

Hugging Face から GGUF ファイルをダウンロードして Ollama にインポートするのは複雑ではありません。モデルファイルを準備し、使用可能な最小限の Modelfile を書き込み、その後 ollama create を実行してサードパーティの GGUF モデルを Ollama に接続します。

Ollama ダウンロードモデルのプル速度が遅い場合のトラブルシューティングと解決策

Thu, 09 Apr 2026 10:42:39 +0800

ollama pull model_name:tag 一部の地域ではダウンロード速度が非常に遅くなり、プロセスが安定しません。

大きなモデルのダウンロード中に繰り返し中断が発生し、TLS handshake timeout または unexpected EOF のエラーメッセージが表示される場合は、おそらく registry.ollama.ai 自体だけでなく、その後にジャンプされる実際のダウンロードリンクに問題があると考えられます。

この記事では、シンプルかつ直接的なトラブルシューティングのアイデアを記録します。最初にモデルファイルの実際のダウンロードアドレスを取得し、次に最終的なトラフィックがどこに落ちるかを確認し、最後に主要なドメイン名に対してのみネットワークの最適化を実行します。

モデルファイルのダウンロードアドレスを取得する

次のプロジェクトを使用して、Ollama モデルに対応するマニフェストと BLOB のダウンロードアドレスを直接抽出できます。

https://github.com/Gholamrezadar/ollama-direct-downloader

gemma4:latest を例として、次のようなリンクを抽出できます。

マニフェストアドレス

`1`	`https://registry.ollama.ai/v2/library/gemma4/manifests/latest`

BLOB アドレス

https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:56380ca2ab89f1f68c283f4d50863c0bcab52ae3f1b9a88e4ab5617b176f71a3

すぐに確認したいだけの場合は、curl を直接使用してマニフェストと BLOB をダウンロードすることもできます。

curl -L "https://registry.ollama.ai/v2/library/gemma4/manifests/latest" -o "latest"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11" -o "sha256-f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a" -o "sha256-4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2" -o "sha256-7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2"

ジャンプ後の実際のダウンロードアドレス

wget を使用して BLOB の 1 つをダウンロードしてみてください。リクエストは registry.ollama.ai にとどまらず、引き続き Cloudflare R2 オブジェクトストレージアドレスにジャンプしていることがわかります。

wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
--2026-04-09 09:22:04--  https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
Resolving registry.ollama.ai (registry.ollama.ai)... 104.21.75.227, 172.67.182.229, 2606:4700:3034::ac43:b6e5, ...
Connecting to registry.ollama.ai (registry.ollama.ai)|104.21.75.227|:443... connected.
HTTP request sent, awaiting response... 307 Temporary Redirect
Location: https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?... [following]
--2026-04-09 09:22:05--  https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?...
Resolving dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com (dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com)... 172.64.66.1, 2606:4700:2ff9::1
Connecting to dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com|172.64.66.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9608338848 (8.9G) [application/octet-stream]

ログからいくつかの重要な情報を確認できます。

registry.ollama.ai が 307 Temporary Redirect を返しました
最終的なダウンロードアドレスは *.r2.cloudflarestorage.com になります。
大きなファイルの送信を実際に実行しているのは、実際にはその背後にあるオブジェクトストレージドメイン名です。

この手順は、プロキシまたは転送ルールが registry.ollama.ai のみをカバーし、*.r2.cloudflarestorage.com を処理しない場合、ダウンロードが依然として遅くなるか、繰り返し中断される可能性があることを意味するため、重要です。

ネットワーク設定を調整する

実際のダウンロードリンクを確認すると、トラブルシューティングの方向性がより明確になります。

プロキシ、オフロード、またはカスタム DNS を使用している場合は、最初に次のことを確認することをお勧めします。

registry.ollama.ai と *.r2.cloudflarestorage.com は同じ安定したルートをたどりましたか?
プロキシルールは前者のみをカバーし、後者は除外しますか?
現在のエクスポートは、数ギガバイトから数十ギガバイトまでの大きなファイルを継続的にダウンロードするのに適していますか?

この種の問題の鍵は、「公式サイトが開設できるかどうか」ではなく、「ジャンプ後のオブジェクトストレージリンクが安定し、長時間送信し続けられるかどうか」である。多くの場合、本当に最適化する必要があるのは、以前のレジストリドメイン名ではなく、Cloudflare R2 レイヤーです。

調整前と調整後の比較

以下は、実際に gemma4:31b-it-q8_0 をダウンロードした場合のパフォーマンスです。

調整前はダウンロード速度が遅く、途中でエラーが報告されていました。

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  38% ▕██████████████████████                                    ▏  12 GB/ 33 GB  1.2 MB/s   4h40m
Error: max retries exceeded: unexpected EOF

調整後、同じモデルを再度ダウンロードすると、速度と安定性が大幅に向上しました。

1
2
3

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  46% ▕████████████████████████████████████████████████████████████████▏ 15 GB/ 33 GB  8.5 MB/s  35m23s

これは、すべてのネットワーク環境で同じ結果が得られるという意味ではありませんが、少なくとも 1 つの点を示しています。ボトルネックは Ollama クライアント自体ではなく、実際の大きなファイルのダウンロードリンクにある可能性が高いということです。

Gemma 4 を実行している Raspberry Pi 5 の実際のテスト: 実行可能ですが、応答が遅い

Wed, 08 Apr 2026 18:42:00 +0800

極端な試み: Raspberry Pi 5（8GB RAM） で Gemma 4 を実行します。目標は、大規模なモデルバージョンではなく、E2B の最小バージョンです。

結論から始めましょう。実行して使用することはできますが、対話頻度の低いシナリオに適しており、リアルタイム要件の高い対話エクスペリエンスには適していません。

テスト環境

デバイス: Raspberry Pi 5 (4コアCPU、8GB RAM)
システム: Ubuntu サーバー (グラフィカルインターフェイスなし)
アクセス方法：SSH
モデルの実行方法: LM Studio CLI (コマンドラインモードのみ)
モデル：Gemma 4 E2B (約4.5GB)

ステップ 1: LM Studio CLI をインストールして起動する

LM Studio の CLI バージョンをインストールし、サービスを開始して、使用可能なコマンドを確認します。

これは純粋なコマンドライン環境であるため、このコマンドラインのみの展開方法は Raspberry Pi に非常に適しています。

ステップ 2: モデルのストレージを SSD に切り替える

SDカードの頻繁な読み書きを避けるため、モデルのダウンロードディレクトリを外付けSSDに変更しました。

SSD を Raspberry Pi 5 に接続する体験は、明らかに以前のモデルよりも実用的です。長期的なローカルモデルでは、最初に SSD を使用することをお勧めします。

ステップ 3: Gemma 4 E2B をダウンロードしてロードする

ダウンロードが完了すると、モデルをメモリに正常にロードできるようになります。

公式情報によると、Gemma 4 シリーズには次の機能があります。

エージェントシナリオのツール呼び出し機能 (関数呼び出し)
マルチモーダル機能 (画像/ビデオを含む。小型モデルには音声関連機能もある)
128K コンテキストウィンドウ
Apache 2.0 ライセンス (商用利用可能)

Raspberry Pi のハードウェア条件から判断すると、最初に試すには E2B レベルの方が適しています。

ステップ 4: API を開始して LAN アクセスを開く

モデルがロードされた後、まずローカルポートで API (4000) を開始し、HTTP リクエストを通じてモデルリストが返されることを確認します。

問題は、デフォルトではこのマシンのみを監視し、LAN 上の他のデバイスは直接アクセスできないことです。

起動パラメータでホストを直接設定できないため、ポート転送に socat を使用して、Raspberry Pi の外部ポート要求を LM Studio の内部ポートにブリッジし、LAN アクセスを実現しました。

結果はうまくいきました。同じ LAN 上の MacBook 上のモデルのリストを正常にリクエストして取得することができました。

ステップ 5: エディター (Zed) にアクセスします。

LM Studio のローカルサービスは OpenAI API フォームと互換性があるため、カスタム base_url をサポートするほとんどのツールに直接アクセスできます。

Raspberry Pi 上の Gemma 4 インスタンスを指す新しい LLM プロバイダーを Zed に追加したところ、エディターでのチャットテストに合格しました。

実際の使用感の判断

このパッケージは次の用途に適しています。

ローカルオートメーションスクリプト
同時実行性とリアルタイム要件が低い補助タスク
個人学習とエッジデバイスの実験

以下にはあまり適していません:

高頻度の対話型チャット
応答遅延の影響を受けやすい開発コラボレーションシナリオ

結論は

Gemma 4 (E2B) を Raspberry Pi 5 で実行することは実現可能で、予想よりもうまく機能します。

オフラインで実行し、ツールを入手し、軽度および中度のタスクを完了できるようにすることが目標である場合、このルートは試してみる価値があります。スムーズなリアルタイムインタラクションが目標の場合でも、より強力なハードウェアを入手することをお勧めします。

OpenClaw とローカル Gemma 4 のドッキング: 完全な構成ガイド

Wed, 08 Apr 2026 18:18:00 +0800

この記事では、OpenClaw をローカル Gemma 4 モデル (Ollama を通じて提供されるインターフェイス) に接続する方法を説明します。

ローカル展開が完了していない場合は、以下を参照してください。

如何在笔记本电脑上运行 Gemma 4：5 分钟本地部署指南

ステップ 1: Ollama API サービスを開始する

まず Ollama サービスを開始します。

`1`	`ollama serve`

次のコマンドを使用して、API が適切に動作しているかどうかを簡単にテストできます。

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "你好"
}'

モデル出力を返すことができる場合は、ローカル API が使用可能です。

ステップ 2: Ollama に接続するように OpenClaw を構成する

OpenClaw 構成ファイルのパスは通常次のとおりです。

`1`	`~/.openclaw/config.yaml`

config.yaml を編集し、ローカルモデルエントリを models に追加します。

models:
  # 你已有的模型配置...

  gemma4-local:
    provider: ollama
    base_url: http://localhost:11434
    model: gemma4:12b
    timeout: 120s

ステップ 3: デフォルトのモデルを設定する (オプション)

Gemma 4 をデフォルトで使用する場合は、以下を追加できます。

`1`	`default_model: gemma4-local`

ステップ 4: OpenClaw を再起動して確認する

OpenClaw を再起動します。

`1`	`openclaw restart`

モデルのリストを表示します。

`1`	`openclaw models list`

会話テストを開始します。

`1`	`openclaw chat --model gemma4-local "你好"`

ダイアログが正常に戻った場合、OpenClaw はローカル Gemma 4 に正常に接続されています。

一般的なトラブルシューティング

connection refused: まず、ollama serve が実行されているかどうかを確認します。
モデルが見つかりません: モデル名が ollama list (たとえば、gemma4:12b) と一致しているかどうかを確認します。
応答タイムアウト: timeout は適切に増やすことができ、小さいモデルを最初にテストする必要があります。

ラップトップで Gemma 4 を実行する方法: 5 分間のローカル導入ガイド

Wed, 08 Apr 2026 18:06:00 +0800

Gemma 4 をラップトップ上でローカルに実行したい場合、現時点では Ollama が最も手間のかからない方法の 1 つです。複雑な環境をいじらなくても、通常は 5 分程度で実行できます。

ステップ 1: Ollama をインストールする

https://ollama.com を開き、対応するシステムのインストールパッケージをダウンロードします。
システムごとにインストールを完了します。

macOS: Applications にドラッグします。
Windows: .exe インストーラーを実行します。
Linux: 公式 Web サイトで提供されているインストールスクリプトを使用します。

インストールすると、Ollama はバックグラウンドサービスとして実行されます。初期インストールを除き、毎日簡単なコマンドのみを使用できます。

ステップ 2: Gemma 4 モデルをダウンロードする

ターミナルを開いて次を実行します。

`1`	`ollama pull gemma4:4b`

マシンのパフォーマンスが高い場合は、12b または 27b に変更できます。ダウンロードが完了すると、モデルはローカルに保存されます。

ダウンロードしたモデルを表示します。

`1`	`ollama list`

ステップ 3: モデルを起動する

`1`	`ollama run gemma4:4b`

これにより、ターミナルで対話型セッションが開きます。質問を入力して Enter キーを押すだけです。セッションを終了するには、次のように入力します。

/bye

Web チャットインターフェイスを希望する場合は、Open WebUI とともに使用できます。 Ollama をブラウザ側 UI にラップできます。これは通常、Docker を通じて数分で構成できます。

ラップトップのパフォーマンス最適化に関する提案

Apple Silicon (M2/M3/M4): デフォルトでは金属が使用されており、通常、加速効果は非常に優れています。 12B も良い経験をしています。
NVIDIA グラフィックスカード: 互換性のある GPU が検出されると、CUDA が自動的に使用されます。事前にドライバーをアップデートすることをお勧めします。
CPU のみの推論: 実行できますが、大規模なモデルは大幅に遅くなります。ほとんどの CPU のみのシナリオでは、4B を優先することをお勧めします。
メモリを解放する: 大きなモデルをロードする前に、メモリを消費するアプリケーションを閉じるようにしてください。経験則として、10 億パラメータごとに約 0.5GB 到 1GB のメモリが必要です。

モデルの選び方

Gemma 4 1B: 軽量の Q&A、基本的な要約、および高速なクエリに適しています。複雑な推論能力には限界があります。
Gemma 4 4B: 速度と品質のバランスが取れており、ほとんどの日常タスク (書き込み支援、コード支援、データ要約) に適しています。
Gemma 4 12B: より長いコンテキストとより複雑なタスクに適しており、コーディングと推論のシナリオでより安定しています。
Gemma 4 27B: 需要の高いタスクに適しており、効果はクラウド大規模モデルに近いですが、ハードウェア要件は大幅に高くなります。

Android での Gemma 4 のインストールと実行: 開始するための完全なガイド

Wed, 08 Apr 2026 17:55:53 +0800

携帯電話で Gemma 4 をオフラインで体験したい場合は、この記事でインストールから実際の機能までを段階的に説明します。

ステップ 1: アプリを入手する

Google AI Edge Gallery は現在 Google Play では利用できないため、APK サイドローディング経由でインストールする必要があります。

Android デバイスで次のように入力します。

设置 -> 应用 -> 特殊应用权限 -> 安装未知应用

それから：

使用しているブラウザ (Chrome や Firefox など) を見つけて、[このソースからの許可] をオンにします。
モバイルブラウザで Google AI Edge Gallery の GitHub リリースページを開きます。

アドレス: https://github.com/google-ai-edge/gallery/releases

最新の .apk インストールパッケージをダウンロードします。
ダウンロードが完了したら、通知バーまたはファイルマネージャーでインストールパッケージをクリックし、プロンプトに従ってインストールを完了します。

ネットワークが正常な場合、この手順は通常、完了するまでに約 2 分かかります。

ステップ 2: 初めて開いて認証する

AI Edge Gallery を初めて開くと、アプリケーションはモデルファイルを保存するためのストレージアクセス許可を要求します。直接許可することをお勧めします。許可しない場合、アプリケーションはモデルをダウンロードまたはロードできません。

通常、ホームページには次の入り口が表示されます。

Ask Image: 画像理解タスク (画像の説明、画像に関する質問に答える)
AI Chat: 通常のテキスト会話
Summarize: テキストを貼り付けて概要を生成します
Smart Reply: 返信候補の生成

ほとんどのユーザーが最もよく使用するのは AI Chat です。

ステップ 3: Gemma 4 モデルをダウンロードする

「AI Chat」と入力します。
プロンプトに従って「Get Models」をクリックします。
モデルリストで Gemma 4 バージョンを選択します (対応するボリュームが表示されます)。
デバイスの性能に応じてモデルを選択します。電話機が 8GB RAM の場合は、最初に Gemma 4 4B から開始できます。
Download をクリックすると、バックグラウンドでダウンロードが開始されます。

注: モデルが大きいほど、ダウンロード時間は長くなります。複数のモデルをダウンロードし、必要に応じて後で切り替えることもできます。ダウンロードしたモデルはローカルに保存されるため、再度ダウンロードする必要はありません。

ステップ 4: 会話を開始する

モデルのダウンロードが完了したら、次のようにします。

モデル名をクリックしてロードします (モデルのサイズとデバイスの機能に応じて、最初のロードには通常 10 ～ 30 秒かかります)。
チャットボックスに質問を入力して送信してください。
モデルはローカルで応答を生成し、データはクラウドにアップロードされません。

一般に、最初の応答はわずかに遅くなりますが、これはモデルがウォームアップするときの正常な現象です。通常、同じセッション内での後続の応答はより速くなります。

ステップ 5: ビジュアル機能を体験する (Gemma 4 マルチモーダル)

Gemma 4 マルチモーダルバージョンをダウンロードした場合:

メインメニューに戻り、「Ask Image」と入力します。
写真を選択するか、直接写真を撮ります。
尋ねたい質問を入力します (たとえば、「この写真には何が写っていますか?」または「この写真のどのテキストに注意を払う必要がありますか?」)。
モデルがローカルで分析され、結果が返されるまで待ちます。

この機能はオフラインで動作し、画像コンテンツは外部サーバーに送信されません。

Google Gemma 4 モデル比較: 2B/4B/26B/31B 選び方は?

Sun, 05 Apr 2026 08:30:00 +0800

Gemma 4 は、多模态 と 本地离线运行 に焦点を当てており、軽量エンドから高性能エンドまでの完全なモデルグラデーションを提供します。ほとんどのローカル展開ユーザーにとって重要なのは、「最大のものを選択する」ことではなく、「ハードウェアとタスクに最適なバージョンを選択する」ことです。

Gemma 4 モデルの比較

次の表は、選択を簡単に参照できるようにしたものです。具体的なパフォーマンスとリソースの使用状況については、実際の展開環境のテストを参照してください。

模型	参数规模	定位	主要优势	主要限制	推荐场景
Gemma 4 2B	20 亿	超轻量	延迟低、资源占用小、部署门槛最低	复杂推理与长链路任务能力有限	移动端、IoT、轻量问答、简单自动化
Gemma 4 4B	40 亿	轻量增强	比 2B 更稳的理解与生成能力，仍易本地部署	高强度编码/复杂 Agent 任务上限有限	本地助手、基础文档处理、多语言日常任务
Gemma 4 26B	260 亿	高性能（专家混合）	推理和工具调用能力明显提升，适合生产工作流	显存需求显著上升，硬件门槛更高	编程助手、复杂工作流、企业内部 Agent
Gemma 4 31B	310 亿	高性能（稠密）	综合能力最强，复杂任务稳定性更好	资源消耗最高，部署与调优成本最大	高要求推理、复杂代码任务、重度自动化

選択方法: ハードウェアとタスクから逆算して考える

「走れるかどうか、スムーズに走れるかどうか」を主に見る場合は以下から選べます。

8GB ビデオメモリ: 優先順位 2B/4B。
12GB ビデオメモリ: 4B 以降のモデルの量子化バージョンを優先します。
24GB ビデオメモリ: 26B に焦点を当て、タスクに従って 31B の量子化バージョンを評価できます。
より高いグラフィックスメモリまたは複数のカード: 31B の高精度構成を試すことができます。

安定性と推論速度の確保を優先し、徐々にモデル規模を大きくしていくことをお勧めします。

4 つの典型的な使用シナリオ

1) 現地の一般アシスタント

優先モデル: 4B
理由：コストと効果のバランスが良く、長期の永続運用に適しています。

2) コードと自動化

優先モデル: 26B
理由: 複数ステップのタスク、ツール呼び出し、およびスクリプト生成においてより安定しています。

3) 難易度の高い推理と複雑なエージェント

優先モデル: 31B
理由: 複雑なコンテキスト下での安定性が向上し、フォールトトレランスが向上します。

4) エッジデバイスと軽量オフライン

優先モデル: 2B
理由: リソースに制約のあるデバイスに実装するのが最も簡単です。

導入に関する推奨事項 (Ollama オリエンテーション)

最も現実的な方法は、「小さなステップで素早く実行する」ことです。

まず、4B を使用して、実行可能なベースライン (速度、メモリ、エフェクト) を確立します。
実際のタスクの固定テストセットを作成します (例: 20 の FAQ + 10 の自動タスク)。
次に、26B/31B にアップグレードして、精度、遅延、メモリコストを比較します。
「メリットが明らかな」場合にのみ、大型モデルをアップグレードしてください。

これにより、最初から大きなパラメータを追求し、遅延、低スループット、複雑なメンテナンスなどの問題が発生することを回避できます。

結論は

Gemma 4 の真の価値は、単に「より大きなパラメーター」ではなく、軽量から高性能までの実装可能なグラデーションの完全なセットです。

低コストで迅速にオンラインに接続したい場合は、2B/4B から始めてください。
ローカル AI を本番プロセスに真に統合したい場合は、26B を優先してください。
複雑な推論と高度な自動化に取り組みたい場合は、31B をもう一度試してください。

Gemma 4 に最適な選択は、通常、パラメータが最大のバージョンではなく、ハードウェアの条件とミッションの目標に最もよく一致するバージョンです。