Qwen 3.6が昨日リリースされたので、このハードウェアでハイブリッド・オフロードが本当に効果を発揮しているのか確かめたくなりました。私の環境はRTX 5060 Tiが2枚（合計32GB VRAM）で、システムRAMは64GBです。ワークステーション向けのカードは一切ありません。
比較のために、同じベンチ用ハーネスを3つの構成で連続して実行しました。MoEについてはghcr.io/ggml-org/llama.cpp:server-cuda13、密（dense）については当社TurboQuantビルドを使用しています。逐次：10イテレーション、最大トークン数128、ウォームアップ2回。ストレス：同時4ワーカー、最大トークン数256、5分。プロンプトは全て同じです。
MoEのフラグ：
--cpu-moe --no-kv-offload --cache-type-k q8_0 --cache-type-v q8_0 --ctx-size 90112 --flash-attn on --n-gpu-layers 99 --split-mode layer --tensor-split 1,1
結果：
| モデル / 設定 | 生成 | P50レイテンシ | ストレス（同時4） |
|---|---|---|---|
| Qwen 3.5-27B dense（GPUフル、TurboQuant KV） | 18.3 tok/s | 7,196 ms | 10.4 tok/s、52 req/5min |
| Qwen 3-Coder-30B-A3B（--cpu-moe ハイブリッド） | 31.1 tok/s | 2,286 ms | 12.0 tok/s、113 req/5min |
| Qwen 3.6-35B-A3B（--cpu-moe ハイブリッド） | 21.7 tok/s | 6,160 ms | 6.8 tok/s、38 req/5min |
いくつか、予想外だったことがあります。
denseの3.5からCoderのハイブリッドへの切り替えは、MoEモデルならほぼコストゼロで性能が上がります。同じ2枚のGPUで生成が70%高速化し、P50レイテンシは3分の1になりました。ハイブリッド・オフロードが机上では有用だというのはずっと知っていましたが、生の数値を横に並べて見ると、もっと早く試せばよかったと思いました。
Qwen 3.6はCoder版より遅いです。どちらも「アクティブな」部分は3Bですが、総パラメータが追加で5Bある分、トークンあたりの専門家（エキスパート）重みトラフィックがシステムRAM経由で増えます。とはいえ品質差ははっきりしています。SWE-bench Verifiedで73.4%対50.3%、さらにTerminal-Bench 2.0で+11ポイントです。エージェント的、またはマルチステップの用途なら3.6を使っています。高速なコード補完ならCoderのほうがまだ手堅いです。
denseはプロンプト処理で大きく勝ちます。毎秒160トークンに対し、ハイブリッド実行では30〜95です。長いコンテキストのRAGや、重いプロンプト取り込みを使っている限り、それは消えません。ハイブリッドが生成速度で先行するのは、PCIe往復が「アクティブな専門家」分だけで済むからです。
さらに攻めてみました。--cpu-moeと当社のTurboQuantのKVキャッシュビルド（tbqp3/tbq3）を組み合わせ、はるかに小さいKVフットプリントで131Kコンテキストまで到達させようとしました。ウォームアップでクラッシュし、終了コード139。スタックはTurboQuantフォーク内のfused Gated Delta Netカーネルを指していました。どうやら、この最適化パスはまだQwen 3のMoEアーキテクチャ向けに更新されていないようです。いまのところ、q8_0で90Kのstock llama.cppは問題なく動いています。
実際に動き始めてからの用途：動いている間に、私がK8sオペレータの次の機能をデプロイするために書いた仕様ドキュメントを渡し、あとは一晩まるごと走らせました。ツール呼び出しは56回、成功率100%、ユニットテスト9本、検証コマンドはすべて緑でした。私が起きたときには、マージ可能なPRになっていました。デプロイしたモデルは、オペレータの次の機能まで実際に出荷することになりました。ちょっとした再帰の瞬間です。より長い版が必要なら、こちらに完全な書き起こしがあります。
構成の詳細、ベンチ用ハーネス、あるいは生の数値なども、必要な方がいれば共有できます。
[link] [comments]
