Если вдруг вы моргнули на моменте, когда разработчики нейросетей мерились, у кого больше цифра рядом с названием модели, а выморгнув, обнаружили, что теперь модно флексить скромными размерами активных параметров, эта статья для вас. Сегодня объясняю, как же так произошло, что все флагманы опенсорса внезапно стали MoE, почему Qwen3.5 на 397 миллиардов параметров строчит токены, как будто ей 17 и почему никто не разорился на видеокартах.

Ну и для тех, кому «только спросить» откроем тайну: в каком же кабинете живет эксперт по медицине.

Привет, сегодня решила поделиться переводом от Маттео Бизи на вечнозеленую (как оказалось) тему — Shadow AI.

В материале про то, почему ИИ-агентов нужно моделировать как угрозу, а не просто как инструмент продуктивности.

Вполне реально, по крайней мере, у нас получилось перевести команду из 300 человек к системной работе с ИИ. 

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

Нет повести печальнее на свете, чем повесть о потерянном пакете. А чтобы пакеты не терялись, нужно проводить нагрузочное тестирование и быть уверенным в своем продукте. Особенно когда речь идет о проксирующем балансировщике и UDP-трафике. Ведь UDP выглядит не как упорядоченный контролируемый процесс, а скорей как толпа школьников, бегущих после звонка в столовую, — часть может не добежать и потеряться по пути. Будет очень печально, если из-за кривого пола балансировщика наши дорогие школьники пакеты попадут в статистику потерь.

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

Разбудите меня ночью и спросите «что нельзя делать с ИИ», и я отвечу «грузить конфиденциальные данные». Это правило должно быть записано у нас на подкорке как таблица умножения. Должно, но не факт, что оно срабатывает во всех 100% случаев, тем более если играться с ИИ не в рабочих, а личных целях. Ну что такого может случиться, если я просто попрошу модель перевести кусок текста с эльфийского синдарина на обычный человеческий?

Если вы такой же тревожный параноик, как я, то внутри для вас несколько простых настроек для чатов с ИИ, чтобы спать спокойно. Да, это не абсолютная гарантия, что ничего никуда не утечет и модель ничему от вас не научится, но, как говорится, береженого Бог бережет.

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

Меня зовут Амиран Гургенадзе, я работаю в технической поддержке Cloud.ru. До этого я был системным администратором, а в облака пришел с готовностью учиться заново.

За последний год я прошел 10 бесплатных курсов от российских облачных провайдеров. Не ради баллов, а потому что без них я бы дольше разбирался с реальными тикетами. Например, курсы по Kubernetes дали мне главное — набор рабочих привычек: спокойно разбирать инциденты с подами, не бояться лезть в admission webhooks, быстро ориентироваться в квотах и API-ошибках. Это то, что превращает «у нас сломалось» в понятный чек-лист диагностики.

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

А вы когда-нибудь задумывались, почему ваша любимая LLM-ка на 70 лярдов параметров, обученная на всем интернете, может с уверенностью университетского профессора выдать, например, что Наполеон изобрел электричество? Откуда это берется?

Долгое время индустрия списывала галлюцинации на плохие данные, кривой RLHF или декодинг. Но группа ученых из Университета Цинхуа залезла внутрь нейросети и нашла конкретных виновников — 0.1% нейронов, которые буквально заставляют модель врать. И это не метафора, это реальные веса в FFN-слоях трансформера.

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

Я попросила Алису AI и ГигаЧат настроить lifecycle-политику объектного хранилища в одном конкретном облаке. Ответы выглядели убедительно, пока я не сверила их с документацией и не нашла расхождения. Почему так получилось? А главное, что с этим делать SEO-специалисту и техническому писателю?

65% участников опроса Хабра и Cloud.ru считают, что будущее, где «роботы вкалывают, а люди счастливы», — утопия. Почти половина респондентов с помощью искусственного интеллекта автоматизирует рутинные задачи и повторяющиеся действия, но лишь каждый 9-й считает, что наибольшая польза от ИИ именно в этом. Большинство же считает, что наибольший эффект ИИ дает процессам разработки и тестирования. А каждый 7-й вовсе не пользуется такими инструментами. 

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

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

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

Раскопал на Medium интересное эссе про Elixir от разработчика Krzyś. Написано так захватывающе и самобытно, что я не смог пройти мимо. Хотел чуть-чуть подсократить, но каждый раздел важен, а терять стиль автора не хочется. Вот тут первая часть, а это — вторая.

Как вы себе представляете работу OCR? Страничка сканируется, программа находит области с буквами, распознает их и выдает текст. Старый добрый Tesseract так и пашет. А вот новый baidu/Unlimited-OCR делает финт ушами: он вообще не ищет буквы. Он берет всю страницу как картинку, жмет ее в горстку визуальных токенов и скармливает языковой модели, которая разворачивает их обратно в структурированный текст. Звучит как извращение, но… работает.

Это прямой наследник идеи DeepSeek-OCR. Сегодня коротко разложу: что это, как устроено, что умеет и как запустить у себя. Будет полезно всем, кто хочет распознавать многостраничные документы за одну проходку или вписать такую функцию в свой проект.

Эта статья о том, как я написал 200-строчную обертку над SQLModel, которая закрывает все реальные задачи с базой. В подарок идет непрошенное мнение об излишней сложности ORM.

Это будет будет попытка переосмыслить существующие подходы к ORM и предложить инструмент с более простой документацией, низким порогом входа в работу с СУБД, но при этом сохраняющий возможность делать сложные вещи.

Раскопал на Medium интересное эссе от разработчика Krzyś про Elixir. Написано так захватывающе и самобытно, что не смог пройти мимо. Хотел чуть-чуть подсократить, но каждый раздел важен, а терять стиль автора не хочется. Поэтому разбиваю его на две части — сегодня делюсь первой.

В начале недели взял задачу, которая выглядела на удивление просто. Сначала я попробовал решить ее одним способом, вторым, пятым, десятым — и очнулся ближе к ночи. Вот тебе и девопс…

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

Ну что, думаете что для запуска LLaMA 3 70B вам нужна серверная стойка за лярд рублей? Поздравляю, вас обманули маркетологи GPU-вендоров. Модели с сотнями миллиардов параметров — LLaMA 3 70B, DeepSeek-V3 с его 671 лярдом параметров — жрут vRAM как не в себя, но есть способ запихнуть это все в обычную потребительскую видюху.

Сегодня в статье разберем, как работает чудо квантизации под капотом, чем отличаются PTQ и QAT, почему MoE-модели (DeepSeek-V3, Mixtral, LLaMA 4 Scout) квантизовать сложнее и как выбрать между GPTQ, GGUF и AWQ.

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

В прошлый раз я рассказывал, как работает Guardrails Filter: зачем вообще понадобился отдельный слой защиты данных при работе с LLM и какие задачи он решает.

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

Как это сделать? Сейчас расскажу.

Наткнулся на интересный материал про тестирование GitOps на масштабируемость и нагрузку. Его целых три недели проводила компания iits-Consulting. Оригинал читать не меньше 40 минут, поэтому сократил его, сохранив все самое важное — и теперь делюсь со всеми обитателями Хабра.

Полночь, деплой горит, а ты вручную поднимаешь десятый сервер за неделю: копируешь ISO, тыкаешь Enter в консоли анакон­ды, правишь fstab, чинишь grub — и на утро выясняешь, что забыл gpg-ключ репозитория на трех машинах из десяти. Признавайтесь, бывало? Эта статья для тех, кто устал платить временем и нервными клетками за ручную сборку образов.

В этой статье расскажу, как построил полностью автоматизированный пайплайн для сборки образов закрытого дистрибутива Linux на базе RedHat — без единого ручного клика после старта. Ansible управляет хостом-билдером, Packer с shell-провижионерами собирает сам образ, и в итоге мы получаем готовый RAW, оптимизированный для OpenStack. Подход не привязан к конкретной ОС: если у вас другой дистрибутив, достаточно заменить ks.cfg на preseed.cfg или любой другой автоустановщик — остальная логика пайплайна должна работать без изменений. На десерт расскажу, как оформил часть решения в модуль для Ansible и отправил его в официальную коллекцию community.general.

Думаю, многие сталкивались с ситуацией, когда облачный провайдер честно обещает 99.95% или даже 99.99% SLA, но в реальности бизнес-система падает на часы. Формально облако работает, виртуалки доступны, диск жив, сеть отвечает. Фактически пользователь открывает приложение и получает ошибку.

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

Я намеренно не погружаюсь сильно в техническую реализацию того или иного описанного метода по улучшению отказоустойчивости. Сейчас эту задачу прекрасно решает почти любая LLM. Цель статьи – поделиться своим майндсетом: на какие вещи я обращаю внимание, когда передо мной стоит задача улучшить стабильность highload-сервиса.