Потестил Gemini 4 Argon: новый "Opus" от Google? Пару дней назад у Google вышла новая модель - Gemini 4 Argon. Так как я в США и сижу на тарифе Ultra, мне она прилетела сразу и с хорошими лимитами. Эти несколько дней я плотно гонял ее по рабочим и бытовым задачам: писал код, работал с документами, делал ресерчи, обсуждал видео-игры. Еще до релиза мне попадалась новость про внутренние тесты Google - мол, сами сотрудники говорили, что по ощущениям модель очень похожа на Claude Opus. После своих тестов могу это подтвердить. Вот только похожа она на Opus не только в своих плюсах, но и в минусах. Argon так же, как и Opus, получила способность решать комплексные, нетипичные задачи, но вместе с этим стала очень медленной. Единственный жирный плюс на фоне антропиков - лимиты здесь не улетают со скоростью света. По моим наблюдениям, модель сливает какое-то невероятное количество токенов на ризонинг. Она слишком долго думает даже над простыми вещами, по десять раз все дабл-чекает и заходит с разных сторон. Объективно: для большинства задач такая тяжелая артиллерия просто не нужна. При этом я специально переключал уровни reasoning effort (думал, может, дело в том, что стоит medium или high), но нет - на всех трех режимах она думает одинаково долго. От такой траты токенов объективно ничего, кроме чувства вины за сожженный компьют я не получил. Пример с кодом: от абсурда до восторга Сейчас пилю лендинг. Цветовое оформление вынесено в отдельный файл стилей. Мне не понравился один оттенок, и я просто попросил модель поменять его на другой. Argon решала эту задачу 23 минуты. Вместо того чтобы просто заменить цветовой код, она все 23 минуты размышляла о природе этого цвета, почему он там вообще оказался, какой оттенок лучше подобрать, и параллельно прочесала цвета вообще во всех файлах проекта. И только после этого сделала то, о чем я просил. Модель как будто учили на текстах Войны и Мира Толстого 😅️️ Для контраста дал ей сложную задачу: собрать форму регистрации с базой данных, прикрутить почтовые рассылки и настроить отбивки о новых регистрациях в Telegram. Плюс попросил предварительно поресерчить, какие вообще есть решения под это дело. Вместе с подробным ресерчем и написанием кода все заняло 17 минут. А следом закинул баг, который до этого у меня так и не смог починить Opus. Argon ковыряла его 45 минут - и пофиксила. И вот для такой задачи это время уже кажется абсолютно оправданным. Короче, паттерн очевидный: модель дико усложняет простые вещи, но отлично тащит там, где реально надо подумать. Что с визуалом и UX Пробовал использовать ее как спарринг-партнера по дизайну. У меня стандартный пайплайн: я текстом накидываю идеи и прошу предложить несколько вариантов того, как может выглядеть блок (сначала просто концептуально, без кода), а потом понравившиеся варианты уже собираю в коде. И тут что модели от Anthropic, что OpenAI, что новый Argon - все одинаково фиговые. То, что они предлагают с нуля, на мой вкус выглядит довольно примитивно. На бумаге описание звучит неплохо, но когда доходит до визуализации, вылезает куча проблем: текст не читается, контролы кривые, иерархия плывет. В этом плане дизайнеры пока могут спать спокойно. Но связка начинает работать, когда включаешь собственную насмотренность. Если закинуть в модель даже неудачный визуальный концепт (хоть сгенеренный ей же итерацией ранее) и прямо ткнуть носом: "здесь не читается шрифт, а тут кнопка странного размера" - вот тогда она выдает красивый, рабочий результат. Но сама, без твоей экспертизы и явных указаний, она на эти косяки внимания не обратит. Где модель реально тащит В ресерче и задачах формата "сходи туда, достань то, проанализируй и собери в структуру". Если нужно забрать какие-то внешние материалы, вытянуть из них суть и на основе этого написать код или документ - справляется отлично. Ответы стали заметно четче, модель лучше работает с источниками (особенно если прямо в промпте попросить на них опираться). Поймал себя на том, что в связке с Argon сейчас открываю обычный Google Search чаще, чем Perplexity. Модель ощущается более агентной и самостоятельной. И снова к вопросу о том, нужны ли нам тяжелые модели Не так давно я уже писал в канале, что для повседневной рутины флагманские модели нам не нужны, а легкие сетки в связке с человеком работают куда эффективнее. И вот тесты очередного топового релиза заставляют меня снова вернуться к этой мысли. Глядя на Argon, я еще больше убеждаюсь: в компаниях нужно целиться не в слепую автоматизацию функций, а в точечное усиление людей, у которых уже есть высокая экспертиза. Потому что на задачах, где я четко понимал, чего хочу, с Argon у меня уходило в 3-5 раз больше времени, чем с обычным Gemini Flash. Легкая модель через несколько быстрых итераций с участием человека дает результат быстрее и лучше, чем попытка сразу делегировать задачу тяжелой сетке. Поэтому на практике весь этот опыт сводится к фильтру из двух простых вопросов перед выбором модели: 1. Понимаю ли я конечный результат в деталях? Если у меня в голове уже есть четкое видение результата - проще, качественнее и в разы быстрее сделать это через легкий Flash. Если же есть только точка А и размытая точка Б без понятных ограничений и требований - тогда иду в Argon. 2. Шарю ли я сам в этой теме? Если это знакомая задача, которую я делаю регулярно - снова берем быструю модель. А вот если нужно залезть в новый рынок, незнакомый тип задач или пофиксить сложный баг в коде, где не хватает собственной экспертизы - тут имеет смысл отдать задачу Аргону. Кто уже успел пощупать обнову - как вам скорость и результаты? 🚀 Влад Корнышев про AI и создание AI-продуктов

Решающие модели (System 1) #decision #rlcd huggingface.co/orcarouter/OrcaSAQ-2-27B - OrcaSAQ2 27B: высокоточный reasoning в файле 12.3GB huggingface.co/orcarouter/OrcaSAQ-2-Cyber-27B-Uncensored-GGUF - OrcaSAQ2 Cyber: без цензуры, 15.7GB huggingface.co/akhilaaa3/Jev-Omni - Jev-Omni: решения по тексту, картинкам, аудио и видео разом huggingface.co/fastino/GLiNER2.5-Decide - GLiNER2.5-Decide: оценка любого набора меток за один проход, без генерации токенов huggingface.co/SupersonicLabs/Julia-1 - Julia 1: 144M параметров, контекст → чёткие решения huggingface.co/Contrastive-LM/CLM-v0.1-8B - CLM-v0.1-8B: вместо медленных верификаторов — эмбеддинги состояний и действий Скорость и кванты #optimization #gguf #dflash huggingface.co/harshatheg/Qwen-2.5-1B-RLCD - RLCD: извлекает структурированные данные в 7 раз быстрее на Apple Silicon huggingface.co/z-lab/Qwen3.8-27B-DFlash2 - Qwen3.8-27B DFlash2: ускоренная генерация (drafter-модель) huggingface.co/sirus/Qwen3.8-27B-heretic-ara-MXFP6-MXFP8-DFlash2-GGUF - новый формат кванта MXFP6/MXFP8 + DFlash2: быстрее инференс huggingface.co/Edge0/Edge0-35B-A3B-preview - Edge0-35B-A3B: модель «телефонного» класса, работает в 3 GiB памяти Агенты и инструменты #agent #toolcalling huggingface.co/XingChen-AGI/Xing4.0-29B-A4B - Xing4.0-29B-A4B: агентные задачи на Ascend NPU, контекст 256K huggingface.co/TokenRhythm/NeoHorse-1-4B - NeoHorse-1-4B: роутинг-обвязка, прокачивает Qwen3.5-4B huggingface.co/apodex/Apodex-1.1-mini-GGUF - Apodex-1.1-mini: агентные задачи по файлам и данным huggingface.co/nex-agi/Nex-N2.5-Pro - Nex-N2.5-Pro: агент для кодинга и работы с компьютером huggingface.co/nex-agi/Nex-N2.5-mini - Nex-N2.5-mini: длинные агентские задачи с vision-обратной связью github.com/ortegaalfredo/ngram-knowledge-injector - инжектор фактов в память Qwen3.8 через n-gram huggingface.co/TheOneWhoWill/Coding-Monkey-Gemma-GGUF - Coding-Monkey: локальная модель с сильными тул-коллами huggingface.co/pipecat-ai/phonellm-alpha-1 - phonellm: держит телефонных агентов в рамках диалога Мультимодальность и контекст #multimodal huggingface.co/deepseek-ai/DeepSeek-V4-Flash-Vision-Exp - DeepSeek-V4-Flash Vision Exp: экспериментальный мультимодальный вариант huggingface.co/Agnes-AI/Agnes-2.5-Pro-Alpha - Agnes-2.5-Pro: рассуждения на миллион токенов github.com/QLNI/SHADOW-250M-Instruct - SHADOW-250M: архив 100M токенов ужат до 60MB файла Код и всякое #coding huggingface.co/ornith-ai/Ornith-1.5-9B - Ornith-1.5-9B: #reasoning и кодинг на одной GPU huggingface.co/ornith-ai/Ornith-1.5-35B-A3B-GGUF - Ornith-1.5-35B-A3B: GGUF под локальных кодинг-агентов huggingface.co/openbmb/MiniCPM5-2B - MiniCPM5-2B: карманная модель, кодит и рассуждает huggingface.co/IFM/K2-Horizon-MoVA-36B-A4B - K2-Horizon-MoVA: 36B всего, активно 4B huggingface.co/XHToken/Spark-X2.5-4B - Spark-X2.5-4B: компактная универсальная 4B (гибридное внимание, 1M контекст) #compact huggingface.co/thesysdev/OUI-1 - OUI-1: диффузионная генерация UI-экранов за ~секунду #gui huggingface.co/LessThanThreeAI/Qwen3.8-27B-Humanlike-Chat-GGUF - Humanlike-Chat: живой, реалистичный ролеплей huggingface.co/TheDrummer/Artemis-31B-v1.1 - Artemis-31B: креативное мышление поверх Gemma 4 Chat huggingface.co/OBLITERATUS/Qwen3.8-27B-OBLITERATED - Qwen3.8 27B полностью без цензуры #uncensored huggingface.co/superwhisper/s1-mini - S1-mini: превращает неразборчивую речь в текст #ASR

✔️ Kimi поймали на следах Claude: модель могла обучаться на его скрытых рассуждениях Исследователи нашли способ восстанавливать зашифрованные reasoning-блоки закрытых моделей и решили проверить, помнят ли другие LLM эти скрытые цепочки. Самая сильная аномалия оказалась у Kimi-K3. Если дать Kimi начало конкретного рассуждения Claude, модель продолжает его намного точнее, чем другие LLM. В некоторых тестах разница доходила примерно до шести порядков. На примере с Opus 4.8 это видно особенно хорошо: Kimi получает несколько первых токенов скрытого reasoning и дальше идёт почти по той же логике решения. Без этой подсказки рассуждает иначе. Это ещё не доказательство того, что Moonshot напрямую использовала приватные данные Claude. Но выглядит так, будто Kimi могла видеть похожие скрытые траектории во время обучения. Модель могла перенять сам способ решения задач. https://x.com/kotekjedi_ml/status/2087147093735714919 #AI #Kimi #Claude #LLM

XYZ-Aquila-mini: компактная reasoning-модель для глубокого веб-поиска XYZ AI Lab выпустила XYZ-Aquila-mini под Apache 2.0. По заявленным результатам модель лидирует среди open-weight моделей до 40B сразу на нескольких поисковых бенчмарках: * GAIA - 97.1 * DeepSearchQA - 89.5 * BrowseComp - 78.8 Модель заточена под длинные цепочки планирования, поиск по англоязычному и китайскому вебу, проверку источников и восстановление после ошибок при работе с инструментами. Контекст до 256K токенов. Отдельно интересен их подход AI4AI: люди задают цели, ограничения и критерии качества, а ИИ-агенты сами разбирают ошибки и предлагают контролируемые изменения для post-training. Модель: https://modelscope.ai/models/XYZAILab/XYZ-Aquila-mini

🧪 Метод и эксперименты В данной работе фокусируются на 2-битном weight-only-сжатии ризонящих моделей. В аппендиксе есть эксперименты с FP4, со сжатием активаций и KV-кэшей. Квантизуют модели Qwen3-8B / Qwen3-32B через GPTQ. Оказывается, что квантизация сильно меняет поведение трейсов ризонинга: 🔄 Число циклов резко возрастает, особенно для меньшей модели. 📏 Многие трейсы не вписываются в заданный лимит токенов. ⚠️ Блок <think> часто оказывается незакрытым. 💡 При этом сам ответ появляется в среднем чуть ли не раньше в трейсе, но модель его не выводит. 📈 Длина ризонинга сильно увеличивается. Из этого следует, что, кроме просадки качества, мы ещё теряем в эффективности из-за того, что генерируем больше токенов. Как и в прошлой статье, замечают, что длина ризонинга у квантизованных моделей обратно коррелирует с качеством. Причина как раз в этих зацикливаниях. При этом результат сильно зависит от выбора задачи: на ризонинг-бенчмарках типа AIME / GPQA-Diamond эффект сильно заметен. На простых задачах — ARC-C, ARC-E, PIQA, WinoGrande — просадка и в 2 битах очень умеренная. Вообще, я думал, что эти бенчмарки likelihood-based и гоняются с выключенным <think>. Вводят четыре режима деградации качества: 🟢 Стабильный. Без заметной просадки. 🟡 Заметная, но умеренная просадка. Трейсы ещё не ломаются, но есть нарушения в плане фактологии и commonsense. 🟠 Значительная деградация. Генерация часто не завершается. 🔴 Полный коллапс. В первую категорию попадает Qwen3-32B на простых задачах. По мере усложнения задач и уменьшения размера модели растёт степень деградации. Дабы как-то подлечить просадку, предлагают два решения: 📝 (+P) FP16-модель пишет план, а квантизованная исполняет. Это заметно поднимает качество и правит многие ошибки ризонинга, но точность всё ещё ощутимо ниже базовой модели. 🔁 (+L) Loop Rescue. Если модель зацикливается, но выдаёт ответ, выписываем промежуточный ответ. Если ответа нет, просим FP16-модель сгенерировать его с нуля. На простых задачах смысла в этом не так много, так как и просадки, и зацикливания нет. Но на сложных задачах и ризонинг укорачивается, и качество заметно улучшается. На простых задачах end-to-end speedup с учётом длины генерации находится в районе 2×, а на сложных — несколько процентов с просадкой порядка 20% в среднем. 📌 Выводы Занятная и интересная стратегия по выправлению ризонинга. Для production-grade-системы, понятное дело, просадки качества слишком велики, но и 2-битная квантизация без свистоплясок — это действительно тяжёлый случай. Интересно было бы дообучить квантизованную модель через какой-нибудь RL с penalty на циклы.

Подборка об RL и ризонинге Рассказываем об улучшении RL для сложных задач, оптимизация в RLVR одной строкой кода (!) и обучении компактной модели для дипресёрча. Reuse your FLOPs: Scaling RL on Hard Problems by Conditioning on Very Off-Policy Prefixes При обучении RL на сложных задачах есть две основные проблемы: 1. Большинство роллаутов — wrong, поэтому положительные примеры для основной части задач не появляются. 2. Сложно дообучать модель, когда так мало положительного сигнала. Улучшение происходит скорее за счёт роста общей «умности» модели на более простых тасках. Авторы предлагают метод Prefix-RL, который как раз направлен на решение сложных задач: 🔴Для них семплируются ответы, и из всех семплов выбирается правильный ответ. 🔴Собираются prefixed problems: промпт + префиксы правильного ответа. 🔴На обучении модель видит исходную задачу и набор prefixed problems и учится продолжать хорошую цепочку. Получается метод, который консистентен с on-policy RL, обладает высоким sample efficiency и может ускорять self-improvement. По замерам авторов, Prefix-RL в сравнении с mid-training SFT + GRPO прокрашивает AIME 2025 больше чем на 12 пунктов при том же компьюте на обучении. Проводят аблейшен на Llama, добавляя в prefixed problems генерации Qwen. Это даёт около +5% при том же компьюте относительно Prefix-RL на prefixed problems инит-модели. Получается что-то похожее на эффективную дистилляцию во время RL. Back-generalization — один из важных выводов статьи. Обучение на цепочках с префиксами улучшает решение задач без них, то есть модель при обучении не попадает в зависимость от подсказок. При этом back-generalization позволяет модели писать начало ответа не той стратегией, что была в префиксах на обучении. Хотя автор сказал, что в агентском обучении аналогичный метод они не пробовали, он хорошо обобщается на агентский сетап: в роли префикса выступает часть траектории. Maximum Likelihood Reinforcement Learning Кликбейт: поменяйте строчку в расчёте advantage, замените std в нормировке на mean в своём RLVR — и всё полетит. Проблема в целом стандартная: GRPO учит модель максимизировать среднюю награду (pass@1), а не вероятность успеха. Из-за этого он «залипает» на лёгких задачах и почти не учится на сложных. В RLVR средний reward — это аппроксимация вероятности правильного ответа (так как награда 0/1). Предлагают взять log p (логарифм вероятности правильного ответа) и разложить его в ряд Маклорена по pass@k — вероятности получить «хотя бы один верный из k независимых семплов». Получается бесконечная сумма вкладов от одной, двух, трёх попыток и так далее с весами 1/k. MaxRL берёт усечение этого ряда до вычислительного бюджета g, то есть размера группы в GRPO. Чем больше семплов N на инференсе, тем выше truncation T ряда и тем ближе к точному ML. Если на пальцах, метод даёт меньше внимания группам, где решаемость уже высокая, и больше смотрит на сложные. MaxRL даёт до 20× прирост эффективности test-time scaling относительно GRPO, Pareto-доминирование по pass@1 и pass@k и лучше масштабируется с данными и вычислениям. Попробовать метод можно дёшево: если уже есть RLVR, достаточно поменять одну строчку в расчёте advantage. Но работ, которые пытаются решить эту проблему, много, и пока непонятно, какая идея окажется лучшей. DR Tulu: Reinforcement Learning with Evolving Rubrics for Deep Research Популярный постер на конференции. Ребята смогли получить лёгкую модель дипресёрча с крутым качеством за счёт генерации и обновления рубрик. Изначально при обучении модели давали небольшое количество хорошо написанных рубрик. После каждой итерации обучения смотрели на изменения в ответах, для них генерировали дополнительные рубрики и джаджем оценивали их качество. При этом генерация рубрик и оценка тоже выполнялись лёгкой моделью. За счёт этого цикла получилось обучить модель собирать больше полезной информации и не галлюцинировать. В итоге сделали лёгкую модель (8B), которая по качеству сравнима с топовыми моделями дипресёрча. Увидели интересное ❣ Даниил Кириллов, Тимофей Смирнов, Иван Дёгтев #YaICML2026 Душный NLP

Вышла полезная работа про то, почему reasoning-модели становятся сильнее после обучения. Авторы пишут, что дело не только в размере датасета. Для reasoning важнее другое: есть ли у модели понятная проверка, где она справилась, где ошиблась и почему. Обычная пара «вопрос → ответ» даёт мало сигнала. Она показывает результат, но не показывает процесс: какой шаг был неверным, какой вызов инструмента помог, где модель восстановилась после ошибки, какой judge подтвердил решение. Поэтому хороший обучающий пример для reasoning должен хранить больше контекста: саму задачу, действия модели, проверку результата и метаданные о том, откуда взялся пример. Проверка бывает разной. В математике и коде можно использовать точные тесты. У агентов можно смотреть, справился ли он в окружении. В более размытых задачах приходится подключать людей или model-judge. Отдельно авторы предупреждают о популярных ошибках. Длинная цепочка рассуждений не всегда полезна. Сложные задачи не всегда улучшают конкретную модель. Большой датасет может выглядеть внушительно, но всё равно плохо покрывать нужные навыки. Для agent data особенно важно сохранять всю «грязную» траекторию: неудачные действия, повторные попытки, исправления, изменения состояния и финальную проверку. Часто именно там лежит самый ценный обучающий сигнал. Итоговый подход такой- обучать reasoning-модель не на красивых ответах, а на проверяемых попытках, где видно, что сработало, что сломалось и почему это можно использовать для обучения. Paper: A Primer in Post-Training Reasoning Data: What They Know About How It Works https://arxiv.org/abs/2606.02113