Tencent、AngelSpecをオープンソース化し、画一的な投機的デコーディングに挑む

Tencent Hunyuanは、標準的な自己回帰デコーディングと比べてHy3-A21Bの推論を最大2.40倍高速化したと報告した後、AngelSpecをオープンソース化した。このフレームワークは、異なる2種類の投機的デコーディング手法に向けた学習、評価、デプロイ支援を統合する。その中核となる主張は、単一のドラフト手法ではあらゆる言語モデルのワークロードを効率的に処理できないという一般的な前提に異議を唱えるものだ。

AngelSpecには、軽量な自己回帰型ドラフターで複数の将来トークンを提案するmulti-token prediction（MTP）が含まれる。また、より長いトークン群を並列にドラフトするブロック拡散システム、DFlyも導入している。Tencentによれば、DFlyはテストしたサービング条件全体で、DFlashより10.5%から11.8%高いスループットを実現した。

この比較が重要なのは、DFlashがすでに投機的デコーディングを厳密な逐次ドラフトから転換させていたためだ。AngelSpecは、単により高速な別のドラフターを提案しているわけではない。対照的な2つの手法を、それぞれが最も得意とするワークロードに対応付け、実行時の状況に応じて検証を調整する。

その結果、推論高速化をより運用面から捉えたオープンフレームワークが生まれた。開発者は学習経路を確認し、公開されたHy3ドラフトモデルを試し、トラフィックに応じた性能変化を調べられる。ただし、Tencentが報告した向上は、同社独自のモデル、構成、評価設計に基づくものだ。決定的に不足している証拠は、独立した本番環境での結果である。

AngelSpec、研究上の選択をデプロイ上の選択へ変える

AngelSpecは投機的デコーディングを、万能のドラフトアーキテクチャを競うものではなく、ワークロード選択の問題として扱う。

Tencentの研究者らは、AngelSpec論文の初版を2026年7月28日に投稿した。改訂版は7月29日に公開された。その後同社は、学習コードとHy3-A21Bドラフトモデルの重みを含むオープンソースリリースを発表した。

投機的デコーディングでは、より小規模または低コストのドラフターが複数の将来トークンを提案する。完全なターゲットモデルがこれらの提案をまとめて検証し、一致した接頭辞を受け入れる。提案が正確であれば、システムは同数の高コストなターゲットモデル実行を避けつつ、複数の有効なトークンを生成できる。

この手法は、必要な検証および棄却プロセスを実装すれば、ターゲットモデルの出力分布を維持する。したがって、ドラフターの回答をターゲットモデルの回答に置き換えるのではなく、トークン生成の効率を変えるものだ。

ただし、ドラフト品質が、その理論上の利点が実用的な高速化になるかどうかを左右する。弱いドラフターは棄却されるトークンを生成し、生成を前進させずに処理を追加する。大規模なドラフターは正確に予測できるかもしれないが、時間とメモリを使いすぎる可能性がある。リクエストに見合わない数の候補をテストすれば、検証も高コストになり得る。

AngelSpecは、こうした変数を単一の学習・評価フレームワークに組み込む。MTPとブロック並列型投機的デコーディングをサポートし、隠れ状態生成、長文コンテキスト学習、ロールアウトワークフロー、オンライン受理評価を含む。このリリースは、研究用チェックポイントから稼働中の推論サービスまでの道のりを、より広くカバーすることを意図している。

フレームワークの2つのドラフト経路は、出力の振る舞いによって問題を分割する。Tencentは、言語が自由形式で次のトークンが比較的不確実な多様な会話データでMTPドラフターを学習する。一方、より長い継続が予測しやすい構造に従うことが多いコードと数学では、ブロック拡散経路を学習する。

この専門化こそが、この出来事における最も重要な変化だ。多くの投機的デコーディングの比較は、平均的にどの手法が勝つかを問う。これに対しAngelSpecは、特定の分布にどのドラフト構造が適するかを問い、両方の構造を共通の開発経路を通じて提供する。

付随する重みにより、このリリースは利用できないシステムを説明する論文よりも検証しやすいものになっている。Tencentによれば、Hy3-A21B向けのMTPおよびDFlyドラフターを同社のモデルチャネルで公開した。開発者には対応するターゲットモデルと適切なサービングハードウェアが依然必要だが、評価を始める前にすべての学習段階を再現する必要はない。

Hy3はこのリリースにとって要求の厳しいターゲットだ。公式のHy3モデルリポジトリでは、総パラメータ数2,950億、アクティブパラメータ数210億のmixture-of-expertsモデルと説明されている。また、38億パラメータのMTPレイヤーと、256,000トークンのコンテキストウィンドウも記載されている。

こうした仕様により、推論効率は経済的に重要になる。各トークンで活性化するのはモデル全体の一部にすぎないが、サービングには依然として相当量のメモリ、通信、ターゲットモデル計算が必要だ。検証ステップあたりの受理出力を増やすドラフターは、主要モデルを再学習せずにレイテンシーやスループットを改善できる。

したがってAngelSpecは、単なるHy3向けの追加機能以上のものとして登場した。サービング条件の変化に応じてドラフトシステムを選択、学習、評価するための明示的なフレームワークを提供する。このより広い範囲こそが、画一的な投機的デコーディングに圧力をかける。

報告された向上は静的なドラフト戦略に圧力をかける

Tencentの最も強い主張はピーク時の高速化だけでなく、同時実行数4から64までのすべてのテスト水準でDFlyが優位に立ったことだ。

論文によると、DFlyはHy3-A21B上で自己回帰デコーディングに対し、エンドツーエンドで1.98倍から2.40倍の高速化を実現した。Tencentはさらに、DFlashより10.5%から11.8%高いスループットと、平均受理出力が約30%長いことも報告している。

同時実行数は、サービングシステムが一度に処理するリクエスト数を示す。これは計算、バッチ処理効率、メモリ負荷、検証オーバーヘッドのバランスを変える。単一リクエストでは高速に見える手法でも、多数のリクエストが同じアクセラレーターを奪い合うと優位性を失う可能性がある。

Tencentによれば、DFlyは同時実行数4から64までの各テスト水準で最高の平均スループットを達成した。この範囲が重要なのは、比較的軽いトラフィックと、より強くバッチ化されたサービスの両方を含むためだ。この結果は、DFlyのスケジューラーと検証戦略が、ドラフトモデルの生の受理率以上に寄与したことを示唆している。

ただし、この数値には慎重な解釈が必要だ。2.40倍の高速化は、すべてのユーザーの応答到着が2.40倍早くなることを意味しない。エンドツーエンドの高速化は、ベンチマークのワークロード、出力長、リクエスト構成、バッチ処理ポリシー、ハードウェアプロファイル、ベースライン構成に左右される。

スループットとレイテンシーも異なる問いに答える。スループットは、システムが一定時間内に完了する処理量を測る。対話型ユーザーは、多くの場合、最初のトークンまでの時間や、その後のトークン間の遅延をより重視する。サービスは総スループットを増やしながらも、個々のリクエストに対しては小さな、あるいは不均一な改善しかもたらさないことがある。

この違いは、固定的なドラフトポリシーを使用する推論チームに圧力をかける。静的なポリシーは、すべてのトラフィックに対して1つのドラフト長、1つの検証深度、あるいは1つのドラフターを選ぶかもしれない。AngelSpecは、こうした選択がドメイン、リクエスト特性、オンライン負荷、デプロイハードウェアに応じて変わるべきだと主張する。

したがって圧力を受ける対象は特定の企業ではない。投機的デコーディングを固定的なモデル付属機能として扱うアプローチだ。Tencentの知見が他の環境でも成立するなら、運用者にはドラフト処理がいつ価値を維持するかを理解するルーティングおよびスケジューリングロジックが必要になる。

DFlashは最も直接的な比較対象となる。ブロック拡散設計は、ターゲットモデルの隠れ状態を用いて複数のドラフトトークンを並列に予測する。このアプローチでは、各提案を別々の逐次ドラフターステップで生成する必要がない。

DFlashの著者らは、選定された実験において6倍超の高速化と、EAGLE-3を上回る性能を報告した。これらの結果は異なるターゲットとテスト条件を用いているため、AngelSpecの最大2.40倍と直接比較すべきではない。Tencentにとって関連する主張は、自社のHy3評価内で報告された、管理された条件下でのDFly比較である。

EAGLE系システムも、依然として重要な参照点だ。これらはターゲットモデルの特徴を利用して小規模な自己回帰型ドラフターを導き、多くの場合、効率的な検証のために提案を構成する。この種のシステムは多様なテキストで安定した結果を出せるが、ドラフト内部の逐次依存関係により、長い候補列を提案する速度が制限される場合がある。

MTPは、その自己回帰経路のより軽量な形態に位置付けられる。ターゲットがすでに互換性のある予測レイヤーを公開している場合、統合しやすい。Tencent自身のHy3リリースにはMTPレイヤーが含まれており、軽量なドラフトと特化型ブロック並列システムを比較する自然なテストベッドとなっている。

AngelSpecが既存デプロイメントにかける圧力は実務的なものだ。チームは、追加モデル、スケジューラーロジック、プロファイリング、メモリ使用量が、その複雑さを正当化するのに十分な受理トークンを生み出すかを判断しなければならない。フレームワークはその問いを探るためのコードと重みを提供するが、答えを普遍的なものにはしない。

AngelSpecはいかにしてDFlyをより選択的にするか

DFlyは並列ドラフトと自己回帰情報を組み合わせ、期待リターンが最も高い場所に検証処理を投入する。

ブロック拡散ドラフターは、複数の位置を一度に予測するため、トークンを1つずつ完了させない。並列予測は、特に候補ブロックが長い場合にドラフトのレイテンシーを低減する。しかし、文やコード列の中のトークンは、同じブロック内の先行トークンに強く依存する。

この依存関係が弱点を生む。各位置がマスクされた、あるいは不完全な近傍情報から予測されると、後続の提案は自己回帰型ドラフターが自然に得る情報を欠く可能性がある。初期の1つの誤りによってターゲットモデルが受け入れる接頭辞が短くなり、提案ブロックの大部分が無駄になることがある。

DFlyは、この緊張関係に対処するため、連携した2つのコンポーネントを採用する。バックボーンはターゲットモデルの特徴に条件付けられつつ、ブロック並列生成を維持する。先行トークンに条件付けられた自己回帰ヘッドも、予測に先行トークンの情報を与え、提案ブロック内の依存関係を改善する。

このアーキテクチャは、ドラフト全体を従来型の逐次プロセスへ変えるものではない。Tencentの設計は、バックボーンの並列処理を維持しながら、候補の一貫性を高めるのに十分な先行情報を加えようとする。このバランスが、平均受理長の向上という主張の中心にある。

受理長とは、不一致に遭遇するまでにターゲットモデルが承認する提案トークン数を指す。受理される接頭辞が長いほど、高コストな各検証ステップをより有用な出力に分散できる。ただし、候補の生成と検査に時間がかかりすぎる場合、受理長だけを最大化しても誤解を招く可能性がある。

そのためAngelSpecは、D-Cutと呼ばれる適応的な検証手法を加えている。検証深度は、ターゲットモデルが各提案継続のどこまでを検査するかを指す。固定深度では、不確実な候補に過剰投資したり、非常に予測しやすい候補を早く打ち切りすぎたりする可能性がある。

D-Cutは、検証能力を共有のバッチレベル資源として扱う。追加の候補位置を保持する期待値を推定し、それをプロファイリングされた実行時コストと比較する。その後スケジューラーは、複数のリクエストにまたがって、高信頼度の接頭辞へより多くの検証処理を振り向けられる。

これは単なるモデル選定ではなく、サービングにおける意思決定である。同じモデルで処理される2つのリクエストでも、必要とされる検証の深さは異なりうる。構造化されたコード補完では長く確信度の高いプレフィックスを維持できる一方、自由形式のチャット応答では数トークン後には分岐する可能性がある。

ハードウェアも計算を左右する。検証バッチを大きくすることで、あるアクセラレータ構成では効率化できる一方、別の構成ではコスト増になることがある。通信コスト、メモリ帯域幅、カーネル、ターゲットモデルの並列性はいずれも、候補位置をもう1つ増やすことが時間短縮につながるかどうかに影響する。

そのためAngelSpecは、確率推定だけに依存せず、ランタイムコストをプロファイリングする。ある候補は受理される可能性が高く見えても、その確認によってバッチが非効率な形状へと拡大するなら、実用性は低い。スケジューラには、確信度と実測されたシステムコストの両方が必要になる。

Nvidiaのspeculative decoding documentationは、デプロイメントフレームワークがすでに手法別の設定を公開していることを示している。DFlashのサポートには、ドラフトモデル、ドラフト長、マスクトークン、選択したターゲットレイヤーが必要だ。AngelSpecはこの課題を、稼働中のリクエスト間で適応的にリソースを割り当てる方向へさらに進めている。

ドメイン分割は、このランタイム適応を補完する。MTPは不確実性の高い会話型出力に向けた軽量ルートとして残る。DFlyは、並列ブロックがより長い予測可能なシーケンスを捉えられるコードと数学を対象とする。どちらの手法も、すべてのリクエストに対する自動的な優先権を持つわけではない。

反復的なテストスイートを生成するAIコーディングサービスを考えてみよう。インポート、関数シグネチャ、アサーションのパターンにより、次のブロックは比較的予測しやすくなる。DFlyはより長い継続を提案でき、確信度が高い状態が続く場合にはD-Cutがより深い検証を維持できる。

次に、同じサービスが曖昧なアーキテクチャ上の質問に答える場面を考える。同じプロンプトから複数の妥当な説明が始まりうる。ドラフターとターゲットが異なる表現を選ぶため、受理されるプレフィックスは短くなる可能性がある。小さなMTP提案なら、生存可能性の低い長い候補ブロックにリソースを費やすことを避けられる。

この仕組みにより、このリリースは単一ベンチマークの改善以上に重要な意味を持つ。投機的デコーディングを、学習データ、ドラフトアーキテクチャ、リクエスト分類、サービングコストにまたがるポリシーとして再定義するからだ。高速化は、孤立した1つのスコアを最大化するのではなく、これらのレイヤーを協調させることで得られる。

AngelSpecの数値が立証していないこと

AngelSpecは信頼できる一次情報を示しているが、DFlyがモデル、ハードウェア、プロダクショントラフィックを問わず優位だとは、まだ立証していない。

論文の結果は、フレームワークを設計し、ドラフトモデルを学習させたチームによるものだ。報告された比較は、リリース時点では独立して再現されていない。読者はこの高速化を、普遍的な性能保証ではなく、企業側が測定して提示した主張として扱うべきである。

第一の制約はモデル依存性だ。DFlyは内部ターゲット特徴を利用するため、ドラフターはターゲットのアーキテクチャと学習特性に密接に結び付いている。Hy3-A21B向けのドラフターを、無関係なモデルファミリーのドロップイン型アクセラレータにそのまま転用することはできない。

この結び付きは、学習と保守のコストを増やす。サポートするターゲットごとに、独自の隠れ状態抽出プロセス、学習データの混合、チェックポイント、検証サイクルが必要になる可能性がある。ターゲットモデルの更新時には、互換性テストの再実施やドラフターの再学習も必要になりうる。

ハードウェア依存性も別の不確実性を生む。Tencentは、D-Cutがプロファイリングされたランタイムコストを使用すると述べており、最適な検証ポリシーがシステムごとに変わることを認めている。あるクラスタ向けに調整されたポリシーは、異なるアクセラレータやネットワークトポロジーで良好に動作させる前に、新たなプロファイルを必要とする可能性がある。

公開された見出しの数値も、複数のワークロードをレンジに圧縮している。コード、数学、会話では予測可能性が異なる。平均スループットは、弱いカテゴリ、不利なプロンプト長、あるいはドラフティングのオーバーヘッドが削減されるターゲット計算量に近づくトラフィックパターンを覆い隠しうる。

長文コンテキストでの挙動には、特に注意が必要だ。AngelSpecは長文コンテキスト学習をサポートし、Hy3は256,000トークンのコンテキストウィンドウを掲げている。しかし、大規模なキー・バリューキャッシュはメモリ圧力を高め、ドラフティングと検証の相対コストを変化させうる。短いコンテキストでの結果だけでは、モデルの最大ウィンドウ付近における性能を判断できない。

品質維持には、実装面での規律も必要になる。投機的デコーディングは、適切な受理・棄却アルゴリズムを通じてターゲット分布を維持できる。デプロイ時の近道、近似的な検証、変更されたサンプリング、互換性のない量子化は、出力を変える可能性がある。運用者は速度と挙動の等価性の両方を検証しなければならない。

メモリもまた現実的なコストである。ターゲットモデル、ドラフトモデル、隠れ状態インターフェース、追加のランタイムバッファが共存する必要がある。軽量なドラフターであっても、キー・バリューキャッシュやより大きなバッチのための余地を減らす可能性がある。その結果生じる容量面のトレードオフにより、メモリ制約のあるデプロイメントではスループット向上が相殺されることもある。

運用の複雑さも重要だ。プロダクションサービスでは、受理長、ドラフト時間、検証時間、キューの挙動、フォールバック時の性能を監視しなければならない。MTPとDFlyのルーティングには別の判断レイヤーが加わり、誤りがあれば不適切なワークロードを不適切なドラフターへ送ることになる。

オープンソースとしてのリリースにより、こうした問いを検証可能にしたことには価値がある。ただし、それらの答えが自動的に得られるわけではない。チームは、AngelSpecのいずれのルートと比較する前にも、自社ハードウェア上で自己回帰ベースラインを再現すべきだ。

続いて、ワークロードとトラフィック水準ごとに測定を分けるべきである。有用なカテゴリには、インタラクティブチャット、コード補完、数理推論、ツール利用トレース、長文生成が含まれる。各カテゴリには、レイテンシのパーセンタイル、スループット、メモリ消費量、受理長、出力等価性チェックを含める必要がある。

公正なDFlash比較にも、条件の一致が求められる。同一のターゲットモデル、精度、サービングフレームワーク、プロンプト分布、出力長、並行実行数を使用すべきだ。そうでなければ、アーキテクチャ上の主張がカーネル品質や設定差と絡み合ってしまう。

コミュニティからのフィードバックは早期のシグナルを提供するが、統制された再現実験の代替にはならない。ローカルデプロイメントの報告では、量子化モデル、コンシューマー向けハードウェア、あるいは改変されたサービングエンジンが使われることが多い。こうした結果は互換性の問題を明らかにしうるものの、論文の設定に十分近いことはまれであり、見出しのレンジを検証するには至らない。

ベンチマーク上の隔たりは、AngelSpecを重要でないものにはしない。それは次の段階を規定する。Tencentは、元の著者が制御していなかった条件下で外部チームが検証できるアーキテクチャ、コードパス、モデルウェイトを提供した。

AngelSpecがHy3を超えて広がるかを決める3つのシグナル

AngelSpecの重要性は、独立した再現、より幅広いモデルサポート、そして適応的ルーティングが実際のプロダクショントラフィックで機能するという証拠にかかっている。

最初のシグナルは、独立した推論チームによる再現可能なHy3-A21Bベンチマークだ。最も強力なテストでは、公開されたMTPおよびDFlyのウェイトを使用しつつ、ハードウェア、精度、フレームワークのバージョン、プロンプトの構成、出力長を報告する。条件を揃えたうえで、自己回帰デコーディング、MTP、DFlash、DFlyを比較すべきである。

Tencentの1.98倍から2.40倍というレンジに近い再現結果が得られれば、中核的な主張の信頼性は高まる。DFlashを一貫して上回る利得も、先行トークン条件付けとD-Cutが一般的なブロック拡散ドラフティングを超える価値を持つことを示唆する。より小さい、あるいは不安定な利得であれば、AngelSpecの実用的な魅力は限定される。

最も有用な独立レポートは、平均スループットだけを公表するものではない。最初のトークンまでの時間、トークン間レイテンシ、テールレイテンシ、メモリ使用量、受理長、並行実行水準ごとの性能も含めるべきである。こうした測定により、総合的な効率がユーザー体験を改善するかどうかが分かる。

2つ目のシグナルは、別の主要なターゲットモデルファミリーへの対応だ。AngelSpecは現在、Hy3周辺で最も明確な証拠と公開済みドラフトウェイトを持つ。Qwen、Llama、または広くデプロイされている別のオープンモデルへの移植が成功すれば、このフレームワークがTencentのアーキテクチャを超えて一般化できるかを検証できる。

移植は、導入の実コストも明らかにする。研究者はターゲットの隠れ状態を生成し、特化したドラフターを学習させ、検証を統合し、ランタイム挙動をプロファイリングする必要がある。妥当なエンジニアリング工数で行える移植を文書化できれば、このフレームワークのエンドツーエンドでの実用性に関する主張は強まる。

移植を引き付けられなければ、AngelSpecは主にHy3向けの最適化パッケージであることが示唆される。その結果でもTencentのモデルユーザーには利益があるが、統合的な投機的デコーディングフレームワークというより広い主張は弱まる。

3つ目のシグナルは、混在ワークロードにおけるプロダクションの証拠だ。Tencentの主張は異質性に依拠しているため、静的ベンチマークでは完全には検証できない。決定的なテストは、トラフィック、ドメイン、ハードウェア利用率が変動するなかで、稼働中のサービスがMTPとDFlyを選択できるかどうかである。

運用者は、ルーティング判断が検証コストあたりの受理済み出力をどれほど改善するかを追跡すべきだ。フォールバック率とルーティングミスも測定する必要がある。複雑な適応型システムは、監視とスケジューリングのオーバーヘッドを含めたうえで、より単純なベースラインを上回らなければならない。

このテストは、チャット、コーディング、数理作業、エージェントアクションを組み合わせるサービスにとり、特に重要である。そのような製品は、エントロピーも長さも大きく異なる出力を生成する。特化したドラフティングが汎用ポリシーを上回るはずの条件が、そこにはある。

混在ワークロードのデプロイメントで安定した利得が示されれば、競合他社には同様のルーティング制御を公開する圧力がかかるだろう。サービングフレームワークは、起動時に1つの投機的アルゴリズムを選択する方式から、リクエストごとにアルゴリズムと検証予算を割り当てる方式へ進化する可能性がある。

利得が厳選されたワークロードの外で失われるなら、より単純な手法は引き続き魅力的である。特に、モデルがすでに互換性のあるレイヤーを備えている場合、MTPは運用しやすくなりうる。静的なドラフト戦略も、チームが保守すべきモデルとポリシーの数を減らす。

このリリースを評価する開発者は、テスト結果と設定上の判断を検索可能なエンジニアリング・ナレッジベースに保存すべきである。投機的デコーディングの実験には相互に作用する変数が多く、記録されていない実行結果はすぐに比較不能になる。

AngelSpecはすでに、推論エンジニアが直面する問いを変えた。もはや選択肢は、投機的デコーディングを有効にするかどうかだけではない。ドラフター、学習分布、検証ポリシー、ハードウェアプロファイルが各リクエストに十分適合し、実際の作業を削減できるかどうかである。

今後1〜3か月で、外部チームがTencentの数値を再現するか、DFlyをHy3以外に移植するか、そして実際の需要下で適応的ルーティングを検証するかが明らかになるはずだ。それまでAngelSpecは、有望な一次結果を持つ本格的なオープン実験であり、決着した勝者ではない。

現在Hy3を提供しているチームにとって、有用な次のステップは、既存の自己回帰およびMTP構成に対する統制されたベンチマークである。それ以外のすべてのチームにとって、問いはより限定的だ。ワークロード認識型のドラフティングは、追加のモデルとスケジューリングレイヤーを正当化できるほど持続的な効率をもたらすのか。その答えが、AngelSpecが広く採用される推論フレームワークになるのか、それとも主にTencent自身のモデルファミリーに結び付いた、よく設計された優位性にとどまるのかを決める。