モデル別実行レシピ
GLM-5.3-Flash：320Bのサーバー向けMoEを動かす
GLM-5.3-Flashの活性18Bについて単一GPUレシピを確認した場合、まず全体320Bの重みをどこに配置するかを確認する必要があります。本稿の公式サーバーパスは複数のアクセラレータ向けです。大容量マックの圧縮版実験と混同せず、ロード・分散・応答を順に確認します。
ハードウェア別速度チューニングおよびサーバーリシピ要約
重み、KVキャッシュ、プリフィルバッチ、同時リクエストと加速機能を分離し、バランス・速度・長い文脈プロファイルで提供します。
| ハードウェア | 適合度 | 推奨ランタイム | 運用プロフィール | 開始文脈 | トークン生成 |
|---|---|---|---|---|---|
| MBP M5 Pro 48GB (41GB) | メモリ超過（非対応） | メモリに収まりません | 検証待ち | 4,096トークン | - |
| Studio M5 Ultra 256GB (236GB) | 実験的な実行 | 圧縮ランタイム検証が必要 | 検証待ち | 4,096トークン | 81.3 ~ 90.3 tok/s |
| Studio M5 Ultra 512GB (480GB) | 実験的な実行 | 圧縮ランタイム検証が必要 | 検証待ち | 4,096トークン | 81.3 ~ 90.3 tok/s |
| RTX 4090 24GB (22.5GB) | メモリ超過（非対応） | メモリに収まりません | 検証待ち | 4,096トークン | - |
| 2× RTX 3090 48GB (NVLink) (45GB) | メモリ超過（非対応） | メモリに収まりません | 検証待ち | 4,096トークン | - |
| RTX PRO 6000 96GB (93GB) | メモリ超過（非対応） | メモリに収まりません | 検証待ち | 4,096トークン | - |
| DGX Spark 128GB (116GB) | メモリ超過（非対応） | メモリに収まりません | 検証待ち | 4,096トークン | - |
| Ryzen AI Max+ 395 128GB (116GB) | メモリ超過（非対応） | メモリに収まりません | 検証待ち | 4,096トークン | - |
詳細ページから、プロフィール別に実行コマンド、適用値、停止すべき条件、および測定順序を確認できます。実行コマンドは、モデルファイルと実行プログラムが確認された組み合わせにのみ表示されます。
公式重みと圧縮版を区別します
zai-org/GLM-5.3-Flashの公式チェックポイントをSGLangまたはvLLMで実行するには、大型モデルを収容するサーバー環境が前提です。活性規模はトークンあたりの計算に関する数字であり、全体ファイルが18Bモデルのように小さくなることはありません。
コミュニティ量子化ファイルを大容量ユニファイドメモリに読み込むことは別途のパスです。サイズが合致しても、アプリがモデル構造をサポートし、実際に回答を生成しているかを確認しなければなりません。公式サーバー命令をマックの実行方法に直接変換して読まないでください。
組み合わせがデバイス選択にサポートされていない場合、推定メモリのみを表示し、命令を強制で実行しません。そのパスの再現記録をまず取得する必要があります。
アクセラレータ数と開始文脈を調整します
GPU_COUNTは実際の構成とランタイムでの並列サポートに合わせて設定される必要があります。数だけ正しいとしても、各カードの容量が不足している場合、ロードされません。カード間の実際の接続および通信経路も確認してください。
大きなネイティブ文脈をすぐにオンするのではなく、16K例のように条件を下げた状態でロードを確認します。その長さが普遍的に安全であるとは保証されていませんので、まず重みとワークスペースの合計を計算しておく必要があります。メモリ制限を無理に極端まで上げるのは避けてください。
サーバーは最初に127.0.0.1にのみ制限します。組織内での共有を計画する場合は、認証・アクセス制限およびログ処理に関する特別な方針を別途策定しなければなりません。ローカル実行という理由だけであらゆるアクセスを自動で制限されるわけではありません。
SGLangの分散サービィス実行（マルチGPUサーバノード）
GPU_COUNT=8 # 실제 물리 GPU 수로 수정
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 16384SGLangを使用して、127.0.0.1:8000ポートで320B分散サービングを開始します。
公式vLLM分散サービィス代替案
GPU_COUNT=8 # 실제 물리 GPU 수로 수정
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.90vLLMの分散サービイスにおいて、127.0.0.1でのローカル隔離バインディングを適用します。
すべてのアクセラレータが担当している仕事をしているか確認します
サーバーが準備されると、短い質問で回答完了とストリーミングを確認します。各GPUのメモリと実行ログを確認し、一方だけが不足しているか、通信が遅延しているかをチェックしてください。全体の平均値だけを見ると、特定ノードの問題を漏らす可能性があります。
準備実行後、同じ入力の3回の中央値を残し、最初のトークン・デコード・ピークメモリを区別します。長いコンテキストを処理する構造であるからといって、どの長さでも速度が一定であるとは限りません。必要な長さごとに結果を別々に再実行します。
複数のユーザーに対応する場合、単一のリクエスト確認後に並列リクエストを増加させます。総処理能力が向上しても、個々のリクエストの待ち時間の長さは別に確認します。1人の最大速度とサーバー全体のパフォーマンスは別々の記録です。
APIチャット完了テスト
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エンドポイントの応答をテストします。
モデルの読み込み失敗と、長い入力での失敗を区別する
重みが最初から入っていない場合、文脈をわずかに下げただけでは解決されない可能性があります。ファイルの精度と分割パス、カードごとのメモリをまず確認してください。基本的なロード後に長い入力でだけ失敗する場合、キャッシュとプリフィルの一時的なスペースを確認します。
16Kより長い入力に拡張する際には、途中で正解を知っている情報を挿入して実際に見つけられるかを確認します。リクエストが終了したという事実と必要な情報を利用したという事実とは異なります。メモリと結果の正確性も記録してください。
設定を変更して失敗した場合は、直前までの正常な構成に戻し、項目ごとに比較します。複数のアクセラレータ環境を同時に変更するよりも、原因を1つずつ特定する方が再現可能な改善に近いです。
このサイズが必要な理由を残します
大規模モデルの運用では、機器の購入後もバージョンや分散状態の管理が残ります。このモデルが、小さいモデルでは不足していた具体的な作業を解決できるかを確認することで、そのコストを説明できます。
ドキュメントやコーディングツールを使う際には、1人のユーザーにとって十分なのは小さなモデルかもしれません。逆に、チーム内の特定のタスクで明確な結果差が見られる場合は、そのタスクを検証基準として使ってください。サーバーが正常に起動された後は、実際に業務の1つを終える段階に進む必要があります。