はじめに
ローカル実行のコーディング特化モデルとして qwen3-coder-next を opencode から使おうとしたところ、モデルが「同じ文言を延々と繰り返す」「存在しないツールを呼び出そうとする」などの症状で全く使い物になりませんでした。
結論から言うと、原因は複数（opencode の設定不足＋モデルの既知の癖＋Ollama のサンプラー設定）が重なったもので、環境（AMD GPU / RDNA4）の問題ではありませんでした。 Modelfile でサンプリングパラメータを調整した専用モデルを作ることで解決し、それ以降は安定して動作しています。同じ症状に遭遇した人向けに、原因の切り分け方と解決手順をまとめます。
環境
| 項目 | 値 |
|---|---|
| OS | Windows 11 |
| エージェントツール | opencode 1.18.x |
| LLMランタイム | Ollama 0.34.2 |
| CPU | AMD Ryzen系 |
| GPU | AMD Radeon RX 9070 XT 16GB（gfx1201 = RDNA4） |
| システムRAM | 64GB（実測 63.6GiB / 空き 44〜47GiB） |
| モデル |
qwen3-coder-next:latest（80B級 MoE・51GB・Q4_K_M） |
症状
opencode で ollama/qwen3-coder-next を選んで使用したときに、以下の不具合が発生。
- 同じ文章を繰り返す（生成がループして進行しない / 同一出力が継続）
-
存在しないツールを呼び出そうとする（
exploreのような実在しない tool 名を出力） -
存在しないファイルパスを参照する（
C:\Users\Owner\...という幻覚パスを指定） - モデル名を聞くと 不正確な自称 を返す（実際と違うモデル名を名乗る）
- opencode の
/modelsに Ollama のモデルが 一切表示されない
原因は1つじゃなかった
調査の結果、問題は複数重なって起きていました。
原因1：opencode が Ollama を認識していなかった（設定不足）
opencode は Ollama を自動で検出しません。 provider セクションへの明示登録が必須です。
-
opencode models ollama→Error: Provider not found: ollama - 設定ファイルがほぼ空（
$schemaのみ）だと、デフォルトのクラウドモデルにフォールバック していました。つまり「qwen3-coder-next を使っているつもりが、別モデルが動いていた」状態。 - さらに
/modelsに表示されるのはprovider.ollama.modelsに登録したモデルだけ という仕様。
原因2：qwen3-coder-next 自体の「ループ問題」（既知の不具合）
qwen3-coder-next は 繰り返し（looping）を起こしやすいモデルであることが既知 です。Alibaba 側も フォーラム/GitHub で「known issue of the qwen3-coder-next model」として認知しており、Reddit や各所で対策情報が共有されています。特に エージェント（ツール呼び出し）用途で顕著 になる傾向があります。
原因3：Ollama のデフォルトサンプラーが「ループ抑制ゼロ」
Ollama のサーバーログ（server.log）を確認すると、qwen3-coder-next の実行時に使われていたサンプラー設定は デフォルトのままでペナルティ類が全て無効 でした。
repeat_last_n = 64, repeat_penalty = 1.000, frequency_penalty = 0.000, presence_penalty = 0.000
dry_multiplier = 0.000 ...
top_k = 40, top_p = 1.000, min_p = 0.000, temp = 1.000
つまり、モデルが持つループ傾向を抑制する仕組みが一切効いていない状態。コミュニティで報告されている対策（presence_penalty や frequency_penalty の調整など）を入れる余地が大幅に残っていました。
原因4：num_ctx が 4096 のまま（コンテキスト不足）
Ollama の VRAM 基準デフォルトにより、実効コンテキストが 4096 に固定 されていました。モデルは 262,144 トークン対応ですが、ツール定義・システムプロンプト・会話履歴が並ぶエージェント用途では 4096 では明らかに不足し、不安定挙動の一因になります。
msg="vram-based default context" total_vram="15.9 GiB" default_num_ctx=4096
（参考）RDNA4 非対応説は誤診だった
当初は「RX 9070 XT は Ollama の ROCm 非対応で CPU フォールバックしているのでは？」と疑いました。確かに 古い Ollama（ROCm 6.4.2 同梱版）では gfx1201 が未対応で CPU 実行に落ちる という事例は実在します。
しかし、Ollama 0.34.2 は ROCm 7.1（rocm_v7_1）を同梱しており、RX 9070 XT を正しく認識・使用していました。
-
server.log:library=ROCm compute=gfx1201 name=ROCm0 ... AMD Radeon RX 9070 XT - ロードログ:
offloaded 49/49 layers to GPU（GPU 14.3GiB + システムメモリ mmap 36GiB）
つまり「GPU が使えていない」のが失敗原因ではなく、モデル側の挙動（原因2〜4）と opencode の設定（原因1） が主因でした。
解決手順
1. Modelfile を作成してループ対策モデルを生成
サンプラーにループ抑制パラメータを入れ、num_ctx を拡大した派生モデルを作ります。
# Modelfile（ファイル名は任意）
FROM qwen3-coder-next:latest
PARAMETER temperature 0.8
PARAMETER top_p 0.95
PARAMETER min_p 0.01
PARAMETER top_k 40
PARAMETER presence_penalty 1.10
PARAMETER frequency_penalty 0.5
PARAMETER num_ctx 16384
ollama create qwen3-coder-next-lf -f Modelfile
反映確認:
ollama show qwen3-coder-next-lf --parameters
# min_p 0.01 / num_ctx 16384 / presence_penalty 1.1 / temperature 0.8 / top_k 40 / top_p 0.95 / frequency_penalty 0.5
⚠️ 注意: Reddit の「Loop Fix」スレッドでは
dry_multiplier=0.5/dry_allowed_length=5も推奨されていますが、Modelfile のPARAMETERでは受け付けられずError: unknown parameterになります（Ollama 0.34.2 で確認）。現状は Modelfile に書かないこと。
2. opencode の設定に Ollama プロバイダとモデルを登録
~/.config/opencode/opencode.jsonc（Windows では C:\Users\<ユーザー名>\.config\opencode\opencode.jsonc）:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama",
"options": {
"baseURL": "http://localhost:11434/v1"
},
"models": {
"qwen3-coder-next-lf": {
"name": "qwen3-coder-next-lf",
"limit": {
"context": 16384,
"output": 16384
}
}
}
}
},
"model": "ollama/qwen3-coder-next-lf"
}
ポイント:
-
npm: "@ai-sdk/openai-compatible"を使い、baseURLに Ollama の OpenAI 互換エンドポイントhttp://localhost:11434/v1を指定。 - モデル単位の
limit.context/limit.outputを設定。 -
opencode を再起動 し、
/modelsでollama/qwen3-coder-next-lfを選択。
3. 効果
-
1+1=?程度の単純応答はもちろん、ツール呼び出し（ファイル操作などの agent 動作）でも安定 - ループ・幻覚パス・誤ツール名の発生が実用上なし（未解決の残るモデル固有の癖は、さらに大きなモデルへ代替する選択肢もある）
他のモデルとの比較
ローカルでコーディング用途を検討している方向けに、検討候補をまとめました。
| モデル | 総パラメータ | 活性パラメータ | サイズ概算 | ネイティブコンテキスト | 必要メモリ目安 | ツール呼び出し |
|---|---|---|---|---|---|---|
qwen3-coder-next |
79.7B（MoE 512×10） | ~3B | 51GB（Q4_K_M） | 262,144 | RAM 64GB 相当 | ◯（ループ癖あり） |
qwen3-coder:30b |
30.5B（MoE 128×8） | 3.3B | ~19GB（Q4_K_M） | 262,144 | 20GB 以上 | ◯ |
gpt-oss:20b |
21B（MoE） | 3.6B | ~13GB（MXFP4） | 128,000 | 16GB 以上 | ◯ |
qwen3:8b |
8.2B（Dense） | 8.2B | ~5.2GB | 32,768（YaRN で 131,072） | 8GB 以上 | ◯ |
選定の目安
-
最高性能を目指す:
qwen3-coder-next。ただし今回の対策（サンプリング設定）が前提。16GB VRAM ではシステムメモリへの mmap 混載となり速度は ~10〜14 tok/s 程度。RAM 不足に注意。 -
性能・リソースのバランス:
qwen3-coder:30b。30B 級 MoE でコーディング特化。16GB VRAM ならほぼ GPU 完結で体感速度も良い。コンテキスト 262k に設定する場合は OOM 対策（例: 32,768 などに短縮）を検討。 -
軽量・低リソース:
gpt-oss:20bやqwen3:8b。RAM/VRAM が少ない環境向け。軽いモデルほどサンプラー依存の不安定性は出にくい傾向。
導入時の注意点まとめ
-
opencode に Ollama モデルを出すには provider 登録が必須。
Provider not foundならまず設定を疑う。 - モデルのループは品質問題ではなく「挙動」。まず既知問題でないか、そのモデル固有のサンプラー推奨を確認する。
-
Ollama の実効
num_ctxはデフォルト 4096（VRAM 基準）。クライアント側でlimit.contextを上げても、Ollama 側（Modelfile のPARAMETER num_ctxまたは環境変数）も上げないと意味がない。 -
Modelfile で設定できるサンプラーは限られる（
dry_*系などは PARAMETER 非対応）。ollama show <model> --parametersで反映を必ず確認する。 -
AMD RDNA4 でも Ollama が新しければ GPU で動く。古い情報（ROCm 6.4.2 時代）を鵜呑みにせず、
server.logでlibrary=ROCm/gfx1201を確認しよう。 - 巨大 MoE モデルは現実的な速度を確認すべき。GPU + RAM の mmap 混載だと遅い。期待値と相談してモデルサイズを選ぶ。
参考リンク
- Reddit r/LocalLLaMA "Qwen3 Coder Next: Loop Fix"(ループ対策のサンプリング設定の出典)
- ollama/ollama issue（qwen3-coder の無限出力に関する報告）
- GitHub xnyzer/ollama-rocm（RDNA4 × Ollama の GPU アクセラレーション情報。今回は適用不要だったが検証に有用）
- Ollama Modelfile 公式ドキュメント（PARAMETER の対応範囲を確認）
おわりに
「インストールしたのに使えない」とき、原因はハードウェアの相性と決めつけがちですが、実は設定とモデル挙動の組み合わせ であるケースが多いです。今回は Ollama のログ（server.log）を確認したことで、GPU が正常に動いていることとサンプラー設定の問題を特定できました。
同じ症状で詰まっている人の参考になれば幸いです。