Скільки GPU потрібно для LLM: таблиця модель → VRAM → відеокарта

Що ми налаштовуємо і навіщо

У цьому гайді ми піднімаємо власний сервер інференсу LLM: модель працює на GPU, приймає запити через API, відповідає в OpenAI-сумісному форматі та може використовуватися вебінтерфейсом, ботом, IDE-плагіном, RAG-системою або внутрішнім SaaS. Як inference engine буде використано vLLM: він ефективно керує KV-кешем, підтримує батчинг запитів і підходить для моделей сімейств Llama, Qwen, Mistral, Gemma, DeepSeek та багатьох інших.

Головне завдання до встановлення — правильно розрахувати GPU. Помилка в оцінці зазвичай виглядає так: модель «майже поміщається» у VRAM, але сервер завершується з CUDA out of memory під час першого довгого діалогу, роботи з кількома користувачами або ввімкнення великого контексту. Тому потрібно рахувати не лише обсяг ваг, а й пам’ять для runtime.

З чого складається споживання VRAM

Споживання пам’яті під час LLM-інференсу можна представити так:

VRAM = ваги моделі + KV-кеш + CUDA-графи та робочі буфери + запас

• Ваги моделі — параметри нейромережі. Це основна, але не єдина частина.
• KV-кеш — пам’ять історії діалогу. Він зростає разом із довжиною контексту та кількістю паралельних запитів.
• Робочі буфери — тимчасова пам’ять CUDA, attention-операцій, завантажувача та компіляції графів.
• Запас — практичний резерв у 10–20%, який зменшує ймовірність OOM під час пікових запитів.

У FP16 або BF16 один параметр займає 2 байти. Отже, 8B-модель потребує близько 16 ГБ лише для сирих ваг. На практиці для FP16 8B потрібна карта від 20–24 ГБ, оскільки залишаються KV-кеш і службова пам’ять. У Q4-квантизації ті самі ваги зазвичай займають 5–6 ГБ, але підсумкове споживання все одно може становити 8–12 ГБ.

Таблиця: модель → VRAM → відповідна GPU

Нижче наведено практичні орієнтири для однокористувацького або малонавантаженого сервісу з контекстом до 8–16 тисяч токенів. Значення не є паспортними: конкретне споживання залежить від архітектури, формату GGUF/AWQ/GPTQ/FP8, версії рушія, довжини контексту та параметрів запуску.

Для моделей Mixture of Experts не можна орієнтуватися лише на кількість активних параметрів. Наприклад, MoE може активувати порівняно мало експертів на токен, однак для інференсу в пам’яті зазвичай мають перебувати ваги всіх експертів. Тому модель із маркуванням «8×7B» може потребувати значно більше VRAM, ніж dense-модель на 7B.

Як вибрати квантизацію

Для першого сервера розумна стратегія така: якщо у вас 24 ГБ VRAM, почніть із Qwen 32B у Q4 або з 8–14B у BF16. Перший варіант дає потужнішу модель, другий — вищу швидкість, довший контекст і більше паралельних користувачів. Для програмування, україномовних відповідей і RAG обов’язково порівняйте моделі на власних документах: розмір параметрів сам по собі не гарантує кращого результату.

Self-hosted, managed API або гібрид

Керований API зручний, якщо навантаження непередбачуване, потрібен швидкий старт або ви не хочете адмініструвати GPU. Його мінуси — вартість за великого обсягу токенів, залежність від зовнішнього сервісу та передавання даних за межі периметра.

Self-hosted LLM на GPU-сервері виправдана, коли запити містять внутрішній код, персональні дані, комерційні документи або коли навантаження достатньо постійне. Ви контролюєте модель, retention логів, ліміти, версію API та витрати. Гібридний підхід також практичний: локальна 8–32B-модель обробляє основний потік, а рідкісні складні запити маршрутизуються у зовнішній API.

Який VPS-конфіг потрібен для цього завдання

Звичайний VPS без GPU не підходить для швидкого LLM-інференсу: запустити модель на CPU можна, але генерація 32B або 70B буде надто повільною для інтерактивного чату. Потрібен GPU VPS, GPU cloud instance або dedicated-сервер із проброшеною відеокартою. Перевіряйте, що GPU виділена вам повністю або має гарантовану VRAM, а драйвер NVIDIA доступний усередині віртуальної машини.

Для старту з моделлю 8–14B у Q4 або BF16 розумним є сервер із GPU на 24 ГБ VRAM, 8 vCPU, 64 ГБ RAM і 200 ГБ NVMe. Як один із варіантів можна взяти VPS із зазначеними характеристиками, якщо вибраний екземпляр справді надає NVIDIA GPU з 24 ГБ відеопам’яті.

Чому системна RAM також важлива

Системна пам’ять не замінює VRAM під час GPU-інференсу. Offload частини моделі в RAM можливий у llama.cpp, але різко знижує швидкість через передавання даних через PCIe. RAM потрібна для операційної системи, Docker, завантаження моделі, токенізаторів, векторної БД, кешів і завантаження файлів. Для однієї GPU з 24 ГБ мінімумом є 32 ГБ RAM, але для стабільного RAG-сервера краще 64 ГБ.

Коли потрібен dedicated, а не VPS

Dedicated переважніший за наявності двох і більше GPU, потреби в NVLink, нестандартних драйверах, цілодобового навантаження з передбачуваною продуктивністю або зберігання великих наборів моделей. На віртуальних GPU можливі обмеження щодо P2P, MIG, power limit і пропускної здатності PCIe. Для однієї карти на 24–48 ГБ і помірного навантаження GPU VPS зазвичай простіший і дешевший в експлуатації.

Якщо ви плануєте tensor parallel для 70B-моделі на двох GPU, перевірте топологію командою nvidia-smi topo -m. З’єднання NVLink є переважнішим, але PCIe також працює; просто затримка та швидкість генерації можуть бути гіршими. Не об’єднуйте карти з дуже різним обсягом VRAM: модель буде обмежена меншою картою, а також з’являться неефективні схеми розподілу.

Локація та затримка

Локація впливає на затримку першого байта відповіді, а не на швидкість самої генерації токенів. Для користувачів із Європи зазвичай обирайте європейський дата-центр, для користувачів із Росії та СНД — точку з хорошою мережевою зв’язаністю з їхніми операторами. Якщо сервер отримує документи через RAG-пайплайн або звертається до внутрішніх баз, розміщуйте його ближче до цих систем. Враховуйте вимоги законодавства до персональних даних і місця зберігання резервних копій.

Підготовка сервера

Нижче використовується Ubuntu Server 24.04 LTS. Ця версія підходить для актуальних гілок Docker, NVIDIA Container Toolkit, CUDA 12.x і сучасних образів vLLM. Виконуйте початкове налаштування з консолі провайдера або через SSH під користувачем із правами root.

Створіть окремого адміністратора

# Создаёт пользователя llmadmin, добавляет его в группу sudo и готовит каталог SSH.
adduser llmadmin
usermod -aG sudo llmadmin
install -d -m 700 -o llmadmin -g llmadmin /home/llmadmin/.ssh

Додайте відкритий SSH-ключ до файлу /home/llmadmin/.ssh/authorized_keys. Не копіюйте приватний ключ на сервер і не зберігайте його в Docker-образах або репозиторії.

# Записывает публичный ключ администратора и задаёт безопасные права доступа.
nano /home/llmadmin/.ssh/authorized_keys
chown llmadmin:llmadmin /home/llmadmin/.ssh/authorized_keys
chmod 600 /home/llmadmin/.ssh/authorized_keys

Оновіть систему та встановіть базові утиліти

# Обновляет пакеты Ubuntu и устанавливает утилиты диагностики, firewall и fail2ban.
apt update && apt full-upgrade -y
apt install -y ca-certificates curl gnupg lsb-release jq htop nvtop \
  ufw fail2ban unattended-upgrades git vim

Після оновлення перезавантажте сервер, особливо якщо оновилося ядро. Потім підключіться знову під створеним користувачем і переконайтеся, що sudo працює.

# Перезагружает сервер, чтобы применить обновлённое ядро и драйверы.
reboot

Налаштуйте SSH і firewall

Спочатку переконайтеся, що вхід за ключем працює в другому терміналі. Лише після цього вимикайте автентифікацію за паролем. Якщо ви помилитеся в конфігурації SSH, доступ можна буде відновити через out-of-band-консоль.

# Отключает root-вход и парольную аутентификацию, оставляя вход только по SSH-ключу.
sudo tee /etc/ssh/sshd_config.d/99-hardening.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
AllowUsers llmadmin
EOF

sudo sshd -t && sudo systemctl restart ssh

# Открывает только SSH, HTTP и HTTPS; API vLLM наружу не публикуется.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable
sudo systemctl enable --now fail2ban

Порт vLLM, зазвичай 8000, не відкривайте в інтернет. Він прослуховуватиме лише 127.0.0.1, а зовнішній доступ здійснюватиметься через Caddy із TLS та API-ключем. Це захищає сервер від випадкового публічного inference, який може швидко вичерпати VRAM і трафік.

Перевірте GPU до встановлення контейнерів

# Показывает модель GPU, объём VRAM, драйвер NVIDIA и активные процессы.
nvidia-smi

Якщо команду не знайдено або вона не показує карту, спочатку встановіть рекомендований драйвер NVIDIA з репозиторію Ubuntu або зверніться до документації майданчика. Не встановлюйте CUDA Toolkit лише заради vLLM: контейнер vLLM містить потрібний userspace CUDA, а на хості критично важливий сумісний драйвер NVIDIA.

Встановлення ПЗ — покроково

Для production-подібного запуску використовуйте Docker Compose. Він ізолює залежності, спрощує оновлення та дає змогу відтворювано зафіксувати версію образу. Станом на 2026 рік актуальні гілки Docker Engine 28+, NVIDIA Container Toolkit 1.17+ і vLLM 0.10+ слід звіряти з офіційними release notes перед оновленням production-сервера.

Встановіть Docker Engine

# Добавляет официальный репозиторий Docker для Ubuntu 24.04.
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Устанавливает Docker Engine, Compose plugin и containerd из официального репозитория.
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker $USER
newgrp docker

Перевірте, що Docker працює без sudo. Команду newgrp docker виконуйте лише в поточній сесії; після нового SSH-входу група застосовується автоматично.

# Запускает тестовый контейнер и проверяет доступ пользователя к Docker daemon.
docker run --rm hello-world

Встановіть NVIDIA Container Toolkit

# Добавляет официальный репозиторий NVIDIA Container Toolkit.
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

# Устанавливает runtime NVIDIA и перезапускает Docker с поддержкой GPU-контейнеров.
sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Проверяет, что контейнер видит GPU и драйвер хоста.
docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi

Тег CUDA-образу може змінитися після виходу нових версій. Найважливіше, щоб версія драйвера на хості підтримувала CUDA runtime усередині контейнера. Якщо тестова команда завершилася помилкою сумісності, оновіть драйвер NVIDIA на хості, а не намагайтеся вручну копіювати бібліотеки CUDA до контейнера.

Створіть робочу структуру

# Создаёт отдельный каталог, где будут compose-файл, секреты и конфигурация Caddy.
sudo mkdir -p /opt/llm-server/{caddy-data,caddy-config}
sudo chown -R $USER:$USER /opt/llm-server
cd /opt/llm-server
umask 077

Для першого запуску візьмемо інструкційну модель 8B у форматі Hugging Face. Для закритих або gated-моделей знадобиться токен Hugging Face із правами на завантаження моделі. Для публічних моделей токен можна не вказувати, але обмеження API-ключем для клієнтів все одно необхідне.

# Генерирует секретный ключ для клиентов API и создаёт файл переменных окружения.
openssl rand -hex 32
nano /opt/llm-server/.env
chmod 600 /opt/llm-server/.env

У файл .env додайте згенерований ключ. Не публікуйте цей файл і не додавайте його до Git.

VLLM_API_KEY=вставьте_сюда_случайную_строку_из_64_символов
HF_TOKEN=
DOMAIN=llm.example.com

Конфігурація

Наведена нижче конфігурація запускає vLLM на localhost, а Caddy — на публічних портах 80/443. Caddy автоматично отримує та продовжує сертифікат Let’s Encrypt, якщо A/AAAA-запис домену вже вказує на IP сервера, а порти 80 і 443 доступні ззовні.

Створіть Docker Compose-файл

Приклад розрахований на одну GPU 24 ГБ і 8B-модель. Параметр gpu_memory_utilization навмисно встановлено в 0.88, а не в 1.0: резерв знижує ризик OOM. Для GPU на 48–80 ГБ і більшого навантаження можна поступово підвищити значення до 0.92–0.95, попередньо перевіривши сервер тривалим тестом.

services:
  vllm:
    image: vllm/vllm-openai:v0.10.0
    container_name: vllm
    restart: unless-stopped
    env_file:
      - .env
    environment:
      HF_TOKEN: ${HF_TOKEN}
      NVIDIA_VISIBLE_DEVICES: all
      NVIDIA_DRIVER_CAPABILITIES: compute,utility
    command:
      - --model
      - Qwen/Qwen2.5-7B-Instruct
      - --served-model-name
      - qwen-7b
      - --host
      - 127.0.0.1
      - --port
      - "8000"
      - --api-key
      - ${VLLM_API_KEY}
      - --dtype
      - auto
      - --max-model-len
      - "8192"
      - --gpu-memory-utilization
      - "0.88"
      - --max-num-seqs
      - "8"
    ports:
      - "127.0.0.1:8000:8000"
    volumes:
      - huggingface-cache:/root/.cache/huggingface
    gpus: all
    ipc: host

  caddy:
    image: caddy:2.10.0-alpine
    container_name: caddy
    restart: unless-stopped
    depends_on:
      - vllm
    env_file:
      - .env
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - ./caddy-data:/data
      - ./caddy-config:/config

volumes:
  huggingface-cache:

Тег образу навмисно зафіксовано, щоб оновлення не відбулося автоматично й не зламало API або CUDA-сумісність. Перед використанням перевірте доступність зазначеного тегу в офіційному реєстрі vLLM. Після тестування оновлюйте версію контрольовано у maintenance window.

Створіть Caddyfile

{$DOMAIN} {
    encode zstd gzip

    @api path /v1/ /health
    handle @api {
        reverse_proxy vllm:8000
    }

    respond "LLM API is available at /v1" 200
}

# Скачивает образы, запускает контейнеры в фоне и показывает их текущее состояние.
cd /opt/llm-server
docker compose up -d
docker compose ps

# Показывает поток логов vLLM; Ctrl+C завершает только просмотр, а не контейнер.
docker compose logs -f vllm

# Проверяет, что модель загружена, а GPU-память занята процессом контейнера.
nvidia-smi
curl -s http://127.0.0.1:8000/v1/models \
  -H "Authorization: Bearer $(grep VLLM_API_KEY .env | cut -d= -f2)" | jq

# Отправляет тестовый chat completion через публичный HTTPS endpoint.
export API_KEY="$(grep VLLM_API_KEY /opt/llm-server/.env | cut -d= -f2)"

curl -sS https://llm.example.com/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $API_KEY" \
  -d '{
    "model": "qwen-7b",
    "messages": [
      {"role": "system", "content": "Отвечай кратко и по-русски."},
      {"role": "user", "content": "Объясни, что такое KV-кэш в LLM."}
    ],
    "temperature": 0.3,
    "max_tokens": 180
  }' | jq '.choices[0].message.content'

# Перезапускает только vLLM после изменения compose-файла и показывает последние сообщения старта.
cd /opt/llm-server
docker compose up -d --force-recreate vllm
docker compose logs --tail=100 vllm

Бекапи та обслуговування

Самі ваги моделі зазвичай необов’язково копіювати до щоденного бекапу: вони великі, відтворювано завантажуються з офіційного репозиторію та можуть займати десятки або сотні гігабайтів. Але якщо ви використовуєте власну донавчену модель, LoRA-адаптери, закритий checkpoint або вручну підготовлені квантизовані файли, резервна копія цих даних є обов’язковою.

Що потрібно бекапити

• Конфігурацію: compose.yaml, Caddyfile, systemd units, скрипти деплою.
• Секрети: файл .env, бажано в зашифрованому сховищі.
• TLS-дані Caddy: каталог caddy-data, щоб зберегти сертифікати та обліковий запис ACME.
• Власні моделі та LoRA: окремий каталог або volume з контрольними сумами.
• Дані RAG: векторну БД, вихідні документи, метадані, PostgreSQL/SQLite за наявності.
• Журнали аудиту: лише якщо це дозволено політикою приватності; не зберігайте користувацькі промпти безстроково без причини.

Простий бекап через restic у S3

Restic шифрує дані на стороні сервера перед відправленням до S3-сумісного сховища. Секрети доступу до S3 та пароль репозиторію зберігайте у root-only файлі. Перед увімкненням cron обов’язково вручну перевірте відновлення хоча б одного файлу.

# Встановлює restic і створює каталог для закритих параметрів резервного копіювання.
sudo apt install -y restic
sudo install -d -m 700 /root/.config/restic
sudo nano /root/.config/restic/llm-backup.env
sudo chmod 600 /root/.config/restic/llm-backup.env

RESTIC_REPOSITORY=s3:https://s3.example.net/llm-backups
RESTIC_PASSWORD=довгий_унікальний_пароль_репозиторію
AWS_ACCESS_KEY_ID=access_key
AWS_SECRET_ACCESS_KEY=secret_key

# Ініціалізує зашифрований restic-репозиторій у віддаленому S3-сховищі.
sudo bash -c 'source /root/.config/restic/llm-backup.env && restic init'

# Створює скрипт бекапу конфігурації, TLS-даних і користувацьких моделей.
sudo tee /usr/local/sbin/backup-llm.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail
source /root/.config/restic/llm-backup.env

restic backup \
  /opt/llm-server/compose.yaml \
  /opt/llm-server/Caddyfile \
  /opt/llm-server/.env \
  /opt/llm-server/caddy-data \
  /srv/llm-models \
  --exclude-caches

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
EOF

sudo chmod 700 /usr/local/sbin/backup-llm.sh
sudo /usr/local/sbin/backup-llm.sh

Якщо каталогу /srv/llm-models немає, видаліть його зі скрипта або створіть для власних моделей. Docker named volume з кешем Hugging Face у цьому прикладі навмисно не бекапиться: це кеш, який можна завантажити повторно. Для закритих моделей, які можуть зникнути із зовнішнього доступу, зберігайте перевірену копію в окремому каталозі, що бекапиться.

# Додає щоденний запуск о 03:25 і записує журнал у захищений системний лог-файл.
echo '25 3    root /usr/local/sbin/backup-llm.sh >> /var/log/llm-backup.log 2>&1' | \
  sudo tee /etc/cron.d/llm-backup

Перевірка відновлення

# Показує знімки та відновлює конфігурацію до тестової директорії без перезапису production.
sudo bash -c 'source /root/.config/restic/llm-backup.env && restic snapshots'
sudo mkdir -p /tmp/llm-restore
sudo bash -c 'source /root/.config/restic/llm-backup.env && restic restore latest --target /tmp/llm-restore'

Неробочий бекап гірший за його відсутність: він створює хибне відчуття безпеки. Раз на місяць перевіряйте, що секрети, конфігурація та власні моделі справді відновлюються на окрему машину або до тестового каталогу.

Оновлення та maintenance window

Оновлення драйвера NVIDIA, Docker, vLLM і моделі можуть змінювати продуктивність, формат API та споживання VRAM. Для одного сервера використовуйте maintenance window: зупиніть вхідний трафік, зробіть бекап, оновіть один компонент, виконайте smoke test і лише потім поверніть сервіс у роботу.

Rolling update можливий за наявності двох незалежних інстансів за reverse proxy або балансувальником: спочатку оновлюється один вузол, проходить тести, потім трафік перемикається на нього. Не використовуйте автоматичне оновлення тегу latest для inference engine: навіть невеликий реліз може потребувати нового драйвера або змінити поведінку квантизації.

Troubleshooting + FAQ

Яка VPS-конфігурація мінімально підійде?

Для першої LLM 7–8B у Q4 мінімально потрібні GPU з 12 ГБ VRAM, 4 vCPU, 16–32 ГБ RAM і 80 ГБ NVMe. Такий варіант підходить для одного користувача, короткого контексту та експериментів. Для стабільного чат-бота, RAG і моделей 8–14B практичніше одразу взяти 24 ГБ VRAM, 8 vCPU, 64 ГБ RAM і 200 ГБ NVMe. Системна RAM не компенсує нестачу VRAM без серйозного падіння швидкості.

vLLM завершується з CUDA out of memory. Що перевірити?

Спочатку виконайте nvidia-smi і перевірте, чи не зайнята GPU іншим процесом. Потім зменште --max-model-len, наприклад з 8192 до 4096, і знизьте --max-num-seqs. Саме KV-кеш часто спричиняє OOM після успішного завантаження ваг. Зменште --gpu-memory-utilization до 0.80–0.85, якщо помилка з’являється під час ініціалізації графів. Якщо цього недостатньо, використовуйте AWQ/GPTQ/FP8/Q4-версію моделі або GPU з більшою VRAM.

Контейнер не бачить GPU і повідомляє «could not select device driver».

Перевірте GPU на хості командою nvidia-smi. Якщо вона не працює, проблема в драйвері NVIDIA або в налаштуваннях GPU VPS. Якщо на хості все нормально, переконайтеся, що встановлено NVIDIA Container Toolkit, виконано команду nvidia-ctk runtime configure --runtime=docker і Docker перезапущено. Потім протестуйте CUDA-контейнер командою з розділу встановлення. Лише після успішного тесту запускайте vLLM.

Модель завантажується, але відповідає дуже повільно. Як знайти причину?

Порівняйте швидкість токенів за секунду в логах vLLM і завантаження GPU через nvtop або nvidia-smi dmon. Якщо GPU завантажена слабо, перевірте, чи не відбувається CPU-offload і чи не обмежений контейнер за CPU. Якщо GPU завантажена на 100%, модель або контекст надто великі для бажаної затримки. Використовуйте компактнішу модель, зменште контекст, увімкніть квантизацію або встановіть продуктивнішу GPU. Для кількох запитів vLLM зазвичай ефективніший за звичайний послідовний запуск.

Чому 70B Q4 не вміщується в GPU на 48 ГБ, хоча розмір файлу близько 40 ГБ?

Розмір файлу на диску не дорівнює піковому споживанню VRAM. Після завантаження додаються метадані квантизації, KV-кеш, буфери attention, CUDA-графи та фрагментація пам’яті. На карті 48 ГБ 70B Q4 може стартувати лише з дуже коротким контекстом і мінімальним паралелізмом, але це нестабільна конфігурація. Для практичної роботи 70B Q4 краще орієнтуватися на 80 ГБ VRAM або на дві GPU з коректно налаштованим tensor parallel.

Що вибрати — VPS чи dedicated для цього завдання?

GPU VPS зручний для однієї GPU, тестів, 8–32B-моделей і змінного навантаження: його простіше швидко розгорнути або вимкнути. Dedicated кращий за постійного високого навантаження, двох і більше GPU, вимог до NVLink, великого локального NVMe та передбачуваної продуктивності. Якщо ви лише перевіряєте економіку продукту, почніть із VPS. Якщо сервер уже постійно обслуговує користувачів і GPU завантажена більшу частину доби, порівняйте вартість із dedicated-конфігурацією.

Чи можна запускати модель на кількох GPU з різним обсягом пам’яті?

Технічно деякі рушії та схеми offload дозволяють це зробити, але для production такий набір небажаний. Tensor parallel розподіляє шари або тензори між картами, і слабша або менш містка GPU стає вузьким місцем. Різна архітектура GPU також може обмежити dtype, FlashAttention і продуктивність. Для 70B краще використовувати однакові карти з однаковим обсягом VRAM, однаковими драйверами та максимально швидким між-GPU-зв’язком.

Як безпечно відкрити API для застосунку, але не зробити його публічною безкоштовною LLM?

Не публікуйте порт 8000 напряму: прив’яжіть його до 127.0.0.1. Віддавайте назовні лише HTTPS через Caddy та увімкніть API-ключ vLLM. Додатково обмежте доступ firewall-правилами за IP, якщо клієнти мають статичні адреси, або використовуйте WireGuard для внутрішнього API. Не передавайте ключ у фронтенд браузерного застосунку: браузер має звертатися до вашого backend, а backend — до LLM API.

Висновки та наступні кроки

Ви отримали практичну схему вибору GPU для LLM і базовий захищений сервер vLLM з HTTPS API. Для більшості особистих і невеликих командних завдань оптимальною стартовою точкою залишається одна GPU з 24 ГБ VRAM: вона дає змогу обирати між швидкими 8–14B у BF16 і більшими моделями у Q4.

1. Протестуйте 2–3 моделі на реальних запитах, а не лише на публічних бенчмарках.
2. Додайте метрики часу відповіді, tokens/sec, завантаження VRAM і кількості помилок OOM.
3. У разі зростання навантаження розділіть API, RAG-векторну БД та inference на окремі вузли або додайте другий GPU-інстанс за балансувальником.