専用モデル推論の設定

Together AIの専用モデル推論プラットフォームは、エンドポイント、デプロイメント、設定の3つのコアコンポーネントで構成されています。エンドポイントはクライアントが呼び出す固定の名前（例：「プロジェクト名/エンドポイント名」）で、アプリケーションコードでモデルパラメータとして渡されます。デプロイメントは特定のモデルリビジョンと設定をバインドし、自動スケーリングポリシーを持ち、実際のレプリカを実行します。デプロイメントは使い捨て可能で、作成と破棄は日常的な操作です。設定は不変のレシピであり、エンジン、GPUタイプと数、並列度、最適化目標（レイテンシ/スループット/バランス）を指定します。各設定には一意のcr_ IDがあり、デプロイメントはテスト済みの設定を常に指します。

これら3つは、容量認識トラフィックスプリットによって連携します。トラフィックスプリットは、デプロイメントIDと重みのリストです。重みはレプリカあたりの重みで、ルーターは各デプロイメントの有効容量（重み×準備完了レプリカ数）を計算し、比例配分します。たとえば、デプロイメントAの重み1、準備完了レプリカ1（容量1）、デプロイメントBの重み1、準備完了レプリカ3（容量3）の場合、トラフィックは25%/75%に分割されます。この設計により、スケーリングとルーティングが自然に連携します。Aが1レプリカから3レプリカにスケールアップすると、容量が3倍になり、自動的に対応するトラフィックを吸収します。重みは任意の正数で、合計の制約はなく、0.7/0.3と700/300は同等です。固定のシェアが必要な場合は、A/B実験の整数パーセント（合計100%）を使用できます。

デプロイメントがスプリットに含まれていても準備完了レプリカが0の場合、容量は0となり、トラフィックは他の利用可能なデプロイメントに流れます。デプロイメントを削除する前に、まずスプリットから削除する必要があります。また、シャドウ実験（重み0のデプロイメントにミラートラフィックを送信）やロールバックもサポートしています。

ユーザーは設定をゼロから記述する必要はありません。サポート対象モデルカタログには、認定されたデプロイメントプロファイルが用意されており、GPUタイプ、数、量子化精度、パフォーマンスベンチマークが含まれます。ユーザーはアクセラレータタイプ、数、最適化目標、トポロジに基づいて設定を選択できます。最適化目標は最も頻繁に選択される軸です。レイテンシプロファイルは最初のトークンまでの時間を最適化し、インタラクティブなチャットに適しています。スループットプロファイルはGPU時間あたりの総トークン数を最大化し、オフラインバッチ処理に適しています。バランスはトラフィックが混在する場合の良いデフォルトです。

設定は不変であるため、「フラグをちょっと調整した」という理由で動作が変化することはなく、古い設定はテスト済みのロールバックターゲットとして残ります。投機的デコードも設定のドラフトモデルプロパティを介してトリガーできます。

記事では、容量認識ルーティングを検証する実験も紹介されています。2つのデプロイメント（各重み1、初期各1レプリカ）は約50/50のトラフィックを処理し、Aを2レプリカにスケールアップすると約66.7/33.3になり、理論と一致しました。パフォーマンス比較では、異なる設定は異なる同時実行レベルで劇的に異なる動作を示します。例えば、設定A（Qwen3.5-9B, BF16, TP1）は同時実行4で362 tok/s、同時実行16で1464 tok/s、TTFT p95は368msでした。設定B（Qwen3-VL-8B, BF16, TP1）は同時実行4で495 tok/sですが、同時実行16では240 tok/sに低下し、TTFT p95は323msでした。Bは低同時実行で勝りますが、高同時実行で急激に劣化します。実際のテストを通じて設定を選択することを推奨しています。

最後に、クイックスタートの5つのコマンドを示しています：tg whoami、tg beta models public --product dedicated、tg beta endpoints deploy、クライアントからの呼び出し、tg beta endpoints get。これ以降は、さらに1つのデプロイメントを追加するだけです。