Развёртывание 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 — обсудим на консультации. Получите предварительную оценку вашего проекта — свяжитесь с нами, ответим в течение дня.