16-битные форматы сокращают память весов модели вдвое без смены архитектуры

У одной и той же модели на 7 млрд параметров веса могут занимать примерно 28 ГБ в FP32, 14 ГБ в FP16 или BF16 и 7 ГБ при восьми битах. Архитектура при этом не меняется — меняется способ хранения чисел. Выгода кажется очевидной: меньше памяти, меньше данных приходится гонять между памятью и вычислительными блоками, значит модель должна отвечать быстрее.

Но именно на этом месте обычно и начинается путаница. Меньше битов не гарантирует ускорение. Если процессор или видеокарта не умеют эффективно выполнять операции в выбранном формате, среда добавит преобразования, переключится на медленное ядро или вообще завершит вычисление ошибкой. А слишком узкий диапазон значений способен превратить крупную активацию в бесконечность или потерять небольшие различия между числами.

FP16 и BF16 решают разные задачи

Число с плавающей точкой хранит знак, порядок и значащую часть. Порядок отвечает за диапазон величин, а значащая часть — за способность различать близкие значения. При уменьшении числа битов приходится выбирать, чем пожертвовать.

FP16 выделяет больше места под значащую часть, поэтому точнее различает соседние числа. Но диапазон у него сравнительно узкий: крупные значения в активациях могут вызвать переполнение. BF16 хранит столько же битов порядка, сколько FP32, поэтому выдерживает гораздо более крупные и малые величины. Цена — меньшая точность для близких значений.

Представим слой, который получает значения 1,001 и 1,002, а позже сталкивается с активацией 100 000. FP16 лучше сохранит разницу между первыми двумя числами, но рискует не справиться с большим значением. BF16 легче переживёт выброс, однако может округлить близкие числа одинаково. Какой вариант лучше, определяют модель, данные и оборудование, а не название формата.

Есть и ещё одна деталь: тип сохранённых весов не раскрывает всей картины. Умножение матриц может читать FP16, накапливать сумму в FP32 и записывать результат обратно в FP16. Поэтому в отчёте о производительности важно указывать точность входов, накопления и выхода.

Смешанная точность страхует чувствительные операции

Модель необязательно целиком переводить в один формат. Матричные умножения можно выполнять в FP16 или BF16, а нормализацию, softmax, сокращения и отдельные слои оставить в FP32. Такой режим сохраняет ускорение на самых тяжёлых операциях и снижает риск численных ошибок.

Однако ручное переключение типов тоже не бесплатно. Лишние преобразования расходуют время, а несовпадение типов входа и весов иногда ломает выполнение. Для готовой модели разумнее сначала использовать поддерживаемый её библиотекой режим смешанной точности, затем проверить профилировщик и только после этого менять отдельные слои.

Загружать крупный чекпойнт лучше сразу в целевом формате. Если сначала разместить FP32-версию, а потом преобразовать её в FP16, на короткое время понадобится память под обе копии. Для большой модели этого достаточно, чтобы получить ошибку нехватки памяти ещё до первого запроса.

Что измерять перед запуском

Сравнивать форматы нужно по трём направлениям. Первое — память: размер весов, пиковое потребление, KV-кеш и временные буферы. Второе — скорость: отдельно задержка обработки входного контекста, генерации токенов и общая пропускная способность при реальных размерах пакета. Третье — качество: перплексия, прикладные метрики и ответы на репрезентативных запросах.

Одного совпавшего текста недостаточно. При жадном выборе токенов ответы могут выглядеть одинаково, хотя распределения вероятностей уже заметно разошлись. Для поиска проблем полезно сравнивать логиты, особенно возле решений, где два токена имеют почти равные оценки.

Практический вывод простой: начните с FP32 как численного ориентира, испытайте FP16 и BF16 на целевом железе, прогрейте модель и синхронизируйте устройство перед замерами. Затем выберите самый компактный формат, который сохраняет требуемое качество и действительно ускоряется на вашем оборудовании. Оптимальная точность — не минимальное число битов, а измеренный баланс памяти, скорости и надёжности.