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