MicrocosmWorksחדשנות ותכנון קוסמוס דיגיטלי
אודותצור קשר
MicrocosmWorksמחדשים ומתכננים קוסמוס דיגיטלי

מספקים פתרונות IT חשובים. אנו נלהבים מטכנולוגיה, אבטחה ועוזרים לעסקים לצמוח באמצעות תשתית IT אמינה וחדשנית.

[email protected]
+91 7011868196
New Delhi, India

מרכז צמיחה AI

מרכז AIחדשנות סטארטאפמאיץ ארגוני

פתרונות

כל הפתרונותאפליקציות בריאות וכושרפלטפורמת וידאו AIפיתוח סוכני AI

משאבים

תובנותמדריכי תעשייהתוכניות מקרה שימושתבניות ארכיטקטורהמחקרי מקרה

חברה

אודותינוצור קשרהעבודה שלנו

שירותים

ייעוץ דיגיטליתשתית ענןפיתוח SaaSפיתוח AIטכנולוגיית וידאו
פיתוח ERPהתאמה אישית של Zohoפיתוח Odooאינטגרציה של Salesforceפיתוח CRM מותאם אישית
אינטגרציה של QuickBooksפתרונות IoTפיתוח בלוקצ'יין
ייעוץ סייברתמיכה טכנית - L3

© 2026 MicrocosmWorks. כל הזכויות שמורות.

מדיניות פרטיותתנאי שירות
חזרה לתבניות ארכיטקטורה
InfrastructureAdvanced

ארכיטקטורת סקיילינג On-Off

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

June 18, 2026
|
2 topics covered
דיון בארכיטקטורה זו
on-off-scaling-architecture.webp
Infrastructure
Category
Advanced
Complexity
AI/ML, Media & Entertainment
Industries
2+
Technologies

מתי זה נחוץ לך

עומס העבודה שלך הוא 'בורסטי' — עבודות קידוד וידאו שעולות בחדות בעת העלאת תוכן, הרצות אימון ML שזקוקות ל-8 GPUs למשך 4 שעות ואז כלום, עבודות הסקת אצווה (batch inference) המופעלות על ידי אירועים עסקיים, או פייפליינים של רינדור הפועלים למשך הלילה. אתה או עם הקצאת יתר (משלם עבור משאבים לא פעילים ב-80% מהזמן) או עם הקצאת חסר (עבודות עומדות בתור שעות במהלך שיאים). אתה זקוק לארכיטקטורה שמספקת בדיוק את כוח העיבוד שאתה צריך, כשאתה צריך אותו, ומשחררת אותו כשהעבודה מסתיימת — ללא עונש ה-cold-start שהופך את "scale to zero" לבלתי מעשי עבור עומסי עבודה של GPU.

Related Architecture Patterns

Explore more design patterns and system architectures

cloud-native-infrastructure.webp
Infrastructure

תשתית Cloud-Native

תשתית שמנוהלת בגרסאות, נבדקת ונפרסת כמו קוד יישום — כי הפלטפורמה שלך אמינה רק כמו מה שנמצא מתחתיה.

EnterpriseView
security-first-architecture.webp

האם אתה זקוק לעזרה בהטמעת ארכיטקטורה זו?

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

צרו קשר

סקירת תבנית

ארכיטקטורת סקיילינג 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, ומאפשר לעבודות להתחדש במופע אחר מבלי להתחיל מחדש.

רכיבי ליבה
  • תור עבודות ומתזמן: תור עבודות מתוזמר עם מגבלות מקביליות הניתנות להגדרה לכל סוג עבודה. תומך בביצוע מושהה, תורי dead-letter לעבודות כושלות, ונתיבי עדיפות (עבודות אקספרס מקבלות מופעי warm pool, עבודות רגילות משתמשות ב-cold pool). AWS SQS, BullMQ on Redis, או Temporal עבור workflows מורכבים
  • מנהל מאגר Warm: מתחזק N מופעים מאותחלים מראש עם מודלים שנטענו לזיכרון ה-GPU, קונטיינרים פועלים, ובדיקות תקינות שעוברות בהצלחה. מופעים עוברים במחזור: סרק → מוקצה → עיבוד → סרק. גודל המאגר ניתן להגדרה לפי שעות היום (גדול יותר בשעות העבודה, קטן יותר במהלך הלילה) וניתן להתאמה בהתבסס על דפוסי ביקוש היסטוריים
  • ספק מאגר Cold: מספק קיבולת נוספת ממופעי spot (AWS), VMs ניתנים לביטול (GCP), או ספקי GPU serverless (RunPod, Modal, Salad). מטפל בהתראות על הפרעת spot על ידי העברת עבודות למופעים זמינים. משתמש באסטרטגיית סוגי מופעים מגוונת (סוגי GPU מרובים, AZs מרובים) כדי למקסם את זמינות ה-spot
  • נקודת ביקורת והתאוששות: עבור עבודות ארוכות טווח (אימון ML, קידוד וידאו גדול), יצירת נקודות ביקורת תקופתיות שומרת מצב ביניים ל-S3. במקרה של פינוי spot, העבודה נכנסת מחדש לתור ומתחדשת מנקודת הביקורת האחרונה. עבור עבודות קצרות (< 10 דקות), עלות יצירת נקודות ביקורת עולה על עלות ההפעלה מחדש — עבודות אלו פשוט מנסות שוב מההתחלה

החלטות תכנון ופשרות

גודל מאגר ה-Warm
מאגר ה-warm הוא פשרה בין עלות (תשלום עבור מופעים לא פעילים) לבין השהיה (זמן cold start עבור העבודה הראשונה). MW מגדיר את גודל מאגרי ה-warm בהתבסס על דפוסי הגעת תור: אם עבודות מגיעות באופן רציף בשעות העבודה, מאגר ה-warm מכסה את התפוקה הממוצעת; מאגר ה-cold מכסה שיאים. אם עבודות מגיעות בפרצים בלתי צפויים, אנו שומרים מאגר warm קטן יותר ומקבלים השהיית cold-start עבור עבודות הפרץ הראשונות בזמן שמאגר ה-cold מספק משאבים.
מופעי Spot לעומת GPU Serverless (RunPod/Modal)
מופעי Spot זולים יותר לפי שעה אך דורשים ממך לנהל הקצאת משאבים, טיפול בפינוי ומחזור חיי המופע. ספקי GPU Serverless (RunPod Serverless, Modal, Banana) מטפלים בהקצאה ומציעים חיוב לפי שנייה אך בתעריף גבוה יותר לשניית עיבוד. MW משתמש במופעי spot עבור עומסי עבודה צפויים וארוכי טווח (>30 דקות) וב-GPU serverless עבור עבודות קצרות ו'בורסטיות' (<10 דקות) שבהן התקורה של ההקצאה תהיה דומיננטית.
אגרסיביות הקטנת קנה מידה (Scale-Down)
הקטן קנה מידה מהר מדי ותשלם קנסות cold-start כשהעבודה הבאה תגיע. הקטן קנה מידה לאט מדי ותשלם עבור מופעים לא פעילים. MW מיישם אסטרטגיית "cooldown עם דעיכה": לאחר שהתור מתרוקן, מופעים נשארים warm למשך תקופה הניתנת להגדרה (ברירת מחדל: 10 דקות). אם לא מגיעות עבודות חדשות, המופעים מקטינים את קנה המידה באופן הדרגתי (50% אחרי 10 דקות, היתרה אחרי 30 דקות). תקופת ה-cooldown ניתנת לכוונון ומתאימה את עצמה אוטומטית בהתבסס על סטטיסטיקות זמני הגעה בין עבודות.
אופטימיזציה לטעינת מודלי GPU
עבור ML inference, צוואר הבקבוק של ה-cold-start הוא לרוב טעינת מודל (הורדה מ-S3 + טעינה לזיכרון GPU), ולא אתחול קונטיינר. MW מייעל זאת על ידי: (א) הטמעת מודלים מראש בתמונות קונטיינר (למודלים קטנים), (ב) שימוש באחסון NVMe משותף בין מופעים עם שמירת מודלים במטמון (למודלים גדולים), ו-(ג) שמירת מופעי warm pool עם מודלים שנטענו מראש לזיכרון ה-GPU.

בחירות טכנולוגיות

שכבהטכנולוגיות
חישוב (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 שעות ומשחררים אותם אוטומטית.

תוכניות קשורות

  • תזמור אשכולות GPU לעומסי עבודה של AI — אספקת ותזמור GPU לאימון ML
  • מערכת מעקב וידאו AI בזמן אמת — הסקת פרץ (burst inference) לאירועי ניתוח וידאו
  • מחולל תקצירי ספורט חיים — עיבוד וידאו מונחה אירועים עם חישוב פרץ (burst compute)

מקרי בוחן קשורים

  • עיבוד וידאו בתבנית On-Off — אספקת GPU עם מאגרי warm/cold עבור עומסי עבודה של קידוד וידאו
  • פלטפורמת קידוד וידאו — קידוד serverless ומבוסס spot עם מאגרי עובדים בעלי קנה מידה אוטומטי (autoscaled worker pools)
Related Technologies
Cloud SolutionsAI Development
Infrastructure

ארכיטקטורה המעניקה עדיפות לאבטחה

אבטחה אינה תכונה שמוסיפים לאחר ההשקה. זוהי תכונה ארכיטקטונית – המערכת תוכננה עבורה, או שלא.

EnterpriseView
serverless-first-architecture.webp
Infrastructure

ארכיטקטורה ממוקדת Serverless

שלם רק על מה שאתה משתמש, סקייל לאפס כשאינך משתמש, והפסק לנהל שרתים לחלוטין — אך דע מתי הכלכלה מפסיקה להיות כדאית.

AdvancedView

שאלות נפוצות

לקוחות 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).