Карта курса: 19 понятий в семи группах

Карта метро: сначала видишь все линии, потом едешь по станциям.

Сначала — счётчик (как считается цена). Потом шесть групп рычагов: какую модель выбрать, как разводить запросы между моделями, как не платить дважды, как слать меньше, как балансировать цену со скоростью и качеством и как всё это мерить.

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

Token — единица стоимости

Счётчик такси: цена поездки — не фиксированная плата, а пройденное расстояние, которое тикает всю дорогу.

Токен (token) — кусок текста, примерно слово или часть слова. Именно в токенах тебе выставляют счёт. Ты платишь не за запрос по фиксированной ставке, а за объём текста, который модель читает и пишет. Как только видишь токен как счётчик, цена всего становится понятной.

Input / Output Tokens — платишь за вход и за выход

Телефонный звонок, где платишь и за то, что говоришь, и за то, что слышишь: считается весь разговор, а не твоя половина.

Тебе считают входные токены (input tokens) — всё, что ты шлёшь: промпт, контекст, историю — и выходные токены (output tokens) — всё, что модель пишет в ответ. Длинный контекст, который ты шлёшь в каждом вызове, оплачивается каждый раз, даже если ответ короткий. Поэтому фича, которая набивает огромный контекст в каждый запрос, дорогая при любом размере ответа.

Cost Formula — токены на вызов × число вызовов

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

У общей стоимости два множителя: сколько токенов на вызов (tokens per call) — в основном от того, сколько контекста шлёшь, — и сколько вызовов (calls) ты делаешь — от того, насколько «болтлив» дизайн: один вызов, фиксированная цепочка или агент, который ходит по кругу много раз. Длинный контекст, умноженный на много вызовов, — вот как ИИ-счета взрываются. Почти любая экономия в этом курсе дёргает один из двух рычагов: слать меньше или вызывать реже.

Frontier Model — самая умная и самая дорогая

Автопарк от велосипеда до фуры: стоимость поездки отличается в разы, и везти фурой одно письмо — много денег за такую работу.

Модели бывают от маленьких и дешёвых до больших и дорогих, и разница в цене за токен между низом и верхом — во много раз. Самая большая и умная модель называется передовой (frontier model). Она правда лучше на трудном, открытом рассуждении. Но большая часть работы реальных продуктов не такая: классифицировать сообщение, вытащить поле, пересказать абзац, направить запрос. Маленькая модель делает это так, что от гиганта не отличишь.

Right-sizing — модель по размеру задачи

Хороший менеджер отдаёт трудную задачу эксперту, а рутину — джуну: талант подбирают под задачу, а не наоборот.

Принцип right-sizing — подбирать модель под то, что задача реально требует. Трудное, новое, многошаговое рассуждение заслуживает мощной модели; простая, чётко очерченная, повторяющаяся работа — маленькой. Это не уступка в качестве, а подбор способностей под нужду: ты перестаёшь переплачивать за рутину и всё ещё приводишь тяжёлую модель туда, где она правда нужна. Сделать этот выбор верно, задачу за задачей, — самый большой рычаг на счёт ИИ-продукта.

Model Routing — дешёвая по умолчанию, эскалация при нужде

Служба поддержки: первая линия отвечает на большинство вопросов и передаёт наверх только по-настоящему сложные. Большинству проблем эскалация не нужна никогда.

Паттерн маршрутизации по сложности (model routing): каждый запрос по умолчанию идёт маленькой дешёвой модели, а к большой и дорогой эскалируется (escalation) только когда задача этого правда требует. Лёгких случаев большинство, поэтому большинство запросов обходится дёшево, а премию ты платишь только за те немногие, что её заслужили. Дефолт переворачивается: не «бери лучшую и экономь потом», а «бери самую дешёвую, что берёт планку, и эскалируй, если не берёт».

Router — кто решает, какая модель получит запрос

Медсестра на сортировке: быстро оценивает каждого пациента и отправляет на нужный уровень помощи. Дешёвое быстрое решение направляет дорогие ресурсы туда, где они нужны.

Чтобы маршрутизировать, кто-то должен оценить сложность каждого запроса — это роутер (router). Это могут быть простые правила (короткие структурированные задачи — маленькой, длинные открытые — большой), дешёвый классификатор или даже маленькая модель, которая судит о сложности. Сам роутер обязан быть дешёвым и быстрым: он работает на каждом запросе. Хороший роутер тихо шлёт основную массу трафика дешёвой модели и бережёт передовую для по-настоящему трудной доли.

Plan-and-Execute — сильная планирует, дешёвые делают

Архитектор проектирует здание, а основную работу делает бригада: дорогому эксперту платишь за мышление, а за руки — дешевле.

Сильная версия маршрутизации — plan-and-execute: один вызов сильной модели разбивает трудную задачу на конкретные шаги, а потом эти шаги выполняет более дешёвая маленькая модель. Дорогое рассуждение происходит один раз, основная масса работы идёт дёшево. Такой смешанный дизайн может срезать счёт очень сильно по сравнению с прогоном всего на большой модели.

Response Caching — не плати дважды за один ответ

Клерк держит на карточке у стола ответы на самые частые вопросы, а не ищет каждый раз с нуля.

Если приложение снова и снова производит один и тот же ответ модели — тот же вопрос, тот же документ на пересказ, тот же поиск, — ты раз за разом платишь за одинаковую работу. Кэширование ответов (response caching) сохраняет результат в первый раз и отдаёт его мгновенно и бесплатно при повторах (механику разбирает курс о кэшировании). Дорогой вызов — один раз, дешёвые чтения — много раз.

Prompt Caching — переиспользуй неизменную часть

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

Часто большой кусок контекста одинаков в каждом вызове — длинный системный промпт, фиксированные инструкции, общий документ. Кэширование промпта (prompt caching) позволяет модели переиспользовать этот неизменный префикс (prefix) вместо повторной обработки и берёт за повторную часть гораздо меньше. Эта часть часто и есть основная масса входных токенов, так что на нагруженных фичах экономия на входе заметная. Почти бесплатно: достаточно устроить промпт так, чтобы стабильная часть шла первой и не менялась.

Semantic Caching — ловит почти-дубликаты

Служба поддержки понимает, что «как сбросить пароль» и «я забыл пароль» — один вопрос, и даёт обоим один готовый ответ.

Кроме точных совпадений есть семантическое кэширование (semantic caching): оно по смыслу (через эмбеддинги, embeddings) понимает, что новый запрос достаточно близок к прошлому, чтобы переиспользовать ответ. «Какая у вас политика возврата» и «как работают возвраты» не нужно считать отдельно. Так кэш ловит частый случай, когда люди спрашивают одно и то же разными словами, — и длинный хвост перефразированных вопросов превращается в дешёвые попадания.

Context Trimming — шли меньше контекста

Собираешь в поездку только то, что правда наденешь, а не весь шкаф: каждую лишнюю вещь надо везти, а большую часть ты бы и не тронул.

Ты платишь за каждый входной токен, поэтому самая прямая экономия — обрезка контекста (context trimming). Обрежь историю разговора, суммируй старые реплики вместо того, чтобы тащить их дословно, доставай только несколько самых релевантных кусков, а не всё подряд. Это инженерия контекста (context engineering), которая окупается дважды: плотный контекст не только лучше для качества, но и дешевле в каждом вызове. Под большинством раздутых счетов лежат раздутые промпты.

Concise Structured Output — проси меньше на выходе

Вопрос «да или нет» даёт быстрый ответ; вопрос, который зовёт к эссе, даёт эссе — его надо оплатить, а потом ещё обрезать.

Выходные токены тоже платные, так что не заставляй модель писать больше, чем нужно. Проси краткий структурированный ответ (concise structured output) — конкретные поля, короткий ответ, без вступлений, — а не длинное эссе, из которого ты вытащишь одно число. Структурированный вывод (structured output) работает здесь дважды: он надёжнее и дешевле, потому что плотная схема даёт меньше токенов, чем свободная проза.

Batching — группируй, где можно

Запускаешь полную стиральную машину, а не стираешь по одной рубашке: группировка делит накладные расходы и делает больше за один прогон.

Когда много похожих запросов и каждому не нужен мгновенный ответ, батчинг (batching) — обработка многих вместе — часто дешевле, чем слать по одному. Провайдеры нередко дают скидку на батч-задачи (batch jobs), которые выполняются, когда им удобно. Ты меняешь задержку (каждый элемент ждёт пакет) на меньшую цену — правильная сделка для фоновой и массовой работы: разобрать завал, обогатить датасет.

Latency–Cost–Quality Triangle — три тянут друг против друга

Старая вывеска мастерской: «быстро, дёшево, хорошо — выбери два». Сильно надавишь на одно — обычно заплатишь другим.

Стоимость, задержка (latency) — то есть скорость — и качество (quality) образуют треугольник и меняются друг на друга. Самая умная модель даёт лучшее качество, но стоит дороже всего и часто медленнее всех; маленькая дешёвая и быстрая, но слабее на трудном; тяжёлый контекст поднимает качество, но поднимает и цену, и задержку. Все три на максимуме разом почти не бывают. Поэтому стоимость не оптимизируют отдельно — для каждого случая решают, какой угол важнее и что за него отдать.

Use-case Balance — баланс под конкретную фичу

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

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

Streaming — дешёвая ощущаемая скорость

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

Один трюк обходит треугольник: стриминг (streaming) — отдавать ответ модели токен за токеном по мере генерации. Человек видит, как слова появляются сразу, а не смотрит в пустой экран, пока не готов весь ответ. Общее время не меняется, но ощущаемая задержка (perceived latency) падает очень сильно. Это дешёвый способ сделать фичу быстрой на ощупь без более быстрой модели: ты управляешь ощущением ожидания, а не самим ожиданием.

Cost per Task — мерь цену задачи, а не только общий счёт

Счёт в ресторане с разбивкой по блюдам вместо одной большой суммы: только разбивка говорит, где резать.

Нельзя управлять стоимостью, которую не меряешь. Считай, сколько токенов на деле стоит каждая фича, каждый тип вызова, каждая задача — стоимость на задачу (cost per task), — а не только месячный итог. Стоимость надо инструментировать и наблюдать, как производительность. У большинства дорогих ИИ-фич одна-две горячие точки (cost hotspots): разбивка показывает их сразу, а итоговая сумма прячет полностью.

Clear the Bar — самое дешёвое, что берёт планку

Покупаешь инструмент, который достаточно хорош для работы, а не самый дорогой на полке: способности сверх нужного — просто потраченные деньги.

Главный принцип: бери самую дешёвую модель, самый маленький контекст и наименьшее число вызовов, которые всё ещё проходят твою планку качества (quality bar), — и не больше. Это не скупость ради скупости, а отказ платить за способности, которые задача не использует. Сначала задай планку эвалами (evals), потом найди самую лёгкую конфигурацию, которая её берёт. Большая часть экономии — не хитрые трюки, а отказ по привычке брать самый мощный, самый тяжёлый по контексту и самый болтливый вариант.

Как всё связано

Панель с тремя ручками: цена токена, токены на вызов, число вызовов. Каждый приём курса крутит одну из них.

Все приёмы курса бьют по трём множителям счёта. Right-sizing, Model Routing и Plan-and-Execute снижают цену токена. Context Trimming, Concise Output и Prompt Caching — токены на вызов. Response и Semantic Caching — число вызовов. Batching даёт скидку за ожидание, Cost per Task показывает, куда смотреть, а треугольник напоминает: каждый рычаг меняется на задержку и качество.