בקטע הזה מוסברים המושגים "יחידת תפוקה ל-AI גנרטיבי" (GSU) ו"שיעורי ניצול". החישוב והתמחור של הקצאת המשאבים לפי התפוקה שנקבעה מתבצעים באמצעות יחידות תפוקה ל-AI גנרטיבי (GSU) ושיעורי ניצול.
GSU וקצב ניצול המכסה
יחידת תפוקה ל-AI גנרטיבי (GSU) היא מדד לתפוקה של ההנחיות והתשובות. הסכום הזה מציין את נפח העיבוד שצריך להקצות למודל.
קצב ניצול הוא יחס שממיר את יחידות הקלט והפלט (כמו טוקנים, תווים או תמונות) לטוקנים של קלט לשנייה, תווים של קלט לשנייה או תמונות של קלט לשנייה, בהתאמה. היחס הזה מייצג את קצב העיבוד ומשמש ליצירת יחידה סטנדרטית בכל המודלים.
מודלים שונים משתמשים בכמויות שונות של תפוקה. כדי לדעת מהו הסכום המינימלי לרכישת GSU ומהן המדרגות לכל מודל, קראו את הקטע מודלים נתמכים ושיעורי ניצול במאמר הזה.
המשוואה הזו ממחישה איך מחשבים את קצב העברת הנתונים:
inputs_per_query = inputs_across_modalities_converted_using_burndown_rates
outputs_per_query = outputs_across_modalities_converted_using_burndown_rates
throughput_per_second = (inputs_per_query + outputs_per_query) * queries_per_second
קצב העיבוד המחושב לשנייה קובע כמה יחידות GSU אתם צריכים לתרחיש לדוגמה שלכם.
שיקולים חשובים
כדי לעזור לכם לתכנן את הצרכים שלכם בנוגע להקצאת משאבים לפי התפוקה שנקבעה, כדאי לעיין בשיקולים החשובים הבאים:
הבקשות מקבלות עדיפות.
לקוחות עם הקצאת משאבים לפי התפוקה שנקבעה מקבלים עדיפות ושירות לפני בקשות על פי דרישה.
קצב העברת הנתונים לא מצטבר.
קצב העברת נתונים שלא נוצל לא נצבר ולא עובר לחודש הבא.
הקצאת המשאבים לפי התפוקה שנקבעה נמדדת בטוקנים לשנייה, בתווים לשנייה או בתמונות לשנייה.
הקצאת המשאבים לפי התפוקה שנקבעה לא נמדדת רק לפי שאילתות לדקה (QPM). הוא נמדד לפי גודל השאילתה בתרחיש לדוגמה, גודל התשובה ומספר השאילתות לדקה.
הקצאת המשאבים לפי התפוקה שנקבעה היא ספציפית לפרויקט, לאזור, למודל ולגרסה.
הקצאת המשאבים לפי התפוקה שנקבעה מוקצית לשילוב ספציפי של פרויקט, אזור, מודל וגרסה. אם תשלחו בקשה לאותו מודל מאזור אחר, היא לא תיכלל במכסה של "הקצאת משאבים לפי התפוקה שנקבעה" ולא תקבל עדיפות על פני בקשות על פי דרישה.
שמירת הקשר במטמון
הקצאת משאבים לפי התפוקה שנקבעה תומכת בשמירה במטמון באופן משתמע ובשמירה במטמון באופן מפורש. מידע על המודלים הנתמכים והמגבלות מופיע במאמר שמירת הקשר במטמון.
שמירה במטמון באופן משתמע מופעלת כברירת מחדל בכל הפרויקטים ב- Cloud de Confiance by S3NS . שמירה במטמון באופן משתמע מפחיתה את העלות ואת זמן האחזור במהלך מציאה במטמון (cache hit). כשמתרחשת מציאה במטמון (cache hit), טוקנים שנשמרו במטמון מחויבים בהנחה ביחס לטוקנים של קלט סטנדרטי (stdin). שמירה מפורשת במטמון מאפשרת שליטה רבה יותר ומבטיחה הנחה כשמפנים למטמונים מפורשים. כדי ללמוד איך ליצור שמירת הקשר במטמון לשמירה מפורשת במטמון, ראה יצירת מטמון הקשר. במאמר סקירה כללית על שמירת הקשר במטמון מפורטות ההנחות הספציפיות לכל מודל. במקרה של הקצאת משאבים לפי התפוקה שנקבעה, ההנחה מיושמת באמצעות שיעור ניצול מופחת.
לדוגמה, אלה שיעורי הניצול של Gemini 2.5 Pro לטוקנים של טקסט קלט ולטוקנים במטמון:
טוקן אחד של טקסט קלט = טוקן אחד
טוקן אחד של טקסט במטמון בקלט = 0.1 טוקנים
אם תשלחו 1,000 טוקנים של קלט למודל הזה, קצב הניצול של הקצאת המשאבים לפי התפוקה שנקבעה יהיה 1,000 טוקנים של קלט לשנייה. לעומת זאת, אם תשלחו 1,000 טוקנים במטמון ל-Gemini 2.5 Pro, קצב הניצול של הקצאת המשאבים לפי התפוקה שנקבעה יהיה 100 טוקנים לשנייה.
חשוב לזכור שהמצב הזה יכול להוביל לקצב עיבוד נתונים גבוה יותר בשאילתות דומות שבהן הטוקנים לא נשמרים במטמון וההנחה על המטמון לא חלה.
כדי לראות את שיעורי הניצול של המודלים שנתמכים בהקצאת משאבים לפי התפוקה שנקבעה, קראו את המאמר מודלים נתמכים ושיעורי ניצול.
הסבר על קצב הניצול של Gemini Live API
Gemini 2.5 Flash עם Gemini Live API תומך בהקצאת משאבים לפי התפוקה שנקבעה. כדי להבין איך לחשב את קצב הניצול כשמשתמשים ב-Gemini Live API, קראו את המאמר הערכת דרישות ה-GSU.
מידע נוסף על השימוש בהקצאת משאבים לפי התפוקה שנקבעה ל-Gemini 2.5 Flash עם Gemini Live API זמין במאמר הקצאת משאבים לפי התפוקה שנקבעה ל-Gemini Live API.
דוגמה להערכת הצרכים שלכם להקצאת משאבים לפי התפוקה שנקבעה
כדי להעריך את הצרכים שלכם לגבי הקצאת משאבים לפי התפוקה שנקבעה, אתם יכולים להשתמש בכלי ההערכה במסוף Cloud de Confiance . בדוגמה הבאה מוסבר איך להעריך את כמות המשאבים שצריך להקצות למודל לפי התפוקה שנקבעה. האזור לא נכלל בחישובי ההערכה.
בטבלה הזו מפורטים שיעורי הניכוי של Gemini 3.6 Flash, שבהם אתם יכולים להשתמש כדי לעקוב אחרי הדוגמה.
| מודל | קצב העברת נתונים לכל GSU | יחידות | הכמות המינימלית לרכישת GSU | קצב ניצול התקציב |
|---|---|---|---|---|
| Gemini 3.6 Flash | 675 | טוקנים | 1 |
טוקן אחד של טקסט קלט = טוקן אחד טוקן אחד של תמונת קלט = טוקן אחד טוקן אחד של סרטון קלט = טוקן אחד טוקן אחד של אודיו קלט = טוקן אחד טוקן אחד של שמירת טקסט קלט במטמון = 0.1 טוקנים טוקן אחד של שמירת תמונת קלט במטמון = 0.1 טוקנים טוקן אחד של שמירת סרטון קלט במטמון = 0.1 טוקנים טוקן אחד של שמירת אודיו קלט במטמון = 0.1 טוקנים טוקן אחד של תגובת טקסט פלט = 5 טוקנים |
אוספים את הדרישות. בדוגמה הזו, אתם צריכים לוודא שאתם יכולים לתמוך ב-10 שאילתות לשנייה (QPS) של שאילתה עם קלט של 1,000 אסימוני טקסט ו-500 אסימוני אודיו, כדי לקבל פלט של 300 אסימוני תגובה של טקסט באמצעות
gemini-3.6-flash.כדי לחשב את קצב העיבוד של תרחיש לדוגמה ספציפי, משתמשים בשיעורי הניצול של המודל שנבחר.
מחשבים את קצב העברת הנתונים. מכפילים את הקלטים בשיעורי הניצול כדי להגיע למספר הכולל של אסימוני הקלט:
$\text{1,000} \times (\text{1 token per input text token}) + \text{500} \times (\text{1 token per input audio token}) = \text{1,500}$ טוקנים של קלט מותאמים לניצול לכל שאילתה.
מכפילים את הפלטים בשיעורי הניצול כדי להגיע לסך כל הטוקנים של הפלט:
$\text{300} \times (\text{5 tokens per output text response token}) = \text{1,500}$ טוקנים של פלט מותאמים לניצול לכל שאילתה.
מחברים את הסכומים:
$\text{1,500 burndown adjusted input tokens} + \text{1,500 burndown adjusted output tokens} = \text{3,000}$ סך כל הטוקנים לשאילתה.
מכפילים את מספר הטוקנים הכולל ב-QPS כדי לקבל את קצב העברת הנתונים הכולל לשנייה:
$\text{3,000 total tokens per query} \times \text{10 QPS} = \text{30,000}$ סך הטוקנים לשנייה.
חשבו את מספר יחידות ה-GSU שאתם צריכים. כדי לחשב את מספר יחידות ה-GSU, מחלקים את מספר הטוקנים הכולל לשנייה בנפח העיבוד לשנייה לכל GSU מטבלת הניצול:
$\text{30,000 total tokens per second} \div \text{675 per-second throughput per GSU} = \text{44.44}$ GSUs.
המינימום לרכישת GSU ל-
gemini-3.6-flashהוא 1, אז תצטרכו 45 יחידות GSU כדי להבטיח את עומס העבודה.