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

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

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

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

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

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

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

Не смешивайте три разные операции: изменение формата весов, выбор 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.

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

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

В отдельном тестовом окружении сначала установите vLLM по инструкции для вашей CUDA/ROCm-платформы и поднимите работающий baseline с фиксированным ID модели. Для CUDA документация рекомендует новое окружение и uv pip install vllm --torch-backend=auto; CUDA/PyTorch-несовместимость может требовать сборки из исходников. Не переносите эту команду на CPU или ROCm как универсальную 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 не доказывает экономию памяти s1s6.

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

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

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

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

Метрики vLLM доступны через /metrics и показывают задержку и очереди, однако их нужно читать вместе с клиентским измерением и логами. Увеличение ёмкости KV-кеша может ослабить preemption в конкретном профиле нагрузки; утверждать рост скорости или сохранение точности без своего сравнения нельзя. Modelium таких измерений не проводил s5s8.

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

• Ошибка FP8/backend: сверяйте версию, GPU, CUDA/ROCm и attention backend; не заменяйте факт запуска картой совместимости другой схемы квантизации. Per-attention-head требует особого пути калибровки s1s3.
• Ответы хуже на ваших данных: вернитесь к baseline или проверьте калибровку на релевантном датасете; сохраните примеры расхождений, не обещайте, что scales устранят каждый сбой s1.
• KV всё равно не помещается: сократите контекст либо параллелизм и разберите логи preemption. Проблема может находиться в весах, других резервах или конфигурации, а не только в dtype кеша s2s8.
• Сервер нужен в закрытой сети: --api-key защищает не каждый endpoint, в том числе /invocations остаётся вне этой защиты. Не публикуйте тестовый vLLM в интернет без сетевых правил и дополнительного шлюза s6s7.

Для отката остановите тестовый экземпляр, верните сохранённую команду baseline без --kv-cache-dtype fp8 и снова выполните контрольные запросы. Основной следующий шаг — сравнить задержку на одинаковой нагрузке. Если память, качество или задержка не выигрывают по вашим критериям, оставьте исходную конфигурацию; выбор основывается на локальном результате, а не на общем обещании FP8 s1s4.