View a markdown version of this page

KV-Caching und intelligentes Routing - Amazon SageMaker KI
Konfigurieren Sie KV-Caching und intelligentes RoutingKV-aware Routing-Kompatibilität

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

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

  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öchtenredis, 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.

  2. Aktivieren Sie intelligentes Routing, indem Sie enabled die Option auf true unter setzenintelligentRoutingSpec. Sie können angeben, unter welcher Routing-Strategie Sie verwenden möchtenroutingStrategy. Wenn keine Routing-Strategie angegeben ist, ist sie standardmäßig auf prefixaware eingestellt.

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

  3. 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

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 festlegeninvocationEndpoint. 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:

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

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

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

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

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

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)