著者 VPSでGLM 5.2を動かす方法と現実的なモデル
OllamaのGLM 5.2はcloudタグのみで、重みは約378 GBです。VPSで動かせるglm-4.7-flashと、量子化ごとに必要なRAMを確認できます。
VPS で GLM 5.2 を実行できますか？
いいえ。VPS を契約する前に、その理由を把握しておく必要があります。2026 年 8 月 18 日時点で、Ollama のライブラリにある GLM 5.2 のタグは glm-5.2:cloud の 1 つだけです。:cloud タグは Ollama のサーバー上で実行されます。サーバーはプロンプトを送信してトークンを受け取るだけなので、重みがディスクに保存されることはありません。モデルのパラメータ数は 7560 億です。7560 億パラメータを 4 bit で保持すると、重みだけで約 378 GB になります。これはコンテキスト、アクティベーション、オペレーティングシステムに必要な容量を含まない単純な計算です。この容量のメモリを提供する標準的な VPS プランはありません。
レンタルサーバーで実行できる GLM モデルは glm-4.7-flash です。ダウンロード可能な重みが 4 個のタグで公開されています。これは mixture-of-experts モデルです。各トークンの処理では、ネットワークの一部だけが実行されます。Z.ai はこのモデルを 30B-A3B と説明しています。総パラメータ数は 300 億で、1 トークンあたり約 30 億のパラメータがアクティブになります。このガイドでは、実際に運用できる問いに答えます。タグを固定し、VPS の容量を決め、自分の環境で速度を測定し、エンドポイントを非公開にしてください。
ここにあるコマンドを含め、コマンドをコピーする前にタグを確認してください。Ollama のライブラリは予告なく変更されます。glm-4.7-flash のタグ一覧を開き、そのタグがまだ存在することを確認してください。ローカルで使用できる重みを持つ新しい GLM リリースが登場している場合は、そちらを優先し、実際にテストしたタグを記録してください。
それでも GLM 5.2 自体を使用したい場合は、ollama run glm-5.2:cloud が ollama signin の後に動作し、クライアント側では他の Ollama モデルと同じように扱えます。ただし、同意する内容を理解してください。プロンプトはサーバーの外部へ送信されます。データをマシン内に保持することがセルフホスティングの目的なら、:cloud タグではその要件を満たせません。
存在する GLM タグと固定すべきタグ
ここで重要なのは、公式の GLM エントリ 3 つです。glm-5.2 と glm-5.1 はクラウド専用です。glm-4.7-flash がローカル版で、以下はその公開タグと、Ollama が各タグについて表示しているダウンロードサイズです。
The data behind this chart
[
{
"label": "q4_K_M",
"download_gb": 19
},
{
"label": "latest",
"download_gb": 19
},
{
"label": "q8_0",
"download_gb": 32
},
{
"label": "bf16",
"download_gb": 60
}
]これらはライブラリページに掲載された値であり、実測値ではありません。latest と q4_K_M はどちらも 19 GB と表示されるため、現在の latest は Q4 ビルドに解決されます。再公開時には変わる可能性があるため、スクリプトや Dockerfile に単独の ollama pull glm-4.7-flash を記述してはいけません。量子化方式まで指定してください。最大のタグである bf16 は、量子化されていない bfloat16 重みを含む 60 GB のダウンロードです。
ライブラリで検索すると、someuser/glm-5.2 のように名前にスラッシュを含む名前空間付きアップロードも表示されます。スラッシュがある場合は、ユーザーアカウントが公開したものです。つまり、公式エントリではなく、コミュニティによる再アップロードです。中身の重みが保証されているわけではありません。オンラインで見つけた署名のないバイナリと同じように扱ってください。
Ollama をインストールし、指定したタグを取得する
Ollama の Linux インストーラーは 1 つのコマンドで実行できます。
curl -fsSL https://ollama.com/install.sh | sh
ollama --versionインストーラーは、ollama ユーザーで実行する systemd サービスを作成します。何かを取得する前に、サービスが起動していることを確認してください。
systemctl status ollama --no-pagerActive: active (running) は、API が 11434 番ポートで待ち受けていることを示します。unit が存在しない場合、インストーラーは通常のバイナリインストールにフォールバックしています。その場合は、Ollama Linux のドキュメントに手動で作成するサービスファイルが記載されています。
glm-4.7-flash のページには、Ollama の最小バージョンが記載されています。古いバイナリではモデルの実行速度が遅くなるのではなく、モデルを拒否します。モデルには新しいバージョンの Ollama が必要だというメッセージが表示され、pull が失敗します。アップグレードするには、インストールスクリプトを再実行してください。2026 年 8 月 18 日時点の最新リリースは 0.32.14 で、この最小バージョンを十分に上回っています。
次に、名前を指定して 1 つのタグを取得します。
ollama pull glm-4.7-flash:q4_K_M
ollama lsollama ls には、公開されている 19 GB に近いサイズの glm-4.7-flash:q4_K_M が表示されます。pull が途中で失敗すると、実行可能な状態のファイルは残りません。そのため、同じコマンドを再実行してください。小規模なプランで pull が失敗する最も一般的な原因は、ネットワークではなくディスク容量の不足です。モデルは root ファイルシステム上の /usr/share/ollama/.ollama/models に書き込まれるためです。開始前に df -h /usr/share/ollama で確認してください。
各量子化方式にはどれだけの RAM が必要ですか？
まずダウンロードサイズを最低ラインとし、そこに必要な容量を加えます。重みはメモリ上に常駐している必要があります。その上に KV cache（key/value cache）が確保されます。これは、ランタイムが会話中にすでに入力されたトークンを保持するために使用するメモリです。さらに、計算用バッファーとオペレーティングシステムが使用するメモリも必要です。RAM がちょうど 19 GB のサーバーでは、19 GB tag は動作しません。
全員に当てはまる単一の倍率はありません。許可するコンテキスト長によって KV cache の容量が増え、その他の使用量もランタイムのバージョンによって変わるためです。そのため、推測せずに測定してください。簡単なプロンプトでモデルをロードし、サーバーが確保した容量を確認します。
ollama run glm-4.7-flash:q4_K_M "Reply with the single word: ready"
ollama psollama ps は、ロードされたモデルを SIZE 列と PROCESSOR 列付きで表示します。SIZE はランタイムが実際に確保した容量です。計画上はこの数値と比較してください。PROCESSOR は処理が行われる場所を示します。100% CPU の場合、GPU はまったく使用されていません。
モデルが収まらない場合、失敗は明確に表示されず、2 つの形で現れます。swap が有効な場合、ロードは成功したように見えますが、その後の生成が極端に遅くなります。トークンごとにページがディスクと RAM の間で移動するためです。swap がない場合、プロセスは即座に kill されます。journalctl -k | grep -i "out of memory" には、ollama を示すカーネルの Out of memory: Killed process 行が表示されます。どちらも、入力していたターミナルには分かりやすいメッセージを表示しないため、両方を確認してください。
19 GB の Q4 tag から 32 GB の Q8 tag への変更が、この容量を左右する主な要素です。Q4 では出力品質が一部低下します。低下の程度はタスクによって異なり、構造化出力や長い推論の連鎖では、雑談よりも影響が大きくなります。CPU のみの VPS では、量子化方式によってモデルが動作するかどうかが決まることが多いため、導入を決める前に Q4、Q8、FP16 の実際の違い を確認してください。
CPU 専用 VPS での動作
ほとんどの VPS プランには GPU がありません。Ollama は警告を表示せず、CPU でモデルを実行します。実用に耐えるかどうかは、ワークロードと待ち時間を許容できるかによって決まります。
Mixture-of-experts 設計により、速度は向上します。1 つのトークンの処理に使用されるのは、30 billion 個のパラメーターのうち約 3 billion 個だけです。そのため、トークンごとの演算量は、dense 30B モデルより大幅に少なくなります。一方、メモリ使用量は減りません。次のトークンでどのエキスパートが選ばれるか分からないため、すべてのエキスパートをメモリ上に常駐させる必要があります。そのため CPU 専用の環境でも、Q4 tag には 19 GB 以上のメモリが必要です。スループットはクロック速度よりも、主にメモリ帯域幅に左右されます。
このため、コア数と RAM 容量が同じ 2 つのプランでも、メモリサブシステムの違いによって生成速度に明確な差が出ることがあります。共有プランでは、別の要因も加わります。他の利用者による CPU steal time が、時間帯によって変化する tokens-per-second の値として現れるためです。これが、他者が公開した数値からあなたの環境の結果を予測できない理由です。また、次のセクションが結果の表ではなく、測定手順になっている理由でもあります。
自分の tokens per second を測定する
Ollama の generate endpoint は、最終 JSON オブジェクトにタイミング情報を返します。生成された token 数を生成時間で割れば、自分のプランとプロンプトにおける値を算出できます。
sudo apt install -y jq
curl -s http://localhost:11434/api/generate -d '{
"model": "glm-4.7-flash:q4_K_M",
"prompt": "Write a 200 word explanation of how TCP congestion control works.",
"stream": false,
"options": {"num_ctx": 8192}
}' | jq '{
tokens: .eval_count,
tokens_per_second: (.eval_count / .eval_duration * 1e9),
prompt_seconds: (.prompt_eval_duration / 1e9),
load_seconds: (.load_duration / 1e9)
}'eval_count は生成された token 数、eval_duration はその生成にかかったナノ秒数です。したがって、eval_count / eval_duration * 1e9 が tokens per second です。prompt_eval_duration はプロンプトの読み込みにかかった時間で、最初の token が表示されるまでの待ち時間に相当します。load_duration はディスクからのモデル読み込みにかかった時間です。そのため、再起動後の最初の呼び出しでは大きくなり、次の呼び出しではほぼ 0 になります。
3 回実行し、2 回目と 3 回目の結果を記録します。1 回目にはモデルの読み込み時間が含まれるためです。次に、入力長を大幅に増やしたプロンプトでも実行します。プロンプト処理時間は入力長に応じて増加しますが、生成速度は変わらないためです。プラン名と量子化方式の横に数値を記録します。これは、他で確認したどのベンチマーク結果よりも有用です。料金を支払っているハードウェア上で測定した値だからです。
コンテキスト長がメモリを増大させる仕組み
Ollama のデフォルトのコンテキストは 4096 トークンです。モデルが対応する上限は glm-4.7-flash の 198K トークンなど、はるかに大きい場合があります。ただし、デフォルトでその値になるわけではなく、有効化にはメモリが必要です。
KV キャッシュは、すべてのレイヤーで、すべてのトークンについて 1 つの key ベクトルと 1 つの value ベクトルを保持します。そのサイズは、許可するトークン数に比例して増加します。4096 トークンから 32768 トークンに増やすと、コンテキストは 8 倍になるため、KV キャッシュもおよそ 8 倍になります。重みを格納するだけでメモリ容量を使い切るサーバーでは、この追加割り当てによって swap が発生します。そのため、短いプロンプトには問題なく応答できていたマシンが、長い文書を貼り付けると突然処理に時間がかかるようになります。
リクエスト単位で、上記の curl コマンドのように options オブジェクト内の num_ctx で設定できます。または、サーバーのデフォルト値を変更します。
sudo install -d -m 755 /etc/systemd/system/ollama.service.d
printf '[Service]\nEnvironment="OLLAMA_CONTEXT_LENGTH=16384"\n' \
| sudo tee /etc/systemd/system/ollama.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment最後のコマンドで OLLAMA_CONTEXT_LENGTH の値が表示されます。空の Environment= が表示される場合は、override ファイルのディレクトリが正しくないか、reload が実行されていません。次回のモデル読み込み後、ollama ps には、4096 の場合より明らかに大きい SIZE が表示されるはずです。値は段階的に増やし、そのたびにこの数値を確認してください。num_ctx で Ollama のコンテキスト長を設定するでは、この設定が keep-alive と並列リクエストにどう影響するかを説明しています。どちらも同じコストを増大させます。複数のクライアントがサーバーを使用する場合は、コンテキスト長と同時実行数の上限を同時に決めてください。並列スロットごとに独自の KV キャッシュを保持するため、queue の設定によって、2 つ目のリクエストを待機させるか、即座に拒否するかが決まります。
API のほうがサーバー本体より安い場合
セルフホストが自動的に安くなるわけではありません。このモデル群では、公開されている定価がその点を特に明確に示しています。
The data behind this chart
[
{
"label": "GLM-5.2 input",
"usd_per_million_tokens": 1.4
},
{
"label": "GLM-5.2 output",
"usd_per_million_tokens": 4.4
},
{
"label": "GLM-4.7-Flash input",
"usd_per_million_tokens": 0
},
{
"label": "GLM-4.7-Flash output",
"usd_per_million_tokens": 0
}
]2026 年 8 月 18 日時点で、Z.ai は GLM-5.2 の入力トークンを 100 万トークンあたり $1.4、出力トークンを 100 万トークンあたり $4.4 と掲載しています。このガイドでローカル実行するモデルである GLM-4.7-Flash は、入力と出力のどちらも $0 です。これらは公開価格であり、変更される可能性があります。そのため、どちらを前提に予算を立てる場合も、計画前に現在の価格ページを確認してください。
したがって、現時点ではセルフホストの費用面での主張 glm-4.7-flash は弱いものです。十分な RAM を備えた VPS には毎月実費がかかります。一方、提供元は同じモデルを無料で提供しています。自分で実行することで得られるものは別の価値です。プロンプトを自分で管理するマシン内に保持でき、変更しない限りモデルのバージョンも変わりません。これらはセルフホストの有力な理由です。このモデルをこの価格で使う限り、コストは理由になりません。
無料ではないモデルを使う場合や、法的な理由でデータを自分のネットワーク外へ出せない場合は、計算結果が変わります。GPU VPS と API トークンの損益分岐点では、各変数を明示してこの計算を説明します。まだマシンを選んでいる段階なら、VPS に実際にかかる月額費用も計算に必要なもう一方の要素です。
localhost でエンドポイントを維持する
ここは省略されがちな手順ですが、最も重要です。
Ollama はデフォルトで 127.0.0.1 のポート 11434 にバインドするため、サーバー自体からしかアクセスできません。思い込みで済ませず、実際のサーバーで確認してください。
ss -ltnp | grep 11434127.0.0.1:11434 が表示されることを確認します。0.0.0.0:11434 または *:11434 が表示される場合、API はパブリックインターフェースを含むすべてのインターフェースで待ち受けています。
これは重要です。Ollama の API には認証がありません。パスワードも、トークンも、許可リストもありません。ポート 11434 に到達できる相手は、モデルの一覧表示、料金を支払っているハードウェアでの生成処理、ディスクが満杯になるまでの新しいモデルの取得、既存モデルの削除を実行できます。ポート 11434 は固定された既知のポートであるため、公開されているポートはスキャナーにすぐ発見されます。
OLLAMA_HOST=0.0.0.0 は設定しないでください。ノート PC 上のクライアントから接続できない場合の解決策として、多くのチュートリアルがこれを勧めていますが、正しい方法ではありません。代わりにポート転送を使用してください。
ssh -N -L 11434:127.0.0.1:11434 you@your-serverこれにより、ノート PC のポート 11434 が SSH 経由でサーバーのループバックアドレスにマッピングされます。そのため、http://localhost:11434 用に設定したクライアントは変更せずに動作し、新たに公開されるものもありません。複数のユーザーやマシンから利用する場合は、サーバーをプライベートなトンネルネットワークに接続し、Ollama をトンネルのアドレスにバインドしてください。0.0.0.0 には決してバインドしないでください。
サーバー以外の場所から確認します。SSH トンネルを閉じた状態で、ノート PC から次を実行してください。
curl -m 5 http://your-server-ip:11434/api/tagscurl: (28) Connection timed out または curl: (7) Failed to connect が正しい結果です。モデルの JSON 一覧が返る場合、ポートがインターネットに公開されているため、直ちに修正が必要です。プロバイダーのネットワークファイアウォールは、サーバー上で稼働するファイアウォールとは別の制御です。両方を確認してください。VPS ホスティングが安全かという、より広い問題では、常時稼働させるマシンに必要な基本的な対策を説明しています。
glm-4.7-flash でもまだ大きすぎる場合
Q4 タグがプランに収まらない場合は、コンテキストを小さくするのではなく、より小さいモデルを選びます。モデルを収めるためにコンテキストを削ると、ロードはできても、最初の長いプロンプトで失敗します。VPS 上で 8B と 27B の Qwen 3 を実行するでは、容量の小さいサーバーに適したサイズで同じインストール手順を説明しています。VPS で Ollama を使って LLM をセルフホストする一般ガイドでは、選択するモデルにかかわらず共通する手順を説明しています。どのモデルを選ぶ場合も、タグを固定し、自分のプランで測定し、エンドポイントは loopback に限定してください。
FAQ
GLM 5.2 は VPS 上でローカル実行できますか？
いいえ。2026 年 8 月 18 日時点で、GLM 5.2 は Ollama のライブラリでは glm-5.2:cloud としてのみ提供されています。これは Ollama 自身のインフラストラクチャー上で実行されるタグで、動作前に ollama signin が必要です。モデルのパラメーター数は 756 billion です。そのため、1 パラメーターあたり 4 ビットにしても、重みだけで数百 GB になり、一般的な VPS プランの容量を大幅に超えます。ダウンロード可能な重みを持ち、レンタルサーバーで実行できる GLM モデルは glm-4.7-flash です。
glm-4.7-flash にはどの程度の RAM が必要ですか？
タグのダウンロードサイズを最低限の容量と考え、KV cache とオペレーティングシステム用の容量を追加してください。Ollama では、Q4 タグが 19 GB、Q8 が 32 GB、bfloat16 タグが 60 GB と表示されます。KV cache は設定したコンテキスト長に応じて増えるため、全員に当てはまる固定倍率はありません。モデルを読み込み、ollama ps を実行して、SIZE 列から自分の環境での実際の値を確認してください。
自分の VPS で 1 秒あたりのトークン数を測定するにはどうすればよいですか？
"stream": false を指定して http://localhost:11434/api/generate に 1 件リクエストを送り、レスポンスから eval_count と eval_duration を確認します。1 秒あたりのトークン数は eval_count / eval_duration * 1e9 です。eval_duration はナノ秒単位で報告されるためです。最初の実行は破棄してください。この実行では load_duration にディスクから重みを読み込む時間が含まれるためです。入力長に応じて prompt_eval_duration は増加しますが、生成速度は変わらないため、長いプロンプトでも繰り返し測定してください。
OLLAMA_HOST を 0.0.0.0 に設定してはいけないのはなぜですか？
Ollama の API には認証がないためです。0.0.0.0 にバインドすると、認証なしのエンドポイントがパブリックインターネット上に公開されます。ポート 11434 に到達できるユーザーは、あなたのハードウェアで生成処理を実行したり、インストールするモデルを変更したりできます。デフォルトの 127.0.0.1 バインドを維持し、ss -ltnp | grep 11434 で確認してください。ラップトップからは、ssh -N -L 11434:127.0.0.1:11434 you@your-server のような SSH トンネル経由で API に接続します。