Compute crunch пришёл: как считать экономику LLM в 2026

от автора

Build, Buy или Hybrid — рассуждаем о подходах к TCO. Статья — приглашение к диалогу и обсуждению, не экспертный нарратив.

«Я говорил» или что случилось с тарифами на LLM API

Два крупнейших API-провайдера одновременно сменили риторику. Anthropic ввёл usage-based billing для агентных фреймворков — плата за токены вместо фиксированных подписок. Часть сторонних обёрток потеряла возможность работать через flat-rate тарифы. OpenAI параллельно ввёл гибкое корпоративное ценообразование для Enterprise, Business и EDU-планов — стоимость подписки теперь масштабируется с объёмом потребления, а не фиксируется на уровне seat.

Тренд последних двух лет («API дешевеет каждый квартал») не отменился, но получил важную оговорку. Цена за токен в прайсах действительно падала: за 2023–2025 годы стоимость миллиона токенов GPT-4-класса снижалась, но в 2026 году ключевой метрикой для бюджета становится не цена за токен, а стоимость решения задачи.

Несколько причин:

  1. Reasoning-режимы съедают output. Opus 4.7, GPT-5.4 Thinking и аналоги на сложных задачах генерируют скрытую цепочку рассуждений — вы её не видите в ответе, но платите как за output-токены. Точных публичных данных о коэффициенте роста output-токенов в документации провайдеров нет — ни Anthropic, ни OpenAI не публикуют таблицу «effort level → overhead токенов». По наблюдениям разработчиков, работающих с GPT-5.4, reasoning effort поддерживает пять уровней (none, low, medium, high, xhigh), каждый следующий уровень увеличивает output. Типичная оценка индустрии от 1.5-2x на medium до 3-4x на xhigh, но это эмпирика, а не спецификация. Лучше всего измерять на своих логах.

  2. Новые токенизаторы более прожорливые. Opus 4.7 вышел с обновлённым токенизатором, который может давать до 35% больше токенов на том же тексте. По данным официального release notes Anthropic — 1.0–1.35× в зависимости от типа контента; верхний конец диапазона чаще всего на коде, структурированных данных и не-английском тексте. При неизменном прайсе это означает рост счёта: одинаковый текст стал стоить дороже не потому что поднялась цена токена, а потому что токенов стало больше.

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

При неизменной цене за токен эти эффекты вместе дают рост итоговой затрат, значительно превышая запланированные бюджеты. Параллельно compute crunch: спрос на GPU растёт быстрее поставок, H100 и B200 для РФ и ЦА доступны с лагом по времени поставок и существенной наценкой. Self-host начинает появляться в бюджетах средних компаний не как «оптимизация», а как hedge против ценовых шоков и supply-рисков.

Возникают вопросы как строить фреймворк принятия решений.

Три режима нагрузки

Для себя я выделил три режима(или подхода), влияющих на расчеты и планы.

Эксперименты. PoC, гипотезы, prompt engineering, A/B на качество. Здесь нужен максимум качества для поиска работающего решения. Почти всегда API (даже дорогой frontier), минимум инвестиций в инфру. Исключение — когда эксперимент изначально направлен на оценку конкретной локальной модели: например, нужно понять, справляется ли Llama 3.3 70B с вашей доменной задачей. Тогда вам действительно нужна локальная инфра — но именно для эксперимента, а не для production. Лид ML-команды, который просит GPU-кластер «попробовать идею» без внятного обоснования, что эта идея требует именно локальной модели — сомнительно.

Production workload. Предсказуемый трафик, жёсткий SLA, чувствительные данные, стабильное качество. Вот здесь имеет смысл считать: при каком объёме API перестаёт быть оптимальным. Тут open-source конкурирует с API не по потолку качества, а по полу стоимости на «достаточно хорошем» уровне.

Устойчивость. Защита от ценовых шоков (Anthropic только что показал, как быстро это случается), supply-риска (rate limits, очереди, изменения ToS), regulatory shock (регулятор требует локализации). В 2024 году это было на последнем слайде «возможные риски» в презентации, сейчас в 2026 уже часто отдельная строка в бюджете.

Пример сценарного расчета TCO (как подход)

Цель — реализовать логику расчёта и границы применимости, а не дать инженерную спецификацию под ваш случай. Реальная стоимость всегда зависит от ваших логов и микса задач с регуляторной рамкой.

Базовые допущения для кейса «100 млн токенов/мес»

  • Token mix: 70M input + 30M output. Скорее подойдет для RAG и аналитических задач. Для генеративных задач (маркетинг, синтез контента) сдвигайте в сторону output.

  • Task mix: 80% простых задач (классификация, extraction, summarization), 20% reasoning-heavy (анализ, агенты, сложная генерация с контекстом).

  • Эффект reasoning-режимов: на high/xhigh effort модель генерирует в существенно больше output-токенов. Точная цифра зависит от вашего промпта и типа задачи. Провайдеры не публикуют официальных таблиц. Лучше всего измерить на своих логах перед тем как закладывать в бюджет.

  • Инфляция токенизатора: 1.15× как усреднение для смешанного русско-английского контента, например при использовании Opus 4.7.

  • Накладные расходы (overhead): +15–30% на retry при 5xx, fallback на более дорогую модель, cache miss.

  • GPU utilization для self-host: 60% как baseline production. Ниже 40% — экономика ломается.

  • Амортизация железа: 36 месяцев.

  • Ставки команды: fully loaded, $100K/год для глобальной команды, $60K для РФ, $40K для ЦА.

Формула для API

TCO_tokens = (input × price_in + output × price_out × effective_mult)             × 12 × tok_inflation × (1 + overhead)

где:

effective_mult = simple_share + reasoning_share × reasoning_multiplier

effective_mult — это средневзвешенный множитель output’а по всему трафику. Простые задачи идут с множителем 1.0, reasoning-задачи — с множителем 2–4. Результат: средний коэффициент, на который нужно умножить «наивный» output для получения реальной стоимости. Важно: reasoning multiplier применяется только к output-токенам, не к общей сумме.

Полный TCO сверх токенов включает FTE поддержки, compliance и ML Ops инструменты — считаем их отдельно.

Пример расчёта для Frontier API (Opus 4.7, $5/$25)

  • effective_mult = 0.80 × 1 + 0.20 × 2.5 = 1.30

  • Месячная база: 70M × $5 + 30M × $25 × 1.30 = $350 + $975 = $1,325

  • Годовая: × 12 = $15,900

  • С токенизатором 1.15: $18,285

  • С overhead 20%: $21,942

  • Плюс FTE поддержки (0.2 × $100K = $20K) и compliance (~$15K): ~$57K/год

Диапазон при более агрессивных допущениях (50% reasoning, multiplier 4×, overhead 30%): до ~$75K/год.

Используйте эту модель, как ориентир.

Пример TCO по пяти опциям развёртывания

Годовой TCO при базовом сценарии (100M токенов/мес, 80/20 mix, Global регион, типичная команда).

Статья расходов

Frontier API

Mid-tier API

Hosted OSS

Self-host 14B

Self-host 70B

Токены / инференс

$22K

$8K

$3K

GPU (амортизация)

$18K

$55K

FTE (люди)

$20K

$20K

$40K

$200K

$350K

ML Ops инструменты

$23K

$45K

$45K

Compliance

$15K

$15K

$20K

$45K

$45K

Итого годовой TCO

~$57K

~$43K

~$86K

~$308K

~$495K

Стоимость на 1M токенов

$48

$36

$72

$257

$413

Почему 60–75% стоимости self-host — это люди, а не железо

Это контринтуитивно, поэтому приводим пример расчета.

Возьмём Self-host 70B с vLLM (3× A100, умеренный регион):

  • GPU: 3 × $2,200/мес × 12 = $79,200/год

  • FTE: 3.5 инженера × $100K = $350,000/год

  • ML Ops инструменты: $45,000/год

  • Compliance: $45,000/год

  • Итого: ~$519K/год

Доля железа: $79K / $519K = 15%. Доля людей: $350K / $519K = 67%.

Почему нужно именно 3.5 FTE? Это не абстрактная цифра. Self-host LLM в production включает:

  • Деплой и конфигурация инференс-стека (vLLM, батчинг, квантизация): разово 2–4 недели DevOps

  • Eval pipeline: без систематической оценки качества вы не поймёте, когда модель деградировала. Это отдельный ML-инженер минимум на 0.5 ставки

  • Model updates: Llama 3.3 → Llama 4 — это не замена одной строки в конфиге. Тест на eval-наборе, ре-тюнинг промптов, A/B, откат если сломалось. Цикл 2–4 недели, каждые 3–6 месяцев

  • Security и compliance: аудит логов, контроль доступа, сертификация. Особенно тяжело для регулируемых вертикалей

  • Дежурство на инфре: GPU-ноды падают, VRAM OOM при пиках, rate-limiter в вашей же инфре

Для 14B-модели, где задачи проще, — 2.0 FTE и TCO ~$308K. Для 70B — 3.5 FTE.

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

Вывод: прежде чем считать GPU, посчитайте людей. Self-host становится экономически выгодным только там, где FTE уже есть и не добавляются ради LLM — то есть у команд с зрелой ML-платформой, где эти люди уже занимаются другими задачами.

Врезка: Self-host как инфраструктура анонимизации — и что это меняет в расчёте

Это отдельная тема, заслуживающая отдельной статьи. Здесь — короткий контур сценария.

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

Сценарий: у вас есть документы с ПДн клиентов или коммерческой информацией, которые нельзя отправлять наружу в исходном виде. Локальная 7–14B-модель работает как preprocessing-слой: находит и заменяет чувствительные сущности (имена, ИНН, суммы, реквизиты) на синтетические плейсхолдеры, отправляет деперсонифицированный текст в frontier API, получает ответ — и конвертирует плейсхолдеры обратно в реальные данные.

Что это меняет в расчёте:

  • Self-host 7–14B для анонимизации стоит существенно меньше, чем self-host для основного инференса. При 2× A100 с vLLM и 80% utilization — порядка $30–50K/год

  • Frontier API при этом остаётся основным «мозгом» — и его стоимость мы уже посчитали (~$57K/год для 100M токенов)

  • Итоговый TCO этого гибрида: ~$90–120K/год против ~$308–495K для полного self-host

Это по факту гибрид — и скорее всего, именно к такому сценарию придёт большинство компаний из регулируемых вертикалей. Сейчас тоже активно развивается класс готовых решений и конкретный микс будет сильно отличаться от организации к организации: одним хватит простого NER-шлюза на 7B, другим нужен более сложный препроцессинг с пониманием контекста на 14B, кто-то и вовсе ограничится простыми ML-классификаторами (fastText, SetFit) и библиотеками для анонимизации персональных данных (Microsoft Presidio, DataFog) 

Главное, что нужно понять про этот сценарий: он не отменяет инфраструктурный оверхед self-host. Нужны полноценная ML-инфра, DevOps-поддержка, compliance и security? потому что вопрос закрытия рисков и соответствия регуляторике никуда не уходит. Но офлоад основной inference-нагрузки в frontier при этом обходится не так дорого, как мы уже посчитали.

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

Матрица решений

Бинарный «build или buy» мёртв. Решение принимается по четырём осям:

Ось 1 — Объём (токенов/мес)

  • <10M — почти всегда API. Self-host не окупится ни при каких параметрах без regulatory-требований

  • 10–500M — зона решения, зависит от остальных осей

  • 500M+ — self-host или hosted OSS начинают выигрывать по unit economics при зрелой команде

Ось 2 — Регуляторный периметр

  • Данные можно отправлять наружу — API

  • Данные чувствительны, но допустим DPA — API с enterprise-контрактом (Anthropic и OpenAI дают BAA/DPA)

  • Данные за периметр нельзя (ЦБ, 152-ФЗ, КИИ) — self-host или гибрид с анонимизацией

Ось 3 — Latency и SLA

  • P95 >2 секунд допустим — API

  • P95 <500 мс, 99.9% uptime — self-host даёт больше контроля

  • Streaming для UX без жёстких SLA — API с fallback

Ось 4 — Зрелость команды

  • Нет ML-команды — API

  • 1–2 ML-инженера — Hosted OSS как промежуточный шаг

  • 3+ ML + DevOps с GPU-опытом — self-host реалистичен

Pure API. Стартап, PoC, нерегулируемый домен, <10M токенов/мес. Оптимизируйте prompt и выбор модели.

Hosted OSS. Нужна гибкость модели, бюджет ограничен, держать железо не хочется. Together AI, Fireworks, DeepInfra (глобально), Selectel и MTS AI (в РФ). Экономика open-source без операционного бремени.

Hybrid — дефолт 2026 для средних и крупных. Frontier API для reasoning-heavy (10–20% задач) + локальная SLM или mid-tier API для рутины (80–90%). Сюда же входит паттерн анонимизации, описанный выше.

Full self-host. Регулируемые вертикали, >500M токенов/мес, зрелая команда, критичная IP-защита.

Региональный контекст: СНГ и ЦА

Регуляторика — не checkbox, а cost driver. 152-ФЗ в РФ, закон о ПДн в КР (2024), аналогичные нормы в РК и РУз — конкретное ограничение: если LLM-пайплайн обрабатывает ПДн клиентов, отправка в Anthropic или OpenAI будет просто невозможна.

GPU — дефицит, наценка и логистический оверхед. Получение высокопроизводительных GPU (H100, A100) для российских и центрально-азиатских компаний усложнено санкционным режимом. NVIDIA и большинство западных производителей чипов подпадают под экспортные ограничения; поставки идут через посредников с соответствующим логистическим и compliance-оверхедом — отсюда наценка 20–40% к глобальным ценам, нестабильность поставок.

Код и API — особый случай

Код редко является персональными данными, и многие организации готовы отправлять его во внешние API.

Практическое правило:

  • Рефакторинг, баг-фикс, генерация тестов → mid-tier или локальная 7–14B. Экономия 5–10× без заметной потери качества

  • Архитектурные решения, security review, сложная генерация с контекстом 100K+ → Frontier API с контролем объёма

  • Гибридный подход: черновики — локально; финальный review — через Frontier с логированием

Чек-лист перед принятием решения

Что измерить:

  1. Текущий и прогнозный объём токенов (input + output, по задачам)

  2. Доля задач, закрываемых mid-tier моделью vs требующих frontier

  3. Регуляторный статус данных: можно ли отправлять наружу, при каких условиях

  4. Доступные ML/DevOps FTE и их текущая загрузка

  5. Целевой SLA (latency P50/P95, uptime)

  6. Текущий API-spend и динамика за 6 месяцев

  7. Стоимость downtime: сколько бизнес теряет за час без LLM-функциональности

Итог

Правильный вопрос не «подписка или железо», а какую часть AI-стека вы готовы контролировать — и хватит ли людей, чтобы этот контроль не стал новым источником риска.

Self-host «ради экономии на токенах» в 2026 году — плохой кейс почти для всех. Self-host ради контроля данных, latency и supply-hedge — другой разговор.

Почитать:

Дисклеймер: все цифры — directional-оценки для планирования. Перед инвестиционными решениями валидируйте на логах вашего реального трафика.

ссылка на оригинал статьи https://habr.com/ru/articles/1024850/