GLM-5.3 セルフホスティング：オープンウェイト公開への準備

Zhipu AIは2026年8月14日にGLM-5.3をリリースしました。ローンチ報道でインフラチームが注目すべき点は、オープンウェイトが約2週間後、8月28日頃にZhipuのHugging Face組織で公開される予定であることです。この期間に、ハードウェア選定、サービングスタックの検証、ホスト型APIを使った回帰ベースラインの取得を済ませておくと、ウェイト公開後すぐにセルフホストへ移行できます。

今すぐApidogを試す

Zhipuの社内評価では、GLM-5.3はGLM-5.2よりコーディング能力が50%高く、Terminal-Bench 3.0は4.6から28.3へ上昇しています。ローンチ報道では、エージェント性能を「Claude Fable 5に迫る」と説明しています。フロンティアモデルに届かない点も含むベンチマークの詳細は、GLM-5.3解説記事を参照してください。

この記事では、GLM-5.3のオープンウェイト公開日までに、セルフホスト環境を動かせる状態にするための実践的な準備手順を解説します。

現時点ではウェイトはダウンロードできません。以下のサービング構成やリポジトリ名は、公開時点の公式モデルカードとドキュメントで必ず確認してください。今すぐ実施できるのは、ホスト型APIの応答を保存し、後でローカル環境と比較するためのベースライン作成です。

要約

• GLM-5.3は2026年8月14日に出荷され、オープンウェイトは約2週間後の8月28日頃にhuggingface.co/zai-orgで公開される予定です。
• GLM-5ファミリーはMixture of Experts（MoE）構成です。Z.aiのドキュメントでは、総パラメータ数は744B、推論パスあたり約40Bがアクティブ、コンテキスト長は200Kとされています。
• ウェイト容量の概算は、BF16で約1.5TB、FP8で約744GBです。KVキャッシュは別途必要です。
• これまでのGLM-5シリーズの公開パターンから、GLM-5.3とGLM-5.3-FP8のリポジトリが公開され、GGUF量子化はコミュニティによって後日提供される可能性があります。
• 公開初日のサービング候補はvLLMまたはSGLangです。どちらもOpenAI互換エンドポイントを提供するため、クライアント側はbase_urlの切り替えで移行できます。
• Apidogで、ホスト型APIとローカル環境を同じコレクションからテストできる回帰ハーネスを作成しておきます。

Zhipuがリリースするものと公開時期

Zhipuは国際市場ではZ.aiとして展開しており、GLM-5.3 APIのローンチと同時に、約2週間後のオープンウェイト公開を示しました。公開予定日は2026年8月28日頃で、配布先はHugging Faceです。

Zhipuは、CyberGymで84.5%を記録したモデル性能を踏まえ、この公開に向けてこれまでで最も広範なリスクレビューを実施したと述べています。Seeking Alphaは、この公開を、DeepSeekとのオープンモデル競争におけるリード維持の試みとして捉えています。

セルフホストを計画する場合、次の2点が重要です。

1. ベースモデルは変更されていません。
   
   GLM-5.3はGLM-5のベースモデルに対して後学習をスケールアップしたものです。vLLMやSGLangがGLM-5およびGLM-5.2で対応しているアーキテクチャを前提に準備できます。

2. リリースパターンがあります。
   
   ZhipuのHugging Face組織にはGLM-5、GLM-5.1、GLM-5.2があり、それぞれFP8版も公開されています。GLM-5.3についても、BF16 safetensorsと公式FP8バリアントの組み合わせが期待されます。

ライセンス条項は、ローンチ報道では確認されていません。商用ワークロードに組み込む前に、公開されたモデルカードで必ず確認してください。

総パラメータ744B、アクティブ40Bがハードウェアに意味すること

GLM-5ファミリーはMoE設計です。Z.aiのドキュメントによると、総パラメータ数は744B、推論時にアクティブになるのはパスあたり約40B、コンテキスト長は200Kです。

MoEでは、計算コストとメモリコストを分けて考える必要があります。

• 計算は40Bの密モデルに近い挙動になります。
  
  トークンごとにルーティングされたエキスパートだけが実行されるため、モデルをVRAMに配置できれば、744Bの密モデルより高いスループットを期待できます。

• メモリは744Bモデルとして扱う必要があります。
  
  すべてのエキスパートをアドレス可能な状態に置く必要があります。概算では、BF16はパラメータあたり2バイトなので約1.5TB、FP8は約744GBです。

以下はウェイトのみの計算値です。KVキャッシュ、ランタイムのオーバーヘッド、通信バッファは含まれません。

精度	ウェイトのフットプリント（概算）	現実的な配置先
BF16	約1.5TB	マルチノードクラスター、または最大級の単一サーバーGPU構成
FP8（公式）	約745GB	ハイエンドなマルチGPU単一サーバー
INT4級のコミュニティ量子化	約370〜400GB	小規模マルチGPU構成。品質評価を要確認

消費者向けGPU 1枚だけで運用する場合、GLM-5.3のフルウェイトは対象外です。その場合は次のいずれかを選びます。

• 評価用途だけGPUインスタンスをレンタルする
• コミュニティ量子化の公開を待つ
• 小型のオープンモデルをローカルで動かし、GLM-5.3はホスト型APIで利用する

単一GPUやワークステーション向けの選択肢は、2026年のローカルLLMガイドも参考になります。

また、200Kコンテキストをそのまま有効化するのではなく、デプロイメントティアごとにmax_model_lenを決めてください。KVキャッシュはコンテキスト長とバッチサイズに応じて増加します。

ウェイト公開前にサービングスタックを選ぶ

公開初日に検討すべきサービングスタックは、主にvLLMとSGLangです。

vLLM: デフォルト候補

vLLMはGLM-5ファミリーへの対応、MoEルーティング、テンソル並列処理、エキスパート並列処理、OpenAI互換サーバーを備えています。

リポジトリ公開後の起動コマンドは、次のような形になります。

vllm serve zai-org/GLM-5.3-FP8 \
  --tensor-parallel-size 8 \
  --max-model-len 65536 \
  --served-model-name glm-5.3

このコマンドはテンプレートです。特に以下は環境に合わせて調整してください。

• リポジトリ名: 公開された公式名を使用する
• --tensor-parallel-size: GPU数とVRAM容量に合わせる
• --max-model-len: KVキャッシュ予算に合わせる
• モデル名: クライアント側と一致するよう--served-model-nameを設定する

SGLang: 共有プレフィックスが長いワークロード向け

SGLangはMoE性能に加え、ラディックスツリープレフィックスキャッシュを提供します。エージェントループのように、長いシステムプロンプトや共通コンテキストを繰り返し送るワークロードでは有力な選択肢です。

SGLangもOpenAI互換エンドポイントを提供するため、vLLMとの切り替えでアプリケーションコードを大きく変更する必要はありません。

llama.cpp、Ollama、LM Studio: GGUF公開後の選択肢

llama.cpp系のスタックではGGUF変換が必要です。safetensors公開直後に利用できるとは限らず、コミュニティの変換版が出るまで数日から数週間かかる可能性があります。

量子化版を採用する場合は、ホスト型APIから取得したベースラインと比較してください。起動できることと、期待する品質を維持できることは別です。

公開前にドライランする

ハードウェアがあるなら、公開日を待たずにGLM-5.2の公開ウェイト、または別のMoEモデルで次を確認してください。

# 例: Python環境を準備
python -m venv .venv
source .venv/bin/activate

pip install vllm

# CUDA、NVIDIAドライバー、PyTorch、NCCL、GPU認識を確認
nvidia-smi
python -c "import torch; print(torch.cuda.is_available()); print(torch.cuda.device_count())"

確認する項目は以下です。

• GPUがすべて認識されているか
• コンテナまたはPython環境からGPUを利用できるか
• vLLMまたはSGLangが起動するか
• OpenAI互換エンドポイントへリクエストできるか
• 複数GPU時の並列処理設定が期待通りか
• 設定したコンテキスト長でOOMが発生しないか

8月28日にCUDAドライバーやNCCLの問題を調査する状態は避けてください。

ホスト型APIを回帰ベースラインとして使う

セルフホスト前に、参照実装であるホスト型APIの出力を保存します。ローカル環境の応答が異なる場合、保存したベースラインがあれば、原因を切り分けられます。

• 量子化設定による品質低下
• サービングスタックの設定ミス
• ツール呼び出しやストリーミングの互換性差
• 通常のサンプリング差

Zhipuのホスト型APIはOpenAI互換です。

• 国際向け: https://api.z.ai/api/paas/v4/chat/completions
• 中国本土向け: https://open.bigmodel.cn/api/paas/v4/chat/completions
• 認証: Authorization: Bearer <key>

現在のドキュメントにはglm-5が記載されています。glm-5.3の正確なモデルIDは、公開時点の公式ドキュメントで確認してください。地域別のセットアップはGLM-5.3 APIクイックスタートにあります。

まずは温度0、固定プロンプトでレスポンスを保存します。

curl https://api.z.ai/api/paas/v4/chat/completions \
  -H "Authorization: Bearer $GLM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "temperature": 0,
    "messages": [
      {
        "role": "user",
        "content": "Write a Python function that parses RFC 3339 timestamps and returns UTC datetimes. Include error handling for invalid input."
      }
    ]
  }' > baseline-rfc3339.json

ベースラインには、実際のワークロードを含めてください。目安は20〜50ケースです。

• コード生成
• コードレビュー、リファクタリング
• JSON出力
• ツール呼び出し
• 長文コンテキストの要約
• エージェントの複数ステップ指示
• エラー処理や境界値を含むタスク

温度を0にしても完全な再現性は保証されません。ただし、積極的な量子化や設定ミスに起因する品質低下を検出できる程度には変動を抑えられます。

Apidogで回帰ハーネスを構築する

cURLスクリプトだけでも開始できますが、エンドポイント、量子化レベル、サービング設定が増えると管理が難しくなります。Apidogを使うと、同じリクエストコレクションをホスト型APIとローカル環境の両方に実行できます。

APIテストの基本的な考え方は、QAエンジニア向けAPIテストガイドと同じです。

1. ベースラインプロンプトを1つのコレクションにまとめる

ベースラインケースごとに、チャット補完APIへのリクエストを作成します。

OpenAI互換のスキーマなので、OpenAI形式の仕様をインポートしてリクエスト構造を検証することもできます。

リクエストURLは環境変数を使います。

POST {{base_url}}/chat/completions

2. hostedとlocalの2環境を作る

hosted環境の例:

base_url=https://api.z.ai/api/paas/v4
api_key={{GLM_API_KEY}}
model=glm-5.3

local環境の例:

base_url=http://localhost:8000/v1
api_key=local-serving
model=glm-5.3

リクエストでは環境変数を参照します。

{
  "model": "{{model}}",
  "temperature": 0,
  "messages": [
    {
      "role": "user",
      "content": "Refactor this function to remove the nested loops: ..."
    }
  ]
}

認証ヘッダーも共通化できます。

Authorization: Bearer {{api_key}}
Content-Type: application/json

これで、UI上の環境切り替えだけでホスト型とローカルを比較できます。

3. まずレスポンス形状を検証する

最初に、生成品質ではなくAPI互換性を確認します。

最低限、以下をアサートしてください。

• HTTPステータスが200
• choices[0].message.contentが空でない
• usageオブジェクトが存在する
• usage.prompt_tokensとusage.completion_tokensが数値である

4. 次に内容レベルのアサーションを追加する

コード生成の応答を完全一致で比較すると、表現揺れで壊れやすくなります。代わりに、目的に沿った特徴を確認します。

RFC 3339解析関数の例では、次のような条件が使えます。

response contains "def"
response contains "datetime"
response contains "try"

JSON出力タスクなら、次を確認できます。

response is valid JSON
response has expected key "result"
response.result is not empty

ツール呼び出しでは、ツール名、引数のJSON構造、必須フィールドを確認してください。

5. ホスト型の応答をフィクスチャとして保存する

ホスト型APIのレスポンスを、ケースごとに保存します。

fixtures/
├── hosted/
│   ├── rfc3339-parser.json
│   ├── refactor-loops.json
│   ├── tool-call-search.json
│   └── long-context-summary.json
└── local/
    ├── fp8/
    ├── int4/
    └── bf16/

公開日にはlocal環境で同じコレクションを実行し、出力とアサーション結果を比較します。

6. CLI実行をCIに組み込む

Apidogのランナーを使えば、コレクションをヘッドレスで実行できます。これにより、次の変更ごとに再テストできます。

• FP8からINT4への量子化変更
• vLLMからSGLangへの切り替え
• テンソル並列数の変更
• コンテキスト長の変更
• プレフィックスキャッシュ設定の変更
• モデル更新

目標は、「ローカルデプロイメントがホスト型モデルと期待通りに動作しているか」を、プロンプト単位の合否レポートで判断できる状態にすることです。

クライアントコードはbase_urlの変更で切り替える

OpenAI互換APIの利点は、アプリケーションコードを大きく書き換えずにセルフホスト環境へ移行できることです。

Python SDKでは、接続先を環境変数で切り替えます。

import os
from openai import OpenAI

# ホスト版:
# GLM_BASE_URL=https://api.z.ai/api/paas/v4
#
# ローカル版:
# GLM_BASE_URL=http://localhost:8000/v1

client = OpenAI(
    base_url=os.environ["GLM_BASE_URL"],
    api_key=os.environ.get("GLM_API_KEY", "local-serving"),
)

response = client.chat.completions.create(
    model="glm-5.3",
    temperature=0,
    messages=[
        {
            "role": "user",
            "content": "Refactor this function to remove the nested loops: ..."
        }
    ],
)

print(response.choices[0].message.content)

vLLMまたはSGLangの起動時に、ホスト型と同じモデル名を登録します。

--served-model-name glm-5.3

これにより、クライアント側のmodel="glm-5.3"も変更せずに済みます。

ただし、以下は必ず回帰テストしてください。

• ストリーミング
• ツール呼び出し
• JSONモード
• 使用量メタデータ
• エラー時のレスポンス形式

特にツール呼び出しは、ローカルサービングスタックとホスト型の動作差が出やすい部分です。

コストの考え方: ホスト型APIと自社GPU

Zhipuはローンチ時点で、GLM-5.3固有のAPI価格を発表していませんでした。見積もり前に公式価格ページで最新情報を確認してください。

744B級MoEのセルフホストは、トークンを処理していない時間もGPU容量コストを負担します。セルフホストが合理的になりやすいのは、次のケースです。

1. 利用率が継続的に高い
   
   APIのトークン単価が、償却済みハードウェア費用やGPUレンタル費用を上回る場合です。

2. データガバナンス要件がある
   
   プロンプトや入力データを外部ネットワークへ出せない場合です。

3. レイテンシーや可用性を自分で制御する必要がある
   
   共有APIでは保証できない運用要件がある場合です。

それ以外では、評価のためにGPUを短期間レンタルし、通常運用はホスト型APIを使う方が現実的なことがあります。

オープンウェイトを準備しておくことにはヘッジの意味もあります。プロバイダー価格が変動しても、セルフホストへ移行する選択肢を維持できます。DeepSeek API価格引き上げ分析で扱ったように、ローンチ時の料金だけを前提に単位経済を組むことにはリスクがあります。

公開日チェックリスト

項目1〜6は、ウェイト公開前に実行できます。

1. 利用可能なハードウェアに対して、BF16、FP8、または量子化待ちのどれを目標にするか決める。
2. vLLMまたはSGLangをインストールし、GLM-5.2または別のMoEモデルでドライランする。
3. Z.aiのAPIキーを作成し、ライブドキュメントで正確なGLM-5.3モデルIDを確認する。
4. ホスト型APIから、温度0のベースライン応答を20〜50件保存する。
5. Apidogコレクションを作成し、hostedとlocalの環境、およびレスポンス形状アサーションを設定する。
6. デプロイメントティアごとに提供する最大コンテキスト長を決める。
7. 公開日にはhuggingface.co/zai-orgでGLM-5.3とGLM-5.3-FP8のリポジトリを確認し、モデルカードのライセンスを読む。
8. ウェイトをダウンロードし、サーバーを起動して、local環境をローカルエンドポイントへ向ける。
9. Apidogコレクションを実行し、ローカルの結果をホスト型フィクスチャと比較する。
10. コンテンツレベルの失敗を調査してから、量子化、並列処理、プレフィックスキャッシュ、コンテキスト長をチューニングする。

FAQ

GLM-5.3のウェイトは今すぐダウンロードできますか？

いいえ。2026年8月14日時点ではホスト型APIのみが稼働しています。Zhipuによると、オープンウェイトはリリースから約2週間後、8月28日頃に公開される予定です。公開先として想定されるのは、GLM-5、5.1、5.2がすでに存在するzai-org Hugging Faceページです。

GLM-5.3は単一の消費者向けGPUで動作しますか？

フルウェイトでは動作しません。744Bパラメータのファミリーは、KVキャッシュを除いてFP8でも約744GBです。単一GPUのVRAMには収まりません。INT4級量子化でもマルチGPU領域です。

単一GPU予算なら、小型オープンモデルをローカルで動かし、GLM-5.3はホスト型APIで利用する構成が現実的です。ローカルLLMまとめも参照してください。

GLM-5.3にはどのサービングフレームワークを使うべきですか？

vLLMが安全なデフォルトです。GLM-5ファミリーへの対応、MoE向け並列処理、OpenAI互換サーバーを備えています。

長い共有プレフィックスを再送信するエージェントワークロードでは、SGLangが有力な代替です。llama.cpp、Ollama、LM Studioは、コミュニティによるGGUF変換が公開された後の選択肢になります。

既存のOpenAI SDKコードはセルフホストしたGLM-5.3でも使えますか？

はい。SDKのbase_urlをhttps://api.z.ai/api/paas/v4から、vLLMまたはSGLangのURLへ切り替えます。リクエスト形式は同じOpenAI互換形式を維持できます。

ただし、ツール呼び出しとストリーミングは必ずテストしてください。ローカルサービング環境とホスト型APIで差が出やすい部分です。

セルフホスト予定なのに、なぜホスト型APIのベースラインが必要ですか？

ホスト型APIが参照実装になるためです。ローカル出力が不自然なとき、ベースラインがなければ、量子化設定、サービング設定、またはモデル固有の挙動のどれが原因かを判断できません。

GLM-5.3 APIクイックスタートを使ってホスト型エンドポイントから応答を保存しておけば、公開日は推測ではなく差分比較の作業になります。

あなたのスタックにGLM-5.3を組み込む場所

GLM-5.3を公開初週から評価・運用したいなら、最初に必要なのは最大のGPU予算ではありません。次の準備です。

• サービングスタックをインストールする
• 精度ティアを決める
• ホスト型APIのベースラインを取得する
• ローカルとホスト型を比較する回帰ハーネスを作る

まずはチェックリストの項目1〜6を実行してください。今週中にホスト型ベースラインを取得し、保存・比較するためにApidogをダウンロードしましょう。

用意するものは、1つのコレクション、hostedとlocalの2環境、そして量子化レベルやサービングフラグを変更するたびに実行できるアサーションです。これにより、「自分のデプロイメントは機能しているか」という問いを、感覚ではなく再現可能なテスト結果で判断できます。