Своя GPU-инфраструктура: когда она выгоднее внешнего API

Почему этот выбор появляется не сразу

На старте почти никто не хочет покупать GPU, поднимать серверы и думать о резерве. Внешний API закрывает задачу быстрее: команда получает доступ к моделям в тот же день и платит только за реальные запросы. Для пилота, внутреннего бота или первой версии продукта это обычно самый разумный путь.

При малом потоке своя GPU-инфраструктура чаще всего убыточна. Если у вас 200 запросов утром и тишина до вечера, карты будут простаивать, а аренда, электричество, администрирование и мониторинг никуда не денутся. В такой ситуации платить за запросы проще, чем держать мощность "на всякий случай".

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

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

Есть и менее заметная часть счета. Когда LLM используют несколько команд, вы платите не только за токены. Деньги съедают повторные запросы после таймаутов, фоновые задачи, тестовые среды, длинные контексты, логирование, ретраи и запас по лимитам. На бумаге цена за миллион токенов может выглядеть нормально. В реальной работе итоговый расход часто выходит заметно выше.

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

Где внешний API начинает проигрывать по деньгам

Внешний API кажется дешевым, пока команда смотрит только на цену за миллион токенов. На практике счет растет из-за вещей, которые редко попадают в первый расчет: повторные запросы, ретраи после таймаутов, A/B-тесты, отладка промптов, прогон eval-наборов и внутренние инструменты, которые тоже ходят в модель.

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

Что учитывать в расчете

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

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

Простой пример: команда запускает чат для клиентов, суммаризацию звонков и ночную обработку архива документов. Днем трафик умеренный, но ночью идут крупные пакетные прогоны. Во внешнем API именно они часто ломают экономику. Пользователи не видят эти расходы, а счетчик крутится без пауз.

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

Для команд в Казахстане и Центральной Азии есть еще один нюанс. Если проекту уже нужны хранение данных внутри страны, аудит-логи, маскирование PII и понятный monthly billing в тенге, часть этих требований все равно придется оплачивать. В такой ситуации локальная инфраструктура или локальный шлюз иногда ближе к вашей фактической экономике, чем кажется в первом Excel.

Внешний API чаще всего начинает проигрывать по деньгам тогда, когда у вас много фонового трафика, мало терпимости к лишним ретраям и достаточно ровная загрузка, чтобы GPU не простаивали.

Где проходит порог по трафику

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

Смотрите не только на общий RPS, но и на RPS по каждой задаче. Короткий диалог, поиск по базе знаний и длинная генерация документов нагружают модель по-разному. Пять запросов в секунду в чат поддержки и пять запросов в секунду на составление отчетов - это не один и тот же трафик.

Обычно хватает четырех метрик:

• средний RPS по часам для каждой задачи
• пиковый RPS в загруженные окна
• средний размер входа и выхода в токенах
• доля часов, когда GPU был бы занят хотя бы на 50-60%

Дальше ищите не самый громкий пик, а базовый поток. Если каждый рабочий день у вас с 10:00 до 19:00 идет ровная нагрузка, которая почти без пауз заполняет хотя бы одну GPU, экономика быстро меняется. Если такой слой трафика держится неделями, собственный кластер уже выглядит не как запасной вариант, а как обычная рабочая схема.

Практичный ориентир простой. Если даже в занятые часы расчетная загрузка одной GPU не дотягивает до 30-40%, внешний API обычно проще и дешевле по усилиям. Когда вы стабильно держите 50-60% по несколько часов в день, уже стоит честно считать оба пути. Когда базовый поток грузит одну или несколько GPU на 70% и выше почти каждый день, своя GPU-инфраструктура часто окупается быстрее, особенно если пики предсказуемы.

Хороший пример - SaaS-команда с тремя сценариями: чат с короткими ответами, поиск по внутренней базе и генерация длинных писем для клиентов. Чат дает высокий RPS, но мало токенов. Поиск работает волнами. А письма идут медленнее, зато держат модель занятой долго. Часто именно длинная генерация, а не чат, первой создает постоянный слой нагрузки, ради которого имеет смысл считать свой кластер.

Суточное среднее легко обманывает. Если днем у вас 8 часов плотной загрузки, а ночью почти тишина, средняя цифра скроет реальные очереди в рабочее время. Поэтому смотрите загрузку по часам и по типам задач.

Во многих случаях лучше всего работает гибридная схема. Ровный базовый поток идет на своих GPU, а редкие пики, тесты новых моделей и нестандартные маршруты остаются на внешнем API. Так проще увидеть, где внешний API уже тесен, а где он все еще удобен.

Когда задержка становится проблемой

Пользователь чувствует не среднюю скорость модели, а паузу до первого ответа. Поэтому мерить нужно не только то, сколько токенов в секунду дает модель, а весь путь от клика до первого токена на экране.

Задержка обычно складывается из нескольких частей:

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

Если смотреть только на время инференса, легко пропустить главную причину тормозов. Например, модель сама думает 300 мс, но еще 500-800 мс уходят на сеть и очередь. Для пользователя это уже "медленно", хотя по внутреннему отчету модель выглядит быстрой.

Для интерактивных сценариев порог наступает рано. В чате люди еще терпят около 1 секунды до первого токена. После 1,5 секунды интерфейс начинает казаться вязким. В голосе и операторских сценариях запас еще меньше: лишние 200-300 мс уже сбивают ритм диалога, а 500 мс часто ощущаются как неловкая пауза.

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

Для команд в Казахстане и Центральной Азии сеть до удаленного региона часто дает ощутимую прибавку к задержке. Если ваши сервисы, база и пользователи находятся внутри страны, а модель отвечает из далекого дата-центра, вы платите временем за каждый запрос. На малом трафике это терпимо. На большом это уже не мелочь, а постоянная потеря в UX.

Смотрите не на один замер, а на хвост задержек. Если в обычный день 700 мс, а в час пик 2-3 секунды из-за очередей, пользователи запомнят именно пики. В этот момент внешний API теряет смысл для сценариев, где ответ должен идти сразу.

Если продукту нужен быстрый первый токен, стабильный p95 и предсказуемая сеть, стоит сравнить внешний API с локальным размещением модели или с инфраструктурой ближе к вашему контуру. Очень часто проблема не в самой модели, а в расстоянии до нее.

Что меняют требования к данным

Иногда своя GPU-инфраструктура нужна не из-за цены, а из-за правил работы с данными. Если компания не может отправлять промпты, ответы или вложения за пределы страны, спор о тарифах быстро теряет смысл. Внешний API в таком случае отпадает сам, даже если он дешевле на тестовом объеме.

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

Что проверить до выбора архитектуры

До выбора архитектуры ответьте на несколько простых вопросов. Могут ли промпты и ответы покидать страну? Где хранятся PII, логи, вложения и следы запросов? Кто получает доступ к данным - провайдер, подрядчик, внутренняя команда? Нужны ли маскирование, аудит и метки AI-контента? Как долго вы обязаны хранить журналы и где именно?

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

Как посчитать переход шаг за шагом

Начните с сырого лога за последние 30 дней. Среднее число запросов в день почти всегда врет: оно скрывает утренние очереди, длинные диалоги и редкие всплески, которые ломают расчет.

Если команда хочет понять, когда своя GPU-инфраструктура уже окупается, считать нужно не "запросы в месяц", а форму нагрузки. Один и тот же объем токенов может стоить по-разному, если часть запросов идет в короткий чат, а часть - в длинный контекст на тяжелой модели.

1. Разделите трафик по моделям, длине входа и выхода, а еще по часам. Отдельно вынесите короткие запросы, длинные документы, пакетные задачи и интерактивные сценарии.
2. Для каждой группы посчитайте не только среднее, но и p95 по запросам и токенам в минуту. Эта цифра лучше показывает, какую нагрузку свои GPU выдержат без очереди и без резких скачков задержки.
3. Найдите постоянную часть нагрузки. Если она повторяется почти каждый день и занимает большую долю счета, ее часто выгодно держать у себя.
4. Оставьте редкие пики, эксперименты с новыми моделями и неожиданные кампании на внешний API. Не стоит покупать железо ради нагрузки, которая появляется два раза в месяц.
5. Сведите все в одну таблицу: цена, задержка, риск простоя, требования по данным, стоимость поддержки, резерв на отказ и отдельная строка для внешнего API на пики.

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

Если для части запросов важно хранение данных в стране, журнал аудита и маскирование PII, считайте эти потоки отдельно. Иногда именно правила по данным меняют решение раньше, чем порог трафика или стоимость внешнего API.

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

Простой сценарий для команды

Представим банк, который запускает два LLM-сценария сразу. Первый помогает операторам колл-центра: подсказывает ответ, ищет нужный регламент, кратко пересказывает историю клиента. Второй ночью проверяет обращения пакетно: ищет рискованные формулировки, сортирует жалобы и отмечает случаи, где нужен ручной разбор.

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

Проблемы начинаются позже. Днем у банка идет ровный поток коротких запросов от операторов. Каждый ответ нужен быстро, иначе сотрудник ждет и разговор с клиентом тянется дольше. Ночью приходит другая нагрузка: пакетные проверки тысяч обращений. Внешний API в такой схеме часто бьет сразу по двум местам - по счету и по задержке в часы пика.

Есть и еще один слой - данные. Если часть обращений, анкет или внутренних комментариев нельзя отправлять за пределы страны, внешний API уже не закрывает весь контур. Тогда команде приходится делить задачи. Чувствительные запросы остаются внутри страны, ночные массовые проверки уходят на свои GPU, а редкие сложные запросы отправляются во внешний API, где нужна более сильная модель.

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

Для команд в Казахстане такой гибридный вариант часто дает самый спокойный баланс. Чувствительные и массовые запросы можно держать на локально размещенных моделях с открытыми весами, а часть трафика отправлять наружу только там, где это допустимо по политике данных.

Ошибки при переходе на свои GPU

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

Часто это выглядит так: чат поддержки обычно обрабатывает 15 запросов в минуту, но два раза в день видит всплеск до 80. Если купить кластер под этот максимум, он будет недогружен почти всегда. В таких случаях разумнее держать запас меньше, а пики закрывать очередями, кэшем или частью трафика через внешний API.

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

Еще одна частая проблема - брать слишком большую модель. Команда тестирует флагман, радуется качеству и сразу строит под него весь расчет. Но в продакшене часто оказывается, что для большей части задач хватает модели заметно компактнее: она дешевле, быстрее и проще в обслуживании. Большую модель лучше оставлять для сложных запросов, а не гонять через нее весь поток.

Без резерва переход тоже ломается быстро. Один узел может выйти из строя в обычный рабочий день. Обновления тоже съедают мощность, потому что часть машин приходится выводить из сервиса. Если кластер рассчитан впритык, любая поломка дает задержки и очередь.

Перед закупкой полезно проверить пять вещей:

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

Последний пункт часто спасает бюджет. Когда команда переносит весь трафик сразу, она теряет недели на отладку логов, батчинга, таймаутов и очередей. Намного спокойнее начать с одного сценария или с 5-10% запросов, а остальное оставить на внешнем API как страховку.

Быстрая проверка перед решением

Своя GPU-инфраструктура окупается редко из-за одной причины. Обычно решение складывается из нескольких простых проверок. Если на три и более пункта вы отвечаете "да" почти без оговорок, внешний API уже пора пересчитать заново.

1. У вас есть ровная ежедневная нагрузка, а не только редкие всплески.
2. Вы часто платите за повтор: похожие вопросы, длинные контексты, ретраи и слабый эффект от кэша.
3. Продукту нужен быстрый ответ и стабильный p95, а лишние 300-700 мс уже мешают пользователю.
4. Данные требуют хранения в стране, аудита и понятного контура доступа.
5. Команда готова обслуживать железо и реагировать на инциденты, а не только считать экономию на бумаге.

Один ответ "да" еще ни о чем не говорит. Четыре подряд уже показывают, что пора считать пилот на своей стороне, а не спорить абстрактно. И даже в этом случае самый разумный следующий шаг обычно не полный отказ от внешних моделей, а смешанная схема.

Что делать дальше

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

Сразу задайте рамки эксперимента: сколько запросов в день вы ждете, какая задержка еще приемлема и какие данные нельзя отправлять во внешний API. Если эти три числа не зафиксировать заранее, решение быстро упрется в споры вместо расчета.

Хороший пилот обычно выглядит так:

1. Выберите один сценарий с предсказуемой нагрузкой на 2-4 недели.
2. Замерьте текущую цену внешнего API по реальным токенам, а не по оценке.
3. Зафиксируйте p50 и p95 по задержке, долю ошибок и стоимость одного успешного ответа.
4. Проверьте, можно ли держать частую нагрузку на моделях с открытыми весами у себя, а редкие пики оставлять снаружи.

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

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

Если команда не хочет менять SDK, код и промпты, можно проверить и промежуточный вариант. Для этого подходит OpenAI-совместимый шлюз вроде AI Router на api.airouter.kz: он позволяет оставить текущую интеграцию и сравнить внешний контур с локально размещенными моделями на одном и том же продукте. Для команд в Казахстане это еще и способ совместить monthly billing в тенге с требованиями к локальному хранению данных, аудит-логам и маскированию PII, если такие требования уже есть.

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