Qwen3.8-27B が公開された。自分は 3.6 を RTX3090 で常用してるので当然載せ替えるつもりなんだけど、公式のベンチを見ていたら、これは今までのオープンモデルとは売り方が違うなと思った。
先に結論だけ書く。
- Qwen3.8-27B は「難しい問題を解く賢さ」ではなく、「長い作業を最後までやり切る粘り強さ」に振ったモデル
- PC操作のベンチ(OSWorld-Verified)では 84.3% で、比較対象の中で一番いい
- SWE-bench Pro は 61.7% で、Claude Opus 4.6 Max の 53.4% を上回ってる
- なので「複雑な推論は Claude、手数の多い作業は Qwen3.8」という分担が現実的な使い方になる
「オープンモデルだからここまでしかできない」という前提は、もう置き直したほうがいい。
公式ベンチを並べてみる
Qwen の公式モデルカードに載っている数字を、そのまま表にする。自分の実測ではなく公式値。実測は 3090 に載せてから別記事でやる。
| ベンチマーク | 何を測るか | Qwen3.8-27B | 比較 |
|---|---|---|---|
| SWE-bench Pro | 実リポジトリのバグ修正 | 61.7% | Opus 4.6 Max 53.4% |
| OSWorld-Verified | デスクトップ操作 | 84.3% | 比較対象中トップ |
| Terminal Bench 2.1 | ターミナル作業 | 73.0% | Opus 4.6 Max 78.2% |
| WebArena-Verified | ブラウザ操作 | 64.8% | — |
| AndroidWorld | モバイル操作 | 81.9% | — |
| CoWorkBench | 長時間の事務タスク | 70.7% | — |
並んでるベンチの顔ぶれを見てほしい。全部「操作」と「作業完遂」のベンチなんだよね。数学オリンピックみたいな難問系がメインじゃない。何を狙って作られたモデルなのかが、ベンチの選び方に露骨に出てる。
27B というサイズで SWE-bench Pro が Opus を上回るのは正直びっくりした。一方で Terminal Bench は Opus に届いていない。全部で勝ってるわけじゃないというのはちゃんと書いておきたい。
3.6 から何が変わったのか
ここが一番大事なポイントで、アーキテクチャは刷新されていない。
変わったのは事後学習のほう。エージェントの作業軌跡(どう考えて、どのツールを呼んで、失敗したらどう立て直したか、という一連の記録)に対する強化学習と、環境からのフィードバックの扱いが厚くなってる。
つまり 3.8 は「頭が良くなった」というより、「作業の途中で諦めなくなった」モデル。
エージェントを実際に回したことがある人なら分かると思うんだけど、ローカルモデルでエージェントを組んだときに詰まるのって、たいてい難しさじゃない。
- ツールを3回くらい呼んだあたりで話の筋を見失う
- エラーが返ってきたときに、同じコマンドをもう一回打つ
- 途中で「できました」と言って終わる(できてない)
- 20ターン目くらいで最初の指示を忘れる
このへんが崩れると、どれだけ賢くても実務では使えない。3.8 が伸ばしてきたのは、まさにここだと思う。
本題:Claude の下で働かせる
で、ここからが自分が一番書きたかったところ。
Claude Code なり Hermes なり Open Code なりでエージェントを回してると、トークンがえげつない勢いで溶ける。特にこういう作業。
- ファイルをひたすら読んで回る
- grep して、また読んで、また grep する
- テストを回して、落ちて、直して、また回す
- ログを流し読みする
手数は多いけど一回ごとの判断は難しくない作業。ここに毎回フロンティアモデルを使うのは、正直もったいない。
分担の考え方
自分が考えてる構成はこう。
| 層 | 担当 | 理由 |
|---|---|---|
| 設計・判断 | Claude | 方針を決める、トレードオフを評価する、最終レビュー |
| 探索・実行 | Qwen3.8-27B(ローカル) | ファイル探索、grep、テスト実行、ログ確認、定型修正 |
| 検証 | Claude | 出てきた差分が意図どおりか見る |
ポイントは、Qwen3.8 に「判断」をさせないこと。「このディレクトリ配下で認証まわりを扱ってるファイルを全部挙げて、各ファイルが何をしてるか1行で書け」みたいな、答えが検証できる作業だけを投げる。
これなら 3.8 の得意分野(ツールを何度も呼んで最後までやり切る)にはまるし、間違っててもこちらで検証できる。そしてそのぶんのトークンはローカルなのでタダ。電気代は別として。
なぜ今まではこれができなかったか
やろうとした人は分かると思うけど、今までのローカルモデルをサブエージェントにすると、監督コストのほうが高くついた。
途中で止まる、勝手に終わる、ツールの引数を捏造する。結局こっちが全部見張ることになって、だったら最初から Claude に投げたほうが速い、となる。
3.8 が伸ばしてきたのが「長い作業を最後までやり切る」ところなら、この監督コストが下がる。下がったぶんだけ分担が成立する。オープンモデルの使いどころが「安い代替品」から「役割の違う戦力」に変わる、というのが、自分がこのリリースで一番面白いと思ったところ。
注意しておきたいこと
いいことばかり書いたので、引っかかってる点も並べておく。
1. 知識の新しさは分からない
Qwen は公式に知識カットオフを公表していない。HuggingFace の discussion に「3.6 と違うのか?」という質問は立ってるんだけど、答えてるのは公式ではなく一般ユーザーで、しかも根拠はモデル自身の自己申告だった。
モデルの自己申告は当てにならない。学習データに含まれる別モデルの発言をそのまま言ってるだけ、というのがよくあるので、これは根拠にできない。
「3.8 のほうが知識が古いらしい」という話も見かけるけど、一次ソースは見つからなかった。これは載せてから実際に聞いて確かめる。続報で書く。
いずれにせよ、エージェント用途なら知識の新しさはそこまで効かない。必要な情報はツールで取りに行かせる前提なので。
2. ベンチはベンダー発表値
上の表は全部 Qwen 自身が出した数字で、第三者検証じゃない。そのまま信じるんじゃなくて、自分の用途で回して確かめるのが前提。自分もこれから 3090 に載せて測る。
3. 全部で勝ってるわけじゃない
Terminal Bench は Opus 4.6 Max に届いてない。「27B が Opus を全面的に超えた」みたいな話ではないので、そこは冷静に。
3090 で動かすには
自分の環境は RTX3090(24GB)1枚 + tabbyAPI + ExLlamaV3。
Qwen3.8-27B は公開直後から exl3 量子化が出ていて、本家系のものから3090単機向けを明示した量子化まである。GGUF 派なら Unsloth のものが HuggingFace のトレンド上位に入っていた。
スペック上の注意点として、ネイティブ 262,144 トークン。YaRN で最大100万まで拡張できる。3.6 を 128K で運用してた身からすると倍なんだけど、3090 の 24GB に 256K 分の KV キャッシュが載るかは別問題。このへんは実測しないと何とも言えない。
あと 3.8 はネイティブに画像と動画を理解するモデルなので、vision のぶん weights が重くなる可能性がある。同じ bpw でも VRAM の余裕が変わるはず。
まとめ
- Qwen3.8-27B はエージェント用途に振り切ったモデル。ベンチの顔ぶれがそう言ってる
- PC操作 84.3%、SWE-bench Pro 61.7%(Opus 4.6 Max 超え)は素直にすごい
- ただし Terminal Bench は Opus に届いてないし、全部ベンダー値
- 使い方としては「Claude が設計して、Qwen3.8 が手を動かす」が現実的
- 知識の新しさは公式が黙ってるので、実機で確かめてから書く
「オープンモデルだからここまで」という線引きは、少なくともエージェント用途では引き直したほうがいい。次は実際に 3090 に載せて、3.6 と並べて測る。

