כאשר NVENC לא עולה: כרטיס מסך מלא במודלים, ורנדר שנופל חזרה
וידאו
רנדר הווידאו שלנו רץ על אותה מכונה כמו מודל השפה שכותב את התסריטים שלו. יום אחד, מקודד החומרה פשוט לא נפתח: "CUDA_ERROR_OUT_OF_MEMORY: out of memory", ואז "No capable devices found".
מה קרה
המכונה היא מחשב שולחני NVIDIA GB10, שה-CPU וה-GPU שלו חולקים מאגר זיכרון אחד. היא משרתת את המודל המקומי שלנו דרך vLLM, ו-Studio מרנדר על אותה מכונה עם ffmpeg, תוך שימוש ב-NVENC כאשר אפשר. במהלך הרצת בדיקה, המקודד נכשל ביצירת הקונטקסט של CUDA. הכשל הגיע וחלף תוך שניות: בדיקת NVENC קצרה עברה, והרנדר מיד אחריה נכשל; בהרצה הבאה, הבדיקה עצמה נכשלה; בהרצה שאחריה, גם הבדיקה וגם הרנדר עברו דרך NVENC.
למה
vLLM שומרת נתח קבוע מזיכרון ה-GPU בעת ההפעלה, עבור המודל והמטמון שלו. NVENC צריכה מעט זיכרון משלה עבור קונטקסט ה-CUDA של כל סשן. כאשר שרת המודלים ומשימות אחרות לא משאירות מקום, המקודד לא יכול להתחיל, למרות שהוא מנוע נפרד על השבב וכמעט לא נוגע בחישובי ה-GPU.
התיקון: להחליט בעת הקידוד, לא בעת הבדיקה
בדיקה בעת ההפעלה אומרת לך ש-NVENC עבדה רגע קודם, לא שהיא תעבוד עבור הקובץ הבא. לכן Studio מנסה NVENC לכל רנדר, ואם ffmpeg נכשל, היא מריצה שוב את אותה תרשים פילטרים עם libx264. הערוץ החי מריץ קידוד בדיקה של חצי שנייה עם ההגדרות החיות לפני כל התחלה, ומשתמש ב-libx264 אם NVENC נכשלת בו; שגיאת NVENC או CUDA במהלך הסטרים מחליפה את ההתחלה הבאה ל-libx264. כל וידאו שהושלם רושם איזה מקודד יצר אותו, כך שנפילה חזרה מופיעה בקובץ המשימה במקום לעבור ללא זיהוי.
מה עולה הנפילה חזרה
פחות ממה שציפינו. על ה-CPU של Arm עם 20 ליבות באותה מכונה, libx264 רנדרה 12 שניות של וידאו 1080p, עם תנועות מצלמה, כתוביות מוטבעות ונרמול עוצמת קול, ב-7.6 שניות. עבור סרטונים קצרים שנוצרים פעם ביום, ה-CPU הוא מקודד טוב דיו. ה-GPU חשובה בהרבה עבור מודל התמונה מאשר עבור הקידוד.
המסקנה
במכונה משותפת, התייחסו למקודד ה-GPU כאופציונלי: השתמשו בו כשהוא זמין, חזרו לאפשרות חלופית כשהוא לא, ותעדו איזו אפשרות שימשתם. אותו דבר חל על כל תכונת GPU הדורשת זיכרון ייעודי במכונה שבה שרת מודלים כבר תפס את רוב הזיכרון. Studio מגיעה עם ההתנהגות הזו פעילה כברירת מחדל.