ืืื ื ืืืืืืชืืช
ืืืคืืืืืืฆืื ืฉื ืืืืขืช LLM: vLLM PagedAttention ืืขืชืื ืืฉืืจืืช ืืืขืื ืฉื AI
מודלי שפה גדולים (LLM) המופעלים ביישומים בעולם האמיתי מציגים אתגרים ייחודיים, במונחים של משאבים חישוביים, עיכוב ויעילות עלות. במדריך המקיף הזה, נחקור את נוף השירות של LLM, עם דגש מיוחד על vLLM (מודל שפה וקטורי), פתרון שמשנה את הדרך בה אנו מפעילים ומתקשרים עם מודלים אלה החזקים.
אתגרים בשירות מודלי שפה גדולים
לפני שנצלול לתוך פתרונות ספציפיים, בואו נבחן את האתגרים המרכזיים שהופכים את שירות LLM למשימה מורכבת:
משאבים חישוביים
LLM מפורסמים במספר עצום של פרמטרים, החל ממיליארדים ועד מאות מיליארדים. לדוגמה, GPT-3 בולט ב-175 מיליארד פרמטרים, בעוד מודלים עדכניים יותר כמו GPT-4 מוערכים כבעלי עוד יותר. גודל זה מתרגם לדרישות חישוביות משמעותיות להסקה.
דוגמה:
בואו ניקח LLM יחסית מודסטי עם 13 מיליארד פרמטרים, כמו LLaMA-13B. אפילו מודל זה דורש:
– כ-26 GB זיכרון רק כדי לאחסן את פרמטרי המודל (בהנחה 16-ביט דיוק)
– זיכרון נוסף להפעלות, מנגנוני קשב וחישובים ביניימיים
– כוח חישוב GPU משמעותי להסקה בזמן אמת
עיכוב
ביישומים רבים, כמו בוטים לצ’אט או ייצור תוכן בזמן אמת, עיכוב נמוך הוא קריטי לחווית משתמש טובה. עם זאת, המורכבות של LLM יכולה להוביל לזמני עיבוד משמעותיים, במיוחד עבור רצפים ארוכים יותר.
דוגמה:
נדמיין בוט תמיכת לקוחות המופעל על ידי LLM. אם כל תגובה לוקחת מספר שניות ליצור, השיחה תרגיש לא טבעית ומרגיזה עבור משתמשים.
עלות
החומרה הנדרשת לרוץ LLM בקנה מידה גדול יכולה להיות יקרה מאוד. GPU או TPU ברמה גבוהה לעיתים קרובות הכרחיים, וצריכת האנרגיה של מערכות אלה משמעותית.
דוגמה:
ריצה של קלאסטר של NVIDIA A100 GPUs (המשמש לעיתים קרובות להסקת LLM) יכולה לעלות אלפי דולרים ליום בתשלומי ענן.
גישות מסורתיות לשירות LLM
לפני שנחקור פתרונות מתקדמים יותר, בואו נסקור בקצרה כמה גישות מסורתיות לשירות LLM:
פריסה פשוטה עם Hugging Face Transformers
ספריית Hugging Face Transformers מספקת דרך ישירה לפריסת LLM, אך היא אינה מותאמת לשירות בעל קצב גבוה.
קוד דוגמה:
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
model_name = "meta-llama/Llama-2-13b-hf"
model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto")
tokenizer = AutoTokenizer.from_pretrained(model_name)
def generate_text(prompt, max_length=100):
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_length=max_length)
return tokenizer.decode(outputs[0], skip_special_tokens=True)
print(generate_text("The future of AI is"))
גישה זו עובדת, אך היא אינה מתאימה ליישומים בעלי תנועה גבוהה עקב השימוש הלא יעיל במשאבים וחוסר אופטימיזציה לשירות.
שימוש ב-TorchServe או פריימוורקים דומים
פריימוורקים כמו TorchServe מספקים יכולות שירות עמידות יותר, כולל ניהול עומס וגרסאות מודל. עם זאת, הם עדיין לא פותרים את האתגרים הספציפיים של שירות LLM, כמו ניהול זיכרון יעיל עבור מודלים גדולים.
הבנת ניהול זיכרון בשירות LLM
ניהול זיכרון יעיל הוא קריטי עבור שירות מודלי שפה גדולים (LLM) בגלל המשאבים החישוביים הנרחבים הנדרשים. התמונות הבאות מאיירות אספקטים שונים של ניהול זיכרון, החיוניים לאופטימיזציה של ביצועי LLM.
זיכרון מפורק לעומת זיכרון מדופד
שתי התמונות האלה משוות בין טכניקות ניהול זיכרון מפורק ומדופד, הנפוצות במערכות הפעלה (OS).
- זיכרון מפורק: טכניקה זו מחלקת את הזיכרון למקטעים שונים, כל אחד מהם מתאים לתוכנית או תהליך שונה. לדוגמה, בהקשר של שירות LLM, מקטעים שונים עשויים להיות משויכים לרכיבים שונים של המודל, כמו טוקניזציה, אינטרפולציה ומנגנוני קשב. כל מקטע יכול לגדול או לקטין באופן עצמאי, מה שמספק גמישות אך עלול להוביל לפירוק מידע אם המקטעים לא נמנות כראוי.
- זיכרון מדופד: כאן, הזיכרון מחולק לדפים בגודל קבוע, הממופים על זיכרון פיזי. דפים יכולים להיחלף כפי הצורך, מה שמאפשר שימוש יעיל במשאבי זיכרון. בשירות LLM, זה יכול להיות קריטי עבור ניהול כמויות גדולות של זיכרון הדרושות לאחסון משקלי המודל וחישובים ביניימיים.
ניהול זיכרון ב-OS לעומת vLLM
תמונה זו מנגדת את ניהול הזיכרון המסורתי ב-OS עם גישת ניהול הזיכרון המשמשת ב-vLLM.
- ניהול זיכרון ב-OS: במערכות הפעלה מסורתיות, תהליכים (למשל, תהליך A ותהליך B) מ
