Машинное обучение *

Уже прошло два года с тех пор, как мы предложили схему 4.6-битного квантования и рассказали про нее, в том числе и на Хабре: раз и два. Вспомним, что при 4.6-битном квантовании веса и входы слоя принимают такие целые значения, что их попарные произведения помещаются в знаковый 8-битный тип данных. Такая схема позволила нам вычислять нейронные сети на процессорах мобильных устройств быстрее, чем в 8-битном формате, и точнее, чем в 4-битном, потому что уровней квантования больше.

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

Привет, Хабр! Меня зовут Антон Алексеев, я MLOps-инженер в Авито. 

В статье рассказываю, как мы строим ML-платформу на базе Kubeflow. От первых DevBox-решений мы пришли к набору небольших юнит-платформ, которые разные команды развивали под свои бизнес-задачи и связывали между собой. Со временем возникла задача объединить эти решения в единую платформу. Поделюсь, как мы это делали, с какими проблемами столкнулись и как их решили. И немного о том, как должны выглядеть агентские платформы, когда за управление инфраструктурой отвечают агенты. 

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

Вот смотрите: кинули в мясорубку не только мясо, но и другие ингредиенты. Что получилось? Уже не чистый фарш, а какая-то смесь всего со всем. А если для каждого ингредиента взять свой инструмент, то получим чистый продукт. В нейросетях то же самое: общие веса = общая мясорубка. Обучили на кошках, потом на машинах, всё смешалось. Кошки забыты.

Это catastrophic forgetting. 30 лет проблемы. Тысячи статей. Регуляризация, replay, elastic weight consolidation, всё какие-то костыли. Решение лежит на поверхности.

Привет, Хабр! Меня зовут Кирилл Кулаков, я занимаюсь развитием MLOps-платформы в Uzum Fintech.

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

И тут коллеги начали задавать вопросы «Почему мы не разворачиваем каждый компонент последовательно, настраивая все досконально?». Для меня это звучало как: «Ты сделал неправильно, сейчас будем разбирать твою работу и от половины откажемся». 

Мы строим MLOps-платформу под широкий спектр AI-задач и по ходу работы постоянно сталкиваемся с архитектурными вызовами и альтернативными решениями. 

В какой-то момент мы поняли: для одной и той же задачи мы можем собрать множество архитектурных вызовов, а потом тестировать такое же множество разных подходов. А время всё ещё не резиновое, как и силы команды. Так что мы сели и серьёзно обсудили наши методы развёртывания ИТ-платформ.

И потом я задумался, а на самом ли деле в разных компаниях и командах бывают настолько разные подходы к этому делу?

В статье предлагаю поисследовать эту тему вместе со мной.

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

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

В 2026 году у этой проблемы появилось решение, до которого дотягивается обычный предприниматель без программиста. Автоматизация рутины нейросетями перестала быть историей про «дорогое внедрение за миллионы». Нейросети научились работать сами: по расписанию, по событию, без вашей команды каждый раз.

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

Статья посвящена практической реализации агента с изолированной средой исполнения кода. Рассказываю как устроен агент, который пишет и исполняет код в Docker песочнице.

Это вторая часть серии про LLM Sandbox. В первой части мы разобрали риски исполнения кода от LLM, ограничения песочницы, способы изоляции (Docker, Wasm, gVisor, microVM) и минимальную архитектуру агент+песочница.

Код реализации агента, skills, полные логи и артефакты примера — в открытом GitHub-репозитории.

Можно ли доверять ответу нейросети?

Получить ответ от нейросети — только половина задачи. Не менее важно понять, насколько этому ответу можно доверять.

В новой статье делюсь своим взглядом на существующие методы верификации.

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

Недавно на рынке появились карты NVIDIA H100 в форм-факторе PCIe, построенные на основе извлеченных из HGX-модулей SXM-чипов. Но точно ли их производительность не уступает производительности оригинальных NVIDIA H100 NVL? 

Меня зовут Артём Маклаев, вместе с командой я занимаюсь оценкой производительности серверных платформ для задач искусственного интеллекта в YADRO. В целях эксперимента мы решили сравнить показатели PCIe-карты NVIDIA H100 (дальше по тексту буду называть их NVIDIA H100 Special) и NVIDIA H100 NVL. Для этого провели испытания с использованием сервера YADRO G4208P G3. Методику построили так, чтобы результат можно было проверить и воспроизвести: для сравнения использовали одинаковую серверную платформу, одинаковые версии драйвера, CUDA и ОС, а также два уровня тестов — прикладной vLLM benchmark и NCCL all_reduce_perf для проверки GPU-интерконнекта. 

В статье покажу результаты бенчмарков на типовых LLM-конфигурациях и дам рекомендации, как валидировать ускорители перед включением в проектный или продуктовый контур. Будет полезно, если приобретаете карты для работы над задачами ИИ.

Через несколько лет представить мир без AI будет так же сложно, как представить мир без интернета сегодня. Однако в обращении с AI мы всё чаще ведём себя как аборигены при общении с цивилизацией. Эта статья — попытка ответить на вопрос: «что такое AI сегодня?», и порефлексировать на тему подводных камней AI в разработке в частности, и в нашей жизни в целом.

Представьте: вы даёте задачу, а интеллект внутри IDE сам всё делает. Без интернета, без копилки токенов. Видит весь проект а не конкретный файл. Это уже реальность.

В чем отличие агента от чата - ассистента?
Всё просто они работают по схеме запрос-ответ. Спросил, получил текст и дальше сам разбирайся. А агент - это совершенно другая история. Агент сам планирует, что делать, сам использует инструменты (редактировать файлы, выполнять команды в терминале, искать по проекту), помнит весь контекст сессии и, что важно, умеет реагировать на ошибки и корректировать свои действия на ходу. Cline в IntelliJ именно такой. Он реально работает в вашей среде, почти как живой коллега.

Многие из нас делают что-то интересное: создают агентов, RAG-системы, делают крутые решения на основе LLM или в области генерирования изображений и видео, собирают датасеты, придумывают бенчмарки — этот список можно продолжать и продолжать. Создав что-то замечательное, напишут статью на Хабре, и на этом всё. Хотя ту же самую работу вполне можно отправить на ведущие мировые конференции по Data Science и ИИ, таких как NeurIPS, ICLR или ACL. Разница не всегда в качестве исследования, просто мало кто знает, как правильно обернуть свои ИИ-решения и разработки в научные статьи, которые пройдут на топовые конференции.

Я Мария Тихонова, исследователь из Sber AI. Занимаюсь бенчмарками и генеративными моделями, развиваю исследовательское направление внутри наших команд. Расскажу о том, как превратить крутые результаты, которые у вас есть, в научную статью высшего ранга (A/A*).

Представьте парк из более чем 700 экземпляров СУБД. Классический сценарий: приходит оповещение о высокой нагрузке, администратор начинает вручную собирать метрики с десятков дашбордов в Prometheus/Grafana, анализировать журналы, ища ошибки и медленные запросы, пытаться сложить разрозненные данные в единую картину, сформулировать проблему и создать задачу на исправление.

На это уходит много ресурсов, а ценное время на реакцию уходит.

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

С вами Станислав Епишин и Константин Резник из команды «R4C.Support.Всадники апокалипсиса» в СберТехе. В этой статье покажем, как мы соединили Prometheus, Pipeliner (CI/CD-оркестратор, разработан в СберТехе, аналог Jenkins), TaskTracker (система управления задачами, разработана в СберТехе, аналог Jira) и GigaChat (продукт Сбера) через AI Hub API (анализ) в единый механизм.

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

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

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

Внутри TTS работает каскад из трёх компонентов: языковая модель предсказывает аудиотокены по тексту, диффузионный декодер восстанавливает мел‑спектрограмму из латентов, а вокодер превращает её в звуковую волну. Долгое время самой тяжёлой была языковая модель, но после её оптимизации на первый план вышел декодер латентов — его forward pass запускается на каждом шаге семплинга диффузии, а шагов — десятки. Именно его мы и взялись ускорять.

В течение двух десятков лет в компании Meta* существовал уникальный высокопроизводительный отдел разработки; всё закончилось в апреле этого года. На протяжении первых двух десятков лет работы компании в ней исповедовалась культура «двигайся быстро и ломай ненужное», в начале 2020-х сменившаяся на «двигайся быстро со стабильной инфраструктурой». Знакомые мне разработчики из этой компании говорили мне, что им представляли всё необходимое для качественной работы с упором на приносимую пользу, а интересы бизнеса находили баланс с надёжной разработкой.

Но за последние несколько недель всё поменялось: руководство начало исполнять подробные планы по разрушению проверенной успешной культуры разработки максимально жестоким и эффективным образом.

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

Всем привет! Листал ленту тиктока и попался американский ролик про СДВГ, где всё объясняют на утках. Понравилось. И я подумал: классно было бы сделать такой же тикток, только на русском.

Но я ленивый. Снимать, писать сценарии, делать всё с нуля - это скучно. А вот взять готовый ролик и перевести-переозвучить его на русский - вот это уже интересно, подумал я, а потом задумался, о том, как это автоматизировать. Это оказалось интересной инженерной задачей, которая увлекла меня на неделю времени, и привела к созданию ИИ утилиты с открытым исходным кодом. А тикток с утками я так и не создал...

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

Я сделал одну линейку с точными насечками: машинно-проверяемый каталог из 83 числовых форматов в 13 кластерах. Для каждого — разрядка битов, смещение, кодирование inf/NaN/субнормалей и общий якорь проверки 0x47C0. Из одного источника истины генерируются Markdown, JSON, Python, Rust, C и RTL для кремния.

У каждого формата стоит метка зрелости: 51 Verified, 12 Historical, 11 Experimental, 9 Open. И отдельная ось — граница RTL: где правило e = round((N−1)/φ²) ещё работающее железо (GF16 доведён до кремния), а где уже гипотеза (GF512/GF1024 — экстраполяция без строки Verilog). Внутри — лестница зрелости форматов, связь с IEEE P3109 и реальный баг в умножителе, который нашли только потому, что под форматом есть железо.

Я взял одного и того же агента (Claude Code), менял у него ровно одну вещь — какой MCP-сервер отдаёт контекст по коду, — и гонял по 26 задачам на apache/superset. Четыре «руки»: filesystem (grep + read), graphlens (структурный граф), serena (LSP) и codegraph. Три модели (haiku / sonnet / opus), три сида — 936 прогонов.

Главный результат: вывод переворачивается в зависимости от типа задачи.

На NLP/LLM-собеседованиях часто проверяют не то, знаешь ли ты слова top-k, top-p и BLEU, а понимаешь ли ты, что происходит с распределением вероятностей, почему greedy decoding зацикливается, зачем нужна temperature и почему BLEU плохо оценивает ответы современных LLM.

В этой статье - чеклист по языковому моделированию, стратегиям генерации и метрикам качества. Это не полноценная лекция с нуля, а тренажёр, по которому стоит пройтись перед техническим интервью по NLP, чтобы закрыть пробелы и вспомнить необходимую базу.

Нам всё чаще заказывают ИИ-ботов для продаж и квалификации. И каждый раз один и тот же вопрос: на каком движке его строить? Бенчмарков «кто умнее» — десятки. На умение продавать, да ещё по-русски, — ноль. Поэтому я собрал свой: одна нейросеть играет продавца, вторая — клиента, который принципиально не покупает с первого раза и ловит на вранье, третья судит по продажной рубрике. Враньё ради сделки штрафуется жёстче, чем провал сделки. Прогнал первую десятку — и тест выдал сенсацию: DeepSeek и GLM «обошли» эталонный Gemini, а одна модель получила 96 из 100 и S-tier. Красиво. Только я в это не поверил. Под более жёстким клиентом модель не может набрать БОЛЬШЕ баллов, чем раньше. А S-tier-чемпиона я открыл руками — и увидел, как бот восемь раз подряд скопировал собственный ответ. Внутри: устройство теста, рубрика с весами, реальные реплики персон, таблица 10 моделей, фрагменты диалогов (враньё, честность, зависший бот) и разбор, почему автосудье нужен живой надзор.