 | ローカルのQwenモデルを、コーディング作業のためにCodexの横で動かしてみたのですが、思った以上に役に立っています。Codexの代替になることは決してありません。むしろ、私よりずっと良い「第2の目」みたいなものです。 ワークフローはおおむね次の通りです： * Codexがメインのリポジトリ作業を行います。 * ローカルのQwenが計画に異議を唱えます。 * Qwenは、過剰な作り込み、見落とした重要な指示、UI/デザイン上の問題、悪い前提、長文コンテキストの見落としをチェックします。 * 私は、次の段階に進む前に、各やり取りを見直し、テストして検証します。これは「大量のプロンプトを投げて、考えることと祈りに任せる」アプローチではありません。ちゃんと動いてスケールする必要があります。 このセットアップが十分に役に立ったので、この役割のためにローカルモデルのプロファイルを、合成データに頼るだけではなく、もう少し具体的にテストする方法が欲しくなりました。 そこで、そのユースケースをもとに、小さな再現可能な評価（eval）スイートを作りました。ベンチや投稿を読むだけでは疲れてしまい、それが自分のユースケースと噛み合っていなかったからです。 私は llama.cpp 経由で、いくつかの Qwen3.6 27B の GGUF プロファイルをテストしました。Bartowski と Unsloth のバリアント、異なるコンテキストサイズ、そして q8/f16 の KV キャッシュを含めています。 ローカル実行からの主な発見： * 最良の 128k プロファイルはスイート内で同率でした：bartowski-128k-f16、bartowski-128k-q8、そして unsloth-128k-q8。 * この特定のスイートにおいては、q8 KV で計測できる精度低下は見られませんでした。とはいえ、あなたのユースケースでも同じことが成り立つとは限りません。 * このワークフローでは、f16-vs-q8 の KV よりもコンテキストサイズの方が重要でした。opencode 経由での直接利用であっても、それは変わりませんでした。 * 65k プロファイルは問題ありませんでしたが、スイートが 65k を超えるコンテキストを要求すると、かなり厳しく失敗しました。 * unsloth-128k-f16 は読み込めましたが、長コンテキストのケースでローカルのメモリ/スループットの圧がかかり、サイズが大きいせいで 5090 が引っかかります。 これはユニバーサルなベンチマークでもなく、既存の何かを置き換えようとしているものでもありません。これは私のワークフロー、私のローカル環境、そしてある仕様のスイートです。「ベストな Qwen の量子化」を主張するつもりも、そういう類のことは言いません。私が提供したいのは、別種の eval です。つまり、ローカルモデルが、（私のケースでは）フロンティアのコーディングエージェントや codex の横で実作業に役立つかどうか。私の使い方では、間違いなく役立ちます。Qwenは、Codex のサイレントな回避を防ぎ、問題を滑らかにして、完了に向けて競争し、障害物を回避するためのハードコーディングを行うのが非常に得意です。Qwenがそれを抑えます。さらに Qwenは UI に関してははるかに優れています。なので UI が関わると役割が逆転し、Qwenがデザイン面で先導します。私は見直して、Codexが実装します。 プロジェクトページ： https://robert896r1.github.io/qwen-realworld-accuracy-evals/ リポジトリ： https://github.com/robert896r1/qwen-realworld-accuracy-evals フィードバックをいただけると嬉しいです。特に、すでにローカルモデルをコーディングの相棒やレビュー担当、サイドカーのエージェントとして使っている人たちからの意見が欲しいです。 また、追加すべきだと思う実世界のテストケースがあれば知りたいです。私はプロンプトベンチングよりも、役に立つ失敗（見落とした指示、悪いチャレンジ行動、過剰な作り込み、UIの判断ミス、長コンテキストの見落としなど）により関心があります。 [link] [comments] |
ローカルのQwenをCodexのバリデータ／コエージェント／チェレンジャーとしてベンチする
Reddit r/LocalLLaMA / 2026/5/5
💬 オピニオンDeveloper Stack & InfrastructureTools & Practical UsageModels & Research
要点
- 著者はローカルのQwenをCodex（OpenAI）と並行して動かし、Qwenを「2つ目の目」として計画を突き返し、過剰な作り込みや指示の見落とし、UI／設計上の問題、誤った前提、長文コンテキストの取りこぼしを検査する。
- ワークフローは反復的で検証中心であり、Codexがリポジトリ作業の主導を行い、Qwenがレビューし、各やり取りは次の段階に進む前にテストと検証で確認する。
- 汎用ベンチマークではなく、この「Codexバリデータ／コエージェント／チェレンジャー」用途に合わせた小さく再現可能な評価スイートを自作した。
- llama.cppでQwen3.6 27Bの複数GGUFプロファイル（量子化とコンテキスト長）をテストした結果、このスイートで上位となったのは128kプロファイルの一部（bartowski-128k-f16、bartowski-128k-q8、unsloth-128k-q8）で同率だった。
- この構成ではKVキャッシュq8でも測定上の精度低下は見られず、f16-vs-q8よりもコンテキスト長の影響が大きい一方で、65kプロファイルは65k超の要求で大きく失速し、unsloth 128k f16は長文ケースでメモリ／スループットの制約にぶつかった。
