Qwen3.6-27B: 270億denseモデルでフラッグシップ級のコーディング性能

 (qwen.ai)
7 ポイント 投稿者 GN⁺ 2026-04-23 | 4件のコメント | WhatsAppで共有
  • 270億パラメータのdenseマルチモーダルモデルとして公開され、単一の統合チェックポイントでthinking・non-thinkingモードと画像・動画処理をあわせてサポート
  • agentic coding性能が主要なコーディングベンチマーク全般で前世代のオープンソースフラッグシップQwen3.5-397B-A17Bを上回り、総パラメータ数が最大15倍大きいモデル群まで凌駕
  • SWE-bench Verified 77.2、SWE-bench Pro 53.5、Terminal-Bench 2.0 59.3、SkillsBench 48.2を記録し、GPQA Diamond 87.8、AIME26 94.1などテキスト推論やSTEM評価の数値も公開
  • denseアーキテクチャ採用によりMoEルーティングの複雑さがなく、デプロイが簡単で、open weights、API、Qwen Studioですぐ使える導線とOpenClaw・Qwen Code・Claude Code統合対応を提供
  • よく学習されたdenseモデルが開発者の中核作業で、はるかに大きい前世代を上回れることを示し、Qwen3.6系のagentic coding拡大にもつながる

概要

  • Qwen3.6-27Bは270億パラメータのdenseマルチモーダルモデルとして公開され、マルチモーダルthinkingモードとnon-thinkingモードの両方をサポート
  • agentic coding性能で、前世代のオープンソースフラッグシップであるQwen3.5-397B-A17Bを主要コーディングベンチマーク全般で上回る
  • MoEルーティングの複雑さがないdenseアーキテクチャの採用によりデプロイが簡単で、実用的かつ広く配備可能な規模で上位クラスのコーディング性能を提供
  • Qwen Studioですぐに利用可能で、コミュニティ向けopen weightsとAPIアクセス経路もあわせて提供
  • 中核特性としてフラッグシップ級のagentic coding、強いテキスト推論、マルチモーダル推論能力を含む

性能

  • Qwen3.6-27BはdenseおよびMoEの基準モデルに対する総合評価が提示されており、agentic codingベンチマークで大幅な向上を記録
  • 総パラメータ数が最大15倍大きいモデル群まで上回ったと明記
  • 評価項目は言語、知識、STEMおよび推論、ビジョン・ランゲージ、文書理解、動画理解、visual agentで構成

  • 言語

    • 270億パラメータだけで主要コーディングベンチマークすべてにおいてQwen3.5-397B-A17Bを上回る
      • SWE-bench Verified 77.2 対 76.2
      • SWE-bench Pro 53.5 対 50.9
      • Terminal-Bench 2.0 59.3 対 52.5
      • SkillsBench 48.2 対 30.0
    • 同規模の他のdenseモデルも大差で上回る
    • 推論課題ではGPQA Diamond 87.8点を記録し、自社モデルより数倍大きいモデル群と競争可能な数値
    • 詳細表にはQwen3.5-27B、Qwen3.5-397B-A17B、Gemma4-31B、Claude 4.5 Opus、Qwen3.6-35B-A3B、Qwen3.6-27Bの比較を含む
    • Coding Agent項目の主要数値
      • SWE-bench Multilingual 71.3
      • QwenWebBench 1487
      • NL2Repo 36.2
      • Claw-Eval Avg 72.4
      • Claw-Eval Pass^3 60.6
      • QwenClawBench 53.4
    • Knowledge項目の主要数値
      • MMLU-Pro 86.2
      • MMLU-Redux 93.5
      • SuperGPQA 66.0
      • C-Eval 91.4
    • STEMおよび推論項目の主要数値
      • HLE 24.0
      • LiveCodeBench v6 83.9
      • HMMT Feb 25 93.8
      • HMMT Nov 25 90.7
      • HMMT Feb 26 84.3
      • IMOAnswerBench 80.8
      • AIME26 94.1

  • 言語評価設定

    • SWE-Bench Seriesは内部agent scaffoldとbash、file-editツールを使用し、temp 1.0、top_p 0.95、200K context window基準
      • 公開SWE-bench Proセットの一部の問題タスクを修正したrefined benchmarkで、すべての基準モデルを評価
    • Terminal-Bench 2.0はHarborまたはTerminus-2 harnessを使用
      • 3時間timeout、32 CPU、48 GB RAM
      • temp 1.0、top_p 0.95、top_k 20、max_tokens 80K、256K ctx
      • 5回実行の平均
    • SkillsBenchはOpenCodeで78タスクを評価
      • API依存タスクを除外したself-contained subset
      • 5回実行の平均
    • NL2Repoの他モデル評価はClaude Codeを使用
      • temp 1.0、top_p 0.95、max_turns 900
    • QwenClawBenchは実ユーザー分布ベースのClaw agentベンチマーク
      • temp 0.6、256K ctx
    • QwenWebBenchは社内フロントエンドコード生成ベンチマーク
      • ENとCNのバイリンガル構成
      • Web Design、Web Apps、Games、SVG、Data Visualization、Animation、3Dの7カテゴリ
      • auto-renderとマルチモーダルjudgeでコードと視覚的一致性を評価
      • BTまたはElo rating systemを使用
    • AIME 26はAIME 2026 IとIIをすべて使用
      • スコアはQwen 3.5ノートと異なる可能性があると明記

  • ビジョン・ランゲージ

    • Qwen3.6-27Bは単一の統合チェックポイントでビジョン・ランゲージthinkingとnon-thinkingモードの両方をサポート
    • テキストに加えて画像および動画を処理可能
    • マルチモーダル推論、文書理解、視覚質問応答タスクをサポート
    • 比較表はQwen3.5-27B、Qwen3.5-397B-A17B、Gemma4-31B、Claude 4.5 Opus、Qwen3.6-35B-A3B、Qwen3.6-27Bを基準に提示

    • STEMおよびパズル

      • MMMU 82.9
      • MMMU-Pro 75.8
      • MathVista mini 87.4
      • DynaMath 85.6
      • VlmsAreBlind 97.0

    • 一般VQA

      • RealWorldQA 84.1
      • MMStar 81.4
      • MMBench EN-DEV-v1.1 92.3
      • SimpleVQA 56.1

    • 文書理解

      • CharXiv RQ 78.4
      • CC-OCR 81.2
      • OCRBench 89.4

    • 空間知能

      • ERQA 62.5
      • CountBench 97.8
      • RefCOCO avg 92.5
      • EmbSpatialBench 84.6
      • RefSpatialBench 70.0

    • 動画理解

      • VideoMME(w sub.) 87.7
      • VideoMMMU 84.4
      • MLVU 86.6
      • MVBench 75.5

    • Visual Agent

      • V* 94.7
      • AndroidWorld 70.3

    • 備考

      • 表の**空欄(--)**は、スコアがまだないか該当しないことを意味

Qwen3.6-27Bの活用

  • Alibaba Cloud Model Studio対応はまもなく提供予定と明記
  • Hugging FaceとModelScopeでopen weightsを提供し、self-hosting可能
  • Alibaba Cloud Model Studio API経由の利用経路と、Qwen Studioでの即時体験経路を提供
  • OpenClaw、Claude Code、Qwen Codeのようなサードパーティ製コーディング補助ツールとの統合をサポート
  • 開発ワークフローの簡素化とcontext-aware coding experience対応に言及

  • API利用

    • 今回のリリースは**preserve_thinking機能**をサポート
    • メッセージ内のすべての過去ターンで生成されたthinkingコンテンツを保持する機能で、agentic taskに推奨と明記

  • Alibaba Cloud Model Studio

    • OpenAI仕様と互換性のあるchat completionsおよびresponses APIをサポート
    • Anthropic互換APIインターフェースもあわせてサポート
    • 公式ドキュメント基準の環境変数例を提供
      • DASHSCOPE_API_KEY
      • DASHSCOPE_BASE_URL
      • DASHSCOPE_MODEL
    • Base URLの地域別例も提示
    • サンプルコードではデフォルトモデル名として**qwen3.6-27b**を使用
    • extra_bodyにenable_thinking: Trueを含む
      • preserve_thinking: Trueはコメント形式で表示
    • ストリーミング応答でreasoning_contentとanswer contentを分けて収集する例を含む
    • 追加情報はAPI docリンクを参照するよう案内

  • Coding & Agents

    • Qwen3.6-27Bはagentic coding能力を備え、OpenClaw、Claude Code、Qwen Codeとシームレスに統合可能

    • OpenClaw

      • OpenClawはself-hostedのオープンソースAI coding agentで、旧称はMoltbotまたはClawdbot
      • Model Studioと接続して、ターミナルで完全なagentic coding体験を提供
      • スタートスクリプトにはNode.js 22+、インストールスクリプト実行、DASHSCOPE_API_KEY設定、openclaw dashboardまたはopenclaw tui実行手順を含む
      • 初回利用時は~/.openclaw/openclaw.jsonの修正が必要
        • ファイル全体の上書き禁止を明記
        • 既存設定を保持するため必要なフィールドだけをマージ
      • 設定例にはmodelstudio providerとqwen3.6-27bモデル登録を含む
        • apiはopenai-completions
        • reasoning値はtrue
        • 入力タイプはtext、image
        • contextWindowは131072
        • maxTokensは16384
        • デフォルトprimaryモデルはmodelstudio/qwen3.6-27b

    • Qwen Code

      • Qwen Codeはターミナル向けオープンソースAI agentで、Qwen Series向けに深く最適化されたツール
      • スタートスクリプトにはNode.js 20+、@qwen-code/qwen-code@latestのインストール、qwen実行手順を含む
      • セッション内で/help、/authコマンドを使う例を提供
      • 初回利用時にはログインプロンプトが表示され、/authで認証方式を切り替え可能

    • Claude Code

      • Qwen APIsはAnthropic API protocolもサポート
      • Claude Codeのようなツールと併用できると明記
      • 設定例には次の環境変数を含む
      • 実行コマンドはclaude

まとめ

  • よく学習されたdenseモデルが、開発者にとって重要な課題で、はるかに大きい前世代を上回れることをQwen3.6-27Bが実証
  • 270億パラメータ規模でありながらQwen3.5-397B-A17Bを主要agentic codingベンチマークすべてで上回る
  • デプロイとサービスが簡単な構造で、Qwen3.6オープンソース系はQwen3.6-27Bの追加により、より幅広いモデル構成を持つようになった

関連記事

4件のコメント

 
kaydash 2026-04-23

せめてA3Bくらいでないと、ローカルでは少し回せる程度ですね（笑）
 
kirinonakar 2026-04-23

ベンチマークは良いと言われていますが、実運用ではまだコーディングエージェントとして使えるレベルではないように見えます。
 
b89kim 2026-04-26

使ってみましたが、エージェント型コーディングに大きな問題はありません。 ただし、おっしゃる通り、実運用＋一般的なコーディングでは、よりパラメータ数の大きいモデルに比べると劣るのは避けられません。 設定値が3.5とは異なり、preserve_thinkingモードも追加されているので、参考にしてください。 27Bの4bit量子化程度であれば、ローカルで使うのにも問題ありませんでした。
 
GN⁺ 2026-04-23
Hacker News のコメント
  • 私の基準では、16.8GB に量子化したローカルモデルとしては pelican の結果が本当に素晴らしかった。https://simonwillison.net/2026/Apr/22/qwen36-27b/ にまとめてあるが、M5 Pro 128GB RAM で動かしたものの、実際に必要なメモリは約 20GB 程度なので、32GB マシンでも無理なく動く気がする。読み取りは 20 トークンを 0.4 秒で処理して 54.32 tokens/s、生成は 4,444 トークンを 2 分 53 秒で生成して 25.57 tokens/s だった。数日前に Opus 4.7 で作った pelican より、今回の結果のほうが気に入った。https://simonwillison.net/2026/Apr/16/qwen-beats-opus/
    • 今回のものは出来が良すぎて、むしろ 学習データ に入っていたのではないかという気もする。ほかのテストも回して差がどう出るか見てみたい
    • そのうちモデル提供元が、Simon の影響力ある pelican riding a bicycle テストに合わせて最適化し始める時期が来るのでは、という半分冗談みたいなことを考えてしまう
    • Qwen Flamingo についている 蝶ネクタイ も本当に絶妙だと感じる
    • 記憶している限り、pelican テストについてここまで excellent という表現を使うのはほとんど聞いたことがないが、今回は本当にそう言うに値するように見える。しばらくは MoE に流れが向いていたのに、今回はまた dense モデルが注目されているのも興味深い。非公開モデルも、高速ラインは MoE、pro ラインは dense という方向なのか気になる
    • もうこのあたりで LLM も、自転車のフレームが実質的には半分に分かれた ひし形 だと把握していそうだと思う → ◿◸。これを言ってしまったことでテストを壊していないといいが
  • Gemma 4 がこの前の Easter ごろに出て以降、self hosting モデルと Claude の差はかなり縮まったと感じている。もちろん差はまだ大きいが、それ以前のローカルモデルがあまりに競争力がなかったので、今は状況がずっと良くなった。そして Qwen 3.6 が Gemma 4 よりさらに一段上だとしたら、かなり胸が躍る。それでもローカルモデルは、いまだに妙な方向へ逸れたり失敗したりすることがあるので、Opus はいつも手元に置いている。それでもローカルモデルがときどき本当に役立ってくれるたびに、コーディングはやはり 自由であるべきだ という感覚に近づく。無料という意味でもあり、自由という意味でもある。私のセットアップは RTX 5090 を積んだ別の Ubuntu マシンで、いまこの瞬間 Qwen 3.6 27B は VRAM 32GB のうち 29GB を使っている。Ollama は root ではない podman インスタンスで動かし、エディタには OpenCode を ACP Service としてつないで使っているが、強くおすすめする。ACP は Agent Client Protocol のことで、私としては世界はこの方向に進むべきだと思う。そして Qwen チームが、Sam Altman だらけの世界の中で少しでも世の中を良くしてくれていることに感謝している
    • 私が M5 MBP でローカル実行したモデルの中では、Gemma4 がいちばん Claude に近い感じだった
    • 私も free と local という理想には共感するが、結局重要なのは 持続可能な競争 だと思う。月 200 ドルのコストをはるかに低い水準まで引き下げる圧力が生まれるだけでも十分うれしい
    • 27B モデルが実際にどの程度の プログラミング作業 までこなせるのか気になる。Claude ですら物足りないことがあるのに、27B がどれほど実戦的なのかは想像しづらい
    • RTX 5090 では tokens/s がどのくらい出るのか気になる
  • モデルを発表するたびに、今すぐどんな consumer hardware で動くのか、コストはいくらか、tok/s はどのくらいかを一緒に示してほしい
    • 彼らが直接配布した 27B モデルを 16-bit でネイティブ実行するには、かなりのハードウェア が必要になる。Mac や Strix Halo 128GB システム、大容量の民生 GPU を複数枚、あるいは RTX 6000 クラスのワークステーションカードが必要だ。だから、どんな consumer hardware で動くかを積極的に宣伝しないのだと思う。そうした結果を出す元のリリースは、一般的な民生システムには収まりにくいからだ。ほとんどの人は元モデルではなく、より少ないビット数の量子化版を動かす。ただし量子化には明確なトレードオフがあり、宣伝された結果とまったく同じ品質を期待するのは難しい。以前の Qwen3.5 27B は、どこまで品質低下を許容するか次第で Q5 や Q4 まではかなり実用的で、統合メモリシステムでは追加で 32GB RAM が必要だったので、だいたい 64GB Mac くらいが妥当だった。NVIDIA 5090 32GB や 16GB または 24GB の GPU 2 枚でも可能だったが、分散のため速度はより遅かった。iPhone やもっと小さいシステムで動かしたという主張は慎重に見たほうがいいと思う。極端な量子化やさまざまな工夫で起動自体はできても、出力品質が実用にならないことが多い。SNS での見栄え目的で、小さなハードウェアで動いたというリポジトリが時々上がってくるが、実際の結果はあまり良くないことが多い
    • 私は M4 32GB RAM で ~5 tokens/s くらい出た。unsloth/Qwen3.6-27B-GGUF:Q4_K_M を llama-server で動かし、35B-A3B モデルは約 25 t/s だった。比較すると、A100 ではそれぞれ 41 t/s と 97 t/s くらいだった。27B はまだ長く試していないが、35B-A3B はコンテキストが 15k〜20k トークンを超えるとよく脱線した。基本的な作業は安定してさせられるが、これを frontier モデル並みだと見るのは難しい
    • ローカル LLM を動かせる CPU/GPU の組み合わせ は事実上無限にあるので、多くの場合は予算と目的に合うシステムを選んでから、モデルサイズと量子化を見て VRAM 使用量をざっくり見積もる形になる。もっと詳しい分析が必要ならオンラインの VRAM 計算機を使えばよく、たとえば https://smcleod.net/vram-estimator/ がある。huggingface アカウントがあればシステム構成を入れて、各 quant の横に適合しそうかを色で確認することもできる。そして t/s はコンテキストサイズを含め変数に大きく左右されるので、せいぜい推定値しか出せない。今のローカル LLM は文字どおりあらゆる点に トレードオフ があって、作業ごとに何を最適化するかを選び続ける状況だ
    • Qwen3.5-27B は 4bit quant 基準なら 24GB カードで無理なく動く。私は Nvidia L4 を 2 枚といくつかの vllm フラグを使って、開発者 10 人に 20〜25 tok/s で提供しており、空いている時は 40 tok/s くらいまで出る。開発者たちはこの性能でも満足しているが、スループットをさらに増やしたくて GPU の追加を求めてはいた
    • 私は RTX 4090D で 30 t/s ほど出ていて、VRAM は 48GB のうち 42GB を使っている。量子化は UD-Q6_K_XL で、関連する議論は https://huggingface.co/unsloth/Qwen3.6-27B-GGUF/discussions/7 にある
  • Qwen や Minimax のようなところが、OpenAI や Anthropic より少し劣るとはいえ似たようなベンチマーク結果を出す オープンソースモデル を公開しているのに、OpenAI や Anthropic の今の競争優位が正確には何なのか気になる。しかも、こうしたオープンモデルのトークン価格は Anthropic Opus 4.6 の一部にすぎない。https://artificialanalysis.ai/models/#pricing
    • コーディングでは最後の数パーセントの 品質差 が、プレミアムを払うに値するほど重要だと思う。大量のスパムメールや HN コメントを量産する仕事とは違う。平均的なエンジニアと P99 エンジニアの報酬差が大きい理由もそこにあると思う。また frontier 企業が現時点で高い R&D コストを負担しながらも競争力を保っているのは、より良い製品とより多い付加価値を生み出すよう強いられるという点で、長期的には利益がある。特に Anthropic は、より 信頼できる供給者 という立ち位置を狙っているように見える。Ali ですら有料 frontier モデルをホストしているが、中国企業でもない限り、本番コード開発のワークロードを中国ホスティング事業者に載せるだろうかという疑問がある。OpenAI にも気になる点はあるが、それでも営業秘密を丸ごと持っていかれるとは比較的疑いにくい。Anthropic はそれより少し信頼している。だからプレミアムが付くのだと思う。中国のホスティング企業が、使える競争優位を総動員し、政府や他企業と共有しうるという歴史的前例があまりに強いので、人々はそのリスクを価格に織り込んでいるのだと思う
    • 私は Opus と Qwen の両方を使っているが、実際の体感では両者の 差 はベンチマークのチャートよりずっと大きい。ホスト型モデルと比べるなら、今は GLM を見るほうが適切だと思う。大手プレイヤーに最も近い位置にいて、以前は非常に安かったが、最近は価格を上げ始めている
    • もしこうした結果が vampire attacks のせいなら、非公開モデルが答えを吸い上げる経路を汚染する方法を覚えた瞬間、性能は今ほど良くないかもしれない。そして日常的なワークフローで使ってみると、そこまで同格ではない。浅い推論は悪くないかもしれないが、コーディングやもっと難しい作業では依然として差が大きい。少なくとも私が使ったオープンモデルの中では、非公開モデルと同じくらい良いものはまだ見つかっていない。もし良い設定があるなら共有してほしい
    • 今この瞬間には 競争優位 はないと思う。ただ、どこかのエコシステムが統合され始めたら、その時点から優位が生まれる気がする
    • Opus の高い トークン価格 は、むしろ人々がそれだけ優れたモデルに喜んでお金を払う証拠だと思う。新しい OpenAI と Anthropic のモデルは、オープンソースより目に見えて優れている。オープンソースが使い物にならないわけではないが、frontier のほうが明らかに良く、当面はそうあり続ける可能性が高い。SWE の時間が 1 分あたり 1 ドルを超えるなら、1 回の会話に 10 ドルかかっても 10 分節約できれば十分元が取れる。特にコード作業では、微妙な品質向上が節約時間に大きくつながるという判断だ
  • 私は M4 MBP で Qwen 3.6 35B と Gemma 4 26B を使っているが、Opus 級ではないにせよ、自分に必要な仕事の 95% はこなしてくれており、それがすべて完全ローカルで動いているというだけで、すでに驚くべきことだ
    • どんな種類の 作業 をしていて、Qwen や Gemma をどんなハーネスやアプローチでつないで使っているのか気になる。つまり、ワークフローやソフトウェアスタックがどういうものか知りたい
    • 今では十分使えるので、Codex が自分の仕事を自ら減らすように、より多くの作業をこのローカルモデルに 委任 するようになった。そして私の M4 では dense 27B より 122B 版のほうがスループットがずっと良いので、そちらにもかなり期待している
    • これを Ollama で使っているのか、それとも別のものなのか気になる
    • 95% という表現が正確にどういう意味なのか、もう少し聞きたい。私が知りたいのは 2 点ある。第一に、出力品質の基準で Opus 4.5 や 4.6 の 精度 の 95% 程度という意味なのか。第二に、ツール呼び出しや agentic な作業、たとえば旅行計画のような仕事で、Opus 比で 95% 程度の遂行力という意味なのかが気になる
  • 私はローカル LLM にまだ慣れておらず、昨日 Qwen3.6-35B-A3B モデルをいくつかセットアップして試すのに時間を使った。mlx 4b と 8b、gguf Q4_K_M と Q4_K_XL あたりだったと思う。64GB の M4 で動く様子はかなり印象的だった。ただ、この新しいモデルは TFA の表を見ると少しだけ 賢く 見える代わりに VRAM をより食うようで、核心的な違いは dense であることなのか気になる。そして 27B は 35B より小さいのだから、近いうちに VRAM 要求をもっと下げる量子化モデルも出てくるのではと期待している
    • 核心は単純なパラメータ数の比較ではない。35B-A3B は Mixture of Experts モデルで、一度に有効化されるパラメータはおよそ 3B 程度しかない。だから実際の計算要求は 35B ではなく、この 3B に近いスケールになる。もちろん全 35B レイヤーに対する高帯域アクセスは依然として必要だ。一方で今回のモデルは dense モデルなので、Mac でははるかに遅い可能性が高い。たとえば私の M4 Pro では Q6 gguf 基準で約 9 tok/s で、35-A3B は Q4 に mlx なので公正な比較ではないが、約 70 tok/s だった。一般にこうした dense モデルは専用 GPU でよりうまく動き、VRAM が十分あってモデル全体を常駐させられるなら判断は簡単になる。このモデルはだいたい 24GB VRAM 以上あれば大丈夫そうで、NVIDIA 3090 や 4090、5090 系なら問題ないだろうという見立てだ
  • llama server で Q4_K_M を使って動かすと、24GB 基準で 91k context くらいになり、計算すると KV-Cache はコンテキスト 1K あたり約 70MB になる。Q5 にしていたら、おそらく 30K トークンくらいの余地が残ったはずで、これはかなり印象的だと思う
  • 私は SVG で自転車に乗る pelican を生成してみた。結果は https://codepen.io/chdskndyq11546/pen/yyaWGJx 。さらに、車を運転しながらホットドッグを食べるドラゴンも作ってみた。結果は https://codepen.io/chdskndyq11546/pen/xbENmgK 。完璧ではないが、こうした結果だけでもモデルがどれほど強力になったかがよく表れていると感じる
    • ドラゴン画像には一つ目や変な尻尾のような問題があるが、pelican のほうは私が見た中で 最高 と感じるほど、ほとんど完璧だった
    • これがあまりにも有名な benchmark になってしまったので、モデルがすでにこのテスト向けに学習されているのではないかと気になる
  • これまでのローカル推論の経験だけを見ると、まだそこまで感動的ではなかった。M5 Pro 128GB RAM で omlx だと 11 tokens/s ほどで、結局数百行の動かないコードを書くのに 1 時間かかった。同じ作業を Opus と Sonnet は CC で数分で成功裏に終えた。昨日 Ollama で動かした 3.6 35b モデルはそこそこ良さそうだった。Claude Code 以外の ハーネス も試してみるつもりだが、今のローカルモデルは遅すぎるというのが実感だ
    • これは dense model なので、Mac で遅いのは自然だ。Mac なら、Qwen3.6 の Mixture of Experts リリースである Qwen3.6-35B-A3B を試すといい。私の M4 Pro では約 70 tok/s 出た。もしこれよりずっと遅いなら、誤って GGUF フォーマットを使っている可能性がある。Mac では Apple 専用フォーマットの MLX のほうが速いことが多い
    • 私は M2 Max MacBook で MLX 8-bit quant 版を使って、生成速度 7 tokens/sec くらいだった
    • OpenCode は Claude よりローカルモデル活用を よりうまくやる ように感じた
  • M4 Pro に RAM 48GB があるとき、何を動かせるのか気になる