Не зови шефа жарить тост: cost/latency-оптимизация

🍳 У каждого блюда есть себестоимость и время отдачи

Начнём с простого факта, который меняет всё. Когда твой бот отвечает гостю, это не бесплатно и не мгновенно. У каждого ответа есть себестоимость (сколько он стоит тебе в деньгах) и время отдачи — по-умному задержка (latency), то есть сколько секунд гость ждёт ответа. Ровно как у блюда на кухне: есть цена продуктов и есть время от заказа до подачи.

Откуда берётся себестоимость? Из двух вещей. Первая — какого повара ты позвал. Дорогая, мощная модель (та, что умеет долго рассуждать, — мы разбирали таких в теме 2.6 про reasoning-модели) — это шеф: берёт за работу много, делает дольше, но вытягивает сложное. Дешёвая быстрая модель — младший повар: берёт копейки, отдаёт за секунду, но на сложном спотыкается. Вторая — сколько продуктов ты выложил повару на стол. Чем больше текста ты скармливаешь модели за раз (вся история переписки, кипа документов, длиннющая инструкция), тем дороже выходит каждый ответ. Это те самые «токены» — кусочки текста, которыми оперирует модель; больше текста — больше токенов — больше денег.

И вот первый вывод владельца: цена и скорость — это не свойство «бота вообще», это результат твоих решений. Кого позвал готовить и сколько вывалил на стол — то и платишь. Значит, этим можно управлять. Не «бот дорогой, ничего не поделаешь», а «я выбрал гонять шефа на тосты — могу выбрать иначе».

🧑‍🍳 Шеф-экспедитор: правильный повар под правильную задачу

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

Посмотри, как раскладываются задачи по «мощности»:

В деньгах разница огромна. Дешёвая модель против мощной может отличаться по цене не на проценты, а в десятки раз за один и тот же объём текста — точные цифры зависят от моделей и меняются чуть ли не ежемесячно (об этом ниже), но порядок именно такой. Представь: половина запросов к боту — это «когда работаете?» и «где вы находитесь?». Если каждый такой тост печёт шеф, ты переплачиваешь не чуть-чуть. Ты переплачиваешь в разы — каждый день, тысячи раз.

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

🥫 Ещё три приёма: заготовки, лёгкий стол и подменный повар

Правильный повар под задачу — главный рычаг, но не единственный. Вот ещё три приёма, которые на кухне очевидны, а в AI работают так же.

Заготовки заранее — это кэширование (запоминание частых ответов). На кухне базовый соус варят утром большой кастрюлей, а не с нуля под каждый заказ. В AI то же: если сто человек в день спрашивают «какой у вас график?», незачем сто раз гонять модель за одним и тем же ответом — посчитали один раз, сохранили, дальше отдаём готовое мгновенно и бесплатно. Но есть ловушка, и она важная: заготовка протухает. Поменялся график работы — а бот всё отдаёт вчерашний сохранённый ответ. Поэтому кэш нужно вовремя сбрасывать (инвалидировать) — выбрасывать протухшую заготовку, как испорченный соус из холодильника. Кэш без присмотра врёт с уверенным лицом.

Лёгкий стол — это сжатие контекста. Помнишь, чем больше текста на столе, тем дороже? Значит, не вываливай повару всё подряд. Не вся история переписки, а её короткая выжимка. Не двадцать документов, а три нужных абзаца. Меньше токенов — меньше денег и быстрее ответ, без потери сути. (Это прямое продолжение разговора про то, что лишнее на столе мешает не меньше нехватки, — мы разбирали это в теме 3.7 про то, когда контекст вредит.)

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

🧾 Как это выглядит изнутри (на пальцах)

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

Заметь главное: «позвать модель» — это не первое и не единственное действие. Сначала экспедитор смотрит в заготовки, потом прикидывает мощность, попутно облегчает стол, а на случай завала держит подмену. И тонкий момент: реши экспедитор по-глупому — например, «длинный запрос = сложный, короткий = простой» — и он промахнётся. Короткое «отмени мой заказ и верни деньги по статье такой-то» бывает куда сложнее длинного пересказа отзыва. Маршрутизировать по длине текста — плохой экспедитор. Об этом — в самом тренажёре и в AI-чутье ниже.