Глава 14 — Экономика токенов и цены API

Четырнадцатый пост поглавного разбора LLM Primer VI: Scaling AI Systems. Глава, соединяющая физику из главы 1 со строками в счёте и объясняющая, почему счёт первого месяца часто ничем не похож на то, что смоделировала команда.

Зачем эта глава существует

Более ранние главы обращались со стоимостью инференса как с физическим фактом — байты, перегнанные по HBM, FLOPs, потраченные в matmul, GPU-секунды, потреблённые запросом. Этот фрейм верен для команды, владеющей кремнием. Для гораздо большей популяции команд, покупающих инференс с API, поверхность стоимости переформирована единицей, за которую провайдер берёт: токен. Глава 14 — о том, почему токен оценивается так, как оценивается, почему стороны вход и выход одного и того же вызова имеют такие разные цены и как тихо история разговора чат-бота и невидимое мышление модели-резонёра оказываются в счёте.

14.1 Выход стоит в 4–8 раз больше входа, потому что декодинг — bandwidth-bound фаза

Входной токен едет по пути prefill — плотный, ограничен вычислениями, параллельный по всем позициям промпта, едет ровно на той нагрузке, для которой GPU разработаны. На 70B-модели H100 прожёвывает десятки тысяч входных токенов в секунду, потому что операция — широкий matmul с высокой арифметической интенсивностью. Выходной токен едет по пути decode — последовательный, ограничен пропускной способностью памяти, один токен на прямой проход, каждый шаг читает весь KV-кэш из HBM. Тот же H100 производит 50–100 выходных токенов в секунду на запрос. Отношение между двумя пропускными — отношение, отражённое в прайс-листе. Фронтирные модели в 2025 году берут два-пять долларов за миллион входных токенов и десять-тридцать — за миллион выходных, — асимметрия 4:1 до 8:1, которая не является выбором маржи, а прямой передачей асимметрии стоящего под ней вычисления. Кэшированный вход ещё дешевле, потому что провайдер заплатил стоимость prefill на предыдущем запросе. Batch API дешевле вдвое, потому что провайдер может планировать работу в окнах простаивающей ёмкости. Reasoning-токены — это выходные токены, потому что таково их существо внутри движка.

14.2 Рычаг оптимизации зависит от формы вход/выход

Ошибка — моделировать стоимость одним ментальным числом «токены стоят X» вместо того, чтобы декомпозировать вход и выход отдельно. Retrieval-тяжёлая триажная поддержка клиентов, отправляющая 8 500 входных токенов и получающая 600-токенный ответ, доминируется входной стоимостью на фронтирных ценах (примерно $255 на вход к $90 на выход на 10 000 запросов в день). Long-form-система набросков на том же объёме — 2 200 входных, 3 000 выходных — доминируется выходной стоимостью ($66 вход к $450 выход). Совет по оптимизации противоположен в двух случаях: сократите промпт для первого, сократите ответ для второго и маршрутизируйте на модель, чей ценовой профиль благоприятствует доминирующей оси. Вторая декомпозиция, которую стоит запустить, — по тенанту или нагрузке. Мультитенантные системы почти всегда показывают power-law перекос, где топ 10 процентов тенантов отвечают за половину или больше расхода, и работа по оптимизации стоимости, нацеленная на этих тенантов, окупается в несколько раз больше, чем равномерная работа, распределённая по длинному хвосту.

14.3 Накопление контекста и невидимые reasoning-токены усложняют счёт

Самый дорогой токен — тот, о котором команда забыла, что его отправляют. API — без состояния; каждый запрос отправляет всю историю разговора как вход на каждом вызове. Накопительная входная стоимость через N-ходовую беседу растёт квадратично по N минус кредит префиксного кэша. Команда, оценивавшая свою систему по одноходовой базовой линии, через шесть месяцев обнаруживает, что её средний разговор теперь охватывает восемь ходов и её стоимость на разговор на входе выросла примерно в квадрате. Второй тихий множитель — reasoning-токены. Модели вроде o1/o3, Anthropic extended thinking, DeepSeek R1 и Google reasoning-варианты производят большой объём внутреннего мышления до видимого ответа — часто 4 000–8 000 токенов за 500-токенным видимым ответом. Эти токены едут по той же выходной decode-петле и биллятся как выход; они не возвращаются вызывающему, если код не спрашивает. Смягчение — правильно инструментировать объект usage в ответе API — prompt_tokens, cached_prompt_tokens, completion_tokens, reasoning_tokens и любые провайдер-специфичные категории — и флагировать неизвестные категории вместо того, чтобы молча их отбрасывать. Каждое новое биллируемое измерение, которое добавляет провайдер, должно появиться в схеме использования команды, иначе следующий счёт — сюрприз.

Что подготавливает глава 14

Как только команда может прочитать свой счёт с декомпозицией вход-против-выход, per-тенант и per-категория, следующий вопрос — тот, что задаст финансы — должна ли команда вообще платить за токен. Глава 15 обходит альтернативу: привести инференс в дом, арендовать или купить GPU и платить за GPU-час вместо этого. Арифметика точки безубыточности чиста. Что менее чисто, и что большинство команд недооценивает, — это всё на стороне выделенного, что не в GPU-счёте: платформенная инженерия, security-патчи, хореография апгрейдов моделей, on-call-ротация, отвечающая, когда узел выпадает из флота.

Дальше — Глава 15: Serverless API против выделенной инфраструктуры. Формула точки безубыточности, скрытая строка и гибридные позы, где и то, и другое — правильный ответ.