Когда вы отправляете запрос к большой языковой модели (LLM) через API, за кулисами происходит сложная работа по оптимизации ресурсов. Один из ключевых факторов, определяющих как стоимость вашего запроса, так и потенциальное качество ответа, — это точность, с которой хранятся веса модели. Сегодня вы можете встретить модели, обслуживаемые в форматах 16-бит (bf16/fp16), 8-бит (fp8) или даже 4-бит (fp4/int4). Но что на самом деле скрывается за этими цифрами? Снижает ли квантование интеллект модели или это просто маркетинговый ход для удешевления инфраструктуры?
В этой статье мы подробно разберем механику квантования больших языковых моделей, опираясь на данные, полученные в ходе масштабного исследования платформы OpenRouter. Мы проанализируем более 1400 конечных точек (endpoints) и провели серию строгих тестов на модели Qwen3.8 27B, чтобы понять, есть ли реальная разница в качестве ответов между fp8, fp4 и fp16, а также как эти параметры влияют на ваш бюджет. Если вы разрабатываете приложения на базе ИИ, понимание этих нюансов критически важно для баланса между производительностью и затратами.
01Что такое квантование LLM и зачем оно нужно?
Квантование (quantization) — это процесс преобразования весов нейронной сети из формата с высокой точностью (обычно 16-битного) в формат с меньшей точностью (8-битный, 4-битный или даже ниже). Большинство современных LLM обучаются и выпускаются в форматах BF16 (Brain Floating Point 16) или FP16 (Floating Point 16). Эти 16-битные форматы обеспечивают хороший баланс между диапазоном значений и детализацией чисел, но требуют значительных объемов видеопамяти (VRAM).
Суть квантования заключается в округлении весов модели до ближайшего значения, которое может быть представлено в меньшем формате. Например, FP8 уменьшает объем памяти, необходимый для хранения весов, вдвое по сравнению с FP16, а FP4 или INT4 — вчетверо. Это позволяет либо запустить более крупную модель на том же оборудовании, либо обслуживать больше запросов одновременно на той же видеокарте. Однако за экономию ресурсов приходится платить: округление приводит к потере части информации, заложенной в весах, что теоретически может снизить точность модели.
Важно понимать, что квантование затрагивает только веса модели. Во время работы модели также требуется память для кэш-буфера внимания (KV cache), где хранится состояние контекста для каждого токена. Поэтому общая потребность в памяти зависит не только от формата весов, но и от длины контекста запроса.
02FP8 против BF16: технические различия
Чтобы понять разницу между форматами, нужно заглянуть в структуру чисел с плавающей запятой. Биты распределяются между знаком числа, экспонентой (которая определяет диапазон значений) и мантиссой (которая определяет точность внутри этого диапазона).
Формат BF16 использует 1 бит для знака, 8 бит для экспоненты и 7 бит для мантиссы. Это дает ему тот же диапазон значений, что и 32-битный FP32, но с меньшей точностью. FP16, в свою очередь, делит 16 бит как 5 бит экспоненты и 10 бит мантиссы, обеспечивая более высокую точность, но меньший диапазон. Стандарт OCP 8-bit floating point определяет два формата FP8: E4M3 (4 бита экспоненты, 3 бита мантиссы) и E5M2 (5 бит экспоненты, 2 бита мантиссы). FP8 жертвует и диапазоном, и точностью, поэтому квантованные модели часто хранят масштабный коэффициент (scale factor) для каждого тензора или блока весов, чтобы минимизировать ошибки округления.
Для конечного пользователя API разница между FP8 и BF16 часто сводится к метке в ответе сервера и цене. Однако, как показали наши тесты, на практике эта разница в метке не всегда коррелирует с заметным падением качества ответов модели.
03Сколько качества теряется при использовании FP8 и FP4?
Это самый важный вопрос для разработчиков. Потеряет ли мое приложение в точности, если я переключусь на более дешевый 4-битный endpoint? Чтобы ответить на него, мы провели серию тестов на модели Qwen3.8 27B, используя шесть различных провайдеров, обслуживающих эту модель в разных форматах: Cerebras (FP16), Parasail, CoreWeave и AkashML (FP8), а также Darkbloom и ModelRun (FP4).
Мы запустили 280 задач с точными ответами, включая многошаговую арифметику с выводом промежуточных результатов, генерацию коротких и длинных фрагментов кода, сортировку списков чисел, поиск ключей в больших массивах (от 4 000 до 20 000 токенов) и цепочки логических выводов. Все запросы отправлялись с температурой 0 и отключенным режимом рассуждений (reasoning), чтобы исключить случайность.
Результаты оказались удивительно стабильными. Все шесть конечных точек показали результаты в диапазоне от 98,3% до 99,2%. Статистически значимой разницы между форматами FP8, FP4 и FP16 обнаружено не было. В большинстве семейств задач ни один формат не отставал от других: каждая конечная точка ошибалась максимум в двух задачах из 50, и эти ошибки были типичными «опечатками» модели, а не систематическими сбоями из-за квантования.
Единственное место, где проявилась небольшая разница, — это умножение многозначных чисел без вывода промежуточных шагов. Конечная точка Darkbloom (FP4) правильно решила 26 из 40 примеров, в то время как другие endpoints решили от 30 до 33. Однако статистический тест показал, что вероятность такого разрыва при отсутствии реальной разницы составляет около 7,5%, что не позволяет однозначно назвать это эффектом квантования. Ошибки были незначительными: медианное отклонение правильного ответа составляло менее 0,01%.
04Какие форматы точности предоставляют провайдеры API?
Анализ более 1455 конечных точек для 470 моделей показал, что FP8 является наиболее часто встречающейся помеченной точностью. Однако значительная часть провайдеров (59,5%) вообще не указывает формат точности в своих метаданных. Среди тех, кто указывает, FP8 занимает 23,6% рынка, FP4 — 8,5%, а BF16 — лишь 4,8%.
Интересно, что для большинства открытых моделей (open-weight) 8-битный или 4-битный форматы являются единственными помеченными опциями. Лишь 54 из 163 моделей с помеченными конечными точками имеют вариант с 16-битной точностью. Это означает, что для многих популярных моделей выбор между высокой и низкой точностью уже сделан провайдером, и пользователю остается только выбрать между FP8 и FP4.
05Делает ли квантование endpoint дешевле?
Общее правило гласит: чем ниже точность, тем дешевле запрос. И наши данные это подтверждают, но с важными исключениями. Мы сравнили самые дешевые endpoint для каждой точности, рассчитывая blended-цену (три входных токена к одному выходному).
Для 14 из 24 моделей, доступных в форматах 8-бит и 16-бит, 8-битный вариант был дешевле. Для 26 из 33 моделей, доступных в 4-бит и 8-бит, 4-битный вариант оказался дешевле. Однако есть исключения. Например, модель gpt-oss-120b у одного из провайдеров стоила дороже в 8-битном формате ($0.100), чем в 16-битном ($0.067). Аналогичная ситуация с MiniMax M3, где 4-битный вариант ($0.412) оказался дороже 8-битного ($0.388).
Важно отметить, что на цену больше влияет конкретный провайдер, чем формат точности. Разброс цен на один и тот же формат у разных провайдеров может быть огромным. Для Qwen3.8 27B в формате FP8 цены варьировались от $0.342 до $1.137 за миллион blended-токенов. Поэтому выбор самого дешевого endpoint, соответствующего вашим требованиям, может сэкономить значительные средства.
06Как выбрать нужную точность при настройке API?
Чтобы контролировать, в каком формате вы получаете ответы, используйте параметр provider.quantizations в ваших запросах к API. Это позволяет задать список форматов, которые вы готовы принять. Роутер OpenRouter затем выберет из доступных endpoint тот, который соответствует вашим критериям, предпочитая более дешевые варианты.
Например, чтобы разрешить использование только 8-битных и выше форматов, можно использовать следующий код на Python:
import os
import requests
response = requests.post(
"https://openrouter.ai/api/v1/chat/completions",
headers={
"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"
},
json={
"model": "qwen/qwen3.8-27b",
"messages": [{"role": "user", "content": "What is the capital of Australia? One word."}],
"reasoning": {"enabled": False},
"provider": {
"quantizations": ["fp8", "bf16", "fp16"]
},
},
timeout=120
)
data = response.json()
if "error" in data:
raise RuntimeError(data["error"])
print(data["provider"]["name"], data["choices"][0]["message"]["content"], f"${data['usage']['cost']:.6f}")В этом примере мы указали, что готовы принять FP8, BF16 или FP16. Роутер выберет наиболее подходящий endpoint из этих вариантов. Если вы укажете формат, который не поддерживается ни одним endpoint для данной модели (например, INT8 для Qwen3.8 27B), вы получите ошибку 404 с сообщением о том, что не найдено ни одной подходящей конечной точки.
:floor к названию модели (например, qwen/qwen3.8-27b:floor), чтобы роутер автоматически направлял запросы на самый дешевый доступный endpoint, соответствующий вашим фильтрам.07Частые проблемы с фильтрами точности
При настройке фильтров точности важно помнить, что фильтрация происходит до отправки запроса провайдеру. Если вы укажете слишком строгие условия, которые не соответствуют ни одному доступному endpoint, запрос будет отклонен мгновенно. Также обратите внимание, что если вы ограничиваете выбор одним endpoint (например, только Cerebras для FP16), и этот endpoint временно недоступен или находится в лимите запросов (rate limit), ваш запрос не сможет переключиться на резервный вариант, если не настроены fallback-механизмы.
Для улучшения качества ответов, особенно при использовании инструментов (tools), рекомендуется использовать суффикс :exacto. Он сортирует endpoint на основе сигналов качества, таких как скорость вызова инструментов и успешность выполнения задач, что может быть важнее, чем просто формат точности.
08Что это значит на практике
Результаты исследования OpenRouter показывают, что квантование до FP8 и даже FP4 не приводит к заметной потере качества для большинства задач, по крайней мере, на примере модели Qwen3.8 27B. Это открывает возможности для значительной экономии затрат на использование API, так как 4-битные и 8-битные endpoint часто стоят дешевле своих 16-битных аналогов.
Однако, не стоит слепо доверять меткам. Качество зависит не только от формата точности, но и от конкретного провайдера, его аппаратного обеспечения и программного обеспечения для инференса. Рекомендуется:
- Тестировать свои промпты на endpoint с разными форматами точности перед внедрением в продакшн.
- Использовать параметр
provider.quantizationsдля гибкого контроля над выбором формата. - Мониторить цены и доступность endpoint, так как они могут меняться.
- Рассматривать
:exactoдля задач, требующих высокой надежности вызова инструментов.
В конечном итоге, квантование — это мощный инструмент оптимизации, который при грамотном использовании позволяет получить отличные результаты от LLM без переплаты за избыточную точность, которая в большинстве случаев остается неиспользованной.
Источник: OpenRouter ↗