著者 VPSでGLM 5.2を実行する方法と必要RAM
OllamaのGLM 5.2はクラウド専用です。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 のサーバー上で実行されます。サーバーはプロンプトを送信してトークンを受信するため、モデルの重みがディスクに保存されることはありません。モデルのパラメータ数は 756 billion です。756 billion パラメータを 4 bits で表すと、重みだけでおよそ 378 GB になります。これはコンテキスト、アクティベーション、オペレーティングシステムに必要な容量を含まない単純な計算です。一般的な VPS プランでは、これほど大容量のメモリは提供されていません。
レンタルしたサーバーで実行できる GLM モデルは glm-4.7-flash です。ダウンロード可能な重みが 4 個のタグで公開されています。これは Mixture of Experts モデルです。つまり、各トークンの処理ではネットワークの一部だけが実行されます。Z.ai はこのモデルを 30B-A3B と説明しています。総パラメータ数は 30 billion で、トークンごとにアクティブになるのは約 3 billion です。そのため、このガイドでは実際に対応できる問いに答えます。タグを固定し、サーバーの仕様を決め、自分の環境で速度を測定し、エンドポイントを非公開にしてください。
ここにあるコマンドも含め、コマンドをコピーする前にタグを確認してください。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 documentation には、手動で作成するサービスファイルが記載されています。
glm-4.7-flash ページには、Ollamaの最低バージョンが記載されています。古いバイナリではモデルの実行速度が低下するのではなく、モデルが拒否されます。pullは、モデルに新しいバージョンのOllamaが必要であるというメッセージを表示して失敗します。アップグレードするには、インストールスクリプトを再実行してください。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 キャッシュ（key/value cache）が載ります。これは、ランタイムが会話内の既存のトークンを保持するために使うメモリです。さらに、計算用バッファーと、オペレーティングシステムが使用するメモリも必要です。RAM がちょうど 19 GB のマシンでは、19 GB のタグは実行できません。
すべての環境に当てはまる単一の倍率はありません。許可するコンテキスト長に応じて KV キャッシュが増え、その他の使用量もランタイムのバージョンによって変わるためです。そのため、推測せずに測定してください。簡単なプロンプトでモデルを読み込み、サーバーが確保したメモリ量を確認します。
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 がない場合、プロセスは直ちに強制終了され、journalctl -k | grep -i "out of memory" にカーネルの Out of memory: Killed process 行が表示され、ollama が示されます。どちらも、入力していたターミナルには役立つメッセージを表示しないため、両方を確認してください。
19 GB の Q4 タグから 32 GB の Q8 タグへ移行することが、この値を左右する主な手段です。Q4 では出力品質が一部低下します。低下の程度はタスクによって異なり、構造化出力や長い推論の連鎖では、雑談よりも影響が大きくなります。CPU のみの VPS では、量子化の選択によってモデルが実行できるかどうかが決まることが多いため、導入を決める前に Q4、Q8、FP16 の実際の違い を読む価値があります。
CPU のみの VPS で起きること
ほとんどの VPS プランには GPU がなく、Ollama は警告を出さずに CPU でモデルを実行します。結果が実用になるかどうかは、ワークロードと待ち時間への許容度によって決まります。
Mixture-of-experts 設計により、速度は向上します。特定のトークンでは 30 billion パラメーターのうち約 3 billion だけを使用するため、トークンごとに必要な計算量は、dense 30B モデルより大幅に少なくなります。ただし、メモリ使用量は減りません。次のトークンでどの expert が選ばれるか分からないため、すべての expert をメモリ上に保持する必要があります。そのため、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 はディスクからの model の読み込みにかかった時間です。そのため、再起動後の最初の呼び出しでは大きくなり、次の呼び出しではほぼ 0 になります。
3 回実行し、2 回目と 3 回目の結果を使用します。1 回目には model の読み込み時間が含まれるためです。次に、より長いプロンプトでもう一度実行します。プロンプトの処理時間は入力の長さに応じて増加しますが、生成速度は変わらないためです。数値をプラン名と量子化方式の横に記録します。その記録は、読んだどのベンチマークよりも有用です。料金を支払っているハードウェア上で実際に測定した値だからです。
コンテキスト長がメモリを増大させる仕組み
Ollama のデフォルトのコンテキスト長は 4096 トークンです。モデルが対応するコンテキスト長は、glm-4.7-flash では 198K トークンと大幅に長くなっています。ただし、デフォルトでこの長さになるわけではなく、有効化してもメモリを無償で利用できるわけではありません。
KV cache には、すべてのトークンについて、すべてのレイヤーの key ベクトルと value ベクトルが保持されます。そのサイズは、許可するトークン数に比例して増加します。4096 トークンから 32768 トークンに増やすとコンテキスト長は 8 倍になるため、KV cache もおおむね 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 と並列リクエストにどう影響するかを説明しています。どちらも同じコストを増大させます。
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 は、入力と出力の両方が 100万トークンあたり $0 です。これらは公開価格であり、変更される可能性があります。そのため、どちらを前提に予算を計画する場合も、事前に現在の料金ページを確認してください。
したがって、現時点でセルフホスト glm-4.7-flash を費用面から正当化するのは困難です。十分な RAM を搭載した VPS には毎月実費がかかりますが、提供元は同じモデルを無料で提供しています。自分で実行することで得られるものは別にあります。プロンプトを自分が管理するマシン内に保持でき、モデルのバージョンも自分で変更しない限り変わりません。これらはセルフホストの十分な理由です。ただし、このモデルをこの価格で使う場合、コストは理由になりません。
使いたいモデルが無料ではない場合や、法的にデータを自分のネットワーク外へ出せない場合は、計算結果が変わります。GPU VPS と API トークンの損益分岐点では、各変数を明示して計算方法を説明しています。まだマシンを選定中であれば、VPS に実際にかかる月額費用が計算のもう一方の要素になります。
localhost でエンドポイントを待ち受ける
ここは省略されがちな手順ですが、最も重要です。
Ollama はデフォルトでポート 11434 の 127.0.0.1 にバインドするため、サーバー自身からしか接続できません。思い込みで済ませず、実際のサーバーで確認してください。
ss -ltnp | grep 11434127.0.0.1:11434 と表示されることを確認します。0.0.0.0:11434 または *:11434 と表示される場合、API はパブリック側を含むすべてのインターフェースで待ち受けています。
これは重要です。Ollama の API には認証がありません。パスワードも、トークンも、allowlist もありません。ポート 11434 に接続できる人は、モデルの一覧表示、料金を支払っているハードウェアでの生成処理の実行、ディスクが満杯になるまでの新しいモデルの取得、既存モデルの削除を行えます。ポート 11434 は固定された既知のポートであるため、公開されているものはスキャナーですぐに見つかります。
OLLAMA_HOST=0.0.0.0 は設定しないでください。ラップトップ上のクライアントから接続できない場合の解決策として、多くのチュートリアルがこれを提案していますが、誤った対処です。代わりにポートを転送してください。
ssh -N -L 11434:127.0.0.1:11434 you@your-serverこれにより、ラップトップのポート 11434 が SSH 経由でサーバーのループバックアドレスに転送されます。そのため、http://localhost:11434 に設定されたクライアントは変更せずに動作し、新たに公開されるものもありません。複数のユーザーや複数のマシンで利用する場合は、サーバーをプライベートなトンネルネットワークに接続し、Ollama をトンネルのアドレスにバインドしてください。0.0.0.0 には決してバインドしないでください。
サーバー以外の場所から確認します。SSH トンネルを閉じた状態で、ラップトップから次を実行します。
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 bits で量子化しても、重みだけで数百 gigabytes になり、一般的な VPS プランの容量を大幅に超えます。ダウンロード可能な重みを持ち、レンタルサーバーで実行できる GLM モデルは glm-4.7-flash です。
glm-4.7-flash にはどの程度の RAM が必要ですか？
タグのダウンロードサイズを最低ラインと考え、その上に KV cache と operating system 用の容量を確保してください。Ollama では、Q4 tag は 19 GB、Q8 は 32 GB、bfloat16 tag は 60 GB と記載されています。KV cache は設定した context length に応じて増えるため、全員に適用できる固定倍率はありません。モデルをロードして ollama ps を実行し、SIZE 列で使用中の環境における実際の値を確認してください。
自分の VPS で tokens per second を測定するにはどうすればよいですか？
"stream": false を指定して http://localhost:11434/api/generate にリクエストを 1 回送信し、レスポンスから eval_count と eval_duration を読み取ります。tokens per second は eval_count / eval_duration * 1e9 です。これは eval_duration が nanoseconds 単位で報告されるためです。最初の実行は破棄してください。最初の実行では、load_duration にディスクから重みを読み込む時間が含まれるためです。入力長に応じて prompt_eval_duration は増加しますが、生成速度は変わらないため、長い prompt でも繰り返し測定してください。
OLLAMA_HOST を 0.0.0.0 に設定してはいけないのはなぜですか？
Ollama の API には認証機能がないためです。0.0.0.0 に bind すると、認証のない endpoint が public internet 上で公開されます。port 11434 に到達できるユーザーは、ハードウェア上で生成を実行したり、インストールされているモデルを変更したりできます。default の 127.0.0.1 bind を維持し、ss -ltnp | grep 11434 で確認してください。ノート PC からは、ssh -N -L 11434:127.0.0.1:11434 you@your-server のような SSH tunnel を使用して API に接続します。