Что говорят 2 122 токена в секунду — и о чём эта цифра умалчивает

27 сентября NaiveAI опубликовала техническую статью о Naive-N0.5-Flash. По данным разработчика, система NaiveRT, оптимизированная для декодирования одного потока при генерации траекторий в обучении с подкреплением (RL rollouts), достигает 2 122 токенов в секунду с помощью интегрированной модели DFlash для черновой генерации при спекулятивном декодировании. Важны условия измерения: восемь GPU, лучший односекундный интервал среди 41 запроса HTML/SVG, отключённый режим размышления и исключённая из расчёта предварительная обработка ввода (prefill). Это измерение самого разработчика; SlateMoth не воспроизводила его независимо. [1]

Главный вопрос — какую долю реального ожидания охватывает эта цифра. Пиковая скорость декодирования описывает лишь часть обработки запроса. Она не показывает напрямую, сколько времени займёт изменение кода, подготовка отчёта или задача агента целиком. Командам, оценивающим модели, полезно разделять эти вопросы, чтобы справедливо судить о перспективном инженерном результате.

Предлагаем вести три отсчёта. Первый — от отправки запроса до первого пригодного к использованию результата; он включает ожидание и обработку ввода, которые ощущает пользователь. Второй — оставшееся время генерации, от первого результата до завершения ответа. Третий охватывает всю задачу от отправки до приёмки, включая вызовы инструментов, тесты и необходимые повторные попытки. Ускорение одного этапа не обязательно сократит общее время в той же пропорции.

Представим гипотетическую задачу по изменению кода: загрузка проекта и ожидание первого результата занимают 12 секунд, генерация — 8 секунд, тесты — 40 секунд. Даже если генерация станет быстрее в четыре раза, общее время уменьшится лишь с 60 до 54 секунд, то есть на 10 %. Это иллюстративные числа, а не результаты измерений NaiveAI. Прежде чем переносить заявленное ускорение на весь рабочий процесс, нужно выяснить, на что уходит время.

Кратковременный пик также не показывает, сохранится ли скорость на протяжении длинного ответа или при одновременных запросах. Запрашивайте время полного ответа и распределение задержек при ожидаемой нагрузке. Разделяйте скорость отдельного запроса и общую пропускную способность: обслужить больше запросов в секунду и раньше завершить задачу одного человека — разные цели.

В карточке модели указаны 309 млрд параметров всего и 15,5 млрд активных параметров. В рекомендациях по развёртыванию в FP8 сказано, что веса занимают примерно 315 GB, а для инференса требуется дополнительная память GPU. Там же указано, что архитектура с разреженным вниманием сохраняет полный KV-кеш. Эти сведения помогают избежать распространённой ошибки: число активных параметров не означает, что вся модель помещается в объём памяти, необходимый плотной модели такого размера. [2]

При выборе конфигурации развёртывания зафиксируйте фактические веса и точность, оборудование и соединения между устройствами, версию среды выполнения, длину контекста и число одновременных запросов. Затем измерьте потребление памяти и сбои именно на этой конфигурации. Меньшее число параметров, задействованных в вычислении, может быть полезным, но не делает любой вариант развёртывания компактным. Квантование, выгрузку данных из памяти GPU или другой движок обслуживания нужно оценивать как отдельные конфигурации; исходную пиковую скорость нельзя автоматически переносить на них.

Важно обозначить границу опубликованных материалов. В технической статье система NaiveRT описана как проект с открытым исходным кодом, но там же сказано, что упомянутые исходные материалы станут доступны к 12 октября. Во время нашей проверки 28 сентября репозиторий NaiveRT по ссылке из статьи возвращал 404. Поэтому мы не смогли изучить по этой ссылке среду выполнения и скрипты тестирования. Это не доказывает, что результат ложный или что веса модели нигде недоступны. Это ограничивает лишь то, что мы могли проверить на тот момент. [1] [3]

Пока соответствующие материалы нельзя изучить и повторить эксперимент, скорость следует считать результатом, о котором сообщил разработчик для конкретных условий. Тест скорости с отключённым режимом размышления также не подтверждает производительность в задачах, требующих длительного рассуждения. Качество и время нужно измерять вместе в том режиме, который действительно будет использоваться для работы.

Начните с небольшого набора типичных задач и заранее определите критерии успеха. Для изменения кода это могут быть работа требуемой функции, успешное прохождение регрессионных проверок и отсутствие изменений в посторонних файлах. Для документа — наличие необходимых фактов и ссылок, подтверждающих утверждения. Измеряйте всю попытку, включая ошибки и доработку, а не сохраняйте только самый впечатляющий результат.

При смене модели или конфигурации обслуживания оставляйте неизменными набор задач, права инструментов и правила приёмки. Фиксируйте время до первого результата, общее время, долю принятых задач и стоимость одной принятой задачи. Включайте короткие и длинные входные данные, обычную параллельную нагрузку и повторные прогоны. Один быстрый пример может стать поводом для дальнейшей проверки, но не описывает опыт всех пользователей.

Наибольший эффект от ускорения декодирования можно ожидать там, где генерация действительно занимает основную часть времени. Длинная, преимущественно последовательная генерация способна заметно выиграть, если качество сохранится. В процессе, где больше времени уходит на поиск информации, медленные инструменты или проверку человеком, выигрыш может быть меньше. Это не умаляет инженерного достижения, а подсказывает, где проверить его в первую очередь.

Отчёт NaiveAI даёт командам конкретную гипотезу для проверки: другая архитектура инференса может сократить время работы с высокой долей генерации. Мы изучили опубликованное описание методики, но не запускали модель и не воспроизводили пиковую скорость. Следующие необходимые свидетельства — доступный код среды выполнения, воспроизводимая конфигурация и результаты на типичных задачах. Решение о внедрении должно опираться на то, насколько быстро система выдаёт приемлемый результат при вашей нагрузке.