הגדרת סביבת AI מקומית: Conda, GPU, PyTorch

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

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

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

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

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

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

מה נותנת סביבה ניתנת לשחזור לצוות מהנדסים

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

אופן הבידוד קובע כמה זמן לוקח לפרוס סביבה מאפס ועד כמה התוצאה צפויה.

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

המהנדסים שלנו בונים סביבות כאלה על PyTorch ומחזיקים מניפסט נפרד לכל פרויקט — עדכון של ספרייה אחת לא גורר בנייה מחדש של האחרות.

סביבות מבודדות והתקנה משותפת: השוואת גישות

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

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

איך מתבצעת ההטמעה: שלבי העבודה ההנדסית

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

1. ביקורת סביבה. מציגים מלאי של מכונות, דרייברי מאיצים וסביבות קיימות, ומתעדים היכן האימון רץ והיכן נופל.
2. סכמת תלויות. בונים מפת חבילות וגרסאות, מאחדים אימון והרצת מודלים לסט משותף, מבודדים פרויקטים ומצמידים גרסאות במניפסטים.
3. הגדרת מאיצים וגישה. מעלים דרייברים, בודקים זיהוי התקנים על ידי הסביבה, מפזרים אותם בין משימות, ומפרידים הרשאות לנתונים ולמאגר מודלים לפי תפקידים.
4. בדיקת יכולת שחזור. פורסים סביבה מאפס במכונה נקייה ומריצים תרחיש ייחוס: פער במטריקות מול ריצת בקרה הוא סיבה לעצור את הקבלה.
5. נוהל עדכונים. משנים גרסאות רק דרך סביבת בדיקה, עם תיעוד מטריקות ויכולת חזרה לסט הקודם.
6. קבלת הסביבה. מעבירים סקריפטי פריסה, מניפסטים, הוראות וצ'קליסט בדיקה — המהנדסים שלכם בונים את הסביבה בעצמם.

מה נשאר אצלכם אחרי ההעברה

הסביבה מפסיקה להיות תלויה באדם מסוים: נבנית ממניפסטים, נבדקת לפי צ'קליסט, מתעדכנת לפי נוהל. מהנדס חדש נכנס לעבודה בהתקנה אחת, ולא אחרי שבוע של ניפוי ידני של «למה אצלי זה לא רץ».

תצורות, סכמות תלויות ונוהלי העברה

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

• קבצי תיאור סביבות — מניפסט עם גרסאות מוצמדות וענפים נפרדים לשכבת בסיס ולפרויקט; פריסה במכונה נקייה בפקודה אחת.
• סכמת קשרים בין פרויקטים — היכן שכבת הבסיס המשותפת, היכן סביבה מבודדת עם סט הספריות שלה ולמה הגבול עובר דווקא כך.
• מדיניות גישה לצמתי חישוב — תפקידים, מכסות למאיצים, למי מותר להריץ משימות ארוכות ולשנות את שכבת הבסיס המשותפת.
• תיעוד הסביבה — מפת תיקיות, משתנים, נקודות כניסה, מיקום מערכי נתונים ומודלים שמורים.
• נוהל עדכון תלויות — תדירות, צומת ניסוי לבדיקת תאימות, קריטריונים לחזרה לאחור וסדר פעולות בעת קונפליקט גרסאות.
• הוראות להעברת הסביבה לצוות — המסלול של מהנדס חדש משכפול המאגר ועד הרצת האימון הראשונה, כולל שגיאות אופייניות.
• גיליון בדיקות קבלה — סט בדיקות שמורצות במכונה נקייה לפני העברת הסביבה למתאר המשותף.

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

מקרה בוחן: זירזנו פריסת סביבות והסרנו פערים

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

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

מה שינינו

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

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

מה לעשות אם התלויות כבר התפזרו בין מכונות

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

הצעד הראשון — לא לבנות הכול מחדש, אלא להפיק תצלום מדויק של סביבת העבודה: רשימה מלאה של חבילות עם גרסאות, הצמדה לרוחב סיביות ולספריות מערכת, ובנפרד — גרסאות דרייברי המאיץ.

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

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

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

האפקט מדיד: פריסת תחנת עבודה חדשה אורכת דקות במקום שעות של התקנה ידנית, ושיעור המשימות שמשוחזרות במכונה שנייה שואף למלוא. הגדרת סביבת פיתוח AI מפסיקה להיות גבורה חד-פעמית של מהנדס אחד והופכת לתהליך ניתן לשחזור.

ספקות טכניים: תאימות, הרשאות, עדכונים

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

להלן מה ששואלים לרוב בשלב ההערכה: איך הסביבות מסתדרות זו עם זו, מי מקבל גישה לצמתים, ומה קורה בעת עדכון.

מי ואיך מקבל גישה לצמתי חישוב?

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

אפשר לעדכן סביבה בלי השבתה?

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

חלק מהעבודה מתבצע על מכונות של העובדים — האם זה תואם?

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

נדון במשימה ונחזור עם הערכה ותוכנית

כדי שהדיון יהיה ענייני, מספיק לשלוח את מה שכבר יש בהישג יד: אין צורך בערכה מלאה, אפילו סט חלקי נותן הבנה של היקף משימת הגדרת הסביבה.

• רשימת מודלים ותרחישים שצריכים לעבוד: אימון מאפס, אימון נוסף על נתונים שלכם או רק הסקה;
• הרכב הציוד: דגמי מאיצים, מספרם, מכונה אחת או כמה צמתים;
• מגבלות נתונים: היכן הם נמצאים, האם מותר להוציא אותם מחוץ לפרימטר, והאם נדרש בידוד סביבות בין צוותים;
• דרישות ליכולת שחזור: האם מספיק להרים סביבה בפקודה אחת מגרסאות מוצמדות או שנדרשת תמונה ניידת;
• אופן העבודה: הגדרה חד-פעמית או ליווי עם עדכונים מתוכננים לספריות ולדרייברים;
• מי מקבל את התוצאה והיכן תרוץ ההרצה — משאבי ענן או שרתים משלכם.

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

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