Гречневые мысли

Выводы: - Эксперимент очень интересный, в первую очередь тем, что гипотеза провалилась, но результаты превзошли мои ожидания. Такое бывает и я даже рад, что так получилось — значит inductive bias надо искать где то в другом месте. - Даже с такими маленькими модельками (17 + 1.2 = 18.2М) параметров можно получить генерализацию в таком, казалось бы, сложном домене, как код. Круто! - Мне очень понравилось играться с архитектурами. Я не написал ни строчки кода руками, правда, но это всё равно было очень прикольно. Как будто я снова трогаю визуализации в курсе Intro to ML на кеггле, только масштаб визуализации побольше. - Данные суперважны. Модель на StarCoder выдавала скоры только с pass@100, модель, обученная на синте, выдавала 0.65 на pass@1 EASY и ненулевые скоры на MEDIUM, HARD и даже HumanEval. - Самый странный вывод всего эксперимента — что бы я ни делал с архитектурой, около 40% генераций стабильно падали с exec_error. SwiGLU научил модель чаще писать синтаксически валидный код, но почти не сдвинул failure mode модели. Похоже, тут надо крутить уже не в архитектуру, а данные или параметры декодинга. Код обучения и создания датасета доступны у меня на гитхабе, сам датасет и веса моделей лежат на хфе, а слоповый репорт от клода — у меня на сайте. Улучшайте, повторяйте, вдохновляйтесь, вайбкодьте.

Пример простой неудачной генерации: # Prompt def subtract(a, b): """Return a minus b.""" # Generation def subtract(a): return a - a Пример сложной удачной генерации: # Prompt def unique_sorted(xs): """Return the sorted list of distinct elements of xs.""" # Generation def unique_sorted(xs): return sorted(set(xs))

Вот табличка с результатами. Я дополнительно попробовал сделать модели чуть большего размера — 3.7M параметров — но не получил особенно большого прироста качества относительно некоторых других рецептов обучения. Что интересного: 1. Warm start (обучать декодер, потом подключать к нему энкодер) не дал статистически значимого прироста на скорах. Я думал, что даст. 2. Модели относительно стабильно решали задачи вне своей обучающей выборки. Даже на 12 задачах из EASY, у которых был жаккард < 0.30 с трейном (то есть, на задачах, у которых в трейне не было близких соседей), модель получает 0.48 pass@1. Больше того, на MEDIUM и HARD тоже скоры были ненулевые, а их в трейне точно не было — генерализация! 3. SwiGLU в моём сетапе тащил. Добавление второго пути в MLP даёт самый большой прирост из всех. 4. Я думал, что надо семплировать более длинные функции для датасета, чтобы модель училась генерить более длинный код и не завершать функции преждевременно — и оказался неправ. Uniform sampling, где эта фича была выключена, показала немного более высокие скоры, чуть за границами CI. 5. Decoder-only ваще ничё не решает и не учится. Даже несмотря на то, что энкодер зафрижен, эмбеддинги от него очень сильно помогают пониманию моделью текста. Я потыкал руками, декодеры просто пишут PAD PAD PAD. Не слишком удивительно, но интересно, что оно не научилось даже генерить gibberish. 6. Энкодер-декодер работает лучше, чем Llava. Oh well, жаль, а у меня такая красивая статья есть про llava-лайк текстовые модели... 7. В эту табличку не попало, но обученные на StarCoder модели получали такие скоры на EASY только в pass@100 режиме. Pass@100! Вот что делает хорошо подобранный датасет :) 8. Серия экспериментов FACTORIAL сравнивает, насколько вообще наше изначальное предположение — что ограничение размера токенизатора — поможет модели. Результат: yе поможет. Модель с BPE токенизатором на 2048 токенов на нормальной архитектуре не отличается по скорам от модели с маленьким токенизатором.

Данные я решил сделать синтетические. Я, конечно, провёл несколько экспериментов предобучением моделей на сабсемпле из Starcoder, но каждый раз получалось, что модель училась импортировать модули и циклиться, а писать более сложную обработку семплов мне было впадлу. Вместо этого я выбрал 6 семейств для типов задач — арифметика, работа со списками, etc — и два специальных семейства: compositional и conditional, где я совмещал задачи из первых шести семейств, делая новые, более сложные задачи с большей композиционной глубиной. Например, решение одной из задач в compositional семействе было sum(abs(b) for b in xs), sorted(xs)[::-1]), то есть совмещение семейств list_transform, list_scan и arithmetic_scalar. Кроме того, для каждого семейства я руками придумал по 15 темплейтов. Темплейт это тройка "инструкция", "код" и "оракул" вида: canonical_instruction: "given two integers a and b, return the absolute value of {{ c1 }} times {{ v1.d }} {{ op.d }} {{ c2 }} times {{ v2.d }}" code: | def f(a, b): return abs({{ c1 }} * {{ v1.v }} {{ op.v }} {{ c2 }} * {{ v2.v }}) oracle: "abs({{ c1 }} * {{ v1.v }} {{ op.v }} {{ c2 }} * {{ v2.v }})" В которые я мог подставлять операции, значения и так далее из какого-то param space и проверить через оракула. Такая система дала мне 120 темплейтов, из каждого темплейта я смог насемплить по 30 инстансов задач (3600 задач), у них я перефразировал описания по 20 раз через Qwen3-4B (72000 задач), которые я мутировал по 8 раз через AST. После дедупликации у меня получилось примерно 507 тысяч семплов с тестами, сгенерированными через оракула. Часть выкинул, оставил 141к семплов — на этом я и учил свои модели. В качестве эвала я сделал HumanEval-лайк бенч с тремя сабсетами: EASY, MEDIUM, HARD. Отличаются они друг от друга, как нетрудно догадаться, сложностью задач — например, в EASY может быть задача "проверить на чётность", в MEDIUM "вернуть сумму чётных чисел", а в HARD — "вернуть произведение первого и последнего элемента массива". В качестве недостижимой верхней границы я взял HumanEval — всё таки задачи там на три порядка сложнее моих и вообще, только 91 из 164 задач описывается моим токенизатором. Сопоставимого размера модельки получилали в своё время там в районе 1-2%. Кроме того, важно было посмотреть не только как модель решает задачи, но и как конкретно она их не решает. Поэтому я ввёл шесть категорий решений: format_ok (всё ок), bad_format (не проходит запуск из-за ошибки синтаксиса), stub_body (пустой боди функции с pass), test_fail (не проходят тесты, но всё ок), timeout (таймаут), exec_error (ошибка исполнения). Сабсет EASY был самым простым не только из-за низкой композициональности, но и потому что 10 из 20 задач покрывались датасетом. Это была в том числе такая проверка — насколько модель вообще выучила то, что я в неё лью. При этом важно, что покрыты были именно названия задач, то есть промпты, а не сами по себе темплейты. Я специально вычистил это из трейн сета через жаккардову близость, так что проверка была относительно честная: у модели были иные решения, чем в тесте, но были похожие задачи. Вторая половина задач в EASY, а так же MEDIUM и HARD сабсеты были сделаны для проверки генерализации модели; если модель решала там задачи, то класс, мы видим генерализацию.

Как то, утром в конце апреля, когда я стоял в душе и думал о высоком, я вспомнил про этот проект и, в качестве разминки для мозгов, я решил подумать, как мы можем сделать из подобной штуки нечто относительно полезное. Ограничение: ради сохранения шарма, я решил, что моя "полезная" языковая модель должна иметь не больше чем 1.2М параметров и весь эксперимент не должен длиться больше часа на моих ресурсах. Не так давно я читал лекцию по DL в Сколтехе и затронул тему inductive bias — а что если мы будем строить архитектуру исходя из предположений о структуре данных? К примеру, картинки локальны и фичи в них инвариантны к расположению, поэтому ядра свёрток в CNN тоже локальны (ограничены своим размером) и применяются где угодно (потому что, ну, ядро одно). Так мы расплачиваемся обобщающей способностью за более лёгкое обучение модели — а значит, получаем более высокое качество на меньшем числе данных, но OOD по нам будут бить больнее. Так как я ограничен числом параметров, применить inductive bias в дизайне моей архитектуры было логичным решением. Поэтому я решил повторить трюк с ограничением словаря из Z80-μLM и зафиксировал домен — функции на питоне. Это достаточно полезный домен, бенчмарки на нём уже есть, я смогу сравниться с бейзлайнами (бейзлайны, правда, будут из начала 20-х, но у меня игрушечный проект, мне можно) и, что самое главное, в питоне оказывается всего лишь 35 ключевых слов. Получается, чтобы я мог генерить простейшие программы на питоне, мне нужно: - 35 токенов под ключевые слова (async, def, for, while, return, yield, etc.) - 26 токенов под английский алфавит - 10 токенов под цифры - 22 токена под операторы (:(){:|:};: и так далее) - 4 структурных токена (NEWLINE, INDENT, DEDENT, STR_QUOTE) - 3 спецтокена (PAD, BOS, EOS) Итого выходит 98 токенов. Разумеется, в питоне есть ещё и стандартные библиотеки, которые этими токенами не покрываются, да и на вход от юзера текст передаётся в виде текста — так что надо что-то придумать, чтобы это работало и не раздувало контекст через character based encoding. Выход оказался прост: я могу делать AST parsing входа, доставать оттуда функции, заменять все литералы на однобуквенные и передавать так в модель. При генерации, модель генерирует однобуквенные литералы, а я потом после декодинга дополнительно детокенизирую, подставляя туда то, что пришло от юзера. Кроме того, чтобы обработать весь вход от юзера и не раздуть контекст, мы можем использовать эмбеддинг от какого-нибудь готового энкодера: он и так умеет понимать текст, он имеет длинный контекст и мы его не обучаем — так что число обучаемых эмбеддингов остаётся малым. Итого, архитектура получилась следующей: ettin-17m в качестве компрессора входа в один входной токен и крохотный декодер трансформер в качестве генератора. Кроме того, я попробовал сделать EncDec вариант — сделать кросс-аттеншн между ettin и декодером + SwiGLU + RoPE и потом учить уже такую штуку. Ну и, разумеется, я покрутил разные варианты архитектуры (число голов, хидден, глубину), растягивая и стягивая модель от 570k параметров до 1.2М.

Про крохотные кодовые модели *этот длиннопост я пишу уже третий месяц — наконец то дошли руки его закончить и выложить* Как я уже писал, I have a soft spot for broken and puny things. Не так давно мне попалась на глаза новость, где кто-то обучил ллм для Z80 — такого восьмибитного процессора из середины 80-х. Для того, чтобы полноценный трансформер уместился и работал в ограничениях памяти процессора, который лишь на десять лет младше моих родителей, авторам пришлось применить много интересных технических решений: QAT в 2 битах, инференс в int16 (потому что другой математики в процессоре добиться сложно) и, что самое прикольное, ограничение размера токенизатора. В современных трансформерах словари огромны. В e5-base, например, токенизатор содержит 30522 токенов, в multilingual-e5-small взят словарь от xlmr, так что там 250037 токенов и так далее. Это означает две вещи: во первых, если у модели в токенизаторе много токенов, то ей будет надо больше данных, чтобы все эти токены увидеть в разных контекстах и собрать статистики. Во-вторых, большой токенизатор означает большую LM Head и большой эмбеддинг слой. И как бы пофиг на это, это же просто lookup table, но хоть e5-small от multilingual-e5-small архитектурно отличаются лишь токенизатором*, число параметров там 33M против 117M. Поэтому авторы Z80-μLM сделали токенизатор character based и рекомендовали структурировать датасет как одно слово. Например: > hello HI > are you real MAYBE Это, с одной стороны, сильно ограничивало полезность такой ллм (ну а кому оно надо если честно), но, с другой стороны, давало неплохую экспрессивность. Это уже не if-else, оно давало ощущение того, что что-то внутри есть и это что-то вполне себе не против с тобой пообщаться. Прикольно. *когда-то я хотел запрунить multilingual-e5-small и сократить размер токенизатора там и в процессе выяснилось, что прунинг блоков трансформера почти не даёт выигрыша в памяти — потому что 91M это эмбеддинги. Когда-нибудь я про это расскажу.

ICML 2026 Волею судеб я оказался на ICML 2026 в сеуле (если вы тоже — приходите на тусу Яндекса или Сбера пообщаться) и я имею сказать: уровень статей тут почему-то очень низкий. На AI Evaluation Oral Session было четыре доклада, половина из которых была…

Скорость префилла, генерации и использующаяся память на разных контекстах.

Про совсем компактные модели Мне нравится идея крутить локальные модели, но не нравится идея забивать всю память ими. Мне всегда казалось, что самый лучший способ сделать подобную edge модель — попробовать создать что-то, что будет достаточно умным, чтобы мочь делать выводы из данных, но не иметь собственных знаний. Да и зачем модели собственные знания, когда есть тривиально настраивающийся поиск в интернете и тулколлинг? Мои коллеги из AIRI подумали о том же и сделали Optimal Cognitive Core, про который я уже писал — затюненные reasoning версии Qwen-3-0.6B и Qwen-3-1.7B, которые оптимизированы под работу с внешним контекстом и RAG. Модели в целом подходят под мои требования к железу — веса занимают 1.2 и 3.4 гб в их родном BF16, ещё столько же на длинный контекст (так как это Qwen3, там GQA, это вам не модный нынче гибрид), итого, с пивком потянет. Другой вопрос, что эти модели слишком малы, чтобы быть применимыми для general purpose задач — всё таки это 600M и 1.7B dense. В этом размере обычно бывают забавные попугаи, который могут делать парафразу или простенькую классификацию после файнтюна, но не более. Следующий способ ужать модель в память моего MacBook Air M4 — использовать квантизацию. Тут отличились PrismML, сделав Bonsai-27B, бинарный- и тернарный кванты Qwen-3.6-27B. 27B модель в тернарном кванте занимает всего 7.2 гб после запуска инференса и вполне себе бегает на маках. К сожалению, Qwen-3.6-27B это dense модель, так что на моём маке она уж совсем медленная — если верить тому, что я нашёл в сети, генерация там будет в районе 13-14 токенов в секунду, чтение контекста — 100-150 токенов в секунду. Кроме того, это QAT (или вообще PTQ, подробностей мало), причём который скорее всего не затачивали на русский — так что я не ожидаю, что итоговая модель за пределами своего калибрационного сета/сета, на котором делали QAT сможет показать что-то интересное. Буквально в ответ на Bonsai появился Maple-Preview. Это 20B A1B MoE, которую специально затачивали под локальный инференс на маках ещё на этапе проектирования архитектуры, обучая свою модель с нуля в тернарной точности — то есть это не квантизация чьей-то модели. В итоге, получилась модель размером в 5.31 гб, 7.5 гб с учётом 131к контекста — почти в полтора раза меньше, чем бинарный квант Bonsai — который выдаёт аж 218 токенов в секунду на M4 Mac Mini и 127 токенов в секунду на iPhone (каком — непонятно). Модель практически не знает русского, да и в целом, мало знает (путает, в какой игре босса зовут Psycho Mantis), но если дать ей поиск, она вполне себе справляется с ответами на простые вопросы. Бенчей по тулколлам они не дают, в целом, понятно почему — я прогнал Tau-2 (в качестве user sim я использовал Qwen3-235B-A22B-Instruct-2507), на Airline скор 0.48, на Retail 0.175, на Telecom 0.427. Это не соннет и тем более не квен, но на то это и Maple Preview, они специально пишут, что учить модель на агентов будут дальше. При всех плюсах квантизации, это всё ещё почти половина доступной мне памяти. Поэтому есть ещё и третий способ как снизить использование оперативки: выгружать все веса на SSD и стримить экспертов у MoE с диска. Уже есть turbo-fieldfare, который запускает Gemma-4-26B на маке с использованием всего 2 гб памяти и есть Mference, форк turbo-fieldfare, который расширяет поддержку на Qwen-3.6-25B, DeepSeek V4 Flash и Inkling-Small 276B. Оно действительно использует очень мало памяти, но ценой того, что скорость генерации и чтения контекста падает до десятков токенов в секунду. Кажется, Apple делает что-то похожее в своей новой Siri, правда, активируя экспертов на весь промпт, а не на токен как в этих фреймворках. И тут появляется интересная идея — а что если мы возьмём Maple Preview, которая суперэффективная, с маленькими экспертами и обучавшаяся в тернарной битности, и внесём её в Mference? Так мы сможем, в теории, получить ещё меньшее использование памяти и относительно нормальную скорость генерации — потому что модель оптимизировалась под это на этапе архитектуры. Сказано — сделано. Спасибо кодексу и моей подписке за 200$, спустя 20 часов и 30% от недельного лимита я получил паритет с официальной имплементацией на teacher forced top-10 токенах в The Raven Эдгара Аллана По. Модель, в зависимости от контекста, занимает от 500 до 1200 мб памяти (!), на MacBook Air M4 читает и генерит со скоростями 40 и 20 тпс соответственно, может дёргать тулы и генерить текст. Такое не жалко оставить всегда включённым в фоне — кушать не просит, пусть лежит, если надо спрошу, он ответит. Попробую дотащить до мейна потом, но сейчас уже можно попробовать запуститься в моём форке на гитхабе. Зачем это нужно? Имхо, есть два режима использования подобных моделей. Первый — интерактивный чат. Там важно, чтобы модель отвечала быстро и имела низкий латенси. Второй — когда модель в фоне, почти не используя память и не мешаясь остальным модулям системы, что-то анализирует — классифицирует сообщения, достраивает граф знаний, фильтрует почту, пишет сводку, что-то медленно ресёрчит в интернете. Во втором режиме требований к латенси нет, так что скорости в 20 тпс вполне себе достаточно. Ну а чтобы переключиться из одного режима в другой, нужно всего лишь загрузить всю модель в оперативку с SSD — что делается довольно быстро, буквально за пару секунд. Если модель умеет в тулколлы — Maple Preview умеет не слишком хорошо, но на то она и Preview — то можно строить агентные пайплайны без требований к латенси и всегда иметь умного помощника, готового к работе оффлайн даже на старых телефонах. И это прекрасно — мне было бы очень приятно, если бы будущее было локальным. Код Суперинтересный пост от DeepGrove про то как они дизайнили модель

При проверке некоторой гипотезы столкнулся с очень странным артефактом: у подозрительно многих моделей возникают сложности с ответом на вопрос про типы столовых приборов. Модели постарше, такие как mistral-tiny, рассказывают про шприцы для лимонада (?), зонтики…

Визуализации скоров, графики соотношения качества/скорости решения/стоимости/числа сгенерированных токенов и отчёт от кодекса по экспериментам. Видно, что все по некоторым рубрикам Luna немного проседает на более высоких reasoning effort, но блин, учитывая стоимость (=траты лимитов в более дешевых вариантах подписки), оно того стоит. И это прекрасно! PHD Level Intelligence наконец то появился не за 120$ за миллион токенов.

А чем вайбкодить? Вышла GPT-5.6 и появился вопрос — кому мне платить 100 баксов в следующем месяце: Anthropic или OpenAI? Я их меняю и просто пользуюсь лучшим вариантом из двух, но как UI мне Codex нравится значительно больше. Да и в целом, интересно было бы проверить как работают новые модели от OpenAI. Чтобы ответить на этот вопрос, я взял ту самую задачу из поста про локальные модели и запустил генерацию через Haiku 4.5, Sonnet 5, Opus 4.8, Fable 5 (харнесс — Claude Code, везде reasoning effort high) и GPT-5.6 Sol/Terra/Luna (харнесс — codex, сетка эффорта от low до max). Потом отправил Codex делать ревью имплементаций в надежде получить красивые графики качества/времени выполнения задачи/числа токенов и понять, что является парето-оптимальным. Дополнительно я закинул несколько опенсорсных моделей, которые клеймят, что они близки к сота моделям — GLM-5.2, Kimi-K2.7-Code, MiniMax-M3, DeepSeek V4 Flash/Pro внутри opencode — чтобы посмотреть, насколько эти клеймы подтвердятся на практике. Результаты: 1. GPT-5.6 Terra как будто бы не находится на парето фронтире.. Luna дешевле почти в три раза, но почти такая же по качеству на тех reasoning effort, где есть смысл их использовать, а Sol справился лучше. Sol high = Luna xhigh по скору и по времени выполнения Клод ни в одном из четырёх случаев не лучше и не быстрее 5.6 — конкретно для кода он хуже предложений OpenAI “Дешёвые” предложения OpenAI не хуже “дорогих” и вполне себе good enough Единственная конкурентоспособная опенсорсная модель — GLM-5.2, но по времени ответа она на уровне GPT-5.6 Sol max, будучи в четыре (!) раза дороже сопоставимой по качеству GPT-5.6-Luna. Иногда higher reasoning effort помогал модели составить более эффективный план и решить задачу даже быстрее и за меньшее число токенов. Семь раз померь, один раз отрежь. Это ни в коем случае не scientific eval — я делал один прогон ревью одного решения одной задачи через субагентов кодекса без зафиксированной модели-судьи и не гонял внешних тестов, статзначимости я бы от этого теста не ожидал. Но при этом, получившиеся графики хорошо коррелируют с моими ощущениями от качества работы моделей: GLM-5.2 действительно не опус, а GPT-5.6 мне нравится больше клода. Значит ли это, что надо пересаживаться на Luna? Нет. Модель хорошо будет работать на run задачах (что-то запустить, что-то простое пофиксить, скилл отработать, конфиги написать), коих большинство, но если надо писать что-то с нуля, я всё равно буду пользоваться Sol high. Да и для не кодинговых задач результаты могут отличаться. Но тем не менее, сравнение, имхо, интересное.

Fun fact: ScaleAI и OpenAI соседи по конфе :Р https://readhacker.news/s/6Y7an

ICML 2026 Волею судеб я оказался на ICML 2026 в сеуле (если вы тоже — приходите на тусу Яндекса или Сбера пообщаться) и я имею сказать: уровень статей тут почему-то очень низкий. На AI Evaluation Oral Session было четыре доклада, половина из которых была ни о чём: Position paper (зачем вообще существует этот класс работ?) о том, что в будущем модели бенчами закрываться не будут, потому что это будет незамеряемо (debatable); Бенчмарк про causal thinking, в котором все модели выбивают 70+-2% GPT-5-Mini скорится выше, чем GPT-5.2 xhigh, рандомная модель выбивает 65%, добавление opencode даёт +25% к скорам; Статья про то, что надо эвалить ризонинг трейсы (хорошая, мне понравилась); Статья про поиск “плохих” комплишенов модели через теорвер (тоже неплохая). На постерах я видел как минимум два постера, где авторы в очередной раз переизобрели p-tuning. Ещё была довольно слабая работа про байесы в LLM-судьях, где они подтвердили, что существует position bias, length bias и self enhancement bias (не то чтобы файндинг). К чести авторов, я им показал свои экспы с судьями и их (не)устойчивостью к языковым и некоторым другим байесам (папира на ревью, обязательно про нее напишу потом), они сказали что офигенно и предложили совместную статью сделать. Еще был постер со статьей про способ подсвечивать лик бенча в модель. Автор сказал оч всратую, на мой взгляд, идею — а давайте в бенч неправильные ответы вмешаем и тогда если скор выше чем число ошибок то тест пролит в трейн. На вопрос «а как это переделать под не mcq эвалы а, положим, тау или свебенч» он не нашелся что ответить. Хорошие статьи есть, но как будто бы плохие статьи превалируют над хорошими и приходится выискивать действительно интересный и качественный ресёрч — я не этого ожидал от мейн трека A* конфы. Зато было много крутых чуваков из индустрии. Мне очень понравилось общаться с лидом рл из MAI — он рассказал, что они почти не делают сфт, чисто дистиллируют внутренних доменных экспертов в базовую модель и потом делают онлайн рл. Чувак из Apple очень интересно рассказал как у них работают эвалы — и что они модели тестят по качеству не только на теслах, но и на финальном железе с измеримым диффом в качестве. Гугловские сказали, что на general домене у них была ооооочень большая корреляция между качеством перевода и умением в open ended generation. Опенаи рассказали что скоро будет новый опенсорс (!!!) и дали мне кепочку и носочки с логотипом. Толокеры очень душевно рассказали про их реварды и то, как они варят данные, классные ребята, очень приятные. Пересёкся с челом из Яндекса, который работает на аналогичной мне должности — вечером на афтерпати Яши надеюсь с ним ещё раз пообщаться, он интересное рассказал. Прикольно, что почти все фронтир и субфронтир лабы — MAI, OpenAI, Google, Meta, Apple — используют файнтюны собственных моделей под судей, а не чужие модели с подобранным промптом/тюном. Это интересно, я поспрашивал, говорят, что self enhancement bias не мешает. Получается, что индустрийная часть мне зашла больше, чем научная. Почему? Мне кажется, что это из-за хака KPI по публикациям. Государства вкладываются в ресёрч, ресёрчеров много, у них publish-or-perish. Поэтому любой эксперимент — удачный, неудачный — оформляется клодиком в статью и засылается на конфу. Ревьюеры перегружены, люди кидают статьи в клодик, клодик выдаёт weak accept, статья проходит на конференцию, готово, слоп на постерах. Проблема на самом деле старая, LLM-бум её только масштабировал. А индустрии на эти KPI пофиг. Они в любом случае заплатят за место в sponsored zone, уставшие от статей студенты (например, я) придут к ним за мерчом и оставят свои резюме и реальные лиды реальных команд расскажут про внутрянку — и это офигенно. И эту проблему не решить через ллм ревью, потому что джаджи точно так же хакаются и результат будет таким же. Можно наверное было бы ограничивать число сабмитов от одного автора (заодно научники не смогут вписываться в работы последними авторами без участия в них), но тогда действительно крутых ресёрчеров, которые реально контрибутили в несколько статей сразу огорчат и дропнут из соавторов. В своём прайме я послал две статьи на NAACL, а прямо перед увольнением из AIRI я был соавтором в трёх статьях, в каждой из которых я делал сильно ненулевое количество работы (вполне подходящее под место авторства). Короче грустно это всё, желаю крепких нервов всем, кто остаётся в академии. Я вот ушёл и очень доволен.

GigaChat 3.5 Ultra 432B Выпустили в опенсорс новое поколение нашей модели. Уникального в этом релизе — своя собственная архитектура (MLA + GatedDeltaNet + Gated Normalization — обученных моделей такого скейла с GN до этого в опенсорсе ещё не было), новый претрейн на другом миксе данных, фулл fp8 обучение, не только дпо степ, наконец-то завезли онлайн рл и сильно улучшили арены. Модель похудела на 40% (теперь влезает в одну ноду без tp16) и сильно ускорилась из-за MTP2 и гибридной архитектуры — мы смогли выбить 260 тпс на 8xH100. В этот раз мы решили не ограничиваться только финальным чекпом, выложив еще и кучу служебных — четыре чекпа с разных степов претрейна, два с мидтрейна, один с расширения контекста, один после дпо и два финальных, после онлайн рл — в fp8 и bf16. Теперь вы можете взять нашу модель и доучить её самостоятельно — передаём эстафету коллегам из Яндекса, ждём новую Алису на зелёной базе :) По метрикам — претрейн идёт ноздря в ноздрю с DeepSeek V4 Flash Base, а финальный наш чекп сравним с DeepSeek V3.2. По сравнению с гигой 3.1 у нас сильно улучшились арены, код, агентность, тулколлинг и математика — в общем, меньше, быстрее, сильнее. Из смешных историй, связанных с разработкой, не вошедших в хабр — в какой-то момент на онлайн рл этапе модель смекнула, что можно хакнуть судью, если писать более эротичные ответы. Слава богу отучили, а то получилось бы неловко. В этом релизе я ушёл из SFT команды гигачата, став главой команды метрик. На мне были задачи по выстраиванию нашей инфраструктуры замеров и придумыванию новых бенчмарков — так что если вам не нравится выбор бенчей, который мы замерили, как обычно, приходите к нам его чинить :) HF: https://huggingface.co/collections/ai-sage/gigachat-35 Habr: https://habr.com/ru/companies/sberbank/articles/1055826/