🎯 はじめに:前回記事の課題
前回の記事「RTX 5060 Ti 16GB で "ローカル Claude Code 開発環境" を構築する」では、
Ollama + gpt‑oss:20B で新規コード生成はできるが、修正作業でループ状態になる
という限界にぶつかりました。
Claude Code の反復的なデバッグ作業に対応できず、
実用には程遠い結果でした。
原因は不明でしたが、後に Ollama が KV キャッシュを量子化しているという情報を得て、
量子化による精度低下が反復作業に悪影響を与えた可能性があると考えました。
そこで、LM Studio v0.4.1 が Anthropic API に対応したことに気づき、
試したところ、同じ gpt‑oss:20B で修正作業まで完走できました。
この記事では、なぜ LM Studio で成功したのかを検証します。
1. LM Studio v0.4.1 の Anthropic API 対応
LM Studio v0.4.1 から、
Anthropic API 互換のエンドポイントが追加されました。
これにより、Claude Code が
Ollama だけでなく LM Studio のローカルモデルも利用可能になりました。
● LM Studio の優位性
Ollama と比較して、以下の点で優れています:
- GUI で細かいパラメータ調整が可能
- コンテキストサイズを自由に設定できる(Ollama は Modelfile 編集+再ビルドが必要)
- GPU オフロード量を手動で最適化できる
- 推論速度のリアルタイムモニタリング
- 設定変更が即座に反映され、試行錯誤が容易
特に、コンテキストサイズの最適化が GUI から簡単にできる点が決定的な違いを生みました。
2. LM Studio のセットアップ
■ LM Studio のインストール
公式サイトから最新版(v0.4.1 以降)をダウンロードしてインストール。
■ モデルのダウンロード
LM Studio の GUI から gpt-oss:20B をダウンロード。
Ollama で使っていたモデルをそのまま使うことも可能ですが、
LM Studio の管理下に置いたほうが設定が楽です。
■ サーバーの起動
LM Studio の「Server」タブで:
- モデルを選択:
gpt-oss:20B - コンテキストサイズを 64k に設定
- GPU Offload を 100% に設定(すべてのレイヤーを GPU に乗せる)
- API エンドポイントを
0.0.0.0:1234に設定(LAN 公開する場合) - 「Start Server」をクリック
3. Claude Code を LM Studio に向ける
WSL のターミナルで環境変数を設定:
export ANTHROPIC_API_KEY="lmstudio"
export ANTHROPIC_BASE_URL="http://<LM StudioサーバーIP>:1234/v1"
※ LM Studio のデフォルトポートは 1234
※ API キーはダミーでよい
Claude Code を起動:
claude --model gpt-oss:20B
4. コンテキストサイズと GPU メモリの最適化が鍵
今回の成功の最大の要因は、
コンテキストサイズを 64k に絞り、すべて GPU に乗せたことです。
● Ollama との違い
| 項目 | Ollama | LM Studio |
|---|---|---|
| コンテキストサイズ | モデルに固定(変更にはModelfile編集+再ビルド) | GUI から自由に変更 |
| KV キャッシュ | 量子化あり(精度低下の可能性) | フル精度で保持 |
| GPU オフロード | 自動 | 手動で 100% 設定可能 |
| パラメータ調整 | Modelfile編集が必要 | GUI で即座に調整 |
| メモリ管理 | ブラックボックス | 透明性が高い |
| 試行錯誤 | 面倒(再ビルド必要) | 容易(即座に反映) |
Ollama は コンテキストサイズが pullしたモデルに固定されており、
変更するには Modelfile を作成して ollama create で再ビルドする必要があります。
また、KV キャッシュを量子化しているという報告があり、
これが反復的な修正作業でのループ状態の原因かもしれません。
一方、LM Studio は GUI から即座に変更でき、試行錯誤が容易で、
KV キャッシュをフル精度で保持しているため、
Claude Code のような反復的な会話に適しています。
今回のように 64k に絞るという最適化を繰り返し試すには、
LM Studio の柔軟性が圧倒的に有利でした。
5. 実測:テトリス作成とデバッグの繰り返し
● プロンプト例
HTML + CSS + JavaScript の単一ファイルで動作するテトリスを実装してください。
外部ライブラリは使わず、1 ファイルで完結させてください。
LM Studio + gpt‑oss:20B で生成し、
以下のようなデバッグ指示を繰り返しました:
- 「ブロックのが落ちません」
- 「コンソールにこんなエラーが出てます・・・」
- 「もう一回全体見直してデバックしてください」
すべての修正依頼に対応し、完成まで持っていくことができました。
Ollama ではループ状態になっていた修正作業が、
LM Studio では 実用的な速度で完走しました。
6. 速度比較:Ollama vs LM Studio
● 簡単なチャットでの速度
| 環境 | 速度 | 状態 |
|---|---|---|
| Ollama | 20-45 t/s | CPU オフロード発生 |
| LM Studio (64k) | -100 t/s | すべて GPU |
LM Studio で 100 tokens/sec まで高速化しました。
これは、コンテキストサイズを絞り、
すべてのモデルが VRAM に収まったためです。
● Claude Code での実用速度
テトリスの生成とデバッグを繰り返す作業で:
- Ollama: 修正依頼でループ状態、実質使えない
- LM Studio: デバッグ指示を何度か繰り返して完成、実用的
単純な速度だけでなく、
Claude Code との相性が劇的に改善しました。
7. なぜ LM Studio で成功したのか
● 理由1:コンテキストサイズの最適化
Ollama は ollama pull で取得したモデルに
コンテキストサイズが固定で埋め込まれています。
これを変更するには:
- Modelfile を作成
-
num_ctxパラメータを指定 -
ollama createでカスタムモデルを再ビルド
という ひと手間が必要です。
一方、LM Studio は GUI から自由にコンテキストサイズを変更でき、
モデルを再ビルドする必要がありません。
64k に絞ったことで、VRAM 16GB に余裕ができ、
反復的な会話でもメモリを圧迫しなくなりました。
● 理由2:KV キャッシュの量子化の有無
Ollama は KV キャッシュを量子化しているという報告があります。
KV キャッシュの量子化は VRAM 節約には有効ですが、
反復的な修正作業では過去のコンテキストの精度が重要になります。
量子化による精度低下が、
Claude Code のループ状態を引き起こした可能性があります。
LM Studio では KV キャッシュを量子化をGUIで指定できオフにすることで、
フル精度でコンテキストを保持しているため、
修正作業が正常に動作したと考えられます。
● 理由3:完全な GPU オフロード
LM Studio の GUI で GPU Offload を 100% に設定できるため、
CPU に逃げることなく、すべて GPU で処理できました。
Ollama は自動調整ですが、
手動で最適化できる LM Studio のほうが確実でした。
● 理由4:推論パラメータの細かい調整
LM Studio では、Temperature、Top-p、Repeat Penalty などを
GUI で簡単に調整できます。
Ollama でもこれらのパラメータは変更できますが、
Modelfile を編集する必要があり、試行錯誤がしにくいです。
Claude Code のようなエージェント型 UI では、
適切なパラメータ設定が重要であり、
GUI で即座に調整できる LM Studio の利便性が決定的でした。
8. 結論
- LM Studio v0.4.1 の Anthropic API 対応により、Claude Code が実用的に
- コンテキストサイズを 64k に絞り、すべて GPU に乗せることが成功の鍵
- Ollama の KV キャッシュ量子化が修正作業のループ状態を引き起こした可能性
- LM Studio はフル精度で KV キャッシュを保持し、反復作業に適している
- Ollama はコンテキストサイズ変更に Modelfile 編集+再ビルドが必要だが、LM Studio は GUI から即座に変更可能
- gpt‑oss:20B で新規作成だけでなく、修正作業も完走できた
- 100 t/s の高速化により、実用的な開発体験を実現
- VRAM16Gでは Ollama から LM Studio への切り替えを強く推奨
- ただしコーディング性能は qwen3‑coder:30B のほうが上 - 今後の最適化に期待
前回記事では「Ollama では修正作業が不可能」という結論でしたが、
LM Studio を使うことで、同じモデルが実用レベルに達しました。
ローカル LLM の運用では、
モデルの性能だけでなく、ランタイムの選択とチューニングが重要だと再認識しました。
特に、KV キャッシュの扱い方が反復的な会話では決定的な差を生むことが分かりました。
また、GUI から簡単にパラメータを調整できる LM Studio の利便性は、
試行錯誤が多いローカル LLM 環境構築において圧倒的なアドバンテージです。
RTX 5060 Ti 16GB という現実的な構成でも、
適切な設定により Claude Code が十分実用的になります。
今後は、より高性能な qwen3‑coder:30B を 16GB VRAM で動かす最適化に挑戦し、
さらに快適なローカル開発環境を目指します。
補足1:gpt‑oss:20B と qwen3‑coder:30B の性能差
今回 gpt‑oss:20B で実用的な環境を構築できましたが、
コーディング性能自体は qwen3‑coder:30B のほうが上です。
● qwen3‑coder:30B の優位性
qwen3‑coder:30B は:
- デバッグなしで動作するコードを生成する確率が高い
- 特にテトリスのような複雑なロジックでも一発で動くことが多い
- コード品質が全体的に高い
つまり、修正作業の回数自体を減らせるという利点があります。
● 今後の課題:qwen3‑coder:30B を 16GB VRAM に最適化
qwen3‑coder:30B を VRAM 16GB で動かすには、
量子化パラメータやコンテキストサイズの調整が必要です。
LM Studio の柔軟な設定を活かせば、
30B モデルでも実用的に動く可能性があります。
次回、qwen3‑coder:30B の最適化実験を行い、結果を報告します。
補足2:前回記事との関連
前回記事:
「RTX 5060 Ti 16GB で "ローカル Claude Code 開発環境" を構築する 〜 Ollama + Claude Code + LAN 構成で推奨モデルを動かす 〜」
では、Ollama での限界を報告しましたが、
本記事はその 解決編として位置づけられます。
Ollama での失敗があったからこそ、
LM Studio での成功がより際立ちました。