MTP受入率:50%閾値が投機的デコードの恩恵を決定づける

Redditユーザーが、mlx-vlmを使用してGemma-4(26B、4ビット)でMTP(マルチトークン予測)をテストし、パフォーマンスが候補トークンの受け入れ率に完全に依存することを発見しました。M4 Max Studioでの測定により、具体的な閾値が明らかになりました。
ワークロードの結果
- コード生成: 75 tok/s → 114.8 tok/s(1.53倍高速) — 受け入れ率:スロットの66%
- 長文散文: 75 tok/s → 71.1 tok/s(0.95倍、ほぼ横ばい) — 受け入れ率:スロットの31%
- JSON出力: 51.3 tok/s → 25.6 tok/s(0.50倍、低速化) — 受け入れ率:スロットの8%
閾値は約50%の受け入れ率であるようです。それ以下では、投機的デコードのオーバーヘッドが利得を上回ります。
テストの詳細:コードは「Xを行うPython関数をいくつか書く」、長文散文は「唐王朝の紙幣について800語のエッセイを書く」、JSON出力は、項目を類似性でグループ化して構造化出力を生成するものでした。
おまけのヒント:ユーザーは、GemmaのJSON構造指示のフォローはまずまずだが、構造化出力(json_schema)を有効にすると約20%のオーバーヘッドがかかると指摘しています。多少不正確なJSONを受け入れ、実行時に修正することを推奨しています。mlx-vlmは投機的デコード向けのjson_schemaをサポートしていません。
結論: MTPはローカルコーディングには優れていますが、受け入れ率が低い構造化タスクや散文タスクではパフォーマンスが低下する可能性があります。
📖 Read the full source: r/LocalLLaMA
👀 See Also

Claude Codeにおけるトークン使用のヒント
Redditの投稿からトークン消費を減らす実践的アドバイス:新しいチャットを始める、質問をまとめる、CLAUDE.mdを簡潔にする、ファイル参照を正確にする、スレッドを要約して再開する、簡単なタスクには軽量モデルを使う。

日本語: エージェント対応コードベース:否定ルール、正確な命名、ディレクトリのREADME
開発者が、CLAUDE.mdのルール、否定命令、正確な命名によってトークンの無駄を削減し、Claude CodeがUserManagerのようなクラスを肥大化させるのを防いだ方法を共有しています。

チャット質問でクロードコードトークンを無駄遣いするのをやめよう
r/ClaudeAIの開発者が、週間トークン上限を節約するために、簡単なチャット質問はHaikuのような安価なモデルに回し、Claude Codeは複数ファイル編集などのエージェントタスクに限定した。

クロードはコーディングが苦手ではない ― あなたのコンテキスト設定が問題なのだ
Claudeを数ヶ月使った後、ある開発者は失敗の原因はモデル自体ではなく、コンテキストの構造化の仕方にあると主張する。主な改善点:指示とロジックを分離し、コンテキストのノイズを削減し、安定したパターンを使用する。