ב-Gemini Enterprise Agent Platform יש כמה אפשרויות לקבלת משאבי מחשוב ולהשתמש בהם כשמשתמשים במודלים גנרטיביים. אפשרויות הצריכה האלה נועדו לענות על הצרכים של כל עומס עבודה, החל מאב טיפוס ראשוני ועד לפריסות בסביבת הייצור. חשוב לבחור את האפשרות הנכונה כדי לאזן בין הביצועים, האמינות והעלות.
במדריך הזה מפורטות אפשרויות הצריכה הזמינות, ומוסבר איך למפות אותן לדרישות הספציפיות של עומס העבודה שלכם. בנוסף, המדריך מספק אסטרטגיות לאופטימיזציה של זמן האחזור, הזמינות והעלות.
אפשרויות צריכה
ב-Gemini Enterprise Agent Platform יש חמש אפשרויות צריכה שמותאמות לדפוסי תנועה ולצרכים עסקיים שונים:
| אפשרות צריכה | תיאור | אידיאלית עבור | תמחור | |
|---|---|---|---|---|
| הקצאת משאבים לפי התפוקה שנקבעה | מספקת תפוקה מובטחת לתקופת התחייבות | עומסי עבודה קריטיים, במצב יציב, עם זמינות תמידית ונדרש להם הסכם SLA | מבוססות-התחייבות (זמינות בתוכניות לשבוע, לחודש, ל-3 חודשים ולשנה) | |
| PayGo | רגילה | אפשרות גמישה של תשלום לפי שימוש, ללא התחייבות מראש | אפשרות ברירת המחדל לתרחישי שימוש יומיומיים, עם גמישות לשינויים בנפח התנועה הנדרש | לכל טוקן (תעריף רגיל) |
| עדיפות | אמינות גבוהה יותר באמצעות עיבוד בעדיפות גבוהה, תוך שמירה על הגמישות של PayGo | עומסי עבודה חשובים שדורשים אמינות גבוהה יותר ומגבלות גבוהות יותר מאשר PayGo רגיל | לכל טוקן (תעריף פרימיום) | |
| Flex | אפשרות משתלמת לעומסי עבודה (workloads) שלא רגישים לזמן אחזור | משימות שבהן אפשר להסתפק בזמני תגובה איטיים יותר ובוויסות נתונים (throttling) גבוה יותר בתמורה למחיר נמוך יותר | לכל טוקן (תעריף מוזל) | |
| היסק ב-Batch | אופטימיזציה של העלויות לעיבוד אסינכרוני בנפח גבוה | משימות בקנה מידה גדול שבהן התוצאות נדרשות בטווח זמן ארוך יותר | לכל טוקן (תעריף מוזל) | |
למידע על תמחור, ראו את דף התמחור.
בחירת האפשרות שמתאימה לעומס העבודה שלכם
בקטעים הבאים מוסבר איך לבחור את אפשרות הצריכה המתאימה ביותר, בהתאם לדרישות ולמאפיינים הספציפיים של עומס העבודה.
עומסי עבודה שרגישים לזמן האחזור
ארגונים צריכים לעיתים קרובות לבחור בין אמינות לבין עלות כשהם בוחרים את מודל הצריכה המתאים. למרות שהקצאת משאבים לפי התפוקה שנקבעה מציעה את האמינות הגבוהה ביותר, היא יכולה לגרום לניצול חלקי אם יש קפיצות בתנועה. באופן דומה, PayGo עשוי להציע את הגמישות המקסימלית, אבל לא יכול להבטיח את איכות השירות. בקטע הבא מוסבר איך לשלב בצורה הטובה ביותר את המנגנונים האלה כדי להשיג את התוצאה האופטימלית:
- הקצאת משאבים לפי התפוקה שנקבעה כדי לכסות את תנועת הגולשים הבסיסית. כך אפשר לנצל טוב יותר את הקיבולת השמורה, לחסוך כסף וליהנות מאמינות מובטחת לתנועה העיקרית. כדי לעשות את זה:
- לנתח את דפוסי התנועה ברמת הדקה או השנייה.
- קובעים את נפח התנועה שרוצים להקצות לו משאבים לפי התפוקה שנקבעה. הוא צריך לכסות את התנועה בעדיפות הגבוהה ביותר.
- ניהול תנועה חורגת באמצעות תשלום רגיל או בעדיפות גבוהה לפי שימוש: כברירת מחדל, תנועה שחורגת מהבסיס של הקצאת המשאבים לפי התפוקה שנקבעה (נקראת תנועה חורגת) מטופלת באמצעות תשלום רגיל לפי שימוש. אם אתם מבחינים בשונות גבוהה יותר בביצועים של בקשות מעל מגבלת ה-TPM, אתם יכולים לצמצם את השונות הזו באמצעות אופטימיזציה. Priority PayGo מאפשר לכם לקבל ביצועים אמינים במחיר פרימיום, בכפוף למגבלת ההסתגלות.
עומסי עבודה אסינכרוניים בנפח גבוה
אם יש לכם צבר גדול של בקשות (לדוגמה, אם יש לכם מיליוני מסמכים שצריך לסכם), והזמן שלוקח לקבל תשובה לא חשוב, כדאי לשלוח משימה באצווה על ידי ניסוח בקשות בקובץ JSON או בגיליון אלקטרוני. האפשרות הזו שימושית לתרחישים לדוגמה כמו תיוג תמונות, עיבוד מסמכים בכמות גדולה או ניתוח סנטימנטים בנתונים היסטוריים.
זו האפשרות הכי משתלמת להסקת מסקנות בנפח גבוה.
עומסי עבודה (workloads) שרגישים לעלויות אבל לא לזמן אחזור
אם אתם צריכים לעבד בקשות שבהן האפליקציה יכולה להמתין לתגובה, אבל הפחתת העלויות היא בעדיפות גבוהה, כדאי להשתמש ב-Flex תשלום לפי שימוש. Flex תשלום לפי שימוש מציע מחיר מופחת לכל טוקן לבקשות שלא דורשות ביצוע מיידי. האפשרות הזו שימושית לתרחישים לדוגמה כמו ניתוח אופליין, הוספת הערות לנתונים, בניית קטלוג מוצרים או תרגום.
אסטרטגיות אופטימיזציה
אחרי שבוחרים את מודל הצריכה, אפשר להשתמש באסטרטגיות הבאות כדי לבצע אופטימיזציה נוספת של זמן האחזור, הזמינות והעלות.
זמן אחזור
כשמפתחים אפליקציות אינטראקטיביות, זמן האחזור משפיע מאוד על חוויית המשתמש. זמן אחזור הוא משך הזמן שלוקח למודל לעבד את הנחיית הקלט וליצור תשובת פלט מתאימה. כשבודקים את זמן האחזור של מודל, חשוב להביא בחשבון את הדברים הבאים:
- Time to first token (TTFT): הזמן שלוקח למודל ליצור את הטוקן הראשון של התשובה אחרי קבלת ההנחיה. המדד הזה רלוונטי במיוחד לאפליקציות סטרימינג, שבהן חשוב מאוד לספק משוב מיידי.
- Time to last token (TTLT): משך הזמן הכולל שלוקח למודל לעבד את ההנחיה וליצור את התשובה.
כדי לבצע אופטימיזציה של זמן האחזור:
- בחירת המודל שמתאים לתרחיש לדוגמה: ב-Gemini Enterprise Agent Platform יש מגוון רחב של מודלים עם יכולות ומאפייני ביצועים שונים. חשוב לבדוק היטב את הדרישות לגבי מהירות ואיכות הפלט כדי לבחור את המודל שהכי מתאים לתרחיש לדוגמה שלכם. רשימת המודלים הזמינים ב-Gemini Enterprise Agent Platform Model Garden
- צמצום גודל ההנחיה: נסחו הנחיות ברורות ותמציתיות שמעבירות את הכוונה שלכם בצורה יעילה, בלי פרטים מיותרים או כפילויות. הנחיות קצרות יותר מקצרות את הזמן עד לקבלת הטוקן הראשון.
- הגבלת טוקנים של פלט:
- אפשר להשתמש בהוראות המערכת כדי לשלוט באורך התשובה. הנחו את המודל לספק תשובות תמציתיות או להגביל את הפלט למספר מסוים של משפטים או פסקאות. האסטרטגיה הזו יכולה לקצר את הזמן עד לטוקן האחרון.
- להגביל את הפלט באמצעות הגדרת מגבלה. הפרמטר
max_output_tokensמאפשר להגדיר מגבלה מקסימלית לאורך התשובה שנוצרת, כדי למנוע פלט ארוך מדי. זמן האחזור הוא ביחס ישר למספר הטוקנים שנוצרו. אם נוצרים פחות טוקנים, התשובות מתקבלות מהר יותר. עם זאת, חשוב להיזהר כי זה עלול לקטוע את התשובות באמצע המשפט.
- שימוש בהקצאת משאבים לפי התפוקה שנקבעה: כדי לקבל את הביצועים העקביים ביותר, השתמשו בהקצאת משאבים לפי התפוקה שנקבעה. כך אפשר למנוע את השינויים שנגרמים בגלל "התחלות קרות" או תורים שיכולים להיווצר מדי פעם במודלים של PayGo בזמן תנועה גבוהה.
- הגבלת מכסת החשיבה: אם אתם משתמשים במודל שתומך בחשיבה, אתם יכולים להפחית את זמן האחזור על ידי הפחתת מכסת החשיבה. כך, על ידי הגבלת מספר הטוקנים של החשיבה הפנימית שהמודל יוצר לפני שהוא עונה, אתם מקצרים את זמן העיבוד הכולל. עם זאת, חשוב לוודא שהתקציב עדיין מספיק למורכבות המשימה כדי לא לפגוע באיכות התשובה.
- שימוש בסטרימינג לתשובות: סטרימינג משפר את מהירות התגובה הנתפסת ויוצר חוויית משתמש אינטראקטיבית יותר. במצב סטרימינג, המודל מתחיל לשלוח את התשובה שלו לפני שהוא יוצר את הפלט המלא. כך אפשר לעבד את הפלט בזמן אמת, לעדכן מיד את ממשק המשתמש ולבצע משימות אחרות בו-זמנית.
זמינות
כדי לבצע אופטימיזציה לזמינות:
- הטמעת לוגיקה של ניסיון חוזר: הטמיעו השהיה מעריכית לפני ניסיון חוזר (exponential backoff) לשגיאות 429, במיוחד כשאתם משתמשים ב-Standard PayGo.
- שימוש בהטמעה היברידית: כמו שמוסבר במאמר בחירת האפשרות שמתאימה לעומס העבודה, אל תסתמכו רק על PayGo לאפליקציות קריטיות בסביבת הייצור. שילוב של הקצאת משאבים לפי התפוקה שנקבעה ו-PayGo מספק את ההגנה הטובה ביותר מפני ניצול יתר של משאבים (שגיאות 429).
- ניהול המכסה של הקצאת המשאבים לפי התפוקה שנקבעה: עקבו באופן קבוע אחרי צריכת ה-TPM והגדילו את ה-GSU של הקצאת המשאבים לפי התפוקה שנקבעה לפני אירועים צפויים של תנועה (כמו השקות מוצרים). אפשר להשתמש במדיניות התראות כדי להפוך את המעקב לאוטומטי.
- שימוש בנקודת הקצה הגלובלית: משתמשים בנקודת הקצה הגלובלית כדי לנצל את מאגר הקיבולת הגלובלי של Google, וכך לצמצם את ההאטה שנובעת ממגבלות קיבולת אזוריות.
- למתן את התנועה כדי לצמצם את העליות החדות ככל האפשר: שיעורי תנועה גבוהים יותר של PayGo (TPM) נוטים להיות משויכים לשיעורי ויסות נתונים גבוהים יותר.
- העברת תנועה לשעות שאינן שעות שיא: השימוש במודל באופן מצטבר בדרך כלל פועל לפי דפוס יומי. אם תעבירו את עומס העבודה לשעות שאינן שעות השיא או לסופי שבוע, תוכלו לשפר משמעותית את הזמינות.
עלות
כדי לבצע אופטימיזציה של העלות:
- התאמת הגודל של הקצאת המשאבים לפי התפוקה שנקבעה: בדרך כלל לא צריך להקצות משאבים לפי התפוקה שנקבעה כדי לכסות את הביקוש בשיא. הקצאת משאבים לביקוש בשיא מפחיתה את הניצול הכולל ומעלה את העלויות. כדאי לכסות אחוזון מסוים מהתנועה בהתאם לסבילות שלכם לסיכון, ולהשאיר את השאר ל-Standard PayGo ול-Priority PayGo.
- רכישת הקצאת משאבים לפי התפוקה שנקבעה לטווח ארוך יותר: התחייבות לשנה אחת להקצאת משאבים לפי התפוקה שנקבעה מתומחרת בהנחה של 26% בהשוואה להקצאת משאבים לפי התפוקה שנקבעה לחודש אחד, מה שמוביל לחיסכון משמעותי בעלויות. אתם תמיד יכולים לשנות את המודל שמשויך ליחידות ה-GSU שרכשתם, כדי לנצל את היכולות של המודלים החדשים שלנו.
- שימוש ב-Flex PayGo: זהו את החלקים בצינור עיבוד הנתונים שלא רגישים לזמן אחזור (למשל, סיכום ברקע, חילוץ נתונים) והעבירו אותם ל-Flex PayGo כדי להוזיל את העלויות בכ-50%.
- שימוש בעיבוד באצווה: למשימות אסינכרוניות כמו עיבוד של מערכי נתונים גדולים, עיבוד באצווה זול משמעותית (50%) מעיבוד של בקשות ברצף באמצעות Standard PayGo.
- שימוש בשמירת הקשר במטמון: שמירת הקשר במטמון עוזרת להפחית את העלות ואת זמן האחזור של בקשות שמכילות תוכן חוזר. כדי להגדיל את שיעורי המציאה במטמון, כדאי למקם תוכן גדול ונפוץ בתחילת ההנחיה, ולשלוח בקשות עם תחילית דומה בפרק זמן קצר.
- בחירת מודל זול יותר: אם תרחיש השימוש שלכם מאפשר זאת, השתמשו באחד מהמודלים הקטנים יותר שלנו, כמו Flash-Lite, שבו המחיר לטוקן נמוך יותר מאשר במודלים המלאים והכבדים שלנו.