推論モデルへの移行を、モデル名だけでサイジングしてはいけない

なぜ古いサイズを再利用せず、測り直すのか

再利用の反射は、モデル名がサイズを運ぶと仮定します——うまくいっている gpt-4o の数値を、ファミリーの乗数でスケールすれば、GPT-5.x にも なお収まる、と。それを受け入れる前に、二つのことを並べておく価値があります。 一つ目はドキュメントが規定していることです。Microsoft Learn は、ピーク RPM、 平均プロンプトと出力トークン、キャッシュ率、モデルの出力対入力比、そして PTU あたり Input TPM から、トラフィックを正規化 TPM に変換し、キャッシュ済み プロンプトトークンを利用率から差し引きます。OpenAI は推論トークンを、 output_tokens_details.reasoning_tokens に報告される、表示されない 出力側のトークンとして文書化しています。二つ目は本リポジトリの例示的な計算で、 その文書化された式を一つの呼び出しの形の例に走らせ、サイズを動かす要因を 並べて見せます——どのデプロイの測定でもありません。

立ち止まる価値があるのは、その対の部分です。可視出力だけで読むと、移行は 扱いやすく見えます——同じプロンプトと同じ可視の答えは、新しいモデルでおおむね 同じ水準か、わずかに軽くサイジングされることさえあります。しかし可視の答えは リクエストのすべてではありません。隠れた推論出力が現れると、同じ答えがはるかに 多くの正規化 TPM を必要としうるのです。そして本リポジトリの作業仮説——文書化 されたプラットフォームの挙動ではなく、検証すべきアドミッションリスク——は、 過大な max_output_tokens の上限が、それらのトークンが実際に生成 されるかどうかにかかわらず、アドミッションの重みを予約しうる、というものです。 だから運用上の問いは「新しいモデルは重いか」ではなく、「測定したリクエストの 形——可視出力、推論出力、キャッシュ率、応答上限——は実際に何を予約するのか」 です。正規化 TPM の式、モデル別の表、キャッシュの差し引き、推論トークンの会計は Microsoft Learn と OpenAI が文書化しているものです。過大な max_output_tokens を検証すべき PTU のアドミッションリスクとして 扱うのは、本リポジトリが擁護する運用上の推論です。続くチャートは、ピン留め した価格スナップショットを伴うモデル化されたワークロード上の合成された計算例 です——測定された容量でも、稼働中の PTU スループットでも、SLA でもありません。 下の例示チャートがサイズを動かす要因を明示します。

公式の挙動 · 正規化 TPM

サイジング計算式はトークンの形に関するものである

Microsoft Learn は、トラフィックを正規化 TPM に変換することで PTU 需要を サイジングします。入力となるのは、ピーク RPM、平均プロンプトトークン、 平均生成出力トークン、キャッシュ率、モデルの出力対入力比、そして モデルの PTU あたり Input TPM 値です。

この計算式があるからこそ、ファミリーレベルの近道は誤解を招きます。あるモデルは 出力比がより重くても、前のモデルより高い PTU あたり Input TPM を持つことが あり得ます。答えは、あなたのワークロード実際のプロンプト・出力・キャッシュ プロファイルに依存します。

運用の視点 · 移行で何が変わるか

移行が適合するかを決めるのは 4 つの要因

例示的な計算 · 同一の可視ワークロード

隠れた出力が答えを変え得る

運用者チェックリスト · 容量を確保する前に再測定する

移行を、名称変更ではなく測定として実行する

1. タスク構成を固定してください。 プロンプト・ツール・スキーマ・検索の配置・サンプル分布を、各モデル設定間でバイト単位で安定させてください。
2. 可視出力を測定してください。 移行前後で可視出力トークンの平均と p95 を比較してください。
3. 推論出力を測定してください。 reasoning_tokens を取得してください。最終的な答えのテキストから推測しないでください。
4. キャッシュ率を測定してください。 特に ReAct やツールスキーマの変更後は、キャッシュキーのバケットごとに cached_tokens / prompt_tokens を記録してください。
5. 上限を適正化してください。 代表的な「可視 + 推論」のパーセンタイルから max_output_tokens を設定し、まれな長文の答えにはコールごとのオーバーライドを用いてください。
6. そのうえで初めて PTU をサイジングしてください。 現行のモデル表と実測したワークロードの形を用いて、正規化 TPM 計算式を適用してください。

出典と根拠の境界

Tier 1 — サービス契約（Microsoft Learn と OpenAI）。 正規化 TPM のサイジング式、モデル別の PTU あたり Input TPM と出力対入力比、GPT-4.1 以降の出力トークンの重み付け、利用率からの 100% キャッシュ差し引き、そして 推論トークンの会計が、ここに文書化されています。

• [1] Determine PTU sizing for a workload — 正規化 TPM の計算 （Input TPM = ピーク RPM × プロンプトサイズ、Output TPM = ピーク RPM × 応答サイズ、Normalized TPM = input TPM × (1 − キャッシュ率) + 出力対入力比 × output TPM、PTU = normalized TPM ÷ PTU あたり Input TPM）、モデル別の PTU あたり Input TPM と出力対入力比の値、そしてキャッシュ済みトークンが利用率の 計算から 100% 差し引かれることを定義しています。出典：Microsoft Learn ドキュメント（2026-06-05 アクセス）· アーカイブ。
• [2] What is provisioned throughput for Foundry Models? — PTU の 利用率モデルと、リクエストの形が予約済み容量をどう消費するかを文書化して います。出典：Microsoft Learn ドキュメント（2026-06-04 アクセス）· アーカイブ。
• [3] Prompt caching with Azure OpenAI — キャッシュ済みプロンプト トークンが利用率から差し引かれるため、プレフィックスの形の変化がサイジング 結果を動かすことを文書化しています。出典：Microsoft Learn ドキュメント（2026-06-04 アクセス）· アーカイブ。
• [4] OpenAI reasoning models guide — 推論トークンを、 output_tokens_details.reasoning_tokens に報告される、表示されない 出力側のトークンとして文書化しています。出典：OpenAI ドキュメント（2026-06-04 アクセス）· アーカイブ。

Tier 2 — 運用上の推論（本リポジトリ）。 過大な max_output_tokens を PTU のアドミッションリスクの仮説として扱う こと、そして推論トークンとキャッシュ済みトークンの測定契約は、本リポジトリの 運用上の推論であって Learn の仕様ではありません。

• [5] 本リポジトリ、docs/13-ptu-vs-payg-decision-runbook.md — mean_max_output_tokens を記録し、大きな max_output_tokens を、推測する値ではなく、検証すべき予約済み アドミッションの重みとして解釈します。出典。
• [6] 本リポジトリ、docs/14-observability-schema.md — reasoning_tokens、cached_tokens、 max_output_tokens_sent をそれぞれの元の usage フィールドに 対応づける、PTU レコードの正準的な契約。出典。

このトピックが証明するものとしないもの。 アクセス日時点で Microsoft Learn が明示する PTU サイジングの契約——正規化 TPM の式、モデル別の PTU あたり Input TPM と出力対入力比、GPT-4.1 以降の出力トークンの重み付け、 100% のキャッシュ差し引き——と、OpenAI の推論トークンの会計、そして本リポジトリの 経験則——サイジングの前に出力・推論・キャッシュ・上限を測り直す——を文書化します。 例示チャートは文書化された式を一つの呼び出しの形の例に適用したものです。これは 計算例であって容量の保証ではなく、特定の GPT-5.x のワークロードがすべての リージョン・モデルバージョン・トラフィック形状にわたって GPT-4o の前任より重いか 軽いかを証明するものではありません。