Cache-svar på API-begäranden för stora språkmodeller

GÄLLER FÖR: Alla API Management-nivåer

Principen llm-semantic-cache-store cachelagrar svar på API-begäranden om chattens slutförande till en konfigurerad extern cache. Responscaching minskar bandbredds- och bearbetningskraven som påtvingas backend-språkmodellens API och minskar latensen som API-konsumenter upplever.

Kommentar

  • Den här principen måste ha en motsvarande api-begärandeprincip för Hämta cachelagrade svar på stora språkmodeller.
  • Krav och steg för att aktivera semantisk cachelagring finns i Aktivera semantisk cachelagring för LLM-API:er i Azure API Management.
  • Eftersom semantisk cachelagring returnerar svar baserat på likhet (inte exakt matchning) kan den visa svar som är felaktiga, inaktuella eller osäkra för den aktuella begäran. Utvärdera den här funktionen noggrant för din arbetsbelastning och inkludera skyddsåtgärder.

Kommentar

Ange principens element och underordnade element i den ordning som anges i principbeskrivningen. Läs mer om hur du anger eller redigerar API Management-principer.

Modell-API:er som stöds

Den här principen fungerar med LLM-API:er som lagts till i API Management och som överensstämmer med något av följande API-scheman:

  • OpenAI-chattens slutförande eller svars-API
  • Anthropic Messages API (stöds för närvarande på API Management v2-nivåer)
  • Google Vertex AI API

Principuttryck

<llm-semantic-cache-store duration="seconds" cache-response="true | false" />

Attribut

Attribut beskrivning Obligatoriskt Standardvärde
varaktighet Time-to-live för de cachelagrade posterna, som anges i sekunder. Principuttryck tillåts. Ja Ej tillämpligt
cache-response Ange till cachelagrat true det aktuella HTTP-svaret. Om attributet utelämnas cachelagras endast HTTP-svar med statuskoden 200 OK . Principuttryck tillåts. No false

Förbrukning

Användningsanteckningar

  • Den här principen kan bara användas en gång i ett principavsnitt.
  • Om cachesökningen misslyckas utlöser inte API-anropet som använder den cacherelaterade åtgärden något fel och cacheåtgärden slutförs.
  • Vi rekommenderar att du konfigurerar en princip för hastighetsbegränsning (eller princip för hastighetsgräns per nyckel ) omedelbart efter alla cachesökningar. Detta hjälper till att hindra serverdelstjänsten från att överbelastas om cacheminnet inte är tillgängligt.

Exempel

Exempel med motsvarande llm-semantic-cache-lookup-policy

I följande exempel visas hur du använder llm-semantic-cache-lookup principen tillsammans med llm-semantic-cache-store principen för att hämta semantiskt liknande cachelagrade svar med ett tröskelvärde för likhetspoäng på 0,05. Cachelagrade värden partitioneras av anroparens prenumerations-ID.

Kommentar

Lägg till en hastighetsbegränsningspolicy (eller rate-limit-by-key-policy ) efter cache-uppslagningen för att begränsa antalet samtal och förhindra överbelastning på backend-tjänsten om cachen inte är tillgänglig.

<policies>
    <inbound>
        <base />
        <llm-semantic-cache-lookup
            score-threshold="0.05"
            embeddings-backend-id ="llm-backend"
            embeddings-backend-auth ="system-assigned" >
            <vary-by>@(context.Subscription.Id)</vary-by>
        </llm-semantic-cache-lookup>
        <rate-limit calls="10" renewal-period="60" />
    </inbound>
    <outbound>
        <llm-semantic-cache-store duration="60" />
        <base />
    </outbound>
</policies>

Relaterat innehåll

Mer information om hur du arbetar med principer finns i:

  • Last updated on