Четыре вопроса о ваших ограничениях и честный ответ, стоит ли вам крутить инференс самим.
Свой open-weight на собственном железе выглядит дешевле в табличке и ощущается как контроль. На практике это постоянное инженерное обязательство — GPU, масштабирование, аптайм, обновления версий, MLOps, — которое большинство команд сильно недооценивает. Так что честный дефолт — это хостинговый API, а свой хостинг — то, во что вас должно *вынудить*: данными, которые по закону не могут покинуть ваш контур; реальной нуждой владеть жизненным циклом модели; или экономикой на очень большом стабильном объёме — и только если у вас есть операционные мускулы это тянуть. Когда чувствительна лишь часть трафика, ответ обычно — разделить. Что бы вы ни выбрали, держите модель за заменяемым швом, чтобы выбор не был навсегда.
Ответьте на все вопросы, чтобы увидеть рекомендацию.
Все варианты вкратце
Звать хостинговый API
GPU, масштабирование и обновления крутит кто-то другой; вы делаете вызов и получаете ответ. Это верный дефолт для подавляющего большинства продуктов: никакой своей инфраструктуры, мгновенный доступ к передовым моделям, и вы платите только за использованное. Не берите инференс в работу, пока вас к этому что-то не вынудит.
Выбирайте это, когда
Ваши данные можно слать вендору
Объём скромный, скачущий или ещё растёт
Вы предпочли бы строить продукт, а не крутить платформу для моделей
Компромиссы
Вы платите за токены — следите за счётом по мере роста объёма
Вы едете на роадмапе вендора: смены цен, лимиты, депрекейты
Чувствительные данные покидают ваш периметр — табу в регулируемых доменах
Свой хостинг open-weight модели
Вы крутите модель на инфраструктуре, которую контролируете, — своё облако, свои серверы, свои правила. Оправдано, когда жёсткое ограничение вынуждает и у вас есть операционная способность это потянуть: регулируемые данные, которые нельзя выпускать; реальная нужда владеть жизненным циклом модели; или экономика, переворачивающаяся на очень большом стабильном объёме. Мощно — и реальное постоянное обязательство.
Выбирайте это, когда
Чувствительные данные нельзя слать третьей стороне
Нужно закрепить версию, глубоко дообучить или гарантировать доступность
Объём настолько большой и стабильный, что владеть железом окупается
Компромиссы
GPU, масштабирование, аптайм и обновления теперь ваша забота, навсегда
Без реальной MLOps-способности экономия испаряется в операционные расходы и простои
Вы отвечаете за то, чтобы держать темп по мере выхода лучших открытых моделей
Гибрид — разделить по чувствительности
Часть, которая должна остаться приватной, маршрутизируйте на инфраструктуру, которую контролируете, а всё остальное шлите в API. Вы получаете лёгкость API для основной массы трафика и держите чувствительный кусок у себя — не взваливая полноценную self-hosted платформу, которую тянуть нечем. Часто прагматичный ответ, когда чувствительна лишь часть данных.
Выбирайте это, когда
Часть трафика регулируема или чувствительна, но изрядная часть — нет
Контроль нужен над частью системы, а не над всей
Вы можете крутить точечное приватное развёртывание, но не весь инференс-стек
Компромиссы
Два пути: построить, маршрутизировать между ними и держать согласованными
Надо правильно классифицировать запросы — и fail closed на чувствительных
Всё ещё немного self-hosting: приватный кусок несёт операционную нагрузку