פרק 4: Local Inference: Ollama, LM Studio, GGUF ו-Quantization

למה Local Inference משנה את כללי המשחק

Local Inference הוא הרצה של מודל שפה על המחשב שלך. לא דרך Groq, לא דרך OpenRouter, לא דרך Colab, אלא תהליך שרץ על ה-CPU, ה-GPU, ה-RAM והדיסק שלך. זה נשמע פחות נוצץ מ-70B שרץ בענן, אבל יש לו תכונה אחת שחשובה מאוד למי שבונה כלים אמיתיים: הוא לא מבקש רשות בכל בקשה. אם המחשב שלך דולק והמודל נכנס לזיכרון, אתה יכול להריץ עוד prompt, ועוד אחד, ועוד אלף, בלי להסתכל בלוח rate limits.

בפרק 2 ראית ש-API חינמי הוא הדרך הכי מהירה לקבל מודל חזק בלי חומרה. זה עדיין נכון. אם אתה רוצה chatbot ציבורי, batch גדול של תקצירים, או מודל 70B באיכות טובה, API חינמי הוא לרוב עדיף. אבל API חינמי תמיד חי בתוך מגבלות: requests per minute, requests per day, tokens per day, שינוי מודלים, ולעיתים גם שינוי policy. Local inference מחליף את המגבלות האלה במגבלות אחרות: זיכרון, מהירות, חום, מקום בדיסק, ויכולת שלך למדוד.

זה מעבר חשוב בחשיבה. בענן אתה שואל: “כמה נותנים לי בחינם?” במקומי אתה שואל: “מה החומרה שלי באמת יכולה להחזיק?” אם המחשב שלך חלש, התשובה אולי תהיה מודל קטן ואיטי. אם יש לך GPU 8GB או 12GB, פתאום 7B או 8B ב-Q4 הופך לכלי יומיומי. אם יש לך הרבה RAM אבל מעט VRAM, CPU offload יכול להציל ניסויים פרטיים. ואם אין לך GPU בכלל, עדיין אפשר להריץ מודלים קטנים על CPU לצורך בדיקות, סיווגים, ניסויי prompt, או assistant אישי איטי אבל פרטי.

הערך הכי גדול של local הוא לא “בחינם” במובן ילדותי. המחשב, החשמל והזמן שלך עולים משהו. הערך הוא שליטה על boundary. קובץ לקוח, מסמך משפטי, export מ-CRM, קוד סגור, רעיון מוצר, או רשימת לקוחות ישראלית עם פרטים מזהים לא צריכים לצאת לענן בשביל כל סיכום קטן. local נותן לך שכבה שבה אפשר לעבוד offline, לנתק Wi-Fi אם צריך, ולהיות בטוח שהמידע נשאר במכונה. בישראל, במיוחד בעסקים קטנים שעובדים עם ספקים, רואי חשבון, עורכי דין, מערכות שכר ומידע רפואי או פיננסי, ההבחנה הזו שווה יותר מעוד כמה tokens לשנייה.

אבל local הוא גם המקום שבו הרבה לומדים נתקעים, כי הוא נראה כמו קסם עד שהוא לא. מודל “7B” לא אומר “7GB”. quantization משנה את המשקל. context משנה את runtime. מערכת ההפעלה והדפדפן אוכלים זיכרון. GPU קטן יכול להריץ משהו, ואז לקרוס כשמגדילים את prompt. לכן בפרק הזה לא ננסה לנחש. נבנה workflow של בחירה, מדידה ותיעוד. כל החלטה תסתיים בשורה בטבלה: איזה מודל, איזה quantization, כמה זיכרון משוער, כמה נמדד בפועל, והאם זה מספיק נעים לשימוש.

דוגמה מייצגת: משרד קטן שרוצה לסכם מסמכים

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

ב-local workflow, אותו משרד יכול להתחיל אחרת: להריץ מודל 7-8B מקומי, לבדוק האם הוא מסכם מסמכי sample באיכות סבירה, ולשמור את החומר במחשב או ברשת פנימית. אם האיכות מספיקה לסיכום ראשוני, הרווח הוא מיידי: עובדים מקבלים עזרה בלי לפתוח שאלות compliance בכל פעולה קטנה. אם האיכות לא מספיקה, עדיין לא הפסדנו. למדנו אילו סוגי מסמכים אפשר להשאיר מקומית ואילו צריכים מודל ענן חזק יותר עם אישור מתאים. זו בדיוק החשיבה של הפרק: local הוא לא תשובה אידאולוגית, הוא שכבה בתכנון.

אותו דפוס עובד גם למפתחים. קוד פנימי של לקוח, קובץ env שנמחק אבל מופיע בהיסטוריה, לוגים עם כתובות IP, או dump קטן של database אינם דברים שצריך לשלוח אוטומטית ל-chatbot חיצוני. מודל מקומי יכול להסביר stack trace, להציע refactor, לנסח test, או לסכם README בלי לצאת מהמחשב. הוא לא תמיד יפתור bug עמוק, אבל הוא מוריד friction. במקום לחשוב פעמיים אם מותר לשאול, אתה שואל מקומית, מקבל כיוון, ואז מחליט אם צריך escalation למודל חזק יותר.

התקנה והרצה ראשונה ב-Ollama

Ollama הוא הדרך הכי פשוטה להפוך מודל מקומי לשרת שימושי. במקום להוריד קובצי GGUF ידנית, לזכור flags של llama.cpp, ולכתוב wrapper משלך, אתה מקבל פקודה אחת שמורידה מודל, מריצה אותו, ומעמידה API מקומי. ברוב המחשבים השרת המקומי מאזין על localhost:11434. זה אומר שאפליקציה שלך יכולה לדבר עם מודל מקומי כמעט כמו שהיא מדברת עם OpenAI, Groq או OpenRouter.

ב-Windows ההתקנה הרשמית בדרך כלל מתחילה מהאתר של Ollama או מפקודת PowerShell שמורידה installer. ב-macOS יש אפליקציה ו-background service. בלינוקס משתמשים בסקריפט install. בפרק הזה לא חשוב איזה מסך התקנה ראית, כי המטרה היא verification, לא צילום מסך מושלם. אחרי התקנה טובה, terminal חדש אמור לזהות את הפקודה ollama. אם הוא לא מזהה אותה, אל תמשיך לתרגילים. עצור ובדוק PATH, הרשאות התקנה, או restart ל-terminal.

המודל הראשון צריך להיות קטן מספיק כדי לא להפוך את היום לסבל. אל תתחיל מ-70B. אל תתחיל מ-32B. אפילו אם יש לך GPU חזק, המטרה כאן היא ללמוד את השרשרת: download, run, prompt, measure, stop. בחר 7B או 8B instruct model עדכני מהקטלוג. שמות מודלים משתנים, ולכן הפרק משתמש בדוגמאות כמו llama3.1:8b, mistral:7b או qwen2.5-coder:7b כתבניות, לא כהבטחה שה-tag הספציפי תמיד יהיה הבחירה הכי חדשה. אם שם לא עובד אצלך, פתח את הקטלוג ובחר מודל 7-8B דומה.

ollama --version
ollama run llama3.1:8b

הפקודה ollama run עושה שני דברים: אם המודל לא קיים מקומית, היא מורידה אותו; ואז היא פותחת session אינטראקטיבי. ההורדה הראשונה יכולה לקחת זמן, בעיקר אם המודל כמה GB. זה תקין. בזמן ההורדה כדאי לפתוח את מדד הזיכרון של מערכת ההפעלה: Task Manager ב-Windows, Activity Monitor במק, או nvidia-smi בלינוקס/Windows עם NVIDIA. אנחנו לא מסתפקים ב-“זה עבד”. אנחנו רושמים כמה זיכרון המודל באמת לקח.

אחרי שהמודל עולה, שלח שתי בדיקות קצרות. הראשונה בעברית: “סכם לי בשלוש נקודות מה ההבדל בין API בענן למודל מקומי.” השנייה טכנית באנגלית: “Write a Python function that retries a local HTTP request three times.” הסיבה לבדיקה הכפולה היא פשוטה: יש מודלים שמרגישים בסדר באנגלית אבל חלשים בעברית; יש מודלים שטובים בשיחה אבל לא בקוד. אתה לא מחפש אמת מוחלטת. אתה מחפש baseline: האם המודל מספיק טוב למשימות שלך, וכמה מהר הוא מתחיל לענות.

כשמסיימים, אפשר לצאת מה-session עם /bye או לסגור את החלון. Ollama עשוי להשאיר את השרת ברקע, וזה טוב. אם אתה רוצה לבדוק שהשרת מגיב בלי UI, אפשר לקרוא ל-API המקומי ישירות. בהמשך נשתמש ב-OpenAI-compatible endpoint, אבל כבר עכשיו אפשר להבין את העיקרון: המודל שלך הוא שירות מקומי. במקום לשלוח טקסט לכתובת ענן, אתה שולח אותו ל-localhost.

איך יודעים שההרצה הראשונה באמת הצליחה

הרבה לומדים עוצרים מוקדם מדי. הם רואים שהמודל ענה “שלום”, ומסמנים הצלחה. זה לא מספיק. הצלחה בפרק הזה היא לא רק תשובה; היא מערכת קטנה שאפשר לחזור אליה מחר. לכן אחרי ההרצה הראשונה בדוק ארבעה דברים. הראשון: האם אתה יודע מה שם המודל המדויק שהורדת. השני: האם אתה יודע כמה מקום הוא תופס בדיסק. השלישי: האם אתה יודע באיזה מצב הוא רץ, GPU, CPU או unified memory. הרביעי: האם אתה יודע לעצור ולהפעיל מחדש בלי לאבד את ההבנה מה קורה.

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

בדיקת ההצלחה צריכה לכלול גם failure path. נסה prompt אחד שהוא מעט מעבר ליכולת המודל: למשל בקש ממנו להסביר שגיאת Python עם trace קצר, או לסכם פסקה ארוכה בעברית. אל תחפש מושלמות. חפש איך המודל נכשל. האם הוא אומר “לא יודע”? האם הוא ממציא? האם הוא מתבלבל בין עברית לאנגלית? האם הוא עונה לאט אבל נכון? הכרת סוג הכשל חשובה כמו הכרת היכולת, כי היא אומרת לך באילו משימות אסור לסמוך עליו לבד.

GGUF ו-Quantization: לבחור קובץ שנכנס לחומרה שלך

GGUF הוא פורמט קובץ למשפחת llama.cpp. מבחינת הלומד, לא צריך לדעת את כל מבנה הקובץ, אבל כן צריך להבין מה הוא מאפשר: לקחת מודל open weights, לארוז אותו בצורה נוחה להרצה מקומית, ולשמור בתוכו גם את המשקלים, גם tokenizer, וגם מטא-דאטה שהמנוע צריך כדי להריץ. Ollama ו-LM Studio מסתירים ממך חלק מהפרטים, אבל מאחורי הקלעים העולם הזה נשען מאוד על GGUF.

Quantization היא דחיסה של משקלי המודל לפחות ביטים. מודל שלא עבר דחיסה יכול להיות מדויק יותר, אבל הוא גדול מדי להרבה מחשבים. Q4 אומר בערך 4-bit למשקל; Q5 אומר בערך 5-bit. האותיות והסיומות, למשל Q4_K_M, מתארות שיטת quantization ספציפית. בשיעור הזה לא נלמד מתמטיקה של quantization, אלא נשתמש בה כידית החלטה: כמה איכות אנחנו מוכנים לאבד כדי לקבל מודל שרץ במחשב שלנו.

הכלל המעשי: Q4_K_M הוא נקודת התחלה טובה כשאתה מוגבל בזיכרון. Q5_K_M עדיף כשמשימה דורשת יותר דיוק, reasoning, math או code, ויש לך מספיק זיכרון וסבלנות ל-latency. Q2 ופורמטים נמוכים מאוד יכולים להיות מפתים כי הם קטנים, אבל ברוב עבודת הלמידה הם פוגעים באמון שלך במודל. אם המודל טועה בגלל שהורדת אותו נמוך מדי, קשה לדעת אם הבעיה ב-prompt, במודל, או ב-quantization. לכן בפרק הזה לא יורדים מתחת ל-Q4 אלא אם מדובר בניסוי מודע.

אל תבחר quantization לפי גאווה. יש מפתחים שמרגישים ש-Q5 הוא “אמיתי” ו-Q4 הוא פשרה. זו דרך לא שימושית לחשוב. אם Q4 נותן לך תשובה מספיק טובה ב-8 שניות ו-Q5 נותן תשובה קצת טובה יותר ב-22 שניות, אז למשימת note-taking או סיווג פשוט Q4 מנצח. אם אתה מבקש מהמודל לכתוב patch לאפליקציה, להבין stack trace, או לפתור לוגיקה, Q5 או מודל קטן יותר אבל איכותי יכולים להיות עדיפים.

מודלי code דורשים עוד זהירות. מודל 7B code ב-Q4 יכול להיות מעולה להשלמות קטנות, הסברים, יצירת boilerplate ותיקוני syntax. אבל הוא עלול לפספס reasoning עמוק או ארכיטקטורה. אל תבנה עליו לבדיקה סופית. השתמש בו כעוזר מקומי מהיר, ואז בדוק עם tests, linter, או מודל ענן חזק יותר כשצריך. המודל המקומי מצוין לשמירה על flow, לא להחלפת שיקול דעת.

איך בודקים איכות בלי להיסחף ל-benchmarking

Benchmark רשמי יכול להיות שימושי, אבל הוא לא אומר הרבה על העבודה שלך. אם אתה כותב בעברית, עובד עם מסמכי לקוחות, ובונה scripts קטנים, לא מספיק לדעת שהמודל קיבל ציון גבוה על מבחן באנגלית. אתה צריך סט בדיקות קטן משלך. שלוש בדיקות מספיקות להתחלה: סיכום בעברית של פסקה מקצועית, תיקון קוד קצר עם bug ברור, ושאלת reasoning שבה התשובה דורשת שני צעדים ולא רק ידע כללי. הרץ את שלושתן על Q4 ועל Q5 אם יש לך מקום. אם Q5 לא משפר את המשימות שלך, אין סיבה לשלם ב-latency.

כדאי גם לבדוק יציבות, לא רק תשובה אחת. מודל מקומי קטן יכול לתת תשובה טובה פעם אחת ותשובה מוזרה בפעם השנייה, במיוחד עם temperature גבוה. לכן בזמן בדיקה שמור את ההגדרות פשוטות: prompt קבוע, temperature נמוך יחסית, context ידוע. אם אתה משנה גם prompt, גם temperature וגם quantization, אין לך ניסוי. יש לך רעש. המטרה היא החלטה מעשית: “למשימות שלי, המודל הזה ב-Q4 מספיק”, או “לקוד אני צריך Q5”, או “עדיף מודל קטן יותר שמתמחה בעברית”.

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

VRAM בפועל: weights, KV cache ו-context

הדרך הכי קצרה להתבלבל ב-local inference היא לחשוב שזיכרון המודל שווה לגודל הקובץ. קובץ GGUF של 4GB לא אומר שההרצה תיקח בדיוק 4GB. יש weights, שהם המשקלים הדחוסים של המודל. יש runtime overhead. ויש KV cache, מטמון שנוצר בזמן generation כדי שהמודל לא יחשב מחדש את כל ה-attention בכל token. ככל שה-context ארוך יותר, ה-KV cache גדל. לכן מודל שנראה “נכנס” ב-context קצר יכול להיכשל כשמבקשים ממנו לקרוא מסמך גדול.

בפרק 1 השתמשנו בכלל אצבע: 7-8B ב-Q4_K_M צריך בערך 5.5-6.2GB בזמן ריצה ב-context קצר, לא רק את ה-weights. 13-14B יכול להגיע לאזור 10GB ומעלה. 32B כבר דורש חומרה רצינית, ו-70B מקומי הוא לא יעד למחשב ממוצע. המספרים האלה טובים לתכנון, אבל לא מספיקים להחלטה סופית. backend, architecture, אורך context, batch size, driver, מערכת הפעלה ואפליקציות פתוחות משנים את התוצאה.

לכן כל פרויקט local צריך טבלת מדידה. לא benchmark חגיגי, רק טבלה. עמודות מינימום: model, quantization, context, prompt type, memory before, peak memory, seconds to first useful answer, subjective quality. זו טבלה שאפשר לבנות ב-Notion, Google Sheets או Markdown. אחרי שלושה מודלים כבר תדע יותר על המחשב שלך ממה שכל טבלת אינטרנט יכולה לספר.

ב-Windows עם NVIDIA אפשר להשתמש ב-Task Manager וגם ב-nvidia-smi. בלינוקס nvidia-smi הוא הכלי הבסיסי. במק עם Apple Silicon אין VRAM נפרד, אלא unified memory, ולכן מסתכלים על Activity Monitor ועל pressure. במחשב בלי GPU מודדים RAM ו-latency. אל תזלזל במדידה בלי GPU: אם assistant מסמכים קטן עונה תוך 25 שניות אבל שומר פרטיות מלאה, אולי זה מספיק טוב למשימה פנימית פעם ביום.

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

טבלת sizing שימושית למחשב שלך

טבלת sizing טובה אינה צריכה להיות מדויקת ברמת MB. היא צריכה לעזור לך לבחור מהר. שורה אחת יכולה להיראות כך: “7-8B, Q4_K_M, context 4K, משימות chat וסיכום, נמדד 6GB בערך, נעים לשימוש”. שורה אחרת: “13B, Q4, offload חלקי, context קצר, איכות טובה יותר אבל איטי, מתאים למסמך פרטי פעם ביום”. ההבדל בין שתי השורות הוא לא רק מספר. זו החלטת מוצר קטנה: במה אתה מוכן להשתמש ביום עבודה אמיתי.

אם יש לך GPU 4GB, אל תתבאס. סביר שתעבוד עם 3-4B או 7B קטן ב-context קצר, ואולי תשתמש ב-API חינמי למשימות כבדות. אם יש לך 8GB, 7-8B Q4 הופך ל-baseline סביר, ו-Q5 אולי אפשרי במשימות מסוימות. אם יש לך 12GB או 16GB, אפשר לבדוק 13B או 14B בזהירות. אם יש לך Apple Silicon עם unified memory גדול, החוויה שונה: אין VRAM נפרד, אבל עדיין יש pressure ו-latency. בכל המקרים, הטבלה המקומית מנצחת עצות כלליות.

שים לב גם לדיסק. מודלים מקומיים מצטברים מהר. כמה הורדות “רק לבדיקה” יכולות לאכול עשרות GB. אם אתה עובד על laptop עם SSD קטן, קבע כלל: כל מודל חייב סיבה. “ראיתי אותו בטוויטר” זו לא סיבה. “צריך baseline עברית”, “צריך code assistant”, “צריך מודל קטן ל-offline travel”, אלה סיבות. פעם בשבוע עבור על הרשימה ומחק מה שלא שייך. מקום בדיסק הוא חלק מתקציב ה-local שלך בדיוק כמו VRAM.

CPU Offload: להריץ 13B גם כשה-GPU קטן

CPU offload הוא אחד היתרונות המעשיים של GGUF ו-llama.cpp workflows. הרעיון פשוט: לא כל שכבות המודל חייבות לשבת על ה-GPU. אפשר להריץ חלק על GPU וחלק על CPU/RAM. זה מאפשר לנסות מודל גדול יותר מה-VRAM, למשל 13B על מחשב עם GPU 6GB, בתנאי שיש מספיק RAM וסבלנות. המחיר הוא מהירות. העברת עבודה ל-CPU מאטה generation, ולפעמים מאטה מאוד.

כאן חשוב להפריד בין “עובד” ל-“שימושי”. אם מודל 13B עם offload עונה אחרי דקה, הוא אולי שימושי לסיכום מסמך רגיש פעם ביום. הוא לא שימושי כ-coding assistant בזמן שאתה כותב. אם מודל 7B עונה תוך כמה שניות, הוא אולי פחות חכם אבל הרבה יותר נעים. local inference הוא תמיד tradeoff בין איכות, latency, פרטיות וזיכרון. אין בחירה אחת נכונה.

offload טוב במיוחד כשאתה מנסה להבין ceiling. נניח שיש לך כרטיס 6GB, 32GB RAM, ואתה רוצה לבדוק האם 13B נותן תשובות טובות יותר בעברית. במקום לקנות GPU חדש, אפשר להוריד GGUF מתאים, להריץ, למדוד, ולראות. אם האיכות קופצת והמהירות עדיין נסבלת, יש לך כלי. אם המחשב נחנק, למדת ש-7B Q5 או 8B Q4 הם sweet spot. בשני המקרים הרווחת החלטה.

לעומת זאת, AWQ ופורמטי quantization אחרים בעולם transformers לא תמיד נותנים את אותו offload נוח. AWQ יכול להיות מעולה ל-serving על GPU מתאים, אבל אם המודל לא נכנס ל-VRAM, אין לך את אותה בריחה פשוטה ל-RAM. לכן למחשב קטן, GGUF הוא לרוב הפורמט הידידותי יותר. אל תתבלבל מהמילה “4-bit”. שתי שיטות יכולות להיות 4-bit ועדיין להתנהג אחרת לגמרי בזיכרון.

מה offload מלמד אותך גם אם לא תשתמש בו קבוע

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

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

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

Ollama מול LM Studio מול llama.cpp: מי עושה מה

שלושת השמות האלה מופיעים יחד כל הזמן, ולכן כדאי לשים אותם במקום. llama.cpp הוא המנוע והאקוסיסטם הנמוך יותר: C/C++, GGUF, inference kernels, CLI, server, ותמיכה במודלים. הרבה כלים מעליו נהנים מהעבודה הזו. Ollama הוא שכבה נוחה מעל עולם המודלים המקומיים: התקנה, model management, פקודת run, שרת מקומי, ו-API שקל לחבר לקוד. LM Studio הוא אפליקציה חזותית חזקה לגילוי מודלים, הורדה, צ'אט מקומי, ובשנים האחרונות גם developer APIs ושרת מקומי.

הבחירה בפרק הזה היא לא “מי הכי טוב”. הבחירה היא “מה מתאים לשלב הלמידה שלך”. אם אתה רוצה לחקור מודלים, לראות UI, להוריד קבצים דרך ממשק גרפי ולשוחח עם מודלים בלי לכתוב קוד, LM Studio נהדר. אם אתה רוצה לשים local model מאחורי script, כלי CLI, Continue.dev או אפליקציה שאתה בונה, Ollama הוא בדרך כלל המסלול הקצר והחוזר. אם אתה רוצה שליטה עמוקה, flags, בנייה ממקור, או debugging ברמת engine, llama.cpp הוא השכבה שאליה תרד.

חשוב לעדכן כאן את ההרגל מהמחקר הישן: בעבר היה מקובל לומר ש-LM Studio API הוא beta ולכן לא מתאים לשירותים. נכון ליוני 2026, ל-LM Studio יש developer docs, REST API, OpenAI-compatible endpoints, SDKs ואפילו headless flow. זה לא אומר שאתה חייב להשתמש בו בפרק הזה. זה אומר שאסור ללמד טענה מיושנת. ההמלצה שלנו נשארת פרקטית: LM Studio לגילוי והשוואה, Ollama לאינטגרציה פשוטה בקוד, llama.cpp כשצריך שליטה עמוקה.

בפועל, הרבה workflow טוב נראה כך: פותחים LM Studio כדי לחפש מודל, לקרוא model card, לבדוק איך הוא עונה, ולראות אם הוא שווה הורדה. אחר כך מריצים אותו או מודל דומה ב-Ollama בשביל קוד. אם נתקלים במגבלה של Ollama, יורדים ל-llama.cpp או לכלי נמוך יותר. זו לא דת של כלי אחד. זו שכבות. ככל שהשכבה גבוהה יותר, קל יותר להתחיל. ככל שהשכבה נמוכה יותר, יש יותר שליטה ויותר אחריות.

איך לא להיתקע בין כלים

המלכודת היא להתקין הכול ואז לשכוח מה ניסית איפה. LM Studio הוריד מודל בשם אחד, Ollama משתמש בשם אחר, llama.cpp CLI מקבל path לקובץ, ופתאום אין לך מושג מי רץ. כדי להימנע מזה, שמור convention פשוט. לכל ניסוי יש שם קצר: hebrew-summary-8b-q4, code-helper-7b-q5, או private-docs-13b-offload. אותו שם מופיע בטבלת המודלים, בקובץ notes, ובשם הסקריפט אם יש. זה נשמע קטן, אבל זה הופך ניסויים לידע חוזר.

כלל נוסף: אל תערבב בין GUI validation לבין integration validation. GUI validation אומר “המודל ענה לי יפה ב-LM Studio”. integration validation אומר “הקוד שלי קרא למודל דרך API, קיבל JSON, טיפל בשגיאה, ויודע להחליף provider”. שניהם חשובים, אבל הם לא אותו דבר. מודל יכול להרגיש נהדר ב-GUI ולהיכשל באפליקציה בגלל שם model, streaming, timeout או context. לכן אחרי שבחרת מודל ב-GUI, תמיד עשה בדיקת API קטנה לפני שאתה בונה סביבו.

לחבר Ollama לקוד דרך OpenAI-compatible endpoint

הסיבה ש-Ollama כל כך שימושי ל-vibe coders היא לא רק שהוא מריץ מודלים. הסיבה היא שהוא יכול להיראות לקוד כמו provider נוסף. בפרק 2 השתמשת ב-OpenAI-compatible clients מול Groq, Cerebras או OpenRouter. עכשיו אתה עושה אותו דבר, רק שה-base_url מצביע ל-http://localhost:11434/v1. המודל לא יושב בענן; הוא יושב אצלך. אבל צורת הקריאה נשארת דומה.

זה דפוס חשוב: provider swap. אל תכתוב אפליקציה שמניחה שספק אחד הוא העולם כולו. כתוב שכבה קטנה שמקבלת provider, base_url, api_key ו-model. בפרק 2 השתמשת בזה כדי לסובב בין providers כשיש 429. כאן אתה משתמש באותה שכבה כדי לעבור בין cloud ל-local. אם הסקריפט צריך privacy, בחר local. אם הוא צריך איכות גבוהה או זמינות ציבורית, בחר cloud. הקוד העליון לא צריך לדעת יותר מדי.

דוגמת Python בסיסית עם OpenAI client:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:11434/v1",
    api_key="ollama-local-key"
)

response = client.chat.completions.create(
    model="llama3.1:8b",
    messages=[
        {"role": "system", "content": "You are a concise Hebrew technical assistant."},
        {"role": "user", "content": "הסבר בקצרה מה זה KV cache."}
    ],
)

print(response.choices[0].message.content)

ה-api_key כאן לא באמת מאמת אותך מול Ollama המקומי כמו בענן. הרבה clients דורשים ערך כלשהו כי הם נבנו עבור OpenAI. לכן שמים מחרוזת dummy. הדבר החשוב הוא base_url וה-model. אם תקבל שגיאה שהמודל לא נמצא, הרץ קודם ollama run <model> או בדוק שם מודל קיים עם פקודות הניהול של Ollama. אם תקבל connection refused, השרת המקומי לא רץ או שה-port שונה.

עכשיו אפשר לבנות provider switch קטן:

PROVIDERS = {
    "local": {
        "base_url": "http://localhost:11434/v1",
        "api_key": "ollama-local-key",
        "model": "llama3.1:8b",
    },
    "cloud": {
        "base_url": "https://api.groq.com/openai/v1",
        "api_key": "YOUR_GROQ_KEY",
        "model": "llama-3.1-8b-instant",
    },
}

def make_client(provider_name):
    cfg = PROVIDERS[provider_name]
    return OpenAI(base_url=cfg["base_url"], api_key=cfg["api_key"]), cfg["model"]

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

להפוך provider switch להרגל קוד

Provider switch טוב הוא לא רק מילון. הוא חוזה קטן בתוך הקוד שלך. החוזה אומר: “השכבה העליונה שולחת messages ומקבלת text, ולא אכפת לה מי הספק”. אם הספק המקומי לא זמין, אפשר להציג הודעה ברורה: “Ollama לא רץ, הפעל אותו או עבור ל-cloud”. אם cloud מחזיר 429, אפשר ליפול למקומי עבור משימות פרטיות או להמתין. ברגע שהחוזה הזה קיים, כל הפרויקט נהיה גמיש יותר.

שמור גם על security hygiene. אל תכתוב API keys בקובץ דוגמה. גם אם בפרק הזה ה-local key הוא dummy, אותו קוד מכיל גם מצב cloud. השתמש במשתני סביבה. כתוב בקובץ README אילו משתנים צריך. אם אתה משתף את הפרויקט ב-GitHub, ודא שאין keys בהיסטוריה. local inference לפעמים גורם לאנשים להוריד guard, כי “הכול במחשב”. אבל ברגע שיש provider switch, יש גם סודות ענן. התנהג בהתאם.

לבסוף, תן לכל provider מגבלות ברורות. local יכול להיות ברירת מחדל ל-prompts קצרים, מידע פרטי ו-development. cloud יכול להיות ברירת מחדל ל-reasoning קשה, batch ציבורי או מודל גדול. אם החלטה נעשית בכל פעם בראש שלך, היא תישכח. אם היא כתובה בקוד ובמסמך קצר, אפשר להסביר אותה גם לעצמך בעוד חודש וגם לשותף שיצטרף לפרויקט.

Continue.dev, LangChain ו-private document assistant

אחרי ש-Ollama נראה כמו provider, אפשר לחבר אותו לכלים קיימים. דוגמה אחת היא Continue.dev, extension שמאפשר להשתמש במודלים שונים בתוך VS Code. במקום לשלוח כל הסבר קוד לענן, אפשר להגדיר provider מקומי. זה לא אומר שהמודל המקומי יחליף מודל frontier בכל משימה. אבל הוא מצוין להסברים קצרים, יצירת boilerplate, refactor קטן, כתיבת tests ראשונית, או שאלות על קוד שלא רוצים להוציא החוצה.

דוגמה אחרת היא LangChain או כל framework דומה שמפריד בין model, retriever, prompts ו-chain. אם כבר יש לך flow שעובד מול OpenAI-compatible model, המעבר ל-Ollama אמור להיות קטן. העניין הוא לא library מסוים; העניין הוא boundary. מסמכים נשארים על הדיסק. embeddings יכולים להיווצר מקומית אם בחרת מודל מתאים. החיפוש יכול לרוץ על vector store מקומי. המודל מסכם רק את הקטעים הרלוונטיים. זה assistant פרטי, לא מוצר SaaS.

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

כאן נכנס ההבדל בין chat model ל-embedding model. chat model כותב תשובות. embedding model הופך טקסט לוקטורים שמאפשרים חיפוש סמנטי. assistant מסמכים טוב לא דוחף את כל התיקייה ל-context. הוא מחלק מסמכים לקטעים, יוצר embeddings, מחפש את הקטעים הרלוונטיים, ואז מכניס רק אותם ל-chat model. זה חשוב גם לזיכרון וגם לאיכות. אם תכניס הכול ל-context, תשלם ב-KV cache, latency ובלבול.

גבולות מידע: החלק שהופך assistant לפרטי באמת

Assistant פרטי אינו פרטי רק כי המודל רץ מקומית. הוא פרטי אם כל השרשרת נשארת מקומית: טעינת מסמכים, chunking, embeddings, retrieval, prompt construction, logging ותשובה. אם embeddings נשלחים לשירות חיצוני, עדיין יש יציאה לענן. אם logs נכתבים לכלי monitoring חיצוני, עדיין יש יציאה. אם אתה מעתיק פסקאות ל-chatbot אחר כדי “לבדוק”, הגבול נשבר. לכן לפני קוד, כתוב data flow.

Data flow פשוט יכול להיות טבלה עם ארבע עמודות: שלב, קלט, איפה הוא מעובד, מה נשמר. לדוגמה: “split documents” קורה בסקריפט מקומי ושומר chunks בדיסק. “embed chunks” קורה עם embedding model מקומי ושומר vector index מקומי. “answer question” קורה עם Ollama ומכניס רק שלושה chunks רלוונטיים ל-context. ברגע שזה כתוב, קל למצוא חורים. אולי embedding לא מקומי עדיין. אולי index נשמר בתיקייה לא מוצפנת. אולי prompt logs נשארים בקובץ. עדיף לדעת.

גם כאן, אל תתחיל מהמסמכים הכי רגישים. בנה prototype עם שני מסמכי sample שאתה מוכן למחוק. בדוק שה-flow עובד, שהמודל לא ממציא יותר מדי, ושאפשר להסביר מאיפה התשובה הגיעה. רק אז תכניס חומר אמיתי, וגם אז בהדרגה. פרטיות היא לא מצב בינארי; היא סדרת החלטות קטנות. local inference נותן לך אפשרות, אבל discipline הופך אותה למערכת.

Debugging וביצועים: מה עושים כשזה איטי או נתקע

Local inference נכשל בדרך כלל באחת מארבע צורות: המודל לא יורד, המודל לא עולה, המודל עולה אבל איטי מדי, או המודל עונה אבל לא מספיק טוב. כל אחת דורשת טיפול אחר. אם ההורדה נכשלת, בדוק רשת, מקום דיסק ושם מודל. אם המודל לא עולה, בדוק זיכרון ושגיאות backend. אם הוא איטי, בדוק model size, quantization, context ואפליקציות פתוחות. אם האיכות נמוכה, בדוק prompt, מודל מתאים למשימה, ושדרוג ל-Q5 או מודל אחר.

אל תתחיל tuning בלי baseline. לפני שאתה משנה context, מחליף מודל או פותח עוד כלי, הרץ prompt קבוע ומדוד בערך כמה זמן לוקח לקבל תשובה שימושית. לא צריך דיוק מדעי. אתה צריך לדעת אם שינוי שיפר או הרס. לדוגמה: prompt קבוע בעברית לסיכום, prompt קבוע לקוד, prompt קבוע לשאלה לוגית. שלושת ה-prompts האלה יהפכו ל-regression set בשגרת העבודה.

אם latency איטי מדי, הסדר הנכון הוא: קודם הקטן context, אחר כך סגור אפליקציות כבדות, אחר כך עבור ל-Q4 אם היית ב-Q5, אחר כך עבור למודל קטן יותר. אל תעשה הכול בבת אחת. שינוי אחד בכל פעם. אחרת לא תדע מה עזר. אם אתה על laptop, בדוק גם חום ו-power mode. מחשב נייד על battery יכול להיות איטי בהרבה ממחשב מחובר לחשמל. לפעמים “המודל גרוע” הוא בעצם “המחשב במצב חיסכון”.

אם התשובה לא טובה, אל תסיק מיד שהמודל חלש. בדוק האם נתת לו מספיק context, האם ההוראה ברורה, והאם המשימה בכלל מתאימה למודל קטן. מודל 7B מקומי לא אמור להחליף מודל frontier בכל reasoning ארוך. הוא כן יכול להיות מצוין ל-draft, סיכום, תיוג, code snippets, שינוי פורמט, או brainstorming פרטי. תן לו משימות בגודל שמתאים לו, ואז הוא מרגיש הרבה יותר חכם.

Playbook קצר לבעיות נפוצות

אם ההורדה איטית או נתקעת, בדוק קודם מקום דיסק ורשת. מודלים גדולים יורדים כקבצים של כמה GB, וחיבור לא יציב יכול ליצור חוויה מתסכלת. אל תחליף מודל לפני שבדקת שהבעיה אינה כללית. אם המודל לא עולה, חפש את ההודעה המדויקת: out of memory, model not found, unsupported architecture, או connection refused. כל הודעה מצביעה על שכבה אחרת. אל תפתור connection refused על ידי הורדת מודל אחר; הפעל את השרת.

אם המודל עולה אבל איטי, עבור לפי סדר. קודם בדוק האם המחשב על power saving. אחר כך בדוק אפליקציות פתוחות. אחר כך הורד context. אחר כך עבור ל-Q4 או למודל קטן יותר. אם האיכות נמוכה, עשה את הסדר ההפוך: שפר prompt, בדוק מודל מתאים יותר למשימה, נסה Q5, ואז שקול cloud. ביצועים ואיכות אינם אותה בעיה, ולכן הטיפול שונה.

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

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

בפרק 2 בנית הרגל של rate limits, rotation ו-backoff. בפרק 3 בנית הרגל של checkpointing ו-storage מתמיד. בפרק הזה השגרה היא אחרת: לשמור את סביבת המודלים המקומית נקייה, מדודה ושימושית. בלי שגרה, local inference הופך למחסן קבצים: עשרה מודלים שהורדת פעם, אין מושג מי טוב למה, הדיסק מלא, והאפליקציה שלך מצביעה למודל ששכחת למה בחרת.

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

איך מחברים את השגרה לפרקים הקודמים

השגרה המקומית לא עומדת לבד. מפרק 2 אתה מביא את ההרגל לא להאמין לספק יחיד: תמיד יש provider נוסף, fallback, והבנה של מגבלות. מפרק 3 אתה מביא את ההרגל לא לסמוך על session זמני: תמיד יש שמירה, מדידה ותיעוד. בפרק הזה אתה מוסיף הרגל שלישי: לא להאמין למודל מקומי רק כי הוא רץ. כל מודל צריך לעבור את שלושת ה-prompts הקבועים, להיכנס לטבלת sizing, ולקבל תפקיד ברור. אם אין לו תפקיד, הוא רעש.

החיבור הזה חשוב במיוחד בפרק 5. כשתבנה pipeline $0, יהיו לך שלוש שכבות: notebook לאימון או fine-tune, API חינמי ל-serving ציבורי או מודל גדול, ו-local fallback למשימות פרטיות או dev. אם השכבה המקומית לא מתועדת, היא לא תהיה fallback אמיתי; היא תהיה “משהו שעבד פעם במחשב שלי”. אם היא מתועדת, אפשר להחליט: prompt פרטי רץ ב-Ollama, batch ציבורי רץ ב-Groq או Cerebras, ו-training רץ ב-Kaggle. זה ההבדל בין אוסף טריקים לבין מערכת.

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