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