Cost optimization LLM — это совокупность инженерных и продуктовых практик для снижения стоимости ответа без потери качества и SLO. Основные рычаги: токены (вход/выход), кэширование (prefill, KV), планирование (непрерывный батчинг, admission control), архитектура (роутинг по моделям, квантование), и RAG-экономика (индекс, ретривер, переранжирование).
Связанные страницы: Model serving, Model evaluation, Evals, Контекстное окно, KV cache, Prefill cache, Retriever, Vector index, Top-k, Top-p, Prompt injection, Prompt leakage, Model poisoning, RAG-хаб.
Из чего складывается стоимость ($/answer)
Облачная модель оплаты токенов Пусть c_in — цена за 1k токенов ввода, c_out — цена за 1k токенов вывода; T_in, T_out — фактические токены: Cost/answer ≈ (T_in/1000) × c_in + (T_out/1000) × c_out.
Собственный сервисинг (GPU/CPU) Добавляется время на GPU/CPU, энергия и эксплуатация: Cost/answer ≈ GPU_час × t_GPU + CPU_час × t_CPU + сеть + хранение. Где t_GPU — доля часа ускорителя, потраченная на префилл/декод (см. serving).
Что дороже всего
- Длинные исторические промпты (T_in) и болтливые ответы (T_out).
- Слабый ретривер → лишние чанки в контексте.
- Плохой планировщик → низкий tokens/s, высокий p95 → больше GPU-времени.
Рычаги экономии: вид сверху
| Уровень | Цель | Приёмы |
|---|---|---|
| Продукт | Отсекать дорогие сценарии | TL;DR и конденсация; шаблоны/кнопки вместо «свободного» диалога |
| Промпт | Урезать T_in | Короткий системный пролог, минимум few-shot, жёсткие стоп-последовательности |
| Маршрутизация | «Дешёвая, но достаточная» модель | Каскад моделей, эскалация по уверенности/evals |
| Декодер | Стабильный T_out и высокий tokens/s | max_new_tokens, стоп-токены, top-k/top-p, спекулятивный декод |
| Кэширование | Повторное использование вычислений | Prefill прологов, KV; кэш эмбеддингов/ретрив-результатов |
| Планирование | ↑ утилизацию без роста p95 | Непрерывный батчинг, admission control, «бюджеты токенов» |
| RAG | Контекст без «воды» | Чанкинг/дедуп/MMR, фильтры метаданных, умеренный k, ленивое переранжирование |
Промпт-инжиниринг, который экономит
- Короткая рамка роли: 2–4 правила вместо длинного «манифеста». Стиль/тон — параметрами, а не токенами.
- Few-shot → правила: где можно — заменяйте примеры на схемы валидации/стоп-последовательности.
- Структура вывода: JSON/ключевые пункты + max_new_tokens.
- Без «эха» вопроса: запрет «пересказывать» входной текст.
- Анти-утечки: правило «не цитируй системные инструкции» снижает PLR и лишние токены.
Роутинг по моделям и каскады качества
- Пирамида: маленькая → средняя → большая модель только при неуверенности.
- Триггеры эскалации: низкая уверенность/лог-пробы, невалидный формат, провал сигнальных evals.
- Sticky-роутинг: закрепляйте модель за повторяющимися задачами — растёт hit-rate кэшей.
- Право на «не знаю»: короткий отказ дешевле, чем дорогая «галлюцинация».
Декодер: влияние настроек на деньги
- max_new_tokens и стоп-последовательности → верхняя граница T_out.
- Спекулятивный декод: черновая модель + подтверждение «большой» → ускорение 2–3× на длинных ответах.
- Beam-search редко выгоден для open-ended: ↑ память KV, ↓ tokens/s.
Кэши: prefill, KV, эмбеддинги
Prefill-кэш (страница) — шаринг «общего пролога» (рамка роли, формат ответа). KV-кэш (страница) — хранит K/V внимания для уже «пройденных» токенов (ветвления/продолжения). Политики: LRU/TTL, горячее на GPU, холодное — на CPU; изоляция по доверию (не шарить префиксы между тенантами — см. утечки).
Кэш в RAG: эмбеддинги вопросов и top-k документов; инвалидируйте при переиндексации/смене модели эмбеддингов.
Непрерывный батчинг и приёмка запросов
См. serving. Коротко:
- Continuous batching подмешивает новые запросы между шагами декода → ↑ утилизацию без HoLB.
- Admission control: лимиты prefill_tokens/decode_tokens per-tenant, таймаут очереди.
- Бюджеты: токены в день/ключ/организацию; ранний отказ «по бюджету».
- Sequence packing и Paged KV → меньше фрагментации памяти, выше tokens/s.
Квантование и ядра ускорения
- Weights: INT8/INT4 (смешанные режимы FP16/BF16 на «чувствительных» слоях).
- KV: INT8/FP8 — сильно снижает footprint при минимальной потере качества.
- FlashAttention / fused kernels / paged attention — ускоряют префилл/декод.
- Любые оптимизации подтверждайте на своих evals.
Экономика RAG: платим только за полезный контекст
- Чанкинг: 400–1200 токенов, перекрытие 50–150 → меньше «воды».
- Гибридный поиск (keyword+dense) + MMR — меньше дублей.
- Фильтры метаданных: язык/дата/продукт до ретрива.
- k «по сценарию»: 5–8 чанков чаще достаточно; не тяните 20 «про запас».
- Переранжирование: кросс-энкодер только при низкой уверенности.
- Цитирование и faithfulness (см. оценка) — короче, предметнее ответы.
Инструменты и агенты: меньше шагов — меньше денег
- JSONSchema для инструментов: LLM заполняет строгие аргументы, а не «роман».
- Idempotent вызовы, кэш промежуточных артефактов.
- Гейтинг tool-use: запускаем инструмент по условиям (регекс, длина, низкая уверенность).
- Лимит циклов в многоагентности; эвристики остановки; отчёты о «пустых» вызовах.
Метрики FinOps: что мерить каждую неделю
| Метрика | Смысл | Ориентир/заметка |
|---|---|---|
| Cost/answer | $ на ответ | Падение при сохранении качества/SLO |
| Tokens_in/out | Токены ввода/вывода | Лимиты по сценариям и моделям |
| Cache hit-rate | Prefill/KV/RAG | 60–90% для повторяющихся прологов |
| Latency p50/p95/p99 | Задержки | Контролируйте хвосты; разделяйте префилл/декод |
| Tokens/s (decode) | Скорость генерации | Рост без деградации качества |
| ASR/PLR | Устойчивость к атакам/утечкам | Низкие значения (см. Evals) |
| RAG recall@k / dup-rate | Полнота/дубли | Высокий recall, низкие дубли |
| Timeout/abandon rate | Потери UX и денег | Сигнал настройки admission control |
Добавляйте пер-тенант отчётность и «тепловую карту» самых дорогих маршрутов.
Политики и лимиты (budgets-as-code)
- Квоты: дневной/месячный бюджет по ключам/тенантам.
- Границы: max_context, max_new_tokens, запрещённые «дорогие» комбинации.
- Fail-open/closed: для критичного сценария — короткий шаблонный ответ, для остальных — вежливый отказ.
- Алерты: всплески T_in, падение hit-rate, рост p95/p99.
Числовые примеры экономии
Базовый кейс (без кэша) Промпт 2 500 токенов, ответ 500; c_in=$1/1k, c_out=$2/1k. Cost ≈ 2,5×1 + 0,5×2 = 3,5.
С prefill-кэшем пролога (−1 500 токенов) Cost ≈ 1,0×1 + 0,5×2 = 2,0 (−43%).
Плюс RAG-урезание k с 12 до 6 + переранж по требованию Средний T_in падает ещё на 20–30% → итог −50–60%.
On-prem эффект ускорений Спекулятивный декод (2×) + FlashAttention + INT8 KV → tokens/s ↑, p95 ↓ → −30–45% GPU-времени на ответ.
Плейбук внедрения (пошагово)
- Замерьте базу: Cost/answer, Tokens_in/out, p95, hit-rate, recall@k (если RAG).
- Укоротите промпт: рамка роли, стоп-последовательности, max_new_tokens, минимум few-shot.
- Настройте планирование: continuous batching, admission control, бюджеты токенов.
- Оздоровите RAG: чанкинг, фильтры, MMR, умеренный k, ленивое переранжирование.
- Роутинг по моделям: дешёвая по умолчанию; эскалация по критериям (уверенность/evals/формат).
- Ускорения: спекулятивный декод, квантование весов и KV, FlashAttention.
- Политики/алерты: квоты/лимиты/бюджеты в конфиге, мониторинг «дорогих» путей.
- Регрессы: еженедельные evals качества/безопасности/производительности.
- Ретро-борд: топ-10 самых дорогих запросов → целевые правки.
Анти-паттерны (что «съедает» бюджет)
- «Одна большая модель на всё» — без роутинга.
- «Энциклопедический пролог» — десятки правил и примеров.
- «Всегда k=20 в RAG» — избыточный контекст и дубли.
- «Beam-search по умолчанию» — KV-взрыв и p95.
- «Нет стоп-последовательностей» — бесконечная «болтовня».
- «Общий кэш префиксов» на всех — риск утечек и деградаций качества.
- «Нулевая наблюдаемость» — решения «вслепую».
Частые вопросы (FAQ)
Реально ли добиться −50% к стоимости без потери качества?
Да. Комбинацией: prefill-кэш, укороченный промпт, разумный k в RAG, роутинг моделей и спекулятивный декод.
Что важнее — экономить T_in или T_out?
Зависит от тарифов и сценария. Часто дороже вход: режьте промпт/контекст. Выход держите max_new_tokens и стоп-последовательностями.
Квантование «ломает» качество?
Проверяйте на своих evals. Смешанные режимы (INT8 KV + BF16 «верх») часто дают оптимум.
Всегда ли нужен переранжировщик в RAG?
Нет. Делайте «двухступенчатый» режим: дешёвый отбор → переранжирование только при низкой уверенности.
Как считать экономию на on-prem?
Мерьте tokens/s, p95 и долю часа GPU/CPU на ответ. Любое ускорение, повышающее tokens/s при том же качестве, напрямую снижает $/answer.
Мини-глоссарий
- Cost/answer — полная стоимость ответа (токены/вычисления/инфра).
- Prefill cache — кэш общего префикса промпта.
- KV cache — кэш ключей/значений внимания для уже «пройденных» токенов.
- Continuous batching — подмешивание последовательностей между шагами декода.
- Speculative decoding — ускорение за счёт «черновой» модели.
- MMR — разнообразие выдачи ретривера, отбрасывает дубли.
- Recall@k — полнота извлечения в RAG.
- Tokens/s — скорость генерации токенов.