Перейти к основному содержимому

For clean Markdown content of this page, append .md to this URL. For the complete documentation index, see https://docs.nvidia.com/dynamo/llms.txt. For full content including API reference and SDK examples, see https://docs.nvidia.com/dynamo/llms-full.txt.

Переключение на резервный движок Shadow Engine

⚠️ Экспериментальная функция: Shadow Engine Failover — это опциональная предварительная функция. Она зависит от GPU Memory Service (GMS), Dynamic Resource Allocation (DRA) и поддержки на стороне конкретного backend. Форму API и поведение еще могут изменить, а конечный автомат failover все еще дорабатывается. Используйте ее только для непроизводственной оценки, если только вы не проверили точный backend, топологию и сценарий отказа в своем кластере.

Обзор​

Используйте Shadow Engine Failover, когда нужен резервный движок, который перехватит работу после неизвестного отказа backend-движка или программного процесса, при этом GPU и узел остаются исправными. Цель — избежать полной повторной загрузки весов модели после сбоя процесса на том же узле.

Shadow Engine Failover — это рабочий процесс Kubernetes. GPU Memory Service — лежащий под ним механизм: GMS владеет находящимися в памяти GPU весами модели, а активный и резервный движки подключаются к этим весам через DRA.

Это отдельно от Dynamo Snapshot. Snapshot захватывает и восстанавливает образ процесса с помощью CRIU и cuda-checkpoint. Shadow Engine Failover удерживает веса модели в памяти GPU, чтобы резервный или заменяющий движок мог подключиться после выбранных отказов на уровне процесса. Оба подхода нацелены на сокращение времени восстановления, но решают разные задачи и не взаимозаменяемы.

Поток восстановления после отказа​

Следующая диаграмма иллюстрирует восстановление на уровне процесса на том же узле:

┌──────────────────────── Same healthy node + GPU ───────────────────────┐
│                                                                        │
│  Before failure                                                        │
│  ┌──────────────┐      attach/use      ┌───────────────────────────┐   │
│  │ Engine A     │ ───────────────────▶ │ GMS-owned model weights   │   │
│  │ active       │                      │ resident in GPU memory    │   │
│  └──────┬───────┘                      └────────────┬──────────────┘   │
│         │                                           ▲                  │
│         │                                           │ attach/use       │
│         │ unknown software/engine failure           │                  │
│         ▼                                           │                  │
│  ┌──────────────┐                            ┌──────┴───────┐          │
│  │ Engine A     │ exits                      │ Engine B     │          │
│  └──────────────┘                            │ shadow       │          │
│                                              └──────┬───────┘          │
│                                                     │ takeover         │
│                                                     ▼                  │
│                                              ┌──────────────┐          │
│                                              │ Engine B     │          │
│                                              │ active       │          │
│                                              └──────────────┘          │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

Как это работает:

  1. Оператор создает контейнеры или pod активного и резервного движка для worker, в зависимости от выбранного режима failover.
  2. Движки разделяют доступ к GPU через DRA и подключаются к весам модели, которыми владеет GMS.
  3. Неизвестный программный сбой или сбой движка завершает активный движок, а процесс GMS, GPU и узел остаются исправными.
  4. Резервный или заменяющий движок берет управление на себя и подключается к уже находящимся в памяти весам GMS вместо полной повторной загрузки весов.
  5. Запросы в полете и состояние KV cache не сохраняются. Если потеряны GPU, узел или процесс GMS, заменяющий worker должен использовать обычный путь перепланирования и загрузки модели.

Когда использовать сейчас​

  • Используйте ее для оценки восстановления на том же узле после неизвестных отказов движка vLLM или программного процесса.
  • Используйте ее, когда нужно избежать загрузки еще одной независимой копии весов модели в память GPU.
  • Используйте примеры только с GMS для проверки загрузки весов backend через GMS, а не как полный workflow failover.
  • Не используйте ее для аппаратного отказа, потери GPU, потери узла, восстановления между узлами, восстановления запросов в полете или восстановления KV cache.
  • Не комбинируйте ее с восстановлением Snapshot. Snapshot вместе с GMS пока недоступен.

Сервис памяти GPU​

GMS переносит владение весами модели, находящимися в памяти GPU, из процесса движка в отдельный сервис памяти GPU. В workflow failover это позволяет активному и резервному движкам использовать одну и ту же границу памяти для весов вместо загрузки независимых копий.

Прямое включение GMS полезно для интеграционного тестирования backend и экспериментов с жизненным циклом в стиле sleep/wake. Само по себе оно не настраивает активное/пассивное failover; для потока shadow engine используйте поле failover.

Предварительные требования​

  • Kubernetes 1.34 или новее с включенным DRA v1 (resource.k8s.io/v1).
  • Установленный драйвер NVIDIA GPU DRA.
  • Соответствующий DRA DeviceClass, по умолчанию gpu.nvidia.com.
  • Поддерживаемый образ backend. Текущие примеры failover ориентированы на vLLM.
  • Поддержка загрузки из GMS в командной строке backend, например --load-format gms.
  • Достаточно памяти GPU для процессов GMS и активного или резервного движков, которые разделяют устройство.

Ограничения​

  • Это не общая система checkpoint/restore.
  • Это не механизм отказоустойчивости на случай потери GPU, узла или стойки.
  • Он не диагностирует и не исправляет отказ backend.
  • Он не сохраняет запросы в полете, сетевые сокеты или состояние KV cache.
  • Он не делает восстановление Snapshot поддерживаемым для нагрузок с памятью GPU.
  • Snapshot plus GMS временно блокируется на уровне admission из-за известных проблем с восстановлением драйвера GPU.
  • Пока функция находится под experimental, на нее не распространяются обычные гарантии совместимости v1beta1.

Расположение в API​

Для DynamoGraphDeployment v1alpha1 GMS и failover являются полями уровня service:

gpuMemoryService:
  enabled: true
failover:
  enabled: true

Для v1beta1 предварительные поля сгруппированы под experimental, чтобы явно показать контракт стабильности:

experimental:
  gpuMemoryService:
    mode: IntraPod
  failover:
    mode: IntraPod

См. справочник API для точной схемы, поддерживаемой вашей версией CRD.

Базовый пример Shadow Engine Failover​

Failover строится поверх GMS. В режиме intra-pod оператор клонирует основной контейнер worker в контейнеры активного и резервного движка, которые делят GPU через DRA и sidecar GMS. Резервный движок берет управление, когда активный движок выходит из строя.

apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeployment
metadata:
  name: vllm-agg-failover
  annotations:
    nvidia.com/dynamo-kube-discovery-mode: container
spec:
  services:
    VllmWorker:
      componentType: worker
      replicas: 1
      resources:
        limits:
          gpu: "2"
      gpuMemoryService:
        enabled: true
      failover:
        enabled: true
      extraPodSpec:
        mainContainer:
          image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:my-tag
          args:
            - --model
            - Qwen/Qwen3-0.6B
            - --tensor-parallel-size
            - "2"
            - --load-format
            - gms

Полный манифест см. в примере failover для vLLM .

Базовый пример GMS​

Worker должен запрашивать GPU через обычные ресурсы Dynamo service, включать gpuMemoryService и запускать команду backend, которая умеет загружать из GMS.

apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeployment
metadata:
  name: vllm-agg-gms
spec:
  services:
    VllmWorker:
      componentType: worker
      replicas: 1
      resources:
        limits:
          gpu: "1"
      gpuMemoryService:
        enabled: true
      extraPodSpec:
        mainContainer:
          image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:my-tag
          workingDir: /workspace/examples/backends/vllm
          command:
            - python3
            - -m
            - dynamo.vllm
          args:
            - --model
            - Qwen/Qwen3-0.6B
            - --load-format
            - gms

Рабочие примеры только с GMS:

Связанная документация​