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

Во-первых, self-hosting — это постоянные затраты, а API — переменные. Значит, ответ зависит не от цены за токен, а от того, насколько плотно вы это железо загрузите. Во-вторых, токены вообще никто не покупает как цель. Покупают решённые задачи. А модели очень по-разному тратят токены на одну и ту же задачу.

И вот что изменилось за последний год: открытые модели догнали топ лидербордов. На SWE-bench Verified DeepSeek V4 Pro берёт 80,6 %, Kimi K3 — 93,4 %, вплотную к лучшим закрытым. То есть во многих сегментах выбор «своё железо vs API» перестал быть выбором по качеству — он стал чисто экономически/операционным. Ниже это то, как я предлагаю его считать.


Part 1. Токены и точка безубыточности

Блендированная цена API

Провайдеры берут за вход и выход по-разному — выход обычно в 3–5 раз дороже (у Claude Opus 4.8 это $5 против $25 за миллион токенов). Если у вашей нагрузки соотношение входных и выходных токенов равно r, то блендированная цена за миллион токенов такая:

P_{\mathrm{API}} = \frac{p_{\mathrm{in}} \cdot r + p_{\mathrm{out}}}{r + 1}

Здесь важно, что r зависит от задачи и двигает цену в 2–3 раза. Генерация поверх длинного контекста (RAG, r \approx 20$) выходит куда дешевле, чем длинная генерация с нуля (r \approx 1).

Модель

вход / выход, $/млн

r=1 (длинная генерация)

r=10 (агентное кодирование)

Claude Opus 4.8

5,00 / 25,00

15,00

6,82

Kimi K3

3,00 / 15,00

9,00

4,09

DeepSeek V3.2

0,229 / 0,343

0,286

0,239

Цены проверены при подготовке текста (Claude Opus 4.8 — $5/$25; Kimi K3 — $3/$15; DeepSeek — $0,229/$0,343, кэш $0,074, на 25 июля 2026).

Во что обходится своё железо в месяц

Обозначим за M полную месячную стоимость инфраструктуры. Если арендуете — это ставка × часы. Если владеете — амортизируем:

 M = \frac{C_{\mathrm{hw}}}{L} + E

где C_{\mathrm{hw}} — цена железа, L — срок амортизации в месяцах, E — энергия и охлаждение.

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

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

Порядок цифр:

  • Нода 8×H200 HGX при покупке — примерно $320–420 тыс. (типично ~$370 тыс., то есть ~$46 тыс. за GPU).

  • Амортизация на 36 месяцев → ~$10,3 тыс./мес до учёта $E$. С учётом остаточной стоимости ~25 % через три года → ~$7,7 тыс./мес.

  • Аренда той же ноды: долгосрочный резерв — $14,40–20/час (~$10,5–14,6 тыс./мес), on-demand у гиперскейлеров — $36–56/час (~$26–41 тыс./мес).

  • Энергия: ~8 кВт биллинговой мощности (7,84 кВт GPU при PUE 1,4) × 730 ч ≈ 5 840 кВт·ч/мес → при $0,10–0,15 за кВт·ч это $580–880/мес по члену E

Собственно безубыточность

Своё железо за миллион токенов сравнивается с API при месячном объёме

V^{*} = \frac{M}{P_{\mathrm{API}}} \quad \text{[млн токенов/мес]}

Но целевой объём бессмыслен, если железо физически его не вывозит. Месячная ёмкость при устойчивой пропускной способности T (токенов/с) и утилизации U \in [0,1]:

 V_{\max} = T \cdot U \cdot \frac{3600 \cdot 730}{10^{6}} = 2{,}628 , T U

Отсюда self-hosting оправдан только когда

 T \cdot U ;\geq; \frac{M}{2{,}628 , P_{\mathrm{API}}}

УтилизацияU приоритетна. ПриU = 0{,}3 требуемая пиковая пропускная способность утраивается — и API становится дешевле независимо от того, какая модель «лучше».

График 1
График 1

Граница безубыточности в плоскости(U, T) для трёх блендированных цен API (r=10), при M \approx 14,000$/мес (амортизированная 8×H200). Смысл картинки: чтобы вытеснить дорогой API (Claude Opus 4.8, P\approx$6{,}82), хватает скромной пропускной способности; а конкурировать с дешёвым API (DeepSeek V3.2, P\approx$0{,}24) на своём железе почти нереально — требуемая T на два порядка выше.


Part 2. Стоимость решённой задачи

Цена за токен всё ещё исходит из того, что модели потокенно взаимозаменяемы. Это не так: они отличаются и долей решённых задач, и числом токенов на попытку. Считаем честнее:

 C_{\mathrm{task}} = \frac{C_{attempt}​}{q}

Если используется несколько попыток, то вместо стоимости одной попытки подставляется суммарная стоимость всех попыток.

гдеC_{attempt} — стоимость одной попытки (токены на попытку по цене из формулы выше или по self-hosted-эквиваленту,q — доля решённых задач.

Долюq берём из опубликованных результатов SWE-bench Verified. И вот тут надо остановиться и разобрать что это за число такое и почему оно не совсем корректно.

Опубликованныеq между собой несопоставимы. Их получают в разных обвязках: Kimi K3 меряют на своём KimiCode, Claude Opus мерят на Claude Code, OpenAI на Codex или OpenHands. Агентный бенчмарк тестирует не модель в вакууме, а всю систему «модель + харнесс». Разброс только от смены обвязки — 10–26 баллов, и это перекрывает разницу между самими моделями. Добавьте сюда разное число попыток и разные token budget. То есть если я просто поставлю вендорскиеq в столбик, поделю и объявлю победителя — это будет ровно та подмена, за которую я весь текст ругаю цену-за-токен.

Поэтому таблицу ниже строю честно, двумя приёмами. Первое: рядом с каждымq пишу, в каком харнессе он получен, — чтобы несопоставимость была видна. Второе: в колонкеC_{\mathrm{task}} я намеренно фиксирую бюджет токенов (1,5 млн,n=1) — не потому что он одинаков в жизни, а чтобы изолировать один эффект: как цена и solve-rate двигают стоимость задачи при прочих равных. Реальные пер-модельные бюджеты токенов надо мерить — про это отдельный разговор.

Модель

q (SWE-bench Verified)

харнесс / условия

цена/млн, $ (r=10)

основа цены

C_{\mathrm{task}}

Claude Opus 4.8

0,886

вендор (Claude/Codex)

6,82

API

$11,54

Kimi K3

0,934

вендор (KimiCode)

4,09

API

$6,57

DeepSeek V3.2

0,731

лидерборд

0,239

API (deepseek)

$0,49

DeepSeek V3.2

0,731

тот же

функция $U$

self-hosted

$4,37 †

C_{\mathrm{task}} посчитан при фиксированном бюджете 1,5 млн токенов/попытку иn=1 — это не реальная стоимость задачи, а индекс «цена × (1 / solve-rate)» при прочих равных. self-hosted приU=0{,}5; это не константа, а функция утилизации (график 2).

Как читать эту таблицу. Это не рейтинг моделей: из-за разных харнессов строки закрытых моделей между собой напрямую не сравнимы, и я специально не пишу «X победил Y». Единственное честное сравнение здесь — две строки DeepSeek, API против self-hosted. У них общийq и общий бюджет токенов, эффект харнесса сокращается, и разница — чисто про экономику размещения. Вот это и есть результат на данный момент; всё остальное в таблице — референсные якоря для контекста.

И этот кусок ещё раз показывает смысл первой части. Смотрите на две строки DeepSeek: self-hosted (приU{=}0{,}5) — $4,37, а свой же API — $0,49. Своё железо не обгоняет дешёвый API той же модели ни при какой реалистичной утилизации — потому что провайдер крутит это железо на несравнимо большей загрузке, чем вы. Self-hosting выигрывает только у дорогих закрытых API: свой DeepSeek дешевле Claude примерно сU \gtrsim 0{,}2 и дешевле Kimi K3 — сU \gtrsim 0{,}35. Существующие же сравнения тарифицируют открытые модели по ставкам хостинг-провайдера и тем самым прячут эту зависимость отU.

График 2
График 2

Self-hostedC_{\mathrm{task}} как функция утилизацииU (кривая) против трёх API-линий: Claude Opus 4.8 ($11,54), Kimi K3 ($6,57) и того же DeepSeek через API ($0,49). Видно главное: кривая опускается ниже дорогих закрытых API с ростомU, но никогда не опускается ниже дешёвого API той же модели. Иллюстративно: 1,5 млн токенов/попытку,n=1,T=5000 ток/с — заменить измеренными.

Пара оговорок: первое это то, чтоq с SWE-bench переносится на задачи по Python-репам, но не на произвольную нагрузку — числа будут другие. Второе:n > 1 означает время человека на ревью между попытками. Так что мойC_{\mathrm{task}} — нижняя оценка, и к моделям с большимn добрее.


Part 3. Что формула не ловит

А теперь самое интересное — то, из-за чего решение часто принимают вообще мимо всех этих цифр.

Резидентность данных. Когда выбор вообще не про деньги, пример: данные клиента не могли покидать его контур. Это выбивает API целиком, по любой цене. Когда упирается сюда — части 1 и 2 просто нерелевантны.

Привязка к вендору и волатильность цен. Цены и доступность моделей меняются по расписанию провайдера, а не вашему. Свежий пример структурного риска: в июле 2026 Moonshot AI приостановила приём новых подписок на Kimi K3 примерно через 48 часов после запуска — спрос превысил доступную GPU-ёмкость. Модель формально «есть», а пропускной способности под неё — нет, и это вне вашего контроля.

Асимметрия апдейтов. Мы как клиенты API получаем обновление модели бесплатно, инженерно. Команда на self-hosting за каждый апгрейд платит полным циклом переквантизации и переоценки.

Амортизация железа. Свои ускорители дешевеют по темпу релизов NVIDIA, а не по вашему бухгалтерскому графику. По рыночным оценкам нода 8×H200 сохраняет ~25 % стоимости через три года (~$92,5 тыс. остаточной на систему за $370 тыс.), то есть теряет ~$277,5 тыс. за срок владения. И задаёт эту траекторию выход следующего поколения (B300 и далее), а не ваш план амортизации.

Вывод

Из этого всего вопрос "API или self-hosting" — это не вопрос стоимости токена. Это вопрос загрузки инфраструктуры, требований к данным и операционных ограничений. Пока своё железо простаивает значительную часть времени, дешёвый API будет выигрывать практически всегда.

Комментарии (14)


  1. rPman
    26.07.2026 11:30

    Такое ощущение что вы делали расчеты исключительно теоретически, без оглядки на практику и реальность.

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

    Почему кеш важен, потому что self-hosted решения стоят не за токены, а за время работы, а кеш токены время практически не требуют (миллисекунды против минут) и математика их стоимости завязана на нехватку памяти под кеш при многопользовательском использовании (модель провайдеров). Если вы один пользователь, для вас кеш почти бесплатен (до определенного уровня).

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

    И ещё пример, swe и прочие агенты тупо складируют всю информацию в контекст, до его исчерпания (режим диалога, это кстати сильно использует кеширование), затем запускают сжатие и... скорее всего после этого идёт провал. А вот к примеру letta сжимает контекст постоянно, это ломает кеш, увеличивает токены генерации но контекст не растет так сильно. Эти два противоположных подхода будет стоить по разному у провайдера и на своем железе.

    Если вы запускали swe-bench на своем железе, поделитесь пожалуйста полным логами и статистикой, что бы делать расчет правильно.


    1. dreary_muskrat Автор
      26.07.2026 11:30

      Спасибо за комментарий!

      Про кэш - действительно упустил этот момент. В self-hosted мы платим за время работы железа, а не за токены, поэтому для одного пользователя закешированный префикс практически ничего не стоит, пока хватает KV-памяти. У API-провайдеров «стоимость кэша» появляется в основном потому, что память приходится делить между большим количеством клиентов. Помимо этого Я специально прайсил API в самом дорогом виде: без кэша, батча и роутинга, => в самом выгодном для self-hosting сценарии. И раз даже так API выигрывает, вывод не ломается

      Насчёт параллелизма тоже согласен. Сколько реальной конкуренции получится набрать, зависит не только от модели, но и от самой задачи и того, как устроен агент. Иногда железо загружено , а иногда часть времени простаивает, именно это я и пытался спрятать в коэффициент утилизации U.

      Что касается цифр в self-hosted, тут всё честно: я специально пометил их как иллюстративные, потому что полноценный end-to-end прогон SWE-bench на своём железе ещё не делал. Придумывать результаты не хочу. Когда сниму нормальные замеры (cache hit rate, prefill/decode, достигнутая конкуренция и всё остальное), выложу их во второй части. Если есть замечания по методике - с удовольствием обсужу заранее.


  1. Plazik
    26.07.2026 11:30

    На своём железе запускают квантованные версии, а не исходные. Соответственно расходы будут в 2-4 раза меньше.


    1. uranik
      26.07.2026 11:30

      Это для дома может копейки считают, а крупной конторе смысл экономить на дистиллятах?


      1. funca
        26.07.2026 11:30

        Нода 8×H200 HGX при покупке — примерно $320–420 тыс. (типично ~$370 тыс., то есть ~$46 тыс. за GPU).

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


  1. ToxaBes
    26.07.2026 11:30

    Part 3. Что формула не ловит

    Формула не ловит, что для огромного количества задач в бизнесе вообще не нужны топовые модели, достаточно 30-80B моделей в Q8. Их качества после файнтюнинга под специфику конкретного бизнеса хватает с головой для решения поставленных задач.


    1. funca
      26.07.2026 11:30

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


    1. dreary_muskrat Автор
      26.07.2026 11:30

      Полностью согласен. Статья только про верхний сегмент лидербордов, а для массы бизнес-задач 30 80B в Q8 с файнтюном под домен закрывают эти задачи. Но все же статья не о них


  1. bashka-pro
    26.07.2026 11:30

    Мамкин Майнер, почему нет ссылки на твой проект? Нече что у тебя будет 20-59 токенов в секунду? А скорее 7?


    1. dreary_muskrat Автор
      26.07.2026 11:30

      Вы, похоже, перепутали иллюстративный параметр с результатом измерений. В статье единственное упоминание T = 5000 ток/с прямо сопровождается пометкой «иллюстративно, заменить измеренными». Это не замер производительности, а параметр для примера на графике. Чисел 7 или 20–59 ток/с в статье вообще нет


  1. BborlasS
    26.07.2026 11:30

    Плюсую за 2 раздел с харнессами.

    По расчёту две придирки.

    Первая: API взят в самом невыгодном для него виде. Ни кэша промпта, ни batch, ни роутинга по моделям. При r=10:1 весь счёт — это вход, а кэш бьёт именно во вход. Плюс базлайн по Opus: в проде никто не гоняет весь трафик на топовой модели, обычно дешёвая + фронтир на сложном хвосте. На ваших же цифрах: против Opus порог ~1,3 млрд токенов/мес, против микса с Haiku — уже ~6,4 млрд, с кэшем ещё вдвое. Порог сдвигается почти в десять раз. То есть вы свой же вывод недооценили и он получается жёстче.

    Вторая: утилизацию нельзя крутить свободно, её держит латентность. При U→1 очередь съедает p95, реальный потолок 60-70%. И, кажется, это и есть ответ на вопрос, почему провайдер выигрывает: не «нагрузка больше», а он держит высокую загрузку, не ломая latency, за счёт тысяч тенантов. Один арендатор так не умеет.

    И момент по энергии: PUE применён к одним GPU (5,6×1,4), а остальная нода потерялась — CPU, вентиляторы, сеть. По факту забор 10-11 кВт, с PUE ~14-15. На итог это не влияет, но там ещё и модель оплаты другая: при аренде стойки в дата-центре платят не за фактические киловатт-часы, а за оговорённый лимит мощности. А 15 кВт на стойку - это уже серъезно.


    1. dreary_muskrat Автор
      26.07.2026 11:30

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


      1. BborlasS
        26.07.2026 11:30

        С нетерпением буду ждать!


  1. viiko
    26.07.2026 11:30

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