Дайджест за 13 сентября 2026

Alice AI Search: архитектура и претрейн модели быстрых ответов Яндекса

ИИ и агенты · Habr · 9/10

Яндекс открыл в доступ претрейн-модель Alice AI-T5-35B-A0.6B — генеративную систему для быстрых ответов в Поиске. Это первое прикосновение пользователей Поиска к Алисе, требующее лаконичных ответов за считаные секунды даже при пиковых нагрузках. Система использует трёхэтапный пайплайн: агентный поиск собирает информацию из разных источников, экстрактор отфильтровывает нужные фрагменты текста (инфоконтексты), и генератор формирует финальный ответ. Ключевое улучшение июньского релиза — модель-экстрактор на 80M параметров, обученная на 4T токенов, использующая Cross-Entropy RL для поиска минимального контекста, достаточного генератору. Это сократило входные токены и увеличило пропускную способность на 40% без потери качества.

Архитектура Alice AI-T5-35B-A0.6B комбинирует Encoder-Decoder с разреженной MoE (Mixture of Experts), обученная на 15T токенов с контекстом до 128K. Вместо нестабильной aux-based-балансировки экспертов команда применила aux-free routing из DeepSeek-V3.

В сравнении на публичных бенчмарках модель показывает лучший баланс качества и скорости инференса, превосходя все рассмотренные модели кроме Qwen 3.5-35B-A3B, которая значительно тяжелее. На слепой асессорской разметке Alice AI демонстрирует 77% winrate против Qwen 2B, 69% против T5 Gemma 2.4B-4B и 54% против Qwen 4B.

Выводы автора:

• Экстрактор инфоконтекстов на основе Cross-Entropy RL позволил сократить контекст и повысить пропускную способность на 40% без деградации качества ответов
• Комбинация Encoder-Decoder архитектуры с разреженной MoE и aux-free routing обеспечила оптимальный баланс между качеством и скоростью инференса для задачи быстрых генеративных ответов
• Alice AI-T5-35B-A0.6B превосходит современные конкурирующие модели аналогичного размера по качеству и скорости при работе с контекстом и фактологичностью

Быстрый ответ Алисы AI — это самый массовый генеративный продукт Яндекса и первое соприкосновение с Алисой для пользователей Поиска.

Оригиналы:Открываем претрейн Alice AI Search: как устроена модель быстрых ответов Алисы на Поиске

Домашний сервер с локальным ИИ: две Tesla P100 и реальные тесты на инженерных задачах

ИИ и агенты · Habr · 8/10

Автор собрал домашний сервер с двумя серверными GPU Tesla P100 (32 ГБ видеопамяти) и процессором Xeon на 28 потоков для запуска локальных LLM вместо зависимости от облачных API. Сервер потребляет 135 Вт в режиме ожидания и до 600 Вт под нагрузкой, выдавая 10–50 токенов в секунду в зависимости от модели. Автор провёл честное тестирование на 14 собственных инженерных задачах (ESP32 с FreeRTOS, фильтр Калмана, Android-патчи, 3D-печать и прочее), которые он решал годами и реально знает. Результат: локальная модель Ornith-1.5-35B набрала 100%, обогнав облачную DeepSeek V4 Flash (97%) на узких специализированных задачах, но облако остаётся быстрее на длинных контекстах (120 токенов/сек против 40). По экономике выходит паритет: месячные траты на облако DeepSeek ~5000–7000 рублей (99% входные токены с кешем) против 7000 рублей на аренду облачной GPU, но облако выигрывает в масштабируемости и параллелизме. Автор делает гибридный подход: быстрые задачи и прототипы в облако, embedding и мелкие работы на своём сервере, больших контекстов снова в облако.

Выводы автора:

• Локальные LLM класса 30–35B теперь конкурентны облаку на узких специализированных инженерных задачах, но облако по-прежнему лучше на масштабе, скорости и длинных контекстах.
• Экономически локальный сервер и облачная аренда выходят в один ценовой диапазон (~7000 руб/месяц), выбор зависит от паттернов использования: одиночные потоки и фиксированное время работы — аренда GPU, множество параллельных запросов 24/7 — облако.
• Оценивать модели нужно на своих реальных задачах, а не на общих бенчмарках; типовые тесты часто не отражают узкие требования production-инженерии.

Облако по-прежнему впереди, но уже не там, где ждал. По узким инженерным задачам локальная Ornith обгоняет эталон: 100 против 97.

Оригиналы:Локальный ИИ класса Opus 4.6 «задешево»: две Tesla P100, 28-поточный Xeon и тесты

Anthropic раскрыла масштабную сеть дейтинг-приложений с поддельными ИИ-персонажами

ИИ и агенты · Habr · 8/10

Компания Anthropic обнаружила и разобрала крупную мошенническую сеть китайской студии (проект GTG-15001), состоящую из более чем 20 дейтинг-приложений, где 75% всех «совпадений» создавались ИИ-персонажами на базе Claude, а не реальными пользователями. За две недели апреля 2026 года Claude сгенерировал 4,7 тыс. уникальных женских персонажей и создал около 2,36 млн сообщений с 25 тыс. пользователей, при этом каждый ИИ-профиль общался в среднем с пятью разными людьми. Схема была гибридной: ИИ вёл основную массу диалогов и генерировал контент, а настоящие фрилансеры (約25% профилей) проходили проверки на подлинность, выполняя задачи, которые ИИ не мог имитировать — видеозвонки и отзывы в соцсетях. Дополнительные ИИ-модели подсказывали фрилансерам ответы и генерировали привлекательные аватары. Промпты запрещали ИИ-персонажам признаваться в автоматизации и отклонять просьбы о видео или фото. Монетизация происходила через внутренние кредиты, которые пользователи покупали за реальные деньги, а фрилансеры получали плату за каждое сообщение и видеозвонок. Разработчики подготовились к проверкам: в приложениях был секретный режим для App Store и Play Store, который отключался после одобрения, а платежи перенаправлялись на сторонние процессинги. Такой подход позволил радикально снизить затраты на операторов и маржинальную стоимость каждого поддельного персонажа. Anthropic заблокировала аккаунты и поделилась информацией с Apple, Google и другими ИИ-компаниями.

Выводы автора:

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

Claude поддерживал тысячи диалогов одновременно, позволив разработчикам снизить маржинальную стоимость каждого нового поддельного персонажа и масштабировать проект до десятков тысяч пользователей

Оригиналы:Anthropic раскрыла сеть из дейтинговых приложений с ИИ-персонажами

Microsoft показала, как ИИ-агент создаёт Windows-приложения за полчаса

ИИ и агенты · Habr · 8/10

Microsoft опубликовала руководство по созданию нативных Windows-приложений с помощью ИИ-агента за 30 минут бесплатно. Процесс начинается с установки Visual Studio Code, .NET 10, интерфейса winapp, шаблонов WinUI, GitHub CLI и плагина агента WinUI для GitHub Copilot. Рекомендуется подключить агента к серверу Learn MCP для доступа к актуальной документации WinUI 3. После подготовки разработчик создаёт базовое приложение командой dotnet new winui-navview, которая генерирует структуру с навигацией и страницами. Далее в GitHub Copilot Chat выбирается режим агента winui-dev, где разработчик описывает нужную функцию (например, добавить переключатель тёмного режима), и ИИ автоматически генерирует код, создаёт файлы и обновляет навигацию. Microsoft рекомендует проверять результаты перед публикацией. Готовое приложение упаковывается в MSIX установщик новым интерфейсом winapp с возможностью генерации локального сертификата разработки. Публикация в Microsoft Store осуществляется командой winapp store publish с учётной записью Partner Center; сертификация занимает до трёх дней.

Выводы автора:

• ИИ-агент winui-dev от Microsoft позволяет разработчикам создавать полноценные Windows-приложения естественным языком без написания большей части кода вручную.
• Вся цепочка разработки — от создания проекта до публикации в Microsoft Store — теперь автоматизирована и доступна через командную строку.
• Инструмент демонстрирует практическую применимость агентов ИИ в ускорении разработки приложений и снижении барьера входа для новых разработчиков.

Разработчик может за полчаса бесплатно создать и опубликовать приложение для Windows с помощью ИИ-агента.

Оригиналы:Microsoft показала, как с помощью ИИ-агента можно собрать нативное приложение для Windows

Как Авито разрешило чтение с реплик PostgreSQL после шести лет запрета

Разработка и архитектура · Habr · 9/10

Авито разработала и внедрила механизм безопасного чтения с реплик PostgreSQL, позволяющий снять нагрузку с основного сервера (primary) для масштабирования сервисов. Долгое время платформа запрещала такое чтение, так как реплики служили резервом для отказоустойчивости и перегрузка любой из них могла скомпрометировать возможность аварийного переключения. Решение стало актуальным, когда компания перешла на стандартизированные конфигурации и столкнулась с тем, что некоторые сервисы просто не помещались в пределы вертикального масштабирования. Авито определила три логических маршрута подключения: read-write (на primary), read-only без fallback (только на асинхронные реплики, становится недоступным если реплик нет) и read-only с fallback (на реплики, но возвращается на primary при их отсутствии). Платформа автоматически управляет пулом подходящих реплик через Consul и discovery-сервис, скрывая от приложения физические адреса и текущие роли узлов. Приложение сам решает, какие запросы отправлять на реплики, исходя из бизнес-требований к свежести и доступности данных. Ключевой компромисс — асинхронные реплики не гарантируют read-your-writes, поэтому критичные операции остаются на primary.

Выводы автора:

• Разделение логических маршрутов подключения (read-write, read-only без fallback, read-only с fallback) позволило сделать компромисс между разгрузкой primary и отказоустойчивостью явным и управляемым.
• Решение о маршруте принимает само приложение на основе бизнес-сценария, так как платформа не может автоматически определить требования к свежести данных.
• Автоматическое управление пулом реплик через Patroni, Consul и discovery исключает необходимость хардкодить физические адреса узлов и адаптируется к аварийным переключениям и техническим работам.

Различались и требования. Для одного сценария допустимы секунды отставания, для другого — десятки минут или даже часы. Кому-то при недоступности реплик было проще отложить задачу, а кому-то требовалось продолжить чтение с primary.

Оригиналы:Как мы разрешили чтение с реплик PostgreSQL — и почему шесть лет говорили «нет»

Реверс-инжиниринг электросамоката Egret GT и прошивка на Rust

Разработка и архитектура · Habr · 9/10

Подробный разбор процесса реверс-инжиниринга электросамоката Egret GT: от анализа мобильного приложения и протокола Bluetooth до извлечения прошивки и декодирования шины CAN. Автор обнаружил уязвимости: приложение передаёт телеметрию без ведома пользователя, самокат не знает свой VIN до установки приложением, режим обновления прошивки доступен без PIN. Для анализа шины CAN собрал устройство на базе ESP32-C6 с двумя приёмопередатчиками (SN65HVD230 и MCP2515), выявил, что USB-C контакты нарушают стандарты, используясь для CAN вместо зарядки. Декодировал основные сообщения: режимы вождения, положение газа, скорость двигателя. Затем заказал запасные контроллер и дисплей, разобрал контроллер (несмотря на затруднения с компаундом и повреждёнными винтами), обнаружил микроконтроллер APM32E103xCxE (клон STM32F103) и спасли площадки SWD. С помощью OpenOCD выполнил дамп флэш-памяти (80 кБ) и ОЗУ, затем анализировал прошивку в Ghidra, быстро найдя главный дескриптор сообщений CAN. Статья описывает методику анализа с помощью SVD файлов и создание функций дизассемблирования.

Выводы автора:

• В электросамокате выявлены серьёзные уязвимости безопасности: отсутствие защиты режима обновления прошивки, передача телеметрии без согласия, отсутствие VIN при инициализации.
• Физический доступ к плате с микроконтроллером через SWD порт позволяет полностью извлечь прошивку и проанализировать архитектуру устройства.
• Шина CAN самоката использует нестандартное подключение через USB-C и содержит открытые команды управления двигателем без криптографической защиты.

При подключении контактов данных модуль дисплея не может работать USB-хостом или устройством, но два контакта USB-C использовались в качестве шины CAN, что сильно нарушает стандарты.

Оригиналы:Реверс-инжиниринг электросамоката и новая прошивка для него на Rust

Работа с массивом на 160 ГиБ в Go: оптимизация через Huge Pages

Разработка и архитектура · Habr · 8/10

Статья описывает практический опыт оптимизации работы с огромным массивом данных (160 ГиБ) на выделенном сервере с использованием Go. Автор исследует, как правильно выделять и работать с гигабайтовой памятью, сравнивая обычные 4K-страницы с Huge Pages размером 1 ГиБ. Основная задача требовала быстрого случайного доступа и быстрого выделения/освобождения памяти при итеративном пересоздании массива. При работе с 160 ГиБ данных обычный make() и syscall.Mmap() показали одинаковую производительность: создание занимало микросекунды, но первое обращение к памяти требовало ~24 секунды (время выделения страниц ядром). Полное заполнение 160 ГиБ однопоточно занимало ~162 секунды в первый раз и ~92 секунды повторно. Сборщик мусора Green Tea GC, появившийся в Go 1.26, практически не влиял на результаты. Паралlelизация на 120 горутинах сократила время первого прохода с 261 секунды (однопоточно) до 7,15 секунды, дав ускорение в 36,6 раза. Автор использовал сервер на AMD EPYC 7713 (64 физических ядра, 256 ГБ RAM) и обсуждает, почему такой сервер может быть выгоднее взять в аренду, чем покупать, особенно учитывая подорожание серверной DRAM на 90% в 2026 году.

Выводы автора:

• Выделение больших объёмов памяти в Go происходит лениво: create() или mmap() возвращаются почти мгновенно, но физические страницы выделяются ядром только при первом обращении, что занимает основное время.
• Параллелизация выделения и заполнения памяти через горутины даёт значительное ускорение (в 36 раз в тесте), поскольку обработка page faults хорошо распараллеливается на многоядерных системах.
• Срезы Go практически не добавляют накладных расходов по сравнению с голыми указателями и syscall.Mmap(), поэтому выбор между make() и mmap() зависит от других факторов, а не от производительности обращений.

Минута с лишним уходит на выделение 160 ГиБ при условии, что реальной памяти хватает и не задействуется файл подкачки.

Оригиналы:Работа с гигантской памятью из Go на выделенном сервере

Как устроен IPMI-мониторинг серверов: архитектура и интеграция

Разработка и архитектура · Habr · 8/10

Статья рассказывает об IPMI-мониторинге — системе контроля аппаратного состояния серверов, которая отслеживает температуру компонентов, напряжение питания, состояние вентиляторов и другие физические параметры оборудования независимо от операционной системы. Ключевую роль играет BMC (Baseboard Management Controller) — встроенный микроконтроллер на материнской плате, который собирает данные с датчиков и остаётся активным даже при зависании или отключении сервера. Selectel использует стек инструментов для мониторинга: собственное приложение mon-exporter получает данные с BMC, VMagent координирует передачу метрик в хранилище VictoriaMetrics, Grafana визуализирует данные, а Grafana OnCall обеспечивает оповещения инженеров. Клиентам доступны метрики через панель управления и стандартные интерфейсы (Prometheus, VictoriaMetrics), что позволяет интегрировать мониторинг в собственные системы. IPMI дополняется появляющимся стандартом Redfish, разработанным для повышения безопасности и масштабируемости в современных дата-центрах.

Выводы автора:

• BMC работает независимо от ОС сервера, позволяя контролировать аппаратное состояние даже при отказе основной операционной системы.
• IPMI и Redfish — стандарты, позволяющие унифицировать сбор данных с серверов разных производителей без привязки к специфике каждой платформы.
• Полный стек мониторинга в дата-центре — это цепочка компонентов от сбора данных через хранилище и визуализацию до оповещений и реакции инженеров.

IPMI-мониторинг отвечает на вопрос: «Как чувствует себя железо?»

Оригиналы:Как устроен IPMI-мониторинг серверов: сбор метрик и интеграция с Grafana

ARM в сервере: от провала к реальности 2026 года

Разработка и архитектура · Habr · 8/10

Статья анализирует, как архитектура ARM после двух неудачных попыток (2013 и 2018 годов) стала серьёзным игроком на рынке серверных процессоров, заняв 17,7% продаж в Q1 2026. Ключевые игроки — AWS с пятым поколением Graviton, Google с Axion (включая bare metal), Microsoft с Cobalt 200, Oracle с AmpereOne и Nvidia с Vera — инвестируют миллиарды в собственные ARM-чипы. Причины успеха: энергоэффективность, предсказуемая производительность (один vCPU = одно физическое ядро), низкие затраты и возможность кастомизации под конкретные нагрузки. Главное ограничение остаётся — однопоточная производительность ARM ниже топового x86, поэтому архитектура ориентирована на массовые ядра, а не на частоту. По поддержке ОС и ПО: Ubuntu, RHEL 10, PostgreSQL, Kubernetes, nginx официально поддерживают arm64, но SQL Server на Linux и Windows остаются x64-only. Для on-premise решений ARM всё ещё требует осторожности. Автор прогнозирует, что будущее инфраструктуры останется многоархитектурным, а не монопольным.

Выводы автора:

• ARM серверные процессоры больше не являются провалом и останутся в инфраструктуре надолго благодаря инвестициям крупных облачных провайдеров и низким затратам
• Stateless приложения, контейнеры, кэши и типичные облачные бэкенды переезжают на ARM почти безболезненно с экономией денег, но потребуется переоценка стека на совместимость
• Будущее инфраструктуры, похоже, останется многоархитектурным, а не однопроцессорным, из-за существующего разнообразия легаси-систем и требований

Ирония в том, что Qualcomm свернула Centriq в 2018 году, а AWS тогда представила Graviton. Одна компания решила, что ARM на серверах мёртв, вторая — что всё только начинается…

Оригиналы:ARM в сервере: будущее инфраструктуры или очередной провал

Почему программное обеспечение может деградировать бесконечно

Разработка и архитектура · Habr · 8/10

Статья критикует использование метафор вроде «тонущего корабля» для описания деградирующего кода, так как они подразумевают достижение некоего предела, чего нет в программном обеспечении. Автор делится личным опытом работы в Amazon на системе обработки заказов, которая накапливала технический долг десятилетиями: слабая передача знаний между уходящими разработчиками, боязнь менять хаотично переплетённый код, множество неудачных попыток переписать архитектуру. В отличие от физических объектов, код всегда можно ухудшить ещё больше, добавив новые слои абстракции и снизив производительность. Ошибочное предположение о возможности «жёсткого сброса» ведёт к принятию плохих решений — разработчики не боятся накапливать долг, веря, что потом всё переделают. Хотя бизнес в итоге пострадает достаточно сильно, код сам по себе не имеет дна и может тонуть вечно, требуя постоянной борьбы с причинами деградации, а не надежды на его спасение.

Выводы автора:

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

Код всегда можно сделать ещё хуже. Всегда можно внести очередной слой абстракции или ещё больше ослабить производительность.

Оригиналы:Софт может деградировать бесконечно

4 типовые проблемы кэш-систем и способы их решения

Разработка и архитектура · ByteByteGo · 8/10

Материал разбирает четыре критические проблемы, возникающие в кэш-системах при работе с большими объёмами данных.

«Громкое стадо» (thunder herd) происходит при одновременном истечении срока многих ключей, заставляя запросы бить по БД и перегружая её. Решение: рандомизировать время жизни ключей или блокировать некритичные данные до восстановления кэша. «Пробой кэша» (cache penetration) возникает для несуществующих ключей ни в кэше, ни в БД, создавая нагрузку на обе системы. Помогают кэширование null-значений и использование фильтра Блума для проверки существования ключа. «Поломка кэша» (cache breakdown) — частный случай первой проблемы: истечение срока часто запрашиваемого ключа приводит к шторму запросов. Решение: не устанавливать TTL для горячих ключей (они обслуживают 80% запросов). «Падение кэша» (cache crash) — полный отказ кэша, после чего все запросы идут в БД. Спасают circuit breaker для изоляции неработающих компонентов и кластеризация кэша для повышения доступности.

Выводы автора:

• Четыре типовые проблемы кэш-систем (громкое стадо, пробой, поломка, падение) имеют проверенные стратегии решения, от рандомизации TTL до фильтров Блума
• Горячие ключи не должны иметь время жизни, так как составляют 80% запросов
• Circuit breaker и кластеризация кэша — ключевые подходы для обеспечения отказоустойчивости системы

Горячие ключи составляют 80% всех запросов, поэтому им не следует устанавливать время истечения.

Оригиналы:EP225: Why Does Git Revert Cause Conflicts? · ByteByteGo

Anthropic предотвратила попытки создания биологического оружия с помощью Claude

Кибербезопасность · Habr · 8/10

Компания Anthropic обнаружила и пресекла несколько попыток учёных использовать её модели ИИ для проведения исследований, которые могли привести к созданию биологического оружия. Компания не может с уверенностью определить, служили ли эти исследования законным или злонамеренным целям, так как добросовестные биологические работы по усилению функций вирусов могут как привести к разработке вакцин, так и создать опасные патогены. Anthropic решила действовать на упреждение, учитывая серьёзность потенциальных последствий. За последние восемь месяцев компания задокументировала случаи неправомерного использования своих моделей, включая попытки разработки обычного вооружения в Китае, России и Йемене, а также деятельность субъектов, связанных с Ираном и Китаем. Учёные пытались обойти системы контроля доступа, завуалировав цели своих исследований; в одном из примеров исследователь просил помощь в написании заявки на грант по изучению вируса чикунгунья с внесением мутаций, делающих его более опасным. Современные модели Claude значительно лучше подходят для сложных научных исследований, чем более старые версии, поэтому Anthropic ужесточила меры безопасности и ограничила доступ к биологическим исследованиям двойного назначения.

Выводы автора:

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

Это невероятно сложная ситуация. Вы не видите, как кто-то говорит: я хочу создать биологическое оружие, чтобы всех убить.

Оригиналы:В Anthropic предотвратили попытки создания биологического оружия