בקצרה

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

READ
מדריך יישומיצעדים שאפשר להפעיל בעבודה
+
Evidenceמחקר, מסגרות ונתונים
+
Actionחיבור לסדנה או תכנית
שלושה מרצים מצוות המכון באווירה חיובית
המטרה היא לא רק להכיר AI, אלא לצאת עם דרך עבודה שאפשר להמשיך.
מדריך וידאו בנושא מודלים קטנים על המכשיר

Gemma 3n: Powerful AI on your device: מדריך וידאו בנושא מודלים קטנים על המכשיר

Google Developers

וידאו רשמי באנגלית על Gemma 3n, ארכיטקטורה יעילה למכשירים, קלט רב-מודאלי והאיזון בין יכולת, זיכרון והפעלה מקומית.

לצפייה ישירה ב-YouTube

מהו Small Language Model

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

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

  • גודל מודל אינו מדד איכות יחיד
  • On-device אינו זהה ל-On-premise
  • כימות מצמצם זיכרון במחיר אפשרי באיכות
  • התאמה למשימה עשויה לנצח גודל

מה המחקר מלמד על איכות של מודלים קטנים

דוח Phi-3 הציג ב-2024 מודל של 3.8 מיליארד פרמטרים שנועד לפעול גם על טלפון, והראה עד כמה סינון נתונים ואימון ממוקד יכולים לשפר יחס בין גודל לביצוע. MobileLLM בחן מודלים מתחת למיליארד פרמטרים והדגיש ארכיטקטורה עמוקה וצרה, שיתוף Embeddings ו-Grouped-Query Attention כדרכים לשפר שימושים על מכשיר.

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

  • Data Curation משמעותי
  • ארכיטקטורה חשובה בגודל קטן
  • Benchmark אינו סביבת ייצור
  • איכות מספקת עדיפה על מרדף דירוג

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

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

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

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

מתי מודל קטן הוא בחירה טובה

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

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

  • משימה צרה ורובריקה ברורה
  • נפח גבוה או השהיה נמוכה
  • פלט שניתן לאימות
  • מסלול הסלמה למקרה מורכב

עלות כוללת ולא מחיר לטוקן

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

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

  • חומרה ותחזוקה
  • עלות תיקון אנושית
  • זמינות והשהיה
  • Portfolio ו-Routing

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

MobileLLM בחן מודלים של 125M ו-350M פרמטרים והראה שארכיטקטורה עמוקה וצרה, שיתוף Embeddings ו-Grouped-Query Attention יכולים לשפר ביצוע בגודל תפעולי קטן. Phi-3 Mini הציג מודל 3.8B שאומן על 3.3 טריליון טוקנים תוך דגש על נתונים מסוננים וסינתטיים. שתי העבודות מחזקות רעיון משותף: בגודל קטן, בחירת הנתונים והארכיטקטורה משפיעה מאוד על יחס איכות-משאבים.

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

  • Data Curation
  • Architecture
  • Distillation
  • Quantization

On-Device כמערכת היברידית

הדוח של Apple מ-2025 מתאר מודל מקומי של כ-3B פרמטרים לצד מודל שרת, עם KV-cache sharing ואימון מודע לכימות 2-bit. זהו מקרה חשוב משום שהוא מדגים ש-On-device אינו בהכרח תחליף מלא לענן. מערכת יכולה לנתב משימה לפי רגישות, יכולת, זמינות והקשר.

Gemma 3n של Google משתמש ב-MatFormer וב-Per-Layer Embeddings כדי לאפשר הפעלה יעילה יותר על מכשירים, כולל קלט טקסט, תמונה ואודיו. המפרט הרשמי מתאר גדלים אפקטיביים E2B ו-E4B, אך גם כאן המספר האפקטיבי אינו הבטחת ביצוע. על הארגון לבדוק חומרה אמיתית, זמן Prefill, מהירות יצירה, זיכרון, חום, סוללה ואיכות בשפה הנדרשת.

  • Routing בין מקומי לענן
  • זיכרון וחומרה
  • Multimodal על מכשיר
  • בדיקה בתנאי שימוש

כימות, זיקוק והתאמה: שלוש דרכי הקטנה

Quantization מייצג משקלים בפחות ביטים וכך מצמצם זיכרון ולעיתים משפר מהירות. Distillation מאמן מודל קטן לחקות התנהגות או התפלגות של מודל גדול. Fine-tuning או LoRA מתאימים מודל למשימה או תחום. הטכניקות ניתנות לשילוב, אך כל אחת יכולה לשנות איכות באופן אחר. לדוגמה, כימות עשוי לפגוע יותר במשימה רגישה לדקויות, והתאמה צרה עשויה לשפר פעולה אחת ולפגוע בגמישות.

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

  • גודל קובץ וזיכרון
  • איכות לפי משימה
  • מבנה פלט ועקביות
  • בדיקת נסיגה

MobileLLM-Pro והכיוון של 2026

MobileLLM-Pro מ-2025 מציג מודל של מיליארד פרמטרים עם הקשר ארוך, זיקוק, מיזוג מומחים וכימות 4-bit. לפי הדוח הוא הוערך על 11 Benchmarks ותוכנן למכשירים ניידים ולבישים. גם ללא אימוץ המודל המסוים, המחקר מדגים שהקטגוריה מתקדמת משיחה קצרה ליישומים ארוכי הקשר ותחומיים.

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

  • חוזה קלט-פלט
  • Model Registry
  • בדיקות לפני החלפה
  • Rollback לגרסה קודמת

מסגרת החלטה: Local, Cloud או Hybrid

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

ב-Architecture Review מציגים שלוש חלופות על אותה משימה ומסבירים Trade-off. Hybrid מתאים כאשר רוב הבקשות פשוטות וחלק קטן מורכב: המקומי מטפל בברירת המחדל, והמערכת מסלימה רק בהסכמה ובמדיניות. חשוב למדוד את שיעור ההסלמה, משום שהוא קובע גם עלות וגם חשיפה. מערכת טובה יודעת לומר איני בטוח ולהעביר הלאה.

  • ספי איכות ופרטיות
  • Latency ו-Offline
  • TCO ויכולת תחזוקה
  • שיעור הסלמה

מדריך יישומי: כך מתחילים עם מודלים קטנים ו-AI מקומי

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

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

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

תכנית עבודה ל-30 יום

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

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

  • שבוע 1 — מיפוי וקו בסיס
  • שבוע 2 — הדרכה ותבנית
  • שבוע 3 — יישום ומשוב
  • שבוע 4 — מדידה והחלטה

שאלות ביקורת לפני שמרחיבים

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

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

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

מבחן Local, Cloud או Hybrid למודלים קטנים על המכשיר

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

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

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

  • השוואה על אותו Golden Set
  • בדיקת טלמטריה ואחסון
  • ניתוב Local, Cloud או Hybrid
  • ניהול גרסאות ומכשירים

להעמקה בנושא:סדנת AI למנמ״רים ומנהלי אבטחת מידעבינה מלאכותית בעבריתמעבדת Use Cases ארגונית

קישורים להעמקה

להמשיך מהידע ליכולת

השורה התחתונה

מה לקחת מכאן?

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

המקורות שעליהם נשענת הסקירה

  1. Abdin et al. (2024), Phi-3 Technical Report
  2. Liu et al. (2024), MobileLLM: Optimizing Sub-billion Parameter Language Models
  3. Apple (2025), Apple Intelligence Foundation Language Models Technical Report
  4. Google DeepMind (2025), Gemma 3n Model Overview and Model Card
  5. Huber et al. (2025), MobileLLM-Pro Technical Report
  6. Google AI for Developers (2025), FunctionGemma

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

שאלות ותשובות לצורך קבלת החלטה

שאלות ותשובות על מודלים קטנים על המכשיר

מהם מודלים קטנים על המכשיר?

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

מהם Small Language Models?

Small Language Models הם מודלים בעלי מספר פרמטרים ודרישות חישוב נמוכים יחסית. הם מותאמים לעיתים למשימה או תחום ויכולים לרוץ מקומית. קטן אינו בהכרח פחות טוב; ההתאמה נמדדת מול משימה, איכות ועלות.

מתי לבחור AI מקומי בארגון?

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

האם On-Device AI מבטיח פרטיות?

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

איך מעריכים מודל שפה קטן?

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

מהו Private AI מקומי?

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

כיצד מחשבים עלות של מודלים קטנים על המכשיר?

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

מפת הנושאים של המאמר

מילות מפתח ונושאים קשורים

רוצים להפוך את מודלים קטנים על המכשיר ליכולת ארגונית?

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

לסדנת AI למנמ"רים ומנהלי אבטחת מידע