やあみんな！
最近、ハードなタスクにおいて Qwen-3.6-27B を下位層のクラウドモデルと比べた私の体験について、ロシア語で文章を書きました。その投稿の翻訳を共有したいと思いました。結果が面白く、しかも驚きだったからです。ルール3を破るかもしれません。というのも、LLMが書いたコードの評価だからですが、まあいいです。私の手法は手作りで、結果もまだ非自明です。翻訳ごめんなさい、英語はそんなに得意じゃありません。
__
以前、3090 と AliExpress から買った Xeon のサーバーがあって、ローカルでモデルを動かしていました。これは、あの素晴らしい時代のことです。LLMとのやり取りは全部Web UI経由で、エージェントはようやく出てき始めた段階で、コードをちゃんと書きたければ、チャットからコピーしてファイルに書き戻す――みたいなことを延々やる必要がありました。当時はローカルで Mixtral 8x7B を動かしていて、部分的に RAM にオフロードしていましたが、非常に満足していました。生成速度はだいたい毎秒8トークンで、インスタントモデルとのカジュアルな会話には十分すぎるほどでした。そして Mixtral は、大学の Entrepreneurship & Innovation の授業で、私のためにエッセイを書いてくれました。コード生成にも使ってみましたし、正確には Ansible の設定のために使ってみたのですが、案の定チームリードに、愚かなミスのせいでボコボコにされました。楽しい時代でした。
今、Qwen-3.6-27B と Qwen-3.6-35B-A3B が出ました。コーディングやエージェント的タスク向けに特化して調整された、小さな2つのモデルで、ローカル推論を想定しています。フル精度、つまり FP8 で動かすには（それはネイティブにその形で学習されています）、およそ 36/40 GB の VRAM が必要です。ですが我々は自慢できるような人間ではありませんし、妥協してでもローカル機材に載せたいので、GGUF を q4_k_m あるいは q3_k_s で使ってローカルのハードウェアに収めます。
そこで私は、ローカルモデルが「ノリでコードを書く（vibe coding）」のどれくらいできるのか気になりました。もちろん Opus や Sonnet の代わりにはならないでしょう。そこで満足できるターゲットとして、フロンティアラボからサブフロンティアモデルを1つ選びました：GPT-Codex-Spark。262k のコンテキストウィンドウを持ちます。完全な Codex や GPT-5.2/5.4/5.5 ほど賢くはありませんが、ツール呼び出しやコードを書くなどは十分にできます。ローカルモデルの近似としては十分に使えます。違いは、ものすごく速いことと、月100ドルかかることです。一方ローカルモデルは、ものすごく遅いけれど無料、いや正確には、ゲーミングPCが消費する電力分だけかかります。あわせて、Anthropic が何を出しているのかを見るために Claude Haiku 4.5 も取りました。
ローカル推論用のハードウェアとして、Ryzen 7 7800X3D、64 GB DDR5-6400、そして RTX 5080（VRAM 16 GB）を使いました。タスクを現実的に十分難しくするために、比較的詳細な設計ドキュメント* からオートリサーチループを実装する――という、かなり複雑な作業プロジェクトを用意し、Qwen-3.6-27B-q4_k_m、OpenRouter 経由の Qwen-3.6-27B、OpenRouter 経由の Gemma-4-31B、Pi Agent 内の Claude Haiku 4.5、そして Codex 内の Codex-Spark に、私の AGENTS.md を使って実装させるようプロンプトしました。OpenRouter のモデルを入れたのは、第一に API 経由で使う場合にどれくらい費用がかかるかを推定するため、第二にそれらの能力の上限――つまり、私のハードウェアでの量子化推論で“弱体化”した状態ではなく、フル精度の状態――を推定するためです。
重要なのは、私はあえて、これらのモデルには難しすぎるタスクを選んだことです。少なくとも1つですら、きれいに解けるとは期待していませんでした。原理的に、これはローカルモデルの評価でよくある問題です。人々はあまりにも簡単なタスクをプロンプトしてしまい、すると「ローカルでホストしたQwenがClaude Opusにパフォーマンスで匹敵した！」みたいな見出しが出る――どちらのモデルも HTML で Snake を書けた、というような話です。私のケースでは「タスクを解く」ことが目的ではなく、「解こうとしながら、できるだけ失敗しないこと」が目的でした。したがって、4つのうち1つしか解けなかったかどうかではなく、失敗のきれいさと、仕様に合わせるために残る修正の数で評価します。評価にあたっては Claude Code を使い、Claude Opus 4.7、xhigh を用いました。設計ドキュメントを書き、それ自身でクリーンな解決策を実装できた（少なくとも GPT-5.5 のレビューによれば）ので、良い審判であると信じることにします。
結果：
- Gemma-4-31B は完全に失敗しました。骨組みの解決策は書きましたが、モジュールの半分を馬鹿にするような（いい加減な）形にして、実装でもいくつかミスをしました。テストなし、__init__.py なし、requirements.txt も pyproject.toml もなし。ドキュメントは基本的に「NumPy をインストールすれば大丈夫」みたいなことを言っているだけです。コスト：$0.112、消費コンテキストトークン 803k、生成トークン 21k。
- Codex-Spark high は、とても美しい実装を、非常に素早く出しました――が、動きません。ファイルはフォルダにきれいに整理されているのに、import が間違っています。モデルは自分のコードのためのメソッドを作り話して（hallucinated）おり、ユニットテストを書かず、すべてを2つのコミットでやり切りました：コード＋ドキュメント全部です。いくらお金を使ったかは分かりません。私の理解では Spark には API がありません。$100 のサブスクリプションから、Spark の上限の 1% だけ使いました。
- Claude Haiku は、非常に詳細なドキュメントと README を書き、いくつかの Git ブランチまで作った（！）のに、テストは書きませんでした。テストが train に漏れ、メトリクスの計算を誤り、提案者（proposer）に必要なサンプルを提供しません。コードには TODO がたくさんあり、例外処理もありません。そしてループ全体が、単一のエラーでクラッシュします。246k トークンを読み、78k トークンを書き、コストは $1.067――テストした中では最も高価なモデルでした。
- Qwen-3.6-27B-q4_k_m は、ほぼ正しくできていますが、コードに train-to-test のリークがあります。1行で直せるものの、やはりエラーです。さらに、テストがなく、LLM リクエストに対するリトライもありません（ただし TODO はあります）。また OPS.md は、よくあるエラー、どう直すか、アップデートガイドなどを説明していません。読み取ったのは 39k トークンで、書き込んだのは 45k トークンです。ほぼ丸1日、作業時間のほとんどを費やし、約8時間走りました。これは驚くに値しません。モデルを部分的に RAM にオフロードしていて、空のコンテキストで 10 TPS、解決策の終盤で 1〜2 TPS しか出なかったからです。まさにその理由で、Gemma-4-31B をローカルで動かすことすら試しませんでした。特に、古いアーキテクチャで、そして KV キャッシュが Qwen と比べてあまりにも重いからです。
- OpenRouter 経由でフル品質の Qwen-3.6-27B は、予想外にも、ほぼ完全にタスクを解いてしまいました。最大の問題は、可変オブジェクトをハッシュする代わりに、その中の部分文字列を使っている点です。つまり変更を追跡できません。ですがオートリサーチループ自体は完全に動作しています。テスト、ドキュメント、コミットはあります――ブランチはありません、正確には本当ですが、それはどうでもいいです。ここでは不要なので。README などもあります。理由はたぶん単純で、モデルが自分で書いたテストを実行したため、他の実装で出てきたエラーをすべて拾えたのだと思われます。消費したのは 4.4M トークン（！）で、書いたのは 58k トークン。実行コストは $0.939 で、かなり高くつきました。というのも、このモデルは 100万トークンあたり $2（！！！）かかるからです。
解決策を「有能なフィードバックがあった場合、どの“弱いエージェント”が一番仕事を仕上げやすいか？」という観点で評価すると、両方の Qwen が決定的に勝っています。フル品質の Qwen はテストがあり、2つのワンライナーで修正できます。量子化 Qwen は1つのワンライナーで修正できます（そしてテストを書く、笑）。それ以外は、直すのがずっと面倒です。特に Codex は失望させられました。美しくクリーンなアーキテクチャにもかかわらず、import ができず、テストでカバーされていません。弱いモデルは、たとえフィードバックが良くても、それを直そうとしてから「直すことは全部やった、信じてくれよ兄弟（trust me bro）」と言ってしまい、実際に修正が機能したことを確認できないのです。
結論：ローカルモデルは、$20、$100、$200 のサブスクリプションの代わりになれるのでしょうか？もちろん無理です。さらに言うと、私の小さなテストはまったく代表的ではありません。実務では、設計ドキュメントからのワンショットプロジェクトではなく、大きな既存リポジトリをナビゲートする必要があります。
それでも、QwenがVRAMに収まって推論がより速くなるように、2枚目のGPUについて考え始めるべきだと思っています。APIはどんどん高くなり、モデルは生成するトークン数が増え、サブスクリプションは制限されてきています――そして、6か月後には、月20ドルのプランではコード作りを気持ちよく（vibeよく）できなくなる一方で、100ドルまたは200ドルのプランは、いま月20ドルだった頃のCodexレベルにまで制限で切り詰められるか、KYCによって締め付けられてしまうと確信しています。とはいえQwenは、私のゲーミング！（！）PC上で動きます。コードを書きます――遅くてミスもしますが、それでも書きます――そして、下位ティアの専用（proprietary）モデルの代替として十分に能力があります。私の環境に、だいたい$200のClaudeサブスクリプションを1.5〜2か月分使うのに相当する、3060のようなものを追加できれば、VRAMをフルに使ってQ6_K_MでQwenを動かせます。速くなります。おそらく、OpenRouterの非圧縮Qwenと同等の性能になるでしょう。そして、月200ドルという通行料に比べれば妥当なROI（投資対効果）です。
6か月後にモデルが更新されることは確信していますが、状況はだいたい同じままだと思います。Qwen-4は、Claude Haiku 5と同等、あるいはそれ以上のレベルで“vibe coding”（雰囲気でコーディング）を扱えるはずです。つまり、現状のSonnet 4.6 / Opus 4.5のレベルです。これは、API経由で大規模で有能なモデルによる、ときどきそして比較的安価なレビューを挟むことで、OpenAI/Anthropic/Googleのサブスクリプションを完全に取り除けるようになる、ということです。そしてそれは私の魂を温めます。
Claudeによる実装のレビュー用ドキュメント：
