Qwen-3.6-27B、llama.cpp、スペキュレイティブ・デコーディングへの感謝投稿

まず、画像に写っている内容で何が起きているのかを少し説明します。

私は、新しいQwenの速度に対して speculative decoding を使うことでどれくらい改善が出るのかを見極めることを目的に、小さな実験をしました（TL;DR すごい！）。

1. 画像は、セッション開始時の私のシンプルなプロンプトを示しています。
2. 画像は、最初のプログラムを作る際の時間とトークン生成速度（13.60 t/s）を示しています。さらに、画像には新しい機能を求める私のプロンプトも表示されています。
3. 画像は、2つ目のバージョンのプログラムに対する時間とトークン生成速度を示しています（25.53 t/s - 改善が見て取れます）。また、画像からバグがあったことも分かります。ブラウザのコンソールを開いた状態で、Qwen にスクリーンショットを提示しました。Qwen は正しく、そのバグがどんな種類のものかを見抜き、修正しました。
4. 画像は、修正版のプログラムに対する時間とトークン生成速度を示しています（68.35 t/s - 大幅な改善）。また、画像にはプログラムに小さな変更を加えるための私のプロンプトも表示されています。
5. 画像は、小さな変更を行った後の最終バージョンのプログラムに対する時間とトークン生成速度を示しています（136.75 t/s !!!）

最後の画像は、完成した美しい水槽です。同程度のサイズの古いモデルや、さらにずっと大きい多くのモデルと比べても、見た目と機能性のレベルが別次元です。

セッション中の速度は 13.60 > 25.53 > 68.35 > 136.75 t/s と上がっていきます。毎回 Qwen が完成したコード一式を返していました。この種のワークフローは、私がとても頻繁に使っているものです。そしてこれらすべてが、 llama-server コマンドのたった1行のおかげです。

'--spec-type ngram-mod --spec-ngram-size-n 24 --draft-min 12 --draft-max 48'.

これが最適な設定かどうかは分かりませんが、私の環境ではうまく機能します。もう少し調整してみます。

私の llama-swap コマンド:

 ${llama-server} -m ${models}/Qwen3.6-27B/Qwen3.6-27B-Q8_0.gguf --mmproj ${models}/Qwen3.6-27B/mmproj-BF16Qwen3.6-27B.gguf --no-mmproj-offload --spec-type ngram-mod --spec-ngram-size-n 24 --draft-min 12 --draft-max 48 --ctx-size 128000 --temp 1.0 --top-p 0.95 --top-k 20 --presence_penalty 1.5 --chat-template-kwargs '{"preserve_thinking": true}' 

私の Linux PC は VRAM 40GB（rtx3090 と rtx4060ti）で、DDR5 RAM は 128GB です。

llamacpp に貢献しているすべての賢い人たち、この Reddit コミュニティ、そして Qwen チームに大きな感謝を。

ただ飯、試してみてください……

編集: 追記。2日前の llama.cpp の変更について、いくつか触れるのを忘れていました。なのでアップデートを試してください。