🎯 はじめに:前回までのあらすじ

前々回の記事「RTX 5060 Ti 16GB で "ローカル Claude Code 開発環境" を構築する」では、
Ollama + gpt‑oss:20B で修正作業がループ状態になるという課題がありました。
https://qiita.com/dokoka/items/ed239dff33fc34fb2d43

前回の記事「LM Studio + gpt‑oss:20B で Claude Code が実用的に!」では、
LM Studio に切り替えることで gpt‑oss:20B が実用レベルに達しました。
https://qiita.com/dokoka/items/bb6b9432974d5a8d6387

ただし、コーディング性能自体は qwen3‑coder:30B のほうが上であり、
次なる課題は「qwen3‑coder:30B を 16GB VRAM で実用的に動かせるか」でした。

この記事では、その実験結果を報告します。

結論を先に言うと、qwen3‑coder:30B は Claude Code では実用難しいでした。

1. qwen3‑coder:30B の実験:KV キャッシュも GPU に載せる場合

● 設定

LM Studio で以下のように設定:

モデル: qwen3‑coder:30B
GPU Offload: 100%(モデルとKVキャッシュをすべてGPUに)
コンテキストサイズ: 可能な限り大きく

● 結果:コンテキストサイズ 10k 弱が限界

VRAM 16GB では、qwen3‑coder:30B と KV キャッシュを両方 GPU に載せると、
コンテキストサイズが 10k 弱しか取れませんでした。

● 速度

簡単なチャットでは 90 t/s と高速でした。

● Claude Code での動作

しかし、Claude Code はコンテキストサイズ 10k では全くまともに動作しません。

Claude Code は:

ファイル内容を丸ごとコンテキストに含める
過去の会話履歴を保持する
システムプロンプトも大きい

そのため、10k では数回のやり取りでコンテキストが溢れてしまい、
実用になりませんでした。

2. qwen3‑coder:30B の実験:KV キャッシュを GPU から下ろす場合

● 設定

次に、KV キャッシュを CPU に逃がす設定を試しました:

モデル: qwen3‑coder:30B
GPU Offload: モデルのみ GPU(KV キャッシュは CPU)
コンテキストサイズ: 64k

● 結果:速度が大幅に低下

コンテキストサイズは 64k まで確保できましたが、
速度が 26 t/s まで低下しました。

● Claude Code での動作

コンテキストサイズは十分になりましたが、
26 t/s では遅すぎて実用とは言えません。

Claude Code は反復的にコード生成と修正を繰り返すため、
レスポンスの遅さがストレスになります。

特に、デバッグ指示を何度も出す場面では、
待ち時間が長すぎて開発フローが止まってしまいます。

3. Claude Code の問題:入力トークンが大きすぎる

● なぜ qwen3‑coder:30B は Claude Code に向かないのか

今回の実験で分かったことは、
Claude Code は入力トークンが非常に大きいということです。

Claude Code の特徴:

ファイル全体をコンテキストに含める
複数ファイルを同時に扱う
過去の会話履歴をすべて保持
システムプロンプトが大きい

そのため、コンテキストサイズが小さいと動作せず、
大きくすると KV キャッシュが VRAM を圧迫します。

30B クラスのモデルでは、
VRAM 16GB では Claude Code との相性が悪いという結論です。

4. 代替案:プロンプトが軽い開発ツールを使う

Claude Code が 30B モデルに向かないなら、
もっと軽量なプロンプトで動く開発ツールを使うべきです。

● Qwen Code CLI

Qwen の公式 CLI ツールで、
必要最小限のコンテキストで動作します。

Claude Code ほど高機能ではありませんが、
Claude Codeよりは軽量なプロンプトで動作します。

● CLINE

VS Code 拡張の一つで、
Claude Code よりもプロンプトが軽いです。

同じコーディング支援でも、
ツールの設計によってコンテキスト消費量が大きく異なることが分かります。

5. 今後の方向性:より小型のモデルを試す

30B モデルが VRAM 16GB で Claude Code に向かないなら、
もっと小型のモデルを試すべきです。

● 次回のテスト対象

次回は以下のモデルで実験します:

GLM‑4.6‑Flash (8B)

8B という小型サイズ
KV キャッシュも含めて GPU に余裕で載る
コンテキストサイズを十分確保できる可能性
性能に不安

qwen2.5‑coder:14B

14B という中型サイズ
30B より軽く、20B より賢い可能性
バランスの取れた選択肢
性能に不安

これらのモデルなら、
KV キャッシュも含めて GPU に載せつつ、64k のコンテキストを確保できるかもしれません。

6. 比較表:これまでのテスト結果まとめ

モデル	サイズ	KV on GPU	コンテキスト	速度	Claude Code 実用性
gpt‑oss	20B	○	64k	100 t/s	○ 実用的
qwen3‑coder	30B	○	~10k	90 t/s	× コンテキスト不足
qwen3‑coder	30B	×	64k	26 t/s	× 遅すぎる

30B クラスは VRAM 16GB では、
速度とコンテキストのトレードオフが厳しいという結果です。

7. 結論

qwen3‑coder:30B は VRAM 16GB では Claude Code に向かない
KV キャッシュも GPU に載せると、コンテキストサイズが 10k 弱しか取れない
KV キャッシュを CPU に逃がすと、26 t/s まで低下し実用不可
Claude Code は入力トークンが大きすぎて、30B モデルとの相性が悪い
Qwen Code CLI や CLINE など、プロンプトが軽いツールを使うべき
次回は GLM‑4.6‑Flash (8B)、qwen2.5‑coder:14B を試す

今回の実験で、
VRAM 16GB では 20B クラスが Claude Code の実用上限であることが確定しました。

ただし、これは Claude Code という コンテキスト消費が激しいツールでの話であり、
より軽量なツールなら 30B でも実用できる可能性があります。

また、より小型のモデル(8B〜14B)なら、
Claude Code でも快適に動作するかもしれません。

次回は、小型モデルでの最適解を探します。