dockerhubber4ustudio/vllm-enriched repository overview

⁠Модернізовний докер-образ vLLM

Оновлений, модернізований докер-образ робить vLLM інтеграбельним з DIALX або з іншим proxy, у якого відсутній контроль кількості одночасних запитів до LLM.

⁠Передумови

1. Чи є у vLLM «максимальна черга»?

   • У vLLM немає одного прямого прапорця --max-waiting-requests. Черга накопичується аж поки не використає всю пам'ять GPU. Обмеження спрацьовує після задовільнення двох наступних чинників, що вказані першими нижче:
     • --max-num-seqs: Це «жорсткий» ліміт на кількість запитів, які обробляються одночасно (Nrunning). Якщо ти поставиш 32, то 33-й запит не почне генеруватися, поки один із 32 не закінчиться.
     • --gpu-memory-utilization: Це обмежувач пам'яті для KV-кешу. Якщо пам'ять закінчилася, vLLM не може взяти новий запит навіть у чергу «очікування», якщо розуміє, що для нього не вистачить місця в пам'яті.
     • MAX_CONCURRENT_REQUESTS: це ENV параметр, який ми мусимо додати, бо DIALX не має налаштувань обмеження кількості паралельних запитів!

2. Чи достатньо тільки --gpu-memory-utilization, щоб не формувалась черга з багатохвилинним очікуванням?

   • Ні, недостатньо. І ось чому: Цей параметр лише каже vLLM: «Забери під кеш 90% пам'яті GPU». Але vLLM — дуже розумна штука. Вона може «напхати» в ці 90% пам'яті дуже багато коротких запитів або мало довгих. Якщо ти не обмежиш чергу, то отримаєш ситуацію:
     • Сервер прийняв 500 запитів. Пам'яті вистачає лише на 50. Решта 450 висять у черзі Waiting. Користувач чекає 2 хвилини, бачить «білий екран», і DIALX обриває з'єднання по таймауту...
   • Можна намагатися шляхом підбирання обмеження пам'яті GPU вплинути на максимальний час відповіді, але це можна досягти лише коли всі запити мають однаковий час виконання, що на практиці не є досяжним.

⁠Завдяки чому ми розв'язуємо проблему?

Беремо базовий докер-образ vLLM і доповнюємо його новою функціональністю:

• Реалізуємо параметр, який обмежує кількість запитів в черзі vLLM, для контроля повертання "http 503" замість нескінченного очікування.
• Додаємо можливість іменування процесів GPU, у відповідність до назви ШІ моделі: «яка модель зжерла всю пам'ять»?
• В налаштуваннях DIALX тепер можа спокійно зробити fail-over-логіку: моментально перекинути запит до альтернативного ресурсу, коли завантаження поточного досягло межі.

⁠Даний репозиторій містить:

• Dockerfile та файли, які додаються до базового образа vLLM. Один з них - файл конфігурації для мікро-nginx.
• Зразок (docker-compose.yml) запускання контейнера vLLM з використанням стандартних та нових параметрів.
• генератор навантаження load_vllm.py
• Цей readme.

⁠Приклад дій для розгортання та запускання

1. Склонувати репозиторій.
2. Збілдити новий образ:

docker build --tag=dockerhubber4ustudio/vllm-enriched:latest .

1. Запустити з образа контейнер:

docker compose up

1. Запит до моделі, що працює в створеному контейнері. Формат пейлоада - OpenAI:

docker exec -t vllm-llama-1b curl -X POST http://localhost/v1/chat/completions -H "Content-Type: application/json" -d '{
   "model": "Llama-3.2-1B-Instruct", 
   "messages": [
     {
       "role": "user",
       "content": "Яка столиця Франції?"
     }
   ],
   "temperature": 1,
   "max_tokens": 300,
   "stream": false
 }'

1. Те саме можна зробити запитом до localhost, до опублікованого порта

curl -X POST http://localhost:50002/v1/chat/completions -H "Content-Type: application/json" -d '{...}'

1. Те саме можна зробити запитом з іншого контейнера, який так само приєднаний до докер-мережі, що і даний контейнер:

curl -X POST http://vllm-llama-1b/v1/chat/completions -H "Content-Type: application/json" -d '{...}'

⁠Додатково

Як і будь-який образ, даний теж може виконуватися не лише для окремого контейнера за допомогою docker compose/docker run, а і як сервіс Swarm або kubernetes.