Michael JohnsonDwie usługi mogą wysyłać do modelu tyle samo zapytań, a mimo to powodować zupełnie różne obciążenie. W poradniku Cohere dotyczącym Embed i Rerank, opublikowanym 9 października, firma proponuje wybierać współdzielone lub dedykowane przetwarzanie w zależności od charakteru zapytań, harmonogramu obciążenia i wymagań dotyczących opóźnień. To praktyczna analiza infrastruktury, a nie zapowiedź nowego planu taryfowego czy produktu.
Dla zespołów budujących wyszukiwarki i systemy RAG wnioski te są istotne przy planowaniu indeksowania i zapytań użytkowników: sama liczba wywołań słabo odzwierciedla zakres obliczeń. Jedna paczka dokumentów przetwarzana w celu utworzenia embeddingów może zużywać więcej zasobów niż wiele krótkich zapytań wyszukiwawczych.
Dlaczego liczba zapytań na minutę może wprowadzać w błąd
Embeddingi zamieniają teksty na reprezentacje liczbowe, których wyszukiwarka używa do semantycznego dopasowywania. Podczas początkowego indeksowania katalogu aplikacja może wysyłać duże paczki opisów; przy zwykłym wyszukiwaniu model otrzymuje krótki tekst zapytania. Te zadania mają różne wymagania: przetwarzanie wsadowe ocenia się zazwyczaj pod kątem przepustowości i kosztu, a wyszukiwanie — czasu odpowiedzi dla użytkownika.
W przypadku Rerank znaczenie ma jeszcze jeden parametr: liczba kandydatów przekazywanych modelowi do ponownego sortowania. W przykładzie Cohere krótkie zapytanie jest dopasowywane do 50 dokumentów; firma szacuje, że takie przetwarzanie obejmuje około 11 tysięcy tokenów. Zwiększenie liczby kandydatów rozszerza zakres pracy, nawet jeśli częstotliwość wyszukiwań użytkowników pozostaje bez zmian.
Co pokazują wyliczenia Cohere
W artykule przedstawiono orientacyjne progi opłacalności przejścia z płatności za zużycie na dedykowaną moc obliczeniową: około 20 zapytań na minutę przy wsadowym indeksowaniu 100 tekstów o długości mniej więcej 200 tokenów każdy, około czterech w przypadku dłuższych dokumentów i około 29 dla opisanego scenariusza Rerank. Dla krótkich embeddingów wyszukiwawczych autorzy szacują próg na dziesiątki tysięcy zapytań na minutę.
Liczby te opierają się na konkretnych założeniach: jednej dedykowanej karcie graficznej NVIDIA A10, pracy z pełnym obciążeniem przez całą dobę, wskazanych rozmiarach zapytań i opublikowanych cennikach. Cohere wyjaśnia również, że wykresy i progi zmieniają się w zależności od czasu pracy, konfiguracji sprzętu, rabatów i liczby dokumentów. Warto traktować je jako ilustrację metody obliczeń, a nie uniwersalne normy.
Sama logika wyboru ma jednak zastosowanie szersze niż opisane przykłady. Przewidywalne, stałe obciążenie może lepiej wykorzystać zarezerwowaną moc; krótkie skoki aktywności przeplatane długimi przestojami częściej przemawiają za płatnością za faktyczne zużycie. W przypadku wyszukiwania interaktywnego trzeba też sprawdzić opóźnienie przy spodziewanym obciążeniu: maksymalna przepustowość sprzętu nie gwarantuje wymaganego czasu odpowiedzi w warunkach produkcyjnych.
Jak zastosować analizę do własnej wyszukiwarki
Przed porównaniem opcji zmierz kilka parametrów na podstawie rzeczywistego ruchu: liczbę tokenów i dokumentów przypadających na zapytanie, wielkość paczek indeksowania, liczbę kandydatów do ponownego sortowania, czas trwania szczytów oraz docelowe opóźnienie. Następnie oblicz koszty dla rzeczywistego harmonogramu, a nie tylko średniej liczby zapytań. Aby uzyskać pełny obraz, sprawdź aktualne stawki i warunki wdrożenia na stronie cennika Cohere: dedykowany model i przetwarzanie rozliczane według zużycia podlegają innym opłatom.
W przypadku wyszukiwania hybrydowego warto osobno ocenić poszczególne etapy: ponowne indeksowanie katalogu w tle, krótkie zapytania użytkowników i ponowne sortowanie kandydatów. Takie wyliczenie pomaga sprawdzić, czy uzasadnione jest używanie jednej infrastruktury, czy też różne części potoku lepiej obsługiwać za pomocą odmiennych modeli wdrożenia. Praktyczny wniosek z publikacji Cohere jest prosty: najpierw zmierz pracę przypadającą na każde zapytanie, a dopiero potem wybierz sposób rozliczeń i przydzielania zasobów.