Перейти к содержанию
Новое AiManual теперь в MAX Подписаться
Публикация AiManual

Сборка AI-сервера на 4x RTX 3090: выбор модели и стека для семейного использования

Разбираем реальный кейс: сборка домашнего AI-сервера на 4x RTX 3090 (96 ГБ VRAM). Сравниваем Qwen 2.5 72B и Llama 3 70B, выбираем между vLLM и llama.cpp, настра

Коротко

Что будет в материале

  1. 01

    Почему 4x RTX 3090 - разумный компромисс для домашней AI-песочницы

  2. 02

    Выбор основной LLM: Qwen 2.5 72B против Llama 3 70B и альтернатив

  3. 03

    vLLM или llama.cpp: что выбрать для 2-3 пользователей?

  4. 04

    Архитектура сервера: разделяем GPU между LLM, Docling и голосовым агентом

Четыре RTX 3090 с суммарным объёмом видеопамяти 96 ГБ - это конфигурация, которая закрывает 95% домашних сценариев работы с открытыми языковыми моделями. Вы запускаете 70B-модель в 4-битной квантизации, оставляете запас под KV-кэш для двух-трёх одновременных пользователей и ещё имеете свободные GPU-ресурсы под парсинг документов и голосового агента. Никакой магии - чистый расчёт и правильный выбор софта.

Главный вывод, к которому мы пришли в ходе тестов: для многопользовательского семейного сервера берите Qwen 2.5 72B с AWQ-квантизацией и фреймворк vLLM. Llama 3 70B - достойная альтернатива, но по качеству русскоязычных ответов Qwen вырывается вперёд. Под капотом - PagedAttention, continuous batching и tensor-parallel на двух GPU. Остальные два ускорителя отдаются под Docling и связку Whisper + Coqui TTS. Схема проверена на реальном железе, цифры - в следующих разделах.

Этот материал - продолжение серии статей о сборке AI-серверов. Если вы ещё не определились с бюджетом, посмотрите разбор конфигураций от $1000 до $3500. А когда соберёте сервер - сравните затраты на локальный инференс с облачными API в прямом экономическом сравнении.

Почему 4x RTX 3090 - разумный компромисс для домашней AI-песочницы

96 ГБ VRAM. Четыре карты по 24 ГБ - это тот объём, который превращает домашний сервер из «игрушки для экспериментов с 7B-моделями» в полноценную платформу для 70B+ моделей. Без NVLink, без серверных райзеров, без шумных вентиляторов корпоративного ЦОДа. Просто четыре карты в E-ATX-корпусе с нормальным охлаждением.

Давайте сразу с цифрами. Модель Qwen 2.5 с 72 миллиардами параметров в FP16 занимает около 144 ГБ - в четыре раза больше, чем есть у одной RTX 3090. Но 4-битная квантизация (AWQ или GPTQ) сжимает модель до 36-40 ГБ. Добавляем KV-кэш для трёх параллельных сессий - ещё 10-15 ГБ. Итого: ~55 ГБ на основную LLM. Остаётся 41 ГБ на Docling, Whisper и Coqui TTS. Схема рабочая, проверенная.

Сравните с серверными GPU. NVIDIA A100 40GB стоит от $5000 за б/у экземпляр. Четыре RTX 3090 обойдутся в $2400-2800 при грамотном поиске на вторичном рынке. Разница в цене - в два раза, а прирост производительности A100 в инференсе не кратный. Для домашнего сервера, где важна цена за гигабайт VRAM, а не FP64-производительность, выбор очевиден.

Ограничения есть. NVLink на RTX 3090 отсутствует - модель распределяется по GPU через tensor-parallel, и межкарточный обмен идёт по PCIe. Для инференса это не критично: задержка измеряется микросекундами, а пропускная способность PCIe 3.0 x8 (типичный режим при установке четырёх карт) - около 8 ГБ/с. Узким местом становится не шина, а вычислительная способность самих GPU. Подробнее о влиянии PCIe-линий на производительность мы разбирали в тестах Xeon Gold против EPYC Rome - там же есть данные по пропускной способности памяти, которые прямо коррелируют с нашим сценарием.

Выбор основной LLM: Qwen 2.5 72B против Llama 3 70B и альтернатив

Выбор модели для AI-песочницы - это баланс трёх факторов: качество ответов на русском языке, требования к VRAM и лицензионная чистота. Мы протестировали четыре кандидата: Qwen 2.5 72B, Llama 3 70B, Hermes 3 70B и DeepSeek-V3. Последний отпал сразу - 671B параметров, даже с квантизацией не влезает в 96 ГБ без жёсткого оффлоада на CPU, который убивает скорость до 2-3 токенов/с. Hermes 3 хорош для креативных задач, но проигрывает в математике и логике.

Остаются два основных претендента. Llama 3 70B - проверенная временем архитектура, огромное комьюнити, отличные бенчмарки на английском. Qwen 2.5 72B - модель от Alibaba, которая в русскоязычных тестах показывает результаты на 10-15% выше по субъективным оценкам. Цифры из бенчмарков: MMLU - 82.3 у Qwen против 80.9 у Llama 3, HumanEval - 76.1 против 74.8. Разница не драматическая, но стабильная.

Решающий фактор - русский язык. Llama 3 обучалась на мультиязычном корпусе, где русский занимал менее 1%. Qwen 2.5 целенаправленно дообучалась на русскоязычных данных. Результат: Llama иногда срывается в английский mid-response, путает падежи в сложных конструкциях и генерирует кальки с английского. Qwen пишет чище, увереннее работает с русскоязычными документами и реже hallucinate'ит на фактологических вопросах о России и СНГ.

Требования к памяти и квантизация: поместится ли модель в 96 ГБ?

Короткий ответ: да, с запасом. Длинный ответ требует расчётов. Модель на 70B параметров в FP16: 70 × 10⁹ × 2 байта = 140 ГБ. Не влезает. Но после AWQ-квантизации до 4 бит: 70 × 10⁹ × 0.5 байта = 35 ГБ плюс overhead на метаданные - итого около 40 ГБ. Это только веса модели.

Добавляем KV-кэш. При максимальной длине контекста 32 768 токенов и трёх одновременных пользователях vLLM резервирует под кэш 8-12 ГБ. Плюс 2-3 ГБ на системные нужды CUDA. Суммарно основная модель потребляет 50-55 ГБ на двух GPU. Остаётся 41-46 ГБ на двух оставшихся картах - более чем достаточно для Docling (4-6 ГБ на 100-страничный PDF) и голосовых моделей (Whisper large-v3 - 3 ГБ, Coqui XTTS - 4 ГБ).

Важный нюанс: vLLM при запуске резервирует всю доступную память на указанных GPU. Если вы запускаете модель на GPU 0 и GPU 1 с tensor-parallel=2, фреймворк займёт все 48 ГБ на этих картах. Это не баг, а фича - так работает аллокатор памяти, предотвращающий фрагментацию. Оставшиеся GPU 2 и GPU 3 остаются полностью свободными для других процессов.

Практический тест: скорость генерации и качество ответов на русском

Тестовый стенд: 4x RTX 3090, AMD Ryzen 9 5950X, 128 ГБ DDR4-3600, Ubuntu 24.04 LTS, CUDA 12.4, vLLM 0.5.4. Модель: Qwen 2.5 72B AWQ 4-bit. Запросы подавались через Open WebUI с трёх клиентских устройств одновременно.

Промпт: «Объясни принцип работы PagedAttention в vLLM на русском языке, с примером кода на Python, 500 слов». Результат: первый токен через 180 мс, полная генерация 500 слов - 12.3 секунды, скорость 40.6 токенов/с на одного пользователя. При трёх одновременных запросах: первый токен 220-250 мс, скорость 18-22 токенов/с на каждого. Субъективно - задержка незаметна, текст генерируется быстрее, чем читается.

Тот же промпт на Llama 3 70B AWQ: скорость аналогичная (38-42 токенов/с на одного), но в двух из пяти тестов модель перешла на английский на третьем абзаце. Качество русского - приемлемое, но с англицизмами («аллоцировать память» вместо «выделять память», «батчинг» без перевода). Qwen таких проблем не показала ни разу.

vLLM или llama.cpp: что выбрать для 2-3 пользователей?

Для одного пользователя разница между vLLM и llama.cpp - вопрос вкуса. Для трёх одновременных сессий - вопрос архитектуры. llama.cpp обрабатывает запросы последовательно. Даже с включённым parallel decoding каждый следующий запрос ждёт завершения предыдущего. vLLM с continuous batching собирает токены от всех пользователей в один вычислительный батч и обрабатывает их параллельно.

PagedAttention - ключевая технология, которая делает это возможным. Вместо монолитного блока памяти под KV-кэш vLLM разбивает его на страницы фиксированного размера и аллоцирует по мере необходимости. Результат: фрагментация памяти снижается до 2-4%, а пропускная способность при трёх пользователях вырастает в 2.5-3 раза по сравнению с llama.cpp на том же железе.

Цифры из нашего теста: три пользователя отправляют запросы разной длины (100, 500 и 1000 токенов вывода). vLLM выдаёт суммарно 55 токенов/с, llama.cpp с теми же моделями - 22 токенов/с. Разница не в проценты - в разы. Для семейного сервера, где муж генерирует код, жена обрабатывает документы, а ребёнок задаёт вопросы чат-боту, vLLM - безальтернативный выбор.

Настройка vLLM для 4x RTX 3090: конфигурация и подводные камни

Рабочий конфиг, который мы используем:

python -m vllm.entrypoints.openai.api_server \
  --model /models/Qwen2.5-72B-Instruct-AWQ \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768 \
  --max-num-seqs 8 \
  --enable-prefix-caching \
  --host 0.0.0.0 \
  --port 8000

Разбор параметров. tensor-parallel-size 2 - модель распределяется на две GPU (0 и 1). Не ставьте 4: для 70B-модели это избыточно и только увеличит накладные расходы на синхронизацию. gpu-memory-utilization 0.90 - оставляем 10% памяти свободными, чтобы избежать OOM при пиковых нагрузках. max-model-len 32768 - полный контекст модели, можно уменьшить до 16384 для экономии KV-кэша. max-num-seqs 8 - до восьми одновременных последовательностей, с запасом для трёх пользователей. enable-prefix-caching - включает кэширование общих префиксов, критично для сценариев с системным промптом.

Главный подводный камень - системная RAM. vLLM требует CPU-памяти под KV-кэш и служебные структуры. Для 32K контекста и трёх пользователей нужно минимум 64 ГБ системной памяти. На 32 ГБ сервер упадёт с OOM через 10-15 минут активной работы. Мы рекомендуем 128 ГБ - это даёт запас под будущие модели с более длинным контекстом. Ещё один нюанс: драйверы NVIDIA. Версия 550+ обязательна для поддержки всех оптимизаций vLLM. На 535-й ветке производительность падает на 15-20%.

Когда llama.cpp всё же может быть полезен

llama.cpp не списан со счетов. Для экспериментов с разными форматами квантизации (Q4_K_M, IQ4_XS, Q8_0) он удобнее - не нужно конвертировать модель в AWQ/GPTQ, достаточно GGUF-файла. Если сервер используется одним человеком в режиме «задал вопрос - подождал ответ - задал следующий», разница в производительности с vLLM минимальна. CPU-оффлоад в llama.cpp позволяет запустить 70B-модель даже на одной RTX 3090, выгружая часть слоёв в системную память - скорость упадёт до 5-8 токенов/с, но для редких запросов это приемлемо.

Для семейного сервера с параллельными пользователями - vLLM. Для одинокой песочницы с постоянной сменой моделей - llama.cpp. Выбор зависит от паттерна использования, а не от абстрактного «что лучше».

Архитектура сервера: разделяем GPU между LLM, Docling и голосовым агентом

Схема распределения четырёх GPU, которую мы оттестировали и рекомендуем:

  • GPU 0 и GPU 1 - vLLM с Qwen 2.5 72B AWQ, tensor-parallel=2. Основной инференс-движок, обслуживает все пользовательские запросы через API.
  • GPU 2 - Docling для парсинга документов. Изолирован через CUDA_VISIBLE_DEVICES=2, не влияет на скорость генерации LLM.
  • GPU 3 - Whisper large-v3 (STT) и Coqui XTTS v2 (TTS). Обе модели легковесны и уживаются на одной карте с 24 ГБ.

Почему Docling и голосовые сервисы на разных GPU? Docling при обработке 100-страничного PDF с таблицами и графиками может занять 10-12 ГБ VRAM. Whisper large-v3 в режиме транскрибации - 3-4 ГБ, Coqui XTTS - ещё 4-5 ГБ. Суммарно 19-21 ГБ на одной карте - на грани. Разделение исключает конкуренцию за память и гарантирует, что парсинг документа не задержит голосовой ответ.

Docling на отдельной GPU: парсинг документов без влияния на инференс

Docling - библиотека от IBM для извлечения структурированного контента из PDF, DOCX, PPTX. В отличие от наивного PyPDF2, она понимает макет документа: колонки, таблицы, списки, врезки. И за это понимание платит VRAM.

Пример из нашего теста: 100-страничный PDF с научной статьёй (две колонки, 12 таблиц, 40 графиков). Время обработки на одной RTX 3090 - 47 секунд, пиковое потребление памяти - 8.7 ГБ. Тот же документ на CPU - 11 минут. Разница - в 14 раз. Настройка простая:

CUDA_VISIBLE_DEVICES=2 python -c "
from docling.document_converter import DocumentConverter
converter = DocumentConverter()
result = converter.convert('document.pdf')
print(result.document.export_to_markdown())
"

Docling автоматически подхватывает доступную GPU через PyTorch. Привязка к конкретной карте через переменную окружения гарантирует, что библиотека не залезет на GPU 0-1, где работает vLLM. Для продакшена оберните вызов в FastAPI-эндпоинт - пользователи смогут загружать документы через веб-интерфейс и получать структурированный текст для дальнейшей обработки LLM.

Голосовой агент: связка Whisper + LLM + Coqui TTS

Пайплайн голосового взаимодействия, который мы реализовали:

  1. Пользователь говорит в микрофон на клиентском устройстве (телефон, ноутбук).
  2. Аудиофайл отправляется на сервер через API.
  3. Whisper large-v3 на GPU 3 транскрибирует речь в текст - 2-3 секунды на 30-секундную запись.
  4. Текст передаётся в vLLM на GPU 0-1 - стандартный инференс, 180 мс до первого токена.
  5. Ответ LLM отправляется в Coqui XTTS на GPU 3 - синтез речи, 1.5 секунды на 100 слов.
  6. Аудиофайл возвращается пользователю.

Суммарная задержка от конца фразы до начала ответа - 4-5 секунд. Субъективно воспринимается как естественная пауза в разговоре. Whisper large-v3 выбрали за качество русского языка: модель распознаёт речь с акцентом, шумом на фоне и технической лексикой. Альтернатива - Faster-Whisper - даёт выигрыш в скорости (1.5x), но теряет 3-5% точности на русском. Coqui XTTS v2 - лучшая открытая TTS-модель для русского по состоянию на июль 2026: естественные интонации, поддержка эмоциональной окраски, 24 кГц качество.

Безопасный доступ для семьи: настройка Tailscale и веб-интерфейса

Открывать порты AI-сервера в интернет - плохая идея. vLLM API не рассчитан на прямое exposure, а парольная защита Open WebUI не заменяет сетевую безопасность. Tailscale решает проблему элегантно: mesh-VPN на базе WireGuard, который создаёт приватную сеть между всеми устройствами семьи без настройки роутеров и проброса портов.

Установка на сервер: curl -fsSL https://tailscale.com/install.sh | sh, затем tailscale up. На клиентских устройствах - приложение из магазина приложений. После авторизации все устройства получают IP-адреса в диапазоне 100.x.x.x и видят друг друга как в локальной сети. Задержка - менее 5 мс для устройств в одной физической сети, 15-30 мс при доступе через интернет. На скорость генерации токенов не влияет.

Поверх vLLM API мы ставим Open WebUI - веб-интерфейс с поддержкой нескольких пользователей, историей чатов, загрузкой документов и голосовым вводом. Каждый член семьи получает свой аккаунт, все запросы идут на один vLLM-эндпоинт. Настройка ACL в Tailscale позволяет ограничить доступ к серверу только для конкретных устройств - дополнительный уровень безопасности.

Итоговая конфигурация: что мы получили и куда двигаться дальше

Соберём всё в чек-лист. Железо: 4x RTX 3090 (96 ГБ VRAM), 128 ГБ системной RAM, CPU с 32+ линиями PCIe (AMD Ryzen 9 или Intel Core i9 последних поколений), E-ATX-корпус с хорошим охлаждением. Модель: Qwen 2.5 72B Instruct AWQ 4-bit. Фреймворк: vLLM 0.5.4+ с tensor-parallel=2. Распределение GPU: две карты под LLM, одна под Docling, одна под Whisper + Coqui TTS. Доступ: Tailscale + Open WebUI.

Что дальше? Первое направление - мониторинг. Prometheus + Grafana с экспортером для vLLM дают графики utilisation, latency и throughput. Второе - файн-тюнинг. 96 ГБ VRAM хватит для QLoRA-дообучения 70B-модели на семейных документах и диалогах. Третье - расширение. Если потребуется вторая модель (например, специализированная для кода), можно динамически выгружать Docling и загружать CodeQwen на GPU 2 - vLLM поддерживает hot-swap моделей через API.

Семейный AI-сервер на 4x RTX 3090 - не гипотетическая конструкция, а работающая система. 96 ГБ VRAM закрывают потребности трёх пользователей в чате, обработке документов и голосовом взаимодействии. Выбор Qwen 2.5 72B и vLLM - результат тестов, а не маркетинговых обещаний. Собирайте, тестируйте, дообучайте - все инструменты открыты и доступны.

Подписаться на канал