Что такое Library of Layers и зачем менять порядок слоёв
Library of Layers (LoL) - архитектура Transformer, которая выбирает порядок выполнения слоёв во время инференса под конкретную задачу. В обычной языковой модели слои всегда идут в одной последовательности, зафиксированной при обучении. LoL переставляет их на лету, поэтому один и тот же набор трансформерных блоков складывается в разные вычислительные цепочки для разных входов.
Работа выложена на arXiv 2 ноября 2026 года: arXiv 2611.03526, первый автор Abdellah Rahmani, всего шесть соавторов. Это исследование, а не готовый движок инференса. Авторы показывают идею, претрейн на текстовых данных и серию экспериментов, где видно: выбранный порядок слоёв меняет то, как модель решает задачу.
Формулировка из аннотации: существующие архитектуры языковых моделей всегда выполняют свои слои в одном и том же порядке, а LoL упорядочивает их динамически. Разница принципиальная. Глубина и последовательность блоков перестают быть константой архитектуры и превращаются в решение, которое принимается на каждом запросе.
Аналогия простая. Обычная LLM похожа на конвейер, где станции жёстко закреплены и идут строго по порядку. У LoL порядок станций можно менять под конкретную задачу, и от этого меняется маршрут обработки. Сами блоки остаются прежними: те же механизмы внимания, те же MLP. Меняется только последовательность их выполнения.
Чем LoL отличается от обычного Transformer
В dense-модели граф вычислений фиксирован: токен проходит через слой 1, слой 2 и так далее до последнего, и все запросы получают одинаковую вычислительную траекторию независимо от сложности. LoL сохраняет блоки, но меняет их порядок: маршрут подбирается под вход.
Идея стоит рядом с адаптивными вычислениями, где модель тратит разное количество compute на разные примеры. Акцент отличается. Там речь обычно идёт о том, сколько слоёв выполнить или какие пропустить, здесь - о том, в каком порядке их выстроить. Родственный разбор есть в материале про метод PoLar, который для каждого запроса пропускает или повторяет предобученные слои, формируя индивидуальную программу выполнения.
Граница важна для практики: LoL не патч поверх готовой модели. Порядок слоёв нужно выучить, поэтому модель проходит претрейн в этой парадигме, а не получает динамику перестановкой весов уже обученной LLM.
Как работает LoL: глобальная библиотека блоков и роутер
Архитектура собирается из двух компонентов. Первый - глобальная библиотека трансформерных блоков, общий пул блоков, из которых строится вычислительный путь. Второй - роутер (маршрутизация слоёв): он решает, какой блок из библиотеки выполнять следующим. Порядок не прописан заранее, он складывается под конкретный вход.
Библиотека работает как набор инструментов, а роутер - как мастер, который подбирает инструмент под задачу. Если библиотека меньше числа выполняемых шагов, блоки переиспользуются: один и тот же блок может отработать несколько раз в разных местах цепочки. Если библиотека большая, маршруты получаются разнообразнее и разреженнее.
Выходы роутера доступны для анализа. В работе на них строят probes, то есть дополнительные классификаторы, которые обучают поверх сигналов маршрутизации. По тем же сигналам можно вмешаться в маршрут и задать его вручную. Маршрутизация перестаёт быть чёрным ящиком: её видно и ею можно управлять.
Что даёт единственный гиперпараметр - размер библиотеки
У LoL один гиперпараметр: размер глобальной библиотеки трансформерных блоков. Других переключателей в описании нет, и это ключевая особенность метода. Один регулятор двигает модель по шкале между переиспользованием параметров и разреженностью.
Маленькая библиотека означает, что блоков мало и они ходят по кругу: уникальных весов меньше, память под них скромнее, зато вычисления становятся глубже и однообразнее по составу блоков. Большая библиотека даёт больше уникальных блоков и разреженные маршруты, где на каждом шаге задействована лишь часть параметров. По описанию авторов, этот диапазон позволяет переходить между переиспользованием параметров и разреженностью без смены архитектуры.
Практический смысл в том, что выбор между «мало параметров, больше последовательных вычислений» и «много параметров, меньше активных вычислений на токен» превращается в настройку одного числа, а не в переписывание модели.
Место LoL среди dense, depth-recurrent и MoE
Три базовые архитектуры, с которыми сравнивают LoL, решают разные части одной задачи: как распределить параметры и FLOPs, то есть память под веса и вычисления на токен.
- Dense (плотные архитектуры). Фиксированная глубина, все параметры задействованы на каждом токене.
- Depth-recurrent. Блоки переиспользуются по глубине: одна и та же группа параметров отрабатывает несколько шагов.
- Mixture of Experts (MoE). Разреженность вычислений: на каждом шаге активируется часть экспертов из общего пула.
| Архитектура | Что экономит | Чем платит |
|---|---|---|
| Dense | Простотой: один граф для всех запросов, предсказуемые батчинг и кэширование | Полный набор параметров и все FLOPs на каждый токен, глубина задана заранее |
| Depth-recurrent | Памятью под веса: блоки переиспользуются по глубине | Меньшим разнообразием параметров и большим числом последовательных шагов через одни и те же веса |
| MoE | FLOPs на токен: активна только часть экспертов | Памятью под все параметры, а также накладными расходами на маршрутизацию и балансировку нагрузки |
| LoL | Гибкостью: один гиперпараметр двигает баланс между переиспользованием блоков и разреженностью | Выбором маршрута на инференсе и усложнением вычислительного графа |
Тезис авторов: размер библиотеки обобщает компромиссы параметро- и FLOPs-эффективности всех трёх архитектур в одном семействе. При претрейне на текстовых данных LoL показывает конкурентные результаты с dense, depth-recurrent и MoE. Численных значений в доступном описании работы нет, поэтому сравнивать подход с бейзлайнами по конкретным метрикам пока не с чем.
Как выглядит переиспользование блоков по глубине на практике, разобрано в отдельном материале про 20B Looping Model: там та же идея повторного прохода через одни и те же слои применяется ради эффективности обучения.
Что показывают эксперименты: от судоку до безопасности
Эксперименты в работе разбиты по сценариям, и каждый отвечает на свой вопрос.
- Претрейн на тексте. LoL даёт конкурентные результаты с тремя бейзлайнами: dense, depth-recurrent и MoE. Базовая проверка того, что динамический порядок не ломает качество.
- Судоку и лабиринты. На синтетических данных модель применяет разные порядки слоёв для разных стратегий решения. Один класс задач, разные подходы, разные маршруты.
- Вмешательство в маршрутизацию. Если задать маршрут вручную, модель применяет к конкретному экземпляру задачи нужную стратегию.
- Многоязычный сценарий. LoL выбирает разные паттерны порядка слоёв в зависимости от языка и письменности.
- Safety data. Модель обучена на данных о безопасности, и probes по выходам роутера с высоким AUROC отличают безопасный текст от небезопасного.
Последний пункт интересен сам по себе: сигналы роутера содержат информацию, связанную с содержанием текста, а не только с его синтаксисом. Точное значение AUROC в описании не приводится, так что речь идёт о качестве разделения «высокое», без числа.
Почему вмешательство в роутер - ключевой аргумент
Наблюдение «разные задачи дают разные порядки слоёв» само по себе допускает возражение: возможно, это побочный эффект, а решение принимается где-то ещё. Эксперимент с вмешательством закрывает эту дыру. Если принудительно заданный маршрут приводит к ожидаемой стратегии решения, значит порядок слоёв действительно управляет вычислением, а не просто коррелирует с ним.
Отсюда вырастает практическая линия: управляемое рассуждение. Маршрут можно не только наблюдать, но и назначать, например чтобы заставить модель решать задачу конкретным способом или проверить, как она поведёт себя при другом порядке блоков. Для исследователей интерпретируемости это удобная точка вмешательства.
Что это значит для оптимизации инференса LLM
Работа отвечает на вопрос «можно ли так устроить модель», а не «сколько токенов в секунду это даст». Данных о латентности и пропускной способности на реальном железе в описании нет, поэтому переносить выводы на продакшн-инференс рано. Всё, что ниже, - следствия из устройства метода, а не измеренные результаты.
Экономия ресурсов: где она может появиться, а где нет
Потенциал виден в двух местах. Переиспользование блоков при маленькой библиотеке сокращает число уникальных весов, а значит, и требования к памяти под параметры - это интересно тем, кто запускает модели локально на ограниченной VRAM. Разреженные маршруты при большой библиотеке уменьшают число активных параметров на токен, что сказывается на FLOPs.
Взамен появляется роутер, который работает на каждом шаге выбора. Его вычисления не бесплатны, и в описании работы их стоимость не измерена. Итоговый баланс «сэкономили на слоях, потратили на маршрутизацию» зависит от реализации, а публичной реализации на момент выхода статьи нет.
Второй эффект касается качества ответов. Порядок слоёв под задачу может помочь там, где одна фиксированная глубина плохо подходит разным типам запросов. Пока это гипотеза, подкреплённая синтетикой и многоязычным сценарием, а не замерами на пользовательских задачах вроде кода, RAG или агентных цепочек.
Поэтому на вопрос «даст ли LoL ускорение моей локальной LLM» честный ответ такой: неизвестно. Сначала нужны замеры латентности и памяти, потом разговор про практику.
Ограничения и накладные расходы: о чём работа умалчивает или говорит прямо
Маршрутизация на инференсе стоит вычислений. Каждый шаг выбора блока - это дополнительная работа поверх самого блока, и в описании она не количественно не оценена. Утверждать, что LoL быстрее dense-модели сопоставимого качества, оснований нет.
- Нужен претрейн в этой парадигме. LoL не надевается на готовые веса как адаптер или лора. Модель изначально обучается с библиотекой и роутером, поэтому для существующих открытых LLM подход напрямую не применим.
- Динамический граф усложняет инфраструктуру. Разные маршруты у разных запросов означают разный порядок блоков в одном батче. Привычные оптимизации, рассчитанные на фиксированный граф, потребуют переработки, и это придётся решать инженерам, а не авторам архитектуры.
- Границы эксперимента. Проверка ограничена претрейном на текстовых данных, синтетическими судоку и лабиринтами, многоязычным сценарием и данными о безопасности. Про другие домены и масштабы модель не заявлена.
- Метрики названы качественно. «Конкурентные результаты» и «высокий AUROC» даны без чисел, поэтому сравнивать LoL с альтернативами по таблицам пока нельзя.
- Заявление о будущем. Формулировка про модели, которые сами собирают вычислительный граф, - перспектива авторов, а не продемонстрированный результат.
Отдельный вопрос - стоимость анализа маршрутов. Probes обучаются поверх выходов роутера, то есть для интерпретации нужен дополнительный этап обучения. Это дёшево по сравнению с претрейном, но добавляет шаг в пайплайн.
Кому следить за направлением и что делать дальше
LoL авторы позиционируют как шаг к моделям, которые динамически составляют собственный вычислительный граф под задачу. Обещание - более эффективное и управляемое рассуждение. Пока это направление, а не продукт.
Читать оригинал стоит исследователям архитектур и тем, кто занимается инференсом: там есть механика библиотеки и роутера, эксперименты с вмешательством и связка с safety-анализом. Инженерам, которые считают бюджет латентности, полезно держать идею в голове как альтернативу MoE при планировании моделей, но без расчёта на скорый выигрыш.
Смежные направления разобраны в материале про looped transformers и другие архитектурные идеи для LLM: они атакуют ту же проблему стоимости вычислений, только со стороны повторного использования слоёв, а не их перестановки.
Если задача - просто запустить локальную LLM на своём железе, LoL ничего не меняет. Это исследовательская архитектура, а не рантайм, и на скорость генерации в привычных инструментах она сегодня не влияет.
Конкретный следующий шаг: открыть arXiv 2611.03526, прочитать раздел с синтетическими задачами и вмешательством в маршрутизацию, затем следить за воспроизведениями и независимыми замерами латентности и памяти. Появление таких замеров и станет сигналом, что подход выходит из категории «интересная идея» в категорию «инструмент для инференса».