נבדק לאחרונה: יוני 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן NCP-GENL בודק. קראו מלמעלה למטה, או דלגו לסעיף.
צורך בזמן השהיה נמוך יותר ב-H100/Blackwell ללא פגיעה בדיוק כתוצאה מקוונטיזציית INT אגרסיבית.
השתמש בקוונטיזציית FP8 (E4M3) באמצעות TensorRT-LLM; ל-Hopper ול-Blackwell יש ליבות Tensor Core מקוריות התומכות ב-FP8.
למה: FP8 שומר על טווח דינמי טוב יותר מ-INT8 ופועל במהירות חומרה מלאה ב-Hopper+, ומספק איכות קרובה ל-FP16 בקצב תפוקה של INT8.
המודל בקושי נכנס לזיכרון ה-GPU והתפוקה מוגבלת על ידי רוחב פס הזיכרון.
החל קוונטיזציית INT4 weight-only (AWQ או GPTQ); שמור הפעלות (activations) ב-FP16/FP8.
למה: Weight-only INT4 מקטין את הזיכרון בערך בחצי לעומת INT8 ומקל על לחץ רוחב הפס; דיוק ההפעלה נשאר גבוה כך שאובדן הדיוק קטן.
החלטה בין קוונטיזציה לאחר אימון (post-training quantization) לאימון מודע קוונטיזציה (quantization-aware training).
התחל עם PTQ (כוונן על מדגם מייצג); חזור ל-QAT רק אם אובדן הדיוק של PTQ חורג מהתקציב.
למה: PTQ מהיר ואינו דורש אימון מחדש; QAT משחזר דיוק אך דורש הרצת אימון, לכן שמור אותו למודלים קריטיים לדיוק.
הגשה בהקשר ארוך שבה מטמון ה-KV שולט בזיכרון ומגביל את גודל האצווה (batch size).
הפעל קוונטיזציית מטמון KV מסוג FP8 או INT8 ב-TensorRT-LLM.
למה: מטמון ה-KV גדל עם אורך הרצף × אצווה; קוונטיזציה שלו משחררת זיכרון עבור אצוות גדולות יותר והקשרים ארוכים יותר עם השפעה מינימלית על האיכות.
אורכי בקשות מעורבים גורמים לזמן סרק של ה-GPU עם batching סטטי.
השתמש ב-in-flight (רציף) batching ב-TensorRT-LLM כך שרצפים שהסתיימו יפונו וחדשים יצטרפו באמצע הדרך.
למה: continuous batching שומר על ה-GPU רווי ומעלה את התפוקה הרבה מעבר ל-batching סטטי עבור זרמי בקשות הטרוגניים.
מודל מורה גדול עומד בדרישות איכות אך לא עומד ביעדי זמן השהיה ועלות.
בצע דיסטילציה למודל תלמיד קטן יותר, ולאחר מכן בצע קוונטיזציה לתלמיד עבור הסקה.
למה: דיסטילציה מעבירה יכולות לארכיטקטורה זולה יותר; בשילוב עם קוונטיזציה היא מגדילה את החיסכון בעלות/זמן השהיה.
זמן השהיה בזרם יחיד גבוה מדי עבור תרחיש שימוש אינטראקטיבי.
החל speculative decoding עם מודל טיוטה קטן המאומת על ידי מודל היעד.
למה: הטיוטה מציעה מספר אסימונים שהמודל הגדול מאמת במעבר אחד, ובכך מקצרת את זמן השהיה בפועל מבלי לשנות את התפלגות הפלט.
קוונטיזציה של הכל ל-INT4 פוגעת בדיוק בכמה שכבות רגישות.
השתמש בדיוק מעורב (mixed-precision): שמור על שכבות רגישות (כגון היטל סופי, attention) בדיוק גבוה יותר ובצע קוונטיזציה לשאר.
למה: הרגישות משתנה משכבה לשכבה; דיוק סלקטיבי מגן על הדיוק במקומות החשובים תוך הקטנת מרבית המשקלים.
דיוק ה-PTQ ירוד למרות תוכנית קוונטיזציה סבירה.
כייל מחדש עם מדגם מתוך ההתפלגות (מאות פרומפטים מייצגים) התואם את תעבורת הייצור.
למה: כיול מגדיר טווחי הפעלה; מדגם לא מייצג מייצר סקאלות שגויות ואובדן דיוק שניתן למנוע.
משקלי המודל חורגים מ-GPU בודד אך מתאימים לצומת יחיד המחובר באמצעות NVLink.
השתמש במקביליות טנסור (tensor parallelism) על פני יחידות ה-GPU בצומת.
למה: מקביליות טנסור מפצלת כל שכבה ומחליפה הפעלות בכל שלב, ולכן היא דורשת את רוחב הפס הגבוה תוך-צמתי של NVLink/NVSwitch.
המודל גדול מדי עבור צומת אחד וחייב להתפרס על פני צמתים דרך InfiniBand.
הוסף מקביליות צינור (pipeline parallelism) על פני צמתים, תוך שמירה על מקביליות טנסור בתוך כל צומת.
למה: מקביליות צינור מתקשרת רק בגבולות שלבים, וסובלת קישורים איטיים יותר בין-צמתים; שמור את מקביליות הטנסור, הדורשת רוחב פס גבוה, עבור NVLink.
הגדלת מספר יחידות ה-GPU מניבה רווחי תפוקה הולכים ופוחתים.
בצע פרופיל עם Nsight Systems כדי לסווג את צוואר הבקבוק; אם פעולות collective שולטות, הפחת את דרגת המקביליות או שפר את הטופולוגיה.
למה: מעבר לנקודה מסוימת, תקורה של all-reduce/all-gather עולה על כוח החישוב הנוסף; אבחון אם הצוואר הוא תקשורתי או חישובי מכוון את התיקון.
תקורה של הפעלת kernel בכל שלב מנפחת את זמן השהיית הפיענוח בגדלי אצווה קטנים.
אפשר CUDA Graphs כדי ללכוד ולהפעיל מחדש את לולאת הפיענוח.
למה: CUDA Graphs מאחדת הפעלות קטנות רבות להפעלה חוזרת אחת, ומסירה את תקורת ההפעלה מצד ה-CPU ששולטת בגדלי אצווה נמוכים.
דרגות מקביליות טנסור הממוקמות על פני קישור איטי גורמות לעיכובים.
קבע דרגות מקביליות טנסור ליחידות GPU החולקות NVLink/NVSwitch; מקם שלבי pipeline על פני צמתים.
למה: מיקום לא תואם מנתב פעולות collective בתדירות גבוהה מעל PCIe או InfiniBand, ובכך חונק את כל ה-pipeline.
Attention מוגבל זיכרון ומגביל את אורך ההקשר הניתן להשגה.
השתמש ב-FlashAttention (ליבות attention מאוחדות, מודעות IO) כפי שמסופק על ידי ערימת TensorRT-LLM/NeMo.
למה: FlashAttention נמנעת ממימוש מטריצת ה-attention המלאה, חותכת את תעבורת הזיכרון ומאפשרת רצפים ארוכים יותר במהירות גבוהה יותר.
מספר מודלים קטנים אינם מנצלים באופן מלא יחידות H100 GPU.
חלק יחידות GPU באמצעות MIG (Multi-Instance GPU) כדי לבודד כל מודל על פרוסה.
למה: MIG מספק מחיצות מבודדות חומרה, מעלה את הניצולת ומספק QoS צפוי לעומסי עבודה קטנים ממוקמים במשותף.
שירות במורד הזרם דורש JSON תקין לחלוטין בכל פעם.
השתמש בפיענוח מודרך/מוגבל (דקדוק או סכימת JSON) בסביבת ההגשה במקום להסתמך על ניסוח הפרומפט בלבד.
למה: פיענוח מוגבל ממסך אסימונים לא חוקיים בזמן הייצור, ומבטיח פלט תקין לפי סכימה, כאשר פרומפטים רק מפחיתים את שיעור הכשלונות.
משימה דורשת פורמט עקבי שהמודל הבסיסי מטפל בו באופן לא עקבי.
נסה תחילה דוגמאות few-shot; עבור לכוונון עדין רק אם ההכוונה מבוססת הפרומפט מגיעה לרוויה או שעלות האסימון מוגזמת.
למה: Few-shot הוא ללא אימון וניתן לעריכה מיידית; כוונון עדין מנצח רק כאשר התבניות יציבות ותקורה של פרומפטים פוגעת.
משימת הנמקה מרובת שלבים מניבה תשובות סופיות שגויות.
עודד "שרשרת מחשבה" ('חשוב שלב אחר שלב') או השתמש בתבנית הנמקה מובנית לפני התשובה הסופית.
למה: חשיפת שלבי ביניים משפרת את הדיוק בריבוי קפיצות והופכת שגיאות לניתנות לביקורת, במחיר של אסימונים נוספים.
שינוי קטן בפרומפט הוריד בשקט את איכות הייצור.
הפעל בקרת גרסאות על פרומפטים של המערכת כקוד, בקר שינויים מאחורי הערכה, ופרוס באמצעות אותו CI כמו ארטיפקטים של מודלים.
למה: פרומפטים הם חלק מחוזה המודל; עריכות ללא בקרת גרסאות גורמות לנסיגות לא מתועדות ולהתנהגות בלתי ניתנת לשחזור.
המודל מדמיין עובדות מחוץ לנתוני האימון שלו.
אחזר הקשר רלוונטי והזרק אותו לפרומפט עם הנחיה לענות רק מתוך ההקשר המסופק.
למה: ביסוס על קטעים מאוחזרים מגביל את המודל לחומר המקור ומפחית הזיות בשאילתות עשירות בידע.
זמן השהיה ועלות גבוהים מכיוון שהפרומפטים מנופחים.
קצץ ודחוס את הפרומפט: הסר כפילויות בהוראות, סכם הקשר מאוחזר, והגבל דוגמאות למינימום השומר על האיכות.
למה: Prefill מתאים את עצמו לאסימוני קלט; פרומפטים רזים מקטינים הן את זמן השהיה והן את העלות לכל בקשה ללא אובדן איכות מדיד.
טקסט המסופק על ידי המשתמש יכול לדרוס את הוראת המערכת.
הפרד הוראות מהימנות מקלט לא מהימן עם מפרידים ברורים וטפל בתוכן מאוחזר/משתמש כנתונים, לא כפקודות.
למה: שרשור טקסט לא מהימן לערוץ ההוראות מזמין הזרקת פרומפטים; גבולות מפורשים מפחיתים את שטח התקיפה.
התאמת מודל בסיס גדול לתחום מסוים בתקציב GPU מוגבל.
השתמש ב-LoRA: אמן מתאמי low-rank והקפא את משקלי הבסיס.
למה: LoRA מאמן חלק זעיר של פרמטרים, מקצץ זיכרון וחישוב תוך כדי התאמה לכוונון עדין מלא ברוב המשימות הצרות.
אפילו אימון LoRA של מודל 70B לא יתאים לזיכרון זמין.
השתמש ב-QLoRA: בצע קוונטיזציה לבסיס הקפוא ל-4 ביט (NF4) ואמן מתאמי LoRA מעליו.
למה: שמירת הבסיס ב-4 ביט תוך עדכון המתאמים בלבד מאפשרת כוונון עדין של מודלים גדולים ב-GPU בודד עם אובדן דיוק מינימלי.
בחירת דרגת LoRA למשימת כוונון עדין חדשה.
התחל עם דרגה צנועה (לדוגמה 8-16); העלה אותה רק אם המשימה מורכבת והפסד האימות עדיין משתפר.
למה: דרגה גבוהה יותר מוסיפה קיבולת ועלות; דרגת יתר (over-ranking) מסכנת overfitting על מערכי נתונים קטנים בעוד שדרגת חסר (under-ranking) מגבילה את האיכות הניתנת להשגה.
המודל עוקב אחר הוראות אך התפוקות שלו אינן תואמות העדפה אנושית.
בצע כוונון עדין מונחה (SFT) תחילה, ולאחר מכן יישור העדפות עם RLHF או DPO.
למה: SFT מלמד את הפורמט והמשימה; אופטימיזציית העדפות מעצבת אילו תשובות תקפות בני אדם מעדיפים בפועל.
RLHF עם PPO אינו יציב וכבד מבחינה תפעולית.
השתמש ב-DPO (Direct Preference Optimization) על מערך נתוני העדפות במקום מודל תגמול + לולאת PPO.
למה: DPO מייעל העדפות ישירות ללא מודל תגמול נפרד או הרצת RL, ובכך מפשט את ה-pipeline ומשפר את היציבות.
מתאם LoRA מוסיף תקורה לכל בקשה בזמן ההגשה.
מזג את משקלי המתאם לתוך הבסיס לצורך פריסה כאשר מוגש מתאם יחיד בלבד.
למה: מודל ממוזג אין לו ענף מתאם בהסקה; שמור מתאמים נפרדים רק כאשר מחליפים (hot-swapping) מספר משימות על בסיס אחד.
כוונון עדין על משימה צרה פוגע ביכולות כלליות.
ערבב פרוסה של נתונים כלליים/הוראות, הורד את קצב הלמידה, והעדף PEFT על פני כוונון עדין מלא.
למה: הפעלה מחדש של נתונים כלליים והגבלת תנועת המשקלים משמרת מיומנויות רחבות תוך כדי למידת המשימה החדשה.
נתוני טרום אימון/כוונון עדין מכילים כפילויות כבדות קרובות.
הרץ הסרת כפילויות מטושטשת (כגון MinHash/LSH) לפני האימון.
למה: כפילויות מבזבזות חישוב, מטים את המודל לתוכן חוזר, ויכולות לגרום לשינון; הסרת כפילויות משפרת הכללה לכל אסימון.
ציוני benchmark גבוהים באופן חשוד לאחר אימון.
בצע דה-קונטמינציה למערך האימון כנגד נתוני benchmark/הערכה באמצעות סינון חפיפת n-גרם.
למה: דליפה של פריטי בדיקה מנפחת מדדים ומסתירה איכות אמיתית; דה-קונטמינציה שומרת על הערכה הוגנת.
הקורפוס עשוי להכיל נתונים אישיים הכפופים לכללי ממשל.
הוסף שלב זיהוי וצנזור PII ל-pipeline הנתונים לפני האימון.
למה: אימון על PII גולמי מסכן חזרה וזיהוי של המידע והפרות תאימות; ניקוי מראש זול בהרבה מתיקון מודל דולף.
נתוני אינטרנט גולמיים שנאספו הם רועשים ומורידים את איכות המודל.
החל מסנני איכות (היוריסטיקות בתוספת מסווג) כדי להשמיט מסמכים באיכות נמוכה, טקסט שבלוני וספאם.
למה: איכות הנתונים עולה על כמות גולמית מעבר לסף מסוים; סינון מניב מודלים טובים יותר מאותו תקציב אימון.
נתוני כוונון עדין חייבים להיכנס בצורה נקייה ל-pipeline האימון של NeMo.
המר לפורמט NeMo הצפוי (לדוגמה JSONL עם שדות prompt/response) ובצע אסימוניזציה (tokenize) באמצעות ה-tokenizer של המודל.
למה: אי התאמות בפורמט וב-tokenizer גורמות לקיטוע שקט או שגיאות תווית; התאמה לסכמת NeMo שומרת על אימון שניתן לשחזר.
הקמת נקודת קצה של LLM לייצור במהירות עם API תואם OpenAI.
פרוס עם מיקרו-שירות NVIDIA NIM; בנה הרכבה מותאמת אישית של Triton רק עבור צרכי עיבוד מקדים/אחרי עיבוד לא סטנדרטיים.
למה: NIM מספק מנועים אופטימליים ו-API סטנדרטי ישר מהקופסה; Triton מותאם אישית שווה את המאמץ רק כאשר אתה זקוק לבקרת pipeline מותאמת אישית.
בקשות עצמאיות מגיעות מהר יותר ממה ששירות בקשה בודדת יכול לטפל בהן.
אפשר Triton dynamic batching כדי לאחד בקשות מקבילות לאצוות GPU.
למה: Batching מפזר את תקורת ה-kernel על פני בקשות, ומעלה את התפוקה בעלות קטנה ומוגבלת של זמן השהיה.
מופע מודל יחיד משאיר את כוח החישוב של ה-GPU לא מנוצל מספיק.
הגדר מספר מופעי מודל לכל GPU ב-Triton כדי לחפוף ביצוע.
למה: מופעים מקבילים ממלאים פערים חישוביים שנותרו על ידי עיכובים בזיכרון, ומשפרים את הניצולת כאשר הזיכרון מאפשר זאת.
התעבורה משוננת ועותקים קבועים מבזבזים יחידות GPU או מורידים SLOs.
בצע קנה מידה אוטומטי של עותקים לפי עומק תור / ניצולת GPU עם מאגר חם כדי לספוג הפעלות קרות.
למה: הפעלות קרות של LLM (טעינת מנוע) איטיות; קנה מידה על אות מוביל עם קיבולת חמה מגן על זמן השהיה בזמן עליות פתאומיות.
לקוחות קיימים מצפים ל-API של השלמות צ'אט של OpenAI.
חשוף את המודל דרך נקודת הקצה התואמת OpenAI של NIM כדי שלקוחות ישתלבו ללא צורך בכתיבה מחדש.
למה: API תואם "drop-in" ממזער את עבודת העברת הלקוח ומאפשר להחליף מודלים (backends) בשקיפות.
שינוי במודל או בפרומפט אסור שיפגע בשקט באיכות.
הרץ סט הערכה "זהב" מנוהל ב-CI וחסום פריסות היורדות מתחת לסף איכות.
למה: שערי רגרסיה אוטומטיים מזהים ירידות באיכות לפני שהן מגיעות למשתמשים, באותו אופן שבו בדיקות יחידה חוסמות קוד.
לפלטי קצה פתוח אין תשובה ייחוס יחידה לציון מולה.
השתמש ב-LLM כשופט עם קריטריוני הערכה (rubric), מכויל כנגד דירוגים אנושיים על מדגם.
למה: שופט מונחה קריטריונים מאפשר קנה מידה של הערכה סובייקטיבית; כיול אנושי מגן מפני הטיה של השופט עצמו.
ציון MMLU גבוה אך משתמשים מתלוננים על משימת הייצור.
הערך באמצעות מדדים ספציפיים למשימה הקשורים לתוצאות עסקיות, ולא רק מדדי ייחוס גנריים.
למה: מדדי ייחוס גנריים מתואמים חלש למשימות ממוקדות; המדד הנכון משקף את מה שהמשתמשים באמת צריכים.
הערכות לא מקוונות נראות טובות אך ההשפעה בעולם האמיתי אינה וודאית.
הרץ בדיקת A/B מקוונת המנתבת חלק מהתעבורה לגרסה החדשה והשווה מדדי תוצאה.
למה: A/B חי לוכד שינוי התפלגות והתנהגות משתמשים שסטים לא מקוונים מפספסים, ומאשר שיפור אמיתי.
צורך בנראות לגבי תקינות וניצולת ה-GPU על פני צי שרתים.
ייצא מדדי DCGM (ניצולת, זיכרון, ECC, טמפרטורה) ל-Prometheus והתריע עליהם.
למה: DCGM הוא מקור הטלמטריה הסטנדרטי של NVIDIA; בלעדיו, רוויה ותקלות ברמת ה-GPU אינם מתגלים.
משתמשים רואים לסירוגין תגובות איטיות אך זמן השהיה הממוצע נראה בסדר.
עקוב אחר זמן הגעה של אסימון ראשון וזמן השהיה בין אסימונים ב-p95/p99, והתריע על הפרות SLO של אחוזונים.
למה: ממוצעים מסתירים זמן השהיה בזנב; חווית המשתמש של LLM נקבעת על ידי p95/p99, לכן מדדי SLI אחוזונים הם אות ההתראה הנכון.
פריסת גרסת מודל חדשה לנקודת קצה בעלת תעבורה גבוהה.
פרוס באמצעות canary (פרוסת תעבורה קטנה) עם חזרה אוטומטית במקרה של SLO או נסיגת איכות.
למה: Canarying מגביל את טווח הפגיעה ומאפשר למדדים לאשר בטיחות לפני פריסה מלאה, בניגוד לפריסה מסיבית מיידית.
התפוקה קורסת תחת עומס ללא עלייה ברורה בכוח החישוב של ה-GPU.
נטר את ניצולת מטמון ה-KV וחריצי האצווה (batch-slot); הרחב קנה מידה (scale out) או קצר את ההקשר המרבי כאשר המטמון מגיע לרוויה.
למה: התרוקנות מטמון ה-KV מגבילה במקביל לפני כוח החישוב; מעקב אחר זה מסביר נפילות תפוקה שניצולת ה-GPU לבדה מפספסת.
מטמון ה-KV גדול מדי עבור אצווה והקשר היעד.
העדף ארכיטקטורה המשתמשת ב-Grouped-Query Attention (GQA) או Multi-Query Attention (MQA).
למה: GQA/MQA משתפים ראשי מפתח/ערך, מקטינים את זיכרון מטמון ה-KV ומעלים את גודל האצווה הניתן להשגה עם אובדן איכות קטן.
צורך להרחיב את ההקשר השמיש של מודל מעבר לאורכו המאומן.
השתמש בסקאלינג RoPE (לדוגמה NTK-aware / YaRN) בתוספת כוונון עדין קל להקשר ארוך.
למה: אינטרפולציית RoPE מותחת קידודי מיקום (positional encodings); כוונון עדין קצר מתאים את המודל לטווח הארוך יותר ללא אימון מחדש מלא.
רוצה יותר קיבולת ללא עלות הסקה פרופורציונלית.
שקול מודל Mixture-of-Experts (MoE) שמפעיל רק את k המומחים המובילים לכל אסימון.
למה: MoE מגדיל פרמטרים תוך שמירה על FLOPs נמוך לכל אסימון, אך מוסיף מורכבות ניתוב ועומס מומחים לא אחיד לניהול.
מודל פרוס זקוק לגבולות נושא, בטיחות ופורמט.
עטוף את המודל באמצעות NeMo Guardrails כדי לאכוף גבולות קלט ופלט (נושאיים, מיתון, jailbreak).
למה: מנגנוני "rails" הניתנים לתכנות מוסיפים שכבת בטיחות ניתנת לשליטה סביב המודל מבלי לאמן אותו מחדש.
המודל מייצר מדי פעם תוכן רעיל או לא בטוח.
הוסף מסווג מיתון פלט וחסום/צור מחדש תגובות החורגות מסף סיכון.
למה: מעבר מיתון נפרד לוכד יצירות לא בטוחות שהוראות ברמת הפרומפט לבדן אינן מונעות באופן מהימן.
בעלי עניין דורשים הוכחה שהמודל עומד בתקני AI אחראי.
הרץ מדדי ייחוס של הטיה ורעילות, תעד תוצאות, ועקוב אחריהם על פני גרסאות בכרטיס מודל.
למה: הערכת בטיחות מתועדת וניתנת לשחזור תומכת בתאימות ומצביעה על רגרסיות לפני שהן מגיעות לייצור.