GLM-5.3-Flashをローカルで実行する方法

GLM-5.3-Flashは、MITライセンスの下でリリースされた3200億パラメータのモデルです。この2つの事実は相反する方向性を示しています。ライセンスは好きなように実行できると言いますが、パラメータの数からすると、それには本格的なハードウェアが必要になります。

興味深いのは、3200億パラメータのうち180億がトークンごとにアクティブであり、量子化されたビルドが存在するという点です。この組み合わせにより、このモデルは、ほとんどのガイドが想定する8x H200ノードよりもはるかに小さいセットアップで利用可能になります。

この記事では、フル精度のプロダクションノードからワークステーション上の量子化ビルドに至るまで、ハードウェアの階層を正直に説明し、自分で実行することがいつ意味をなすのかを解説します。

実際に何をロードしているのか

混合エキスパート（MoE）設計がこれを実現可能にしています。3200億パラメータすべてがメモリに常駐している必要がありますが、特定のトークンには180億しか関与しないため、計算需要は合計が示唆するよりもはるかに低くなります。メモリがボトルネックであり、FLOPsではありません。

Z.aiはまた、GLM-5.3と比較して約4.4倍小さいKVキャッシュを報告しており、これは長文コンテキスト作業において非常に重要です。KVキャッシュはコンテキストが埋まるにつれてメモリを消費し、100万トークンのウィンドウでは通常それがボトルネックとなります。

Tier 1: プロダクションノードでのフル精度

実際の同時実行性で最高の品質でサービスを提供するには、参照構成は8x H200ノード（それぞれ141GB、合計約1,128GB）です。8x H20ノードでも機能します。

おおよその数値ですが、ウェイトだけで精度に応じて700～800GBの領域を必要とし、KVキャッシュとランタイムオーバーヘッドのためにさらに余裕が必要です。このようなノードのクラウドレンタル費用は1日あたり約24ドルから48ドルです。

vLLM

vLLMは一般的なデフォルトであり、最も広範なエコシステムサポートがあります。テンソル並列サイズは2のべき乗である必要があります。

vllm serve zai-org/GLM-5.3-Flash \
  --tensor-parallel-size 8 \
  --max-model-len 1048576 \
  --trust-remote-code

設定を検証している間は、より小さな--max-model-lenから始めてください。すぐに100万トークンのウィンドウ全体を要求すると、その分のKVキャッシュが割り当てられ、そこで失敗すると構成の問題ではなくメモリ不足エラーのように見えます。

SGLang

SGLangは、H100、H200、B200、B300、GB200、GB300用の公開レシピ（マルチモーダルサービスを含む）で、このモデルの「デイゼロ」サポートを提供していました。Z.aiは、独自のプレローンチサービスにSGLangベースのスタックを使用しました。

python -m sglang.launch_server \
  --model-path zai-org/GLM-5.3-Flash \
  --tp 8 \
  --context-length 1048576

SGLangは、構造化出力や高同時実行性のエージェントワークロードで優位に立つ傾向があります。チャットインターフェースではなくコーディングエージェントをサービスしている場合、デフォルトにするのではなく、vLLMと比較してベンチマークを行う価値があります。

ファンクション呼び出しを適切に機能させたい場合は、どちらのスタックもツール呼び出しパーサーを設定する必要があります。パーサー名はリリース間で変更されるため、各プロジェクトのドキュメントで現在のフラグを確認してください。

Tier 2: 小規模ハードウェアでの量子化

これはほとんどの報道が省略するティアであり、データセンターを持たないすべての人にとって重要なものです。

量子化されたGGUFビルドはunsloth/GLM-5.3-Flash-GGUFで公開されており、IQ1_SやIQ2_XXSのような積極的な1ビットおよび2ビット形式まで対応しています。3200億モデルの2ビット量子化により、ウェイトは、特にCPUオフロードを使用する場合、大容量メモリのワークステーションやマルチGPUコンシューマーリグが保持できる範囲になります。

2つの正直な注意点：

積極的な量子化は品質を犠牲にします。 IQ1_Sはフル精度とはかけ離れています。3200億MoEでは、劣化は同じ処理を密なモデルに適用するよりも穏やかであることが多いです。なぜなら、失われる冗長性が多いためですが、「実行できる」と「うまく実行できる」は異なる主張です。何らかの結論を出す前に、自分のタスクでテストしてください。

Unslothのこのモデルに関するドキュメントは進行中の作業としてマークされています。 量子化の可用性と推奨設定はまだ変動しています。特定の形式を中心にビルドを計画する前に、実際に公開されているものを確認してください。

CPUが重いハイブリッドセットアップの場合、KTransformersはまさにこのケースのために設計されており、MoEエキスパートをシステムRAMに保持し、必要なものだけをGPUに移動させます。180億のアクティブパラメータを持つMoEモデルでは、そのアーキテクチャは非常にうまく適合します。TokenSpeedもサポートされるランタイムのリストに含まれています。

GLM-4.7-Flashをローカルで実行するためのガイドは、このワークフローの小規模モデル版をカバーしており、GLM-5をローカルで無料で実行する方法は一般的なローカルGLMのセットアップをカバーしています。

メモリ予算の算出

設定が適合するかどうかは、2つの数値によって決まります。

ウェイト。 BF16でパラメータあたり約2バイトの場合、3200億パラメータはオーバーヘッドなしで約640GBです。FP8はその約半分です。4ビット量子化では約160GBになり、積極的な2ビット形式では品質を犠牲にしてさらに低くなります。

KVキャッシュ。 これはコンテキスト長と同時実行性に応じてスケールし、人々を驚かせます。8Kコンテキストで問題なくロードできる設定が、ウェイトではなくキャッシュが増加したために128Kで失敗する可能性があります。Z.aiが報告したGLM-5.3と比較して4.4倍の削減はここで大いに役立ちますが、スケーリングは依然としてトークンに比例します。

実用的な意味合いとしては、モデルが宣伝する最大値ではなく、実際のコンテキスト長に合わせてサイズを設定することです。100万トークンのウィンドウ全体が必要なアプリケーションはごくわずかであり、決して使用しないウィンドウのためにプロビジョニングすることは、このモデルが法外に見える最も一般的な方法です。

このファミリーの以前のオープンウェイトの経緯を追っていた方のために、GLM-5.3のセルフホスティングに関する投稿はリリース前に書かれました。現在、FlashのウェイトはMITの下で公開されているため、ここでのガイダンスがそれに優先します。

ファインチューニング

MITライセンスはファインチューニングと再配布を許可しており、これはこの能力レベルでは異例であり、自分でウェイトを保持する最も強力な理由です。

コストについては現実的になりましょう。3200億モデルのフルファインチューニングは、ほとんどのチームにとって手の届かないものです。LoRAなどのパラメータ効率の良い方法が現実的なパスであり、混合エキスパートモデルでは、ルーター、エキスパート、またはアテンション層のどれを適応させるかという追加の設計上の問題があります。これは密なモデルよりもまだ定まっていないガイダンスを持つ活発な分野です。

目標が新しい機能ではなくドメイン適応である場合、最初にベースモデルに対してプロンプティングと検索をテストしてください。100万トークンのコンテキストウィンドウを持つモデルでは、ドメイン知識をプロンプトに入れる方が、トレーニングするよりも安価で優れていることがよくあります。

サンプリング設定

Z.aiはタスクごとに異なる推奨事項を公開しています。

このモデルは、reasoning_effortを通じて3つの推論モード（low、high、max）もサポートしています。Maxがデフォルトです。 ローカルハードウェアでは、APIを使用する場合よりもこの点が重要になります。なぜなら、推論トークンはドルではなく実時間で支払う生成だからです。リグの生成が遅い場合、lowは使い物になるかどうかの違いになります。

セルフホスティングは金銭的に意味があるか？

通常はありません。API価格がその理由です。

定価では、GLM-5.3-Flashは100万入力トークンあたり0.15ドルかかります。約月額1,000ドルでレンタルできる8x H200ノードは、約67億入力トークンのAPI使用量に相当します。それ以上のボリュームを継続的に維持することは、大規模な運用となります。

ノードは飽和状態でもアイドル状態でも同じコストがかかりますが、APIは使用した分だけ課金されます。利用率が本当に終日高い場合を除き、固定費は負けになります。

したがって、セルフホスティングの理由はコストではありません。

• データの所在とプライバシー。 インフラストラクチャから何も離れません。
• レート制限なし。 自分の容量は自分の容量です。
• 可用性保証。 ベンダーの稼働時間や価格決定に依存しません。
• MITライセンス。 修正、ファインチューニング、再配布が可能です。これはこの能力レベルのモデルとしては異例であり、リストの中で最も強力な論点です。
• 既に所有しているハードウェア。 GPUを購入済みでアイドル状態の場合、限界費用は電気代であり、計算全体が逆転します。

当社の価格内訳では、この比較のAPI側をより詳細に説明しています。

デプロイの検証

vLLMとSGLangは両方ともOpenAI互換のエンドポイントを公開しているため、同じリクエスト形式がローカルサーバーとZ.aiに対して機能します。

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [{"role": "user", "content": "reply with OK"}]
  }'

煙テストを超えて検証する価値があるのは、実際に必要な長さでの長文コンテキスト動作、マルチモーダルをサービスしている場合の画像入力、実際のスキーマでのツール呼び出し、そして単一リクエストのレイテンシーではなく、同時実行下でのスループットです。

ここで、保存されたテストコレクションが役立ちます。ApidogをローカルサーバーとZ.aiエンドポイントの両方にベースURLを環境変数として設定し、それぞれに対して同じスイートを実行して比較します。アプリケーションが依存するツールスキーマを量子化ビルドがまだ処理できるかどうかを迅速に確認できます。これは、人々が本番環境で発見する障害モードです。

FAQ

最低限必要なハードウェアは？ フル精度の場合、8x H200クラスのノードです。量子化されたGGUFビルドの場合、はるかに少なくて済みますが、量子化レベルとともに品質は低下します。

3200億パラメータすべてをメモリにロードする必要がありますか？ はい。トークンごとにアクティブなのは180億だけですが、全体が常駐している必要があります。ボトルネックはメモリであり、計算ではありません。

vLLMとSGLangのどちらが良いですか？ SGLangは公開されているマルチモーダルレシピとともに「デイゼロ」サポートを提供し、同時実行性と構造化出力で優位に立つことが多いです。vLLMはより広範なエコシステムサポートがあります。ワークロードに合わせて両方をベンチマークしてください。

シングルGPUで実行できますか？ フル精度ではできません。KTransformersを介した積極的な量子化とCPUオフロードを使用する場合、大容量メモリのシングルGPUシステムと大量のシステムRAMがあれば可能性があります。生成は遅くなると予想されます。

ライセンスは本当にMITですか？ はい。ウェイトはMITとして公開されており、商用利用、修正、再配布が許可されています。