Продолжаем обновлять swe-rebench leaderboard, и вчера туда на первое место ворвалась gpt5 с medium reasoning effort. Хочется на этот счет оставить пару комментариев:
1. Как видно из лидерборда, medium effort стоит выше high. Связано это как минимум отчасти с тем, что с high effort модель получается чересчур саморефлексирующей, то есть постоянно перепроверяет себя, повторно тестирует решение и в конце концов упирается в лимит по кол-ву шагов (сейчас это 80).
2. Запуск использовал completions эндпоинт, а с ним есть проблема: ризонинг модели нельзя подать на вход следующего терна, поэтому на каждом шаге модель видит аутпут + тул, но не рассуждения.

Если первый пункт остается под вопросом, то второй мы поправим в ближайшее время. Глобально это означает, что результаты gpt5 могут быть еще выше.

Подробнее про rebench: https://news.1rj.ru/str/AIexTime/121

> Мы раскатываем релиз в прод без анонсов, чтобы проверить, что все ок

> Игорь пишет обзор спустя 15 минут

Для тех, кто все еще не привык смотреть на наличие prompt caching у провайдеров или использовать его. Запуски выше grok code fast заняли 14 долларов с кэшированием. Ровно такой же прогон без вышел бы 66 долларов. Разница больше чем в 4 раза, не требующая никаких телодвижений с вашей стороны. Поэтому а) не забывайте про кэширование и b) старайтесь не отходить без весомой причины от парадигмы append-only context. Об этом сегодня будет следующий любопытный пост.

Рефлексия на тему построения AI агентов от команды Manus, где собран ряд практических советов, как строить контекст, обрабатывать наблюдения из среды, работать с тулами. Любопытно почитать, к какому дизайну пришли авторы после многократных итераций и фидбек лупов. Вся заметка написана через призму использования in-context learning (ICL), то есть упор сделан не на обучении, а использовании мощных уже существующих моделей, где основная задача — правильно собрать контекст: написать хорошие промпты, тулы, решить, какую информацию мы будем помещать туда, а какую нет и тд. Один из первых пунктов звучит так: If I had to choose just one metric, I'd argue that the KV-cache hit rate is the single most important metric for a production-stage AI agent…Keep your prompt prefix stable…Make your context append-only.

За этим стоит понятное объяснение: закэшированные токены ускоряют инференс, снижая time-to-first-token (TTFT), у фронтир моделей почти всегда цена за токены в кэше сильно меньше, что очевидно очень важно для коммерческого продукта (пример с grok code выше). Но, проецируя описанные проблемы еще и на сценарий обучения моделей, я бы добавил один важный момент. Если у нас нарушается линейность траектории и в разных моментах контекст собирается по-разному (такое может быть часто, если мы начнем смотреть в сторону суммаризации предыдущей истории для экономии длины контекста), то мы столкнемся с проблемой во время обучения, а именно не сможем использовать всю multi-turn траекторию, чтобы обучаться на ней за раз. Вместо этого придется дробить ее на отдельные семплы, маскировать префикс и обучаться только на последнем действии, что катастрофически снижает sample efficiency тренировки. Так что нужно помнить, что должны быть действительно весомые причины, чтобы отойти от концепта append-only context. По этой же причине, кстати, неприятно тюнить гибридные модели qwen3, у которых манипуляции с <think> тегами происходят только на последнем шаге траектории.

Вопрос к вам, дорогие читатели: в каких срезах вы считаете важным смотреть на поведение SWE агентов?
Сейчас на лидерборде https://swe-rebench.com мы замеряем способности моделей решать GitHub issues на питоне. Это покрывает лишь малую часть того, что мы понимаем под разработкой. Возможными шагами по расширению бенча могут быть:
- Оценка качества написания тестов (может ли модель написать тест, который падает до и проходит после правильного фикса?)
- Добавление множества языков (например, Java, Go, Rust, etc)

Хочу собрать фидбек на следующие темы:
- Считаете ли вы что-то из вышеперечисленного более приоритетным?
- Если говорить про мультиязычность, то какие языки интересны в первую очередь?
- Какие еще срезы вам кажутся важными в контексте замеров агентов?

Если у вас есть возможность порепостить аналогичный пост в X, то буду признателен. Хочется собрать максимально возможный фидбек от пользователей.

Nvidia Rubin CPX — чипы для ИИ всё более специализируются

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

Из-за такой разницы, на нодах которые занимаются префилом, простаивает самая дорогая часть современных датацентровых GPU — HBM память, которая сейчас составляет 50%+ всей стоимости GPU. К тому же она всё ещё в дефиците и является чуть ли не основным ограничителем производства видеокарточек.

Решение от Nvidia — сделать специальные, более дешёвые, карточки для префила. В качестве памяти — 128 гигабайт GDDR7 (против 288GB HBM4 у VR200), пропускной способность в 2 терабайта в секунду вполне достаточна для префила. Кроме этого экономят на других штуках вокруг чипа — вместо дефицитного CoWoS-L используют более бюджетный FC-BGA, а связываются карточки друг с другом по PCIe вместо NVLink.

Большой плюс — упаковать в одну стойку можно 144 таких видеокарты, против всего 72 GPU в NVL144. При этом такая стойка с Rubin CPX будет не просто иметь больше компьюта, но и кушать меньше энергии.

Так как префил в больших деплойментах и так делают на отдельных нодах, на высоком уровне мало что изменится — просто машины для префила переедут на специальное железо. Главный минус — такие GPU перекидывать между тренировкой и инференсом вряд-ли выйдет, но это явно будет компенсировано разницей в цене и доступности.

@ai_newz

Небольшой апдейт https://swe-rebench.com

Добавили 4 модели: Grok 4, Qwen3-Next-80B-A3B-Instruct, DeepSeek V3.1, Kimi-K2 0905

Из хайлайтов:
- Grok4 ворвался в верхнюю часть лидерборда
- Kimi K2 значительно прибавил и, помимо общего топа, теперь входит в топ3 опенсурс моделей
- DeepSeek шагнул вперед тоже, но не так сильно. Зато посмотрите, сколько теперь токенов он генерит
- Qwen3-Next выглядит очень неплохо для своих A3B, ждем кодер версию

Какой-то привлекающий внимание релиз от 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, но об этом возможно напишу в другой раз.