プロバイダー比較
deepinfraとTogether AIのどちらを選ぶべきかは、実際に使用するモデル、ワークロード、トラフィックによって異なります。DeepinfraもTogether AIも推論の候補になります。アプリケーションを移行する前に、同じリクエストで比較してください。
deepinfraとTogether AIを比較する際は、月額費用を見積もる前に、各プロバイダーで対象モデルと最新の利用条件を確認してください。公開料金だけでは、ワークロードにかかるすべてのコストは把握できません。
| Deepinfra | Together AI | |
|---|---|---|
| モデルの選択 | 必要なモデルとバージョンがあるか、Deepinfraのカタログで確認してください。 | 同じモデルとバージョンがあるか、Together AIのカタログで確認してください。 |
| 入力の使用量 | 測定したプロンプト使用量に、Deepinfraの最新の入力料金を適用してください。 | 同じ測定使用量に、Together AIの最新の入力料金を適用してください。 |
| 出力の使用量 | 実際の応答の長さを使って、出力コストを別途見積もります。 | 同じ応答の長さと、対応する出力料金を使用します。 |
| 長いリクエスト | 必要なコンテキスト長が利用可能か、またどのように課金されるかを確認します。 | 同等のコンテキストオプションとその課金条件を確認します。 |
| 失敗と再試行 | Deepinfraの試用で観測された再試行の挙動を含めます。 | Together AIの試用で観測された再試行の挙動を含めます。 |
| 導入作業 | Deepinfraを使用するために必要なコード、監視、プロンプトの変更をすべて算入します。 | Together AIを導入する場合も、同じ作業を算入します。 |
| 実質的な月額コスト | 測定したリクエスト構成と現在の条件に基づいて計算します。 | まったく同じリクエスト構成と現在の条件に基づいて計算します。 |
プロバイダー名は品質スコアではありません。同一の入力から始め、各サービスがタスクに必要なモデルのバージョンと設定を提供しているかを確認します。
利用可能なモデルが評価セットで安定した結果を出すなら、有力な候補になります。
適している点
トレードオフ
対応するモデルと設定が同じ品質基準を満たすなら、有力な候補になります。
適している点
トレードオフ
レイテンシーには複数の意味があります。対話型アシスタントでは最初のトークンが表示されるまでの時間が重要ですが、バッチジョブでは処理全体の完了時間が最も重要な場合があります。
選択肢 1
利用地域と通常のプロンプト長で、最初のトークンが出るまでの時間がより安定しているプロバイダーを選びましょう。
同じモデルとプロンプトを、1日のうち複数の時間帯にDeepinfraとTogether AIで実行します。中央値だけでなく、極端に遅いケースも記録してください。平均でわずかに速いことより、時折発生する長い待ち時間のほうが重要な場合があります。
選択肢 2
必要な同時実行数でバッチ全体を確実に完了できるプロバイダーを選びましょう。
総所要時間、完了したリクエスト数、再試行回数、レスポンスの長さを合わせて測定します。負荷が高まると失敗が増えるなら、個々のレスポンスが速くても必ずしも優れているとは限りません。
選択肢 3
代替プロバイダーで意味のある、再現可能な改善が確認できない限り、現状を維持しましょう。
プロンプトの再テスト、リクエスト処理の更新、結果の監視に必要な時間も考慮してください。所要時間がわずかに短くなるだけでは、安定したワークフローを変更する価値はないかもしれません。
プロバイダーの選択は、利用可能なモデル、現在の料金、ほかに何と比較するかによっても変わります。
条件に合うモデルが品質基準を満たし、測定したコスト、レイテンシー、信頼性のいずれかで有意な改善が得られる場合は、切り替えを検討してください。Deepinfraの現在の結果がすでに要件を満たし、実際のトラフィックに近い条件ではTogether AIの優位性がなくなるなら、Deepinfraを使い続けてください。逆の場合はTogether AIを使い続けてください。どちらにも明確な優位性がない場合は、全面的に移行するより、小規模な試験運用のほうが安全です。プロンプト一式を維持し、現在の利用条件を記録して、成功した応答と同じくらい慎重に失敗も比較してください。
すべてのモデルとリクエストに当てはまる、プロバイダー全体での答えはありません。対象モデルについて各プロバイダーの現在の利用条件を確認し、実際の利用を反映したプロンプトのサンプルから入力と出力の使用量を計算してください。
必ずしもそうではありません。まずモデルのバージョンと生成設定を確認し、1つの応答ではなく複数の出力を比較してください。サンプリングやサービス側の動作によって違いが生じることもあります。
アプリケーションを実行する場所から両方をテストしてください。同じモデル、プロンプトの長さ、応答の上限を使い、最初のトークンが出るまでの時間、応答全体にかかる時間、極端に遅いケースを比較します。
現在のプロバイダーでの品質、コスト、レイテンシー、失敗の基準値を記録します。同じワークロードを代替プロバイダーでも実行し、再現性のある改善が、統合作業や再テストに見合うかを判断してください。
はい。ただし、プロバイダーを統制条件下で比較するテストではなく、選択肢全体の比較として扱ってください。各選択肢をタスクで求められる出力に照らして評価し、結果を解釈する際はモデルの違いを明示してください。