Американская ИИ-компания PrismML расширила семейство Bonsai 2, представив три новые модели с 2, 4 и 9 миллиардами параметров. Все они созданы на основе Qwen 3.5 от Alibaba.

Разработчики ограничили основные веса языковых моделей тремя значениями: −1, 0 и +1. Благодаря этому размеры файлов удалось сократить до 0,43 ГБ, 0,95 ГБ и 2 ГБ соответственно. Это примерно в девять раз меньше, чем у исходных моделей с 16-битными весами.

Новые модели по-прежнему поддерживают рассуждения, понимание изображений и вызов инструментов. Прежде всего они предназначены для локальных ИИ-агентов, работающих на смартфонах, персональных компьютерах и других устройствах.

По данным PrismML, на iPhone 18 Pro Max модель 9B генерирует до 34 токенов в секунду, тогда как версия 2B достигает скорости 120 токенов в секунду.

В официальных тестах Bonsai 2 9B практически не уступает исходной Qwen 3.5 аналогичного размера в программировании и следовании инструкциям, однако на сложных задачах разница заметнее.

В Tau2Bench, проверяющем способность моделей вести многоэтапные диалоги и работать с инструментами, Bonsai 2 9B набрала 73,02 балла против 85,25 у оригинальной Qwen 3.5. В тесте на анализ сложных документов результаты составили 73,8 и 88,73 балла соответственно.

Веса всех трёх моделей уже опубликованы под лицензией Apache 2.0.

При этом стоит учитывать, что 2 ГБ это размер только языковой модели 9B в наиболее компактном формате. Для обработки изображений потребуется дополнительно загрузить визуальный модуль объёмом около 0,62 ГБ.

https://huggingface.co/collections/prism-ml/bonsai-2-small

Я думал, что понимаю, как работает загрузка GPU, пока не начал писать это руководство.

Я постоянно смешивал три разных понятия:

- Объём работы, который мы запускаем.
- Объём работы, который фактически размещён на GPU.
- Объём работы, готовый к выполнению прямо сейчас.

Но это совершенно разные вещи.

Возьмём CUDA-ядро с 240 блоками по 256 потоков в каждом. Всего получается 61 440 логических потоков, или 1920 варпов. Однако количество запущенных потоков ничего не говорит о том, сколько варпов может одновременно находиться на GPU.

Блоки размещаются на потоковых мультипроцессорах (SM) с учётом доступных регистров, разделяемой памяти и ограничений на количество потоков, варпов и блоков.

Даже после размещения на SM варп может ожидать завершения операции с памятью, разрешения зависимости между арифметическими операциями или синхронизации. Планировщик может выбирать только те варпы, которые действительно готовы к выдаче инструкций на выполнение.

Это изменило и мой подход к анализу показателей производительности.

Occupancy — показатель, отражающий отношение количества активных варпов на SM к максимально поддерживаемому количеству варпов на этом SM.

GPU utilization измеряет другое. В NVML этот показатель отражает долю интервала измерения, в течение которой выполнялось хотя бы одно CUDA-ядро.

Таким образом, GPU может показывать загрузку 100%, даже если Tensor Cores не используются на полную мощность, пропускная способность HBM не исчерпана, а производительность ограничивается одним из компонентов системы. При этом значительная часть ресурсов GPU может оставаться недозагруженной.

С памятью возникают похожие заблуждения. Регистры, разделяемая память, L1, L2 и HBM — это не просто уровни памяти, последовательно отличающиеся скоростью. У каждого из них свои области доступности, ёмкость, особенности управления и способы доступа.

Если модель помещается в HBM, это означает лишь то, что для неё достаточно видеопамяти. Но практически ничего не говорит о том, сколько байтов приходится передавать, насколько эффективно объединяются обращения к памяти, как часто данные используются повторно и действительно ли память ограничивает производительность CUDA-ядра.

Хороший пример — FlashAttention. Алгоритм вычисляет точный механизм внимания (attention), но использует разбиение на блоки (tiling) и повторные вычисления, чтобы сократить объём передачи данных между HBM и внутренней памятью GPU.

Tensor Cores оказались ещё одной технологией, которую я раньше воспринимал слишком упрощённо.

Это специализированные вычислительные блоки для матричных операций умножения с накоплением, играющие огромную роль в задачах ИИ. Однако они не «выполняют модель» целиком.

Операции редукции, индексации, поэлементные вычисления, синхронизация и перемещение данных по-прежнему задействуют другие компоненты GPU. Кроме того, запуск CUDA-ядер тоже создаёт дополнительные накладные расходы.

Со временем я перестал спрашивать себя: «Почему GPU не загружен на 100%?» Вместо этого я начал задавать более правильный вопрос: «Что именно сейчас ограничивает скорость выполнения полезной работы?»

В итоге всё это превратилось в руководство на 42 страницы.

В нём рассматриваются потоковые мультипроцессоры (SM), варпы и планировщики, иерархия памяти и скрытие задержек, Tensor Cores, распределение вычислений GEMM по аппаратным ресурсам GPU, точность вычислений и показатели производительности, которые очень легко интерпретировать неправильно.

https://drive.google.com/file/d/17tyvxr__8vZ6o995GNq6I5PC5JOiv0ql/view

Трансформеры с циклическим выполнением (Looped Transformers) сейчас активно обсуждаются.

И эти 10 новых научных работ действительно заслуживают вашего внимания.

▪️ Recurrent Looped Transformer ▪️ Looped Prediction Transformer (LPT) ▪️ Recursive Multi-Agent Systems (на основе Looped Transformer) ▪️ Loop Flow Transformers (LiFT) ▪️ Looped Diffusion Transformer ▪️ LAST: Looped Audio Spectrogram Transformer ▪️ LoopCD ▪️ Hyperloop Transformer ▪️ OperLoop ▪️ LoopQuant

Исследователи подготовили краткое руководство, в котором объясняется, что представляют собой эти подходы, как они работают и в каких случаях стоит использовать каждый из них.

Подробнее: https://www.turingpost.com/p/10-looped-transformer-papers

Большинство разработчиков, работающих с машинным обучением на Python, используют PyTorch.

У Amazon есть собственные чипы для машинного обучения — Trainium. В AWS инстансы с Trainium стоят примерно вдвое дешевле, чем инстансы с GPU Nvidia, хотя и предоставляют несколько меньшую вычислительную мощность. В целом AWS утверждает, что использование Trainium обходится на 30% дешевле, чем Nvidia.

Теперь Amazon значительно упростила запуск PyTorch на собственных чипах. TorchNeuron — это нативный бэкенд для PyTorch.

Чтобы перенести существующий код PyTorch на Trainium, достаточно изменить строку с указанием устройства:

model = MyModel().to('neuron')

Чипы Trainium доступны в облачных инстансах AWS EC2.

Проект пока находится на стадии бета-тестирования.

https://github.com/aws-neuron/torch-neuronx

Подборка из 30 видео на YouTube для изучения основ машинного обучения с нуля.

(1) Introduction to Machine Learning Teach by Doing: https://lnkd.in/gqN2PMX5
(2) What is Machine Learning? History of Machine Learning: https://lnkd.in/gvpNSAKh
(3) Types of ML Models: https://lnkd.in/gSy2mChM
(4) 6 steps of any ML project: https://lnkd.in/ggCGchPQ
(5) Install Python and VSCode and run your first code: https://lnkd.in/gyic7J7b
(6) Linear Classifiers Part 1: https://lnkd.in/gYdfD97D
(7) Linear Classifiers Part 2: https://lnkd.in/gac_z-G8
(8) Jupyter Notebook, Numpy and Scikit-Learn: https://lnkd.in/gWRaC_tB
(9) Running the Random Linear Classifier Algorithm in Python: https://lnkd.in/g5HacbFC
(10) The oldest ML model - Perceptron: https://lnkd.in/gpce6uFt
(11) Coding the Perceptron: https://lnkd.in/gmz-XjNK
(12) Perceptron Convergence Theorem: https://lnkd.in/gmz-XjNK
(13) Magic of features in Machine Learning: https://lnkd.in/gCeDRb3g
(14) One hot encoding: https://lnkd.in/g3WfRQGQ
(15) Logistic Regression Part 1: https://lnkd.in/gTgZAAZn
(16) Cross Entropy Loss: https://lnkd.in/g3Ywg_2p
(17) How gradient descent works: https://lnkd.in/gKBAsazF
(18) Logistic Regression from scratch in Python: https://lnkd.in/g8iZh27P
(19) Introduction to Regularization: https://lnkd.in/gjM9pVw2
(20) Implementing Regularization in Python: https://lnkd.in/gRnSK4v4
(21) Linear Regression Introduction: https://lnkd.in/gPYtSPJ9
(22) Ordinary Least Squares step by step implementation: https://lnkd.in/gnWQdgNy
(23) Ridge regression fundamentals and intuition: https://lnkd.in/gE5M-CSM
(24) Regression recap for interviews: https://lnkd.in/gNBWzzWv
(25) Neural network architecture in 30 minutes: https://lnkd.in/g7qSrkxG
(26) Backpropagation intuition: https://lnkd.in/gAmBARHm
(27) Neural network activation functions: https://lnkd.in/gqrC3zDP
(28) Momentum in gradient descent: https://lnkd.in/g3M4qhbP
(29) Hands on neural network training in Python: https://lnkd.in/gz-fTBxs
(30) Introduction to Convolutional Neural Networks (CNNs): https://lnkd.in/gpmuBm3j

Китайская Unitree представила робота H2-X Kung Fu Legend Guardian.

Он оставляет вмятины на автомобильных дверях. Прыгает с высоты 4 метров. Выполняет удары ногами с разворота и сальто. И даже поднимает переднюю часть автомобиля.

Нам конец. 💀

Вот полное официальное видео от Unitree.

Новая научная работа Google DeepMind и Кембриджского университета показывает, что ИИ-агент способен самостоятельно совершать математические открытия, доказывая точные закономерности для 11 ранее не исследованных машин Тьюринга.

ИИ может перейти от решения математических задач, поставленных человеком, к самостоятельному поиску новых закономерностей. Это продемонстрировал агент на базе Gemini, который обнаружил новые правила для 11 машин из задачи Busy Beaver («Занятой бобр»), ранее не имевших опубликованного анализа, и формально доказал их с помощью Lean.

Агент проверял пограничные случаи в симуляторе, составлял неформальные доказательства, а затем формально доказывал найденные закономерности в системе проверки доказательств Lean.

https://arxiv.org/abs/2610.22603

ПОГОДИТЕ. Kimi K3.1 Pro настолько преуспела в эксплуатации уязвимостей, что Moonshot пришлось УРЕЗАТЬ её хакерские возможности, прежде чем открывать доступ к весам.

> Из обучения и обучения с подкреплением (RL) исключили данные по кибербезопасности.
> Доля успешных эксплуатаций уязвимостей снизилась с 90,5 до 81%.
> Но даже этот результат более чем ВДВОЕ превосходит показатель предыдущей модели — 33,3%.

При этом в будущих моделях компания намерена ПОВЫШАТЬ возможности в области кибербезопасности. Вот что сказано в блоге:

«Во-первых, мы стремимся не публиковать открытые веса моделей, которые установили бы новую планку возможностей в области кибербезопасности. Наступательные возможности K3.1 Pro намеренно ограничены: они ниже того уровня, которого позволяет достичь наш процесс разработки, и по-прежнему уступают возможностям передовых закрытых моделей.
Во-вторых, мы намерены постепенно расширять возможности в области кибербезопасности, доступные в моделях с открытыми весами. Мы считаем, что доступ к K3.1 Pro на равных условиях приносит пользу тем, кому возможности двойного назначения нужны для защиты систем. Когда мощная модель открыта и работает на инфраструктуре, подконтрольной самим пользователям, гораздо больше команд получают средства для аудита кода, который они поддерживают. Это касается и устаревших систем, редко проходящих целенаправленные проверки безопасности.
Мы убеждены, что постепенное распространение таких возможностей, а не их сосредоточение в нескольких закрытых системах, в конечном счёте делает всё программное обеспечение безопаснее».

https://www.kimi.ai/blog/kimi-k3-1-pro

«The Linear Algebra Behind Google» — небольшая научная статья, в которой объясняется математика, лежащая в основе оригинального алгоритма Google PageRank.

В статье рассматриваются собственные значения и собственные векторы, стохастические матрицы, цепи Маркова и итерационные методы. На численных примерах и графиках авторы показывают, как работает PageRank.

Помимо разбора самого алгоритма и оригинальной научной работы Ларри Пейджа и Сергея Брина, статья будет интересна всем, кто хочет разобраться, как линейная алгебра применяется в одном из самых влиятельных алгоритмов в истории интернета.

https://sites.cs.ucsb.edu/~gilbert/cs111/

Claude Opus при проведении научных исследований может принять широко известный метод настройки гиперпараметров за настоящее научное открытие.

В новой статье Anthropic рассматривается одна из главных проблем современных исследовательских ИИ-агентов: они всё лучше справляются с экспериментами, но по-прежнему с трудом отличают действительно новые идеи от давно известных методов.

В рамках исследования Agent4Sci авторы протестировали Claude Code, Codex и Gemini на 20 реальных задачах из области машинного обучения для научных исследований.

Агенты самостоятельно изучали научные статьи, изменяли код, проводили эксперименты и пытались превзойти результаты, полученные авторами исходных работ.

В результате передовым агентам удалось добиться улучшений во всех 20 задачах, причём Claude Opus показал средний относительный прирост на 10,4%.

Однако дальнейший анализ выявил любопытную закономерность. Большинство улучшений достигалось благодаря хорошо известным приёмам машинного обучения: настройке гиперпараметров, замене оптимизаторов, объединению нескольких моделей и многократному локальному поиску.

При этом способность агентов самостоятельно оценивать научную значимость своих решений оставалась недостаточно развитой.

Они нередко переоценивали новизну собственных идей, не использовали доступные графические процессоры или, обнаружив перспективное направление, ограничивались дальнейшим подбором параметров.

Впоследствии исследователи добавили всего три небольших скилла:

- Генерация научных идей.
- Управление экспериментами.
- Периодическая самопроверка.

После этого средний прирост результатов Claude Opus увеличился с 10,4% до 20,1%, а Codex — с 4,4% до 8,1%.

Таким образом, главное ограничение современных исследовательских агентов заключается уже не столько в способности выполнять эксперименты, сколько в умении принимать обоснованные исследовательские решения.

Результаты показывают, что даже несколько простых скиллов, формирующих правильный подход к научной работе, способны почти вдвое повысить эффективность агентов без необходимости увеличивать вычислительные ресурсы.

Статья особенно полезна разработчикам, использующим Claude Code и Codex для проведения экспериментов.

https://arxiv.org/abs/2610.28763

Один и тот же отчёт, подготовленный Research Agent, два эксперта могут оценить совершенно по-разному. Возникает закономерный вопрос: насколько вообще надёжны наши Evals, если в роли оценщика выступает LLM Judge?

Недавняя статья Кэмерона Р. Вулфа как раз посвящена этой проблеме. В ней разбирается, как оценивать задачи агентов, где результат по своей природе во многом субъективен: например, Deep Research или творческое письмо.

Автор предлагает довольно практичный подход.

Сначала специалисты в предметной области определяют критерии оценки, после чего несколько экспертов независимо проверяют один и тот же набор результатов. Если их оценки сильно расходятся, сначала нужно пересмотреть сами критерии, а в некоторых случаях и вовсе отказаться от метрик, которые слишком субъективны для надёжной оценки.

Затем LLM Judge калибруют на данных, уже проверенных людьми. Повторные тесты и доверительные интервалы помогают не принять случайные колебания результатов за реальное улучшение модели.

И наконец, нужно вернуться к самому продукту: с помощью A/B-тестов и обратной связи от пользователей проверить, действительно ли рост показателей в офлайн-оценках приводит к улучшению пользовательского опыта.

Мне особенно близка мысль о том, что сначала нужно проверить самого оценщика.

При разработке Research Agents мы часто слишком внимательно следим за тем, растут ли показатели Eval, и гораздо реже задаёмся вопросом, насколько вообще надёжны критерии, по которым эти показатели считаются.

Эту статью определённо стоит сохранить тем, кто занимается Agent Eval. Особенно полезны разделы о выборке данных, калибровке экспертов и статистических методах.

https://cameronrwolfe.substack.com/p/subjective-evals