1. 画像理解が最初から組み込まれている
ローカルLLMの中には、画像処理だけ別のVisionモデルを組み合わせる構成もまだ多くあります。
Qwen3.8-27Bは最初からマルチモーダル対応です。
画像、グラフ、PDF、コードのスクリーンショットを直接読み取れ、動画フレームの内容も理解できます。
PC操作能力を見るOSWorld-Verifiedでは 84.3点 を記録し、Claude Opus 4.6 Maxの72.7点を上回っています。
Agent用途では、単に画像を認識できるだけでは足りません。
画面の状態を理解して、次にどこをクリックするのか、何を入力するのかまで判断する必要があります。Qwen3.8-27Bは、この「見てから動く」部分までかなり強くなっています。
2. 262K Tokenあれば、普段使いではかなり余裕がある
ネイティブで 262K Token。
大規模なコードベース、論文、契約書、長い社内資料などをまとめて扱うには十分なサイズです。
さらにYaRNを使えば、最大 100万Token まで拡張できます。
開発者にとって分かりやすいメリットは、ファイルを細かく分割して何度も読み込ませる手間が減ることです。
大きなプロジェクトでも、より広い範囲を一度にモデルへ渡し、依存関係を含めて見てもらいやすくなります。
ただし、100万Tokenはスペック表としては魅力的でも、ローカル環境で常用するとなると話は別です。
コンテキストを伸ばすほどメモリ消費と推論時間は増えます。個人的には、まず 262Kを無理なく使えること のほうが実用上は重要だと思います。
3. 今回いちばん伸びたのはコード
SWE-bench Proは、前世代の 53.5から61.7 まで上がりました。
今回のアップデートで、かなり注目していい数字です。
SWE-benchは、単純に「この関数を書いて」というタイプのテストではありません。
既存のコードベースを読み、問題箇所を探し、複数のファイルを修正し、その変更で別の部分が壊れていないかまで確認する必要があります。
つまり、61.7というスコアは、コード生成そのものより ソフトウェア開発全体に近い能力 が伸びたことを示しています。
Coding Agent、バグ修正、既存リポジトリのメンテナンス用途では、かなり期待できそうです。
もちろん、ベンチマーク1つだけで最上位のクラウドモデルを全部置き換えられるとは言えません。
依存関係が複雑な大型プロジェクトや、何十ステップも続くタスクでは、実際のコードベースで試したほうがいいでしょう。
4. reasoning_effort：簡単な質問まで全力で考えさせない
個人的にかなり実用的だと感じるのが reasoning_effort です。
タスクに応じて、モデルがどれくらい深く考えるかを調整できます。
要約、書式変換、簡単な質問なら低めにして、時間と計算量を節約。
コード解析、複雑なロジック、Agentの計画などでは高めにする。
ローカルLLMでは、この調整がかなり重要です。使っているGPUも、電気代も自分持ちだからです。
海外の開発者によるテストでは、「自転車に乗るペリカン」のSVGを作らせたところ、デフォルトの高い推論設定で約 2.2万Token を使い、完成まで約21分かかった例もあります。
ちゃんと答えにはたどり着く。ただ、ちょっと真面目すぎます。
reasoning_effort は常に最大にするのではなく、普段は低め、難しい仕事だけ上げる使い方が合いそうです。
5. Qwen3.6-27Bからどこが変わった？
面白いのは、モデルサイズを大きく変えずに、任せられる仕事がかなり増えたことです。
分かりやすいのはコード性能。
SWE-bench Proは 53.5 → 61.7 まで上昇しました。
Officeや専門業務系も改善しており、JobBench関連では前世代比で約 50%向上 しています。文書、表計算、業務資料の処理ではかなり使いやすくなっています。
すでに27Bクラスを動かせる環境がある人にとっては、かなり理想的なアップデートです。
GPUを買い替えて巨大モデルへ移行しなくても、同じくらいのハードウェアで、コード、Agent、業務処理を一段上のレベルまで持っていけます。
ローカルLLMでは、こういう進化のほうが単純なパラメータ数の増加よりありがたいです。
コメント（0件）