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