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

В этом гайде разберём практический ФинОпс для LLM — подход к управлению затратами и производительностью моделей. Поговорим о том, как:

• снизить стоимость запросов (токены, inference, векторный поиск);
• ускорить ответы за счёт архитектуры, а не «магических галочек» в настройках;
• при этом не угробить качество и UX.

Более теоретический разбор лежит в вики-гайде «Оптимизация стоимости LLM». Здесь фокус на прикладных паттернах и чек-листах для продакшена — особенно в связке с Web3, DePIN и агентными системами.

1. Из чего на самом деле состоит «счёт за LLM»

Ошибка №1: думать, что FinOps для LLM — это «дешевле токены у провайдера». На практике расходы делятся минимум на четыре корзины:

• Токены модели — стоимость prompt + completion (OpenAI, Anthropic и т.п.) или собственный inference (GPU-время, память, сетевой трафик);
• RAG и векторная БД — хранение эмбеддингов, поиск (QPS), обновление индексов;
• Инфраструктура и обвязка — API-шлюзы, очереди, кеши, мониторинг, логирование;
• Обучение и дообучение — fine-tuning, переобучение на новых данных, эксперименты.

Хороший ФинОпс-подход начинает с простого вопроса: за что именно вы платите? Если у вас ChatGPT-подобный сервис, может оказаться, что 40–60% затрат — это не сами токены, а поисковые запросы к векторной БД и инфраструктурные накладные.

2. Сначала архитектура, потом оптимизация токенов

Интуитивный путь — сразу лезть в «компрессию промтов». Правильный путь — сначала понять архитектуру:

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

И только после этого имеет смысл сокращать контекст, переписывать промты и играться с температурами.

3. Модельный портфель: стратегия распределения задач между LLM

Одна из ключевых идей ФинОпс для LLM — model routing: вместо одной «магической» модели вы используете портфель, маршрутизируя запросы по сложности и критичности.

3.1. Типовая схема

• Small LLM / classifier:
  • быстрая, дешёвая, компактная модель;
  • используется для классификации запросов, извлечения intent, фильтрации спама/токсичности;
  • часто — open-source модель, крутящаяся у вас (или в DePIN-сетях) за копейки.
• Medium LLM:
  • «рабочая лошадка» для большинства запросов;
  • даёт достаточное качество для 70–90% кейсов;
  • может быть как облачной моделью среднего тарифа, так и локальной с умеренным GPU-футпринтом.
• Big LLM:
  • используется редко, только когда нужно (сложные задачи, VIP-клиенты, рискованные решения);
  • дорогая по токенам и задержке, но даёт максимум качества;
  • подключается через роутер по чётким правилам.

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

4. Оптимизация токенов: методы сокращения затрат без потери качества

4.1. Сокращаем контекст разумно

Очевидное (но всё равно важное): чем меньше контекст, тем дешевле запрос. Но важно не перейти грань, когда вы убили качество. Практические приёмы:

• Chunking и top-k:
  • делите документы на разумные куски (например, 300–600 токенов);
  • подбирайте top-k (количество фрагментов для RAG) по метрикам — иногда k=3 не хуже, чем k=8, но в 2–3 раза дешевле.
• Сжатие контекста:
  • используйте отдельную небольшую модель или pre-processing, чтобы сжать документы в краткие резюме;
  • в LLM-промт попадает не сырой документ, а конспект, адаптированный под задачу.
• Динамический контекст:
  • не тащите в каждый запрос одинаковые инструкции/FAQ, лучше хранить их отдельно и подтягивать только нужные куски;
  • отделяйте стабильные «правила» (короткий системный промпт) от переменного контекста RAG.

Хорошая практика — сначала собрать статистику: средняя длина промта/ответа, доля «обязательной» части и доля RAG-контента. Часто оказывается, что половина токенов — это повторяющиеся инструкции, которые можно радикально сократить.

4.2. Пишем промты «экономно»

Промты часто растут органично: добавили одну фразу, вторую, третью — и внезапно у вас 400 токенов правил для задачи, которую можно описать в 50–80.

Практический приём:

• выпишите промт в отдельный документ;
• уберите всё, что:
  • повторяется;
  • не влияет на ответ;
  • уточняет очевидное (например, «будь вежливым», если это и так по умолчанию делается пост-обработкой).
• сфокусируйтесь на формате ответа и ограничениях, а не на длинном лоре.

Уменьшение системного промта с 300 до 80 токенов даёт экономию на каждом запросе и ускоряет inference, особенно если у вас тысячи QPS.

4.3. Кэширование ответов и промежуточных шагов

LLM часто используют для повторяющихся задач — например, парсинг одинаковых типов документов, стандартизированные вопросы. Они идеальные кандидаты для кеша.

• Кэш на уровне вопрос → ответ:
  • для часто повторяющихся вопросов;
  • для внутренних запросов (например, разработчики гоняют одни и те же тестовые промты).
• Кэш на уровне chunk → summary:
  • когда вы один раз сжали документ в summary и переиспользуете его в RAG;
  • особенно полезно для статичных документов (документация, whitepaper).
• Кэш routing-решений:
  • для схожих запросов уже известно, что не нужно звать большую модель;
  • можно сразу направлять в среднюю/малую, не считая заново сложность.

Даже простой Redis/KeyDB-кэш по нормализованному запросу даёт ощутимую экономию при живом трафике.

5. Ускоряем ответы: batching, streaming, KV-кэш

Время ответа (latency) — второй столп ФинОпс: медленная система не только раздражает пользователей, но и увеличивает инфраструктурные расходы (долгие соединения, очереди, таймауты).

5.1. Batching: меньше вызовов — больше throughput

Если вы контролируете свой inference (self-hosted LLM или DePIN-инфра), batching — один из главных инструментов:

• объединяете несколько запросов в один batch на уровне GPU;
• получаете лучшую загрузку видеокарт и выше throughput;
• уменьшаете overhead на уровне сетевых и сервисных вызовов.

Компромисс: увеличивается p95 latency для отдельных запросов, если вы слишком агрессивно ждёте наполнения batch. ФинОпс-задача — найти баланс между latency и ценой GPU-времени.

5.2. Streaming-ответы для UX

Даже если технически ответ считается 1–2 секунды, стриминг (построчная отдача) сильно улучшает ощущение скорости. Пользователь видит, что система уже «думает», и меньше раздражается на p95.

В некоторых сценариях можно часть логики переносить в пост-обработку, коротко отвечая сразу, а детальную часть — дорисовывая позже или по отдельному запросу.

5.3. KV-кэш и повторное использование состояний

Для сценариев диалога или многошаговых рассуждений (chain-of-thought, агенты) важно использовать KV-кэш — механизм повторного использования промежуточных представлений внутри модели. Это снижает стоимость и latency последующих шагов.

Ключевые практики:

• разносить диалог на короткие шаги, а не каждый раз пересылать весь контекст;
• при self-hosted inference (например, через vLLM, см. вики-страницу vLLM) включать и правильно настраивать KV-кэш;
• следить за trade-off: KV-кэш потребляет память, но экономит FLOPs.

6. RAG и векторные БД: где прячутся скрытые расходы

Если у вас RAG (Retrieval-Augmented Generation), весомая часть FinOps-истории — это векторное хранилище и поиск.

6.1. Выбор векторной БД под нагрузку

Разные движки по-разному ведут себя при больших объёмах и нагрузке. Подробно это разбирается в гайде «Векторные БД в продакшене: Qdrant vs Weaviate vs Pinecone», здесь — коротко:

• Qdrant — мощная фильтрация, хороший opensource, гибкий деплой (self-hosted, managed);
• Weaviate — гибридный поиск (BM25+вектора), удобный serverless-режим;
• Pinecone — полностью управляемый сервис, хорош для enterprise-RAG, но дороже на больших объёмах.

Важный момент ФинОпс: выбирать не по «хайпу», а по модели использования — сколько запросов в секунду, объём векторов, требования к фильтрации и отказоустойчивости.

6.2. Оптимизация запросов и индексов

Типичные ошибки, которые увеличивают чек:

• Слишком большой top-k: выносите 50–100 ближайших векторов, хотя в промт реально попадает 5–10;
• Отсутствие фильтрации: ищете по всей базе, хотя можно заранее ограничить по языку, дате, типу документа;
• Переиндексация всего массива при каждом обновлении — вместо инкрементальных вставок.

Рецепт:

• меряйте recall/precision и влияние top-k на качество ответа;
• используйте фильтры (metadata) для уменьшения объёма поиска;
• грамотно планируйте шардирование и репликацию.

Больше практических советов по выбору и настройке векторной БД — в гайде «Векторные БД в продакшене: Qdrant vs Weaviate vs Pinecone» и на странице Qdrant и Weaviate в нашей вики.

7. Выбор инфраструктуры: облако, self-hosted или DePIN для LLM

Ещё один уровень ФинОпс-выбора — где вообще крутить модели:

• Облако (OpenAI, Anthropic и т.п.):
  • плюсы — простота, качество, отсутствие забот о железе;
  • минусы — стоимость токенов, зависимость от одного провайдера, возможные задержки.
• Self-hosted:
  • плюсы — полный контроль, предсказуемая стоимость (особенно при стабильной нагрузке);
  • минусы — капитальные затраты, DevOps, необходимость следить за обновлениями и безопасностью.
• DePIN-сети (GPU DePIN):
  • пример — io.net, Aethir, Nosana (см. io.net, Aethir, Nosana);
  • плюсы — гибкость по ценам, распределённая инфраструктура, Web3-совместимость;
  • минусы — вариативность latency и SLA, сложность интеграции.

ФинОпс-подход здесь — не выбирать «единую истину», а строить гибридную архитектуру:

• для критичных задач — облако высокого качества;
• для массовых и стабильных задач — self-hosted или DePIN;
• для экспериментов — то, что быстрее развернуть и проще выключить.

8. Чек-лист внедрения: 10 шагов для ФинОпс LLM-продукта

• Есть разделение моделей по размерам и задачам (small/medium/big), а не одна «универсальная».
• Промты пересмотрены: убраны лишние фразы, инструкции, повторения, всё зафиксировано в одном месте.
• RAG настроен: разумный top-k, фильтры по метаданным, нет лишних вызовов к векторной БД.
• Включён и используется KV-кэш, диалоги и пайплайны разбиты на шаги.
• Есть понятный routing-слой, который решает, когда вызывать какую модель.
• Работает кэш ответов и промежуточных результатов, особенно для повторяющихся задач.
• Считаются метрики стоимости: $/запрос, $/ответ, $/активный пользователь.
• Есть мониторинг latency (p50, p95) и throughput, а не только средняя задержка.
• Принято решение по размещению (облако/self-hosted/DePIN) для разных типов нагрузки.
• Команда понимает, где именно находятся bottlenecks и что даст следующий шаг оптимизации.

9. Вопросы и ответы: разбор сложных кейсов оптимизации LLM

Полезные материалы

• Оптимизация стоимости LLM-нагрузок (вики-гайд)
• Qdrant: векторная БД для RAG и Weaviate — сравнение подходов
• AI Security Hub: безопасность LLM и агентов
• io.net, Aethir, Nosana — DePIN-сети GPU для self-hosted inference