Together Research、RLベースのadaptive speculative decoding基盤 Aurora を公開
Original: New from Together Research: Aurora. Speculative decoding that adapts to shifting traffic in real time — and keeps improving the longer it runs. Open-source, RL-based, 1.25x faster vs. a well-trained static speculator with no offline retraining pipeline. Thread 🧵 View original →
Togetherが発表した内容
2026年3月31日、Together Researchは、配備後も継続的に適応するspeculative decodingシステムAuroraを発表した。同社は今回の更新を本番運用の問題に結びつけている。Inference高速化のために使うdraft modelはtraffic変化に応じてすぐにstale化しやすく、offline retrainingではその変化に追いつけない、という主張だ。
この問題設定は重要である。Speculative decodingは大規模モデルservingの代表的な最適化手段だが、多くの実装ではdraft modelをofflineで一度作る静的artifactとして扱っている。Togetherは、必要なのは単に一度だけ良いspeculatorを作ることではなく、live workloadに合わせて継続的に更新し続けることだと示している。
Auroraの仕組み
TogetherのブログはAuroraを、reinforcement learningによるserve-to-train flywheelとして説明する。別個のoffline pipelineを待つのではなく、live inference tracesから直接学習する。説明によれば、inference serverはtarget modelとdraft modelでspeculative decodingを実行し、asynchronous training serverはaccepted tokenとrejected proposalを利用してspeculatorを改善し、その更新済みweightをservice interruptionなしでhot-swapする。
- 論文はonline speculator learningをasynchronous RLとして再定義している。
- Accepted tokenはpositive feedbackになり、rejected proposalはimplicit negative feedbackとして使われる。
- システムはSGLangベースのinference serverとasynchronous training serverを組み合わせ、serving中の更新を可能にしている。
論文が加える具体性
arXiv論文はAuroraを単なる学習アルゴリズムではなく、unified training-serving systemとして提示している。著者らは、speculator trainingとservingを分離すると、高いtime-to-serve、utility feedbackの遅れ、traffic distribution shift時のdomain driftという3つの本番上の問題が生じると論じる。Auroraの答えはday-0 deploymentとonline adaptationである。
性能面では、Togetherのブログがtraffic pattern変化時に強いstatic speculator比で1.25xの追加高速化を強調している。論文はさらにMiniMax M2.1 229BやQwen3-Coder-Next 80Bのようなfrontier modelで1.5x day-0 speedupを報告している。今回の公開が高信号なのは、ブログ、arXiv論文、open-source codeが同時に出そろっている点にもある。
なぜ重要か
実務上のポイントは、inference最適化がもはや一度限りのmodel compression課題ではなく、continual-learning型のシステム課題として現れ始めていることだ。Speculative decodingの性能がtraffic mixに左右されるなら、serving telemetryと高速なupdate loopを持つ事業者が、遅いoffline retrainingに依存するチームより有利になりうる。
今回のリリースから読み取れるのは、Togetherがspeculation benchmarkよりもproduction-adaptive servingへ重心を移そうとしていることだ。Auroraの結果がより多くのmodelやinfrastructure stackで再現されるかは今後の検証を要するが、具体的なシステム主張、open-source code、そしてRL trainingと実運用の経済性を直接つなぐ論文を同時に示した点で、今回の公開は非常にシグナルが強い。
出典: Together AI X投稿 · Together Researchブログ · Aurora論文 · Auroraコード
Related Articles
OrthrusフレームワークがQwen3モデルで1回のforwardパスあたり最大7.8倍のトークン生成を達成した。単一KVキャッシュで自動回帰と拡散ビューを統合するデュアルビューアーキテクチャにより、出力分布は原本と数学的に同一だ。
LocalLLaMAの実装報告は、Apple Silicon向けnative MLX DFlash runtimeがQwen系inferenceを複数条件で2倍から3倍以上高速化すると主張する。注目点はspeedupだけでなく、greedy baselineとbit-for-bit identical outputを維持したと説明しているところだ。
LocalLLaMAはこれを単なるベンチ画像として流さなかった。単一のRTX 3090でQwen3.6-27Bの処理量を平均1.98倍まで押し上げ、再学習なしで長文脈も支えるという主張がスレッドの熱源になっている。