Перейти к содержанию

Запуск vLLM с offload в RAM

При работе с большими языковыми моделями одна из главных проблем — нехватка видеопамяти (VRAM). Даже для inference современные LLM могут требовать десятки гигабайт памяти, особенно при длинном контексте и большом числе одновременных запросов. Именно здесь в vLLM появляется механизм offload.

Offload в vLLM — это перенос части данных с GPU в оперативную память (CPU RAM), чтобы снизить использование VRAM. Проще говоря, vLLM решает задачу так: - всё, что нужно для быстрых вычислений — остаётся на GPU - всё, что используется реже — временно хранится в RAM

Это позволяет запускать модели, которые иначе не помещались бы в видеопамять.

Почему это особенно важно для vLLM

vLLM оптимизирован для высокопроизводительного inference и активно использует: - batching - paged attention - KV cache

Но именно KV cache становится главным потребителем памяти при: - длинных промптах - большом количестве пользователей - генерации длинных ответов

Offload позволяет вынести часть этого KV cache за пределы GPU.

Что именно offload’ится в vLLM

1. KV cache (основной сценарий)

KV cache — это ключи и значения attention для уже сгенерированных токенов. Он растёт линейно с длиной контекста и может занимать десятки гигабайт.

vLLM умеет: - хранить активные страницы KV cache на GPU - перемещать неактивные страницы в CPU RAM - при необходимости возвращать их обратно

Это и есть основной смысл offload в vLLM.

2. Offload весов модели (реже)

В некоторых конфигурациях часть весов модели может: - храниться в RAM - подгружаться на GPU по мере необходимости

Этот вариант используется реже, так как: - увеличивает latency - сильно зависит от скорости PCIe / NVLink

Как включается offload

Пример запуска сервера vLLM с offload в CPU:

vllm serve model-name \
  --cpu-offload-gb 16

Что это означает: - vLLM может использовать до 16 GB оперативной памяти - для хранения KV cache - тем самым снижая нагрузку на GPU

Дополнительно часто используют:

--gpu-memory-utilization 0.9

чтобы задать безопасный лимит использования VRAM.

Плюсы и минусы offload

Преимущества

  • можно запускать более крупные модели
  • меньше OOM ошибок
  • больше параллельных запросов
  • лучше подходит для long-context сценариев

Недостатки

  • увеличивается latency
  • производительность зависит от CPU и шины
  • не подходит для ultra-low-latency inference

Когда offload — хорошая идея

Offload отлично подходит, если: - у вас ограниченная VRAM - вы обслуживаете много пользователей - используете длинные контексты - важна стабильность, а не минимальная задержка

Плохо подходит, если:

  • нужен real-time отклик в миллисекундах
  • вы работаете с обучением модели

Пример запуска vLLM с CPU offload

Базовый вариант (KV cache offload в RAM)

vllm serve meta-llama/Llama-2-13b-chat-hf \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.9 \
  --cpu-offload-gb 16 \
  --max-model-len 4096

Что здесь происходит: - meta-llama/Llama-2-13b-chat-hf — модель - --gpu-memory-utilization 0.9 — vLLM использует до 90% VRAM - --cpu-offload-gb 16 — до 16 GB KV cache будет храниться в CPU RAM - --max-model-len 4096 — максимальная длина контекста - --tensor-parallel-size 1 — одна GPU

Пример для GPU с 24 GB VRAM (типичный кейс)

vllm serve meta-llama/Llama-2-13b-chat-hf \
  --gpu-memory-utilization 0.85 \
  --cpu-offload-gb 24 \
  --max-model-len 8192

Такой конфиг позволяет: - запустить 13B модель на 24 GB GPU - обслуживать длинные диалоги - избежать OOM при росте KV cache

Пример с несколькими GPU

vllm serve meta-llama/Llama-2-70b-chat-hf \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.9 \
  --cpu-offload-gb 64 \
  --max-model-len 4096

Проверка, что offload работает

В логах vLLM при старте обычно видно строки вида: 

Using CPU offload with 16 GB

И при нагрузке: 

KV cache pages evicted to CPU

Важные рекомендации - CPU RAM должна быть быстрой (DDR4/DDR5) - Желательно: - NVLink между GPU (если несколько) - современный CPU - Не ставь cpu-offload-gb больше доступной RAM

Использование enable-cpu-offload

--enable-cpu-offload и --cpu-offload-gb — это разные уровни контроля над одним и тем же механизмом, и они решают разные задачи.

Главное отличие | Флаг | Что делает | |------|---------------| | --enable-cpu-offload | Просто включает возможность offload | | --cpu-offload-gb | Включает offload и задаёт лимит RAM в гигабайтах |

--enable-cpu-offload

Что это такое

Это булевый флаг:

--enable-cpu-offload

Он говорит vLLM:

«Можно переносить KV cache на CPU, если потребуется»

Но: - лимит RAM не задан - vLLM сам решает, сколько памяти использовать - поведение более автоматическое и менее предсказуемое

Когда используют - для быстрого теста - когда RAM много и не жалко - в экспериментальных конфигурациях

--cpu-offload-gb

Что это такое

--cpu-offload-gb 16

Это: - явное включение CPU offload - жёсткий верхний предел RAM - более безопасно для production

vLLM не выйдет за указанный лимит, даже если нагрузка растёт.

Важный момент: совместимость В актуальных версиях vLLM: - если указан --cpu-offload-gb - --enable-cpu-offload не нужен - --cpu-offload-gb считается предпочтительным способом

Флаг --enable-cpu-offload существует в основном: - для обратной совместимости - или внутренних экспериментов

Итог

--enable-cpu-offload - ✔ включает offload - ✖ не контролирует память

--cpu-offload-gb - ✔ включает offload - ✔ задаёт лимит RAM - ✔ рекомендуется для production

Пример использования enable-cpu-offload

Скачайте модель командой:

huggingface-cli download TheBloke/Llama-2-70B-AWQ --local-dir llama70b-awq

Запуск vLLM с offload в RAM

python -m vllm.entrypoints.api_server \
  --model ./llama70b-awq \
  --device cuda \
  --enable-cpu-offload

Что делает --enable-cpu-offload ?

  • vLLM автоматически переносит на CPU те веса, которые не помещаются в VRAM.
  • Вам не нужно указывать сколько — он сам распределяет слои.
  • Использует память RAM и шину PCIe для подкачки.

Настройки, которые улучшают работу с offload

Чтобы использовать почти всю VRAM, но не выйти за пределы:

--gpu-memory-utilization 0.95

Полная команда:

python -m vllm.entrypoints.api_server \
  --model ./llama70b-awq \
  --device cuda \
  --enable-cpu-offload \
  --gpu-memory-utilization 0.95

Настройки для длинного контекста (KV-cache может лежать в RAM)

--max-model-len 32768
--cpu-kv-cache

Пример:

python -m vllm.entrypoints.api_server \
  --model ./llama70b-awq \
  --device cuda \
  --enable-cpu-offload \
  --cpu-kv-cache \
  --gpu-memory-utilization 0.95 \
  --max-model-len 32768

Дополнительный контроль нагрузки на GPU

Если хотите жёстко ограничить VRAM, например 30GB из 40GB:

--limit-gpu-memory 30GiB

Пример:

python -m vllm.entrypoints.api_server \
  --model ./llama70b-awq \
  --device cuda \
  --enable-cpu-offload \
  --cpu-kv-cache \
  --limit-gpu-memory 30GiB

Итог

Полный рабочий пример для A100 40GB:

python -m vllm.entrypoints.api_server \
  --model ./llama70b-awq \
  --device cuda \
  --enable-cpu-offload \
  --cpu-kv-cache \
  --gpu-memory-utilization 0.95 \
  --max-model-len 32768