Глава 16 — Стратегии сокращения затрат в продакшене
Заключительный пост поглавного разбора LLM Primer VI: Scaling AI Systems. Каталог ортогональных приёмов, складывающихся в треть или половину счёта прошлого месяца.
Зачем эта глава существует
Предыдущие две главы рассказали команде, куда идут деньги, и дали фреймворк для решения, на какой стороне линии API-против-выделенного сидеть. Эта глава — каталог движений, которые команда может сделать, когда те решения улажены. Движения в основном независимы от позы — они экономят деньги на API, они экономят деньги на выделенном железе, они экономят деньги в гибриде — и они складываются. Команды, применяющие их последовательно, шесть месяцев в направленном усилии по стоимости обычно обнаруживают, что их счёт за инференс — треть-половина того, чем был. Ни одно из движений не экзотично; все требуют направленной инженерии; стоимость их построения мала относительно того, что они экономят.
16.1 Интеллектуальная маршрутизация моделей — самый большой одиночный рычаг
Продакшен-трафик не равномерно сложен. Половина или больше запросов достаточно просты для бюджетного тира модели, на порядок дешевле фронтирного; меньшая доля действительно нуждается в фронтире. Команда, маршрутизирующая всё в топ, переплачивает за простые в 10–20 раз. Правильная архитектура — роутер, классифицирующий каждый запрос и диспетчирующий на самый дешёвый тир, способный его обработать. Градиент стоимости на момент написания — примерно 30:1 на входе и 20:1 на выходе между фронтиром ($15–30/M вывод) и бюджетным ($0,10–1/M). Варианты роутера — от эвристики по форме запроса (длина, формат, маркеры tool-use) до маленького бюджет-тировского классификатора, выдающего метку тира, до обученного роутера, обученного на исторических данных «какая-модель-действительно-сработала». Ограничения дизайна: дёшево и быстро (меньше 100 мс, десятая цента), наблюдаемо (каждое решение логируется с фичами и исходом), безопасно по умолчанию (при неуверенности маршрутизировать вверх — цена over-route — один лишний доллар, цена under-route — видимая регрессия качества).
16.2 Компакция, batch API и семантический кэш выкупают большие куски
Компакция контекста атакует квадратичный рост входа, названный в главе 14. Простейшая форма — скользящее окно: держать последние K ходов дословно, заменить всё до них бюджет-тировским резюме; вызов резюмирования стоит долю цента и ужимает вход на каждом последующем ходу с тысяч дословных исторических токенов до сотен токенов резюме. Более сложный компактор сохраняет определённые виды дословно (код, вывод инструментов, данные, предоставленные пользователем) и резюмирует остальное. Асинхронные batch API за полцены обрабатывают любую нагрузку без синхронного бюджета задержки — ночное резюмирование, переклассификация, пре-генерация для A/B-теста, обновление эмбеддингов — категория больше, чем команды поначалу распознают, и инженерия для перевода нагрузки в batch тривиальна. Семантический кэш отвечает до вызова модели: эмбедить каждый запрос, искать в векторном индексе прежних пар запрос-ответ, вернуть закэшированный ответ, если сходство пересекает порог. Два пользователя, спрашивающие «какова политика возврата» и «как мне вернуть товар», попадают в тот же вход. На FAQ-трафике кэш-хит-рейты 30–50 процентов рутинны, и самый дешёвый токен — тот, что никогда не сгенерирован.
16.3 Движения складываются мультипликативно, а не аддитивно
Возьмите агента, чей счёт вырос до $4 000/месяц при 1 000 запросов/день. Маршрут: 60 процентов бюджетный, 30 процентов средний, 10 процентов фронтир → смешанная стоимость падает до 28 процентов фронтирной ставки, счёт падает до $1 100. Компакция: раздув входа сокращён вдвое, счёт падает до $770. Перевод 20 процентов в batch: $720. Семантический кэш с 25-процентным хит-рейтом: $540. С $4 000 до $540 — 86-процентное сокращение — без видимого пользователю изменения. Два дополнительных движения зарабатывают свою долю даже без собственных секций. Аудит промптов — прочитать каждый промпт свежим глазом, удаляя всё, что не может оправдать свои токены — обычно находит 10–20 процентов расхода на сокращение без изменения поведения. Явный потолок max_tokens останавливает ответ от разрастания до 2 000 токенов, когда приложению нужно было только 300 — почти 7-кратная переплата на этом запросе. Ментальная модель — из Тома IV: у каждого запроса есть удельная стоимость, а инженерная работа — маршрутизировать каждый запрос через дешёвые слои первым делом и достигать дорогого слоя только когда необходимо.
Что закрывает глава 16
Том открылся авторегрессионным узким местом — неснимаемым фактом, что генерация LLM последовательна и что железо, столь хорошее в параллельной арифметике, тратит большую часть времени, ожидая память. Каждая глава после этого была ответом на этот центральный факт на другом уровне стека. Аппаратные главы построили физическую подложку. Модельно-уровневые главы уменьшили модель. Системно-уровневые главы извлекли максимум полезной работы на такт. Главы движка и оркестрации привели это в продакшен. Экономические главы описали, как команда, эксплуатирующая систему, за неё платит. Каждый слой — ответ на предыдущий, и дисциплина запуска LLM на масштабе — интеграция всех их одними и теми же людьми или по крайней мере людьми, которые могут говорить друг с другом на одном словаре.
На этом книга заканчивается. Серия продолжается в Томе VII — Безопасность ИИ, который расширяет продакшен-инженерную дисциплину этого тома на моделирование угроз, guardrails, песочницы для сгенерированного моделью кода, смягчение prompt-injection, фильтрацию вывода и регулирование, которое сейчас определяет, как всё вышеперечисленное должно разворачиваться. Инфраструктура, построенная через этот том, — флот инференса, слой маршрутизации, песочницы, среды исполнения агентов — это ровно та инфраструктура, на которой играются заботы безопасности Тома VII. Масштабирование и безопасность — две стороны одной задачи: одна — инженерия роста, другая — инженерия устойчивости к атакам, которые этот рост приглашает.
