בקטע הזה מוסבר איך הקצאת משאבים לפי התפוקה שנקבעה עובד עם 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), תוכלו להשתמש בדפוסי התנועה ובאסימוני הסשן האלה כדי להעריך את הצרכים שלכם לגבי הקצאת משאבים לפי התפוקה שנקבעה.
דוגמה להערכת הדרישות שלכם לגבי הקצאת משאבים לפי התפוקה שנקבעה (Provisioned Throughput) ל-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 טוקנים