モデル別実行レシピ
Gemma 4 26B-A4Bの実行設定：24GB〜32GBのQ4とBF16サーバー
Gemma 4 26B-A4Bはトークンごとに使う部分が小さくても、モデル全体をメモリに置く必要があります。24GBの機器で期待より遅いなら、計算の設定より先に重みがどこへ読み込まれたかを確認します。Q4の読み込みを確かめてから、コンテキスト長と生成速度を調整しましょう。
実行レシピ
機器別の設定
1人で使う場合
使う機器を選ぶと、起動コマンドと調整できる設定が表示されます。
プロファイル
Apple MacBook Pro M5 Pro (64GB)
メモリに収まる推奨ランタイム： LM Studio (MLX 4ビット（GGUF Q4_K_Mとは別形式）) · ドキュメントに基づくランタイム設定
インストール後の初回実行や、毎日安定して使いたいときに
プロファイルのコンテキスト長
16,384 トークン
ランタイムのドキュメントに基づく初期設定です。下の手順に沿って調整し、速度を比べてください。
デコード速度の推定値
26.9 ~ 65.4 tok/s
1人で使う場合の推定値
最初のトークンまでの推定時間
8.8 ~ 21.5秒
プリフィル: 765 ~ 1,861 tok/s
推定メモリ使用量
約 16.34GB / 56GB
残余の余裕：少ない 39.7GB
サーバーアドレス
http://127.0.0.1:1234
ローカルのみ · 127.0.0.1
推定値は、計算ツールが推奨する量子化・高速化設定と 16,384トークンを基準にしています。上記の実行設定を測定した値ではありません。
このプロファイルの設定
| 設定値 | この設定にする理由 |
|---|---|
| モデルの重みMLX 4ビット（GGUF Q4_K_Mとは別形式） | MLXモデルのディレクトリを使います。Q4_K_MのGGUFとはファイル形式が異なります。 |
| 入力長の確認16,384 | lms loadのcontext-length設定と、実際に読み込まれたコンテキスト長を合わせて確認します。 |
| KVキャッシュモデル設定で確認 | この起動コマンドではKVキャッシュの精度を指定していません。 |
| プリフィルのバッチサイズランタイム設定で確認 | llama.cppのbatch-sizeとubatch-sizeを、MLXの設定値としてそのまま使わないでください。 |
| 同時リクエスト数1 | 1件のリクエストの速度を測ります。複数リクエストを合わせた処理量とは分けて確認します。 |
| メモリの余裕2GB以上 | モデルの読み込み後に、実際のメモリ使用量とスワップの有無を確認します。 |
MBP M5 Pro 64GB 実行コマンド（LM Studio)
# lms ls에서 확인한 MLX 4비트 모델 식별자를 입력
MODEL_ID=""
lms ls
: "${MODEL_ID:?MLX 모델 식별자를 입력하세요}"
lms load "$MODEL_ID" --gpu=max --context-length=16384
lms server start --port 1234起動後の確認
- 01起動ログで、モデルの読み込み完了と実際のコンテキスト長を確認します。
- 02ウォームアップ後はリクエストを1件ずつ送ります。同じ長さの異なる入力を3つ使い、キャッシュを再利用しない初回の処理時間を記録します。
- 03同じ入力を繰り返した結果は、キャッシュ再利用の記録として分けます。初回入力の結果と混ぜないでください。
- 04プリフィルtok/s、デコードtok/s、ピークメモリをまとめて記録し、その後は一項目ずつ変更します。
変わる点と注意点
- コンテキスト長と同時リクエスト数を控えめにしているため、機器の最大処理量より低い結果になることがあります。
1つずつ調整
高速化の手順
複数の値を一括で変更すると原因を特定するのが難しいです。
- STEP 1
基準値を保存
初回入力とキャッシュ再利用を分け、それぞれ3回記録します。プリフィル、デコード、ピークメモリを一緒に比較します。
とき： エラーがある場合やメモリの余裕が2GB未満の場合は、次の段階へ進まないでください。
- STEP 2
プリフィルのチャンクサイズを調整
1,024 → 2,048 → 4,096の順に増やし、長い入力のTTFTとピークメモリを比べます。
とき： TTFTが短くならない場合やピークメモリが急増する場合は、直前の値へ戻します。
- STEP 3
KVキャッシュ調整
コンテキスト長を確保したいときだけ、同じ質問でQ8キャッシュとF16/BF16の基準値を比較します。
とき： 出力に差が出る場合や、必要なコンテキスト長をすでに確保できている場合は、標準の精度を維持します。
- STEP 4
MTP・投機的デコーディング
対応モデルだけで有効にし、コードと通常の文章を分けて、採用率と実際のデコードtok/sを測定します。
とき： 3回の中央値が基準値より良くならなければ、無効に戻します。
- STEP 5
コンテキスト拡張
実際に必要な長さまで段階的に2倍ずつ伸ばし、入力途中の情報を見つけられるかと、スワップの有無を確認します。
とき： 情報を探す精度が落ちたり、スワップ・メモリ圧縮が始まったりしたら、一段階短くします。
自分の機器の測定記録を送る
同じ条件で3回以上測定したJSONを読み込んでください。送信ボタンを押すまでは、このブラウザ内でのみ確認します。
受け付けるのは機器・モデル・実行条件と測定値だけです。プロンプト・回答・元のログ・ファイルパスは含めないでください。
記録ファイルがなければ、起動中のローカルサーバーと測定ツールで作成できます。Node.js 20以上が必要です。結果の自動送信は行いません。
内容を確認したユーザーの投稿記録です。このサイトが直接測定した結果とは区別しています。
設定の問題を報告
この設定でどこにつまずいたかを教えてください。報告を読めるのは管理者だけです。
報告する設定 · MBP M5 Pro 64GB · Gemma 4 26B-A4B (MoE) · バランス
アクティブなパラメータ数と、ダウンロードする重み全体を区別する
このMoEは全約25.2Bのうち、トークンごとに約3.8Bがアクティブになります。その部分だけをダウンロードして実行するわけではないので、変換版全体の容量を確認します。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側に残っている部分を確認します。重みの一部がCPU側へ移っていると、アクティブな計算量が小さくても転送のために生成が遅くなることがあります。GPUへ正常に載った結果と、同じ条件として比較しないでください。
# 1. 로컬 모델 식별자 확인
lms ls
# 2. 호환 변환본을 8K 문맥으로 로드
lms load <gemma-26b-a4b-identifier> --gpu=max --context-length=8192
# 3. 로컬 서버 시작
lms server start --port 1234vllm serve google/gemma-4-26B-A4B-it --host 127.0.0.1 --port 8000 --max-model-len 8192 --gpu-memory-utilization 0.90密なモデルと比べるときも作業条件をそろえる
短い質問が正常に完了したら、普段使う文書を入れてみます。ウォームアップ後に3回の中央値を記録し、初めて読む文書と入力キャッシュを再利用したリクエストは分けて残してください。最初のトークンまでの時間とデコードも区別します。トークン数や量子化が異なる結果を、機器の性能差と取り違えないことが大切です。
密なモデルより速い場合もありますが、常にそうとは限りません。MoEカーネル、メモリアクセス、キャッシュの条件に左右されます。アクティブなパラメータ数だけから速度を逆算せず、ランタイムで実行した結果を使ってください。
速い回答でも、大事な条件が抜けていないか確認します。最高tok/sの数値一つより、繰り返し使う質問をいくつか用意して答えの正しさを確かめるほうが、モデル選びに役立ちます。
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
}'
コンテキストを長くしたら遅くなった場合
モデル本体が同じでも、KVキャッシュや一時領域は増えることがあります。同時リクエストを1件にし、8Kから必要な長さまで段階的に伸ばしてください。急に遅くなったら、まずスワップ、メモリの圧迫、CPUオフロードを確認します。
対応するキャッシュ圧縮を試すときも、重みの精度は同時に変えないでください。どの変更が品質や速度に影響したかを判断するためです。問題が出たら、直前に正常に動いていたコンテキスト長へ戻して比較します。
メモリが多いことの価値は、モデルを一度起動できるかだけでは決まりません。普段の長い入力や他のアプリを併用しても余裕が残るかまで確かめると、自分に必要な構成かを判断できます。
26Bを選んだ理由に立ち返る
12Bより良い結果が必要だった質問で、このモデルが実際に差を出せたかを確認します。差がなければ、小さいモデルを余裕のある状態で使い続ける選択もできます。モデルが大きいという理由だけで、つらい待ち時間を受け入れる必要はありません。
必要な結果と速度が得られたら、ファイル、バージョン、コンテキスト長、キャッシュ設定を保存してください。モデルの可能性を試す段階から、毎日使う道具へ進むための最後の作業です。
NVFP4で実行するには
現在のチェックポイントの案内はTP=1が前提です。MoEバックエンドはCUTLASSまたはMarlinの対応を確認してください。
vLLM · nvidia/Gemma-4-26B-A4B-NVFP4
変更履歴
サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。
Macのモデル形式と実行設定を訂正
MacのMLX実行経路をGGUF Q4_K_Mと区別し、エンジン名・モデル形式・コマンドの表記を揃えました。コマンドで指定していないKVキャッシュ精度とプリフィルのバッチ設定は、モデル・ランタイム設定で確認する案内に変更しました。
コマンドは同じなのにバッチだけが大きくなるように見えていたMLX速度プロファイルも削除しました。
初回入力とキャッシュ再利用の記録を分離
検証手順を変更し、初めて読む入力と同じ入力を繰り返した結果を別々に記録するようにしました。キャッシュの効果を初回プリフィル処理量や機器の差に含めません。
機器・プロファイルの保存と再表示を追加
実行可能なプロファイルを機器の選択と一緒にこのブラウザに最大5件保存し、ガイド一覧から再び開けるようにしました。保存後に公開設定が変わったりプロファイルの提供が終了したりした場合は、実行前の再確認を案内します。
実行エンジンの説明へのリンクを追加
設定に表示されるエンジン名から、該当する実行プログラムの説明へ移動できるようにしました。エンジンを特定できない経路に、推測で別のプログラムをリンクすることはありません。