Майнинговая ферма как домашний LLM-кластер: возможности и ограничения

Локальный запуск больших языковых моделей перестал быть экзотикой. Для части задач достаточно ноутбука с Apple Silicon или одной потребительской видеокарты, но желание запускать модели крупнее быстро приводит к идее использовать несколько GPU. На вторичном рынке всё ещё встречаются бывшие майнинговые фермы: рамы, блоки питания, райзеры и набор видеокарт, которые раньше считали хэши, а теперь могут обслуживать инференс.

Такой подход выглядит привлекательно: железо уже собрано, видеокарт несколько, цена за гигабайт VRAM может быть ниже, чем у нового сервера. Но LLM-нагрузка отличается от майнинга. Здесь важны не только ватт на вычисление, но и объём видеопамяти, пропускная способность PCIe, стабильность драйверов, скорость обмена между CPU и GPU, охлаждение под переменной нагрузкой и удобство эксплуатации. Если оценивать ферму только по числу карт, можно получить шумный и капризный стенд, который сложно поддерживать.

Чем LLM-нагрузка отличается от майнинга

Майнинг обычно нагружал видеокарты однотипно и предсказуемо. После настройки ферма могла месяцами выполнять одинаковые операции, а обмен с CPU был минимальным. Инференс LLM устроен иначе: модель нужно загрузить в память, принять запрос, токенизировать текст, выполнить генерацию, вернуть поток токенов клиенту и освободить ресурсы для следующей сессии. Нагрузка зависит от длины контекста, числа параллельных пользователей, параметров sampling и выбранного runtime.

Особенно заметна роль VRAM. Для майнинга карта с 8 ГБ могла быть рациональным выбором, но для современных LLM это уже жёсткое ограничение. Квантизованные модели помещаются в меньший объём памяти, однако качество, скорость и максимальный контекст зависят от формата. Если модель не помещается на одну карту, приходится распределять слои между несколькими GPU или переносить часть вычислений в RAM/CPU. Это работает, но добавляет задержки и делает конфигурацию чувствительной к PCIe и настройкам runtime.

Также меняется профиль тепловыделения. Генерация может идти рывками: короткий всплеск при обработке prompt, затем длительный поток декодирования токенов. Веб-интерфейс или API могут создавать пики параллельных запросов. Охлаждение, которое справлялось с равномерной майнинговой нагрузкой, не всегда удобно для интерактивного сервиса: шум, горячие зоны в раме и нестабильные райзеры быстро становятся эксплуатационной проблемой.

Аппаратная база: на что смотреть перед запуском

Первый параметр — объём видеопамяти на каждой карте. Для локального ассистента, RAG-пайплайна или экспериментов с агентами важнее не суммарное количество GPU, а то, какую модель можно разместить без чрезмерного offload. Несколько карт по 8 ГБ могут быть полезны, но одна карта с 24 ГБ часто проще в настройке и предсказуемее в работе.

Второй параметр — PCIe-топология. Майнинговые фермы нередко используют райзеры и работают в режиме x1, потому что для майнинга этого хватало. Для LLM это может стать узким местом, особенно если модель распределена по нескольким картам или часть данных постоянно ходит через CPU. Не каждый сценарий требует x16 на каждую карту, но топологию нужно знать заранее: lspci, nvidia-smi topo -m и тесты реальной генерации полезнее маркетингового описания сборки.

Третий параметр — питание. У старой фермы могут быть несколько блоков питания, переходники, синхронизаторы и кабели, рассчитанные на длительную работу на пределе. Для домашнего LLM-стенда лучше иметь запас по мощности, аккуратную разводку PCIe-питания и понятную схему аварийного отключения. Нестабильное питание проявляется не только выключениями: возможны ошибки драйвера, сбросы GPU и повреждение процесса инференса в самый неудобный момент.

Четвёртый параметр — RAM и CPU. Даже если основная модель живёт в VRAM, система использует оперативную память для загрузки весов, кэша, веб-интерфейса, векторной базы, очередей и сопутствующих сервисов. CPU отвечает за токенизацию, сетевой стек, постобработку и часть runtime-логики. Слабый процессор не отменяет GPU, но может ограничить throughput и увеличить задержку первого токена.

Выбор программного стека

Для локального запуска LLM есть несколько практичных вариантов. Ollama удобна для быстрого старта и простого API. llama.cpp хорош для экспериментов с GGUF, CPU/GPU-offload и широкого набора потребительского железа. vLLM и Text Generation Inference ближе к production-подходу: они дают batching, эффективную работу с памятью и более предсказуемую многопользовательскую нагрузку, но требуют аккуратнее относиться к версиям CUDA, драйверам и форматам моделей.

На бывшей майнинг-ферме стоит начинать с минимальной конфигурации: одна модель, один runtime, один GPU или понятное распределение по нескольким GPU. Сначала нужно измерить tokens/sec, время первого токена, использование VRAM и поведение при длинном контексте. Только потом имеет смысл добавлять веб-интерфейс, Open WebUI, RAG-компоненты, агенты, очереди и автоматический перезапуск.

Контейнеризация помогает зафиксировать окружение, но не решает проблему драйверов на хосте. Нужно согласовать версию NVIDIA-драйвера, CUDA runtime в контейнере, nvidia-container-toolkit и зависимости Python. Для домашнего стенда достаточно docker compose, где отдельно описаны inference-сервис, UI, векторная база и мониторинг. Главное — не скачивать веса модели при каждом рестарте контейнера: лучше хранить их на локальном NVMe или отдельном volume с понятной структурой.

Квантизация и распределение модели

Квантизация — основной способ запустить более крупную модель на ограниченной VRAM. Форматы уровня Q4/Q5 часто дают приемлемый баланс качества и скорости для домашнего ассистента, анализа документов и технических задач. Но квантизация не бесплатна: разные модели по-разному реагируют на снижение точности, а скорость зависит от конкретного backend и GPU.

Если модель помещается на одну карту, эксплуатация обычно проще. Если не помещается, можно распределить слои между несколькими GPU. В этом случае важны одинаковость карт, скорость обмена и поддержка выбранного runtime. На смешанной ферме с разными GPU придётся вручную подбирать параметры: сколько слоёв уходит на каждую карту, какой контекст допустим, где начинается OOM и как ведёт себя сервис под параллельными запросами.

Отдельно стоит проверить длинный контекст. Модель может успешно стартовать, отвечать на короткие вопросы и при этом падать или резко замедляться на реальных документах. KV-cache занимает память, а несколько одновременных диалогов быстро увеличивают расход VRAM. Поэтому тестовый набор должен включать не только короткие prompts, но и длинные инструкции, фрагменты логов, README, конфиги и несколько параллельных сессий.

Эксплуатация: шум, тепло и удалённый доступ

Домашний LLM-кластер редко стоит в серверной. Бывшая ферма может быть шумной, горячей и неудобной для размещения рядом с рабочим местом. Перед постоянной эксплуатацией нужно продумать airflow, фильтрацию пыли, безопасное крепление карт, температурные лимиты и сценарий обслуживания. Открытая рама упрощает охлаждение, но повышает риск случайного контакта, повреждения кабелей и накопления пыли.

Полезно сразу настроить удалённое управление: SSH, VPN, systemd-сервисы или compose-профили, автоматический старт после отключения питания, журналирование и ограничение доступа к API. Локальная LLM часто обрабатывает приватные данные, поэтому открытый без авторизации веб-интерфейс в домашней сети — плохая идея. Минимум — reverse proxy с auth, firewall и отдельная сеть для сервисов.

Мониторинг нужен не меньше, чем для обычного сервера. Базовый набор: температура GPU, потребление, загрузка, VRAM, частота, ошибки Xid в логах драйвера, загрузка CPU/RAM, скорость диска и latency API. Для LLM полезны tokens/sec, time to first token, длина очереди, число активных сессий и ошибки OOM. Такой набор быстро показывает, что именно ограничивает стенд: память, охлаждение, PCIe, CPU или настройки runtime.

Когда такая сборка оправдана

Бывшая майнинг-ферма подходит для обучения инфраструктурной стороне AI, локальных экспериментов, приватного ассистента, тестирования RAG, ночной пакетной обработки документов и сравнения моделей. Она особенно полезна, если уже есть железо или удалось недорого купить комплект с понятной историей и исправными картами.

Для production-сервиса или команды, где важны SLA, тишина, гарантия и быстрая замена компонентов, такой вариант спорнее. Серверные GPU, нормальная PCIe-топология, ECC RAM, IPMI и предсказуемое охлаждение стоят дороже, но экономят время администратора. Компромиссный путь — использовать ферму как лабораторию: на ней проверять модели, квантизацию, prompts и RAG-пайплайны, а стабильные сценарии переносить на более надёжную платформу или облачный inference.

Практичный план запуска

Начинать лучше с инвентаризации: модели GPU, объём VRAM, состояние вентиляторов, блоки питания, схема райзеров, версия BIOS, доступные PCIe-линии, объём RAM и тип дисков. Затем установить чистую ОС, драйвер NVIDIA, Docker и один выбранный runtime. После этого — загрузить одну модель, прогнать короткие и длинные prompts, зафиксировать метрики и только потом усложнять стенд.

Хороший минимальный чек-лист выглядит так:

Проверить стабильность каждой GPU отдельно под нагрузкой.
Измерить генерацию на одной карте и на нескольких картах.
Настроить лимиты температуры и power limit.
Разместить веса моделей на быстром локальном диске.
Добавить мониторинг GPU и логов драйвера.
Закрыть API авторизацией или доступом через VPN.
Документировать рабочие параметры запуска для каждой модели.

Главная мысль проста: майнинговая ферма может стать полезным LLM-стендом, если относиться к ней как к инженерной системе, а не как к «куче видеокарт». Локальный инференс выигрывает приватностью, контролем и предсказуемой стоимостью экспериментов, но требует дисциплины в питании, охлаждении, версиях, мониторинге и выборе моделей. Тогда старое GPU-железо получает вторую жизнь и превращается в рабочий инструмент для разработки, homelab и внутренних AI-сценариев.