View a markdown version of this page

Cache KV e routing intelligente - Amazon SageMaker AI
Configura il caching 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à.

Cache KV e routing intelligente

Amazon SageMaker HyperPod Inference fornisce un caching KV (chiave-valore) gestito e un routing intelligente per ottimizzare le prestazioni di inferenza per i carichi di lavoro LLM (Large Language Model). Il caching 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 della CPU per il riutilizzo locale a bassa latenza e una cache L2 che sfrutta Redis o lo storage gestito su più livelli per consentire la condivisione della cache scalabile a livello di nodo.

Il routing intelligente analizza le richieste in arrivo e le indirizza all'istanza di inferenza che molto probabilmente contiene le 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 arrivo vengono indirizzate all'istanza con la più alta percentuale di hit 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 distribuzioni Amazon (sia console che kubectl), le SageMaker JumpStart distribuzioni di storage locale NVMe e le distribuzioni da Amazon S3, Amazon FSx o Hugging Face Hub. Puoi abilitare il caching e il routing indipendentemente dal metodo di distribuzione utilizzato per servire il tuo modello.

Nota

Il caching KV e il routing intelligente attualmente supportano solo i contenitori v inference. LLM-based

Configura il caching KV e il routing intelligente

  1. Abilita la memorizzazione nella cache KV impostando e to. enableL1Cache enableL2Cache true Quindi, configura l2CacheSpec impostando su l2CacheBackend uno o. redis tieredstorage Se lo desideriredis, aggiorna 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 del HyperPod 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 sottointelligentRoutingSpec. È possibile specificare in quale strategia di routing utilizzare. routingStrategy Se non viene specificata alcuna strategia di routing, il valore predefinito è. 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 uguale a quello sottocontainerPort. modelInvocationPort

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

KV-aware compatibilità del routing

La matrice di compatibilità e i vincoli di versione in questa sezione si applicano solo alla strategia di kvaware routing. La kvaware strategia indirizza le richieste in arrivo all'istanza di inferenza con la più alta frequenza di risposta 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 il routing. kvaware Altre strategie di routing (prefixaware,session,roundrobin) funzionano con qualsiasi endpoint di chiamata.

Immagini supportate:

Versione dell'operatore di inferenza Versione Amazon EKS Add-on Versione dell'immagine LMCache Versione dell'immagine vLLM
> = 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 post2 v0.11.1
Nota

Si consiglia di utilizzare la versione dell'operatore di inferenza v3.1.3 o superiore 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 implementato un modello con il KV-aware routing abilitato, utilizza i seguenti passaggi per verificare che il routing funzioni correttamente.

Controlla la registrazione dei lavoratori

Verifica che i lavoratori si siano registrati al router controllando i log del router:

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

Una registrazione integra 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 (si torna al round-robin):

DEBUG: Matched instance url None

Controlla l'inizializzazione di LMCache nei log dei lavoratori

Verificate che LMCache sia stato inizializzato correttamente sui worker pod:

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

Un'inizializzazione corretta 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 di 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 risposta della cache con prefisso GPU (calcolata come rapporto)
lmcache:num_vllm_hit_tokens_total Numero di token forniti da LMCache
lmcache:num_lookup_hits_total / lmcache:num_lookup_tokens_total Percentuale di successo della ricerca in LMCache (calcolata come rapporto)
lmcache:request_cache_hit_rate Per-request frequenza di accesso alla cache (istogramma)