Я решил попробовать локальный ИИ на отдельном домашнем сервере. Для начала использовал то железо, которое уже было под рукой: Intel Core i3-10100, 16 ГБ оперативной памяти и GeForce GTX 1050 Ti с 4 ГБ видеопамяти.
Покупать новую видеокарту ради первого знакомства мне не хотелось. Сначала было интереснее получить работающий результат и понять, чего можно добиться на этой конфигурации.
Задачу я поставил вполне конкретную: открыть веб-интерфейс, задать вопрос текстовой модели, создать изображение и убедиться, что после перезагрузки сервер заработает без ручного запуска служб.
Этот результат я получил. Но по дороге пришлось разобраться и с ограничениями памяти, и с выбором моделей, и с разницей между успешным запросом к API и работой через браузер.
Что я установил
Основой стала Ubuntu 24.04 LTS. После установки драйвера NVIDIA я проверил, что система видит GTX 1050 Ti, определяет её 4 ГБ памяти и может использовать видеокарту для вычислений.
Дальше я разделил задачи между несколькими компонентами:
- Ollama — запуск текстовых моделей;
- ComfyUI — генерация изображений;
- Open WebUI — общий веб-интерфейс для общения и создания картинок;
- Nginx — HTTPS-доступ к веб-приложениям.
Программы и окружения размещены на SSD, а модели и основные данные — на отдельном HDD. Это позволило использовать имеющиеся диски, хотя скорость первой загрузки моделей стала одним из заметных ограничений.
Сервер я подключил к домашней серверной сети. Для веб-интерфейсов настроил понятные локальные имена и доверенные сертификаты. Внутренние API оставил доступными только через loopback-интерфейс самого сервера.
Почему 4 ГБ видеопамяти определяли выбор
На такой видеокарте нельзя выбирать модели только по принципу «возьму самую большую». Нужно учитывать не только размер файла, но и память, необходимую во время работы.
Для чата я использовал квантованные модели. Квантование сокращает объём памяти, который требуется для хранения весов, но не отменяет остальных расходов: контекста, рабочих буферов и самого окружения.
Первой заработала Qwen2.5 на 3 миллиарда параметров. Она позволила проверить весь путь от запроса до ответа с использованием GPU.
Затем я сравнил несколько вариантов на одинаковых восьми заданиях на русском языке. Проверял исправление текста, простые технические объяснения, вычисления и соблюдение заданного формата ответа.
Основной в итоге выбрал Qwen3.5 4B в квантовании Q4_K_M. В моём небольшом сравнении она лучше справилась с частью заданий и исправила ошибки, которые допускала первоначальная модель.
При этом неточности остались. Например, в техническом объяснении модель могла правильно передать общий смысл, но ошибиться в термине. Поэтому я воспринимаю её ответы как материал для проверки, а не как готовую техническую справку.
Какую скорость я получил в чате
В серии сравнительных заданий у выбранной модели медианная скорость составила около 14,7 токена в секунду. Это результат конкретного набора запросов и настроек.
Он не означает, что любой вопрос будет обрабатываться с такой же скоростью. На время влияют длина запроса, объём ответа, состояние модели в памяти и распределение вычислений между CPU и GPU.
Для веб-интерфейса я сохранил контекст 4096 токенов и отключил режим развёрнутого рассуждения. Для пробного сервера мне было важнее получать обычный ответ без лишнего ожидания.
Отдельно пришлось учесть, что выбор модели по умолчанию относится прежде всего к новым диалогам. В уже открытом чате может остаться прежняя модель — это легко принять за то, что настройка не применилась.
Что получилось с изображениями
Для генерации картинок я начал с модели семейства Stable Diffusion 1.5, а затем установил DreamShaper 8.
Сравнение делал на трёх парах изображений: одинаковые описания и одинаковые начальные значения генератора случайных чисел. Так было проще увидеть разницу между моделями, а не между случайно получившимися вариантами.
В моих примерах DreamShaper лучше справилась с отдельными деталями и композицией. Но точного выполнения сложного описания я от неё не получил и обещать этого не могу.
Для повседневной пробы сохранил такие параметры:
- размер — 512 × 512 пикселей;
- 24 шага;
- DPM++ 2M с расписанием Karras;
- одно изображение за запрос.
В сравнительных запусках генерация занимала примерно 41–46 секунд. Использование видеопамяти доходило примерно до 3,8 ГиБ — для GTX 1050 Ti это уже близко к её объёму.
Мне было важно проверить картинку не только по сообщению об успешном выполнении. Я получил готовый PNG, открыл его и сверил параметры генерации.
Как я разделил одну видеокарту между двумя задачами
И чат, и генерация изображений используют одну GTX 1050 Ti. Держать обе модели в видеопамяти одновременно для этой конфигурации непрактично.
Я добавил промежуточный обработчик, который координирует обращения к GPU и освобождение памяти при смене задачи. Расчёт здесь на последовательную работу, а не на одновременное обслуживание нескольких пользователей.
Проверял я это реальным циклом: запрос в чат, создание изображения, затем ещё один запрос в чат. Такой переход прошёл успешно.
Это подтвердило нужный мне сценарий: я могу пользоваться обеими функциями через один веб-интерфейс, не останавливая службы вручную перед каждым переключением.
Почему проверки API оказалось недостаточно
Прямой запрос к модели помог проверить вычисления, но не весь пользовательский сценарий.
В Open WebUI первоначальная небольшая модель неправильно выбирала функцию для обычного вопроса. Один такой вызов завершился ошибкой из-за отсутствующего обязательного параметра; действие выполнено не было.
Я изменил режим вызова функций на Legacy и повторил проверку через сам интерфейс.
Для создания картинки также нужно действительно включить режим изображения перед отправкой. Если отправить описание как обычное сообщение, оно уйдёт в текстовую модель.
Поэтому итоговую проверку я проводил через браузер: вход, выбор режима, отправка запроса, получение ответа или картинки. Именно этим путём я собирался пользоваться сервером.
Что произошло после полной перезагрузки
Последней проверкой стала полная перезагрузка сервера.
Для пользовательских служб я настроил запуск без интерактивного входа. Отдельно проверил автозапуск системных компонентов и подключение диска с моделями.
После перезагрузки оба HTTPS-интерфейса стали доступны ещё до первого подключения по SSH. Вручную запускать службы после загрузки не потребовалось.
Затем я проверил конечные функции:
- текстовая модель ответила на запрос;
- вычисление 23 × 17 дало правильный результат — 391;
- DreamShaper создала новое изображение 512 × 512 за 24 шага;
- параметры выбранных моделей сохранились.
Первый запрос после перезагрузки занял около 22,5 секунды, а создание картинки — около 67,2 секунды. В эти результаты входила холодная загрузка моделей с HDD, поэтому они отличаются от последующих запусков с уже подготовленным окружением.
Картинку я получил и просмотрел. Для меня это было более убедительным завершением проверки, чем один статус active у службы.
Как я добавил сервер в мониторинг
В Uptime Kuma я создал отдельные проверки для чата и генерации изображений.
Они обращаются к HTTPS-интерфейсам и проверяют ожидаемые ответы API. Для интерфейса изображений используется авторизация, проверка TLS-сертификатов включена.
После перезагрузки обе проверки дали по два последовательных успешных сигнала с интервалом в минуту.
При этом я разделяю две вещи: доступность приложения и способность выполнить вычисление. Проверка состояния не генерирует картинку каждую минуту. Реальные запросы к моделям я выполнил отдельно.
С каким результатом я закончил
На имеющемся компьютере у меня работают локальный чат и генерация изображений через веб-интерфейс. Они используют одну видеокарту, переключаются между задачами и автоматически поднимаются после перезагрузки.
GTX 1050 Ti с 4 ГБ памяти оказалась пригодна для такого пробного сервера. Ограничения тоже стали понятны: небольшие модели ошибаются, сложные описания картинок выполняются неточно, а загрузка с HDD добавляет ожидание.
Я пока не проверял многопользовательскую нагрузку и не считаю эту конфигурацию универсальным решением. Независимая резервная копия тоже не входила в завершённую проверку запуска.
Но исходную задачу я закрыл: попробовал локальный ИИ на том, что было под рукой, получил ответы и изображения и проверил, что всё это продолжает работать после перезагрузки.