AI[ex]Time

За последнее время пришлось углубиться в спекулятивный декодинг и прочитать с десяток статей. Некоторыми из них, которые показались мне интересными и при этом не базовыми, захотелось поделиться: GRIFFIN: Effective Token Alignment for Faster Speculative Decoding. Во время обучения драфт моделей, у нас происходит training-inference misalignment, потому что во время трейна все токены получены из таргетной модели, в то время как во время инференса токены получаются из драфт модели авторегресионно. Статья предлагает, на мой взгляд, немного костыльный способ борьбы с этим, но сама проблема – интересная, и про нее кажется не так много пишут. Block Verification Accelerates Speculative Decoding. Просто очень классный взгляд на процесс верификации, когда от rejection sampling на уровне каждого токена, мы переходим на уровень целого предсказанного блока. DistillSpec: Improving Speculative Decoding via Knowledge Distillation. Изучает различные виды divergences для дистилляции таргетной модели в драфтерную, все-таки KL loss – не единственный вариант учить такие модели. FR-Spec: Accelerating Large-Vocabulary Language Models via Frequency-Ranked Speculative Sampling. Тк драфт модели сейчас делаются довольно маленькими, language head занимает существенную часть времени во время инференса. Авторы предлагают делать словарь намного меньше, убирая нечастотные токены и для драфтера использовать такие обрубленные словари. Кстати, EAGLE3, которые выходят в опенсорс, часто используют уже эту оптимизацию. Например, популярная коллекция от RedHat. Speculative Diffusion Decoding: Accelerating Language Generation through Diffusion. Очень интересное направление, чтобы для драфтинга использовать диффузионные модели, которые на первый взгляд очень хорошо ложатся в данную задачу, но несут много дополнительных вопросов. По этой статье можно найти еще серию интересных связанных, и уже есть продолжение работы – SpecDiff2. RADAR: Accelerating Large Language Model Inference With RL-Based Dynamic

Возвращаюсь с ICLR и хочу поделиться одним наблюдением, которое мне показалось интересным. Из множества разговоров с авторами и просто ребятами, делающими ресерч, вижу такой паттерн: очень большое кол-во работ и текущих исследований направлено в сторону lossy inference optimization. Под lossy имею в виду методы, которые не гарантируют сохранения качества исходной модели – то есть такого же распределения токенов. В целом вообще никаких гарантий нет: глобально мы хотим ускорить/сэкономить на памяти и не просадить качество. На другой стороне есть lossless подходы. Примеры для понимания: • Lossless: speculative decoding – мы на уровне алгоритма гарантируем, что токены получены из такого же распределения, что и большая target модель. • Lossy: routing в более слабые модели, когда нам кажется, что они справятся +- так же. Так вот, направление lossy – это большая кроличья нора: speculative decoding с ослабленными условиями верификации, компрессия KV cache, merging экспертов в MoE, всякие early exits во время forward pass, разного рода квантизации – в общем, там есть, куда разгуляться. При этом многие, занимающиеся подобными направлениями, одновременно много времени уделяют гранулярным эвалам: раз все эти методы не гарантируют сохранения качества, нужно супер детально понимать, где и когда качество падает сильно. И это тоже на самом деле нетривиальная задача. По ощущениям, эта связка становится очень большим направлением современного инференса – когда за скорость и цену приходится бороться с минимальными деградациями.

Только успели выкатить мини-релиз SWE-rebench с Gemini 3.5 Flash, MiniMax M3 и Junie (теперь на Opus 4.8 high, кстати, топ1 model-harness результат этого цикла: 61.6% resolved / 72.7% pass@5), как сразу прилетел Fable Решил написать небольшой обзор планов на ближайшие релизы лидерборда: – Поэвалили Opus 4.8 в разных reasoning efforts: от low до ultracode с dynamic workflows. Скоро расскажем про трейдоффы качество/цена + какие-то интересные наблюдения из траекторий – Точно будет релиз для любителей локальных моделей: квены, геммы, gpt-oss разных размеров. Если есть популярные модели, которые гоняются на мелком железе и которые было бы интересно посравнивать, пишите, подумаем над тем, чтобы поэвалить тоже – Ну и Fable, разумеется 💀 P.S. Если вдруг знаете кого-нибудь из антропик, кто мог бы помочь с кредитами, напишите плиз в DM @alex_golubev13 😳

На следующей неделе я буду на ICML, в том числе презентовать с командой постеры по нескольким принятым работам: LK Losses и SWE-rebench V2. Приходите к нам на стойку Nebius, на постеры или просто пишите, если хотите выпить кофе и познакомиться В этот раз мы решили провести after-party 9-ого числа https://luma.com/y5x82rk1, с едой, напитками, тихой музыкой и интересными разговорами. Мы приедем большой компанией и можно будет пообщаться с ребятами из ресерча/инжиниринга, обсудить все от агентских пайплайнов, стабильности MoE в RL до кернелов и низкоуровневых оптимизаций LLM инференса. Если вы глубоко погружены в LLM, inference optimization, pre/post-train, agentic evals, environments, agentic harnesses и прочие релевантные темы, то будет здорово вас увидеть. Мест у нас немного, поэтому конечно сможем позвать далеко не всех

Еще немного интересных наблюдений из RL для MoE. В нем есть одна проблема, которая делает обучение гораздо более склонным к нестабильностям. В любом современном RL есть train-inference mismatch, обычно вызванный двумя вещами: 1) из-за асинхронности инференс отстает от трейнера и 2) из-за разной имплементации кернелов/разного железа/неассоциативности сложения (у одной версии dense чекпоинта pi_train(tok) / pi_inference(tok) отличается обычно в четвертом знаке). Однако, в MoE появляется еще один очень неприятный источник такого расхождения: routed experts. Проблема в том, что во время инференса могут активироваться одни эксперты, а во время forward_pass на стороне трейнера – другие, и незначительное изменение в скорах роутера (но достаточное для того, чтобы topK изменился) могут значительно изменить итоговый результат. Основные решения такие: - Просто фризим роутер и уменьшаем асинк ⇒ роутер реже пересекает границу, при которой меняется topK - R2/R3, они же Routing Replays: сохраняем экспертов, активируемых версией модели для инференса и форсируем forward pass через них в трейнере. В статье https://arxiv.org/abs/2512.01374 можно почитать про разницу R2 vs R3 и всякие доп детали. Но проблема в том, что экспертов-то мы форсируем, но скоры роутера меняются, и это может быть проблемой (можно порассуждать на тему, что будет, если инференс версия дала i-ому эксперту высокий скор, а трейнер – низкий) И на самом деле у всех результаты смешанные: у кого-то работает одно, у других – другое. Вчера прочитал https://kiddyboots216.github.io/mismatch/#conclusion-router-replay и увидел еще один способ: Total Router Recall – сохраняем не только экспертов, но и их скоры, а в трейнере фризим роутер. Интересно, что можно предложить способ, при котором мы будем роутер учить, используя скоры и экспертов с инференса, правда работать это будет плохо. В общем, для всех интересующихся RL-ем рекомендую полистать блогпост, там много чего интересно помимо реплеев