Последние пару месяцев я плотно работал над этим релизом, и наконец-то мы выкатываем его в опенсорс!

📟 Встречайте SWE-rebench-V2: самый большой открытый, мультиязычный датасет для обучения кодовых агентов!

Вместе с командой Nebius AI R&D мы построили пайплайн для масштабного сбора задач из реальных GitHub репозиториев и теперь делимся всем с комьюнити. На текущий момент это самый большой и разнообразный открытый датасет подобных задач в мире.

Что внутри:
> 32 000+ задач — на базе реальных issue + готовый Docker-образ.
> 20 языков программирования. Некоторые языки (например, Lua или Clojure) вообще никогда раньше не были покрыты!
> 120 000+ дополнительных задач, собранных на базе реальных PR.
> Качество — задачи отфильтрованы и размечены с помощью ансамбля LLM. Также мы обогатили их метаданными и добавили интерфейсы, которые проверяются в тестах.

Вместе с датасетом мы дропаем техрепорт со всеми деталями нашего пайплайна и прогонами моделей.

📄 Статья и датасет

👾 Наш Discord (мы там онлайн, залетайте с фидбеком и вопросами).

✉️ Пост в X

Если есть любые мысли, идеи, предложения - приходите!

🔁 Буду благодарен за репост и пересылку!

Возвращаюсь с ICLR и хочу поделиться одним наблюдением, которое мне показалось интересным. Из множества разговоров с авторами и просто ребятами, делающими ресерч, вижу такой паттерн: очень большое кол-во работ и текущих исследований направлено в сторону lossy inference optimization. Под lossy имею в виду методы, которые не гарантируют сохранения качества исходной модели – то есть такого же распределения токенов. В целом вообще никаких гарантий нет: глобально мы хотим ускорить/сэкономить на памяти и не просадить качество. На другой стороне есть lossless подходы. Примеры для понимания:

• Lossless: speculative decoding – мы на уровне алгоритма гарантируем, что токены получены из такого же распределения, что и большая target модель.
• Lossy: routing в более слабые модели, когда нам кажется, что они справятся +- так же.

Так вот, направление lossy – это большая кроличья нора: speculative decoding с ослабленными условиями верификации, компрессия KV cache, merging экспертов в MoE, всякие early exits во время forward pass, разного рода квантизации – в общем, там есть, куда разгуляться.

При этом многие, занимающиеся подобными направлениями, одновременно много времени уделяют гранулярным эвалам: раз все эти методы не гарантируют сохранения качества, нужно супер детально понимать, где и когда качество падает сильно. И это тоже на самом деле нетривиальная задача. По ощущениям, эта связка становится очень большим направлением современного инференса – когда за скорость и цену приходится бороться с минимальными деградациями.

На неделе у нас был очень классный reading club по статье Coupling without Communication and Drafter-Invariant Speculative Decoding, из которой хочется поделиться одной интересной концепцией.

Но для начала стоит сказать про Gumbel-Max trick – способ семплировать из категориального распределения. Стандартный путь такой – считаем softmax над всем словарём и семплируем сам токен. Обе процедуры могут быть достаточно дорогими. Gumbel-Max делает следующее: к логитам прибавляем шум из распределения Gumbel(0, 1) и просто берём argmax. Математически это эквивалентно семплированию из softmax распределения, но при этом:

- softmax можно не считать вообще
- шум не зависит от логитов, его можно подготовить заранее, пока модель делает forward pass
- из коробки получается top-k семплирование (Stochastic Beams and Where to Find Them)

Теперь про идею Gumbel Coupling и ее применение для спекулятивного декодинга. Идея в том, чтобы использовать один и тот же gumbel шум при семплировании из драфтового и таргетного распределений. В таком случае можно записать корректный алгоритм с оценкой на acceptance rate, который будет просто сравнивать два токена между собой: токен от draft и target моделей. И вот тут получаются две интересные истории:

1. Не нужно материализовывать драфтовые логиты. В классической схеме верификации rejection sampling работает с обоими распределениями p и q одновременно, то есть драфтовые вероятности надо тащить через всю фазу верификации. С Gumbel coupling решение можно принимать, имея на руках только argmax от драфтера.
2. Воспроизводимость генерации. Вот это прям супер прикольно! В стандартной схеме итоговый сэмпл зависит от обоих распределений: меняется драфтер – меняется и то, что итоговая модель насемплит, даже при фиксированном seed. Получается, что чисто техническая оптимизация инференса влияет на то, что выходит из модели. С Gumbel coupling это свойство восстанавливается: при фиксированном seed выход не зависит от того, какой драфтер используется (и используется ли он вообще). Естественно, при условии, что все остальные источники недетерминизма мы победили (Defeating Nondeterminism in LLM Inference).

В презентации есть ещё иллюстрации к самому coupling-у, разбор алгоритма в vLLM и отсылки в сторону Speculative Speculative Decoding.

По горячим следам добавили Opus 4.8 xhigh, картина теперь такая

На следующей неделе я буду на 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 и прочие релевантные темы, то будет здорово вас увидеть. Мест у нас немного, поэтому конечно сможем позвать далеко не всех

Какое-то время назад открыл для себя, насколько CISPO робастнее к выбору гиперпараметров по сравнению с DAPO и насколько он по дефолту работает лучше в async режиме. На async в 64 шага дефолтный DAPO деградирует безумно сильно, да и на 16 уже заметно

Для Qwen3 30B MoE картина та же, только коллапс в async происходит еще раньше из-за проблем с разным роутингом экспертов

Еще немного интересных наблюдений из 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-ем рекомендую полистать блогпост, там много чего интересно помимо реплеев