GGUF 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

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

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、コンテキスト長、速度、出力品質のバランスです。

参考元

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、速度、コンテキスト長、出力品質のバランスです。

参考元

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> を直接使用します。これが通常は最も簡単な方法です。

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 にダウングレードする方が安全です。

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 に接続します。

GGUF on KnightLiブログ

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

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

Windowsプリビルド版の選び方

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

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

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

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

よくある問題

まとめ

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

まず VRAM の上限を見る

おすすめ1：Qwen3 8B

おすすめ2：Llama 3.1 8B Instruct

おすすめ3：Gemma 3 12B

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

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

量子化の選び方

どのツールで動かすか

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

用途別の選び方

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

まとめ

参考リンク

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

まず結論

公式重みサイズ

Qwen3.6-27B VRAM表

Qwen3.6-35B-A3B VRAM表

27B と 35B-A3B の選び方

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

どう選ぶか

参考元

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

まず結論

Gemma 4 E2B VRAM表

Gemma 4 E4B VRAM表

Gemma 4 26B A4B VRAM表

Gemma 4 31B VRAM表

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

どう選ぶか

参考元

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

基本的な使い方

共通パラメータ

定量化の選び方

実践的なアドバイス

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

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

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

K_M / K_Sとは

実用的な選択の提案

品質の勾配 (高から低)

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

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

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

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

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

既存のモデルのモデルファイルを表示する方法

このルートを使用するのが適切なのはどのような場合ですか?

共通の注意点

結論は

`K_M` / `K_S`とは