Что такое FP8

FP8 (Float8) — формат чисел с плавающей точкой в 8 битах. В отличие от INT4/INT8 (целочисленная квантизация), FP8 сохраняет плавающую запятую: часть битов уходит под мантиссу, часть — под экспоненту. Это даёт больший динамический диапазон и плавность ошибок, чем целочисленная квантизация той же битности.

Два основных формата:

  • E4M3 (4 бита экспоненты, 3 мантиссы) — больше точность, меньший диапазон. Используется для весов и активаций в инференсе.
  • E5M2 (5 экспонент, 2 мантиссы) — больший диапазон, меньшая точность. Используется в обучении (градиенты).

Поддержка GPU

Критично: FP8-инференс требует аппаратной поддержки в Tensor Cores.

GPUАрхитектураНативный FP8
RTX 3090AmpereНет
RTX 4090AdaЧастично (через Tensor Cores, без полного pipeline)
A100AmpereНет
H100HopperДа (нативный, 2x против FP16)
B200BlackwellДа (расширенный)

На Ampere (3090, A100) аппаратного FP8-пути нет: значения либо эмулируются с потерей скорости, либо вовсе не поддерживаются. Поэтому на 3090 FP8 — не вариант, и там используется AWQ (INT4).

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

  • 2x экономия памяти против FP16 (8 бит против 16).
  • Нативная аппаратная поддержка на Hopper/Blackwell — Tensor Cores считают FP8 в 2 раза быстрее FP16.
  • Минимальная потеря качества: плавающая запятая сохраняет динамический диапазон лучше, чем INT8.
  • Ускорение вычислений через Tensor Cores (на поддерживающем железе).

FP8 против AWQ: что выбрать

КритерийFP8 (E4M3)AWQ (INT4)
Битность84
Память (27B)~27GB~14GB
Требуемое железоH100/B200любое
Потеря качестваминимальная< 1 BLEU point
Скорость2x (на H100)зависит от GPU

Правило выбора:

  • H100/B200 → FP8: 2x память + 2x скорость при почти нулевой потере. Если модель в FP16 влезает с запасом, FP8 — очевидный выбор.
  • 3090/4090/A100 → AWQ (INT4): FP8 недоступен, и 4 бита — единственный способ ужать 27B+ в доступную VRAM.
  • Гибрид: на H100 можно держать веса в FP8, а KV-cache в FP16/FP8 в зависимости от нагрузки.

Настройка в vLLM

vllm serve model --quantization fp8

Для online-квантизации (квантование на лету при загрузке модели) vLLM поддерживает --quantization fp8 для моделей, которые не были пред-квантованы. Для пред-квантованных FP8-моделей из Hugging Face формат определяется автоматически по quantization_config.

Что мы видели в референс-деплое

Честно: в нашем референс-деплое FP8 не используется — и это осознанное решение, а не упущение.

Наше железо — 3×(2×RTX 3090), Ampere. Нативного FP8 на 3090 нет, поэтому мы квантуем в AWQ (INT4). Если бы мы строили на H100, FP8 стал бы естественным выбором: 27B в FP8 (~27GB) влезает в одну H100 80GB с огромным запасом под KV-cache, и Tensor Cores дают 2x скорость.

Это важный урок: квантизация подбирается под железо, а не наоборот. На consumer-железе (Ampere/Ada) — AWQ; на datacenter Hopper/Blackwell — FP8. Смешивать их в одной стратегии нельзя, потому что они требуют разных архитектур.

Полный разбор выбора железа и квантизации — в части 1 (секция «Что НЕ работает») и части 2 серии «Наш опыт».

Когда FP8 не нужен

Частая ошибка — квантовать в FP8 «для порядка», даже когда это не даёт выигрыша. FP8 не нужен, когда:

  • Модель влезает в FP16 с запасом. Если 7B-модель в FP16 занимает 14GB из 80GB H100, FP8 не даст ощутимого выигрыша в capacity, а только усложнит pipeline.
  • Нужна максимальная точность. Для задач, где качество критично (медицина, юридические тексты), FP16 безопаснее, чем любая квантизация.
  • Железо не поддерживает FP8. На 3090/4090/A100 FP8 — эмуляция, которая медленнее FP16. Не используйте.

FP8 KV-cache

Отдельная тема — квантизация KV-cache в FP8 (не весов). Это даёт 2x экономию памяти на KV-cache, что позволяет держать больше параллельных запросов или больший контекст при том же VRAM.

vllm serve model --kv-cache-dtype fp8

Это особенно полезно на H100: веса в FP16 (максимальная точность), KV-cache в FP8 (экономия памяти). Потеря качества от FP8 KV-cache обычно меньше, чем от квантизации весов, потому что KV-значения имеют меньший динамический диапазон.

На consumer-железе FP8 KV-cache недоступен (нет аппаратной поддержки), поэтому на 3090/4090 KV-cache остаётся в FP16 — и именно поэтому 256K контекст «съедает» столько VRAM.

Как проверить качество FP8

После квантизации в FP8 обязательно сравните с FP16 baseline на eval-наборе:

  1. Программный eval: прогоните стандартный benchmark (MMLU, HellaSwag, или ваш внутренний набор) на FP16 и FP8, сравните scores. Для FP8 ожидаемая деградация — < 0.5% на большинстве задач.
  2. Ручная проверка: сгенерируйте ответы на 20–50 реальных промптов на FP16 и FP8, сравните качество. Ищите специфические деградации (галлюцинации, потеря формата, «заезженные» ответы).
  3. A/B на production: если есть возможность, направьте 5–10% трафика на FP8-реплику и сравните метрики (user satisfaction, error rate) с FP16.

Если деградация > 1% на eval или заметна вручную — вернитесь к FP16 или используйте FP8 только для KV-cache (не для весов).

Вывод

FP8 — лучший формат для H100/B200: 2x память, 2x скорость, минимальная потеря. Но на consumer-железе (3090/4090/A100) он недоступен, и там правильный выбор — AWQ. Не гонитесь за «самым новым форматом» — подбирайте квантизацию под архитектуру GPU, на которой реально будете гонять. И помните: FP8 KV-cache — отдельный рычаг экономии памяти, который стоит рассмотреть на Hopper.

Смежные материалы: AWQ, Tensor Parallelism, A100 vs RTX 4090.

← AWQ Multi-tenant Serving →