いろいろとハマりどころがあったのでメモ。
2026/7 時点での情報なので、今後3か月もすれば陳腐化すると思われる
想定ユースケース
- Hermes Agent(Claude Codeもどき)を使い、リポジトリの編集を担当させる
- VSCodeの拡張機能からエージェントとして使う
すぐ回答が欲しいものはクラウドモデルを使い、軽作業やバックグラウンドタスクはローカルに任せる役割分担です。
「リアルタイム性を求めない」というところが格安編成にする上での割り切りポイントです。
マシン選定
私はRyzen AI HX 370搭載の64GBマシンを選びました。
iGPUがそれなりに強力なマシンなら何でもいいです。(Radeon 890M / Arc 140Vとか)
モデルは30B MoE Q4、コンテキストは100kを最低要件としますので、KVキャッシュあわせて27GBほど必要です。
OSをLinuxにしてサーバ専用にするなら、32GBマシンでも何とかなるかもしれません。
dGPUを選ばない理由
そもそもdGPUにして何が得られるか?というところを考えて比較した結果、dGPUは不要と判断しました。
最低限のdGPU構成でもiGPUの4倍速くらい出ますが、3万トークンのプリフィルに30秒かかります。
30秒かかるのであれば私は別の作業を表で開始しますので、それはiGPUで2分待つのと体験的には大差ないと感じます。
また、以下のとおりコストも大きく異なります。
※ランニングコストを 25円/kWh、1か月連続動作で試算
- dGPU:中古デスクトップ8万円 + dGPU 13万円(RX 9060 XT 16GB ×2)=21万円 + 9000 円/月
- iGPU:本体12万円(32GB) + 増設メモリ4万円 = 16万円 + 900 円/月
ローカルLLMサーバのセットアップ
OS
なるべくiGPU側にメモリを回したいので、OSはUbuntuとします。
メインメモリ16GB / iGPU 48GB の設定にします。
LM Studioの導入
LM Studioを導入します。
Ollamaとか色々ありますが、個人的にはGUIで色々と設定できるLM Studioが一番使いやすいです。
最近できたLM Linkという機能を使うと、外出先から自宅サーバのLLMにリクエストを投げることも可能です。
OpenAI互換サーバとしての公開設定
Developer - Local Server 画面で、サーバをRunning、ローカルネットワークで提供をオンにしておきます。
家庭内LANを想定していますが、必要ならセキュリティをかけてください。

JITロードもONにすると、リクエストに応じて自動でモデルをロードするようになります。
モデルの導入
unsloth/Qwen3.6-35B-A3B-MTP-GGUF を使います。
27Bモデルは遅すぎるので使えません。
量子化は最低でもQ4、可能ならQ6あたりを使うとよいです。
※12Bや9Bモデルで「〇〇を超えた!」と騒がれているモデルは、エージェントとして使うには少々厳しいです。
モデルのパラメータ設定
一番重要なポイントです。ここを間違えると無限ループします。
大容量モデルなら多少設定を間違えても無限ループしないのですが、30B MoEはかなり気を使います。
パラメータは Unsloth の公式ガイド に従いましょう。
| パラメータ | 設定内容 |
|---|---|
| バックエンド | vulkan |
| コンテキスト長(※1) | 100k |
| GPUオフロード | 最大(デフォルト) |
| KVキャッシュのGPUオフロード | オン(デフォルト) |
| number of layers for... | 0(32GBマシンの場合は適量まで上げる) |
| Max Concurrent Predictions | 1~2 |
| K/Vキャッシュ量子化 | Q8 |
| Temperature | 0.6 |
| Top K | 20 |
| 繰り返しペナルティ | 1.0 |
| 存在ペナルティ | 無効 |
| Top P | 0.95 |
| Min P | 無効 |
| Enable Thinking(※2) | 無効 |
(※1)コンテキスト長を100k、クライアントでの上限を70k程度に設定して使います。
それ以上のコンテキスト長にも設定できますが、動作が重くなり無限ループの危険性も高まります。
(※2)Qwen3.6の場合、Thinking中にtool_callしてVSCode側がパースできずに落ちてしまう問題があります。
Thinkingオンにする場合でも、以下のようなシステムプロンプトをLM Studioで設定して注意を促しましょう。
モデル自体の改善が根本解決ですが、現状ではこうするしかありません。
システムプロンプト例:
For complex or multi-step tasks, proceed one coherent part at a time. After completing each part, briefly summarize the result before moving on to the next part when doing so improves clarity. Keep responses concise and focused. Include only the assumptions, conditions, evidence, and reasoning necessary to support the answer. Keep thinking, internal reasoning, and <think>...</think> content as concise as possible. Use only the minimum reasoning necessary to choose the next action and solve the task. Do not output any tool invocation inside thinking, internal reasoning, or <think>...</think> blocks. This includes tool_call, function_call, parseable tool-call JSON, XML-style tool-call tags, tool arguments, or any other structure that the runtime could interpret as a tool invocation. If a tool call is required, complete the thinking phase first, and then emit the call only in the formal tool_call format defined by the runtime environment. If no tool call is required, do not emit any tool_call-like structure.
プロンプトテンプレートは、froggeric/Qwen-Fixed-Chat-Templatesに更新します。
こうすることで、GUI上でThinkingのON/OFFを切り替えられるようになります。
クライアント側の設定
以前はOpenCodeを使っていたのですが、動きが悪いので Hermes Agent に乗り換えました。
こちらはかなりClaudeっぽい動きをします。
Hermes Agent Desktop
公式ページを参考にHermes Agentを導入します。
設定画面の「プロバイダー」ー「API キー」ー「LM Studio」に、サーバのURLを入力すれば、自動でモデルが認識されます。
VSCode
Copilot 拡張機能(今はVSCode内蔵)が独自モデル設定に対応したので、chatLanguageModels.json を以下のように設定します。
[ { "name": "LocalLLM Server", "vendor": "customendpoint", "apiType": "chat-completions", "models": [ { "id": "qwen3.6-35b-a3b-mtp", // 導入したモデル名を LM Studio からコピー "name": "qwen3.6-35b", "url": "http://xxx.xxx.xxx.xxx:1234/v1", // サーバのアドレスとポートをコピー "toolCalling": true, "thinking": false, // サーバ側の thinking 設定に合わせる "vision": true, // モデルの画像入力有無に合わせる "maxInputTokens": 70000, // 100k に対し余裕をみておく "maxOutputTokens": 8192 } ] } ]
このようにエージェントとして使えます。
