MVP стартапа с ИИ на своём сервере: с чего начать

MAATRIX

У вас есть идея продукта с ИИ-фичей внутри, дедлайн до демо-дня и бюджет, который считается в тысячах, а не в десятках тысяч долларов. Первый инстинкт — взять API OpenAI или Anthropic и быстро собрать прототип. Это правильно ровно до момента, когда вы не знаете, сколько у вас будет пользователей и сколько токенов они сожгут — а на старте вы этого не знаете почти никогда. Разберём, когда свой сервер оказывается дешевле и надёжнее для MVP, и с чего конкретно начинать техническую часть.

Почему API по токенам — плохая ставка на старте

Модель оплаты за токены удобна ровно тогда, когда вы можете прогнозировать нагрузку. У стартапа на этапе MVP прогноза нет — есть гипотеза. Вы не знаете, придёт ли 50 пользователей в первую неделю или 5000 после случайного поста в соцсетях. У API-биллинга здесь два неприятных сценария:

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

Свой сервер переворачивает эту логику: вы платите фиксированную сумму в месяц независимо от того, сколько запросов обработала модель — хоть десять, хоть десять тысяч (в пределах мощности железа). Для MVP, где важнее всего продержаться до следующего раунда или до первых платящих клиентов, предсказуемый фикс почти всегда выгоднее переменной ставки при неопределённом объёме.

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

Где именно ломается экономика токенов

Возьмём условный пример: чат-бот поддержки или генератор текста как фича внутри продукта, 200 активных пользователей в месяц, каждый делает 15-20 запросов со средним ответом на 500-800 токенов. Это не заоблачные цифры, но они уже дают ощутимый счёт у облачных провайдеров — и счёт растёт линейно с ростом пользователей, без потолка.

Сервер с открытой моделью (например, через Ollama) масштабируется иначе: до определённого предела нагрузки стоимость не меняется вообще, она упирается в тариф сервера, а не в число запросов. Дальше этого предела встаёт вопрос апгрейда тарифа или добавления второго сервера — но это шаг, который вы делаете осознанно, а не сюрприз в конце месяца.

Есть нюанс, о котором честно нужно сказать сразу: открытые модели, которые реально тянет один сервер за разумные деньги (7B-14B параметров), уступают по качеству топовым закрытым моделям вроде GPT-5 или Claude Opus. Для узкой задачи — классификация, извлечение данных, генерация по шаблону, чат по FAQ — разрыв часто не критичен. Для задач, требующих сложных рассуждений или творческого письма, разрыв может быть заметен. Это ключевой критерий, к которому мы вернёмся в разделе про переход на облако.

С какого тарифа стартовать

Для MVP не нужен мощный GPU-сервер — это оверинжиниринг на этапе, когда вы ещё проверяете гипотезу, а не обслуживаете тысячи одновременных запросов. Разумная отправная точка:

Важная оговорка: без GPU модель работает на CPU, и это заметно медленнее, чем в облаке у крупного провайдера — ответ может занимать несколько секунд вместо долей секунды. Для MVP, где вы проверяете саму ценность фичи, а не борьбетесь за миллисекунды отклика, это обычно приемлемо. Если продукту принципиально нужна низкая задержка уже на этапе MVP — сразу смотрите в сторону облачного API или GPU-тарифа, не пытайтесь сэкономить там, где экономия ломает продукт.

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

Минимальный стек: три инструмента за вечер

Для MVP с ИИ-фичей вам не нужен сложный ML-пайплайн — нужен работающий инференс, к которому удобно подключить фронтенд и продуктовую логику. Практичный минимальный стек:

1. Ollama — локальный запуск модели с готовым API-эндпоинтом. Ставится одной командой, отдаёт OpenAI-совместимый интерфейс, так что фронтенд и бэкенд можно писать так же, как если бы вы работали с облачным API.

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama serve

1. LiteLLM — прокси-гейтвей поверх Ollama (и любых других провайдеров), который даёт единый OpenAI-совместимый эндпоинт, ключи доступа, лимиты и логирование запросов. Это то, что превращает "у меня модель крутится локально" в "у меня есть API, который можно безопасно подключить к продукту и переключить на другого провайдера одной строкой конфига".

model_list:
  - model_name: mvp-model
    litellm_params:
      model: ollama/llama3.1:8b
      api_base: http://localhost:11434

Установка и базовая настройка подробно разобраны в статье как установить и настроить LiteLLM на VPS.

1. n8n — если в MVP есть автоматизации вокруг модели (обработка заявок, скрейпинг данных, отправка уведомлений, склейка нескольких шагов "получить данные → прогнать через модель → сохранить результат"), n8n экономит недели разработки этой логики руками. Он тоже спокойно ставится на тот же сервер и подключается к LiteLLM как к обычному API. Пошагово — в статье как поднять n8n для ИИ-автоматизаций на сервере.

Все три сервиса умещаются на один сервер начального тарифа и поднимаются за один вечер, если действовать по шагам из перечисленных статей — не нужно отдельно нанимать ML-инженера ради MVP.

Когда переходить на облачный API

Свой сервер — это оптимизация под бюджет и предсказуемость расходов, а не универсальный ответ на все случаи. Есть ситуации, где переход на облачный API оправдан именно на этапе MVP, а не после:

• Демо для инвесторов. На питче качество и стабильность ответа модели работают на вашу репутацию сильнее, чем экономия пары сотен долларов в месяц. Если фича — это витрина продукта, а не фоновая утилита, лучше показать её на топовой модели через API, чем рисковать неровным ответом от локальной 7B на CPU в момент, когда на вас смотрит инвестор.
• Задача требует сложных рассуждений. Если фича завязана на многошаговую логику, код, сложный анализ документов — разрыв в качестве между открытой моделью на 7-8B и топовым закрытым API становится заметен пользователю, а не только вам на тестах.
• Нагрузка стала предсказуемой и большой. Когда у вас уже есть данные о реальном трафике и юнит-экономика API при этом объёме считается и сходится — переход с фикса на переменные расходы может снова стать выгоднее, особенно если пиковые нагрузки редки, а провайдер даёт скидки за объём.

Здесь стоит держать в голове, что это не выбор "либо-либо" навсегда, а решение, которое можно и нужно пересматривать по мере роста продукта. У нас есть отдельный разбор с более подробным сравнением: локальная модель против облачного API — что выгоднее и когда.

Гибридная схема: не выбирать одно на всё

На практике большинство MVP с ИИ выигрывают не от выбора "или сервер, или API", а от гибрида, где LiteLLM выступает переключателем между провайдерами без переписывания кода продукта:

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

Настраивается это на уровне конфига LiteLLM: разные модели регистрируются под разными именами, а в коде продукта вы просто указываете, какую модель вызвать для какого сценария. Плюс такой схемы — вы платите за облако только там, где качество реально критично, а весь фоновый объём остаётся бесплатным сверх фикса за сервер. Минус — усложняется инфраструктура и появляется точка отказа: если сервер с LiteLLM ляжет, ляжет и доступ к облачной модели тоже, поэтому для продакшена (не для MVP) стоит думать про резервирование заранее.

Частые вопросы