כל מנהל טכנולוגיה בארגון פיננסי, ביטוחי או ביטחוני בישראל מכיר את הרגע הזה: ההנהלה ראתה הדגמה של מודל שפה שמסכם דוחות בשניות, וגורם הסייבר או היועץ המשפטי עוצר את הכל במשפט אחד — "דאטה של לקוחות לא יוצא מהארגון". LLM פרטי בארגון הוא בדיוק הגשר בין שתי העמדות: הרצה של מודל שפה גדול (Large Language Model, LLM) על תשתית שנמצאת בשליטה מלאה שלכם — חדר שרתים פיזי, ענן פרטי מבודד (VPC) או ענן ריבוני שיושב בישראל.
ההחלטה העקרונית היא החלק הקל. הפער האמיתי הוא הנדסי: כמה זיכרון GPU נדרש בפועל, מה עולה להחזיק את זה שנה, איך מעדכנים מודל בלי להשבית ייצור, ומה קורה כשמודל פתוח טוב יותר יוצא שלושה חודשים אחרי שסיימתם אינטגרציה. במאמר הזה נפרק את הדרך ל-LLM פרטי בארגון למספרים, לארכיטקטורות ולהחלטות שאתם באמת צריכים לקבל — מנקודת מבט של מי שבנה את זה בשטח.
למה ארגונים בישראל מחזירים AI לתשתית מקומית
תיקון 13 לחוק הגנת הפרטיות, שאושר באוגוסט 2024, שינה את מאזן הכוחות. הרשות להגנת הפרטיות קיבלה סמכויות פיקוח ואכיפה רחבות, כולל עיצומים כספיים שיכולים להגיע למאות אלפי שקלים — ובמקרים של הפרה נמשכת או רחבת היקף, למיליונים. במקביל, ארגונים מסוימים מחויבים כיום למנות ממונה הגנת פרטיות (DPO). אפשר לקרוא את ההנחיות המלאות באתר הרשות להגנת הפרטיות.
עבור CTO כל זה מתרגם לשאלה פרקטית אחת: מי עוד נגע ברשומות הלקוחות שלכם בדרך לתשובה שהמודל החזיר? אצל לקוחות ביטחוניים ובתעופה השאלה בכלל לא נשאלת — סיווג הדאטה קובע שהוא לא עוזב את הרשת, נקודה. בבנקאות ובביטוח האילוץ רך יותר אבל לא פחות מחייב: נהלי ענן, מיפוי זרימות דאטה חוצות גבולות, והסכמי עיבוד מול ספק חוץ שמישהו צריך לחתום עליהם בשמו.
גם המגמה הגלובלית מצביעה לאותו כיוון. גרטנר מעריכה שעד 2030 יותר מ-75% מהארגונים באירופה ובמזרח התיכון יחזירו עומסי עבודה וירטואליים לגיאוגרפיה שלהם כדי לצמצם סיכון גאופוליטי — לעומת פחות מ-5% היום. במילים אחרות, מי שבונה עכשיו ארכיטקטורה שמניחה ענן ציבורי אמריקאי כברירת מחדל בונה חוב טכני, ולכן השאלה של LLM פרטי בארגון עלתה מ"נחמד להיות" ל"תנאי סף".
LLM פרטי בארגון: שלוש ארכיטקטורות ומה מתאים למי
On-Premise מלא (bare metal). שרתי GPU פיזיים בחדר השרתים שלכם, משקולות המודל על דיסק מקומי, אפס תעבורה יוצאת. זו האופציה היחידה כשסיווג הדאטה או רגולטור אוסרים העברה. המחיר: אחריות תפעולית מלאה — קירור, חשמל, מלאי חלפים ואנשים שיודעים לתחזק דרייברים של CUDA בשעה שלוש לפנות בוקר.
ענן פרטי מבודד (dedicated VPC). מכונות GPU ייעודיות שלכם בענן, ברשת מבודדת, בלי multi-tenancy על שכבת ההסקה. הדאטה עדיין יוצא מהמתקן הפיזי שלכם, אבל אתם מקבלים אלסטיות ולא צריכים לקנות חומרה מראש. מתאים לרוב ארגוני הפינטק והבריאות שאיתם אנחנו עובדים.
ענן ריבוני בישראל. פשרה שהולכת ותופסת: הדאטה נשאר בגבולות המדינה, עם התחייבות חוזית מול ספק מקומי. פותר את שאלת הריבונות, לא בהכרח את שאלת הבידוד מול ספק שלישי.
הכלל שאנחנו עובדים לפיו: אם אי אפשר לענות בכתב על "איפה בדיוק שוכבות משקולות המודל ומי יכול לקרוא את הלוגים של הפרומפטים" — הארכיטקטורה לא סגורה.
עוד שיקול שמפריד בין ארכיטקטורות: מי אחראי על עמידה ב-SLA. במודל On-Premise מלא ההשבתה היא באחריותכם וצריך יתירות אמיתית — לא כרטיס בודד שכל המערכת תלויה בו. בענן פרטי אתם קונים את היתירות הזאת בכסף. בפרויקטים ביטחוניים שליווינו זה היה השיקול המכריע: לא העלות, אלא זמן ההתאוששות המותר.
סייזינג GPU: ה-VRAM הוא האילוץ, לא ה-FLOPS
הטעות הנפוצה ביותר בתקצוב של LLM פרטי בארגון היא לחשוב בכוח חישוב. בהסקה (inference) האילוץ הבינארי הוא זיכרון ה-GPU (VRAM): מספר הפרמטרים כפול מספר הבייטים לפרמטר, פלוס KV cache שגדל עם אורך הקונטקסט ומספר הבקשות המקבילות, פלוס 2–4 ג׳יגה-בייט תקורה של הרנטיים.
דוגמה קונקרטית: מודל בסדר גודל של 70 מיליארד פרמטרים ב-FP16 דורש כ-140GB רק למשקולות — כלומר לפחות שני כרטיסים מהמעמד של 80GB. אותו מודל בקוונטיזציה של INT4 מתכנס לכ-35GB ונכנס לכרטיס בודד, במחיר של פגיעה מדודה באיכות שחייבים למדוד ולא להניח.
ברוב הפרויקטים שלנו הקפיצה האמיתית בתפוקה לא באה מחומרה נוספת אלא משכבת ההגשה. מנועי הסקה כמו vLLM עם continuous batching ו-PagedAttention מכפילים throughput על אותה חומרה בדיוק. תמדדו tokens-per-second ולא spec sheet.
שני מספרים שכדאי לחשב מראש: מספר הבקשות המקבילות בשעת שיא, ואורך הקונטקסט הממוצע. אלה שקובעים את ה-KV cache, ולכן את הכרטיס. ראינו לא מעט ארגונים שקנו חומרה לפי גודל המודל, ואז גילו שקונטקסט של 32 אלף טוקנים עם עשרים משתמשים במקביל אכל להם את כל הזיכרון שנשאר.
עלות אמיתית של LLM פרטי בארגון מול GPU בענן
הנה הטווחים שאנחנו רואים בשוק ב-2026. תחנת עבודה מחלקתית עם כרטיס בודד מהמעמד של 24GB: כ-1,500–4,000 דולר, מספיקה לפיילוט ולמודלים קטנים. מערך בינוני שמשרת מודל במעמד 70B: כ-10,000–15,000 דולר. מערך ייצור מרובה GPU למודלים הפתוחים הגדולים: כ-40,000–190,000 דולר חומרה.
מול זה, צומת של שמונה כרטיסי H100 בענן ציבורי בתמחור on-demand עולה בסביבות 287,000–482,000 דולר לשנה בניצולת מלאה, כשרצפת העלות של אותו מערך בבעלות עומדת סביב 237,000 דולר לשנה. נקודת האיזון נופלת בערך בניצולת של 50%–83%, תלוי אזור ותמחור.
המסקנה המעשית: אם העומס שלכם ספייקי ולא צפוי — הענן זול יותר. אם יש לכם עומס בסיס יציב 24/7, כמו ניתוח מסמכים לילי או מוקד שירות שעובד כל היום, החומרה מחזירה את עצמה. וכשהאילוץ הוא רגולטורי, החישוב הזה בכלל לא רלוונטי: זה אילוץ קשיח, לא שאלה של כלכלה.
מה שכמעט תמיד נשכח בתקציב: חשמל וקירור, זמן אדם של DevOps, וסביבת staging נפרדת. תוסיפו 25%–40% מעל עלות החומרה לשנה הראשונה.
RAG מאחורי חומת האש: איפה הדאטה באמת נמצא
ברוב מקרי השימוש של LLM פרטי בארגון אתם לא באמת צריכים מודל שיודע את הדאטה שלכם בעל פה. אתם צריכים RAG (Retrieval-Augmented Generation) — המודל מקבל את הקטעים הרלוונטיים מתוך מסמכי הארגון בזמן השאילתה. הדאטה נשאר במאגר שלכם, המודל רק קורא אותו.
הרכיב שמכריע את הפרויקט הוא לא המודל אלא ה-embeddings — ייצוג וקטורי של טקסט שמאפשר חיפוש סמנטי לפי משמעות ולא לפי מילים. בעברית זו נקודת כשל אמיתית: מודלי embedding כלליים מתמודדים פחות טוב עם מורפולוגיה עשירה, כתיב חסר וקיצורים מקצועיים. חלק מהעבודה שלנו בפרויקטי AI הוא בדיוק כאן — התאמת שכבת האחזור לעברית ולז׳רגון של הלקוח.
קריטי לא פחות: אחזור מודע-הרשאות. אם משתמש שואל שאלה, שכבת האחזור חייבת לסנן מסמכים לפי ההרשאות שלו לפני שהם מגיעים למודל. אחרת בניתם דלת אחורית מנומסת מאוד למערכת ההרשאות הארגונית.
עוד החלטה ארכיטקטונית שנוטים לדחות: איפה יושב מאגר הווקטורים. אם המודל רץ מקומית אבל ה-vector database בענן ציבורי, הדאטה הרגיש נמצא שם — כי הקטעים שנשלחים לאחזור הם בדיוק הטקסט שרציתם להגן עליו. חומת האש צריכה להקיף את כל הצינור, לא רק את שכבת ההסקה.
Fine-tuning מקומי מול RAG: מה באמת מצדיק את עצמו
Fine-tuning — אימון נוסף של מודל קיים על הדאטה שלכם — לא נועד להזרקת ידע עדכני. הוא נועד להתנהגות: פורמט פלט, טרמינולוגיה, סגנון ומשימות סיווג צרות. ידע מתעדכן פותרים ב-RAG; התנהגות פותרים ב-fine-tuning. בלבול בין השניים הוא הסיבה הראשונה לפיילוטים שנתקעים.
הבשורה הטובה: עם שיטות כמו LoRA ו-QLoRA לא צריך לאמן מודל מאפס. באימון מותאם על דאטה ארגוני אמיתי אנחנו רואים בדרך כלל שיפור של 15–30 נקודות אחוז בדיוק המשימה הצרה מול מודל בסיס עם prompt engineering בלבד, על חומרה של כרטיס בודד או שניים ובתוך ימים ולא חודשים.
ב-Dialex, מערכת ה-Voice AI בעברית שפיתחנו, זה היה הכרחי: מודלי דיבור כלליים נשברים על שמות עבריים, מספרי זהות ומעברי קוד לאנגלית. שילוב של התאמת מודל וסביבת הרצה בשליטה מלאה הוא מה שהפך שיחה שנשמעת כמו רובוט למשהו שלקוח מוכן להישאר בו. באותו אופן ב-MaiTech בתחום החינוך וב-Quantap בנדל"ן ובנייה, הערך נוצר מהתאמה לדומיין ולא מגודל המודל.
MLOps ואבטחה: מה נשבר כשזה מגיע לייצור
פיילוט מוצלח על מחשב של חוקר דאטה הוא לא מערכת. ברגע ש-LLM פרטי בארגון נכנס לייצור נדרשת שכבת MLOps: ניהול גרסאות של משקולות ושל פרומפטים, סביבת staging, מדידה רגרסיבית לפני כל שדרוג, ותצפיתיות (observability) שמראה לא רק זמני תגובה אלא גם דריפט באיכות התשובות.
בצד האבטחה, שלושה וקטורים שאנחנו בודקים בכל פרויקט: prompt injection דרך מסמכים שהמודל שואב, זליגת מידע בין משתמשים דרך קונטקסט או קאש, ותיעוד ביקורת מלא לכל שאילתה ותשובה — כי בסופו של יום מבקר פנים או רגולטור יבקש לראות מי שאל מה ומה המערכת ענתה.
ולבסוף שאלה שמעטים שואלים מראש: מה תוכנית ההחלפה? מודלים פתוחים מתחלפים כל כמה חודשים. ארכיטקטורה נכונה מפרידה בין שכבת המודל לשכבת האפליקציה, כך שהחלפת מודל היא שינוי קונפיגורציה ולא פרויקט מחדש.
נקודה תפעולית שחוזרת בכל פרויקט: הגדירו מראש מי מאשר שדרוג מודל בייצור ולפי איזה מדד. בלי סט מבחנים אוטומטי שרץ על מאה שאלות אמיתיות מהארגון, כל שדרוג הוא הימור — ומודל חדש שמשפר בממוצע עלול להיות גרוע דווקא בתרחיש שהרגולטור בודק.
מפת דרכים מעשית ל-90 יום
שבועות 1–3: מיפוי מקרי שימוש ל-LLM פרטי בארגון וסיווג דאטה. בוחרים שני תרחישים עם ROI מדיד, לא שמונה. מגדירים מדד הצלחה מספרי מראש.
שבועות 4–7: פיילוט על סביבה מבודדת — מודל פתוח בגודל בינוני, RAG על קורפוס אמיתי אבל מוגבל, ומדידה מול baseline אנושי.
שבועות 8–12: קיבוע ארכיטקטורה, סייזינג חומרה לפי מדידות אמת, הקמת שכבת MLOps ואינטגרציה למערכות הליבה. במקביל מתחילים לתכנן סוכני AI שירוצו מעל אותה תשתית — כי אחרי שהתשתית קיימת, כל מקרה שימוש נוסף זול משמעותית מהראשון.
הטעות היקרה ביותר שראינו: לקנות חומרה לפני הפיילוט. תמדדו קודם, תקנו אחר כך.
ב-Two Solutions אנחנו בונים מערכות AI עמוקות לארגונים בישראל — מהתאמת מודלים ועד הטמעה בייצור בסביבות מוגבלות רגולטורית. אם אתם שוקלים LLM פרטי בארגון ורוצים לדעת מה נכון למקרה שלכם: לשיחת ייעוץ ללא עלות.
