# vLLM FP8 KV-кеш: калибровка и проверка памяти и качества

Источник: https://modelium.tech/zhurnal/vllm-kv-cache-fp8/

FP8 KV-кеш в vLLM снижает точность хранения ключей и значений внимания, чтобы уменьшить их долю в памяти. Он не квантует автоматически веса модели и не гарантирует ускорение или сохранение качества. Сначала проверьте поддержку backend и калибровочные scales, затем сравните два запуска одной модели на одинаковых запросах.

**Документация vLLM проверена на Git-ревизии **`**f98d1fc**`** от 4 октября 2026 года.** Это процедура для вашего стенда, не результат прогона Modelium. Поддержка FP8 зависит от платформы, attention backend и модели; проверяйте фактический лог своего сервера [s1](#src-s1)[s3](#src-s3).

## Когда FP8 KV-кеш имеет смысл?

KV-кеш хранит промежуточные ключи и значения внимания для обрабатываемых токенов. В документации vLLM FP8 описан как способ уменьшить *эту часть* памяти и дать место большему числу токенов; это не автоматическая квантизация весов и не обещание, что вся занятая GPU-память сократится вдвое. Ёмкость сервера зависит также от весов, контекста, конкурентных последовательностей и других резервов [s1](#src-s1)[s2](#src-s2).

Выбирайте этот эксперимент, когда базовый сервер vLLM уже отвечает на запросы, а измерения указывают на нехватку ёмкости KV-кеша или частые preemption при вашей нагрузке. vLLM документирует preemption и пересчёт запросов при нехватке кеша; сначала проверьте, не помогает ли ограничение `max_model_len`, `max_num_seqs` или перераспределение бюджета GPU. FP8 не заменяет подбор модели и железа [s2](#src-s2)[s8](#src-s8).

Маршрут: задача с длинными запросами или параллельной генерацией → точный ID и ревизия текстовой модели → GPU и поддерживаемый attention backend → vLLM с исходным KV dtype → вариант FP8 → сравнение корректности ответов и задержки. Размер файла весов сам по себе **не** равен минимальному VRAM: перед выбором конфигурации смотрите реальные логи размещения модели и ёмкости кеша [s1](#src-s1)[s2](#src-s2).

## Что проверить перед сменой dtype?

Зафиксируйте версию vLLM, ID и ревизию модели, формат её весов, `--max-model-len`, `--max-num-seqs`, бюджет GPU, архитектуру карты и используемый attention backend. Для CUDA-установки vLLM описывает compute capability от 7.5, но это не гарантия поддержки каждого FP8-ядра и не минимальная память для вашей модели; сначала подтвердите успешный старт исходного сервера [s3](#src-s3)[s1](#src-s1).

Не смешивайте три разные операции: изменение формата **весов**, выбор dtype **KV-кеша** и калибровку **scales**. В документации KV-кеша режим `kv_cache_dtype="auto"` использует dtype модели, `fp8` — FP8 KV-cache с scales 1.0 без калибровки. Явные `fp8_e4m3` и `fp8_e5m2` имеют разные платформенные условия: для первого указаны CUDA 11.8+ и ROCm, для второго — CUDA 11.8+. Это перечень документированных опций, не свидетельство, что они заработают на любой карте [s1](#src-s1).

Есть две схемы масштабов: per-tensor и per-attention-head. Последняя по документации доступна только через Flash Attention backend и калибровку llm-compressor. Выбор `--kv-cache-dtype fp8` **сам по себе** не проводит калибровку на ваших документах. Для чувствительного сценария используйте репрезентативный датасет, проверенную совместимость модели с llm-compressor и его официальный путь подготовки scales; авторский пример квантует также attention и потому не является универсальным рецептом только для KV [s1](#src-s1).

## Как провести пробный запуск без неподтверждённого рецепта?

В отдельном тестовом окружении сначала установите vLLM по инструкции для вашей CUDA/ROCm-платформы и поднимите работающий baseline с фиксированным ID модели. Для CUDA документация рекомендует новое окружение и `uv pip install vllm --torch-backend=auto`; CUDA/PyTorch-несовместимость может требовать сборки из исходников. Не переносите эту команду на CPU или ROCm как универсальную [s3](#src-s3).

Остановите baseline, затем запустите **ту же модель и те же ограничения** с документированным аргументом `vllm serve <MODEL_ID> --kv-cache-dtype fp8`. Подставьте свой проверенный ID вместо `<MODEL_ID>`; это форма вызова из документации vLLM, а не команда, исполненная Modelium. Сначала оставьте сервер привязанным к доверенной среде. `/v1/chat/completions` требует модели с chat template; для неподходящей модели используйте поддерживаемый completion endpoint. Убедитесь по логам, что выставлен нужный KV dtype и модель запущена без ошибки backend; один HTTP 200 не доказывает экономию памяти [s1](#src-s1)[s6](#src-s6).

Для подготовки калиброванной версии следуйте pinned-документации llm-compressor: калибровочные тексты должны быть похожи на ваши входы, а на выходе должны сохраниться корректные scales в артефакте модели. В примере автора фигурируют Llama, Ultrachat и 512 образцов — это **иллюстрация процедуры**, не минимальный размер датасета, не рекомендация загружать закрытые данные в чужой сервис и не подтверждение качества русской речи. Если инструмент, модель или attention backend не совместимы с этим путём, не заявляйте о выполненной калибровке и оставьте baseline [s1](#src-s1).

## Как отделить экономию памяти от потери качества?

На обеих конфигурациях запишите одну и ту же ревизию модели, dtype и формат весов, GPU, sampling-параметры, длины контекста, количество одновременных запросов, версии CUDA/ROCm и vLLM. Сначала сравните запуск с базовым dtype и FP8 без калибровки, затем при необходимости — калиброванный FP8. Сохраните число доступных KV-блоков из логов, фактическое потребление GPU, ошибки и число preemptions. Если менялись веса или длины входа, эффект одного KV dtype из сравнения уже не выделить [s1](#src-s1)[s2](#src-s2)[s8](#src-s8).

Качество проверяйте по собственному обезличенному набору задач: факты с ожидаемым ответом, длинный контекст с проверяемой цитатой, структурированный вывод и отказ при недостатке данных. Сверяйте ответы с исходными документами, считайте ошибки отдельно от времени; одинаковый HTTP-статус не означает равное качество. Для скорости фиксируйте распределение длины входов и выходов, успешность, throughput, клиентские TTFT, ITL и TPOT. `vllm bench serve` документирует эти величины, но повторяемые запросы могут получить prefix-cache hit и исказить сравнение: сбрасывайте кеш или контролируйте seed и общий префикс [s4](#src-s4).

Метрики vLLM доступны через `/metrics` и показывают задержку и очереди, однако их нужно читать вместе с клиентским измерением и логами. Увеличение ёмкости KV-кеша **может** ослабить preemption в конкретном профиле нагрузки; утверждать рост скорости или сохранение точности без своего сравнения нельзя. Modelium таких измерений не проводил [s5](#src-s5)[s8](#src-s8).

## Когда отказаться и как вернуться к исходному серверу?

- **Ошибка FP8/backend:** сверяйте версию, GPU, CUDA/ROCm и attention backend; не заменяйте факт запуска картой совместимости другой схемы квантизации. Per-attention-head требует особого пути калибровки [s1](#src-s1)[s3](#src-s3).

- **Ответы хуже на ваших данных:** вернитесь к baseline или проверьте калибровку на релевантном датасете; сохраните примеры расхождений, не обещайте, что scales устранят каждый сбой [s1](#src-s1).

- **KV всё равно не помещается:** сократите контекст либо параллелизм и разберите логи preemption. Проблема может находиться в весах, других резервах или конфигурации, а не только в dtype кеша [s2](#src-s2)[s8](#src-s8).

- **Сервер нужен в закрытой сети:** `--api-key` защищает не каждый endpoint, в том числе `/invocations` остаётся вне этой защиты. Не публикуйте тестовый vLLM в интернет без сетевых правил и дополнительного шлюза [s6](#src-s6)[s7](#src-s7).

Для отката остановите тестовый экземпляр, верните сохранённую команду baseline без `--kv-cache-dtype fp8` и снова выполните контрольные запросы. Основной следующий шаг — [сравнить задержку на одинаковой нагрузке](/zhurnal/vllm-bench-serve/). Если память, качество или задержка не выигрывают по вашим критериям, оставьте исходную конфигурацию; выбор основывается на локальном результате, а не на общем обещании FP8 [s1](#src-s1)[s4](#src-s4).

## Источники

1. [vLLM: Quantized KV Cache](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/features/quantization/quantized_kvcache.md) — получено 2026-10-04
2. [vLLM: Conserving Memory](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/configuration/conserving_memory.md) — получено 2026-10-04
3. [vLLM: CUDA installation and hardware requirements](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/getting_started/installation/gpu.cuda.inc.md) — получено 2026-10-04
4. [vLLM: Benchmark CLI and latency definitions](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/benchmarking/cli.md) — получено 2026-10-04
5. [vLLM: Production Metrics](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/usage/metrics.md) — получено 2026-10-04
6. [vLLM: OpenAI-Compatible Server](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/serving/online_serving/openai_compatible_server.md) — получено 2026-10-04
7. [vLLM: Security and API authentication limits](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/usage/security.md) — получено 2026-10-04
8. [vLLM: Optimization and preemption](https://github.com/vllm-project/vllm/blob/f98d1fc49361cb50457f6109c3c01a5c77e415b4/docs/configuration/optimization.md) — получено 2026-10-04