Как урезать счёт за LLM в 10 раз, не теряя качества

Первый месяц после запуска продукта с LLM — это шок от счёта. $800 за то, что выглядит как чат-бот для двухсот пользователей. Люди начинают паниковать, прикручивать лимиты, говорить "нам этот ИИ слишком дорог".

Почти всегда дело не в модели, а в неоптимальной работе с ней. Разберу пять техник, которые на реальных проектах дают 10-кратную экономию.

1. Prompt caching

Самое главное. Если у вас есть системный промпт на 5000 токенов, который отправляется с каждым запросом, — вы платите за его обработку каждый раз. Это 80% стоимости типичного чат-приложения.

Prompt caching в Anthropic API: помечаете стабильную часть промпта специальным флагом, она кэшируется на 5 минут, повторный запрос платит за неё в 10 раз дешевле.

messages.create({
  model: "claude-sonnet-4-5",
  system: [
    { type: "text", text: LONG_SYSTEM_PROMPT, cache_control: { type: "ephemeral" } },
  ],
  messages: [...],
});

Одна строчка. Экономия на диалоговых системах — до 70% сразу.

2. Routing: лёгкие модели для лёгких задач

Не всё, что делает ваше приложение, требует Opus. Классификация входящего запроса, извлечение параметров из текста, простые трансформации — отлично делаются Haiku или Sonnet 4.5.

Схема: первый запрос идёт в Haiku с вопросом "к какой категории относится запрос, нужны ли сложные рассуждения?" Ответ определяет, куда роутить дальше. Haiku в 60 раз дешевле Opus, а на простых задачах отличает "да" от "нет" прекрасно.

В продакшене обычно 70-80% запросов может обрабатываться меньшей моделью. Экономия считайте сами.

3. Streaming для UX, batching для backend

Если у вас синхронный пайплайн из нескольких LLM-запросов, и пользователь не видит промежуточный вывод — не используйте streaming. Batch API у Anthropic стоит в 2 раза дешевле обычного, но с задержкой до суток.

Streaming оставьте только там, где его видит пользователь. Фоновые задачи, агенты-исполнители, рассылки, классификаторы — всё в batch.

4. Output tokens — где они съедают деньги

Output в 5 раз дороже input. Если модель возвращает JSON на 2000 токенов, из которых 1500 — это повторение полей и boilerplate, — вы платите за шум.

Фикс: structured output с жёсткой схемой через tool use. Либо просите модель возвращать компактный формат (CSV, короткие коды вместо названий), и разворачивайте на стороне сервера.

Ещё: устанавливайте max_tokens агрессивно. Большинство задач не требуют 4000 токенов ответа. Если поставили 500 — модель сама упакует компактнее.

5. Маленькая модель как препроцессор

Подход, который мало используется, но даёт большую экономию. Перед отправкой в Opus прогоняете запрос через маленькую локальную модель (Llama 3.2 3B, Phi-4, что угодно). Её задача: почистить шум, извлечь структуру, сократить лишний текст.

Пример: пользователь присылает запрос на 3000 токенов с историей переписки, мусором, дубликатами. Локальная 3B-модель за миллисекунды сжимает его до 400 токенов чистой сути. В Opus улетает меньше → платите меньше за input.

Локальная модель бесплатна, если у вас есть сервер. Экономия на дорогих моделях окупает инфраструктуру уже на 10K запросов в месяц.

Что не делать

Не оптимизируйте преждевременно. Сначала постройте систему на лучшей модели, убедитесь что она работает, потом режьте стоимость. Сэкономить 90% на том, что не работает, — бессмысленно.

Не переходите на более дешёвого провайдера ради цены. GPT-4 и Claude стоят разного, но качество разное, и экономия в 20% не компенсирует часы разбирательств с артефактами.

Не пытайтесь убрать LLM из пайплайна. Если задача решается регулярками — она и так должна решаться регулярками. Если вы поставили LLM — значит без него не получалось.

Итоговая стратегия

На практике стек выглядит так: prompt caching + routing в 2-3 модели по сложности + batch для всего неинтерактивного + structured output для экономии на ответах. Это даёт 5-10x от наивной реализации.

Нужна помощь оптимизировать затраты на LLM в вашем продукте? Напишите — разберём конкретный кейс.