ローカルで動く27B、本当に使えるのか — Jackrong「Qwopus-3.6-27B-Coder」を量子化4種で実機評価してみた

この記事の結論（先に言います）

• Qwopus-3.6-27B-Coder は、Qwen3.6-27Bをベースに「Trace Inversion」というCoT再構成手法とエージェント軌跡データでSFTした、ローカル運用向けのコーディング特化モデル。

• 自前の 20問のコード生成ベンチ を量子化4種（Q4_K_M / Q5_K_M / Q6_K / Q8_0）で回したところ、Q5_K_Mだけが20/20の満点。他は19/20で、いずれも同じ1問（括弧つき四則演算）を落とした。

• つまり、「精度の高い量子化ほど賢い」わけではない。実用上のスイートスポットは、配布元の公式評価とも一致する Q5_K_M。

• 自信度: HIGH（手元の実測ベース）。ただしサンプルは20問と小規模なので、1問差はノイズの範囲という前提で読んでください。

Qwopus-3.6-27B-Coderとは何か

Jackrong/Qwopus3.6-27B-Coder-MTP-GGUF は、HuggingFace上で公開されているコミュニティ製のコーディングモデルです。モデルカードの記載をまとめると、要点はこうです。

ベースは Alibaba の Qwen3.6-27B（Denseな27Bパラメータ）。ここに Trace Inversion という独自手法を組み合わせています。これは、商用フロンティアモデルが出力する「圧縮された推論サマリ」を、専用の再構成器（Trace-Inverter-4B）でフルの段階推論（CoT）に逆算復元し、それを学習データに使うという考え方です。Claude Opus系の再構成トレース（4.6/4.7由来とされるデータセット）と、Hermes系のエージェント軌跡（ツール呼び出しの多ターン実行ログ約1万件）を合わせて、3段階のカリキュラム学習でSFTしています。

設計思想は明快で、**「APIの高額モデルと、非力なローカル小型モデルのあいだを埋める」**こと。27Bという規模は、RTX 5090クラスの単一GPUに載せられつつ、リポジトリ構造や複数ファイル依存、ツール呼び出しを内面化できるギリギリのラインを狙っています。

今回手元にあるのは MTP版のGGUF量子化 です。MTP（Multi-Token Prediction）は補助予測ヘッドを使った投機的デコードで、モデルカードによれば標準デコード比 約1.66倍 の高速化を、精度を保ったまま実現したとされています。

配布元が公表しているベンチ（＝これは「主張」として読む）

モデルカードの目玉は SWE-bench Verified（フル500問）で 335/500 = 67.0% という数字です。条件が独特で、thinking-off（推論非表示モード） かつ Q5_K_M量子化、RTX 5090 + MTPで 約100トークン/秒 という、いかにも「ローカルで速いエージェント」を意識したセッティングです。

参考までに、カードに併記された他モデル（多くはthinking-on）の数字：

ただし配布元自身も注記しているとおり、これはモード違いの横並び表ではなく「位置づけの目安」。thinking-offの27Bローカル量子化で67%に届く、という事実の方が本質です。ここは鵜呑みにせず、自分で確かめるべきところ——というわけで、実機テストに移ります。

自前ベンチでの実機評価

テスト設計

20問（t001〜t020）の小規模なコード生成タスクを用意し、生成されたコードを pytestで自動採点 しました。各問は「仕様を満たすPython関数/クラスを書かせ、隠しテストを通すか」を見るもので、難易度と領域を散らしています。

• 基礎ユーティリティ: 範囲合計、クランプ、回文判定、統計量

• データ構造: LRUキャッシュ、優先度付きキュー、トライ木

• パース系: スラグ生成、HTMLタグ抽出、CSV行、括弧つき四則演算の評価器

• システム系: レートリミッタ、設定マージ、レジストリ、単位変換

これを 量子化4種（Q4_K_M / Q5_K_M / Q6_K / Q8_0） で同条件実行し、合否を比較しました。

結果

20問中19問は全量子化が安定して正解。基礎ユーティリティからLRU・トライ・優先度付きキューといったデータ構造、レートリミッタや設定マージのようなやや実務的なお題まで、27Bらしい安定感で通しています。この価格帯（＝ローカル単一GPU）で、出力フォーマットが崩れず素直にテストを通るのは普通に優秀です。

唯一の分かれ目：t020「括弧つき四則演算の評価器」

面白いのはここです。唯一全体で割れたのが t020、`(1+2)*3` のような括弧を含む式の評価器を書かせる問題でした。

Q4 / Q6 / Q8 は、トークナイザで認識する文字集合を `+-*/` と数字に限定してしまい、`(` を「不正な文字」として例外を投げて落ちました。一方 Q5_K_M だけは文字集合に `()` を含め、再帰下降パーサで括弧を正しく処理して満点。コードを見比べると、失敗組は「括弧の存在自体をトークナイザで取りこぼす」という、いかにも詰めの甘い実装でした。

# 失敗組（Q4/Q6/Q8）: 括弧が文字集合に無い
if ch in "+-*/":
    ...
# 成功（Q5_K_M）: 括弧を含めて再帰下降でパース
if ch in "+-*/()":
    ...

この結果をどう読むか

直感的には「Q8 > Q6 > Q5 > Q4」の順に賢いはずですが、今回は最高精度のQ8でもQ5に負けた。ここが実務的な教訓です。

20問という小サンプルでの1問差なので、統計的には誤差（サンプリングノイズ）の範囲と見るのが妥当です。量子化のビット数と難問の正答が、必ずしも単調に対応するわけではない、という良い実例になりました。重要なのは、わざわざQ8を選ぶ動機は（少なくともこのテストでは）無かったこと。配布元がベンチに使ったのもQ5_K_Mであり、容量・速度・精度のバランス点としてQ5_K_Mを選ぶのは理にかなっています。

どんな用途に向くか

モデルカードの推奨と実測の手触りを合わせると、向き不向きはこう整理できます。

向いているのは、エージェント的なコード生成、リポジトリ規模のデバッグ・パッチ生成、ツール呼び出しを伴う多段ワークフロー、DevOps系スクリプティングなど。`<think>`タグで推論を出すモデルなので、フロントやエージェント基盤側でそのパースを前提に組むと素直に扱えます。thinking-offでも実用速度（RTX 5090で約100 t/s）を保てるのが、対話的な開発ループで効いてきます。

注意点としては、コーディング特化のため一般ドメインや安全性の網羅評価は未実施（コミュニティの実験的リリースという位置づけ）。非コーディングタスクでは能力低下が起こりうること、ツール呼び出しの挙動がプロンプト形式とツールスキーマの一貫性に強く依存すること、32K超の長文ではRoPE/YaRNスケーリングが要ること。このあたりは導入前に押さえておきたいところです。

まとめ — 量子化はQ5_K_Mを選べばいい

Qwopus-3.6-27B-Coderは、「ローカル単一GPUで動くコーダー」というジャンルで、実用十分な完成度を見せました。自前の20問ベンチでは19問が全量子化で安定正解、唯一割れた括弧つきパーサも、配布元推奨の Q5_K_M なら満点。

最終的な落としどころはシンプルです。

• 基本は Q5_K_M を選ぶ。 容量・速度・精度のバランスが良く、配布元の公式評価とも条件が揃う。

• Q8_0やQ6_Kに、このクラスの作業で追加コストを払う明確な理由は見当たらなかった。

• VRAMが厳しいなら Q4_K_M でも19/20。実用上の差はごくわずか。

「API級の精度を、手元で、速く」を狙うなら、十分に試す価値のある一台です。次は thinking-on でのSWE-bench再現や、ツール呼び出しの安定性も測ってみたいところ。

評価環境: Jackrong/Qwopus3.6-27B-Coder-MTP-GGUF（Q4_K_M / Q5_K_M / Q6_K / Q8_0）を、20問のローカルコード生成ベンチで実行しpytestで自動採点。ベンチマークの主張部分はHuggingFaceモデルカード（2026年6月時点）の記載に基づく。

#ローカルLLM #LLM #生成AI #コーディングAI #Qwen #量子化 #GGUF #SWEbench #エンジニア #機械学習