Запуск нейросети на видеокарте: подробный гайд

✅ ШАГ 1 — начнем с установки Forge, через который будем запускать нейросеть

Переходим в репозиторий Forge и кликаем по строке с рекомендованной версией, которая заработает у большинства.

После загрузки архива извлекаем файлы в любой корневой диск системы. Я создал папку Forge и скопировал в нее файлы из архива.

Позже объясню, какие настройки выбирать для генерации, а пока скачаем модели.

Как вести разработку без мощного локального железа

Даже если в статье мы используем GPU с 16 ГБ видеопамяти, на практике далеко не у каждого разработчика есть такое железо под рукой. А что говорить о более тяжёлых конфигурациях?

Вести разработку напрямую на сервере через SSH — неудобно. Но есть простой и очень эффективный лайфхак.

VS Code + Remote SSH

Решение — расширение Remote SSH для VS Code. Оно позволяет работать с кодом на удалённом сервере так, будто проект находится локально.

Windows (PowerShell)

Инфраструктура готова. Дальше — подключение VS Code к серверу, открытие папки проекта и самое вкусное — разработка FastAPI-оболочки с четырьмя локальными нейросетями.

Подготовка инфраструктуры

Прежде чем переходить к коду и нейросетям, нам нужно подготовить базовую инфраструктуру: арендовать сервер с GPU, купить доменное имя и настроить окружение для разработки.

Аренда VPS с GPU

Для примера будем использовать провайдера Hostkey, но общая логика подойдёт для любого хостинга с GPU.

1. Регистрируемся в Hostkey (если аккаунта ещё нет).
2. Заходим в личный кабинет.
3. Переходим в раздел «Новый сервер».
4. Выбираем «Серверы с GPU».
5. Подбираем сервер с минимум 16 ГБ видеопамяти. В качестве операционной системы рекомендую Ubuntu 24.04 — на ней выполнялись все тесты проекта.
6. Арендуем сервер. У Hostkey доступна почасовая оплата, что удобно для тестов и экспериментов.

Подбираем сервер с минимум 16 ГБ видеопамяти. В качестве операционной системы рекомендую Ubuntu 24.04 — на ней выполнялись все тесты проекта.

Арендуем сервер. У Hostkey доступна почасовая оплата, что удобно для тестов и экспериментов.

• IP-адрес сервера;
• имя пользователя;
• пароль.

Сразу копируем IP-адрес сервера. Он нам будет нужен на следующем этапе.

Покупка доменного имени

Домен можно купить у любого регистратора — принципиальной разницы нет. Важно лишь одно: после покупки зайти в DNS-настройки и добавить A-запись, указывающую на IP-адрес вашего сервера.

Это понадобится позже, когда мы будем публиковать FastAPI-приложение наружу.

Показываю пример покупки через сервер (регистратор доменных имен может быть любым, принципиальной разницы нет).

• Регистрируемся на сайте регистратора
• Заходим в меню покупки доменных имен. Первое, что нас интересует — это проверка того, что доменное имя свободно. Проверка доступности домена: /

Заходим в меню покупки доменных имен. Первое, что нас интересует — это проверка того, что доменное имя свободно. Проверка доступности домена: /

Если имя свободно — можно переходить к покупке. Убираем все доп услуги. Нам нужен только домен!

На момент написания статьи работал промокод NY2026, который позволял в купить домен за 1 рубль на год. Проверьте, может ещё работает.

Далее убедитесь, что в настройках домена указаны DNS-серверы и. Эти серверы позволяют гибко привязать свой собственный IP-адрес сервера, без привязки к стороннему хостингу.

Далее добавляем А записи. Сделал отдельную A-запись для доступа к домену через www.

После создания А-записей ждем 15-30 минут и можно настраивать Nginx на сервере (займемся этим немного позже)

Инфраструктура

• VPS
• 8 vCPU
• 32 ГБ RAM
• 240 ГБ SSD
• GPU: RTX A4000 (16 ГБ VRAM)

Стоимость — около 12 000 рублей в месяц (актуальная цена, которая была на конец 2026 года), что делает такой сетап разумной альтернативой облачным ML-API при постоянной нагрузке.

Первичная настройка сервера

Отложим пока купленный домен и перейдём к подготовке сервера для разработки. На этом этапе подключимся к серверу по SSH, обновим пакеты, установим необходимый софт, драйверы и полностью подготовим систему к запуску FastAPI-проекта с четырьмя локальными нейросетями под капотом.

Установка NVIDIA-драйверов

После перезагрузки снова подключаемся по SSH и проверяем, что GPU корректно определяется системой:

Удобный SSH-доступ без пароля

Прежде чем мы нырнём в код, настроим удобный вход на VPS без постоянного ввода пароля. Это сильно упростит жизнь на следующих этапах — особенно когда поделюсь лайфхаком написания кода прямо на сервере, если локального железа нет под рукой.

Подготовка проекта и виртуального окружения

Общая архитектура проекта

• FastAPI выступает в роли HTTP‑оболочки;
• каждая нейросеть инкапсулирована в отдельный модуль;
• модели загружаются через PyTorch + Transformers;
• отдельный менеджер управляет GPU‑памятью и жизненным циклом моделей.

Какие нейросети будем поднимать

В качестве примера мы соберём мультимодальный пайплайн из четырёх моделей, каждая из которых решает свою конкретную задачу:

• DeepSeek OCR — извлечение текста из изображений и PDF (компьютерное зрение);
• Whisper Large v3 (RU) — распознавание русской речи из аудио с преобразованием в текст;
• Qwen2.5-3B — LLM‑модель‑«говорун», которую будем использовать:как чат‑модель;как инструмент нормализации и постобработки текста, полученного от OCR и ASR;
• MMS‑TTS (RU) — озвучивание русского текста.

DeepSeek OCR — извлечение текста из изображений и PDF (компьютерное зрение);

• как чат‑модель;
• как инструмент нормализации и постобработки текста, полученного от OCR и ASR;

Такой подход позволяет принимать на вход изображения, PDF или аудио, приводить данные к аккуратному текстовому виду, при необходимости обрабатывать их через LLM и возвращать результат в виде озвученного ответа.

Основной технический стек

Вся реализация будет выполнена на Python. Глубоких знаний машинного обучения не потребуется, но базовое понимание Python и серверной разработки будет полезно.

• FastAPI — HTTP‑оболочка сервиса;
• torch — базовый фреймворк для работы с моделями;
• transformers — загрузка и управление нейросетями из экосистемы Hugging Face.

transformers — загрузка и управление нейросетями из экосистемы Hugging Face.

Этот стек позволяет держать код компактным, управлять памятью и dtype моделей, а также без лишних зависимостей собрать продакшн-готовый ML-сервис.

В следующем разделе мы переходим от теории к практике и начнём с самого основания — настройки инфраструктуры и сервера под GPU.

Локальные нейросети

• данные остаются внутри собственного контура;
• предсказуемая экономика — вы платите только за железо и электричество;
• полный контроль над моделями и пайплайнами.

предсказуемая экономика — вы платите только за железо и электричество;

• необходимость инфраструктуры;
• порог входа выше, чем у облачных решений.

Из названия статьи уже понятно, что дальше мы будем говорить именно о локальных нейросетях. Причём не в теории, а на практике — с реальным кодом и реальным сервером.

Основных возражений против локального подхода обычно два: «это дорого» и «это сложно поднимать». В рамках этой статьи я постараюсь оба тезиса аккуратно разобрать.

Во-первых, инфраструктура. Сегодня я покажу, как развернуть полноценный мультимодальный ML-сервис из четырёх нейросетей на видеокарте с 16 ГБ видеопамяти. Аренда такого сервера обойдётся примерно в 12 000 рублей в месяц, что уже сравнимо с затратами на облачные API при умеренной нагрузке.

Во-вторых, сложность. Если вы Python-разработчик и уже сталкивались с ML-инструментами, то знаете: запуск даже моделей уровня GPT-4-класса сегодня часто сводится к одной-двум командам благодаря таким инструментам, как vLLM или Ollama.

Метод, который мы будем использовать в этой статье, чуть сложнее «одной кнопки», но зато даёт больше гибкости и контроля. Следуя шаг за шагом, вы сможете запускать практически любые современные модели на относительно доступном железе и собирать из них рабочие продакшн-сервисы.

Облачные нейросети

• быстрая интеграция в любой проект;
• минимум инфраструктурных забот;
• стабильно высокое качество моделей.

• данные компании отправляются на сторонние серверы (что критично для корпоративного сектора, финтеха и госструктур);
• высокая стоимость при масштабировании — многие проекты с активным использованием API столкнулись с тем, что счета за inference растут быстрее бизнеса.

данные компании отправляются на сторонние серверы (что критично для корпоративного сектора, финтеха и госструктур);

высокая стоимость при масштабировании — многие проекты с активным использованием API столкнулись с тем, что счета за inference растут быстрее бизнеса.

Базовые файлы в корне проекта

• FastAPI выступает в роли HTTP‑оболочки;
• каждая нейросеть инкапсулирована в отдельный модуль;
• модели загружаются через PyTorch + Transformers;
• отдельный менеджер управляет GPU‑памятью и жизненным циклом моделей.

.env

Файл с переменными окружения (пути к кешам, настройки памяти, параметры запуска). Мы будем использовать его для конфигурации сервиса без хардкода значений.

Большинство этих библиотек используются напрямую или косвенно самими моделями. Особенно это касается:

• accelerate и bitsandbytes — для управления памятью и квантизацией;
• sentencepiece и protobuf — для корректной загрузки токенизаторов;
• библиотек для работы с аудио и изображениями, которые требуются OCR и ASR моделям.

библиотек для работы с аудио и изображениями, которые требуются OCR и ASR моделям.

Кеши моделей

• models_cache — кеш загруженных моделей;
• offload_cache — временное хранилище для offload‑операций.

Мы вернёмся к ним позже, когда будем говорить об оптимизации использования GPU-памяти.

Структура папки app

• models/ Файлы, отвечающие за загрузку и конфигурацию конкретных нейросетей.
• routers/ FastAPI‑роутеры. Один файл — один логический раздел API (OCR, ASR, LLM, TTS).
• Вспомогательные функции, используемые в разных частях приложения.
• memory_manager.py Менеджер памяти — ключевой компонент всей архитектуры. Он отвечает за:загрузку и выгрузку моделей;контроль использования GPU;предотвращение OOM‑ошибок. Этому модулю мы посвятим отдельный раздел статьи.
• Централизованные конфигурации приложения.
• Точка входа. Здесь происходит сборка FastAPI‑приложения, подключение роутеров и инициализация сервисов.

• загрузку и выгрузку моделей;
• контроль использования GPU;
• предотвращение OOM‑ошибок. Этому модулю мы посвятим отдельный раздел статьи.

Точка входа. Здесь происходит сборка FastAPI‑приложения, подключение роутеров и инициализация сервисов.

Структура проекта может отличаться — это не догма. Важно лишь понять общий принцип связки FastAPI → PyTorch → Transformers и подход к организации кода.

На этом подготовительная часть завершена. Дальше мы начнём разбирать работу ключевых модулей приложения, начиная с архитектуры FastAPI и инициализации моделей.

Далее — как именно мы загружаем и держим несколько нейросетей в GPU-памяти, не убивая сервер.

Архитектура сервиса: как FastAPI управляет нейросетями

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

Общая концепция

В основе проекта лежит FastAPI — асинхронный веб-фреймворк, который в данном случае выступает не ML-инструментом, а оркестратором.

• принимает HTTP-запросы от клиентов;
• маршрутизирует их к нужной нейросети;
• управляет жизненным циклом моделей;
• возвращает структурированный JSON-ответ.

Сами нейросети изолированы от веб-слоя и работают как независимые вычислительные компоненты.

Слой 1: Routers — HTTP API Gateway

Роутеры — это тонкий HTTP-слой, который не знает, как работает модель, а знает только что нужно сделать.

• валидация входных данных;
• получение модели через менеджер;
• запуск инференса;
• формирование ответа.

• async def — FastAPI не блокирует event loop;
• тяжёлые операции выполняются через asyncio.to_thread;
• всегда возвращается предсказуемый JSON.

Структура модуля: один роутер = один раздел API

• имеет собственный URL-префикс;
• отдельный Swagger-раздел;
• singleton-экземпляр модели;
• одинаковый набор endpoint’ов.

Анатомия роутера: на примере OCR

• загружает OCR модель;
• занимает 6–7 GB VRAM;
• может длиться 10–20 секунд.

Конфигурация роутера

• задаёт URL-префикс;
• группирует endpoint’ы в Swagger.

Singleton-экземпляр модели

• загрузка модели = 5–10 секунд;
• потребление = 5–7 GB VRAM;
• создавать модель на каждый запрос — гарантированный OOM.

Основной endpoint

1. Валидация входных данных;
2. Получение модели;
3. Ленивая загрузка при необходимости;
4. Inference в отдельном потоке;
5. Формирование JSON-ответа.

Singleton Pattern

• экономия памяти;
• мгновенные повторные запросы;
• сохранение состояния между вызовами.

Единая структура endpoint’ов

• основной endpoint — функциональность;
• /model-info — статус и метаданные;
• /reload-model — принудительная перезагрузка.

• предсказуемый API;
• простые клиенты;
• единый мониторинг.

Асинхронность без блокировки event loop

• event loop остаётся свободным;
• сервис принимает новые запросы;
• throughput вырастает в несколько раз.

Единая обработка ошибок

• логируют полный traceback;
• возвращают клиенту понятный JSON.

Преимущества модульной структуры роутеров

• Изолированность Можно отключить OCR, не затрагивая ASR или TTS.
• Масштабируемость Новая модель = новый файл + include_router().
• Читаемая документация Swagger становится интуитивным.
• Переиспользование кода Общая логика вынесена в app/.

Слой 2: Model Managers — умные прокси к AI

• загрузка модели занимает 5–20 секунд;
• потребляет 5–10 GB памяти;
• создавать новый экземпляр на каждый запрос — катастрофа.

Жизненный цикл модели

1. Первый запрос к эндпоинту.
2. Менеджер создаёт объект модели.
3. Проверяет: загружена ли она в память.
4. При необходимости — загружает с учётом лимитов.
5. Обновляет last_used.
6. Повторные запросы выполняются мгновенно.
7. После простоя модель автоматически выгружается.

Слой 3: Model Wrappers — единый интерфейс для всех моделей

• унификация работы с Transformers, Whisper, TTS;
• менеджер памяти работает с любой моделью;
• добавление новой модели = новый класс + минимум кода.

Почему именно такая архитектура

1. Singleton для моделей — минимальный overhead и переиспользование памяти.
2. Чёткое разделение Router / Model — API не зависит от конкретной реализации модели.
3. Базовый класс — единый контракт для менеджера памяти.
4. Async‑friendly подход — FastAPI остаётся отзывчивым даже при тяжёлых инференсах.

Singleton для моделей — минимальный overhead и переиспользование памяти.

Чёткое разделение Router / Model — API не зависит от конкретной реализации модели.

Async‑friendly подход — FastAPI остаётся отзывчивым даже при тяжёлых инференсах.

Модуль app/models: унифицированные обёртки над AI-моделями

Перед тем как переходить к управлению памятью, нужно разобраться с ещё одним фундаментальным элементом проекта — модулем app/models. Именно здесь скрыта большая часть «магии», позволяющей управлять разными нейросетями одинаково.

Философия модуля: один интерфейс для разных библиотек

Главная боль при работе с несколькими AI-моделями — разрозненный API. Каждая библиотека живёт своей жизнью:

• Transformers (Hugging Face) — AutoModel.from_pretrained(), ();
• Whisper — (), своя логика работы с аудио;
• TTS — (), фонемы, sample rate;
• PyTorch напрямую — forward(), ручное управление device.

• сложно поддерживать;
• невозможно масштабировать;
• почти нереально оптимизировать по памяти.

Решение: единый интерфейс для всех моделей

Каждая модель — это «чёрный ящик» с тремя кнопками: load(), predict(), unload()

Что внутри модели — Transformers, Whisper, TTS или чистый PyTorch — остальному коду не важно.

Структура модуля app/models

• знает, как загрузить модель;
• умеет выполнять inference;
• корректно управляет памятью;
• безопасно выгружается из GPU / CPU.

BaseModel: контракт для всех моделей

В основе лежит абстрактный класс BaseModel. Он задаёт единый контракт, которому обязаны следовать все модели.

• @abstractmethod Python не позволит создать модель без реализации load(), unload() и predict().
• Общее состояние, self.last_used хранятся в базовом классе и работают одинаково для всех.
• Мониторинг использования Методы get_idle_time_minutes() и should_auto_unload() используются менеджером памяти без знания конкретной модели.

@abstractmethod Python не позволит создать модель без реализации load(), unload() и predict().

Общее состояние, self.last_used хранятся в базовом классе и работают одинаково для всех.

Мониторинг использования Методы get_idle_time_minutes() и should_auto_unload() используются менеджером памяти без знания конкретной модели.

Централизованная конфигурация моделей

Все параметры вынесены в единый конфиг app/ на базе pydantic-settings.

• все настройки в одном месте;
• легко переопределять через.env;
• типизация и валидация;
• singleton — конфиг создаётся один раз.

Пример реализации: DeepSeek OCR

• загрузку через Transformers;
• обработку изображений и PDF;
• OCR-инференс;
• очистку памяти.

• PDF → изображения;
• resize больших картинок;
• batch processing;
• очистку CUDA-контекста.

С обёрткой

Управление памятью: как запустить 4 AI-модели на 16 GB VRAM

Этот раздел — ключевой во всей статье. Я намеренно выбрал сложную конфигурацию: четыре достаточно тяжёлые нейросети и всего 16 GB видеопамяти. Это не демонстрация «в вакууме», а попытка показать реальную ситуацию, в которой оказываются большинство продакшн-проектов.

Если ничего не делать с памятью, такой сервис будет регулярно падать с CUDA out of memory, независимо от того, насколько аккуратно написан код.

Почему это критично

• Qwen 2.5-3B (LLM) — компактная чат‑модель, но всё равно ~4–5 GB VRAM;
• DeepSeek OCR — визуальная модель, на пиках ~6–7 GB;
• Whisper Large‑v3 — крупная ASR‑модель, ~5–6 GB;
• MMS‑TTS — относительно лёгкая, но тоже ~2–3 GB.

Если попытаться держать их все одновременно в памяти, получится: 17–21 GB VRAM при наличии всего 16 GB

Без продуманной стратегии управления памятью приложение будет нестабильным. Поэтому дальше — не «оптимизации ради оптимизаций», а необходимые инженерные решения.

Стратегия управления памятью

В проекте используется многоуровневый подход, который можно свести к четырём ключевым идеям.

Проблема

После обработки запроса модель не освобождает всю память автоматически. В видеопамяти остаются:

• промежуточные активации;
• KV-cache;
• временные тензоры.

• загрузка модели: ~6 GB VRAM;
• после одного инференса: ~7 GB;
• после нескольких запросов подряд: 8–9 GB.

Решение

• экономит 1–3 GB VRAM;
• предотвращает накопление «мусора»;
• резко снижает вероятность OOM при серии запросов.

Гибридное распределение GPU / CPU памяти

Даже с очисткой контекста бывают пики, когда GPU-памяти физически не хватает — особенно при параллельных запросах.

• модель сначала пытается уместиться в GPU;
• если не влезает — часть слоёв уходит в RAM;
• GPU никогда не превышает заданный лимит.

Lazy Loading

• при старте сервиса: ~0 GB VRAM;
• память используется только при реальных запросах.

Auto-Unload

• запрос → загрузка → быстрые ответы;
• 5 минут простоя → выгрузка → 0 GB VRAM;
• новый запрос → повторная загрузка.

Защита от OOM: приоритетная выгрузка моделей

Пользователь может почти одновременно вызвать OCR, ASR и Chat. Все модели начнут загружаться и переполнят GPU.

1. проверяем свободную память;
2. выгружаем самые «долго простаивающие» модели.

Типичное потребление VRAM

• старт приложения: ~500 MB;
• первый OCR‑запрос: ~6–7 GB;
• OCR + Chat: ~10–11 GB;
• 5 минут простоя: ~500 MB.

Именно это и позволяет стабильно запускать мультимодальные AI-сервисы на доступном железе, без серверов с 48+ GB VRAM.

Файл сборки приложения: app/

Если app/models — это бизнес-логика работы с нейросетями, а app/routers — HTTP-интерфейс, то app/ — это точка входа и оркестратор всего приложения.

• создаётся экземпляр FastAPI;
• подключаются все роутеры;
• настраиваются middleware (CORS);
• инициализируются фоновые задачи;
• регистрируются lifecycle-события (startup / shutdown).

Общая структура

1. настройка логирования;
2. lifecycle management (startup / shutdown);
3. создание FastAPI-приложения;
4. middleware (CORS);
5. подключение роутеров;
6. служебные endpoints;
7. entry point для запуска.

Что происходит при запуске

• логируется текущая конфигурация;
• инициализируется и запускается MemoryManager;
• подготавливаются фоновые задачи.

Что происходит при завершении

• корректно останавливается MemoryManager;
• все загруженные модели принудительно выгружаются из памяти;
• освобождаются GPU и CPU ресурсы.

• гарантированный cleanup ресурсов;
• отсутствие утечек GPU-памяти;
• корректное завершение в production-среде.

Глобальный MemoryManager

MemoryManager — это фоновый оркестратор, который следит за тем, какие модели используются, и автоматически выгружает простаивающие.

• запускает его;
• останавливает;
• доверяет ему контроль над моделями.

Создание FastAPI-приложения

Подключение роутеров

• модульность — любой роутер можно отключить одной строкой;
• масштабируемость — новый AI‑модуль = новый роутер;
• прозрачность — весь API виден сразу.

/health

• статус приложения;
• наличие GPU;
• текущее потребление памяти.

• liveness / readiness probes;
• автоматического мониторинга.

/models/status

• какие модели загружены;
• сколько времени простаивают;
• текущее состояние GPU-памяти.

• отладки OOM-проблем;
• понимания нагрузки;
• capacity planning.

Entry point для запуска

• запускать приложение напрямую (python -m);
• использовать uvicorn или gunicorn в production.

Порядок инициализации приложения

1. uvicorn:app
2. импорт модулей и конфигурации
3. создание FastAPI instance
4. подключение middleware
5. регистрация роутеров
6. lifespan STARTUP
7. приложение готово принимать запросы
8. lifespan SHUTDOWN при остановке

Запуск и тестирование приложения

• настроенный сервер с GPU;
• собранное FastAPI-приложение;
• архитектура, менеджер памяти и все модели.

Теперь запускаем сервис и проверяем, что всё действительно работает так, как задумано.

Подготовка окружения

Открываем терминал на сервере (через VS Code Remote SSH или обычный SSH) и переходим в директорию проекта.

Шаг 1. Активация виртуального окружения

Шаг 2. Установка зависимостей

Установка займёт 5–10 минут, так как PyTorch и CUDA-библиотеки достаточно тяжёлые.

Базовый запуск (development)

• :app — путь к FastAPI instance;
• —host 0.0.0.0 — слушаем все интерфейсы;
• —port 8000 — порт сервиса;
• —log-level info — читаемые логи.

• нет ошибок в логах;
• Memory Manager успешно стартовал;
• приложение слушает порт.

Health Check

• приложение живо;
• GPU доступна;
• память используется корректно.

Тест OCR

• загружает OCR модель;
• занимает 6–7 GB VRAM;
• может длиться 10–20 секунд.

Тест ASR и TTS

• /asr/transcribe — распознавание речи;
• /tts/synthesize — синтез аудио в WAV.

Проверка авто-выгрузки моделей

Модели будут автоматически выгружены, а GPU-память освобождена — это и есть ключевая цель всей архитектуры.

✅ ШАГ 3 — Генерация мемов

2 — Выбор самой модели. Из выпадающего списка выбираете ту, что скачали.

5 — Сюда вписываем промпт (негативный промпт не нужен, только позитивный)

Разрешение генерации можете выставлять такое, какое будет работать стабильно и быстро. Не мучайте свою милую видеокарту!

a coffin labeled «SD3» laying in a field of grass, A woman is shown holding a sledgehammer striking a large spike into the coffin, The scene should convey a dramatic, intense atmosphere with strong emphasis on the coffin and the hand

Как это работает

• VS Code устанавливает на сервер небольшой server‑агент.
• Все операции (терминал, git, запуск скриптов, линтеры) выполняются на VPS.
• В локальном VS Code вы просто редактируете файлы и управляете проектом.

Все операции (терминал, git, запуск скриптов, линтеры) выполняются на VPS.

В локальном VS Code вы просто редактируете файлы и управляете проектом.

Что нужно сделать

1. Установить расширение Remote — SSH (-ssh).
2. Убедиться, что SSH‑доступ к серверу без пароля работает:ssh myserverОбъяснить с
3. В VS Code нажать F1 → Remote-SSH: Connect to Host… → выбрать подготовленный ранее сервер (myserver).

В VS Code нажать F1 → Remote-SSH: Connect to Host… → выбрать подготовленный ранее сервер (myserver).

После подключения выбрать папку проекта на сервере в которой уже установлено виртуальное окружение — она откроется как обычный workspace.

Дисклеймер перед разработкой

Сразу небольшой дисклеймер. В проекте получилось достаточно много кода. Как это обычно бывает: начинаешь с «пары эндпоинтов», а дальше архитектура постепенно обрастает вспомогательными модулями, обработкой ошибок, управлением памятью и прочими необходимыми вещами.

В рамках статьи я не буду разбирать каждую строчку кода. Вместо этого мы сосредоточимся на ключевых и нетривиальных моментах:

• архитектуре приложения;
• загрузке и инициализации моделей;
• управлении GPU-памятью;
• интеграции PyTorch + Transformers с FastAPI.

Для удобства изучения дальнейшей информации — советую сразу клонировать проект себе и открыть его в IDE в котором вы привыкли работать:

Если по ходу чтения появятся вопросы или захочется обсудить реализацию с другими разработчиками, приглашаю в мой Telegram-канал «Лёгкий путь в Python». Там я публикую дополнительные материалы, исходники учебных проектов и разбираю практические кейсы. На момент написания статьи сообщество насчитывает более 5000 участников.

Приступаем к разработке

• уже арендован VPS с GPU;
• установлен NVIDIA-драйвер;
• настроен удобный доступ по SSH;
• VS Code подключён к серверу через Remote SSH.

Публикация сервиса: systemd

Если на предыдущем этапе вы убедились, что приложение корректно запускается, модели загружаются и тестовые запросы отрабатывают без ошибок, можно переходить к завершающим шагам:

1. перевести FastAPI‑приложение в постоянный продакшен‑режим;
2. обеспечить автозапуск и автоматический рестарт при сбоях;
3. подготовить сервис к публикации наружу под доменным именем.

Начнём с systemd — это самый простой и надёжный способ управлять сервисом на сервере без лишних технологий.

Почему systemd

• автозапуск приложения при старте сервера;
• автоматический перезапуск при падениях;
• централизованные логи;
• контроль состояния сервиса (active / failed).

Шаг 1. Останавливаем запущенное приложение

Если FastAPI сейчас запущено вручную через uvicorn — остановите его (Ctrl+C) и убедитесь, что порт 8000 свободен.

Шаг 2. Проверяем структуру проекта

• есть файл app/;
• виртуальное окружение.venv создано и содержит uvicorn.

Шаг 3. Создаём systemd unit-файл

Для GPU-приложений рекомендуется —workers 1. Несколько воркеров означают несколько процессов, каждый из которых будет:

• иметь собственные экземпляры моделей;
• дублировать потребление VRAM;
• быстро привести к OOM.

Что мы получили на этом этапе

• FastAPI‑приложение, работающее в продакшен‑режиме;
• автозапуск при старте сервера;
• автоматический рестарт при сбоях;
• централизованные логи через systemd;
• стабильная работа с GPU и памятью.

Публикация наружу: Nginx + домен + HTTPS

На этом этапе FastAPI-приложение уже стабильно работает через systemd и доступно на localhost:8000. Осталось сделать последний шаг — открыть сервис во внешний мир:

• привязать доменное имя;
• настроить Nginx как reverse-proxy;
• включить HTTPS с помощью Let’s Encrypt.

Шаг 1. Установка Nginx и Certbot

Шаг 2. Проверка DNS

Шаг 3. Базовый конфиг Nginx (без HTTPS)

Шаг 4. Подключаем HTTPS через Certbot

• автоматически выпустит SSL-сертификат;
• изменит конфиг Nginx;
• настроит редирект с HTTP → HTTPS.

Проверка

Тестируем API в Swagger

На момент прочтения статьи ссылка скорее всего неактивна — VPS использовался только для демонстрации в этой статье.

Приступаем к тестам!

1. Перейдите по ссылке — увидите интерактивную документацию со всеми эндпоинтами
2. Нажимайте «Try it out» для каждого метода
3. Заполняйте параметры и жмите Execute
4. Проверяйте ответы в правой панели — статус 200 и корректный JSON?

Где такой сетап действительно полезен

• корпоративных сервисов, где важна конфиденциальность данных;
• внутренних инструментов (документооборот, распознавание речи, ассистенты);
• стартапов, которым дорого масштабироваться на облачных API;
• экспериментальных проектов, где важен полный контроль над моделями;
• образовательных и R&D‑задач.

внутренних инструментов (документооборот, распознавание речи, ассистенты);

Главный вывод, который я хотел донести: локальные нейросети — это больше не «дорого и сложно». При грамотной архитектуре и управлении ресурсами они становятся вполне доступным и практичным инструментом.

Что можно улучшать дальше

• добавить streaming‑ответы для Chat и ASR;
• прикрутить очередь задач (например, Redis + background workers);
• добавить авторизацию и rate limiting;
• вынести модели на отдельные GPU при росте нагрузки;
• подключить метрики и мониторинг (Prometheus / Grafana).

✅ Дополнительный шаг для самых любознательных

👋 Сейчас я пишу плагины для Figma с помощью нейросетей, параллельно изучая Front-end — рассказываю в тг-канале

Сейчас у нас в сообществе очень весело, спасибо нейронке FLUX и ее талантливым разработчикам!

Обратная связь и обсуждение

• было ли полезно;
• какие моменты стоило раскрыть глубже;
• какие темы по локальным нейросетям интересны дальше.

Если хотите обсудить архитектуру, задать вопросы или посмотреть другие практические проекты — приглашаю в мой Telegram-канал «Лёгкий путь в Python». Там уже более 5000 участников, я регулярно публикую исходный код, разборы и дополнительные материалы к статьям.

Ссылка на исходники проекта — в начале статьи, всё в открытом доступе.

Спасибо, что дочитали до конца. Надеюсь, этот материал поможет вам увереннее чувствовать себя в мире локальных AI-решений и не бояться поднимать нейросети на собственном железе.

Серверы с видеокартами NVIDIA — от доступных моделей начального уровня до профессиональных Tesla, в дата-центрах в России и Европе.

• fastapi
• whisper
• deepseek
• deepseek ocr
• python
• локальный ии
• Локальные LLM VPS
• Локальный AI сервис
• OCR ASR TTS сервер
• CUDA PyTorch FastAPI

• Блог компании HOSTKEY
• Программирование
• Искусственный интеллект
• Python
• Natural Language Processing

Оставляя почту, я принимаю Политику конфиденциальности и даю согласие на получение рассылок

Ответы на популярные вопросы о запуске нейросетей на GPU

Вопрос: Можно ли запустить нейросеть на обычной игровой видеокарте?
Ответ: Да, большинство современных игровых видеокарт NVIDIA (серии GTX и RTX) с достаточным объемом VRAM (от 6 ГБ) поддерживают запуск локальных нейросетей через фреймворки вроде PyTorch или TensorFlow.

Вопрос: Что обязательно нужно установить перед запуском нейросети на GPU?
Ответ: Обязательны драйверы NVIDIA, CUDA Toolkit (совместимая версия с вашей картой и фреймворком) и cuDNN. Затем — сам фреймворк (PyTorch/TensorFlow) с поддержкой GPU.

Вопрос: В чем разница между локальным и облачным запуском нейросети?
Ответ: Локальный запуск — на своем железе, требует мощной видеокарты, но дает полный контроль и конфиденциальность. Облачный — аренда GPU-сервера (VPS), не требует своего железа, но зависит от интернета и тарифа.

Вопрос: Сколько видеопамяти (VRAM) нужно для запуска современных LLM?
Ответ: Зависит от размера модели. Малые модели (7B параметров) могут работать на 8-12 ГБ VRAM. Крупные (70B) требуют 40+ ГБ VRAM или использования техник квантования, загрузки по частям.

Вопрос: Что такое Forge и зачем он нужен?
Ответ: Forge (например, Ollama WebUI Forge) — это удобная оболочка или менеджер для запуска и управления локальными LLM-моделями. Он упрощает установку, загрузку моделей и предоставляет веб-интерфейс.

Вопрос: Можно ли использовать AMD видеокарты для запуска нейросетей?
Ответ: Да, но поддержка хуже. Потребуется ROCm (аналог CUDA от AMD) и проверка совместимости фреймворков. Процесс настройки сложнее, чем для NVIDIA.

Вопрос: Что делать, если не хватает видеопамяти для модели?
Ответ: Можно использовать квантование (загрузка модели с меньшей точностью), offloading (часть модели в оперативную память) или streaming (загрузка по слоям).

Вопрос: Зачем нужен Nginx и HTTPS при публикации нейросервиса?
Ответ: Nginx выступает обратным прокси, балансируя нагрузку и повышая безопасность. HTTPS (через Certbot) шифрует трафик между клиентом и сервером, что критично для передачи данных.

Вопрос: Что такое systemd и зачем создавать unit-файл?
Ответ: Systemd — система инициализации в Linux. Unit-файл позволяет запускать ваш нейросервис как фоновую службу, которая автоматически стартует при загрузке сервера и перезапускается при сбоях.

Вопрос: Обязательно ли арендовать VPS с GPU или можно начать локально?
Ответ: Начинать можно локально на своей видеокарте для тестов и изучения. Аренда VPS с GPU нужна для публичного доступа к сервису, круглосуточной работы или если локального железа недостаточно.

Памятка: ключевые шаги для успешного запуска

1. Определите цель: какая нейросеть (LLM, генерация изображений, распознавание) и для каких задач вам нужна.
2. Оцените требования: проверьте необходимый объем VRAM и совместимость модели с вашим железом или выберите облачный GPU.
3. Для локального запуска: убедитесь, что у вас установлены актуальные драйверы NVIDIA.
4. Установите необходимый стек ПО: CUDA Toolkit, cuDNN, Python, фреймворк (PyTorch/TensorFlow).
5. Рассмотрите использование менеджера/оболочки (Ollama, Forge) для упрощения работы с моделями.
6. Скачайте или подготовьте веса (weights) нужной нейросетевой модели.
7. Настройте виртуальное окружение Python для изоляции зависимостей проекта.
8. Напишите или скопируйте минимальный скрипт для загрузки модели и выполнения вывода (inference).
9. Протестируйте работу модели на небольшом примере, отслеживая загрузку GPU и потребление VRAM.
10. Для публикации сервиса: арендуйте VPS с GPU (если нужно), настройте сервер и безопасность (SSH, фаервол).
11. Перенесите код и модель на сервер, повторите шаги по настройке окружения.
12. Настройте