Adept | Машинное обучение | Открытое ПО

Привет! Последние две недели занимаюсь расширением тензорного API и развитием функциональности, необходимой для обучения YOLOv11. Часть времени на прошлой неделе ушла на подготовку к конференции, поэтому темп оказался ниже, чем планировал. Но, несмотря на это, работа над задачами для YOLOv11 продолжается. Что сделано: 🔹 Тензорные операции Добавил arange для генерации последовательностей, утилиты создания тензоров и element-wise min/max. Реализовал clamp с forward/backward и Python-биндингами. Для sum() и mean() добавил keepdim, чтобы поведение было ближе к привычным ML-фреймворкам. 🔹 Скаляры и типы Перешёл от явных типов в аргументах к более гибкому std::variant для поддержки всего набора используемых типов. Сделал типизированную поддержку скаляров в Tensor::full() и Tensor::item(), включая динамический вывод формы. Это уменьшило количество неявных преобразований и сделало API более предсказуемым. 🔹 Boolean и unsigned integer Отдельная история — поддержка boolean. Сначала она выглядела как небольшая задача, но на практике потребовала заметно больше времени. Нужно было аккуратно продумать хранение bool в тензорах, взаимодействие со скалярами, приведение типов, проверки на уровне backend и корректный проброс в Python. Плюс добавил поддержку unsigned integer. В результате эти изменения затронули не одну точку в коде, а потребовали согласованной работы нескольких слоёв. 🔹 Контроль памяти Добавил проверки на contiguous-тензоры в backend-операциях. Это помогает раньше ловить ошибки, связанные с layout и памятью, и делает поведение операций более явным. 🔹 Python bindings Продолжаю приводить в порядок Python-слой. Добавил биндинги для новых операций, и сделал skill создания Python-биндингов для LLM агентов. 🔹 GPU backend Подготовил skills для разработки GPU-шейдеров и регистрации dispatcher. Это больше инфраструктурная работа, поэтому неплохо автоматизируется агентами. 🔹 YOLOv11 Продолжаю двигаться к обучению YOLOv11: обновил план реализации, добавил прототип loss-функции и подготовил inference pipeline с учётом нового tensor API. Итог: Базовый tensor API становится более зрелым, появляются элементы, необходимые для обучения моделей, и YOLOv11 уже выглядит как вполне достижимая цель 🚀 #tensor #cpp #python #machinelearning #deeplearning #yolo #yolov11 #gpu #autograd #computervision

Привет! На этой неделе, 1 августа, в Москве будет проходить конференция Back to Back. Я с коллегой в 16:30-19:00 буду проводить воркшоп «Реализация CUDA-расширения для PyTorch: ускоряем работу LLM». Кто будет на конференции присоединяйтесь, участие бесплатное но надо зарегистрироваться, на офлайн часть это можно сделать до конца завтрашнего дня. На воркшопе участники на практике познакомятся созданием расширения для популярного фреймворка PyTorch использующего CUDA ядра. В качестве примера мы запустим локальную LLM и измерим её производительность в реальном тесте. Начнём с краткой теории GPU, узнаем немного про работу LLM и познакомимся с инфраструктурой PyTorch для создания расширений на С++ и связыванием их с Python API. После чего реализуем оптимизации для работы модели как расширение для PyTorch. Участники: - напишут CUDA-ядра для функции активации GeLU - познакомятся с реализацией матричного умножения для GPU - реализуют расширение для PyTorch на С++ с интегрированными CUDA ядрами - используют созданное расширение в реализации LLM модели GPT2 написанной на Python API В конце сравним производительность базовой и оптимизированной версии модели посчитав количество токенов в секунду. Требования: уверенное владение C++, CMake и понимание Python.

⚡ Forward pass YOLOv11 — готов! За неделю с лишним закончил сквозной forward pass для модели YOLOv11 на Adept! 🚀 Добил тензорный движок до состояния, когда его можно использовать для реальных нейросетей. Основные изменения — по коммитам: 🧠 Core Tensor Operations - N-мерный transpose, concatenation, stacking — теперь и на CPU, и на Vulkan; - chunk / split с автоградом; - софтмакс на произвольной размерности с autograd; 🔧 Backend и Python-биндинги - reshape и view теперь принимают вариадик (можно писать view(1, -1, 4) как в PyTorch); - новые биндинги для тензоров и параметров Linear/Conv2d; - переработал контейнеры — Sequential, ModuleList стали ближе к torch; 📦 Neural Networks & Models - починил перенос внутренних индексов в MaxPool2d между устройствами; - адаптировал модель YOLO под обновлённое API тензоров. 🧩 Что было самым сложным Главная боль — изначально я не заложил в тензор полноценную поддержку slices, то есть смещения и шагов (strides). И реализовал базовые операции transpose, concat, stack только для одномерных случаев (по сути, только dim=1). Этого хватало для простых экспериментов, но для полноценного YOLO с многомерными тензорами потребовалась поддержка произвольных размерностей. Если бы я добавил strides с самого начала, то реализация этих операций и chunk / split для произвольных размерностей была бы существенно проще через использование slices и ядер типа scatter и gather. Теперь всё на месте и операции работают для любых размерностей — код стал проще и единообразнее. По биндингам — их тоже пришлось расширять, потому что без полноценного Python API удобный интерфейс не построить. Хотелось, чтобы модель на Adept писалась так же естественно, как на PyTorch и NumPy. Вроде получилось. 🎯 Что дальше Следующая остановка — функция потерь и цикл тренировки. Нужно: - реализовать loss (скорее всего, комбинация box + cls + dfl, как в оригинальном YOLO); - собрать тренировочный пайплайн с батчами. Дальше — больше. Всем удачи в ваших проектах! 💪 #YOLOv11 #Adept #TensorEngine #MachineLearning #PythonBindings

Привет! За неделю в ветке yolo-impl мы расширили набор слоёв в Adept. Новая функциональность: групповые свёртки, Winograd на CPU и GPU, транспонированная свёртка и апсемплинг. Всё — с поддержкой CPU и Vulkan GPU, без фолбэков, с автоградом и Python-биндингами. 🚀 Групповые свёртки Добавили параметр groups в Conv2d. Теперь можно эффективно резать каналы на группы — и на CPU (per-group im2col + GEMM), и на Vulkan (аналогичные шейдеры). ONNX-импорт и Python-биндинги — на месте. Тесты покрывают forward/backward для разных конфигураций. ⚡ Winograd: CPU с группами, GPU для 3x3 Доработали CPU-версию Winograd, чтобы она поддерживала групповые свёртки — вынесли буферы за цикл по группам, избежав лишних аллокаций (это критично для depthwise с большим числом групп). А следом завезли Vulkan-шейдеры для Winograd с ядром 3x3: три шейдера (преобразование входа, весов и обратное). Это даёт выигрыш в количестве умножений против im2col. Выбор пути — динамический, под капотом на основе аргументов операции. 🔄 Транспонированная свёртка (ConvTranspose2d) Нужна для апскейлинга в декодерах — в первую очередь для UNet и подобных архитектур. Реализована через im2col/col2im и GEMM с транспонированными весами. Оба прохода (forward/backward) — на CPU и на Vulkan. Инициализация Kaiming-He, тесты с наивной референсной реализацией, Python-биндинги. 📐 Upsample (Nearest + Bilinear) Два режима интерполяции, поддержка align_corners. Реализация - 4 Vulkan-шейдера (forward/backward для каждого метода) и оптимизированный CPU-код. Биндинги в Python — есть, так что можно использовать в питоновских скриптах. Итог: Мы закрыли ключевые потребности детекторов (YOLO) и добавили фундамент для генеративных/сегментационных сетей (UNet). Code review и идеи по оптимизации приветствуются! 👨‍💻 #YOLO #UNet #Conv2d #ConvTranspose2d #Upsample

Реализация DataSet для YOLOv11 на базе Adept завершена! Рассказываю, как я наступил на грабли с разделяемой памятью в многопроцессном DataLoader’е. 🔍 Предыстория В Adept есть модуль shared_mem_manager.cpp, который отвечает за межпроцессное взаимодействие через разделяемую память. При указании num_workers > 0 в DataLoader каждый воркер — отдельный процесс, и они синхронизируются через общий буфер. Всё шло гладко, пока я не запустил тренировку с несколькими воркерами. И тут — segmentation fault 💥. Не в логике обработки данных, а в коде синхронизации. ⚠️ Симптомы Ошибка валилась в коде: struct ShmInfo { std::atomic<int> ref_counter; }; class SharedMemoryBuffer : public SharedBuffer { void close() { ShmInfo* shm_info = static_cast<ShmInfo*>(ptr_); if (--shm_info->ref_counter == 0) { // ... } }; Сначала я грешил на гонку потоков или двойное освобождение буфера. ref_counter — atomic, всё должно быть потокобезопасно. Но почему тогда падает? Я потратил несколько часов, перепроверяя логику счётчика, синхронизацию процессов, порядок создания и удаления буферов. Всё выглядело корректно. Но segfault упрямо появлялся при обращении к shm_info. 🧠 Истина оказалась прозаичнее Если посмотреть на размер при создании и удалении отображения: Конструктор: SharedMemoryBuffer(void* ptr, const std::string& filename, size_t size, bool create) : ptr_(ptr), filename_(filename), size_(size + shm_alloc_offset) { ... } Тут размер буфера увеличивается на shm_alloc_offset — это нужно для хранения метаданных (в том числе ShmInfo) в начале сегмента. Деструктор / close: CHECK(munmap(ptr_, size_ + shm_alloc_offset) == 0, ...); В close() мы снова прибавляем shm_alloc_offset к size_, но size_ уже включает это смещение. В итоге munmap пытается освободить больше памяти, чем было выделено. Итог: выход за границы отображённой области, повреждение служебных структур, падение в самом неожиданном месте. 💡 Уроки 1. Двойное смещение — классика. Легко запутаться, когда константа применяется в разных местах. Лучшим решением было бы реализовать функцию возвращающую размер и использовать константу в одном месте. 2. Ошибки работы с памятью маскируются — проблемы могут возникнуть практически в произвольном месте кода не связанном с реальной ошибкой. Поэтому такие баги - одни из самых коварных. 3. Address Sanitizer (ASan) — лучший друг 🛠️. Если бы я сразу запустил бинарник с ASan, он скорее всего указал на некорректный размер в munmap. Не пренебрегайте санитайзерами. Берегите память, коллеги, и пусть ваши munmap всегда точно совпадают с mmap! 😉 #Adept #C++ #DataLoader #Segfault #MemoryManagement #AddressSanitizer

В NumPy и PyTorch поддерживаются тензоры, у которых одна или несколько осей имеют нулевую длину. Например: np.zeros((0, 24)) # форма (0, 24) torch.empty((17, 0)) # форма (17, 0) Это полноценные объекты, с которыми выполняются стандартные операции (сложение, умножение, транспонирование, конкатенация при согласованных размерностях). Такие тензоры часто называют «пустыми» (empty tensors), но они не являются None и не требуют специальной обработки на каждом шагу алгоритма. 🔍 Зачем они нужны? Главное преимущество — единообразие кода. Вместо проверок if data is not None на каждом этапе вы создаёте пустой тензор с нулевой длиной по нужной оси и продолжаете работать с ним как с обычными данными. Финальная проверка (например, наличие хотя бы одного элемента в пакете) откладывается до самого конца пайплайна. 💡 Пример из загрузки датасетов При сборке батча некоторые примеры могут не иметь разметки. Вместо пропуска или вставки заглушек вы формируете тензор формы (0, num_features) и объединяете его с остальными через torch.cat – операция корректно обрабатывает пустой тензор, не нарушая размерность. Лишь на этапе подсчёта функции потерь вы проверяете, что размер батча > 0. ⚙️ Другие сценарии использования - Обработка последовательностей переменной длины – пустые последовательности удобно представлять тензорами с нулевой длиной. - Фильтрация данных – если после условий выборки не осталось элементов, результатом становится пустой тензор. - Агрегация в группах – группы без данных возвращают пустые тензоры, упрощая универсальные функции редукции. 🚧 Проблема при портировании на Adept В Adept концепция тензоров с нулевой размерностью не поддерживается. Библиотека проверяет размерности на этапе выполнения и генерирует исключение при обнаружении оси длины 0. Это существенно затрудняет перенос кода из NumPy/PyTorch. Я столкнулся с этим при реализации DataLoader для тренировки модели YOLO. В исходной PyTorch-версии пустые тензоры свободно использовались для тренировочных данных без разметки. При адаптации под Adept пришлось вносить дополнительные проверки при формировании пакета. Оптимальным решением будет расширить Adept поддержкой нулевых размерностей по аналогии с NumPy и PyTorch. Это позволит писать более лаконичный и надёжный код, избегая избыточных проверок и упрощая миграцию проектов между фреймворками. Также это снизит порог входа для новых пользователей. #NumPy #PyTorch #Adept #Tensor #DataLoader

Мой доклад про роль C++ в ML выложили в виде статьи на Хабр: https://habr.com/ru/companies/yadro/articles/1048932/

Привет! Немного новостей про развитие проекта: - В мастер ветку добавлено распределённое обучение по данным, на основе Open MPI с синхронизацией через хост. Аналог DDP в PyTorch. - Активно работаем над интеграцией библиотеки для логгирования. Думаю в ближайшее время добавим. - Также в ближаших планах добавить пример реализации и обучения, в том числе распределённого, модели YOLO v11. - Уже есть прототип реализации новой архитектуры вычислительного графа, который позволит проводить оптимизации. Думаю после реализации и тестирования YOLO сделаем релиз библиотеки и выложим модуль для Python.

Привет! Извините что не по теме канала, но думаю кому-то может быть интересно. Большинство демок ИИ-агентов — это либо обёртки над готовыми фреймворками (LangChain, CrewAI), либо простые демки с одним тулом. Я решил пойти другим путём: написать агента с нуля, на голом OpenAI API, без использования «агентных фреймворков». Что получилось: агент, который сочиняет стихи на русском языке. Но суть не в стихах, а в архитектуре. Проект состоит из модулей: — цикл агента (до 1000 итераций «мысль → вызов тула → ответ») с потоковым взаимовоздействием — регистратор инструментов с использованием OpenAI-совместимых JSON-схем — менеджер контекста (контроль количества токенов и трёхстадийная компрессия) — системный промпт с полным описанием алгоритма Инструменты, которые агент использует: - веб-поиск (с фильтрацией доменов) - векторная память (ChromaDB + bge-m3, дедупликация по хешу) - чтение/запись/поиск-замена в файлах (песочница в рабочей директории) - расстановка ударений в русском тексте — для проверки стихотворного размера - управление собственной «креативностью» меняя температуру при выводе Что мне кажется самым важным — алгоритм действий агента описан прямо в системном промпте, это как привила и умения. То что он реализован не в коде, позволяет легко изменить агента для других задач. Агент читает много-фазную инструкцию и выполняет её, переключая креативность в зависимости от этапа: 0.4 для поиска → 1.0 для синтеза → 1.2 для генерации строк → 0.3 для валидации метра стихов. При этом: - каждая строфа проходит несколько попыток создания - пользователь утверждает план на каждую строфу и полный вариант - если агент «застрял» — он просит совета у пользователя Используйте что бы разобраться как работают те же KiloCode, Claude Code на базовом уровне, или как основу для своих специализированных агентов. Код: https://gitflic.ru/project/kolkir/lmagent #agent #llm #AI #opensource #python

Привет! В очередной раз решил сделать Docker образ с Vulkan-бэкендом для сборки проекта. Дело в том что публичные образы (например, localai/localai:latest-gpu-vulkan или j3soon/vulkan-runtime) устарели: в них либо старая версия SDK, либо отсутствует актуальный toolchain (CMake, Python, Node.js), либо нет актуальной поддержки X11/Wayland. Использовать их без существенных доработок не получилось, из-за чего я переключил CI сборку чисто на хост систему. И в последних PR мы получили проблемы с использованием различных сред разработки. Решение: собственный многостадийный Dockerfile. - Base toolchain — устанавливается всё для компиляции и линтинга (clang, ccache, doxygen, Python 3.11, Node.js 20 LTS). Без Vulkan. - Vulkan SDK — загружается и настраивается конкретная версия SDK (1.4.341.0) с runtime-зависимостями. - Финальный образ, куда копируются только нужные артефакты от предыдущих стадий. Это сокращает размер образа и исключает «мусор» из промежуточных слоёв. Как используем: В VS Code DevContainer — в devcontainer.json пробрасываются GPU (--gpus all, /dev/dri), X11 и сеть хоста. Разработчик работает в изолированной среде, идентичной CI. В CI (self-hosted) — в YAML-описании указывается предварительно собранный образ (экономим время на установке зависимостей при каждом запуске) и те же флаги рантайма: --gpus all, --device=/dev/dri, --network=host. Это гарантирует, что Vulkan-тесты реально выполнятся на GPU. Результат: воспроизводимые сборки, отсутствие «у меня работает» на машине разработчика, а CI ловит проблемы со средой сборки на начальных этапах. Рекомендую использовать контейнеризацию для разработки всегда когда это возможно, хотя с GPU это бывает непросто. #Docker #Vulkan #CI #DevOps #Cpp #DevContainer

Вкину анонс весеннего слета FPGA-сообщества от YADRO. От ИТМО на нем выступит Иван Дейнека: к.т.н, доцент Высшей инженерно-технической школы и автор open-source "Руководства по реализации Edge AI на FPGA" . Почитать руководство (или даже законтрибьютить в него) можно тут: https://github.com/debreti/nirsii-fpgai Подробности про мероприятие: 26 мая в 19:00 приглашаем вас присоединиться к онлайн-трансляции. В этот раз поговорим об RTL-разработке и синтезе, документировании RTL и применении ИИ в FPGA/ASIC-разработке. Среди тем выступлений: 🔸open-source-инструмент Yosys, 🔸применение и преобразование SystemRDL в читаемую документацию, 🔸реализация Edge AI на программируемой логике, 🔸CLI-инструмент для анализа вейвформ с помощью LLM. Своим опытом поделятся эксперты YADRO, ИТМО и независимые RTL-разработчики. Чтобы получить ссылку на трансляцию и все материалы, зарегистрируйтесь. Доклад Ивана будет про "Edge AI на ПЛИС: тенденции и руководство по размещению". Аннотация следующая: "В докладе расскажу о преимуществах реализации концепции Edge AI на программируемой логике. Продемонстрирую практическое руководство по размещению нейросетей на FPGA и разберу реализацию полносвязной сети на языке описания аппаратуры, а также свёрточной сети через высокоуровневый синтез."

Думаю должен быть интересный доклад про EdgeAI на FPGA

Появляются новые вычислительные бекэнды на Vulkan. В рамках секции Open Source на DataFest 2026 будет доклад "ggmlR:Vulkan GPU-бэкенд для R" Юрия Барамыкова старшего руководителя проекта Иннотех. Код проекта: https://github.com/cran/ggmlR

Привет! Закончилась ежегодная конференция C++ Russia. В этом году я продолжил знакомить участников с проектом Adept, рассказывал про устройство работы конвейера запуска вычислительных шейдеров. А ещё мы провели мастер-класс где участники познакомились с основами разработки для GPU и попробовали сами создать расширение для PyTorch.

Привет! Я на днях делал доклад "Актуальность и области применения языка С++ в современном ML" на конференции "Современные технологии в теории и практике программирования" в Санкт-Петербургском Политехническом Университете. К сожалению записи с мероприятия нет, но я делюсь видео с подготовки доклада. Надеюсь кому-то будет полезно. https://rutube.ru/video/bc863eb9180b8cf67d118bb4b2ab1cb7/

Привет! Я открыл PR который добавляет реализацию срезов и изменяет API индексации тензоров. Он вносит существенные изменения в движок обработки тензоров и затрагивает больше 150 файлов. Я начинал реализацию вручную потом использовал coding агентов. Буду благодарен сообществу за помощь с code review, комментарии и предложения. Также есть возможность посмотреть какой С++ код сегодня генерирую агенты с использованием моделей Qwen Coder 3.5, GLM-5.1, Grok Code fast 1. Основные изменения: Изменено внутреннее представление тензоров для поддержки срезов: - Добавлено смещение(offset) для буфера данных - Добавлены смещения по размерностям(strides) API индексации тензоров: - Тип Slice для гибкого слайсинга с параметрами начала, конца и шага - Тип Index для целочисленной индексации (сокращение размерности) - Поддержка Ellipsis и None для продвинутых паттернов индексации - Синтаксис, совместимый с NumPy и PyTorch: tensor[1:5], tensor[::2], tensor[:, 1] Операции сбора (gather) для копирования данных с учётом срезов: - SIMD ядра и шейдеры для Vulkan - Поддержка отрицательных индексов для обоих бэкендов GEMM API вместо matmul: - BLAS совместимый API для CPU и GPU - Добавлены параметры alpha и beta Python-привязки: - Полная поддержка срезов через getitem и setitem - Автоматическое создание представлений и управление непрерывностью - Многомерная индексация с правильной обработкой форм Пример кода: import adept as ad # Создание тензора t = ad.Tensor([1, 2, 3, 4, 5]) # Базовый срез sliced = t[1:4] # Многомерная индексация matrix = ad.Tensor([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) row = matrix[1] col = matrix[:, 1]

Привет! Небольшая сводка изменений за последние 3 недели. Вышло 3 фичи, которые делают работу с библиотекой удобнее. Вот что теперь может сделать Python-разработчик: 🖥 Детекция GPU через Vulkan Теперь можно программно узнать, какой GPU доступен на машине: import adept if adept.vulkan.is_available(): print(f"GPU: {adept.vulkan.get_device_name(0)}") model = model.gpu() Зачем: • Запускать инференс на GPU с автоматическим fallback на CPU • Логировать модель видеокарты для телеметрии и дебага • Строить device selection UI, как в других ML-фреймворках 🔍 Фильтрация параметров модели по имени Два новых метода в классе Module: # подстрока for name, p in model.named_parameters("weight"): ... # Регулярное выражение for name, p in model.named_parameters_regex(".*layer[23].*bias"): ... Зачем: • Selective fine-tuning — заморозить одни слои, разморозить другие • Группы параметров в оптимизаторе — разный learning rate для весов и смещений • Weight decay только для weight-тензоров — исключить bias и batch-norm running stats • Быстрая инспекция модели — не нужно руками обходить все child-модули ⚡ Оптимизация autograd Теперь при выключенном авто-дифференцировании (no_grad) не создаются лишние объекты для хранения градиентов. Это затронуло все основные слои: Linear, Conv2d, BatchNorm2d, MaxPool2d, AvgPool2d, активации и loss-функции. Зачем: • Меньше расход памяти — no-grad mode больше не аллоцирует ненужные autograd-ноды • Быстрее инференс — нет накладных расходов на создание и удаление временных объектов • Predictable performance — поведение no_grad ближе к «bare metal», как и ожидается #gpu #autograd #changelog #python #inference #optimization

Привет, я делал доклад на тему «Эмуляция запуска GPU-ядер на CPU или нестандартные приёмы отладки». Выкладываю презентацию, в которой рассказываю про реализацию симулятора, воспроизводящего модель выполнения GPU (Grid → Block → Thread) с полной интеграцией в GDB. В отличие от CUDA, где есть много иструментов для отладки и анализа, экосистема Vulkan и OpenCL практически лишена инструментов пошаговой отладки общего назначения. Презентация показывает трюки, позволяющие разрабатывать и отлаживать ядра без физического ускорителя. Ключевые архитектурные решения: • Lockstep-исполнение на корутинах (C++23): Каждый поток реализуется через std::generator. Вызов co_yield эмулирует аппаратный барьер, а внешний диспетчер синхронно продвигает все генераторы, обеспечивая детерминированное блокирующее выполнение, идентичное __syncthreads(). • Иерархия контекста и памяти: Контекст инкапсулирует координаты потоков и размеры сетки/блока. Выделяются именованные области разделяемой памяти с семантикой, повторяющей shared, для кооперативной работы потоков внутри блока. • Трекер доступа к памяти: Прокси-обёртка над буферами логирует каждое чтение/запись с привязкой к координатам потока. Постобработка группирует доступы, проверяет последовательность адресов для соседних потоков и рассчитывает метрику эффективности группировки и распределение шагов (strides). • GDB Python-инфраструктура: Кастомные pretty-printers и специализированные команды позволяют инспектировать состояния блоков, разделяемую память и визуализировать линейные буферы как 2D-матрицы прямо в сеансе отладки. Презентация Код проекта #VulkanCompute #Cpp #Coroutines #GDB #GPUDebugging #SIMT

Channel name was changed to «Adept | Машинное обучение | Открытое ПО»