モデル別実行レシピ

Gemma 4 26B-A4B:24〜32GB機器で動かす設定

Gemma 4 26B-A4Bの活性スケールは小さいものの、モデル全体はメモリ上に存在しなければなりません。24GBクラスのデバイスで期待よりも遅い場合、計算設定を確認する前に重みがどこに移されたかを確認しなければなりません。Q4ロードから確認した後、文脈と生成速度を調整してみます。

ハードウェア別速度チューニングおよびサーバーリシピ要約

重み、KVキャッシュ、プリフィルバッチ、同時リクエストと加速機能を分離し、バランス・速度・長い文脈プロファイルで提供します。

ハードウェア適合度推奨ランタイム運用プロフィール開始文脈トークン生成
MBP M5 Pro 48GB (41GB)十分なメモリLM Studioバランス重視の設定 · プリフィル優先 · 長い文脈16,384トークン26.9 ~ 65.4 tok/s
Studio M5 Ultra 256GB (236GB)十分なメモリLM Studioバランス重視の設定 · プリフィル優先 · 長い文脈16,384トークン85.2 ~ 160.6 tok/s
Studio M5 Ultra 512GB (480GB)十分なメモリLM Studioバランス重視の設定 · プリフィル優先 · 長い文脈16,384トークン85.2 ~ 160.6 tok/s
RTX 4090 24GB (22.5GB)十分なメモリllama.cpp (CUDA)バランス重視の設定 · プリフィル優先 · 長い文脈8,192トークン67.6 ~ 157 tok/s
2× RTX 3090 48GB (NVLink) (45GB)十分なメモリllama.cpp (マルチGPU)バランス重視の設定 · プリフィル優先 · 長い文脈16,384トークン83.7 ~ 242.7 tok/s
RTX PRO 6000 96GB (93GB)十分なメモリllama.cpp (CUDA)バランス重視の設定 · プリフィル優先 · 長い文脈16,384トークン117.8 ~ 273.4 tok/s
DGX Spark 128GB (116GB)十分なメモリllama.cpp (CUDA)バランス重視の設定 · プリフィル優先 · 長い文脈16,384トークン17.9 ~ 41.6 tok/s
Ryzen AI Max+ 395 128GB (116GB)十分なメモリllama.cpp (ROCm/HIP)バランス重視の設定 · プリフィル優先 · 長い文脈16,384トークン16.8 ~ 39.1 tok/s

詳細ページから、プロフィール別に実行コマンド、適用値、停止すべき条件、および測定順序を確認できます。実行コマンドは、モデルファイルと実行プログラムが確認された組み合わせにのみ表示されます。

有効パラメータ数と、ダウンロードする重みの総量を区別する

このモデルは、約25.2Bの全パラメータ中、トークンあたり約3.8Bが活性化されるMoEです。活性化される部分だけを実行するものではなく、全体の変換サイズを確認します。24GB VRAMまたは大きなユニファイドメモリでも、キャッシュとアプリの割当を残す必要があります。

公式のBF16チェックポイントとQ4デスクトップパスは異なります。公式のgoogle/gemma-4-26B-A4B-itの例は、より大きなメモリを備えたNVIDIAサーバ用です。Q4で入ったデバイスでは、公式モデルIDだけを変更しても、同じ容量を期待しないでください。

MoEをサポートするアプリは、新しいモデル構造や量子化のサポートは別途です。まず、ファイルの推奨ランタイムを確認し、モデルを正常にロードすることから始めます。

文脈8Kおよび1つのリクエストを出発点として

実際のLM Studioの識別子を確認し、以下の例に合わせます。8Kでも空間が不足する場合は、長さを低くしてロードから確認します。最も長いコンテキストを有効にすることでモデルの性能をすべて使う、とは意味しません。

LM Studioはこの例で1234を、vLLMは8000ポートを使用します。アドレスとモデル名を同じパスに合わせてください。ローカル専用アクセス設定を確認し、外部に提供する予定であれば、認証およびネットワーク制限を別途準備します。

実際にGPUの占用とCPUに残った部分を確認します。重みが一部超過した場合は、活性計算量が低い場合でも、伝送のため生成が遅れる可能性があります。この状態を正常なGPUのロード結果と同条件で比較しないでください。

LM Studio CLI ローカルサービィング (24GB~32GB デスクトップ)

# 1. 로컬 모델 식별자 확인
lms ls

# 2. 호환 변환본을 8K 문맥으로 로드
lms load <gemma-26b-a4b-identifier> --gpu=max --context-length=8192

# 3. 로컬 서버 시작
lms server start --port 1234

24GB GPUまたはMac 36GB+環境で、127.0.0.1ローカルデーモンを実行します。

公式vLLM MoE サービング(高容量NVIDIA)

vllm serve google/gemma-4-26B-A4B-it   --host 127.0.0.1   --port 8000   --max-model-len 8192   --gpu-memory-utilization 0.90

公式インストラクションチェックポイントは、Q4デスクトップパスよりもより多くのメモリが必要です。

Denseモデルと比較するときも、同じ仕事をさせる

短い質問が正常に終了したら、通常のドキュメントを試してみます。準備実行後、同じ入力について3回の中央値を記録し、最初のトークンの時間とデコードを別々に残してください。トークン数と量子化が異なる結果について、機器の性能差として読み取らないでください。

Denseモデルよりも速い場合もありますが、常にそうとは限りません。MoEカーネルおよびメモリアクセス、キャッシュ条件に影響を受けます。実際の速度を平均活性値一つで逆算しないでください。実行時の実行結果を使用してください。

回答の速さにおいて重要な条件が抜けているかを確認します。複数の質問に対して繰り返し回答を確認することで、モデル選択にtok/s1よりも大きな助かります。

OpenAI互換チャット完了呼び出しテスト

curl -N http://127.0.0.1:1234/v1/chat/completions   -H "Content-Type: application/json"   -d '{
    "model": "<gemma-26b-a4b-identifier>",
    "messages": [
      {"role": "user", "content": "MoE 아키텍처의 장점을 짧게 정리해줘."}
    ],
    "max_tokens": 512,
    "stream": true
  }'

127.0.0.1のローカルエンドポイントの応答遅延および生成速度を測定します。

文脈を広げているうちに遅くなった場合

モデル本体はそのままでもKVキャッシュと一時的なスペースが増える可能性があります。同時リクエストを1つに抑え、8Kから必要な長さまで段階的に増やしてください。急に遅くなる場合はスワップやメモリ圧迫、CPUオフロードの有無をまず確認してください。

サポートされるキャッシュ圧縮を試す場合でも、重みの精度を同時に変更しないでください。品質または速度にどのような影響を与えたかを確認してください。問題が生じた場合は、直前で正常に動作していた状態に戻して比較してください。

上位メモリの値は、モデルを起動した瞬間で終了しません。通常の長い入力や他のアプリを併用しても、その際に必要なオプションかどうかを判断するために、残りのスペースが確保されているかを確認できます。

26Bを選んだ理由について戻ります

12Bよりも優れた結果が必要な質問があったか、その差がこのモデルで実際に得られたかを確認します。差がない場合、小さなモデルを余裕を持って維持することも可能です。サイズが大きくなったことだけによって不快な待機を受ける必要はありません。

望んだ結果と速度を確認したら、ファイル・バージョン・文脈・キャッシュ設定を保存してください。モデルの可能性を確認する段階で、毎日使うツールに移行する最後の作業です。