Together AI、LLM推論のオートスケーリング機能を公開

発表内容と背景

Together AIは2026年7月31日、Dedicated Model Inference向けにオートスケーリング機能の詳細を公開した。この機能では、レプリカ数の最小・最大値を設定し、スケーリングの基準となるメトリクスとターゲット値を選ぶことができる。対応するメトリクスは、inflight_requests（処理中リクエスト数）、TTFT（最初のトークンが返るまでの時間）、GPU使用率、トークン処理量などである。従来のWebサービス向けオートスケーリングがCPU使用率などを基準にするのに対し、LLM推論ではそうした指標が負荷を正しく反映しないという問題がある。

オーバープロビジョニングとアンダープロビジョニングの両方がコスト面で問題になる。過剰にGPUを確保すると使用率が15%程度のままピークを待つことになり、不足するとp95レイテンシが急激に悪化する。LLMサービングは非線形に劣化し、同時実行数の上限を超えると待ち行列が発生してTTFTが200msから15秒に跳ね上がることもある。そのため、単にCPUメトリクスを見るのではなく、推論エンジンが理解するメトリクスでスケールする必要がある。

制御ループと設定

制御ループは比例制御で、観測したメトリクス値とターゲット値の比に応じて所望レプリカ数を計算する。たとえば、inflight_requestsのターゲットを8に設定し、観測値が16であれば、レプリカ数を2倍にしようとする。ただし、この計算結果はそのまま適用されるのではなく、タイミングウィンドウとレプリカ数の上下限で調整される。スケールアップウィンドウは圧力が続く時間を指定し、短めに設定するのが推奨されている。スケールダウンウィンドウはデフォルトで5分で、トラフィックの自然なリズムよりも長く設定する。

この非対称な設定が重要な理由は、間違ったスケールアップは数レプリカ分のコストだけですむが、スケールダウンの誤りは次のピーク時にコールドスタートを伴うからである。コールドスタートには数分かかるため、スパイクが発生してからレプリカを増やしても間に合わない。つまり、先行指標で早めにスケールアップし、落ち着いてもすぐに縮小しないという挙動が求められる。

メトリクスの選び方

利用できるメトリクスは、同時実行駆動、SLO駆動、効率駆動の3つに分類できる。同時実行駆動であるinflight_requestsは、需要が供給を上回ったときにレイテンシが目に見えて悪化する前に上昇する先行指標であり、安全なデフォルトとされる。エンジンがリクエストをバッチ処理する方法に直接対応しているため、パーセンタイルを選ぶ必要もない。SLO駆動のTTFTやe2e_latencyは、ユーザーへの約束を直接的に守るための指標だが、遅延が悪化してから反応するため、min_replicasで余裕を持たせておく必要がある。

効率駆動のGPU使用率やトークン使用率は、ハードウェアを最大限に活用するための指標で、コスト最適化に向いている。ただし、GPUが忙しくてもレイテンシが健全であるとは限らない。使用率のターゲットを100%近くに設定すると、到着バーストに対する余裕がなくなる。また、ttftやトークン処理量、レプリカあたりスループットはストリーミング経路でのみ発行される。クライアントがストリーミングしない場合、これらのメトリクスはデータが得られないため、オートスケーリングに使うべきではない。e2e_latencyはストリーミング・非ストリーミングの両方で測定される例外である。

実験結果

Together AIは、Qwen3.5-9Bモデルを1×H100のレプリカ構成で運用し、同じ負荷を3つのオートスケーリングポリシーで再生する実験を行った。負荷は約12〜48 RPSの正弦波に、80 RPSのスパイクを2回重ねたもので、レプリカの上下限は1〜3に設定された。3つのポリシーは、inflight_requestsのターゲット8、TTFTのp95ターゲット300ms、GPU使用率のターゲット75%である。

結果として、inflight_requestsポリシーだけがスケールアウトを実行した。TTFTポリシーが反応しなかったのは、継続バッチングによって待ち行列の圧力がTTFTではなく全体のレイテンシに吸収されたためである。GPU使用率も、短いバースト状のリクエストでは75%の基準に達しなかった。つまり、システムが飽和していてもTTFTとGPU使用率は健全に見える状況があり、これらの指標だけでは問題を検知できない。inflight_requestsがデフォルトに選ばれた理由がここにある。

注意点と今後の課題

スパイクがコールドスタートよりも速く到来した場合、既存レプリカでキューイングが発生し、TTFTが悪化した後にエラーやタイムアウトのリスクが生じる。これを防ぐには、min_replicasで余裕を持たせるか、高いターゲットで余剰容量を維持するポリシーを設定する必要がある。また、ロールアウト中はオートスケーリングの上下限が固定され、スケールダウンによるレプリカ数変更がロールアウトを妨げないようになっている。

スケールダウンウィンドウがトラフィックの自然なリズムより短いと、レプリカ数のグラフがのこぎり波状になる。バーストごとにスケールダウンとコールドスタートを繰り返すからだ。この場合はスケールダウンウィンドウを広げるのが対策となる。また、min_replicasを0に設定するだけではゼロへのスケールダウンはできず、minとmaxを両方0にするとデプロイメントが停止して課金も止まる。ただし、自動で復帰することはなく、停止中のデプロイメントへのリクエストはエラーを返す。本番のp95 SLOを守る必要がある場合は、min_replicasを1にしておくべきだ。