私はエージェント的なコーディング作業のため、Blackwell RTX PRO 4000（24GB）で Qwen 3.5 27B Q4_K_M を動かしてきましたが、メインライン llama.cpp で壁にぶつかりました。今日は ik_llama.cpp フォークに切り替えたところ、差は圧倒的です。役に立つかもしれないので、実数を公開します。
ハードウェア Lenovo ThinkStation P520、Xeon W-2295 18コア、128GB DDR4 ECC NVIDIA RTX PRO 4000 Blackwell 24GB GDDR7 コンテキスト: 131,072 トークン、KV キャッシュ q8_0/q4_0
ベンチマーク結果
指標 メインライン b8457 ik_llama.cpp b4370 プロンプト評価 ~43 トークン/秒 1,122 トークン/秒（26倍） 生成 ~7.5 トークン/秒 26 トークン/秒（3.5倍） グラフ分割 34 2 推論中の CPU すべてのスレッドがピーク アイドル GPU プロンプト処理 部分的 100% GPU
違いの理由
Qwen 3.5 はゲート付きデルタネット（GDN）と Mamba風SSM アーキテクチャを標準のアテンションと組み合わせたハイブリッドな構造を採用しています。メインライン llama.cpp はこれを 34 のグラフノードに分割しており、CPU の関与が大きかった。ik_llama.cpp は全計算を CUDA 上で処理する結合 GDN カーネルを実装しており、グラフ分割を 34 から 2 に削減しています。
ik_llama.cpp を起動すると次のように表示されます:
結合済みゲーテッド・デルタネット（自己回帰）を有効化 結合済みゲーテッド・デルタネット（チャンク化）を有効化 グラフ分割 = 2
これが差の鍵です。モデルのウェイトは変わっていません。サーバーが変わりました。
完全な再処理バグ
Qwen 3.5 の再発現アーキテクチャは、プロンプトが変わるたびに（llama.cpp の issue #20225 で追跡）各ターンで完全なプロンプト再処理を強制します。1,122 tok/秒ではこれを許容できます — 以前は数分かかっていた処理が今は数秒に短縮されます。ただし、まだ各ターンで発生します。留意してください。
入手先
AVX512 VNNI を搭載した Windows 用 CUDA 12.8 のプリビルトバイナリは Thireus フォークから入手可能です:
https://github.com/Thireus/ik_llama.cpp/releases
既存の llama-server フォルダのドロップイン置換です。同じコマンドライン引数、ポート 1234 での同じ OpenAI 互換 API。
W-2295（AVX512 VNNI）の場合: ik_llama-main-b4370-4d7223c-bin-win-cuda-12.8-x64-avx512_vnni.zip
結論
メインライン llama.cpp で Qwen 3.5 を動かしていて遅い理由を知りたいなら、これが理由です。ik_llama.cpp の結合 GDN カーネルはまだメインラインには入りません。フォークを試してみてください。
セットアップやベンチマークの方法論に関する質問には喜んでお答えします。
[リンク] [コメント]
