На этом видео с WWDC 2026 показано, как агентный AI целиком работает на Mac: агент думает, вызывает инструменты, читает файлы, собирает проект - и модель при этом крутится на вашем железе. Без облака, без API-ключей, без счётчика токенов. Что внутри: - три команды - и любой агент (OpenCode, Xcode, свой скрипт) переключён на локальную модель - агент собирает SwiftUI-приложение с нуля за две минуты и сам чинит ошибки сборки - Xcode подключается к локальной модели и исправляет баг прямо в IDE - если модель не влезает в 512 ГБ, её раскладывают по нескольким Mac через Thunderbolt Русские субтитры с подсветкой слов сделали с Claude Code: транскрипция, перевод, вшивание - тоже полностью локально. 13 минут. Сергей Булаев AI 🤖 - об AI и не только

В последнее время появляется все больше историй, когда человек решает какую-то свою зудящую проблему, свалив ее описание и знание нюансов на AI Coding агента. А потом обнаруживается, что еще пара человек готовы заплатить несколько евро в месяц за это решение. Просим агента затеплить на какой-нибудь fly.io, прикрутить прием платежей, и вот вам деньги на новую удочку. Несколько примеров со ссылками на рассказы авторов: MyMarineForecast - автор очень любит лодки. Он собрал с Claude Code приложение-дашборд для морских прогнозов. Через несколько недель и 99 коммитов появились первые платящие пользователи. LOC8 - полицейский сделал удобное приложение-локатор для спасателей. 1500$ в месяц спустя несколько месяцев Plottie - исследователь в биоинформатике, который не умеет кодить, сделал приложение для генерации красивых графиков, которые можно публиковать. Через 25 дней, говорит автор, 2000+ пользователей и 100+ платных пользователей, 1000$ в месяц. InfoDrizzle - мелкое приложение (одно из тысяч) для iOS, которое делает персональный дайджест новостей. Ноль опыта в мобильной разработке, 15$ в месяц расходов на сервер и 200$ в месяц от 28 платящих пользователей, рассказывает DrizzleX3. Поскольку сложность, стоимость разработки и запуска небольших продуктов падает, у людей появляется возможность занимать небольшие ниши, которые раньше пустовали. Состояние там сколотить нельзя, но накопить со временем на интересное путешествие и подарки детям - вполне. А какие продукты пилите вы? Какие проблемы решаете? Какой у вас стэк и какие агенты помогают? Какие затраты в месяц на поддержку всего, сколько пользователей и какая прибыль (если уже появилась и не секрет)? Ваш, @llm_under_hood 🤗

🔥 Perplexity разогнала локальный запуск LLM на Apple Silicon Компания сделала собственный движок Lily специально под Mac и Qwen3.6-35B-A3B без PyTorch и MLX в цепочке выполнения. На MacBook Pro с M5 Max и 128 ГБ unified memory: - prefill: 5749 ток/с - генерация: 186,6 ток/с - в среднем prefill быстрее MLX-LM в 1,23× - decode — в 1,35× Что внутри: - runtime на Rust - собственные Metal-кернелы - MoE-routing остаётся на GPU - оптимизация отдельно под prefill и decode - KV-cache и Gated DeltaNet заточены под Apple GPU - 35B-модель ужата до 19,4 ГБ в 4-bit На длинном контексте отдельная оптимизация attention дала до +40% скорости на 128K токенов. Сам Lily Perplexity обещает скоро открыть. https://www.perplexity.ai/hub/blog/optimizing-on-device-inference-for-apple-silicon

Почему AI автоматически не делает бизнес или продукт лучше и прибыльнее? Инсайт после конференции AGDay от друзей из студии Alto в Екатеринбурге на прошлой неделе. Потому что ключевым фактором успеха по-прежнему остаются компетенции в бизнесе и продукте, а не технические. Когда технические задачи стали решаться в 10–100 раз быстрее, это не сделало автоматически каждого предпринимателя богаче, а каждый продукт — успешнее. Ключевые вопросы всё те же: – кому и что ты продаёшь, – зачем это людям, – как это упаковать, – как продать – и как всем этим управлять. Раньше, пока команда месяцами пилила продукт, с ответами на эти вопросы можно было тянуть. Сейчас код пишется за дни вместо месяцев — и ограничение в продажах, маркетинге, продукте или операционке обнаруживается почти сразу. AI не убрал ограничения бизнеса. Он просто очень быстро передвинул бутылочное горлышко из разработки в другие части компании. Но есть и обратная сторона: без новой скорости разработки и автоматизации до этого горлышка теперь можно вообще не добраться. Технология стала новой нормой, а не преимуществом. А выигрывает по-прежнему тот, кто лучше понимает, что именно делать, для кого и зачем.

Loop the Loopies! Сегодня обсудим статью, которая посвящена моделям Loopies, построенным на шеринге параметров между разными слоями.  Обычно у трансформерных моделей и свёрточных нейросетей отдельные параметры на каждом блоке, благодаря чему объём вычислений и число параметров масштабируются с глубиной. Это даёт гибкость — каждый блок может выполнять специфические задачи. Но при этом с ростом числа слоёв растёт и количество параметров, а значит, модель становится дороже хранить.  Выходом из этой ситуации может стать переиспользование весов по несколько раз за форвард — шеринг параметров. Так не нужно хранить много параметров, однако блок может принимать распределение данных с разной глубины, что усложняет задачу оптимизации.  Перспективность шеринга первым доказал метод ALBERT. В нём было два механизма: факторизация матрицы эмбеддингов и переиспользование одного трансформенного блока несколько раз. На этом принципе работают looped-модели — hidden state в них прогоняется R раз через один и тот же блок. Число параметров становится меньше, а количество вычислений не меняется.  Рекуррентность имеет и другие преимущества: hidden state проходит несколько шагов улучшения, эффективная глубина растёт без увеличения размера модели. В перспективе число шагов можно адаптировать под сложность запроса — если он простой, то прогонять один раз, а если сложный, то больше. Рекуррентность хорошо показывает себя на алгебраических задачах и задачах, связанных с пазлами. Однако сравнения looped-моделей с не-looped-аналогами были не совсем честными. При том же размере модели делаются R прогонов, а, следовательно, в R раза больше вычислений. Соответственно, и обучать такую модель дольше. В плане оптимальности компьюта looped-модели уступали обычным трансформерам.  Авторы серии Loopie предлагают две модели: Loopie-20B-A2B и Loopie-6B-A0.6B. Архитектурно это Qwen3. В отличие от решений прошлого, здесь не вся модель прогоняется несколько раз, а каждый слой (верхняя схема на изображении 1). В пределах одного блока активации меняются не так сильно, к тому же это проще для чекпоинтинга. Также такой метод даёт потенциально большую гибкость: можно делать разное количество проходов на каждом слое.  Подход layer-loop проще для распределённого обучения, потому что повторения слоя остаются в одном pipeline stage, а параметры градиента могут использоваться локально. В то же время model-loop требует, чтобы вычисления синхронизировались внутри всей модели а первый блок должен уметь обрабатывать один или несколько полных проходов через модель.  Претрейн состоял из двух стадий. Сперва используют датасет Nemotron-CC-v2-HQ, а дальше дообучают на более качественных данных, делая упор на синтетику, STEM, код, математические рассуждения и веб-данные. Так получается базовая Loopie. На неё делают Supervised Pre-Training (SPT). Это похоже на SFT, лосс считается только по target-токенам, однако масштаб — как у претрейна: 2Т токенов. Контекст увеличивают и обучают довольно большими батчами примерно по 128М токенов. SPT, как отмечают авторы, улучшает способность модели к рассуждению.  На RL сначала делают математику, а потом программирование. Используют GSPO, ассиметричный клиппинг и динамическую фильтрацию промптов. Роллаут увеличивают с 32К до 64К.  По бенчам Loopie-20B примерно сопоставима с моделями вроде Qwen3, Nemotron 3 Nano и GPT-OSS (изображение 2). Казалось бы, не слишком большое достижение для 2026 года, однако стоит помнить, что у Loopie намного меньше параметров. Loopie-6B в своей «весовой категории» также показывает себя достойно — особенно в задачах, связанных с математикой (изображение 3). Разбор подготовил ❣ Денис Кузнеделев Душный NLP

Исследования говорят, что после нескольких лет экспериментов и пилотов большинство компаний не могут чётко ответить, какой ROI они получают от ИИ. Опросы и бенчмарки дают противоречивую картину, а рекомендации звучат как «инвестируйте и экспериментируйте» без метрик результата.  Исследователи из LUT Business School (Финляндия) при поддержке MIT Sloan Management Review провели 30+ интервью с CEO из разных индустрий на тему ROI от ИИ. И выделили три подхода к подсчету на основе зрелости компании: 🔵Function-focused approach — внедрение ИИ в одну функцию или небольшой процесс: поддержка клиентов, HR, маркетинг, производство. Возврат измеряется через функциональные KPI: время ответа, уровень ошибок, скорость обработки и т.п.  🔵Coordinated approach — по факту то же, что и п.1, но в нескольких отделах сразу. В таком случае ответственный задает общие правила на каждую команду / функцию с понятными целями по каждой метрике + одинаковым подсчетом ресурсов: интеграции, подписки, время сотрудников  🔵Enterprise portfolio approach — управление ИИ как портфелем инвестиций на уровне компании. Используются финансовые метрики (NPV, IRR, ROI бизнес-кейсов) и стратегические критерии. Подходит зрелым организациям, где ИИ - это часть корп стратегии. Кстати, мы в Colife внедрили ИИ на первую линию продаж. Он квалифицирует, отрабатывает возражения и передаёт менеджеру. Наши метрики: снижение % ФОТ продаж в выручке, скорость ответа Честно сказать, мы довольно дохера сил и времени потратили и еще потратим. Так же честно, у нас снизился % ФОТ продаж в выручке, правда на эту метрику сильно влияет еще несколько важных факторов Вообще, хочется отметить, что для успешного внедрения ИИ при любом из подходов нужен ответственный за внедрение с KPI.  Иначе как и любой новый проект никакой ИИ никуда не полетит

🌟 Аблитерированная GLM-5.3 AbliterationAI сделали версию GLM-5.3 под названием abliterated-model-large-v2. В материнской модели изменены веса в части ослабления механизма отклонения запросов. Модель позиционируется как инструмент для наступательной кибербезопасности, задач ред-тиминга и использования агентами. По собственным замерам AbliterationAI на CyberGym, где было обнаружено 1507 уязвимостей OSS-Fuzz в 188 проектах, модель показала 84,5% успешных прохождений.

Для сравнения: GPT-5.5 - 85,6%, DeepSeek V4 - 83,3%, Mythos - 83,1%.

На Terminal-Bench 4.0 она выполнила 41,8% задач, Opus 5 - 51,8%, Fable 5 - 44,5%, GPT-5.6 Sol - 37,3%. API сервиса по умолчанию принудительно блокирует только взрослый контент, связанный с несовершеннолетними, и селфхарм, все остальные ограничения сняты. Сервис предоставляет доступ через совместимые с OpenAI и Anthropic-style эндпоинты с гарантией нулевого сохранения промптов, результатов вывода и метаданных по подписке от 20 до 200 долларов в месяц. Есть ознакомительный период в веб-песочнице с лимитом в 1 доллар. @ai_machinelearning_big_data #news #ai #ml

MM Harness [1/x] Уже немало времени посвятил изучению мультимодальных харнесов. Если раньше, когда занимался моделями, я думал что беды существуют только на уровне модели, то увы, я прям очень сильно ошибался: сложность решений здесь растёт по экспоненте — и примерно по той же кривой растёт желание разработчиков (и иногда моё) забить на эту мультимодальность. Ниже — список вопросов, на которые стоит ответить до того, как вы начнёте проектировать мультимодальную систему (ну или по пути, как пойдёт). Давайте сейчас будем считать модели токенодробилками, а потому не будем углубляться в их строение, а рассмотрим систему вокруг. Допустим, мы делаем какого-нибудь агента, с которым ещё и можем общаться в формате диалога. Интерфейс Проблемы начинаются уже в тот момент, когда пользователь прикладывает картинку. 1. Загружаем оригинал или жмём? А если пользователь сидит на мобильном интернете и хочет экономить трафик? 2. Сохраняем метаданные EXIF или дропаем? Разные библиотеки по-разному обрабатывают, например, ориентацию изображения, поэтому об этом лучше подумать сразу. 3. Поддерживаем несколько изображений в одном сообщении? Если да, все остальные проблемы множатся. Контекстный менеджер Допустим, картинки всё-таки долетели до бэкенда и попали в контекстный менеджер. 1. Ресайзим ли мы их? До какого размера? Есть ли замеры влияния на качество? Чем больше изображение, тем больше токенов оно может занять — хотя тут всё зависит от препроцессинга конкретной модели. 2. Сколько картинок держим в контексте? Можно очень просто забить весь контекст изображениями! 3. Что делаем с картинками, которые в контекст уже не помещаются? Оставляем ли хотя бы описание или идентификатор, чтобы агент мог к ним вернуться? Модель и инструменты Дальше изображения уходят в модель. При этом модель может вызывать тулы, которые тоже возвращают изображения. 1. Как кладём эти картинки в контекст? Передаём модели сами изображения или только подпись "тул вернул такие-то картинки"? Другими словами, должна ли модель посмотреть на картинки, которые вернул условный поиск? 2. А в сами тулы мы какую картинку подаём? Ту самую пожатую и с ресайзом? Или какую-то другую? 3. А если передаём модели сами картинки, как поступаем, когда контекст уже ими забит? И это только базовые вопросы доставки и управления контекстом, где правильного решения нет — есть только ваше, скорее всего компромиссное. И всё это добавляется к уже известным сложностям текстовых агентов. Мы ещё не дошли до хранения, кеширования, безопасности и различных UI-фич. Продолжение следует... P.S. Календарь перевернули?)

Мне жаль, у вас нейрослоп LinkedIn выкатил кнопку, чтобы жаловаться на нейрослоп в ленте. Месяц назад в меню каждого поста (это где три точечки) появился пункт "Seems like AI slop". Через неё можно репортить, если текст на ваш взгляд выглядит нейро-высер. Пруфы прикладывать не нужно. Заодно компания прикончила свою же фичу "Enhance your post" (она дописывала посты ИИшкой за юзера) и заменила её на пруфридер, который просто чинит грамматику, но стилистику и голос не трогает. Логика понятная: по свежему исследованию Pangram, у LinkedIn 41% лонгридов - это стопроцентный нейрослоп 80 левела. Это худший показатель среди крупных площадок. У тех же Х, Reddit или Substack доля заметно скромнее. Отдельный треш - два месяца назад Линк выкатил отчёт, как они яростно борются со слопом. И что вы думаете? Этот отчёт сам оказался нейрослопом. К - классика. Мультивселенная схлопнулась. В общем, за первые две недели после релиза кнопкой воспользовалось >миллиона человек, а помеченные посты стали получать на 40% меньше показов. Да, эта кнопка не просто косметическая, она реально влияет на алгоритм. Но и не прям расстрельная - один клик ничего не решает. Чтобы алгоритм задумался - репорты должны быть массовые. Интересно, конечно, а что если зарепортят реальный текст (хотя кого я обманываю, реальный текст в 2026? Пффф). ИИ-детекторы постоянно косячат и ложно-срабатывают, а люди смогут чётко отличать? Ну, может и смогут, всё-таки у слопа куча иррациональных паттернов, которые норм палятся как раз кожаным глазом, а не машиной. Получается, LinkedIn долго и упорно пушил ИИ-инструменты для постинга, но в итоге понял, что это нифига не преимущество, а скорее наоборот. И теперь пытается всё исправить радикально - в том числе, привлекая юзеров. Ну, удачи им, Бог им судья, что тут сказать. Этот пост, если что, не нейрослоповый. Мы же не на Linkedin, в конце концов 🤔 Фичизм

Главный организационный вопрос внедрения AI Уже не первый год мы все спорим про влияние AI на бизнес-процессы, делимся кейсами, меримся автоматизациями, количествами созданных агентов и сожжённых токенов. Но все эти вопросы мне кажутся вторичными по отношению к более глубокому, который почему-то задают реже: а какая работа и какие люди нам вообще теперь нужны в организации? Это не обязательно вопрос про увольнения - вопрос скорее про перераспределение задач, ролей и ответственности внутри организации. Если руководитель команды может за пару часов навайбкодить сервис и автоматизировать большой блок работы, какая часть работы действительно требует разработчика? Если маркетолог может провести аналитику данных самостоятельно, когда и зачем теперь звать аналитика? Если продакт может сам собрать прототип, провести несколько пользовательских тестов и разобрать результаты, в какой момент ему всё ещё нужен дизайнер или UX-исследователь? Мне кажется, работать с прежней оргструктурой и игнорировать все эти вопросы долго не получится: AI всё сильнее меняет не только отдельные процессы, а само разделение труда между ролями и функциями. А, значит, настоящая AI-трансформация начнётся, когда люди начнут открыто договариваться о своих зонах ответственности (а не проводить очередной цикл обучений): почему эта работа вообще существует, кто должен её выполнять, какие компетенции для неё теперь нужны и где должна проходить граница ответственности в организации. А это всё потенциально конфликтно, сложно и больно. Потому что обсуждать новые навайбкоженные инструменты гораздо проще, чем поднимать сложные вопросы, которые никакая языковая модель за организацию не решит.