著者 OllamaでQwen 3.8 27BをVPSで動かす方法
OllamaにQwen 3.8はまだありません。実在する27BタグをCPUのみのVPSで動かす計算を示し、8〜64 GBで何が収まるかを解説します。
GPU なしの VPS で Qwen 3.8 27B を実行できますか？
VPS で Qwen 3.8 27B を実行するには、まず実在するモデルタグが必要です。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 page で最新の一覧を確認してください。後から実際の qwen3.8 がリリースされても、ここでの計算はそのまま適用できます。計算はバージョン番号ではなく、パラメーター数と重みあたりのビット数に基づいているためです。
取得する Ollama タグと確認方法
存在しないタグを pull すると明確なエラーが表示されるため、対象のマシン上ですぐに判断できます。存在するタグでも、ローカルでは実行できない場合があります。ライブラリには掲載されていますが、Ollama のクラウドからのみ提供される GLM 5.2 で混乱しやすいのはこの点です。
ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist
ollama pull qwen3.6:27b
ollama show qwen3.6:27bollama show では、実際に取得したタグのアーキテクチャ、パラメータ数、コンテキスト長、量子化方式が表示されます。パラメータの行が 27.8B で、量子化の行が Q4_K_M なら、このガイドが前提とするビルドです。ライブラリには、同じ重みをより高精度で提供する qwen3.6:27b-q8_0 と qwen3.6:27b-bf16 もあります。また、CPU 上での動作が大きく異なる MoE（mixture of experts）モデルの 35b-a3b タグも複数あります。これらについては後述します。
パラメータ数と重みあたりのビット数の積
The data behind this chart
[
{
"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 形式では、すべてのテンソルを公称ビット幅で格納するわけではありません。圧縮による品質低下が大きいテンソルは 5 ビットまたは 6 ビットで保持し、token embedding と出力層は通常 Q6_K または Q8_0 のままにします。形式名が示すのは平均値であり、実際の平均は 4.9 付近になります。同じことがスケールの反対側にも当てはまります。BF16 の 56 GB は、重みあたり 16.1 ビットです。単純な 16 ビットではありません。ファイルにはメタデータとフル精度の embedding table も含まれるためです。
このモデルには Q5_K_M の公開タグがないため、19.8 GB の行は実測値ではなく、この形式で通常使われる重みあたり 5.7 ビットを基に計算しています。Q8_0 は Q4 のほぼ 2 倍で、30 GB になります。CPU のみの環境では、この差により token あたりのメモリ転送量も 2 倍になるため、1 秒あたりの token 数もおおむね半分になります。そのため、この点だけを見ても Q4_K_M が適切なデフォルトです。メモリ使用量ではなく、この選択による品質面を確認したい場合は、Q4、Q8、fp16 の詳しい比較で出力が実際に低下し始める箇所を確認できます。
コンテキストが長くなると KV キャッシュにかかるコスト
重みは固定費です。KV キャッシュ（key と value のキャッシュ。モデルがすでに処理した各トークンの attention 状態を保持するもの）はコンテキスト長に比例して増加し、多くの場合、実際に RAM が不足する原因になります。
The data behind this chart
[
{
"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 モデルで採用している構成を前提にしています。64 層、GQA（grouped-query attention）による 8 個の key/value ヘッド、head dimension 128 です。f16 では 1 トークンあたり 256 KiB になり、32k トークンでは 8 GB、128k では 32 GB です。自分の環境でも同じ結果になるとは限りません。モデルを読み込み、重み、キャッシュ、オーバーヘッドの合計値を示す ollama ps の SIZE 列を確認してください。
モデルカードに記載された 256K コンテキストは、実際の計画というより見出しにすぎません。f16 で上限まで使用すると、重みに加えて 64 GB のキャッシュが必要です。そのマシンでは、すでに重みに 17 GB を使用しています。Ollama はデフォルトでウィンドウ全体を割り当てません。はるかに小さいウィンドウを読み込み、OLLAMA_CONTEXT_LENGTH で意図的に大きくします。このサーバー全体の変数だけが設定手段ではありません。個々のリクエストで num_ctx を設定すると、その他の処理には小さいデフォルト値を維持しながら、長時間のジョブだけ大きなウィンドウを割り当てられます。段階的に値を上げ、変更するたびに 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 をデフォルトのままにすると、見積もったキャッシュ容量が気付かないうちに倍増します。このマシンを複数人で使用する場合、問題の起点はこの増加です。self-hosted モデルが同時に処理できるユーザー数は、core count よりはるか前に、キャッシュスロット数とキューの深さによって決まります。
8、16、32、64 GB の RAM に収まる内容
The data behind this chart
[
{
"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 を使用した場合の 1000 トークン単位で示しています。対象は、OS 用に約 1.5 GB と少しの余裕を残した、ヘッドレスの Linux VPS です。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 推論はどの程度高速か
密モデルで 1 トークンを生成するには、すべての重みをメモリから 1 回読み取る必要があります。一部だけではありません。すべてです。したがって速度の上限を決めるのはコア数ではなく、メモリ帯域幅を重みのサイズで割った値です。Q4 では、1 トークンあたり 17 GB のメモリトラフィックが発生します。
The data behind this chart
[
{
"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 の上限は毎秒 3 トークンなので、実際には毎秒 2 トークン程度を見込んでください。2 チャネル DDR5-4800 のサーバーの上限は 4.5 なので、毎秒 3 トークン程度を見込めます。
大規模サーバーの行には注意が必要です。12 チャネルの EPYC プラットフォームではメモリ帯域幅が 460.8 GB/s、上限が毎秒 27.1 トークンですが、EPYC 全体を借りるわけではありません。メモリ帯域幅はホスト全体で共有されるリソースです。同じマシン上のすべてのテナントが使用するため、8 vCPU のスライスに 12 チャネル分の専用帯域幅が付属するわけではありません。GPU に重点を置いたガイドでは、この点が完全に省略されています。そのため、同じモデルで vCPU 数が同じ VPS プランでも、速度が 3 倍異なることがあります。
同じ理由で、vCPU を増やしても早い段階で効果がなくなります。コアがメモリコントローラーの供給速度を上回る速度でデータを要求すると、追加スレッドはスケジューリングのオーバーヘッドを増やすだけで、ほかの効果はありません。OLLAMA_NUM_THREAD には物理コア数を設定して測定し、その後で半分の値も試してください。共有プランでは、低い設定のほうが高速になることがよくあります。
プロンプト処理は動作が異なります。プリフィルは、最初のトークンが表示される前に入力全体を処理する段階です。これは帯域幅ではなく計算能力に制限されるため、コア数に応じて速度が向上します。実際には、大きなプロンプトでは出力が始まるまで長く待たされ、その後に上記の低速で安定した生成速度が続きます。--verbose で両方の段階を個別に計測できます。--verbose はリクエストごとに prompt eval rate と eval rate を出力します。
密モデルの 27B が遅すぎる場合は、CPU を諦める前に qwen3.6:35b-a3b タグを確認してください。これらのタグでは、27.8 billion 個のパラメーターすべてではなく、1 トークンあたりおよそ 3 billion 個のパラメーターだけを有効にします。そのため、ディスク上のファイルは大きくなりますが、1 トークンあたりのメモリトラフィックはほぼ 1 桁減少します。RAM 使用量と速度を引き換えます。ここではランタイムの選択も重要です。同じ基盤の推論コードを使用していても、Ollama と llama.cpp では CPU チューニング用の制御項目が異なります。
GPU 時間を借りるべき場合
The data behind this chart
[
{
"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 のコンシューマー向けカードでは、これらの重みに対する上限は 59 tokens per second です。現行のデータセンター向けカードでは 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 -gollama --version は 0.32.5 以降を出力する必要があります。何かを pull する前に free -g を確認してください。Mem 行の total 列が 32 未満の場合は、ここで中止して小さいモデルを選択してください。実行できない 17 GB のモデルを pull すると、1 時間と大量のディスク容量を無駄にするためです。
ランタイムオプションは、shell ではなく 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 を再読み込みすると、リクエストの処理自体より時間がかかるためです。デフォルトのアイドルタイムアウトは 5 分です。短すぎるため、項目間に間隔がある batch queue では、その読み込みコストが何度も発生します。モデルを常駐させるためのオプションでは、リクエスト単位の keep_alive フィールドと、再起動後も設定を維持する方法の両方を扱います。
モデルの読み込み中に、別の terminal でメモリ使用量を確認します。
ollama psSIZE 列は、KV cache を含む実際のメモリ使用量です。weights と、KV chart にある使用コンテキスト長の行の合計に近い値になるはずです。8 ビットの cache で 8192 tokens を使用する場合、weights に加えて約 1 GB を見込みます。cache が f16 のままなら 2 GB になります。PROCESSOR 列は 100% CPU と表示されるはずです。それ以外の場合は、何らかのプロセスが GPU を使用しています。その場合、このガイドの速度測定値はあなたのマシンには当てはまりません。
失敗する場合と表示される正確な文字列
モデルの読み込みに失敗する。 Ollama は、両方の数値を示す行を model requires more system memory (18.6 GiB) than is available (15.2 GiB) の形式で出力します。これは、kernel に処理を任せる前に Ollama が確認しているため、望ましい失敗です。コンテキスト長を短くするか、より小さい tag に変更するか、より大きいプランへ移行します。
応答の途中でプロセスが消える。 client には有用な情報が表示されず、journalctl -u ollama -n 50 には service が再起動していることが表示されます。dmesg -T | tail を実行し、Out of memory: Killed process ... (ollama) と表示された行があれば、kernel の OOM killer がプロセスを終了させています。事前の読み込みチェックには通過したものの、長い会話中に cache が見積もりを超えて増大すると発生します。コンテキスト長を短くします。
pull がすぐに失敗する。 Error: pull model manifest: file does not exist は、その tag が library に存在しないことを示します。qwen3.8:27b と入力するとこのメッセージがそのまま表示され、version number の入力ミスでも同じ結果になります。network を疑う前に、library page で tag を確認します。
すべて動作するが、耐えられないほど遅い。 RAM が十分なマシンで 1 秒あたり 1 token 未満になる場合は、compute ではなく paging が原因と考えられます。生成中に vmstat 1 を実行します。si または so の column が 0 以外なら、kernel が swap を使用しています。コンテキストを短くするか、読み込むモデル数を減らします。swap の動作がないのに wa が継続的に高い場合は、memory-mapped weights が disk から再読み込みされています。つまり、weights が実際にはメモリに収まっていません。
最初の token まで 30 秒かかり、その後は出力が速くなる。 これは prefill であり、正常な動作です。長い system prompt は cache を利用できないリクエストごとに処理する必要があります。ほかの調整を行う前に、system prompt を短くします。
CPUのみの27Bモデルで実際にできること
期待ではなく、数値を基準に見積もってください。1秒あたり2〜4トークンでは、500トークンの回答に2〜4分かかります。これはチャットには使えませんが、キュー処理には十分実用的です。回答前に思考するモデルでは、非表示の推論トークンも回答と同じ低速で生成されるため、この計算結果はさらに悪化します。そのため、モデルを入れ替えずに回答時間を短縮する手段は、タスクに応じて推論の強度を合わせることなど、限られています。文書の要約、大量のタグ付け、ファイルのバックログからのフィールド抽出、無人でのコードレビューは、回答を待つ必要がないため、この速度でも問題ありません。コーディング支援はその境界にあります。したがって、自分でホストするモデルをコーディングエージェントに指定することは、コミットメッセージやテストの雛形などのバックグラウンド処理には有効ですが、入力中に待つインライン候補には向きません。
本当の利点はプライバシーです。モデルは自分が借りて管理するハードウェア上で実行され、リクエストがサーバー外へ出ることはなく、トークン単位の料金も発生しません。1秒あたり3トークンでも、規制対象データを扱う場合は大きな価値があります。ただし、代替案と正直に比較してください。フロンティア規模のモデルをセルフホストするには桁違いに多くのハードウェアが必要です。そのため、CPU上の27Bモデルは、出力をまだ読む価値がある範囲で最も安価な選択肢です。
Ollamaを初めてインストールする場合は、VPSでOllamaを実行する手順の全体版で、このガイドが前提とするサービス設定、HTTP API、ファイアウォールルールを確認してください。ポート11434をインターネットに公開しないでください。Ollamaには認証機能が組み込まれていないため、そのポートに到達できるすべての相手がモデルを使用し、プロンプトを読み取れます。
FAQ
Ollama に Qwen 3.8 27B モデルはありますか？
いいえ。2026 年 8 月 4 日時点で、Ollama ライブラリに qwen3.8 namespace はありません。存在する 27B タグは qwen3.5:27b と qwen3.6:27b で、どちらも 278 億パラメーターの dense モデルを 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、OS には約 1.5 GB が必要で、KV cache は f16 のコンテキスト 4000 トークンごとに約 1 GB を追加で消費します。16 GB のプランでは重み自体を保持できません。ファイルは memory-mapped で読み込まれるため、swap も役に立ちません。カーネルがトークンごとにディスクから再読み込みするだけだからです。64 GB あれば、長いコンテキストや、30 GB の Q8_0 重みを使用できます。
CPU で 27B モデルを実行すると、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 が有利です。