Optimera kostnaderna för den serverlösa prismodellen i Azure AI-sökning

Note

Azure AI-sökning är tillgängligt via Azure-portalen, REST-API:er och Azure-SDK:er. Den ligger också till grund för Foundry IQ, det hanterade kunskapsskiktet som omvandlar företagsinnehåll till återanvändbara, behörighetsmedvetna kunskapsbaser för agenter i Microsoft Foundry-portalen.

Azure AI-sökning har stöd för två prismodeller, var och en utformad för olika arbetsbelastningsmönster:

  • Dedikerad: Fast prissättning mätt i sökenheter (SU). Du väljer en tjänstnivå och debiteras per timme baserat på etablerade enheter.

  • Serverlös (förhandsversion): Förbrukningsbaserad prissättning mätt med beräkningsenheter per timme (CU/hr) och per GB/månad för indexerad lagring.

Important

Nivån Serverless Developer är för närvarande i förhandsversion. Den här förhandsversionen tillhandahålls utan ett serviceavtal och rekommenderas inte för produktionsarbetsbelastningar. Vissa funktioner kanske inte stöds eller kan vara begränsade. Mer information finns i Kompletterande villkor för användning av Microsoft Azure-förhandsversioner.

Fakturering för nivån Serverlös utvecklare är ännu inte aktiverad under förhandsversionen. Uppskattade kostnader för din användning är tillgängliga i Azure-portalen och telemetrin, men den användningen visas inte på din Azure faktura under den första perioden. Microsoft anger minst 30 dagars varsel innan faktureringen börjar. Uppskjutning av fakturering under den här förhandsversionen är tillfällig. Serverlös utvecklare är en betald nivå och du kommer att ansvara för eventuella avgifter som ackumuleras när faktureringen börjar.

Nivån Serverlös utvecklare stöder inte migrering till eller från andra prisnivåer och vissa funktioner som är tillgängliga på andra nivåer stöds inte under den offentliga förhandsversionen. Tjänstbegränsningar, funktioner som stöds och prisinformation kan ändras före allmän tillgänglighet.

Förhandsversionen är för närvarande endast tillgänglig i USA, västra centrala, Schweiz, norra och Japan, östra.

Mer information om prismodell- och tjänstnivåskillnader finns i Välja en prismodell och tjänstnivå.

Hur kostnaden bestäms i den serverlösa modellen

I den serverlösa modellen påverkar prestandaoptimering direkt kostnaden. Kostnaden är direkt kopplad till arbetsbelastningskörning:

  • Frågor och indexering förbrukar beräkning, mätt i Beräkningsenheter per timme (CU/h).
  • Lagring faktureras separat baserat på indexstorleken på disken.
  • När tjänsten är inaktiv utan aktiva frågor eller indexering är beräkningsanvändningen noll. Det finns ingen reserverad eller lägsta kapacitetsavgift.

Den serverlösa prismodellen är mest kostnadseffektiv för arbetsbelastningar med variabel, tillfällig eller oförutsägbar trafik, där etablerad kapacitet skulle vara underutnyttad.

Important

Dina avgifter per timme för Compute Unit (CU/h) inkluderar inte semantisk rangordning, agentbaserad hämtning, bildextraktion och körning av färdigheter. Dessa funktioner faktureras separat.

Förstå beräkningsenheter (CUS)

En beräkningsenhet (CU) representerar de uppmätta systemresurser som krävs för att utföra sök- och indexeringsåtgärder i den serverlösa modellen. CU-kostnaden drivs främst av processor-, minnes- och I/O-användning och i andra hand av indexstorlek och dokumentnyttolaststorlek med användning som faktureras som beräkningsenhet per timme (CU/h).

Beräkningskostnaden skalar med:

  • Frågekomplexitet
  • Indexstorlek (GB) och struktur
  • Dokumentnyttolaststorlek (KB)
  • Antal fält och hämtade resultat

Olika åtgärder har olika kostnadsprofiler:

  • Lookup: Låg kostnad. Att hämta ett enskilt dokument med dess ID är den mest effektiva åtgärden.
  • Nyckelordssökning: Låg kostnad. Textsökning använder inverterade index, som är optimerade för hastighet och låg beräkningsanvändning.
  • Vektorsökning: Hög kostnad. Vektorfrågor är beräkningsmässigt dyra eftersom de kräver likhetsberäkningar för högdimensionella inbäddningar. Jämfört med nyckelordssökning förbrukar de betydligt mer beräkning.
  • Hybridsökning: Kombinerar kostnaden för nyckelords- och vektorsökning, eftersom båda pipelines körs för varje fråga, plus en liten extra kostnad för Reciprocal Rank Fusion (RRF) för att sammanfoga resultat.

Övervaka beräkningsanvändning

Genom att övervaka beräkningsförbrukningen kan du identifiera dyra åtgärder, optimera frågemönster och beräkna kostnader. Kostnaden för beräkningsenhet (CU) för varje begäran returneras i x-ms-request-charge HTTP-svarshuvudet som ett flyttalsnummer. Använd den här rubriken för att identifiera dyra åtgärder och optimera frågemönster. Du kan spåra CU-kostnaden för varje begäran genom att granska HTTP-svarshuvuden och åtgärdshändelser i Azure Monitor. Mer information om vilka typer av övervakningsdata som är tillgängliga och metoder för att analysera dessa data finns i Övervaka Azure AI-sökning.

  • Rubrik: x-ms-request-charge: <value>
  • Värde: Ett flyttalsnummer som representerar de förbrukade CUS:erna.

Exempel:

Status: 200 OK
Content-Type: application/json
x-ms-request-charge: 12.45

I det här exemplet förbrukade begäran 12,45 beräkningsenheter. Du kan använda det här värdet för att identifiera högkostnadsåtgärder och jämföra den relativa kostnaden för olika frågemönster.

Om du vill granska den historiska beräkningsförbrukningen för en serverlös söktjänst använder du Azure Monitor mått i Azure-portalen:

  1. Gå till söktjänsten.
  2. Välj Mått.
  3. Välj + Lägg till mått.
  4. I måttlistan väljer du Beräkningsenheters användning.
  5. Använd diagrammet för att analysera användningstrender och identifiera perioder med ökad beräkningsförbrukning.

Övervakning av aggregerad användning hjälper dig att förstå övergripande tjänstkostnader och identifiera arbetsbelastningar som förbrukar mest beräkningsresurser. Beskrivningar av tillgängliga övervakningsmått finns i Övervakningsdatareferens. Du kan använda Azure Monitor loggar för att spåra aggregerad CU-användning över tid och korrelera den med ändringar av frågevolym och arbetsbelastning.

Skärmbild av instrumentpanelen för måttövervakning för serverlösa beräkningsenheter i Azure Portal.

Konfigurera aviseringar för beräkningsanvändning

Du kan skapa en aviseringsregel som ska meddelas när beräkningsförbrukningen når ett angivet tröskelvärde i Azure portalen.

  1. Gå till Aviseringar i söktjänsten.
  2. Välj + Skapa aviseringsregel.
  3. Under Villkor väljer du Användning av beräkningsenheter som signal.
  4. Definiera aviseringslogik. Du kan till exempel utlösa när den totala användningen är större än ett angivet värde.
  5. Konfigurera åtgärder, till exempel e-post, SMS eller webhook-meddelanden.
  6. Slutför de återstående stegen och välj Granska + skapa.

Aviseringar hjälper dig att proaktivt svara på oväntade användningstoppar och hantera kostnader.

Skärmbild av hur du skapar en aviseringsregel i Azure Portal.

Beräkna serverlösa kostnader

Den Azure priskalkylatorn och sökenhetens (SU)-baserade vägledning för kapacitetsplanering gäller inte för tjänster som använder den serverlösa prismodellen.

Så här beräknar du serverlösa kostnader:

  1. Index representativa exempeldata.
  2. Kör vanliga indexerings- och frågearbetsbelastningar.
  3. Registrera det värde som returneras av x-ms-request-charge för varje åtgärd.
  4. Använd Azure Monitor mått för att mäta aggregerad användning över tid.
  5. Extrapolera kostnader baserat på förväntad produktionstrafik.

Eftersom samma begäran som körs mot samma data vanligtvis ger liknande beräkningsförbrukning kan representativa arbetsbelastningar ge en tillförlitlig grund för kostnadsuppskattning.

Serverlös användning mäts kontinuerligt och aggregeras för fakturering. Beräkningsförbrukningen spåras under varje minut och genereras endast när beräkningsresurser används.

När du beräknar kostnader använder du avgiftsvärden för begäran för att förstå kostnaden för enskilda åtgärder och Azure Monitor mått för att förstå övergripande mönster för tjänstförbrukning.

Faktureringen baseras på aggregerad beräkningsanvändning i stället för enskilda begäranden. Användningen mäts i enminutersintervall och avrundas upp till närmaste 0,25 CU per minut. Dessa användningsintervall på en minut ackumuleras under en timme för att fastställa det fakturerbara CU/timbeloppet. Internt aggregeras användningen från milli-beräkningsenheter (mCU) till beräkningsenheter (CU) och omvandlas till den timvisa användning som rapporteras för fakturering.

Olika åtgärder förbrukar olika mängder beräkning. I regel:

  • Nyckelordssökningar använder vanligtvis minst beräkningsresurser.
  • Vektorsökningar använder vanligtvis fler beräkningsresurser än nyckelordssökningar.
  • Hybridsökningar kombinerar körning av nyckelord och vektorsökning, så de använder vanligtvis fler beräkningsresurser än enbart någon av teknikerna.

Den faktiska beräkningsförbrukningen beror på faktorer som frågekomplexitet, indexstorlek, datavolym, vektorkonfiguration och antalet returnerade resultat. Övervakning av avgifter för begäranden och aggregerade användningsstatistik kan hjälpa dig att identifiera optimeringsmöjligheter och bättre förutsäga produktionskostnader.

Minska beräkningskostnaderna genom optimering

Effektiva frågor och indexdesign minskar beräkningsförbrukningen och lägre kostnader.

Optimera ditt schema

Indexschemat avgör baslinjens beräknings- och lagringskostnader:

  • Begränsa fältattribut: Aktivera endast attribut (sökbara, filterbara, fasettbara, sorterbara) när det behövs. Varje attribut ökar indexstorleken och indexeringskostnaden.
  • Platta ut komplexa typer: Mappa kapslade JSON-strukturer till enkla fält eller samlingar där det är möjligt.
  • Ange hämtningsbar=falskt för fält med endast filter eller endast sortering: Om ett fält används för filtrering eller sortering men inte behöver returneras i resultat, behåll det indexerat och inställt retrievable=false på att minska lagringskostnaden på disk och per GB/månad.
  • Använd endast hämtningsbara fält när det är möjligt: Till exempel bör fält som endast används för visning (till exempel bild-URL:er) inte vara sökbara.
  • Minska vektordimensioner: Högre dimensionella vektorer ökar lagrings- och frågekostnaden. Använd mindre inbäddningsmodeller eller kvantisering när det är lämpligt.
  • Minimera storleken på dokumentnyttolasten före indexering: Större dokument kostar mer att indexera. Ta bort onödiga fält, trimma lång text och ta bort HTML innan du skickar dokument till indexet.

Optimera indexeringsbegäranden

Hur du skickar data till indexet påverkar både kostnad och dataflöde:

  • Använd större batcher när det är möjligt: Indexering i batcher minskar omkostnaderna per begäran genom att fördela nätverks- och bearbetningskostnader över fler dokument. I allmänhet är batchar med upp till ~1 000 dokument eller ~16 MB mer CU-effektiva än många små begäranden. Optimal batchstorlek beror dock på din arbetsbelastning. Testa för att balansera dataflöde, svarstid och tillförlitlighet.

  • Indexera endast nya eller ändrade data: Undvik fullständig omindexering när det är möjligt. Att bara skicka tillägg och uppdateringar minskar antalet bearbetade dokument, vilket sänker beräkningskostnaden och förbättrar inmatningshastigheten.

  • Använd ändringsidentifiering för inkrementell indexering: Identifiera vad som har ändrats innan du bearbetar om innehållet. Inkrementell indexering undviker upprepat arbete för oförändrade dokument och håller kostnaderna för ombearbetning nere.

  • Hoppa över extrahering av bilder om du inte behöver det: Bildextrahering lägger till extra bearbetningsarbete och kan bli en separat kostnadsdrivrutin. Aktivera den endast för dokument eller arbetsflöden som faktiskt behöver bildinnehåll.

  • Rikta kunskaper till relevanta fält och dokument: Omfångsberikningsfärdigheter till de specifika fält eller dokument de behöver. Undvik att använda kompetenser på innehåll som inte behöver någon berikning, särskilt när utdata inte används i senare steg.

  • Ta hänsyn till indexstorlekstillväxt: Skapa mindre index där det är möjligt. När ett index växer ökar indexeringskostnaderna eftersom mer data måste lagras och underhållas, och åtgärder kräver mer beräkning. För mycket stora datauppsättningar bör du överväga att partitionera data över flera index för att hantera prestanda och kostnader. Även om kostnaderna ökar med indexstorleken är ökningen sublineär. Större index kostar mer per åtgärd, men inte proportionellt mer.

Mer information finns i Tips för bättre prestanda i Azure AI-sökning.

Optimera dina frågor

Frågedesign är en primär drivrutin för variabel kostnad:

  • Använd $select för att begränsa returnerade fält: Detta minskar nyttolastens storlek och beräkning som krävs för serialisering.

    GET /docs?search=test&$select=id,title,url

  • Använd searchFields för att begränsa var text söks: Begränsa matchning av frågetid till de fält som är viktiga för scenariot. Varje ytterligare sökbart fält ökar frågearbetet och kan öka CU/h.

  • Föredrar exakta matchningsfrågor eller enkla nyckelordsfrågor: Fuzzy-, jokertecken-, regex- och prefixliknande frågor kan tvinga breda indexgenomsökningar och förbruka betydligt mer CU/h. Använd dem bara när du behöver delvis matchande beteende och välj exakta matchningsfrågor eller enklare nyckelordsfrågor där det är möjligt.

  • Använd sökningar i stället för sökningar när det är möjligt: Det är effektivare att hämta ett dokument med ID än att köra en sökfråga. Om du känner till dokument-ID:t använder du en sökning i stället för en sökfråga. Sökningar är mer effektiva eftersom de hämtar ett dokument direkt efter nyckel, medan sökfrågor anropar den fullständiga frågepipelinen (parsning, indexbläddring, bedömning och rangordning), vilket ökar beräkningskostnaden.

  • Undvik djup sidindelning ($skip): Stora $skip-värden ökar beräkningsbelastningen eftersom motorn måste bearbeta och rangordna alla tidigare resultat (till exempel kräver $skip=5000 poängsättning av minst 5 000 dokument som inte returneras). Detta slösar bort beräkningsresurser (CUs) och ökar kostnaderna. Använd i stället filter för att begränsa resultaten och begränsa antalet som returneras med $top. Anpassa storleken på $top så att den passar användargränssnittet. Till exempel $top=10 kostar mindre än $top=50 eftersom färre resultat poängsätts och returneras. Begär bara så många resultat som programmet behöver och undvik mönster som kräver att motorn bearbetar ett stort antal oanvända resultat.

  • Minimera fasetteringsantal och fasetteringsomfång: Begär endast de fasetter som visas i användargränssnittet och håll varje aspektvärde count så lågt som praktiskt. Fasetter kräver aggregeringar per fråga och höga antal ökar beräkningskostnaden.

  • Använd search.in för filtrering: När du filtrerar efter en lista med ID:ar eller värden använder du search.in funktionen i stället för flera or villkor (till exempel id eq '1' or id eq '2'). Den här metoden är effektivare och minskar beräkningskostnaderna. Du bör också undvika att markera fält med hög kardinalitet (de med ett stort antal unika värden, till exempel unika ID:er eller fritextbeskrivningar) som filterbara eller fasettbara om det inte krävs, eftersom detta ökar indexstorleken och frågekostnaden.

Optimera dina administrativa begäranden

Förutom fråge- och indexeringsåtgärder omfattar Azure AI-sökning administrativa åtgärder på objektnivå och servicenivå (till exempel hämtning av indexscheman eller tjänststatistik). Dessa begäranden har en fast kostnad per begäran. Varje begäran är billig, men upprepade eller onödiga anrop kan ackumuleras över tid och öka den totala beräkningsanvändningen.

  • Undvik orimliga administrativa begäranden: Cachemetadata, till exempel indexscheman, på klientsidan i stället för att hämta dem upprepade gånger. Om du till exempel hämtar indexschemat före varje skrivåtgärd medför det onödiga kostnader. I den serverlösa modellen ökar det här mönstret direkt beräkningsavgifterna, medan effekten i Dedikerade tjänster ofta döljs av fast timfakturering.

Optimera vektorkostnader

Vektorarbetsbelastningar är vanligtvis den högsta kostnadskomponenten i sökningen efter den serverlösa prismodellen eftersom de påverkar både beräkningsenheter (frågor och indexering) och lagring (vektorstorlek på disk). Optimera både hur vektorer lagras och hur de efterfrågas för att minska kostnaderna.

Optimera vektorlagring och schema

Vektorfält kan avsevärt öka indexstorleken och indexeringskostnaden. Använd följande tekniker för att minska lagringskostnaderna:

  • Använd komprimering för att minska vektorstorleken: Använd kvantisering för att minska lagringsavtrycket med minimal relevanspåverkan. Till exempel kan skalbar kvantisering minska vektorlagringen med upp till 4× med minimal påverkan på sökkvaliteten.

  • Inaktivera lagring för vektorer när det inte behövs: Ange stored=false på vektorfält om du bara behöver vektorer för sökning, inte hämtning. Detta förhindrar lagring av de ursprungliga vektorerna i indexet, vilket minskar lagringskostnaden utan att påverka frågebeteendet.

  • Använd mindre inbäddningsdimensioner när det är möjligt: Högre dimensionella vektorer ökar både lagrings- och frågekostnaden. För icke-kritiska arbetsbelastningar använder du mindre inbäddningsmodeller (till exempel 384 eller 768 dimensioner i stället för 1536) för att minska kostnaderna.

Optimera vektorfrågekörning

Vektorfrågor är beräkningsintensiva eftersom de kräver likhetsberäkningar jämfört med högdimensionella datastrukturer.

  • Använd hybridsökning selektivt: Hybridfrågor kör både nyckelords- och vektorhämtning. Använd endast när det behövs för relevans.

  • Använd filter före vektorfrågor: Begränsa kandidatuppsättningen före vektorsökning för att minska mängden data som bearbetas. Se Så här fungerar filtrering i vektorfrågor.

Minska kostnaderna genom att minimera användningen

Den serverlösa modellen debiterar endast för förbrukade resurser. När det inte finns några begäranden minskar beräkningsanvändningen i enlighet med detta.

Så här minimerar du användningskostnaderna:

  • Kör endast frågor när det behövs.
  • Undvik redundanta eller alltför ofta förekommande begäranden.
  • Övervaka användning och justera arbetsbelastningar baserat på efterfrågan.

Tip

Samma fråga kan ha olika svarstider och CU-profiler beroende på om tjänsten är varm eller kall. Efter en period utan läs- eller skrivtrafik sjunker beräkningsanvändningen i den serverlösa prismodellen till noll. Nästa begäran kan ha högre svarstid och förbruka fler processorer medan datasökvägarna värms upp. Större index tar vanligtvis längre tid att värma än mindre index, så kallstartseffekter är ofta mer märkbara för större tjänster.

Optimera lagringskostnader

Lagring faktureras per GB/månad baserat på diskindexstorleken, vilket kan överskrida rådatastorleken. Så här minskar du lagringskostnaderna:

  • Ta bort oanvända index.
  • Minimera lagrade fält.
  • Utforma scheman med lagringskostnader i åtanke.
  • Använd förslagsgivare selektivt eftersom de kan öka lagringsstorleken dramatiskt.

Vektorspecifika tekniker (komprimering, beskärning och lagringsinställningar) finns i Optimera för lagring och bearbetning av vektorer.

Mer information om kompromisser med lagrings- och frågeprestanda finns i Tips för bättre prestanda i Azure AI-sökning.

  • Last updated on