Байтовые языковые модели: что даёт отказ от токенизатора
У каждой современной LLM есть незаметный посредник. Токенизатор решает за модель, что считать единицей текста: BPE-словарь заранее нарезает корпус на кусочки, и модель работает с номерами этих кусочков, никогда не видя сырые символы. Байтовые языковые модели выбрасывают посредника и учатся прямо на байтах.
Но сможет ли трансформер сам восстановить структуру, которую раньше задавали вручную? И не станет ли вчетверо более длинная последовательность приговором? Работа в arXiv 2610.05978 от 5 октября 2026 года (Jie Wang, Shiwei Luo, Qi Zhang, Yuanbin Wu) отвечает: сможет. При масштабировании байтовые модели обгоняют обычные, сами изобретают внутренние чанки размером с токены, а четверть слоёв можно сжать без потери качества. И всё это на плоском трансформере, без специальных иерархических архитектур.
Что такое байтовые языковые модели
Байтовые языковые модели (byte language models) это трансформеры без токенизатора: текст подаётся как поток байтов UTF-8, словарь сжимается до 256 значений, и модель сама учится собирать из них осмысленные единицы. Цена решения известна: один токен обычной LLM покрывает около четырёх байтов, так что последовательность удлиняется примерно вчетверо, а вычислений на единицу текста становится больше.
Байты пробовали и раньше. ByT5 в 2022 году работала байт-в-байт, MambaByte перенесла на байты селективные state space модели, а свежие BLT, H-Net и ByteFlow построили иерархию local-global-local: локальный энкодер сжимает поток в чанки переменного размера, глобальные слои работают с чанками, декодер разворачивает обратно. Такие архитектуры требуют собственных схем обучения и оптимизации, и непонятно, что именно даёт выигрыш: совместная формулировка задачи или инженерные надстройки. Авторы новой работы убрали надстройки и оставили голый трансформер, чтобы измерять только эффект гранулярности.
Два приёма, которые включают масштабирование
Учить байты стандартным рецептом неоптимально: токенов больше, а локального контекста в каждом меньше. Первый приём это token-superposition training (TST). Модель усредняет эмбеддинги четырёх подряд идущих байтов и предсказывает следующий «мешок» из четырёх вместо одного токена. В первые 30% обучения это даёт четырёхкратную экспозицию токенов, дальше модель возвращается к обычному next-token prediction, и суммарно при том же числе шагов видит в 1,9 раза больше текста.
Второй приём это hash embeddings. К эмбеддингу байта добавляются представления его n-грамм, и один байт вбирает информацию о соседних паттернах, компенсируя нехватку локального контекста. По мелочи там есть ещё пара настроек. Словарь байтовой модели состоит из 256 значений, а 13 байтов, запрещённых в UTF-8 (0xC0, 0xC1 и диапазон от 0xF5 до 0xFF), отведены под служебные токены. Ширина свёртки Gated DeltaNet увеличена с 4 до 16, чтобы расширить локальное рецептивное поле.
Архитектура гибридная, как у Qwen3.5: слои Gated DeltaNet и Gated Softmax Attention чередуются в пропорции 3 к 1. Subword-версия использует словарь из 49 152 токенов. Основной набор моделей это плотные сети от 200M до 3B параметров, от 16 до 40 слоёв, обученные с нуля на датасете ClimbMix, с контекстом 8192 байтовых токенов против 2048 токенов у subword.
Методология стоит пары слов. Кривые оптимальных моделей строили в стиле Chinchilla: семейства байтовых и subword-моделей обучали при разных бюджетах вычислений и разном объёме данных, замеряли валидационный loss в битах на байт, а затем подгоняли стандартную функцию потерь от числа параметров и объёма текста. Для каждого бюджета находили точку минимума: сколько параметров и сколько данных оптимально при фиксированных FLOPs. Именно на этих кривых и видно расхождение двух семейств.
Числа: где байты выигрывают
Сравнение получилось честным в обе стороны, и это важнее красивого заголовка. Если считать в параметрах, кривая байтовой модели лежит ниже по BPB (bits per byte, меньше значит лучше): дополнительная длина работает как дополнительное вычисление. Но если зафиксировать бюджет по FLOPs, пока выигрывает subword. Авторы не прячут этот результат, а показывают, где его можно перевернуть.
Сдвиг прячется в оптимуме. При одном и том же бюджете байтовый оптимум выбирает модель поменьше и даёт ей в 3,2 раза больше исходных байтов на один параметр. Оптимальная пропорция данных к параметрам у байтов выше в 1,5 до 3 раз, чем у subword. Проще говоря, байтовый трек выигрывает тогда, когда данных продолжают подвозить, а параметры можно и не раздувать.
На прикладных задачах разрыв резче. Тест CUTE на манипуляции со словами: уже на 200M параметров байтовая модель набирает 99,19% против 69,89% у subword, на 3B это 99,93% против 80,83%. OCRBench поднимается с 34,70% до 42,40%, TextVQA с 50,76% до 55,39%. В относительных числах около 40% улучшения на CUTE и около 20% на OCRBench. Логика простая: где нужна мелкая гранулярность, символы, границы слов, порядок букв, байтовый вход видит больше.
| Бенчмарк | 200M | 3B |
|---|---|---|
| CUTE | 69,89 против 99,19 | 80,83 против 99,93 |
| OCRBench | 27,10 против 35,10 | 34,70 против 42,40 |
| TextVQA | 40,62 против 45,08 | 50,76 против 55,39 |
В каждой ячейке первое число у subword-модели, второе у байтовой. На широких vision-language бенчмарках семьи идут вровень, а на остальных текстовых задачах байтовые модели впереди за счёт большего числа вычислений на параметр.
Вычисления можно перераспределить
Разрыв между семействами зависит от того, как распределены вычисления. Четырёхпроходная subword-модель с общими весами (приём из LoopFormer) почти закрывает разрыв по BPB и вдобавок обходит плотную байтовую модель по QA RC: одни и те же слои прогоняются подряд четыре раза, поэтому вычисления растут без роста числа параметров. Разреженные MoE действуют зеркально и работают в пользу байтов: параметров много, но на каждый токен активируется лишь часть экспертов. 1B байтовая MoE получает BPB ниже, чем плотная 3B subword, при сопоставимом QA RC. Спор «байты против токенов» на деле оказывается спором о том, куда деваются FLOPs.
Токены, которые никто не задавал
Самая интересная часть работы про то, что происходит внутри. Модели дают задачу на копирование строки: «скопируй X». По картам внимания видно, что в промежуточных слоях внимание концентрируется на небольшом наборе позиций, и несколько следующих байтов раз за разом обращаются к одним и тем же агрегированным точкам. Эти точки ведут себя как границы кусочков текста, причём возникают даже в строках, где убраны все пробелы. То есть байтовая модель сама строит внутренние чанки: изобретает токенизацию, только неявную.
Дальше жёсткая проверка. Исследователи принудительно сжали работу семи промежуточных слоёв из 28 (это 25% сети) до представлений вчетверо меньшей длины. Параметры не трогали, дообучения не было. Байтовая модель почти не заметила интервенцию: качество на всех задачах осталось около исходного. Та же операция на subword-модели ломает результат почти на всех интервалах слоёв. Иерархия local-global не обязана быть зашита в архитектуру, как в BLT. Она вырастает сама.
Сложность распределена неравномерно
Если посмотреть на распределение потерь по байтам, картина у двух семейств резко разная. У байтовой 1B модели 23,3% байтов предсказываются почти бесплатно (потеря ниже одной тысячной бита), у subword-1B таких байтов 1,5%. Зато в хвосте у байтов 7,43% дорогих байтов с потерей выше четырёх бит против 2,35%, и трудные позиции жмутся к границам выученных чанков. Около нуля плотность байтовой модели приближается к кривой 1/x со степенным показателем от минус 0,97 до минус 0,91, у subword показатель мягче, от минус 0,8 до минус 0,6. Токенизатор сглаживает обе крайности: он склеивает лёгкие байты с соседями, поэтому у обычных моделей меньше и бесплатных предсказаний, и дорогих.
Проверка на внешних моделях: у публичных байтовых BLT-1B и H-Net распределения почти совпадают с результатами авторов, а среди обычных моделей доля почти бесплатных байтов не дотягивает и до 11%. И ещё одна деталь. Если усреднить байтовые потери внутри интервалов, нарезанных subword-токенизатором, разница почти исчезает. Значит, всё дело в группировке информации, а не в том, что байтовая модель принципиально умнее.
Практический вывод: дополнительные шаги не одинаково дорогие, поэтому их можно проверять пачками. В симуляции спекулятивного декодирования черновик на 200M параметров принимает у байтовой модели 90,6% токенов против 74,1% у subword. Принятых токенов за один проход целевой модели 9,527 против 2,831, в 3,37 раза больше. С черновиком на 50M картина такая же: 84,6% против 62,0% и 5,471 против 1,618. А по принятым байтам паритет: 9,527 против 9,523. Короткие токены компенсируются высокой долей приёма.
Что это значит
После прочтения картина честная: токенизатор пока не умер. При равных FLOPs subword дешевле, а байтовому оптимуму нужно от 1,5 до 3 раз больше данных на параметр, что плохо ложится на сценарии с дефицитом данных. Но направление понятно: длина последовательности превращается из дефекта в ресурс, а абстракции модель добывает сама. Авторы предлагают смотреть на три оси вместе: длина (сколько шагов приходится на текст), обученная абстракция (что модель склеивает из байтов) и распределение вычислений (куда эти шаги уходят).
Дальше напрашивается мультимодальность: единый входной алфавит убрал бы трение между модальностями и примирил текст, код и бинарные форматы. Это заявка на будущее, а не готовый результат, но заявка логичная.
Часто задаваемые вопросы
Байтовые модели быстрее обычных?
Нет, сами по себе они дороже: последовательность вчетверо длиннее, и все эти шаги нужно посчитать. Смягчают картину два фактора. При масштабировании байтовый оптимум сдвигается к моделям поменьше с большим объёмом данных, а лёгкие шаги проверяются пачками: спекулятивное декодирование принимает в 3,4 раза больше токенов за проход.
Заменит ли это токенизаторы?
Не в ближайшее время. При одинаковом бюджете вычислений subword пока выигрывает, а байтовому варианту нужно от 1,5 до 3 раз больше данных на параметр. При этом результат не маргинальный: выигрыш растёт вместе с масштабом и данными, а 40% на задачах вроде CUTE говорят, что ниша у байтовых моделей есть уже сейчас.
Что за внутренние абстракции они находят?
Локальные чанки. Модель сама назначает позиции, в которых агрегирует информацию о соседних байтах, и переиспользует их при генерации. Сжать четверть промежуточных слоёв до этих представлений можно без потери качества, чего не выдерживает ни одна subword-модель.
Итог
arXiv 2610.05978 переворачивает привычную рамку: длина последовательности это не только счёт за вычисления, но и способ эти вычисления потратить с пользой. Байтовые языковые модели выигрывают у subword при масштабировании по параметрам, сами строят локальные абстракции и распределяют сложность так, что большинство дополнительных шагов оказываются дешёвыми. Полностью без токенизаторов мир пока не останется, но планка для них поднялась.
Если хочется копнуть в соседнюю тему, почитайте разбор Mamba и state space моделей: там ту же проблему длины решают через архитектуру, а не через гранулярность входа.