フィールドレポート：M2 MacBook Pro（32GB）上のQwen 3.6 27B – 遅いが賢い出力

r/LocalLLaMAの開発者が、M2 MacBook Pro（32GB RAM）でQwen 3.6 27B（IQ4_XS unsloth量子化）をテストしました。予想通り、27Bの高密度モデルにはマシンのスペックが不足していますが、このフィールドレポートは具体的な数値とパフォーマンスおよび出力品質に関する現実的な評価を提供しています。

コマンドとセットアップ

モデルはllama-serverを使用して以下のコマンドで提供されました：

llama-server -m ~/models/unsloth/Qwen3.6-27B-IQ4_XS.gguf --mmproj ~/models/unsloth/Qwen3.6-27B-mmproj-BF16.gguf -c 131072 --batch-size 256 -ngl 99 -np 1 --host 127.0.0.1 --port 8899 -ctk q8_0 -ctv q8_0 --spec-type ngram-mod --spec-ngram-size-n 24 --draft-min 12 --draft-max 48

注目すべき選択：GPUへの過負荷を避けるためのシングルプロセス（-np 1）、ngram-modによる投機的デコード、コンテキストウィンドウ131072トークン。

パフォーマンスの内訳

初期速度：プロンプト処理80 t/s、トークン生成7.9 t/s。52,000トークンのコンテキストで、パフォーマンスはプロンプト処理4 t/sに低下（著者はタイポではないと確認）、トークン生成は3.1 t/sに。メモリプレッシャーがレッドゾーンに入ることはなく、ボトルネックがスワップではなくメモリ帯域幅であることを示しています。

投機的デコードは効果なし

レポーターはngram-mod投機的デコードを有効にしましたが、実質的なメリットは見られませんでした。ログには：

accept: low acceptance streak (3) – resetting ngram_mod ... draft acceptance rate = 1.00000 ( 2 accepted / 2 generated)

n-gramマッチの低さによりモデルが常にリセット。見かけ上の100%受入率は、小さなサンプルサイズによるアーティファクトです。著者は、このような高密度モデルはngram-modアプローチがうまく機能するほど繰り返しが多くないと結論付けています。

コード品質

速度の遅さにもかかわらず、Qwen 3.6 27Bが生成したコードは優れていると評価されました。追加のプロンプトなしで大規模なコードベースを分析し、品質面でQwen 35B A3B（MoE）モデルを上回りました。著者は出力を、セルフホストのClaude Sonnetに期待されるものと比較し、Claude Opus 4.7でさえ感銘を受けたと述べています。

主なポイント

• メモリ帯域幅が高密度モデルを左右する： Apple Siliconでは、コンテキストが増えるにつれてトークン生成が半減。スワップがなくても、帯域幅の制限がパフォーマンスを低下させた。
• シングルプロセスが最適： このハードウェアで同時エージェントタスクを実行してもメリットはなく、単に直列キューイングになるだけ。
• 投機的デコードはモデル依存： ここではngram-modは効果がなく、モデルの繰り返しの少なさがドラフトマッチを妨げた。

著者は、Qwen 3.6 27BをクラウドGPU（R9700と同等のスペック、現在Amazonで約1,400ドル、eBayではそれ以上）でテストし、自身のプログラミングタスクでの真の性能を評価する予定です。