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 →

Read in other languages: 한국어English
LLM Apr 1, 2026 By Insights AI 1 min read Source

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コード

Share: Long

Related Articles

LLM Reddit 4d ago 1 min read

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に達したと説明している。

LLM sources.twitter 3d ago 1 min read

Cursorは2026年3月26日、real-time reinforcement learningによって改善版Composer checkpointを最短5時間ごとに投入できると述べた。研究記事によれば、このループは実ユーザー対話から得た数十億tokenを学習信号にし、配備前にCursorBenchを含むevalを通し、edit persistence・dissatisfied follow-up・latencyの改善も確認している。

Comments (0)

No comments yet. Be the first to comment!

Leave a Comment

© 2026 Insights. All rights reserved.