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

Привет! На этой неделе, 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