Каждый раз, когда очередной стартап пишет «мы используем Transformer», я вспоминаю сцену из «Офиса»: все делают вид, что это работает, хотя на деле — просто жгут GPU. Self-attention с его квадратичной сложностью O(n²) — это роскошь, которую не каждый проект может позволить. Особенно если у тебя не кластер H100, а мобильный чип или бюджет в $500.
И тут на сцену выходит новая архитектура декодера на основе сверток — работа российского исследователя, выложенная на arXiv под ID 2604.18580. Без пафоса, без шума — просто берет и заменяет механизм внимания на то, что работает в полторы строчки кода. Звучит как ересь? Давайте разбираться.
Как свертки жрут внимание на завтрак
Идея до неприличия проста: вместо того чтобы считать матрицу внимания для каждого токена со всеми предыдущими (O(n²) памяти и времени), автор предлагает использовать одномерные каузальные свертки (causal convolutions). В такой свертке каждый выходной токен зависит только от фиксированного окна предыдущих — например, от 512 токенов. Сложность — O(n·k), где k — размер ядра (константа). Никакого экспоненциального роста при длинных последовательностях.
Но как модель поймет, какие токены важны, если нет внимания? Спойлер: совсем не обязательно «смотреть» на все прошлое, чтобы понять контекст. Сверточный декодер учится выделять паттерны локально, а за счет глубины слоев — накапливает рецептивное поле экспоненциально. Плюс — адаптивные ядра: размер окна может динамически меняться в зависимости от позиции.
Ключевое преимущество: декодер на свертках потребляет в 5–10 раз меньше памяти при инференсе на последовательностях длиной 8K токенов по сравнению с Transformer той же глубины. Да, вы не ослышались — без потери качества на задачах генерации текста, если верить бенчмаркам из статьи.
Более того, архитектура из коробки поддерживает контекст до 128K токенов без модификаций — просто за счет увеличения числа слоев или размера ядра. Никаких трюков с attention sink или sliding window — обычная свертка.
Кого эта штука обгоняет и на сколько
Автор сравнил свою модель с открытыми Transformer-декодерами на задачах генерации текста (вплоть до Llama-подобных моделей 1B–3B параметров). Результаты: точность сопоставима, но скорость инференса выше в 2–3 раза на CPU и в 4–6 раз на GPU с оптимизированными сверточными ядрами. А если использовать фреймворк вроде SyDecode для vLLM — выигрыш еще круче.
Не забываем и про альтернативы, которые тоже пытаются свергнуть Transformer с трона. Например, архитектура TAPE с активным восприятием для computer vision. Или Differential Transformer V2 от Microsoft — там внимание тоже модифицировано, но без выхода за O(n²).
Отдельно стоит упомянуть рекуррентные модели вроде Ouro-2.6B от ByteDance — они тоже борются с квадратичной сложностью, но требуют совместимости с конкретными версиями библиотек. Сверточный декодер, напротив, работает на любом фреймворке, где есть Conv1D.
Где это можно применить прямо сейчас
Допустим, вы пишете чат-бота для телеграм-канала с миллионом активных пользователей. Каждое сообщение нужно обработать за 50 мс, а GPU — только один T4. Transformer с контекстом 4096 токенов будет жрать всю память и лагать. Сверточный декодер даст вам экономию памяти в 3–5 раз на ту же длину контекста — можно даже на CPU работать без потери качества.
Еще пример: генерация кода в IDE. Модели вроде InCoder-32B уже умеют писать под микроконтроллеры. Но если вы захотите запустить такую модель на Raspberry Pi — Transformer не пройдет. А сверточный декодер — запросто, потому что он линеен по памяти.
Те, кто уже экспериментировал с рекуррентными блоками вроде LoopCoder, знают, что повторяющиеся слои иногда дают парадоксальный эффект. Свертки же — детерминированы и предсказуемы, как каменная стена. Никаких «дрейфов» или «thinking loops».
Кому это надо, а кому — проходить мимо
Не советую использовать сверточный декодер, если: вы тренируете huge модель на 70B параметров — там выигрыш может быть не таким ощутимым из-за особенностей распределенных алгоритмов. Или если ваша задача требует буквального «чтения» всей истории (например, поиск в длинных документах). Там свертка может упустить далекую зависимость, хотя глубокая сеть это компенсирует.
Но если вы хотите:
- запихнуть генеративную модель на мобильное устройство или в браузер;
- сделать real-time голосового ассистента без GPU;
- сэкономить бюджет на облачных инстансах;
- получить O(n) сложность без выдумок с sparse attention —
то сверточный декодер — ваш выбор. Архитектура уже реализована автором в открытом репозитории, код можно запустить хоть сегодня (ссылка в статье arXiv).
Лично я бы посоветовал попробовать эту штуку на задаче суммаризации диалогов — там контекст обычно не выходит за 2K токенов, и свертка даст максимальный профит по скорости. А заодно проверить, не устарел ли ваш любимый Transformer.
