> ## Documentation Index
> Fetch the complete documentation index at: https://phaseo.app/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# 料金と性能を測る
> 観測データを管理されたベンチマークとみなさずに、プロバイダーの料金と Gateway の運用性能を比較します。
このガイドでは、ルートごとのコストと速度の比較、Phaseo が表示する指標の理解、本番トラフィックを切り替える前のワークロード調査の設計方法を説明します。
## 判断したいことから始める
守りたいユーザー体験に合った指標を選びましょう。
| ワークロード | 最初に見る指標 | 理由 |
| - | - | - |
| チャット、コパイロット、音声 | Gateway TTFT | ユーザーは、有用な出力が始まるまでの速さに気づきます。 |
| 長文回答とコード生成 | Output speed | 長い応答では、生成速度を維持できるかが大きく影響します。 |
| ツールと構造化ワークフロー | Gateway E2E | ルーティング、再試行、オーケストレーションが全体の結果に影響します。 |
| バッチ処理やオフライン処理 | コストと実効スループット | 総スループットと費用を重視する場合は、開始が遅くても許容できることがあります。 |
単一のスコアだけで、あらゆるワークロードに最適なモデルだとは判断できません。
## 料金を比較する
プロバイダーの料金表では、トークン、100 万トークン、画像、秒、分、リクエスト単位などが使われます。Phaseo は元の単位を保持し、カタログ表示や料金計算ツールで比較できるよう料金を正規化します。
テキストモデルでは、入力、キャッシュ入力、キャッシュ書き込み、推論、出力の料金がある場合、それぞれ分けて比較します。メディアモデルでは元の課金単位を表示し、動画の秒単価をトークン単価のように示さないでください。
カタログ料金はリクエストの見積もりに使うもので、あらゆるペイロードに対する確定料金ではありません。プロバイダーの階層、地域別オファー、バッチ料金、キャッシュの動作、リクエスト固有の課金項目によって最終額は変わります。
代表的なペイロードで[料金計算ツール](https://phaseo.app/tools/pricing-calculator)を使い、テストリクエスト後に Gateway の使用状況で請求額を確認してください。
## 性能指標を理解する
PhaseoはGateway経由でルーティングされたリクエストの運用上の所要時間を記録します。
| 指標 | 定義 |
| - | - |
| **Gateway TTFT** | Gateway リクエストの開始から、コンテンツを含む最初の生成出力まで。 |
| **Provider TTFT** | 選択したプロバイダーへの送信から、コンテンツを含む最初の生成出力まで。 |
| **Provider duration** | 選択したプロバイダーへの送信から最終応答まで。 |
| **Gateway E2E** | Gateway リクエストの開始から完了まで。 |
| **Phaseo overhead** | `max(0, Gateway E2E - provider duration)`. |
| **Effective throughput** | すべての出力トークン数をプロバイダー処理時間全体で割った値。 |
| **Output speed** | 最初の出力後の出力トークン数を、TTFT 後のプロバイダー処理時間で割った値。 |
| **TPOT / ITL** | 最初の出力後における、リクエスト単位のトークンあたり平均時間。 |
TTFT、出力速度、TPOT、ITL の計測には、最初の出力にコンテンツを含むストリーミング応答が必要です。 メタデータだけのストリームフレームは対象になりません。 非ストリーミング応答でも、架空の TTFT を設定せずにプロバイダー処理時間、Gateway E2E、有効スループットの算出に利用できます。
Phaseo オーバーヘッドは、選択したプロバイダーの呼び出し以外にかかった時間を切り分けます。 Gateway の処理、ルーティング、再試行、ネットワークの影響が含まれる場合があります。 固定されたプラットフォーム定数ではなく、定義した期間における分布として読み取ってください。
## 運用データを正しく読み取る
性能ページには、Gateway の実際のトラフィックが集計されています。 これは観測に基づく測定であり、管理されたベンチマーク実行でもモデル固有の特性でもありません。
結果は次の要因で変動します。
* プロバイダーとルートの選択
* Cloudflare の実行場所とネットワーク経路
* プロバイダーのキューや地域負荷
* プロンプトと出力の長さ
* ストリーミングか非ストリーミングか
* 再試行、キャンセル、ツール呼び出し
* 選択した期間中のモデルまたはプロバイダーの更新
公開グラフには、P50、P90、P95、P99 などのパーセンタイルが表示されることがあります。 レイテンシは低いほど優れています。 スループットは高いほど優れているため、低いスループットのパーセンタイルは遅い側の裾を表します。
結果の横に、選択した期間、ルート、地域、サンプルフィルター、パーセンタイルを必ず記録してください。 期間が異なるスクリーンショットを同じ調査結果として比較しないでください。
## 再現可能なワークロード調査を実施する
公開テレメトリで候補を絞り込み、最終候補を独自のプロンプト構成で検証します。
1. 既定の `GET /v1/models` レスポンスから、ルーティング可能なモデルを 2～3 個選びます。
2. 短いリクエスト、典型的なリクエスト、長いリクエストを含む、機密情報を除いたプロンプトセットを作成します。
3. エンドポイント、地域、ストリーミングモード、プロバイダー制約、同時実行数を固定します。
4. 1 回のサンプルに頼らず、各プロンプトでリクエストを繰り返します。
5. リクエスト ID、選択されたプロバイダー、成功またはエラー、出力トークン数、Gateway TTFT、プロバイダー処理時間、Gateway E2E、Phaseo オーバーヘッド、コストを記録します。
6. 分布と障害の種類を比較し、生データをテスト構成とともに保存します。
結果スキーマの例:
```json theme={null}
{
"study_id": "support-summary-v1",
"model": "",
"endpoint": "responses",
"stream": true,
"region": "",
"request_id": "req_...",
"gateway_ttft_ms": 0,
"provider_duration_ms": 0,
"gateway_e2e_ms": 0,
"phaseo_overhead_ms": 0,
"output_tokens": 0,
"cost_usd": 0,
"status": "completed"
}
```
0 の値はプレースホルダーです。測定値を公開する場合は、ワークロードの定義、サンプル数、期間、データ公開の許可を必ず併記してください。
## Phaseo が主張しないこと
* カタログに掲載されていても、そのモデルにルーティングできるとは限りません。既定の有効な利用可能性フィルターを使ってください。
* 公開運用テレメトリは、将来のレイテンシや稼働時間を保証するものではありません。
* ベンチマークスコアだけでは、独自のプロンプト構成で本番品質を満たすとは判断できません。
* 画面に表示される例示的なプロファイルは、モデルの実測値ではありません。
* 顧客のコメント、ロゴ、ワークロード結果は、許可と裏付け資料なしに公開しないでください。
## 次のステップ
インシデント、モデルの現在のルーティング可否、指標の定義、障害対応を確認できます。
料金、メタデータ、利用可能なパフォーマンス指標を並べて比較します。
1 つのモデルについて、プロバイダーのルート、機能、利用可能状況、料金を確認できます。
ベンチマークの情報源やスコアが Gateway のテレメトリとは別に正規化される方法を確認できます。
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.