הרצת LLM ברשתות מנותקות: מה נדרש כדי להגיע לייצור

מהשטח, מאת Strategus. אוקטובר 2026.

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

מה משתנה כשאין חיבור לאינטרנט

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

החלטה 1: לבחור מודל לפי החומרה שיש לכם

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

החלטה 2: להכניס את כל הסטאק, לא רק את המודל

מערכת עובדת צריכה הרבה יותר ממשקולות המודל: שרת inference, מודל embeddings, מסד נתונים וקטורי, חבילות של מערכת ההפעלה, אימג'ים של קונטיינרים והתלויות שלהם. בונים רשימת רכיבים מלאה מראש, מאמתים כל קובץ עם checksum ומסכמים מוקדם עם צוות האבטחה על תהליך ההעברה. תלות חסרה שמתגלה בתוך הרשת יכולה לעלות שבועות.

החלטה 3: הערך נמצא באחזור המידע

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

החלטה 4: לבדוק איכות בתוך הרשת, לפני העלייה לאוויר

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

החלטה 5: לתכנן את התפעול מהיום הראשון

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

כשלים נפוצים

• פיתוח פיילוט על מודל API בענן, ואז גילוי שהמודל המאושר ב-⁠on-prem לא מגיע לאותה רמה
• הערכת חסר של הזמן שנדרש להעברות ולאישורים
• התעלמות מהרשאות באחזור
• אין סט בדיקה, ולכן אין דרך להוכיח שהמערכת מוכנה

לוח זמנים ריאלי

כשהגישה והחומרה מוכנות, התהליך הראשון יכול לעלות לייצור תוך שבועות. רוב הסיכון בלוח הזמנים נמצא באישורים ובהעברת החומרים, ולא ב-⁠AI עצמו. מתחילים בהם כבר בשבוע הראשון, במקביל לבנייה.

צ'קליסט לפני שמתחילים

• רשימת החומרה המאושרת
• מקורות הנתונים ומודל ההרשאות שלהם
• רשימת רכיבים מלאה להעברה
• תהליך העברה מוסכם
• סט בדיקה בבעלות מומחי התחום
• בעלים מוגדר בצד הלקוח