В этом материале
Разделение точности KV-кэша и весов, проверка backend и масштабов, оценка длинного контекста до увеличения числа одновременных запросов.
FP8 KV caching меняет представление ключей и значений attention, сохраняемых при инференсе. Оно независимо от низкой точности весов модели: можно изменить одно, оставив другое прежним. Это различие важно при оценке экономии памяти и поиске причин ухудшения ответов на длинных запросах. Слова «модель FP8» сами по себе не описывают точность всех её состояний во время исполнения.
Определите сжимаемое состояние
Разделите в отчёте память весов, KV-блоков attention, другого состояния архитектуры и рабочих буферов. Снижение числа байтов на элемент KV не уменьшает вдвое весь объём памяти сервера. Гибридные архитектуры также могут хранить состояние, не соответствующее обычному формату attention-кэша.
Справочник конфигурации кэша vLLM показывает варианты dtype, автоматическое поведение которых зависит от модели и релиза. Проверяйте фактически выбранную конфигурацию, не предполагая одинаковую начальную точность и одинаковые преобразования во всех развёртываниях без дополнительных настроек.
Проверьте backend и масштабы
Отправная точка для выбранного релиза — актуальная документация квантованного KV-кэша. Вместе проверяйте архитектуру GPU, attention backend, детализацию масштабов и поддерживаемые метаданные чекпойнта. Распознанный параметр запуска ещё не доказывает использование нужного вычислительного пути.
Для воспроизводимой ссылки руководство vLLM v0.25.0 различает калибровку и обработку масштабов. Эти детали привязаны к версии. Перенос рецепта в новый образ требует подтверждения, что путь квантования и архитектура модели по-прежнему соответствуют документированным предпосылкам, а не только позволяют запустить процесс.
Подготовьте корпус калибровки
Если калибровка требуется или поддерживается, используйте текст с ожидаемыми языками, длинами входа и типами задач. Короткий английский чат плохо представляет многоязычный сервис с длинными техническими документами. Отделите проверочный набор, чтобы примеры калибровки не стали единственным материалом оценки качества.
Запишите ревизию источника, предварительную обработку, полученные масштабы и точный способ загрузки. Неизменённые значения по умолчанию могут быть допустимой экспериментальной базой, но они не подтверждают пригодность масштабов для конкретной модели. Считайте артефакты калибровки частью релиза с собственным происхождением и процедурой восстановления.
Проверьте качество до роста ёмкости
Сравните исходный dtype и FP8 при одинаковых весах, токенизации и параметрах генерации. Включите поиск свидетельств в далёких частях входа, извлечение по ограничениям и вопросы, где существенна небольшая числовая или фактическая ошибка. Отделяйте потерю свидетельства от нарушения формата ответа.
В том же эксперименте измерьте память и поведение первого токена. Только затем увеличивайте число одновременных запросов, проверяя пределы задержки. Одновременная смена точности и нагрузки мешает понять, вызвано ухудшение численным представлением или насыщением сервера.
Сформулируйте ограниченный вывод
Укажите проверенные архитектуру, backend, процедуру масштабирования, распределение контекста и качество задач. Опишите изменившиеся компоненты памяти. Не обещайте универсальную эквивалентность FP8 или превращение номинальной экономии байтов в такой же рост полезной производительности.
Сохраните прежнюю конфигурацию точности для сравнения и отката. Уменьшенный кэш полезен, когда весь сервис сохраняет приемлемые ответы на своей нагрузке, а не только когда счётчик памяти сдвигается в желаемую сторону.
Материалы по теме
KV-кеш и экономика GPU: зачем считать память активных запросов, Квантизация LLM: как проверить качество перед выбором GPU.