Ollama on KnightLiブログ

Claude Code + Ollama ローカル導入ガイド：CC Switch で無料の AI コーディングアシスタントを作る

Fri, 15 May 2026 23:27:50 +0800

最近、Claude Code のような AI コーディングアシスタントが注目されています。魅力は単にコードについて会話できることではなく、プロジェクトを読み、ファイルを編集し、コマンドを実行し、依存関係を入れ、エラーを見ながら修正を続けられる点にあります。かなり Agent に近い使い方ができます。

ただし問題はコストです。プロジェクトが大きくなるとコンテキストも長くなり、複数ターンの Agent 操作で API クォータを一気に消費します。試用、小さなツールの修正、スクリプト作成、ローカルのプライベートプロジェクトで使いたいだけなら、Claude Code の操作感を残したままモデルだけローカルにできないか、と考えるのは自然です。

この構成の鍵になるのが CC Switch です。Claude Code から OpenAI 互換 API としてローカルの Ollama サービスへ接続し、公式 Claude API ではなくローカルモデルへリクエストを転送できます。

この構成で解決できること

全体の流れは次のように考えると分かりやすいです。

1
2
3

Claude Code デスクトップ
+ CC Switch API 転送レイヤー
+ Ollama ローカルモデル

Claude Code は引き続きコーディングワークフローとプロジェクト操作を担当します。CC Switch はモデルプロバイダー設定と API 互換性を受け持ち、Ollama はローカルでモデルを動かします。

これはローカルモデルが突然 Claude と同等になるという意味ではありません。価値があるのは、Claude Code の Agent ワークフローを低コスト、オフライン、プライベートなローカル環境で使えるようにする点です。

基本準備

始める前に、次のものを用意します。

Git をインストールする。
Ollama をインストールする。
コーディング向きのローカルモデルを取得する。
CC Switch をインストールする。
Claude Code をローカルで使える状態にする。

モデルは、まずコード能力が比較的強いものから試すとよいでしょう。たとえば Qwen Coder、DeepSeek Coder、またはツール呼び出しとコード生成がある程度安定しているモデルです。大きいモデルほど結果は良くなりやすい一方、メモリや GPU への負荷も高くなります。

メモリに余裕がないマシンでは、小さめのモデルで流れを確認してから、徐々に大きいモデルを試すのがおすすめです。

CC Switch の重要設定

Ollama を起動すると、通常のローカル API アドレスは次のようになります。

`1`	`http://127.0.0.1:11434/v1`

CC Switch では OpenAI 互換のプロバイダー種別を選びます。よく使う選択肢は次のものです。

`1`	`OpenAI Chat Completions`

そのうえで base URL を Ollama のローカルアドレスに向けます。

API key はローカル Ollama では通常、本物のキーを必要としません。ただし多くのツールは環境変数やプレースホルダーを求めます。次のような値を使えます。

`1`	`ANTHROPIC_API_KEY`

または、手元のローカル設定で受け入れられる別のプレースホルダー変数でも構いません。

特に注意したい設定項目があります。

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

これは Claude Code が期待するモデルロールをローカルプロバイダーへマッピングする設定です。実際には haiku、sonnet、opus を Ollama または CC Switch 側で利用できるモデル名に対応させる必要があります。この対応が間違っていると、Claude Code がモデルを呼べなかったり、意図しない設定へ戻ったりします。

Claude Code の強み

Claude Code の一番の価値は、単発の補完ではなくコーディング全体のワークフローにあります。

プロジェクト構造を読み取って理解する。
タスクに応じて関連ファイルを見つける。
コードを直接編集する。
コマンドやテストを実行する。
エラーを観察して修正を繰り返す。
1 つのセッションで複数ステップの作業を進める。

多くの人が Claude Code を残したい理由もここにあります。通常のチャット UI でもコード片は生成できますが、リポジトリ内で自然に作業してくれるわけではありません。Claude Code は、実行できる開発アシスタントに近い存在です。

Ollama の役割

Ollama はローカルモデルの実行と管理を担当します。モデルのダウンロード、ロード、ローカル推論を扱います。

利点は明確です。リクエストは手元のマシンに残り、繰り返し使っても API 課金が発生せず、ネットワークが制限された環境でも使えます。プライベートなコードを扱う場合も、すべてのコンテキストをクラウドモデルに送るより受け入れやすいでしょう。

一方で代償もあります。ローカルモデルはハードウェアとモデル品質に大きく左右されます。小さいモデルでも簡単な修正、説明、スクリプト生成はできますが、大規模な複数ファイルリファクタリングや細かな設計判断では能力差が出やすくなります。

体験の限界

この構成は、Claude の強力なクラウドモデルを完全に置き換えるものとして考えるべきではありません。

次のような問題に遭遇する可能性があります。

長いコンテキストの理解が弱い。
複雑なタスクでツール呼び出しが不安定になる。
CPU のみの環境では推論が遅い。
存在しないファイルパスや API を幻覚しやすい。
複数ターンの計画が安定しにくい。
大規模リポジトリのリファクタリング成功率が低い。

したがって、期待値としては「無料で使えるローカル開発アシスタント」が現実的です。トップクラスのクラウドモデルの完全な代替ではありません。

マルチモーダル互換性はまだ不安定

Claude Code にスクリーンショット、UI 画像、図、その他のマルチモーダル入力を扱わせたい人もいます。この部分はローカルモデルと転送レイヤーの対応状況に依存します。

選んだ Ollama モデルが画像入力に対応していない場合、または CC Switch がリクエスト形式を正しく変換できない場合、マルチモーダル機能は失敗する可能性があります。Vision モデルを使っても、公式 Claude API と同じ挙動になるとは限りません。

現時点では、この構成はテキストとコードのワークフロー向きです。マルチモーダル対応は実験的なものとして扱うのがよいでしょう。

試す価値がある人

この構成は次のような人に向いています。

Claude Code のワークフローを低コストで試したい開発者。
スクリプト、小さなツール、自動化をよく書く人。
コードをできるだけローカルに残したいチーム。
API コストを気にせず AI コーディングアシスタントを学びたい初心者。
さまざまなローカルコードモデルを検証している人。

長いコンテキスト、大規模 monorepo、厳密なコードレビュー品質、複雑なプロジェクト全体のリファクタリングに強く依存する場合は、まだ安定性が足りないかもしれません。

使い方のおすすめ

まずは小さなタスクから始めましょう。

たとえば次のような作業です。

1 つのファイルを説明させる。
小さな関数をリファクタリングする。
shell スクリプトを生成する。
単純なエラーを修正する。
小さな機能を追加する。
狭いモジュールに単体テストを追加する。

変更後は、自分でテストを実行するか、少なくとも diff を確認してください。ローカルモデルは便利ですが、生成された編集をすべて無条件に受け入れるべきではありません。

モデルがよくコンテキストを見失う場合は、タスク範囲を小さくします。「プロジェクト全体をリファクタリングして」ではなく、「この関数をリファクタリングして」や「このファイルにバリデーションを追加して」のように依頼すると安定しやすくなります。

まとめ

Claude Code + CC Switch + Ollama はかなり面白い組み合わせです。Claude Code の Agent 的な開発体験を保ちつつ、モデル推論をローカルへ移せます。

大きな利点は、コストの低さ、データのプライバシー、扱いやすい開発ワークフローです。一方で、モデル品質、ハードウェア性能、長いコンテキスト、ツール呼び出しの安定性が体験を左右します。

すでに Ollama を使っていて、より実践的なローカル AI コーディング環境が欲しいなら、この構成は試す価値があります。ただし小さな作業から始め、すべての変更を確認し、ローカルモデルを自動エンジニアではなくアシスタントとして扱うのが安全です。

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

Ollama が GPU を使わず CPU で動いてしまう問題の対処法

Fri, 24 Apr 2026 18:30:00 +0800

ローカルで大規模モデルを動かしているとき、かなり悩まされやすいのが「GPU があるのに Ollama がほぼ CPU しか使わず、速度も極端に遅い」という問題です。

先に結論を言うと、この手の問題はたいてい単一の原因ではありません。よくある原因は次のとおりです。

Ollama が利用可能な GPU を認識できていない
ドライバ、ROCm、CUDA の環境構築が正しくない
Ollama サービスが正しい環境変数を引き継がずに起動している
モデルが大きすぎて CPU もしくは CPU/GPU の混在ロードに落ちている
AMD 環境では、ROCm のバージョン、gfx 設定、デバイス可視性などの互換性問題が追加で発生している

以下、時間を無駄にしにくい順番で切り分けていきます。

1. まず本当に GPU を使えていないのか確認する

一番わかりやすい確認方法はこれです。

`1`	`ollama ps`

見るべきなのは PROCESSOR 列です。

100% GPU: モデルは完全に GPU 上で動いている
100% CPU: GPU はまったく使えていない
48%/52% CPU/GPU のような表示: 一部は VRAM に載り、一部はシステムメモリに落ちている

100% CPU なら、次は環境とサービス設定を重点的に確認すべきです。
混在ロードの場合は、GPU が壊れているとは限らず、単純に VRAM が足りないだけのことも多いです。

2. まず一番多い思い込みを外す: モデルが VRAM に収まっていない

GPU を積んでいれば Ollama は常にフル GPU 推論になる、と考えている人は多いですが、実際はそうではありません。

モデルが大きすぎる、コンテキストが長すぎる、あるいは別のモデルがすでに VRAM を使っている場合、Ollama は次のような状態に落ちることがあります。

一部 GPU + 一部 CPU
100% CPU

この場合、まずは次の 2 つを試すのがいちばん早いです。

より小さいモデルでテストする
いきなり大きなモデルを試すのではなく、まずは 4B や 7B のような小さめのモデルで確認します。
すでに読み込まれている他のモデルを外してから再確認する
先に ollama ps を見て、別のモデルが VRAM を占有していないか確認します。

小さいモデルは GPU で動くのに、大きいモデルだけだめなら、原因はドライバではなく VRAM 容量であることがほとんどです。

3. GPU ドライバと下位ランタイムが正常か確認する

小さいモデルですら CPU しか使わないなら、次は下位レイヤの確認です。

NVIDIA の場合

まずはドライバが正常で、OS から GPU が見えているかを確認します。よく使う確認方法は次のとおりです。

`1`	`nvidia-smi`

ここでエラーになるなら、Ollama が GPU を正常に使える可能性はかなり低いです。

AMD / ROCm の場合

AMD GPU、特に ROCm 環境なら、まず次を確認します。

1
2

rocminfo
rocm-smi

これらがデバイスを正常に列挙できないなら、問題はまだ Ollama より下の層にあります。アプリ側をいじる前に、そこを直すべきです。

AMD でよくあるのは、単純な「ドライバが入っているか」ではなく、次のような問題です。

ROCm のバージョンと OS の組み合わせが合っていない
対象 GPU アーキテクチャのサポートが不完全
デバイス自体は存在するが、実行環境が Ollama に正しく渡っていない

4. ターミナルではなく Ollama サービス自体を再起動する

これはかなりよくある落とし穴です。

ドライバを入れ直し、環境変数を変え、ROCm を調整したあとで、単に新しいターミナルを開いて ollama run を続けてしまうケースがあります。ですが Ollama がバックグラウンドサービスとして動いているなら、古い環境のまま動作し続けている可能性があります。

なので、より安全なのは次のやり方です。

Ollama サービスを完全に再起動する
必要なら OS ごと再起動する

Linux でサービスとして動かしているなら、古いプロセスを再利用していないかも確認してください。

5. 環境変数が本当にサービスまで届いているか確認する

これは特に AMD ROCm 環境で重要です。

シェル上で手動実行すると問題ないのに、Ollama サービスにすると CPU しか使わない、というケースがあります。多くの場合、原因はシェルで設定した変数がサービスプロセスに渡っていないことです。

よく確認したい変数は次のあたりです。

1
2

ROCR_VISIBLE_DEVICES
HSA_OVERRIDE_GFX_VERSION

それぞれの意味は次のとおりです。

ROCR_VISIBLE_DEVICES: ROCm から見える GPU を制限または指定する
HSA_OVERRIDE_GFX_VERSION: 一部 AMD 環境で互換性確保のために使うことがある

現在のターミナルで一時的に export しただけでは、systemd、デスクトップのバックグラウンドサービス、その他のデーモン経由で起動された Ollama には反映されないことがあります。

つまり、ターミナルで「設定済みに見える」ことと、Ollama が実際にその設定を使っていることは別です。

6. AMD 環境では ROCm の互換性を重点的に見る

公開ページの情報を見る限り、この話題の元動画は AMD Max+ 395、strix halo、AMD ROCm の文脈にあります。
この種の環境では、Ollama が GPU を使えない原因は、NVIDIA よりもバージョン整合性に左右されやすい傾向があります。

優先的に見るべき点は次のとおりです。

現在の OS と GPU に対して ROCm のバージョンが適切か
その GPU が ROCm で比較的安定して動くアーキテクチャか
HSA_OVERRIDE_GFX_VERSION の指定が必要か
古い Ollama や古い推論ランタイムが互換性の問題を起こしていないか

rocminfo は正常で GPU も OS から見えているのに、Ollama だけが CPU しか使わないなら、モデルパラメータをいじるより、まずバージョンの組み合わせを疑うべきです。

7. Docker、WSL、リモート環境ではデバイスマッピングも確認する

もしベアメタルではなく、次のような環境で動かしているなら:

Docker
WSL
リモートコンテナ
仮想化環境

もう一段下を見て、「GPU デバイスが本当にその環境に渡っているか」を確認する必要があります。

典型的には次のような状態になります。

ホスト側では GPU が見えている
しかしコンテナやサブシステム内の Ollama は CPU しか使わない

この場合、問題は Ollama 自体ではなく、コンテナやサブシステムに GPU アクセス権限が渡っていない可能性があります。

8. 最後にログを見る。やみくもに再インストールしない

ここまで確認したなら、次に有効なのは何度も再インストールすることではなく、Ollama の起動ログと実行ログを直接見ることです。

見るべきポイントは大きく 2 つです。

GPU を認識できているか
ドライバ、ライブラリ読込、デバイス初期化失敗などのエラーが出ていないか

ログに「互換 GPU が見つからない」や「ROCm/CUDA の初期化に失敗した」といった内容が出ていれば、切り分けの方向はかなり明確になります。

切り分け順序

最短ルートだけ覚えたいなら、次の順番で確認すると効率的です。

ollama ps で GPU、CPU、混在ロードのどれかを確認する
小さいモデルで試し、VRAM 不足を切り分ける
nvidia-smi、rocminfo、rocm-smi で下位環境が正常か先に確認する
Ollama サービスを完全に再起動する
特に AMD では ROCR_VISIBLE_DEVICES と HSA_OVERRIDE_GFX_VERSION を確認する
Docker / WSL ならデバイスマッピングを確認する
最後にログを見て、具体的なエラーを特定する

まとめ

Ollama が GPU ではなく CPU を使ってしまう問題は、だいたい次の 3 パターンのどれかです。

GPU がそもそも認識されていない
GPU は見えているが、実行環境が Ollama に届いていない
GPU は動いているが、モデルが大きすぎて CPU または混在メモリに落ちている

この 3 つをまず分けて考えるだけで、切り分けはかなり速くなります。
AMD 環境では特に、ROCm のバージョン整合性、デバイス可視性、互換性用の環境変数を重視して確認するのがポイントです。

元動画：https://www.bilibili.com/video/BV1cHoYBqE8k/

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

Windows で WSL + Ollama を使って Hermes Agent をローカル導入し、Telegram に接続する

Sat, 18 Apr 2026 00:48:22 +0800

Windows 上でできるだけ手軽に Hermes Agent を動かしたいなら、比較的やりやすい流れは次の通りです。

ホスト OS はそのまま Windows を使う
WSL 内で Ubuntu を動かす
Ollama でローカルモデルを提供する
Hermes Agent からローカル Ollama のエンドポイントへ直接つなぐ

この方法の利点は、環境を比較的きれいに保ちやすく、コマンドも Linux 方式でそろえやすいことです。別に Linux マシンを用意しなくても始められます。

全体の流れ

この構成は 4 ステップに分けられます。

WSL を有効化して Ubuntu を入れる
Ubuntu 内で Python、Node.js、Git などの基本環境を入れる
Ollama を入れてローカルモデルを取得する
Hermes Agent を入れ、Telegram を接続する

まず Hermes Agent を動かすことだけが目的なら、実質的には 3 ステップ目まででかなり近いところまで行けます。

1. WSL と Ubuntu をインストールする

管理者権限の PowerShell で次を実行します。

`1`	`wsl --install`

インストールが終わったら PC を再起動し、そのあと Ubuntu を入れます。

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

以降のコマンドは、WSL の Ubuntu 側で実行していきます。

2. Ubuntu を更新し、基本環境を入れる

まずシステムを更新します。

1
2

sudo apt update
sudo apt upgrade -y

そのあと Python、展開ツール、Node.js、Git を入れます。

Python をインストール

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

zstd をインストール

`1`	`sudo apt install -y zstd`

Node.js をインストール

1
2

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

Git をインストール

1
2

sudo apt update
sudo apt install -y git

入れ終わったら、軽く確認しておくと安心です。

1
2
3

node -v
npm -v
git --version

3. Ollama を入れて Gemma 4 を取得する

Ollama のインストール:

`1`	`curl -fsSL https://ollama.com/install.sh \| sh`

Hermes Agent 用にローカルモデルを用意するなら、まずは Gemma 4 から始めるのが無難です。

たとえば:

`1`	`ollama run gemma4:e4b`

もしマシンのリソースが弱ければ:

`1`	`ollama run gemma4:e2b`

より大きい版としては:

1
2

ollama run gemma4:26b
ollama run gemma4:31b

一般的な Windows + WSL 環境では、gemma4:e4b が現実的な出発点になりやすいです。

4. Hermes Agent をインストールして設定する

インストールコマンド:

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

インストール後、Ollama のローカルエンドポイントを指定します。

`1`	`http://127.0.0.1:11434`

モデル名には実際に使うものを入れます。たとえば:

`1`	`gemma4:e4b`

インストーラから shell の再読み込みを求められたら:

`1`	`source ~/.bashrc`

Hermes Agent のよく使うコマンド

普段よく使うのは次のあたりです。

起動

hermes

再設定

`1`	`hermes setup`

チャットゲートウェイ設定

`1`	`hermes setup gateway`

更新

`1`	`hermes update`

Telegram 接続の基本手順

Hermes Agent で Telegram の送受信をしたいなら、まずは次を実行します。

`1`	`hermes setup gateway`

そのうえで Telegram 側で次の 2 つを用意します。

BotFather で bot を作成する
@userinfobot で自分の User ID を確認する

これらを揃えたら、Hermes Agent のゲートウェイ設定に入力していきます。

この構成が向いている人

この方法は、次のような人に向いています。

メイン環境が Windows
別に Linux マシンを用意したくない
まずはローカル Agent を動かし、その後チャット連携を広げたい
できるだけクラウド API ではなくローカルモデルを使いたい

最初から本格的な本番環境を組むのではなく、まずローカルで Agent を試したい人には十分実用的です。

注意点

WSL はあくまで互換レイヤーなので、極端なケースではネイティブ Linux と完全に同じとは限りません
大きなモデルが快適に動くかどうかは、RAM、VRAM、CPU / GPU に依存します
gemma4:e4b は現実的な出発点ですが、最終的な体感はマシン性能次第です
Hermes Agent のチャット連携は拡張機能なので、まずローカルモデル経路を通してから Telegram を足すほうが安定しやすいです

まとめ

Windows 上でなるべく素直に Hermes Agent をローカル導入するなら、流れは次の順番がやりやすいです。

WSL -> Ubuntu -> Ollama -> Gemma 4 -> Hermes Agent -> Telegram

最初にローカルモデルを確実に動かし、そのあとでゲートウェイ接続を追加すると成功率が上がります。多くのユーザーにとって、最初から部品を積みすぎるよりもこのほうが切り分けしやすく、後から拡張もしやすいです。

元記事

この投稿は次のページをもとに整理・リライトしています。

X超哥博客：太简单了！Hermes Agent 本地部署（无需API）接入 Telegram + 微信

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 クライアント自体ではなく、実際の大きなファイルのダウンロードリンクにある可能性が高いということです。

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: 需要の高いタスクに適しており、効果はクラウド大規模モデルに近いですが、ハードウェア要件は大幅に高くなります。

Ollama モデルが GPU にロードされているかどうかを確認する方法

Mon, 06 Apr 2026 10:15:18 +0800

Ollama モデルが実際に GPU 上で実行されているかどうかを確認する最も直接的な方法は、現在ロードされているモデルのプロセッサ使用状況情報を確認することです。

コマンドを使用する

`1`	`ollama ps`

出力例

1
2

NAME        ID            SIZE    PROCESSOR   UNTIL
llama3:70b  bcfb190ca3a7  42 GB   100% GPU    4 minutes from now

`PROCESSOR` 列の解釈方法

100% GPU: モデルは GPU メモリに完全にロードされています。
100% CPU: モデルはシステムメモリに完全にロードされています (GPU 推論は使用されません)。
48%/52% CPU/GPU: モデルは一部がメモリ内にあり、一部がビデオメモリ内にあり、混合負荷です。

実践的なアドバイス

GPU を使用する予定なのに 100% CPU が表示される場合は、まずグラフィックスドライバー、CUDA/ROCm 環境、および Ollama ランタイムパラメーターを確認してください。
モデルパラメータの数が多く、ビデオメモリが不足している場合、通常、CPU/GPU 混合負荷が発生します。
パフォーマンスの問題のトラブルシューティングを行う場合は、最初に ollama ps を実行し、次に速度データを確認してボトルネックをより迅速に特定します。

要約する

ollama ps は、モデルが実際に GPU を使用しているかどうかを判断する最初のステップです。 PROCESSOR 列に注目して、現在の読み込み位置をすばやく確認し、それに応じてその後の最適化の方向を決定します。

Ollama モデルのデフォルトの保存場所と移行方法 (C ドライブがいっぱいになるのを防ぐため)

Mon, 06 Apr 2026 09:38:00 +0800

大規模なモデルをローカルで実行する場合、多くの場合、システムディスクが最初に爆発しやすくなります。 Ollama は、デフォルトでモデルをユーザーディレクトリまたはシステムディレクトリにダウンロードします。事前にパスを計画しておかないと、C ドライブがすぐにいっぱいになってしまいます。

Ollama 共通のデフォルトモデルディレクトリ

Windows: C:\Users\<用户名>\.ollama\models
macOS：~/.ollama/models
Linux: /usr/share/ollama/.ollama/models (一部インストール方法が異なる場合があります)

Windows: モデルディレクトリをシステム以外のディスクに移行します。

モデルディレクトリを D:\OllamaModels などに移行することをお勧めします。主な方法は、システム環境変数 OLLAMA_MODELS を設定することです。

1. 新しいターゲットディレクトリを作成します

たとえば、最初に D:\OllamaModels を作成します。

2. システム環境変数を構成する

変数名: OLLAMA_MODELS
変数値: D:\OllamaModels

これは、「システムのプロパティ -> 詳細設定 -> 環境変数」で追加することも、コマンドライン (管理者 PowerShell) を使用して設定することもできます。

`1`	`[System.Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\OllamaModels", "Machine")`

3. Ollama を再起動します (またはシステムを再起動します)。

環境変数が有効になったら、Ollama サービス/アプリケーションを再起動します。有効になったかどうかわからない場合は、コンピュータを直接再起動するのが最も安全です。

4. 新しいディレクトリが有効かどうかを確認します

モデルをダウンロードまたはプルした後、新しいファイルが D:\OllamaModels の下に表示されるかどうかを確認します。

5. 古いディレクトリをクリーンアップします（それが正しいことを確認した後）

新しいディレクトリでモデルが正常に動作していることを確認してから、古いディレクトリの内容を削除して、C ドライブのスペースを解放します。

よくある質問

設定した後もCドライブに書き込まれたままの場合はどうすればよいですか?

まず、環境変数が「現在のセッションの一時変数」ではなく「システム変数」であることを確認します。
Ollama プロセスが再起動されたことを確認します。
変数名が正しいことを確認してください。それは OLLAMA_MODELS である必要があります。

古いモデルのファイルを移行する必要がありますか?

再度ダウンロードしたくない場合は、Ollama を停止した後、古いモデルを新しいディレクトリに手動でコピーし、Ollama の検証を開始できます。

Linux 上の Ollama を完全にアンインストールします (残留クリーニングを含む)

Mon, 06 Apr 2026 09:16:29 +0800

Linux 上で Ollama を完全に削除する必要がある場合は、以下の手順に従ってください。この記事では、サービス、実行可能ファイル、モデルディレクトリ、および ollama ユーザーとユーザーグループをクリーンアップします。

アンインストール前の注意事項

次のコマンドは、ネイティブ Ollama モデルファイル (通常は /usr/share/ollama) を削除します。最初にバックアップする必要があるかどうかを確認してください。
このコマンドはデフォルトで sudo を使用します。現在のアカウントに管理者権限があることを確認してください。

1. systemd サービスを停止して削除します。

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm -f /etc/systemd/system/ollama.service
sudo systemctl daemon-reload

2. Ollama 実行可能ファイルを削除します

OLLAMA_BIN="$(command -v ollama)"
if [ -n "$OLLAMA_BIN" ]; then
  sudo rm -f "$OLLAMA_BIN"
fi

3. Ollama 関連のライブラリディレクトリを削除します (存在する場合)。

インストール方法によって Ollama ファイルが lib ディレクトリに書き込まれる場合は、次のようにファイルを消去できます。

1
2
3

for d in /usr/local/lib/ollama /usr/lib/ollama /lib/ollama; do
  [ -d "$d" ] && sudo rm -rf "$d"
done

4. モデルとデータのディレクトリを削除します。

`1`	`sudo rm -rf /usr/share/ollama`

5. システムユーザーとグループを削除します (存在する場合)。

1
2

id -u ollama >/dev/null 2>&1 && sudo userdel ollama
getent group ollama >/dev/null 2>&1 && sudo groupdel ollama

6. アンインストールが完了したことを確認します

1
2

command -v ollama || echo "ollama binary not found"
systemctl status ollama || true

上記のチェックで ollama が見つからなかった場合は、アンインストールが完了したことを意味します。

大規模モデルの定量化の詳細な説明: FP16、Q8、Q5、Q4 ～ Q2 を選択するにはどうすればよいですか?

Sun, 05 Apr 2026 22:09:11 +0800

量子化の中心的な目標は単純です。サイズを小さくし、メモリ使用量を減らし、推論速度を速くする代わりに、精度の損失を小さくすることです。
ローカル展開ユーザーにとって、多くの場合、盲目的に大きなパラメータを追求するよりも、適切な定量的バージョンを選択することの方が重要です。

定量化とは何ですか

量子化とは、モデルパラメーターを高精度形式 (FP16 など) からより低いビット幅形式 (Q8、Q4 など) に圧縮することを指します。

それは次のように理解できます。

オリジナルモデル: 高精度の写真のように鮮明ですが、ファイルサイズが大きくなります。
量子化モデル: 圧縮された写真と同様に、細部はわずかに失われますが、軽量かつ高速です。

一般的な定量バージョンの比較

量化版本	精度/位宽	体积	质量损失	推荐场景
FP16	16 位浮点	最大	几乎无损	研究、评测、追求极致质量
Q8_0	8 位整数	较大	几乎无损	高配电脑，兼顾质量与性能
Q5_K_M	5 位混合	中等	轻微损失	日常主力，平衡方案
Q4_K_M	4 位混合	较小	可接受损失	通用默认，性价比高
Q3_K_M	3 位混合	很小	明显损失	低配设备，能跑优先
Q2_K	2 位混合	最小	较大损失	极限资源场景，临时可用

定量的な命名規則

gemma-4:4b-q4_k_m を例として取り上げます。

gemma-4:4b: モデル名とパラメータスケール。
q4: 4 ビット量子化。
k: K-quants (改良された量子化方法)。
m：中（中レベル、s/小、l/大が共通）。

ビデオメモリに基づいてモデルを素早く選択する方法

内存/显存	推荐量化
4 GB	Q3_K_M / Q2_K
8 GB	Q4_K_M
16 GB	Q5_K_M / Q8_0
32 GB+	FP16 / Q8_0

最初から最大のモデルを追求するのではなく、安定して動作するバージョンから始めて、徐々に精度を向上させることをお勧めします。

実践的な提案

デフォルトでは、Q4_K_M から開始され、最初に実際のタスクの効果を確認します。
回答の品質が十分でない場合は、Q5_K_M または Q8_0 にアップグレードしてください。
主なボトルネックがビデオメモリまたは速度である場合は、Q3_K_M にドロップします。
定量化バージョンに切り替えるたびに、同じバッチのテスト問題を比較に使用してください。

結論は

品質第一: FP16 または Q8_0。
バランス優先度: Q5_K_M。
共通のデフォルト: Q4_K_M。
ローエンドポケット: Q3_K_M または Q2_K。

モデル選択の本質は、「大きいほど良い」ではなく、「ハードウェア条件下で最も安定して使用可能な効果を実現する」ことです。

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 に最適な選択は、通常、パラメータが最大のバージョンではなく、ハードウェアの条件とミッションの目標に最もよく一致するバージョンです。

Ollama on KnightLiブログ

Claude Code + Ollama ローカル導入ガイド：CC Switch で無料の AI コーディングアシスタントを作る

この構成で解決できること

基本準備

CC Switch の重要設定

Claude Code の強み

Ollama の役割

体験の限界

マルチモーダル互換性はまだ不安定

試す価値がある人

使い方のおすすめ

まとめ

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 への現実的な期待

まとめ

参考リンク

Ollama が GPU を使わず CPU で動いてしまう問題の対処法

1. まず本当に GPU を使えていないのか確認する

2. まず一番多い思い込みを外す: モデルが VRAM に収まっていない

3. GPU ドライバと下位ランタイムが正常か確認する

NVIDIA の場合

AMD / ROCm の場合

4. ターミナルではなく Ollama サービス自体を再起動する

5. 環境変数が本当にサービスまで届いているか確認する

6. AMD 環境では ROCm の互換性を重点的に見る

7. Docker、WSL、リモート環境ではデバイスマッピングも確認する

8. 最後にログを見る。やみくもに再インストールしない

切り分け順序

まとめ

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

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

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

SLI や NVLink は不要

Ollama が使う NVIDIA GPU を制限する

AMD と Vulkan の選択変数

Docker で複数 GPU を見せる

OLLAMA_SCHED_SPREAD とは

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

よくある誤解

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

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

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

誤解 4：NVLink / SLI が必須

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

GPU 選びの目安

まとめ

参考連結

Windows で WSL + Ollama を使って Hermes Agent をローカル導入し、Telegram に接続する

全体の流れ

1. WSL と Ubuntu をインストールする

2. Ubuntu を更新し、基本環境を入れる

Python をインストール

zstd をインストール

Node.js をインストール

Git をインストール

3. Ollama を入れて Gemma 4 を取得する

4. Hermes Agent をインストールして設定する

Hermes Agent のよく使うコマンド

起動

再設定

チャットゲートウェイ設定

更新

Telegram 接続の基本手順

この構成が向いている人

注意点

まとめ

元記事

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

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

ファイアウォールを開く

`OLLAMA_SCHED_SPREAD` とは

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

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

Ollama ダウンロードモデルのプル速度が遅い場合のトラブルシューティングと解決策

ジャンプ後の実際のダウンロードアドレス

`PROCESSOR` 列の解釈方法

Ollama 共通のデフォルトモデルディレクトリ

Windows: モデルディレクトリをシステム以外のディスクに移行します。

3. Ollama 関連のライブラリディレクトリを削除します (存在する場合)。

5. システムユーザーとグループを削除します (存在する場合)。