View a markdown version of this page

Caching KV e routing intelligente - Amazon SageMaker AI
Configura la memorizzazione nella cache KV e il routing intelligenteKV-aware compatibilità di routing

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Caching KV e routing intelligente

Amazon SageMaker HyperPod Inference offre caching KV (chiave-valore su più livelli) e routing intelligente per ottimizzare le prestazioni di inferenza per carichi di lavoro LLM (Large Language Model). La memorizzazione nella cache KV salva i vettori chiave-valore precalcolati dopo l'elaborazione dei token precedenti, eliminando i ricalcoli ridondanti. Tramite un'architettura di caching a due livelli, è possibile configurare una cache L1 che utilizza la memoria CPU per il riutilizzo locale a bassa latenza e una cache L2 che sfrutta Redis o lo storage gestito su più livelli per consentire una condivisione scalabile della cache a livello di nodo.

Il routing intelligente analizza le richieste in entrata e le indirizza all'istanza di inferenza che ha più probabilità di avere coppie chiave-valore pertinenti memorizzate nella cache. Il sistema esamina la richiesta e la indirizza in base a una delle seguenti strategie di routing:

  • prefixaware— Le richieste successive con lo stesso prefisso di prompt vengono indirizzate alla stessa istanza.

  • kvaware— Le richieste in entrata vengono indirizzate all'istanza con la più alta frequenza di accessi della cache KV.

  • session— Le richieste provenienti dalla stessa sessione utente vengono indirizzate alla stessa istanza.

  • roundrobin— Distribuisce le richieste in modo uniforme senza considerare lo stato della cache KV.

Il routing intelligente funziona con tutti i metodi di distribuzione di Amazon SageMaker HyperPod Inference, incluse le SageMaker JumpStart implementazioni Amazon (sia console che kubectl), le implementazioni di storage locale NVMe e le distribuzioni di Amazon S3, Amazon FSx o Hugging Face Hub. Puoi abilitare la memorizzazione nella cache e il routing indipendentemente dal metodo di distribuzione utilizzato per servire il tuo modello.

Nota

La memorizzazione nella cache KV e il routing intelligente attualmente supportano solo i contenitori di inferenza v. LLM-based

Configura la memorizzazione nella cache KV e il routing intelligente

  1. Abilita la memorizzazione nella cache KV impostando e su. enableL1Cache enableL2Cache true Quindi, configura l2CacheSpec impostando l2CacheBackend su oredis. tieredstorage Se lo desideriredis, esegui l'aggiornamento l2CacheLocalUrl con l'URL del cluster Redis.

      kvCacheSpec:
    enableL1Cache: true
    enableL2Cache: true
    l2CacheSpec:
      l2CacheBackend: <redis | tieredstorage>
      l2CacheLocalUrl: <Redis cluster URL if l2CacheBackend is redis >
    Nota

    Se il cluster Redis non si trova all'interno dello stesso Amazon VPC HyperPod del cluster, la crittografia dei dati in transito non è garantita.

    Nota

    Non è necessario che l2CacheLocalUrl tieredstorage sia selezionato.

  2. Abilita il routing intelligente impostando enabled su true underintelligentRoutingSpec. È possibile specificare la strategia di routing da utilizzare. routingStrategy Se non viene specificata alcuna strategia di routing, l'impostazione predefinita è. prefixaware

    intelligentRoutingSpec:
    enabled: true
    routingStrategy: <routing strategy to use>

  3. Abilita le metriche del router e le metriche di memorizzazione nella cache impostando su under. enabled true metrics Il port valore deve essere lo stesso del valore inferiore. containerPort modelInvocationPort

    metrics:
    enabled: true
    modelMetrics:
      port: <port value>
    ...
    modelInvocationPort:
      containerPort: <port value>

KV-aware compatibilità di routing

La matrice di compatibilità e i vincoli di versione in questa sezione si applicano solo alla strategia di routing. kvaware La kvaware strategia indirizza le richieste in entrata all'istanza di inferenza con la più alta frequenza di accesso alla cache KV e attualmente supporta solo LLM-based immagini v con l'API come endpoint di invocazione. /completions

Nota

Se si utilizza il kvaware routing, è necessario impostarlo nel manifesto di distribuzione. invocationEndpoint /completions L'/v1/chat/completionsendpoint non è supportato con kvaware il routing. Altre strategie di routing (prefixaware,session,roundrobin) funzionano con qualsiasi endpoint di invocazione.

Immagini supportate:

Versione dell'operatore di inferenza Add-on Versione Amazon EKS Versione dell'immagine LMCache Versione dell'immagine VLM
>= v3.1.3 >= v1.2.1-eksbuild.1 >= v0.4.3 >= v0.19.1
< v3.1.3 < v1.2.1-eksbuild.1 v0.3.9 post 2 v0.11.1
Nota

Si consiglia di utilizzare la versione dell'operatore di inferenza v3.1.3 o successiva con le versioni LMCache e vLLm corrispondenti mostrate nella matrice di supporto. Le versioni più recenti di LMCache supportano il parallelismo tensoriale, una migliore gestione degli errori e la registrazione dei cache worker, che forniscono una maggiore robustezza per il routing. KV-aware

Convalida del routing con riconoscimento della cache KV

Dopo aver distribuito un modello con il KV-aware routing abilitato, utilizza i seguenti passaggi per verificare che il routing funzioni correttamente.

Controllate la registrazione dei lavoratori

Verifica che i lavoratori si siano registrati sul router controllando i registri del router:

kubectl logs -n hyperpod-inference-system <router-pod> | grep -i "register"

Una registrazione corretta mostra:

INFO: Worker registered: lmcacheengineconfig_<hash>

Controlla gli accessi alla cache nei log del router

Verifica che il router utilizzi il KV-aware routing per indirizzare le richieste:

kubectl logs -n hyperpod-inference-system <router-pod> | grep -i "kvaware\|Matched instance\|Lookup"

Quando il KV-aware routing funziona correttamente:

INFO: Routing request to lmcacheengineconfig_<hash> found by kvaware router

Quando KV-aware il routing non funziona (torna al round robin):

DEBUG: Matched instance url None

Controlla l'inizializzazione di LMCache nei log di lavoro

Verifica che LMCache sia stato inizializzato correttamente sui worker pod:

kubectl logs -n <namespace> <worker-pod> | grep -i "LMCache"

Una buona inizializzazione mostra:

LMCache INFO: LMCacheManager initialized successfully

Se l'inizializzazione di LMCache non è riuscita, vedrai:

LMCache ERROR: Failed to initialize LMCacheManager components: . System will operate in degraded mode (recompute).

Verifica con le metriche Grafana

Con le metriche abilitate (metrics.enabled: true), le seguenti metriche dell'endpoint di lavoro VLLm confermano gli accessi alla cache. /metrics Queste metriche dovrebbero mostrare valori elevati quando il routing funziona correttamente: KV-aware

Metrica Description
vllm:prefix_cache_hits_total / vllm:prefix_cache_queries_total Frequenza di accesso alla cache del prefisso GPU (calcolata come rapporto)
lmcache:num_vllm_hit_tokens_total Numero di token serviti da LMCache
lmcache:num_lookup_hits_total / lmcache:num_lookup_tokens_total Frequenza di successo della ricerca LMCache (calcolata come rapporto)
lmcache:request_cache_hit_rate Per-request frequenza di accesso alla cache (istogramma)