2026年 Llama 4 Scout を LM Studio で速度計測するには？

読み込みは完了するのに、生成速度が安定せず、LM Studioの表示値だけでは比較できません。

最短の判断は、16GB Macを本番性能の代表にせず、まず資源限界の確認に使うことです。 Llama 4 Scout LM Studio 速度計測を正式に行う場合は、余裕のあるApple Silicon環境でGGUFの量子化形式、実行ランタイム、コンテキスト長、プロンプトを固定し、首字遅延・プロンプト処理・生成速度・連続運転を別々に記録します。

最終更新：2026年9月1日。モデル名とパラメータの確認はMetaの公式発表および公式モデルカード、LM Studioの仕様は公式システム要件を基準に再確認しています。

この手順を読むべき人

コミュニティで配布されたLlama 4 ScoutのGGUFを入手したものの、表示された速度を信用してよいか判断できないMacユーザー向けです。
ローカルMacとクラウドMacの推論環境を比較するAIアプリケーション開発者、デモ環境や社内検証、導入判断の基準を作りたい小規模チームにも適しています。

最初に無効な結論を切り分ける

Llama 4 Scoutは、公式資料上ではMoE構成で、17Bのアクティブパラメータと109Bの総パラメータを持つモデルです。したがって、これを公式の「8B小型モデル」として扱い、16GB Macで一度生成できた結果をScout全体の実用性能とみなす前提は成立しません。公式モデルカードのパラメータ説明と照合してください。

16GB Macで確認できるのは、指定した量子化ファイルが読み込めるか、コンテキスト長をどこまで確保できるか、スワップやエラーが発生する境界です。開発用の試走には役立ちますが、長文処理、複数ユーザー、サービス化の速度を代表する測定にはできません。

また、記録には必ず「Llama 4 Scout」「GGUFの配布元」「量子化形式」を完全な名称で残します。コミュニティが変換したファイルをMeta公式GGUFと表現してはいけません。

第一段階：ダウンロード前にファイルの身元を確定する

配布ページでは、次の項目を確認します。

1. リポジトリの管理者と更新履歴を確認する。
2. ファイル名の量子化表記を記録する。Q4系、Q5系などは同じモデル名でも別ファイルです。
3. SHA-256などのチェックサムが提示されていれば、取得後に照合する。
4. モデルカードのライセンス、対応機能、既知の制限を読む。
5. テキスト専用に変換されていないか、視覚入力や長いコンテキストが失われていないか確認する。
6. LM Studioがそのファイルを認識しても、変換の完全性まで保証されたとは考えない。

この段階でテキスト機能だけが残っているなら、結論の適用範囲を「変換済みGGUFのテキスト生成」に限定します。公式資料とコミュニティファイルの役割を混ぜないことが、後から比較条件を説明するための最低条件です。

第二段階：読み込み前にメモリ条件を固定する

LM Studioのリソース見積もりで、モデル本体、コンテキスト、KVキャッシュ、GPUオフロードを含む構成を先に確認します。モデルの読み込みに関する公式手順でも、読み込み時の設定を明示的に扱っています。読み込みに失敗する構成を何度も強制するより、条件を一つずつ下げて境界を記録する方が有用です。

測定中は、ブラウザーの多数のタブ、動画編集、仮想マシンなど、統合メモリを大きく消費するアプリケーションを閉じます。Apple SiliconではCPUとGPUが同じメモリを共有するため、GPUオフロードを増やせば必ず速くなるとは限りません。Mac上の権限やメモリ使用状況を事前に整理する場合は、macOSの権限移行ガイドも確認しておくと、測定中のアプリケーション競合を減らせます。

Llama 4 Scout LM Studio 速度計測で表示値を正しく読む

LM Studioの「tokens per second」は、読み込み時間、プロンプト処理、生成処理を同じ数字として読むものではありません。首字遅延は最初のトークンが出るまでの時間、プロンプト処理は入力を読み込む速度、生成速度は出力中の継続速度として分離します。

最初の1回はモデル読み込みやMetalの初期化を含むため、ウォームアップとして扱います。その後、短い固定プロンプトと長い固定プロンプトを使い、同じ出力上限で複数回実行します。採用するのは最高値ではなく中央値とし、極端に遅い回やエラーが出た回も除外せず記録します。

ベンチマークの考え方は、llama.cppのllama-bench公式説明にあるように、入力処理と出力処理を分ける方法が基本です。LM Studioの画面で生成速度だけを読んだ場合、長い入力を処理する実際の待ち時間を見落とします。

同じGGUFでもMacごとに速度が変わる理由

同一ファイルでも、チップの世代、統合メモリの余白、GPUオフロード量、コンテキスト長、Metal対応状況、ランタイムの版が違えば結果は変わります。特にメモリが足りない状態では、読み込み成功後にスワップが発生し、短い一回の生成だけでは見えない速度低下が出ます。

ローカルMacとリモートMacを公平に比較する場合は、モデルファイルを変えないだけでは不十分です。次の条件を一致させます。

• 同じGGUFの量子化形式と同じファイルハッシュ
• 同じLM Studioの版と実際のllama.cppランタイム
• 同じコンテキスト長、KVキャッシュ位置、GPUオフロード
• 同じプロンプト、出力上限、サンプリング設定
• 同じウォームアップ後の測定回だけを比較

クラウド側の通信遅延は生成速度とは別の指標です。画面転送やAPIの往復時間を含める場合は、モデル処理時間と分けて記録しないと、Mac本体の性能差を正しく評価できません。

第三段階：最初の連続運転で実用性を確認する

単発の回答が返った後、短い質問、長い入力、複数ターンの対話を順に実行します。ここでは速度だけでなく、次の状態を確認します。

1. 生成速度が回を重ねても急落しないか。
2. メモリ使用量とスワップの増加が止まるか。
3. LM StudioのログにMetalやランタイムのエラーがないか。
4. 途中終了、無限反復、同じ文章の繰り返しがないか。
5. 直前の会話内容を保持できるか。
6. 設定を攻めた結果、回答の完全性を損なっていないか。

温度や消費電力を評価するなら、macOSの記録機能や検証可能な監視ツールのログを保存します。「筐体が熱く感じた」という印象だけで温度や電力を断定してはいけません。LM StudioのREST読み込み仕様を利用する場合も、APIで指定した設定と実際に読み込まれた設定をログで照合します。

測定結果から用途別に判定する

実際の速度数値は、Macのチップ、統合メモリ、macOS、LM Studio、ランタイム、GGUF、量子化、コンテキスト、サンプリング設定が揃わない限り比較できません。したがって、取得していないJexMac環境の速度、温度、消費電力、ファイルサイズを推測して掲載することはしません。

16GB Macでテストできるかという問いには、「動作確認なら条件付きで可能、本格的な性能評価には不十分」と答えるのが適切です。コンテキストを極端に下げる、スワップを許容する、回答品質を犠牲にする、といった条件で得た数字は、サービス運用の合格値にしてはいけません。

最後に残すべき記録と環境選択

測定記録は、次の形式で保存すると再測定しやすくなります。

Macチップ / 統合メモリ / macOS / LM Studio / llama.cppランタイム / GGUF配布元 / 量子化 / コンテキスト / KVキャッシュ / GPUオフロード / サンプリング / 首字遅延 / プロンプト処理 / 生成速度 / スワップ / 連続運転結果

この記録で安定して合格した場合だけ、より長いコンテキストや同時実行数の検証へ進みます。一度だけ回答できた場合は、ローカルの軽量モデルを維持し、Scoutの検証をメモリに余裕のあるクラウドMacへ移す、または用途に合う別モデルへ変更する、という3つの出口を用意します。

現在のMacをそのまま使う方法は、物理的な手軽さと追加費用の少なさが利点です。一方で、統合メモリ不足によるスワップ、他の作業との資源競合、同じ条件を再現しにくい点が、デモやチーム検証では実際の負担になります。短期間だけScoutを試す、複数の設定を比較する、購入前にApple Silicon環境を確認する目的なら、JexMacのMacレンタルの選択肢を使い、同じGGUFと記録項目で再測定する方が、自前の16GB環境だけで結論を急ぐより判断しやすくなります。長期の安定した高負荷運用や物理インターフェースが必要な用途では、レンタルより専用機の購入や別の推論基盤が適しています。