SpecForge: SGLang 向け投機的デコーディングモデルの訓練と配備をつなぐ
Train speculative decoding models effortlessly and port them smoothly to SGLang serving.
ひと目でわかる
- これは何？
- SGLang チームが MIT ライセンスで公開する投機的デコーディング訓練フレームワーク。EAGLE3 や DFlash など複数の手法を単一の型付き訓練エントリポイントで扱い、SGLang への移植作業を不要にすることを狙う。ただし対応する手法とトポロジの組み合わせは限られ、検証は設定段階で拒否される。
- 誰に向いている？
- SpecForge が向くのは、SGLang を既にサービング基盤として使い、EAGLE3 系のドラフタを自前のデータで訓練して受け入れ率を上げたいチームである。逆に、SGLang 以外の推論エンジンを前提とする場合や、README の表に載っていない手法とトポロジの組み合わせを試したい場合には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
SpecForge が埋めようとしている穴
投機的デコーディングのドラフタモデルを訓練するためのオープンソース実装は複数ある。README はその状況について、多くが十分にメンテナンスされておらず、SGLang と直接互換ではないと述べている。SpecForge はこの2点を出発点にしている。訓練済みのドラフタを SGLang に載せる際の移植作業をなくし、コードがそのまま動く状態を保つことを目標に掲げる。対象読者は、SGLang でモデルを配信していて、受け入れ率の改善を自前のデータで試したいエンジニアである。ドラフタの訓練そのものを研究対象にしているわけではなく、サービング側の高速化を目的とした実務寄りの位置づけだ。
単一の訓練エントリポイントという設計
SpecForge の特徴は、手法ごとに Python の訓練スクリプトが分かれていないことだ。README は「There are no method-specific Python training entry points」と明記し、すべての手法が同じ型付きの訓練エントリポイントを使うとしている。実際のコマンドは次の形になる。
specforge train --config examples/configs/online/disaggregated/external/qwen3-8b-eagle3-disaggregated.yaml
設定ファイルのパスが、機能モード、トポロジ、オンラインサービスの所有権を同時に表す。examples/configs の下をたどるだけで、どのレシピが何を意味するかが決まる構造だ。手法ごとに実装を分岐させるのではなく、設定の検証と実行アセンブリの段階で組み合わせを判定する。README によれば、サポートされない組み合わせは古いトレーナーにフォールバックせず、設定検証か実行アセンブリの時点で拒否される。
external と managed-local の責任分界
オンライン訓練のレシピは、サービスの所有権によって2種類に分かれる。external レシピでは、SpecForge は単一のトレーナーノード上で producer と consumer を監督する。Mooncake と SGLang はユーザーまたはスケジューラが管理する。managed-local レシピでは、それらのサービスもローカルホスト上で起動する。この違いは運用負荷に直結する。既に Mooncake と SGLang を別途運用している環境なら external が自然だが、そうでなければ managed-local のほうが起動は楽になる代わりに、ローカルホストのリソースを訓練とサービングで奪い合うことになる。README はまた、オンラインのターゲット並列度は SGLang 側に属し、deployment.trainer がトレーナーの DP とオフライン EAGLE3 の USP プロセスグループを所有すると説明している。並列度の設定が1か所にまとまっていない点は、構成を読むときに最初に混乱しやすい箇所だ。
対応手法の広がりと、その読み方
README の表には EAGLE3、P-EAGLE、EAGLE3.1、DFlash、DFlash2、Domino、DSpark が並ぶ。それぞれに例示された設定ファイルがあり、EAGLE3 と DFlash と Domino は online external、offline colocated、offline disaggregated の複数レシピを持つ。一方で P-EAGLE、EAGLE3.1、DSpark は online external のみ、DFlash2 は online managed-local のみが示されている。表の Optimization 列には LK loss や D-PACE といった最適化手法が一部の行にだけ記載され、他はダッシュになっている。ここから読み取れるのは、すべての手法がすべてのトポロジで同じ成熟度にあるわけではないということだ。手法名が並んでいるからといって、自分のユースケースに合うレシピが必ず存在するとは限らない。設定を書く前に、目的の手法に対応するレシピが examples/configs のどこにあるかを確認する必要がある。
SpecBundle と受け入れ率の話
SpecForge チームと業界パートナーは SpecBundle という投機的デコーディングモデルの集合も公開している。README はこれを production-grade と表現し、既存のオープンソースチェックポイントと比べて広い領域で高い受け入れ率を提供し、SGLang と組み合わせて最大4倍の高速化が得られるとしている。ただしこの数値は README の主張であり、条件や測定方法は本文には示されていない。SpecBundle の性能ダッシュボードへのリンクが用意されているので、自分のワークロードに近い条件がそこにあるかを確認するのが現実的だ。自前で訓練する場合と SpecBundle を使う場合は競合する選択肢ではなく、まず既存チェックポイントで足りるかを見て、足りなければ SpecForge で訓練するという順序が素直である。
向かないケースと代替の考え方
SpecForge が明らかに向かないのは、SGLang 以外の推論エンジンを使っている場合だ。SGLang への移植作業を不要にすることが設計目標の中心にあるため、別のエンジンを前提にすると、この利点はそのまま失われる。投機的デコーディングのドラフタ訓練だけを目的に、特定のサービング基盤に縛られない実装を探しているなら、既存のオープンソース実装のほうが選択肢としては広い。ただし README 自身が指摘するように、それらのメンテナンス状況と互換性は保証されていない。もうひとつの向かないケースは、README の表にない手法とトポロジの組み合わせを試したい場合である。設定検証で拒否される設計なので、独自の組み合わせを動かすにはコード側の変更が必要になる。ここはフォールバックを許さないという設計判断の裏返しであり、利点と制約が同じ仕組みから来ている。
ライセンスとメンテナンスの見え方
ライセンスは MIT で、リポジトリの LICENSE ファイルにその旨が示されている。MIT は制約の少ないライセンスとして広く知られているが、実際の運用判断は法務の確認を経るべきで、ここで法的な助言はできない。メンテナンスについては、README が SpecForge チームによる定期的なメンテナンスと out-of-the-box で動くことをうたっている。ただし取得できた情報にはリリースノートが含まれておらず、バージョニングの方針や後方互換性の扱いは確認できない。デフォルトブランチは main で、アーカイブはされていない。導入を検討するなら、依存する SGLang 側のバージョンとの対応関係を docs.sglang.io の SpecForge ドキュメントで確認するのが先決だ。訓練フレームワークとサービングフレームワークが別々に更新される構成では、この対応関係が実質的なアップグレードコストを決める。
編集部の結論
SpecForge が向くのは、SGLang を既にサービング基盤として使い、EAGLE3 系のドラフタを自前のデータで訓練して受け入れ率を上げたいチームである。逆に、SGLang 以外の推論エンジンを前提とする場合や、README の表に載っていない手法とトポロジの組み合わせを試したい場合には向かない。導入前に確認すべきは、使いたい手法とトポロジが examples/configs 配下のどのレシピに対応するか、そして online の場合に Mooncake と SGLang のどちらを自分で管理する責任範囲になるかである。external レシピを選ぶなら、SpecForge が面倒を見るのは訓練ノード上の producer と consumer だけだと理解した上で構成を決めたい。
コミュニティノート