Свой инференс против API по токенам: с какого месячного объёма выгоднее

MAATRIX

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

Как устроена стоимость API по токенам

Провайдеры API считают деньги за миллион токенов, и почти всегда раздельно для входа и выхода:

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

Итоговый месячный счёт линеен по объёму — это и есть ключевое свойство, которое делает сравнение вообще возможным:

C_api(V) = (V_in / 1 000 000) × P_in + (V_out / 1 000 000) × P_out

где V_in и V_out — месячный объём входных и выходных токенов, P_in и P_out — цена за миллион токенов у выбранного провайдера для выбранной модели. Обратите внимание: конкретные значения P_in и P_out вы должны взять из актуального прайс-листа провайдера на момент расчёта — они регулярно меняются, отличаются между моделями одного и того же провайдера в разы, и любые цифры, зафиксированные в статье сегодня, устареют к моменту, когда вы её прочитаете. Единственное, что стабильно — сама структура: линейный рост счёта с объёмом, без верхнего предела, и без скидки на масштаб, если вы не переходите на корпоративный тариф с индивидуальными условиями.

Практическое следствие: посчитайте V_in и V_out за последний полный месяц из логов или биллинг-панели провайдера, подставьте актуальные P_in/P_out — и вы получите не абстрактную, а свою реальную точку на кривой C_api(V).

Фиксированная стоимость своего инференса

Аренда GPU-сервера под собственный инференс — это фиксированный ежемесячный платёж C_server, который не зависит от того, сколько токенов вы сгенерировали в этом месяце — 10 тысяч или 10 миллионов, пока вы не упёрлись в пропускную способность конкретного сервера. Это принципиально другая экономика: у API стоимость привязана к использованию, у своего сервера — к владению мощностью.

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

У фиксированной стоимости есть потолок применимости — сервер не резиновый. У любой связки «модель + железо + движок инференса» есть предельная пропускная способность в токенах в секунду, и она задаёт верхнюю границу месячного объёма, который сервер способен обслужить:

V_max = throughput_tok_s × 86400 × 30 × utilization

где throughput_tok_s — устойчивая пропускная способность вашей связки модели, квантования и движка (vLLM, TGI, TensorRT-LLM и подобные — конфигурацию для инференса можно поднять по методике из материала про установку vLLM на сервере), а utilization — доля времени, когда сервер реально занят полезной работой, а не простаивает (обычно заметно меньше 1.0 из-за неравномерности нагрузки в течение суток). Точное значение throughput_tok_s для вашей модели и объёма контекста нельзя взять из статьи — это надо измерить бенчмарком на конкретной конфигурации, потому что оно зависит от размера модели, длины контекста, батчинга запросов и типа GPU. Как только V > V_max, C_server перестаёт быть константой — вам нужен второй сервер, и фиксированная стоимость становится ступенчатой функцией, а не прямой линией.

Методика нахождения точки перелома

Точка перелома — это объём токенов V*, при котором C_api(V*) = C_server. Дальше методика простая:

1. Возьмите фактический V_in и V_out за представительный месяц — не пиковый и не самый тихий, а типичный для текущей стадии продукта.
2. Разложите объём на долю входных и выходных токенов — обычно она у вас достаточно стабильна от месяца к месяцу (например, диалоговый ассистент с длинным контекстом и коротким ответом будет иметь совсем другое соотношение, чем суммаризация длинных документов).
3. Подставьте текущие P_in, P_out вашего провайдера и постройте C_api(V) как прямую, проходящую через ноль с наклоном, заданным средневзвешенной ценой токена для вашего соотношения входа и выхода.
4. Возьмите цену аренды подходящего под вашу модель GPU-сервера как горизонтальную линию C_server.
5. Точка пересечения этих двух линий на графике «стоимость / объём токенов в месяц» и есть V* — если ваш реальный месячный объём выше неё, аренда своего сервера дешевле; если ниже — платить за API выгоднее.

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

Здесь V* = C_server / P_avg = 1000 / (10 / 1 000 000) = 100 000 000. Логика формулы не меняется от того, какие числа вы подставите — только сама точка V* сдвигается пропорционально соотношению цены аренды и цены токена. Если ваш проект генерирует условные 10 миллионов токенов в месяц при таких вводных — аренда сервера пока не окупается, разница копится в резерв на будущий рост. Если 300 миллионов — вы уже переплачиваете за API кратно стоимости аренды.

Отдельно стоит посчитать не только точку перелома, но и запас по времени окупаемости первоначальных трудозатрат на миграцию (см. следующий раздел) — если объём токенов растёт быстро, разумно ориентироваться не на текущий V, а на прогноз через 2-3 месяца, чтобы не переносить инфраструктуру дважды.

Что рушит простую формулу на практике

Линейная модель выше — упрощение, и в реальности на неё влияет несколько факторов, которые стоит явно учесть, а не игнорировать:

• Неравномерность нагрузки во времени. API прекрасно держит любые всплески — вы платите за фактически потреблённые токены. Свой сервер с фиксированной мощностью либо простаивает в тихие часы (вы платите за неиспользуемую мощность), либо не справляется в пиковые (запросы встают в очередь или отклоняются). utilization в формуле V_max — это ваш инструмент честно отразить эту неравномерность, а не игнорировать её.
• Множественность моделей. Если продукту нужна одна большая модель для сложных задач и лёгкая модель для простых, у API это просто два разных вызова с разной ценой. На своём сервере — это либо два развёрнутых инстанса (двойная фиксированная стоимость), либо компромисс с одной моделью на все случаи.
• Скидки провайдера на объём и контекстное кэширование могут заметно снизить наклон C_api(V) относительно списочной цены — если у вас большая доля повторяющегося контекста (RAG с постоянной базой документов, длинные системные промпты), пересчитайте P_in с учётом реальной, а не номинальной цены.
• Длина контекста напрямую снижает throughput_tok_s, а значит и V_max вашего сервера — при увеличении окна контекста в разы пропускная способность падает не линейно, и это надо перемерить, а не экстраполировать.
• Батчинг запросов. Пропускная способность на своём сервере сильно зависит от того, сколько запросов вы можете объединять в один батч на GPU одновременно — при низкой параллельности реальный throughput_tok_s окажется заметно ниже паспортных цифр вендора GPU или бенчмарков «из интернета», посчитанных при идеальном батчинге.

Скрытая цена экспертизы: что вы покупаете вместе с API

Формула выше сравнивает только деньги, но решение «свой сервер против API» — это ещё и решение «кто несёт ответственность за то, что модель работает». API снимает с вас целый пласт забот за свою наценку:

• разворачивание и обновление модели — провайдер сам выкатывает новые версии, вам не нужно тестировать регрессии при обновлении весов;
• масштабирование под нагрузку — вы никогда не думаете о V_max, провайдер абсорбирует любой всплеск (в пределах rate limit вашего тарифа);
• отказоустойчивость и SLA — если один регион провайдера недоступен, трафик обычно переключается прозрачно для вас;
• безопасность инфраструктуры — патчинг движка инференса, изоляция арендаторов, защита от атак на уровне провайдера — не ваша задача.

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

• подобрать связку модель + квантование + движок инференса под доступную видеопамять и целевую задержку;
• настроить батчинг, мониторинг очереди запросов и алерты на деградацию (падение throughput_tok_s из-за фрагментации VRAM, зависшего процесса, перегрева — это реальные отказы, которые не видны в логах API, потому что там их просто нет);
• следить за обновлениями весов модели и движка инференса самостоятельно, оценивая регрессии перед раскаткой;
• держать резервную ёмкость или план деградации на случай, если сервер выходит из строя, а SLA такого же уровня, как у крупного API-провайдера, самостоятельно обеспечить сложнее и дороже.

Это не аргумент против своего инференса — это честная часть уравнения. Если у команды уже есть MLOps-экспертиза или процесс её взять на аутсорс за разумные деньги, C_server в формуле должен включать и эту стоимость поддержки, а не только счёт за аренду железа. Если экспертизы нет и её негде взять быстро — точка перелома V* может быть математически пройдена, а решение оставаться на API — всё равно рациональным, потому что риск простоя без экспертизы дороже разницы в счёте.

Практический алгоритм для вашей команды

Пошагово, без абстракций:

1. Выгрузите фактический расход токенов за последние 1-3 месяца из биллинг-панели провайдера API — отдельно V_in и V_out, и посмотрите на тренд, а не только на последнее число.
2. Возьмите текущий прайс-лист провайдера для той модели, которую реально используете (не флагманской, если в проде работает младшая модель) — посчитайте фактическую средневзвешенную цену токена P_avg по вашему соотношению входа и выхода.
3. Определите модель-кандидата для self-hosting — открытую модель сопоставимого качества под вашу задачу, и оцените, сколько видеопамяти нужно под неё в нужном квантовании.
4. Забенчмаркайте throughput_tok_s на тестовой аренде GPU-сервера — на реальных промптах вашего продукта, а не на синтетических бенчмарках из чужих статей, и посчитайте V_max.
5. **Посчитайте V*** по формуле выше, сравните с фактическим и прогнозным объёмом на 2-3 месяца вперёд.
6. Добавьте к C_server стоимость поддержки — время инженера на развёртывание, мониторинг и обновления, даже если это доля ставки, а не отдельный найм.
7. Примите решение с запасом, а не впритык — если V* пройдена с запасом в 2-3 раза, миграция окупится даже с учётом ошибок настройки на старте. Если запас 10-20%, вы рискуете потратить силы на миграцию ради экономии, которую съест первая же неделя простоя из-за незрелого процесса.

Для большинства команд разумный путь — не резкий переход, а гибрид: перевести на свой сервер основной, предсказуемый поток запросов (там, где объём выше V* и нагрузка стабильна), а пиковые и редкие запросы — например, к более мощной модели для сложных случаев — оставить на API, где переменная цена не страшна из-за низкого объёма. Это снижает и капитальный риск миграции, и зависимость от единственного канала.

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