役立つメンタルモデル
出力トークンは、回答の一部であると同時に、回答を作成するためのステップでもあると考えてください。
テキストモデルは、完全な返信を裏側で書いてからトークンに分割するわけではありません。返信を一度に1トークンずつ構築します。各トークンの後、増加した系列が次のトークンを選ぶために使われる情報の一部になります。
この違いから、長い回答の生成には短い回答より時間がかかることが分かります。出力トークンが1つ増えるたびに、生成ステップがもう1つ必要になります。
出力トークンの生成方法
モデルは入力を処理した後、次に来る可能性のあるすべてのトークンにスコアを割り当てます。生成設定によって、それらの候補のうちどれを選ぶかが決まります。選択されたトークンが系列に追加され、モデルはこの処理を繰り返します。
process the input
|
v
score possible next tokens
|
v
choose one output token ----+
| |
v |
append it to the sequence --+
|
v
stop when a stopping condition is metこのループは、次の理由で終了します。
- モデルが自然な終端に達した場合
- 設定された停止シーケンスを生成した場合
- 出力トークン上限に達した場合
- ツール呼び出しなどのアクションに切り替えた場合
- サービスがモデル固有またはポリシー固有の別の停止条件を適用した場合
正確なトークン数は、モデルのトークナイザーによって決まります。短い単語は1トークンの場合があります。長い単語やなじみの薄い単語は、複数のトークンになる場合があります。スペース、句読点、コード、英語以外のテキストも異なる分割になることがあります。そのため、文字数や単語数から出力の長さを推定することはできますが、正確に決定することはできません。
出力トークンに含まれるもの
通常のテキスト応答では、表示される返信が生成された出力トークンから形成されます。生成されたJSONやツール呼び出しの引数もモデルの出力です。アプリケーションがそれらを生のテキストとして表示せず、インターフェース上のアクションとして表示する場合も同様です。
プロバイダーの使用量カテゴリーによって、もう1つの側面が加わります。「出力トークン」は、表示される生成系列を指す場合もあれば、計測された合計を指す場合もあります。これらの合計方法は標準化されていません。
- 生成されたトークンを完了トークンと呼ぶAPIもあります。
- 隠れた推論を出力合計に含め、別の内訳として提供するAPIもあります。
- 表示される候補トークンと思考トークンを別々のフィールドで報告するAPIもあります。
- 特殊な出力タイプには、固有の詳細や課金ルールが適用される場合があります。
特定のリクエストについて信頼できる情報源は、そのプロバイダーとエンドポイントが返す使用量データです。表示された応答をトークナイザーにそのまま入力するだけで、課金対象の出力を推測しないでください。現在のOpenAI、Anthropic、およびGoogleのドキュメントを見ると、ラベルや内訳が異なる理由が分かります。
具体例
出力トークンの最大数を100とするAPIリクエストを考えてみましょう。
モデルが完全な回答を生成し、24トークンで停止したとします。使用量データは次のように報告します。
{
"input_tokens": 18,
"output_tokens": 24,
"total_tokens": 42
}出力トークン数は24です。100トークンという設定は単なる上限でした。モデルに100トークンの生成を強制したわけではなく、それだけで100トークンが課金されたことを意味するわけでもありません。
次に、モデルが100トークンの上限に達するまで生成を続けたとします。この場合も、APIは技術的には正常なレスポンスを返せますが、回答が文の途中や構造の途中で終わる可能性があります。本番アプリケーションでは、返されたテキストが完全だと想定せず、レスポンスの停止理由を確認する必要があります。
さらに、もう1つ注意点があります。推論モデルは、表示される回答の前に内部推論を生成する場合があります。プロバイダーによっては、使用量にそれらの隠れたトークンをoutput_tokensとして含める場合もあれば、別の思考フィールドで報告する場合もあります。したがって、表示される回答と計測される出力では、トークン数が異なることがあります。
出力トークンが重要な理由
コスト
トークン単位で価格設定されるサービスでは、通常、入力と出力を別々に計測し、料金も異なる場合があります。したがって、各リクエストのコストには、要求した上限だけでなく実際の出力使用量も関係します。プロバイダー固有のクォータシステムでは、課金に実際の生成量を使う場合でも、上限に基づいて一時的に容量を確保することがあります。
応答時間
出力トークンは順番に生成されます。一般に、出力が多いほど生成ステップが増え、完全な応答を待つ時間も長くなります。ストリーミングを使えば部分的な出力を早く表示できますが、残りのトークンの生成に必要な処理がなくなるわけではありません。
完全性
出力上限は長さの制御に役立ちますが、上限が低すぎると、文章、コード、JSON、またはツール引数が途中で切れる可能性があります。完全性が重要な場合は、停止理由を確認してください。
利用可能なコンテキスト
入力と出力はどちらも、モデルのコンテキストウィンドウの容量を消費します。利用可能な容量の大部分を入力に使うリクエストでは、モデルとエンドポイントの制限および計算ルールに応じて、生成に使える容量が少なくなる場合があります。
よくある誤解
「出力トークンは単語と同じ」
同じではありません。トークンは、単語全体、単語の一部、句読点、スペース、その他の単位になることがあります。同じ文でも、トークナイザーが異なればトークン数は変わります。
「最大出力設定は予想される出力量である」
最大出力設定は上限です。モデルはその上限に達する前に停止できます。また、プロバイダーがより低いモデル上限や、内部推論を含む共有予算を適用する場合もあります。
「APIがテキストを返したなら、回答は完全である」
必ずしもそうとは限りません。出力上限に達すると、長さに関係する停止理由とともに部分的なテキストが返されることがあります。これは特にコードや構造化データで重要です。閉じ括弧などの文字が1つ欠けるだけで、結果が使えなくなる可能性があるためです。
「表示される応答は課金対象の出力と同じである」
多くの場合はそうですが、常にそうとは限りません。隠れた推論、複数の生成候補、またはエンドポイント固有の計算方法によって、使用量が表示されるテキストより多くなることがあります。そのサービスでは、返された使用量フィールドを信頼できる情報として扱ってください。
「出力の長さはプロンプトによって固定される」
プロンプトは長さに影響しますが、生成は依然として条件付きです。モデルの挙動、サンプリング設定、停止シーケンス、ツールの使用、安全性に関する挙動によって、出力がどこで終わるかは変わります。
モデルのリクエストにおける出力トークンの位置付け
リクエストは入力トークンから始まります。次に、モデルが出力トークンを生成します。推論モデルでは、内部の推論トークンも使用される場合があり、その報告方法や課金上の扱いはプロバイダーによって異なります。
この区別は、入力トークン・出力トークン・推論トークンの比較で横並びにすると最も分かりやすくなります。サービングの挙動を測定する場合、出力生成は1秒あたりのトークン数や推論レイテンシとも直接関係します。
実務上のルールは簡単です。妥当な出力上限を設定し、実際の使用量を読み取り、応答を完全なものとして扱う前に停止理由を確認してください。