Ollama או vLLM: משתמש יחיד חוסך זיכרון, עומס מקביל הופך את הבחירה

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

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

מה קורה ב־Ollama כשהעומס גדל

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

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

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

מתי הזיכרון הופך לשיקול מכריע

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

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

מה vLLM עושה עם בקשות חופפות

היתרון המרכזי של vLLM מתגלה כשיש רצפי יצירה פעילים במקביל. התיעוד של vLLM מפרט batching רציף לבקשות נכנסות, ניהול זיכרון קשב באמצעות PagedAttention, מטמון קידומות, אפשרויות קוונטיזציה ושרת API תואם OpenAI. בתזמון רציף, המנוע יכול לצרף עבודה חדשה בזמן שרצפים אחרים עדיין מתקדמים, במקום לבנות כל מחזור עבודה סביב קבוצת בקשות שחייבת להסתיים יחד.

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

מה מלמדים מספרי העומס — ומה מגביל אותם

במבחן שפרסם SitePoint על NVIDIA RTX 4090 עם Llama 3.1 8B, תצורת Ollama במשקולות Q4_K_M השתמשה בכ־5.2GB של VRAM ללא בקשות פעילות, לעומת כ־16.1GB בתצורת vLLM במשקולות FP16; בעומס של 50 משתמשים מקבילים דווח על תפוקה כוללת של כ־155 לעומת כ־920 אסימונים לשנייה ועל השהיית p99 של 24.7 לעומת 2.8 שניות, בהתאמה. המספרים מתארים את שתי התצורות האלה על החומרה שנבדקה, ולא יתרון מובטח לכל התקנה.

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

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

עד כמה תאימות API מקלה על הבחירה

שני המנועים מציעים דרך להגיש בקשות במבנה המוכר של OpenAI, ולכן יישום שמשתמש ב־Chat Completions יכול לעיתים להחליף כתובת שרת ושם מודל בלי לשכתב את כל שכבת הלקוח. מדריך התאימות המקומית של Ollama מציג את הנתיב ‎/v1/chat/completions ואת השימוש בו דרך לקוח OpenAI. בצד vLLM, שרת תואם OpenAI הוא חלק מיכולות ההגשה המתועדות שלו.

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

סף המעבר הוא תור, זיכרון והשהיית קצה יחד

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

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

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

קראו גם:

• FreshBooks או QuickBooks: משתמש נוסף הופך מחיר נמוך לחשבון יקר
• Docker או Podman: Rootless חוסך הרשאות, לא תמיד זיכרון
• Asana או Trello: לוח פשוט חוסך כסף עד שהפרויקטים מתחילים להצטלב