אינפרנס LLM במחשוב קצה: קוונטיזציה ופריסה על Raspberry Pi ו-Jetson

פריסת LLM על התקני קצה: היכן האינפרנס נשבר

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

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

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

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

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

מה נותן אינפרנס מקומי: השהיה, אוטונומיה, פרטיות

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

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

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

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

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

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

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

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

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

להלן ארבעה מצבים שאמיתית בוחרים ביניהם בעת פריסת LLM בפריפריה: מפלטפורמות של לוח בודד כמו Raspberry Pi ו-Jetson ועד מודולים תעשייתיים. ההשוואה מבוססת על מגבלות, לא על הבטחות.

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

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

סדר העבודות זהה עבור Raspberry Pi ו-Jetson — משתנה רק עומק האופטימיזציה עבור המאיץ ביעד. מתחילים בביקורת המודל ומסיימים במסירה לתפעול: בכל שלב נשאר ארטיפקט שאפשר לבדוק.

1. ביקורת המודל. מחשבים פרופיל: אורך ההקשר, התפלגות המשקלים לפי שכבות, רגישות הבלוקים להורדת דיוק. בפלט — החלטה מה מעבירים לפורמט 8 סיביות ומה משאירים בדיוק מלא.
2. סכימת פריסה. מקבעים היכן נשמרים המשקלים, מי יוזם את האינפרנס, כיצד ההתקן מקבל עדכונים ומה הוא מוסר בעת אובדן קשר עם השרת.
3. בניית דימוי ההתקן. בונים דימוי עם תלויות מקובעות והמודל בפנים — הפריסה יוצאת מארטיפקט אחד, באופן משוחזר וללא שלבים ידניים במקום.
4. הגדרת מצב האינפרנס. מתאימים את גודל האצווה, מספר התהליכונים ופריסת השכבות בין המאיץ ל-CPU, כדי לעמוד בדרישת זמן התגובה בלי התחממות יתר של המארז.
5. מדידות. מודדים זמן עד לתשובה הראשונה ועבור כל טוקן עוקב, צריכת זיכרון וטמפרטורה תחת עומס ממושך — על פרופיל פניות הקרוב לעבודה, ולא על נתונים סינתטיים.
6. בדיקה על נתונים אמיתיים. מריצים מערך בקרה ומשווים איכות לפני ואחרי קוונטיזציה לפי מדדי המשימה, ולא רק לפי התאמת מחרוזות לעוגן.
7. מסירה לתפעול. תצורות, סכימת עדכון, נוהל חזרה לדימוי הקודם והוראות ברורות למשמרת התורנית.

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

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

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

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

מקרה בוחן: אינפרנס מקומי על קו ייצור

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

מה שינו

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

מה השתנה

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

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

במה שונה קוונטיזציה במהלך האימון מקוונטיזציה לאחר האימון

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

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

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

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

שאלות נפוצות: זיכרון, דיוק, עדכוני מודלים

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

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

איך נמדדת הדעיכה בדיוק לאחר קוונטיזציה?

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

איך לעדכן את צי ההתקנים ולחזור לגרסה קודמת?

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

מה כלול בתמיכה לאחר ההפעלה?

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

נדון במשימה: נתאים מצב ונבנה תוכנית יישום

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

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

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

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