jsonscraper

Cohere legt uit wanneer dedicated infrastructuur voordeliger is voor Embed en Rerank

Een analyse van 9 oktober koppelt de keuze tussen gedeelde en dedicated verwerking aan de omvang van aanvragen, het belastingspatroon en de gewenste latentie.

Redactioneel beleid Een fout melden

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.

Artikel: Cohere legt uit wanneer dedicated infrastructuur voordeliger is voor Embed en Rerank
Samenvatting: Cohere publiceerde een gids voor de keuze tussen gedeelde en dedicated infrastructuur voor Embed en Rerank. De belangrijkste praktische les: kijk niet alleen naar aanvragen per minuut, maar ook naar de hoeveelheid werk per aanvraag en de benutting van de capaciteit.
Beeldrol: omslag — het centrale idee
Sectie: 
Visueel onderwerp: Een technische stillevenfoto van dichtbij, met gedrukte productcataloguskaartjes die door een fysiek sorteersysteem bewegen int
© jsonscraper · AI-gegenereerde illustratie

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.

een zwart-witfoto van een keuken
Hoseung Han · Unsplash-licentie

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.

Keep readingGoogle stelt SynthID Detector beschikbaar voor controle van afbeeldingen, video en audio
Read the next article

Maak van wat je leest een werkende integratie

Ontdek de socialdata-API's van jsonscraper, test aanvragen en bouw je volgende workflow.

API's verkennen