LoRA ו-QLoRA - איך זה עובד ומה נכנס על GPU חינמי

למה full fine-tuning לא נכנס ל-GPU חינמי

נתחיל מהכאב האמיתי: אתם רואים tutorial שמבטיח fine-tuning למודל 7B, פותחים Colab, מפעילים תא ראשון, ואחרי כמה דקות מקבלים OOM (Out Of Memory). ההודעה נראית טכנית, אבל הסיבה פשוטה: אימון מלא לא שומר בזיכרון רק את המודל. הוא צריך להחזיק גם את ה-gradients, את מצבי ה-optimizer, ואת ה-activations שנוצרים בזמן מעבר קדימה ואחורה. לכן "מודל 7B ב-bf16" הוא לא רק 14GB של משקלים. זה בסיס שמושך אחריו עוד שכבות זיכרון.

המספר שמופיע בסילבוס, בערך 28GB למודל 7B ב-bf16, הוא דרך שימושית לזכור את הסדר גודל. הוא לא simulator מדויק, כי בפועל הזיכרון תלוי ב-batch size, אורך רצף, optimizer, gradient checkpointing, framework וגרסת הספריות. אבל כאינטואיציה, הוא מספיק כדי לקבל החלטה: אם ה-GPU החינמי שלכם נותן בערך 15GB usable, full fine-tuning של 7B הוא לא נקודת פתיחה טובה. גם אם תא מסוים מצליח להיטען, האימון עצמו עלול ליפול באמצע, וזה הרגע הכי יקר: כבר שרפתם זמן session, הורדתם מודל, התחלתם להרגיש שהכול עובד, ואז הזיכרון נגמר.

חשוב להבין את ההבדל בין inference לבין training. בהרצה רגילה, אתם מבקשים מהמודל להשיב. צריך מקום למשקלים, קצת cache, וקונטקסט. באימון, אתם מבקשים מהמודל לשנות את עצמו. כדי לדעת איך לשנות, המערכת צריכה לשמור מידע ביניים, לחשב שגיאות, ולעדכן פרמטרים. זו פעילות הרבה יותר רעבה לזיכרון. לכן אותו 7B שאולי רץ לכם יפה ב-Ollama או LM Studio יכול להיות בלתי אפשרי לאימון מלא על אותה חומרה.

כאן נכנסת החשיבה של הפרק: אנחנו לא מנסים לנצח את מגבלת הזיכרון בכוח. אנחנו משנים את השאלה. במקום "איך מאמנים את כל המודל", נשאל "איזה חלק קטן מספיק ללמד כדי לקבל את ההתנהגות הרצויה". אם בפרק 1 בחרתם fine-tuning בגלל brand voice, schema compliance או סגנון קוד אישי, לרוב לא צריך לשכתב את כל הידע של המודל. צריך ללמד אותו דפוס תגובה. זה בדיוק האזור שבו LoRA ו-QLoRA הופכים את הבעיה מאפשרית.

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

לעומת זאת, אם אותה חברה רוצה שהמודל יענה על זמינות מלאי, מדיניות החזרות שמתעדכנת, או מחיר מבצע שמתשנה כל שבוע, LoRA לא פותר את הבעיה המרכזית. שם הבעיה היא ידע דינמי. בפרק 1 קראנו לזה אזור של RAG או prompt עם מקור נתונים, לא fine-tuning. ההבחנה הזאת תחסוך לכם הרבה כסף: LoRA טוב בללמד "איך לענות", לא בלשמור "מה המחיר המעודכן". אפשר להכניס ידע ל-dataset, אבל ידע משתנה יהפוך את המודל למיושן מהר.

עוד דרך לזכור את זה: full fine-tuning שואל "מה כל המשקלים צריכים להיות עכשיו". LoRA שואל "איזה תיקון קטן צריך להוסיף על ההתנהגות הקיימת". QLoRA שואל "איך נשמור את אותו תיקון קטן, אבל נטען את הבסיס בצורה חסכונית מספיק כדי שזה יעבוד על GPU חינמי". שלוש השאלות האלה יופיעו שוב ושוב בפרק. בכל פעם שתתלבטו בין מודל גדול יותר, rank גבוה יותר או runtime חזק יותר, חזרו אליהן. אם לא ברור איזה תיקון קטן אתם מלמדים, אין סיבה לרוץ לאימון.

אפשר להפוך את זה לנוסחה קצרה: אם השינוי שאתם רוצים לתאר נשמע כמו "המודל צריך לדעת עובדה חדשה", עצרו וחזרו ל-RAG או ל-dataset עם מקור ברור. אם השינוי נשמע כמו "המודל צריך לענות אחרת על סוג בקשות שהוא כבר מבין", המשיכו ל-LoRA. אם השינוי הזה צריך לרוץ על GPU חינמי, המשיכו ל-QLoRA. הנוסחה הזו אינה מחליפה חשיבה, אבל היא מצמצמת טעויות. היא גם עוזרת להסביר ללקוח למה לא קופצים ישר לאימון מלא: אנחנו לא חוסכים כי אנחנו מתפשרים, אלא כי הבעיה עצמה קטנה יותר מאימון מלא.

הנה דוגמה נגדית: מישהו רוצה "מודל שמכיר את כל קטלוג המוצרים שלנו". זה נשמע כמו fine-tuning, אבל ברוב המקרים זו בעיית retrieval. הקטלוג משתנה, מחירים משתנים, מלאי משתנה, ותיאורים מתעדכנים. אם תאמן מודל על קטלוג מאי, ביוני כבר יש לך מודל בטוח בעצמו ומיושן. לעומת זאת, "מודל שכותב תשובות מוצר באותו טון של צוות המכירות שלנו" הוא שינוי התנהגותי. הוא יכול להשתמש בקטלוג דרך RAG, אבל הטון והמבנה יכולים להגיע מ-LoRA. לפעמים הפתרון הטוב הוא שילוב: RAG לידע, LoRA להתנהגות.

LoRA בגובה העיניים: לאמן שינוי קטן במקום מודל שלם

LoRA (Low-Rank Adaptation) היא דרך לומר למודל: "אל תשנה את כל מה שאתה יודע. הוסף שכבת שינוי קטנה מעל הידע הקיים". מבחינה טכנית, במקום לעדכן את מטריצות המשקל הגדולות של המודל, משאירים את ה-base weights קפואים ומוסיפים שתי מטריצות קטנות, בדרך כלל נקראות A ו-B. המטריצות האלה לומדות delta, כלומר שינוי ביחס להתנהגות הבסיסית. בסוף האימון אפשר לטעון את ה-base יחד עם ה-adapter, או למזג את ה-adapter חזרה למודל לשימוש נוח יותר.

הדימוי הכי שימושי הוא שכבת שקיפות על מפה. המפה המקורית נשארת. אתם לא מציירים מחדש את כל המדינה. אתם מסמנים עליה נתיב, אזהרות, צבעים ועדיפויות. אם מחר תרצו נתיב אחר, לא צריך לשכפל את כל המפה. מחליפים שכבת שקיפות. אותו דבר ב-LoRA: base model אחד יכול להחזיק כמה adapters שונים, למשל אחד ל-brand voice של סוכנות שיווק ישראלית, אחד לתשובות תמיכה, ואחד לפורמט JSON של מוצר SaaS.

למה זה חוסך זיכרון? כי רוב הפרמטרים לא מקבלים gradients ולא מתעדכנים. במקום לאמן מיליארדי מספרים, מאמנים חלק קטן מאוד, לעיתים פחות מאחוז אחד מהמודל. זה לא אומר שהשינוי חסר כוח. מודלים גדולים כבר מכילים הרבה יכולת. בפרק 1 ראינו ש-fine-tuning מתאים במיוחד כשהבעיה היא התנהגות עקבית, לא חיפוש ידע חדש. אם המודל כבר יודע לכתוב, לסכם, למיין, לענות בעברית, ולהחזיר JSON, לפעמים צריך רק ללמד אותו איך אתם רוצים שיבחר בין האפשרויות האלה.

יש עוד יתרון חשוב: adapter הוא artifact קטן. בסביבת עבודה אמיתית, זה אומר שאפשר לנהל ניסויים. אתם יכולים לשמור adapter ל-r=8, adapter ל-r=16, ו-adapter עם dataset נקי יותר, בלי להעתיק מאות גיגה של מודלים. עבור Vibe Coder או צוות קטן, זה ההבדל בין "אני יכול לבדוק שלוש גרסאות השבוע" לבין "אני מפחד לגעת בזה כי כל ניסיון עולה יותר מדי".

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

בפועל, LoRA גם משנה את צורת העבודה שלכם. במקום "אימנתי מודל" כפעולה אחת גדולה, אתם מתחילים לחשוב בגרסאות: adapter-v1 על 300 דוגמאות, adapter-v2 עם dataset נקי יותר, adapter-v3 עם rank נמוך יותר. זה חשוב במיוחד למי שעובד לבד או בצוות קטן, כי אין לכם תקציב למחקר ארוך. אתם צריכים לייצר evidence מהר. adapter קטן מאפשר לשמור תוצאות, להשוות, לחזור אחורה, ולהבין מה באמת עבד. אם fine-tuning הופך להיות תהליך שאי אפשר לשחזר, הוא לא כלי עבודה; הוא הימור.

יש גם מושג שכדאי להכיר כבר עכשיו: target modules. ב-notebooks רבים תראו שה-LoRA מחובר לשכבות attention או לשמות כמו q_proj, v_proj, k_proj ו-o_proj. בפרק הזה לא נכתוב קונפיג מלא, אבל חשוב להבין למה זה קיים. adapter לא חייב להתחבר לכל מקום במודל. הספרייה בוחרת נקודות שבהן שינוי קטן משפיע הרבה. עבור מתחילים, ברוב המקרים עדיף להשתמש ב-default של notebook מוכר כמו Unsloth ולא להמציא target modules לבד. שינוי כזה לפני שיש baseline הוא דרך מהירה לייצר תוצאה שאי אפשר להסביר.

כדאי גם לדעת מה קורה בסוף. Adapter יכול להישאר נפרד, ואז אתם טוענים base model ואיתו adapter. הוא גם יכול להיות ממוזג אל תוך המודל, למשל עם פונקציות כמו merge_and_unload() בעולם PEFT. המיזוג חשוב בהמשך כשנרצה להמיר ל-GGUF ולהריץ ב-Ollama. כרגע רק זכרו את העיקרון: LoRA יוצר שינוי קטן ונייד, אבל כדי להפוך אותו למודל נוח להפצה צריך להבין את שלב ה-merge. בפרק 4 נעשה את זה בפועל.

מתי LoRA לא מספיק גם אם הוא נכנס לזיכרון? כאשר המשימה דורשת שינוי עמוק ביכולות reasoning שה-base חלש בהן. אם מודל קטן לא יודע לפתור סוג מסוים של בעיות קוד, adapter על 200 דוגמאות לא יהפוך אותו פתאום למומחה. הוא עשוי לחקות סגנון פתרון, אבל לא תמיד לרכוש יכולת כללית. לכן בחירת base model חשובה. LoRA הוא מכפיל של יכולת קיימת, לא תחליף לבסיס לא מתאים. אם אתם רוצים assistant לקוד, התחילו ממודל coder. אם אתם רוצים עברית טובה, בדקו עברית ב-base לפני אימון. adapter לא אמור לתקן בחירת מודל גרועה.

באותה רוח, LoRA טוב במיוחד כאשר אתם יכולים לנסח "לפני ואחרי" ברור. לפני: המודל כותב תשובה באורך 400 מילים. אחרי: 120 מילים, שלוש נקודות, CTA אחד. לפני: המודל מחזיר JSON עם שדות לא עקביים. אחרי: schema קבוע עם שמות שדות יציבים. לפני: המודל נשמע אמריקאי מדי. אחרי: עברית עסקית ישראלית, בלי תרגום מילולי ובלי סופרלטיבים מוגזמים. אם אין לכם לפני ואחרי כזה, כנראה שהמשימה עדיין לא מוכנה ל-dataset.

QLoRA: אותו רעיון, בסיס דחוס ל-4-bit

QLoRA (Quantized LoRA) מוסיף ל-LoRA טריק אחד גדול: ה-base model נטען בצורה דחוסה, בדרך כלל 4-bit, בזמן שה-adapter נשאר החלק שמתאמן. במקום להחזיק את משקלי הבסיס ב-16-bit, משתמשים ב-quantization כדי לייצג אותם בפחות זיכרון. בפשטות: המודל עדיין שם, אבל המספרים שלו מאוחסנים בצורה חסכונית יותר. זה לא חינם מבחינת דיוק, אבל עבור הרבה משימות SFT מעשיות, זה מספיק טוב כדי להתחיל.

חשוב לדייק: QLoRA לא אומר שכל האימון קורה ב-4-bit בצורה נאיבית. הרעיון הוא שה-base quantized חוסך את רוב הזיכרון, וה-adapter לומד את השינוי. מערכות מודרניות מטפלות בפרטים של compute precision, טעינת שכבות, ו-backprop כך שהלומד לא צריך לכתוב את זה מאפס. מבחינתכם, השאלה המעשית היא: האם אני יכול להשתמש ב-QLoRA כדי להכניס מודל 7B ל-GPU חינמי ולבצע ניסוי הגיוני בלי לשלם.

המונח NF4 מופיע הרבה בהקשר הזה. הוא סוג של 4-bit quantization שמותאם להתפלגות משקלים במודלים. אתם לא צריכים לזכור את המתמטיקה שלו עכשיו. כן כדאי לזכור את ההשלכה: 4-bit נותן חיסכון משמעותי בזיכרון, אבל ההחלטה אינה "4-bit תמיד טוב" או "4-bit תמיד גרוע". זו פשרה. כשאתם מאמנים מודל ל-brand voice, סיווג, או תשובות תמיכה, הפשרה בדרך כלל משתלמת. כשאתם חייבים syntax מדויק, JSON מושלם, או reasoning עדין, צריך בדיקת A/B קטנה.

הסיבה ש-QLoRA נהיה default למתחילים היא לא שהוא מושלם. הוא default כי הוא פותח דלת. במקום להתחיל עם דרישה ל-A100 או לשרת יקר, אתם יכולים להתחיל עם Colab או Kaggle, להבין את ה-data, לבנות loop של מדידה, ורק אחר כך להחליט אם צריך יותר חומרה. בעולם של קורס מעשי, זה חשוב יותר מהאפשרות התיאורטית להגיע לאיכות עוד טיפה גבוהה יותר באימון מלא שלא תצליחו להריץ.

יש גם בלבול נפוץ בין quantization לאימון קצר. QLoRA לא אומר שה-run בהכרח יהיה קצר, ולא אומר שה-dataset יכול להיות רשלני. הוא רק משנה את פרופיל הזיכרון. אם ה-dataset שלכם מכיל 80 דוגמאות חלשות, QLoRA יאפשר לכם לאמן מהר יותר מודל לא טוב. אם ה-chat template לא תואם, QLoRA לא יציל אתכם מפלט מקושקש. לכן בפרק 3 נתמקד ב-data. בפרק הזה אנחנו רק מוודאים שאתם בוחרים מסלול חומרה והיפר-פרמטרים שלא יפילו אתכם לפני שהגעתם בכלל לבעיית איכות.

כדאי להיזהר גם מהמשפט "QLoRA כמעט כמו full fine-tuning". הוא יכול להיות נכון במשימות מסוימות ולא מספיק באחרות. עבור brand voice, ניסוח, תמיכה ו-classification פשוט, הפער לרוב פחות חשוב מהיכולת להריץ ניסוי בכלל. עבור קוד, תבניות JSON קשיחות, או reasoning שבו טעות קטנה שוברת תהליך אוטומטי, הפער יכול להפוך לבאג מוצר. לכן ההחלטה אינה טכנית בלבד. שאלו מה מחיר הטעות. אם טעות היא רק ניסוח קצת פחות חד, QLoRA הוא התחלה מצוינת. אם טעות היא webhook שנכשל או חשבונית שנוצרת עם שדה שגוי, צריך מדידה יותר קשוחה.

בתרחיש ישראלי טיפוסי, נניח סוכנות אוטומציה בונה assistant שמחזיר JSON ל-Make או Zapier. אם המודל מחזיר פסיק מיותר, האוטומציה יכולה ליפול. במקרה כזה אל תסתפקו בתחושה שהמודל "נשמע יותר טוב". הכינו validation קטן: עשרים prompts, בדיקת schema, ותיעוד כמה עברו. אם QLoRA משפר את הטון אבל מוריד עמידה ב-schema, אולי צריך rank אחר, dataset אחר, או אפילו פתרון prompt+validator במקום fine-tuning. זה לא כישלון; זו למידה מוקדמת וזולה.

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

הכלל המעשי שלי: QLoRA הוא default לניסוי ראשון, לא בהכרח default לניסוי אחרון. מתחילים איתו כי הוא זול, נגיש ומלמד מהר. אם הוא נכשל, לא קופצים מיד ל-full fine-tuning. קודם שואלים ארבע שאלות: האם ה-base מתאים, האם ה-dataset מספיק נקי, האם ה-rank מתאים, והאם מדד ההצלחה בודק את הדבר הנכון. רק אחרי שהתשובות האלה טובות ועדיין יש פער, שווה לשקול חומרה חזקה יותר או שיטה אחרת. זה סדר חסכוני ובריא.

תקציב VRAM מעשי: מה נכנס על T4, P100 ו-T4x2

עכשיו נתרגם אינטואיציה להחלטה. GPU חינמי הוא לא הבטחה קשיחה. Colab יכול לתת GPU או לא לתת GPU, סוג ה-GPU משתנה, והמשאבים אינם מובטחים. Kaggle מתעדת מכסה שבועית של GPU, אבל גם שם זמינות accelerator תלויה בסביבה ובזמן. לכן הטבלה הבאה אינה חוזה. היא כלי pre-flight: דרך לחשוב על סיכון לפני שמפעילים run.

כלל האצבע לפרק הזה: אל תתכננו על 100% מה-VRAM. השאירו margin. יש activations, tokenizer, data loader, overhead של framework, ולעיתים גם זיכרון שמור. אם אתם רואים 15GB usable, אל תבנו תוכנית שדורשת 14.9GB ומקווה לטוב. למתחילים, margin של 20% הוא לא פחדנות. הוא ביטוח נגד session מבוזבז. אם run נופל אחרי שעה, העלות היא לא רק זמן GPU. העלות היא איבוד אמון בתהליך.

הדרך הפשוטה לחשוב על תקציב היא בשלוש שכבות. שכבה ראשונה: גודל המודל אחרי quantization. זו השכבה שכולם מדברים עליה. שכבה שנייה: עלות האימון סביבו, כולל activations ו-batch. זו השכבה שמפילה runs. שכבה שלישית: מרווח העבודה שלכם, כלומר מקום לשגיאות, לגרסאות ספרייה, ולתאים נוספים שרצים ב-notebook. אם הטבלה אומרת "אפשרי" אבל אין לכם מרווח, תתייחסו לזה כ"צמוד". אם הטבלה אומרת "צמוד" ואתם מתחילים, תתייחסו לזה כ"לא היום".

למשל, 13B יכול להיראות אפשרי כי מספר מסוים באינטרנט אומר שהוא נכנס ב-12-13GB. אבל אם אתם מוסיפים sequence length ארוך, batch לא שמרני, או dataset עם דוגמאות ארוכות, אותו ניסוי יכול לעבור את הגבול. לכן בפרויקט ראשון אין בושה להתחיל ב-2B או 4B. להפך: מודל קטן שמסיים אימון ונותן לכם loop של data-eval עדיף ממודל גדול שנופל. אחרי שיש לכם pipeline עובד, אפשר לעלות גודל. סדר הפעולות חשוב: קודם מערכת שמסיימת, אחר כך מערכת מרשימה.

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

שימו לב לכוכבית החשובה: מספרי VRAM משתנים לפי מודל, framework וגרסה. מודל 7B אחד לא זהה למודל 7B אחר. Qwen, Llama, Gemma ומודלי coder שונים משתמשים ב-tokenizer, שכבות והגדרות שונות. אם אתם רואים טבלה אחרת באינטרנט, אל תנסו להכריע מי "צודק". שאלו מה היו התנאים: max_seq_length, batch size, optimizer, gradient checkpointing, quantization, וגרסת Unsloth או PEFT. כל טבלה בלי התנאים האלה היא מצפן, לא מפה.

אחרי התרגיל, אל תזרקו את הטבלה. היא תהפוך למסמך עבודה בפרק 4. כשנגיע ל-notebook ויהיה מפתה לשנות model name למשהו גדול יותר, חזרו לשורה שבחרתם. אם לא עדכנתם VRAM, rank, sequence length ו-success test, אין שינוי. זה נשמע נוקשה, אבל זו בדיוק המשמעת שמפרידה בין "שיחקתי עם fine-tuning" לבין "בניתי ניסוי שאפשר ללמוד ממנו".

אם אתם עובדים בצוות, הטבלה גם יוצרת שפה משותפת. במקום ויכוח כללי על "למה לא 13B", אפשר להראות ש-13B הוא צמוד על runtime החינמי, שדורש fallback, ושאינו נחוץ למשימת style ראשונה. זה מאפשר להחליט מקצועית בלי להיכנס לאגו של מודלים. הרבה פרויקטי AI קטנים נתקעים לא בגלל חוסר ידע, אלא בגלל בחירה מוקדמת במסלול גדול מדי.

כדאי להוסיף לטבלה עמודת "מה אני לומד מה-run". אם 2B קטן מדי אבל מסיים, הוא עדיין יכול ללמד האם dataset בנוי נכון, האם chat template תקין, והאם ה-evaluation שלכם עובד. אם 7B נותן איכות טובה יותר אבל קשה להרצה, אתם יכולים להחליט שהוא run שני ולא ראשון. אם 13B נכשל לפני שהתחיל, הוא לא לימד כלום חוץ מזה שהתכנון היה אופטימי. פרויקט טוב מתוכנן כך שגם ניסוי קטן נותן מידע שימושי.

עוד עמודה מועילה היא "עלות החלפה". מעבר מ-Colab ל-Kaggle דורש קצת הסתגלות, אבל לא משנה את כל הפרויקט. מעבר מ-2B ל-7B עשוי לשנות זמני אימון, batch, ואולי איכות. מעבר מ-QLoRA ל-full fine-tuning משנה את כל הנחת המשאבים. כשאתם כותבים את העלות הזאת ליד כל אפשרות, קל יותר לבחור מסלול שמתקדם בשלבים במקום לקפוץ מצוק. fine-tuning טוב נבנה כמו גרם מדרגות, לא כמו קפיצה אחת גדולה.

Rank ו-lora_alpha: הכפתור שלא כדאי לנפח סתם

Rank (r) הוא אחד הפרמטרים הראשונים שתראו בקוד LoRA. הוא קובע כמה "רחב" adapter העדכון. Rank גבוה נותן ל-adapter יותר יכולת לייצג שינוי מורכב, אבל גם מגדיל זיכרון, זמן אימון, וסיכון שהמודל ילמד יותר מדי מה-dataset הצר שלכם. Rank נמוך מגביל את השינוי, וזה לפעמים יתרון. אם המשימה היא style transfer, אתם לא רוצים שהמודל ישכח יכולות כלליות. אתם רוצים רק שידבר בטון מסוים.

המספרים הבאים הם heuristics, לא חוק טבע. r=8 הוא נקודת פתיחה טובה למשימות style, brand voice, ניסוח, tone, ותבניות תגובה פשוטות. r=16-32 מתאים כשיש skill learning: סיווג עם נימוק, שכתוב לפי כללים, תשובות תמיכה עם מבנה קבוע, או סגנון קוד אישי. r=64+ נשמר למשימות מורכבות יותר, אבל לא מתחילים ממנו רק כי יש מקום בזיכרון. אם אין לכם dataset איכותי ומדידה טובה, rank גבוה יכול לתת למודל יותר מקום ללמוד רעש.

lora_alpha הוא scaling factor. בהרבה notebooks תראו כלל אצבע של alpha כפול מה-rank, למשל r=16 ו-alpha=32. אל תתייחסו לזה כאמת קדושה. זה default נוח להתחלה. בפרויקט לימודי, אתם לא מנסים למצוא את optimum המתמטי. אתם מנסים לבחור נקודת פתיחה יציבה. לכן הכרטיס שתבנו בתרגיל יכלול לא רק r ו-alpha, אלא גם תנאי שינוי: מה צריך לקרות כדי שתעלו rank, ומה צריך לקרות כדי שתורידו אותו.

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

עוד דבר שמבלבל beginners הוא הקשר בין rank לבין גודל dataset. אם יש לכם dataset קטן מאוד, rank גבוה יכול לתת למודל יותר מדי חופש ללמוד רעש. אם יש לכם dataset גדול, מגוון ונקי, rank מעט גבוה יותר עשוי להיות מוצדק. לכן "r=64 כי המשימה חשובה" אינו נימוק. נימוק טוב נשמע כך: "המשימה דורשת למידה של מבנה תשובה מורכב, יש לי לפחות 1,000 דוגמאות מגוונות, ויש לי held-out set שמודד schema ויכולת כללית". אם אין לכם את המשפט הזה, התחילו נמוך יותר.

ביומן הניסוי, רשמו rank לצד סימפטומים, לא רק לצד score. לדוגמה: "r=8: הטון השתפר אבל הפורמט נשבר ב-6 מתוך 20". או: "r=32: הפורמט יציב אבל התשובות נהיו דומות מדי וארוכות מדי". סימפטומים כאלה מלמדים יותר ממספר יחיד. הם גם עוזרים להחליט האם התיקון הוא rank, data, prompt, או post-processing. בלי הסימפטומים, קל מאוד להחליף פרמטרים באקראי ולהרגיש שאתם עושים optimization.

זכרו ש-rank אינו כפתור איכות בודד. הוא עובד יחד עם learning rate, מספר epochs, אורך הדוגמאות, גיוון dataset, ויכולת ה-base. בפרק 4 נשתמש ב-defaults שמרניים, ובכוונה לא נשחק עם הכול בבת אחת. כלל עבודה טוב: בכל ניסוי משנים משתנה מרכזי אחד בלבד. אם שיניתם גם rank, גם model, גם dataset וגם epochs, אין דרך לדעת מה גרם לשיפור או לכישלון. Fine-tuning הוא ניסוי, וניסוי צריך בידוד.

במונחים עסקיים, rank הוא תקציב שינוי. אם אתם עובדים עם חנות אונליין ישראלית שרוצה תיאורי מוצר בסגנון קצר, חם ומכבד, r=8 יכול להספיק. אם אתם בונים assistant שצריך להפוך brief שיווקי ל-JSON קבוע עם 12 שדות, אולי תתחילו ב-r=16 או r=32 ותבדקו validation. אם אתם מנסים ללמד reasoning משפטי או קוד מורכב, הבעיה כבר אינה רק rank; צריך dataset עמוק, eval רציני, ולעיתים מודל גדול יותר.

איכות מול סיכון: מתי QLoRA מספיק ומתי צריך בדיקת A/B

QLoRA מספיק להרבה מאוד פרויקטים ראשונים, אבל לא לכל מצב באותה רמת ביטחון. אם המטרה היא tone, סגנון, אורך תשובה, או העדפת phrasing מסוים, QLoRA על מודל 2B-7B יכול להיות מצוין. אם המטרה היא JSON exactness, קוד תקין, או תשובות שחייבות לעמוד ב-schema בלי שגיאה, כדאי להוסיף בדיקת A/B מוקדמת. לא בגלל ש-QLoRA בהכרח ייכשל, אלא בגלל שהעלות של כשל בפורמט גבוהה יותר.

בדיקת A/B בפרק הזה היא לא מערכת evaluation כבדה. היא שלוש עד עשרים דוגמאות held-out, כלומר דוגמאות שלא הופיעו באימון. אתם מריצים אותן על ה-base ועל המודל המאומן ומשווים. אם המודל המאומן נשמע יותר כמו המותג אבל שובר JSON, לא ניצחתם. אם הוא שומר על JSON אבל מאבד יכולת לענות לשאלות פשוטות, יש סימן ל-catastrophic forgetting. אם הוא משתפר רק בדוגמאות שהיו דומות מאוד ל-training data, כנראה שה-dataset צר מדי.

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

מבחינת לקוח או פרויקט אישי, בדיקת A/B היא גם דרך לשמור על שיחה בריאה. במקום לומר "המודל המאומן טוב יותר", אתם אומרים: "על 20 דוגמאות שלא ראו אימון, עברנו מ-11 תשובות תקינות ל-17, והיו שני כשלי JSON שצריך לתקן". זה נשמע פחות דרמטי, אבל הרבה יותר מקצועי. בפרק 5 נרחיב את זה ל-evaluation מסודר. כאן אתם רק מניחים את השריר.

כדי שהבדיקה תהיה שימושית, הגדירו rubric קצר. עבור brand voice, אפשר לתת ציון 1-5 על קרבה לטון, ציון 1-5 על בהירות, וסימון כן/לא על אורך מתאים. עבור JSON, אפשר לבדוק שלושה דברים: האם הפלט parseable, האם כל השדות קיימים, והאם הערכים עומדים בהוראות. עבור תמיכה, אפשר לבדוק האם התשובה אמפתית, האם היא שואלת שאלת הבהרה כשצריך, והאם היא נמנעת מהבטחה לא נכונה. rubric כזה מספיק לפרק ראשון. הוא לא מושלם, אבל הוא מונע הערכה לפי תחושת בטן בלבד.

אל תבנו held-out set שמחמיא למודל. זו טעות עדינה. אם כל הדוגמאות קצרות, נקיות ודומות ל-training data, המודל ייראה טוב מדי. הכניסו לפחות דוגמה אחת עם עברית לא מושלמת, דוגמה אחת עם מונח אנגלי באמצע, ודוגמה אחת שבה המשתמש מבקש משהו מחוץ לגבולות המשימה. fine-tuning טוב אינו רק זה שנותן תשובה יפה כשהכול נוח; הוא זה שלא מתפרק כשהקלט נראה כמו עבודה אמיתית.

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

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

בחירת סביבת ריצה: Colab, Kaggle או מחשב מקומי

בשלב הזה יש לכם שלוש החלטות מחוברות: גודל מודל, שיטת אימון, ו-runtime. Colab נוח מאוד לניסוי קצר. פותחים notebook, מחליפים runtime ל-GPU, ורצים. החיסרון הוא שהמשאבים לא מובטחים, סוג ה-GPU משתנה, ו-free tier יכול להסתיים או לרדת ל-CPU בזמנים עמוסים. Kaggle פחות חלק למי שלא מכיר, אבל עבור fine-tuning הוא לעיתים יציב יותר, ומכסת ה-GPU השבועית הופכת אותו למסלול חינמי טוב. מחשב מקומי נוח אם יש לכם GPU מתאים, אבל ההתקנה יכולה לגנוב יום שלם אם הדרייברים לא במקום.

ההחלטה אינה אידאולוגית. היא פונקציונלית. אם אתם רק לומדים את pipeline ורוצים לאמן 2B או 4B, Colab מספיק. אם אתם רוצים להריץ 7B בצורה יותר אמינה או לבדוק 13B בזהירות, Kaggle יכול להיות עדיף. אם יש לכם RTX עם מספיק VRAM, local נותן שליטה ופרטיות, אבל דורש תחזוקה. אם אתם עובדים על חומר לקוח רגיש, שימו לב גם לשיקולי פרטיות: העלאת dataset ל-notebook חיצוני אינה תמיד מתאימה.

לפני כל run, בצעו בדיקת runtime אמיתית. ב-Colab או Kaggle, תא פשוט עם !nvidia-smi יראה לכם סוג GPU ו-VRAM. אם אתם לא מקבלים GPU, אל תריצו את שאר ה-notebook בתקווה שזה יסתדר. עצרו. החליפו runtime, עברו ל-Kaggle, או דחו את ה-run. זה נשמע בסיסי, אבל הרבה beginners מבזבזים session על הורדת מודל ל-CPU בלי לשים לב.

יש גם החלטת פרטיות. Dataset של פוסטים ציבוריים, דוגמאות מוצר או טון מותג כללי אפשר בדרך כלל להעלות ל-notebook חיצוני, בכפוף למדיניות שלכם. Dataset של לקוחות, מידע רפואי, משפטי, פיננסי או פרטים אישיים לא מעלים בקלות ל-Colab או Kaggle רק כי זה חינם. במקרה כזה local או סביבת cloud מבוקרת יהיו נכונים יותר, גם אם הם עולים כסף. חינם אינו חינם אם הוא מכניס אתכם לסיכון משפטי או מסחרי.

לגבי Kaggle, חשבו על המכסה השבועית כמו תקציב. אם יש לכם 30 שעות GPU בשבוע, אל תשרפו 8 שעות על ניסוי שלא תיעדתם. עצרו sessions לא פעילים, שמרו notebooks, והשתמשו ב-checkpoints בפרקים המעשיים. לגבי Colab, אל תבנו תהליך שמחייב 12 שעות רצופות רק כי זה כתוב ב-FAQ. runtime יכול להסתיים קודם. תכננו runs קצרים, checkpoints, ובדיקות smoke test לפני run ארוך. המטרה היא לא להוכיח שהסביבה חזקה; המטרה היא להוציא תוצאה שניתן לשחזר.

במחשב מקומי, בדקו קודם inference, אחר כך training קטן. אם Ollama מריץ מודל, זה לא אומר שסביבת Python מוכנה לאימון. CUDA, PyTorch, גרסת driver, ויכולת להריץ kernels של Unsloth הם דברים שונים. למתחילים, לעיתים עדיף להתחיל ב-Colab או Kaggle כדי ללמוד את התהליך, ורק אחר כך להעביר local. אם אתם כבר מנוסים בהתקנות GPU, local יכול להיות נפלא. אם לא, אל תיתנו להתקנה להפוך לתחליף ללמידת fine-tuning.

בכל סביבת ריצה, הגדירו מראש מהו "כשל רך" ומהו "כשל קשה". כשל רך הוא למשל GPU לא זמין היום, אז עוברים ל-runtime אחר או מקטינים מודל. כשל קשה הוא למשל dataset רגיש שלא מותר להעלות, או מודל שדורש יותר VRAM ממה שיש לכם גם אחרי הקטנה. ההבחנה הזו מונעת בזבוז זמן. לא כל בעיה צריכה פתרון טכני; לפעמים התשובה היא לשנות מסלול.

לפרויקט ראשון, אני מעדיף runtime שמוריד חיכוך גם אם הוא חלש יותר. אם Colab פועל ונותן T4, התחילו שם עם 2B או 4B. אם Colab מתעקש על CPU, אל תילחמו בו שעה. עברו ל-Kaggle. אם Kaggle לא זמין או שאתם עובדים עם data רגיש, שקלו local או המתינו. המשמעת היא לא להכריח את הסביבה להתאים לפנטזיה, אלא להתאים את הניסוי לסביבה שקיימת עכשיו.

מחשבון לפני אימון: החלטה ב-6 שורות

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

שש השורות הן: base model, runtime, method, rank/alpha, dataset size, success test. דוגמה: base model הוא Qwen 2B instruct; runtime הוא Kaggle או Colab T4; method הוא QLoRA; rank הוא r=8 alpha=16; dataset size הוא 600 דוגמאות brand voice; success test הוא 20 prompts held-out עם דירוג טון ו-validation של אורך. עכשיו יש לנו ניסוי. לא חלום. ניסוי.

לכרטיס יש גם תפקיד רגשי. Fine-tuning מושך אותנו לשחק עם settings כי זה מרגיש כמו שליטה. בפועל, settings בלי החלטת מוצר הם רעש. כרטיס pre-flight מזכיר לכם למה אתם מאמנים, מה מגבלת החומרה, ומה ייחשב הצלחה. בפרק 4, כשה-notebook יציג עשרה פרמטרים, תחזרו לכרטיס הזה ותדעו מה לא לגעת בו עדיין.

הנה דוגמה מלאה: base model הוא Llama 3.2 3B Instruct; runtime הוא Kaggle כי רוצים מכסת GPU יציבה; method הוא QLoRA כי אין סיבה לאימון מלא; rank הוא r=8 alpha=16 כי המשימה היא brand voice; dataset size מתוכנן הוא 600 זוגות קצרים; success test הוא 20 prompts שבהם לפחות 16 מקבלים דירוג טון 4 ומעלה, בלי חריגה מ-120 מילים. זו החלטה טובה גם אם המודל אינו הכי גדול. היא טובה כי אפשר להריץ אותה, למדוד אותה, ולשפר אותה.

דוגמה שנייה: base model הוא Qwen Coder 7B Instruct; runtime הוא Kaggle או Colab לפי GPU זמין; method הוא QLoRA; rank הוא r=16 alpha=32 כי המשימה היא יצירת snippets לפי סגנון repository; dataset size הוא 1,000 דוגמאות code review; success test הוא 20 prompts שבהם הקוד עובר lint בסיסי ושומר על naming convention. כאן הסיכון גבוה יותר כי קוד נשבר בקלות. לכן לא מסתפקים במדד "נראה טוב". מכניסים בדיקה מכנית.

דוגמה שלישית, שבה כדאי להיזהר: base model 13B, runtime T4 יחיד, rank r=64, dataset של 120 דוגמאות, success test לא מוגדר. הכרטיס הזה אומר לעצור. לא כי אף חלק בו בלתי אפשרי לבד, אלא כי הצירוף מסוכן: מודל צמוד לזיכרון, rank גבוה, data קטן, ואין מדידה. אם תפתחו notebook במצב הזה, כל כשל ייראה כמו בעיית קוד, למרות שהכשל נכתב בכרטיס עוד לפני שהתחלתם.

הכרטיס צריך לכלול גם owner של ההחלטה, גם אם אתם עובדים לבד. כתבו "אני לא משנה model size בלי לעדכן את טבלת VRAM" או "אני לא מעלה rank לפני בדיקת held-out". זה נשמע קצת טקסי, אבל זה יוצר חוזה עם עצמכם. כשה-run הראשון לא מושלם, והראש רוצה ללחוץ על כל הכפתורים, החוזה הזה שומר עליכם. לא בגלל שהוא קשיח, אלא בגלל שהוא מזכיר שכל שינוי צריך סיבה.

אם אתם מתכננים להשתמש ב-Claude או במודל אחר כדי לעזור לכתוב configs, תנו לו את הכרטיס. אל תבקשו "תן לי הגדרות LoRA טובות". בקשו: "בהינתן base model זה, runtime זה, rank זה, dataset בגודל זה, ומדד הצלחה זה, הצע קונפיג שמרני". איכות התשובה תהיה טובה בהרבה, ואתם תישארו בעלי ההחלטה. AI יכול לעזור להמיר החלטה לקוד, אבל הוא לא אמור להחליף את החלטת הניסוי.

שגרת עבודה: איך לא לבזבז sessions חינמיים

בפרק 1 השגרה שלכם הייתה לקבל החלטה לפני שמכריזים על fine-tuning. בפרק הזה מוסיפים שגרת חומרה וניסוי. היא קטנה, אבל היא מונעת את רוב הכשלים המבאסים: GPU לא זמין, מודל גדול מדי, rank מנופח, או אימון שאין לו מדד הצלחה.

השגרה הזו צריכה להיות קצרה מספיק כדי שתשתמשו בה באמת. אל תבנו spreadsheet מפואר עם עשרים עמודות אם בסוף לא תמלאו אותו. מספיק יומן ניסוי פשוט: תאריך, מודל, runtime, method, rank, dataset, תוצאה, הערה אחת. אחרי שלושה runs, היומן הזה שווה זהב. הוא יראה לכם האם שיפור הגיע מ-data נקי יותר, rank אחר, או רק ממזל בדוגמה אחת.

בנוסף לשגרה מפרק 1, שבה אתם שואלים אם fine-tuning הוא בכלל הכלי הנכון, כאן אתם מוסיפים שאלת pre-flight: האם הניסוי הבא קטן מספיק כדי להסתיים וגדול מספיק כדי ללמד. אם התשובה לא, משנים את הניסוי. זה נשמע כמו ניהול פרויקט, וזה בדיוק מה שזה. Fine-tuning מוצלח הוא לא קסם מודלים; הוא סדרה של ניסויים קטנים שמצטברים למודל שימושי.

בדיקה עצמית, סיכום וצ'קליסט