Общие или выделенные ресурсы для вывода данных для Embed и Rerank? Начните с анализа нагрузки
Выбор между общими, потребляемыми ресурсами для вывода данных и выделенными, предоставленными ресурсами для вывода данных — это не просто вопрос того, какой вариант дешевле.
Для задач встраивания и переранжирования ответ в значительной степени зависит от того, как приложение использует модель. Полезный способ подумать об этом решении:
Профиль запроса -> Модель трафика -> Использование -> Выбор развертывания. Понимание этих факторов может рассказать вам гораздо больше, чем сравнение основных цен.
Начните с анализа профиля запроса
Первый вопрос: как выглядит типичный запрос к модели? Для встраивания профили запросов могут значительно варьироваться. Давайте на минутку представим приложение для поиска в электронной коммерции. Прежде чем покупатель сможет что-то поискать, каждый товар в магазине должен быть преобразован в что-то, с чем может работать система поиска. Итак, приложение берет каждое описание товара, прогоняет его через модель встраивания и сохраняет результат. Это задача индексации, большая в первый раз и затем постоянный поток меньших пакетов по мере изменения ассортимента. Чтобы эффективно справиться с этим, приложение отправляет товары пачками: скажем, около 100 описаний в одном запросе, каждое примерно из 150 слов (~200 токенов). Пользователь не ждет мгновенных результатов, поэтому важно завершить работу, а не сделать это быстро.
Теперь сравните это с ситуацией, когда покупатель вводит в строку поиска «водонепроницаемые кроссовки для трейлового бега». Та же модель, но на этот раз это один короткий запрос, и пользователь наблюдает за спиннером загрузки, пока он не вернется.
Оба сценария включают задачи встраивания, но они оптимизируются для противоположных целей. Пакетная обработка касается пропускной способности и цены/производительности — получения максимального количества работы за доллар. В то время как один запрос касается отзывчивости, и вы соглашаетесь на более низкую цену/производительность, чтобы достичь ее.
Для сценариев пакетной обработки и поискового запроса профиль встраивания может выглядеть следующим образом:
Вы не выполняете одну и ту же работу дважды, вы просите одну модель выполнить две очень разные задачи. Инфраструктура, настроенная для больших пакетов, не обязательно обеспечит такое же время отклика при обслуживании тысяч небольших, чувствительных к задержкам запросов.
У переранжирования другая форма запроса
Задачи переранжирования вводят еще одну важную переменную в смесь: сколько кандидатских документов вы фактически просите модель оценить.
Давайте вернемся к нашему примеру поиска товаров. Сначала ваша векторная поисковая система может выдать 50 кандидатских товаров, соответствующих запросу. Затем вступает в дело переранжировщик, это как иметь опытного продавца-консультанта, который смотрит на эти 50 вариантов и решает, какие из них действительно заслуживают верхних позиций.
Модель по сути сравнивает запрос покупателя с каждым кандидатом и ранжирует их по релевантности. Каждая пара запрос-документ оценивается независимо, что означает, что запрос обрабатывается один раз на каждого кандидата — то есть работа масштабируется напрямую от того, сколько кандидатов вы отправляете.
Типичный запрос на переранжирование выглядит следующим образом: один короткий запрос из примерно 20 токенов плюс 50 кандидатских товаров примерно по 200 токенов каждый. Это около 11 000 токенов, с которыми модель работает для одного поиска.
Довольно просто, правда? Но вот где все становится интересно. Предположим, вы меняете свою стратегию с переранжирования 20 кандидатов на 50 или 100. На первый взгляд ничего не меняется для пользователя — то же количество поисков, тот же опыт. За кулисами вы перешли от примерно 4400 токенов на поиск к примерно 22 000. Это разница между просьбой к кому-то выбрать лучшие 20 товаров из каталога и ранжированием 100 из них. Та же задача, но гораздо больше материала для чтения.
Вот почему глубина извлечения становится таким критическим инфраструктурным решением. Вы больше не масштабируетесь только на основе объема пользователей, вы масштабируетесь на основе того, насколько глубоко вы хотите копать в своей базе результатов.
Модель трафика важна так же, как и объем трафика
После того, как профиль запроса понятен, следующий вопрос: как поступает трафик? Два приложения могут иметь одинаковый пиковый трафик, но при этом иметь очень разную экономику инфраструктуры.
Стабильные модели трафика. Давайте представим глобальную поисковую службу, трафик которой течет относительно равномерно в течение всего дня. Нет резкого роста, нет драматических спадов. В этом сценарии выделенная мощность начинает выглядеть очень привлекательно, потому что ваша инфраструктура остается хорошо использованной. Вы не платите за мощность, которая простаивает большую часть времени, и вам никогда не приходится спешно справляться с неожиданными всплесками.
Импульсные модели трафика. Теперь представьте другое приложение, возможно, систему финансовой отчетности или задачу пакетной обработки. Это приложение поддерживает низкий объем трафика во время стандартных операционных периодов, с концентрированными всплесками, происходящими во время пиковых часов работы или запланированных окон обработки. Для этого сценария потребляемые услуги — хороший вариант, потому что вы не платите за всю эту простаивающую мощность во время низкого объема трафика.
Настоящий инфраструктурный вопрос
Это не просто «Насколько высок трафик в пике?» Это «Насколько стабильно можно использовать инфраструктуру?» Пиковый трафик говорит вам о ваших максимальных потребностях в мощности, но модели использования говорят вам, насколько эффективно вы фактически будете использовать эту мощность. Сервис, который обрабатывает 10 000 запросов в секунду, но только в течение 5 минут в день, имеет очень другую экономику, чем сервис, который обрабатывает 100 запросов в секунду постоянно. Правильное решение означает разницу между инфраструктурой, которая просто достаточна, и инфраструктурой, которая действительно оптимальна с точки зрения экономичности и отзывчивости.
Помимо объема запросов: форма и модель имеют большее значение
Анализируя только объем запросов, можно принять неправильные инфраструктурные решения. Рассмотрите эти контрастные сценарии:
Низкий RPM, высокая обработка: задача встраивания каталога с всего 30 запросами в минуту может показаться небольшой, но если каждый запрос содержит 100 текстов × 200 токенов, это 600K токенов в минуту постоянной обработки. Выделенная мощность может быть хорошо использована.
Высокий RPM, низкая обработка: тысячи запросов на встраивание запросов в минуту звучат требовательно, но если каждый из них содержит всего несколько токенов и всплески трафика длятся всего несколько часов, общая инфраструктура может быть более экономичной.
Переранжирование следует той же модели: несколько поисков с большими наборами кандидатов могут перевесить множество поисков с маленькими наборами.
Ключевое различие:
- Скорость запросов говорит вам, как часто модель вызывается.
- Форма запроса говорит вам, сколько работы представляет собой каждый вызов.
- Модели трафика говорят вам, насколько стабильно нужна мощность.
Точка пересечения затрат зависит от нагрузки
После того, как форма запроса и модель трафика понятны, вы можете оценить точку, в которой выделенная инфраструктура становится более экономичной, чем потребляемое вывод данных. Нет универсальной точки безубыточности, точка пересечения специфична для нагрузки.
Например, используя репрезентативные нагрузки и предположения, приведенные в этом анализе:
Встраивание запросов
1 короткий запрос
~8 токенов
десятки тысяч запросов/мин
Встраивание каталога
100 текстов * 200 токенов
~20K токенов
~20 запросов/мин
Встраивание длинных документов
100 текстов * 1000 токенов
~100 тыс. токенов
~4 запроса/мин
**Эти точки безубыточности основаны на репрезентативном ценообразовании на основе потребления и одном выделенном экземпляре GPU NVIDIA A10 с почасовой оплатой, при условии отсутствия согласованных скидок и постоянного трафика 24×7. Рабочие нагрузки, которые выполняются только часть дня, требуют более высокой частоты запросов в активные часы для достижения того же экономического порога. Другой тип экземпляра меняет как стоимость, так и производительность, потенциально смещая точки безубыточности. Пропускная способность экземпляра определяет, какой объем может обработать один экземпляр, прежде чем потребуется дополнительная емкость; она не определяет напрямую экономический порог, который основан на ценообразовании. Встраивание оплачивается за токен, а переранжирование — за единицу поиска, поэтому их частота запросов напрямую не сопоставима. Эти цифры являются иллюстративными, специфичными для рабочей нагрузки порогами, а не универсальными пороговыми значениями развертывания. Первые три строки представляют одну и ту же модель по одной и той же цене. Единственное, что меняется, — это форма запроса, и точка перехода смещается с примерно четырех запросов в минуту до десятков тысяч. Короткий запрос должен поступать в огромном объеме, прежде чем выделенная емкость станет оправданной. Пакет длинных документов достигает этого почти мгновенно.
Это имеет практическое значение для рабочей нагрузки каталога, описанной ранее. При 30 запросах в минуту это звучит как небольшая задача, но точка безубыточности для этого конкретного профиля запроса составляет ~20 запросов в минуту. Это уже тот диапазон, где выделенная емкость является более экономичным выбором, несмотря на скромную частоту запросов.
Сравнение моделей требует большей осторожности. Встраивание оплачивается за токен, а переранжирование — за единицу поиска, и их затраты на выделенную емкость различаются, поэтому ~20 и ~29 запросов в минуту не являются двумя точками на одной шкале. То, что точка перехода переранжирования находится между профилями каталога и запроса, является совпадением этих конкретных форм запросов, а не свойством моделей.
Измените вычислительную мощность, модель ценообразования или структуру использования, и точка безубыточности изменится.
Задержка меняет уравнение
Максимальная пропускная способность не равна полезной емкости, поскольку разные рабочие нагрузки имеют принципиально разные требования к производительности.
- Пакетная индексация: может работать при пиковой пропускной способности, поскольку эффективность завершения важнее немедленного ответа
- Поисковые запросы: требуют строгих целевых показателей задержки — время отклика напрямую влияет на пользовательский опыт и бизнес-результаты
- Переранжирование: расширение наборов кандидатов улучшает количество обрабатываемых документов/сек при снижении количества выполняемых поисков/сек
Этот компромисс между задержкой и пропускной способностью означает, что при определении размера инфраструктуры необходимо учитывать оба параметра производительности. Для интерактивных рабочих нагрузок емкость должна основываться на устойчивой пропускной способности, которая соответствует целевым требованиям к задержке, а не только на максимальной производительности по результатам тестов. Это часто требует дополнительного запаса сверх расчетов пикового спроса.
Простая система принятия решений
Прежде чем выбирать общее или выделенное логическое выведение для Embed или Rerank, ответьте на эти вопросы, и решение по инфраструктуре станет намного проще
Что содержит типичный запрос?
Определяет объем работы на запрос
Это встраивание документа или запроса?
Требования к пропускной способности и задержке различаются
Сколько документов переранжируется?
Напрямую влияет на вычисления переранжирования
Какова ожидаемая частота запросов?
Определяет спрос на инфраструктуру
Трафик стабильный или скачкообразный?
Определяет достижимый уровень использования
Какая задержка требуется приложению?
Определяет полезную емкость
Вывод
Когда люди начинают сравнивать общее и выделенное логическое выведение, они обычно сначала смотрят на две цифры: цену за токен и количество запросов в минуту. Ни одна из них сама по себе не дает много информации. На самом деле вам нужно знать, какой объем работы несет каждый запрос, насколько стабильно он поступает и будет ли ваша емкость оставаться загруженной.
Так что нет никакого волшебного числа безубыточности, которое можно просто найти. Точка перехода принадлежит вашей рабочей нагрузке, а не выбранному вами варианту развертывания. И многие поисковые приложения в конечном итоге используют и то, и другое: выделенную емкость для индексации каталога и ценообразование на основе потребления для трафика запросов, который возрастает в зависимости от спроса конечных пользователей.
Поймите запрос → Поймите трафик → Поймите использование → Затем выберите модель развертывания.
