ТЕХНОЛОГИИ

FP8 и FP4 GEMM в SGLang: как проверить совместимость ядра и checkpoint

В этом материале
ГЛАВНОЕ ЗА МИНУТУ

Совместимость FP8 или FP4 в SGLang проверяют по сочетанию checkpoint, scaling recipe, GPU architecture и GEMM backend.

Совместимость FP8 или FP4 в SGLang проверяют по сочетанию checkpoint, scaling recipe, GPU architecture и GEMM backend. Название формата само по себе недостаточно. Один runtime может иметь несколько вычислительных путей для похожих весов. До измерения скорости установите, какой путь действительно выбран и соответствует ли он metadata модели. Attention backend проверяется отдельно: он не заменяет матрицу совместимости операций с квантованными весами.

Начните с артефакта

Offline quantized checkpoint содержит сведения о примененном методе и представлении весов. Руководство SGLang по quantization описывает чтение соответствующей конфигурации и отдельные GEMM варианты. Не добавляйте quantization flag только потому, что он присутствовал в другом примере: runtime может уже распознавать формат из артефакта. Сначала сохраните config и revision, затем сравните их с требованиями конкретной реализации. Принудительная настройка, противоречащая файлам, не является способом автоматически преобразовать checkpoint в другой рецепт.

Проверьте GPU и зависимости

Для выбранного GEMM сопоставьте compute capability, поддерживаемую форму scaling и требования к библиотекам либо JIT. Не сводите совместимость к объему VRAM: достаточно памяти не означает наличие подходящего ядра. Сохраните версию движка и доступных компонентов. Если backend отсутствует, различайте неподдерживаемое оборудование и недостающую зависимость сборки. Решения различаются: одно сочетание может быть принципиально недопустимо в проверяемом релизе, другое требует корректной установки предусмотренного компонента, без изменения самой модели.

Разделите GEMM и attention

Документация attention backend описывает отдельный выбор реализации attention. Успешный запуск этой части не доказывает правильность квантованных matrix multiplications, и наоборот. В карточке запуска сделайте две строки: weight GEMM и attention. Для каждой укажите requested, selected и основание совместимости. Если приложение использует quantized KV, добавьте третью независимую строку. Такой разбор предотвращает ситуацию, когда исправление одного слоя ошибочно объявляют поддержкой всех форм низкой точности в модели.

Пример диагностической карточки

Для одного checkpoint запишите quantization metadata, SM, GEMM selection, attention selection и результат короткого функционального запроса. Затем проверьте явный неподходящий выбор только в изолированном тесте, если это нужно для диагностики. Ожидаемое поведение должно быть понятным отказом, а не молчаливой сменой смысла весов. Таблица не содержит готовых измерений throughput: такие значения появляются лишь после отдельной серии с фиксированными prompts, длинами ответов и concurrency. Сравнивать разные рецепты по одному имени FP8 недостаточно.

Приемка обновления

Повторяйте карточку после изменения runtime или GPU placement. Сохраняйте журнал выбранных kernels и fixture ответа, чтобы отличить несовместимость от регрессии качества. Если доступен альтернативный backend, его нужно проверить отдельно, а не считать эквивалентным по умолчанию. Указывайте ограничения конкретной версии и не распространяйте поддержку одной архитектуры на все видеокарты того же производителя. Итог — проверяемый маршрут вычислений от metadata до реально выбранной реализации. Он объясняет, почему модель может запускаться на одном узле и отклоняться на другом при одинаковом размере VRAM, и позволяет обсуждать измерения только после подтверждения корректного исполнения, без выдуманного обещания, что любой низкобитный формат обязательно окажется быстрее.

Связанные материалы

Квантизация LLM: как проверить качество перед выбором GPU; vLLM quantization: как согласовать веса, формат и GPU.

← Все материалы