話題の中心はモデルカードではなく実行条件

r/LocalLLaMAのQwen 3.6投稿が読まれたのは、公式benchmarkの焼き直しではなく、手元で動かしたfield reportに見えたからだ。投稿者は、通常ならOpusやCodexに任せるworkloadをQwen 3.6で試し、同じ水準ではないが実用の壁は越えたと書いた。環境も具体的だった。M5 Max 128GB、8bit、3K PP、100 TG、oMLX、Pi.devという条件が添えられていた。

一番実用的だったのは設定の注意だ。投稿者はpreserve_thinkingを必ず有効にするよう促した。LocalLLaMAでこうした投稿が伸びる理由はここにある。local LLMではweightsだけでは結果が決まらない。quantization、runtime、context handling、prompt format、memory pressure、小さなflagの違いで、同じモデルがかなり違って感じられる。

コメント欄には期待と疑いが同時に出ていた。Qwenは中規模モデルで前世代のflagshipに迫る体感を何度も出してくる、という反応があった。一方で、122B級より良いという読み方には慎重な声もあった。これは重要なバランスだ。このスレッドは正式な評価ではなく、投稿者自身の作業に基づく報告であり、過度な一般化はできない。

それでもこの投稿は、local LLMの関心がどこへ移っているかをよく示している。ユーザーは小型・中型モデルが会話できるかだけを見ていない。codingやagent workflowに入れて、十分速く返し、reasoningの状態を保ち、作業を壊さずに続けられるかを見ている。その文脈では、ひとつの設定項目もニュースになる。

今回の要点は限定的だ。Qwen 3.6は一部のlocal agentやcoding補助で有力な選択肢になり得る。ただし、その体感は正しい設定と実行スタックに強く依存する。

Source: r/LocalLLaMA discussion.

#configuration

LocalLLaMAのQwen 3.6熱、焦点は性能より設定