Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# KV-Caching und intelligentes Routing
<a name="sagemaker-hyperpod-model-deployment-caching-routing"></a>

Amazon SageMaker HyperPod Inference bietet verwaltetes Tiered Key-Value (KV) -Caching und intelligentes Routing, um die Inferenzleistung für große Language Model (LLM) -Workloads zu optimieren. KV-Caching speichert vorberechnete Schlüssel-Wert-Vektoren nach der Verarbeitung früherer Token, wodurch redundante Neuberechnungen vermieden werden. Mithilfe einer zweistufigen Caching-Architektur können Sie einen L1-Cache konfigurieren, der CPU-Speicher für die lokale Wiederverwendung mit geringer Latenz verwendet, und einen L2-Cache, der Redis oder verwalteten Tiered Storage nutzt, um eine skalierbare Cache-gemeinsame Nutzung auf Knotenebene zu ermöglichen.

Intelligentes Routing analysiert eingehende Anfragen und leitet sie an die Inferenzinstanz weiter, bei der die relevanten Schlüssel-Wert-Paare am wahrscheinlichsten zwischengespeichert sind. Das System untersucht die Anfrage und leitet sie auf der Grundlage einer der folgenden Routing-Strategien weiter:
+ `prefixaware`— Nachfolgende Anfragen mit demselben Prompt-Präfix werden an dieselbe Instanz weitergeleitet.
+ `kvaware`— Eingehende Anfragen werden an die Instanz mit der höchsten KV-Cache-Trefferquote weitergeleitet.
+ `session`— Anfragen aus derselben Benutzersitzung werden an dieselbe Instanz weitergeleitet.
+ `roundrobin`— Verteilt Anfragen gleichmäßig, ohne den Status des KV-Cache zu berücksichtigen.

Intelligentes Routing funktioniert mit allen Bereitstellungsmethoden von Amazon SageMaker HyperPod Inference, einschließlich SageMaker JumpStart Amazon-Bereitstellungen (sowohl Konsole als auch Kubectl), lokalen NVMe-Speicherbereitstellungen und Bereitstellungen von Amazon S3, Amazon FSx oder Hugging Face Hub. Sie können Caching und Routing unabhängig davon aktivieren, welche Bereitstellungsmethode Sie für Ihr Modell verwenden.

**Anmerkung**  
KV-Caching und intelligentes Routing unterstützen derzeit nur LLM-based V-Inferenzcontainer.

## Konfigurieren Sie KV-Caching und intelligentes Routing
<a name="sagemaker-hyperpod-model-deployment-deploy-ftm-cache-route"></a>

1. Aktivieren Sie das KV-Caching, indem Sie `enableL1Cache` und `enableL2Cache` auf einstellen. `true` Konfigurieren Sie dann, `l2CacheSpec` indem `l2CacheBackend` Sie entweder `redis` oder `tieredstorage` wählen. Wenn Sie möchten`redis`, aktualisieren Sie `l2CacheLocalUrl` mit der Redis-Cluster-URL.

   ```
     kvCacheSpec:
       enableL1Cache: true
       enableL2Cache: true
       l2CacheSpec:
         l2CacheBackend: <redis | tieredstorage>
         l2CacheLocalUrl: <Redis cluster URL if l2CacheBackend is redis >
   ```
**Anmerkung**  
Wenn sich der Redis-Cluster nicht in derselben Amazon VPC wie der HyperPod Cluster befindet, ist die Verschlüsselung der Daten während der Übertragung nicht garantiert.
**Anmerkung**  
Sie benötigen es nicht, `l2CacheLocalUrl` wenn es ausgewählt `tieredstorage` ist.

1. Aktivieren Sie intelligentes Routing, indem Sie `enabled` die Einstellung auf `true` unter setzen`intelligentRoutingSpec`. Sie können unter angeben, welche Routing-Strategie verwendet werden soll`routingStrategy`. Wenn keine Routingstrategie angegeben ist, wird standardmäßig verwendet. `prefixaware`

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

1. Aktivieren Sie Router-Metriken und Caching-Metriken, indem Sie `enabled` auf `true` unter setzen. `metrics` Der `port` Wert muss mit dem `containerPort` Wert unter `modelInvocationPort` übereinstimmen.

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

## KV-aware Routing-Kompatibilität
<a name="sagemaker-hyperpod-model-deployment-kv-routing-compatibility"></a>

Die Kompatibilitätsmatrix und die Versionseinschränkungen in diesem Abschnitt gelten *nur* für die `kvaware` Routingstrategie. Die `kvaware` Strategie leitet eingehende Anfragen an die Inferenzinstanz mit der höchsten KV-Cache-Trefferquote weiter und unterstützt derzeit nur LLM-based V-Bilder mit der `/completions` API als Aufruf-Endpunkt.

**Anmerkung**  
Wenn Sie `kvaware` Routing verwenden, müssen Sie `/completions` in Ihrem `invocationEndpoint` Bereitstellungsmanifest den Wert auf festlegen. Der `/v1/chat/completions` Endpunkt wird beim `kvaware` Routing nicht unterstützt. Andere Routing-Strategien (`prefixaware`,`session`,`roundrobin`) funktionieren mit jedem Aufruf-Endpunkt.

**Unterstützte Bilder:**
+ [vLLM-Bild: hub.docker. com/r/vllm/vllm-openai](https://hub.docker.com/r/vllm/vllm-openai)
+ [LMCache-Bild: hub.docker. com/rlmcache/vllm](https://hub.docker.com/r/lmcache/vllm-openai/tags)/-openai
+ AWS [Container für tiefes Lernen: gallery.ecr. aws/deep-Lernen](https://gallery.ecr.aws/deep-learning-containers/vllm) - containers/vllm


| Version des Inferenzoperators | Amazon Add-on EKS-Version | LMCache-Image-Version | vLLM-Image-Version | 
| --- | --- | --- | --- | 
| >= 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 Beitrag 2 | v0.11.1 | 

**Anmerkung**  
Wir empfehlen, die Inferenzoperatorversion v3.1.3 oder höher mit den entsprechenden LMCache- und vLLM-Versionen zu verwenden, die in der Unterstützungsmatrix aufgeführt sind. Neuere LMCache-Versionen unterstützen Tensorparallelität, verbesserte Fehlerbehandlung und Cache-Worker-Registrierung, wodurch das Routing robuster wird. KV-aware

### Validierung des KV-Cache-fähigen Routings
<a name="sagemaker-hyperpod-model-deployment-kv-routing-validation"></a>

Führen Sie nach der Bereitstellung eines Modells mit aktiviertem KV-aware Routing die folgenden Schritte aus, um zu überprüfen, ob das Routing ordnungsgemäß funktioniert.

#### Überprüfen Sie die Mitarbeiterregistrierung
<a name="sagemaker-hyperpod-model-deployment-kv-routing-validation-registration"></a>

Überprüfen Sie anhand der Router-Protokolle, ob sich die Mitarbeiter beim Router registriert haben:

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

Eine fehlerfreie Registrierung zeigt:

```
INFO: Worker registered: lmcacheengineconfig_<hash>
```

#### Überprüfen Sie die Cache-Treffer in den Router-Protokollen
<a name="sagemaker-hyperpod-model-deployment-kv-routing-validation-cache-hits"></a>

Stellen Sie sicher, dass der Router KV-aware Routing verwendet, um Anfragen weiterzuleiten:

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

Wenn das KV-aware Routing ordnungsgemäß funktioniert:

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

Wenn das KV-aware Routing nicht funktioniert (fällt auf Round-Robin zurück):

```
DEBUG: Matched instance url None
```

#### Überprüfen Sie die LMCache-Initialisierung in den Worker-Logs
<a name="sagemaker-hyperpod-model-deployment-kv-routing-validation-lmcache"></a>

Stellen Sie sicher, dass LMCache erfolgreich auf den Worker-Pods initialisiert wurde:

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

Eine fehlerfreie Initialisierung zeigt:

```
LMCache INFO: LMCacheManager initialized successfully
```

Wenn LMCache nicht initialisiert werden konnte, wird Folgendes angezeigt:

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

#### Mit Grafana-Metriken verifizieren
<a name="sagemaker-hyperpod-model-deployment-kv-routing-validation-metrics"></a>

Wenn Metriken aktiviert sind (`metrics.enabled: true`), bestätigen die folgenden Metriken vom `/metrics` vLLM-Worker-Endpunkt Cache-Treffer. Diese Metriken sollten hohe Werte aufweisen, wenn das KV-aware Routing ordnungsgemäß funktioniert:


| Metrik | Description | 
| --- | --- | 
| vllm:prefix\_cache\_hits\_total / vllm:prefix\_cache\_queries\_total | Cache-Trefferrate für das GPU-Präfix (berechnet als Verhältnis) | 
| lmcache:num\_vllm\_hit\_tokens\_total | Anzahl der von LMCache bereitgestellten Token | 
| lmcache:num\_lookup\_hits\_total / lmcache:num\_lookup\_tokens\_total | Trefferquote bei der LMCache-Suche (berechnet als Verhältnis) | 
| lmcache:request\_cache\_hit\_rate | Per-request Cache-Trefferquote (Histogramm) |