結論

私の環境では以下の設定が良さそう

以下、どのように調べてそうなったかを解説。

Qwen3.6-35B-A3Bのトークン速度の測定

まずはすべてをVRAMに載せる（n-cpu-moeの設定なし）条件でモデルを変えて試してみた。
ちなみに、セルの色が変わっている部分は llama.cpp がVRAM警告を出したものだ。

一番使いたかった「Q4_K_M」がギリギリVRAMに乗りきらなかったので、n-cpu-moeの値を1から増やして計測してみた。
ちなみに、以下の表のCPU退避は「CPU_Mapped model buffer size」に出てきたサイズをメモしたものだ

結果は以下

llama.cppはVRAMを1GBは空けておこうとする。警告が出なくなったのは n-cpu-moeを「4」以上にしたときだった。

全てVRAMに載せて余裕を持たせる（llama.cppの警告が出なくなる）なら「UD-IQ4_NL_XL」をq8_0か、q4_0で運用
これなら65トークン/秒前後が出る

せっかくMoEを使うので、一部をCPUに載せるなら「Q4_K_M」をq4_0で、n-cpu-moeは「4レイヤー」にする。
これでも62トークン/秒が出る

たった数トークンの速度のために量子化を厳しくするのは残念な気がするので、私が使うとすれば以下が良さそう

上記のllama.cppと同じような設定をする場合は、以下のように設定する

llama.cppを試したときと全く同一条件ではないので参考程度だが62.66トークン/秒と、llama.cppと同等の速度が出た

上記は簡単なプロンプト1つでテストしているので、コンテキスト長が伸びてきたときの速度とは異なる
実際にClaudeCodeで数時間かかる処理をさせて、トークンを消費したときの速度を実測した

Qwen3.6-35B-A3Bの実測結果は以下
最大：59.78トークン/秒
最小：24.72トークン/秒
平均：38.30トークン/秒

私が同じパソコンで他の作業をしながら動かしていたためか、上記で測定した62トークン/秒よりちょっと遅いが、まずまずの数字が出ている

コンテキストサイズが大きくなって圧縮。またコンテキストが……、を繰り返したので速度が落ちたり上がったりしたが、平均38.3は私が何かの作業をしているときにウラでやってくれると思えば十分な速度だ