# Какие методы оптимизации затрат на LLM окупаются?

> Рейтинг методов оптимизации затрат на LLM по усилиям и отдаче с расчетами для кеширования, маршрутизации, пакетной обработки и дистилляции.

Счета за LLM редко требуют необычного решения. Большинство команд может убрать значительную долю расходов, если правильно считать стоимость каждого запроса, сократить ненужный вывод, повторно использовать стабильный ввод и перенести несрочную работу из синхронного процесса. Маршрутизация идет после этих изменений. Дистилляция нужна гораздо позже.

Я видел, как команды неделями строили хитрый маршрутизатор моделей, хотя каждый запрос по-прежнему нес руководство на 12 000 токенов и выдавал 900 токенов, которые никто не читал. С экономической точки зрения это обратный порядок. Сначала оптимизируйте токены и уровень обслуживания, затем решайте, оправдывает ли оставшийся объем новую инфраструктуру моделей.

В рейтинге ниже учтены трудозатраты, вероятная отдача и операционный риск. В денежном примере 100 000 запросов в месяц, по 6 000 входных и 500 выходных токенов в каждом. Для конкретного ориентира я беру опубликованные стандартные тарифы GPT-5.6 Terra: $2,50 за миллион входных токенов, $0,25 за миллион кешированных входных токенов и $15 за миллион выходных токенов. Цены меняются, поэтому сохраняйте формулы и подставляйте актуальный тариф перед утверждением проекта.

## Сопоставьте экономию со своей структурой токенов

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

Считайте этот рейтинг очередью инвестиций, а не универсальным эталоном. Диета промптов и ограничения вывода требуют мало работы и экономят деньги на каждом удаленном токене, но в запросе должен остаться контекст для полного ответа. Кеширование промптов требует малых или средних усилий и окупается, когда стабильный префикс занимает большую часть ввода. Его ограничивают требования к точному повторению и правила провайдера.

Пакетная обработка тоже требует малых или средних усилий. Для подходящих асинхронных задач она дает опубликованную скидку 50% на токены, но результата иногда приходится ждать несколько часов. Маршрутизация требует средних усилий и может сэкономить больше, если дешевая модель справляется со многими запросами, однако для нее нужны размеченные проверки и логика отката. Дистилляция требует больших усилий и стоит последней, поскольку обучение, обслуживание, дрейф и повторное обучение способны поглотить ожидаемую выгоду.

Сначала рассчитайте расходы по измеренным классам токенов, а не по общей сумме счета. Запрос может содержать обычные входные токены, кешированные входные токены, видимый вывод, скрытые токены рассуждений, вызовы инструментов и обращения к поиску данных. Провайдер может назначать для этих классов разные цены. Если событие учета сводит все в одно число, команда оптимизации не сможет объяснить экономию или заметить ухудшение.

Для нашего примера базовые месячные расходы считаются просто:

```text
input_cost  = 100,000 * 6,000 / 1,000,000 * $2.50 = $1,500
output_cost = 100,000 *   500 / 1,000,000 * $15.00 = $750
total_cost  = $2,250
cost_per_successful_request = total_cost / successful_requests
```

Последняя строка важнее стоимости вызова. Дешевый вызов, который завершился неудачей и потребовал повтора, может стоить дороже одного успешного вызова. Записывайте хотя бы `request_id`, класс задачи, модель, входные токены, кешированные токены, выходные токены, задержку, число повторов и оценку результата. Финансовая панель без показателя результата поощряет неработающие системы.

Не ограничивайтесь средним числом токенов. Храните p50 и p95 для входных и выходных токенов по каждому классу задач. Длинные диалоги, огромные найденные документы и зацикленные агенты прячутся в хвосте распределения. Я видел, как небольшая доля запросов создавала почти весь неожиданный расход, хотя среднее значение выглядело вполне прилично.

Так же внимательно распределяйте общие расходы. Индекс для поиска, плата за хранение кеша, шлюз или сервис оценки могут обслуживать несколько классов задач. Вынесите эти расходы в отдельную группу и распределяйте их по понятному показателю, например по числу запросов, сохраненным токенам или расходам на модели. Не прячьте их внутри одной удобной задачи. Распределение не будет идеальным, но единое правило позволяет основателю сравнивать месяцы и не дает одному маршруту выглядеть искусственно дешевым.

Помечайте и эксперименты. Когда команда меняет промпт, модель, префикс кеша или правило очереди, прикрепляйте версию конфигурации к каждому событию использования. Без версии аналитики сравнивают смешанные группы и приписывают случайные колебания последнему изменению. Оставляйте прежний путь доступным достаточно долго, чтобы получить контрольную группу при тех же условиях трафика. Во время теста это немного увеличивает расходы, зато не позволяет утвердить экономию, которая исчезнет после полного запуска.

## Диета промптов окупается раньше архитектурных изменений

Диета промпта должна убирать контекст, который не влияет на ответ, и ограничивать вывод длиной, которую продукт способен использовать. Обычно это самый быстрый способ сэкономить, потому что изменения затрагивают конфигурацию и сборку контента, а не инфраструктуру моделей.

Начните с вывода. В нашем примере выходной токен стоит в шесть раз дороже обычного входного. Если убрать 100 ненужных выходных токенов из каждого запроса, месячная экономия составит $150. Удаление 100 входных токенов сэкономит $25. Команды часто шлифуют системный промпт, но игнорируют модель, которая пишет пять абзацев для блока интерфейса, рассчитанного на два предложения.

Устанавливайте лимит вывода для каждой задачи, а не единый максимум. Метке категории может хватить 10 токенов. Ответу клиенту может потребоваться 250. Для изменения кода иногда нужны тысячи. Затем простыми словами или схемой укажите модели ожидаемый формат. Лимит останавливает сбой, а инструкция его предотвращает.

Входной текст нужно редактировать строже. Удаляйте повторяющиеся правила, примеры с одинаковым поведением, многословное описание роли, полные каталоги инструментов, которые не нужны на текущем шаге, и найденные фрагменты со слабой релевантностью. Сохраняйте ограничения безопасности, определения предметной области, требования к формату и данные, которые действительно нужны задаче. Краткость сама по себе не означает качество. Пропущенное ограничение, которое увеличивает число повторов, съест всю экономию.

Допустим, команда убрала из каждого запроса 1 000 входных и 100 выходных токенов. Новый состав равен 5 000 входных и 400 выходных токенов:

```text
input  = 500M * $2.50 = $1,250
output =  40M * $15.00 = $600
total  = $1,850
saving = $400, or 17.8%
```

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

Популярный совет предлагает сжать каждую инструкцию до непонятной стенографии. Это плохой совет. Токенизаторы считают символы неравномерно, инженерам трудно безопасно проверять плотный код промпта, а модели иногда нужны ясные формулировки, чтобы выполнить ограничение. Сначала удаляйте ненужный смысл, а потом сокращайте полезный. Проверяйте каждое изменение на одном наборе оценок и отменяйте его, если доля принятых ответов выходит за согласованный допуск.

Диета промптов включает и управление диалогом. Не отправляйте всю историю чата без ограничения. Сохраняйте последние реплики, нужные для понимания ссылок, держите постоянные сведения о пользователе в структурированном состоянии, а старый материал кратко пересказывайте только после проверки на потерю обязательств. Резюме, которое потеряло обещание возврата денег или исключение из правил безопасности, обойдется дорого, но счет за токены этого не покажет.

## Кеширование выигрывает на стабильных префиксах

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

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

OpenAI показывает кешированные токены среди деталей входных токенов в объекте использования API. Anthropic разделяет создание кеша и чтение из него. В опубликованной таблице цен пятиминутная запись в кеш стоит в 1,25 раза дороже базового ввода, а попадание в кеш стоит 0,1 от базовой цены. Google описывает неявное кеширование для новых моделей Gemini и советует размещать большой общий контент в начале. Механика различается, но все три провайдера поощряют стабильные повторяющиеся префиксы, а не просто похожие идеи.

Предположим, что 3 000 из 5 000 токенов сокращенного промпта попадают в кеш при каждом запросе. По тарифам нашего примера получаем:

```text
cached_input = 300M * $0.25 = $75
fresh_input  = 200M * $2.50 = $500
output       =  40M * $15.00 = $600
total        = $1,175
```

Это на 47,8% ниже исходных $2 250 и на 36,5% ниже результата после диеты промпта. Эффект велик, потому что в этом тарифе кешированный ввод стоит в десять раз дешевле обычного, а общий префикс достаточно длинный.

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

```text
break_even_reuses = cache_write_premium / (fresh_read_price - cached_read_price)
```

Измеряйте `cached_tokens / cache_eligible_tokens` по реальным событиям использования. Не делайте вывод о попаданиях только по снижению задержки. Даже временная метка, другой порядок свойств JSON, динамическое описание инструмента или персональное уведомление перед стабильным блоком могут нарушить совпадение префикса. Приведите сериализованные объекты к единому виду, ставьте изменчивые значения в конец и осознанно меняйте версию общего префикса.

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

## Отправляйте в пакет задачи, которые действительно могут ждать

Пакетная обработка дает самую понятную фиксированную скидку, если пользователю не нужен мгновенный ответ. В документации OpenAI Batch API сказано, что задания выполняются в пределах 24 часов со скидкой 50%. Anthropic публикует скидку 50% на входные и выходные токены в пакетном режиме. Google публикует такое же снижение на 50% для своего Batch API. Это условия тарифов, а не оценки производительности.

Для пакетной обработки подходят ночная классификация, извлечение данных из документов, обновление эмбеддингов, прогоны оценок, обогащение каталогов, создание отчетов и черновики писем в очереди, которые человек проверит утром. Живой чат, интерактивное программирование, решения по мошенничеству и запрос пользователя, который ждет на странице, подходят плохо, даже если финансовому отделу нравится цена.

Если перенести все запросы из исходного примера на пакетный тариф провайдера с половинной ценой, расходы снизятся с $2 250 до $1 125. Если ждать могут только 60% запросов и состав токенов у них совпадает со всем потоком, экономия составит 30%:

```text
batchable_share = 60%
discount        = 50%
portfolio_saving = 60% * 50% = 30%
new_total        = $2,250 * 70% = $1,575
```

Отправкой файла JSONL работа не заканчивается. Продуктивному пакетному процессу нужны стабильные пользовательские идентификаторы, идемпотентный импорт результатов, обработка ошибок по каждому элементу, учет истечения срока и очередь для окончательно неудачных задач. Весь пакет может завершиться, хотя отдельные элементы не сработали. Если импортер считает отсутствующие строки пустыми ответами, бизнес получает незаметную потерю данных со скидкой.

На некоторых платформах пакетную обработку и кеширование промптов можно сочетать, но ценовые коэффициенты и поведение кеша различаются. Проверьте актуальную таблицу для выбранной модели и запустите небольшой оплачиваемый образец. Нельзя складывать экономию 50% от пакетного режима и 90% от кеша так, будто проценты равны долларам. Применяйте каждую ставку к подходящему классу токенов и показывайте уравнение.

Обычно полезны две очереди. Стандартная обслуживает задачи со сроком в несколько секунд. Пакетная принимает задачи со сроком в несколько часов. Записывайте крайний срок в данные задания, переносите его в срочный режим только при приближении этого срока и измеряйте частоту таких переносов. Если приходится переносить половину задач, продукт на самом деле не допускает пакетной задержки.

## Маршрутизируйте по измеренной сложности, а не по длине промпта

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

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

Для прозрачной оценки отправим 70% сокращенной нагрузки в GPT-5.6 Luna по опубликованным тарифам: $1 за миллион обычных входных токенов, $0,10 за миллион кешированных входных токенов и $6 за миллион выходных токенов. Остальные 30% оставим на Terra. Сохраним допущение о 3 000 кешированных и 2 000 обычных входных токенах, а также о 400 выходных токенах на запрос:

```text
Luna, 70%: 210M*$0.10 + 140M*$1.00 + 28M*$6.00  = $329.00
Terra, 30%: 90M*$0.25 +  60M*$2.50 + 12M*$15.00 = $352.50
routed total = $681.50
```

Расчетная сумма после маршрутизации на 69,7% ниже исходной. Это число не служит прогнозом для другого продукта. Оно предполагает, что дешевая модель успешно обрабатывает 70% запросов, отдельный классификатор ничего не стоит, длина вывода не меняется, попадания в кеш стабильны и повторов нет. Измените любое условие, и результат изменится.

Передача запроса сильной модели тоже может уничтожить экономию. Если 20% вызовов дешевой модели приходится повторять на дорогой, эти запросы дважды оплачивают ввод и вывод. Отслеживайте долю принятых ответов с первой попытки, частоту передачи, полную стоимость после передачи и качество каждого маршрута. Маршрутизатор успешен только тогда, когда снижается стоимость принятого результата.

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

Начните с правил, прежде чем строить обучаемый маршрутизатор. Фиксированные классы задач легко отлаживать, и часто они дают большую часть выгоды. Обучаемый маршрутизатор оправдывает обслуживание только после того, как матрица ошибок простых правил покажет достаточный объем неоднозначных случаев.

## Дистилляция требует долгого обязательства

Дистилляция окупается, когда узкая задача имеет большой стабильный объем, а меньшая модель может научиться нужному поведению по отобранным ответам модели-учителя. Это не переключатель в тарифе. Команда отвечает за обучающие данные, оценку, развертывание, мощности, наблюдение и повторное обучение.

В этой области часто смешивают дообучение и дистилляцию. Дообучение адаптирует модель к примерам, формату, тону или поведению в предметной области. При дистилляции более сильная модель-учитель создает метки или распределения вероятностей для меньшей модели-ученика. Дообученная передовая модель может повысить качество без снижения цены инференса. Цель дистиллированной небольшой модели состоит в сохранении достаточного качества при меньшей стоимости обслуживания. Экономический расчет зависит именно от этой разницы.

Перед сбором данных рассчитайте точку окупаемости:

```text
break_even_requests = (data + training + evaluation + deployment + retraining)
                      / (teacher_cost_per_accepted_result - student_cost_per_accepted_result)
```

Рассмотрим условный проект с общими начальными и ближайшими расходами на обслуживание в $12 000. Если принятый результат учителя стоит $0,010, а результат ученика с учетом хостинга, повторов и отката стоит $0,002, экономия равна $0,008 на результат. Окупаемость наступит после 1,5 млн принятых результатов. При 100 000 результатов в месяц модель начнет приносить чистую экономию через 15 месяцев. Если задача меняется каждый квартал, проект не достигает своей точки окупаемости.

Этот условный пример объясняет, почему команды завышают отдачу. Они сравнивают цену токенов API учителя с чистым временем GPU и не учитывают простаивающие мощности, запас для автоматического масштабирования, наблюдение, время инженеров и откат к учителю. Включайте все регулярные расходы. Собственная модель-ученик с загрузкой 20% может стоить дороже управляемого API, где оплата берется только за вызов.

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

Ответы учителя тоже нужно проверять. Запуск большой модели не создает достоверные данные. Отфильтруйте ответы с неверным форматом, удалите конфиденциальные сведения, сбалансируйте редкие случаи и сохраните контрольный набор с человеческой разметкой, который не создавал ни один учитель. Иначе ученик получит высокий балл, просто повторяя слабые места учителя.

## Объединяйте методы в одной модели затрат

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

В нашем расчете диета промпта снизила сумму с $2 250 до $1 850, кеширование сократило ее до $1 175, а маршрутизация до $681,50. Если 60% этой нагрузки действительно получает пакетную скидку 50% на все оплачиваемые классы токенов, расчет выглядит так:

```text
interactive_share = $681.50 * 40% = $272.60
batch_share       = $681.50 * 60% * 50% = $204.45
combined_total    = $477.05
cumulative_saving = 78.8%
```

Считайте $477,05 вариантом для анализа чувствительности, а не обещанием бюджета. Он зависит от того, разрешает ли провайдер сочетать предполагаемые скидки, одинаков ли состав токенов в очередях, действительно ли дешевая модель принимает 70% запросов и сохраняется ли качество. Полезный результат здесь дает логика таблицы, которая стоит за числом.

Постройте модель затрат со строками для классов задач и столбцами для числа запросов, обычного ввода, кешированного ввода, вывода, вызовов инструментов, доли повторов, тарифа модели, доли пакетных задач и уровня приемки. Финансовый отдел должен менять одну ячейку и видеть месячный эффект. Инженеры должны связывать каждую ячейку с телеметрией использования или опубликованным тарифом.

Следите за сочетаниями, которые повышают расходы. Более короткий промпт может изменить префикс и снизить попадания в кеш. Небольшая модель может писать более длинные ответы или чаще вызывать инструменты. Пакетное задание может повторно отправить весь файл вместо неудачных строк. Дистиллированной модели может потребоваться дорогой откат к учителю в редких случаях. После каждого изменения измеряйте объединенную систему, а не перемножайте экономию из лабораторных тестов.

Храните тарифы и допущения оптимизации рядом с конфигурацией сервиса. Когда провайдер меняет названия моделей или цены, пересчитывайте модель. Маршрут, который экономил деньги в прошлом квартале, может потерять смысл после снижения цены сильной модели или роста стоимости вывода дешевой.

## Ограничения качества превращают снижение цены в экономию

Оптимизация расходов завершена только тогда, когда более дешевая система отвечает требованиям продукта. Определите эти требования до изменения промптов или моделей. Иначе каждое ухудшение вызовет спор, а самая дешевая конфигурация победит, когда остальные устанут спорить.

Используйте показатели для конкретных задач. Для структурированного извлечения нужны точность полей, соблюдение схемы и правильный отказ. Для ответов поддержки нужны соответствие правилам, опора на факты, доля решенных вопросов и объем правок человека. Для агентного программирования нужны тесты, статические проверки, проверка безопасности и число циклов исправления. Одна общая оценка модели-судьи не покрывает все эти задачи.

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

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

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

Заявленная экономия должна сходиться со счетом. Сложите измеренную стоимость из событий использования, сравните с суммой провайдера и объясните разницу округлением, платой за инструменты, хранением или кредитами. Затем сравните оптимизированную группу с контрольной при одинаковой структуре спроса. Снижение счета в тихий месяц не доказывает успех инженерной работы.

## Внедряйте оптимизацию в порядке зависимостей

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

1. В первую неделю настройте учет классов токенов, результатов, повторов, задержки, класса задач и стоимости запроса. Сопоставьте данные за полные сутки с отчетом провайдера.
2. Во вторую неделю ограничьте вывод и удалите ненужный материал из промпта под флагом функции. Запустите неизменный набор проверок и небольшую рабочую группу.
3. В третью неделю стабилизируйте общие префиксы, измерьте долю подходящих для кеша токенов и реальные попадания, затем перенесите действительно несрочные задачи в пакетную очередь.
4. В четвертую неделю оцените более дешевую модель по классам задач и внедрите простые правила маршрутизации с откатом к дорогой модели.
5. Готовьте предложение по дистилляции только в том случае, если измеренный оставшийся объем, стабильность задачи и срок окупаемости оправдывают проект.

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

Если у основателей нет чистой телеметрии или набора оценок, Team & AI Audit от oleg.is поможет описать потоки токенов, состав задач и инженерные работы до более крупного преобразования. Фиксированная услуга стоит $5 000, занимает пять рабочих дней и гарантирует не менее $50 000 выявленной годовой экономии, иначе аудит проводят бесплатно. Это имеет смысл только для компании, чьи расходы на инженеров и ИИ достаточны для такой цели.

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