Shared или dedicated инфраструктура для embedding и reranking: как выбрать по рабочей нагрузке

Request Profile: форма запроса важнее объёма

Cohere провела анализ выбора между shared (потребление по факту) и dedicated (выделенная инфраструктура) для embedding и reranking. Основная находка: люди обычно сравнивают только цену за токен и количество запросов в минуту, но эти метрики почти ничего не говорят о правильном выборе. Логика проста — Request Profile → Traffic Pattern → Utilization → Deployment Choice.

Одна и та же embedding-модель может выполнять совершенно разные работы. На e-commerce сайте embedding применяется двояко: индексирование каталога (сотни описаний продуктов за раз, по 150 слов, около 200 токенов на текст) и обработка поискового запроса (один короткий запрос, пока пользователь смотрит на спиннер). Batch-обработка оптимизирует throughput и стоимость, поисковый запрос — responsiveness. Это противоположные требования, и одна инфраструктура не может эффективно обслуживать обе.

В reranking добавляется критически важный параметр: число кандидатов для переранжировки. Vector search возвращает 50 товаров, reranker переоценивает каждый относительно запроса. Модель сравнивает запрос против каждого кандидата независимо, работа масштабируется строго с числом кандидатов. Типичный профиль: запрос из 20 токенов плюс 50 документов по 200 токенов каждый = около 11,000 токенов на операцию. Перейди с 20 на 100 кандидатов — пользователь ничего не заметит, но нагрузка вырастет с 4,400 до 22,000 токенов. Это решение о глубине поиска, а не масштабировании по пользователям.

Traffic Pattern и Latency: что определяет реальную ёмкость

Два приложения с одинаковым peak traffic могут иметь совершенно разную стоимость инфраструктуры. Steady traffic (глобальный search, постоянный поток в течение дня) делает dedicated capacity экономичнее: инфраструктура хорошо используется, нет простоев и необработанных всплесков. Bursty traffic (финансовые отчёты, batch-job, пики в определённые окна) — лучше shared инфраструктура, потому что не платишь за ёмкость, которая сидит без дела большую часть времени.

Ключевой вопрос не «какой пик-трафик?», а «насколько предсказуемо и постоянно используется ёмкость?» Сервис с 10,000 запросами в секунду на 5 минут в день имеет совершенно разную экономику, чем сервис со 100 запросами в секунду постоянно.

Максимальная пропускная способность GPU не равна реальной production-ёмкости, потому что разные рабочие нагрузки имеют разные требования к latency. Batch-индексирование может работать на максимуме (завершение важнее скорости). Поисковые запросы требуют строгих latency-бюджетов (задержка влияет на UX и выручку). Reranking при расширении кандидатов увеличивает documents/sec, но снижает searches/sec. Инфраструктура должна обеспечить throughput, соблюдающий latency-требования, а не просто достичь benchmark-пик.

Break-even и экономика выбора

Cohere рассчитала точки экономического crossover на примере одного NVIDIA A10 GPU с типовыми consumption-based ценами (без учёта скидок, трафик 24/7):

• Query Embedding (одиночный запрос, 8 токенов): break-even ~десятки тысяч req/min • Catalog Embedding (100 текстов × 200 токенов, 20K на запрос): break-even ~20 req/min • Long-document Embedding (100 текстов × 1000 токенов, 100K на запрос): break-even ~4 req/min • Reranking (1 запрос + 50 документов, 11K токенов): break-even ~29 req/min

Одна модель, одна цена, break-even меняется в сотни раз в зависимости от размера запроса. Catalog-профиль при 30 req/min выглядит скромно, но уже выше break-even в 20 req/min — dedicated уже экономичнее. Измени размер запроса, число кандидатов, latency-требования или паттерн трафика — и точка резко сместится. Поэтому универсального ответа нет: выбор между shared и dedicated зависит от конкретной рабочей нагрузки, требуемых задержек и трафик-паттернов, а не от headline-метрик типа цены за токен или RPM.