LM Studioおすすめ設定｜メモリ別モデル比較
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
LM Studio 0.4.20を基準に、Context Length、GPU Offload、Flash Attention、KVキャッシュの設定と、8〜128GBの搭載メモリ別おすすめモデルを解説します。
先に結論
- 2026年7月24日時点の安定版はLM Studio 0.4.20。まずアプリと推論runtimeを更新してから設定する
- 最初の設定はContext Length 8,192、GPU OffloadはAuto、Flash AttentionはON、その他はモデル既定値が安全
- モデルはQ4_K_MまたはMLX 4bitから始め、モデル・KVキャッシュ・runtimeを含む推定使用量に20〜25％の余白を残す
- 搭載メモリ別の本命は、8GBがQwen3.5 4B、16GBがQwen3.5 9B、24GBがGemma 4 26B-A4B、32GBがQwen3.6 35B-A3B
- 64GBではQwen3-Coder-Nextがコーディング用途の候補。96GBはNemotron 3 Superの最小量子化が限界寄り、128GBなら同モデルを余白込みで扱いやすい
- 「最大256K・1M context対応」は常用推奨値ではない。8Kから始め、16K、32Kと必要な分だけ増やす
迷ったら、使える最大モデルではなく、日常のpromptと必要なcontextを入れてもmemory警告が出ないモデルを選びます。少し小さいモデルをGPUへ全層offloadした方が、巨大モデルをCPUへ逃がすより快適な場合が多くあります。
情報監査日: 2026年7月24日
対象: LM Studio 0.4.20、LM Studio Engine Protocolが有効な現行UI、GGUF / llama.cpp系とApple SiliconのMLX系。設定名はmodel、engine、OSにより表示されない場合があります。
容量の扱い: モデル欄のGBはLM Studio公式catalogに表示された最小構成の目安です。実際の使用量にはKV cache、vision encoder、runtime、OS、他アプリが加わります。
画像: アイキャッチはメモリ容量ごとのモデル選択を表現した当サイトの要点図解で、LM Studioの実画面ではありません。
LM Studio 0.4.20で変わった前提
LM Studio公式changelogでは、2026年7月22日に0.4.20が公開されています。0.4.19から安定版でLM Studio Engine Protocolが標準ONとなり、0.4.17以降は一部の設定場所も変わりました。古い解説動画と画面が違う場合は、現在のMy Models → 対象モデルの歯車、またはモデル読み込み時のLoad Parametersを確認します。
0.4.16ではdefault context lengthが8Kへ更新されました。これは現行モデルの128K、256K、1Mという最大値より小さいものの、初回起動時の速度、memory消費、安定性のバランスがよい出発点です。
モデルごとの既定値は、My Modelsで対象モデルの歯車を開いて保存できます。LM Studio公式のPer-model Defaultsも、GPU Offload、Context Size、Flash Attentionをモデル単位で保存できると説明しています。
最初に区別するRAM、VRAM、統合メモリ
「32GBのPC」という表現だけでは、動かせるモデルを正確に決められません。LM Studioでは次の3種類を分けます。
| 構成 | モデルを置く場所 | 選び方 |
|---|---|---|
| Apple Silicon Mac | CPUとGPUが共有するUnified Memory | 搭載メモリ全体からOSとアプリ分を引く |
| Windows / Linux＋離散GPU | 主にGPUのVRAM、入り切らない層はsystem RAM | まずVRAM内へ全層を収めるモデルを優先 |
| CPUのみ、iGPU中心 | system RAM | 容量は載ってもmemory帯域が速度を制限しやすい |
たとえばsystem RAM 32GB、VRAM 8GBのPCは「32GBのGPU」と同じではありません。8GB VRAMへ重みとKV cacheが収まらなければ、一部をRAMへ置けますが、PCIeをまたぐ転送でdecodeが遅くなります。一方、32GBのApple Siliconは同じpoolをCPUとGPUで使うため、20GB前後のmodelも動かしやすい反面、OSやブラウザーもその32GBを共有します。
安全側の目安は、モデル読み込み後も搭載memoryの20〜25％を空けることです。離散GPUは表示用に1〜2GBのVRAMも残します。これは一律の保証値ではなく、長文脈、画像入力、並列request、他アプリの量で調整する実用上の目安です。
まず使うロード設定
| 項目 | 最初の推奨値 | 変更する場面 |
|---|---|---|
| Context Length | 8,192 | 文書・codeが入らないとき16K、32Kへ段階的に増やす |
| GPU Offload | Auto | 推定上収まるならMax。VRAM不足時だけ割合を下げる |
| Flash Attention | ON / Auto | 非対応engineや不具合の切り分け時だけOFF |
| KV Cache Offload | ON / Auto | 離散GPUのVRAMが足りないときRAM側へ移す |
| KV Cache Quantization | FP16既定 | 長文脈で不足するときQ8、最後の手段としてQ4を比較 |
| Evaluation Batch Size | 512またはAuto | 読み込み・prefillでOOMなら256、128へ下げる |
| CPU Thread Pool Size | Auto | CPU推論で他アプリが重い場合だけ物理core数より1〜2少なくする |
| Speculative Decoding | 初回はOFF | 基準速度を測った後、互換draft modelまたはMTPを有効化 |
現行のLoad Model APIにも、Context Length、Evaluation Batch Size、Flash Attention、KV cacheのGPU offloadがload設定として定義されています。設定を変えたらmodelを読み直し、同じpromptでPeak Memory、Time to First Token、Tokens per Secondを比較します。
Context Lengthは最大値へ上げない
Context Lengthは「一度に保持できるinput、会話履歴、outputの合計上限」です。大きくするとKV cacheが増え、長いpromptのprefillも重くなります。モデルカードに256Kと書かれていても、日常chatが4K以内なら8K設定で十分です。
- 8K: chat、要約、短いcode、最初の動作確認
- 16K: 複数ファイルのcode、小さな仕様書、長めの会話
- 32K: repository調査、複数文書の比較。memory再見積もりが必須
- 64K以上: 必要性を確認し、prefill時間と回答精度まで段階的に測る
GPU OffloadはAutoからMaxを試す
GPU Offloadはmodel layerをGPUへ置く割合です。LM Studioは未指定時にhardwareに合わせて自動調整します。モデルとKV cacheがVRAMへ収まるならMaxが一般に高速です。OOMになる場合は、Context Lengthを下げ、不要なmodelをunloadし、それでも足りなければoffload割合を下げます。
「70％offloadなら70％の速度」という単純な関係ではありません。CPU側のmemory帯域、PCIe、architectureで変わります。速度が重要なら、部分offloadで大型modelへ挑む前に一段小さいmodelの全層offloadも比較します。
Flash AttentionとKVキャッシュ
Flash Attentionは対応するllama.cpp系modelでattention計算を最適化し、速度向上とmemory削減が期待できます。通常はONまたはAutoでよく、出力異常やruntime固有の問題を調べるときだけOFFと比較します。
KV cacheは過去tokenの計算結果です。離散GPUでKV Cache OffloadをOFFにするとVRAMを空けられますが、system RAMを使い、速度が下がる場合があります。KV cache量子化は長文脈を載せる手段ですが、まずFP16、次にQ8で品質と速度を比較し、Q4は用途固有の評価後に使います。
Batch SizeとCPU Threadsは最後に触る
Evaluation Batch Sizeは主にpromptをまとめて処理する量です。大きいほどprefillが速くなる可能性がある一方、peak memoryが増えます。loadや長文入力で落ちる場合は512から256、128へ下げます。生成される1 tokenずつのdecodeを大幅に速くする設定ではありません。
CPU Thread Pool SizeはAutoが基本です。CPU推論時に手動設定するなら、論理threadを全部埋めるより、物理core相当から1〜2 coreをOSへ残す方が操作しやすい場合があります。値を増やしてもmemory帯域が飽和すれば速くなりません。
量子化はQ4から選ぶ
| 量子化 | 使いどころ | 判断 |
|---|---|---|
| Q4_K_M / MLX 4bit | 最初のdownload、容量優先 | 本記事のメモリ別表の基準 |
| Q5_K_M / MLX 5〜6bit | 余白があり品質を上げたい | 同じmodelを長く使う場合の本命 |
| Q8_0 / MLX 8bit | 量子化差を小さくしたい | 容量増に対する改善を実promptで確認 |
| Q2 / Q3 | 大規模MoEを限界memoryへ載せる | 小型dense modelでは品質低下を受けやすく、通常は避ける |
同じ容量なら「小さいmodelのQ8」と「大きいmodelのQ4」のどちらが常に上とは限りません。日本語、coding、tool call、画像、長文など自分のtaskを10〜20問用意して比べます。LM Studio catalogのmodel cardがQAT版や推奨presetを用意している場合は、手動でtemplateやsamplingを上書きせず、その組み合わせを優先します。
搭載メモリ別おすすめモデル
次の表は、1modelを対話用途で使い、OSとKV cacheの余白を残す安全側の出発点です。Apple Siliconは搭載Unified Memory、CPU中心のPCはsystem RAMを基準にしています。離散GPUでは後述のVRAM目安も確認してください。
| 搭載メモリ | 本命モデル | catalog表示 | 開始context | 選ぶ理由 |
|---|---|---|---|---|
| 8GB | Qwen3.5 4B | 約3.75GB | 4K〜8K | 日本語を含む多言語、画像、reasoningを小容量で試せる。重ければ2Bへ |
| 16GB | Qwen3.5 9B | 約7.0GB | 8K | 日常chat、要約、軽いcodingの速度と品質が均衡 |
| 24GB | Gemma 4 26B-A4B | 約15.6GB | 8K | 総26B・active約4BのMoE。画像、reasoning、tool useも扱う |
| 32GB | Qwen3.6 35B-A3B | 約20.4GB | 8K〜16K | 総合、画像、agentic codingに強く、active 3Bでdecodeが軽い |
| 64GB | Qwen3.6 35B-A3Bの高精度量子化 | 4bitは約20.4GB | 16K〜32K | Q5〜Q8と長めのcontextを安定運用。coding専用ならQwen3-Coder-Next |
| 96GB | Qwen3-Coder-Next | 約42GB | 16K〜32K | 80B total・3B activeのcoding agentを十分な余白で利用 |
| 128GB | Nemotron 3 Super | 約83GB | 8K〜16K | 120B total・12B active。reasoning、tool use、日本語対応の大型MoE |
8GB：Qwen3.5 4B、安定優先なら2B
LM StudioのQwen3.5 catalogは、2Bを約2.0GB、4Bを約3.75GB、9Bを約7.0GBで掲載しています。8GB機では4BをQ4 / MLX 4bit、4K〜8K contextで始めます。ブラウザーを多く開く、画像を連続投入する、memory圧縮が頻発する場合は2Bへ下げます。
8GB VRAMの離散GPUはsystem RAM 8GBとは条件が違いますが、表示用VRAMとKV cacheを考えると4Bの全層offloadが安全です。9Bはmodel fileだけで約7GBあるため、8GB VRAMへ無理に詰めず、部分offloadか一段小さい量子化を検討します。
16GB：Qwen3.5 9B
16GBではQwen3.5 9Bの4bitが扱いやすい本命です。text、画像、reasoning、tool useを1modelで試せます。画像理解を重視する場合は、約7.4GBのGemma 4 12Bも比較候補です。
Qwen3.6 27Bはcatalog上約16.1GBなので、16GB搭載機ではmodelだけでほぼ上限です。loadできてもOSとKV cacheの余白がなく、日常推奨にはしません。
24GB：Gemma 4 26B-A4B
Gemma 4公式catalogページでは、26B-A4Bが約15.6GBです。総25.2Bのweightを持ちながら1 token当たり約3.8Bを使うMoEで、画像、reasoning、function calling、日本語を含む多言語に対応します。24GB Macやsystem RAM 24GB級で、8K contextから始める候補です。
同じ容量帯のQwen3.6 27Bは約16.1GBです。dense 27Bなので、複雑なcodingや総合品質を優先して速度を許容できる場合は比較する価値があります。
32GB：Qwen3.6 35B-A3B
Qwen3.6のcatalogは、35B-A3Bを約20.4GB、dense 27Bを約16.1GBで掲載しています。35B-A3Bはactive 3BのMoEで、画像入力、reasoning、tool use、repository-level codingを狙った現行の総合候補です。
32GBなら4bit版と8K〜16K contextから始められます。回答の深さを重視するならThinkingをON、短い質問や日常chatではOFFを比較します。過去のthinkingをすべて保存する設定はcontextを消費するため、長いagent session以外は既定値のままが安全です。
64GB：高精度Qwen3.6、codingならQwen3-Coder-Next
64GBでは単に最大modelを詰めるより、Qwen3.6 35B-A3BのQ5〜Q8、16K〜32K context、画像入力を余白込みで使う構成が安定します。
コーディングが主目的なら、Qwen3-Coder-Nextが有力です。80B total・3B active、catalogの最小構成は約42GBで、256K native contextとtool useを備えます。ただし64GBで256Kをそのまま設定する余裕はなく、まず16Kから始めます。
96GB：Qwen3-Coder-Nextを快適に、Nemotronは限界寄り
96GBならQwen3-Coder-Nextへ20GB以上の余白を取り、32K contextやcoding tool、IDEを同居させやすくなります。大型general modelではNemotron 3 Superの最小構成が約83GBですが、OSとKV cacheを含めると余白は約13GBしかありません。8K context、単一model、他アプリを閉じた条件から試す上級者向けです。
128GB：Nemotron 3 Super
Nemotron 3 Superのcatalogページは、120B total・12B active、最小構成約83GB、最大1M contextとしています。日本語を含む7言語、reasoning、tool useに対応し、128GBならweightを置いた後も約45GBをOS、KV cache、runtimeへ残せます。
ただし1M contextはmodel仕様の上限で、128GBにおける初期設定ではありません。8Kまたは16Kで速度と品質を確認し、32K、64Kと増やします。MTP対応modelではLM Studio 0.4.14からMTP Speculative Decodingが安定機能になっていますが、最初はOFFで基準を測り、有効化後のaccept率と速度を比較します。
離散GPUはVRAMで読み替える
| GPU VRAM | 安全側のモデル目安 | 補足 |
|---|---|---|
| 6〜8GB | 2B〜4B Q4 | display用とKV cacheを残す |
| 12GB | 9B Q4 | 8K contextから開始 |
| 16GB | 12B Q4 | 15〜16GBのmodelは余白不足になりやすい |
| 24GB | 27B / 35B-A3B Q4 | 20GB級weight＋短中context |
| 48GB | 35B高精度量子化、80B MoE Q4 | 42GB modelはcontextとruntimeを見積もる |
| 96GB | 120B MoEの約83GB版 | 長文脈や並列requestでは余白を再確認 |
VRAMを超えるmodelもCPU Offloadで動く可能性はありますが、快適さはhardwareごとに大きく変わります。購入判断では「loadできた」という報告より、同じquantization、context、GPU offload率でのdecode速度を見るべきです。
生成パラメーターはモデル既定値から始める
Temperature、Top P、Top K、Repeat Penaltyはload容量ではなく、回答の選び方を変えるprediction parameterです。現行modelは専用presetやthinking toggleを持つため、古いLlama向けの値を全modelへコピーしません。
| 用途 | Temperatureの出発点 | Max Output | 注意 |
|---|---|---|---|
| 通常chat・要約 | model preset、未指定なら0.7前後 | 2,048〜4,096 | Top P / Top Kもpresetを維持 |
| 情報抽出・JSON | 0.1〜0.3 | 1,024〜2,048 | schemaと停止条件を明示 |
| code修正 | 0.2〜0.5 | 4,096〜8,192 | agent modelは公式presetとも比較 |
| 創作 | 0.8〜1.0 | 4,096以上 | 破綻するならTop Pを同時に大きく動かさない |
| reasoning | model preset | 8,192以上も検討 | Thinking tokenもcontextとoutputを消費 |
比較ではSeedを固定し、同じsystem promptと入力を使います。Temperatureだけを変えて3回ずつ実行し、正答率、指示遵守、冗長さ、tool call成功率を見ると、速度だけでなく使いやすさを判断できます。
読み込み前に必要メモリを見積もる
LM Studioのlms load公式資料では、--estimate-onlyでcontext、GPU offload、Flash Attention、visionの有無を含むresource estimateを確認できます。model keyはdownload後にlms lsで確認します。
lms ls
lms load --estimate-only <model-key> \
--context-length 8192 \
--gpu max
lms load <model-key> \
--context-length 8192 \
--gpu max \
--ttl 1800
推定がguardrailを超えたら、次の順で軽くします。
- Context Lengthを半分にする
- 他のloaded modelをunloadする
- 同じmodelのQ4 / MLX 4bitへ下げる
- 一段小さいmodelへ変更する
- 離散GPUではKV cacheをRAMへ移す、またはGPU offload率を下げる
- 最後にEvaluation Batch SizeとKV cache量子化を調整する
APIや常駐serverではTTLも有効です。30分使わなければunloadするなら--ttl 1800とし、別のmodelやアプリへmemoryを返せます。
Speculative Decodingは後から試す
LM Studio公式のSpeculative Decoding解説は、大きいmain modelと同じ語彙を持つ小さいdraft modelを組み合わせ、draft tokenをmain modelが検証する仕組みを説明しています。品質を落とさず速くなる可能性がありますが、2model分のmemoryと計算を使い、promptによっては遅くなります。
最初にmain model単体を測り、次にdraft modelを追加してaccepted draft tokens、Tokens per Second、Peak Memoryを比較します。MTP head内蔵modelは別modelを追加しない方式を使えます。いずれも「ONにすれば必ず高速」ではありません。
よくある失敗と直し方
| 症状 | 主な原因 | 最初に試すこと |
|---|---|---|
| model loadでOOM | weight＋KV＋runtimeが上限超過 | contextを半分、Q4、他modelをunload |
| loadできるが極端に遅い | CPUへの部分offload、memory swap | 小さいmodelを全層GPUへ載せて比較 |
| 長いpromptで落ちる | KV cache、batchのpeak | contextとEval Batchを下げる |
| 回答が毎回ぶれる | samplingとseed | presetへ戻し、比較時だけseed固定 |
| 回答が途中で切れる | Max Outputまたはcontext上限 | input＋history＋outputの合計を確認 |
| thinkingだけで長くなる | reasoning ON、budget過大 | 簡単なtaskはThinking OFF / Lowへ |
Apple SiliconのMLXでは、2026年6月公開のmlx-engine v1.8.5の解説が、反復する長文agent workflow向けにdisk-backed KV cacheを導入し、Qwen3.6 27Bを使った改善例を報告しています。長い会話の2turn目が速い場合はmodel自体のdecode向上だけでなく、prefix cacheが再利用された可能性も分けて見ます。
よくある質問
32GBならQwen3.6 35Bを256K contextで使えますか？
推奨しません。modelの最大contextと、32GB機で安定するcontextは別です。約20.4GBの最小modelにOS、runtime、KV cache、vision入力が加わるため、8K〜16Kから始め、resource estimateを見て増やします。
Q8ならQ4より必ず賢くなりますか？
量子化誤差は小さくなりますが、体感差はmodelとtask次第です。Q8へ上げるため一段小さいmodelを選ぶより、大きいmodelの良質なQ4が強い場合もあります。同じ評価promptで比較してください。
RAMが多ければGPUなしでも速いですか？
容量と速度は別です。RAMが多ければ大型modelをloadできますが、decodeはmemory帯域とcomputeに制限されます。CPUのみではloadできても、GPUや高帯域Unified Memoryより遅い場合があります。
Flash Attentionは常にONでよいですか？
対応する現行runtimeではON / Autoを出発点にできます。不具合、非対応architecture、出力異常を切り分ける場合だけOFFと比較し、runtime更新後に再確認します。
日本語用途だけならどのmodelがよいですか？
8〜16GBはQwen3.5 4B / 9B、24〜32GBはGemma 4 26B-A4BとQwen3.6 35B-A3Bを同じ日本語promptで比較するのが現実的です。128GBでは日本語を明記したNemotron 3 Superも候補です。翻訳、要約、敬語、固有名詞など用途別に試します。
まとめ
LM Studioの設定は、Context Length 8K、GPU Offload Auto、Flash Attention ON、model preset維持から始めれば、大きく外しにくくなります。必要なcontextだけを増やし、読み込み前にresource estimateを確認し、20〜25％のmemory余白を残すことが安定運用の基本です。
モデルは8GBのQwen3.5 4Bから、16GBの9B、24GBのGemma 4 26B-A4B、32GBのQwen3.6 35B-A3Bへ段階的に上げます。64〜96GBは高精度量子化やQwen3-Coder-Nextを余裕を持って使う価値があり、128GBではNemotron 3 Superの120B MoEが現実的な大型候補です。
最大context、最大parameter、最高quantizationを同時に狙う必要はありません。自分のtaskで全層GPU offloadでき、必要な文脈を保持し、毎日待てる速度で返る構成が、そのPCにとっての最適設定です。
参照資料
- LM Studio Changelog：0.4.20、Engine Protocol、8K default、MTP対応（2026年7月22日更新版、7月24日確認）
- LM Studio：lms load、GPU Offload、Context Length、resource estimate（2026年7月24日確認）
- LM Studio：Load a model REST API（2026年7月24日確認）
- LM Studio：Per-model Defaults（2026年7月24日確認）
- LM Studio Model Catalog：Qwen3.5（2026年6月3日更新版を7月24日確認）
- LM Studio Model Catalog：Qwen3.6（2026年6月3日更新版を7月24日確認）
- LM Studio Model Catalog：Gemma 4（2026年6月3日更新版を7月24日確認）
- LM Studio Model Catalog：Qwen3-Coder-Next（2026年7月24日掲載確認）
- LM Studio Model Catalog：Nemotron 3 Super（2026年7月24日掲載確認）
- LM Studio：Speculative Decoding（2026年7月24日確認）
- LM Studio：Improving the MLX Engine for Agentic Workflows（2026年6月5日）
