正気を失いそうです。ここで3090にQwen 3.6 27Bを載せて、30〜100+ tok/s（100+は推測デコード込み）を出している人たちを見かけます。私はそれを再現しようとしていますが、私のパフォーマンス数値はそのレベルにまったく届きません。
llama.cppを、UnslothのQ4XLとQ4_K_MのGGUFで試しました。そこでの結果は、50kコンテキスト時にだいたい10 tok/sでした。さらに、この小さめのGGUFでik_llama.cppも試しました：https://huggingface.co/sokann/Qwen3.6-27B-GGUF-5.076bpw。これはUnlosthのGGUFより約1GB小さく、その組み合わせでは50kコンテキストで約18〜19 tok/s出ます。（編集：どちらのセットアップでも、VRAM上の設定はすべて同じです）
ik_llama.cppのログをClaude Sonnet 4.6に投げたら、こう言われました：
ログ内の2つの計算バッファを見てください：
CUDA0 compute buffer size = 2020.00 MiB ← GPU
CUDA_Host compute buffer size = 552.05 MiB ← CPU
graph splits = 2**`graph splits = 2` とは、生成された各トークンごとに必ずこうなることを意味します：**
**CPUへの同期** → CPUがSSMのリカレンス状態アップデートを計算（CPU側の作業が552 MiB）
**GPUへ同期** → GPUが完了
`CUDA_Host compute buffer` はデータ転送のための単なるメモリではありません。CPUがトークンごとの各ステップで実行する、実際の計算バッファです。SSM状態のリカレンス（`ssm_d_state = 128`、`ssm_d_inner = 6144`）は数学的に静的なCUDAグラフとしては表現できず、CPU側で逐次的に行う必要があります。
だからこそ `HAVE_FANCY_SIMD` が重要です。このトークンあたり552 MiBのCPU作業では、量子化解除カーネル（`iq4_ks`、`q6_0`）が使われますが、これはAVX-VNNI/AVX-512で飛躍的に速くなります。これがないと、ボトルネックはGPUではなくCPU側になります。
モデルは**重みの格納**という意味では「完全にGPU上」ですが、**生成時の計算**という意味ではそうではありません。これはQwen3.6のハイブリッドSSMアーキテクチャの根本的な性質で、どんなフラグや配置の工夫でも修正できません。
あなたは i9-9900K を使っていますね。これはCoffee Lake（2018）のCPUです。AVX2とFMAはサポートしていますが、AVX-512やAVX-VNNIはサポートしていません（それらはIce Lake / Alder Lake以降で登場しました）。なので、はい、確認済みです——あなたのCPUは構造的にHAVE_FANCY_SIMDパスを実行できません。
あなたが得ている18〜19 t/sは、このCPU + SSMハイブリッドモデルの組み合わせにおける現実的な上限です。
誰かこれが正確かどうか確認できますか？それとも私を騙（ガスライティング）しているだけですか？私がオンラインで見ている数値はすべてもっと高いです。あの人たちはより新しいCPUを使っているからでしょうか？
[link] [comments]
