Почему «просто вложить всё» выглядит бесплатным
Главная приманка длинного контекста — не качество ответов, а экономия на разработке. Не надо резать корпус на фрагменты и настраивать поиск по ним: вложили документы целиком — модель сама найдёт нужное место. Демо собирается на коленке, отвечает по делу, и из архитектуры исчезает целая подсистема со всеми её настройками и точками отказа.
Короткий ответ на вопрос «выгодно ли»: выгодно, пока произведение размера корпуса на число обращений вписывается в бюджет, а сам корпус — в окно контекста без штрафного тарифа. Дальше — арифметика, в которую вы подставляете свои значения. Как вообще складывается счёт за LLM, мы разбирали в простом материале для начинающих; здесь важна одна его особенность: за каждый отправленный токен платят при каждом обращении. Длинный контекст не читает документы бесплатно — он продаёт вам весь корпус заново с каждым запросом.
Модель расчёта: подставьте свои значения
Считать надо не «сколько стоит модель», а произведение двух чисел. Понадобятся ваши значения:
N— запросов за месяц;C— постоянная часть промпта в токенах: корпус и инструкции. Одна и та же при каждом обращении;Q— переменная часть: вопрос пользователя и его данные;A— средняя длина ответа.
И три цены из тарифа провайдера:
p— входной токен;p_out— выходной токен, он дороже входного;p′— входной токен сверх порога длиныT.
Порог — не экзотика. Обрабатывать длинную последовательность дороже, чем короткую, и это следует из устройства вычислений: объём работы растёт быстрее длины входа, память под промежуточные состояния — вместе с ним, и провайдер перекладывает эти расходы в тариф. У одних дорожает только хвост запроса, у других — весь запрос целиком; загляните в свой тариф, от этой детали зависит, насколько больно переваливать порог. Почему длинная последовательность вообще обходится дорого — вопрос к устройству инференса, его стоимость на реальной нагрузке мы разбирали в предыстории.
Счёт за месяц без ухищрений:
N × (C + Q) × p + N × max(0, C + Q − T) × (p′ − p) + N × A × p_out
Главное в формуле — произведение N × C. Корпус не покупается один раз, а арендуется при каждом обращении. Демо было дешёвым, потому что N было мало; в проде N — это ваши пользователи, и каждый при каждом обращении тащит за собой весь корпус.
Два следствия. Если C + Q не дотягивает до порога T, штрафное слагаемое нулевое — это лучший режим. Если переваливает, каждый добавленный в промпт документ стоит дороже предыдущего, и обрезка контекста ниже порога экономит по повышенной цене: резать хвост выгоднее всего.
Кэш: скидка, которая зависит от вашего трафика
Первый легальный способ не платить за C целиком — кэш префикса. Провайдер запоминает обработанное начало промпта и при точном повторении берёт за него меньше, иногда заметно меньше.
Пусть d — скидка на кэшированный токен, h — доля запросов, где кэш реально сработал. Эффективная цена входного токена: p_эфф = h × p × (1 − d) + (1 − h) × p. Постоянная часть стоит N × C × p_эфф вместо N × C × p.
Вся экономика сидит в h, а h — не настройка, а характер вашего трафика. Кэш попадает, только если префикс совпадает с прошлым запросом до последнего токена и не успел протухнуть. Плотный поток на один и тот же корпус — h высокий. Редкие запросы — кэш умирает между ними. Персональные вставки в начале промпта — у каждого пользователя свой префикс, и h рассыпается.
Отсюда правило раскладки: стабильное — корпус и инструкции — в начало промпта, изменчивое — вопрос и данные пользователя — в конец. И ещё: любая правка документа сбрасывает кэш для всех последующих запросов, так что частота обновлений корпуса входит в цену напрямую. В реальном тарифе к кэшу прилагаются оговорки — минимальная длина префикса, время жизни, — но для выбора между длинным контекстом и поиском хватает грубой модели.
С чем сравнивать: поиск отправляет фрагменты, а не корпус
Альтернатива — поиск по документам: на запрос уходит не C, а r × s, то есть r найденных фрагментов по s токенов. Токеновый счёт:
N × (r × s + Q) × p + N × A × p_out
Он почти не зависит от размера корпуса. Зато появляются статьи, которых у длинного контекста нет: I — разовая индексация, пропорциональная корпусу, а не числу запросов, и M — владение: хранилище, пайплайн обновления, настройка релевантности. Это инженерное время и сроки, а не токены. Когда поиск вообще уместнее дообучения — отдельный спор, мы вели его в материале о выборе между дообучением и поиском; здесь сравниваем только по деньгам.
Граница проходит там, где N × C × p_эфф сравнивается с N × r × s × p + I + M (если r × s + Q не переваливает за порог — а это и есть цель поиска, — штрафного слагаемого нет). Слева стоимость растёт и от корпуса, и от трафика. Справа от размера корпуса зависит только I, и один раз. Компактный корпус при редких запросах — левая часть мала, поиск как проект не окупится. Большой корпус при частых запросах — левая часть растёт как произведение двух больших чисел.
Есть и слагаемое, которого нет ни в одном счёте: промах. Поиск не нашёл нужный фрагмент — модель отвечает уверенно и мимо. У длинного контекста такого промаха нет: всё уже внутри. Зато внутри так много, что модель может ответить по общему тону кучи, а не по нужной строчке. Обе системы ошибаются по-разному, и это придётся взвешивать отдельно от денег — к промаху вернёмся в позиции редакции.
Тупик: сжать и обрезать
Когда счёт за длинный контекст становится страшным, первым делом пробуют не поиск, а сжатие: прогнать документы через модель, оставить выжимку, вложить её целиком. Логика понятная — не нужна новая подсистема, и кажется, что теряем только мусор.
Не помогает. Сжатие — сам по себе инференс: за прогон корпуса платят и за вход, и за выход, и повторяют это при каждом обновлении документов. Хуже: выжимка теряет не шум, а ответы на вопросы, которых составитель не предвидел. Сохраняется то, что казалось важным при подготовке, а спрашивают обычно про остальное. Провал тихий — модель уверенно отвечает по выжимке, счёт падает, на дашборде всё хорошо, об ухудшении узнают из жалоб, а не из метрик.
Арифметически сжатие уменьшает C, но сохраняет структуру N × C: произведение остаётся, просто с меньшим множителем. Если счёт давит трафик, а не размер корпуса, выжимка почти ничего не меняет — а качество меняет. Настоящие рычаги меняют не множитель, а структуру (перестать отправлять корпус — поиск) или цену (платить за него меньше — кэш). Ручная обрезка «на глазок» — та же выжимка, только без правил: что вырезали и почему, через месяц не вспомнит никто.
Когда длинный контекст экономит
Случаи, где арифметика на его стороне, пересчитываются по пальцам — и это удобно: каждый проверяется по своей формуле.
Корпус компактный: C + Q не переваливает за порог T или переваливает чуть-чуть. Штрафного тарифа нет, и длинный контекст — наименьшая система из возможных: нечему ломаться, и это самый быстрый путь в прод.
Запросов мало относительно корпуса. Внутренний инструмент для пары команд: произведение N × C вписывается в бюджет без всякого кэша, и строить поиск — значит тратить инженерное время на экономию того, что и так вписывается.
Префикс стабильный, трафик плотный. Кэш попадает почти всегда, p_эфф падает на скидку, и длинный контекст может стоить меньше поиска — при нулевой стоимости владения поиском.
Вопросы требуют весь корпус сразу. «Найди противоречия между договорами», «сравни позиции во всех прайсах» — поиск собирает такие ответы плохо: нужные куски не обязаны попасть в одну выдачу. Длинный контекст решает их по построению, и экономия тут не в токенах, а в том, что задача вообще решается.
Обратный случай назовём честно: корпус большой, запросы частые, вопросы точечные — «что сказано о сроках в таком-то договоре». Здесь длинный контекст платит за чтение всего ради одной строчки. Поиск выигрывает и по деньгам, и по скорости: короткий префикс — быстрый первый токен, длинный без кэша заставляет ждать, пока модель прожуёт всё.
Позиция редакции
Мы считаем, что «выгоден ли длинный контекст» — вопрос не вкуса, а умножения. Решает произведение частоты запросов на размер постоянного промпта на эффективную цену токена, и его надо считать до того, как что-то строить. Вписывается в бюджет, а корпус — в окно без штрафного тарифа? Берите длинный контекст и не стройте поиск: меньше подсистем и точек отказа, честная плата за простоту. Не вписывается — не спасут ни сжатие, ни обрезка: меняйте структуру или цену, а не множитель.
Позиция неверна при одном проверяемом условии: если цена ошибки у вас выше цены токенов. Поиск иногда промахивается — нужный фрагмент не найден, модель уверенно отвечает мимо. Если один такой промах обходится вам дороже, чем вся переплата за длинный контекст за тот же срок, выбирать по токеновому счёту — значит выбирать не по тому счёту: длинный контекст берут даже при невыгодной арифметике, как страховку от промахов, и это разумно. Проверка: посчитайте, во что вам обходится один неверный ответ — потерянная сделка, сорванный срок, час разбирательств, — и сравните с разницей между левой и правой частью формулы из раздела о поиске. Первое больше — наша позиция к вам не применима, берите длинный контекст вопреки счёту.
Есть и второе условие, но рыночное: если провайдеры отвяжут цену токена от длины запроса — кэш станет почти бесплатным, ступенчатые тарифы исчезнут, — произведение перестанет расти вместе с корпусом и аргумент «дорого» умрёт сам. Его, в отличие от первого, проверяют не в своих числах, а в чужом прайсе.