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

Предел в 32, 128 или 256 тысяч токенов означает, что модель технически принимает такой ввод. Он не означает, что каждый запрос следует заполнять до предела, что модель одинаково хорошо использует все части текста или что длинный ввод почти бесплатен.

Где возникает «налог длинного контекста»

Инференс языковой модели состоит из двух разных участков. На этапе prefill сервер обрабатывает весь входной текст и готовит состояния внимания. Затем на этапе decode генерирует ответ по одному токену. Чем длиннее исходный запрос, тем больше работы до появления первого токена и тем больше памяти нужно удерживать для текущей последовательности.

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

В примере NVIDIA для Llama 2 7B в FP16 один запрос длиной 4 096 токенов занимает около 2 ГБ только под KV-кэш. Если механически увеличить длину до 16 384 токенов, для той же архитектуры и точности расчёт даёт около 8 ГБ на последовательность. Восемь таких одновременных запросов потребовали бы около 64 ГБ только для кэша — без весов модели, активаций и служебного запаса.

Это модельный пример, а не оценка современной модели по названию. Grouped-query attention, sliding-window attention, квантизация кэша, распределение по GPU и особенности рантайма меняют цифру. Реальный расчёт нужно делать из `config.json` конкретной модели и измерений на целевом сервере.

Почему стоимость проявляется по-разному

В облачном API длинный контекст обычно виден как рост оплачиваемых входных токенов. Если одинаковую задачу решать запросом на 16 тысяч токенов вместо четырёх, входной объём увеличивается в четыре раза. Тариф, кэширование провайдера и скидки могут менять рублёвую разницу, но лишние токены никуда не исчезают.

В локальном контуре счёт выглядит иначе. Компания уже купила или арендует GPU, поэтому кажется, что следующий токен бесплатен. На практике длинный ввод влияет на:

  • время до первого токена;
  • число запросов, помещающихся в KV-кэш одновременно;
  • размер очереди и p95 задержки;
  • частоту вытеснений и повторных вычислений;
  • требуемый класс GPU или число устройств;
  • энергопотребление и резерв мощности;
  • способность обслужить пиковую нагрузку без второго сервера.

vLLM прямо связывает нехватку KV-кэша с вытеснением запросов и повторным вычислением, что ухудшает сквозную задержку. Chunked prefill делит длинный ввод на части и помогает планировщику сочетать его с генерацией других запросов. Это полезная оптимизация, но она не превращает ненужный текст в бесплатный: сервер всё равно должен обработать токены и разместить состояние.

Максимальное окно не равно полезному окну

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

Работа Lost in the Middle на моделях своего периода показала ещё один эффект: релевантная информация использовалась хуже, когда находилась в середине длинного набора документов, чем в начале или конце. Это не доказывает, что любая современная модель повторит тот же профиль. Вывод практический: длину нужно проверять на собственной задаче, а не по максимальному числу в модельной карточке.

Если 64 тысячи токенов технически помещаются, но доля принятых ответов падает, бизнес платит дважды: за вычисления и за ручную перепроверку.

Когда длинный контекст оправдан

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

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

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

Когда RAG экономичнее

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

Но RAG добавляет собственные расходы:

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

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

Формула для управленческого расчёта

Используйте стоимость принятого ответа:

`C_accepted = (C_inference + C_retrieval + C_index + C_operations + C_review) / N_accepted`

Здесь `N_accepted` — ответы, которые прошли проверку качества или были приняты пользователем без исправления. Ошибочные, просроченные и слишком медленные ответы не должны улучшать экономику только потому, что сервер их сгенерировал.

Для длинного контекста `C_retrieval` и часть `C_index` могут быть малы, зато растут prefill, KV-кэш, очередь и ручная проверка. Для RAG появляются индекс и поиск, но уменьшается средний вход модели. Победителя определяет поток запросов, а не архитектурный лозунг.

Минимальная таблица сравнения должна содержать:

  • медиану и p95 входных токенов;
  • время до первого токена и полную задержку;
  • запросы в минуту при целевой конкуренции;
  • пиковое использование KV-кэша и число вытеснений;
  • долю ответов с верной цитатой;
  • долю принятых ответов;
  • минуты ручной проверки;
  • стоимость индексации и обновления корпуса;
  • стоимость простоя или нарушения SLA.

Пример без выдуманной цены GPU

Предположим, справочный помощник получает 10 000 запросов в месяц. Вариант A каждый раз прикладывает 16 тысяч входных токенов. Вариант B через RAG передаёт четыре тысячи токенов вместе с инструкцией и цитатами. Входной объём модели в варианте B в четыре раза меньше: 40 млн токенов против 160 млн.

Этого недостаточно, чтобы объявить четырёхкратную экономию. Нужно измерить, сколько запросов реально обслуживает сервер, как меняется очередь, сколько стоит поиск и не падает ли полнота ответа. Если RAG принимает 8 700 ответов из 10 000, а длинный контекст — 9 400, знаменатель в формуле различается. Эти числа должны прийти из теневого теста, а не из предположения редакции.

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

Как провести тест за две недели

Сначала соберите 100–300 реальных обезличенных запросов и эталонные источники. Не используйте только лёгкие вопросы: добавьте случаи с несколькими документами, противоречиями, длинными таблицами и отсутствующим ответом.

Запустите два варианта на одной модели и одном оборудовании:

1. Большой контекст с целыми документами.
2. RAG с фиксированным top-k, метаданными, цитатами и одинаковым лимитом ответа.

Для каждого варианта прогоните корзины 2k, 4k, 8k, 16k и, если оправдано, 32k токенов. Повторите при одной, четырёх и целевом количестве одновременных сессий. Снимайте TTFT, p95, throughput, размер очереди, KV-cache usage, вытеснения и долю принятых ответов.

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

Гибрид обычно практичнее крайностей

Для малого и среднего бизнеса разумная схема часто состоит из нескольких уровней:

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

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

Что взять в бюджет

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

Если сокращение контекста с 16k до 4k сохраняет качество и увеличивает пропускную способность, это реальная экономия. Если из-за слабого поиска сотрудники чаще исправляют ответы, экономии нет. Правильная длина — не максимальная и не минимальная, а самая короткая, которая стабильно решает задачу при нужном SLA.

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