Розгортання LLM на виділеному GPU-сервері під ключ

Команда стартапу з трьох осіб розгорнула 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. Ось таблиця рекомендацій для популярних моделей:

Квантування в 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.

Що робити при OOM?

При OOM насамперед перевірте gpu-memory-utilization — часто він встановлений занадто високо. Рекомендоване значення — 0.85-0.90, решта під CPU swap. Також налаштуйте max-model-len пропорційно середній довжині контексту. В systemd додайте Restart=always і скрипт health-перевірки — сервіс перезапуститься автоматично.

Процес розгортання та оновлення

Етапи

1. Аналітика — оцінка моделі, очікуваного RPS та latency SLA. Підбір GPU та квантування.
2. Проектування — конфігурація tensor parallel, batch size, quantization, вибір фреймворку.
3. Реалізація — встановлення CUDA, драйверів, деплой vLLM/TGI як systemd-сервісу з watchdog.
4. Тестування — навантажувальне тестування (locust/vegeta), замір p99 latency, перевірка на long-tail.
5. Деплой — nginx reverse proxy з rate limiting, SSL, моніторинг Prometheus + Grafana.
6. Документація — опис ендпоінтів, конфігів, процедури оновлення.

Оновлення без 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

Досвід наших інженерів — понад 5 років у ML/infra, понад 30 розгорнутих інференс-систем. Ми супроводжуємо кожен проєкт гарантією на конфігурацію та підтримкою після деплою. Якщо потрібна інтеграція з RAG-пайплайном, fine-tuning або MLOps-CI/CD — обговоримо на консультації. Отримайте попередню оцінку вашого проєкту — зв'яжіться з нами, відповімо протягом дня.