こちらは
https://www.reddit.com/r/LocalLLaMA/comments/1sf8zp8/qwen_3_coder_30b_is_quite_impressive_for_coding/ へのフォローアップです。
私の見た範囲のコメントからすると、私がレビューしたQwen 3.5（およびGemma 4）は、一般公開のために発表されたモデルの中でも最高クラスに位置づけられているようです。
HFにある元のモデルはこちらです：
https://huggingface.co/collections/Qwen/qwen35
unslothがさまざまな量子化（quant）を提供しています
https://huggingface.co/collections/unsloth/qwen35
私が試したモデルの中では、私の環境（普通のHaswell i7 CPU、メモリ32GB）では、すべてQ4_K_Mの量子化です。
unsloth/Qwen3.5-27B-GGUF 0.95 tokens / s
unsloth/Qwen3.5-35B-A3B-GGUF 4 tokens / s
https://huggingface.co/barozp/Qwen-3.5-28B-A3B-REAP-GGUF
barozp/Qwen-3.5-28B-A3B-REAP-GGUF 7.5 tokens / s
tokens / s はコンテキストが大きくなるほど低下します。たとえば、同じコンテキスト／スレッド内でプロンプトを追記していくときです。7.5から徐々に1 tok/sまで落ちることもありました。
私が使ったのは Qwen-3.5-28B-A3B-REAP-GGUF です。これは、私の環境でほぼ必要十分なスループット（7.5 t/s）を出せる「小さめ」のサイズだからです。
---
率直な印象としては、Qwen 3.5は関連する懸念点／参照に触れることが多く、llama.cppでは実際の応答に切り替える前に、かなり詳しい「思考」／計画ステップを挟みます。
関連する話題への言及があることで、良いドキュメント作成役になります。実際に私は、これにシェルスクリプトのコードを解析させ、使用方法のドキュメントを作らせました。かなりうまく、整った .md 形式で仕上げてくれます。
コード提案も良好（場合によってはまあまあ）ですが、私がいつもLLMにやらせたいと思っている、特に面白い「難しい」こととしては、おそらく、これらの小規模LLMに *コードをリファクタリング* させることです。
私はこれに、シェルスクリプトをリファクタリングさせ、いくつかのバグを直し、データの構造変更（たとえばデータのJSON形式）にも適応させました。これは、このような「小さめ」のLLMにとってはかなり複雑なタスクだと思います。確かに「思考」フェーズでいくつかの > 10kトークンを使いますが、最終的にはリファクタリングされたコードで戻ってきます。このLLMは、依存関係／課題を考慮しながら（同じ）論点に繰り返し当たっていくような「慎重さ」があるのだと思います。たとえば「wait ... `」のような部分を巡ってです。出来上がったコードは「最高のリファクタリング」ではないと思いますが、私のプロンプトの要件にできるだけ忠実に従おうとしていたのだろうと推測しています。
その中には再帰的な提案もあります。つまり、まずデータのJSON構造をリファクタリングし、その次に、リファクタリングされた新しいデータ構造を扱うためにシェルスクリプトをリファクタリングします。JSONデータ構造のリファクタリングはできていますが、新しい構造に対応するようにシェルスクリプトの更新が抜けています。新しいデータ構造と、それに対応するスクリプトについて、2回目の実行を行うと検討対象になります。
また、プロンプトが「曖昧すぎる」と、「思考」フェーズでその曖昧さを解消しようとしてループに入ることがあります。実際に「思考」フェーズでそういう挙動が見られました。私は、推論（inference）を止めて、プロンプトをより具体的に組み直す必要があることが多く、その調整が解決に繋がります。
[link] [comments]
