Команда стартапу з трьох осіб розгорнула Llama-3-70B на одиночному A100 80GB — і модель падала з CUDA OOM при кожному другому запиті. Проблема була не в GPU, а в конфігурації: vLLM виділив 0.95 GPU-пам'яті під KV-cache, не залишивши запасу на варіації довжини контексту. Ми переключили gpu-memory-utilization на 0.85 і ввімкнули swapping через CPU — падіння припинилися. Такі ситуації — наша щоденна робота. За останні роки ми розгорнули понад 30 production-систем інференсу Large language model на виділених GPU-серверах (on-premise або bare metal) та гарантуємо стабільну роботу навіть при пікових навантаженнях.
Виділений сервер дає передбачувану продуктивність, відсутність cold start і повний контроль над даними. Це оптимальний вибір для високонавантажених сценаріїв з вимогами до data residency або кастомних pipelines.
Проблеми, які ми вирішуємо
Помилка в розрахунку VRAM. Наприклад, Llama-3-70B у BF16 потребує 140 GB — не кожен сервер потягне. Ми використовуємо quantization (AWQ/GPTQ) і tensor parallelism, щоб оптимально утилізувати ресурси. Mixtral-8x7B (MoE) активує лише 13B параметрів, але потребує 90 GB VRAM — легко вміщується на 2×A100 80GB після 4-бітного квантування.
Падіння сервісу при OOM. На довгих контекстах (>16k токенів) vLLM може вилетіти. Рішення — налаштування max-model-len і gpu-memory-utilization в парі з systemd-сервісом, який автоматично перезапускає процес при збої. Додатково ставимо watchdog-скрипт, що перевіряє health-ендпоінт.
Простий при оновленні моделі. Без blue-green деплою кожне оновлення — downtime. Ми запускаємо нову версію на іншому порту, тестуємо, потім перемикаємо nginx upstream — downtime відсутній.
Як вибрати GPU під вашу модель?
Вибір GPU залежить від розміру моделі та необхідного latency. Ось таблиця рекомендацій для популярних моделей:
| Модель | BF16 VRAM | 4-bit VRAM | Рекомендовані GPU |
|---|---|---|---|
| 7B | 16 GB | 6-8 GB | RTX 4080, A10G, L4 |
| 13B | 28 GB | 8-10 GB | A30, RTX 4090 (INT8) |
| 70B | 140 GB | 40 GB | 2×A100 80GB, 4×A40 48GB |
| Mixtral 8x7B | 90 GB | 30 GB | 2×A100 80GB |
Квантування в INT4/INT8 знижує вимоги до VRAM в 3-4 рази, що дозволяє вмістити 70B модель на 2×A100.
Чому vLLM частіше обирають для production?
vLLM використовує PagedAttention — ефективне управління KV-cache, що дає на 20-50% вищий throughput при малих batch розмірах. На нашому бенчмарку Llama-3-8B з AWQ-квантуванням: vLLM видав 1200 токенів/сек проти 800 у TGI (batch=32). Однак TGI краще справляється з довгим контекстом (≥32k токенів) за рахунок більш агресивного tensor parallelism.
| Характеристика | vLLM | TGI |
|---|---|---|
| Throughput (batch=32) | 1200 tok/s | 800 tok/s |
| Підтримка довгого контексту | Добра | Відмінна |
| Streaming responses | Так | Так |
| Tensor parallelism | Так | Так, більш агресивний |
Якщо ваш сценарій — онлайн-чат з короткими запитами, обирайте vLLM. Якщо потрібно обробляти багатосторінкові документи — TGI.
Що робити при OOM?
При OOM насамперед перевірте gpu-memory-utilization — часто він встановлений занадто високо. Рекомендоване значення — 0.85-0.90, решта під CPU swap. Також налаштуйте max-model-len пропорційно середній довжині контексту. В systemd додайте Restart=always і скрипт health-перевірки — сервіс перезапуститься автоматично.
Процес розгортання та оновлення
Етапи
- Аналітика — оцінка моделі, очікуваного RPS та latency SLA. Підбір GPU та квантування.
- Проектування — конфігурація tensor parallel, batch size, quantization, вибір фреймворку.
- Реалізація — встановлення CUDA, драйверів, деплой vLLM/TGI як systemd-сервісу з watchdog.
- Тестування — навантажувальне тестування (locust/vegeta), замір p99 latency, перевірка на long-tail.
- Деплой — nginx reverse proxy з rate limiting, SSL, моніторинг Prometheus + Grafana.
- Документація — опис ендпоінтів, конфігів, процедури оновлення.
Оновлення без downtime
Класичний blue-green: запускаємо нову версію на порту 8001, тестуємо її, перемикаємо nginx upstream з порту 8000 на 8001, потім зупиняємо старий сервіс. Весь процес займає ~30 секунд, при правильному налаштуванні keepalive користувачі не помічають перемикання.
Що входить в роботу
- Підбір GPU та конфігурація сервера.
- Встановлення CUDA, драйверів (якщо потрібно — Docker).
- Деплой vLLM/TGI з systemd + watchdog.
- Nginx reverse proxy з rate limiting та SSL.
- Моніторинг (Prometheus + Grafana — дашборди GPU, latency, throughput).
- Оновлення моделі без downtime.
- Документація та навчання команди.
- Підтримка 30 днів після здачі.
Терміни: від 2 до 7 днів залежно від складності (наявність GPU, кількість моделей, HA). Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту, це займе 1 робочий день.
Налаштування сервера та інфраструктура
Конфігурація сервера
Перед початком перевірте наявність GPU та версію драйверів:
nvidia-smi nvcc --version Встановіть CUDA 12.1 та cuDNN. На Ubuntu 22.04:
apt-get install -y nvidia-driver-545 apt-get install -y cuda-toolkit-12-1 Перевірте PyTorch: python3 -c "import torch; print(torch.cuda.get_device_name(0))"
Деплой vLLM як systemd-сервісу
# /etc/systemd/system/vllm-llama.service [Unit] Description=vLLM LLaMA-3-8B Inference Server After=network.target [Service] Type=simple User=mlserving WorkingDirectory=/opt/vllm Environment="CUDA_VISIBLE_DEVICES=0,1" Environment="HF_TOKEN=hf_xxx" ExecStart=/opt/vllm/venv/bin/python -m vllm.entrypoints.openai.api_server \ --model /data/models/llama-3-8b-instruct \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --max-num-seqs 128 \ --gpu-memory-utilization 0.92 \ --host 127.0.0.1 \ --port 8000 \ --log-level info Restart=always RestartSec=5 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target Nginx reverse proxy
# /etc/nginx/sites-available/vllm upstream vllm_backend { server 127.0.0.1:8000; keepalive 100; } limit_req_zone $binary_remote_addr zone=api_limit:10m rate=60r/m; server { listen 443 ssl http2; server_name llm.company.internal; ssl_certificate /etc/nginx/ssl/cert.pem; ssl_certificate_key /etc/nginx/ssl/key.pem; location /v1/ { limit_req zone=api_limit burst=20 nodelay; proxy_pass http://vllm_backend; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_read_timeout 300s; proxy_buffering off; chunked_transfer_encoding on; } location /health { proxy_pass http://vllm_backend/health; } } Моніторинг та автоматичний перезапуск
Використовуємо Prometheus та Grafana з nvidia_gpu_exporter для відстеження температури GPU, VRAM utilization та throughput. Алерти: температура > 85°C, VRAM > 95%, сервіс недоступний > 30 секунд.
systemd Restart=always + watchdog скрипт, що перевіряє health-ендпоінт кожні 30 секунд. При трьох невдалих спробах — рестарт сервісу.
#!/bin/bash while true; do if ! curl -sf http://127.0.0.1:8000/health > /dev/null; then systemctl restart vllm-llama echo "$(date) - vLLM restarted" >> /var/log/vllm-watchdog.log fi sleep 30 done Технічні деталі конфігурації
Ми використовуємо AWQ-квантування для 4-бітного представлення ваг. Це дає зниження VRAM на 75% при мінімальній втраті точності (менше 1% на бенчмарках). Для моделей з MoE-архітектурою (Mixtral) tensor parallelism обов'язковий — без нього половина параметрів не вміщується в VRAM. Рекомендуємо --tensor-parallel-size рівний числу GPU.
Досвід наших інженерів — понад 5 років у ML/infra, понад 30 розгорнутих інференс-систем. Ми супроводжуємо кожен проєкт гарантією на конфігурацію та підтримкою після деплою. Якщо потрібна інтеграція з RAG-пайплайном, fine-tuning або MLOps-CI/CD — обговоримо на консультації. Отримайте попередню оцінку вашого проєкту — зв'яжіться з нами, відповімо протягом дня.