GLM-5.3をデスクトップ向けGPUで動かせるか気になっているなら、フル版についての答えは明確です。現行のフラッグシップ・チェックポイントにはサーバー級のメモリが必要で、一般的なPC向けではありません。GLM-5.3-Flashなら導入のハードルは下がりますが、それでも大規模なマルチGPUモデルです。量子化済みチェックポイントを読み込めることと、応答性の高いコーディングエージェントとして提供できることは別問題です。
まず結論:必要なハードウェア一覧
フル版GLM-5.3には、文書化された8 GPUのFP8構成があります。完全な100万トークンコンテキストの目標構成として示されているのは、8× B200です。MoEのスパースルーティングではトークンごとに有効化されるパラメータの一部だけですが、24 GB、64 GB、128 GB、192 GBのマシンはフルモデルを実用運用する対象にはなりません。
| 対象 | 公開されている根拠 | 根拠の種類 | 実際の判断 |
|---|---|---|---|
| GLM-5.3 ネイティブFP8 | 公式vLLMレシピでは8× H200またはH20 | 公式トポロジー | サーバー級、または専門的なワークステーション向け。 |
| GLM-5.3 BF16 | BF16チェックポイントを別途提供。vLLMレシピではマルチノード配信 | 公式デプロイメント注記 | 評価用途、またはハイエンドな本番環境に限定。 |
| GLM-5.3 NVFP4 | 公式vLLMレシピに、約465 GBのBlackwell向けチェックポイントInferact/GLM-5.3-NVFP4を掲載 | 公式レシピに掲載されたコミュニティ製チェックポイント | Blackwell専用の実験またはサービス向け。 |
| GLM-5.3 量子化版 | コミュニティによる2ビットGGUFの報告では約281 GBのファイルを使用 | コミュニティのパッケージング。Z.aiの容量情報ではない | オフロード実験は可能だが、通常のデスクトップ導入ではない。 |
| GLM-5.3-Flash | 検証済みプロファイルでは、175.6 GBの4-bpwチェックポイントを2× RTX PRO 6000 Blackwell 96GBで利用 | コミュニティによる検証 | ローカルで使うGLMとして現実的な選択肢。ただし依然マルチGPU。 |
現行のHugging Faceモデルカードでは、総パラメータ数は753,329,940,480、FP8パラメータは751,226,191,872、safetensorsファイルの合計サイズは755,643,409,571バイトとされています。vLLMレシピでは、およそ743Bの総パラメータ、39Bのアクティブパラメータと丸めて表記されています。数値にはわずかな違いがありますが、必要なハードウェアについての結論は変わりません。
重みだけで見たメモリ容量
以下はKVキャッシュ、アクティベーション、ランタイムバッファ、アロケータのオーバーヘッドを含まない算術上の概算です。FP8とBF16は現行フラッグシップの約753Bパラメータ規模に基づき、NVFP4と2ビットは個別実装の値です。
| 表現形式 | 重みに必要なおおよそのメモリ | 意味すること |
|---|---|---|
| FP8 | 約753 GB | ネイティブFP8の8 GPU級デプロイメント計画に対応。 |
| BF16 | 約1.5 TB | 配信オーバーヘッドを考慮する前から、マルチノード級のメモリが必要。 |
| NVFP4 | 掲載されているコミュニティ製チェックポイントで約465 GB | 公式レシピ上ではBlackwell専用の経路であり、標準のZ.aiチェックポイントではない。 |
| 2ビット | コミュニティビルドでは数百GB | 24 GB環境向けではなく、オフロードまたは大容量メモリでの実験向け。 |
リリース前のハードウェア情報から変わった点
GLM-5.3リポジトリは現在公開され、ネイティブFP8ファイルを利用できます。チェックポイントのメタデータは現行モデルカード、トポロジーと起動フラグは公式vLLMレシピ、実測に基づく導入経験はコミュニティ報告を参照するのがよいでしょう。現行レシピでは、1,048,576トークンのコンテキストウィンドウを案内しています。
パラメータ数ではなく、メモリ予算で選ぶ
GLM-5.3では、まず重みのメモリが制約になり、次にコンテキスト用メモリが問題になります。アクティブパラメータが少なければ計算量は下がりますが、ルーティング対象のエキスパートやランタイムバッファを保持しなくてよくなるわけではありません。
24~64 GB:フル版GLM-5.3のローカル運用は考えない
RTX 4090、RTX 5090などの24 GB級GPU 1枚では、フラッグシップのネイティブFP8チェックポイントを収められません。現行Hugging Faceリポジトリのsafetensorsファイルは約756 GBあり、64 GBのワークステーション向けカードでも重みの必要容量には大きく届きません。
CPUオフロードなら量子化版を読み込んで実験できる場合はあります。しかし、対話型コーディングサービスの標準構成というよりはデバッグ経路です。エージェントは繰り返し行うツール呼び出しを、許容できる速度で完了しなければなりません。
128~192 GB:フラッグシップは不可、Flashには限定的な構成がある
128 GBまたは192 GBのユニファイドメモリ環境でも、フラッグシップのネイティブFP8要件には達しません。一方、Flashには具体的な選択肢があります。公開されている検証済みプロファイルでは、固定されたEXL3/TR3の4-bpwチェックポイントを2× RTX PRO 6000 Blackwell 96GB GPUにまたがって実行します。
このプロファイルでは、175.6 GBのチェックポイントデータ、約220 GBの空きストレージ、PCIeピアツーピア通信、固定されたランタイムを使用します。リクエスト上限は262,144トークンと報告されていますが、これは192 GBの一般的なシステムRAMではなく、2枚のディスクリートGPUによる構成です。この正確なFlash構成では、デコード171.7 tokens per second、最初のトークンまでの時間の中央値0.059 secondsも報告されています。
大容量GPUを2~4枚:検討するならフラッグシップではなくFlash
Flashを検討する最初の現実的な帯域は、大容量GPUを2枚または4枚搭載した構成です。精度、ランタイム、コンテキスト長、バッチ処理、画像入力の有無によって、必要なメモリ予算は変わります。検証済みの2 GPUプロファイルはテキスト、構造化ツール、セマンティック画像入力をサポートします。ただし動画は無効で、エンドポイントには組み込み認証がなく、同梱のビジョンテンプレートはマルチモーダル検証前に元に戻せる修正が必要です。これらは固定された当該レシピに関する注意点であり、すべてのFlashビルドやフラッグシップに当てはまるものではありません。
8× H200またはH20:FP8フラッグシップで文書化された構成
公式vLLMレシピでは、ネイティブFP8の標準トポロジーとしてH200またはH20を8枚指定しています。8-wayのテンソル並列、FP8 KVキャッシュ、5トークンのマルチトークン予測、自動ツール選択、GLM固有の推論・ツール呼び出しパーサーを使う構成です。
これは文書化されたトポロジーであり、特定のtokens-per-secondを保証するものではありません。実際のスループットはインターコネクト、コンテキスト長、バッチサイズ、同時シーケンス数、サービングビルドに左右されます。vLLMのページには構成情報がありますが、本番環境での実測スループットは掲載されていません。
100万トークンのコンテキストが必要なら8× B200
公式レシピでは、完全な1,048,576トークンのコンテキスト構成に8枚のB200を位置付けています。この追加コンテキストはVRAMの問題です。KVキャッシュはアクティブなシーケンス数とコンテキスト長に応じて増えるため、32Kまたは128Kトークンで動作する構成でも、同じ同時実行数のまま100万トークンを扱えるとは限りません。
まずは小さい--max-model-lenから始め、KVキャッシュ使用量を測定してから段階的に引き上げてください。長いリポジトリや文書には大きなコンテキストウィンドウが有用ですが、すべてのリクエストを低コスト・低レイテンシーにするものではありません。
公式レシピでは明示されないホスト側の要件
vLLMレシピにはGPUトポロジーと起動フラグが示されていますが、システムRAM、電力、冷却、ストレージの余裕、ネットワークについて、すべてに通用する要件は公開されていません。必要値はチェックポイント、ランタイム、コンテキスト目標、プロバイダープラットフォームによって変わります。
| ホスト側の項目 | 収集した根拠から言えること |
|---|---|
| モデル保存領域 | 現行フラッグシップのリポジトリでは、safetensorsファイルが755.6 billion bytesとされています。キャッシュと一時シャードのために追加領域を確保してください。 |
| GPUインターコネクト | レシピには8-wayのテンソル並列が必要です。PCIeのみの性能を想定せず、レンタルまたはサーバープラットフォームのトポロジーを確認してください。 |
| システムRAM | vLLMレシピでは、汎用的な公式値は公開されていません。必要GPUメモリをシステムRAMの数値で代用してはいけません。 |
| 電力と冷却 | 汎用的な公式値は公開されていません。ハードウェア購入前に、採用プラットフォームの8 GPU構成における電力・熱仕様を確認してください。 |
| ソフトウェア | 公式レシピではvLLM 0.28.0以降およびTransformers 5.15.0以降が示されています。FP8性能にはDeepGEMMが必要です。 |
公式の最小サービング構成
文書化されているデプロイメント手順は、vLLM 0.28.0とOpenAI互換エンドポイントを使用します。これはマルチGPUノード向けの構成であり、小規模なマシンにコマンドをそのままコピーしても、モデルメモリの要件はなくなりません。
指定されたランタイムをインストールする
uv venv
source .venv/bin/activate
uv pip install "vllm==0.28.0" --torch-backend=auto
uv pip install "transformers>=5.15.0"
vLLMレシピでは、FP8性能にDeepGEMMが必要であることも記載されています。有料ノードを準備する前に、対象GPUのイメージと現行レシピの組み合わせを確認してください。
ネイティブFP8版GLM-5.3を起動する
vllm serve zai-org/GLM-5.3 \
--kv-cache-dtype fp8 \
--tensor-parallel-size 8 \
--speculative-config.method mtp \
--speculative-config.num_speculative_tokens 5 \
--tool-call-parser glm47 \
--reasoning-parser glm45 \
--enable-auto-tool-choice \
--served-model-name glm-5.3
各フラグの役割は次のとおりです。
--tensor-parallel-size 8は、チェックポイントを8基のGPUへ分散します。--kv-cache-dtype fp8は、より高精度なキャッシュと比べてキャッシュのメモリ負荷を抑えます。- 5トークンのMTP設定により、文書化されたレシピの投機的デコーディングを有効にします。
--tool-call-parser glm47および--reasoning-parser glm45は、ツール利用と推論のためにモデル出力を整形します。--enable-auto-tool-choiceにより、クライアントがツールを渡した際にサーバー側でツールを選択できます。
エージェント接続前にエンドポイントを検証する
curl -X POST "http://localhost:8000/v1/chat/completions" \
-H "Content-Type: application/json" \
--data '{
"model": "glm-5.3",
"messages": [
{"role": "user", "content": "Write a Python function that reverses a linked list."}
],
"max_tokens": 256
}'
応答が成功しても、確認できるのはモデルのロードだけであり、ツール利用や長文コンテキストの挙動までは検証できません。公式モデルカードではSGLangも別のOpenAI互換経路として紹介されています。本記事でvLLMを使うのは、GPUトポロジーとフラグが専用レシピに明記されているためです。
見落としやすいメモリ消費:KVキャッシュと常時有効の推論
GLM-5.3モデルカードとvLLMレシピでは、thinkingは常時有効として扱われています。対応する推論努力の値はlow、high、maxです。対応する低い設定が指定されない場合、デフォルトはmaxになります。
推論を長くするほど出力トークンを消費します。またコーディングエージェントでは、繰り返すツール呼び出しの間、大きなリポジトリのプレフィックスをKVキャッシュに保持することがあります。同時シーケンス数を増やせば、モデル重みが変わらなくても必要なキャッシュ容量は増加します。
これらの設定はデプロイメントの制御手段として使ってください。
- Low:対話的なコーディング、短いリクエスト、レイテンシーに敏感なツールではここから始めます。
- High:より多くの計画が必要だが、対話的な応答時間の範囲に収めたいタスク向けです。
- Max:追加の推論トークンを使う価値がある、難度が高く長期的なタスクに限定します。
公式レシピでは、フルコンテキストのB200構成に--max-num-seqs 32を推奨し、FP8キャッシュ設定を使用しています。この数値は出発点として扱ってください。サーバーがメモリ不足になるなら同時実行数を下げ、実際のリクエストがキャッシュ切り詰めなしにその範囲へ到達するまで、100万トークン対応をうたうべきではありません。
APIの方が合理的になるケース
セルフホスティングでは、開発者がリクエストを送っていない時間にもGPU容量を確保し続けます。断続的なトラフィック、低い同時実行数、あるいはGLM-5.3をまだ検証しているチームなら、APIを使うことで8 GPUノードの購入や継続レンタルを避けられます。その代わり、ホスト側でのデータ取り扱いとプロバイダー依存は受け入れる必要があります。
Z.aiの現行料金ページでは、GLM-5.3の料金を入力100万トークンあたり$1.40、キャッシュ済み入力100万トークンあたり$0.26、出力100万トークンあたり$4.40としています。GLM-5.3-Flashの通常料金は$0.15 / $0.03 / $0.50で、2026年9月9日まで50%プロモーションが表示されています。予算を組む前に、必ず最新の請求ページを確認してください。
| ワークロード | GLM-5.3の通常料金での計算 | GLM-5.3-Flashの通常料金での計算 |
|---|---|---|
| 新規入力10M + 出力2M | $14.00 + $8.80 = $22.80 | $1.50 + $1.00 = $2.50 |
| 新規入力2M + キャッシュ済み入力8M + 出力2M | $2.80 + $2.08 + $8.80 = $13.68 | $0.30 + $0.24 + $1.00 = $1.54 |
これはトークン料金の例であり、セルフホスティングとの損益分岐計算ではありません。ローカル運用と比較するには、ノードの時間料金、持続的なtokens per second、稼働率、電力、ストレージ、エンジニアリング工数、失敗またはリトライしたエージェント実行まで考慮する必要があります。料金体系を詳しく知りたい場合は、AIReiterのGLM-5.3-Flash API pricing guideを参照してください。
選び方は次のとおりです。
- フラッグシップが必要でも、需要が不規則または中程度ならホスト型GLM-5.3 APIを選びます。
- フラッグシップの能力よりも低いトークン料金、マルチモーダル入力、小さめのセルフホスティング環境を重視するならGLM-5.3-Flashを選びます。
- プライバシー、制御、または継続的な高稼働率が8 GPU構成を正当化するなら、セルフホストのフラッグシップGLM-5.3を選びます。
GLM-5.3のハードウェア要件FAQ
GLM-5.3はRTX 4090、RTX 5090、24 GB GPU 1枚で動きますか?
いいえ、フルモデルとしては動きません。現行のネイティブFP8リポジトリには約756 GBのsafetensorsファイルが含まれるため、24 GBカードでは通常のサービング向けにモデルを保持できません。極端なオフロードまたは量子化の実験に参加できる程度です。
128 GBまたは192 GBのRAMで足りますか?
フラッグシップのネイティブFP8デプロイメントには足りません。検証済みのFlashプロファイルは、2枚の96 GBディスクリートGPU、固定された4-bpwチェックポイント、追加ストレージを使います。これは192 GBのノートPCやユニファイドメモリ搭載ワークステーションと同じではありません。
GLM-5.3とGLM-5.3-Flashは何が違いますか?
両者は別モデルです。フラッグシップのモデルカードでは総パラメータ数は約753B、一方でZ.aiによるFlashの説明では総パラメータ数320B、アクティブパラメータ18Bで、ネイティブのマルチモーダルモデルとして位置付けられています。Flashはより小さく低コストですが、18Bのデスクトップモデルではなく、依然としてサーバー級のモデルです。
どの精度を選ぶべきですか?
文書化された8 GPUトポロジーを用意できるなら、ネイティブFP8を使ってください。マルチノード級のメモリを許容できる、基準品質の評価や専門的な評価にはBF16を使います。NVFP4は対応するBlackwellハードウェア上でのみ検討し、掲載されているNVFP4チェックポイントは、元の標準パッケージではなくコミュニティによる再量子化版である点を忘れないでください。
GLM-5.3をコーディングエージェントに接続できますか?
はい。公式vLLMレシピではOpenAI互換エンドポイントに加え、ツール呼び出しと推論のパーサーを有効にしています。そのため、そのインターフェースに対応するクライアントであれば、サーバー検証後に接続できます。チャット補完の成功だけでエージェント互換性を判断せず、実際に使うハーネス、ツールスキーマ、長時間セッションの挙動をテストしてください。
次に取るべき行動
デスクトップ環境または192 GB未満のホストなら、まずホスト型APIを試してください。代表的なワークロードで文書化済みの8 GPUトポロジーをレンタルするか、大容量マルチGPUマシンでFlashを評価します。計測した稼働率から、制御性とプライバシーがインフラコストを正当化できると分かってからセルフホストへ進むのが妥当です。