«Точка безубыточности принадлежит нагрузке, а не инстансу»: Cohere объяснила, как выбирать между общим и выделенным инференсом для Embed и Rerank

Не цена за токен, а форма запроса

Вопрос «что дешевле» — общий инференс с оплатой за потребление или выделенная, заранее выкупленная мощность — Cohere предлагает решать не сравнением прайса за токен и не по числу запросов в минуту (RPM). Ни один из этих показателей сам по себе, по утверждению компании, ничего не говорит о реальной нагрузке. Полезнее сначала посмотреть, из чего состоит типичный запрос к модели.

Пример из поиска по интернет-магазину: прежде чем товар можно будет найти, каждое описание нужно прогнать через embedding-модель и сохранить результат — это задача индексации. Первый проход большой, дальше идёт поток небольших пакетов по мере изменения каталога; чтобы пройти его эффективно, приложение отправляет товары пачками — около 100 описаний в одном запросе, каждое примерно 150 слов (порядка 200 токенов). Пользователь при этом никуда не спешит, поэтому важна не скорость отдельного ответа, а сколько работы делается за один доллар.

Тот же запрос из строки поиска — противоположный случай: один короткий запрос, и пользователь ждёт результата по спиннеру. Обе задачи — про embedding, но оптимизируют они противоположные вещи: пакетная обработка — пропускную способность и цену за единицу работы, одиночный запрос — отзывчивость, ради которой можно принять худшую цену за единицу. Отсюда вывод Cohere: инфраструктура, настроенная под крупные пачки, не обязательно даст те же времена отклика на тысячах мелких, чувствительных к задержке запросов.

У rerank своя форма запроса: всё решает число кандидатов

Rerank добавляет ещё одну переменную — сколько документов-кандидатов модель должна оценить. Сначала векторный поиск поднимает, скажем, 50 подходящих товаров, а затем reranker сравнивает запрос покупателя с каждым кандидатом и расставляет их по релевантности: каждая пара «запрос — документ» оценивается независимо, поэтому запрос обрабатывается по разу на каждого кандидата, и объём работы растёт прямо вместе с их числом.

Типичный запрос на rerank в примере Cohere — короткий запрос около 20 токенов плюс 50 кандидатов примерно по 200 токенов каждый, то есть около 11 000 токенов на один поиск. Если поменять стратегию и ранжировать не 20 кандидатов, а 50 или 100, для пользователя снаружи ничего не изменится, но за кадром объём вырастет примерно с 4 400 до 22 000 токенов на поиск. Поэтому глубина поиска становится отдельным инфраструктурным решением: масштаб задаёт уже не только число пользователей, но и то, насколько глубоко приложение копает в пул результатов.

Трафик: важен не пик, а стабильность загрузки

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

Настоящий вопрос инфраструктуры, по Cohere, звучит не «как высок пик», а «насколько стабильно мощность будет использоваться». Пик говорит о максимальной потребности в ёмкости, а профиль загрузки — о том, насколько эффективно эта ёмкость будет использована. Сервис, который держит 10 000 запросов в секунду, но только пять минут в день, и сервис, который держит 100 запросов в секунду постоянно, имеют совершенно разную экономику.

Почему объём запросов обманывает

Смотреть только на число запросов — плохой ориентир. Каталог на 30 запросов в минуту кажется небольшой нагрузкой, но если в каждом запросе 100 текстов по 200 токенов, это 600 000 токенов устойчивой обработки в минуту — и выделенная мощность может оказаться хорошо загруженной. И наоборот: тысячи запросов на embedding в минуту выглядят требовательно, но если в каждом всего несколько токенов, а всплески длятся считаные часы, общий инференс может оказаться выгоднее. С rerank та же логика: несколько поисков с большим набором кандидатов могут перевесить множество поисков с маленьким. Иными словами, RPM сам по себе — ненадёжный ориентир для подбора ёмкости.

Точка безубыточности зависит от нагрузки

Универсальной точки безубыточности нет — переход к выделенной мощности наступает на своём уровне для каждой нагрузки. Cohere приводит расчёт на представительных профилях и допущениях: один выделенный инстанс с GPU NVIDIA A10 с почасовой оплатой, без договорных скидок и при круглосуточном трафике.

По этому расчёту одиночный короткий запрос на embedding (около 8 токенов) выходит на выделенную мощность только при десятках тысяч запросов в минуту; каталог из 100 текстов по 200 токенов (около 20 000 токенов) — уже примерно с 20 запросов в минуту; embedding длинных документов по 100 текстов на 1000 токенов (около 100 000 токенов) — примерно с 4 запросов в минуту; а rerank (запрос на 20 токенов плюс 50 документов по 200 токенов, около 11 000 токенов) — примерно с 29 запросов в минуту.

Первые три профиля в таблице — одна и та же модель по одной и той же цене; меняется только форма запроса, и порог сдвигается от примерно четырёх запросов в минуту до десятков тысяч. Для каталога из примера это означает, что при 30 запросах в минуту работа уже находится в зоне, где выделенная мощность экономичнее, несмотря на скромный темп. Cohere отдельно предупреждает, что сравнивать модель и rerank напрямую нельзя: embedding тарифицируется по токенам, а rerank — по поисковой единице, поэтому ~20 и ~29 запросов в минуту не лежат на одной шкале, а совпадение rerank между профилями каталога и запроса — свойство этих конкретных форм запроса, а не моделей. Компания добавляет и другие оговорки: нагрузка, работающая лишь часть дня, требует более высокой частоты запросов в активные часы для того же экономического перехода, а другой тип инстанса меняет и стоимость, и ёмкость.

Латентность и пропускная способность — вместе

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

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