Никита, системный архитектор Selectel, взял выделенный сервер GL8-B300-HGX-25GE на базе NVIDIA HGX B300 и последовательно развернул на нём четыре крупные языковые модели: DeepSeek R1, DeepSeek V3.2, Minimax M2.5 и Qwen 3.5 397B. Цель — понять, как ведёт себя почти топовое серверное железо при реальной нагрузке и стоит ли переходить на новый формат квантизации NVFP4.
HGX B300 — модульная платформа NVIDIA для сборки вычислительных узлов в дата-центрах, в отличие от готового решения DGX. В конфигурации Selectel установлено восемь карт B300 на архитектуре Blackwell: суммарно 2,3 ТБ VRAM и 192 петафлопс в режиме FP4. Ключевое отличие Blackwell от предыдущих поколений — аппаратная поддержка формата NVFP4 наряду с привычными BF16 и FP8.
| Формат | Бит на параметр | Ускорение относительно BF16 | Особенности |
|---|---|---|---|
| BF16 | 16 | ×1 (базовый) | Стандарт для обучения и дообучения |
| FP8 | 8 | ≈×2 | Часть слоёв остаётся в BF16 (например, в DeepSeek) |
| NVFP4 | 4 | ≈×4 | Блочное хранение с масштабными коэффициентами; потеря точности до 1% vs FP8 |
Чтобы понять, зачем вообще нужны разные форматы, стоит разобраться в узком месте инференса. Скорость генерации текста упирается не в количество вычислительных блоков GPU, а в пропускную способность видеопамяти. Чем компактнее представлены веса модели, тем быстрее они перемещаются между памятью и вычислительными ядрами. BF16 — 16 бит на параметр, стандарт для большинства современных моделей. FP8 вдвое компактнее и ускоряет инференс примерно в два раза относительно BF16. NVFP4 идёт ещё дальше: 4 бита на параметр, прирост производительности — ещё в 1,8 раза относительно FP8, то есть почти в четыре раза быстрее базового BF16. При этом NVIDIA заявляет о потере точности не более 1% по сравнению с FP8. Механизм компенсации — блочное хранение с масштабными коэффициентами, которые позволяют восстанавливать точность до уровня FP8 прямо в процессе вычислений. Схожий принцип используют форматы MXFP и GGUF.
NVFP4 ускоряет инференс примерно в 1,8 раза относительно FP8 и почти в 4 раза относительно BF16.
Для тестов выбран инференс-сервер vLLM версии 0.16.0. Альтернативы отпали по практическим причинам: sglang нестабильно работал под нагрузкой и падал, llama.cpp заметно проигрывал по скорости на этапе prefill — обработки входного запроса. Prefill нагружает вычислительные блоки GPU, тогда как decode — генерация ответа — упирается именно в пропускную способность памяти.
Из четырёх протестированных моделей DeepSeek R1 выступил базовой точкой отсчёта: модель хорошо поддерживается в vLLM и широко известна. DeepSeek V3.2 на момент развёртывания была актуальной версией с механизмом разреженного внимания (Sparse Attention), который ускоряет prefill на длинных контекстах. Minimax M2.5 с 229 млрд параметров оказался неожиданно силён в задачах кодинга — при том что по размеру уступает конкурентам. Qwen 3.5 397B от Alibaba — новая версия модели, предыдущее поколение (235B) уже используется в части внутренних задач Selectel.
Два кандидата в тест не попали. Kimi K2 — крупнейшая из рассматривавшихся моделей — не поместилась на доступные диски: сервер стоял без штатных накопителей, а времени на подключение подходящих не осталось. GLM 5 запустить удалось, но подобрать параметры, при которых модель выдаёт связные ответы, а не мусор, не получилось — проблема, по всей видимости, в поддержке со стороны текущей версии vLLM.
Параллельно с ростом производительности железа отрасль активно работает над сокращением потребления памяти на уровне алгоритмов. Для уменьшения KV-кэша — структуры, хранящей контекст диалога, — применяются разреженное внимание и MLA (Multi-Head Latent Attention). Google недавно опубликовала статью о методе Turbo Quant, который снижает потребление памяти KV-кэшем в 4–8 раз за счёт новой схемы квантизации. Всё это означает, что даже при фиксированном объёме VRAM модели будут становиться быстрее и дешевле в эксплуатации.
