‏کانکتور push در vLLM: انتقال KV cache سریع‌تر بین prefill و decode

تو اجرای مدل‌های زبانی دو تا مرحله داریم: prefill که پرامپت ورودی رو پردازش می‌کنه و KV cache (یعنی حافظهٔ میانی‌ای که مدل برای تولید توکن‌های بعدی لازم داره) رو می‌سازه، و decode که با همون کش توکن‌ها رو یکی‌یکی تولید می‌کنه. vLLM می‌تونه این دو تا رو روی سرورهای جدا اجرا کنه (P-D disaggregation) تا هرکدوم جدا مقیاس بگیرن. ولی بعدش باید KV cache از سرور prefill به decode منتقل بشه و سرعت این انتقال مستقیم روی TTFT (زمان رسیدن اولین توکن) اثر می‌ذاره.

یکی از راه‌های این انتقال، کانکتور NIXL انویدیاست که بلوک‌های KV رو با RDMA (یعنی کپی مستقیم بین حافظهٔ دو ماشین بدون درگیر کردن CPU) روی شبکه‌هایی مثل AWS EFA جابه‌جا می‌کنه. حالت پیش‌فرضش pull هست: بعد از تموم شدن prefill، روتر اطلاعات بلوک‌ها رو به decode می‌ده، decode بلوک مقصد رزرو می‌کنه، انتقال رو آماده می‌کنه و بعد خودش داده رو می‌خونه. همهٔ این مراحل پشت سر هم و بعد از prefill انجام می‌شن، پس مستقیم به TTFT اضافه می‌شن.

کانکتور جدید push این ترتیب رو عوض می‌کنه. سرور decode همون موقع که بلوک‌هاش رو رزرو می‌کنه، آدرسشون رو برای prefill می‌فرسته، یعنی قبل از اینکه prefill تموم بشه. سمت prefill این ثبت‌نام و پایان prefill می‌تونن با هر ترتیبی برسن و هرکدوم که دیرتر برسه، انتقال رو شروع می‌کنه. بعد prefill با یه NIXL WRITE داده رو مستقیم تو حافظهٔ decode می‌نویسه. decode هم صبر می‌کنه تا از همهٔ rankهای prefill پیام تکمیل بگیره و بعد شروع به تولید توکن می‌کنه.

یه بخش مهم دیگه، thread پس‌زمینه‌ست. آماده کردن descriptorها، ادغام بلوک‌های پشت سر هم و ارسال WRITE روی یه thread جدا تو سمت prefill انجام می‌شه. پس نه حلقهٔ اصلی prefill معطل می‌شه، نه decode که حساس‌ترین بخش به تأخیره. نویسنده‌ها توضیح می‌دن که تو حالت pull این کارها داخل حلقهٔ موتور decode انجام می‌شه و همین تولید توکن رو متوقف می‌کنه.

تست روی Qwen3-32B با یه سرور prefill و یه سرور decode از نوع EC2 P5en (هشت H200) انجام شده و prefix caching خاموش بوده تا هر درخواست واقعاً کل KV رو منتقل کنه. تو بار کم و پرامپت کوتاه دو حالت تقریباً یکی‌ان. ولی تو ۸ QPS و ورودی ۱۶ هزار توکنی، TTFT حالت pull به حدود ۱۷۴۴ میلی‌ثانیه می‌رسه و push حدود ۵۴۰ میلی‌ثانیه می‌مونه. TPOT (تأخیر هر توکن خروجی) هم تو pull تا حدود ۱۰.۴ میلی‌ثانیه بالا می‌ره و push نزدیک ۷ می‌مونه. این قابلیت اول روی Trainium ساخته شده و بعد مستقل از سخت‌افزار به vLLM اضافه شده.

یه بده‌بستون هم هست. تو pull روتر می‌تونه بعد از prefill تصمیم بگیره درخواست بره سراغ کدوم سرور decode، که برای load balancing انعطاف بیشتری داره. push باید سرور decode رو زودتر انتخاب کنه. به گفتهٔ نویسنده‌ها، push برای وقتیه که TTFT کمتر اولویته و انتخاب زودهنگام مشکلی نداره، و pull برای انتقال دوطرفهٔ KV یا routing وابسته به بار بهتره. برای فعال کردنش کافیه رو هر دو سرور به‌جای NixlConnector از NixlPushConnector استفاده کنی.

نکات کلیدی:

• کانکتور NixlPushConnector آماده‌سازی انتقال KV رو با prefill هم‌زمان می‌کنه
• تو ۸ QPS و ورودی ۱۶k، TTFT از حدود ۱۷۴۴ به ۵۴۰ میلی‌ثانیه رسیده
• TPOT زیر بار سنگین حدود ۷ میلی‌ثانیه مونده در برابر ۱۰.۴ تو pull
• تست با Qwen3-32B روی دو نود p5en.48xlarge و شبکهٔ EFA
• بده‌بستون: push باید سرور decode رو قبل از prefill انتخاب کنه
• تو PR شمارهٔ ۴۵۲۱۱ دارن بررسی می‌کنن که همین thread پس‌زمینه رو به حالت pull هم بیارن