Twee diensten kunnen evenveel aanvragen naar een model sturen, maar toch een heel verschillende belasting veroorzaken. In de op 9 oktober gepubliceerde gids van Cohere over Embed en Rerank stelt het bedrijf voor om gedeelde of dedicated verwerking te kiezen op basis van de vorm van de aanvragen, het belastingspatroon en de latentievereisten. Het is een praktische analyse van infrastructuur, geen aankondiging van een nieuw tarief of product.

Voor teams die zoekfuncties en RAG bouwen, is deze conclusie relevant bij het plannen van indexering en gebruikersaanvragen: het aantal aanroepen geeft op zichzelf een gebrekkig beeld van de hoeveelheid rekenwerk. Eén batch documenten voor embeddings kan meer capaciteit vergen dan veel korte zoekopdrachten.
Waarom aanvragen per minuut misleidend kunnen zijn
Embeddings zetten teksten om in numerieke representaties die een zoeksysteem gebruikt voor semantische overeenkomsten. Tijdens de eerste indexering van een catalogus kan een toepassing grote batches beschrijvingen versturen; bij gewone zoekopdrachten krijgt het model een korte tekstuele zoekopdracht. Die taken stellen verschillende eisen: batchverwerking wordt doorgaans beoordeeld op doorvoer en kosten, terwijl bij zoeken de responstijd voor de gebruiker telt.
Voor Rerank is nog een parameter van belang: hoeveel kandidaten het systeem aan het model doorgeeft om opnieuw te rangschikken. In het voorbeeld van Cohere wordt een korte zoekopdracht vergeleken met 50 documenten; het bedrijf schat dat dit ongeveer 11.000 tokens aan verwerking vergt. Meer kandidaten vergroten de hoeveelheid werk, zelfs als de frequentie van zoekopdrachten door gebruikers gelijk blijft.
Wat de berekeningen van Cohere laten zien
Het artikel noemt indicatieve omslagpunten waarbij dedicated capaciteit economischer wordt dan betalen naar verbruik: ongeveer 20 aanvragen per minuut voor batchindexering van 100 teksten van elk circa 200 tokens, ongeveer vier voor langere documenten en circa 29 voor het beschreven Rerank-scenario. Voor korte zoekembeddings schatten de auteurs de drempel op tienduizenden aanvragen per minuut.
Deze cijfers zijn gebaseerd op specifieke aannames: één NVIDIA A10-gpu, die 24 uur per dag op volle capaciteit draait, de genoemde aanvraaggroottes en de gepubliceerde tarieven. Cohere licht afzonderlijk toe dat de grafieken en drempels veranderen bij een andere gebruiksduur, hardwareconfiguratie, kortingen en documentvolume. Zie ze als een illustratie van de berekeningsmethode, niet als universele richtlijnen.
De afweging is ook buiten de concrete voorbeelden breder toepasbaar. Een voorspelbare, constante belasting kan gereserveerde capaciteit beter benutten; korte pieken met lange perioden van inactiviteit passen vaker bij betalen naar werkelijk verbruik. Voor interactief zoeken moet ook de latentie bij de verwachte belasting worden getest: de maximale doorvoer van hardware garandeert niet de gewenste responstijd tijdens normaal gebruik.
Hoe je de analyse op je eigen zoekfunctie toepast
Meet vóór je opties vergelijkt een aantal zaken op basis van werkelijk verkeer: tokens en documenten per aanvraag, de omvang van indexeringsbatches, het aantal kandidaten voor herordening, de duur van piekperioden en de beoogde latentie. Bereken vervolgens de kosten op basis van het werkelijke belastingspatroon, niet alleen van het gemiddelde aantal aanvragen. Raadpleeg voor het volledige plaatje de tarievenpagina van Cohere voor de actuele tarieven en hostingvoorwaarden: dedicated modellen en verwerking naar verbruik worden verschillend in rekening gebracht.
Bij hybride zoektoepassingen is het verstandig de stappen afzonderlijk te beoordelen: achtergrondherindexering van de catalogus, korte zoekopdrachten van gebruikers en het opnieuw rangschikken van kandidaten. Zo kun je nagaan of één infrastructuur geschikt is, of dat verschillende onderdelen van de pijplijn voordeliger met verschillende hostingmodellen worden uitgevoerd. De praktische conclusie van Cohere is eenvoudig: meet eerst hoeveel werk elke aanvraag met zich meebrengt en kies pas daarna hoe je betaalt en capaciteit toewijst.