Квантизация vLLM может позволить модели уместиться в меньшем объёме памяти GPU, но это не универсальный переключатель скорости. Меньший чекпоинт может оставить больше места для KV-кеша и параллельных запросов. Фактическая пропускная способность зависит от модели, формата квантизации, архитектуры GPU, ядра, длины промпта, длины вывода и характера трафика. Разумный подход — выбрать поддерживаемый формат, а затем измерить репрезентативную нагрузку в сравнении с неквантизованным базовым вариантом.
Это руководство по квантизации vLLM предлагает практический процесс выбора и тестирования. Оно не заявляет результаты бенчмарков для GPU или модели, которые мы не тестировали.
Что меняет квантизация vLLM
Квантизация хранит некоторые значения модели в меньшем числе битов, чем типичный чекпоинт FP16 или BF16. Наиболее очевидный эффект первого порядка — меньший объём памяти, занимаемый весами. Если память под веса не позволяет модели уместиться, совместимый квантизованный чекпоинт может позволить запустить её на GPU меньшего размера или оставить больше памяти для запросов. GPU всё равно требуется память для активаций, KV-кеша, накладных расходов среды выполнения и любых параллельных воркеров. Поэтому деление числа параметров на число битов на вес — лишь грубая нижняя граница, а не оценка памяти, достаточная для развёртывания.
Для квантизации vLLM есть два распространённых пути. Можно загрузить чекпоинт, квантизованный заранее, либо использовать поддерживаемый путь онлайн-квантизации при загрузке. В обоих случаях перед выбором формата изучите карточку модели и актуальную матрицу совместимости vLLM. Документация по квантизации vLLM является источником истины по методам и поддержке оборудования; в ней явно указано, что матрица меняется по мере развития поддержки.
Выбирайте формат по чекпоинту и GPU
| Вариант | Практическая отправная точка | Проверьте перед развёртыванием |
|---|---|---|
| AWQ | Модель, распространяемая как чекпоинт AWQ, и совместимый GPU | Качество модели, выбор ядра, длины промптов и фактическую задержку. |
| GPTQ | Модель, распространяемая как чекпоинт GPTQ | Точную конфигурацию чекпоинта, версию vLLM, поддержку GPU и деградацию качества. |
| FP8 | Совместимый чекпоинт и GPU с поддерживаемым выполнением FP8 | Поддерживает ли выбранная реализация vLLM вашу архитектуру и слои модели. |
| GGUF | Модель, уже распространяемая в формате GGUF | Конкретную архитектуру и поддержку функций vLLM; не предполагайте, что поведение Ollama отображается один к одному. |
| BitsAndBytes или сжатые тензоры | Чекпоинт и путь развёртывания, которые явно требуют их | Зависимости среды выполнения, поведение при загрузке, поддерживаемые ядра и пропускную способность. |
Текущая матрица vLLM указывает AWQ и GPTQ для Ampere, Ada и
Hopper. Она указывает FP8 через llm-compressor для Ada,
Hopper и некоторых путей AMD GPU, тогда как GGUF имеет другую схему
поддержки. A100 — это GPU Ampere, а H100 — GPU Hopper, но поддержка
зависит от метода. Не делайте вывод, что каждый вариант FP8, FP4 или Marlin
работает на каждой карте в семействе. Проверьте точную строку в таблице
совместимости оборудования и метаданные самого чекпоинта.
Если вы ещё не выбрали модель, сравните два кандидатных чекпоинта, использующих одну и ту же базовую модель и набор оценки. Сравнение модели AWQ из одного семейства с неквантизованной моделью из другого смешает квантизацию vLLM с качеством модели.
Рабочий процесс развёртывания, позволяющий избежать ложных улучшений
- Определите целевые показатели сервиса. Зафиксируйте модель, длину контекста, ожидаемые длины ввода и вывода, число параллельных запросов, целевую задержку p95 и тесты качества. У чат-бота, пакетного классификатора и агента с длинным контекстом разные узкие места.
- Зафиксируйте базовый вариант. Запустите неквантизованный чекпоинт на том же GPU и той же версии vLLM. Зафиксируйте пиковое потребление памяти GPU, время до первого token, пропускную способность по выходным токенам, сквозную задержку p50/p95, ошибки и долю принятых результатов.
- Выберите совместимый квантизованный чекпоинт. Прочитайте его карточку модели и актуальную матрицу методов vLLM. Зафиксируйте редакцию чекпоинта, версию vLLM, стек CUDA/драйверов и SKU оборудования в записи теста.
- Начните с небольшой канареечной проверки. Убедитесь, что модель загружается, обслуживает требуемый endpoint и настройки генерации, а также выдаёт правдоподобные результаты до подачи трафика.
- Проводите бенчмарки на нескольких уровнях параллелизма. Измеряйте при реальных для вас длинах промптов и ответов. Один запрос может отдавать предпочтение другой конфигурации, чем стабильное обслуживание.
- Запустите тот же набор тестов качества. Квантизация может изменить результаты. Оценивайте специфичную для предметной области корректность, соблюдение формата, отказы и случаи, чувствительные к безопасности, вместо того чтобы полагаться только на перплексию.
- Рассчитайте стоимость на принятый результат. Почасовой тариф GPU, поделённый на число необработанных токенов в секунду, недостаточен, если квантизованная модель проваливает больше задач или требует повторных попыток.
Для бенчмарка обслуживания vLLM документирует vllm bench serve
и его наборы данных и параметры endpoint в официальном
руководстве по CLI для бенчмарков. Используйте набор данных трафика, соответствующий вашему
приложению; синтетические случайные промпты полезны для контролируемых
сравнений, но их не следует выдавать за производительную производительность.
Планирование памяти: веса — лишь одна статья
Простой рабочий лист планирования разделяет четыре категории:
общий требуемый объём памяти GPU ≈ веса модели + KV-кэш + накладные расходы времени выполнения/активаций + запас памяти
Формат квантизации в основном изменяет объём, занимаемый весами модели. Нагрузка на KV-кэш растёт с длиной контекста и числом активных последовательностей. Модель, которая едва помещается при одном запросе, всё равно может не справиться или существенно замедлиться при одновременном трафике с длинным контекстом. В конфигурациях с несколькими GPU тензорный параллелизм меняет как объём памяти на каждую карту, так и накладные расходы на коммуникацию; минимально возможный чекпойнт не всегда обеспечивает самое дешёвое развёртывание.
Перед арендой GPU определите, нужно ли вам разместить одну более крупную модель, повысить параллелизм для меньшей модели или снизить стоимость, сохранив качество. От этого зависит, какой компромисс между памятью и пропускной способностью важнее. В сервисе Flatkey Cloud GPU Compute перечислены варианты аренды GPU, а клиентам предлагается подтвердить конфигурацию, регион, доступную мощность и условия аренды. Считайте актуальную доступность и цену входными данными на момент запроса коммерческого предложения, а не фиксированными значениями из статьи с бенчмарком.
Корректное бенчмаркинг-тестирование квантизации vLLM
Сохраняйте неизменными базовую модель, параметры генерации, набор промптов, ограничение на вывод, состояние кэша и GPU. Измеряйте как минимум три уровня нагрузки: один запрос для оценки отзывчивости, репрезентативную производственную параллельность и стрессовую точку, в которой задержка начинает ухудшаться. Указывайте как общую пропускную способность, так и задержку p95. Если сообщать только токены в секунду при насыщении, пользователи не смогут понять, остаются ли интерактивные запросы приемлемыми.
Включите качество модели в таблицу показателей:
| Показатель | Почему это важно |
|---|---|
| Пиковое потребление памяти GPU | Показывает, создаёт ли квантизация полезный запас памяти. |
| Время до первого токена | Важно для потоковых интерфейсов. |
| Выходных токенов в секунду | Показывает пропускную способность генерации, но не качество выполнения задачи. |
| Сквозная задержка p95 | Показывает поведение хвостовых задержек под нагрузкой. |
| Частота ошибок и OOM | Выявляет конфигурацию, которая выглядит быстрой только тогда, когда запросы выполняются успешно. |
| Доля принятых результатов | Преобразует исходную скорость в полезную работу. |
Ключевое сравнение для квантизации vLLM — не абстрактное «квантизированная против неквантизированной». Это «данный чекпойнт и ядро на данном GPU, при данной нагрузке, по сравнению с нашей базовой линией». Публикуйте условия вместе с любым результатом. Если в вашем тесте нет проверки качества, называйте его экспериментом только по производительности.
Распространённые режимы отказа
Модель не загружается. Проверьте метаданные чекпойнта, метод квантизации, версию vLLM, возможности GPU и то, поддерживает ли метод каждый слой, используемый архитектурой. Прежде чем вслепую менять флаги команд, следует проверить матрицу методов vLLM.
Экономия памяти не улучшила задержку. Меньший объём весов не гарантирует более быстрого ядра. Тестируйте при целевой параллельности и анализируйте время до первого токена, скорость декодирования и загрузку GPU. Настоящим преимуществом может быть больший запас для KV-кэша.
Низкобитный чекпойнт выглядит быстрым, но не проходит проверки качества. Поддерживайте производственный набор для проверки приемки и измеряйте процент результатов, которые соответствуют критериям вашего приложения. Порог отката следует установить до канареечного развёртывания.
Бенчмарк нельзя воспроизвести. Записывайте версии модели и чекпойнта, версии vLLM и драйвера, SKU GPU, набор данных, параллельность, длины промптов, длины выходных данных и аргументы команд. Без этого показатель пропускной способности — маркетинг, а не инженерное доказательство.
Когда использовать Flatkey Cloud GPU
Если вам нужно запустить собственный сервер vLLM и сравнить квантизированные чекпойнты, выбирайте мощность GPU на основе измеренных требований к памяти и параллельности. Flatkey предоставляет варианты аренды NVIDIA GPU через Cloud GPU Compute. Перед принятием обязательств подтвердите доступный SKU, регион развёртывания, доступную мощность, цены и условия обслуживания. Тест квантизации vLLM следует проводить на конфигурации, которую вы действительно планируете арендовать. Если вместо эксплуатации vLLM вам нужен управляемый API модели, отдельно оцените маршрут API и каталог моделей Flatkey; это другая операционная модель.
О смежных решениях по развёртыванию читайте в нашем руководстве по развёртыванию vLLM, руководстве по инференсу vLLM на нескольких GPU и сравнении vLLM и Ollama.
Часто задаваемые вопросы
Всегда ли квантизация vLLM ускоряет инференс?
Нет. Она может уменьшить объём памяти, занимаемый весами, но задержка и пропускная способность зависят от чекпойнта, ядра, GPU, длины последовательностей и нагрузки запросов. Сравнивайте реальную нагрузку с базовой линией.
Можно ли использовать AWQ на A100 или H100?
Текущая матрица совместимости vLLM указывает поддержку AWQ для Ampere и Hopper, к которым относятся A100 и H100. Перед развёртыванием проверьте точный чекпойнт, текущую версию vLLM и архитектуру модели.
Поддерживается ли FP8 на каждом GPU NVIDIA?
Нет. Поддержка зависит от реализации квантизации и архитектуры. Текущая матрица различает такие методы, как llm-compressor FP8 и Marlin; проверьте точную строку для вашего оборудования.
Следует квантизировать до или после выбора GPU?
Сначала определите размер рабочей нагрузки и целевой уровень качества, затем протестируйте подходящие чекпойнты на совместимых GPU. Выбор формата и оборудования следует оценивать совместно.
