何が出たのか

Qwen 3.8 27Bは、Alibabaの研究組織Qwenが公開したApache 2ライセンス・27Bパラメータ・画像入力対応のLLMです。Qwenの自己申告ベンチマークでは、前世代のQwen 3.6 27Bだけでなく、2026年5月時点でQwenの最強クラスだったクローズドウェイトのQwen 3.7-Plusをも上回るとされています(独立系の検証はこれから)。検証はLM Studio上のQ4_K_M量子化ビルド(17GB)と、Spark上のllama-serverで行われました。

「賢すぎる既定値」という新しい落とし穴

注目すべきは性能そのものより、既定の推論強度がxhighに設定されている点です。Qwen3.8はreasoning_effortパラメータを公式サポートし、xhigh(複雑なタスク向けの徹底分析)、medium(精度と速度の均衡)、low(速度とコスト重視)の3段階を持ちますが、既定はxhigh。LM StudioのGGUFもその既定を引き継ぎます。

結果は極端でした。LM Studioの既定コンテキスト8,192トークンは、平凡な問題への「思考」だけで使い切られ、最大262,144トークンで読み込み直す必要が生じます。恒例のペリカンが自転車に乗るSVGテストは21分・推論22,276トークンを消費して出力3,223トークン。ローカル実行モデルとして過去最高の出来(フレーム形状が正しく、脚が自転車の両側にあり、翼がハンドルに届き、モーションラインが後方にある)でしたが、推論をオフにすると同じプロンプトが137秒・3,715トークンで完了します。

極めつけは「円のSVGを描いて」という指示への反応です。モデルは同心円のガイド、目盛り、グラデーション、アニメーション、パレットまで熟慮し、数分かけて「頼んでいない」美しいアニメーション円を出力しました。Willison氏の推奨は明快で、既定値は無視してlowか推論なしから始めよ、というものです。

実務で効いたのは推論より「道具として動くこと」

一方、実用面の手応えは本物です。0-1000スケールを指定した画像内バウンディングボックス抽出では、写真中の2羽のペリカンに対し[195, 290, 370, 780]と[445, 320, 675, 850]を正しくJSONで返しました。オフライン状態のノートPC上で、単一プロンプトからバウンディングボックス注釈用のHTMLツールを丸ごと生成もしています(ただし思考強度を絞っていないため過剰設計で、頼んでいないデモ機能まで付いた)。さらにシステムプロンプトが短いエージェントPiと組み合わせ、Datasetteのコードベースに「認証はどう動いているか」と尋ねると、複数ファイルを横断する推論とツール呼び出しの末に的確な回答を返し、Pi のJSONLセッションをMarkdownへ変換するPythonスクリプトも書いて動かしました。

残る課題は速度、そしてその改善余地

唯一にして最大の難点は速度で、LM Studioでは毎秒15〜30トークン程度。Artificial AnalysisがOpenAI 5.6 Solを74トークン/秒、5.6 Luna を184トークン/秒と計測しているのと比べると、ホスト型APIから乗り換えるには厳しい水準です。理由は構造的で、MoEでない密なモデルはメモリ帯域を大量に要求し、M5 MacもDGX Sparkも帯域の王者ではありません。

ただしここは動きが速い領域です。QwenはMulti-Token Prediction(安価な機構が数トークン先を推測し、本体が検証する方式)に対応しており、llama.cpp作者Georgi Gerganov氏の投稿を元に--spec-default --spec-type draft-mtpで起動したサーバーは、Codex上のGPT-5.6が実施した比較ベンチマークでLM Studio既定のGGUFを約72%上回りました。MLXコミュニティ側の最適化も含め、配信高速化の工夫はこれから積み上がると見られます。

💼 事業会社視点:これは自社にどう効くか

日本企業にとっての含意は「オンプレLLMの検討開始ラインが下がった」ことです。17GBのファイルが、長いコンテキストと実用的なツール呼び出しをこなし、オフラインのノートPC上でHTMLツールを一から書き上げる——1年前なら最高級のプロプライエタリモデルと張り合う水準です。Apache 2なので商用改変・自社製品への同梱も可能。図面・帳票・現場写真といった外部送信しづらいデータを扱う製造業、健康保険組合や自治体案件を持つ受託開発、そして機微な顧客画像を扱うECの検品・出品審査は、まずPoCを社内で回せる段階に来ました。

ただし役員が意思決定すべき論点は精度ではなく単価と待ち時間です。毎秒15〜30トークンは、対話UIに載せれば顧客が離脱する速度です。判断軸はこう置くべきでしょう。リアルタイム応答が要る用途はホスト型API、夜間バッチ・大量処理・機密データの一次処理はローカル、と切り分ける。加えてreasoning_effortは事実上のコストつまみです。SaaS事業者なら推論強度をプラン別に割り当てる設計、受託開発なら見積時に「思考トークン量」を工数変数として明示する運用が、今期から必要になります。既定値をそのまま本番投入すると、円を1つ描くだけで数分溶かす事故が起きます。

関連リンク