נבדק לאחרונה: יוני 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן NCA-AIIO בודק. קראו מלמעלה למטה, או דלגו לסעיף.
החלט אם עומס עבודה שייך ל-GPUs או ל-CPUs.
מתמטיקה מקבילית במיוחד (אימון/הסקת deep-learning, פעולות מטריצה, סימולציה) ← GPU. לוגיקת בקרה סדרתית ועשירת הסתעפויות, משימות OS, קלט/פלט קל ← CPU.
למה: ל-GPUs יש אלפי ליבות הממוטבות לתפוקה בעבודה מקבילית של SIMT; מעבדי CPU מנצחים בלוגיקה סדרתית הרגישה לזמן אחזור. רוב מערכות ה-AI משלבות את שניהם.
בחר את אבן הבניין של NVIDIA: מתקן שלם לעומת לוח למערכות OEM.
שרת AI משולב מוכן לשימוש (GPUs + CPUs + NVLink + רשתות + תוכנה) ← DGX. לוח אם ל-GPU שספקי OEM/ענן בונים סביבו שרתים ← HGX.
למה: DGX היא מערכת הייחוס המוכנה להפעלה של NVIDIA; HGX הוא לוח ה-multi-GPU שספקי hyperscalers משלבים בעצמם.
כרטיסי GPU בשרת אחד זקוקים לרוחב פס מהיר יותר בין GPU ל-GPU ממה שהאפיק מספק.
השתמש ב-NVLink (וב-NVSwitch לתקשורת all-to-all) עבור קישוריות GPU בתוך צומת ברוחב פס גבוה; PCIe הוא חלופה כאשר NVLink אינו זמין.
למה: NVLink מספק רוחב פס גבוה בהרבה בין GPU ל-GPU וזמן אחזור נמוך יותר מ-PCIe – קריטי לאימון מקביל מודל (model-parallel) ואצוות גדולות בתוך צומת.
כל 8 ה-GPUs בצומת חייבים לתקשר ביניהם בו-זמנית ברוחב פס מלא של NVLink.
NVSwitch — רשת מתגים ללא חסימה שמחברת כל GPU לכל GPU אחר במהירות מלאה של NVLink.
למה: NVLink נקודה-לנקודה לבדו אינו מספק רוחב פס all-to-all; NVSwitch מספק את ה-crossbar לתקשורת GPU מסוג full-mesh.
הבחן בין קישוריות scale-up (בתוך שרת) לבין scale-out (על פני שרתים).
קישוריות GPU מסוג Scale-up בתוך צומת ← NVLink/NVSwitch. קישוריות Scale-out על פני צמתים באשכול ← InfiniBand (או RoCE Ethernet).
למה: NVLink הוא בתוך צומת (intra-node); InfiniBand מחבר צמתים לאשכול לצורך אימון מבוזר מרובה צמתים.
בחר את רשת האשכול (cluster fabric) לאימון מבוזר בקנה מידה גדול שבו זמן האחזור של פעולות קולקטיביות (collective-op) הוא החשוב ביותר.
זמן האחזור הנמוך ביותר, חישוב בתוך הרשת (SHARP), RDMA-native ← InfiniBand. מוכר, בעלות נמוכה יותר, אקוסיסטם רחב ← RoCE על Spectrum-X Ethernet.
למה: InfiniBand עם SHARP מוריד את פעולות all-reduce למתג, ומקצר את זמן האחזור הקולקטיבי; Spectrum-X היא התשובה של NVIDIA לרשתות Ethernet עבור AI.
הורד את עבודת הרשת, האחסון ועיבוד האבטחה מה-CPU כך שהליבות יתפנו לחישוב AI.
NVIDIA BlueField DPU — יחידת עיבוד נתונים ניתנת לתכנות המפנה ומבודדת שירותי תשתית מ-CPU/GPU המארח.
למה: DPUs מאיצים רשתות east-west, אחסון NVMe-oF, ואבטחת zero-trust, ומעלים את ניצול ה-GPU/CPU האפקטיבי ובידוד הדיירים.
צריך NIC מהיר עם RDMA לצמתי GPU ללא פריקת DPU מלאה.
NVIDIA ConnectX SmartNIC — מתאם InfiniBand/Ethernet עם תפוקה גבוהה, תמיכה ב-RDMA ו-GPUDirect.
למה: ConnectX מספק RDMA בקצב קו (line-rate); BlueField מוסיף תת-מערכת Arm ניתנת לתכנות מעל לצורך פריקת תשתית מלאה.
צמצם את זמן האחזור על ידי העברת נתונים לזיכרון ה-GPU ללא מעבר דרך זיכרון ה-CPU/מארח.
GPUDirect RDMA — כרטיסי NIC קוראים/כותבים זיכרון GPU ישירות; GPUDirect Storage עושה את אותו הדבר עבור אחסון NVMe.
למה: עקיפת ה-CPU bounce buffer מסירה העתקות וזמן אחזור מנתיב הנתונים, דבר חיוני לתפוקת אימון מרובה צמתים.
בחר ארכיטקטורת GPU מודרנית למרכזי נתונים לאימון מודלים גדולים.
Hopper (H100/H200) היא הדור המבוסס עם Transformer Engine + FP8; Blackwell (B200/GB200) היא הדור החדש יותר עם תפוקה גבוהה יותר ו-FP4 למודלים הגדולים ביותר.
למה: שניהם מיועדים לעומסי עבודה של Transformer; Blackwell מקדם את קנה המידה ואת הסקת המסקנות בדיוק נמוך יותר (FP4). התאם לתקציב ולגודל המודל.
זהה את החומרה שמאיצה את מתמטיקת המטריצות של deep-learning.
Tensor Cores — יחידות מיוחדות המבצעות פעולות fused matrix-multiply-accumulate בדיוק מעורב (FP16/BF16/FP8/FP4).
למה: הם מספקים תפוקה גבוהה בסדר גודל ב-GEMM/convolution מאשר ליבות CUDA רגילות, מה שמניע את ביצועי ה-DL.
מודל גדול לא מתאים; רוחב פס הזיכרון, ולא החישוב, הוא צוואר הבקבוק.
בחר GPUs עם HBM רב ומהיר יותר (לדוגמה, H200/B200 עם HBM3e); השתמש במקביליות מודל מרובת-GPU כאשר הזיכרון של GPU אחד אינו מספיק.
למה: אימון/הסקת מודלים גדולים מוגבלים לעיתים קרובות בקיבולת זיכרון וברוחב פס; HBM מספק את רוחב הפס הגבוה שה-GPUs זקוקים לו.
הקם מחשב-על AI מרובה ארונות (multi-rack), מוכן לשימוש ומאומת, לאימון ארגוני.
NVIDIA DGX SuperPOD — ארכיטקטורת ייחוס של צמתי DGX, רשת InfiniBand, אחסון ותוכנת Base Command.
למה: SuperPOD הוא התכנון המלא והמאומת מראש; הוא מבטל את ניחושי החיווט של הרשת, האחסון והתיאום בקנה מידה גדול.
קבל יכולת אימון ברמת DGX מבלי להחזיק בחומרה.
NVIDIA DGX Cloud — תשתית אימון AI מנוהלת המתארחת אצל ספקי ענן גדולים, ונגישה כשירות.
למה: OpEx מול CapEx: DGX Cloud מתאים לאימון מתפרץ או קצר טווח; DGX/SuperPOD מקומי מתאים לניצול גבוה מתמשך ולאילוצי כבידת נתונים.
בחר אשכול GPU מקומי לעומת GPUs בענן עבור עומסי עבודה של AI.
ניצול גבוה מתמשך, ריבונות נתונים, הוצאות צפויות ← DGX/SuperPOD מקומי. דרישה משתנה/מתפרצת, התחלה מהירה, ללא טביעת רגל של מרכז נתונים ← ענן או DGX Cloud.
למה: GPUs בבעלות פרטית מתגלגלים היטב רק בניצול יציב וגבוה; חומרה בבעלות פרטית שאינה בשימוש היא עלות טהורה.
אשכול GPU חדש חורג מתקציב הכוח והקירור של מתקן ה-rack במרכז נתונים קיים.
תכנן עבור כוח בצפיפות גבוהה (עשרות קילוואט/rack) וקירור נוזלי עבור ה-GPUs החדשים ביותר; קבע את גודל ה-PDUs, ה-busways והקיבולת התרמית לפני ההתקנה.
למה: צמתי GPU מודרניים (וארונות GB200) צורכים הרבה יותר כוח וחום מאשר שרתים מדור קודם; קירור אוויר ו-PDUs סטנדרטיים לרוב אינם יכולים לעמוד בקצב.
האימון נעצר כי צינור הנתונים לא יכול להזין את ה-GPUs מספיק מהר.
השתמש באחסון מקבילי/NVMe בעל תפוקה גבוהה עם GPUDirect Storage; תכנן עבור רוחב פס קריאה מתמשך כדי לשמור על ה-GPUs רוויים.
למה: קלט/פלט אחסון בתת-הקצאה מותיר GPUs יקרים בחוסר פעילות בהמתנה לנתונים; רמת האחסון חייבת להתאים לדרישת הקריאה המצטברת של ה-GPU.
מודל גדול מדי מכדי לאמן אותו על צומת יחיד בתוך זמן סביר.
הגדל את קנה המידה למספר צמתים מעל InfiniBand באמצעות מקביליות נתונים/טנזורים/צינור (data/tensor/pipeline parallelism); NCCL מטפל בתקשורת הקולקטיבית של ה-GPU.
למה: הגדלת קנה המידה למספר צמתים דורשת רשת עם זמן אחזור נמוך וספריית קולקטיבים אופטימלית (NCCL); רשת איטית הורסת את יעילות ההגדלה.
A100/H100 יחיד הוא מוגזם עבור עבודות הסקה קטנות; אתה רוצה פרוסות מבודדות חומרה.
Multi-Instance GPU (MIG) — חלק GPU אחד לעד 7 מופעים מבודדים, כל אחד עם חישוב וזיכרון ייעודיים.
למה: MIG מספק בידוד חומרה אמיתי ו-QoS צפוי להסקה מרובת דיירים, בניגוד ל-time-slicing רך.
הבחן בין AI, למידת מכונה (machine learning) ולמידה עמוקה (deep learning).
AI היא המטרה הרחבה; ML הוא תת-קבוצה הלומדת מנתונים; DL הוא תת-קבוצה של ML המשתמשת ברשתות נוירונים רב-שכבתיות.
למה: הם מקוננים: DL ⊂ ML ⊂ AI. DL מניע את הביקוש ל-GPU מודרניים מכיוון שרשתות נוירונים הן מקביליות במיוחד.
הבחן בין פרופיל החישוב של אימון לעומת הסקה.
אימון = עתיר חישוב וזיכרון, ארוך טווח, אצווה, GPUs רבים. הסקה = רגישה לזמן אחזור, קלה יותר, לעיתים קרובות GPU יחיד/חלקי, פועלת באופן רציף בייצור.
למה: יש להם צרכי חומרה וקנה מידה שונים; גודל אשכול דורש הפרדה בין שני עומסי העבודה.
בחר פרדיגמת למידה: נתונים מתויגים, נתונים לא מתויגים, או ניסוי וטעייה מונחי-תגמול.
מתויג ← למידה מפוקחת (supervised). אשכולות/מבנה לא מתויגים ← למידה בלתי מפוקחת (unsupervised). סוכן (agent) לומד מתגמול ← למידת חיזוק (reinforcement learning).
למה: הנתונים שיש לך (והמטרה) מכתיבים את הפרדיגמה; RLHF היא למידת חיזוק המונחית על ידי משוב אנושי ליישור (align) LLMs.
הסבר מדוע רשתות נוירונים מתאימות היטב ל-GPUs.
הן שכבות של כפל מטריצות משוקללות והפעלות לא ליניאריות — אלגברה ליניארית מקבילית וצפופה ש-GPUs מבצעים ביעילות.
למה: מעברים קדימה/אחורה עתירי GEMM; Tensor Cores מאיצים בדיוק זאת, וזו הסיבה ש-DL פועל על GPUs.
זהה את הארכיטקטורה שמאחורי LLMs מודרניים ו-AI גנרטיבי.
ה-Transformer — ארכיטקטורה מבוססת קשב (attention) המתרחבת עם נתונים ופרמטרים; מודלי יסוד (foundation models) ו-LLMs בנויים עליה.
למה: Transformers ניתנים למקביליזציה גבוהה, וזו הסיבה שהם מניעים את הביקוש לאשכולות GPU גדולים ולחומרת Transformer Engine.
האץ את האימון וצמצם את השימוש בזיכרון מבלי לפגוע באופן מהותי בדיוק.
השתמש בדיוק מעורב (mixed precision) — FP16/BF16 (ו-FP8 ב-Hopper/Blackwell) למתמטיקה, FP32 לצבירה (accumulation); Tensor Cores מאיצים את פעולות הדיוק הנמוך יותר.
למה: דיוק נמוך יותר חותך את הזיכרון בחצי ומכפיל את התפוקה; סקאלינג הפסד (loss scaling) / BF16 שומר על יציבות מספרית.
נקוב בשם היסוד המאפשר לתוכנה לפעול על NVIDIA GPUs.
CUDA — פלטפורמת המחשוב המקבילי ומודל התכנות של NVIDIA; CUDA-X היא שכבת הספריות (cuDNN, cuBLAS, NCCL, RAPIDS וכו').
למה: Frameworks כמו PyTorch/TensorFlow קוראים לספריות CUDA-X מתחת למכסה המנוע; CUDA הוא ה"חפיר" שקושר תוכנת AI ל-NVIDIA GPUs.
האץ פרימיטיבים של למידה עמוקה (convolutions, attention) בתוך framework.
cuDNN מספק פרימיטיבים של DL ממוטבי GPU; cuBLAS מטפל באלגברה ליניארית צפופה; שניהם יושבים מתחת ל-PyTorch/TensorFlow.
למה: ספריות אלו הן הסיבה לכך ש-frameworks מקבלים מהירות GPU מבלי שתצטרך לכתוב CUDA kernels.
קבל מכולות (containers), מודלים ו-Helm charts ממוטבים של NVIDIA, מוכנים ל-GPU.
קטלוג NGC (NVIDIA GPU Cloud) — מאגר מתורבת של מכולות ממוטבות (frameworks, NIM, Triton), מודלים מאומנים מראש (pretrained models), ו-SDKs.
למה: מכולות NGC מגיעות מכוילות ונבדקות עבור NVIDIA GPUs, מה שמבטל ניחושי תלות ותאימות דרייברים.
הגש מודלים רבים מ-frameworks מרובים מאחורי נקודת קצה אחת סטנדרטית ויעילה ל-GPU.
NVIDIA Triton Inference Server — הגשת מודלים מרובת framework עם batching דינמי, ביצוע מודלים מקביל ושיתוף GPU.
למה: Triton ממקסם את ניצול ה-GPU עבור הסקה באמצעות batching ומקביליות מודלים במקום תהליך אחד לכל מודל.
פרוס מודל יסוד (foundation model) כמיקרו-שירות הסקה ממוטב ומוכן לייצור במהירות.
NVIDIA NIM — מיקרו-שירותי הסקה בנויים מראש, מבוססי מכולות, עם מנועים ממוטבים וממשקי API סטנדרטיים למודלים פופולריים.
למה: NIM אורז מודל + סביבת ריצה ממוטבת (TensorRT-LLM/Triton) + API ליחידה אחת שניתנת לפריסה, ומקצר את זמן ההגעה לייצור.
צמצם את זמן האחזור בהסקה והגדל את התפוקה עבור מודל מאומן.
הדר את המודל עם TensorRT (או TensorRT-LLM עבור LLMs) — מיזוג שכבות (layer fusion), כיול דיוק (INT8/FP8), וכיוונון אוטומטי של קרנלים (kernel auto-tuning).
למה: TensorRT מייצר מנוע הסקה ממוטב עבור ה-GPU היעד, ולעיתים קרובות מכפיל את התפוקה לעומת ה-framework הגולמי.
האץ הכנת נתונים בסגנון pandas/scikit-learn ו-ML קלאסי על GPUs.
NVIDIA RAPIDS — cuDF (DataFrames), cuML (ML), cuGraph (graphs) מריצים את זרימת העבודה של מדעי הנתונים על GPUs.
למה: RAPIDS שומר על ETL טבלאי ו-ML קלאסי על ה-GPU, ובכך מונע צווארי בקבוק של CPU בצינור.
נהל עומסי עבודה, משימות ומשתמשים של AI על פני אשכול DGX/SuperPOD.
NVIDIA Base Command — תזמון משימות, ניהול אשכול ותזמור עומסי עבודה עבור תשתית DGX.
למה: Base Command הוא מישור הבקרה התפעולי למערכות DGX; הוא מטפל בהגשת משימות מרובות משתמשים ובמעקב אחר משאבים.
צריך תוכנת AI נתמכת, מאובטחת וברמת ייצור עם SLAs ארגוניים.
NVIDIA AI Enterprise — חבילת התוכנה הנתמכת (frameworks, NIM, Triton, RAPIDS, GPU Operator) עם תיקוני אבטחה ותמיכה ארגונית.
למה: הוא מאגד את הערימה המאומתת עם תמיכה ואחריות למחזור חיים, כפי שנדרש בסביבות מוסדרות/ייצור.
הגדר מודל יסוד (foundation model) וכיצד צוותים מתאימים אותו.
מודל גדול שאומן מראש על נתונים רחבים, ניתן להתאמה למשימות רבות באמצעות prompting, RAG, או fine-tuning במקום אימון מאפס.
למה: התאמה (prompt/RAG/fine-tune) זולה בהרבה מאימון מראש (pretraining); רוב הארגונים צורכים מודלי יסוד ולא בונים אותם.
הוסף ידע פרטי/עדכני לאפליקציה המגובה ב-LLM.
עובדות המשתנות לעיתים קרובות ← RAG (אחזר מחנות וקטורית (vector store) בהסקה). למד התנהגות/סגנון/מיומנות תחום חדשים ← fine-tuning.
למה: RAG שומר נתונים חיצוניים וניתנים לעדכון ללא אימון מחדש; fine-tuning אופה התנהגות למשקולות ויקר יותר לרענן.
שפוט אם GPUs יקרים מנוצלים ביעילות.
עקוב אחר ניצול GPU, שימוש בזיכרון ופעילות SM/Tensor-Core; ניצול נמוך מאותת על צווארי בקבוק בצינור הנתונים, גודל אצווה או תזמון.
למה: GPU "עסוק" על פי שעון קיר עדיין יכול להסוות חישוב אפקטיבי נמוך; הסתכל על תפוסת Tensor-Core/SM, לא רק על מד הניצול.
נטר את תקינות ה-GPU, ניצול, טמפרטורה, הספק ושגיאות על פני אשכול.
NVIDIA DCGM (Data Center GPU Manager) — טלמטריה, בדיקות תקינות ואבחון; ייצא מדדים ל-Prometheus/Grafana.
למה: DCGM הוא מקור הטלמטריה הסטנדרטי של GPU; ה-DCGM Exporter מזין את Prometheus עבור לוחות מחוונים והתראות ברמת האשכול.
ספק דרייברים ל-GPU, את ערכת הכלים של המכולות וניטור על אשכול Kubernetes ללא התקנה ידנית לכל צומת.
NVIDIA GPU Operator — אוטומטי תצורת דרייבר, סביבת ריצת מכולות, device plugin, DCGM ו-MIG ב-Kubernetes.
למה: הוא מנהל את מחזור החיים המלא של תוכנת ה-GPU באופן דקלרטיבי, ומבטל התקנות דרייברים שבריריות של צומת-לצומת.
בחר מנהל תזמור (orchestrator) לעומסי עבודה של GPU.
מיקרו-שירותים/הסקה, cloud-native, עומסי עבודה מעורבים ← Kubernetes. משימות אימון בסגנון HPC באצווה, תזמון "חבורות" (gang scheduling), אשכולות מסורתיים ← Slurm.
למה: Kubernetes מצטיין בשירותים ארוכי טווח ובגמישות; Slurm מצטיין במשימות אצווה בתור עם תזמון בסגנון MPI.
פודים (pods) של Kubernetes צריכים לבקש ולהיות מתוזמנים על GPUs.
ה-device plugin של NVIDIA מפרסם GPUs כמשאבים ניתנים לתזמון; פודים מבקשים `nvidia.com/gpu` והמתזמן ממקם אותם.
למה: ללא ה-device plugin, Kubernetes אינו יכול לראות או להקצות GPUs; זה מה שהופך את ה-GPUs למשאב מדרגה ראשונה.
משימות/משתמשים קטנים רבים חייבים לחלוק GPUs כדי להעלות את הניצול.
בידוד חומרה ← MIG. שיתוף רך של GPU אחד ← time-slicing או MPS. שלב עם מכסות מרחבי שם (namespace quotas) להוגנות.
למה: MIG מספק הבטחות QoS; time-slicing/MPS מבצעים oversubscribe ל-GPU ללא בידוד. בחר לפי דרישת הבידוד.
אימון בעדיפות גבוהה חייב לדחוק ניסויים בעדיפות נמוכה באשכול משותף.
השתמש בעדיפות/דחייה (priority/preemption) ובתורים במתזמן (Slurm partitions או Kubernetes PriorityClasses עם מכסה); תזמן משימות multi-GPU כ"חבורה" (gang-schedule).
למה: תזמון "חבורות" (gang scheduling) מונע קיפאון בהקצאה חלקית; priority classes אוכפים סדר עסקי על GPUs נתונים בתחרות.
שמור על גרסאות דרייברים ל-GPU, CUDA וערכת כלי המכולות עקביות ותואמות על פני צמתים.
תקנן באמצעות ה-GPU Operator (Kubernetes) או מכולות NGC; התאם את הדרייבר לגרסאות ה-CUDA שה-frameworks שלך זקוקים להן ופרוס עדכונים בחלונות תחזוקה.
למה: חוסר התאמה בין דרייבר/CUDA/framework הם גורם מרכזי לכשלים באשכול; CUDA מקובע במכולה מפריד את האפליקציה מהדרייבר המארח בטווחים נתמכים.
קבע את גודל אשכול GPU עבור דרישות אימון והסקה חזויות.
הפרד אימון (שיא, אצווה) מהסקה (מתמשך, מוגבל בזמן אחזור); תכנן מרווח בטחון לכוח/קירור/רשת וכיוון לניצול יציב וגבוה.
למה: הגדלת יתר מבזבזת CapEx על GPUs מובטלים; הקטנה יתר על המידה מחניקה את האספקה. תכנן לפי תמהיל עומסי העבודה, לא שיא יחיד.
GPUs מאטים (throttles) או נכשלים תחת עומס כבד מתמשך.
נטר טמפרטורה והספק באמצעות DCGM; ודא קירור הולם (נוזלי עבור racks צפופים), קבע מגבלות הספק סבירות, והתריע על ספי טמפרטורה.
למה: האטה תרמית (Thermal throttling) מפחיתה את התפוקה בשקט; טלמטריה פרואקטיבית ותכנון קירור מגנים הן על הביצועים והן על אורך חיי החומרה.
ספק האצת GPU למספר מכונות וירטואליות (VMs) או משתמשי VDI מחומרה משותפת.
תוכנת NVIDIA vGPU מחלקת GPU פיזי בין VMs עם תזמון ובידוד; MIG יכול לתמוך בפרופילי vGPU עבור חלוקה קשיחה.
למה: vGPU מאפשר גישת GPU וירטואלית/מרובת דיירים (VDI, ענן) ש-bare-metal passthrough אינו יכול לשתף.
צומת מחזיר שגיאות Xid או משימות נכשלו; עליך לבודד GPUs פגומים לפני שהם משחיתים ריצות נוספות.
הפעל אבחון DCGM ובדיקות תקינות אקטיביות; בודד/רוקן את הצומת, החלף או אפס את ה-GPU, ורק אז החזר אותו למאגר.
למה: שגיאות Xid ותקלות ECC מסמנות GPUs כושלים; שער בריאות אוטומטי מונע מ-GPU פגום להרעיל את מאגר התזמון.