Michael JohnsonДва сервіси можуть надсилати однакову кількість запитів до моделі, але створювати зовсім різне навантаження. В опублікованому 9 жовтня посібнику Cohere з Embed і Rerank компанія пропонує обирати спільну або виділену обробку з огляду на форму запитів, графік навантаження та вимоги до затримки. Це практичний огляд інфраструктури, а не анонс нового тарифу чи продукту.
Для команд, які створюють пошук і RAG, цей висновок важливий під час планування індексації та користувацьких запитів: сама кількість викликів погано описує обсяг обчислень. Один пакет документів для створення ембедингів може потребувати більше ресурсів, ніж безліч коротких пошукових запитів.
Чому кількість запитів за хвилину вводить в оману
Ембеддинги перетворюють тексти на числові представлення, які пошукова система використовує для семантичного зіставлення. Під час початкової індексації каталогу застосунок може надсилати великі пакети описів; під час звичайного пошуку модель отримує короткий текст запиту. Ці завдання мають різні вимоги: пакетну обробку зазвичай оцінюють за пропускною здатністю та вартістю, а пошук — за часом відповіді користувачеві.
Для Rerank важливий ще один параметр: скільки кандидатів система передає моделі для повторного ранжування. У прикладі Cohere короткий запит зіставляється з 50 документами; компанія оцінює такий обсяг обробки приблизно у 11 тисяч токенів. Збільшення кількості кандидатів розширює обсяг роботи, навіть якщо частота користувацьких пошуків не змінюється.
Що показують розрахунки Cohere
У статті наведено орієнтовні точки економічного переходу від оплати за фактичним споживанням до виділеної потужності: близько 20 запитів за хвилину для пакетної індексації 100 текстів приблизно по 200 токенів, близько чотирьох — для довших документів і близько 29 — для зазначеного сценарію Rerank. Для ембедингів коротких пошукових запитів автори оцінюють поріг у десятки тисяч запитів за хвилину.
Ці числа розраховано за конкретних припущень: одна виділена відеокарта NVIDIA A10, цілодобова робота з повним завантаженням, зазначені розміри запитів і опубліковані тарифи. Cohere окремо пояснює, що графіки й порогові значення змінюються залежно від тривалості роботи, конфігурації обладнання, знижок і обсягу документів. Їх варто сприймати як ілюстрацію методу розрахунку, а не як універсальні нормативи.
Водночас логіка вибору застосовна й поза межами конкретних прикладів. Передбачуване постійне навантаження може ефективніше використовувати зарезервовану потужність; короткі сплески з тривалими періодами простою частіше підходять для оплати за фактичним споживанням. Для інтерактивного пошуку також потрібно перевірити затримку за очікуваного навантаження: максимальна пропускна здатність обладнання не гарантує потрібного часу відповіді в робочому режимі.
Як застосувати цей огляд до власного пошуку
Перш ніж порівнювати варіанти, виміряйте на реальному трафіку кілька показників: кількість токенів і документів на запит, розмір пакетів індексації, кількість кандидатів для повторного ранжування, тривалість піків і цільову затримку. Потім розрахуйте вартість з урахуванням фактичного графіка, а не лише середньої кількості запитів. Для повної картини звірте актуальні ціни й умови розміщення зі сторінкою тарифів Cohere: для виділеної моделі та обробки за фактичним споживанням діють різні тарифи.
Для гібридного пошуку доцільно оцінювати етапи окремо: фонову повторну індексацію каталогу, короткі користувацькі запити й повторне ранжування кандидатів. Такий розрахунок допомагає з’ясувати, чи виправдана єдина інфраструктура, чи різні частини конвеєра вигідніше обслуговувати за різними моделями розміщення. Практичний підсумок публікації Cohere простий: спочатку виміряйте обсяг роботи, який припадає на кожен запит, і лише потім обирайте спосіб оплати та виділення ресурсів.