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
<a name="sagemaker-hyperpod-model-deployment-caching-routing"></a>

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
<a name="sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route"></a>

1. Abilita la memorizzazione nella cache KV impostando e su. `enableL1Cache` `enableL2Cache` `true` Quindi, configura `l2CacheSpec` impostando `l2CacheBackend` su o`redis`. `tieredstorage` Se lo desideri`redis`, 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.

1. Abilita il routing intelligente impostando `enabled` su `true` under`intelligentRoutingSpec`. È 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>
   ```

1. 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
<a name="sagemaker-hyperpod-model-deployment-kv-routing-compatibility"></a>

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/completions`endpoint non è supportato con `kvaware` il routing. Altre strategie di routing (`prefixaware`,`session`,`roundrobin`) funzionano con qualsiasi endpoint di invocazione.

**Immagini supportate:**
+ [Immagine VLM: hub.docker. com/r/vllm/vllm-openai](https://hub.docker.com/r/vllm/vllm-openai)
+ [Immagine LMCache: hub.docker. com/r/lmcache/vllm-openai](https://hub.docker.com/r/lmcache/vllm-openai/tags)
+ AWS [Contenitore di deep learning: gallery.ecr. aws/deep-apprendimento](https://gallery.ecr.aws/deep-learning-containers/vllm) - containers/vllm


| 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
<a name="sagemaker-hyperpod-model-deployment-kv-routing-validation"></a>

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
<a name="sagemaker-hyperpod-model-deployment-kv-routing-validation-registration"></a>

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
<a name="sagemaker-hyperpod-model-deployment-kv-routing-validation-cache-hits"></a>

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
<a name="sagemaker-hyperpod-model-deployment-kv-routing-validation-lmcache"></a>

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
<a name="sagemaker-hyperpod-model-deployment-kv-routing-validation-metrics"></a>

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) |