Together Compiler：推論ワークロードに追従する継続的コンパイル基盤
固定チューニングから、ワークロード追従型の継続コンパイルへ
Together AIが紹介したTogether Compiler（TKCC）は、モデル・ハードウェア・トラフィック形状に応じて推論エンジンを継続的に最適化する仕組みである。中心となる問題意識は、推論最適化の対象が急速に多様化し、従来の人手による個別調整や固定ルールでは対応しきれないという点だ。
記事によれば、オープンソースLLMのアーキテクチャは多様であり、OpenRouterのトップ10に同一アーキテクチャを採用したモデルはない。また、Together AIが扱うトラフィックは1日あたり数兆トークン、顧客は数千に及び、バッチサイズ、系列長、MoEのエキスパート負荷、注意機構のスパース性、セッション時間、ドメインなどが異なる。ハードウェアもH100、B200、B300、NVL72、VR、Groqなど多岐にわたり、それぞれで有効な最適化方針は変わる。
さらに、トラフィック自体も固定ではない。地域によって、ある国の勤務時間帯のプロンプトが別の国より1.4倍長い例（97k対70k）が観測されたという。新モデルの公開後は、利用者がチャット中心の評価からエージェント的な利用へ移行し、2週間後にはプロンプト長が80%増加するケースもある。突発的なリクエスト集中では、プロンプト長の倍増やキャッシュヒット率の低下も起こり得る。したがって、最適化対象はモデル単体ではなく、時間とともに変化する「モデル×ハードウェア×トラフィック」の組み合わせとなる。
TKCCはこの組み合わせを入力として、エージェント群が推論エンジン向けの最適化案を生成・評価する。記事が強調するのは、エージェントが最適化案を考えられるかどうかだけでなく、その案をどれほど速く実験できるかが、最終的な性能向上を左右するという点である。
持続エンジンと二層測定で、探索速度と実運用再現性を両立
既存のエージェント型最適化では、新たな実験ごとにvLLM、SGLang、TRT-LLMなどのエンジンを起動・終了する方式が一般的で、初期化時間が探索のボトルネックになる。TKCCはエンジンを一度起動したまま候補のforward passをホットリロードする「persistent engines」を採用し、複数のエージェントがメッセージボードを通じて案を共有しながら並列に探索する。
記事の計測では、従来方式のサービング開始までの合計時間は467秒だった。内訳はプロセス・ワーカー初期化93秒、重み読み込み50秒、KVキャッシュサイズ決定21秒、JITカーネルのウォームアップ93秒、自動チューニング193秒、APIサーバー準備10秒である。TKCCでは、Together CompilerのRPC呼び出しとセットアップが1.7秒、CUDAグラフのキャプチャが7.3秒で、合計9.0秒としている。エンジン起動にともなう待ち時間を短縮し、実験スループットを高める設計である。
一方、探索速度を上げるだけでは、実際の推論性能に結び付かない。単独カーネルをランダム入力で評価する方法は、MoEやスパース注意のように入力分布で実行特性が変わる演算では、実運用を代表しない可能性がある。TKCCはこの「測定スループット」と「測定忠実度」のトレードオフに対し、二層の持続エンジンを設ける。
- 高速エンジン：少数レイヤーを読み込み、反復を速くし、低分散のタイミング測定に用いる。
- 低速エンジン：より多くのレイヤーを読み込み、実データ分布に対して最適化が維持されるかを確認する。
この構成により、候補を短時間で絞りつつ、入力依存の挙動を含む実運用に近い評価も行う。また、TP、EP、DCPなどの並列化戦略を選ぶために、ハードウェア仕様、マイクロベンチマーク、実測forward passを段階的に組み合わせたカスタムコストモデルを使う。生のハードウェア仕様だけで構成を決めると、MoEのエキスパート負荷偏りやプロンプト長分布の不均一性を捉えにくいためである。測定に基づいて探索空間を早期に絞りながら、トラフィック変化に応じた再最適化を支える。
ベンチマーク結果と適用範囲
記事では、TKCCは既存のエージェント型性能最適化システムに比べて、実験スループットを252倍に高めたと報告されている。その結果、24時間未満で、記事が対象とするフロンティアのオープンソースモデルにおいて最大2.6倍のTPS向上を達成したとしている。対象モデルとして挙げられているのはKimi K3、GLM 5.3、MiniMax M3.1-Flash、DeepSeek v4.1-Flashである。
低レイテンシー評価では、SemiAnalysisのInferenceXベンチマーク上で、MiniMax M3.1-Flashが1111 TPS、DeepSeek v4.1-Flashが1205 TPSを達成し、記事はこれらを同ベンチマークの最先端性能としている。この評価では、InferenceXの構成をそのまま使うのではなく、TKCCのコストモデルで並列化構成を選び、速度向上を確認したという。
従来から最適化が進んでいる代表的な条件として、Llama 1Bのバッチサイズ1も評価されている。TKCCは手調整されたメガカーネルに対し1.7倍高いTPSを示し、系列長が増加しても性能優位を維持したと報告する。また、天気予測、偏微分方程式（PDE）、時系列、生物学のオープンソースコードベースにも適用し、Claude Codeの/goalコマンドを用いる方法との幾何平均スピードアップを比較している。図の説明では、4モデル中3モデルでTKCCがより大きな高速化を見つけたとしており、LLM推論に限定されない汎用コンパイラとしての可能性を示す。
ただし、Trainium2の結果はAgentXではなく、合成マルチターンデータセット（70k ISL、3.5k新規ISL、95%キャッシュ、700 OSL）で測定されている。記事はその理由として、限られたHBM容量で高い同時実行数を扱う実装が未対応であることを挙げる。ベンチマーク値を比較する際は、この測定条件の違いを区別する必要がある。
開発者・エンジニア視点での考察
-
最適化の単位を「モデル」から「稼働条件の組」に広げる。
実運用では、モデルやGPUが同じでも、並列度、系列長、キャッシュ率、MoE負荷、同時実行数が異なれば有効なカーネルや並列化方式が変わり得る。評価用のトラフィック形状を一つに固定せず、地域・時間帯・利用パターンごとに代表的なプロファイルを定義し、構成選択の入力として扱うのが重要だ。 -
ベンチマーク基盤では、起動時間と測定忠実度を別々に管理する。
エンジン再起動のコストを除いた高速な候補評価と、実データ分布での検証を同じ測定と見なさず、段階的なゲートとして設計する。高速エンジンで候補を絞り、より多くのレイヤーを使うエンジンで再検証する考え方は、実験数を増やしながら、入力分布の違いによる誤選択を抑える実務的な設計指針になる。 -
自動探索の成果を、再現可能な最適化記録として残す。
エージェントが生成した候補コードだけでなく、トラフィック条件、ハードウェア、並列化構成、測定エンジンの層、入力分布、採否の根拠を一体で記録すべきである。こうした履歴があれば、トラフィックドリフト後の再最適化で過去の結果を比較でき、TPS向上が特定条件だけの偶然なのか、対象範囲で再現する改善なのかを判断しやすくなる。
Source / 元記事
この記事について
この記事は、公開されているニュース、論文、公式発表、RSSフィードなどをもとに、AIが要約・補足調査・考察を行って作成しています。
元記事の完全な翻訳・逐語的な要約ではなく、AIによる背景説明や開発者向けの考察を含みます。
重要な技術仕様・価格・提供状況などは、必ず元記事または公式情報をご確認ください。
