> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tokios.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Tokios exposes private local models through https://api.tokios.com using an outbound-only connector tunnel.
> Use 'connector' for the local tokios-connector process.
> Use 'deployment' for the public model name in the API model field.
> Use 'upstream model id' for the model served by Ollama, llama.cpp, vLLM, LM Studio, or another local backend.
> API keys use the prefix sk-tok-. Connector tokens use the prefix ct-tok-.

# LM Studio を速度とメモリの観点で最適化する

> LM Studio の速度を最大化するためのチューニングです。GPU オフロード、コンテキストウィンドウ、flash attention、KV キャッシュの量子化、バッチサイズを解説します。これらの設定でレイテンシを 2-5x 削減できます。

LM Studioは最もユーザーフレンドリーなローカルモデル実行方法だ — モデルをダウンロードし、Loadをクリックすればチャットを始められる。内部ではllama.cpp（およびApple SiliconではMLX）をラップし、ハードウェアの使用方法を制御する設定オプションを公開している。デフォルトはカジュアルな使用には機能するが、重要なパフォーマンスを逃している。このガイドでは重要なすべての設定項目と、ワークロードに応じた設定方法を解説する。

> [!NOTE]
>
> Last verified: 2026-10-14 — LM Studio v0.3.26 / Bionic 1.1.8.

> [!NOTE]
>
> **Apple SiliconはMLXを使用する。** Apple Silicon搭載Macでは、LM Studioは自動的にllama.cppではなくAppleのMLXフレームワークを使用する。MLXはMシリーズチップで大幅に高速な推論を提供する（[Apple SiliconとMLXの最適化](#apple-silicon-and-mlx-optimization)を参照）。このガイドのほとんどの設定オプションは両方のバックエンドに適用される。動作が異なる場合は明示的に説明する。

## コンテキストウィンドウのチューニング

コンテキストウィンドウは単一リクエストでモデルが処理できるトークン数を制御する — プロンプトと生成されるレスポンスの合計だ。モデルウェイト自体に次ぐメモリ使用量の最大のドライバーだ。

### LM Studioでコンテキストウィンドウを増やす方法

LM Studioのデフォルトは互換性のために2048トークンのコンテキストウィンドウだ。ほとんどの最新モデルは8K、32K、または128Kトークンをサポートするが、LM Studioはデフォルトでモデルの最大値を使用しない — メモリ使用量を抑えるために2048を使用する。

設定方法は3つある：

**UI内（モデルロードパネル）：**

モデルをロードすると、ロードパネルに**Context Length**スライダーが表示される。 desired値（例：8192、16384、32768）にドラッグしてから**Load Model**をクリックする。

**モデルごと（永続デフォルト）：**

特定のモデルのデフォルトコンテキスト長を設定し、ロードするたびに適用されるようにする。ライブラリでモデルに移動し、ギアアイコンをクリックし、**Per-model Defaults**の**Context Length**を設定する。詳細は[Per-model Defaults](https://lmstudio.ai/docs/app/advanced/per-model)を参照。

**API経由（リクエストごと）：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Summarize this document..."}],
    "context_length": 32768
  }'
```

**CLI経由：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
lms load llama-3.1-8b-instruct --context-length 32768
```

### コンテキストウィンドウのメモリコスト

KVキャッシュはコンテキスト長に比例して増加する。計算式：

```
KV cache memory = 2 × num_layers × hidden_dim × num_ctx × precision_bytes
```

7Bモデル（32レイヤー、4096 hidden dimension）のf16精度の場合：

| Context length | KV cache memory |
| - | - |
| 2,048 (default) | \~1 GB |
| 8,192 | \~4 GB |
| 32,768 | \~16 GB |
| 128,000 | \~64 GB |

> [!TIP]
>
> コンテキスト長はワークロードが実際に必要とする高さまでにのみ設定すること。2Kプロンプトを送信するコーディングエージェントは128Kコンテキストウィンドウから利益を得ない — 他のリクエストをサービスするかより大きなモデルを収めるために使用できた64 GBのKVキャッシュスペースを無駄にするだけだ。

## Flash attention

Flash attentionはLM Studioが提供するほぼフリーのパフォーマンス向上だ。トークン間のアテンションの計算方法を見直す — 完全なアテンション行列をメモリに展開する代わりに、高速なSRAMに収まるタイル状のチャンクでアテンションを計算する。結果は以下の通りだ：

* **30-50%低いメモリ使用量** — KVキャッシュの、ロングコンテキスト長で最大の効果がある。
* **高速な推論** — 特にGPU上で効果的であり、タイル計算がテンソルコアにうまくマッピングされる。
* **同じ出力品質** — flash attentionは標準アテンションと数学的に等価であり、近似ではない。

### LM Studioでflash attentionを有効にする方法

**UI内：**

モデルをロードすると、ロードパネルに**Flash Attention**トグルが表示される。**Load Model**をクリックする前に有効化する。

**モデルごと（永続デフォルト）：**

特定のモデルのデフォルトを設定し、ロードするたびに適用されるようにする。ライブラリでモデルに移動し、ギアアイコンをクリックし、**Per-model Defaults**の**Flash Attention**を有効化する。

**API経由：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "flash_attention": true
  }'
```

> [!TIP]
>
> **常にflash attentionを有効にすること。** 特定のモデルやプラットフォームで互換性の問題に遭遇しない限り、オフにする理由はない。このガイドで最も影響の大きい設定だ。

> [!NOTE]
>
> MLXバックエンドを使用するApple Siliconでは、flash attentionはデフォルトで有効化されており、この設定は効果を持たない — MLXは常に最適化されたアテンションカーネルを使用する。

## GPUオフロード戦略

LM StudioはモデルレイヤーをGPUに自動的にオフロードする。モデル全体がVRAMに収まる場合、すべてのレイヤーが最大速度でGPU上で実行される。VRAMが逼迫している場合、LM StudioはレイヤーをGPUとCPUに分割する — GPUが可能な限りを実行し、残りはシステムRAMにフォールバックする。

### LM StudioがGPUレイヤーを決定する方法

LM StudioのGPUスケジューリングは以下の順序で動作する：

1. **フルオフロード** — モデルウェイト + KVキャッシュがVRAMに収まる場合、すべてのレイヤーがGPUに送られる。これが最速の設定だ。
2. **パーシャルオフロード** — モデル全体が収まらない場合、LM StudioはVRAMが許す限りのレイヤーをGPUに配置し、残りをCPUで実行する。CPU常駐レイヤーのために各フォワードパスがPCIeバスを渡る必要があるため、パフォーマンスが低下する。
3. **CPUのみ** — GPUが利用できないか、VRAMが数レイヤーすら収めるには小さすぎる場合、モデル全体がCPU上で実行される。

### GPUオフロードの制御

次の**GPU Offload**設定でGPUにオフロードするレイヤー数を制御する。UI、モデルごとのデフォルト、またはAPIで設定する：

**UI内：**

モデルをロードすると、ロードパネルに**GPU Offload**スライダーが表示される。以下を設定できる：

* **Auto**（デフォルト） — LM Studioが利用可能なVRAMを自動検出し、収まる限りのレイヤーをオフロードする。
* **Max** — すべてのレイヤーをGPUに強制する。モデルが収まることを確認している場合に使用する。
* **Off** — GPUオフロードを完全に無効化する（CPUのみの推論）。
* **Manual** — スライダーをドラッグして特定のレイヤー数を設定する。

**モデルごと（永続デフォルト）：**

特定のモデルのデフォルトを設定する。ライブラリでモデルに移動し、ギアアイコンをクリックし、**Per-model Defaults**の**GPU Offload**を設定する。

**API経由：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "gpu": "max"
  }'
```

| `gpu` value | Behavior |
| - | - |
| `"auto"` (default) | LM Studio auto-detects based on available VRAM |
| `"max"` | All layers on GPU — use when you know the model fits |
| `"off"` | No GPU offload — CPU only |
| `0.0` to `1.0` | Fraction of layers on GPU (e.g., `0.5` = 50% of layers) |

> [!TIP]
>
> ほとんどの場合、GPUオフロードは**Auto**のままLM Studioに決定させること。特定の分割を強制する必要がある場合にのみ手動で設定する — 例えば、より大きなコンテキストウィンドウのためにVRAMを確保する場合や、ぎりぎりで収まるモデルの一部のレイヤーをCPUに保持する場合。

### VRAM見積もり

オフロードされた各レイヤーはウェイトとKVキャッシュの両方のためにVRAMを消費する。大まかな見積もり：

```
VRAM per layer ≈ (parameters_per_layer × bytes_per_weight) + (KV_cache_per_layer × num_ctx)
```

7Bモデル（Q4\_K\_M、ウェイトあたり約4.5ビット、約32レイヤー）の場合：

| Component | Per layer | 32 layers total |
| - | - | - |
| Weights | \~0.19 GB | \~6 GB |
| KV cache (f16, 8K ctx) | \~0.13 GB | \~4 GB |
| **Total** | | **\~10 GB** |

CUDAコンテキストとオーバーヘッドのために1-2 GBのVRAMヘッドルームを残すこと。

> [!WARNING]
>
> コンテキスト長を増加させると、KVキャッシュが成長してレイヤーがVRAMから追い出される可能性がある。32Kコンテキストウィンドウを設定した後にLM Studioが突然レイヤーの半分をCPUにオフロードし始めた場合、KVキャッシュがVRAM予算を消費したことになる。コンテキスト長を減らすか、小さい量子化を使用するか、flash attentionを有効化してKVキャッシュを縮小すること。

## KVキャッシュ精度

KVキャッシュはすべてのアクティブなシーケンスの各トークンのキーテンソルとバリューテンソルを格納する。デフォルトでは、LM Studioは`f16`（16ビット浮動小数点）を使用する。量子化精度に切り替えることで、わずかな品質コストでメモリ使用量を削減できる。

ロードパネルまたはAPIでキャッシュタイプを設定する：

**UI内：**

モデルをロードすると、**Advanced Settings**を展開して**KV Cache Quantization**を探す。以下を設定できる：

* **f16**（デフォルト） — 全精度
* **q8\_0** — 8ビット量子化
* **q4\_0** — 4ビット量子化

**API経由：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "llama_k_cache_quantization_type": "q8_0",
    "llama_v_cache_quantization_type": "q8_0"
  }'
```

| Cache type | Memory per element | Quality | When to use |
| - | - | - | - |
| `f16` (default) | 2 bytes | Baseline | Maximum quality; you have plenty of memory |
| `q8_0` | 1 byte | Near-identical to f16 | Best balance — halves KV cache memory with negligible quality loss |
| `q4_0` | 0.5 bytes | Slight degradation | Tight memory; long context or many concurrent sequences |

> [!TIP]
>
> メモリ節約を最大化するには、`q8_0`KVキャッシュとflash attentionを組み合わせます。フラッシュアテンションはKVキャッシュフットプリントを30-50%削減し、q8\_0がさらに半減します — 組み合わせるとデフォルトと比較してKVキャッシュメモリを60-75%削減できます。

> [!WARNING]
>
> `q4_0`KVキャッシュはロングコンテキストにわたる正確なアテンションに依存するタスク — ニードルインヘイスタック検索、マルチドキュメント要約、長い会話 — で測定可能な品質低下を引き起こす。`q4_0`にコミットする前に、特定のワークロードをテストしてほしい。

## バッチサイズチューニング

次の**Eval Batch Size**パラメータはプリフィルフェーズ（プロンプト読み込み）でLM Studioが一度に処理するトークン数を制御する。デフォルトは512だ。

設定はロードパネルの**Advanced Settings**またはAPI経由で行う：

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "eval_batch_size": 1024
  }'
```

| Setting | Effect |
| - | - |
| `512` (default) | Balanced for interactive chat with short prompts |
| `1024` | Faster prefill for long prompts — roughly 50-100% faster time-to-first-token |
| `2048` | Maximum throughput for document ingestion — up to 150% faster prefill |
| `2048+` | Diminishing returns; higher memory usage without proportional speed gains |

> [!TIP]
>
> 短いプロンプト（1Kトークン未満）のインタラクティブチャットの場合、デフォルトの`512`で問題ない。長いドキュメントを定期的に読み込み、time-to-first-tokenを高速化したい場合にのみ増加させること。

> [!WARNING]
>
> 大きなバッチサイズはプロンプト読み込み中にVRAMをより多く消費する。バッチサイズを増加させてメモリ不足エラーに遭遇した場合は、減らすかコンテキスト長を下げること。

## モデルメモリ管理

### TTLによるモデルのロード状態保持

デフォルトでは、LM Studioは非アクティブ期間後にメモリからモデルをアンロードする。次のリクエストはディスクからモデルを再ロードする必要があり、モデルサイズとディスク速度に応じて数秒から数分かかる。

次の**TTL (Time To Live)** を設定してモデルのロード状態を制御する：

**UI内：**

モデルをロードすると、ロードパネルに**TTL**ドロップダウンが表示される。以下を設定できる：

* **Until you close the app** — モデルは無期限にロードされたままになる。
* **Until you unload it** — 手動でアンロードするまでモデルがロードされたままになる。
* **Custom duration** — 指定時間後にモデルがアンロードされる（例：5分、1時間）。

**API経由：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [{"role": "user", "content": "Hello"}],
    "ttl": -1
  }'
```

**CLI経由：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
lms load llama-3.1-8b-instruct --ttl -1
```

| Value | Behavior |
| - | - |
| Default (5 minutes) | Unload after 5 minutes of inactivity |
| `-1` | Keep loaded indefinitely — no reload penalty |
| `0` | Unload immediately after each request |
| Duration in seconds (`3600`, `86400`) | Keep loaded for that duration after the last request |

> [!TIP]
>
> 終日同じモデルを実行する専用推論サーバーの場合、TTLを**Until you close the app**または`-1`に設定すること。モデルがメモリに保持され、すべてのリクエストがコールドスタートペナルティなしで即座に応答する。

### マルチモデルサービング

LM Studioは複数のモデルを同時にロードできる。追加のモデルをロードすると、LM Studioは十分なメモリがあるか確認する。ない場合、最も最近使用されていないモデルをアンロードして空きを作る。

ロードされたモデルを管理するには：

**UI内：**

次の**Models**パネルにすべてのロード済みモデルが表示される。モデルの横のアンロードボタンをクリックしてメモリを解放する。

**CLI経由：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
# List loaded models
lms status

# Unload a specific model
lms unload llama-3.1-8b-instruct

# Unload all models
lms unload --all
```

**API経由：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
# Unload a specific model
curl -X DELETE http://localhost:1234/v1/models/llama-3.1-8b-instruct
```

## ローカルサーバーの設定

LM StudioはOpenAI互換のAPIサーバーを公開する。デフォルトでは`http://localhost:1234`でリッスンする。

### サーバー設定

**UI内：**

次の**Server**タブに移動し、**Server Settings**をクリックして設定する：

* **Host** — バインドアドレス（デフォルト：`127.0.0.1`）。ローカルネットワークでサービスするには`0.0.0.0`に変更する。
* **Port** — リッスンポート（デフォルト：`1234`）。
* **CORS** — Webクライアントのクロスオリジンリクエストを有効化する。
* **Require API Key** — 認証にベアラートークンを要求する。

**CLI経由：**

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
lms server start --host 0.0.0.0 --port 8080
```

> [!WARNING]
>
> ホストを`0.0.0.0`に設定すると、LM Studioがローカルネットワークに公開される。ネットワーク上のすべてのデバイスを信頼している場合、またはファイアウォールでアクセスを制限する場合にのみ行うこと。インターネット経由のリモートアクセスには[Tokios](/ja/guides/lm-studio-remote-access.md)を使用すること — ポートを開かずに認証されたリモートアクセスを提供する。

### APIエンドポイント

LM Studioは以下のOpenAI互換エンドポイントをサポートする：

| Endpoint | Purpose |
| - | - |
| `/v1/chat/completions` | Chat completions (most common) |
| `/v1/completions` | Text completions (legacy) |
| `/v1/embeddings` | Generate embeddings |
| `/v1/models` | List loaded models |
| `/v1/responses` | Responses API (newer format) |
| `/v1/decisions` | Decision models (classification, routing) |

例：ロード済みモデルの一覧表示

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
curl http://localhost:1234/v1/models
```

例：チャット完了

```bash theme={"theme":{"light":"github-light","dark":"css-variables"}}
curl http://localhost:1234/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama-3.1-8b-instruct",
    "messages": [
      {"role": "user", "content": "Hello!"}
    ]
  }'
```

## サポートされるモデルフォーマット

LM Studioは2つの主要なモデルフォーマットをサポートする：

### GGUF（クロスプラットフォーム）

GGUFは最も広くサポートされているフォーマットだ。Windows、Linux、macOSで動作し、GPUの有無を問わない。GGUFモデルはファイルサイズを削減するために量子化される（例：Q4\_K\_M、Q5\_K\_M、Q8\_0）。

**GGUFを使用する場面：**

* クロスプラットフォームのポータビリティが必要な場合（Windows、Linux、Mac）。
* NVIDIA GPUとApple Siliconの両方で同じモデルを実行したい場合。
* 最も豊富な量子化オプションの選択を優先する場合。

### MLX（Apple Silicon最適化）

MLXはAppleの機械学習フレームワークで、Mシリーズチップに最適化されている。Apple Siliconでは、LM Studioは自動的にMLXを使用して高速な推論を行う。

**MLXを使用する場面：**

* Apple Silicon（M1、M2、M3、M4）を使用している場合。
* Macで最大のパフォーマンスを得たい場合。
* Apple以外のハードウェアで同じモデルを実行する必要がない場合。

> [!TIP]
>
> Apple Siliconでは、LM Studioがハードウェアに最適なランタイム（MLXまたはllama.cpp）を自動的に選択する。手動で設定する必要はない。

## Apple SiliconとMLXの最適化

Apple Silicon搭載Macでは、LM StudioはデフォルトでAppleのMLXフレームワークを使用する。MLXはAppleの統一メモリアーキテクチャに最適化されており、Mシリーズチップでllama.cppよりも大幅に高速な推論を提供する。

### パフォーマンス向上

コミュニティテストからのベンチマーク：

| Model | Quantization | Tokens/sec (MLX) |
| - | - | - |
| Llama 3.1 8B | Q4\_K\_M | \~70-80 tok/s |
| Gemma 4 12B | Q4\_K\_M | \~46 tok/s |
| Qwen 2.5 7B | Q4\_K\_M | \~60-70 tok/s |

MLXはApple Siliconで高度な量子化もサポートし、ほぼBF16品質を4ビットメモリフットプリントで提供する — Q4量子化の半分の品質低下だ。

### Apple Silicon最適化のヒント

1. **MLX最適化モデルを使用する。** Apple Siliconでモデルをダウンロードすると、LM Studioは自動的にMLXバックエンドを使用する。設定は不要。
2. **Flash attentionは常にオン。** MLXはデフォルトで最適化されたアテンションカーネルを使用する。Flash attentionの設定は効果を持たない。
3. **統一メモリによりフルGPUオフロード。** Apple SiliconのGPUは全RAMプールにアクセスできるため、モデルとKVキャッシュが統一メモリに収まる限りフルGPUオフロードが機能する。
4. **Apple Siliconでは`q8_0`KVキャッシュ**を使用してメモリ予算を最大化する。KVキャッシュを半減することで、より大きなモデルやより長いコンテキストを実行できる。
5. **常時稼働の推論にはTTLを「Until you close the app」に設定する。** モデルは統一メモリに保持され、リロードペナルティなし。

> [!NOTE]
>
> クロスプラットフォームのポータビリティが必要か、NVIDIA GPUとMacで同じ設定を実行したい場合は、Apple Siliconでllama.cppバックエンドを使用するようLM Studioを強制できる。バックエンド選択をオーバーライドする設定については、LM Studioサポートに問い合わせるかドキュメントを確認してほしい。

## 設定例

### Mac Studio M2 Ultra — 128 GB統一メモリ

**UI設定：**

* **GPU Offload:** Max
* **Context Length:** 32768
* **Flash Attention:** Enabled (auto on MLX)
* **KV Cache Quantization:** q8\_0
* **TTL:** Until you close the app

この設定は70B Q4モデルを32Kコンテキストウィンドウで実行する。128 GBの統一メモリプールは約40 GBのモデルウェイト、約16 GBのKVキャッシュ（q8\_0）を処理し、複数モデルのヘッドルームを残す。MLXはApple Siliconで最大のスループットを提供する。

### NVIDIA RTX 4090 — 24 GB VRAM

**UI設定：**

* **GPU Offload:** Max
* **Context Length:** 16384
* **Flash Attention:** Enabled
* **KV Cache Quantization:** q8\_0
* **Eval Batch Size:** 1024
* **TTL:** Until you close the app

この設定は8B Q4モデルを16Kコンテキストウィンドウで実行する。24 GBのVRAMは約5 GBのモデルウェイト、約4 GBのKVキャッシュ（q8\_0、flash attention付き）を処理する。大きなバッチサイズがプロンプト読み込みを高速化する。

### マルチGPUサーバー — 2× RTX 4090（合計48 GB VRAM）

**UI設定：**

* **GPU Offload:** Max
* **Context Length:** 32768
* **Flash Attention:** Enabled
* **KV Cache Quantization:** q8\_0
* **Eval Batch Size:** 2048
* **TTL:** Until you close the app

この設定は70B Q4モデルを2つのGPUで実行する。合計48 GBのVRAMは約40 GBのモデルウェイト、約16 GBのKVキャッシュを処理する。大きなバッチサイズがバッチワークロードのスループットを最大化する。

### CPU専用サーバー — 64 GB RAM、GPUなし

**UI設定：**

* **GPU Offload:** Off
* **Context Length:** 8192
* **Flash Attention:** Disabled
* **KV Cache Quantization:** q8\_0
* **Eval Batch Size:** 512
* **TTL:** Until you close the app

この設定は8B Q4モデルを完全にCPU上で実行する。小さいバッチサイズと単一の並列リクエストがメモリ使用量を抑える。5-10 tok/sが期待できる — インタラクティブチャットには使用可能だが、バッチワークロードには不向き。

## よくある間違いと回避方法

### 間違い1：コンテキスト長を高く設定しすぎる

**問題：** 「念のため」コンテキスト長を128Kに設定したが、プロンプトは2Kトークン未満。64 GBのKVキャッシュメモリを無駄にした。

**修正：** 実際のワークロードに合わせてコンテキスト長を設定すること。プロンプトが4Kトークン未満なら、4096または8192を使用する。後でAPIを通じて特定のリクエスト用に増やすことができる。

### 間違い2：flash attentionを忘れる

**問題：** flash attentionが有効になっていないため、必要より30-50%多いVRAMを使用している。

**修正：** 常にflash attentionを有効にすること。サポートされたハードウェアでデメリットはない。

### 間違い3：モデルのアンロードを制御しない

**問題：** 10分の休憩後にリクエストを再開すると、LM Studioがディスクからモデルを再ロードしたため最初のリクエストに30秒かかる。

**修正：** TTLを**Until you close the app**または`-1`に設定して常時稼働の推論を実現すること。モデルがメモリに保持され、すべてのリクエストが即座に応答する。

### 間違い4：KVキャッシュ精度を無視する

**問題：** VRAMが不足しLM StudioがレイヤーをCPUにオフロードしているが、KVキャッシュが必要の2倍のメモリを使用していることを考慮していない。

**修正：** KVキャッシュ量子化を`q8_0`に設定してKVキャッシュメモリを半減すること。品質とメモリ節約の最適なバランスだ。

### 間違い5：収まらないモデルでGPUオフロードを使用する

**問題：** GPUオフロードを**Max**に設定したが、モデルがVRAMに収まらない。LM Studioがメモリ不足になるかクラッシュする。

**修正：** GPUオフロードを**Auto**に設定してLM Studioに決定させること。手動で設定する必要がある場合は、低い値から始めて制限に達するまで増加させる。

## トラブルシューティング

### 起動後にLM Studioが遅い

**原因：** モデルがアンロードされており、ディスクから再ロードする必要があった。

**修正：** TTLを**Until you close the app**または`-1`に設定してモデルを無期限にロード状態に保つこと。

### メモリ不足エラー

**原因：** モデル + KVキャッシュが利用可能なVRAMまたはRAMを超えている。

**修正：** コンテキスト長を減らす、flash attentionを有効化する、KVキャッシュ量子化を`q8_0`に設定する、または小さい量子化を使用すること。

### GPUが使用されていない

**原因：** LM StudioがGPUを検出しなかったか、VRAMが数レイヤーすら収めるには小さすぎる。

**修正：** ロードパネルでレイヤーがGPU上にあるか確認すること。NVIDIA GPUの場合、NVIDIAドライバーとCUDAツールキットがインストールされていることを確認すること。AMD GPUの場合、ROCmがインストールされていることを確認すること。

### 遅いCPU推論

**原因：** レイヤーがGPUとCPUに分割されている、またはGPUオフロードなし。

**修正：** 可能であれば、より多くのレイヤーをGPUにオフロードすること。小さい量子化（Q4\_K\_MまたはQ5\_K\_M）を使用してより多くのレイヤーをGPUに収めること。

### モデルのロードに失敗する

**原因：** モデル + KVキャッシュに十分なメモリがない。

**修正：** コンテキスト長を減らす、GPUオフロードを減らす、または小さい量子化を使用すること。モデルがハードウェアに対して大きすぎる場合は、より小さいモデルをダウンロードすること。

## 次のステップ

> **[LM Studio remote access](/ja/guides/lm-studio-remote-access.md)**
>
> Expose your LM Studio model to teammates and agents through Tokios — without opening ports or serving on the local network.

> **[Hardware reference](/ja/guides/hardware-reference.md)**
>
> Compare hardware platforms for local LLM inference — specs, model capacity, and recommendations.

> **[Model fit finder](/ja/guides/model-fit.md)**
>
> Find which models run on your hardware, or which hardware can run your target model.

> **[Test your deployment](/ja/guides/benchmark-your-deployment.md)**
>
> Measure latency and throughput after tuning to confirm the improvement.

## FAQ

### 最適なGPUオフロード設定は？

ほとんどの場合、**Auto**を使用すること。LM Studioが利用可能なVRAMを検出し、収まる限りのレイヤーをオフロードする。フルモデルがVRAMに収まることを確認している場合のみ**Max**に設定する。CPUのみの推論には**Off**に設定する。

### コンテキストウィンドウを増やすには？

ロードパネルで**Context Length**スライダーを desired値（例：8192、16384、32768）にドラッグする。モデルの設定でモデルごとのデフォルトを設定するか、APIリクエストで`context_length`を渡すこともできる。

### LM Studioはflash attentionをサポートしているか？

はい。ロードパネルまたはモデルごとのデフォルトで有効化する。Flash attentionはKVキャッシュメモリを30-50%削減し、推論を高速化する。MLXを使用するApple Siliconでは、flash attentionは常にオン。

### モデルをロード状態に保つには？

次の**TTL**を**Until you close the app**に設定するか、APIで`-1`を設定する。モデルがメモリに保持され、すべてのリクエストがリロードペナルティなしで即座に応答する。

### 複数のモデルを同時に実行できるか？

はい。LM Studioは複数のモデルを同時にロードできる。メモリが逼迫している場合、最も最近使用されていないモデルをアンロードして空きを作る。`lms status`でロード済みモデルを確認し、`lms unload`でメモリを解放する。

### どのモデルフォーマットを使用すべきか？

クロスプラットフォームの互換性には**GGUF**を使用すること（Windows、Linux、Mac）。Apple Siliconでは、LM Studioがより高速な推論のために自動的に**MLX**を使用する。手動で選択する必要はない。

### LM Studioをローカルネットワークでサーブするには？

Serverタブで**Server Settings**をクリックし、**Host**を`0.0.0.0`に変更する。LM Studioがローカルネットワークに公開される。インターネット経由のリモートアクセスには[Tokios](/ja/guides/lm-studio-remote-access.md)を代わりに使用すること。

### 最適なKVキャッシュ量子化は？

品質とメモリ節約の最適なバランスには**q8\_0**を使用すること。KVキャッシュメモリを半減し、ほぼ品質低下なし。メモリが非常に逼迫しており、ある程度の品質低下を受け入れる場合にのみ**q4\_0**を使用する。

## ソース

* [LM Studio documentation](https://lmstudio.ai/docs) — official documentation on configuration and API
* [LM Studio per-model defaults](https://lmstudio.ai/docs/app/advanced/per-model) — setting persistent configuration per model
* [LM Studio CLI reference](https://lmstudio.ai/docs/cli) — CLI commands for loading, unloading, and server management
* [LM Studio OpenAI compatibility](https://lmstudio.ai/docs/developer/openai-compat) — API endpoints and client integration
* [LM Studio changelog](https://lmstudio.ai/changelog) — release notes and new features
* [GGUF vs MLX on Apple Silicon](https://atomic.chat/blog/guides/gguf-vs-mlx) — performance comparison and format selection
* [LM Studio GPU offload guide](https://houtini.com/articles/how-to-set-up-lm-studio/) — GPU offload and context size configuration

> [!NOTE]
>
> LM Studioの設定を変更した後、Tokiosデプロイメントを再登録してコネクターが新しいアップストリームエンドポイントを取得するようにすること。[Register Model](/ja/setup/register-model.md)を参照。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.