vLLM מעבירה פענוח וידאו ל-NVDEC ומכפילה תפוקה ב-8×H100

ספריית ההסקה vLLM הטמיעה את PyNvVideoCodec והעבירה את פענוח הווידאו מה-CPU ל-NVDEC, מפענח החומרה של NVIDIA, וכך הסירה צוואר בקבוק שהגביל סקיילינג של משימות כיתוב וידאו (video captioning) על צמתים מרובי-GPU. התוצאה: יותר מכפול תפוקה בקונפיגורציה של 8×H100, והפונקציונליות כבר כלולה בגרסאות CUDA הרגילות של vLLM.

הבעיה: CPU נחנק עוד לפני שהמודל מתחיל לעבוד

עד עכשיו vLLM השתמשה בבקאנד CPU מבוסס OpenCV ו-FFMPEG. במודלי שפה-ראייה (VLM) שמייצרים פלט קצר יחסית, 100 עד 200 טוקנים לכיתוב, חלקו של הפענוח בזמן הכולל גדול במיוחד. על צמתים עם 2 עד 4 כרטיסים ה-CPU כבר הגיע לרוויה מלאה, וכל GPU נוסף רק החמיר את המצב. עבור ארגונים שמריצים מאות אלפי שעות וידאו לאימון רכב אוטונומי, זה היה חסם קשה.

הפתרון: PyNvVideoCodec מממשק את NVDEC ישירות

PyNvVideoCodec היא עטיפת פייתון למפענחי החומרה של NVIDIA. השילוב ב-vLLM מאפשר להעביר את עומס הפענוח מה-CPU ל-NVDEC, וכך לשחרר ליבות עיבוד לאינפרנס עצמו. בגרסאות CUDA הסטנדרטיות של vLLM הספרייה כבר בפנים (PyNvVideoCodec==2.0.4); בהתקנות קאסטום צריך להוסיף אותה ידנית כ-dependency.

סקיילינג אמיתי: מ-2× ועד 8×H100 בלי להזיע

בבדיקות של NVIDIA על משימות כיתוב לרכב אוטונומי, המעבר לפענוח GPU הניב יותר מכפול תפוקה ב-8×H100 לעומת הבקאנד הישן. הגרף מראה קו ישר כמעט עד 8 רפליקות, כל אחת על GPU בודד, בעוד הגרסה מבוססת ה-CPU משתטחת כבר ב-2 עד 4 כרטיסים. עבור צוותי AV שמתמודדים עם מאות מיליוני קליפים, זה הבדל של ימי עיבוד שלמים.

בפרודקשן: MPS, הקצאת VRAM וקונטיינרים בודדים

כדי לממש את הביצועים צריך להרים את CUDA MPS Daemon לפני `vllm serve`, חובה לעומסי אינפרנס מרובי-תהליכים. הפרמטר `--mm-ipc-gpu-memory-gb` שומר VRAM לפענוח; ההמלצה היא לבדוק ערכים שונים ולשמור את המינימום שלא פוגע בתפוקה. הארכיטקטורה המומלצת: קונטיינר נפרד לכל רפליקת vLLM עם GPU יחיד (דרך `CUDA_VISIBLE_DEVICES`), ו-reverse proxy שמפזר את הבקשות.