# Плати за интеллект по токенам Экспресс-курс об экономике ИИ: почему каждый вызов модели стоит денег и времени и как держать это доступным. 19 понятий — Token, Frontier model, Model routing, Plan-and-execute, Prompt caching, Semantic caching, Batching, треугольник Latency–Cost–Quality, Streaming и другие — у каждого английское название, схема и карточка «что это → пример → подвох → связи». В конце — шпаргалка на одной странице. Главная мысль: стоимость и скорость — это ограничения дизайна, и обычно побеждает самая дешёвая модель, которая берёт планку. - **Author:** Фёдор Чищин - **Level:** intermediate - **Reading time:** ~30 минут чтения - **Published:** 2026-06-13 - **Source:** https://fedorthinks.com/ru/learn/model-economics-express --- ## 1. Ты платишь по токену Чтобы управлять ценой ИИ-фичи, сначала надо понять счётчик. Модели берут деньги за токены, и почти любое решение об экономике вытекает из этого факта. ### Карта курса: 19 понятий в семи группах > Карта метро: сначала видишь все линии, потом едешь по станциям. Сначала — **счётчик** (как считается цена). Потом шесть групп рычагов: какую модель выбрать, как разводить запросы между моделями, как не платить дважды, как слать меньше, как балансировать цену со скоростью и качеством и как всё это мерить. _Diagram: Счётчик сверху, под ним шесть групп рычагов — по ним идут главы 2–7._ У каждого понятия дальше одно и то же: **английский термин** (по нему его ищут в документации), образ из жизни, **схема** и **карточка** с полями: _что это_, _пример_, _подвох_ и _связи_ с другими понятиями. ### Token — единица стоимости > Счётчик такси: цена поездки — не фиксированная плата, а пройденное расстояние, которое тикает всю дорогу. **Токен (token)** — кусок текста, примерно слово или часть слова. Именно в токенах тебе выставляют счёт. Ты платишь не за запрос по фиксированной ставке, а за объём текста, который модель читает и пишет. Как только видишь токен как счётчик, цена всего становится понятной. _Diagram: Текст режется на токены, счётчик их считает — счёт растёт с каждым токеном._ #### Token (токен) - **Что это:** Кусок текста — примерно слово или его часть. Единица тарификации. - **Пример:** «The refund policy is 30 days» — это около семи токенов, не один запрос. - **Подвох:** Платишь за объём текста, а не за число запросов: длинный запрос дороже. - **Связи:** Из токенов складываются **Input / Output Tokens** и вся **Cost Formula**. ### Input / Output Tokens — платишь за вход и за выход > Телефонный звонок, где платишь и за то, что говоришь, и за то, что слышишь: считается весь разговор, а не твоя половина. Тебе считают **входные токены (input tokens)** — всё, что ты шлёшь: промпт, контекст, историю — _и_ **выходные токены (output tokens)** — всё, что модель пишет в ответ. Длинный контекст, который ты шлёшь в каждом вызове, оплачивается каждый раз, даже если ответ короткий. Поэтому фича, которая набивает огромный контекст в каждый запрос, дорогая при любом размере ответа. _Diagram: Слева всё, что ты шлёшь, справа то, что пишет модель. Оплачиваются обе половины — в каждом вызове._ #### Input / Output Tokens (входные и выходные токены) - **Что это:** Вход — промпт, контекст, история. Выход — сгенерированный ответ. - **Пример:** Системный промпт на тысячи токенов + короткий вопрос + ответ в одну строку: почти весь счёт — это вход. - **Подвох:** Большой контекст стоит денег в каждом вызове, а не один раз. - **Связи:** Вход режут **Context Trimming** и **Prompt Caching**; выход — **Concise Structured Output**. ### Cost Formula — токены на вызов × число вызовов > Служба доставки, которая берёт за посылку и за километр: итог — сколько поездок умножить на длину каждой. Сократи любое — и счёт падает. У общей стоимости два множителя: сколько **токенов на вызов (tokens per call)** — в основном от того, сколько контекста шлёшь, — и сколько **вызовов (calls)** ты делаешь — от того, насколько «болтлив» дизайн: один вызов, фиксированная цепочка или агент, который ходит по кругу много раз. Длинный контекст, умноженный на много вызовов, — вот как ИИ-счета взрываются. Почти любая экономия в этом курсе дёргает один из двух рычагов: **слать меньше** или **вызывать реже**. _Diagram: Два рычага в твоих руках: слать меньше и вызывать реже. Цена токена (выбор модели) умножает оба._ #### Cost Formula (формула стоимости) - **Что это:** Стоимость = токены на вызов × число вызовов (× цена токена у модели). - **Пример:** Агент, который делает 20 вызовов с длинным контекстом, стоит в разы больше одного вызова с тем же контекстом. - **Подвох:** Агентные петли незаметно умножают число вызовов. - **Связи:** Каждая следующая техника курса уменьшает один из множителей — см. схему связей в конце. > **Вопрос рамки:** «Что на самом деле раздувает счёт этой фичи — большой контекст в каждом вызове, умная, но дорогая модель или слишком много вызовов? От ответа зависит, какой рычаг дёргать». > Модели берут деньги за токены — за вход и за выход. Стоимость — это токены на вызов умножить на число вызовов, так что любая экономия сводится к «слать меньше» или «вызывать реже». ## 2. Передовая модель — не всегда ответ Первый порыв — брать самую умную модель на всё. Это дорогой порыв: разрыв в цене между моделями огромный, а большинству задач верх линейки не нужен. ### Frontier Model — самая умная и самая дорогая > Автопарк от велосипеда до фуры: стоимость поездки отличается в разы, и везти фурой одно письмо — много денег за такую работу. Модели бывают от маленьких и дешёвых до больших и дорогих, и разница в цене за токен между низом и верхом — во много раз. Самая большая и умная модель называется **передовой (frontier model)**. Она правда лучше на трудном, открытом рассуждении. Но большая часть работы реальных продуктов не такая: классифицировать сообщение, вытащить поле, пересказать абзац, направить запрос. Маленькая модель делает это так, что от гиганта не отличишь. _Diagram: Цена за токен растёт от маленькой модели к передовой во много раз (схема не в масштабе)._ #### Frontier Model (передовая модель) - **Что это:** Самая большая, умная и дорогая модель в линейке. - **Пример:** Брать её для классификации тикетов — как звать топ-хирурга наклеить пластырь. - **Подвох:** Если она стоит по умолчанию на всех задачах — ты по умолчанию выбрал самый дорогой вариант. Это самая частая растрата в ИИ-продуктах. - **Связи:** Правильное место для неё задают **Right-sizing**, **Model Routing** и **Plan-and-Execute**. ### Right-sizing — модель по размеру задачи > Хороший менеджер отдаёт трудную задачу эксперту, а рутину — джуну: талант подбирают под задачу, а не наоборот. Принцип **right-sizing** — подбирать модель под то, что задача реально требует. Трудное, новое, многошаговое рассуждение заслуживает мощной модели; простая, чётко очерченная, повторяющаяся работа — маленькой. Это не уступка в качестве, а подбор способностей под нужду: ты перестаёшь переплачивать за рутину и всё ещё приводишь тяжёлую модель туда, где она правда нужна. Сделать этот выбор верно, задачу за задачей, — самый большой рычаг на счёт ИИ-продукта. _Diagram: Рутинные задачи — маленькой модели, только по-настоящему трудные — передовой._ #### Right-sizing (модель по размеру задачи) - **Что это:** Для каждой задачи берётся самая слабая модель, которая с ней справляется. - **Пример:** Извлечь поле из письма — маленькая модель; разобрать запутанный юридический случай — большая. - **Подвох:** «Справляется» надо проверить эвалами, а не на глаз. - **Связи:** Делается статично; динамическая версия — **Model Routing**. Проверка — **Clear the Bar**. > **Вопрос модели:** «Этой задаче правда нужна самая умная модель — или я плачу передовую цену за работу, которую маленькая дешёвая модель сделала бы не хуже?» > Цены моделей отличаются в разы, а большинству задач передовая не нужна. Маленькая модель для рутины, мощная для трудного — и ты перестаёшь переплачивать за лёгкое большинство. ## 3. Маршрутизация по сложности Если большая часть работы лёгкая, а часть трудная, не надо выбирать одну модель на всё — шли каждый запрос нужной. Этот выбор на лету называется маршрутизацией, и это один из самых сильных рычагов. ### Model Routing — дешёвая по умолчанию, эскалация при нужде > Служба поддержки: первая линия отвечает на большинство вопросов и передаёт наверх только по-настоящему сложные. Большинству проблем эскалация не нужна никогда. Паттерн **маршрутизации по сложности (model routing)**: каждый запрос по умолчанию идёт маленькой дешёвой модели, а к большой и дорогой **эскалируется (escalation)** только когда задача этого правда требует. Лёгких случаев большинство, поэтому большинство запросов обходится дёшево, а премию ты платишь только за те немногие, что её заслужили. Дефолт переворачивается: не «бери лучшую и экономь потом», а «бери самую дешёвую, что берёт планку, и эскалируй, если не берёт». _Diagram: Запрос идёт к маленькой модели; если ответ не дотягивает — эскалация к передовой._ #### Model Routing (маршрутизация, эскалация) - **Что это:** Динамический выбор модели для каждого запроса по его сложности. - **Пример:** Бот поддержки: «где мой заказ» отвечает маленькая модель, запутанную жалобу — большая. - **Подвох:** Нужно уметь понять, что дешёвый ответ не дотягивает, — иначе плохие ответы уходят к людям. - **Связи:** Решение принимает **Router**; родственный паттерн — **Plan-and-Execute**. ### Router — кто решает, какая модель получит запрос > Медсестра на сортировке: быстро оценивает каждого пациента и отправляет на нужный уровень помощи. Дешёвое быстрое решение направляет дорогие ресурсы туда, где они нужны. Чтобы маршрутизировать, кто-то должен оценить сложность каждого запроса — это **роутер (router)**. Это могут быть простые правила (короткие структурированные задачи — маленькой, длинные открытые — большой), дешёвый классификатор или даже маленькая модель, которая судит о сложности. Сам роутер обязан быть дешёвым и быстрым: он работает на каждом запросе. Хороший роутер тихо шлёт основную массу трафика дешёвой модели и бережёт передовую для по-настоящему трудной доли. _Diagram: Роутер шлёт основной поток маленькой модели, а трудную долю — передовой._ #### Router (роутер) - **Что это:** Компонент, который оценивает запрос и выбирает для него модель. - **Как работает:** Правила, дешёвый классификатор или маленькая модель-судья. - **Подвох:** Если роутер сам дорогой или медленный, он съедает всю экономию. - **Связи:** Сердце **Model Routing**; превращает разброс цен между моделями в экономию. ### Plan-and-Execute — сильная планирует, дешёвые делают > Архитектор проектирует здание, а основную работу делает бригада: дорогому эксперту платишь за мышление, а за руки — дешевле. Сильная версия маршрутизации — **plan-and-execute**: один вызов сильной модели разбивает трудную задачу на конкретные шаги, а потом эти шаги выполняет более дешёвая маленькая модель. Дорогое рассуждение происходит один раз, основная масса работы идёт дёшево. Такой смешанный дизайн может срезать счёт очень сильно по сравнению с прогоном всего на большой модели. _Diagram: Сильная модель один раз пишет план, дешёвые модели выполняют шаги._ #### Plan-and-Execute (спланируй дорого, выполни дёшево) - **Что это:** Сильная модель планирует, дешёвые модели выполняют шаги плана. - **Пример:** Отчёт по 50 документам: большая модель решает, что извлечь и как сложить, маленькая проходит по каждому документу. - **Подвох:** Если план плохой, дешёвые шаги аккуратно сделают не то. - **Связи:** Вариант **Model Routing**; использует **Frontier Model** точечно. > **Вопрос маршрутизации:** «Я шлю каждый запрос одной модели — или лёгкое большинство идёт дешёвой, а дорогой достаются только по-настоящему трудные случаи?» > Маленькая модель по умолчанию, эскалация к большой — только когда задача заслужила. Дешёвый роутер и схема «планируй дорого, выполняй дёшево» превращают разброс цен в экономию. ## 4. Кэш: не делай работу дважды Самый дешёвый вызов модели — тот, которого не было. Когда одна и та же или похожая работа повторяется, запомнить ответ вместо пересчёта — одна из самых крупных экономий. ### Response Caching — не плати дважды за один ответ > Клерк держит на карточке у стола ответы на самые частые вопросы, а не ищет каждый раз с нуля. Если приложение снова и снова производит один и тот же ответ модели — тот же вопрос, тот же документ на пересказ, тот же поиск, — ты раз за разом платишь за одинаковую работу. **Кэширование ответов (response caching)** сохраняет результат в первый раз и отдаёт его мгновенно и бесплатно при повторах (механику разбирает курс о кэшировании). Дорогой вызов — один раз, дешёвые чтения — много раз. _Diagram: Попадание в кэш — мгновенно и бесплатно; промах идёт к модели, и результат сохраняется._ #### Response Caching (кэширование ответов) - **Что это:** Хранить готовый ответ модели и отдавать его при точном повторе входа. - **Пример:** Пересказ одной и той же статьи для тысячи читателей считается один раз. - **Подвох:** Работает только там, где вход правда повторяется; ответ может устареть. - **Связи:** Расширения — **Prompt Caching** (общая часть промпта) и **Semantic Caching** (похожие запросы). ### Prompt Caching — переиспользуй неизменную часть > Шаблонное письмо: длинная стандартная шапка уже напечатана, ты дописываешь только несколько строк, которые меняются. Часто большой кусок контекста одинаков в каждом вызове — длинный системный промпт, фиксированные инструкции, общий документ. **Кэширование промпта (prompt caching)** позволяет модели переиспользовать этот неизменный **префикс (prefix)** вместо повторной обработки и берёт за повторную часть гораздо меньше. Эта часть часто и есть основная масса входных токенов, так что на нагруженных фичах экономия на входе заметная. Почти бесплатно: достаточно устроить промпт так, чтобы стабильная часть шла первой и не менялась. _Diagram: Первый вызов платит полную цену; дальше общий префикс берётся из кэша и стоит намного меньше._ #### Prompt Caching (кэширование промпта) - **Что это:** Провайдер переиспользует неизменный префикс промпта и берёт за него меньше. - **Пример:** Бот с длинной инструкцией и справочником: они кэшируются, по полной цене идёт только вопрос пользователя. - **Подвох:** Любая мелочь в начале промпта (например, дата) ломает совпадение префикса. - **Связи:** Режет вход из **Input / Output Tokens**; дополняет **Context Trimming**. ### Semantic Caching — ловит почти-дубликаты > Служба поддержки понимает, что «как сбросить пароль» и «я забыл пароль» — один вопрос, и даёт обоим один готовый ответ. Кроме точных совпадений есть **семантическое кэширование (semantic caching)**: оно по смыслу (через **эмбеддинги, embeddings**) понимает, что новый запрос достаточно близок к прошлому, чтобы переиспользовать ответ. «Какая у вас политика возврата» и «как работают возвраты» не нужно считать отдельно. Так кэш ловит частый случай, когда люди спрашивают одно и то же разными словами, — и длинный хвост перефразированных вопросов превращается в дешёвые попадания. _Diagram: Два запроса близки по смыслу — один кэшированный ответ. Далёкий по смыслу идёт к модели._ #### Semantic Caching (семантический кэш) - **Что это:** Кэш, где ключ — смысл запроса (эмбеддинг), а не точный текст. - **Пример:** «Я забыл пароль» получает ответ, сохранённый для «как сбросить пароль». - **Подвох:** Порог близости надо ставить аккуратно: похожие по словам вопросы могут требовать разных ответов. - **Связи:** Расширяет **Response Caching**; опирается на эмбеддинги. > **Вопрос кэша:** «Где эта фича пересчитывает тот же или почти тот же ответ — и может ли кэш, включая фиксированный префикс промпта, превратить повторную стоимость в разовую?» > Самый дешёвый вызов — тот, что пропустил. Кэшируй повторные ответы, переиспользуй неизменный префикс и лови перефразированные дубликаты по смыслу: повторная работа — это повторная стоимость, которую платить не обязательно. ## 5. Шли меньше и группируй Когда вызов всё же нужен, его цену определяет то, сколько ты шлёшь и просишь. Слать меньше и группировать работу — будничные рычаги, которые держат цену вызова низкой. ### Context Trimming — шли меньше контекста > Собираешь в поездку только то, что правда наденешь, а не весь шкаф: каждую лишнюю вещь надо везти, а большую часть ты бы и не тронул. Ты платишь за каждый входной токен, поэтому самая прямая экономия — **обрезка контекста (context trimming)**. Обрежь историю разговора, **суммируй** старые реплики вместо того, чтобы тащить их дословно, доставай только несколько самых релевантных кусков, а не всё подряд. Это **инженерия контекста (context engineering)**, которая окупается дважды: плотный контекст не только лучше для качества, но и дешевле в каждом вызове. Под большинством раздутых счетов лежат раздутые промпты. _Diagram: До: вся история и все документы. После: краткое резюме, три лучших куска и вопрос._ #### Context Trimming (обрезка контекста) - **Что это:** Слать модели только то, что нужно для этого шага. - **Пример:** Вместо 40 прошлых реплик — их резюме в абзац; вместо всей базы знаний — три лучших куска. - **Подвох:** Обрежешь лишнего — модель потеряет нужный факт и ответит хуже. - **Связи:** Режет первый множитель **Cost Formula**; соседи — **Prompt Caching**. ### Concise Structured Output — проси меньше на выходе > Вопрос «да или нет» даёт быстрый ответ; вопрос, который зовёт к эссе, даёт эссе — его надо оплатить, а потом ещё обрезать. Выходные токены тоже платные, так что не заставляй модель писать больше, чем нужно. Проси **краткий структурированный ответ (concise structured output)** — конкретные поля, короткий ответ, без вступлений, — а не длинное эссе, из которого ты вытащишь одно число. **Структурированный вывод (structured output)** работает здесь дважды: он надёжнее _и_ дешевле, потому что плотная схема даёт меньше токенов, чем свободная проза. _Diagram: Эссе стоит много выходных токенов; схема с одним полем даёт тот же ответ гораздо дешевле._ #### Concise Structured Output (краткий структурированный вывод) - **Что это:** Ограничить форму и длину ответа: только нужные поля. - **Пример:** Оценка отзыва — `{"score": 4}`, а не три абзаца рассуждений. - **Подвох:** Слишком жёсткая схема может лишить модель места подумать на трудных задачах. - **Связи:** Режет выходную половину **Input / Output Tokens**. ### Batching — группируй, где можно > Запускаешь полную стиральную машину, а не стираешь по одной рубашке: группировка делит накладные расходы и делает больше за один прогон. Когда много похожих запросов и каждому не нужен мгновенный ответ, **батчинг (batching)** — обработка многих вместе — часто дешевле, чем слать по одному. Провайдеры нередко дают скидку на **батч-задачи (batch jobs)**, которые выполняются, когда им удобно. Ты меняешь **задержку** (каждый элемент ждёт пакет) на меньшую цену — правильная сделка для фоновой и массовой работы: разобрать завал, обогатить датасет. _Diagram: По одному — сразу и по обычной цене. Пакетом — позже, но часто со скидкой._ #### Batching (пакетная обработка) - **Что это:** Отправлять много несрочных запросов одной пакетной задачей. - **Пример:** Ночью разметить 100 000 старых тикетов одним батчем. - **Подвох:** Ответ приходит не сразу — не для того, где человек ждёт. - **Связи:** Сознательно выбирает угол «стоимость» в **Latency–Cost–Quality Triangle**. > **Вопрос эффективности:** «Я шлю больше контекста и прошу больше вывода, чем нужно этой задаче, — и не сделает ли батчинг несрочную работу дешевле?» > Управляй ценой вызова, отправляя меньше: обрезай контекст, проси краткий структурированный ответ и группируй несрочную работу. Плотный промпт и дешевле, и лучше. ## 6. Задержка, стоимость, качество Стоимость никогда не живёт одна — она меняется на скорость и качество. Если видеть три величины как треугольник, который балансируешь под задачу, не разрушишь одну, оптимизируя другую. ### Latency–Cost–Quality Triangle — три тянут друг против друга > Старая вывеска мастерской: «быстро, дёшево, хорошо — выбери два». Сильно надавишь на одно — обычно заплатишь другим. Стоимость, **задержка (latency)** — то есть скорость — и **качество (quality)** образуют треугольник и меняются друг на друга. Самая умная модель даёт лучшее качество, но стоит дороже всего и часто медленнее всех; маленькая дешёвая и быстрая, но слабее на трудном; тяжёлый контекст поднимает качество, но поднимает и цену, и задержку. Все три на максимуме разом почти не бывают. Поэтому стоимость не оптимизируют отдельно — для каждого случая решают, какой угол важнее и что за него отдать. _Diagram: Большая модель тянет к качеству, маленькая — к цене и скорости. Все три сразу на максимуме почти не бывают._ #### Latency–Cost–Quality Triangle (треугольник компромиссов) - **Что это:** Три величины, которые нельзя одновременно выжать до предела. - **Пример:** Переход на маленькую модель: дешевле и быстрее, но слабее на трудных случаях. - **Подвох:** Срезав цену, легко незаметно уронить качество — проверяй эвалами. - **Связи:** Конкретный выбор угла — **Use-case Balance**; обходной трюк для скорости — **Streaming**. ### Use-case Balance — баланс под конкретную фичу > Для гонки берёшь спорткар, для переезда — грузовой фургон: вопрос один, ответы противоположные, потому что решает работа. Правильный баланс целиком зависит от фичи. Чат, где человек ждёт ответа, живёт или умирает на **задержке** — ему нужна быстрая и способная модель. Ночной батч заботится только о **стоимости** и может взять самый дешёвый медленный вариант. Ответ с высокими ставками — юридический, медицинский — ставит **качество** выше обоих. Единой правильной точки на треугольнике нет: назвать, какой угол эта фича должна выиграть, а каким можно пожертвовать, — вот решение, от которого идут все остальные. _Diagram: Три фичи — три разных победителя: задержка для чата, стоимость для батча, качество для высоких ставок._ #### Use-case Balance (баланс под сценарий) - **Что это:** Для каждой фичи явно назвать главный угол треугольника. - **Пример:** Автодополнение в поиске — задержка; ночная разметка — стоимость; медицинская выжимка — качество. - **Подвох:** Одна настройка «на всё» проигрывает везде понемногу. - **Связи:** Определяет выбор в **Right-sizing**, **Batching** и **Streaming**. ### Streaming — дешёвая ощущаемая скорость > Кухня выносит каждое блюдо, как только оно готово, а не держит тебя до конца всей трапезы: общее время то же, но ждать кажется гораздо меньше. Один трюк обходит треугольник: **стриминг (streaming)** — отдавать ответ модели токен за токеном по мере генерации. Человек видит, как слова появляются сразу, а не смотрит в пустой экран, пока не готов весь ответ. Общее время не меняется, но **ощущаемая задержка (perceived latency)** падает очень сильно. Это дешёвый способ сделать фичу быстрой на ощупь без более быстрой модели: ты управляешь ощущением ожидания, а не самим ожиданием. _Diagram: Без стриминга — пустой экран до конца. Со стримингом слова идут сразу, хотя общее время то же._ #### Streaming (потоковый вывод) - **Что это:** Показывать ответ по мере генерации, токен за токеном. - **Пример:** Чат-ассистент начинает печатать ответ через мгновение после вопроса. - **Подвох:** Не ускоряет полную обработку: если ответ нужен целиком (например, JSON для кода), выигрыша нет. - **Связи:** Помогает углу «задержка» в **Latency–Cost–Quality Triangle** без смены модели. > **Вопрос треугольника:** «Какой угол для этой фичи важнее всего — стоимость, задержка или качество — и выбрал ли я модель и дизайн так, чтобы выиграть его и пожертвовать правильным другим?» > Стоимость, задержка и качество меняются друг на друга — все три сразу на максимуме почти не бывают. Выбери угол, который фича должна выиграть, пожертвуй правильным другим и бери стриминг, чтобы ощущаемая скорость досталась почти даром. ## 7. Применять хорошо Экономика ИИ сводится к простой позиции: знай, сколько что стоит, и сознательно трать минимум, который делает работу. Рычагов немного, и большая часть экономии — это отказ переплачивать по умолчанию. ### Cost per Task — мерь цену задачи, а не только общий счёт > Счёт в ресторане с разбивкой по блюдам вместо одной большой суммы: только разбивка говорит, где резать. Нельзя управлять стоимостью, которую не меряешь. Считай, сколько токенов на деле стоит каждая фича, каждый тип вызова, каждая задача — **стоимость на задачу (cost per task)**, — а не только месячный итог. Стоимость надо инструментировать и наблюдать, как производительность. У большинства дорогих ИИ-фич одна-две **горячие точки (cost hotspots)**: разбивка показывает их сразу, а итоговая сумма прячет полностью. _Diagram: Один месячный счёт ничего не говорит; разбивка по фичам сразу показывает горячую точку._ #### Cost per Task (стоимость на задачу) - **Что это:** Учёт токенов и денег по фичам, типам вызовов и задачам. - **Пример:** Разбивка показывает, что агентная петля съедает больше, чем чат, поиск и пересказы вместе. - **Подвох:** Без разбивки оптимизируешь не то — то, что видно, а не то, что дорого. - **Связи:** Показывает, какой множитель **Cost Formula** дёргать первым. ### Clear the Bar — самое дешёвое, что берёт планку > Покупаешь инструмент, который достаточно хорош для работы, а не самый дорогой на полке: способности сверх нужного — просто потраченные деньги. Главный принцип: бери самую дешёвую модель, самый маленький контекст и наименьшее число вызовов, которые всё ещё проходят твою **планку качества (quality bar)**, — и не больше. Это не скупость ради скупости, а отказ платить за способности, которые задача не использует. Сначала задай планку **эвалами (evals)**, потом найди самую лёгкую конфигурацию, которая её берёт. Большая часть экономии — не хитрые трюки, а отказ по привычке брать самый мощный, самый тяжёлый по контексту и самый болтливый вариант. _Diagram: Планка задаётся эвалами. Берёшь первую по цене модель, которая её проходит; всё выше — переплата._ #### Clear the Bar (самое дешёвое, что берёт планку) - **Что это:** Минимальная конфигурация (модель, контекст, вызовы), которая проходит эвалы. - **Пример:** Спустил фичу с большой модели на среднюю, прогнал эвалы — качество держится, счёт упал. - **Подвох:** Без эвалов «планка» — это ощущение, и экономия незаметно портит качество. - **Связи:** Итог всех рычагов курса; проверяет **Right-sizing** и **Model Routing**. ### Как всё связано > Панель с тремя ручками: цена токена, токены на вызов, число вызовов. Каждый приём курса крутит одну из них. Все приёмы курса бьют по трём множителям счёта. **Right-sizing**, **Model Routing** и **Plan-and-Execute** снижают цену токена. **Context Trimming**, **Concise Output** и **Prompt Caching** — токены на вызов. **Response** и **Semantic Caching** — число вызовов. **Batching** даёт скидку за ожидание, **Cost per Task** показывает, куда смотреть, а треугольник напоминает: каждый рычаг меняется на задержку и качество. _Diagram: Рычаги сверху снижают три множителя, множители дают итоговую стоимость; разбивка по задачам её измеряет._ #### Прежде чем выкатывать ИИ-фичу в масштабе - **Знаешь ли ты стоимость на задачу** — в токенах, а не только общий счёт? - **Подобрана ли модель под сложность** — маленькая для рутины, передовая только где нужно? - **Есть ли маршрутизация** — лёгкое большинство к дешёвой модели, трудное — с эскалацией? - **Кэшируешь ли ты** — повторные ответы, фиксированный префикс промпта, почти-дубликаты? - **Шлёшь ли ты минимум** — обрезанный контекст, краткий структурированный ответ, батчи для несрочного? - **Какой угол треугольника побеждает** — стоимость, задержка или качество — и настроен ли дизайн под него? #### Признаки, что ты управляешь стоимостью хорошо - Ты **меряешь стоимость на задачу** и знаешь свои горячие точки, а не только месячный итог. - Ты **подбираешь модель под сложность** и **маршрутизируешь**, а не берёшь передовую на всё. - Ты **кэшируешь** повторную работу и фиксированный префикс промпта. - Ты **шлёшь минимум** контекста и просишь **краткий** ответ. - Ты **балансируешь треугольник** под каждую фичу и используешь **стриминг**, чтобы всё ощущалось быстрым. ## Шпаргалка: все 19 понятий ### Счётчик - **Token** (токен): Кусок текста, примерно слово. Единица, в которой выставляют счёт. - **Input / Output Tokens** (вход и выход): Платишь и за то, что шлёшь, и за то, что модель пишет, — в каждом вызове. - **Cost Formula** (формула стоимости): Токены на вызов × число вызовов (× цена токена модели). ### Выбор модели - **Frontier Model** (передовая модель): Самая умная и самая дорогая. Исключение, а не дефолт. - **Right-sizing** (модель по размеру задачи): Маленькая модель для рутины, мощная — для по-настоящему трудного. ### Маршрутизация - **Model Routing** (эскалация): Дешёвая модель по умолчанию, дорогая — только когда нужно. - **Router** (роутер): Дешёвый быстрый судья, который решает, какая модель получит запрос. - **Plan-and-Execute** (план дорого, работа дёшево): Сильная модель планирует один раз, дешёвые выполняют шаги. ### Кэширование - **Response Caching** (кэш ответов): Готовый ответ на точный повтор — мгновенно и бесплатно. - **Prompt Caching** (кэш промпта): Неизменный префикс промпта переиспользуется и стоит намного меньше. - **Semantic Caching** (семантический кэш): Похожие по смыслу запросы получают один сохранённый ответ. ### Шли меньше - **Context Trimming** (обрезка контекста): Только нужный контекст: резюме вместо истории, лучшие куски вместо всего. - **Concise Structured Output** (краткий вывод): Только нужные поля — меньше выходных токенов и надёжнее. - **Batching** (пакетная обработка): Несрочная работа пакетом: позже, но часто со скидкой. ### Баланс - **Latency–Cost–Quality Triangle** (треугольник): Быстро, дёшево, хорошо — выбери два. - **Use-case Balance** (баланс под сценарий): Каждая фича явно называет свой главный угол. - **Streaming** (потоковый вывод): Слова идут сразу: время то же, ожидание короче на ощупь. ### Применять хорошо - **Cost per Task** (стоимость на задачу): Разбивка счёта по фичам и задачам показывает горячие точки. - **Clear the Bar** (планка качества): Самая дешёвая конфигурация, которая проходит эвалы, — и не больше. > Экономика ИИ — это сознательная бережливость: плати по токену, подбирай модель под сложность, маршрутизируй, кэшируй, шли минимум и балансируй цену со скоростью и качеством. Побеждает самое дешёвое, что берёт планку. Конец экспресс-курса · 7 глав · 19 понятий Дальше — практика: возьми ИИ-фичу и замерь, сколько токенов на деле стоит одна задача. Потом попробуй очевидные ходы: спусти её на модель поменьше и проверь эвалами, держится ли качество; обрежь контекст; закэшируй повторы. Обычно счёт сильно падает без реальной потери, потому что ты по привычке брал самый дорогой вариант. Дисциплина щёлкает в момент, когда дешёвая конфигурация проходит планку и ты понимаешь, что передовая модель и не была нужна. Главное держи в голове: за интеллект платишь по токену — так трать минимум, который делает работу.