幅 vs. 深さ：マージンでの推測

これは楽しい（ある種の非普遍的な楽しさの定義において）面接の質問です。 Qwen3.6-35B-A3Bをバッチサイズ111で、単一のGPUで実行していると想像してください。スループットを向上させたいと決めたとします。何らかの理由で、あなたのエンジンは一度に222トークンしか処理できません。 あなたは2つの選択肢があります（ドラフトモデルのフォワードパスは無料だと仮定します。バッチ処理のために事前に入力する必要はないと仮定します。シーケンスが十分に短く、KVキャッシュの移動が関係しないと仮定します）。 1. 222個のランダムなユーザーシーケンスをまとめてバッチ処理することで、バッチサイズ222で実行する。 2. バッチサイズ111で実行し、111トークン先を推測する――つまり、検証は222の位置（サンプリングしたトークンと1つのドラフト）で機能し、トークンごとの受け入れ率をαとします。 出力される総トークン数/秒だけを気にする場合、どちらが良いでしょうか？ これはもっともらしい答えです：すべてがメモリバウンドであると仮定すると、α<1の場合、バッチサイズを増やすことによってワーキングセットに追加されたトークンが拒否される可能性がないため、バッチ処理が常に優れています。 しかし、モデリングを行うと次のようなことがわかります：推測シーケンス1つに2つの位置を費やすことは、α=0.9であっても、2つのシーケンスのバッチに費やすよりも、全体としてより多くの出力トークンを生成します。 どうしてでしょうか？ 最初の話：深さは幅よりも安価になりうる それを知るために、データを見てみましょう（前回の投稿から収集したデータ：2つのドラフトモデルのそれぞれについて50万回のドラフトラウンド、ドラフター自身の深度ごとの信頼度と実際にコミットされたトークン数を記録し、さらに各トークンがどのエキスパートを経由したかの個別のキャプチャ――そしてDeepSeek-V4-Flashについても同様のルーティングキャプチャを行いました（すべてspecdec-calibrationとして公開されています）。）。 答えはMoEルーティングにあります。 MoEルーティングはLLMのパフォーマンス分析の奇妙な部分です：データセマンティックの内容が、どの作業が行われるかに影響を与える場所の1つです。原則として、ランダムデータでのベンチマークが代表的でないといった、混乱を招くようなことを行う可能性があります。 まず、ルーティングされたエキスパートの経験的分布を見てみましょう（以前は、均一なルーティングを仮定していましたが、これはクーポンコレクターの数学になります）。 レイヤーごとの平均 レイヤー0レイヤー1レイヤー2レイヤー3レイヤー4レイヤー5レイヤー6レイヤー7レイヤー8レイヤー9レイヤー10レイヤー11レイヤー12レイヤー13レイヤー14レイヤー15レイヤー16レイヤー17レイヤー18レイヤー19レイヤー20レイヤー21レイヤー22レイヤー23レイヤー24レイヤー25レイヤー26レイヤー27レイヤー28レイヤー29レイヤー30レイヤー31レイヤー32レイヤー33レイヤー34レイヤー35レイヤー36レイヤー37レイヤー38レイヤー39 Qwen3.6-35B-A3B DeepSeek-V4-Flash HumanEval SPEED-Bench -- all categories SPEED-Bench -- coding SPEED-Bench -- writing SPEED-Bench -- qa SPEED-Bench -- rag SPEED-Bench -- math SPEED-Bench -- reasoning SPEED-Bench -- stem SPEED-Bench -- humanities SPEED-Bench -- summarization SPEED-Bench -- multilingual SPEED-Bench -- roleplay 驚くほど不均一です！ランク対シェアの曲線にフィットさせると、ランクとともにほぼ指数関数的に減衰します：最も忙しいエキスパートは、公正なシェアの数倍を引っ張ります（エキスパート負荷分散損失による事前学習で、異なるタイプのデータでエキスパートがどの程度バランスが取れているかから、データ分布のプロキシメトリックがあるのではないかと思います）。 それはドメイン、モデル、レイヤーによって異なります。 これはそれ自体では何も説明しません。 しかし――幅と深さの間で選択する際に、テーブル上の2つの選択肢の違いを見てみましょう：ランダムに選択された2つのトークンを処理するか、それらが互いに続く2つのトークンを処理するかです。 NNNが成長するにつれて、検証フォワードが触れる異なるエキスパートは3つの方法で異なります：NNN個の別々のシーケンス（幅）、NNN個の連続した位置を実行する1つのシーケンス（深さ）、そして均一なクーポンコレクターです。 レイヤーごとの平均 レイヤー0レイヤー1レイヤー2レイヤー3レイヤー4レイヤー5レイヤー6レイヤー7レイヤー8レイヤー9レイヤー10レイヤー11レイヤー12レイヤー13レイヤー14レイヤー15レイヤー16レイヤー17レイヤー18レイヤー19レイヤー20レイヤー21レイヤー22レイヤー23レイヤー24レイヤー25レイヤー26レイヤー27レイヤー28レイヤー29レイヤー30レイヤー31レイヤー32レイヤー33レイヤー34レイヤー35レイヤー36レイヤー37レイヤー38レイヤー39 Qwen3.6-35B-A3B DeepSeek-V4-Flash HumanEval SPEED-Bench -- all categories SPEED-Bench -- coding SPEED-Bench -- writing SPEED-Bench -- qa SPEED-Bench -- rag SPEED-Bench -- math SPEED-Bench -- reasoning SPEED-Bench -- stem SPEED-Bench -- humanities SPEED-Bench -- summarization SPEED-Bench -- multilingual SPEED-Bench -- roleplay これが答えです。 バッチサイズ1ではメモリバウンドであり、2位置の推測実行を検証することは、2番目のシーケンスを追加することよりもエキスパートの重みを少なく移動させます。 それは共同活性化によって行われます――推測された実行はランダムに選択されたデータよりも類似しているため、より多く同じエキスパートを活性化します（Joshはバッチ処理のための共同活性化を回復しようと素晴らしい仕事をしてくれました）。 α=0.9で推測されたトークンの10％を破棄したとしても、深さは幅に勝ちます。 これはおもちゃの問題ですが、洞察をどのように活用できるかを考えるのは興味深いです（実際のエンジンでは、ドラフトモデルのコストによって洗い流されます。KV読み取りでバウンドされる長いシーケンスでは戻ってきますが、ここでストーリーを伝えるために深さと幅を制御するのは難しくなります）。 実際には、より大きなバッチサイズで実行するため、エキスパートの活性化はバッチ全体で飽和し、効果は洗い流されるはずです。 しかし、αの税金はそうではありません：推測された各トークンは依然として拒否のリスクを負います。 すべてのシーケンスに同じように支払う必要があるのでしょうか――それとも、支払う可能性が高い場所にのみ深さを使うことができるのでしょうか？ 2番目の話：深さはどこに使うべきか 推論エンジンの寿命全体で形成されるバッチは均質ではありません：一部のデコードリクエストは、他のリクエストよりも推測しやすいです。 ドラフターがどれほど自信を持っているかについての何らかの感覚を得ることができれば、必要な場所にのみ深さを使うことができ、ドラフター（EAGLEのようなトークンを逐次提案するドラフターシステム。DFlashではすべてのトークンが無料で得られます）と検証者の計算の両方を節約できます。 節約した分は、他の場所でさらに推測するために、またはバッチにシーケンスを追加するために使うことができます。 最初の質問は、シーケンス間で受け入れられるトークン数にどれだけのばらつきがあるかです――もしばらつきがなければ、これはまったくやる価値がありません。 実際には、かなりのばらつきがあります。 コミットされたトークン数は平均値の周りにクラスター化されていません：特定のラウンドでは、ドラフターはほとんどすべてをドラフトしたか、またはすぐに間違ったかのどちらかです。 ラウンドは「ほとんどがミス」または「クリーンなスイープ」に分かれます（探求すべき質問：この最大ドラフト長でのスパイクは、モデルがさらに進むことができたのに、できなかったという事実を表しているのでしょうか？）。 SPEED-Bench -- all categories SPEED-Bench -- coding SPEED-Bench -- writing SPEED-Bench -- qa SPEED-Bench -- rag SPEED-Bench -- math SPEED-Bench -- reasoning SPEED-Bench -- stem SPEED-Bench -- humanities SPEED-Bench -- summarization SPEED-Bench -- multilingual SPEED-Bench -- roleplay HumanEval MTPDFlash バッチ全体で単一の固定深度は、両方の集団の間で妥協する必要があります。簡単なラウンドで利益を得るには十分に深く、ほとんどすべてが拒否されるリクエストに検証時間を浪費しすぎないように浅くする必要があります。 実際には、ドラフターは検証者が実行される前に、それがどのような種類のラウンドであるかについてすでに意見を持っています。 以下に、ドラフター自身の深度ごとの信頼度――累積積の合計――が示唆する受け入れ長を、実際にコミットされた総長に対してプロットします。 対角線は「完全にキャリブレーションされている」ことを意味します：つまり、経験的な受け入れトークンは、ドラフターの信頼度が予測したものと同じです。 対角線の下は、ドラフターが過度に自信があったことを示し、上は、十分に自信がなかったことを示します。 SPEED-Bench -- all categories SPEED-Bench -- coding SPEED-Bench -- writing SPEED-Bench -- qa SPEED-Bench -- rag SPEED-Bench -- math SPEED-Bench -- reasoning SPEED-Bench -- stem SPEED-Bench -- humanities SPEED-Bench -- summarization SPEED-Bench -- multilingual SPEED-Bench -- roleplay HumanEval MTPDFlash 対角線に沿って多くの青い線があり、これは私たちのドラフティングポリシーを改善するために使用できる無料の信号です。 どうすればそれができるでしょうか？ ラウンドiiiの、深度γからの期待コミットトークンを、それ自身の信頼度から書く