Bagian ini menjelaskan cara kerja Throughput yang Disediakan dengan Gemini Live API untuk penghitungan token dan penerapan kuota.
Gemini Live API mendukung interaksi multimodal latensi rendah melalui sesi. Fitur ini menggunakan memori sesi untuk menyimpan dan memanggil kembali informasi dari interaksi dalam sesi. Hal ini memungkinkan model mengingat informasi yang sebelumnya diberikan atau dibahas. Throughput yang Disediakan mendukung model Gemini 2.5 Flash dengan Gemini Live API. Untuk mengetahui informasi selengkapnya tentang Gemini Live API, termasuk batas dan kemampuan sesi, lihat referensi Gemini Live API.
Gemini Live API memerlukan sesi yang sepenuhnya didedikasikan untuk traffic Throughput yang Disediakan atau PayGo. Fitur ini tidak mendukung spillover traffic antara Throughput yang Disediakan dan PayGo dalam sesi yang sama. Jenis traffic yang ditetapkan di awal sesi akan berlanjut selama durasi sesi tersebut. Jika mencapai kuota Throughput yang Disediakan selama sesi aktif, Anda tidak akan mengalami pembatasan atau error. Sebagai gantinya, sistem akan membiarkan traffic melonjak sementara agar sesi dapat dilanjutkan, dengan semua penggunaan berikutnya dicatat terhadap kuota keseluruhan Anda. Lonjakan sementara ini dapat menyebabkan dasbor pemantauan Anda menampilkan penggunaan Throughput yang Disediakan (traffic khusus) di atas batas Anda. Untuk menghindari terlampauinya batas yang dialokasikan di tengah sesi, Anda harus membeli GSU yang cukup untuk mendukung perkiraan penggunaan Anda.
Pelimpahan didukung dari satu sesi ke sesi berikutnya. Jika Anda melampaui batas Throughput yang Disediakan setelah sesi berakhir, Anda dapat memulai sesi tambahan menggunakan PayGo. Apakah sesi diproses sepenuhnya sebagai Throughput yang Disediakan atau PayGo diputuskan di awal sesi. Sistem memeriksa header yang dikirim oleh pengguna, lalu memverifikasi apakah kuota Throughput yang Disediakan cukup untuk sesi tersebut. Jika kuota Throughput yang Disediakan yang tersedia tidak cukup untuk memproses seluruh sesi, kuota PayGo akan digunakan.
Menghitung throughput untuk Gemini Live API
Saat menggunakan Gemini Live API, token yang disimpan dalam memori sesi dapat digunakan dalam permintaan berikutnya ke model. Akibatnya, Throughput yang Disediakan memperhitungkan token masuk serta token memori sesi dalam permintaan yang sama. Hal ini dapat menyebabkan jumlah token yang diproses per permintaan lebih besar daripada token yang dikirim oleh pengguna dalam permintaan yang sedang berlangsung.
Gemini Live API memiliki batas pada total token yang dapat disimpan dalam memori sesi dan juga memiliki kolom metadata yang berisi total jumlah token. Saat menghitung jumlah throughput yang diperlukan untuk melayani permintaan Anda, Anda harus memperhitungkan token dalam memori sesi. Jika telah menggunakan Gemini Live API dengan model bayar sesuai penggunaan (PayGo), Anda dapat menggunakan pola traffic dan token sesi ini untuk membantu memperkirakan kebutuhan Throughput yang Disediakan.
Contoh cara memperkirakan persyaratan Throughput yang Disediakan untuk Gemini Live API
Selama sesi, semua traffic diproses sebagai Throughput yang Disediakan atau bayar sesuai penggunaan.
Status sesi, termasuk memori sesi, tersedia selama sesi berlangsung.
Contoh ini menggambarkan cara dua permintaan berurutan diproses dengan menyertakan token dari memori sesi.
Detail permintaan#1
Durasi: 10 detik
Token yang dikirim (audio): 10 detik x 25 token/detik = 250 token
Token yang dikirim (video): 10 detik x 258 token/frame per detik = 2.580 token
Total token yang diproses untuk Request#1:
- Token yang dikirim: Jumlah token audio dan video yang dikirim = 2580+250 = 2830 token
- Token yang diterima: 100 (audio)
Detail permintaan#2
Durasi: 40 detik
Token yang dikirim (audio): 40 detik x 25 token/detik = 1.000 token
Total token yang diproses untuk Permintaan#2:
- Token yang dikirim: Token yang dikirim dalam Permintaan#2 + token memori sesi dari Permintaan#1 = 2830 token + 1000 token = 3830 token
- Token yang diterima: 200 (audio)
Menghitung jumlah token yang diproses dalam permintaan
Jumlah token yang diproses selama permintaan ini dihitung sebagai berikut:
Request#1 hanya memproses token input dan output dari permintaan yang sedang berlangsung, karena tidak ada token tambahan dalam memori sesi.
Permintaan #2 memproses token input dan output dari permintaan yang sedang berlangsung, tetapi juga menyertakan token input dari memori sesi, yang terdiri dari token input dari permintaan sebelumnya (Permintaan #1) dari memori sesi. Rasio pengurangan token dalam memori sesi sama dengan rasio pengurangan token input standar (1 token memori sesi input = 1 token input).
Jika Request#2 memerlukan waktu tepat 1 detik untuk diproses setelah Anda mengirimkannya, token Anda akan diproses dan diterapkan ke kuota Throughput yang Disediakan, sebagai berikut:
Kalikan input Anda dengan rasio penyelesaian untuk mendapatkan total token input:
2830 x (1 token per token memori sesi) + 1000 x (1 token per token teks input) = 3830 token input yang disesuaikan untuk burn-down per kueri
Kalikan output Anda dengan rasio penyelesaian untuk mendapatkan total token output:
200 x (24 token per token output audio) = 4.800 token
Tambahkan kedua total ini untuk mendapatkan jumlah total token yang diproses:
3.830 token + 4.800 token = 8.630 token