モデル別実行レシピ

GLM-5.3-Flashサービングガイド:320Bサーバー規模MoEレシピ

GLM-5.3-Flashの実行設定:MacとマルチGPUサーバー

GLM-5.3-Flashは、質問や文書を入力すると回答を生成し、コードの作成も支援する言語モデルです。ローカルでの実行方法は主に2つあります。公式モデルを複数のGPU1に分散して読み込む方法と、量子化2したMLX3変換版を大容量メモリのMacで動かす方法です。この記事では、機器に合う方法を選び、サーバーを起動して最初の回答を受け取るまでを説明します。

自分のMacで使うなら、まずoMLXの実行方法を確認しましょう。複数人で同じモデルを使うGPUサーバーには、SGLangやvLLMを選べます。起動できたら入力の長さと同時利用者数を増やし、実際の作業でも快適に応答するか試します。

実行条件と要点
  • 公式モデルにはSGLang・vLLM、MacのMLX変換版にはoMLXを使います。
  • 総パラメータ数は320Bで、トークンごとに約18Bが計算に参加します。
  • GPUサーバーは16Kのコンテキストから始め、まず短いAPIリクエストを送ります。
機器別の実行設定へ移動

機器に合う実行方法を選ぶ

GLM-5.3-Flashは、複数の専門家ネットワークから一部を選んで計算するMoE4モデルです。総パラメータ数は320Bで、1トークン5を生成するときは約18Bが有効になります。実行には全重みを保存できるメモリが必要です。公式のzai-org/GLM-5.3-Flashモデルは、SGLangやvLLMで複数のGPUに分散して読み込みます。

Macでは、コミュニティが量子化してMLX形式に変換したファイルを使います。oMLX 0.7.0は、GLM-5.3-FlashのLightning MTP6とDFlash2に対応しています。DFlash2を使う場合は、incoai/GLM-5.3-Flash-DFlash2というドラフトモデルも用意します。方式によって必要なファイルが異なるため、先に加速方式を決めると準備しやすくなります。

GLM-5.3-Flashの2つの実行方法
機器モデルファイル実行ソフト
マルチGPUサーバー公式zai-org/GLM-5.3-FlashSGLangまたはvLLM
大容量メモリのMacコミュニティのMLX量子化変換版oMLX 0.7.0
書類入りの緑の箱と暗色block箱の下に、大きなblockと小さなblockの列があります。
使う機器に合わせてモデルと実行ソフトを選びます。

MacでMLX-VLMサーバーを起動してAPIを確認する

Macではmlx-community/GLM-5.3-Flash-4bit変換版とmlx-vlmを使います。モデルカードではファイルサイズを190GiBとし、256GB以上のメモリーを搭載したMacが必要と案内しています。このアーキテクチャはmlx-lmではなくmlx-vlmの使用経路として示されているため、実行環境とチェックポイント7を合わせます。

サーバーを127.0.0.1:8080で起動し、/v1/modelsがモデルIDを返すことを確認します。一覧にmlx-community/GLM-5.3-Flash-4bitがあれば、同じIDを使って短いコード質問を送ります。choices[0].message.contentに先頭要素と空入力時の動作を説明する文が返れば、基本的なテキスト経路を確認できています。

コマンドが見つからない場合は、同じPython環境にmlx-vlmがインストールされているか確認します。チェックポイントの読み込みエラーでは、mlx-vlmのバージョンと正確なモデルIDを確認してください。メモリーエラーが出た場合は、他の実行中アプリが使うユニファイドメモリ8ーを確認し、モデルカードに記載された190GiBのファイルと256GB以上という要件も考慮します。

MLX-VLMをインストールしてローカルサーバーを起動
python -m pip install -U mlx-vlm
mlx_vlm.server --model mlx-community/GLM-5.3-Flash-4bit --host 127.0.0.1 --port 8080
Apple SiliconのMLX-VLM経路で変換版を読み込み、loopbackにサーバーをbindします。
サーバー状態とモデルIDを確認
curl --fail-with-body http://127.0.0.1:8080/v1/models
モデル一覧で実行に使う識別子を確認します。
Macサーバーに短いコード質問を送る
curl --fail-with-body http://127.0.0.1:8080/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"mlx-community/GLM-5.3-Flash-4bit","messages":[{"role":"user","content":"Explain this function empty-input behavior in one sentence: def first_item(items): return items[0]"}],"temperature":0,"max_tokens":128}'
レスポンス本文に関数の動作説明が最後まで返ることを確認します。

GPUサーバーを16Kコンテキストで起動する

使う実行ソフトに合わせて、以下のコマンドのどちらか一方を実行します。GPU_COUNT=8は物理GPUを8枚使う例です。搭載GPU数とソフトが対応するテンソル並列9構成に合わせて変更してください。GPUごとのメモリ容量が異なると、モデルを均等に分割できる範囲が制限されることがあります。

どちらのコマンドもコンテキストを16Kに設定しています。モデルを読み込んだ後もKVキャッシュ10と作業領域のメモリが必要なので、まずこの長さから始めましょう。短い質問への回答を確認した後、実際に読み込ませる文書の長さまで増やします。

サーバーのアドレスは127.0.0.1:8000です。同じコンピューターから接続でき、外部からは接続できません。チームで共有する前に、認証とアクセス制御を設定しましょう。社内資料を送る場合は、ログに残す内容と保存期間も決めておきます。

SGLangでマルチGPUサーバーを起動
GPU_COUNT=8 # Change this to the number of physical GPUs
python -m sglang.launch_server   --model-path zai-org/GLM-5.3-Flash   --tp "$GPU_COUNT"   --host 127.0.0.1   --port 8000   --context-length 16384
実GPU数に合わせてTPを設定し、127.0.0.1:8000でserverを起動します。
vLLMでマルチGPUサーバーを起動
GPU_COUNT=8 # Change this to the number of physical GPUs
vllm serve zai-org/GLM-5.3-Flash   --tensor-parallel-size "$GPU_COUNT"   --host 127.0.0.1   --port 8000   --max-model-len 16384   --gpu-memory-utilization 0.90
実GPU数にtensor parallelを合わせ、local serverを起動します。

最初の回答を受け取り、速度を確認する

モデルの読み込みが終わり、サーバーがリクエストを受け付ける状態になったら、新しいターミナルで以下のコマンドを実行します。回答が少しずつ表示されれば、ストリーミングが動作しています。回答が終わるまで確認し、各GPUのメモリ使用量とサーバーログも見ておきましょう。

ウォームアップを1回行ってから、同じ質問を3回送ります。最初のトークンまでの時間、デコード11速度、最大メモリ使用量の中央値を記録すると、次の設定と比較しやすくなります。初めて読む入力とキャッシュを再利用する入力は分けて記録しましょう。読む文書量が変わると、待ち時間も変わります。

Macでの応答速度を知りたい場合は、公開されているM5 Ultraの記録が参考になります。

公開記録のMacはM5 Ultra 256GB・80コアGPUです。コミュニティのMLX oQ4 MTP変換版をoMLX 0.7.0で実行し、code_python入力、出力予算128トークン、temperature 0を使用しています。KVキャッシュはTurboQuant 4ビット、メモリガードはaggressiveです。以下はこの構成で得られた結果です。

M5 Ultra 256GBでのGLM-5.3-Flash公開記録
入力長プリフィルデコード
4K token2,270 tok/s64.0 tok/s
16K token2,313 tok/s83.6 tok/s

複数の開発者が使うサーバーでは、同時リクエストも試しましょう。たとえば4人が同時に質問するなら、4件をまとめて送り、それぞれの初回応答時間と完了時間を記録します。処理した総トークン数も記録すると、個人の待ち時間とチーム全体の処理量を確認できます。

短い質問を送る
curl -N http://127.0.0.1:8000/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "zai-org/GLM-5.3-Flash",
    "messages": [
      {"role": "user", "content": "대규모 분산 추론 환경의 이점을 정리해줘."}
    ],
    "max_tokens": 512,
    "stream": true
  }'
127.0.0.1:8000へstreaming requestを送り、完了を確認します。
laptopが曲線経路で8台のserverに接続し、それぞれに緑のcheckがあります。
GPU別メモリと通信を調べ、各acceleratorがrequestを処理するか確認します。

長い文書と同時リクエストに合わせて調整する

長い文書では、必要な情報を実際に見つけられるか確認します。日付や例外条件など、答えを確認できる情報を文書の中ほどに入れて質問してみましょう。入力を16Kより長くするたびに、回答の正確さとメモリ使用量を記録します。

コンテキスト長、キャッシュ設定、MTPは1つずつ変更しましょう。どの設定で速くなったか分かりやすくなります。GPU別のメモリ使用量とサーバーログも残しておくと、エラーの原因を調べやすくなります。短い質問には答えるのに長い入力で失敗する場合は、KVキャッシュと作業領域のメモリが不足していないか確認します。

実際の作業でモデルを選ぶ

モデルの最終判断には、普段の作業を使うとよいでしょう。関数の使用箇所を探す、設定変更コミットを要約する、2つのファイルの違いを説明するなど、答えを確認できる質問をいくつか用意します。同じ資料を小型モデルとGLMに入力し、正確さ、応答時間、メモリ使用量を比較します。

小型モデルでも必要な回答が得られ、複数人のリクエストを処理できるなら、軽い構成で運用できます。GLMのほうが重要な作業をうまく処理できるなら、その改善を基準に選びましょう。利用者が増えたときの待ち時間も確認すると、機器選びに役立ちます。

動作した構成は、モデル識別子、ソフトのバージョン、GPU構成、コンテキスト長、同時リクエスト数と一緒に保存しましょう。次の更新を同じ質問で試すと、性能の変化を比較しやすくなります。問題が起きたときも、以前の設定に戻せます。

棚の色blockがconveyorとdashboardへ続き、横に大きなblock群と色別書類トレイがあります。
普段の作業で回答の品質と待ち時間を比べ、モデルを選びましょう。

NVFP4にはGLM5-nextローダーを使う

RadixArk/GLM-5.3-Flash-NVFP4を使う場合は、GLM5-nextモデルローダーと混合精度MoEカーネルを含むSGLangを選びます。このファイル形式には専用ローダーが必要です。使うSGLangのブランチにローダーとカーネルが含まれているか確認してから読み込みましょう。

用語の注釈

  1. GPU — 多くの計算を並列に処理するプロセッサーです。AIモデルの実行ではモデル計算を担います。

    本文に戻る
  2. 量子化 — モデルの重みや計算値を少ないビット数で表し、保存容量やメモリ使用量を減らす方法です。表現が粗くなるため、精度にも影響することがあります。

    本文に戻る
  3. MLX — Appleが開発する機械学習フレームワークで、Apple SiliconのCPUとGPUが共有するメモリを使ってモデルを実行します。

    本文に戻る
  4. MoE — 複数の専門家サブネットワークから入力に応じて一部を選ぶモデル構造です。総パラメータ数と1トークン処理時に有効な数は異なることがあります。

    本文に戻る
  5. トークン — モデルが入力や出力を分けて処理する単位です。

    本文に戻る
  6. MTP — 複数の将来トークンを一度に予測する学習目標、またはそれを行うモデル構成です。投機的デコーディングでは、その予測を候補トークンとして提案できます。

    本文に戻る
  7. チェックポイント — 学習済みモデルの重みなどを保存したファイルです。同じモデル系列でも、版や用途によって異なるチェックポイントを使うことがあります。

    本文に戻る
  8. ユニファイドメモリ — CPUとGPUが同じ物理メモリ領域を共有する構造です。

    本文に戻る
  9. テンソル並列 — モデルの層内の行列や演算を複数の装置に分割して計算する方式です。部分結果をまとめるために装置間通信が必要です。

    本文に戻る
  10. KVキャッシュ — 過去トークンのAttention用キー・バリューを保存し、後続トークン生成で再利用するメモリです。容量はコンテキスト長やバッチサイズで変わります。

    本文に戻る
  11. トークンのデコード — 入力とそれまでの回答をもとに、次の出力トークンを順に生成する段階です。

    本文に戻る

よくある質問

この記事で最初に確認すべきことは何ですか?
GLM-5.3-Flashは、質問や文書を入力すると回答を生成し、コードの作成も支援する言語モデルです。ローカルでの実行方法は主に2つあります。公式モデルを複数のGPUに分散して読み込む方法と、量子化したMLX変換版を大容量メモリのMacで動かす方法です。この記事では、機器に合う方法を選び、サーバーを起動して最初の回答を受け取るまでを説明します。
必要なメモリはどのくらいですか?
Macでは`mlx-community/GLM-5.3-Flash-4bit`変換版と`mlx-vlm`を使います。モデルカードではファイルサイズを190GiBとし、256GB以上のメモリーを搭載したMacが必要と案内しています。このアーキテクチャは`mlx-lm`ではなく`mlx-vlm`の使用経路として示されているため、実行環境とチェックポイントを合わせます。
条件と出典はどこで確認できますか?
コマンドが見つからない場合は、同じPython環境に`mlx-vlm`がインストールされているか確認します。チェックポイントの読み込みエラーでは、`mlx-vlm`のバージョンと正確なモデルIDを確認してください。メモリーエラーが出た場合は、他の実行中アプリが使うユニファイドメモリーを確認し、モデルカードに記載された190GiBのファイルと256GB以上という要件も考慮します。

実行レシピ

機器別の設定

1人で使う場合

使う機器を選ぶと、起動コマンドと調整できる設定が表示されます。

使用可能メモリ: 236GB / 帯域幅: 1200GB/s

プロファイル

Apple Mac Studio M5 Ultra (256GB)

メモリに収まる

推奨ランタイム: oMLX (Q4_K_M · MLXチェックポイント) · ドキュメントに基づくランタイム設定

インストール後の初回実行や、毎日安定して使いたいときに

プロファイルのコンテキスト長

16,384 トークン

ランタイムの文書に基づく設定Studio M5 Ultra 256GB · Q4 · 要求 1個

ランタイムのドキュメントに基づく初期設定です。下の手順に沿って調整し、速度を比べてください。

デコード速度の推定値

66.9 ~ 100.3 tok/s

1人で使う場合の推定値

最初のトークンまでの推定時間

5.9 ~ 8.9 秒

プリフィル: 1850.4 ~ 2775.6 tok/s

推定メモリ使用量

約 192.94GB / 236GB

残余の余裕:少ない 43.1GB

サーバーアドレス

http://127.0.0.1:8000

ローカルのみ · 127.0.0.1

推定値は、計算ツールが推奨する量子化・高速化設定と 16,384トークンを基準にしています。上記の実行設定を測定した値ではありません。

このプロファイルの設定

設定値この設定にする理由
重みQ4_K_M · MLXチェックポイントMLXモデルのディレクトリを使います。Q4_K_MのGGUFとはファイル形式が異なります。
入力長の確認16,384リクエスト前にモデル設定の入力上限を確認してください。この起動コマンドではコンテキスト長を指定していません。
KVキャッシュモデル設定で確認この起動コマンドではKVキャッシュの精度を指定していません。
プリフィルのバッチサイズランタイム設定で確認llama.cppのbatch-sizeとubatch-sizeを、MLXの設定値としてそのまま使わないでください。
同時リクエスト数11件のリクエストの速度を測ります。複数リクエストを合わせた処理量とは分けて確認します。
メモリの余裕2GB以上モデルの読み込み後に、実際のメモリ使用量とスワップの有無を確認します。

Studio M5 Ultra 256GB 実行コマンド(oMLX)

Apple Silicon · MLX モデル · メモリ ガード
MODEL_DIR="$HOME/.omlx/models"
omlx serve \
  --model-dir "$MODEL_DIR" \
  --host 127.0.0.1 \
  --port 8000 \
  --max-concurrent-requests 1 \
  --memory-guard balanced
まずこの設定で基準速度を記録し、その後は下の手順に沿って一項目ずつ変更します。

起動後の確認

  1. 01起動ログで、モデルの読み込み完了と実際のコンテキスト長を確認します。
  2. 02ウォームアップ後はリクエストを1件ずつ送ります。同じ長さの異なる入力を3つ使い、キャッシュを再利用しない初回の処理時間を記録します。
  3. 03同じ入力を繰り返した結果は、キャッシュ再利用の記録として分けます。初回入力の結果と混ぜないでください。
  4. 04プリフィルtok/s、デコードtok/s、ピークメモリをまとめて記録し、その後は一項目ずつ変更します。

変わる点と注意点

  • コンテキスト長と同時リクエスト数を控えめにしているため、機器の最大処理量より低い結果になることがあります。

1つずつ調整

高速化の手順

複数の値を一括で変更すると原因を特定するのが難しいです。

  1. STEP 1

    基準値を保存

    初回入力とキャッシュ再利用を分け、それぞれ3回記録します。プリフィル、デコード、ピークメモリを一緒に比較します。

    とき: エラーがある場合やメモリの余裕が2GB未満の場合は、次の段階へ進まないでください。

  2. STEP 2

    プリフィルのチャンクサイズを調整

    1,024 → 2,048 → 4,096の順に増やし、長い入力のTTFTとピークメモリを比べます。

    とき: TTFTが短くならない場合やピークメモリが急増する場合は、直前の値へ戻します。

  3. STEP 3

    KVキャッシュ調整

    コンテキスト長を確保したいときだけ、同じ質問でQ8キャッシュとF16/BF16の基準値を比較します。

    とき: 出力に差が出る場合や、必要なコンテキスト長をすでに確保できている場合は、標準の精度を維持します。

  4. STEP 4

    MTP・投機的デコーディング

    対応モデルだけで有効にし、コードと通常の文章を分けて、採用率と実際のデコードtok/sを測定します。

    とき: 3回の中央値が基準値より良くならなければ、無効に戻します。

  5. STEP 5

    コンテキスト拡張

    実際に必要な長さまで段階的に2倍ずつ伸ばし、入力途中の情報を見つけられるかと、スワップの有無を確認します。

    とき: 情報を探す精度が落ちたり、スワップ・メモリ圧縮が始まったりしたら、一段階短くします。

自分の機器の測定記録を送る

同じ条件で3回以上測定したJSONを読み込んでください。送信ボタンを押すまでは、このブラウザ内でのみ確認します。

受け付けるのは機器・モデル・実行条件と測定値だけです。プロンプト・回答・元のログ・ファイルパスは含めないでください。

記録ファイルがなければ、起動中のローカルサーバーと測定ツールで作成できます。Node.js 20以上が必要です。結果の自動送信は行いません。

内容を確認したユーザーの投稿記録です。このサイトが直接測定した結果とは区別しています。

設定の問題を報告

この設定でどこにつまずいたかを教えてください。報告を読めるのは管理者だけです。

報告する設定 · Studio M5 Ultra 256GB · GLM-5.3-Flash (MoE) · バランス

変更履歴

サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。

  1. 機器・プロファイルの保存と再表示を追加

    実行可能なプロファイルを機器の選択と一緒にこのブラウザに最大5件保存し、ガイド一覧から再び開けるようにしました。保存後に公開設定が変わったりプロファイルの提供が終了したりした場合は、実行前の再確認を案内します。

  2. 実行エンジンの説明へのリンクを追加

    設定に表示されるエンジン名から、該当する実行プログラムの説明へ移動できるようにしました。エンジンを特定できない経路に、推測で別のプログラムをリンクすることはありません。