בקטע הזה מוסבר איך הקצאת משאבים לפי התפוקה שנקבעה עובד עם Gemini Live API לצורך ספירת טוקנים ואכיפת מכסה.
Gemini Live API תומך באינטראקציות מולטימודאליות עם זמן טעינה נמוך באמצעות סשנים. הוא משתמש בזיכרון של סשן כדי לשמור מידע מאינטראקציות בסשן מסוים ולשלוף אותו. כך המודל יכול להיזכר במידע שסופק או נדון בעבר. הקצאת משאבים לפי התפוקה שנקבעה נתמכת במודל האודיו המקורי של Gemini 2.5 Flash Live API. מידע נוסף על Gemini Live API, כולל מגבלות על סשנים ויכולות, זמין במאמר Gemini Live API reference.
ממשק 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 טוקנים
- טוקנים שהתקבלו: 200 (אודיו)
חישוב מספר האסימונים שעברו עיבוד בבקשות
מספר האסימונים שעברו עיבוד במהלך הבקשות האלה מחושב באופן הבא:
בקשה מס' 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 טוקנים