モデル別実行レシピ
Gemma 4 12Bの実行設定：デスクトップのQ4とサーバーのBF16
小さな機器でGemma 4 12Bを試すなら、すべての機能を一度に有効にするより、まずテキストの回答を一つ確認するほうが確実です。正常に回答が完了する設定を残し、長い文書、画像、音声を順に加えていきます。どこでメモリ使用量や待ち時間が増えるのかを確かめるためです。
実行レシピ
機器別の設定
1人で使う場合
使う機器を選ぶと、起動コマンドと調整できる設定が表示されます。
プロファイル
Apple MacBook Pro M5 Pro (64GB)
メモリに収まる推奨ランタイム： LM Studio (MLX 4ビット（GGUF Q4_K_Mとは別形式）) · ドキュメントに基づくランタイム設定
インストール後の初回実行や、毎日安定して使いたいときに
プロファイルのコンテキスト長
16,384 トークン
ランタイムのドキュメントに基づく初期設定です。下の手順に沿って調整し、速度を比べてください。
デコード速度の推定値
31.3 ~ 34.8 tok/s
1人で使う場合の推定値
最初のトークンまでの推定時間
21.3 ~ 46.3秒
プリフィル: 354 ~ 769 tok/s
推定メモリ使用量
約 9.61GB / 56GB
残余の余裕：少ない 46.4GB
サーバーアドレス
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 12B · バランス
Q4変換版か、公式の重みかを確認する
デスクトップでは、使うアプリが対応しているGGUFまたはMLX Q4変換版を選びます。同じ16GBの機器でも、OSやキャッシュ用に残せる容量で扱える範囲は変わります。ダウンロードするファイルの実際の容量を確認し、短いコンテキストから始めてください。
公式google/gemma-4-12B-itのBF16の重みは約24GBです。下のvLLM例は、それを収められる大容量メモリのNVIDIA環境向けで、Q4のデスクトップ用コマンドとは異なります。モデル名が同じでも、メモリ条件を混同しないでください。
最初は画像や音声ではなく、短い韓国語の質問を使います。テキストの基準値を得てから他の対応入力を追加すると、どの機能で負荷が増えたのかを切り分けられます。
LM Studioか、公式チェックポイントのサーバー構成を選ぶ
LM Studioでは、一覧で確認したモデル識別子を指定し、8Kコンテキストの例から始めます。メモリが足りなければさらに短くして、まず読み込めることを確認してください。--gpu=maxはGPUへのオフロードを最大にする指定ですが、実際にどこまで載ったかはアプリの表示とログで確かめます。
この例ではLM Studioは1234、vLLMは8000ポートを使います。別のコマンドのアドレスと混ぜないでください。LM Studioのネットワーク公開設定でも接続できる範囲を確認し、他の機器から接続させる場合は、先に認証とファイアウォールを用意します。
アプリが起動しただけでは、モデルの準備ができたとは限りません。読み込みの完了と実際のコンテキスト設定を確認してから質問を送ります。準備中に複数のリクエストを重ねると、初回実行のメモリ使用量を把握しにくくなります。
# 1. 모델 목록 확인
lms ls
# 2. GPU 최대 오프로드 및 8K 컨텍스트로 모델 로드
lms load <gemma-4-12b-identifier> --gpu=max --context-length=8192
# 3. 로컬 서버 데몬 구동 (127.0.0.1:1234)
lms server start --port 1234vllm serve google/gemma-4-12B-it --host 127.0.0.1 --port 8000 --max-model-len 8192 --gpu-memory-utilization 0.90まず短い韓国語の回答を確認する
下のリクエストのモデル名を、実際に読み込んだ識別子へ変更します。回答が途中で途切れないか、指定した言語で答えるかを先に確認してください。ストリーミングなら文章が少しずつ届く様子も見られますが、正確なtok/sにはランタイムの測定値を使います。
ウォームアップ後、同じ質問を3回実行し、最初のトークンまでの時間、生成速度、ピークメモリを記録します。続いて普段要約する文書に変え、違いを見ます。短い自己紹介ができたからといって、長い業務文書も十分に扱えるとは判断しません。
出力の品質も確認してください。短い質問にはうまく答えても、日付や例外条件を見落とすことがあります。答えを確認できる文書の質問を一つ残しておくと、設定変更後の比較に使えます。
curl -N http://127.0.0.1:1234/v1/chat/completions -H "Content-Type: application/json" -d '{
"model": "<gemma-4-12b-identifier>",
"messages": [
{"role": "user", "content": "한국어로 자기소개를 간단히 작성해줘."}
],
"max_tokens": 512,
"stream": true
}'
画像と音声を追加する
まず、モデルファイルとアプリがその入力形式に対応しているかを確認します。一種類ずつ加え、メモリ使用量がどれだけ増えるかを見てください。テキストだけなら空いていた領域が、エンコーダーや入力処理に使われることがあります。
メモリが少ない環境で失敗するなら、まずコンテキスト長と同時リクエスト数を減らします。キャッシュの精度やオフロードも、一項目ずつ変えて比べてください。すでにQ4のモデルでQ4を選び直しても、別の原因によるメモリ不足は解消しません。
毎日必要な入力で問題が繰り返されるなら、メモリの多い構成を検討する理由があります。逆に、テキストの作業で十分に使えているなら、マルチモーダルの最大条件に合わせるためだけに機器を大型化する必要はないかもしれません。
小さいモデルを使い続ける選択もある
12Bで普段の文書を十分に処理でき、待ち時間も許容できるなら、より大きいモデルへ移る必要はありません。うまく答えられない質問が出てきたら、その質問を次のモデルにも送り、違いを比べるほうが分かりやすくなります。
安定して使えたモデルファイル、アプリのバージョン、入力長を保存してください。再インストールや更新後に戻れる基準になります。小さな機器で役立つ作業を一つ完了できれば、次に必要な性能も具体的に考えられるようになります。
NVFP4で実行するには
Gemma 4ローダーを含むSGLangブランチが必要です。FFNはNVFP4、AttentionはBF16です。
SGLang · AxionML/Gemma-4-12B-NVFP4
変更履歴
サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。
Macのモデル形式と実行設定を訂正
MacのMLX実行経路をGGUF Q4_K_Mと区別し、エンジン名・モデル形式・コマンドの表記を揃えました。コマンドで指定していないKVキャッシュ精度とプリフィルのバッチ設定は、モデル・ランタイム設定で確認する案内に変更しました。
コマンドは同じなのにバッチだけが大きくなるように見えていたMLX速度プロファイルも削除しました。
初回入力とキャッシュ再利用の記録を分離
検証手順を変更し、初めて読む入力と同じ入力を繰り返した結果を別々に記録するようにしました。キャッシュの効果を初回プリフィル処理量や機器の差に含めません。
機器・プロファイルの保存と再表示を追加
実行可能なプロファイルを機器の選択と一緒にこのブラウザに最大5件保存し、ガイド一覧から再び開けるようにしました。保存後に公開設定が変わったりプロファイルの提供が終了したりした場合は、実行前の再確認を案内します。
実行エンジンの説明へのリンクを追加
設定に表示されるエンジン名から、該当する実行プログラムの説明へ移動できるようにしました。エンジンを特定できない経路に、推測で別のプログラムをリンクすることはありません。