モデル別実行レシピ
最終更新
Gemma 4 12Bの実行設定：デスクトップのQ4とサーバーのBF16
Gemma 4 12BをQ4デスクトップとBF16サーバーで実行します
Gemma 4 12Bはテキストの質問を受けて回答を生成し、対応するモデルとアプリの組み合わせでは画像や音声も処理します。ここでは16～24 GBのデスクトップ向けQ4変換版と、より大きなNVIDIA環境向け公式BF161 checkpoint2をそれぞれ準備し、ローカルAPI3の応答を確認します。
2つの経路は同じモデル系列ですが、ファイル形式と実行環境が異なります。デスクトップではアプリが対応するGGUF4またはMLX5 Q4ファイルを選び、公式サーバー例ではNVIDIA上でgoogle/gemma-4-12B-itのBF16重みを使います。まず読み込みとテキスト応答を確認し、必要な場合にだけ文脈を広げたり画像・音声入力を追加したりします。
まずファイル形式と機器の経路を選びます
16 GB環境から始めるなら、現在のアプリが対応するGGUFまたはMLX Q4変換版を使います。約7.5 GBはファイルサイズにすぎず、読み込み後はruntime6、OS、会話のKV cache7、他のアプリもメモリを共有します。取得後、アプリのモデル一覧で識別子と形式を確かめ、短い文脈から始めます。
公式google/gemma-4-12B-it checkpointはBF16で約24 GBです。以下のvLLM例は公式重みを使うNVIDIA server向けであり、Q4デスクトップのcommandとは別経路です。結果を比較するときは重みの精度と実行環境の両方が変わることを記録します。
最初は画像や音声ではなく、短い韓国語のテキスト質問を送ります。最後まで処理できれば、モデルの読み込みとテキスト経路を確認できます。その後、要約する文章や答えが分かっている文書質問を試し、基本応答と追加入力機能を分けて評価します。
LM Studioまたは公式vLLMの一方で起動します
デスクトップcommandはLM Studioに表示されたモデル識別子でQ4ファイルを読み込み、文脈上限を8Kにします。--gpu8=maxはGPU offload9を要求する設定です。起動後、アプリの読み込み状態とlogで実際の経路を確認します。この設定だけでは全重みがGPUに載ったとは判断できません。
公式serverはgoogle/gemma-4-12B-itを文脈8K、GPUメモリ使用率0.90で実行します。例の127.0.0.1 bindはserver processがlocal interfaceで待ち受ける設定です。LM Studioのネットワーク公開範囲も確認し、他の機器から接続できるよう変更する場合は認証とfirewall規則を別途設定します。
process起動後、モデルの読み込み完了と選択名を確認し、まずrequestを1件送ります。正常完了してから文脈や同時request数を変えれば、どの設定がメモリや待ち時間に影響したか追跡しやすくなります。
LM Studioのコマンドは取得済みファイルの選択一覧を開きます。lms lsで確認したGemma 4 12Bを選び、ロードを待ちましょう。API別名をgemma-localに統一します。vLLMを選んだ場合はサーバーのターミナルを残し、別のターミナルからAPIリクエストを送ります。
# 1. List models
lms ls
# 2. Load the model with maximum GPU offload and an 8K context
lms load --gpu=max --context-length=8192 --identifier gemma-local
# 3. Start the local server daemon (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.90APIで短い回答と実作業を確認します
LM Studioには前に付けたAPI別名gemma-localで韓国語の自己紹介を依頼します。vLLMなら8000ポートの例でgoogle/gemma-4-12B-itを使います。回答が最後まで指定言語で届くか確認しましょう。ストリーミングは送信の様子を示すため、正確な生成速度は別測定で記録します。
次に同じ質問を複数回送り、最初のtoken10までの時間、生成区間の速度、peak memoryを記録します。普段の要約文書に変えたら、初回応答までと全体完了までを分けて確認します。短い自己紹介だけで実作業の品質を代表させません。
文書内の日付や担当者など、答えを照合できる質問も使います。設定を比較するときは同じ文章とファイルを保ち、何の変更が結果に影響したか分かるようにします。
LM Studioには下の1234ポートのリクエストを使います。BF16のvLLMサーバーを選んだ場合は、その次の8000ポート用を送ります。/v1/modelsで名前を先に確認すると、アプリにも同じ値を設定できます。
curl -N http://127.0.0.1:1234/v1/chat/completions -H "Content-Type: application/json" -d '{
"model": "gemma-local",
"messages": [
{"role": "user", "content": "한국어로 자기소개를 간단히 작성해줘."}
],
"max_tokens": 512,
"stream": true
}'curl --fail-with-body http://127.0.0.1:8000/v1/models
curl --fail-with-body http://127.0.0.1:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{"model":"google/gemma-4-12B-it","messages":[{"role":"user","content":"Reply with one short sentence."}],"max_tokens":64}'
画像と音声は一つずつ追加します
テキスト基準のrequestが安定して完了したら、実際のアプリとモデルの組み合わせが対応する画像入力を追加します。質問文は固定し、画像だけを変えると入力経路とメモリの変化を比較しやすくなります。画面でファイルを添付できるだけでは画像がモデルに届いたとは限らないため、requestに含まれたか確認します。
音声では、文字起こしか音声についての会話かを先に決め、録音がアプリ経由でモデルに届くか試します。画像・録音・長文書を一度に組み合わせなければ、失敗原因を見つけやすく、multimodal encoderと入力処理のメモリも個別に観察できます。
メモリ不足が起きたら、まず文脈と同時request数を減らし、テキスト基準のrequestが回復するか確認します。重みファイルのQ4形式とKV cache精度は別設定なので区別して調整します。普段の作業で同じ制限が繰り返されるなら、実際に必要な余裕を基準に大容量メモリ環境を検討します。
作業に必要な経路だけを選びます
Q4構成で文書やテキスト依頼を十分に処理でき、待ち時間も許容範囲なら、より大きな重みに替える必要はありません。別候補を試すときは同じファイル、質問、文脈を使い、作業の成功と全体完了時間を比較します。
公式BF16 serverを運用する予定なら、約24 GBの重みとruntime用の余裕を載せられるNVIDIA環境を別途検討します。実際に使うファイルと入力機能を決めてから購入条件を合わせれば、使わない経路のメモリまで費用に含めずに済みます。正常に動作したモデルファイル、アプリ版、文脈、server設定を記録し、更新後の再テスト基準にします。
NVFP4配布版では実行環境との互換性を確認します
用語の注釈
BF16 — モデルの数値に使う16ビット浮動小数点形式です。指数部はFP32と同じ幅で、同程度に広い値の範囲を表せます。
本文に戻るチェックポイント — 学習済みモデルの重みなどを保存したファイルです。同じモデル系列でも、版や用途によって異なるチェックポイントを使うことがあります。
本文に戻るAPI — 別のコードからプログラムの機能を呼び出すための決められたインターフェースです。
本文に戻るGGUF — モデル情報を格納するファイル形式で、llama.cpp系のツールで広く使われます。
本文に戻るMLX — Appleが開発する機械学習フレームワークで、Apple SiliconのCPUとGPUが共有するメモリを使ってモデルを実行します。
本文に戻るランタイム — プログラムの実行時に必要な機能を提供するソフトウェア環境です。ローカルAIではモデル実行エンジンを指すこともあります。
本文に戻るKVキャッシュ — 過去トークンのAttention用キー・バリューを保存し、後続トークン生成で再利用するメモリです。容量はコンテキスト長やバッチサイズで変わります。
本文に戻るGPU — 多くの計算を並列に処理するプロセッサーです。AIモデルの実行ではモデル計算を担います。
本文に戻るオフロード — 容量が足りないとき、モデルデータの一部をGPUメモリからシステムRAMやストレージへ移して処理する方法です。データ転送が追加されます。
本文に戻るトークン — モデルが入力や出力を分けて処理する単位です。
本文に戻るNVFP4 — NVIDIAが定義した4ビット浮動小数点データ形式です。対応状況はGPU世代、モデル、ソフトウェア実装によって異なります。
本文に戻るAttention — 入力トークン間の関連度を計算し、各位置の情報を現在の表現に反映するニューラルネットワーク演算です。
本文に戻る
よくある質問
- この記事で最初に確認すべきことは何ですか？
- Gemma 4 12Bはテキストの質問を受けて回答を生成し、対応するモデルとアプリの組み合わせでは画像や音声も処理します。ここでは16～24 GBのデスクトップ向けQ4変換版と、より大きなNVIDIA環境向け公式BF16 checkpointをそれぞれ準備し、ローカルAPIの応答を確認します。
- 必要なメモリはどのくらいですか？
- 16 GB環境から始めるなら、現在のアプリが対応するGGUFまたはMLX Q4変換版を使います。約7.5 GBはファイルサイズにすぎず、読み込み後はruntime、OS、会話のKV cache、他のアプリもメモリを共有します。取得後、アプリのモデル一覧で識別子と形式を確かめ、短い文脈から始めます。
実行レシピ
機器別の設定
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 · バランス
変更履歴
サイトの説明を変更した記録です。インストール済みのエンジンやモデルのバージョンを自動で確認した結果ではありません。
Macのモデル形式と実行設定を訂正
MacのMLX実行経路をGGUF Q4_K_Mと区別し、エンジン名・モデル形式・コマンドの表記を揃えました。コマンドで指定していないKVキャッシュ精度とプリフィルのバッチ設定は、モデル・ランタイム設定で確認する案内に変更しました。
コマンドは同じなのにバッチだけが大きくなるように見えていたMLX速度プロファイルも削除しました。
初回入力とキャッシュ再利用の記録を分離
検証手順を変更し、初めて読む入力と同じ入力を繰り返した結果を別々に記録するようにしました。キャッシュの効果を初回プリフィル処理量や機器の差に含めません。
機器・プロファイルの保存と再表示を追加
実行可能なプロファイルを機器の選択と一緒にこのブラウザに最大5件保存し、ガイド一覧から再び開けるようにしました。保存後に公開設定が変わったりプロファイルの提供が終了したりした場合は、実行前の再確認を案内します。
実行エンジンの説明へのリンクを追加
設定に表示されるエンジン名から、該当する実行プログラムの説明へ移動できるようにしました。エンジンを特定できない経路に、推測で別のプログラムをリンクすることはありません。