Cohere: rerank 100 кандидатов вместо 20 поднимает нагрузку с 4,4 до 22 тыс. токенов

Cohere опубликовала практический разбор того, как выбирать между shared-инференсом с оплатой по потреблению и dedicated-инференсом с выделенной ёмкостью для моделей Embed и Rerank. Автор текста, solutions architect Payal Singh, исходит из простой мысли: сравнивать прайс-листы бессмысленно, пока не понятно, как приложение использует модель. Один вызов эмбеддингов на 100 описаний товаров по ~200 токенов тянет около 20 тысяч токенов. Один поисковый запрос покупателя занимает несколько слов. Для биллинга это оба «запроса», для железа это совершенно разные нагрузки.

Одна модель, два профиля

Cohere берёт пример интернет-магазина. Сначала нужно проиндексировать каталог: каждое описание проходит через модель, и вектор сохраняется. В первый раз это большая работа, потом поток небольших батчей по мере обновления ассортимента. Приложение шлёт товары пачками, около 100 описаний за вызов, и пользователь при этом никого не ждёт. Важно закончить задачу, а не закончить её быстро, поэтому оптимизируют throughput и цену за единицу работы.

Поисковый запрос «waterproof trail running shoes» устроен наоборот. Он короткий, а человек смотрит на индикатор загрузки. Здесь важна отзывчивость, и за неё приходится платить худшим price-performance. По сути, одну модель просят выполнять две разные работы. Инфраструктура, настроенная под большие батчи, не обязательно даст нужное время ответа на тысячах мелких запросов, чувствительных к задержке.

Rerank: глубина выдачи работает как множитель

У реранкера своя геометрия. Векторный поиск отдаёт, скажем, 50 кандидатов, и модель оценивает каждую пару «запрос — документ» независимо. Запрос обрабатывается заново для каждого кандидата, поэтому работа растёт прямо пропорционально их числу.

Типичный вызов, по оценке Cohere: запрос около 20 токенов плюс 50 товаров по ~200 токенов. Выходит порядка 11 тысяч токенов на один поиск. Если поднять глубину выдачи, картина меняется без единого нового пользователя:

• 20 кандидатов: около 4 400 токенов на поиск;
• 50 кандидатов: около 11 000 токенов;
• 100 кандидатов: около 22 000 токенов.

Число поисков и пользовательский опыт остаются прежними, а вычислений нужно в пять раз больше. Поэтому глубину retrieval Cohere предлагает считать инфраструктурным решением, а не только настройкой качества.

Выводы из key takeaways

Из тезисов материала складывается следующая логика:

• request shape важнее объёма запросов: несколько крупных вызовов Embed могут потребить больше compute, чем тысячи коротких поисковых запросов, поэтому RPM как единственная метрика для планирования ёмкости ненадёжен;
• dedicated-инференс обычно экономичнее при стабильной предсказуемой нагрузке, а consumption-based лучше подходит для переменного или всплесками трафика;
• точка безубыточности зависит от размера запроса, объёма токенов и числа кандидатов в rerank, а не только от цены инфраструктуры;
• максимальный throughput не равен реально доступной production-ёмкости: нужно укладываться в требования по latency и при этом держать стоимость в разумных рамках.

Как подойти к выбору на практике

Порядок действий такой, какой предлагает сама Cohere: профиль запроса, затем паттерн трафика, затем утилизация, и только потом выбор развёртывания. Начните с замера реальных размеров запросов: сколько документов в батче индексации, сколько токенов в среднем, сколько кандидатов уходит в реранкер. Затем разделите нагрузку на фоновую (индексация, пакетные пересчёты) и интерактивную (поиск, где пользователь ждёт). Первую часто можно держать в shared-режиме, если она нерегулярна. Вторая при стабильном потоке — кандидат на выделенную ёмкость.

Отдельно пересчитайте стоимость при изменении глубины реранкинга: переход с 20 на 100 кандидатов может сдвинуть точку безубыточности. И тестируйте мощность под целевую задержку, а не по паспортному максимуму throughput. Эта часть материала в доступном фрагменте обрывается на разделе о паттернах трафика, поэтому конкретные пороги переключения между режимами Cohere здесь не приводятся.