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
2026年3月26日、Google CloudのB200 clusterでQwen 3.5 27Bをserveした事例を扱うr/LocalLLaMA投稿は、クロール時点で205 pointsと52 commentsを集めた。リンク先記事はtensor parallelismからdata parallelismへ切り替え、context lengthを縮め、FP8 KV cacheとMTP-1 speculative decodingを有効化することで、12 nodeで合計1,103,941 tokens per secondに達したと説明している。
Cursorは2026年3月26日、real-time reinforcement learningによって改善版Composer checkpointを最短5時間ごとに投入できると述べた。研究記事によれば、このループは実ユーザー対話から得た数十億tokenを学習信号にし、配備前にCursorBenchを含むevalを通し、edit persistence・dissatisfied follow-up・latencyの改善も確認している。
r/MachineLearning の新しい投稿が、TurboQuant を KV cache の話題から weight compression へ押し進めた。GitHub 実装は low-bit LLM inference の drop-in path を狙う。
Comments (0)
No comments yet. Be the first to comment!