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 mehrstufiges Key-Value (KV) -Caching und intelligentes Routing, um die Inferenzleistung für Workloads mit großen Sprachmodellen (LLM) zu optimieren. KV-Caching speichert vorberechnete Schlüsselwert-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 niedriger 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, die höchstwahrscheinlich über relevante zwischengespeicherte Schlüssel-Wert-Paare verfügt. 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-Trefferrate 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 Amazon SageMaker HyperPod Inference-Bereitstellungsmethoden, einschließlich SageMaker JumpStart Amazon-Bereitstellungen (sowohl Konsole als auch Kubectl), lokalen NVMe-Speicherbereitstellungen und Bereitstellungen über 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 setzen. `true` Konfigurieren Sie dann, `l2CacheSpec` indem `l2CacheBackend` Sie entweder `redis` oder `tieredstorage` einstellen. 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 übertragenen Daten nicht garantiert.
**Anmerkung**  
Sie benötigen es nicht, `l2CacheLocalUrl` wenn ausgewählt `tieredstorage` ist.

1. Aktivieren Sie intelligentes Routing, indem Sie `enabled` die Option auf `true` unter setzen`intelligentRoutingSpec`. Sie können angeben, unter welcher Routing-Strategie Sie verwenden möchten`routingStrategy`. Wenn keine Routing-Strategie angegeben ist, ist sie standardmäßig auf `prefixaware` eingestellt.

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

1. Aktivieren Sie Router-Metriken und Caching-Metriken, indem Sie die Einstellung `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 Versionsbeschränkungen in diesem Abschnitt gelten * nur für * die `kvaware` Routing-Strategie. Die `kvaware` Strategie leitet eingehende Anfragen an die Inferenzinstanz mit der höchsten KV-Cache-Trefferrate weiter und unterstützt derzeit nur LLM-based V-Images mit der `/completions` API als Aufruf-Endpunkt.

**Anmerkung**  
Wenn Sie `kvaware` Routing verwenden, müssen Sie dies `/completions` in Ihrem Bereitstellungsmanifest festlegen`invocationEndpoint`. 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/-openai ](https://hub.docker.com/r/lmcache/vllm-openai/tags)
+ AWS Deep-Learning-Behälter: gallery.ecr[. aws/deep-Lernen- containers/vllm ](https://gallery.ecr.aws/deep-learning-containers/vllm)


| Version des Inferenzoperators | Amazon EKS-Version Add-on  | 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 Inferenzoperator-Version v3.1.3 oder höher mit den entsprechenden LMCache- und vLLM-Versionen zu verwenden, die in der Support-Matrix aufgeführt sind. Neuere LMCache-Versionen unterstützen Tensorparallelität, eine verbesserte Fehlerbehandlung und die Cache-Worker-Registrierung, wodurch eine bessere Robustheit beim Routing erreicht wird. KV-aware

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

Nachdem Sie ein Modell mit aktiviertem KV-aware Routing bereitgestellt haben, überprüfen Sie anhand der folgenden Schritte, ob das Routing ordnungsgemäß funktioniert.

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

Stellen Sie anhand der Router-Protokolle sicher, dass sich 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-Protokollen
<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).
```

#### Überprüfen Sie mit Grafana-Metriken
<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-Trefferquote für GPU-Präfixe (als Verhältnis berechnet) | 
| 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 (als Verhältnis berechnet) | 
| lmcache:request\_cache\_hit\_rate | Per-request Cache-Trefferrate (Histogramm) |