Еще немного интересных наблюдений из RL для MoE. В нем есть одна проблема, которая делает обучение гораздо более склонным к нестабильностям. В любом современном RL есть train-inference mismatch, обычно вызванный двумя вещами: 1) из-за асинхронности инференс отстает от трейнера и 2) из-за разной имплементации кернелов/разного железа/неассоциативности сложения (у одной версии dense чекпоинта pi_train(tok) / pi_inference(tok) отличается обычно в четвертом знаке). Однако, в MoE появляется еще один очень неприятный источник такого расхождения: routed experts. Проблема в том, что во время инференса могут активироваться одни эксперты, а во время forward_pass на стороне трейнера – другие, и незначительное изменение в скорах роутера (но достаточное для того, чтобы topK изменился) могут значительно изменить итоговый результат. Основные решения такие: - Просто фризим роутер и уменьшаем асинк ⇒ роутер реже пересекает границу, при которой меняется topK - R2/R3, они же Routing Replays: сохраняем экспертов, активируемых версией модели для инференса и форсируем forward pass через них в трейнере. В статье https://arxiv.org/abs/2512.01374 можно почитать про разницу R2 vs R3 и всякие доп детали. Но проблема в том, что экспертов-то мы форсируем, но скоры роутера меняются, и это может быть проблемой (можно порассуждать на тему, что будет, если инференс версия дала i-ому эксперту высокий скор, а трейнер – низкий) И на самом деле у всех результаты смешанные: у кого-то работает одно, у других – другое. Вчера прочитал https://kiddyboots216.github.io/mismatch/#conclusion-router-replay и увидел еще один способ: Total Router Recall – сохраняем не только экспертов, но и их скоры, а в трейнере фризим роутер. Интересно, что можно предложить способ, при котором мы будем роутер учить, используя скоры и экспертов с инференса, правда работать это будет плохо. В общем, для всех интересующихся RL-ем рекомендую полистать блогпост, там много чего интересно помимо реплеев

Better MoE model inference with Warp Decode 🔗 Блогпост Ребята из Cursor не остановились на Mixture-of-Kittens и реализовали ещё одну примечательную оптимизацию MoE для low-batch-инференса под названием Warp Decode. Традиционные пайплайны инференса MoE expert-centric: они собирают токены для каждого эксперта, прогоняют вычисления и переставляют их обратно в исходном порядке. Операции перестановок занимают нетривиальное время и существенно замедляют инференс. Курсоровцы же предлагают параллелизовать не по экспертам, а по выходам. Каждый варп отвечает за одно выходное значение. Инференс реализован через два fused-кернела — gate+up и down. Варп достаёт в потоковом режиме нужную строчку из матрицы весов и проводит операции. ⚡ Так как варпы работают независимо, то всё выходит embarrassingly parallel: вообще не нужно париться по поводу банковских конфликтов, барьеров и синхронизаций. Все редукции выполняются через warp-level-инструкции вида __shfl_xor_sync. 🛠️ Ещё из полезных плюшек стоит отметить следующее: - 📐 Не нужно паддить до какой-то степени двойки (типа 128). - 🗂️ Можно избавиться от scatter и combine: токены последовательности раздаются экспертам, а потом всё собирается. Также исчезает необходимость в промежуточных буферах. 🚀 В итоге оно даёт ускорение порядка 1,8× на B200. 💡 А ещё они избавляются от MXFP8-квантизации, ибо и так всё работает достаточно быстро) 📈 На батче из 32 удаётся достичь до 58% максимально достижимой пропускной способности. Однако авторы утверждают, что их подход не полностью вытесняет expert-centric-исполнение, особенно в сценарии низкой загрузки. На больших батчах оверхеды от перестановок/перегруппировок токенов не так сильно болят.

Открытая MoE-видеомодель MAGI-2 Preview от Sand.ai Разработчики из Sand.ai выложили в открытый доступ веса и код инференса MAGI-2 Preview. Модель построена на single-stream архитектуре и генерирует 10-секундные ролики сразу вместе с синхронной аудиодорожкой. Внутри применили редкий для таких моделей fine-grained MoE. При суммарном объеме в 114B параметров на каждый токен активируется всего 6B. По объему вычислений на шаг это в разы легче плотного MiniMax H3 (33B), благодаря чему стоимость инференса упала в ~10 раз, а модель заскочила на 6 место в лидерборде Artificial Analysis. Сам пайплайн генерации двухстадийный. Сначала базовая модель генерирует видео в низком разрешении, а затем refiner апскейлит результат до 1080p. Пока это не конкурент MiniMax H3 в плане локальной доступности. Квантованный H3 влезает в одну карту на 24GB (RTX 3090/4090), тогда как для MAGI-2 нужно заметно больше ресурсов. Зато у облачных провайдеров за счет всего 6B активных параметров инференс по API будет значительно дешевле dense моделей, да и у такой архитектуры хороший потенциал для скейлинга. Техрепорт Код Веса @ai_newz

🔥 Kimi K3 на 2,78 ТРИЛЛИОНА параметров запустили на CPU с 8 ГБ RAM. Без GPU, BLAS и фреймворков Проект kimi-k3-in-c реализует inference Kimi K3 практически с нуля на portable C99. Чекпоинт модели занимает 1,56 ТБ, но пик RAM при запуске составил всего 8,24 ГБ. Фокус в MoE и стриминге весов. Из 896 экспертов на токен выбираются только 16, а остальные веса не обязаны постоянно лежать в оперативной памяти. Огромная часть модели читается прямо с диска, поверх этого работает LRU-кэш экспертов. Цена такого трюка очевидна: скорость. При 8 ГБ RAM автор получил около 26,5 секунды на токен, при 64 ГБ уже 19,8 секунды, а на машине с 128+ ГБ, где нужные данные помещаются в память, около 5,6 секунды. Получается любопытная смена ограничения: гигантскую MoE уже можно заставить работать без серверной фермы. Вопрос теперь скорее в том, сколько диска и времени на токен вы готовы отдать за такой inference. github.com/FareedKhan-dev/kimi-k3-in-c #AI #Kimi #LLM #C #LocalAI

Про совсем компактные модели Мне нравится идея крутить локальные модели, но не нравится идея забивать всю память ими. Мне всегда казалось, что самый лучший способ сделать подобную 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 про то как они дизайнили модель

🧪 Метод Основными задачи при разработке кернела были: • Уменьшить обьем CPU работы и CPU-GPU синхронизации • Максимально эффективно перекрывать вычисления и коммуникации Рассматриваются два типа dispatching Push-based dispatch (традиционный подход) 1. Router для каждого токена определяет его экспертов. 2. Для каждого токена выполняется: Отправить этот токен эксперту №7. То есть именно токен "толкается" (push) в буфер нужного эксперта.

T0 ---> Expert 2 T1 ---> Expert 7 T2 ---> Expert 2 T3 ---> Expert 5 :ale Проблемы Если тысячи потоков одновременно хотят записать данные эксперту 7, они начинают конкурировать за • atomic counter, • место в буфере, • память. Получается много случайных записей и плохая эффективность памяти. Pull-based dispatch Идея разворачивается наоборот. Сначала известно, какие токены принадлежат каждому эксперту (например, после сортировки). После этого сам эксперт приходит за своими токенами. Expert 2: беру токены [0,2,9,15] Expert 5: беру токены [3,8] Expert 7: беру токены [1,4,5,6]

Теперь данные читаются большими непрерывными кусками. Никаких scatter-записей больше не требуется. Pull позволяет организовать данные так, чтобы чтение стало почти непрерывным, что улучшает пропускную способность памяти и снижает накладные расходы на scatter/atomic операции. Кернел валидируют на разных MoE моделях - GLM-5.2, Qwen-3.5-397B, Kimi-K2.7, DeepSeek V4 Pro. Удается добиться ускорения ~2x против бейзлайнов на форварде, и ~1.5x на обратном проходе. Выкладывание в открытый доступ данного кернела - хороший подарок компаниям, которым завезли NVL72, и они не знают, как их эффективно использовать.

ICML 2026 — личные впечатления Конференция закончилась, но говорить о ней можно ещё долго. Сегодня личными впечатлениями с нашим каналом поделился старший разработчик команды инфраструктуры обучения YandexGPT Владислав Тыцкий.

Конференция ощущалась очень масштабной: много людей, огромные залы для докладов, плотное расписание и буквально бесконечное количество постеров. Иногда возникало ощущение, что между интересными работами нужно не ходить, а почти бегать. Для себя я в основном смотрел темы вокруг pretraining, scaling, MoE, efficient training и разных попыток лучше понять динамику обучения LLM. В этом смысле конференция оказалась очень насыщенной: почти в каждой постерной сессии находилось несколько работ, которые хотелось разобрать подробнее. Постерный формат показался мне самым полезным. На докладах — особенно в больших залах — немного теряется камерность: масштаб впечатляет, но вовлечённость аудитории ощущается слабее. У постера проще быстро понять основную идею, задать автору вопрос и уйти либо с хорошим инсайтом, либо с пониманием, что работа тебе не очень релевантна. Отдельно понравилась инфраструктура конференции. У ICML очень удобные сайт и приложение: можно собирать расписание, смотреть материалы онлайн, возвращаться к записям и в целом не чувствовать, что ты полностью пропустил материал, если не успел попасть на доклад. Плюс Gangnam оказался приятным районом для такой конференции: вокруг много кофеен, мест для еды и просто красивый бизнес-квартал, по которому интересно гулять между сессиями. ICML большая, шумная и местами немного перегруженная, но при этом очень полезная. Особенно если заранее понимать, какие темы тебе интересны, и не пытаться посмотреть вообще всё.

Владислав также рассказал о некоторых запомнившихся постерах. Variational Routing: A Scalable Bayesian Framework for Calibrated Mixture-of-Experts Transformers Статья об uncertainty-aware routing в MoE. Идея в том, чтобы добавить неопределённость именно в router — место, где MoE и так принимает важное и довольно хрупкое решение. Практически интересно, что такой слой можно дообучать уже поверх обученных моделей. В экспериментах это улучшает калибровку и устойчивость роутера к шуму при небольшом дополнительном компьюте. Decoupling the “What” and “Where” With Polar Coordinate Positional Embeddings Работа о позиционных эмбеддингах и RoPE. Авторы обсуждают, что в RoPE могут смешиваться content- и position-информация, и предлагают PoPE — способ лучше развести «что» и «где». Не уверен, что это прямо новый дефолт вместо RoPE, но сама идея про content phase и positional phase показалась интересной. BAS: Bridging Adam and SignSGD for Memory-Efficient LLM Training Постер о memory-efficient-оптимизации. Авторы пытаются приблизиться к Adam-like динамике, но снизить память за счёт block-wise статистик. Плюс используют трюк с sign update, что делает работу интересной не только с точки зрения оптимизации, но и с точки зрения практических ограничений больших обучений. Revisiting Efficiency–Accuracy Scaling in Mixture-of-Experts Architectures Hardware-aware-работа о трейд-оффе между качеством и стоимостью MoE. Авторы предлагают LatentMoE: скоры роутера считаются в исходном пространстве, после чего токены — перед отправкой к экспертам — проецируются в пространство меньшей размерности. Это уменьшает объём all-to-all и стоимость вычисления экспертов. Сэкономленный бюджет можно вложить в большее число экспертов и больший top-k. #YaICML2026 Душный NLP

«Моэ» — это сленговый термин в культуре отаку, описывающий чувство привязанности, возникающее в ответ на аниме-персонажей. Эти персонажи, как правило, миловидны по своей природе и стали символами идентификации в виртуальном пространстве. Такие аниме-сериалы, как Lucky Star, создаются специально для того, чтобы вызывать у зрителя чувство моэ. Моэ переживается висцерально на уровне аффекта — как мгновенная реакция на упорядоченные элементы, конструирующие образ персонажа. Виртуальное тело — это состояние бытия внутри виртуальной, симулированной среды. Оно контрастрирует с физическим телом — телесным объектом, который привязывает субъекта к физическому миру. В то время как физическое тело наследует свойства, обусловленные его генеалогией, экономическим положением, социальными ролями, биологией и так далее, виртуальное тело выстраивается из симулированных элементов и ориентируется на описания, которые создают репрезентации и организуют отношения (алгоритмы, метаданные и т. д.). Это виртуальное тело позволяет конструировать элементы репрезентаций для создания качественно новой мета-идентичности без ограничений, накладываемых телесной обусловленностью. Структура интернета и профилей в социальных сетях фундаментально сместила фундамент, на котором мы основываем свою идентичность. Когда мы задумываемся о том, кто мы есть на самом деле, это больше не опирается исключительно на унаследованные элементы нашей физической жизни. Мы все обрели свое второе тело в виртуальном пространстве. По мере того как мир автоматизируется с целью снижения энергетических затрат физического тела, мы по необходимости начинаем все больше полагаться на функцию нашего виртуального тела. Это создает двусмысленность между виртуальным и физическим. Результатом этого разъединения становится объективация физического тела. Наши способы взаимодействия с миром все дальше удаляются от физического пространства и абстрагируются в сторону виртуального. Растущая пропасть между физическим и виртуальным приводит к развоплощению. Без запроса на физическое присутствие тело теряет свою спонтанность, превращаясь в механический инструмент, функционирующий в рамках наших трех измерений, в то время как сам субъект словно парит над миром, подобно призраку. Появляется ощущение, будто человек утратил свои чувства. Человек больше не может быть-телом, а скорее имеет-тело. Бытие раскалывается между неуклюжим опытом обладания-телом и бесшовной непрозрачностью бытия-виртуальным. Одним из источников нашего коллективного невротизма является «двойная бухгалтерия», которую нам приходится вести, чтобы справляться с двусмысленностью между физическим и виртуальным — процесс, вызывающий внутреннюю разорванность. Наш внутренний нарратив теперь формируется телесным объектом, запертым в трех измерениях, и мета-идентичностью, выстраиваемой субъектом, который уже не связан ограничивающими условиями телесного мира, но при этом еще не полностью овеществлен ими. Персонаж моэ — это репрезентация не физического тела, а стремления к идеальному «Я» или идеальному партнеру, выраженному через виртуальное тело. Широкое распространение эстетики моэ и ее использование в «хронически онлайн» интернет-сообществах указывают на то, что виртуальные идентичности в каком-то смысле хотят, чтобы их интерпретировали не по физическим предписаниям, составляющим телесное состояние человека по ту сторону экрана, а скорее по их досознательной и аффективной идеализации себя. Милая эстетика стала мощным образом идеализации. Милые персонажи, манеры, способы речи и так далее — это способы коммуникации, посредством которых могут взаимодействовать виртуальные тела, что в противном случае было бы невозможно из-за ограничений и предписаний физического мира. Для некоторых людей эстетика моэ предлагает способ самовыражения, модус бытия, который может ослабить напряжение от условностей реального мира, но при этом может усилить стремление к становлению-виртуальным.

Оптимизируют MoE, стабилизируют RLVR, колдуют над кэшем и очень активно обсуждают GRPO: продолжаем рассказывать, что в тренде ICML 2026 Но обо всём по порядку. Читайте TL;DR от наших коллег и листайте фото с постерами! Stable Asynchrony: Variance-Controlled Off-Policy RL for LLMs Классная статья про стабилизацию RLVR. Авторы предлагают метрику, которая лучше всех предыдущих детектит потенциальный взрыв — effective sample size. По сути, это нормированная сумма important weight между движками актора и роллаута. Мы в Яндексе тоже её используем — работает! Дальше авторы рассматривают два пути решения. Первый — простой (мы тоже его пробуем). Если метрика начинает стрелять, надо понижать лёрнинг рейт адаптивно. Второй путь — умный потокенный решейпинг — чинит все проблемы сразу. RL учится 1000 степов и не разваливается, даже на специально усложнённом сетапе со staleness 12. Имплементировать, судя по описанию, должно быть легко. TVCACHE: A Tool-Value Cache for Post-Training LLM Agents В этой работе кэшируют последовательные цепочки туллколов в агентских роллаутах. Получается приличный кэшхит в десятки процентов. Применяют хаки типа прогрева кэша перед роллаутом. Кэш шарят по всему по времени обучения, поэтому кэшхит к концу может расти. Tackling Length Inflation Without Trade-offs: Group Relative Reward Rescaling for Reinforcement Learning Говорят, что научились заставлять GRPO растить reward, не удлиняясь относительно инита. В GRPO вместо reward'а на R делают R • s, где s — нормализующий коэффициент, функция от относительной длины ответов в группе. Spurious Rewards: Rethinking Training Signals in RLVR Обучают GRPO на шумные сигналы, доходя до обучения на случайный шум. Обнаружили парадокс: в некоторых моделях Qwen обучение даже на такой «сигнал» даёт профит. Объясняют тем, что виноват клиппинг в GRPO — он чаще срабатывает на маловероятных траекториях, вероятности высоковероятных, наоборот, растут. Проверяют это, отключив клиппинг: действительно, модель перестает учиться на «испорченные» сигналы. Revisiting Efficiency–Accuracy Scaling in Mixture-of-Experts Architectures NVIDIA оптимизируют MoE. Обычно инференс таких архитектур упирается в пропускную способность памяти: либо перекачиваем туда-обратно экспертов на каждом токене, либо при большом батче упираемся в all-to-all. Авторы сделали архитектуру LatentMoE — временно проецируют представления токенов в низкоразмерное латентное пространство перед маршрутизацией. Весь тяжелый сетевой трафик all-to-all и чтение экспертов из памяти происходят в сжатом формате. А на выходе из MoE-слоя данные возвращаются к исходному размеру. Экономию при зеродифф-костах реинвестируют в увеличение числа экспертов и количество активируемых. Качество растёт — говорят, что уже используют это в Nemotron. Why Tree-Style Branching Matters for Thought Advantage Estimation in GRPO В GRPO при обучении ризонинг-модели на reward-сигнал генерации итогового ответа могут отличаться друг от друга, получая разную награду. В работе показывают, что часть бюджета выгодно потратить на генерации нескольких ответов при фиксированном CoT, чтобы разделить награду конкретного ответа от ожидаемой награды для цепочки (T4A4 > T16A1). На практике при правильном использовании это также экономит компьют, так как ризонинг цепочки обычно занимают бóльшую часть генерации. Поделились впечатлениями ❣ Даниил Кириллов, Тимофей Смирнов, Даниил Гусев, Дмитрий Калашников, Алексей Зотов #YaICML2026 Душный NLP

North-Mini-Code-1.0-w4a16 Квантованная версия (4-бит вес, 16-бит активации) первой модели Cohere для разработчиков: управление подзадачами, анализ архитектуры, code review. * Архитектура: Sparse MoE на базе Transformer. 30B параметров всего, 3И активно. Высокая скорость, низкие требования к GPU. * Контекстное окно: 256K токенов для анализа репозиториев целиком. * Максимальный вывод: до 64K токенов. * Поддержка: нативные инструменты, чередующееся рассуждение (interleaved reasoning) через JSON-схему. * Обучение: платформы SWE-Agent, mini-SWE-agent, OpenCode, Terminus 2 для устойчивости в реальных средах. Сценарии использования: * генерация кода и тестов * рефакторинг legacy-кода * автоматизированный code review в CI/CD * локальный AI-ассистент для приватности * создание агентных пайплайнов для аудита безопасности и unit-тестов #MoE #reasoning #coding

Прошло 3 недели и никто не написал про Apple и WWDC, а мне было лень, но что поделать, надо браться. В начале июня компания проводила ежегодную конференцию для разработчиков и вместе с этим рассказала про обновления в AI. Очень сильно прокачали Siri, теперь она работает на относительно большой (по мобильным меркам) LLM, умеет вызывать инструменты и тесно связана с приложениями и экосистемой. Я видел пару демонстраций в твиттере, где запросы и сценарии показались мне не предусмотренными разработчиками (то есть модель на них не тренировали), и тем не менее Siri справилась отлично. Для тех, кто пользовался LLM, такая генерализация не является чем-то выдающимся, но для обычных пользователей может вызвать ВАУ-эффект. Ого, оно что И ТАК умеет??? Не только по пяти заложенным 15 лет назад сценариям работать? На девайсах может быть одна из двух моделей — AFM 3 Core (3 миллиарда параметров) и AFM 3 Core Advanced для девайсов помощнее, Phone 17 Pro и выше, iPad с чипом M4 и выше, MacBook с чипами M3 и выше. Такое ограничение потому, что модель действительно «Large» — 20 миллиардов параметров с микстурой экспертов (MoE). Но работает очень хитро — классический MoE работал бы плохо, так как у девайса ограничена пропускная способность между NAND (флеш-память для хранения ваших файлов и весов модели) и DRAM (где хранятся активные параметры для работы). В обычном MoE вы не знаете наперёд, какие именно эксперты вам нужны, поэтому загружаете всю модель, что а) долго б) занимает много памяти, а потом уже экономите на вычислениях, так как работает часть экспертов. Apple применили трюк, который я вижу впервые: для вашего промпта модель предварительно выбирает набор экспертов на всю модель, а затем загружает только их, и получается от 1 до 4 миллиарда активных параметров. Подход называется Instruction-Following Pruning for Large Language Models и описан в этой статье из начала 2025-го года. Также эта модель работает и для распознавания вашего голоса (поэтому и оно улучшилось), и для генерации нового голоса Siri (...тоже улучшилось). Вот тут внизу есть пара семплов было/стало, честно говоря старое мне нравится больше 🤷‍♂️ И вторая часть анонса — это удвоение ставки на Private Cloud Compute (PCC), который анонсировали два года назад. Идея в том, что для более сложных запросов, для которых локальной модели (особенно на смартфоне) не хватает, можно отправить промпт и контекст (например, файлы) на зашифрованный сервер, внутрь которого ни у кого нет доступа. Несмотря на то что система имеет открытый код и анализировалась лучшими специалистами по кибербезопасности, надеюсь, что Mythos тоже натравили 😀 Так вот, в PCC тоже обновилась модель, AFM 3 Cloud. Она запущена на серверах Apple и крутится на собственных чипах M-серии. И есть ещё AFM 3 Cloud Pro, которая ещё больше, ещё умнее, развернута на серверах Google на Nvidia GPU. Мне кажется это очень крутой паттерн, с которым мы будем жить: на смартфонах и умных девайсах в ближайшее время не будет настолько мощных чипов, как в серверных стойках, но хочется, чтобы умные модели были доступны. Все эти модели созданы компанией Apple, это НЕ модели Gemini. Говорят, что Apple усовершенствовала некоторые из этих моделей, дистиллируя Gemini, но все они являются совершенно новыми моделями, в которых используются собственные знания и технологии Apple. Самое крутое — и на смартфонах, и на макбуках у вас как у разработчика есть доступ к этим LLM. То есть вы можете написать приложение, не обучать свою модель (только сделать промпт) и вызывать её. Это бесплатно для локальной модели, а для облачных бесплатно до какого-то порога, дальше придется платить. Вот тут и тут можно посмотреть на скорость генерации на разных девайсах — получается даже быстрее, чем я бы ожидал!