Буквально на днях Андрей Карпаты, один из ранних сооснователей OpenAI, покинувший компанию, исследователь нейросетей, опубликовал на Гитхаб фантастическую вещь: чистый (без специализированных библиотек) 200-строчный python-код трансформера, аналога GPT-2, для изучения всеми желающими. И написал в блоге статью для понимания этого кода (и работы трансформеров). Я перевёл статью и комментарии к коду — ведь этот код (я уверен!) войдёт в ИТ-историю...

Присоединяйтесь к этому завораживающему сеансу разоблачения gpt-магии, за считанные годы овладевшей миром!..

В этой статье пойдет речь об одной из самых сложных и интересных архитектур — трансформере, лежащей в основе современных моделей от OpenAI и Google DeepMind. И это не научпоп для обывателя с наивным уровнем объяснения, а полноценный учебный материал, который поможет вам понять работу трансформера на фундаментальном уровне без черных ящиков типа TensorFlow и Pytorch.

А для того чтобы лучше вникнуть, давайте напишем настоящий мини-трансформер на процедурном Python и обучим его!

Данный материал можно изучать в разных режимах:

* Как объяснение архитектуры для общего представления;

* Как полноценный гайд с чтением кода и самостоятельной практикой;

* Как основу для собственных экспериментов.

Вы сами можете выбрать тот режим, который нужен для ваших целей на данный момент.

Наш трансформер будет довольно простым: со статическим графом и одноблочными энкодером и декодером. Сам код написан в парадигме процедурного программирования (за исключением некоторых модулей) и может быть прочитан на любом уровне и без знания ООП. И все же это будет полноценный обучаемый трансформер с мультиголовым вниманием, батчами данных, параллельным вычислением и множеством параметров.

Для закрепления материала, выполните Домашнее задание, которое ждет вас в конце статьи.

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

Каждый, кто хоть раз вводил pip install transformers, наблюдал, как терминал начинает безостановочно выводить простыню зависимостей: pytorch, accelerate, bitsandbytes, peft и многие, многие другие. Но если PyTorch является фундаментом, настоящим Атлантом, на плечах которого держатся тензорные вычисления, то какую роль играют его помощники?

В этой статье мы проведём ревизию джентльменского набора LLM инженера. Для этого мы изучим функционал, методы работы и даже заглянем в исходный код таких библиотек, как PyTorch, Transformers, Accelerate, Bitsandbytes, PEFT и Unsloth. Эти знания позволят вам видеть за списком импортов не просто названия, а четкую структуру, на которой держится ваше приложение.

Привет, Хабр! Когда начинаешь новый проект на FastAPI, всё кажется простым: пара моделей Pydantic, несколько эндпоинтов — и готово. Но через полгода и 20 000 строк кода оказывается, что базовая валидация размазана по всему приложению, бизнес-логика перемешана с обращениями к БД, а тесты пишутся со скрипом.

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

Как поднять мультимодальный AI-сервис (OCR, ASR, LLM, TTS) на одной GPU 16GB без облачных API?

Разбираем пошагово:

• Подготовка VPS (Ubuntu + CUDA + драйверы)

• FastAPI-архитектура с PyTorch/Transformers

• Управление памятью (без OOM-ошибок)

• Продакшен: systemd + Nginx + HTTPS + домен

• Тестирование в Swagger

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

Для кого: DevOps, Python-разработчики, AI-интеграторы, стартапы.

Исходники в репозитории, демо-видео, лайфхаки по разработке прямо на сервере!

Облачные ассистенты вроде Алисы, Google Assistant и Siri давно стали привычными. Но у всех у них одни и те же слабые места: зависимость от быстрого интернета и риск утечки данных. И речь не только о персональной информации — дома нередко обсуждают темы, которые можно отнести к коммерческой или даже военной тайне. Неудивительно, что многим некомфортно говорить в присутствии микрофона, который каждое слово отправляет куда-то «в облако» (один из наших заказчиков прямо сказал: «никаких Алис в доме не будет»).

На Хабре уже появлялись статьи про попытки заменить Алису на полностью локальные решения. Но почти всегда все сводилось к стандартной схеме: ESP32-микрофон → Home Assistant → intent recognition. Такая связка работает, но до действительно «умного» ассистента ей далеко.

Мы пошли дальше и собрали свой голосовой ассистент, о котором расскажем в статье.

Привет! Меня зовут Миша Васильев, я разработчик в команде AI Битрикс24.

В последнее время мы часто говорим про МСР и вот, наконец, решили рассказать простыми словами о том, что это такое, как работает, как мы это используем и планируем использовать. Если коротко, то MCP — это АРІ для LLM.

Все мы начинали с print() для отладки, но в серьезных проектах это превращается в хаос. Стандартный logging? Мощно, но громоздко. Пора это исправить.

Loguru — это библиотека, которая делает логирование простым, как print(), и мощным, как logging, но без боли и десятков строк конфигурации. В статье покажу, как одной строкой настроить цветные логи, автоматическую ротацию файлов и ловить исключения с полным контекстом переменных. Заходите, чтобы сделать свою отладку в разы приятнее.

На данный момент я прохожу 5-дневный интенсив по AI-агентам от Google и параллельно веду собственный конспект. Эта статья представляет собой перевод оригинального материала, выполненный с помощью Gemini и мной. В некоторых местах я немного упростила формулировки или обобщила идеи.
Оригинал материала можно найти тут Introduction to Agents.

Вы научились получать и обрабатывать данные. Но что дальше? Как хранить эту информацию надежно, а не в CSV-файлах? Как поделиться результатами своей работы с другими, предоставив им удобный доступ через API? Что делать, если сайт настолько сложен, что Requests не может справиться с его динамическим контентом? И как убедиться, что весь написанный вами код не сломается после очередного изменения?

Прошло семь лет с момента разработки оригинальной архитектуры GPT. На первый взгляд, если оглянуться на GPT-2 (2019) и взглянуть вперёд на DeepSeek-V3 и Llama 4 (2024–2025), можно удивиться, насколько эти модели по-прежнему структурно схожи.

Разумеется, позиционные эмбеддинги эволюционировали от абсолютных к роторационным (RoPE), Multi-Head Attention в значительной степени уступил место Grouped-Query Attention, а более эффективная SwiGLU заменила такие функции активации, как GELU. Но если отбросить эти незначительные усовершенствования, действительно ли мы наблюдаем принципиальные архитектурные сдвиги — или просто продолжаем полировать одни и те же фундаментальные конструкции?

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

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

Прошлым летом в свет вышла новая архитектура нейронных сетей под названием Kolmogorov-Arnold Networks (KAN). На момент выхода статьи про KAN эта новость произвела фурор в мире машинного обучение, так как KAN показывала существенный прирост в качестве аппроксимации различных сложных функций. Ошибка новых сетей падает значительно быстрее при увеличении числа параметров. Однако, за все приходится платить, и цена таких маленьких значений функции ошибки - медленное обучение: KAN обучается примерно в 10 раз медленнее, чем старый добрый MLP. Из всего этого возникает вопрос: насколько все же уместно использование новой архитектуры вместо привычных всем MLP?

В данной статье будет найдена функция, которая может быть реализована с помощью двухслойного KAN полиномиальной ширины, но не может быть приближена никакой двухслойной ReLU MLP сетью с полиномиальной шириной

Многие используют Cursor, не зная, на что он на самом деле способен. Будем идти от простого к сложному.

1. Самое простое, что позволит улучшить работы с Cursor — это использовать Cursor Rules

Что это даёт?

- Cursor лучше кодит, делает это по вашим правилам.
- Можно настраивать разные правила для разных файлов/директорий.
По сути это дополнение к системному промпту, где вы делаете тонкую настройку один раз.

Документация здесь.
А тут отличные заготовки для правил

2. Включайте сразу несколько ИИ-агентов

В Cursor можно открыть 3 вкладки, где параллельно будут работать 3 ИИ-агента (это максимум). Единственное что - контролируйте, чтобы они они не использовали дни и те же файлы — могут перезаписать или удалить результаты работы другого агента, так что им нужно давать изолированные задачи.

Дополнительно можно ещё использовать фонового агента, который работает на серверах Cursor, и будет выполнять задание на основании вашего кода в репозитории. А потом все его результаты можно отправить в репозиторий или локально, однако он работает за дополнительную плату (Price-based)

Можно даже открыть второй Cursor, и запустить работу ещё там (особенно если работа ведётся с кардинально разными репозиториями), но это не очень удобно с точки зрения переключения между ними.

3. Кладите связанные репозитории в 1 папку и открывайте её в Cursor

Допустим, у вас есть бэкенд, фронтенд и ещё микросервис для управления подписками. Если вы поместите их в 1 папку и откроете её в Cursor, то он сможет ходить между ними и делать согласованный код. Допустим, он может сразу сделать контроллеры на бэкенде и api для них на фронтенде.

Доброго времени суток, «Хабр»!

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

Релиз DeepSeek R2 официально отложен и пока R1 не потерял актуальность, попробуем запустить модель на домашнем ПК. Оригинальная DeepSeek R1 имеет размер 700гб, так как она обучалась в fp8, но если бы она обучалась в стандартных f16, её вес был бы 1400гб, а мы попробуем версию в 10 раз меньше. Запустим самый маленький 1.66-битный IQ1_S_R4 квант полноценной модели размером 130гб на игровом ПК, отдельно с 4090 и 4060ti. Загрузим туда очень-очень много контекста и проверим, такой квант всё ещё способен давать разумные ответы или нет.

Привет!
Задумывались, какую версию квантованной LLM выбрать: Q4_K_M, Q6_K или Q8_0? Насколько Q6_K хуже справляется с задачами по сравнению с Q8_0? И что вообще означают все эти буквы в суффиксах?

Примечание: это адаптированный перевод моей статьи на Medium. Перевод был сделан при помощи мозга, а не нейросетей или Google Translate.

Состязательные атаки используют уязвимости глубоких нейронных сетей (DNN), внося минимальные изменения во входные данные, чтобы заставить модель ошибаться. Они часто незаметны для человека, но могут полностью изменить результат работы модели. В этой статье рассмотрим три популярных метода состязательных атак.

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

В этом разделе мы рассмотрим некоторые из наиболее эффективных методов.

Заметил, что трачу часы на поиск, баги и рутину — собрал ИИ-агента, который делает это за меня. Протестировал 3 подхода — от no-code до кастомного LangChain. В статье — инструкция и инсайты.