이 섹션에서는 토큰 수와 할당량 적용을 위해 Live API에서 프로비저닝된 처리량이 작동하는 방식을 설명합니다.
Live API는 세션을 통해 지연 시간이 짧은 멀티모달 상호작용을 지원합니다. 세션 메모리를 사용하여 세션 내 상호작용의 정보를 유지하고 다시 불러옵니다. 이를 통해 모델은 이전에 제공되거나 논의된 정보를 기억할 수 있습니다. 프로비저닝된 처리량은 Live API를 사용한 Gemini 2.5 Flash 모델을 지원합니다. 세션 한도 및 기능 등 Live API에 관한 자세한 내용은 Live API 참조를 참고하세요.
Live API의 처리량 계산
Live API를 사용하는 동안 세션 메모리에 저장된 토큰은 모델에 대한 후속 요청에서 사용할 수 있습니다. 따라서 프로비저닝된 처리량은 동일한 요청에서 수신 토큰과 세션 메모리 토큰을 모두 고려합니다. 이로 인해 요청당 처리되는 토큰 수가 진행 중인 요청에서 사용자가 보낸 토큰 수보다 많아질 수 있습니다.
Live API에는 세션 메모리에 저장할 수 있는 총 토큰 수에 제한이 있으며 총 토큰 수가 포함된 메타데이터 필드도 있습니다. 요청을 처리하는 데 필요한 처리량을 계산할 때는 세션 메모리의 토큰을 고려해야 합니다.
사용량 기반 요금제 (PayGo)로 Live API를 사용한 경우 이러한 트래픽 패턴과 세션 토큰을 사용하여 프로비저닝된 처리량 요구사항을 추정할 수 있습니다.
Live API의 프로비저닝된 처리량 요구사항을 추정하는 방법의 예
세션 중에 모든 트래픽은 프로비저닝된 처리량 또는 종량제로 처리됩니다. 세션 중에 프로비저닝된 처리량 할당량에 도달하면 나중에 다시 시도하라는 오류 메시지가 표시됩니다. 할당량 내에 있으면 요청 전송을 재개할 수 있습니다. 세션 메모리를 비롯한 세션 상태는 세션이 라이브 상태인 동안 사용할 수 있습니다.
이 예시에서는 세션 메모리의 토큰을 포함하여 연속된 두 요청이 처리되는 방식을 보여줍니다.
요청#1 세부정보
재생 시간: 10초
전송된 토큰 (오디오): 10초 x 25토큰/초 = 250토큰
전송된 토큰 (동영상): 10초 x 초당 프레임당 258개 토큰 = 2,580개 토큰
요청 1에 대해 처리된 총 토큰 수:
전송된 토큰: 전송된 오디오 및 동영상 토큰의 합계 = 2,580 + 250 = 2,830개
세션 메모리에 추가 토큰이 없으므로 요청 1은 진행 중인 요청의 입력 및 출력 토큰만 처리합니다.
요청 2는 진행 중인 요청의 입력 및 출력 토큰을 처리하지만 세션 메모리의 입력 토큰도 포함합니다. 세션 메모리의 입력 토큰은 이전 요청(요청 1)의 입력 토큰으로 구성됩니다. 세션 메모리의 토큰 소진율은 표준 입력 토큰의 소진율과 동일합니다(입력 세션 메모리 토큰 1개 = 입력 토큰 1개).
요청 2를 보낸 후 처리하는 데 정확히 1초가 걸린 경우 토큰은 다음과 같이 처리되어 프로비저닝된 처리량 할당량에 적용됩니다.
입력에 소진율을 곱하여 총 입력 토큰을 구합니다.
2,830 x (세션 메모리 토큰당 1개 토큰) + 1,000 x (입력 텍스트 토큰당 1개 토큰) = 쿼리당 3,830개의 소진 조정 입력 토큰
출력에 소진율을 곱하여 총 출력 토큰을 구합니다.
200 x (오디오 출력 토큰당 6개 토큰) = 1,200개 토큰
다음 두 합계를 더하여 처리된 총 토큰 수를 구합니다.
3,830개 토큰 + 1,200개 토큰 = 5,030개 토큰
프로비저닝된 처리량 할당량이 초당 5,030개 이상의 토큰인 경우 이 요청은 즉시 처리될 수 있습니다. 이보다 적으면 할당량에 설정된 비율로 시간이 지남에 따라 토큰이 처리됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Provisioned Throughput for Live API\n\n| **Request access:** For information about access to this release, see the [access request page](https://docs.google.com/forms/d/e/1FAIpQLScxBeD4UJ8GbUfX4SXjj5a1XJ1K7Urwvb0iSGdGccNcFRBrpQ/viewform).\n\nThis section explains how Provisioned Throughput works with the\nLive API for token counting and quota enforcement.\n\nThe Live API supports low-latency multimodal interactions through\nsessions. It uses a session memory to retain and recall information from\ninteractions within a session. This lets the model recall previously provided or discussed information. Provisioned Throughput supports\nthe Gemini 2.5 Flash with Live API model. For more\ninformation about the Live API, including session limits and\ncapabilities, see the\n[Live API reference](/vertex-ai/generative-ai/docs/model-reference/multimodal-live).\n\nCalculate throughput for Live API\n---------------------------------\n\nWhile using the Live API, the tokens stored in the session memory\ncan be used in subsequent requests to the model. As a result, Provisioned Throughput\ntakes into account the incoming tokens as well as session memory tokens in the\nsame request. This might lead to the number of tokens being processed per request\nbeing greater than the tokens sent by the user in the ongoing request.\n\nThe Live API has a limit on the total tokens that can be stored in\nthe session memory and also has a metadata field containing the total number\nof tokens. While calculating how much throughput is needed to serve your requests,\nyou must account for tokens in the session memory.\nIf you've used the Live API with pay-as-you-go (PayGo), you can\nuse these traffic patterns and session tokens to help estimate your\nProvisioned Throughput needs.\n\n### Example of how to estimate your Provisioned Throughput requirements for Live API\n\nDuring a session, all traffic is processed either as\nProvisioned Throughput or pay-as-you-go. If you reach your\nProvisioned Throughput quota during a session, you'll receive an\nerror message requesting that you try again later. Once you're within your quota,\nyou can resume sending requests. The session state, including the session memory,\nare available as long as the session is live.\n\nThis example illustrates how two consecutive requests are processed by\nincluding the tokens from the session memory.\n\n#### Request#1 details\n\n**Duration**: 10 seconds\n\n**Tokens sent (audio)**: 10 seconds x 25 tokens/second = 250 tokens\n\n**Tokens sent (video)**: 10 seconds x 258 tokens/frame per second = 2580 tokens\n\n**Total tokens processed for Request#1**:\n\n- **Tokens sent**: Sum of audio and video tokens sent = 2580+250 = 2830 tokens\n- **Tokens received**: 100 (audio)\n\n#### Request#2 details\n\n**Duration**: 40 seconds\n\n**Tokens sent (audio)**: 40 seconds x 25 tokens/second = 1000 tokens\n\n**Total tokens processed for Request#2**:\n\n- **Tokens sent**: Tokens sent in Request#2 + session memory tokens from Request#1 = 2830 tokens + 1000 tokens = 3830 tokens\n- **Tokens received**: 200 (audio)\n\n#### Calculate the number of tokens processed in the requests\n\nThe number of tokens processed during these requests is calculated, as follows:\n\n- Request#1 processes only the input and output tokens from\n the ongoing request, as there are no additional tokens in the session\n memory.\n\n- Request #2 processes the input and output tokens from\n the ongoing request, but also includes the input tokens from the\n session memory, consisting of the input tokens from the preceding request\n (Request #1) from the session memory. The burndown rate for tokens in the session\n memory is the same as that for standard input tokens\n (1 input session memory token = 1 input token).\n\n If Request#2 took exactly 1 second to process after you sent it,\n your tokens are processed and applied to your Provisioned Throughput quota, as follows:\n - Multiply your inputs by the burndown rates to get the total input tokens:\n\n 2830 x (1 token per session memory token) + 1000 x (1 token per input text token) = 3830 burndown adjusted input tokens per query\n - Multiply your outputs by the burndown rates to get the total output tokens:\n\n 200 x (6 tokens per audio output token) = 1,200 tokens\n - Add these two totals to get the total number of tokens processed:\n\n 3,830 tokens + 1,200 tokens = 5,030 tokens\n\nIf your Provisioned Throughput quota is greater than 5,030 tokens\nper second, then this request can be processed immediately. If it's less, the\ntokens are processed over time at the rate that you've set for your quota.\n\nWhat's next\n-----------\n\n- [Purchase Provisioned Throughput](/vertex-ai/generative-ai/docs/purchase-provisioned-throughput)."]]