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

Из-за чего весь сыр-бор? Вчера вышла статья, что потребитель пошел по магазинам, искать себе новый телефон для установки туда мессенджера Макс. На Хабре комментаторы в большинстве своем решили: это всё из-за недоверия народного! Допустим. А что, сразу телефон отдельный покупать надо?

Каждый раз, когда вы пишете .await, происходит не магия, а вполне конкретный механизм: Future, Waker и опрос состояния. Чтобы увидеть это своими глазами, я написал собственный async-рантайм на Rust с нуля - с executor, reactor на epoll и рабочим TCP-эхо-сервером. По пути разобрался, как именно tokio будит ваши задачи, и нашёл баг, который тихо висел у меня в проде. Внутри - весь код целиком и объяснение без отсылок к чёрным ящикам.

Когда мы выпустили Auto Embeddings — функцию автоматического преобразования текстов в векторные представления — без развёртывания отдельного сервиса для работы с ML-моделью, — главный запрос пользователей касался скорости работы. Ранее для генерации эмбеддингов использовался только стек SentenceTransformers поверх Candle (Rust-рантайм Hugging Face для ML-инференса), и ресурсы CPU использовались далеко не полностью: в большинстве сценариев нагрузки показатель QPS держался на уровне нескольких десятков документов в секунду независимо от способа подачи данных, а параллельные запросы обрабатывались последовательно в рамках одной сессии модели.

Поэтому мы в течение нескольких недель оптимизировали механизм запуска ONNX-моделей в Manticore. Новый бэкенд ONNX Runtime доступен начиная с Manticore Search 27.1.5 . ONNX (Open Neural Network Exchange) — переносимый формат моделей, в котором уже публикуется большинство популярных open-source моделей для эмбеддингов: MiniLM, BGE, E5 и другие. В результате получилось решение, которое в среднем в 14 раз быстрее прежней реализации SentenceTransformers/Candle на том же оборудовании (обычный недорогой сервер с 16 ядрами / 32 потоками), с той же моделью и теми же весами, если усреднить по всей матрице замеров threads × batch, — и это преимущество сохраняется как при одном клиентском потоке, так и при тридцати двух. Предыдущая реализация во всём диапазоне нагрузок показывала 5–11 документов/с; новая реализация работает в диапазоне 70–230 документов/с.

DGX Spark и его клоны поставляются с DGX OS (фактически, Ubuntu 24.04 с кучей дополнительных пакетов от Nvidia). Причем, драйвера используются довольно старые, версии 580, cuda toolkit тоже чуток устарел, 12-ой версии. Кроме того, стоит куча невразумительных пакетов с телеметрией (типа, для работы с Nvidia Sync), обвешано все какими-то левыми скриптами и странными настройками.

Не то, чтобы это создавало прямо уж совсем серьезные проблемы, но сам факт наличия какого-то непонятного bloatware меня, как бывшего системного администратора - довольно сильно расстраивал. На форуме Nvidia кто-то уже написал, что ставил чистую Ubuntu 26.04 без серьезных трудностей, так что я решил сделать так же. Попутно захотелось перейти на ZFS ради возможности точно устанавливать размер файлового кэша и компрессии.

Разумеется, сначала сделал полный бэкап на внешний nvme. Потом поставил Ubuntu 26.04 Desktop ARM, и оно даже успешно заработало, успешно установил необходимые пакеты и скомпилировал llama.cpp. Но появилась странная проблема с повышенным энергопотреблением - GX10 начал жрать из розетки во всех режимах на примерно 15 ватт больше. В idle - 41 ватт вместо 26, во время работы LLM - 195 вместо 180. Вроде бы немного, но для спарков и его клонов, с их системой охлаждения, работающей на пределе - это довольно критично.

Чатгпт раскопал пост, где кто-то сетовал на похожую проблему с портами ConnectX-7 (и, как потом оказалось, это действительно была та самая проблема), но его предложения по деактивации этих портов и выгрузке драйверов никак не помогли.

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

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

В этой статье разберу архитектуру целиком: из чего она собрана, почему именно так, и где проходят границы, за которые я агентам выходить не даю. В качестве подопытного — мой pet-проект, обычный Telegram-бот на Go (MongoDB, Kubernetes). Что именно он делает — выходит за рамки статьи; важно, что это работающий продакшен с реальными пользователями, а не песочница.

«Я собрал приложение за вечер. Разработчики больше не нужны».

Лента забита такими постами, но мало кто показывает продолжение этих историй. А оно бывает ярким: от продовской базы, снесённой AI-агентом, до взлома на второй день после запуска.

По красивой картинке больше не понять, кто её собрал — инженер или человек, который научился красиво писать промпты. Разбираемся, почему рынок ослеп, при чём тут верстальщики на Tilda и что с этим делать бизнесу и инженерам.

Я срьрал 100+ вопросов с собеседований по Rust с краткими разборами: владение, типажи, конкурентность, async, unsafe, производительность и др. Отдельный продвинутый блок A1–A21 для staff-уровня. Цель - показать, где обычно спотыкаются даже опытные, и помочь подготовиться к следующему собеседованию. Надеюсь будет реально полезно!

Большинство медиа-библиотек для Go рано или поздно упираются в одну и ту же проблему.

У них нет собственного декодера.

Вместо этого они полагаются на установленный в системе пакет FFmpeg, shared библиотеки, платформозависимые DLL или внешние исполняемые файлы, которые должны присутствовать на целевой системе.

На этапе разработки всё работает. Затем начинается развертывание.

И внезапно вы отлаживаете отсутствующие DLL в Windows, несовместимые версии FFmpeg в Linux, различия версий из Homebrew на macOS, образы контейнеров без нужных библиотек или продуктовые серверы, где рядовое обновление пакета неожиданно ломает обработку медиа.

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

Ту статью многие прочитали как «вот и хорошо, нанимаем нескольких сеньоров, увольняем середину, экономим на FTE». Это понятно с точки зрения CFO — но это полупонимание.

Дирижёр без мотивации — это не дирижёр. Это дорогой пассивный наблюдатель. AI рядом с ним даст ровно ноль ускорения.

Сегодня — про вторую половину. Кто реально получает 10× от AI и почему это вопрос лояльности, а не технологии.

При разработке ИИ-агента для базы знаний, мне казалось, что задача почти типовая: складываем информацию в Qdrant, находим информацию через векторный поиск и поиск в интернете и формируем красивый ответ через LLM. На деле ИИ-агент начал уверенно галлюцинировать, приносить не только нерелевантные ответы, но и тупить с короткими пользовательскими запросами. И самое неприятное, при всем при этом метрика «похожести» similarity выглядела достаточно высокой, что сильно вводило в заблуждение.

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

В статье расскажу, как я пришла от «просто добавь LLM» к промышленному графовому ИИ-агенту на LangGraph + Qdrant.

Ваш AI‑чат или автокомплит тормозит при 50 запросах в секунду? Монолит убивает GPU и латенси?

В этом туториале — реальная архитектура low‑latency инференса на high‑load: почему изолированный inference‑bundle вместо монолита, как выбрать между vLLM и SGLang без маркетинга, зачем нужны continuous batching и admission control.

Мы все привыкли строить производство софта как конвейер. Продакт берёт идею, отдаёт аналитику. Аналитик пишет требования, отдаёт разработчику. Разработчик пишет код, отдаёт QA. QA проверяет, отдаёт DevOps. DevOps выкатывает в прод.

Каждый знает свой участок. Каждый передаёт результат дальше. Лента сама довозит результат до пользователя.

Так работало 30 лет. И вот в каждый из этих участков пришёл AI-агент. И конвейер начал барахлить.

async fn в Rust — это не магия и не зелёный поток, а обычный enum, который компилятор генерирует за тебя. Разбираем, почему Future это машина состояний, зачем нужен Pin, как работает Waker и executor, и как одна .await-точка может незаметно заставить твой сервис есть память гигабайтами.

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

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

Мы представляли себе идеальную картинку: загружаем исходники, документацию, ТЗ в модель, нажимаем кнопку и на выходе получаем JSON с описанием архитектуры, связей, интеграций и методов. Вишенкой на торте должен был стать умный чат, в котором можно спросить что-то вроде «как у нас реализованы выплаты по убыткам?» и почти мгновенно получить ответ.

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

Но не тут-то было. Идея разбилась о суровую реальность enterprise-разработки. За несколько месяцев мы собрали коллекцию из 12 ошибок, которые едва не похоронили наш проект Code Scope (именно так мы назвали решение). Сегодня расскажу о пяти, на мой взгляд, самых показательных. Спойлер: в итоге наш код на 99% состоит из «инженерии», и только 1% – это тексты промптов.

Ошибка 1: Один запрос обо всём

Мы начали красиво. Взяли внутреннюю систему, написали «классный» промпт и попросили LLM вернуть все возможные факты о коде в виде структурированного JSON-объекта: описание методов, интеграции, точки входа, расчёт метрик и так далее. 

Описываю методологию разработки эффективных чат-бот промптов, направленных на оптимизацию рутинных процессов.

Показываю на практике философию пошагового решения задач с помощью нейросетей. Указываю на необходимость контролировать контекст работы ИИ.

Показываю весь цикл разработки промпта. Даю промпты для создания промптов.

У меня на столе стоит небольшая золотистая коробочка размером чуть больше Mac mini. Внутри — приватный AI-сервер: чат с локальной 26B-моделью, поисковая индексация моих документов с GPU-парсингом, конструктор агентов в Dify, RAGFlow для тяжёлого парсинга PDF, мониторинг, бэкапы, опциональный кластер из двух машин по QSFP 200G. Тридцать контейнеров, пять минут на установку через sudo bash install.sh, ноль обращений к внешним API.

Я делал это не как pet-project, а под себя — мне нужна была машина для работы с корпоративными документами, договорами и регламентами, которые ни при каких условиях нельзя отдавать в облачные ассистенты. Сборка получилась самостоятельным дистрибутивом — назвал его AGmind, выложил на GitHub под Apache 2.0.

В статье разберу:

— из чего собран стек и зачем там каждый компонент; — почему RAGFlow пришлось пересобрать с нуля и что я туда добавил; — как устроен кластер из двух Spark'ов; — пять конкретных грабель GB10, которые я ловил вечерами; — почему Claude Code за месяц превратил один из этих компонентов в работающий продукт, но при этом не заменил собственно программиста.

Всё больше выходит больших MoE моделей с малым числом активных параметров. У MoE совсем другой сценарий нагрузки и использования ресурсов нежели у Dense моделей, достаточно немного VRAM. Большие MoE модели устроит 1 GPU и много обычной RAM. О том, как устроены MoE и как ускорить работу одним параметром не меняя железо.

Самый просто способ запустить локальную LLM - это установить ollama или LM Studio. Это быстро и просто, но вы теряете и в скорости, и в качестве. Почему UD_Q4_K_XL лучше при том же размере, почему квант Q3 может быть медленнее чем Q4. Хорошая ли идея взять REAP для вырезания ненужных экспертов из MoE. Кто быстрее, Linux или Windows. В общем как выжать больше из локальных LLM на домашнем железе.

Как клонировать экспертизу человека, на которого у тебя нет бюджета? Я взял двухчасовой разговор с топовым маркетологом, прогнал транскрипт через промпты, построенные на научных методах извлечения знаний — CogKC, Knowledge Graph, поведенческое клонирование — и получил JSON-файл, который отвечает на вопросы почти как она.
Сначала проверил на себе: файл с «душой» выглядел банально, но агент на его основе пугающе точно воспроизводил мою логику решений. Внутри — наука, два эксперимента, этика и готовые промпты.

Ваша LLM галлюцинирует? Наденьте на неё экзоскелет — и заставьте работать по правилам

Тесты на Qwen и DeepSeek показали: одна системная инструкция превращает модель из «уверенного вруна» в инструмент, которому можно доверять.