Какой-то привлекающий внимание релиз от Kwaipilot (раньше не слышал про них) – 32B и 72B модели, выбивающие на SWE-bench Verified 62.4% и 74.6%, причем используя дефолтный swe-agent. А это уже так-то уровень gpt5 codex high анонса openai. Пока что есть только блогпост, в котором раскрыли чуть-чуть деталей, но не столько, сколько хотелось бы. Обучение выглядит уже по классике: base → mid-train → SFT → RFT → RL. Расскажу, что, на мой взгляд, есть интересного:

– Обычно награда на стадии RL строится так: за успешное прохождение тестов дается +1, за неудачное — 0. Есть альтернативы, когда считается похожесть сгенерированного патча на golden patch (то есть изменения, взятого напрямую из pull request-а), так делали например, в недавней работе CWM от FAIR или в SWE-RL. Здесь авторы предлагают другое. Во время RFT они собирают с помощью людей “teacher trajectories”, которые используют потом во время RL для того, чтобы считать отклонения от хорошего поведения. Это отклонение и выступает в роли награды. Если траектория во время RL становится сильно не похожей ни на какую траекторию из ground truth, то она удаляется. На мой взгляд, идея интересная, но возникает много вопросов, возможно хорошее направление для ресерча.
– Написано довольно размыто, но, по-видимому, авторы агрегируют все траектории в префиксное дерево, где узел – это префикс, который может встречаться сразу в нескольких траекториях. А далее это дерево прунят по каким-то критериям, чтобы оставить самые ценные узлы. Мотивация здесь может быть следующей: тк контексты в моделях большие, а награда всего одна в конце, то апдейты на каждом шаге – вещь довольно шумная. За счет прунинга дерева траекторий, можно выкидывать какие-то маловажные части контекста. Но тут слишком мало информации, чтобы делать выводы сложнее. Хотя направление опять же прикольное.
– В mid-train ребята запихнули кучу данных с гитхаба, куда я думаю точно вошел SWE-bench Verified. Он обязательно войдет, если напрямую не делать деконтаминацию. Поэтому хочется посмотреть на качество модели на более свежем бенчмарке.

Пока, кстати, читал блогпост, увидел, что 2 недели назад на лидерборде Verified новый лидер – 78.8% с моделью Doubao-Seed-Code от bytedance. Со дня на день увидим очередной релиз значит.

Together выложили заметку про их подход (ATLAS) к использованию адаптивного спекулятора – пример того, в какую сторону можно развивать классическую идею спекулятивного декодирования, чтобы выжимать бОльший перформанс в практических кейсах.

Классический speculative decoding заключается в следующем: мы обучаем легкую модель-драфтер предсказывать сразу много токенов наперед. Далее основная модель может делать быструю верификацию этих токенов: вместо того чтобы авторегрессионно генерировать по одному токену за шаг, она получает от драфтера целую последовательность (например, 5-10 токенов) и проверяет их все параллельно за один forward pass:

1. Основная модель вычисляет, какие токены она бы сама сгенерировала на каждом шаге.
2. Сравнивает свою последовательность с предложенной драфтером.
3. Принимается самый длинный отрезок-префикс, в котором предсказания совпали.
4. Если драфтер угадал все, например, 5 токенов, мы получаем 5 токенов за один проход основной модели.
5. Если совпал только первый, а на втором ошибка — принимается этот один токен, а следующий за ним генерирует уже основная модель.

Эта схема гарантирует, что качество генерации не страдает, и результат всегда идентичен тому, что выдала бы основная модель. Это направление уже довольно сильно развилось от оригинальной статьи до Medusa (учим отдельные головы на каждый следующий токен) и EAGLE 1/2/3 (там чуть сложнее и в EAGLE-3 подход сильно поменялся по сравнению с первой версией). Насколько я понимаю, EAGLE-3 – сота или около сота сейчас в целом.

В блогпосте Together пытаются решить проблему статичности, так как обычно спекулятор хорош в тех задачах, на которых его обучали. ATLAS добавляет совсем маленький, но обучаемый драфтер предсказывать токены, более подходящие под конкретный контекст. Далее поверх двух спекуляторов стоит controller, который на основании уверенности предсказаний, во-первых, выбирает, из какого спекулятора брать драфты токенов, а, во-вторых, определяет, сколько токенов наперед сейчас имеет смысл предсказывать.

Недавно удалось чуть-чуть погрузиться в Tinker (спасибо коллеге, который сделал обзор). Помимо общего положительного впечатления, одна вещь в дизайне платформы мне особенно понравилась – имплементация поддержки кастомных лосс-функций.

Пару слов о Tinker – это API, которым вы пользуетесь для обучения LLM. Вы пишете скрипт с подгрузкой данных и логикой обучения (включая лосс и эвалы), но весь инференс и обучение (sample, forward, backward, save_model) происходят на серверах Thinking Machines. То есть вы можете запустить скрипт на локальном компьютере с CPU и хорошим интернетом и на нем тюнить DeepSeek. Точнее, не весь DeepSeek, а только лоры. На это есть любопытная причина: для высокой утилизации GPU нужны большие батчи, особенно для MoE, а с лорами можно эффективно инференсить все еще одну LLM для пользователей с разными тюнами. Небольшой тред от одного из разработчиков Tinker в эту же тему. Вот пример скрипта, как может выглядеть обучение SFT.

Так вот по умолчанию Tinker дает доступ к трем лоссам: cross_entropy, importance_sampling и ppo, но вы можете заимплементировать любой свой, который будет принимать на вход (data: tensor, logprobs: tensor). Первое, что ожидаешь увидеть в таком случае – пользовательский код будет сериализовываться и отправляться по сети исполняться на сервере. Но здесь появляется очень элегантное, на мой взгляд, решение: forward_backward_custom. Forward_pass с сервера возвращает вам логпробы, по которым вы локально считаете лосс и производные, но только dLoss/dLogprobs (весов-то у вас нет). Далее, при вызове backward, сервер еще раз делает forward, считает новый лосс sum(logprobs * dLoss/dLogprobs) и по нему апдейтит веса модели. Цена за это – два forward pass’а и, как следствие, 1.5x FLOPS на шаг. Но зато Тинкеру не нужно вообще никак связываться со сторонним кодом.

Другое интересное архитектурное решение – это Clock Cycles, но об этом возможно напишу в другой раз.

Фича Gemini 3 Pro, про которую я говорил в посте выше. Прикрепляя ссылку на ютуб, оно нативно подается на вход и пишет число токенов, которое тратится. На 2-2.5 часа уходит примерно 700-800к токенов, то есть близко к пределу в 1M.

Очень нравится разгребать видео, которые давно лежат и вроде хотелось бы посмотреть, но не так сильно, чтобы тратить столько времени.

🎄 Релизим 67 074 траектории Qwen3-Coder с OpenHands + 2 RFT чекпоинта.

> Мы выкладываем: 67 000+ траекторий по 3 800 решенным задачам в 1 800+ Python репозиториях.

> Примерно в 3 раза больше успешных траекторий и в 1.5 раза больше репозиториев, чем в нашем прошлом датасете.

> Траектории длинные: в среднем 64 шага, до 100 шагов и контекст до 131k токенов.

> RFT на этих данных, SWE-bench Verified:
Qwen3-30B-Instruct: 25.7% → 50.3% Pass@1.
Qwen3-235B-Instruct: 46.2% → 61.7% Pass@1.
Также сильный рост на SWE-rebench September (цифры в блог посте)

> Мы сделали много эвалов.
прогнали OpenHands с лимитом 100 и 500 шагов.
Запускаем на SWE-bench Verified и сентябрьском SWE-rebench.

> Мы отдельно проверяем тесты, которые пишет модель.
Считаем, как часто тесты корректны.
Проверяем, как часто финальный патч модели проходит ее собственные тесты.
В итоге получаем пул данных в том числе для обучения верифаеров.

Полностью Permissive License
Датасет и модели: https://huggingface.co/collections/nebius/openhands-trajectories

Подробный блогпост: https://nebius.com/blog/posts/openhands-trajectories-with-qwen3-coder-480b

Пост в x: https://x.com/ibragim_bad/status/2003423706861936856

P.S. Прошу поддержать пост в x, если у вас есть аккаунт!