GPGPU *

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

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

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

В последнее время открытых моделей сверхбольшого размера развелось неимоверное количество, даже не просто моделей, а производителей. Вариации GLM, Kimi, DeepSeek занимают по нескольку строк в топ 5-10-20. Понадобилось перебрать основные LLM для тестов и выбора "рабочей лошадки", для чего пришлось немного пошуршать в интернетах. Оставлю в качестве памятки, вдруг кому-то окажется полезным.

Всё делалось на базе образов vllm-openai, платформ B200/H200 и дров 590.48.01. На момент начала экспериментов - примерно пару недель тому назад - версии vllm 0.16 ещё не было, но, как выяснилось в итоге, это не сильно повлияло на ситуацию. Основные костыли остались теми же самыми. Разве что кастомизация образа не для каждой модели нужна теперь.

В целом там, понятное дело, никакого RocketScience нету (особенно после того, как почитаешь китайские форумы в поисках нюансов). Но если бы кто-то посидел заранее и собрал советы в одном месте - жизнь была бы немного проще )) поэтому делюсь.

LLM научилась запоминать беседу, не подгядывая в контекст. Архитектуры типа Titans и обещают превращение цикла вывода в цикл онлайн-оптимизации

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

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

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

В данной статье я описываю свой опыт разработки приложений с OpenCL/SYCL.

Вычисления на видеокартах ассоциируются преимущественно с графикой, научными вычислениями и с недавних пор с нейросетями. Но чаще всего с графикой.

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

Самый краткий ввод в гетерогенное программирование: у нас есть две роли — хост и девайс, задача хоста – формировать задачи и отдавать их на девайс, в то время как задача девайса обработать их и вернуть результат. При этом хост и девайс могут быть одним вычислительным устройством (это не обязательно CPU + GPU, так как CPU может отдавать задачи сам себе).

Программа визуализирует решение и промежуточные результаты задачи Дирихле для уравнения Лапласа/Пуассона в прямоугольнике на CPU и GPU.

Уравнение Пуассона(при уравнение Лапласа) :

Задача Дирихле(краевые условия 1-го рода) - заданы значения на границе области(в данном случае в прямоугольнике).

Результаты визуализируются при помощи тепловой карты(HeatMap). Используются цвета и оттенки синего, сине-зелёного(циан), зеленого, желтого и красного цветов(от меньшего к большему значению).

Привет, Хабр! Меня зовут Даша Косова, я продакт менеджер Рег.облака. 

Когда-то 3D было для меня большим увлечением, которому я уделяла много времени. Я хорошо помню, как выглядел рендер на локальном компьютере: запускаешь сцену, смотришь как идут первые сэмплы. Сначала изображение зернистое, и только со временем начинает проявляться. Обычно на этом этапе ясно, что рендер займет часы, и компьютер лучше не трогать — можно пойти заниматься своими делами и просто проверять Blender время от времени.

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

Универсальный компилятор для FPGA, который понимает 42 языка программирования

Пишите код на любимом языке — получайте работающий Verilog для FPGA. Бесплатно, без vendor lock-in.

В прошлой статье я описывал как построить сетевую часть самодержавного сервера, пора принести в него что-то отдаленно разумное. Это руководство описывает весь процесс: от подготовки хоста Proxmox и настройки LXC-контейнера до поиска, конвертации и запуска embedding-моделей (на примере BAAI/bge-large-en-v1.5) с использованием Intel GPU для работы модели. Но будет легко запустить не одну модель или полноценного чатбота на этой основе. Главное, что будет ясно как использовать даже простое имеющееся железо домашнего сервера для этого.

Привет, Хабр! На связи команда Рег.облака. Мы давно следим за развитием Retrieval-Augmented Generation (RAG) и хотели проверить, как эта технология работает в живых сценариях. У нас есть ИИ-ассистент — это образ виртуальной машины с предустановленными Ollama, Open WebUI и набором моделей. Его можно развернуть в пару кликов и сразу работать с LLM в приватном окружении. Но мы решили пойти дальше и проверить, как он справится в прикладной задаче: собрать чат-бота для нашей техподдержки.

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

В этой серии статей разберёмся, почему на орбите до сих пор нет полноценных дата-центров, какие технологии приближают их появление, а что всё ещё остаётся фантастикой. Поговорим о лазерах и ретрансляторах, о проектах Китая, США и России, и реально ли охлаждать серверы в космосе.

Почему видеокарта, имеющая неплохие вычислительные возможности, в Stable Diffusion работает в 20 раз медленнее, чем RTX 3060? Почему в LM Studio она становится фаворитом, а в ComfyUI карета превращается в тыкву? Почему FurMark на CMP 90HX тормозит, а на CMP 50HX «бублик» крутится почти нормально? Разгадки в разных программных ограничениях, которые можно найти с помощью экспериментов. Я купил три майнинговые карты NVIDIA, чтобы понять, можно ли заставить их эффективно работать.

В этот раз мы рассмотрим: статистику производительности в LM Studio, как всё печально в ComfyUI и Stable Diffusion, анатомию программного кода GPU, почему оптимизации производительности дают на CMP обратный эффект, какие режимы вычислений могут раскрыть их потенциал.

Используем Vulakn API на Rust! На В этом руководстве мы шаг за шагом разберём, как создать Logical Device - основу для общения с вашей видеокартой. Без лишней магии, только чёткие объяснения и работающий код. Убедимся, что сложность Vulkan - это не страшно, а очень даже логично!

Теоретическая производительность майнинговых карт весьма высока, но синтетические тесты показывают, что они в 10 раз слабее игровых - где же правда?

На практике с LLM они оказались на уровне RTX 2060/3060. Эта статья для тех, кто хочет сделать дешёвый LLM-сервер и любителей хардкорных экспериментов.

Вероятно, вам уже попадались подобные руководства по CUDA: хрестоматийный пример «Hello World», в котором перемешан код для ЦП и графического процессора. Всё это сложено в один гетерогенный файл с исходниками на CUDA C++, а для запуска ядра применяется синтаксис NVCC с тройными угловыми скобками <<<>>>, который уже стал культовым:

Привет, Хабр! Сегодня я расскажу про реализацию матричного умножения и особенности разработки для GPU. Познакомлю вас с устройством GPU, объясню, чем отличается программирование от привычного для CPU, какие нюансы нужно учитывать для эффективной реализации операций GEMM. А затем сравним производительность разных подходов к реализации.

Код AI Flame Graphs теперь открыт, этот проект поддерживает GPU Intel Battlemage. Это значит, что AI Flame Graphs теперь способен генерировать flame-графики (Flame Graph, граф пламени, диаграмма пламени), охватывающие полный стек GPU — это даёт пользователям новые аналитические данные о производительности игр. Особенно полезным AI Flame Graphs выглядит в связке с FlameScope (это — мой опенсорсный проект, созданный несколько лет назад). Вот — пример профилирования игры GZDoom. Тут показаны результаты визуализации использования CPU и GPU, проведённые с помощью FlameScope и снабжённые комментариями.

Примерно через каждый день проходит то или иное событие в Москве в даты с 25 мая по 2 июня 2025 года. Видимо, мероприятия от организаторов Data Fusion не одноразовое, и что-то подобное планируется проводить ежегодно, поэтому интересно посмотреть программу данного фестиваля.

Наверное, я очень опоздал с изучением CUDA. До недавнего времени даже не знал, что CUDA — это просто C++ с небольшими добавками. Если бы я знал, что изучение её пойдёт как по маслу, я бы столько не медлил. Но, если у вас есть багаж привычек C++, то код на CUDA у вас будет получаться низкокачественным. Поэтому расскажу вам о некоторых уроках, изученных на практике — возможно, мой опыт поможет вам ускорить код.

Привет, Хабр. На связи команда Т1 Облако. Если вы следите за новостями в мире серверных видеокарт для ML, то точно знаете об Nvidia H100 — вычислительной молотилке на GPU, даже не имеющей видеовыхода. Она играет важную роль в области машинного обучения, анализа больших данных, 3D‑моделирования и много другого. Устройство корпоративного уровня, то есть домой себе такое купят разве что полтора энтузиаста.

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