ローカル vs クラウドモデル：Qwen-3.6-27B、Gemma-4-31B、Claude Haiku、Codex-Spark のハードコード生成比較

あるRedditユーザーが、ローカルで実行したQwen-3.6-27B（GGUF q4_k_m）とAPIでの同等モデル（OpenRouter経由のQwen-3.6-27B、OpenRouter経由のGemma-4-31B、Claude Haiku 4.5、GPT-Codex-Spark）を比較しました。テストでは、設計書からのオートリサーチループの実装という、成功率ではなく失敗の鮮明さを評価するために意図的に難しいタスクが使用されました。

ハードウェア構成

• CPU: Ryzen 7 7800X3D
• RAM: 64 GB DDR5-6400
• GPU: RTX 5080（16 GB VRAM）
• ローカルモデル: Qwen-3.6-27B q4_k_m（GGUF）—量子化により16 GB VRAMに適合

結果

• Gemma-4-31B（API）: 完全に失敗。モックされたモジュールでスケルトンを作成したが、テストや設定ファイル（__init__.py、requirements.txt、pyproject.toml）はなし。コスト: $0.112、803kコンテキストトークン消費、21k生成。
• Codex-Spark（API）: 美しいフォルダ構造とコードを生成したが、インポートは幻覚。単体テストなし。$100/月のSpark制限の1%を使用。
• Claude Haiku 4.5（API）: 詳細な実装だが、正しさに失敗。（詳細はソースで省略）
• Qwen-3.6-27B（ローカルq4_k_m）: 明示的なスコアはないが、量子化推論はフル精度API版と比べて品質が低下するとユーザーは指摘。

コンテキスト

ユーザーは、典型的なローカルモデル評価では、ローカルモデルも最先端モデルも成功する簡単なタスク（例：HTMLでスネークゲーム）が使われ、そのためローカルモデルが実際よりも優れているように見えると主張。このテストでは設計書付きの実際のプロジェクトを使用し、完全に書かれた（ただし壊れた）コードを生成したのはCodex-Sparkだけだった。ポイントは、ローカルモデルは大幅な修正なしでは複雑なコード生成にはまだ対応していないということ。