GPGPU *

Бизнес нацелился делать свой собственный AI. Все задают вопрос: «Какая модель мне нужна?» Но никто не задумывается, на каких мощностях модель будет работать. 

Мы тоже сначала не задумывались. Разработали корпоративного AI-агента, прокачали ИТ-команду, чтобы двигаться дальше — и споткнулись о «железный порог». Так родилась идея AI ready модуля. В статье рассказали, что это такое и почему AI начинается не с модели, а с инфраструктуры. 

На рынке софта для оптимизации есть две крайности.

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

На этом фоне AGIQ Solver Enterprise оказывается любопытным кейсом. Не потому, что это «магия на видеокарте» или «квантовый компьютер для бедных», а потому что продукт пытается занять вполне конкретную нишу: быстрый поиск хороших решений в сложных булевых и оптимизационных задачах за счёт GPU и квантово-вдохновлённой логики поиска.

Ниже — разбор, что это вообще такое, где оно действительно может пригодиться, почему здесь вообще всплывает слово «квантовый», и как с этим работать на практике.

Вокруг квантовых вычислений много маркетингового шума. Если вы попытаетесь смоделировать честное 48-кубитное квантовое состояние в комплексном базисе complex128, то неизбежно упретесь в «стену памяти» в 4.5 Петабайта. Если же вы решите применить блочную декомпозицию пространства состояний для ее поочередного обсчета, то упретесь в «стену времени» длиною в несколько лет непрерывных вычислений на GPU.

В этой статье мы разберем проект гибридного симулятора, который обходит обе стены, удерживая потребление видеопамяти в пределах 268 МБ, а время симуляции сокращает в 400 раз.

Давайте сразу снимем маски: физически данный симулятор не удерживает 48 кубитов в единой суперпозиции. Между старшей и младшей половиной регистра полностью отсутствует квантовая запутанность (entanglement).

Вместо этого применена жесткая, но эффективная классическая блочная декомпозиция (принцип Space-Time Trade-off, то есть размен памяти на время):

С момента публикации статьи на Хабре «Импортозамещаем numpy, pandas, scipy и sklearn» прошло почти три года. В течение этого времени я приостановил работу над проектом из-за нехватки времени, ресурсов и сил. К тому же, меня расстроило, что не смог выполнить просьбу пользователя @N-Cube, который активно интересовался моей библиотекой и хотел ускорить работу своего Jupyter Notebook.

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

За это время в библиотеки были добавлены поддержка CUDA, множество ручных SIMD-оптимизаций с динамическим выбором SIMD, несколько реализаций линейной регрессии и многое другое.

Давайте рассмотрим, что на сегодняшний день позволяет сделать моя библиотека.

Я представлю несколько тестовых примеров в двух вариантах: с использованием AVX-2 на процессоре Intel® Core™ i7-4790K и AVX-512 на Intel® Xeon. Также покажу результаты замеров для каждого из них. Все тесты проводились без использования GPU, исключительно на процессоре. Это позволяет сравнивать производительность Python и моей библиотеки на равных условиях. Операционная система – Ubuntu 24.04, компилятор – GNU 13.3.0.

Нет, не для того, чтобы вытеснить с рынка NVIDIA, хотя в перспективе и такое возможно. Как бы то ни было, компания SpaceX неожиданно раскрыла планы по созданию собственных графических процессоров. Пока речь идет только о планах по выпуску продукции под собственные нужды (да, в космосе тоже нужны GPU). Посмотрим, что и зачем планирует выпускать корпорация Илона Маска.

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

Индустрия ИИ сегодня напоминает строительство Вавилонской башни. Пока гиганты вроде OpenAI, Google и Meta соревнуются, кто закупит больше H100 и сожжет больше мегаватт, я разрабатываю детерминированное ИИ-ядро на обычном MacBook Air M2 (8GB RAM). В этой статье я расскажу, почему текущий путь развития нейросетей - это тупик, и как математика O(1) на языке Rust решает проблему галлюцинаций.

В новой статье наш эксперт Антон Пчелинцев размышляет о причинах дефицита качественных данных, следующем прорыве в области развития ИИ и о том, что делать для получения преимущества.

В статье расскажем, как мы командой Yandex Infrastructure внедрили QoS в сетях InfiniBand при ограниченной вендорской поддержке и скудной практической документации. Обсудим мотивацию: рост смешанных нагрузок во внутреннем облаке и необходимость предсказуемых SLO для различных обучений. Отдельно рассмотрим как могут быть связаны QoS и топология сети DragonFly+.

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

Это четвертая статья из цикла От MNIST к Transformer, цель которого пошагово пройти путь от простого CUDA ядра до создания архитектуры Transformer - фундамента современных LLM моделей. Мы не будем использовать готовые высокоуровневые библиотеки. Мы будем разбирать, как все устроено под капотом, и пересобирать их ключевые механизмы своими руками на самом низком уровне. Только так можно по настоящему понять как работают LLM и что за этим стоит. В этой статье мы разберем как работает градиентный спуск, реализуем его и обучим нашу модель для распознования mnist датасета.

Приготовьтесь, будет много кода на C++ и CUDA, работы с памятью и погружения в архитектуру GPU. И конечно же математика что за этим стоит. Поехали!

Кейс полностью автономного траблшутинга нетривиальной системной проблемы с неработоспособностью NVENC в Docker-контейнере на Jetson Orin NX с помощью Claude Opus 4.6, как пример выхода больших языковых моделей за пределы квалификации middle-grade инженера. Около 40 минут заняло расследование проблемы, по мотивам которого, я попросил сеть написать статью, которую и предлагаю вашему вниманию как пример того, на что я мог потратить целый день, а большинство middle-grade инженеров бы не справилось вообще. Весь траблшутинг и статья сделаны в полностью автоматическом режиме без участия человека.

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

Для всех юридических экспертов, читающих это: моя компания подала форму SB/43 в USPTO и оплатила пошлину за отказ от конечной части срока действия патента № 10 373 352, действующий с 17 марта 2026 года.

16 марта 2026 года на конференции GTC компания NVIDIA представила DLSS 5. Если раньше DLSS в основном помогал поднимать FPS и улучшать картинку за счет апскейлинга, то теперь речь идет уже о другом уровне. DLSS 5 подают не как очередное обновление технологии масштабирования, а как шаг к нейронному рендерингу - когда искусственный интеллект не просто дорисовывает недостающие пиксели, а глубже вмешивается в то, как выглядит сцена.

Казалось бы - а в чем проблема? Но все оказалось не так очевидно и вокруг анонса сразу начались споры. Чтобы понять, почему реакция оказалась такой резкой, давайте вспомним, как вообще развивалась графика в играх.

Привет, Хабр! На связи Илья Мартысь из Рег.облака. Сегодня расскажу, как мы переезжали в новый московский дата-центр, почему именно DataHouse «Магистральный-1» и при чем здесь серверы с NVIDIA H200.

3 дня борьбы с ROCm, RX580 и Ollama: как я запустил LLM на домашней видеокарте

Я попытался запустить LLM inference на старой AMD RX580 через ROCm и Ollama в Kubernetes. GPU определялся, VRAM занималась, контейнеры запускались — но inference падал с ошибками hipMemGetInfo, а иногда просто выдавал бессмысленный текст.

В статье — полный инженерный разбор:как диагностировать реальный GPU compute (а не просто VRAM usage), почему Vulkan помог найти root cause, какие версии ROCm и kernel оказались рабочими, и как добиться стабильной генерации ~42 tokens/sec на RX580.

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

Это третья статья из цикла От MNIST к Transformer, цель которого пошагово пройти путь от простого CUDA ядра до создания архитектуры Transformer - фундамента современных LLM моделей. Мы не будем использовать готовые высокоуровневые библиотеки. Мы будем разбирать, как все устроено под капотом, и пересобирать их ключевые механизмы своими руками на самом низком уровне. Только так можно по настоящему понять как работают LLM и что за этим стоит. В этой статье мы перейдем от матриц к такому понятию как тензоры, напишем умножение тензоров, так же создадим свой первый линейный слой или полно-связную нейронную сеть. И наконец напишем сеть для распознования mnist датасета.

Приготовьтесь, будет много кода на C++ и CUDA, работы с памятью и погружения в архитектуру GPU. И конечно же математика что за этим стоит. Поехали!

Массовое применение и внедрение ИИ-технологий среди обычных потребителей случилось буквально пару лет назад. В 2023-м нас всех поражала возможность ChatGPT писать логически складные и осмысленные абзацы, а качество картинок с Midjourney вообще вызвала ажиотаж и беспокойство о будущем профессий художника и дизайнера. 

И ИИ-контент еще не выглядел так инородно: если сегодня каждый третий Shorts или картинка в соцсетях сгенерированы, то в 2023 году многим и в голову не могло прийти, что картинку можно нарисовать нечеловеческими «руками».

И именно в тот год один ушлый художник решил провернуть перформанс, который зашел слишком далеко. Настолько, что смог обмануть весь Twitter (X) и кучу авторитетных зарубежных СМИ, включая The Verge, Tom Hardware и TechRadar. 

Имя авантюры: Del Complex — независимый плавучий город с 10 тысячами GPU-ускорителей H100 на борту посреди океана. Вспомним, как это было и как удалось разоблачить эксперимент одного художника.

Привет, Хабр! Меня зовут Андрей Шукшов. Я пишу YNMT в Яндекс R&D — это движок инференса, на котором работают почти все наши большие языковые модели (LLM). Бо́льшую часть времени я пытаюсь понять, почему некоторые вещи работают медленно и как сделать так, чтобы у них это получалось чуточку быстрее.

Если вы запускали локальную LLM, то, возможно, тоже удивлялись: почему железо, способное рендерить фотореалистичные миры в реальном времени, работает в темпе печатной машинки? В своей статье я попробую хотя бы отчасти ответить на этот вопрос. Под микроскопом посмотрим на механизм Attention в режиме генерации (декодирования) и, вооружившись лучшими современными практиками ускорения на GPU, объединим всю математику в один эффективный kernel, который выжмет максимум производительности из имеющегося у нас железа.

В этой статье разберём, как Unreal Engine строит Hierarchical Z Buffer (HZB).

Покажем, как вычисляются размеры mip-уровней, зачем нужно специальное округление float, как используются функции Gather, батчинг нескольких mip-уровней за один Dispatch, groupshared память, wave-операции и Morton Z Curve.

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

Писать быстрые GPU‑ядра вручную долго и требует узкой экспертизы: нужно понимать модель памяти, эффективные паттерны доступа к памяти, ограничения конкретного бэкенда и уметь быстро разбираться в compile и runtime ошибках. При этом выигрыш от кастомного kernel'а может быть очень заметным. Поэтому автоматизация и упрощение процесса разработки ядер — практически важная задача.

В этой статье расскажу о KernelEvo — новом фреймворке от команды «Вычислительный интеллект» Института AIRI, позволяющем по исходному коду автоматически искать эффективные cuda и triton реализации. Ключевая идея простая: вместо ручного цикла «написал → проверил → увидел ошибку → переписал» мы строим автоматический search loop. В типовом сценарии на одну задачу уходит до ~1 млн токенов, что делает такой поиск достаточно выгодным для регулярных запусков.

Подробности далее.