המרת מודל לפורמט GGUF עבור llama.cpp

המרת מודל ל-GGUF: היכן נשבר הייצוא

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

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

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

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

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

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

מה נותנת בנייה מוכנה: מהירות וצפיות

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

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

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

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

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

תאימות עם llama.cpp נבדקת על ענף ריצה עדכני — אם הקובץ נקרא ומפיק את אותן התשובות בסט בקרה, הבנייה מוכנה למסירה.

מצבי דיוק ואפשרויות אספקת משקלים

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

איך בוחרים מצב דיוק

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

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

סדר העבודה: ממלאי משקלים ועד קבלה

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

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

2. סכמת בניית המודל. מתארים את ה-GGUF העתידי: מילון, תבנית דיאלוג, מטא-נתונים, התאמת שמות טנסורים. שגיאה בתבנית הצ'אט נראית אחר כך כמו «המודל עונה בפורמט לא נכון» — על הסכמה היא עולה פחות.

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

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

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

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

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

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

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

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

איך זה נראה בפועל: תוצאות לפני ואחרי

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

לכל מהדורה מהנדס הרכיב ידנית משקלים ומילון, השווה הגדרות ותיקן שדות שירות — ההרצה ארכה בין 40 ל-60 דקות ו-5–7 תיקונים ידניים, וחלק מהמהדורות נפלו כבר אחרי ההתחלה, כשהמודל לכאורה עלה.

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

מה קרה במספרים: הכנת המהדורה התקצרה מ-40–60 דקות ל-5–8, תיקונים ידניים — מ-5–7 לאפס. הסרנו סוג שלם של כשלים — חוסר סנכרון בין המילון למשקלים, כשהמודל עולה אבל מפיק טקסט לא קוהרנטי. עכשיו אי-התאמה כזו נתפסת בשלב הבדיקה, ולא בצד המשתמש.

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

במה GGUF שונה מפנייה למודל ברשת?

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

הרצה מקומית של משקלים שהומרו ל-GGUF מסירה את שני המרכיבים הראשונים: השהיית התגובה מפסיקה להיות תלויה בעומס זר ונשארת יציבה גם בשיא.

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

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

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

ספקות טכניים שאנחנו מסירים לפני ההתחלה

חלק מהשאלות עולות עוד לפני ההתחלה — בדרך כלל הן על איך המודל יתנהג אחרי המרה ל-GGUF ומה יקרה לו בעדכון המשקלים הבא. להלן תשובות קצרות לשאלות הנפוצות ביותר בפרויקטים על llama.cpp. כל תרחיש אנחנו מפרטים מראש ומקבעים בתכנית העבודה, כדי לא לברר אותו בשלב ההרצה.

משקלים מגיעים בעשרה קבצים — זו בעיה?

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

הדחיסה לא תפגע באיכות התשובות?

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

היקף סגור בלי גישה לרשת — זה יעבוד?

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

נדון במשימה ונחזור עם הערכה ותכנית

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

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

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

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