Provisioned Throughput for Gemini Live API

בקטע הזה מוסבר איך הקצאת משאבים לפי התפוקה שנקבעה עובד עם Gemini Live API לצורך ספירת טוקנים ואכיפת מכסה.

‫Gemini Live API תומך באינטראקציות מולטימודאליות עם זמן טעינה נמוך באמצעות סשנים. הוא משתמש בזיכרון של סשן כדי לשמור מידע מאינטראקציות בסשן מסוים ולשלוף אותו. כך המודל יכול להיזכר במידע שסופק או נדון קודם לכן. הקצאת משאבים לפי התפוקה שנקבעה תומכת במודל Gemini 2.5 Flash עם Gemini Live API. מידע נוסף על Gemini Live API, כולל מגבלות על סשנים ויכולות, זמין במאמר הפניית API של Gemini Live.

ממשק Gemini Live API דורש שהסשן יוקדש כולו לתעבורה של הקצאת משאבים לפי התפוקה שנקבעה או PayGo. הוא לא תומך בתעבורה עודפת בין הקצאת משאבים לפי התפוקה שנקבעה לבין PayGo באותו סשן. סוג התנועה שמוגדר בתחילת הסשן ממשיך לאורך כל משך הסשן. אם תגיעו למכסת הקצאת משאבים לפי התפוקה שנקבעה במהלך סשן פעיל, לא תיתקלו בהגבלת קצב העברת הנתונים או בשגיאות. במקום זאת, המערכת מאפשרת תנועה זמנית כדי שהסשן יימשך, וכל השימוש הבא יירשם במסגרת המכסה הכוללת. הפרץ הזמני הזה עלול לגרום ללוחות הבקרה שלכם להציג שימוש בהקצאת משאבים לפי התפוקה שנקבעה (תעבורת נתונים ייעודית) מעל המגבלה. כדי להימנע מחריגה מהמגבלות שהוקצו לכם באמצע הפגישה, חשוב לרכוש מספיק יחידות GSU כדי לתמוך בשימוש הצפוי.

יש תמיכה בהעברה מביקור אחד לביקור הבא. אם חרגתם ממגבלת התפוקה שהוקצתה לכם אחרי סיום הסשן, תוכלו להתחיל סשן נוסף באמצעות PayGo. ההחלטה אם סשן יעבור עיבוד מלא כסשן של הקצאת משאבים לפי התפוקה שנקבעה או כסשן של PayGo מתקבלת בתחילת הסשן. המערכת בודקת את הכותרת שנשלחה על ידי המשתמש, ואז מוודאת שיש מכסת הקצאת משאבים לפי התפוקה שנקבעה מספקת לסשן. אם המכסה הזמינה של הקצאת משאבים לפי התפוקה שנקבעה אינה מספיקה לעיבוד כל הסשן, המערכת משתמשת במכסה של PayGo במקום זאת.

חישוב קצב העברת הנתונים ב-Gemini Live API

במהלך השימוש ב-Gemini Live API, אפשר להשתמש בטוקנים שמאוחסנים בזיכרון של הסשן בבקשות הבאות למודל. כתוצאה מכך, הקצאת משאבים לפי התפוקה שנקבעה מתייחסת לטוקנים הנכנסים וגם לטוקנים של זיכרון הסשן באותה בקשה. יכול להיות שמספר הטוקנים שעוברים עיבוד בכל בקשה יהיה גדול ממספר הטוקנים שהמשתמש שולח בבקשה הפעילה.

ל-Gemini Live API יש מגבלה על מספר הטוקנים הכולל שאפשר לאחסן בזיכרון הסשן, ויש לו גם שדה מטא-נתונים שמכיל את המספר הכולל של הטוקנים. כשמחשבים את נפח התפוקה שנדרש כדי לטפל בבקשות, צריך לקחת בחשבון את הטוקנים בזיכרון הסשן. אם השתמשתם ב-Gemini Live API עם תשלום לפי שימוש (PayGo), תוכלו להשתמש בדפוסי התנועה ובטוקנים של הסשן כדי להעריך את נפח התפוקה המוקצה שנדרש לכם.

דוגמה להערכת הדרישות שלכם לגבי קצב העברת הנתונים שהוקצה לכם ב-Gemini Live API

במהלך סשן, כל התנועה מעובדת לפי הקצאת משאבים לפי התפוקה שנקבעה או לפי תשלום לפי שימוש.

מצב ההפעלה, כולל הזיכרון של ההפעלה, זמין כל עוד ההפעלה פעילה.

בדוגמה הזו אפשר לראות איך שתי בקשות עוקבות מעובדות על ידי הכללת האסימונים מזיכרון הסשן.

פרטים על בקשה מס' 1

משך: 10 שניות

טוקנים שנשלחו (אודיו): 10 שניות x 25 טוקנים לשנייה = 250 טוקנים

Tokens sent (video): 10 seconds x 258 tokens/frame per second = 2580 tokens

סה"כ הטוקנים שעברו עיבוד בבקשה מס' 1:

  • Tokens sent: Sum of audio and video tokens sent = 2580+250 = 2830 tokens
  • Tokens received: 100 (audio)

פרטי בקשה מס' 2

משך: 40 שניות

טוקנים שנשלחו (אודיו): 40 שניות x‏ 25 טוקנים לשנייה = 1,000 טוקנים

סה"כ הטוקנים שעובדו עבור בקשה מס' 2:

  • טוקנים שנשלחו: טוקנים שנשלחו בבקשה מס' 2 + טוקנים של זיכרון הסשן מבקשה מס' 1 = 2,830 טוקנים + 1,000 טוקנים = 3,830 טוקנים
  • Tokens received: 200 (audio)

חישוב מספר האסימונים שעברו עיבוד בבקשות

מספר האסימונים שעובדו במהלך הבקשות האלה מחושב באופן הבא:

  • בקשה מס' 1 מעבדת רק את טוקני הקלט והפלט מהבקשה המתמשכת, כי אין טוקנים נוספים בזיכרון של הסשן.

  • בקשה מספר 2 מעבדת את אסימוני הקלט והפלט מהבקשה הנוכחית, אבל כוללת גם את אסימוני הקלט מזיכרון הסשן, שמורכבים מאסימוני הקלט מהבקשה הקודמת (בקשה מספר 1) מזיכרון הסשן. קצב השחיקה של אסימונים בזיכרון של הסשן זהה לזה של אסימוני קלט רגילים (אסימון זיכרון אחד של סשן קלט = אסימון קלט אחד).

    אם עיבוד בקשה מס' 2 נמשך בדיוק שנייה אחת אחרי ששלחתם אותה, האסימונים יעובדו ויוחלו על מכסת הקצאת המשאבים לפי התפוקה שנקבעה שלכם, באופן הבא:

    • מכפילים את נתוני הקלט בשיעורי השחיקה כדי לקבל את מספר האסימונים הכולל של הקלט:

      ‫2,830 x (1 token per session memory token) + 1,000 x (1 token per input text token) = 3,830 burndown adjusted input tokens per query

    • מכפילים את התפוקות בשיעורי השחיקה כדי לקבל את מספר הטוקנים הכולל של התפוקה:

      ‫200 x (24 טוקנים לכל טוקן של פלט אודיו) = 4,800 טוקנים

    • כדי לקבל את המספר הכולל של האסימונים שעברו עיבוד, מחברים את שני הסכומים האלה:

      ‫3,830 טוקנים + 4,800 טוקנים = 8,630 טוקנים

המאמרים הבאים