8月16日、Simon Willisonが「Qwen 3.8 27B is excellent, but it defaults to wildly overthinking things」と題した記事を公開した。この記事では、AlibabaのQwen研究所が新たにリリースした27BパラメータのローカルLLM「Qwen3.8-27B」を実際に動かした結果と、デフォルト設定の問題点について詳しく紹介されている。
デフォルトのxhigh設定が引き起こす「過剰思考」問題
Qwen3.8-27BはApache 2ライセンスで公開されたビジョン対応モデルで、ディスク上のファイルサイズは17GB（Q4_K_M量子化）。128GB M5 Max MacBook ProやNVIDIA DGX Sparkのようなハイエンドな消費者向けハードウェアで動作する。
このモデルを試すうえで、まず引っかかるのがデフォルトの推論努力レベルだ。Qwenの公式ドキュメントによると、以下の3段階が用意されている。
xhigh（デフォルト）：徹底的な分析を要する複雑なタスク向けmedium：精度と速度のバランス型low：速度とコストを優先
問題は**xhighがデフォルト**になっていることだ。Simon Willisonはこれを「笑えるデフォルト」と表現している。
実際の弊害を示す具体例が興味深い。「自転車に乗るペリカンのSVGを描け」というプロンプトに対して、モデルは22,276トークンの推論を行い、3,223トークンの出力を生成するのに21分かかった。
出力の品質自体は高い。自転車のフレーム形状が正確、ペリカンの足が自転車の両側に描かれている、翼がハンドルバーに触れているなど、細部の完成度は高い。だが、21分待つ価値があるかというと「絶対にない」とSimon Willisonは断言している。
推論をオフにした同じプロンプトでは3,715トークン、約2分で完了した。品質は落ちるものの、実用上はこちらが現実的だ。
さらに極端な例として、「円のSVGを描け」という単純なプロンプトでもxhighはこう考え始めた。
The user is asking for an SVG drawing of a circle. Simple request — but I want it to be a carefully crafted piece. Let me make something that goes beyond just
<circle>: a single self-contained SVG file with character — maybe a geometric "circle study," with subtle animation, layered rings, and a distinctive palette.
その結果、アニメーション付きの「幾何学的スタディ」が生成された。頼んでいないものを数分かけて作り上げた形だ。
実際に使う際の推奨設定はlow、あるいは推論オフからスタートすること。LM Studioではデフォルトのコンテキスト制限が8,192トークンになっており、xhigh設定ではすぐに上限に達してしまう。最大の262,144トークンに設定変更が必要な点も注意が必要だ。
ビジョン機能：バウンディングボックスの精度
ビジョン機能のテストとして、写真内のペリカンにバウンディングボックスを返させた。
llm -a https://static.inaturalist.org/photos/714731804/large.jpg \
-m lmstudio/qwen/qwen3.8-27b \
'Return JSON bounding boxes for the pelicans in this photo, 0-1000 scale for each dimension'
返ってきたJSONはこうだ。
[
{"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
{"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]
座標の精度は非常に高く、ボックスは各ペリカンをほぼ正確に囲んでいる。ローカルで動作する27Bモデルとしては十分な性能だ。
コーディングエージェントとしての実用性
ローカルモデルでコーディングエージェントループを回せるか、という点も検証されている。Qwen3.8-27Bは長いコンテキスト、コード生成、ツール呼び出しの3要件をスペック上は満たしている。
Simon Willisonはllm-cli向けのコーディングエージェントプラグインであるPiをLM Studio経由でQwen3.8-27Bに接続し、Datasette（Pythonのデータ公開ツール）のリポジトリで試した。「認証はどう動いているか？」という問いに対して、複数ファイルを参照した後に質の高い回答を生成した。
さらにセッションのトランスクリプトをMarkdownに変換するPythonスクリプトをビルドさせ、実際に動作するコードを一発で生成している。このスクリプトはそのままGitHubにコミットされた。
速度の課題とMTPによる改善
現状のスループットはLM Studioで15〜30トークン/秒程度。実用できなくはないが、ホスト型APIと比べると見劣りする。Artificial Analysisのデータによれば、OpenAI 5.6 Solが74トークン/秒、5.6 Lunaは184トークン/秒だ。
速度改善の有力な手段として、モデル自体がサポートするMulti-Token Prediction（MTP）がある。MTPはSpeculative Decodingの一形態で、補助的な小型ヘッドが複数トークン先の候補を先読み生成し、メインモデルがその候補をまとめて検証・採択することで、1ステップあたりに確定できるトークン数を増やすアーキテクチャ上の工夫だ。実装コストが低い割に推論スループットへの効果が大きく、近年のLLMで採用が広がっている。llama.cppの作者Georgi Gerganovがツイートで言及した方法でDGX Sparkで試せる。
まとめ
Qwen3.8-27Bは、ローカルで動作するモデルとして高い能力を持っている。ビジョン機能、コーディングエージェント、ツール呼び出しのいずれも実用レベルだ。ただし、デフォルトのxhigh設定は使い物にならない。最初は推論オフかlowで試すのが正解だ。速度の問題は残るが、MTPなどの最適化で改善の余地がある。
詳細はQwen 3.8 27B is excellent, but it defaults to wildly overthinking thingsを参照していただきたい。
