Нейро сети для самых маленьких

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

Это первая статья из небольшого цикла, посвящённого сетям для AI/ML-кластеров и HPC.

В этой серии мы коснёмся принципов работы и обучения моделей, параллелизации, технологий DMA и RDMA, сетевых топологий, InfiniBand и RoCE, а ещё пофилософствуем на тему общих и специальных решений.

Конкретно в этой статье мы разберёмся, что представляет из себя нейросеть, как она работает, как происходит её обучение, а самое главное, почему для неё нужны сотни дорогущих GPU-карточек и какая-то особенная сеть.

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

Каждый электронщик, работающий (или отдыхающий) с цифровыми микросхемами рано или поздно обязательно сталкивается с протоколом JTAG. Значительное количество материалов о данном протоколе содержит три раздела:
1) Обширный экскурс в историю и рассказ о том, как стенд с летающими щупами и рентгеновская установка легко могут быть заменены отладчиком на 2-3 порядка дешевле их.
2) Достаточно сжатое описание протокола JTAG (с картинкой его конечного автомата).
3) Рассказ о том, что фирменный отладчик, а также программное обеспечение компании <COMPANY NAME> позволят почти без усилий протестировать почти любое устройство почти любой сложности и конфигурации.

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

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

Такие платы называют HDI (англ. High Density Interconnect) — это печатные платы с высокой плотностью межсоединений.

Цель нашей статьи — показать, что соблюдая простые рекомендации и имея представление о "популярных" ошибках, можно заметно сэкономить время, а также получить надежные и соответствующие функциональным характеристикам HDI-платы, поставленные в срок, с минимальным риском дефектов и по оптимальной стоимости.

Эмбеддинги (иначе говоря, векторные представления) — это способ представления абстрактных данных в виде набора чисел (в виде векторов, как вы могли уже понять), близкие значения которых связаны семантически и математически и с которыми может работать модель искусственного интеллекта.

Разберемся какие модели лучше других подходят для кодирования слов. Параллельно с этим разберём принципы, на которые нужно опираться при выборе эмбеддинг-модели, пощупаем русские BERT-модели и внесём ясность про системные требования, контекстное окно и размер батча.

Многие производители программно-аппаратных комплексов (ПАК) не знают, что могут претендовать на налоговые льготы: НДС 0%, страховые взносы 15% вместо 30%, налог на прибыль 5% вместо 25%. Но для этого ПО должно соответствовать требованиям Минцифры. Рассказываю, каким...

Целью этой статьи не является полный пересказ спецификации USB или книгу по USB. Я хочу приоткрыть магию работы USB и представить информацию таким образом, чтобы вы получили быстрый старт для понимания всего стека USB: от интерфейсов и конечных точек до электрических сигналов.

В C++ часть ошибок выглядит слишком безобидно, чтобы сразу насторожиться: std::move в return, emplace_back «для скорости», перемещение из const, move‑конструктор без noexcept. Код компилируется, тесты могут проходить, а потом внезапно появляются лишние копирования, просадки производительности и странное поведение объектов.

Разберём пять типичных ловушек move‑семантики на небольших задачах и посмотрим, где именно ожидания разработчика расходятся с тем, что реально делает язык.

Двоичный интерфейс приложений, чаще именуемый просто ABI — это концепция, которая кажется знакомой и незнакомой одновременно. В каком смысле знакомой? Об ABI часто говорят в контексте устранения неисправностей, упоминают в статьях. Иногда даже приходится решать проблемы с совместимостью, которые провоцирует этот интерфейс. А в каком смысле незнакомый? Дело в том, что, если кто-то попросит вас описать, что такое ABI — то вы обнаружите, что понимаете, о чём речь, но чётко сформулировать ответ на этот вопрос сложновато. В конце концов, можно ограничиться формулировкой, указанной в Википедии: «набор соглашений для доступа приложения к операционной системе и другим низкоуровневым сервисам, спроектированный для переносимости исполняемого кода между машинами, имеющими совместимые ABI». Возникает ли проблема с такой формулировкой? Нет, в качестве общего описания этого вполне достаточно. Но оно может казаться немного поверхностным.

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

Привет, Хабр! Меня зовут Кирилл, я разработчик СХД в YADRO и ML-энтузиаст, автор книги "Hands-on Machine Learning with C++". Я заметил, что роль С/С++ в экосистеме машинного обучения трансформируется прямо сейчас. Чтобы понять, какое значение язык играет в развитии ML, мы поговорим о классическом применении C++ для ручной оптимизации вычислительных ядер. Затем разберемся, почему новый стандарт не закрепляет реализаций линейной алгебры, а отдает это на откуп поставщикам стандартной библиотеки и вендорам оборудования. И в завершение подумаем, как работать с «зоопарком реализаций», который из-за этого остается. 

Полгода назад я построил себе в Obsidian продуманную структуру хранилища. PARA-подобная иерархия, аккуратные папки под проекты и области, шаблоны, теги. Я честно верил, что вот теперь заживём.

Прошло несколько месяцев, и структура уснула. Не развалилась, не сломалась, именно уснула. Заметки продолжали появляться, но раскладывать их по местам мне стало банально лень. Каждая новая мысль требовала маленького ритуала: решить, куда её положить, как назвать, с чем связать, какие теги повесить. По отдельности каждое решение занимает секунды, но их десятки в день, и в какой-то момент мозг просто отказывается. Заметки стали оседать одной кучей, а красивая иерархия превратилась в музей.

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

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

Только вот некоторые культурные и даже профессиональные мифы повышают порог вхождения в тренажерный зал. Взращивают ментальный барьер, к которому нужно морально готовиться, настраиваться и из-за этого постоянно откладывать начало тренировок. Один из таких барьеров — время. Многие думают, что тренировки обязательно должны быть продолжительными, чтобы быть эффективными. Второй барьер — утомление. Не редко можно услышать что-то из разряда “не устал = не потренировался”, “не болит = не растет”.

Сейчас я постараюсь показать и доказать, что это не так и можно действовать намного эффективнее, опираясь на науку об упражнениях, а не мифы. С помощью рационального подхода делать хороший результат ценой приемлемых усилий. Это не будет материал из разряда “фигура Апполона за 10 минут в день”, но кое-что более изящное, чем классический убийственный метод и подходящее вам — людям с полной занятостью, которым хочется ввести силовые в жизнь, чтобы поддерживать организм и получать от этого бонусы внешнего вида.

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

Все знают, как писать промпты правильно: роль, критерии готовности, защита от выдумок, разметка под конкретную модель. Проблема в другом - выписывать все эти пунктыруками для каждого нового промпта утомительно. Да ещё и думать надо :) Поэтому я собрал скилл, который делает рутину за меня: описываешь задачу своими словами, получаешь полноценный промпт под Claude, GPT, Gemini или DeepSeek. Под катом - как он устроен: десять обязательных блоков, Python-проверяльщик, протокол разнообразия из свежей научной работы. Скилл открытый, ссылка внутри.

Есть на ютубе видео на пятьдесят минут с хвостиком, с гордым названием «худший язык программирования всех времён». Не удивлюсь, если вы подумаете, что оно про C++. Оно действительно про плюсы и я его смотрел где-то с полгода назад, ну как смотрел... пробежался на x2 с перемотками, мало ли что обиженный джун там наговорил, но добрый @alyokhin опять про него напомнил, и теперь я его посмотрел полностью. И знаете что самое неприятное? Если убрать интонацию обиженного джуна и оставить только аргументы, то процентов семьдесят там будет правды. Не «спорно», не «зависит от контекста», а буквально правда, которую любой разработчик, проведший с языком пару лет, подтвердит вам не задумываясь.

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

Жанр «почему C++ ужасен» на Хабре выжжен дотла и про Init-зоопарк, перегруженный static, vector названный неправильно, std::move который не move, супер медленный regex, медленный unordered_map вы всё читали раз по двадцать. Сам по себе список этих болей давно не новость, от себя добавлю, что все жалобы и примеры ниже - это следствия одного решения, и я к нему приду. Или открывайте спойлеры, там скрыта история, почему каждая часть языка получалась так, как получалась.

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

Звучит как безнадежная задача. Все, что Алиса крикнет Коле, услышит и Ева. Любая информация, которая дойдет до Коли, дойдет и до нее. Кажется, что общий секрет в таких условиях невозможен в принципе.

А теперь плохая новость для нашей интуиции: именно это сейчас происходит на вашем устройстве.

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

Большинство этих примеров родилось в эпоху до C++11, когда у языка ещё не было ни умных указателей в стандарте, ни move-семантики, ни constexpr, ни концептов, и приходилось руками собирать из шаблонов и перегрузок некоторые конструкции, которые в более поздних стандартах язык даёт почти бесплатно. Многие идиомы, примеры и идеи стоит читать в двух смыслах сразу, как исторический артефакт, объясняющий «почему старый код выглядит вот так», и как живой приём, который всё ещё применяется в движках и играх.

Разработка игр тут не случайно, потому что игровой движок это обычно место, где абстракции встречаются с профилировщиком, и проигрывают ему чаще, чем хотелось бы. А легаси паттерны цветут и пахнут из-за чьих-то забытых в углу костылей, но большинство вещей вполне правильны, применяются и спасают от ошибок. Многое из этого спрашивают если не дословно, то хотя в паре слов, хорошие лиды на собесе, перед тем как позвать вас в команду, и просто взяв рандомо 5-6 пунктов можно составить впечатление, сталкивался ли новый человек с определенными проблемами.

Когда я собирал оглавление Game++, раздел про идиомы, идеи, паттерны и механизмы C++ планировался шестым и завершающим, и должен был занять страниц сто, по одной на каждый пункт, но чем дальше я собирал материал, тем яснее становилось, что каждая секция тянет за собой историю, а каждая история требует контекста, а каждый контекст в игрострое никогда не бывает простым. В итоге текст разросся до размеров, при которых он просто сломал бы структуру книги, и мне пришлось выбирать между «урезать до неузнаваемости» и «отпустить жить отдельно». Пришлось выбрать второе.

Перед вами то, что могло бы стать половиной Game++, но стало самостоятельным материалом. Здесь собраны идиомы, идеи, паттерны и механизмы C++, которые сложились в сообществе за несколько десятилетий и продолжают жить в кодовых базах игровых движков, иногда под своими именами, иногда под другими, иногда вообще без имён, потому что их давно перестали объяснять. У большинства имена все же есть, есть и история с ответом почему именно так, а не иначе.

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

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

Статью я решил поделить на два уровня. Первая часть (без которой сложно понять вторую) — для тех, кто слышал слово «эмбеддинг», но не трогал его руками: разберем на пальцах и со стрелочками, что модель держит внутри своего цифрового серого вещества, в общем объясню простые вещи простыми словами. Вторая часть — для тех, кому интересно копнуть чуть дальше базы: туда я поместил grokking, фурье-частоты и суперпозицию, и там мы вытащим реальное пространство обученной модели и посмотрим, как оно устроено. 

Привет, Хабр!

В Axelix мы в последнее время начали получать contribution-ы извне. И как по приватным обсуждениям, так и по GitHub я могу сделать вывод, что у очень многих людей есть довольно серьёзное непонимание того, что означает та или иная лицензия, что вообще такое “Open Source” и даже что такое Copyright.

Мне кажется, что я пару вещей в этой теме немного понимаю, и я чувствую некоторую ответственность этим знанием поделиться. Поэтому я решил написать небольшую статью, которая объясняет базовые концепции в Software, начиная с Copyright и Licensing.

Позже я, возможно, ещё напишу про CLA, Open Core и про то, как AI Agents и AI в целом вписываются в эту картину. Так что, если вам интересно, дайте знать :)

Прежде чем мы начнём: я не юрист, и я не советую вам выбирать ту или иную лицензию, или подход. Я всего лишь Software Engineer, который писал много кода под разными лицензиями, в том числе проприетарными и Open Source.

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

Привет, Хабр!

К 2026-му году Cursor стал полноценной средой для кодинга без…. кодинга. Вместо этого вы оперируете ИИ-агентами и отдаете им приказы. Ручное программирование с каждым годом становится ближе к статусу «истории». Cursor является лучшим ПО для работы с агентами и вайбкодинга.

В этом гайде мы без воды рассмотрим такие аспекты программы как: интерфейс, работа с контекстом, режимы агента, модели, правила проекта, MCP, skills, hooks и др.

Актуально на лето 2026 года. На момент написания самая свежая версия — Cursor 3.6.

Поехали.

Наверное, всем уже очевидно, что ИИ крайне полезен, мир поменялся, нас всех заменят роботы и вообще ИИ уже нас во всём превзошёл.

Всё так или почти так, "но есть одно но" как поётся в одной известной песне. ИИ стоит денег, и весьма немалых при текущих ценах. А про локальные модели для большинства пользователей и компаний в РФ можно забыть. Ну и в целом кажется локальные модели - это не сценарий ИИ будущего.

Соответственно, как мы платим за интернет и за свет - регулярный платёж за ИИ — то, что нам светит в будущем, а большинству уже сейчас. На текущий момент времени расход токенов - пожалуй, самое главное что-тормозит повсеместное внедрение ИИ. Полностью без оплаты конечно не обойтись (нуу почти), но существенно сократить её точно можно. Далее все методы, которые я испробовал и использую за 3 года работы. По убыванию - от самых жестких и очевидных, до самых хитрых и "технологичных".

Мне регулярно пишут: «У тебя Max-подписка, токенов вагон — зачем городить индексацию кода? Дай агенту grep и не выпендривайся». Полгода назад я бы согласился. Сейчас — нет. Когда агент ищет «где тут авторизация», он спавнит эксплорацию, грепает по ключевым словам и читает 15-20 файлов целиком, чтобы догадаться о связях. Это сотни тысяч токенов, куча tool calls и регулярные промахи. Граф кода схлопывает этот веер чтений в один точный запрос к индексу. Я сейчас гоняю CodeGraph (лёгкий локальный индекс символов для агента), а Graphify (граф знаний всего проекта — код плюс документы, PDF и медиа) только собираюсь попробовать. Это два разных инструмента под разные боли, и их постоянно путают. В статье: чем они отличаются архитектурно, почему модель хранения индекса — следствие этой архитектуры (и как держать индекс при работе с разных машин и командой), их бенчмарки с честной пометкой «не мои цифры», кому что брать — плюс карта соседних инструментов: Gortex, CodeGraphContext, Sourcegraph MCP и Cognee.