Экспресс-курс · No. 31
Каждый вызов модели стоит денег и времени, отмеряемых по токену, — а счёт масштабируется с тем, сколько ты шлёшь и насколько умную модель используешь. Относиться к стоимости и скорости как к ограничениям дизайна, а не мыслям вдогонку, вот что отделяет демо, что работает раз, от продукта, что доступно работает в масштабе. Выучи слова и рычаги, и «сделай дешевле» станет рутиной, а не кризисом.
Только суть · Один образ на идею · Стоимость — это ограничение дизайна
Чтобы контролировать стоимость ИИ-фичи, сперва надо понять счётчик. Модели тарифицируются по токену, и почти любое экономическое решение следует из того, что это значит.
Токен — это единица стоимости
Счётчик такси, что берёт по миле, — цена поездки не фиксированная плата, а пройденное расстояние, тикающее всю дорогу.
Токен (token) — это кусок текста, примерно слово или его часть, — и это единица, в которой тебя тарифицируют. Каждый вызов модели стоит сумму, основанную на числе задействованных токенов, как такси берёт по расстоянию. Это фундаментальный факт экономики ИИ: ты платишь не за запрос по фиксированной ставке, а за объём текста, что модель читает и пишет. Как только видишь токен как счётчик, стоимость всего становится читаемой.
Ты платишь и за то, что входит, и за то, что выходит
Телефонный звонок, где тебя тарифицируют и за то, что говоришь, и за то, что слышишь, — весь разговор считается, не только твоя половина.
Тебя тарифицируют за входные токены (всё, что ты шлёшь, — промпт, контекст, историю) и выходные токены (всё, что модель генерирует). Обе половины считаются, и длинный контекст, что ты шлёшь на каждом вызове, стоит каждый раз, даже если ответ короткий. Поэтому фича, что набивает огромный контекст в каждый запрос, дорога вне зависимости от размера вывода — ты платишь за весь разговор, в обоих направлениях, на каждом вызове.
Стоимость масштабируется с контекстом и числом вызовов
Служба доставки, что тарифицирует за посылку и за милю, — твой итог это сколько поездок умножить на то, как далеко каждая идёт. Срежь любое, и счёт падает.
У твоей общей стоимости два множителя: сколько токенов на вызов (в основном от того, сколько контекста ты шлёшь) и сколько вызовов ты делаешь (от того, насколько болтлив твой дизайн, — один вызов, фиксированная цепочка или агент, петляющий много раз). Длинный контекст, умноженный на много вызовов, — вот как ИИ-счета взрываются. Оба рычага в твоём контроле, и почти любая техника экономии в этом курсе на деле о том, чтобы дёрнуть один из них: слать меньше на вызов или делать меньше вызовов.
Модели тарифицируют по токену, за вход и выход. Твоя стоимость — это токены-на-вызов умножить на число-вызовов, так что любая экономия сводится к «слать меньше» или «вызывать меньше».
Инстинкт — использовать самую умную модель для всего. Этот инстинкт дорог, потому что разрыв в цене между моделями огромен, а большинству задач не нужна вершина диапазона.
Модели колоссально различаются по цене и мощи
Автопарк от велосипеда до грузовика, — дико разная стоимость на поездку, и использовать грузовик доставить одно письмо это много денег за работу.
Есть широкий спектр моделей, от маленьких и дешёвых до больших и дорогих, и разница в цене между верхом и низом часто огромна — во много раз на токен. Самая большая, самая умная передовая (frontier) модель драматически дороже маленькой. Так что выбор модели — одно из крупнейших решений по стоимости, что ты делаешь, и дефолтить на самую мощную для каждой задачи — это дефолтить на самую дорогую.
Большинству задач не нужна самая умная модель
Ты не нанимаешь топ-хирурга наложить пластырь, — рутинную задачу делает так же хорошо кто-то куда дешевле, а специалист на ней растрачен.
Передовая модель по-настоящему лучше на тяжёлом, открытом рассуждении, — но большинство того, что делают реальные продукты, не такое. Классифицировать сообщение, извлечь поле, суммировать абзац, маршрутизировать запрос: маленькая, дешёвая модель тянет это с качеством, что не отличить от гиганта. Платить по передовым ценам за рутинную работу — самая частая растрата в ИИ-продуктах. Самая умная модель — это исключение, к которому тянешься, а не дефолт, с которого начинаешь.
Подбери модель под сложность задачи
Хороший менеджер назначает тяжёлую проблему эксперту, а рутинную работу — джуну, — подбирая талант под задачу, а не наоборот.
Принцип — подобрать модель под то, что задача на деле требует. Тяжёлое, новое, многошаговое рассуждение заслуживает мощной модели; простая, хорошо-очерченная, повторяющаяся работа идёт маленькой. Это не компромисс по качеству — это подбор способности под нужду, так что ты перестаёшь переплачивать за рутинную работу, всё ещё приводя тяжёлую модель туда, где она правда нужна. Взять этот подбор верно, задача за задачей, — самый большой рычаг на счёт ИИ-продукта.
Цены моделей колоссально различаются, и большинству задач не нужна передовая. Подбирай модель под сложность задачи — маленькую для рутины, мощную для правда тяжёлого — и перестань переплачивать за лёгкое большинство.
Если бо́льшая часть работы лёгкая, а часть тяжёлая, ты не выбираешь одну модель на всё — ты шлёшь каждый запрос нужной. Этот динамический выбор — маршрутизация, и это один из самых рычажных паттернов из всех.
Дефолти на маленькую модель, эскалируй при нужде
Стол поддержки, где передовая линия обрабатывает большинство вопросов и передаёт лишь правда хитрые вверх специалисту, — большинству проблем эскалация не нужна никогда.
Ключевой паттерн — маршрутизировать по сложности: слать каждый запрос маленькой, дешёвой модели по умолчанию и эскалировать к большей, дороже только когда задаче это правда нужно. Поскольку лёгкие случаи — большинство, большинство запросов обрабатываются дёшево, и ты платишь премию лишь за те немногие, что её заслужили. Это переворачивает дефолт с «бери лучшую модель и экономь потом» на «бери самую дешёвую модель, что берёт планку, и эскалируй, когда не берёт».
Роутер решает, какая модель получает каждый запрос
Медсестра-сортировщик, что быстро оценивает каждого пациента и шлёт его на нужный уровень помощи, — быстрое, дешёвое суждение, что направляет дорогие ресурсы туда, где нужны.
Чтобы маршрутизировать, что-то должно решить сложность каждого запроса — роутер (router). Это могут быть простые правила (короткие, структурированные задачи идут маленькой; длинные, открытые — большой), дешёвый классификатор или даже маленькая модель, судящая сложность. Сам роутер должен быть дёшев и быстр, ведь он бежит на всём. Хороший роутер тихо шлёт основную массу трафика дешёвой модели и приберегает передовую для правда тяжёлого среза — превращая разброс цен между моделями в экономию.
Дай сильной модели планировать, дешёвым исполнять
Архитектор проектирует здание, но строительная бригада делает основную часть труда, — ты платишь дорогому эксперту за мышление и дешёвым рукам за работу.
Мощная версия маршрутизации — plan-and-execute: используй один вызов сильной модели, чтобы разбить тяжёлую задачу на конкретные шаги, потом гоняй эти шаги более дешёвой, маленькой моделью. Дорогое рассуждение случается раз; основная масса работы бежит дёшево. Это ловит способность передовой модели планировать там, где это важно, держа стоимость на шаг низкой, — гетерогенный дизайн, что может срезать счёт драматически против прогона всего на большой модели.
Маршрутизируй по сложности: маленькая модель по умолчанию, эскалация к большой, лишь когда задача заслужила. Дешёвый роутер и разделение «планируй-дорого, исполняй-дёшево» превращают разброс цен в экономию.
Самый дешёвый вызов модели — тот, что ты никогда не делаешь. Когда одна и та же или похожая работа всплывает многократно, запомнить ответ вместо пересчёта — одна из крупнейших доступных экономий.
Не плати дважды за один ответ
Клерк, что держит самые спрашиваемые ответы на карточке у стола, вместо того чтобы искать каждый с нуля каждый раз, как спрашивают.
Если твоё приложение производит один и тот же вывод модели многократно — один вопрос, один суммируемый документ, один поиск, — ты платишь за идентичную работу снова и снова. Кэширование (caching) хранит результат в первый раз и отдаёт его мгновенно и бесплатно на повторах (курс о кэшировании покрывает механику). Дорогой вызов случается раз; дешёвые чтения случаются много раз. Везде, где один и тот же вход повторяется, кэш превращает повторную стоимость в единственную.
Кэширование промпта переиспользует неизменную часть
Шаблонное письмо, где длинная стандартная преамбула предпечатана, а ты заполняешь лишь несколько строк, что меняются, — ты не переписываешь всё каждый раз.
Часто большой кусок твоего контекста одинаков на каждом вызове — длинный системный промпт, фиксированные инструкции, общий документ. Кэширование промпта (prompt caching) даёт модели переиспользовать этот неизменный префикс вместо переобработки его каждый раз, беря куда меньше за повторную часть. Поскольку этот фиксированный контекст часто основная масса твоих входных токенов, кэшировать его может существенно срезать входную стоимость на высокообъёмных фичах. Это почти-бесплатная экономия, что ты получаешь, просто структурировав стабильную часть промпта так, чтобы её можно было кэшировать.
Семантическое кэширование ловит почти-дубликаты
Стол поддержки, что распознаёт «как сбросить пароль» и «я забыл пароль» как один вопрос — и даёт один подготовленный ответ обоим.
Помимо точных совпадений, семантическое кэширование (semantic caching) использует смысл (через эмбеддинги), чтобы распознать, когда новый запрос достаточно близок к предыдущему, чтобы переиспользовать ответ, — «какая у вас политика возврата» и «как работают возвраты» не надо пересчитывать отдельно. Это ловит частый случай, где пользователи спрашивают одно разными словами, расширяя досягаемость кэша далеко за идентичные входы. Использованное аккуратно, оно превращает длинный хвост перефразированных-но-эквивалентных вопросов в дешёвые попадания кэша.
Самый дешёвый вызов — тот, что пропускаешь. Кэшируй повторные ответы, переиспользуй неизменный префикс промпта и лови перефразированные дубликаты семантически — повторная работа это повторная стоимость, что платить не обязательно.
Когда ты всё же делаешь вызов, ты контролируешь, сколько он стоит, контролируя, сколько шлёшь. Слать меньше и группировать работу — будничные рычаги, что держат стоимость на вызов низкой.
Шли меньше контекста
Паковать только то, что реально используешь в поездке, вместо всего гардероба, — каждый лишний предмет стоит везти, а большинство ты бы и не тронул.
Поскольку ты платишь за входной токен, самая прямая экономия — слать меньше контекста. Обрежь историю разговора, суммируй старые ходы вместо того, чтобы нести дословно, извлекай лишь несколько самых релевантных чанков, а не всё. Это дисциплина инженерии контекста, окупающаяся дважды: более тугой контекст не только лучше для качества, он дешевле на каждом вызове. У большинства раздутых ИИ-счетов под ними раздутые промпты — срежь набивку, и стоимость падает с ней.
Проси меньше вывода, структурированного
Задать вопрос, что хочет «да или нет», даёт тебе быстрый ответ; задать тот, что приглашает эссе, даёт тебе эссе, за которое надо заплатить и потом обрезать.
Ты платишь и за выходные токены, так что не заставляй модель генерировать больше, чем нужно. Проси краткий, структурированный вывод — конкретные поля, короткий ответ, без растекающейся преамбулы — а не длинное эссе, из которого вытащишь лишь число. Структурированный вывод (курс о нём) делает двойную работу тут: он надёжнее и дешевле, потому что тугая схема производит меньше токенов, чем свободная проза. Ограничь то, что возвращается, и ограничишь выходную половину счёта.
Батчи работу, где можешь
Гонять полную загрузку стирки вместо одной рубашки за раз, — группировка работы размазывает фиксированные накладные и делает больше за прогон.
Когда у тебя много похожих запросов, каждому из которых не нужен мгновенный ответ, батчинг (batching) их — обработка многих вместе — часто дешевле, чем стрелять по одному, и провайдеры часто предлагают скидку за батч-задачи, что могут бежать, когда удобно. Это меняет задержку (каждый элемент ждёт батч) на меньшую стоимость, что верная сделка для фоновой или массовой работы — обработать завал, обогатить датасет, — где скорость на элемент не важна. Где не нужно сейчас, батчинг делает дешевле.
Контролируй стоимость на вызов, слав меньше: обрезай контекст, проси краткий структурированный вывод и батчи несрочную работу. Более тугой промпт дешевле и при этом лучше.
Стоимость никогда не живёт одна — она меняется на скорость и качество. Видеть три как треугольник, что балансируешь под случай, не даёт оптимизировать одно, разрушив другое.
Три тянут друг против друга
Старая вывеска мастерской — «быстро, дёшево, хорошо: выбери два», — потому что давить сильно на одно обычно стоит тебе другого.
Стоимость, задержка (latency, скорость) и качество образуют треугольник, и они размениваются. Самая большая, самая умная модель даёт лучшее качество, но стоит больше всего и часто медленнее всех; маленькая модель дешёвая и быстрая, но слабее на тяжёлом; тяжёлый контекст улучшает качество, но поднимает и стоимость, и задержку. Ты редко получаешь все три на максимуме разом. Так что ты не оптимизируешь стоимость в изоляции — ты решаешь, для каждого случая, какой угол важнее всего и что ты разменяешь на него.
Выбирай баланс под случай
Ты выбираешь спорткар для гонки и грузовой фургон для переезда, — один вопрос, противоположные ответы, потому что работа решает, что важно.
Верный баланс целиком зависит от фичи. Обращённый к пользователю чат живёт или умирает на задержке и нуждается в быстрой, способной модели. Ночная батч-задача заботится лишь о стоимости и может использовать самый дешёвый, медленный вариант. Высокоставочный юридический или медицинский ответ ставит качество выше обоих. Нет единой верной точки на треугольнике — назвать, какой угол эта конкретная фича должна выиграть, а какой может пожертвовать, — вот решение, что гонит каждый выбор модели и дизайна вокруг неё.
Стриминг покупает воспринимаемую скорость дёшево
Кухня, что выносит каждое блюдо, как оно готово, вместо того чтобы заставлять ждать всю трапезу, — общее время то же, но ожидание ощущается куда короче.
Один трюк обходит треугольник: стриминг (streaming) вывода модели токен за токеном по мере генерации, чтобы пользователь видел появляющиеся слова немедленно, вместо того чтобы пялиться в пустой экран, пока весь ответ не готов. Общее время не меняется, но воспринимаемая задержка драматически падает, потому что что-то происходит сразу. Это дешёвый способ сделать фичу ощутимо быстрой без более быстрой модели — управляя опытом задержки, а не самой задержкой.
Стоимость, задержка и качество размениваются — ты редко максимизируешь все три. Выбери, какой угол каждая фича должна выиграть, пожертвуй верным другим и используй стриминг, чтобы купить воспринимаемую скорость бесплатно.
Экономика ИИ сводится к простой позе: знай, что вещи стоят, и намеренно трать самое малое, что делает работу. Рычагов немного, и бо́льшая часть экономии идёт от отказа переплачивать по умолчанию.
Меряй стоимость на задачу, а не только общий счёт
Детализированный счёт, что показывает, какое блюдо что стоило, вместо одного большого числа, — только разбивка говорит, где резать.
Нельзя контролировать стоимость, что не меришь. Отслеживай, что каждая фича, каждый тип вызова, каждая задача на деле стоит в токенах, а не только общий месячный счёт, чтобы видеть, куда уходят деньги и какую часть оптимизировать. Стоимость — это то, что инструментируешь и наблюдаешь, как производительность, — у большинства дорогих ИИ-фич одна-две точки горячести стоимости, что разбивка вскрывает мгновенно, а итог прячет целиком. Меряй на задачу, и место для экономии объявит себя само.
Используй самое дешёвое, что берёт планку
Ты покупаешь инструмент, что достаточно хорош для работы, а не самый дорогой на полке, — способность сверх того, что нужно, это просто потраченные деньги.
Управляющий принцип — использовать самую дешёвую модель, самый маленький контекст и наименьшее число вызовов, что всё ещё встречают твою планку качества, — и не больше. Это не дешевизна ради неё; это отказ платить за способность, что задача не использует. Задай планку качества эвалами, потом найди самую лёгкую конфигурацию, что её берёт. Бо́льшая часть экономии стоимости — не хитрые трюки, а просто отказ дефолтить на самый мощный, самый контекст-тяжёлый, самый болтливый вариант, когда более стройный проходит планку.
- Знаешь ли ты стоимость на задачу — измеренную в токенах, а не только общий счёт? - Подобрана ли модель под сложность — маленькая для рутины, передовая лишь где нужно? - Маршрутизируешь ли ты — лёгкое большинство дешёвой модели, эскалируя тяжёлые случаи? - Кэшируешь ли ты — повторные ответы, фиксированный префикс промпта, почти-дубликаты? - Шлёшь ли ты минимум — обрезанный контекст, краткий структурированный вывод, батчи где несрочно? - Какой угол треугольника побеждает — стоимость, задержка или качество — и настроен ли дизайн под него?
- token / input / output — единица тарификации, берётся за то, что шлёшь, и то, что возвращается. - передовая модель (frontier) — самый большой, умный и дорогой вариант. - маршрутизация / роутер — слать каждый запрос нужной модели по сложности. - plan-and-execute — сильная модель планирует, дешёвые делают основное. - кэширование / prompt caching / semantic caching — переиспользовать ответы, фиксированные префиксы и почти-дубликаты.
- батчинг — группировать несрочную работу ради меньшей стоимости, меняя задержку. - задержка / стоимость / качество — треугольник, что балансируешь под случай; стриминг для воспринимаемой скорости.
- Ты меряешь стоимость на задачу и знаешь свои горячие точки, а не только месячный итог. - Ты подбираешь модель под сложность и маршрутизируешь вместо использования передовой на всё. - Ты кэшируешь повторную работу и фиксированный префикс промпта. - Ты шлёшь минимум контекста и просишь краткий вывод. - Ты балансируешь треугольник под каждую фичу и используешь стриминг, чтобы вещи ощущались быстрыми.
Экономика ИИ — это намеренная бережливость: тарифицируй по токену, подбирай модель под сложность, маршрутизируй, кэшируй, шли минимум и балансируй стоимость против задержки и качества — самое дешёвое, что берёт планку, побеждает.