金曜日の目玉リリースはQwen 3.8 27Bだった。AlibabaのQwen研究ラボによる、Apache 2.0ライセンスの270億パラメータでビジョン対応のLLMだ。個人的にこのリリースを楽しみにしていた。27BはそこそこのスペックのノートPCで動かすのに絶妙なサイズだし、前身のQwen 3.6 27Bも印象的だったからだ。

Qwenが公開するこのモデルの自己申告ベンチマークは目を見張るものだ。Qwen 3.6 27Bからだけでなく、今年5月時点ではあらゆるサイズの中でもQwen最強クラスだったクローズドウェイトのQwen 3.7-Plusからも向上している。独立したベンチマークがこのモデルをどう評価するのか、興味深いところだ。

このモデルは2台のマシンで動かしてみた。128GBメモリのM5 Max MacBook Proと、NVIDIA DGX Sparkだ。どちらでもLM Studioと17GBのQ4_K_M量子化ビルドを使っている。Sparkではllama-serverを直接使っても試した。

デフォルトのextra highは度を超えた考えすぎを招く

Qwenのドキュメントによると、このモデルは推論の強度（reasoning effort）がデフォルトでxhighになっており、今回試したLM StudioのGGUFでもそのデフォルトが維持されている。

Qwen3.8はreasoning_effortを公式にサポートしており、推論の深さの調整やコストの制御に利用できます。

• xhigh（デフォルト）: 徹底的な分析を要する複雑なタスク向け
• medium: 正確さと速度のバランスを取る
• low: 速度とコストを最適化する効率的な推論

これは笑ってしまうデフォルトだ。モデルを動かす方法として決して良いとは言えない。特にコンシューマー向けハードウェアではなおさらだ。ただ、その結果はめちゃくちゃ面白い。

すぐにLM Studioのデフォルトのコンテキスト上限である8,192トークンで問題にぶつかった。Qwenはどんな些細な問題でも考えるのにトークンを使い切ってしまうのだ。モデルの最大コンテキスト長である262,144で読み込み直すと、その問題は解消した。

こちらが、コンテキスト長を拡張して最初の試行で得られたペリカンが自転車に乗るSVGだ。生成には21分かかり、3,223トークンの出力を得るために22,276の推論トークンを使った。推論トレースはこちらで読める。

これはローカルマシンで動くモデルで生成できた中では断トツで最高のペリカンSVGだ。しかもこのQwenはかなり小さく、ディスク上ではたった17GBのファイルでしかない。気に入る点は多い。

1. 自転車のフレームが正しい形をしている
2. 自転車の両側に脚がある――これは極めて珍しい
3. ペリカンののど袋がはっきりきれいに描かれている
4. 翼が伸びてハンドルに届いている！
5. 動きを表す線が前ではなく後ろにある
6. 趣のある背景がある――いい感じの太陽、雲、丘、花と草。

それが21分待つ価値があったか？ 全くなかった。

同じプロンプトを推論をオフにして実行したのがこちらだ――トランスクリプトはこちら。こちらは3,715トークンを生成し、かかった時間は137秒――2分強だ。

念のため、OpenRouterを使って同じプロンプトを、はるかに大規模なQwen 3.8 2.4T-A95B（先週リリース）でも実行してみたところ、こんなイカしたアニメーションSVGが得られた。

Qwenはxhighだと考えすぎる傾向があると言ったが、実際どれくらいひどいのか？

もっとシンプルなプロンプトでも、同じデフォルトのextra high設定で試してみた。

draw an svg of a circle

Qwenの推論トレースはこんな風に始まった。

ユーザーは円のSVG描画を求めている。シンプルなリクエストだが、丁寧に作り込んだ作品にしたい。単なる<circle>を超えるものを作ろう。個性のある、単一で完結したSVGファイルだ――幾何学的な「円の習作」のようなもので、さりげないアニメーション、重ねたリング、特徴的なパレットを添えてみよう。

スコープは適切に保とう。求められているのは円のSVGだ。だから中核は円だ。でも工夫は加えられる。同心円のガイド（コンパス／作図のような）、目盛り、メインの円には柔らかいグラデーションの塗り、控えめな環境的モーション（ゆっくり回転する破線のリング、脈動するグロー）など。prefers-reduced-motionへの配慮？ それはCSS向けだろう。SVGならSMILかSVG内のCSSで対応できる。

パレットの選択肢。温かみのある紙に深いティール色のインク？ それともオフホワイトにネイビーの作図線を配した大胆な朱色の円――バウハウス／コンパス作図風か。「幾何学習作」風で行こう。クールなスレート色の背景か、明るい紙の白か？ クリームとテラコッタの組み合わせでなければ、紙の白でもいい。 [...]

数分後、モデルはこんなとてつもなく美しいアニメーションする円を生成した。まったく頼んだものではなかったが！

強くお勧めしたいのは、あのデフォルトは無視することだ。Qwen 3.8 27Bはまずはlowか、推論なしで動かしてみてほしい。素晴らしいモデルだが、あのデフォルト設定から始めるのはひどい選択だ。

バウンディングボックスがとても得意

ビジョンモデルを試す楽しい方法のひとつが、写真内の物体の周りにどれだけ正確にバウンディングボックスを返せるかを見ることだ。以前のQwenモデルがこれをうまくこなすのを見てきたので、今回はペリカンの周りにバウンディングボックスを描かせて試してみることにした。

過去には0〜1000スケールで頼むと良い結果が出るのを見てきた。今回はこう試した。

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'

推論トレースはこちらで、生成されたのはこれだ。

[
  {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
  {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

これは驚くほど正確だ。これらのボックスを写真の上に描画したのがこちら。

バウンディングボックスを表示するツールを作らせる

先ほどのバウンディングボックスの可視化は、ノートPC上でオフラインで動くQwen 3.8 27Bに作らせた新しいカスタムツールを使ったものだ。

思考の強度を下げるのを忘れたので、結果はとてつもなくオーバーエンジニアリングなものになったが、この単一のプロンプトからこのフル機能のインターフェースを作り上げることには成功した。

[
   {"bbox_2d": [195, 290, 370, 780], "label": "pelicans"},
   {"bbox_2d": [445, 320, 675, 850], "label": "pelicans"}
]

Build an HTML page which has an input box for accepting the URL to an image and a textarea for accepting the above style of JSON.

It appends the image to the page, measures its width and height, then treats the coords in the bbox_2d as scaled from 0-1000 and scales them against the actual width and height, then it renders labelled boxes over the image.

このスクリーンショットは、頼んですらいない機能のひとつを示している――テスト用の写真がない場合のためのデモシーンだ。

以下は思考トレースの該当部分だ。プロンプトで渡したサンプルJSONでラベルとして「pelicans」を使ったというだけで、自前でペリカンを描くことを決めた箇所である。

既知の画像を使った「サンプル読み込み」も？ 外部画像には依存できないが……画像URL入力はユーザーが提供するものだし、「サンプルで試す」ボタンを追加できるかも [...] うーん、canvasにシンプルなシーンを描いてdata URLとしてエクスポートし、画像として読み込めばいい――これなら自己完結していてデモもできる！ [...] でもユーザーの座標は実際のペリカン画像用のものだ。生成したプレースホルダーでもスケーリングのデモはできる。1000x1000のプレースホルダーを生成しよう。グラデーションの水面＋与えられたbboxの位置に置いたブロブ状の「ペリカン」シルエット2つ（同じスケールを使う――かわいい：シルエットを正確に0-1000の位置に置くことで、ボックスが揃うことを示せる）。これで楽しく自己完結したデモになる。シンプルにいこう。空のグラデーション、太陽、水、ペリカンっぽい形2つ（楕円の体、円の頭、くちばし）。bboxの中心に配置する。

（世界中のモデルが、私のくだらないベンチマークにほぼ2年間晒されたことで、機会さえあればペリカンを描こうとするバイアスを持ってしまっているのではないかと、少し心配になる。）

あれほどの考えすぎは必要なのだろうか？ 少なくとも多少は必要なのかもしれない。推論をオフにして試したところ、こんなバージョン（トランスクリプトはこちら）ができた。ほぼ動くが、ボックスの位置がずれている。

つまり推論なしでは、一発で動くツールを作るには至らなかった。追加のプロンプトでやり取りすれば到達できただろうが、これは推論が違いを生む良い例だ。

コーディングエージェントも駆動できる

ローカルモデルをめぐる最大の疑問のひとつは、コーディングエージェントのループを回すのに十分なパワーがあるかどうかだ。コーディングエージェントには長いコンテキスト、強力なコード生成サポート、そして信頼できるツール呼び出しが求められる。スペック上、Qwen 3.8 27Bはこの3つをすべて備えている。果たして役目を果たせるだろうか？

Piを使った初期実験はとても有望だった。Piを選んだのは、他の多くの選択肢よりもシステムプロンプトが短く、小さなモデルを試すのにより適しているからだ。

Spark上のLM Studioで動くQwen 3.8 27B（tailscale serve経由で共有）をPiが使うように、~/.pi/agent/models.jsonに以下を追記して設定した。

{
  "providers": {
    "spark": {
      "baseUrl": "https://spark-18b3.tail68a31.ts.net/v1",
      "api": "openai-responses",
      "apiKey": "dummy",
      "models": [
        {
          "id": "qwen3.8-27b",
          "reasoning": true
        }
      ]
    }
  }
}

そして~/dev/datasetteフォルダでpi --provider spark --model qwen3.8-27bを実行し、こうプロンプトを送った。

how does auth work?

さまざまなファイルにアクセスする推論とツール呼び出しを重ねた末、こんな回答を返してきた。非常にしっかりした内容だ。

ただひとつ問題があった。そのトランスクリプトを共有したかったのだ。そこでPiとQwen 3.8 27Bに~/.pi/agent/sessions/--Users-simon-Dropbox-dev-datasette--にあるJSONLのトランスクリプトファイルを指し示し、こうプロンプトを送った。

Write Python code to convert this jsonl to markdown

するとモデルはpi_jsonl_to_md.pyを構築してテストし、まさに必要な通りに動いた。そのセッションのトランスクリプトはこちらで、作らせたツールを使って公開したものだ。

速度の探求

ここまではすべて非常に有望に見える。ハイエンドのコンシューマーハードウェアで動く17GBのモデルがあり、コードを書き、ツールを駆動し、画像に注釈を付け、実際の作業をこなすためにLLMに求めることを概ねすべてこなせるのだ。

ただ、ひとつ非常に大きな引っかかりがある。動きが遅く感じられるのだ――特に考えすぎが始まると顕著だが、そうでなくても決してキビキビしているわけではない。

LM Studioでは毎秒15〜30トークン程度出ている。ひどくはないが、ホストされたAPIモデルから乗り換えさせるには遅すぎる。APIモデルはもっとずっと速く結果を返せるからだ。Artificial Analysisはトークン速度を計測しており、OpenAI 5.6 Solが74トークン/秒、5.6 Lunaが驚異の184/秒となっている。

良いニュースは、このモデルが2日前に初めてリリースされて以来、コミュニティが高速化の方法を模索してきたことだ。

最も有望な最適化のひとつは、モデル自体に組み込まれている。QwenはMulti-Token Predictionをサポートしている。これは、より安価な仕組みが数トークン先を予測し、メインモデルがその予測が正しかったかを素早く検証するというアーキテクチャ上の工夫だ。これにより推論性能が劇的に向上することがある。

llama.cppの作者であるGeorgi Gerganovのこのツイートを参考に、SparkでMTPを使ってモデルを次のように実行してみた。

llama serve \
 -hf  ggml-org/Qwen3.8-27B-GGUF:Q4_K_M \
 -hfd ggml-org/Qwen3.8-27B-GGUF:Q4_0 \
 --spec-default \
 --spec-type draft-mtp \
 --reasoning-preserve

そして案の定、これは大きなブーストになった。Codex上のGPT-5.6にSparkでの比較ベンチマークを実行させたところ、--spec-type draft-mtpサーバーはLM StudioのデフォルトGGUFを約72%上回った。

今後数週間で、このモデルをより高速にサーブするためのさらなるイノベーションがたくさん出てくるだろう。MLXコミュニティも何か秘策を練っているはずだ。

いくつかの所感

わずか17GBのファイルが自宅のマシンでこれらすべてをこなせるという事実は、奇跡だ。ローカルモデルが今年どれだけ進歩したかに、改めて嬉しく驚かされる。1年前なら、これほどの性能は最も優れた高価なプロプライエタリモデルと競えるレベルだった――それが今では高性能なノートPCで動くのだ。

これが日常使いのモデルになるのを妨げている唯一のものはパフォーマンスだ。M5 MacでもDGX Sparkでも、かなり遅く感じられる。これがこうしたdense（Mixture-of-Expertsではない）モデルの難点だ――十分な性能を発揮するには大量のメモリ帯域幅が必要になるが、私が使えるどちらのマシンもその点ではトップクラスの性能を持っているわけではない。

Qwen 3.8 27Bについて最も重要なのは、それが示していることだ。長いコンテキスト、効果的なツール呼び出し、強力なビジョン能力、そしてまともなコード生成を備えたオープンウェイトの汎用モデルを、わずか17GBのファイルに収められるということだ。

このサイズのモデルは驚くべきペースで改良され続けている。有能なモデルを動かすために、データセンター級のハードウェアに50万ドルも費やす必要はもうないのだ。