Бэкенд

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

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

Команда VK Cloud перевела статью, в которой разбирается, как развернуть дезагрегированный инференс в Kubernetes. Здесь мы посмотрим на разные решения экосистемы, как они работают в кластере и что дают «из коробки».

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

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

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

В течение последних двух лет мы проделали большую работу по изданию неустаревающих книг, связанных с проектированием и развитием API. Как известно, сам вопрос «Что такое API?» довольно многогранен, и в своё время на Хабре развёрнутый ответ на него дала одна из наших топовых авторов Ольга Назина @Molechka — к настоящему моменту её статья собрала почти 1 350 000 просмотров и 1555 закладок. Книги Ольги Назиной не относятся к этой статье напрямую, но, если вы их ещё не читали, рекомендуем посмотреть все четыре. Будем исходить из того, что API — это предоставляемый программой интерфейс‑контракт, в котором заложены правила взаимодействия с ней, в частности, форматы принимаемых и выдаваемых данных. Нашим главным бестселлером в этой области является книга «Проектирование архитектуры API: Как правильно проектировать, развивать и эксплуатировать API» (вышла на русском языке в июне 2024 года), написанная великим Джеймсом Гофом в соавторстве с Дэниэлом Брайантом и Мэтью Оберном, а также ещё три крутые книги:

— «API как искусство: разработка, поддержка, интеграция» Сергея Константинова (вышла в мае 2024 года)
— «Архитектура бэкенда. API для надежных корпоративных приложений» Владислава Светлакова (вышла в августе 2025 года)
— «Web API. Сборник рецептов: Повысьте уровень JavaScript‑приложений» Джо Аттарди (вышла в сентябре 2025 года).

На этой в продаже появилась следующая книга, наполняющая эту нишу: «Прикладные API для искусственного интеллекта и Data Science» Райана Дэя — оригинал вышел в издательстве «O'Reilly“ в апреле 2025 года. Эта весьма оригинальная книга исследует работу с библиотеками Python и в качестве сквозного проекта рассматривает фэнтези‑футбол. Для нас это первый опыт издания книги с серьёзным включением FastAPI, но в перспективе мы не теряем надежд издать и исходно русскоязычную книгу об этом фреймворке.

TL;DR: ИИ не заменяет инженерный контроль, но меняет базовую планку разработки. С ним проще удерживать скоуп, тесты, техническое качество и в режиме дедлайна. Главный риск — потерять ownership, поэтому уровень автономности должен зависеть от проекта, стадии и зрелости инженерного процесса.

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

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

Знакомая работает в IT-департаменте организации с 16 филиалами и ~5000 единиц оргтехники на балансе. Попросила: “Сделай сервис, чтобы загрузить фотку шильдика, и он сказал, у кого эта железка стоит”. Звучит просто. На практике это вылилось в production-сервис с распознаванием по фото через Claude vision, ETL из бухгалтерских .xls (привет, xlrd 1.2), нормализацией грязных инвентарных номеров и автопушем в Google Sheets. Рассказываю про все грабли — от deadlock pandas vs xlrd до бага, который считал две разные железки одной

Меня зовут Игорь Симаков, работаю engineering manager’ом и руковожу командами разработки

На одном из наших сервисов, который работает с XLSX-файлами, прилетел production-алерт на высокое потребление памяти. Стандартный P3, обычно решается рестартом. Пошёл смотреть поды и нашёл проблему, к памяти отношения не имеющую, но представляющую больший риск, чем сам алерт. Об этом и расскажу ниже: чем «утечка диска» отличается от «утечки памяти», как мы наткнулись на грабли в Apache POI и как закрыли их на уровне архитектуры

С момента публикации статьи на Хабре «Импортозамещаем numpy, pandas, scipy и sklearn» прошло почти три года. В течение этого времени я приостановил работу над проектом из-за нехватки времени, ресурсов и сил. К тому же, меня расстроило, что не смог выполнить просьбу пользователя @N-Cube, который активно интересовался моей библиотекой и хотел ускорить работу своего Jupyter Notebook.

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

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

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

Я представлю несколько тестовых примеров в двух вариантах: с использованием AVX-2 на процессоре Intel® Core™ i7-4790K и AVX-512 на Intel® Xeon. Также покажу результаты замеров для каждого из них. Все тесты проводились без использования GPU, исключительно на процессоре. Это позволяет сравнивать производительность Python и моей библиотеки на равных условиях. Операционная система – Ubuntu 24.04, компилятор – GNU 13.3.0.

Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно три ответа провайдера 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку.

Мы делали B2B-платформу для деловых поездок: бронь авиа, отели, трансфер, страховка, в финале – оплата корпоративной картой через платежный шлюз. С этой ночи началась история, которая закончилась переписыванием всего платёжного слоя нашего booking-сервиса. По дороге мы поймали 5 граблей.

15-й выпуск IT-новостей от OpenIDE!

Вредоносная версия плагина провисела в VS Code Marketplace 18 минут и этого хватило, чтобы слить конфиги Claude Code, ключи AWS и 3800 репозиториев GitHub. 

Параллельно двое братьев удалили 96 правительственных баз данных за ~1 час после увольнения по Teams, а Bolt вообще уволил весь HR-отдел.

Есть такие анти‑паттерны, которые выглядят нормально и даже проходят код‑ревью, но тихо убивают производительность в горячих местах: 

- Конкатенация строк в циклах

- String.format() в горячем коде

- Автобоксинг 

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

Если вы пишете на Java и у вас всё вроде работает, но под нагрузкой сервисы начинают задыхаться, в новом переводе от команды Spring АйО рассмотрим конкретные паттерны, на которые стоит посмотреть.

Быстрые интеграции в 1С: прощайте, бесконечные переделки!

Как же бесит, когда приходится переписывать интеграции снова и снова… Опять растет тех. долг, пока исправляешь названия полей в JSON… 

Я Михеев Антон – ведущий специалист модуля разработки 1С и я прошел через это: переписывал интеграции по несколько раз в день, снова и снова «договаривался» с внешней системой. И вот, когда всё протестировано и пора стартовать, кто‑то вдруг меняет структуру пакета!!!

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

Наступил момент, когда заказчики стояли над душой и требовали, чтобы 1С отдавала данные ещё вчера. А у нас уже рука не поднималась переписывать интеграцию в очередной раз.

Оптимизация кода сервисов на Go под реальную нагрузку

Когда сервис на Go начинает «тормозить» под реальной нагрузкой, проблема почти всегда не в самом языке и даже не в алгоритмах. Чаще всего узкие места лежат на уровне работы с памятью, сериализации данных и неочевидных накладных расходов рантайма. Если сервис упирается в сеть, базу данных или внешние API — оптимизация кода даёт ограниченный эффект. Но в CPU-bound сценариях (парсинг JSON, агрегации, обработка данных) каждая лишняя аллокация и копирование начинают стоить дорого.

Ключевая особенность Go — автоматическое управление памятью через garbage collector. Это удобно, но под нагрузкой GC становится заметным фактором:

Привет, Хабр! Меня зовут Михаил, в Циане я занимаюсь развитием культуры и developer experience. Архитектура у нас микросервисная, за каждый микросервис отвечает конкретная команда. В любой команде обычно есть микросервисы, которые помогают ей достигать собственных целей, и микросервисы, которые достались по наследству — поскольку архитектура наша не всегда развивалась достаточно последовательно. Бывает, что сервис приходит с каким-нибудь разработчиком из другой команды. Бывает, что сервис когда-то отдали команде, потому что больше некому было отдать.

Наш бэкенд написан на Python и C#. Иногда в одной команде могут быть микросервисы и на Python, и на C#. Я считаю, что это нНе самый удобный расклад, я считаю: лучше все-таки иметь один стек в рамках одной команды. Если, например, в команде с питонистами и единственным шарпистом последний уходит в отпуск, то при поломке сервиса на C# остальной команде придется этого шарписта ждать. Либо срочно вызывать на подмогу другого шарписта.

Можно переписать все микросервисы на один язык. Довольно трудоемкая задача, если заниматься этим вручную. Разработчику нужно погрузиться в микросервис, максимально покрыть тестами бизнес-логику и аккуратно все переписать. Не забывая, что делать один в один нужно не всегда, поскольку архитектурные паттерны Python и C# различаются.

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

Привет! Я Ильдус Тукаев, разработчик в команде образовательной платформы Т-Банка. Мы помогаем школьникам, студентам, молодым специалистам и сотрудникам получать знания и качать свои софт и хард навыки. Основной язык у нас Go, но сегодня расскажу больше про архитектурную тему: как у нас в команде использовался паттерн Outbox и как он эволюционировал.

За полтора года реализация Outbox прошла четыре итерации. По пути мы ловили VACUUM, который останавливал сервис на три часа, теряли 5% событий за полтора дня и заваливали поддержку обращениями. Расскажу, какие реализации мы пробовали, на какие грабли наступали и почему остановились на варианте, который сами же не считаем идеальным.

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

В этой статье я расскажу об эволюции моего проекта — GroupModerBot, бота для модерации Telegram‑групп. Я покажу, как проект прошел путь от первой версии «всё в одном файле» до продуманной архитектуры с ООП, in‑memory кэшированием, безопасным выполнением команд и нестандартными алгоритмами наказаний пользователей.

В разработке ПО произведение двух целых чисел часто вычисляется до фиксированного количества битов с переполнением. Возьмём для примера 8-битные целые. Если умножить 127 на 127, то мы получим число 1 в виде 8-битного беззнакового целого с переполнением. Реальное полное произведение равно 16129. Для представления 16129 обычно используются 16 бит точности.

Таким образом у нас появляется понятие полного произведения. Полное произведение двух 32-битных чисел обычно представляется при помощи 64 бит. У меня возник вопрос, какую долю всех 64-битных чисел можно записать, как произведение двух 32-битных целых.

Двадцать лет назад кто-то написал первую статью на Хабре. Скорее всего, поздно вечером, скорее всего — потому что хотелось поделиться. Тогда никто не знал, что из этого вырастет.

За 20 лет здесь написали 352 855 статей и переводов, их суммарное время на прочтение перевалило за два миллиона минут, а само сообщество выросло до 71 849 авторов. У самой охватной статьи — 5,6 миллиона просмотров. У самой заплюсованной  — 1 467 плюсов, у самой комментируемой — 2 939 комментариев. А самую сохраняемую добавили в закладки 9 292 раза.

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

Хабр — это дом, который вы строили сами, и к юбилею сообщества мы оттолкнулись от этой мысли и сделали из неё игру «Дом Хабра». 

Ниже рассказываем, что внутри, а вы пока откройте её в соседней вкладке — и лучше всего с десктопа. 

Ещё несколько лет назад разговоры об iPad как полноценном инструменте разработчика воспринимались скептически. Машинка для Netflix, блокнот для набросков, планшет для презентаций — но только не рабочая среда для написания и деплоя кода. У этого скептицизма были основания: iPadOS долго не имела нормальной многозадачности, инструментов для работы с серверами почти не существовало, а необходимость постоянно переключаться между приложениями делала любой серьёзный рабочий процесс мучительным.

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

Наш прежний SLA формально выглядел корректно: была формула, «четыре девятки» и отчёты. Но в моменты сбоев это не помогало ответить бизнесу на вопросы: сколько времени мы были недоступны, какова потенциально недополученная прибыль и каким был вклад разных подразделений в «наши девятки». Команды по‑своему считали простои и потери, называли разные цифры, и формально все были правы, но временами договориться про общий знаменатель в расчётах становилось слишком сложно.

Меня зовут Дмитрий Химион, я руководитель ML Platform в X5 Digital. В статье расскажу, как мы «жили у границы потери доверия к SLA» и что с этим сделали: от запроса руководства и пересборки инцидент-менеджмента до доверенного алгоритма расчёта потерь и разделения SLA на бизнес- и технический уровни.

В понедельник утром бухгалтер из клиентской компании написала мне в Telegram: «У контрагента в SAP всё оплачено, а в Smartup долг 12 миллионов». Я открыл обе системы. Одна и та же накладная. Два разных состояния. Два источника правды и оба врут.

Это было ровно то место в книге Designing Data-Intensive Applications, на котором я когда-то уверенно кивнул и пошёл дальше. Глава 5. Replication. «Ну да, master-slave, понятно». А когда через год сам построил систему с двумя ведущими даже не назвав её так, — Клеппманн взял своё со штрафами и пенями.

Это история о том, как я понял пятую главу DDIA не из книги, а из логов.