ainews
Разработчик ускорил ядро в 29 раз — и получил всего 6% прироста в реальности
Разработчик inference-движка на C99 для тернарных моделей BitNet две недели писал новое матричное ядро с AVX-512, разогнал его в 29 раз по бенчмаркам, но в реальном конвейере прирост оказался всего 6–10%. Причина: модель упирается в пропускную способность RAM (95% загрузки), а не в вычисления — быстрее считать нечего, если данные не успевают подгружаться.
Это классический кейс про разницу между микробенчмарками и реальной производительностью — урок для всех, кто оптимизирует AI-инференс. Показывает, что для CPU-based моделей вроде BitNet узкое место сместилось с вычислений на память, что меняет приоритеты оптимизации.
Когда бенчмарк врёт: история про 29x, которые превратились в 6%
Разработчик inference-движка на чистом C99 (без Python и BLAS, только gcc и make) для тернарных моделей BitNet поделился поучительной историей про оптимизацию.
Победа в вакууме
Две недели ушло на переписывание ядра матричного умножения (matmul kernel) с использованием инструкций AVX-512BW. Новый подход упаковывает 5 тернарных весов в байт вместо 4, используя vpermt2w. Результаты изолированного бенчмарка впечатляли: 74.6 Gop/s против 2.5 Gop/s у скалярной версии — ускорение в 29 раз. Цифра попала в несколько постов и PR.
Столкновение с реальностью
При ревью pull request всплыл очевидный вопрос: а какова реальная пропускная способность RAM? Измерения показали, что BitNet decode на тестовом Xeon уже работает на ~95% пропускной способности DRAM. Модель memory-bound, а не compute-bound: узкое место — не вычисления, а скорость подачи данных из памяти.
Быстрее считать бессмысленно, если процессор всё равно простаивает в ожидании следующей порции данных. Честный расчёт даёт 6–10% прироста в реальном end-to-end сценарии — после того, как ядро будет интегрировано в dispatch path (пока оно просто лежит протестированным, но не подключённым).
Что работает
Движок всё равно функционален: BitNet b1.58-2B-4T выдаёт 36 токенов/сек на Xeon с 4 потоками без GPU. Поддерживает и обычные GGUF dense модели. Исходники и бинарники доступны на GitHub (project-zero).
Вывод
Автор честно признаёт: лучше узнать правду сейчас, чем запустить хедлайн про «29x ускорение», который развалится при первом же замере tok/s вместо Gop/s. И задаёт вопрос сообществу: сталкивался ли кто-то с похожей ситуацией, когда профилировали не тот слой стека?
Ключевые выводы
- Изолированные бенчмарки могут давать драматические цифры (29x), но в реальных системах узким местом часто оказывается пропускная способность памяти, а не вычислительная мощность
- BitNet decode на CPU упирается в DRAM bandwidth (~95% загрузки), что делает дальнейшую оптимизацию вычислительных ядер малоэффективной
- Честная метрика для inference — tok/s (токены в секунду), а не Gop/s (операции в секунду), так как первая отражает реальный пользовательский опыт
- C99 inference-движок без Python и BLAS показывает 36 tok/s для BitNet b1.58-2B на Xeon с 4 потоками — доказательство жизнеспособности минималистичного подхода
- Ревью кода помогло избежать публикации misleading бенчмарка — хороший пример инженерной честности
Автор: Анна Мельникова · Источник: reddit.com
Это история про то, как легко обмануться собственными цифрами. Парень написал хардкорное AVX-512 ядро, запаковал тернарные веса плотнее, получил красивые 74 гигаопса — и только при ревью спохватился посмотреть на реальный bottleneck. А там RAM уже орёт на 95%, и весь его красивый код просто быстрее упирается в ту же стену.
Но вот что подкупает: он не стал пиарить 29x, а честно вышел и сказал «облажался, смотрите, вот как на самом деле». В мире, где каждый стартап кричит про «revolutionary 100x speedup», такая откровенность — редкость. И project-zero всё равно работает: 36 tok/s на CPU для BitNet — это вполне рабочая цифра для локального инференса, если GPU нет или не нужен. Минималистичный стек на чистом C99 без PyTorch-оверхеда имеет право на жизнь, просто не там надо было копать.
Комментарии