אל תשלם עבור GPUs לא פעילים. ספק משאבי עיבוד בדיוק בזמן, עבד את עומס העבודה, ופרק אותו — והפוך הוצאה הונית לעלות תפעולית לכל משימה.

עומס העבודה שלך הוא 'בורסטי' — עבודות קידוד וידאו שעולות בחדות בעת העלאת תוכן, הרצות אימון ML שזקוקות ל-8 GPUs למשך 4 שעות ואז כלום, עבודות הסקת אצווה (batch inference) המופעלות על ידי אירועים עסקיים, או פייפליינים של רינדור הפועלים למשך הלילה. אתה או עם הקצאת יתר (משלם עבור משאבים לא פעילים ב-80% מהזמן) או עם הקצאת חסר (עבודות עומדות בתור שעות במהלך שיאים). אתה זקוק לארכיטקטורה שמספקת בדיוק את כוח העיבוד שאתה צריך, כשאתה צריך אותו, ומשחררת אותו כשהעבודה מסתיימת — ללא עונש ה-cold-start שהופך את "scale to zero" לבלתי מעשי עבור עומסי עבודה של GPU.
Explore more design patterns and system architectures
אדריכלים שלנו יכולים לעזור לך לעצב ולבנות מערכות תוך שימוש בדפוס זה לדרישות הספציפיות שלך.
צרו קשרארכיטקטורת סקיילינג On-Off מנהלת משאבי עיבוד באמצעות מאגרי warm/cold pooling, הקצאת משאבים מונחית-תור-עבודות, ופירוק אוטומטי. מאגר warm מתחזק מספר קטן של מופעים מאותחלים מראש שמוכנים לשימוש מיידי. מאגר cold מספק קיבולת נוספת ממופעי spot/preemptible כאשר הביקוש עולה על מאגר ה-warm. מתזמר עבודות מנתב עבודה למופעים זמינים, מנטר התקדמות, מטפל בניסיונות חוזרים בעקבות פינוי spot, ומפעיל הקטנת קנה מידה (scale-down) כשהתור מתרוקן. התבנית קריטית במיוחד עבור עומסי עבודה של GPU שבהם cold start (משיכת קונטיינר + טעינת מודל) יכול לארוך 3-10 דקות.
המערכת ממוקדת סביב תור עבודות (SQS, Redis, או מותאם אישית) המאגר בקשות עבודה נכנסות. בקר סקיילינג מנטר את עומק התור ומספק מופעים ממאגר ה-warm תחילה, ולאחר מכן ממאגר ה-cold (מופעי spot). כל מופע עובד מושך עבודות מהתור, מבצע את עומס העבודה (קידוד, אימון, הסקה), מדווח על השלמה, וחוזר למאגר או מסיים פעילות. מנהל נקודות ביקורת מטפל בפינוי spot על ידי שמירת מצב ביניים ל-S3, ומאפשר לעבודות להתחדש במופע אחר מבלי להתחיל מחדש.
| שכבה | טכנולוגיות |
|---|---|
| חישוב (Compute) | AWS EC2 Spot (G5/P4), GCP Preemptible (A2/L4), RunPod Serverless, Modal |
| תזמור (Orchestration) | Kubernetes (Karpenter עבור autoscaling), AWS Batch, custom job orchestrator |
| תור עבודות | AWS SQS, BullMQ (Redis), Temporal, Celery |
| אחסון | S3 (נקודות ביקורת, ארטיפקטים של מודלים), NVMe (מטמון מודלים), EFS (סביבת עבודה משותפת) |
| ניטור | CloudWatch/Prometheus (עומק תור, ניצול מופעים, השהיית עבודות), לוחות מחוונים מותאמים אישית לעלויות |
| השתמש כאשר | הימנע כאשר |
|---|---|
| עומס העבודה הוא 'בורסטי' — ביקוש שיא הוא פי 5+ מהביקוש הממוצע | התעבורה יציבה וצפויה — מופעים שמורים בגודל מתאים זולים יותר |
| עבודות GPU/חישוב אינטנסיבי יקרות כשהן לא פעילות | עומס העבודה הוא עיבוד CPU קל שמתאים ל-serverless (Lambda) |
| עבודות יכולות לסבול cold start של 1-5 דקות עבור הקצאת cold pool | נדרשת השהיה של פחות משנייה להתחלת עבודה — אתה זקוק לתשתית תמיד-פועלת (always-on) |
| אופטימיזציית עלויות היא דאגה עיקרית ותמחור spot מציע חיסכון של 60-90% | הפרעת spot תגרום לאובדן נתונים שנקודות ביקורת לא יכולות למנוע |
MW מתכננת סקיילינג On-Off עם עדשת "עלות למשימה" — אנו ממדלים את העלות הכוללת של עיבוד יחידת עבודה אחת (וידאו אחד, הרצת אימון אחת, הסקת אצווה אחת) על פני אסטרטגיות סקיילינג שונות ובוחרים את זו שממזערת את העלות תוך עמידה ב-SLA ההשהיה הנדרש. היישומים שלנו כוללים לוחות מחוונים של עלויות בזמן אמת המציגים עלות למשימה, ניצול תשתית וחיסכון מ-spot. בנינו תשתית GPU מסוג On-Off שהפחיתה את עלויות עיבוד הווידאו ב-70% בהשוואה למופעים שמורים, ואשכולות אימון ML שמספקים 64 GPUs להרצת אימון של 4 שעות ומשחררים אותם אוטומטית.
אבטחה אינה תכונה שמוסיפים לאחר ההשקה. זוהי תכונה ארכיטקטונית – המערכת תוכננה עבורה, או שלא.
לקוחות MicrocosmWorks עם עומסי עבודה כבדי אצווה או תקופתיים רואים בדרך כלל הפחתות של 60-80% בעלויות הענן לאחר הטמעת מדרגיות הפעלה-כיבוי (on-off scaling), מכיוון שמשאבי המחשוב פועלים רק במהלך חלונות עיבוד פעילים במקום 24/7. אנו מתכננים מדיניות מדרגיות (scaling policies) המבוססת על טלמטריית שימוש בפועל – לדוגמה, צינור עיבוד נתונים (data processing pipeline) הפועל 4 שעות ביום משלם רק עבור 4 שעות אלו במקום 24 השעות המלאות. הארכיטקטים שלנו מנתחים את דפוסי עומס העבודה שלכם במהלך שלב גילוי (discovery phase) כדי לחזות חיסכון מדויק לפני שכל הטמעה מתחילה.
זמני אתחול קר (cold-start times) נעים בין 2-3 שניות עבור יישומים מבוססי קונטיינרים (containerized applications) על מאגרי צמתים מחוממים מראש (pre-warmed node pools) לבין 5-10 דקות עבור עומסי עבודה הדורשים מופעי GPU מיוחדים או טעינת מודלים גדולים, ו-MicrocosmWorks משתמשת במספר טכניקות כדי למזער עיכוב זה. אנו מיישמים מדרגיות חזויה (predictive scaling) המפעילה משאבים לפני ביקוש צפוי באמצעות דפוסי תעבורה היסטוריים ואירועים מתוזמנים, ואנו משתמשים בטעינה מוקדמת של תמונות קונטיינר (container image pre-pulling) ובהזמנות מאגר חם (warm pool reservations) עבור עומסי עבודה רגישים לזמן השהיה (latency-sensitive workloads). עבור יישומים שאינם יכולים לסבול כל אתחול קר, אנו שומרים על בסיס חם מינימלי (minimal warm baseline) המגדיל קנה מידה באגרסיביות כאשר מגיע ביקוש.
MicrocosmWorks מטמיעה קנה מידה אוטומטי ריאקטיבי (reactive auto-scaling) עם מדיניות הגדלת קנה מידה אגרסיבית (aggressive scale-up policies) המופעלות על ידי עומק תור (queue depth), ניצולת מעבד (CPU utilization) או מדדי יישומים מותאמים אישית (custom application metrics), בשילוב עם מדיניות הקטנת קנה מידה הדרגתית יותר הכוללת תקופות צינון (cooldown periods) כדי למנוע מצב חוסר יעילות (thrashing). אנו מגדירים חוצצי הקצאת יתר (over-provisioning buffers) במהלך אירועי הגדלת קנה מידה כך שהמערכת צופה צמיחה מתמשכת במקום לרדוף אחר הביקוש מופע אחד בכל פעם. עבור קפיצות בלתי צפויות באמת כמו מבצעי בזק (flash sales) או אירועים ויראליים (viral events), אנו מקצים קיבולת מראש (pre-provision capacity) באמצעות טריגרים מונחי אירועים (event-driven triggers) מיומן השיווק או התפעול שלכם.
MicrocosmWorks מיישמת מדרגיות הפעלה-כיבוי (on-off scaling) על מסדי נתונים באמצעות הצעות מסדי נתונים ללא שרת (serverless database offerings) כמו Aurora Serverless, Neon או PlanetScale, המפחיתים את המחשוב לאפס במהלך תקופות סרק (idle periods) תוך שמירה על אחסון עמיד וזמין באופן מיידי. עבור עומסי עבודה בעלי מצב (stateful workloads) שאינם יכולים להשתמש במסדי נתונים ללא שרת, אנו מטמיעים מדרגיות רפליקות קריאה (read-replica scaling) שמוסיפה ומסירה רפליקות בהתבסס על עומס שאילתות (query load) תוך שמירה על מופע ראשי מינימלי הפועל תמיד. גישה היברידית זו מעניקה ללקוחות את יתרונות העלות של מדרגיות עבור שכבת הנתונים שלהם ללא המורכבות של ניהול מצב מסד הנתונים במהלך מחזורי כיבוי והפעלה מחדש.
MicrocosmWorks פורסת נראות מדרגיות מקיפה (comprehensive scaling observability) העוקבת אחר ספירת מופעים (instance counts), זמן השהיה של אירועי מדרגיות (scaling event latency), ניסיונות מדרגיות כושלים (failed scaling attempts), והפער בין הקיבולת הרצויה לקיבולת בפועל בזמן אמת באמצעות לוחות מחוונים של Grafana או Datadog. אנו מגדירים התראות מרובות ערוצים (multi-channel alerts) עבור כשלי מדרגיות, ניצולת גבוהה מתמשכת המעידה שתקרת המדרגיות נמוכה מדי, וחריגות עלויות (cost anomalies) המצביעות על מדרגיות בלתי נשלטת (runaway scaling). ספרי ההפעלה (runbooks) שלנו כוללים תיקון אוטומטי (automated remediation) למצבי כשל נפוצים כמו הגעה למגבלות מופעים של ספק הענן (cloud provider instance limits) או נתקעות בשגיאות של קיבולת לא מספקת (insufficient capacity errors) באזורי זמינות ספציפיים (availability zones).