Cloudflare ускорила Kimi на 41% сжатием KV-кеша и уменьшила GLM на 40% сжатием весов

Cloudflare в блоге Workers AI описала три технических приёма, которыми компания обслуживает две крупные и требовательные к памяти открытые модели, линейку Kimi от Moonshot и GLM от Z.ai, на собственных GPU в своих дата-центрах. Обе модели, большие mixture-of-experts с длинным контекстом, и именно память GPU становится узким местом при их обслуживании: чаще всего заканчивается место не под веса модели, а под KV-кеш (структуру, где хранятся ключи и значения внимания для уже обработанных токенов, позволяющую не перечитывать весь контекст заново на каждом новом токене).

Первый приём, квантование KV-кеша. По умолчанию кеш хранится в 16-битной точности (BF16); Cloudflare переводит его в 8-битный формат с плавающей точкой (FP8, e4m3), что вдвое уменьшает размер. Для модели Kimi K2.6 это увеличивает объём контекста, помещающегося в памяти, примерно с 686 тысяч токенов до 1,37 миллиона, вдвое больше. Сам по себе FP8-кеш на каждый токен работает на несколько процентов медленнее, чем BF16 (ядру внимания приходится конвертировать значения при чтении), но выигрыш не в скорости на запрос, а в числе запросов, которые можно держать в памяти одновременно: BF16-кеш упирается в потолок на 32 параллельных запросах и не может принять 33-й, а FP8-кеш продолжает работать вплоть до 64 запросов и достигает 2192 токенов в секунду, примерно на 41% выше пикового показателя BF16, притом что стоимость на токен снижается примерно на 30%. Поскольку Cloudflare разделяет этапы prefill (обработку входного запроса) и decode (генерацию токенов) на разные пулы GPU, компания применяет FP8-кеш только там, где он даёт выигрыш: prefill упирается не в память, а в вычисления, поэтому там кеш оставляют в BF16 ради его чуть более высокой скорости. По собственной оценке Cloudflare на её тестовом наборе, ответы модели при FP8- и BF16-кеше неотличимы.

Второй приём, сжатие весов самой модели. Для GLM 5.2 Cloudflare сжимает веса с 8-битного формата с плавающей точкой до 4-битных целых чисел (INT4) без потери точности, по заявлению компании. Файл модели уменьшается с 705 ГБ до 421 ГБ (примерно на 40%), а память на один GPU в развёртывании с 8-кратным тензорным параллелизмом падает примерно с 88 ГБ до 52 ГБ, освобождая место ещё для примерно 1,18 миллиона токенов KV-кеша на том же оборудовании. Меньшие веса ускоряют именно этап decode: генерация каждого токена требует прогонки весов модели через память GPU, а значит, скорость ограничена пропускной способностью памяти, чем меньше данных нужно переместить, тем быстрее приходит токен. Эффект сильнее всего при низкой конкурентности запросов, когда важнее всего задержка на один запрос. С prefill всё наоборот: этот этап упирается в вычисления, а INT4-веса перед умножением приходится разворачивать обратно, поэтому лишний шаг замедляет, а не ускоряет prefill, GLM выдаёт около 10 160 токенов в секунду на prefill в FP8 против 8660 в INT4. Как и с кешем, разделение этапов превращает это в осознанный выбор, а не компромисс: decode работает на INT4, prefill, на FP8, там, где каждый формат выигрывает. Точность модели, по данным Cloudflare, отклоняется от точности FP8-версии не более чем на 0,8 балла по всем прогоняемым тестам.

Третий приём, защита общего KV-кеша. Оба предыдущих приёма приводят к тому, что память одного GPU делят между собой гораздо больше запросов одновременно, а значит, сотни запросов читают и пишут страницы одного и того же физического кеша. При таких объёмах даже ошибка «одна на миллиард» будет проявляться регулярно, поэтому Cloudflare добавила отдельный слой проверки целостности кеша: каждая физическая страница кеша получает метку, которая меняется при каждом повторном выделении страницы, а сервер запоминает, какие страницы и метки ожидает получить каждый запрос. Перед чтением из кеша на этапе decode эти соответствия проверяются; если что-то не совпадает, соответствующий запрос прерывается, вместо того чтобы вернуть данные с чужой страницы. Проверку измерили на модели среднего размера в конфигурации с двумя пулами prefill и двумя пулами decode, на входах по 8192 токена и выходах по 1000 токенов: стоимость проверки составила менее 1% и по пропускной способности, и по хвостовой задержке, причём даже верхняя граница 95%-го доверительного интервала остаётся у отметки около 1%. Чтобы держать накладные расходы низкими, проверку реализовали как отдельную пакетную операцию, а не встроили в само ядро внимания (это создало бы гонку между группами потоков GPU); проверку можно включать по каждому развёртыванию отдельно, а по умолчанию используется «пустой» механизм без измеримых накладных расходов, так что развёртывания, которым проверка не нужна, ничего за неё не платят.

Все эксперименты и продакшен-трафик Cloudflare прогоняет через SGLang, открытый фреймворк для инференса; компания заявляет, что он даёт лучшую производительность на рынке, и работает с командой SGLang над переносом своих патчей и новых функций в открытый код. Дальше Cloudflare планирует расширять применение FP8-кеша на большую часть своего парка GPU, проверять веса в формате NVFP4 на архитектуре Blackwell от NVIDIA и стремиться к тому, чтобы проверку целостности можно было включать повсеместно с пренебрежимо малой стоимостью.

Ключевые факты

• Перевод KV-кеша Kimi K2.6 с BF16 в FP8 увеличивает вместимый в памяти контекст с ~686 тыс. до ~1,37 млн токенов и поднимает пиковую пропускную способность decode до 2192 токенов/с, на 41% выше пика BF16, при снижении стоимости на токен примерно на 30%.
• Сжатие весов GLM 5.2 с FP8 до INT4 уменьшает размер модели с 705 ГБ до 421 ГБ (~40%) и память на GPU с ~88 ГБ до ~52 ГБ, освобождая место под ~1,18 млн токенов KV-кеша; при этом prefill в INT4 медленнее, чем в FP8 (8660 против 10 160 токенов/с).
• По заявлению Cloudflare, ни квантование кеша, ни сжатие весов не меняют качество ответов моделей: FP8/BF16-кеш и INT4/FP8-веса неотличимы на внутреннем наборе тестов, а разброс точности не превышает 0,8 балла.
• Из-за того что много запросов теперь делит один физический KV-кеш, Cloudflare добавила проверку целостности кеша по меткам страниц; она обходится дешевле 1% пропускной способности и хвостовой задержки и по умолчанию включена как «пустой» механизм без накладных расходов.
• Все техники обкатаны в продакшене на инференс-фреймворке SGLang и опираются на разделение этапов prefill и decode по отдельным пулам GPU, что позволяет применять разные форматы точности там, где каждый выигрывает.

Почему это важно

Открытые модели вроде Kimi и GLM большие, с длинным контекстом и архитектурой mixture-of-experts, поэтому обслуживать их дёшево и быстро тяжело: память GPU обычно заканчивается раньше, чем вычислительные ресурсы, причём чаще из-за KV-кеша, а не самих весов. Пост Cloudflare показывает конкретные цифры того, сколько эффективности можно выжать из инфраструктуры инференса без замены железа и без потери качества ответов, рост пропускной способности decode на 41% и снижение стоимости токена на 30% при квантовании кеша, плюс почти двукратное сжатие модели при переходе весов на INT4.

Кому это важно

Материал в первую очередь для инженеров, которые сами разворачивают инференс больших открытых моделей на GPU: облачных провайдеров вроде самой Cloudflare, команд, эксплуатирующих SGLang или похожие фреймворки, и разработчиков, которые обращаются к Kimi и GLM через Workers AI и ощущают эффект в виде более низкой стоимости и большей доступности этих моделей.

Как это применить

Три приёма можно переносить по отдельности: квантовать KV-кеш в FP8 там, где инференс упирается в память (обычно decode), оставляя prefill в BF16 или FP8, поскольку он упирается в вычисления, а не в память; сжимать веса модели до INT4 для decode, если нужна максимальная скорость генерации при низкой конкурентности, и держать FP8 для prefill, где INT4 наоборот всё замедляет; и добавлять лёгкую проверку целостности разделяемого KV-кеша (метки страниц, сверяемые перед чтением), если множество запросов делят один физический кеш, по данным Cloudflare, такая проверка обходится дешевле 1% пропускной способности.

Можно ли доверять

Это официальный технический пост инженерной команды Cloudflare с конкретными числами по конфигурациям (H200, 8-way tensor-parallel, конкретные размеры входа/выхода) и явным указанием, на каком именно фреймворке и наборе тестов получены результаты (SGLang, внутренний eval-набор). Пост не подписан именем конкретного автора. При этом все цифры и заявления о точности, собственные измерения и оценки Cloudflare на собственном оборудовании и собственном наборе тестов, независимого подтверждения нет, а состав и охват «внутреннего eval-набора» в тексте не раскрыты.

Риски и подводные камни

Квантование, это компромисс, а не бесплатный выигрыш: FP8-кеш на каждый отдельный запрос работает на несколько процентов медленнее BF16, а INT4-веса замедляют prefill (8660 токенов/с против 10 160 у FP8), выигрыш проявляется только благодаря разделению prefill/decode и росту допустимой конкурентности, а не всегда и не в любой конфигурации. Более плотное совместное использование GPU многими запросами одновременно повышает цену ошибки в системе кешей, что и заставило Cloudflare отдельно строить защиту от утечки чужих данных между запросами; сама компания признаёт, что при таких объёмах трафика даже вероятность «один на миллиард» реализуется регулярно. Наконец, все данные о точности и производительности, самоотчёт вендора без внешнего аудита.

«Если что-то не совпадает, соответствующий запрос прерывается, вместо того чтобы вернуть данные с чужой страницы.»

— Cloudflare, блог Workers AI