To tjenester kan sende like mange forespørsler til en modell, men likevel skape svært ulik belastning. I Cohere-guiden om Embed og Rerank, publisert 9. oktober, foreslår selskapet å velge delt eller dedikert behandling ut fra forespørselsmønster, belastningsplan og krav til responstid. Dette er en praktisk gjennomgang av infrastruktur, ikke en kunngjøring av en ny prisplan eller et nytt produkt.

For team som bygger søk og RAG, er poenget viktig når de planlegger indeksering og brukerforespørsler: antall kall beskriver i seg selv arbeidsmengden dårlig. Én dokumentpakke for generering av innbygginger kan kreve mer ressurser enn mange korte søk.
Hvorfor forespørsler per minutt kan villede
Innbygginger omformer tekst til numeriske representasjoner som søkesystemer bruker til semantisk matching. Når en katalog indekseres første gang, kan appen sende store pakker med beskrivelser; ved vanlig søk får modellen en kort søketekst. Oppgavene har ulike krav: Batchbehandling vurderes vanligvis ut fra gjennomstrømning og kostnad, mens søk vurderes ut fra hvor raskt brukeren får svar.
For Rerank er enda en parameter viktig: hvor mange kandidater systemet sender til modellen for omrangering. I Cohere-eksempelet matches en kort forespørsel mot 50 dokumenter; selskapet anslår at dette tilsvarer omtrent 11 000 tokener i behandling. Flere kandidater øker arbeidsmengden, selv om søkefrekvensen blant brukerne er uendret.
Hva Cohere-beregningene viser
Artikkelen oppgir omtrentlige økonomiske terskler for når det lønner seg å gå fra forbruksbasert betaling til dedikert kapasitet: rundt 20 forespørsler per minutt for batchindeksering av 100 tekster på omtrent 200 tokener hver, rundt fire for lengre dokumenter og rundt 29 for det beskrevne Rerank-scenarioet. For innbygginger av korte søk anslår forfatterne terskelen til titusenvis av forespørsler per minutt.
Tallene bygger på bestemte forutsetninger: én dedikert NVIDIA A10-GPU, drift med full utnyttelse døgnet rundt, de angitte forespørselsstørrelsene og publiserte priser. Cohere presiserer at grafer og terskler endres når driftstiden, maskinvarekonfigurasjonen, rabattene eller dokumentmengden er annerledes. Tallene bør derfor ses som en illustrasjon av beregningsmetoden, ikke som universelle normer.
Logikken bak valget gjelder likevel bredere enn de konkrete eksemplene. En forutsigbar, jevn belastning kan utnytte reservert kapasitet bedre; korte belastningstopper med lange perioder uten aktivitet passer oftere med betaling etter faktisk forbruk. Ved interaktivt søk bør man også teste responstiden under forventet belastning: maksimal gjennomstrømning fra maskinvaren garanterer ikke ønsket svartid i vanlig drift.
Slik bruker du analysen på ditt eget søk
Før du sammenligner alternativer, mål flere forhold ved reell trafikk: tokener og dokumenter per forespørsel, størrelsen på indekseringspakker, antall kandidater som skal rangeres på nytt, hvor lenge belastningstoppene varer, og ønsket responstid. Beregn deretter kostnaden ut fra det faktiske belastningsmønsteret, ikke bare gjennomsnittlig antall forespørsler. For å få hele bildet bør du kontrollere gjeldende priser og vilkår for drift på Cohere-prissiden: dedikerte modeller og forbruksbasert behandling prises forskjellig.
For blandet søk er det fornuftig å vurdere hvert trinn separat: bakgrunnsindeksering av katalogen, korte brukerforespørsler og omrangering av kandidater. En slik beregning hjelper deg med å finne ut om én felles infrastruktur er hensiktsmessig, eller om ulike deler av arbeidsflyten bør bruke forskjellige driftsmodeller. Den praktiske konklusjonen i Cohere-publikasjonen er enkel: Mål først arbeidet hver forespørsel innebærer, og velg deretter betalingsmodell og ressursallokering.