OllamaでQwen 3.8 27BをVPSで動かす方法

GPU なしの VPS で Qwen 3.8 27B を実行できますか？

Qwen 3.8 27B を VPS で実行するには、まず実在するモデルタグが必要です。2026 年 8 月 4 日時点で、Ollama library には qwen3.8 のエントリがまったくありません。現在リリースされている最も近い 27B タグは qwen3.6:27b です。パラメータ数は 27.8 billion、量子化方式は Q4_K_M、ライセンスは Apache 2.0 です。以下のコマンドと数値はすべて、2026 年 7 月 27 日に公開された Ollama v0.32.5 で、このタグを使用する前提です。

短く答えると、32 GB 以上の VPS なら実行できます。ただし、速度は遅くなります。Q4 の 27B dense model では、コンテキストを 1 token も保存していない状態でも、重みだけで約 17 GB の RAM が必要です。そのため、8 GB と 16 GB のプランでは完全に不足します。一般的な 2 チャネル DDR4 VPS では、上限はおよそ 3 tokens per second です。これは多くの人の読解速度を下回ります。

3.8 はどこから来たのでしょうか。最も可能性が高いのは、パラメータ数の取り違えです。qwen3.6:27b の Ollama ページには 27.8B parameters と記載されており、27.8 は後から 3.8 として思い出しやすい数字です。また、前のリリースの同じ Q4_K_M build である qwen3.5:27b もあります。コマンドをコピーする前に、Ollama の qwen3.6 tag ページで最新の一覧を確認してください。後日、本物の qwen3.8 がリリースされても、ここでの計算は引き続き適用できます。計算はバージョン番号ではなく、パラメータ数と重み 1 個あたりのビット数に基づくためです。

取得する Ollama tag と確認方法

存在しない tag を取得すると明確なエラーが表示されるため、実際のサーバー上ですぐに確認できます。

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show では、実際に取得した tag のアーキテクチャ、パラメータ数、コンテキスト長、量子化方式が表示されます。パラメータの行が 27.8B で、量子化の行が Q4_K_M なら、このガイドが前提とする build です。同じ重みには、より高精度な qwen3.6:27b-q8_0 と qwen3.6:27b-bf16 も用意されています。また、CPU 上では動作が大きく異なる MoE（mixture of experts）モデルの 35b-a3b tag もあります。これらについては後述します。

パラメータ数に 1 重みあたりのバイト数を掛ける

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

式は 1 行です。重みのバイト数 = パラメータ数 * 重みあたりのビット数 / 8 です。正確に 4 ビットなら、27.8 billion パラメータは 13.9 GB になります。提供されている Q4_K_M タグは 17 GB であり、実際には重みあたり 4.89 ビットになります。

この差はエラーではありません。K-quant 形式では、すべての tensor を公称ビット幅で保存するわけではありません。圧縮による品質低下が大きい tensor は 5 または 6 ビットで保持し、token embedding と出力層は通常 Q6_K または Q8_0 のままにします。形式名が示すのは平均値であり、平均すると約 4.9 になります。同じことがスケールの反対側にも当てはまります。BF16 の 56 GB は、単純な 16 ビットではなく、重みあたり 16.1 ビットです。ファイルには metadata と full-precision の embedding table も含まれるためです。

このモデルには Q5_K_M の公開タグがないため、19.8 GB の行は実測値ではなく、この形式で一般的な重みあたり 5.7 ビットとして計算しています。Q8_0 では Q4 のほぼ 2 倍となり、30 GB になります。CPU のみのマシンでは、この増加により token あたりのメモリトラフィックも 2 倍になるため、tokens per second もおおむね半分になります。この理由だけでも、ここでは Q4_K_M が適切なデフォルトです。

コンテキストが長くなると KV キャッシュにかかるコスト

重みのコストは固定です。KV キャッシュ（key と value のキャッシュ。モデルがこれまでに処理した各トークンについて保持する attention の状態）はコンテキスト長に比例して増加し、多くの場合、実際に RAM が不足する主な原因になります。

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

この数値は、Qwen がこのサイズ帯の最近の dense model で採用している構成を前提にしています。64 層、GQA（grouped-query attention）で 8 個の key/value head、head dimension は 128 です。f16 では 1 トークンあたり 256 KiB となるため、32k トークンでは 8 GB、128k では 32 GB です。この計算結果を自分の環境で確認せず、そのまま信頼しないでください。モデルをロードし、ollama ps の SIZE 列を確認してください。ここには重み、キャッシュ、オーバーヘッドを合計した値が表示されます。

そのため、model card に記載された 256K のコンテキストは、実際の運用計画というより見出しに近いものです。f16 で上限まで使用すると、重みにすでに 17 GB を使っているマシンで、さらに 64 GB のキャッシュが必要になります。Ollama はデフォルトではウィンドウ全体を割り当てません。より小さいウィンドウをロードし、OLLAMA_CONTEXT_LENGTH で意図的に拡大します。段階的に増やし、変更するたびに ollama ps を確認してください。

キャッシュを半分以下に減らせる設定が 2 つあります。OLLAMA_KV_CACHE_TYPE=q8_0 を使うと、キャッシュを 16 ビットではなく 8 ビットで保存するため、32k トークン時の容量を 8 GB から 4 GB に減らせます。flash attention が必要なので、OLLAMA_FLASH_ATTENTION=1 も設定してください。適用されたと推測せず、ollama ps で削減を確認してください。OLLAMA_NUM_PARALLEL=1 も同じくらい重要です。Ollama は複数のリクエストを同時に処理でき、各スロットがそれぞれコンテキストの領域を持ちます。そのため、parallelism をデフォルトのままにすると、見積もったキャッシュ容量が気付かないうちに倍増します。

8、16、32、64 GB の RAM に収まるもの

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

2 つの数値は、重みと同時に確保できるコンテキストの量を、f16 キャッシュ、ヘッドレスの Linux VPS、OS 用に約 1.5 GB と追加の小さな余裕を残した条件で、数千トークン単位で示しています。0 は重み自体が収まらないことを示すため、何も収まりません。

8 GB と 16 GB は、ぎりぎりの差ではありません。17 GB の重みは 16 GB の RAM には収まらず、コンテキスト設定を変更しても解決しません。swap を追加しても救済にはなりません。Ollama は GGUF ファイルをメモリーマップするため、常駐ページが RAM を超えると、カーネルはページの追い出しと再読み込みを始めます。その結果、各トークンの生成でディスクから数 GB を読み込むことになります。サーバーは高い iowait の状態になり、1 秒あたり 1 トークンを大幅に下回る速度しか出ません。

32 GB が実用上の出発点です。重みが 17 GB を使用し、約 13 GB が残ります。この容量なら、余裕を見て f16 コンテキストを約 32k トークン確保できます。30 GB の Q8_0 の重みは、この容量にはまったく収まりません。

64 GB なら余裕があります。Q4 では約 128k トークンのコンテキストを確保でき、Q8_0 の重みでも約 64k トークン分の余裕が残ります。Q8 を使うためだけに 64 GB の RAM に料金を払う前に、何を得るのかを明確にしてください。すでに低速なマシンで、出力品質が少し向上する代わりに速度が半分になります。ほとんどの場合、より長いコンテキストを使える Q4 のほうが適切な選択です。

VPS での CPU 推論はどの程度高速ですか？

dense model で 1 token を生成するには、すべての重みをメモリから 1 回読み取る必要があります。一部だけではありません。すべてです。そのため速度を決めるのはコア数ではなく、メモリ帯域幅を重みのサイズで割った値です。Q4 では、1 token あたりのメモリトラフィックは 17 GB です。

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

これは測定値ではなく上限値です。実際の出力速度は、表示された値の 50〜70% 程度になります。メモリレイテンシと不完全なプリフェッチにより、理論上の最大値には到達できないためです。2 チャネル DDR4-3200 の VPS では上限が 1 秒あたり 3 token なので、実際には約 2 token/秒を見込みます。2 チャネル DDR5-4800 のサーバーでは上限が 4.5 token/秒なので、約 3 token/秒を見込みます。

大規模サーバーの行には注意が必要です。12 チャネルの EPYC プラットフォームは 460.8 GB/s の帯域幅と、1 秒あたり 27.1 token の上限を備えます。ただし、EPYC 全体を借りるわけではありません。メモリ帯域幅はそのホスト上のすべてのテナントで共有するホスト全体のリソースです。そのため、8 vCPU のスライスに 12 チャネル分の専用帯域幅が付属するわけではありません。GPU に重点を置いたガイドでは、この点が完全に省略されています。同じモデルでも、vCPU 数が同じ 2 つの VPS プランで速度が 3 倍異なる理由はここにあります。

同じ理由で、vCPU を増やしても早い段階で効果がなくなります。コアがメモリコントローラーの供給速度を超えてデータを要求すると、追加スレッドはスケジューリングのオーバーヘッドを増やすだけで、ほかの効果はありません。OLLAMA_NUM_THREAD には物理コア数を設定して測定し、その後で半分の値も試してください。共有プランでは、低い設定のほうが速いことが多くあります。

プロンプト処理は異なる動作をします。Prefill は、最初の token が表示される前に入力全体を処理する段階です。これは帯域幅律速ではなく計算律速なので、コア数に応じて速度が上がります。実際には、大きなプロンプトでは出力が始まるまで長く待たされ、その後に上記の遅い安定した速度が続きます。--verbose を使って両方の処理時間を個別に測定できます。このコマンドは各リクエストについて prompt eval rate と eval rate を出力します。

dense 27B が遅すぎる場合は、CPU を諦める前に qwen3.6:35b-a3b タグを確認してください。これらを使用すると、27.8 billion 個すべてではなく、1 token あたりおよそ 3 billion 個のパラメーターだけが有効になります。そのため、ディスク上のファイルは大きくなりますが、1 token あたりのメモリトラフィックは 1 桁近く減少します。RAM 使用量と速度を交換する構成です。ここでは runtime の選択も重要です。同じ基盤の推論コードを使用していても、Ollama と llama.cpp では CPU チューニング用の制御項目が異なります。

GPU を時間単位で借りるべき場合

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

公開されている GPU メモリ帯域幅に同じ計算式を適用すると、答えの分類が変わります。24 GB のコンシューマー向けカードでは、これらの重みに対する上限は 1 秒あたり 59 トークンです。現行のデータセンター向けカードでは 197 に達します。これはスレッド数の調整で埋められる差ではありません。カードは 1008 GB/s でメモリを動作させますが、VPS では数十 GB/s にとどまります。

そのため、好みではなくワークロードで線引きします。非同期で、処理中に誰も待っていない場合は CPU 推論が適しています。たとえば、文書群の夜間要約や、就寝中に実行する毎晩の分類ジョブです。人が出力を待つようになった時点、または 30 秒に 1 回より速い頻度でリクエストが届くようになった時点で、GPU を借りてください。CPU のみの環境にはバッチ処理の余裕がなく、キューが増え続けるためです。

コスト比較は、見た目ほど単純ではありません。64 GB の VPS はモデルをロードしていない時間も含め、毎月すべての時間に対して課金されます。一方、GPU インスタンスは稼働させた時間だけ課金されます。実際の利用時間が 1 日 2 時間なら、借りた GPU のほうが高速で安価になる場合があります。まず稼働率を計算し、その後で料金を比較してください。GPU 付き VPS の選び方では、インスタンス自体で確認すべき点を説明しています。また、GPU 上で同時リクエストを処理する場合は、適切にバッチ処理を行うため、GPU で同時リクエストを処理すると vLLM が Ollama を上回る理由も参照してください。

忘れられがちな 3 つ目の選択肢もあります。バッチ処理では 27B を CPU 上で動かし、対話処理にはホスト型 API モデルを前段に置きます。1 つのモデルで両方を処理する必要はありません。

Ollama をインストールして自分のマシンを測定する

インストールスクリプトは公式のものです。専用の ollama ユーザーで実行する systemd サービスを設定します。

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version は 0.32.5 以降を出力するはずです。何かを pull する前に free -g を確認してください。Mem 行の total 列が 32 未満の場合は、ここで中止して小さいモデルを選んでください。実行できない 17 GB のモデルを pull すると、1 時間と大量のディスク容量を無駄にするためです。

ランタイムのオプションはシェルではなく、systemd の override に設定してください。モデルはサービス内で実行されるため、対話シェルの環境は引き継がれません。

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

--verbose の出力が、測定したかった結果です。eval rate は生成中の tokens per second です。prompt eval rate は prefill の速度です。load duration はディスクから weights を読み取るのにかかった時間です。そのため OLLAMA_KEEP_ALIVE=60m を設定しています。CPU では、リクエストごとにディスクから 17 GB の weights を再読み込みすると、リクエスト自体よりも時間がかかるためです。

モデルの読み込み中に、別の端末からメモリ使用量を確認してください。

ollama ps

SIZE 列は KV cache を含む実際のメモリ使用量です。KV chart で、weights に使用するコンテキスト長の行を加えた値に近くなるはずです。8-bit cache で 8192 tokens を使用する場合、weights に加えて約 1 GB を見込んでください。cache が f16 のままの場合は 2 GB になります。PROCESSOR 列は 100% CPU になるはずです。それ以外の場合は、何らかのプロセスが GPU を使用しています。このガイドの速度の数値は、そのマシンには当てはまりません。

失敗パターンと表示される正確な文字列

モデルの読み込みに失敗する。 Ollama は、2 つの値を示す行を model requires more system memory (18.6 GiB) than is available (15.2 GiB) の形式で出力します。これは、カーネルに処理を任せず、割り当て前に Ollama が確認した結果なので、望ましい失敗です。コンテキスト長を短くするか、より小さい tag に切り替えるか、より大きなプランへ移行します。

回答の途中でプロセスが消える。 クライアントには有用な情報が表示されず、journalctl -u ollama -n 50 にはサービスの再起動が表示されます。dmesg -T | tail を実行し、Out of memory: Killed process ... (ollama) という行があれば、カーネルの OOM killer がプロセスを終了しています。これは、事前読み込み時の確認には通過したものの、長い会話の途中で cache が見積もりを超えて増大した場合に発生します。コンテキスト長を短くします。

pull が直ちに失敗する。 Error: pull model manifest: file does not exist は、その tag が library に存在しないことを示します。qwen3.8:27b と入力すると、まったく同じ結果になります。バージョン番号の入力ミスでも同様です。ネットワークを疑う前に、library のページで tag を確認します。

すべて動作するが、耐えられないほど遅い。 十分な RAM があるマシンで 1 秒あたり 1 token 未満になる場合は、compute ではなく paging が原因と考えられます。生成中に vmstat 1 を実行します。si または so 列が 0 以外の場合、カーネルが swap を使用しています。コンテキストを短くするか、読み込むモデルを減らします。swap の動作がないのに wa が継続的に高い場合、memory-mapped の重みがディスクから再読み込みされています。これは、重みが実際にはメモリに収まっていないことを意味します。

最初の token まで 30 秒かかり、その後は出力が速くなる。 これは prefill であり、正常な動作です。cache を利用できないリクエストでは、長い system prompt の処理コストが毎回発生します。ほかの調整を行う前に、system prompt を短くします。

CPU のみで動かす 27B が実際に得意とする用途

期待ではなく、数値を基準に見積もります。1 秒あたり 2〜4 tokens では、500 tokens の回答に 2〜4 分かかります。これはチャットには使えませんが、キュー処理には十分実用的です。文書の要約、大量のタグ付け、ファイル群からのフィールド抽出、無人でのコードレビューには適しています。どれも応答を待つ必要がないためです。

本質的な利点はプライバシーです。モデルは利用者が借りて管理するハードウェア上で動作し、リクエストがそのサーバーの外部へ出ることはなく、token ごとの料金も発生しません。1 秒あたり 3 tokens でも、規制対象データを扱う場合には大きな価値があります。ただし、代替手段と正直に比較してください。最先端規模のモデルをセルフホストするには桁違いに多くのハードウェアが必要です。CPU 上の 27B は、その曲線上で、出力を読む価値がまだある最も安価な地点です。

Ollama のインストールが初めての場合は、VPS で Ollama を実行するための完全な手順で、このガイドが前提とするサービス設定、HTTP API、ファイアウォールルールを確認できます。ポート 11434 をインターネットに公開しないでください。Ollama には認証機能が組み込まれていないため、そのポートに到達できるものは誰でもモデルを使用し、プロンプトを読み取れます。

FAQ

Ollama に Qwen 3.8 27B モデルはありますか？

いいえ。2026 年 8 月 4 日時点で、Ollama のライブラリに qwen3.8 名前空間はありません。存在する 27B タグは qwen3.5:27b と qwen3.6:27b で、どちらも 278 億パラメーターの密モデルを Q4_K_M でビルドしたものです。検索語に含まれる 3.8 は、27.8B というパラメーター数をバージョン番号として記憶していたものと考えられます。現在の一覧は https://ollama.com/library/qwen3.6/tags で確認し、最新リリースの 27B が必要なら qwen3.6:27b を pull してください。存在しないタグを指定すると、Error: pull model manifest: file does not exist で失敗します。

VPS で Qwen 27B モデルを実行するには、RAM がどの程度必要ですか？

Q4_K_M では、実用上の最小容量は 32 GB です。重みは 17 GB を占有し、オペレーティングシステムには約 1.5 GB が必要です。さらに、f16 のコンテキストでは、KV キャッシュが 4000 トークンごとに約 1 GB 増加します。16 GB のプランでは重みを保持できず、swap も役に立ちません。ファイルが memory-mapped されているため、カーネルはトークンごとにディスクから再読み込みするだけです。64 GB あれば、長いコンテキストや 30 GB の Q8_0 重みに対応できます。

27B モデルを CPU で実行すると、1 秒あたり何トークン処理できますか？

メモリ帯域幅を重みのサイズで割り、その 50〜70% を目安にしてください。2 チャネル DDR4-3200 の VPS は、上限が 3 トークン/秒付近で、実測値は約 2 です。2 チャネル DDR5-4800 のサーバーは、上限が 4.5 付近で、実測値は約 3 です。チャネル数の多いサーバープラットフォームは仕様上は大幅に高性能に見えますが、ホスト上のすべてのテナントでメモリ帯域幅を共有します。そのため、ollama run qwen3.6:27b --verbose で自分の環境を測定し、eval rate の行を確認してください。

CPU のみの VPS では、Q4 と Q8 のどちらを使うべきですか？

ほとんどの場合、Q4_K_M です。Q8_0 は 30 GB で、17 GB の Q4_K_M より大きいため、64 GB のプランが必要です。また、トークンごとに移動するメモリ量がほぼ 2 倍になり、1 秒あたりのトークン数はおよそ半分になります。27B モデルでは、ほとんどのタスクで Q4_K_M と Q8_0 の品質差は小さいです。RAM は、モデルの言い回しではなく実行可能な内容を変える、より長いコンテキストに回してください。

大容量 RAM の VPS より GPU のレンタルが安くなるのは、どのような場合ですか？

稼働率が低い場合、または人が処理を待っている場合です。メモリ 24 GB の GPU は、これらの重みに対して約 59 トークン/秒に達します。一般的な VPS では 2 または 3 程度です。GPU は稼働した時間分だけ課金されますが、64 GB の VPS はモデルをロードしているかどうかにかかわらず、1 か月分が課金されます。実際に 1 日何時間トークンを生成するのかを計算してください。2〜3 時間未満であれば、時間単位の GPU レンタルが速度とコストの両方で有利になることが一般的です。低優先度のバッチ処理を継続的に実行する場合は、常時稼働する VPS が有利です。