Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Длинный входной контекст научились обрабатывать без полного внимания на каждом входном токене, сохранив доступ ко всему тексту во время генерации. В препринте Yuhong Chou и коллег, который не проходил рецензирование и содержит замеры самих авторов, Orthros ускорил обработку входа до 21,9 раза относительно обычного Transformer. Архитектура меняет экономику запросов с длинными документами и короткими ответами, но переносит часть затрат в обучение.
Полное внимание включается только для выходных токенов
Обычный Transformer при обработке входа сопоставляет каждый токен со всеми предыдущими. Число таких операций растёт квадратично: удлинение контекста увеличивает работу быстрее, чем сам контекст.
Механизмы со скользящим окном ограничивают каждый токен ближайшим фрагментом и поэтому масштабируются линейно. Однако удалённый факт может оказаться за пределами окна. Гибридные архитектуры добавляют слои полного внимания, но именно эти слои снова создают квадратичное узкое место.
Orthros разделяет две фазы запроса. При обработке входного контекста (prefilling) каждый слой использует скользящее окно и одновременно сохраняет ключи и значения всех токенов в KV-кэше. Только последний токен запроса выполняет полное внимание по этому кэшу, чтобы начать ответ.
Во время генерации каждый новый токен обрабатывается двумя потоками. Первый обновляет KV-кэш и работает в локальном окне, второй обращается ко всему накопленному контексту и предсказывает следующий токен. Поэтому модель экономит на длинном входе, но не отказывается от глобального поиска при формировании ответа.
Вычислительная сложность зависит не только от общей длины последовательности, но и от соотношения входа и выхода. Если модель читает большой документ и возвращает короткий результат, затраты растут почти линейно относительно входа. Если выход становится сопоставим с входом, полное внимание при генерации возвращает квадратичный характер вычислений.
Ускорение проявилось на длинном входе, а не на декодировании
Архитектуру проверяли на моделях от сотен миллионов до нескольких миллиардов параметров. Одну модель обучили с нуля, а готовые базовые модели Llama и Qwen преобразовали заменой модулей внимания и продолжили обучать. Сравнения охватывали обычный Transformer, линейное и гибридное внимание, задачи понимания текста и извлечение фактов из длинного контекста.
На входе длиной 128K токенов время до первого токена сократилось с 77,249 до 17,016 секунды — примерно в 4,5 раза. Сквозная задержка тоже снизилась, но преимущество уменьшалось по мере роста ответа: генерация занимала всё большую долю времени.
Максимальное ускорение из лида получили в отдельном тесте обработки входа на самой длинной последовательности и нескольких GPU. Это не означает такого же выигрыша для всего запроса: итог зависит от длины ответа, пакетной обработки и доли времени, которую система тратит на генерацию.
В тесте «иголка в стоге сена» Orthros почти безошибочно находил вставленный факт на той же длине контекста. На прикладных задачах извлечения информации результаты оставались на уровне Transformer. Эти проверки показывают, что глобальный доступ во время генерации закрывает основной недостаток одного лишь скользящего окна, хотя набор задач не заменяет испытания на конкретных данных продукта.
Планы стоит менять только для запросов с коротким выходом
Orthros имеет смысл учитывать в системах, где модель принимает репозитории, длинные документы, историю агента или мультимодальный контекст, а возвращает сравнительно короткий ответ либо вызов инструмента. Здесь обработка входа определяет задержку, поэтому перенос полного внимания в генерацию может сократить время до первого токена и повысить пропускную способность.
Для чат-систем с длинными ответами выгода слабее. Скорость самого декодирования у Orthros осталась близкой к базовому Transformer: дополнительный поток почти не увеличил задержку в проведённых тестах, но и не ускорил последовательное создание токенов. Гибридные варианты с линейным вниманием декодировали быстрее.
Замена архитектуры также не бесплатна. При обучении Orthros дублирует позиции, для которых модель предсказывает следующий токен, поэтому вычислительная работа над последовательностью удваивается. Преобразование готового Transformer требует продолженного обучения, а поддержку нового режима ещё предстоит встроить в используемый сервер вывода и его ядра.
Работа не решает расход памяти KV-кэша: Orthros сохраняет ключи и значения всех входных токенов. Для моделей со смесью экспертов потребуется согласовать маршрутизацию двух потоков, иначе они могут попасть к разным экспертам и увеличить обмен данными.
Практический вывод — не заменять текущую архитектуру заранее, а добавить Orthros в стенд для нагрузочных испытаний с реальным распределением длин входа и выхода. Если продукт в основном читает много и пишет мало, результаты дают основание пересмотреть стоимость длинного контекста. Для генеративных нагрузок и обучения с нуля экономический баланс остаётся менее очевидным.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
