LocalAI

購入前に、速度と費用を確かめる

モデル別実行レシピ

GLM-5.3-Flash：320Bのサーバー向けMoEを動かす

GLM-5.3-Flashのアクティブ18Bという数字を見て単一GPUのレシピを探しているなら、まず全320Bの重みをどこに収めるか確認が必要です。ここで扱う公式サーバー構成は複数アクセラレータ向けです。大容量Macで圧縮版を試す構成とは分け、読み込み、分散、応答の順に確かめます。

実行レシピ

機器別の設定

1人で使う場合

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

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

Apple Mac Studio M5 Ultra (256GB)

実験的な構成

推奨ランタイム： 圧縮ランタイム検証が必要 (Q4圧縮重み（アーテファクト・ランタイム検証が必要）) · 実験的な構成（検証が必要）

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

4,096 トークン

デコード速度の推定値

81.3 ~ 90.3 tok/s

1人で使う場合の推定値

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

15.0 ~ 26.1秒

プリフィル: 157 ~ 273 tok/s

推定メモリ使用量

約 190.21GB / 236GB

残余の余裕：少ない 45.8GB

サーバーアドレス

http://127.0.0.1:1234

ローカルのみ · 127.0.0.1

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

このプロファイルの設定

設定値この設定にする理由
量子化とモデルファイルQ4量子化済みの重み（ファイルとランタイムの検証が必要）· $MODEL_PATH1人でのデコード時に、重みの転送量と読み込みに必要なメモリをまず減らす初期設定です。
開始時のコンテキスト長4,096トークン重み・KVキャッシュ・ランタイムの余裕を残したまま、ネイティブ1024Kを即座に割り当てるものではない
バインド先アドレス127.0.0.1:1234認証のないローカルサーバーが外部ネットワークに露出しないように、ループバックにのみバインディングする
GPUオフロードと分割単一ユニファイドメモリ全体のロード検証重みを高速メモリに置き、CPU・RAMへのオフロードによるボトルネックを避けます。
Flash Attentionモデルの互換性を確認した後、選択ランタイムでアクティブ化するプリフィル時や長いコンテキストで、アテンションのメモリ使用量を減らす設定です。
KVキャッシュ基本精度でロード後、q8_0を別途検証メモリ使用量を抑えつつ、ランタイムが対応する精度だけを使います。
プリフィルのバッチとマイクロバッチランタイム設定で確認llama.cppのbatch-sizeとubatch-sizeを、MLXの設定値としてそのまま使わないでください。
同時要求数1個サーバー全体の処理量より、1人で使うときの最初のトークンまでの時間とデコードの遅延を優先します。

メモリに収まることと、実際に実行できることは別です。圧縮されたモデルファイルとランタイムの互換性を確認するまでは、コピー用の実行コマンドを表示しません。

使う際の注意点

  • GLMの公式サービングとローカルQ4変換版は別の構成です。実際のモデルファイルとランタイムの互換性を確認するまでは、実行コマンドを表示しません。
推奨設定での速度を見る Studio M5 Ultra 256GB 価格・電力・販売構成の確認

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以上が必要です。結果の自動送信は行いません。

測定方法を読む測定ツールをダウンロード機器・設定のテンプレートをダウンロード

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

公式の重みと圧縮版を分けて考える

zai-org/GLM-5.3-Flashの公式チェックポイントをSGLangやvLLMで動かすには、モデル全体を収められるサーバー環境が必要です。アクティブな規模はトークンごとの計算量の説明であって、ファイル全体が18Bモデル並みに小さくなるわけではありません。

コミュニティの量子化ファイルを大容量ユニファイドメモリへ載せるのは別の方法です。容量が収まっても、アプリがそのモデル構造に対応し、実際に回答できるかを確認する必要があります。公式サーバーのコマンドを、そのままMacの実行手順として読まないでください。

機器選択欄で非対応の組み合わせと表示されたら、推定メモリが足りそうという理由だけでコマンドを無理に実行しないでください。まず、その構成で再現できる実行記録を確認する必要があります。

公式の重みと圧縮版を分けて考える
公式の重みと圧縮版を分けて考える

機器に合わせてアクセラレータ数と開始コンテキストを決める

下の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 16384
SGLangで320Bモデルの分散実行を開始し、127.0.0.1:8000で提供します。
代替構成：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.90
vLLMの分散実行では、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より長い入力を試すときは、答えを確認できる情報を途中に入れ、実際に見つけられるかを確かめます。リクエストが完了したことと、必要な情報を回答に使えたことは別です。メモリ使用量と合わせて、結果の正確さも記録してください。

設定変更で失敗したら、直前に動いていた構成へ戻し、一項目ずつ比較します。複数アクセラレータの環境をまとめて変えるより、原因を一つ特定するほうが、再現できる改善につながります。

この大きさが必要な理由を確かめる

大きなモデルの運用では、機器を買った後もバージョンや分散構成の管理が続きます。小さいモデルでは足りなかった具体的な作業をこのモデルで解決できるか、そこを確認して初めて費用を説明できます。

個人で文書やコーディングに使う道具を用意するなら、もっと小さいモデルで十分かもしれません。一方、チームの特定の作業で明確な差が出るなら、その作業を検証の基準にしてください。サーバーが起動した次は、実際の仕事を一つ最後まで試す段階です。

この大きさが必要な理由を確かめる
この大きさが必要な理由を確かめる

NVFP4で実行するには

GLM5-nextローダーと混合精度MoEカーネルが必要です。通常のGLM-5.3チェックポイントとは異なります。

SGLang · RadixArk/GLM-5.3-Flash-NVFP4

変更履歴

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

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

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

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

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