OllamaにGGUFモデルをインポートする方法

Ollama に GGUF モデルをインポートする 2 つの方法

GGUF モデルを Ollama にインポートする方法は 2 つあります。適切な方法は、ファイルが現在どこにあるかで決まります。モデルが Hugging Face のリポジトリにある場合は、ollama run コマンド 1 つで取得して実行できます。この方法では Modelfile は不要です。.gguf ファイルがすでにサーバーのディスク上にある場合は、2 行の Modelfile を作成して ollama create を実行します。

どちらの方法でも、最終的にはローカル Ollama ライブラリに名前付きモデルが作成されます。このモデルは ollama run と Ollama API から提供できます。別のユーザーがファイルを公開している場合は、最初の方法を使用します。自分でモデルを量子化した場合、ファイルが scp または rsync 経由で届いた場合、またはマシンから Hugging Face に接続できない場合は、2 番目の方法を使用します。

GGUF ファイルは、重み、tokenizer、モデルメタデータを 1 つにまとめたバイナリファイルです。これは llama.cpp が読み取る形式です。Ollama は llama.cpp を基盤としているため、ほぼすべてのオープンモデルにコミュニティによる GGUF 変換版があります。Ollama は .safetensors の重みを含むディレクトリもインポートできます。ただし、これは別の方法です。以下の --quantize のセクションで、その位置付けを説明します。

以下では、Ollama がすでにインストールされ、サービスが起動していることを前提とします。起動していない場合は、まず VPS に Ollama をインストールする を参照してから戻ってきてください。最初に ollama list を実行します。接続エラーではなく、空のテーブルを含むテーブルが返れば、サーバーは起動しています。このガイドの以降の手順を実行できます。

Hugging Face から GGUF を Modelfile なしで実行する方法

Ollama は Hugging Face リポジトリから GGUF を直接 pull できます。コマンドには、リポジトリのパスに hf.co/ プレフィックスを付けます。

ollama run hf.co/{username}/{repository}

ドメイン名には hf.co と huggingface.co のどちらも使用できます。Hugging Face のドキュメントにある実例を示します。

ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF

初回の実行ではファイルがダウンロードされるため、ダウンロードが完了するまでチャットプロンプトは表示されません。その後、モデルはローカルライブラリに保存され、すぐに起動できます。別のシェルを開き、ollama list を実行すると、保存時に付けられた名前を確認できます。この名前はタグを含む hf.co/... 文字列全体で、毎回入力するには長すぎます。短いエイリアスを付けます。

ollama cp hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF my-llama
ollama run my-llama

この方法は、実際に GGUF ファイルを含むリポジトリでのみ機能します。.safetensors の重みだけを公開しているリポジトリには、この方法で取得できるファイルがありません。その場合は、この後で説明するローカルインポートのいずれかが必要です。

Ollama はどの量子化を選択するか

2026 年 10 月 10 日に確認した Hugging Face の Ollama ドキュメントには、デフォルトの動作が明記されています。「デフォルトでは、モデルリポジトリ内に存在する場合、Q4_K_M 量子化方式が使用されます。存在しない場合は、リポジトリ内にある妥当な量子化タイプが 1 つ選択されます。」したがって、10 種類の量子化を公開しているリポジトリでは Q4_K_M が選択され、Q4_K_M がないリポジトリでは Ollama が代わりに選択した量子化が使われます。デフォルトは変更されるため、この動作を前提にする前に該当ページを再確認してください。

タグとして指定すると、特定の量子化を選択できます。

ollama run hf.co/{username}/{repository}:{quantization}

ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Q8_0
ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:iq3_m
ollama run hf.co/bartowski/Llama-3.2-3B-Instruct-GGUF:Llama-3.2-3B-Instruct-IQ3_M.gguf

量子化名では大文字と小文字が区別されないため、:iq3_m と :IQ3_M は同じ意味です。タグには正確なファイル名も指定できます。リポジトリ内の短い名前が曖昧な場合は、この形式が安全です。タグには、そのリポジトリに実在するファイル名を指定する必要があります。そのため、入力する前に Files and versions タブを開き、実際のファイル名を確認してください。どの量子化を選ぶかは、メモリ使用量と品質の問題です。Q4、Q8、FP16 の違いで、このトレードオフを詳しく説明しています。

自分のディスクから .gguf ファイルをインポートする方法

ファイルがすでにサーバー上にある場合は、Modelfile が必要です。1 行だけでも構いません。ディレクトリを作成し、その中に Modelfile を置いて、FROM にファイルを指定します。

mkdir -p ~/models/my-model
cd ~/models/my-model

FROM /home/you/models/my-model-Q4_K_M.gguf

これを Modelfile として保存し、モデルをビルドします。

ollama create my-model

ollama create は、デフォルトでカレントディレクトリにある Modelfile というファイルを読み取ります。ファイル名が異なる場合や別の場所にある場合は -f を使います。例は ollama create my-model -f /home/you/models/my-model/Modelfile です。ollama create --help を実行すると、ビルド時のフラグとデフォルト値を確認できます。FROM のパスは絶対パスでも、Modelfile からの相対パスでも指定できます。そのため、両方を同じディレクトリに置けば FROM ./my-model-Q4_K_M.gguf が機能します。絶対パスを使えば、この問題は完全に解消できます。

信頼する前に、結果を確認します。

ollama list
ollama show my-model
ollama run my-model "Reply with one short sentence."

ollama list には my-model が含まれているはずです。ollama show my-model は、Ollama がファイル自身のメタデータから読み取ったアーキテクチャ、パラメータ数、コンテキスト長、量子化方式を表示します。ファイル名だけを信頼せず、これらの値を確認してください。ファイル名は、誰かが手動で入力した文字列にすぎないためです。テストプロンプトにモデルが通常の文章で回答し、その後停止すれば、インポートは成功しています。そうでない場合は、以下のテンプレートのセクションに進んでください。ほとんどの場合、原因はそこにあります。

ディスク容量について、1 つ注意点があります。ollama create は、ファイルが置かれている場所を参照するのではなく、GGUF を Ollama 自身のモデルストアにコピーします。元のファイルを削除するまで、重みはディスク上に 2 つ存在します。ollama run my-model が正常に動作したら元のファイルを削除するか、二重に容量を消費しない場所へ移してください。Ollama がディスク上でモデルを保存する場所 に、ディレクトリ構成と移動方法を示しています。

--quantize が適用される場合と適用されない場合

ollama create には --quantize フラグがあります。現在、このフラグが適用されるのは 1 つの場合だけです。.safetensors の重みを含むディレクトリからモデルをインポートする場合です。10 October 2026 に確認した現在の Ollama ソースでは、ヘルプテキストに "Quantize safetensors model to this level (e.g. nvfp4)" と記載されており、指定できる値は int4、int8、nvfp4、mxfp4、mxfp8 です。q8_0 や q4_K_M などの GGUF の量子化名は、サポートされていない型として拒否されます。Ollama のインポートドキュメントには、GGUF について明確に "Ollama does not quantize GGUF models during import." と記載されています。

ollama create --quantize int8 my-model

このコマンドは、FROM 行で .safetensors ファイルを含むディレクトリを指定した Modelfile を前提としています。

FROM が .gguf を指定している場合は、精度にかかわらず、このフラグを渡さないでください。FP16 または FP32 の GGUF も Q4_K_M と同じように拒否され、"create-time quantization is only supported for safetensors imports" で始まるエラーが表示されます。.gguf の名前に Q4_K_M または Q5_K_S が含まれている場合、そのファイルはすでに量子化されています。失われた精度を元に戻すことはできません。llama.cpp の llama-quantize を使えば、--allow-requantize を渡して、そのようなファイルを別の型（Q8_0 を含む）として再エンコードできます。ただし、マニュアルには、この方法では "can severely reduce quality compared to quantizing from 16bit or 32bit" と記載されています。また、Q4 ファイルを Q8 として書き換えても、品質が向上しないままサイズだけが大きくなります。フル精度の GGUF を小さくするには、まず llama-quantize を実行してください。これは Ollama のドキュメントが案内しているツールです。その後、生成されたファイルをインポートします。ソースが .safetensors ファイルを含む Hugging Face リポジトリの場合は、そのディレクトリを FROM に指定し、ollama create にインポートさせる方法があります。小さくしたい場合は --quantize を指定します。または、llama.cpp リポジトリの convert_hf_to_gguf.py で変換し、そのスクリプトが生成した GGUF をインポートできます。Ollama と llama.cpp の関係では、これらのツールが別のプロジェクトに属する理由を説明しています。

インポートした GGUF の応答が文字化けしたり、停止しなかったりするのはなぜですか？

これは多くのインポートチュートリアルで省略されていますが、必ず直面する問題です。症状としてはモデルが壊れているように見えます。<|im_start|>assistant や <|end|> といった文字列が制御トークンとしてそのまま出力されます。モデルは回答した後に新しいユーザーの質問を勝手に生成し、それにも回答し続けます。生成は Ctrl+C を押すまで止まりません。

モデル自体は正常です。チャットテンプレートが間違っています。チャットテンプレートとは、ユーザーのメッセージをモデルが学習した通りの正確なトークンシーケンスに変換するためのラッパーであり、システムプロンプトの終了やユーザーのターンの開始を示すマーカーを含みます。Ollama は自動的にテンプレートを選択します。ドキュメントによれば、GGUF ファイル内に格納された tokenizer.chat_template メタデータに基づき、「一般的に使用されるテンプレートのリストから自動的に選択される」仕組みです。このメタデータが欠落しているか、リストに一致するものがない場合、汎用的なラッパーが適用されます。その結果、モデルは学習時とは異なる形式のプロンプトを受け取るため、学習済みの終了マーカーを認識できず、停止できなくなります。

Ollama が実際に選択したテンプレートを表示します。

ollama show --template my-model
ollama show --modelfile my-model

テンプレートが空、あるいは明らかに汎用的なものであれば、それが原因です。Modelfile 内でテンプレートを自分で記述してください。

FROM /home/you/models/my-model-Q4_K_M.gguf

TEMPLATE """{{ if .System }}<|system|>
{{ .System }}<|end|>
{{ end }}{{ if .Prompt }}<|user|>
{{ .Prompt }}<|end|>
{{ end }}<|assistant|>
{{ .Response }}<|end|>"""

PARAMETER stop "<|end|>"

ollama create my-model で再構築し、同じテストプロンプトを再度送信します。stop パラメータは安全策として機能します。これは指定した文字列が出現した時点で生成を強制終了させるもので、テンプレートの調整中であっても無限生成を防ぐことができます。指定したマーカーが出現せず応答が止まらない場合は、a num_predict ceiling を設定することで、テンプレートの出力に関わらずトークン数で強制的に打ち切ることができます。

テンプレートは Jinja テンプレートではなく、Go テンプレートである必要があります。 Hugging Face のドキュメントにも明記されていますが、これは重要です。元のモデルリポジトリにある tokenizer.chat_template フィールドには Jinja が記述されているため、そのままコピー＆ペーストしても動作しません。Ollama の構文には {{ .System }}（システムプロンプト）、{{ .Prompt }}（ユーザーメッセージ）、{{ .Response }}（モデルの回答）という 3 つの変数があります。モデルカードや tokenizer_config.json で実際のターンマーカーを確認し、それを手作業で Go 構文に書き換えてください。

作業を簡略化する近道があります。多くのモデルは共通のプロンプト形式を採用しているため、ライブラリ内の別のモデルが同じ形式を使用している場合は、ollama show --template を実行して出力内容をコピーしてください。

Hugging Faceリポジトリ内のテンプレート、システム、およびパラメータファイル

Hugging Faceのルートでは、Modelfile内の指示ではなく、リポジトリ内のファイルとして同様の制御を提供します。リポジトリの所有者である場合、あるいは独自の量子化モデルを公開する場合は、それらのファイルを追加することで、すべての ollama run hf.co/... がそれらを読み取ります。

• template という名前のファイルにはGoテンプレートを記述します。ルールは同じで、JinjaではなくGoを使用してください。
• system という名前のファイルにはシステムプロンプトを記述します。
• params という名前のファイルにはサンプリングパラメータを記述します。これはJSON形式である必要があります。

最小限の params ファイルの例：

{
  "stop": ["<|end|>"],
  "temperature": 0.7
}

リポジトリの所有者ではない場合、これらのファイルを追加することはできません。一度モデルをプルし、ollama show --modelfile hf.co/... を実行して提供された内容をダンプし、その出力をModelfileとして保存してください。その中の FROM 行はOllamaが既にダウンロード済みのblobを指しているため、TEMPLATE 行と PARAMETER 行を編集し、ollama create を実行することで、再ダウンロードすることなく固定されたローカルコピーをビルドできます。これが、他者が作成した不完全な量子化モデルに対する標準的な修正方法です。

プライベートな GGUF リポジトリをインポートする方法

プライベートリポジトリにアクセスするには、Hugging Face アカウントに Ollama の SSH 公開鍵を登録する必要があります。この手順では API トークンではなく SSH 鍵を使用するため、既存のトークンではアクセスできません。

公開鍵を表示します。公式スクリプトで Ollama をインストールした Linux サーバーでは、サービスは ollama ユーザーとして実行されるため、鍵はそのユーザーのホームディレクトリに存在します。

sudo cat /usr/share/ollama/.ollama/id_ed25519.pub

もし ollama serve を自分自身のユーザー権限で直接実行している場合、パスは ~/.ollama/id_ed25519.pub になります。表示された行全体をコピーし、Hugging Face のアカウント設定ページ https://huggingface.co/settings/keys を開き、新しい SSH 鍵として追加してください。これで、通常のコマンドでプライベートリポジトリから取得できるようになります。

ollama run hf.co/{username}/{repository}

鍵を追加しても pull が失敗する場合は、誤ったファイルを読み取っている可能性があります。ダウンロードを実行するのはサーバーであり、サーバーは自身の鍵を使用します。systemd で起動されたサーバーはユーザーの ~/.ollama を読み込まないため、ホームディレクトリにある鍵は Hugging Face 側からは認識されません。

モデルはVPSに収まりますか？

これを決定する数値は、ディスク上のファイルサイズと、コンテキストウィンドウが必要とするメモリ量の合計です。重みはファイルサイズに近い容量でメモリにロードされ、その上にトークン数に応じて増加するコンテキスト割り当てが加わります。ollama listを実行してOllamaが記録したモデルサイズを確認し、サーバー上のfree -hと比較してください。その際、OSや他のプロセス用に余裕を持たせる必要があります。実際のモデルで計算例を確認したい場合は、VPSでのNemotron 3.5 Lightningの実行を参照してください。取得すべき正確なタグ、必要なRAM容量、CPUのみの環境で動作可能かどうかが記載されています。

コンテキストは忘れられがちな要素です。デフォルトのウィンドウサイズでロードされるモデルでも、num_ctxを増やすと失敗することがあります。これは、割り当て量が指定したウィンドウサイズに応じて拡大するためです。num_ctxの設定とメモリ消費量にサイジングの詳細があります。合計が大きすぎる場合の解決策は、通常、同じモデルのより小さい量子化版を使用することです。これについてはQ4とQ8の比較で解説しています。

失敗は明確に発生します。CPUのみのVPSでは、カーネルのout of memory killerがプロセスを停止させ、journalctl -u ollama -n 50とdmesgでその終了を確認できます。GPU搭載のサーバーでは、ollama psを実行するとPROCESSOR列が表示され、ロードされたモデルがGPUメモリ、システムメモリ、あるいはその両方に分割されて配置されたかが分かります。システムメモリに溢れたモデルでも応答はしますが、動作は低速になります。1秒あたりのトークン数の測定では、「低速」を量子化版間で比較可能な数値に変換する方法を説明しています。

インポート内容の確認

インポート後は、以下の順序でこれら4つのコマンドを実行してください。

ollama list
ollama show my-model
ollama show --modelfile my-model
ollama run my-model "Reply with one short sentence."

ollama list はモデルが存在することと、Ollama が記録したサイズを表示します。ollama show は、Ollama が GGUF から必要なメタデータを読み取ったことを証明します。ollama show --modelfile は、実際に使用されるテンプレートとパラメータを確認します。これは、ユーザーが遭遇する前に不適切な出力が発生する不具合を未然に防ぐためのチェックです。テストプロンプトは一連の処理全体を検証します。テンプレートが壊れているモデルは、極めて短いリクエストでも失敗するためです。プロンプトが正常に返されたら、そのモデル名は、自身のサーバーを指定したコーディングエージェントを含む、Ollama API と通信するあらゆるツールで使用する名前となります。インポートに失敗した場合は ollama rm my-model で削除し、再度ビルドしてください。このコマンドは Ollama 側のコピーのみを削除し、ソースである .gguf には影響を与えません。

FAQ

GGUF を Modelfile を書かずに Ollama へインポートできますか？

はい。ファイルが Hugging Face リポジトリにある場合は可能です。ollama run hf.co/{username}/{repository} で直接取得して実行でき、ollama run hf.co/{username}/{repository}:{quantization} で特定の量子化形式を選択できます。自分のディスク上にすでにある .gguf には Modelfile が必要ですが、その場合は FROM /path/to/file.gguf という 1 行だけを記述し、その後に ollama create my-model を実行できます。

指定しない場合、Ollama はどの量子化形式をダウンロードしますか？

2026 年 10 月 10 日に確認した Hugging Face のドキュメントでは、その量子化形式がリポジトリに存在する場合は Q4_K_M が使用され、存在しない場合は、リポジトリ内にある妥当な量子化形式が Ollama によって選択されると説明されています。:Q8_0 のようなタグを追加すると、使用する形式を指定できます。実際に取得したファイルについては ollama show <model> で確認できます。これはファイル名ではなく、ファイルのメタデータに記録された量子化形式を表示します。

インポートしたモデルが同じ内容を繰り返したり、生成を停止しなかったりするのはなぜですか？

チャットテンプレートがモデルと一致していません。Ollama は GGUF 内の tokenizer.chat_template メタデータからテンプレートを自動選択します。このメタデータがないか認識されない場合は汎用ラッパーが使用されるため、モデルは学習時に使用したターン終了マーカーを認識できません。ollama show --template <model> で現在のテンプレートを表示し、Modelfile に TEMPLATE ブロックと PARAMETER stop 行を追加して、もう一度 ollama create を実行してください。Go template 形式で記述します。元のリポジトリにある Jinja テンプレートは使用できません。

ダウンロードした GGUF に --quantize を使用すべきですか？

いいえ。--quantize は ollama create 中の safetensors インポートでのみ機能し、FP16 や FP32 を含むすべての GGUF ソースを拒否します。その際、インポート前に GGUF モデルを量子化する必要があることを示すエラーが表示されます。Q4_K_M のようにファイル名に量子化形式が含まれているファイルは、すでに変換済みです。再度量子化しても、失われた精度は戻りません。llama-quantize --allow-requantize で Q8_0 に変換することはできますが、結果のファイルは大きくなるだけで、品質は向上しません。完全精度の GGUF から小さいファイルを作るには、llama.cpp の llama-quantize を実行してから、結果をインポートしてください。

非公開の GGUF リポジトリを取得するにはどうすればよいですか？

Ollama の SSH 公開鍵を Hugging Face アカウントに追加します。標準的な Linux インストールでは sudo cat /usr/share/ollama/.ollama/id_ed25519.pub で鍵を表示できます。自分のユーザーとしてサーバーを実行している場合は ~/.ollama/id_ed25519.pub で表示できます。その後、アカウントの SSH key 設定ページで鍵を追加します。これで、ollama run hf.co/{username}/{repository} を使用して、自分が所有する非公開リポジトリと、所属する組織のリポジトリを取得できます。