Глава 16. Экономика LLM-систем

Учебник «Большие языковые модели»

Заключительная глава — о деньгах. LLM-система, в отличие от обычного локального правила, часто имеет заметную предельную стоимость каждого исполнения. Она зависит от модели, объёма токенов, инструментов, задержки и архитектуры и иногда различается на порядки. Соберём воедино приёмы, разбросанные по книге, и добавим главный расчёт: API против собственного железа.

16.1. Из чего складывается счёт

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

def token_cost(input_tokens, cached_input_tokens, output_tokens, rates):
    """rates: $/млн для input, cached_input и output."""
    cached = min(max(cached_input_tokens, 0), input_tokens)
    uncached = input_tokens - cached
    return (uncached * rates["input"]
            + cached * rates["cached_input"]
            + output_tokens * rates["output"]) / 1_000_000

Пример с условными, не рыночными ставками $3 за миллион входных, $0,30 за кэшированные и $15 за выходные токены: конвейер обрабатывает 500 заметок в день; на заметку — промпт 3000 токенов (из них 2000 — стабильная инструкция) и ответ 300 токенов. На «большой» модели без оптимизаций: 500 × (3000×3.00 + 300×15.00)/10⁶ ≈ $6,75/день. Если все стабильные 2000 токенов действительно попадут в кэш, получится $4,05/день. Пакетная скидка считается отдельным сценарием по условиям конкретного API: не предполагайте, что она складывается с кэшем, пока это не указано в тарифе. В итог добавьте нетокенные сборы и повторные вызовы. Более дешёвую модель применяйте только после eval (глава 13).

16.2. Лестница удешевления

Приёмы удобно перебирать от простых к трудоёмким. Не звать модель: где хватает регулярного выражения, словаря или правила, детерминированный код обычно дешевле, быстрее и проще проверяется; у него тоже есть стоимость разработки и сопровождения. Короче промпт и ответ: ревизия инструкции (глава 8), max_tokens по делу, «отвечай одним словом» для классификации — выходные токены могут быть самыми дорогими. Кэширование: стабильное вперёд (глава 7), если сервис подтвердил cache hit. Батчи для несрочного — когда актуальный тариф даёт выигрыш (глава 9). Маршрутизация: дешёвая модель по умолчанию, дорогая — по триггеру («НЕЯСНО», результат верификатора, класс риска). Самооценка модели не является калиброванной уверенностью, поэтому маршрутизатор проверяют на eval вместе с долей эскалаций. Рассуждение по необходимости: reasoning-режим — для задач, где eval подтверждает выигрыш, а не по умолчанию. Дистилляция (глава 12): большая модель размечает, маленькая дообучается и работает; учитывайте права на данные и вывод учителя, персональную информацию, стоимость подготовки и повторного обучения. И над всем — мониторинг: стоимость на задачу — такая же метрика конвейера, как качество, с алертом на аномалии (зацикленный агент из главы 11 обнаруживается по счёту быстрее, чем по логам).

16.3. API против своего железа

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

monthly_local = (
    (purchase_price - resale_value) / useful_months
    + power_kw * utilization * 730 * electricity_per_kwh
    + admin_hours * loaded_hourly_wage
    + colocation_network_and_backup
    + expected_repairs
)

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

Отдельная строка — цена ошибки: во сколько она обходится. Опечатка в развлекательном дайджесте и неверная цифра в финансовой сводке имеют разную цену, и оптимум «модель × проверки» у них разный. Экономика LLM — это минимизация (стоимость вызовов + Σ вероятность исхода × ущерб от исхода + стоимость проверок). Эти величины оцениваются через eval, инциденты и предметную экспертизу; дешёвая по токенам система может оказаться дорогой целиком.

16.4. Итоги — и итоги книги

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

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

Упражнения

1. Материализуйте функцию token_cost() в своём конвейере и соберите недельную статистику: стоимость на задачу, доля входных/выходных/кэшированных токенов. Какая строка счёта самая большая — и какой приём из 16.2 бьёт именно по ней?

2. Проведите свой конвейер по лестнице 16.2, применяя по одному приёму за шаг и фиксируя стоимость и качество (eval!) после каждого. Постройте итоговую таблицу «приём → экономия → влияние на качество».

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