Qwen 3.8 27Bは優れているが、デフォルトで考えすぎる

Qwen 3.8 27B is excellent, but it defaults to overthinking things

Qwen 3.8 27Bは優れているが、デフォルトで考えすぎる

AlibabaのQwen研究所が公開したApache 2.0ライセンスの27Bパラメータのビジョン対応LLM「Qwen 3.8 27B」は、ラップトップでも動作するサイズながら高性能。しかし、デフォルトの推論レベルが「xhigh」に設定されており、単純なプロンプトでも過剰に考え込む癖がある。著者は、ペリカンのSVG生成に21分もかかった例を挙げ、推論をオフにすれば2分で済むと指摘。それでも、バウンディングボックスの精度は高く、コーディングエージェントとしても有望だ。

私の強いおすすめは、そのデフォルト設定を無視することだ。Qwen 3.8 27Bはまず低い推論レベルか、まったく推論なしで実行してみてほしい。素晴らしいモデルだが、そのデフォルト設定は最悪の出発点だ。
  1. chvid

    「17GBのファイルが自宅のマシンでこんなことを全部できるなんて、奇跡だ。今年のローカルモデルの進歩には、またしても嬉しい驚きと感動を覚えている。」これこそが、点滅する見出しであるべきだと思う。これは、コンシューマー向けハードウェアで何ができるかを示している。

  2. jatora

    現在の時代のモデルはすべて考えすぎる。それは、RLのインセンティブ(またはそれらを持つモデルの蒸留)の産物だからだ。Fable 5とOpus 5のシステムカードを読んだ限りでは、私の再構成は次のようなものだ。タスクを完了する→完了したことを外部から観察可能な証拠で示す→自分の仕事をチェックする→問題を修正する→早まって止めない→評価者を包括的に満足させる。これはSWEベンチマークや自律エージェントにとっては素晴らしい。しかし、それは自然に病理も生み出す。過少回答は高くつき、過剰回答は安いのだ。

  3. hellajack3d

    私はllama.cppをフォークして、この挙動を正確に制御するための粗雑なメカニズムを追加した。基本的には、特定のしきい値でテキストを戦略的に注入して推論プロセスを誘導するものだ。これは主にQwen3.6-27Bを抑えるために作ったが、3.8も同様に反応するだろう。フォークはこちら - https://github.com/laurencehardman/llama-mindcontrol/tree/ma... もちろん、このようなハックは完璧ではなく、注入されたテキストがモデルをわずかに分布外に押しやるため、パフォーマンスが多少低下する可能性がある。そのため、文字列定数は慎重に選ぶ必要がある。Qwen3.5のテクニカルホワイトペーパーには、この点に関する指針がいくつかある。このメカニズムは、機能というよりは絶対にハックであり、llama.cppがより適切な推論制御をサポートすれば不要になるだろう。しかし今のところ、かなり便利だと感じている。

  4. RachelF

    私にとって驚くべきことは、約1年前のハイエンドモデルの推論に匹敵するローカルモデルが今や存在するということだ。この傾向が続くことを願っている。

  5. xlayn

    私はllama.cppのこのブランチを持っている。これは、KVキャッシュを壊さないようにテンプレートをパッチしたり、会話をディスクに保存して数日後にすばやく再開できるようにするなど、他の機能に加えて、推論努力フラグも受け付ける。https://github.com/alainnothere/llama.cpp/tree/disk-cache-ev... 私はテストを行い、推論努力はメッセージごとに設定できることを確認した。@xscottが言及したnoneオプションについては知らなかった。テストしたが変化は見られなかった。https://huggingface.co/Qwen/Qwen3.8-27B-FP8 によると、xhigh、medium、lowの3つの値しかないと思う。私はテストを行い、このモデルは「何かを見逃していないことを確認するために、自分自身に1000万語話す」ことができ、その後、より高速なモデルに切り替え、そしてまた切り替える...ということができる。私はテストを行い、このモデルは一貫性を保ち、思考トークンの流れに従う。結果はこちらで確認できる... https://github.com/alainnothere/llama.cpp/blob/disk-cache-ev...

  6. jedbrooke

    LLMが現在行っている「推論」は、結局は行き詰まるだろうと感じている。「でも待って」や「実は」といった言葉で「推論」しながら(時にはより良い)答えにたどり着く回答を読むたびに、実際の思考を模倣してトークンをぐるぐる回すのではなく、実際の正解への近道があるはずだと思う。

  7. xscott

    既存のツールセットにモデルをドロップして実行したいだけの人々を満足させるものではないが、この考えすぎ問題に対処する方法はたくさんあると思う。例えば、それは後退だが、私は{"reasoning_effort":"none"}を設定し、鼻先を導いた。ユーザー: 「<ばかげたデモ>を作ります。プランを作成してください。ただし、まだコードは書かないでください。」 エージェント: <短くて妥当なプラン> ユーザー: 「では、そのプランに従ってコードを書いてください。他のチャットは不要です。」 エージェント: <妥当な時間で妥当なコード> これはJinjaテンプレートか何かで修正できるかもしれないし、ハーネスへのハックかもしれないが、モデルに妥当に推論させることができることを示している。

  8. dexterlagan

    私はM5 Maxを48GBの(V)RAMで実行しているが、Q4でほぼ2回収まる。完璧に動作する。128GBに余分に2400ドル使わなくてよかったと思っている。もうそれ以上は必要ない...そしてそれは良いことだ(tm)。店頭で考えたことは確かにある。しかし、思ったんだ...今年はローカルモデルの年になるかもしれない?もしかしたら、もうすぐそんなにRAMは必要なくなるかもしれない?私は正しかった。省電力モードで15tk/s、パフォーマンスモードで30tk/sで動作するという事実に、私は驚嘆している。LMStudioでホストされたOpenCodeで何かをコーディングさせながら、バックグラウンドでモデルを実行し、他のことを同時にできる。なんという世界に生きているんだろう。人間の知能に近いもの(少なくとも推論とコードに関しては)がラップトップで動作するというのは、驚くべきことだ。

  9. SwellJoe

    これは本当だが、問題を過小評価していると思う。私は最近、多くの小規模モデルで行ってきたタスク(https://github.com/swelljoe/flar/pull/17)を実行したところ、それは素晴らしい仕事をし、セルフホスト可能なモデルの中で最高だった。しかし、私のデュアルGPUセットアップでは11時間もかかった。それは本当に噛みしめて、多くの時間をチェックと再チェックに費やした。これまで使ったモデルの中で、このタスクでは断然最も遅かった。GPT 5.5は同様のタスクを約20分で行った。ほとんどの大きなモデルは約1時間かかり、ほとんどの小さなモデルは数時間かかった(しかし、より悪い仕事をした)。

  10. andy99

    高密度モデルでの考えすぎの大きな問題は、明らかに速度低下だ。私の場合、Qwen 35BA3Bから27Bへの移行は約7〜8倍遅くなる(約9倍になるはず?)。これにより、無駄な思考トークンに対する忍耐力が大幅に低下する。これを、非常に簡潔で、まったく異なる思考方法(「待って」がない)を持つ新しいMuse 30Bモデルと比較したい。私の実験では、トークン効率がはるかに高く、絶対的なtok / sは実際には重要ではなかった。

この日のほかの記事

2026-08-17