vLLM מוסיף מנוע דקודינג מתמחה בלי לשבור את הקיים

פרויקט vLLM משיק אינטגרציה רשמית עם TileRT, ראנ־טיים הסקה (inference runtime) שפותח ממוקד במהירות דקודינג פר־יוזר, דרך ממשק המחברים הפתוח של vLLM V1. החבילה מגיעה עם TileRT 0.1.5 ומאפשרת להריץ פריפיל (prefill) ב-vLLM הסטנדרטי ולהעביר את שלב הדקודינג למנוע הייעודי, בלי לגעת בקוד הליבה, בלי פורק (fork) ובלי פאטצ'ים פנימיים. הרעיון פשוט: כשהפריפיל והדקודינג מופרדים ארכיטקטונית, צד הדקודינג נעשה "ניתן להחלפה" (pluggable), וכל עומס עבודה יכול לבחור את המנוע שמתאים לו.

למה צריך מנוע דקודינג שני

הדקודינג המקורי של vLLM נשאר ברירת המחדל הנכונה: הוא בנוי לתפוקה מצרפית (throughput) גבוהה במגוון רחב של מודלים וחומרה. אבל יש סוג עומסים הולך וגדל, לולאות סוכנים (agentic loops), עוזרי קוד אינטראקטיביים, קול בזמן אמת, שבהם המדד הקובע אינו כמה טוקנים המערכת פולטת בסך הכול, אלא כמה מהר כל משתמש מקבל את הטוקן הבא שלו. העומסים האלה חסומי־זמן־תגובה (latency-bound), ו-TileRT תוכנן מהבסיס בדיוק למשטר הזה. שני המנועים יושבים על נקודות שונות באותו גבול תפוקה־זמן־תגובה, ולכן הם משלימים זה את זה במקום להתחרות.

ארכיטקטורה: דו־קיום מתוכנן

העיקרון המוביל הוא אפס שינויים ב-vLLM. האינטגרציה חיה כולה מאחורי משטח ההרחבה הציבורי של V1: מימוש של `KVConnectorBase_V1` שמורכב תחת `MultiConnector` וניטען דרך המנגנון הסטנדרטי `kv_connector_module_path`. מעבר לאסתטיקה הנדסית, זה אומר שהוספת בריכת דקודינג של TileRT לא יכולה לערער פריסה קיימת של vLLM, ושדרוג גרסה לא דורש ניוד (re-port) של פורק. ניתוב (routing) קליל יושב לפני בריכת TileRT: לכל בקשה הוא קובע `max_tokens=1` (כך ש-vLLM עושה פריפיל ופולט טוקן ראשון) ומצרף את צומת היעד בשדה המעבר הסטנדרטי `kv_transfer_params`. תעבורה לבריכה המקורית זורמת דרך פרוקסי הדיסאגרגציה הרגיל, ללא שינוי.

סינון תביעות ומפיק טהור

המחבר של TileRT "תובע" (claims) רק בקשות שנושאות את הסימון הייעודי, ומתנהג כ-no-op מוחלט לכל השאר, כך ששתי בריכות הדקודינג יכולות לחלוק מופע פריפיל יחיד (אפילו באצ'ה קדמית אחת) בלי שהאימוץ של TileRT לחלק מהתעבורה ישפיע על השאר. המחבר פועל כ-`kv_producer` בלבד: הוא מחלץ ומשדר מצב אחרי הפריפיל, ואינו נוגע בתזמון (scheduling) או בדגימה (sampling). במילים אחרות, ה-API התואם-OpenAI, התזמון, מטמון הקידומות (prefix caching), קריאות כלים (tool calling) והבשלות התפעולית של vLLM נשארים בדיוק במקום, רק צינור הדקודינג מוחלף, ורק למי שמבקש את זה.