Сколько 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, нестандартных драйверах, 24/7-нагрузке с предсказуемой производительностью либо хранении больших наборов моделей. На виртуальных 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-инстанс за балансировщиком.