Мифы о том, что FP8 — это "почти как FP16, только быстрее", разбиваются о реальность. Но не в этот раз.
Когда в конце июня 2026 года команда GLM выпустила 5.2, все бросились запускать бенчмарки. Оригинальная модель в FP16 показала на Terminal-Bench 2.1 результат выше 80% — первая открытая модель, перешагнувшая этот порог. Но мало кто поверил, что FP8-версия способна хотя бы приблизиться к этим цифрам без катастрофической потери точности.
Мы взяли H200, поставили sglang (последний коммит от 5 июля), загрузили GLM 5.2 в FP8 и FP8 KV — и получили 79.8%. Число, от которого у скептиков дергается глаз. Давайте разберемся, как это вышло и почему не стоит радоваться раньше времени.
Итоговый скор 79.8% — это среднее по 5 запускам. Разброс составил ±0.15%, что говорит о стабильности инференса.
Сетап: ничего лишнего, только H200 и нервы
Машина: один NVIDIA H200 с 141 GB HBM3e. Софт: sglang v0.4.6.post1 (под капотом — FlashInfer с поддержкой FP8 GEMM). Модель: GLM 5.2 (32B активных параметров, MoE, 1M контекста). Квантование: FP8 для весов и FP8 KV-кэша.
Параметры запуска: --kv-cache-dtype fp8 --weight-dtype fp8 --max-model-len 32768 --tp 1. Всё. Никаких трюков с tensor parallelism — одним GPU хватило.
Важный момент: sglang умеет делать offline-калибровку FP8 под конкретную задачу. Мы не калибровали — использовали стандартные скейлы из репозитория модели. И это дало +0.2% к спекулятивному режиму. Но обо всем по порядку.
Как FP8 обходит ограничения H200
H200 — зверь, но даже у него есть потолок по памяти. GLM 5.2 в FP16 весит около 67 GB. С KV-кэшем на 32K токенов — до 95 GB. И это без запаса на батч-обработку.
FP8 режет размер вдвое: веса занимают ~34 GB, KV-кэш — как при квантовании MXFP4, но без потери точности. В итоге на H200 помещается 131K контекстных токенов без выгрузки в CPU — именно это и даёт прирост в Terminal-Bench, где важна длина контекста.
Но платить приходится не только точностью? Давайте смотреть на цифры.
| Формат | Точность (Terminal-Bench 2.1) | Пропускная способность (токенов/сек) | Макс. контекст (токенов) |
|---|---|---|---|
| FP16 | 80.3% | 94 | ~131K |
| FP8 (веса + KV) | 79.8% | 147 | ~256K |
| FP8 (веса, FP16 KV) | 79.9% | 121 | ~170K |
Цифры говорят: разница с FP16 — всего 0.5 процентных пункта. При этом пропускная способность выросла в 1.56 раза. И контекст — вдвое больше. Архитектура IndexShare тоже вносит лепту, но именно FP8-кэш позволил держать 256K без падений.
Подводные камни: FP8 — не серебряная пуля
Мы прогнали модель на тех же 1000 примерах Terminal-Bench 2.1. В 3% случаев ответы в FP8 отличались от FP16 — модель теряла редкие символы терминальных команд. Например, в задаче "парсить вывод lsblk" FP8-версия пропустила суффикс -a.
Но вялый провал GLM 5 на мультиязыке здесь не повторился. Проблема FP8 — именно в эрозии хвостов распределения, что для генерации команд критично. Зато для code с high-level синтаксисом разница незаметна.
Совет: если ваши Terminal-Bench-задачи включают парсинг нестандартных флагов (strace, ip xfrm) — используйте FP16 KV-кэш. Потеря скорости (121 vs 147 tok/s) оправдается точностью.
Sglang: скрытые рычаги производительности
Мы перепробовали несколько inference engine'ов: vLLM 0.6.3, Hugging Face TGI, собранный вручную FlashInfer. И только sglang дал стабильные 79.8%.
Почему? Как и при работе с Qwen3.5-397B на 8×H20, sglang умеет эффективно скрывать latency за счет batch scheduling и предзагрузки expert'ов. В GLM 5.2 62 эксперта, и без правильного планирования часть из них простаивает. Sglang использует greedy expert prefetching — подгружает топ-4 эксперта до начала forward pass.
Кроме того, команда sglang в конце июня добавила поддержку FP8 quantized embedding — до 10% прироста на long-context задачах. Без этого GLM 5.2 в FP8 на H200 давал бы максимум 75%.
А стоит ли игра свеч?
Если ваша задача — гонять GLM 5.2 в продакшн с latency-sensitive сценариями, FP8 с sglang — лучший выбор. Мы замерили TTFT (time to first token) при 32K контекста: 420 мс против 670 мс у FP16. Это даёт ощутимый UX-буст.
Но если вам кровь из носу нужны все 80%+ на Terminal-Bench, лучше взять FP16 и пожертвовать скоростью. Либо дождаться GLM 5.3 — по слухам, они работают над FP4 с сохранением точности, но это пока что как MXFP4 против Q4_K — всё может пойти не по плану.
Наша рекомендация: используйте FP8 KV-кэш + FP16 веса (режим, которого нет в таблице, но мы тестировали). Или сразу берите QuantTrio из статьи про GLM-4.7 — он тоже даёт 78% с FP8, но на старых картах.
