On-premise LLM: היכן שמערך הענן נכשל
חלק מהבקשות פיזית לא יכולות לצאת מההיקף: נתונים אישיים, סודות מסחריים ודרישות אבטחה פנימיות לבינה מלאכותית אוסרים במפורש למסור פרומפטים לצד שלישי. פורמלית, התעבורה עוברת בערוץ מאובטח, בפועל הנתונים נמצאים בתשתית זרה — ומערך הענן נופל עוד בשלב התיאום עם האבטחה.
הצוואר בקבוק השני — מגבלות הספק: מכסות על מספר בקשות בדקה, קיצוץ הקשר, תעדוף תעבורה של אחרים וזכות להחליף מודל בלי התראה. תחת עומס שיא, כאשר כמה מערכות פנימיות פונות בו-זמנית, חלק מהקריאות מקבלות סירוב או הקשר מקוצץ, והשאר — השהיה שאי אפשר להכניס לתקנון השירות.
נקודת הכשל השלישית — שחזוריות. אחרי עדכון משקולות בצד הספק אותה בקשה נותנת תשובה אחרת, וגרסת המודל שעליה התקבלה ההחלטה אינה זמינה לבדיקה. ביקורת וחקירת החלטות שנויות במחלוקת במערך כזה просто לא מסתדרות.
On-premise LLM סוגר את שלוש הנקודות בבת אחת: הרצה מקומית של המודל במערך סגור משמעה שהנתונים לא עוזבים את הרשת שלכם, רוחב הפס מוגבל רק בציוד שלכם, וגרסת המודל קבועה וניתנת לשחזור. נפרט כיצד זה נסגר בפועל.
מה נותנת הרצה מקומית של המודל: אפקט במדדים
בעת פריסת on-premise זמן התגובה מפסיק להיות תלוי בעומס של שירות זר: שעות שיא של ספק חיצוני כבר לא מותחות את התשובות כשכל החברה פונה למערכת. אנחנו מודדים התפלגות השהיות לפי סוגי בקשות ומכווננים את הפלט כך שתשובות ארוכות לא ידחקו תשובות קצרות.
פיזור זמן התגובה מצטמצם מכפולה לכזה צפוי — אפשר להכניס אותו לממשק: פסקי זמן, מחווני המתנה, פלט זורם.
נעלם סוג נפרד של כשלים: הגבלות על קצב בקשות, החלפת מודלים זמינים אצל הספק, שינוי בהתנהגות הממשק החיצוני לאחר עדכון בצד השירות. גרסת המודל מוצמדת ללקוח, עדכון נעשה רק לפי החלטתו ואחרי ריצה של סט בקרות בסביבת בדיקה. אי-תלות בספק משמעה גם שתוכנית פיתוח המוצר לא תלויה בלוח הזמנים של מהדורות של אחרים.
יציבות איכות התשובות היא תוצאה של אותה הצמדה: גרסת מודל אחת, הגדרות יצירה אחידות ופרומפט מערכת אחד נותנים תוצאות ברות-השוואה מהרצה להרצה, ולכן בדיקות לא נבדלות בין סביבות.
ניצולת השרתים הופכת לניתנת לניהול: חלק מהפניות עוברות למודלים קומפקטיים, שבהם די בקיבולת קטנה יותר, ותרחישים כבדים מקבלים משאב ייעודי.
את הסטאק מתאימים למשימה — ממשפחות פתוחות כמו Llama ועד וריאנטים שעברו אימון נוסף על הנתונים שלכם, אם התחום דורש טרמינולוגיה משלו. כיצד זה נפרס על הציוד שלכם — נפרט בהמשך.
אפשרויות פריסה: השוואת גישות ומצבים
הבחירה בין התצורות נקבעת לפי שאלה אחת: אילו בקשות מותר להוציא מחוץ להיקף ומה יקרה אם הערוץ החיצוני נדרדר. בכניסה מוצבת ניתוב בקשות — חוקים לפי סוג הנתונים, השולח ורמת הגישה קובעים אם הפנייה עוברת למערך מבודד או לחלק החיצוני של תצורה היברידית.
בכל אפשרויות פריסת המודל מערך הרכיבים זהה: שער, שירות פלט, תור, תיעוד יומנים ובקרת גישה. השונים הם מדיניות הניתוב, קיום עתודה חיצונית והשאלה מי אחראי לעדכון משקולות המודל.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מערך מבודד לחלוטין | נתונים אישיים, סוד מסחרי, דרישות רגולטור לאחסון בתוך ההיקף | אין עתודה חיצונית וגישה למודלים חזקים יותר; עומס שיא נתקל בחומרה עצמית |
| תצורה היברידית עם ניתוב חלק מהבקשות החוצה | חלק מהתרחישים ציבוריים — עזר, טיוטות, סיכום טקסטים פתוחים | נדרש מסווג בכניסה ויומן החלטות; טעות בניתוב = דליפה |
| מערך מקומי עם עתודה חיצונית | שירות קריטי שבו השבתה יקרה מהשהיית תגובה | העתודה חלשה יותר באיכות; נדרש נוהל מפורש למעבר ולחזרה |
| ענן פרטי על משאבים ייעודיים | עומסי שיא משתנים, הנתונים צריכים להיות באזור מוסכם | בידוד נמוך יותר מאשר במערך עצמי; תלות בספק ובערוץ |
הטמעת on-premise LLM: שלבי העבודה ההנדסית
בלי ביקורת תשתית וסביבת בדיקה המודל עובר לפעילות מבצעית ללא בדיקה, וטענות לגבי איכות התשובות צפות כבר אצל המשתמשים. אנחנו מובילים הטמעת on-premise LLM בשלבים — כל אחד מסתיים בארטיפקט שניתן לבדוק.
- ביקורת תשתית. בודקים מאיצים, תת-מערכת דיסקים, ערוצי תקשורת ומערך אבטחה — מקבלים מפת צווארי בקבוק ומגבלה על סשנים במקביל.
- הגדרת דרישות. מקבעים תרחישים, שפה ותחום, דרישות לסודיות נתונים ולהפרדת גישות; מסכימים כיצד מודדים איכות.
- תוכנית הטמעה. בוחרים ארכיטקטורה, נקודת גישה למודלים, תצורת תיעוד בקשות ושלביות עם נקודות חזרה.
- סביבת בדיקה. פורסים מערך מבודד עם אותן גרסאות רכיבים, מריצים עומס ומודדים השהיית תגובה וצריכת משאבים.
- כיול. מתאימים פרמטרי יצירה וגודל הקשר, מפעילים מטמון, גיבוי מודלים וניטור זמינות.
- קבלת הפתרון. משווים מדדים לקריטריונים מוסכמים על שאלות בקרה, בודקים התאוששות לאחר תקלה והרשאות גישה.
- מסירה לפעילות. מוסרים נהלי עדכון, תיעוד והדרכה לצוות שלכם, ונשארים בליווי.
ביקורת או סביבת בדיקה שהוחמצו כמעט תמיד חוזרות כעבודה מחדש בקבלה — לכן את הסדר והקריטריונים מקבעים לפני תחילת העבודה.
חבילת מסירה: תצורות, תרשימים ונהלים
חבילת מסירה היא לא ארכיון עם קובצי הגדרות, אלא סט ארטיפקטים שלפיהם צוות הליווי שלכם יפרס את הפתרון מאפס וינהל אותו בעצמו. כל מסמך קשור לסביבת בדיקה עובדת: המתואר תואם את מה שבאמת פועל, כולל חריגות שבדרך כלל לא מתעדים בשום מקום.
- תרשים פריסה: טופולוגיית צמתים, מיקום שירותי יצירה ומאגר וקטורי, דרישות למאיצים, אזורי רשת, נקודות יציאה למערכות חיצוניות.
- תצורות: קובצי פרמטרי הפעלה, תבניות סביבות, כרכים ונקודות עיגון עם הסבר מה אחראי לכל ערך ומה ישתנה בעריכה.
- מדיניות גישה: תפקידים ותחומי ראייה, כללים לבחירת מודל לפי בקשה, מגבלות על אורך הקשר וסשנים במקביל, תיעוד פניות.
- תרשימי זרימת נתונים: מאין מגיעים מסמכים, כיצד עוברים ניקוי ופיצול, היכן נמצאים אמבדינגים, כיצד נתונים נמחקים בעת שלילת גישה.
- תיעוד הפתרון: ארכיטקטורה, קטלוג מודלים עם ייעוד כל אחד, מגבלות ידועות וירידות איכות תחת עומס.
- נוהל עדכון מודל: סדר הפצת משקולות חדשות, ריצה חובה על סט שאלות בקרה, חלון חזרה לגרסה קודמת.
- נהלי תחזוקה: ניטור השהיות וכשלים, סבב מפתחות, גיבוי מאגר ואינדקסים, תדירות בדיקות.
מקרה בוחן: פריסת מודלים במערך סגור
תצורה ראשונית וצווארי בקבוק
מפעיל עיבוד פניות הגיע עם עוזר עובד: תשובות לפי בסיס ידע נוצרו על ידי API חיצוני, האיכות סיפקה את העסק, אבל כל פנייה יצאה מחוץ להיקף, ואבטחת המידע חסמה הרחבה למחלקות חדשות. בסיס הידע עודכן בייצוא ידני — פער מול נהלים עדכניים הגיע עד שלושה שבועות. בעומס שיא הבקשות נתקלו במגבלות קריאות חיצוניות, וחלק נפלו בפסק זמן.
מה נבנה מחדש במעבר
את הפלט העבירו לשרת בתוך רשת הלקוח: מאגר ארטיפקטים, שער עם אימות לפי חשבונות פנימיים, יומן לכל בקשה. משקולות המודל נלקחו פעם אחת דרך פרוקסי מבודד מ-Hugging Face, ומכאן והלאה — רק מראה פנימית של המאגר, אין לעוזר תעבורה חיצונית.
גודל המודל הותאם לחומרה הקיימת, נוספו תור בקשות, עיבוד באצוות ומטמון לניסוחים נפוצים, ובסיס הידע עבר לאינדוקס מחדש אוטומטי לפי נהלים.
מדדים לפני ואחרי
| מדד | לפני המעבר | אחרי המעבר |
|---|---|---|
| פניות שנסגרו ללא נציג | 34% | 71% |
| זמן תגובה חציוני | רמת בסיס | קטן פי שלושה |
| כשלים בפסק זמן בשיא | 4% | 0.2% |
| עדכון בסיס הידע | עד 3 שבועות | פחות מיממה |
| הפצת מהדורה חדשה של המודל | שבועיים | יום עבודה |
אחרי חודשיים המערך עבר ביקורת פנימית בלי הערות, וחיבור מחלקות חדשות הצטמצם להנפקת חשבונות. התרחיש ניתן לחזרה: מתארים את זרימת הפניות — מחשבים משאבים עבורה וחוזרים עם תוכנית מעבר.
מה לעשות אם חלק מהשירותים כבר פועל בענן?
מצב עבודה היברידי הוא לא שלב ביניים אלא מצב יעד נורמלי. הענן נשאר במקומות שבהם הנתונים לא רגישים ונדרש מודל חזק ככל האפשר. המערך המקומי לוקח את מה שאסור שיצא מההיקף: נתונים אישיים, תיעוד מסחרי, נהלים פנימיים.
מעבר הדרגתי בונים לא לפי שירותים אלא לפי זרימות נתונים. תחילה מיפוי: אילו נתונים עוברים למודל, מאילו מערכות, עם איזה תג רגישות. בכניסה מוצב שכבת ניתוב, שלפי כלל מחליטה לאן לשלוח את הבקשה — ל-on-premise LLM או למודל בענן. קוד האפליקציה לא משתנה: השירות פונה לכתובת אחת.
הפרדת זרימות נתונים נקבעת במדיניות, לא בהסכמה בין צוותים. הכלל «נתונים אישיים או מסמך עם גישה מוגבלת — רק מקומית» נבדק אוטומטית, לא לפי מצפונו של המפתח. מקרים שנויים במחלוקת נפתרים באמצעות תגים על המקורות, ולכן שירות חדש נכנס למערך הנכון בלי הגדרה ידנית.
מתחילים בזרימה אחת — חיפוש פנימי במסמכים או עוזר תמיכה. אחר כך משווים איכות: אותן קבוצות שאלות, אותם מדדים, בנפרד שיעור הכשלים וזמן התגובה. כשהמערך המקומי לא נופל מהענני, חלק התעבורה עליו גדל — זה תיקון של כלל ניתוב, לא כתיבה מחדש של אינטגרציות. גם החזרה אחורה דורשת שלב אחד: הכלל חוזר לענן, יומני הבקשות וההיסטוריה נשארים במקומם.
ספקות טכניים לפני התחלה: פירוק שאלות
לפני ההתחלה מהנדסי הלקוח בודקים לא מצגת אלא את המערך: היכן יוצבו המודלים, מי אחראי לאיכות התשובות, מה יקרה בעדכון וכיצד המערך ישרוד מסירה לצוות שלו. להלן ארבע שאלות שצפות כמעט תמיד, והתשובות שלנו לגופן.
איזה ציוד נדרש והאם אפשר להסתפק בקיים?
מחשבים לא «בעין» אלא לפי עומס: כמה בקשות במקביל, מה אורך ההקשר, האם נדרש פלט זורם. לפי המספרים האלה בוחרים סוג מאיצים ומצב עבודה של המודל — בענף עדכני של NVIDIA נכנס לאותו מארז הרבה יותר ממה שמניחים כברירת מחדל. אם חלק מהמלאי כבר קיים, הוא לוקח משימות מתאימות, ורוכשים רק את החסר.
כיצד לעדכן את המודל בלי השבתה?
מחזיקים שני עותקים מאחורי מאזן עומסים: על השני מפיצים גרסה חדשה, מריצים אותה על סט בקשות ייחוס ורק אחר כך מעבירים את התעבורה. חזרה אחורה — החזרת התעבורה לעותק הקודם תוך דקות, בלי לעצור את השירות למשתמשים.
מי אחראי לאיכות התשובות?
את האיכות מקבעים לפני ההתחלה: אוספים סט שאלות ייחוס עם תשובות מצופות וקריטריוני קבלה מוסכמים. בהמשך כל מהדורה של מודל ופרומפטים עוברת ריצת רגרסיה, ופערים מנתחים יחד עם המומחים שלכם — כך ירידת איכות נראית לפני שהמשתמשים מבחינים בה.
האם נוכל לנהל את המערך עם הצוות שלנו?
כן, זו מטרת הפרויקט. מעבירים פריסה כקוד, נהלי עדכון וחזרה אחורה, תרשים ניטור וניתוח תקלות טיפוסיות, מעבירים הדרכה ומשמרות ראשונות יחד. אחרי המסירה אתם מחליפים מודל והגדרות בעצמכם, בלי לפנות אלינו בכל פעולה.
נדון במשימה: מה צריך להערכה ותוכנית עבודה
כדי לחזור עם הערכת פרויקט ולא עם מילים כלליות, אנחנו צריכים את ההקשר שלכם: היכן הפתרון יעבוד, על אילו נתונים ובאיזה עומס. להלן סט מינימלי של נתוני מוצא. אם משהו אין ביד — לא נורא, חלק נבהיר יחד בשיחה, אבל ככל שהנתונים מדויקים יותר, כך יש פחות הנחות בתצורה ובתוכנית השלבים.
- תרחישים: אילו משימות המודל צריך לסגור — תשובות לפי בסיס ידע פנימי, ניתוח וסיווג מסמכים, יצירת טקסטים, עזרה בקוד. חשוב לתעדף: מה מפעילים ראשון.
- נתונים: סוגים ופורמטים של מקורות, נפח משוער, באיזו תדירות מתעדכנים, האם יש מידע אישי או מסחרי — מכך תלויים מערך האחסון ומדיניות הגישה.
- תשתית: אילו שרתים כבר קיימים, האם מותר מערך מבודד בלי יציאה לאינטרנט, מי אחראי לחומרה ווירטואליזציה מצדכם.
- עומס: מספר משתמשים, פרופיל פניות, תקופות שיא ודרישות לזמן תגובה — זה קובע את מרווח הכוח ואת תצורת ההרחבה.
- הרשאות ואבטחה: הפרדת תפקידים, תיעוד בקשות, מי מנהל את המערכת, אילו בדיקות חובה לפני העלאה לפעילות.
- תפעול: מי מקבל את התוצאה, כיצד מתכננים לעדכן את המודל, האם נדרש מצב תמיכה וחלונות לעבודות תחזוקה.
בסיום תקבלו תצורת פתרון למערך שלכם, הרכב עבודה לפי שלבים, תוכנית הטמעה עם נקודות קבלה ורשימת סיכונים. תארו את המשימה — נחזור עם הערכה ותוכנית.