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. API ini menggunakan memori sesi untuk menyimpan dan mengingat 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 mengharuskan sesi didedikasikan sepenuhnya untuk traffic Throughput yang Disediakan atau PayGo. API ini tidak mendukung spillover traffic antara Throughput yang Disediakan dan PayGo dalam sesi yang sama. Jenis traffic yang ditetapkan pada awal sesi akan berlanjut selama durasi sesi. Jika Anda mencapai kuota Throughput yang Disediakan selama sesi aktif, Anda tidak akan mengalami throttling atau error. Sebagai gantinya, sistem akan memungkinkan traffic sementara melonjak agar sesi dapat dilanjutkan, dengan semua penggunaan berikutnya yang tercatat 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 melebihi batas yang dialokasikan di tengah sesi, Anda harus membeli GSU yang cukup untuk mendukung penggunaan yang diharapkan.
Spillover didukung dari satu sesi ke sesi berikutnya. Jika Anda melebihi batas Throughput yang Disediakan setelah sesi berakhir, Anda dapat memulai sesi tambahan menggunakan PayGo. Apakah sesi diproses sepenuhnya sebagai Throughput yang Disediakan atau PayGo akan diputuskan pada awal sesi. Sistem akan memeriksa header yang dikirim oleh pengguna, lalu memverifikasi apakah ada kuota Throughput yang Disediakan yang 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. Oleh karena itu, Throughput yang Disediakan akan 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 total token yang dapat disimpan dalam memori sesi dan juga memiliki kolom metadata yang berisi jumlah total token. Saat menghitung jumlah throughput yang diperlukan untuk menayangkan permintaan Anda, Anda harus memperhitungkan token dalam memori sesi. Jika telah menggunakan Gemini Live API dengan 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 aktif.
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 Permintaan#1:
- Token yang dikirim: Jumlah token audio dan video yang dikirim = 2.580+250 = 2.830 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 = 2.830 token + 1.000 token = 3.830 token
- Token yang diterima: 200 (audio)
Menghitung jumlah token yang diproses dalam permintaan
Jumlah token yang diproses selama permintaan ini dihitung sebagai berikut:
Permintaan#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. Tingkat burndown untuk token dalam memori sesi sama dengan tingkat burndown untuk token input standar (1 token memori sesi input = 1 token input).
Jika Permintaan#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 tingkat burndown untuk mendapatkan total token input:
2.830 x (1 token per token memori sesi) + 1.000 x (1 token per token teks input) = 3.830 token input yang disesuaikan dengan burndown per kueri
Kalikan output Anda dengan tingkat burndown 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