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

Precompilazione e decodifica disaggregate per l'inferenza HyperPod

Disaggregated Prefill and Decode (DPD) separa le due fasi di inferenza LLM, prefill e decodifica, su pool di GPU dedicati e trasferisce la cache chiave-valore (KV) tra di loro tramite Elastic Fabric Adapter (EFA) utilizzando Remote Direct Memory Access (RDMA). GPU-Direct

Quando la precompilazione e la decodifica vengono eseguite sulla stessa GPU (in co-location), una singola richiesta a lungo contesto può bloccare i flussi di token in corso per altri client, aumentando la latenza per token sotto carico. DPD rimuove questa interferenza eseguendo la precompilazione associata al calcolo su un set di GPU e la decodifica limitata alla larghezza di banda di memoria su un altro, producendo una latenza più prevedibile in caso di traffico misto e consentendo di scalare ogni fase in modo indipendente.

L'operatore di inferenza gestisce l'orchestrazione, che include il provisioning del router, il cablaggio dei pod di precompilazione e decodifica tramite LMCache e NIXL e l'integrazione con l'osservabilità. HyperPod Puoi abilitare DPD aggiungendo una sezione alla stessa risorsa che già utilizzi per gli endpoint di inferenza. pdSpec InferenceEndpointConfig

Quando DPD aiuta

DPD offre il massimo vantaggio quando sono presenti tutte le seguenti condizioni:

Se il carico di lavoro prevede input brevi, bassa concorrenza o utilizza modelli di piccole dimensioni, un'implementazione standard in colocation è più semplice e offre buone prestazioni.

Prerequisiti

Prima di distribuire endpoint di inferenza che utilizzano Disaggregated Prefill and Decode, è necessario configurare i seguenti componenti nell'ambiente di sviluppo locale:

Implementate un endpoint DPD

La maggior parte dei InferenceEndpointConfig campi è condivisa con endpoint non DPD e documentata in. Implementazione di modelli di fondazione e di modelli ottimizzati con fine-tuning personalizzati Per abilitare DPD, aggiungete le seguenti sezioni al manifesto.

Prefill-Decode Specifiche: PDSpec

Dichiara la topologia e specifica gli prefill/decode argomenti. La presenza di questo campo è ciò che rende l'endpoint disaggregato: l'operatore crea implementazioni separate per la precompilazione e la decodifica e le collega tra loro tramite il router e il backend LMCache PD.

pdSpec:
  prefillSpec:
    replicas: 1
    resources:
      limits:
        nvidia.com/gpu: ${GPUS_PER_NODE}
      requests:
        nvidia.com/gpu: ${GPUS_PER_NODE}
    args:
      - "--gpu-memory-utilization"
      - "0.75"
  decodingSpec:
    replicas: 1
    resources:
      limits:
        nvidia.com/gpu: ${GPUS_PER_NODE}
      requests:
        nvidia.com/gpu: ${GPUS_PER_NODE}
  routingThreshold: 4096

Variabili di ambiente DPD: variabili d'ambiente

Queste variabili di ambiente vengono applicate in modo identico sia al contenitore del prefiller che al contenitore del decoder; non esiste un campo env-var per ruolo. Per pdSpec.{prefillSpec,decodingSpec}.args un comportamento per ruolo, usa invece.

environmentVariables:
  - name: PD_BUFFER_SIZE
    value: "8589934592"
  - name: LMCACHE_SAVE_DECODE_CACHE
    value: "False"
  - name: PYTHONHASHSEED
    value: "0"

Configura la strategia di routing

La intelligentRoutingSpec sezione imposta la strategia di routing utilizzata dal router DPD per selezionare un prefiller per ogni richiesta. Il router viene creato automaticamente quando è presente; questa sezione pdSpec è facoltativa e l'impostazione predefinita è. prefixaware

intelligentRoutingSpec:
  enabled: true
  routingStrategy: prefixaware

DPD può anche essere integrato con il routing intelligente e la memorizzazione nella cache KV. Per ulteriori informazioni, consulta Configura la memorizzazione nella cache KV e il routing intelligente.

Con un'unica replica di precompilazione, tutte le strategie vengono indirizzate verso quella replica. La scelta influisce sul comportamento solo quando: prefillSpec.replicas > 1

Esempio completo

Il seguente manifesto distribuisce Llama 3.3 70B su due istanze ml.p5.48xlarge (un prefiller, un decoder):

apiVersion: inference.sagemaker.aws.amazon.com/v1
kind: InferenceEndpointConfig
metadata:
  name: dpd-test
  namespace: default
spec:
  endpointName: dpd-test
  instanceType: ml.p5.48xlarge
  invocationEndpoint: v1/chat/completions
  modelName: Llama-3.3-70B-Instruct
  modelSourceConfig:
    modelSourceType: s3
    modelLocation: Llama-3.3-70B-Instruct
    s3Storage:
      bucketName: <YOUR_BUCKET>
      region: <YOUR_REGION>
  loadBalancer:
    healthCheckPath: /health
  metrics:
    enabled: true
  kvCacheSpec:
    enableL1Cache: true
  intelligentRoutingSpec:
    enabled: true
    routingStrategy: prefixaware
  pdSpec:
    prefillSpec:
      replicas: 1
      resources:
        requests:
          nvidia.com/gpu: "8"
        limits:
          nvidia.com/gpu: "8"
    decodingSpec:
      replicas: 1
      resources:
        requests:
          nvidia.com/gpu: "8"
        limits:
          nvidia.com/gpu: "8"
    routingThreshold: 4096
  worker:
    image: public.ecr.aws/deep-learning-containers/vllm:server-hyperpod-cuda-v1.1
    args:
      - "--model"
      - "/opt/ml/model"
      - "--host"
      - "0.0.0.0"
      - "--port"
      - "8000"
      - "--tensor-parallel-size"
      - "8"
      - "--max-model-len"
      - "16384"
      - "--gpu-memory-utilization"
      - "0.75"
    modelInvocationPort:
      name: http
      containerPort: 8000
    modelVolumeMount:
      name: model-weights
      mountPath: /opt/ml/model
    resources:
      requests:
        cpu: "96"
        memory: 1024Gi
        nvidia.com/gpu: "8"
      limits:
        cpu: "96"
        memory: 1024Gi
        nvidia.com/gpu: "8"
    environmentVariables:
      - name: HF_HOME
        value: /tmp/hf_home
      - name: PD_BUFFER_SIZE
        value: "8589934592"
      - name: LMCACHE_SAVE_DECODE_CACHE
        value: "False"
      - name: PYTHONHASHSEED
        value: "0"

Applica il manifesto:

kubectl apply -f inference_endpoint_dpd_config.yaml

Verifica della distribuzione

L'estrazione dell'immagine e il caricamento del modello richiedono alcuni minuti. Monitora lo stato del pod:

kubectl get pods -A \
  | grep -E "prefill-|decode-|router"

Una corretta implementazione dimostra:

NAMESPACE                   NAME                                   READY   STATUS    RESTARTS   AGE
default                     prefill-dpd-test-XXXX                  3/3     Running   0          7m
default                     decode-dpd-test-XXXX                   3/3     Running   0          7m
hyperpod-inference-system   dpd-test-router-XXXX                   2/2     Running   0          7m

Ogni pod modello ha 3 contenitori (vLLM worker, Nginx reverse proxy, collector). OpenTelemetry Il pod del router ha 2 contenitori (router, collector). OpenTelemetry Controlla lo InferenceEndpointConfig stato:

kubectl get inferenceendpointconfig dpd-test -n default \
  -o jsonpath='{.status.conditions[0].message}{"\n"}'

Output previsto: DPD prefill and decode deployments are ready

Verifica i ruoli DPD

Conferma i rapporti del precompilatore sender e dei decodificatori. receiver Questo è il segnale di avvio più importante: se entrambi i pod riportano lo stesso ruolo o nessuno dei due riporta la linea, l'operatore non ha cablato DPD correttamente.

PREFILL_POD=$(kubectl get pod -n ${NAMESPACE} \
  -l 'inference.sagemaker.aws.amazon.com/dpd-role=prefill' \
  -o jsonpath='{.items[0].metadata.name}')

DECODE_POD=$(kubectl get pod -n ${NAMESPACE} \
  -l 'inference.sagemaker.aws.amazon.com/dpd-role=decode' \
  -o jsonpath='{.items[0].metadata.name}')

kubectl logs $PREFILL_POD -n ${NAMESPACE} -c prefill-${DEPLOYMENT_NAME} \
  | grep -oE "'pd_role': '[a-z]+'" | sort -u

kubectl logs $DECODE_POD -n ${NAMESPACE} -c decode-${DEPLOYMENT_NAME} \
  | grep -oE "'pd_role': '[a-z]+'" | sort -u

Output previsto:

'pd_role': 'sender'
'pd_role': 'receiver'

Richiamare l'endpoint

Una volta che l'endpoint è pronto, invia un prompt breve e uno lungo per eseguire entrambi i percorsi di routing, quindi controlla i log per confermare il trasferimento KV tramite EFA.

PREFILL_POD=$(kubectl get pod -n ${NAMESPACE} \
  -l 'inference.sagemaker.aws.amazon.com/dpd-role=prefill' \
  -o jsonpath='{.items[0].metadata.name}')

DECODE_POD=$(kubectl get pod -n ${NAMESPACE} \
  -l 'inference.sagemaker.aws.amazon.com/dpd-role=decode' \
  -o jsonpath='{.items[0].metadata.name}')

ROUTER_POD=$(kubectl get pods -n hyperpod-inference-system -o name \
  | grep -- "${DEPLOYMENT_NAME}-${NAMESPACE}-router" | head -1)

ROUTER_URL=http://${DEPLOYMENT_NAME}-${NAMESPACE}-routing-service.hyperpod-inference-system.svc.cluster.local:443/v1/chat/completions

Richiesta breve (sotto la soglia, diretta al decoder)

Le richieste con un numero di token inferiore a quello di routingThreshold bypassano il prefiller e vanno direttamente al decoder:

kubectl run curl-short --rm -it --image=curlimages/curl --restart=Never -- \
  curl -s -k -X POST "$ROUTER_URL" \
    -H "Content-Type: application/json" \
    -d '{
      "model": "/opt/ml/model",
      "messages": [{"role": "user", "content": "What is disaggregated prefill-decode in one sentence?"}],
      "max_tokens": 80,
      "temperature": 0.0
    }'

Richiesta lunga (supera la soglia, percorso DPD)

Le richieste che superano la soglia vengono inoltrate attraverso il prefiller per il calcolo della cache KV, quindi verso il decoder per la generazione di token:

kubectl run curl-long --rm -it --image=curlimages/curl --restart=Never -- sh -c '
LONG=""
i=0; while [ $i -lt 600 ]; do LONG="${LONG}The quick brown fox jumps over the lazy dog. "; i=$((i+1)); done
curl -s -k -X POST "'"$ROUTER_URL"'" \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"/opt/ml/model\",\"messages\":[{\"role\":\"user\",\"content\":\"${LONG}\"}],\"max_tokens\":30,\"temperature\":0.0}"
'

Verifica il trasferimento KV

Dopo aver inviato una richiesta lunga, conferma che la cache KV è stata trasferita controllando i registri del decoder:

kubectl logs $DECODE_POD -n ${NAMESPACE} -c decode-${DEPLOYMENT_NAME} \
  | grep -E "Retrieved.*tokens.*throughput" | tail -2

Output previsto (una riga per grado TP):

[Worker_TP5] [LMCache INFO] [req_id=cmpl-...] Retrieved 6035 out of 6035 required tokens (from 6035 total tokens).
   size: 0.2344 gb, cost 1.3304 ms, throughput: 176.1686 GB/s

Retrieved N out of N required tokenscon N > 0 conferma che la cache KV ha attraversato correttamente il canale NIXL. Se vediRetrieved 0 out of N, il decoder è tornato alla ricalcolo locale: vedi. Problemi di implementazione di Disaggregated Prefill and Decode (DPD)

Puoi anche verificare la decisione di routing nei log del router:

kubectl logs $ROUTER_POD -n hyperpod-inference-system -c router-container --tail=20 \
  | grep -E "Conditional routing"

Per il prompt lungo, dovresti vedere:

[INFO] Conditional routing: estimated_tokens=6750, threshold=4096, disaggregate=True

Per il prompt breve:

[INFO] Conditional routing: estimated_tokens=12, threshold=4096, disaggregate=False

Osservabilità

Abilita le metriche impostando il tuo. metrics.enabled: true InferenceEndpointConfig Le metriche DPD sono disponibili nella dashboard di inferenza. HyperPod Per ulteriori informazioni, consulta Implementazione dell'osservabilità inferenziale sui cluster HyperPod.

Sono disponibili le seguenti DPD-specific metriche:

Ottimizzate la distribuzione di DPD

La tabella seguente fornisce un riferimento rapido per ottimizzare DPD in base ai sintomi osservati nella dashboard delle metriche.

Esegui il test con il carico di lavoro effettivo e la distribuzione della lunghezza di input.

Per applicare le modifiche alla configurazione, modifica il codice YAML della tua implementazione e riapplica:

kubectl apply -f inference_endpoint_dpd_config.yaml

Limiti noti

Per la risoluzione dei problemi relativi alle implementazioni DPD, consulta. Problemi di implementazione di Disaggregated Prefill and Decode (DPD)