- AlibabaのQwen3.5モデル群は、0.8Bから397Bまで多様なサイズを提供し、マルチモーダル・ハイブリッド推論機能と256Kコンテキストをサポート
- UnslothはすべてのQwen3.5モデルをDynamic 2.0 GGUF量子化で提供しており、llama.cppまたはLM Studioを通じてローカルで実行可能
- thinkingモードとnon-thinkingモードを切り替え可能で、小型モデル（0.8B〜9B）はデフォルトでnon-thinkingモードに設定
- 各モデルごとに必要なRAM/VRAM容量と推奨設定値（temperature、top_p など）が明記されており、Mac 22GB環境でも27B・35Bモデルを実行可能
- Unsloth GGUFは改良された量子化アルゴリズムとimatrixデータを適用して性能を改善しており、Ollamaとは非互換
Qwen3.5 概要
- Qwen3.5はAlibabaが公開した新しいLLMシリーズで、0.8B・2B・4B・9B（小型）から27B・35B・122B・397B（大型）までを含む
- マルチモーダル・ハイブリッド推論をサポートし、201言語と256Kコンテキスト長を処理
- エージェントコーディング、ビジョン、対話、長文コンテキスト作業で高い性能を示す
- 35Bと27Bモデルは22GB RAM環境のMacでも実行可能
- すべてのGGUFファイルは改良された量子化アルゴリズムと新しいimatrixデータを使用
- チャット、コーディング、長文コンテキスト、ツール呼び出し（tool-calling）で性能向上
- MXFP4レイヤーは一部のGGUF（Q2_K_XL、Q3_K_XL、Q4_K_XL）で削除
ハードウェア要件
- 表によると、モデルサイズごとの最小メモリ要件が明記されている
- 例: 0.8B〜2Bモデルは3GB、9Bは5.5GB（3-bit基準）、35B-A3Bは17GBが必要
- 397B-A17Bは3-bit基準で180GB、4-bit基準で214GBが必要
- **総メモリ（RAM+VRAM）**がモデルファイルサイズより大きい必要があり、最適な性能を確保
- 不足する場合でもSSD/HDDオフロードで実行可能だが、速度低下が発生
- 27Bは精度優先、35B-A3Bは速度優先の選択肢
推奨設定値
- 最大コンテキストウィンドウ: 262,144（YaRNで1Mまで拡張可能）
- presence_penalty: 0.0〜2.0（反復低減用で、高いほど性能がやや低下する可能性あり）
- 出力長: 32,768トークン推奨
- ThinkingモードとNon-thinkingモードで設定値が異なる
- Thinkingモード: 一般作業はtemperature=1.0、コーディングは0.6
- Non-thinkingモード: 一般作業はtemperature=0.7、推論作業は1.0
- **小型モデル（0.8B〜9B）**はデフォルトでreasoning無効
- 有効化時は
--chat-template-kwargs '{"enable_thinking":true}' を使用
実行と推論チュートリアル
- すべてのモデルはDynamic 4-bit MXFP4_MOE GGUF版で提供
- llama.cppを用いたローカル推論手順
- GitHubから最新バージョンをインストール後、
-DGGML_CUDA オプションでGPU/CPUを選択
- Hugging Faceからモデルをダウンロード（
hf download unsloth/Qwen3.5-XXB-GGUF）
llama-cli または llama-server コマンドで実行
- LM Studioでも実行可能
- モデル検索後にGGUFをダウンロードし、YAMLファイルでThinkingトグルを有効化
- 再起動後にトグル機能を使用可能
モデル別実行サマリー
- Qwen3.5-35B-A3B: 24GB RAM/MacでDynamic 4-bitによる高速推論が可能
- Qwen3.5-27B: 18GB RAM/Macで実行可能
- Qwen3.5-122B-A10B: 70GB RAM/Mac環境で動作
- Qwen3.5-397B-A17B:
- 3-bit: 192GB RAM、4-bit: 256GB RAMが必要
- 24GB GPU + 256GB RAMの組み合わせで毎秒25トークン以上を生成
- Gemini 3 Pro、Claude Opus 4.5、GPT-5.2に近い性能クラス
推論サーバーとAPI連携
llama-server を通じてOpenAI互換APIの形でデプロイ可能
- Tool Calling機能をサポート
- Pythonコード実行、ターミナルコマンド、数式演算などの関数呼び出しが可能
unsloth_inference() のサンプルコードを提供
ベンチマーク結果
- Unsloth GGUFベンチマーク
- Qwen3.5-35B Dynamic quantは大半のビット帯域でSOTA性能
- 150回以上のKL Divergenceテスト、合計9TBのGGUFデータを使用
- 99.9% KLDでPareto Frontier上の最高性能
- Qwen3.5-397B-A17B
- Benjamin Marieの第三者テストでは
- 原本 81.3%、UD-Q4_K_XL 80.5%、UD-Q3_K_XL 80.7%
- 精度低下は1ポイント未満で、メモリ削減は約500GB
- Q3はメモリ節約型、Q4は安定型の選択肢として提示
その他の機能
- Reasoning有効/無効コマンドを提供（
--chat-template-kwargs）
- Claude Code / OpenAI Codexと連携可能
- Tool Calling Guideを通じてローカルLLMのツール呼び出し構成が可能
- Ollama非互換、llama.cppベースのバックエンドのみ対応
2件のコメント
HX370で27Bを使っていますが、結果はかなり良好です
Hacker Newsのコメント
ASUS 5070ti 16GでQwen3.5 9Bをlm studioで動かしてみたところ、約100 tok/sで非常に安定して動作した。
ほとんどのオンラインLLMサービスより速く、出力品質もベンチマーク水準と一致している。
コンシューマー向けハードウェアでここまで実用可能なモデルを動かしたのは初めてだ。
SonnetやOpusのような上位モデルとの実用性比較ではないと思う。
コーディング作業には最低100k contextが必要だ。
私は無限ループにはまって無効にしたし、いろいろなパラメータを変えても解決しなかった。
品質は2025年夏のSonnet 4.0レベルで、ik_llama.cppでは速度も非常に良い。
オーケストレーションがかなり重要そうだ。
「All uploads use Unsloth Dynamic 2.0」とあるが、実際のオプションにはIQ4_XS、Q4_K_S、Q4_K_Mなどいろいろある。
それぞれのトレードオフの説明がないので混乱する。
Mac mini M4 16GBでQwen3-4B-Instruct-2507-Q4_K_Mを主に使っているが、Qwen3.5-4B-UD-Q4_K_XLはずっとおしゃべりだ。
人それぞれ必要は違うだろうが、モデル/ハードウェア別の設定とメモリ使用量を整理した表があるとよい。
Redditでも具体的な設定例はほとんどない。
この3か月ずっとこの話題を追っているが、明確な情報より混乱のほうが多い。
今はqwen CLIのcoder-modelをクラウドで使い、低消費電力のローカルモデルが出るのを待っている。
Q4_K_XLとQ4_K_Mのディスク容量あたりのKL Divergence比較がある。
Q4_0、Q4_1は速度は速いが精度が落ちるので、今ではおすすめされない。
Q4_K_MとUD-Q4_K_XLはほぼ同じで、_XLのほうが少し大きい。
ただし、まだQwen3.5関連のデータはない。
Rustコードを扱っているのが原因かもしれない。
6bit量子化したqwen3.5-35b-a3bを4090で動かしたときはかなり良い結果だった。
今は8bit qwen3.5-27bをメインエンジンとして使っていて満足している。
新しいオープンモデルが出るたびに、PP（プロンプト処理）とTG（トークン生成）速度をllama-cpp/serverでテストしている。
M1 Max 64GB MacBookでClaude Code環境（15〜30K context）として実験した。
Qwen3.5-30B-A3BはQwen3-30B-A3BよりTG速度が半分程度だ。
Qwen3.5はsliding window attentionのおかげでRAM使用量が少なく、応答品質は良いが、33k contextでは速度が遅い。
詳細設定はこの文書に整理されている。
個人ベンチマークではDeepSeek APIを基準にClaude Opusで評価した。
Qwen3.5 35B A3B(q8_0, thinking)は92.5%、Q4_K_M(thinking)は90%程度だった。
27B denseモデルのほうが高いと思っていたので意外だった。
ただし、この数値はone-shot応答評価なので、エージェント反復の状況は反映していない。
プロンプトの論理的不整合が27Bの推論を妨げた可能性もある。
thinking traceを見ると原因をデバッグできそうだ。
Qwen3.5 9BをCPUでOCRとテキスト整形用に動かしてみたが、かなり実用的だった。
ただしGPUオフロードがうまく動かず、VRAM 4GBの1650 Tiではメモリ不足になった。
sudo apt install nvidia-driver-570コマンドで対応できた。35Bモデルが4Bモデルと同程度の速度で動作しつつ、はるかに強力だ。
ただしqwen3.5はqwen3より速度が半分程度だ。
それでも全体的には満足している。
Qwen3.5:0.8bをOrangepi Zero 2wでCPUのみで問題なく動かしている。
Vulkan GPUを使いたいときは、Meta Quest 3でqwen3.5:2bをzeroclawから実行している。
そのおかげで低消費電力環境で数百ドル節約できた。
中古のAndroidスマホでローカルモデルを動かしてみるのをおすすめする。
9Bモデルをホスティング提供しているところがあるのか気になる。
GPUレンタルが難しいビジネス環境なので、OpenRouterには小さいモデルがない。
runpod serverlessテンプレートができるとよい。
9Bモデルが4090で8bitや6bitの低レイテンシ実行が可能なのかも知りたい。
RTX 3050 8GBでQwen3.5 35B-A3Bを動かしてみたが、かなり応答性が良く、コーディング作業もよくこなした。
以前のバージョンにはツール使用中にループに陥る問題があったが、新しいバージョンで修正されたようだ。
tok/sの数値も知りたい。
RTX 3060ノートでもローカルサーバーとして十分いけそうだ。
ローカルモデルがそこまでできるとは思わなかった。
397B-A17BモデルがFrontierと比べてどうなのか気になる。
おそらく大半の人には動かせないレベルのハードウェアが必要だろう。
個人的には122Bモデルでプライバシーとコスト削減の面から十分満足している。
古い4xV100 Teslaサーバーでこのモデルが動くのか気になる。
fp関連の設定が複雑で、初心者には理解しづらい。