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

  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ö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 Daten während der Übertragung nicht garantiert.

    Anmerkung

    Sie benötigen es nicht, l2CacheLocalUrl wenn es ausgewählt tieredstorage ist.

  2. Aktivieren Sie intelligentes Routing, indem Sie enabled die Einstellung auf true unter setzenintelligentRoutingSpec. Sie können unter angeben, welche Routing-Strategie verwendet werden sollroutingStrategy. Wenn keine Routingstrategie angegeben ist, wird standardmäßig verwendet. prefixaware

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

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

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:

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

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

Ü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

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

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

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)