vLLM и Qwen3.6-27B: квантование и бэкенды меняют ответы модели
Автор поста на форуме Level1Techs (обсуждение подхватили на Hacker News) поставил серию контролируемых экспериментов, чтобы показать: даже при одних и тех же весах модели разные комбинации железа и программного стека инференса дают разный результат, потому что разные GPU и наборы инструкций по-разному считают одну и ту же математику. Для проверки использовался официальный BF16-чекпоинт Qwen3.6-27B (плотная, но гибридная модель: 64 слоя, из которых чередуются три слоя Gated DeltaNet/линейного внимания и один слой полного внимания; выбираемый бэкенд внимания задействуют только эти 16 слоёв полного внимания) на GPU RTX PRO 6000 Blackwell, с закреплённой ночной сборкой vLLM. Автор отдельно отмечает, что в контейнере vLLM он насчитал 734 пакета (252 из них, Python-пакеты через uv/pip), то есть 734 отдельных кодовых базы со своими багами.
Тест 1 сравнивал три бэкенда полного внимания в vLLM, FlashAttention 2, FlashInfer и Triton Attention, на реальном промпте примерно в 100 тысяч токенов (эпизод работы агента с несколькими вызовами инструментов, специально выбранный так, чтобы не пересекаться ни с одним публичным бенчмарком). Логиты по всему словарю снимались каждые 32 токена, затем в FP64 считалась дивергенция Кульбака-Лейблера (KLD) и совпадение «топ-1»-токена (жадный выбор) относительно бэкенда Triton, взятого за базовую линию. На первых нескольких тысячах токенов все три бэкенда сходились в выборе следующего токена; дальше в промпте начали появляться расхождения, не плавно нарастающие с длиной контекста, а кластерами, привязанными к содержанию конкретного участка текста. Контрольный прогон одного и того же бэкенда несколько раз подряд дал побитно идентичные логиты, то есть расхождение не случайный шум, а детерминированный эффект от того, как именно операции умножения и сложения матриц реализованы в ядрах trt/fa2/fi на этапе предзаполнения контекста (prefill).
Тест 2 проверял квантование только KV-кэша при неизменных BF16-весах: расхождения в топ-токенах во время вызовов инструментов накопились настолько, что автор довёл диалог до конца и получил воспроизводимую ошибку вызова инструмента. При BF16-кэше проблемы не было; при int8-кэше модель в итоге восстанавливалась и справлялась с задачей; при int4-кэше, нет, ошибка так и осталась невосстановленной. Заголовок этого раздела у автора шуточный («почему IQ вашей LLM падает как камень после 40 тысяч токенов»), это авторская подача темы, а не отдельно измеренный порог с конкретными цифрами.
Тест 3 сравнивает уже квантование весов: помимо эталонного BF16, официальный FP8-чекпоинт, неофициальный INT8 (схема W8A16, квантуются только веса, активации остаются в BF16), NVIDIA NVFP4 (смешанный чекпоинт: 208 целей квантуются в FP8 W8A8, это 64 проекции полного внимания и 144 проекции Gated DeltaNet, и отдельно 193 цели квантуются в NVFP4 W4A16, 192 проекции MLP плюс lm_head, размер группы 16) и AWQ W4A16. Для каждого варианта используется свой набор CUDA-ядер: FP8-чекпоинт идёт через CUTLASS, потому что vLLM автоматически отключил DeepGemm, формат масштабирования E8M0 в этом чекпоинте помечен как снижающий точность именно на этой архитектуре GPU (SM120); откалиброванного набора данных для этого чекпоинта в опубликованных файлах не нашлось. INT8-вариант квантован «в один проход» тоже без калибровочных данных, но благодаря тому, что активации и проекции Gated DeltaNet/lm_head оставлены не квантованными, его точность оказалась заметно выше ожидаемой. Для NVFP4-чекпоинта на использованном GPU не нашлось нативной поддержки FP4-арифметики, поэтому vLLM выбрал вместо неё квантование только весов через ядро Marlin. На этом сохранённый текст обрывается на полуслове внутри описания NVFP4-чекпоинта, конкретных цифр точности или выводов по Тесту 3 в тексте нет.
Ключевые факты
- Ночной контейнер vLLM, который проверял автор, содержит 734 пакета (252 из них, Python-пакеты через uv/pip), то есть множество независимых кодовых баз внутри одного инференс-стека.
- Тест 1: три бэкенда внимания vLLM (FlashAttention 2, FlashInfer, Triton) на реальном промпте в ~100 тыс. токенов расходятся в выборе следующего токена, расхождения появляются кластерами по содержанию, а не линейно растут с длиной контекста; повторные прогоны одного бэкенда дают побитно идентичные логиты, значит расхождение детерминировано, а не шум.
- Тест 2: при квантовании только KV-кэша до int4 автор получил воспроизводимую ошибку вызова инструмента, которая не восстанавливалась; при int8 модель в итоге справлялась, при BF16 проблем не было.
- Тест 3 сравнивает пять схем квантования весов (BF16, официальный FP8, неофициальный INT8 W8A16, NVIDIA NVFP4, AWQ W4A16), у каждой свой путь ядер GEMM; для FP8-чекпоинта в опубликованных файлах не нашлось калибровочных данных, а vLLM на использованном GPU отключил DeepGemm ради точности; сохранённый текст обрывается до того, как в нём приведены итоговые цифры точности.
Почему это важно
Пост даёт техническое объяснение расхожей жалобе «локальная модель тупее, чем в облаке/на бенчмарке разработчика»: даже при полностью совпадающих весах разные бэкенды внимания и схемы квантования KV-кэша и весов физически по-разному считают умножение и сложение матриц на разном железе, и это меняет, какой именно токен модель выберет следующим. Автор экспериментально показывает, что это не случайный шум (повторные прогоны одного и того же бэкенда дают побитно идентичные логиты), а системный, воспроизводимый эффект конкретной комбинации железа, бэкенда и типа квантования.
Кому это важно
В первую очередь, людям, которые сами разворачивают LLM локально или на своём сервере через инференс-движки вроде vLLM (домашние лаборатории, инженеры self-hosted инфраструктуры), особенно если рабочая нагрузка, это агентные сценарии с вызовом инструментов и длинным контекстом, где, как показывает Тест 2, накопленные расхождения токенов способны сломать вызов инструмента целиком.
Как это применить
Практические выводы из текста: проверять модель на бенчмарках, близких к своей реальной нагрузке (агентные задачи с вызовом инструментов и длинным контекстом), а не на паре тестовых промптов при температуре ноль; относиться настороженно к громким заявлениям о низком значении KLD на карточке квантованной модели, если автор не раскрыл полную методологию измерения (эталонный чекпоинт, окружение, данные калибровки, направление KLD и способ агрегации); при квантовании KV-кэша для длинных контекстов и вызовов инструментов учитывать, что агрессивное сжатие (в тексте, int4) может давать невосстановимые ошибки, тогда как менее агрессивное (int8) в описанном случае восстанавливалось; и что схема квантования весов (например, W8A16 с оставленными в BF16 активациями и отдельными проекциями) заметно влияет на итоговую точность отдельно от самого факта «модель квантована».
Можно ли доверять
Методология описана подробно и прозрачно: указаны конкретная модель (Qwen3.6-27B), GPU (RTX PRO 6000 Blackwell), закреплённая сборка vLLM, отключённые CUDA-графы и префиксное кэширование, а тестовый промпт специально взят из реальной рабочей сессии, чтобы избежать утечки в обучающие данные или бенчмарки. При этом сохранённый в источнике текст обрывается на середине описания Теста 3, до того как в нём приведены итоговые цифры точности или общий вывод по сравнению схем квантования весов, эту часть материала по имеющемуся тексту проверить и пересказать нельзя. У самого поста также нигде не указан автор (текст ведётся от первого лица без подписи); пользователь Hacker News, через которого новость попала в обсуждение, автором статьи не является.
Риски и подводные камни
Главный риск, о котором явно предупреждает сам автор, интерпретировать одно вырванное из контекста число (низкое значение KLD на карточке модели) как доказательство качества квантования без знания полной методологии измерения: без раскрытых деталей такое число невозможно корректно истолковать. Отдельный риск для практиков, считать любое квантование KV-кэша одинаково безопасным: в описанном эксперименте именно агрессивное int4-сжатие кэша привело к невосстановимой ошибке вызова инструмента. Также стоит учитывать разговорный, местами шутливый тон поста (автор сам называет часть материала упрощением и иронично комментирует происходящее), это стиль изложения технического разбора, а не намёк на то, что описанные эксперименты не были проведены всерьёз.
«Математика есть математика!»
— @wendell, цитата внутри поста автора