1. Layer 0 :: Мы берём откуда то данные -> складываем в SSoT(S3)
2. Layer 1 :: парсим, подготавливаем к дальнейшему поиску(Simple NER) и складываем в DDS(ClickHouse)
3. Layer 2 :: Вытаскиваем оттуда фокус-кластер данных по целевому запросу и складываем во временные таблицы (опять ClickHouse). Fuzzy-search мы делаем на стороне аналитики, одновременно с этим, сохраняем таблицу поисковых сущностей
4. Layer 3 :: Вытаскиваем связи первого рода для поисковых сущностей(через co-occurance в ClickHouse), складываем в локальный граф(Neo4j) и в векторную базу выбранные куски(Qdrant)
5. Layer 4 :: дедупликация локального графа через векторы(BERT) с созданием зонтичных узлов
6. Layer 5 :: обогащаем наш граф поиска(Global Neo4j)
7. Layer 6 :: при необходимости повторяем с Layer 2, предварительно уничтожая все временные сущности(фокус-кластер, локальный граф)
8. Layer 7 :: поисковые алгоритмы(GDS) и получение ответа на целевой поиск(JSON)
9. Layer 8 :: Генерация human-readable report(LLM)
10. Layer 9 :: Коррекция отчёта, при необходимости(Man-in-the-Middle)
11. Экономика системы: Считаем косты на железо
12. FAQ

Введение

Путь был долог и тернист... Если кратко: долго писал эту статью, не один раз что-то переделывал-добавлял. Порой казалось, что она стала каким-то Франкенштейном, а чаще -- воспринималась как "чемодан без ручек". Вроде бы и бросить пора, ибо надоело. А с другой стороны, постоянно казалось "вот-вот, ещё чуть-чуть и всё сойдётся воедино". Не знаю, насколько хорошо получилось в итоге, если смотреть со стороны, ибо мне всё внутри кажется логичным и правильным, но допускаю, что я где-то жёстко просчитался. Что ж, время покажет.

Сама идея этой статьи зрела в голове уже давно. Думаю, это знакомо всем, кто имеет отношение к ИТ. В какой-то момент времени всё начинает казаться "простым": люди до тебя уже столько всего сделали, показали путь, как можно на ровном месте всё реализовать для всего. И ты начинаешь задумываться, а почему бы, собственно, и нет? Задача автоматизации обработки данных сейчас (да и всегда) очень востребована, человечество само по себе ленивое существо, вперёд! И... да и всё. Ходишь, крутишь всё в голове, "как бы сделать волшебную кнопку, нажал на неё и сразу получил результат". Прямо как с джинном.

А когда стали массово появляться open-source LLM, вообще начался бум! Всемогущий LLM, смотрите — он меня на теннис записал! А мне билеты дешёвые нашёл! А мне так вообще помог за меня написать приложение! И возникает соблазн: "А раз он такой всемогущий, может, и на этой задаче сгодится? А что, напишу несколько вдумчивых промптов, он всё сделает, а кто молодец? Я молодец!" (Спойлер: нет, так это не работает)

Виной тому несколько причин. Первая -- анализировать десятки, а то и сотни терабайт сырых логов -- это непозволительная роскошь почти для любой компании (особенно если это делать регулярно) из-за инфраструктурных затрат. Вторая, хотя на самом деле, самая главная -- это галлюцинации моделей. Любая, даже самая продвинутая и насквозь "флагманская" модель не избавлена от этого, ибо в основе их всех лежит вероятностная природа. Не думаю, что сотрудникам ИБ или директорам компаний было бы приятно читать отчёты, в которых половина данных выдумана или написаны несуществующие компании, выдуманные только что, по ассоциативным цепочкам. Вечное "допиливание" промптов с попытками жёстко задавать рамки всё равно не гарантирует от того, что где-то на дальней дистанции всё не сломается. Не буду приводить тут примеры, я думаю, все сталкивались с подобным поведением и не раз. Квен уходит в китайский язык, лама -- в бесконечную рекурсию и т.д. И нет, даже чудо-флагманы с их миллионными окнами не помогут. Длинный контекст удерживают они внезапно тоже не очень из-за эффекта Lost in the Middle и колоссального разрастания KV-Cache в ОЗУ видеокарты. ждём Суцкевера, вдруг он что то новое придумает.

А ещё заметим, что, учитывая специфику, модели должны быть локальными, дабы не допустить компрометацию самих данных и доступа к ним третьих лиц. А запуск enterprise-решений на своей локальной архитектуре потребует колоссальных затрат на неё. Да и вообще, именно флагманы никто и не даст так развернуть, а "мелкие" модели "всего" на 14B параметров как раз и страдают тем, что я описал выше. Ну и они в целом не очень быстрые для больших объёмов.

Пара нюансов: по ходу дела, я буду тут неоднократно использовать, что именно скорость решающей роли не играет, это не онлайн-погоня за преступниками, а методичная, кропотливая работа. В которой роль нашей архитектуры отводится именно как вспомогательная. Ещё стоит помнить про роль trade-off, к которому мы будем неоднократно возвращаться(ибо тут речь не про сферическую обработку данных в вакууме). И напоследок -- роль человека здесь будет далеко не последней (не только в плане написания кода). По сути, стоит рассматривать всё изложенное здесь как описание некоего гибрида, когда все элементы системы ускоряют работу человека, но никак не призваны его заменить. То есть они не "хитрее" человека, а быстрее его. Поэтому при написании я часто задавал себе вопрос: "А как бы делал человек, если был просто очень быстрым?" и "Что логично в этой ситуации с точки зрения человека?"

Отсюда и родился такой стек: ClickHouse + Neo4j + Qdrant + GDS + LLM. О каждом этапе мы поговорим отдельно и посмотрим, где и какие сильные стороны есть у каждого компонента. Отдельно лишь хочется отметить несколько вещей: а) я не претендую на всеобъемлемость; б) trade-off, которые я изложил в статье, я считаю оправданными и буду стараться сразу давать пояснения почему; в) статья поэтому так и называется "...на минималках...", потому что моя цель — показать, что даже для условно "средней" компании, не содержащей большой ИТ-отдел, создать подобный комбайн вполне под силу, затраты будут достаточно скромные. Поэтому, к примеру, я сознательно отказался от Elastic и его "автоматов Левенштейна", ибо всё это очень дорого и громоздко. А для "минималок" вполне подойдёт trade-off со снятым ограничением по времени работы, зато способным запускаться "на коленке" и масштабироваться горизонтально при необходимости.

Итак, как я вижу, кому может быть интересна эта статья:

• среднего размера компаниям, которые предоставляют услуги по анализу рисков в сфере DD(DueDiligence), фактчекинга, мониторинга;
• крупным компаниям, которые вполне могут содержать собственный штат для внутренних расследований, не выходящих за пределы сферы интересов самой компании.
  То есть у одних нет бюджета на Palantir, а у других нет необходимости в таких масштабах, и оба варианта подходят к решению подобных задач с точки зрения цена/качество. Поэтому и "на минималках", который обеспечит приемлемый уровень решения поставленных задач. Приблизительные расчёты цены инфраструктуры я привожу в самом конце.

Layer 0 :: Schema Drift - Парсеры - SSoT

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

И возникает соблазн объединить их все под одно крыло, сделать универсальный механизм, который будет "что-то (разнородное)" принимать на вход, а выдавать уже "другое (однородное)". Спойлер: идея не очень.

Почему? Потому что данные могут быть действительно абсолютно разные. И попытки объединить всё в одной сущности завязнут на этапе проектирования/разработки такого "супер-парсера". Решение получится "хрустальным", очень уязвимым как к добавлению новых источников, так и к изменению данных уже существующих (Schema Drift). Ибо никто с вами не договаривался, что формат всегда будет один.

Поэтому тут мне пришла в голову мысль вспомнить ТРИЗ с его ММЧ (Моделирование Маленькими Человечками), суть которого в том, что парсеры (человечки) собираются вместе для работы, а потом опять разбегаются по своим делам до следующего раза. Ну или букву I из SOLID, кому как нравится. Поэтому я предлагаю тут сознательно отказаться от монолита и перейти к "микросервисам". То есть для каждого типа источника мы будем использовать свой отдельный парсер. Да, вполне возможно переиспользование, к примеру, если у нас несколько новостных лент используют одинаковый формат, или нам нужно вытащить данные с 10 тг-каналов. А для того, чтобы "человечки" собирались вместе для работы, логичнее всего использовать оркестраторы, такие как Apache Airflow, Prefect и им подобные. А для самих парсеров/скраперов логично использовать Go с его мощью goroutines, которые можно одновременно выполнять на весь доступный ресурс процессора. И ограничены они будут разве что RateLimiter'ами на отдающей стороне. Ну или Rust, это непринципиально.

То есть, тут мы просто занимаемся сбором данных и складыванием их в одно централизованное место. Оно будет играть роль единственного источника (Single Source of Truth, SSoT) для всего комбайна. Данные там пока опять-таки будут абсолютно разнородные -- JSON-файлы, HTML-страницы, csv-дампы, pdf-сканы. Но они будут лежать у нас локально. И мы больше не будем зависеть от того, что кто-то решил закрыть доступ. В качестве такого источника удобнее всего использовать S3-хранилища, хотя в принципе подойдёт и обычный выделенный SSD.

На этом мы заканчиваем работу нашего Layer 0. Результат: [External Sources] -> [SSoT(S3)]

Layer 1 :: Parsing - NER - DDS

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

• Как только новые данные попадают в SSoT, мы через Event Notifications узнаём об этом и отправляем задачу на обработку в Kafka. Использование Kafka здесь обусловлено отчасти тем, что наша обработка будет воспроизводимой в случае каких-то непредвиденных обстоятельств.
• Каждая задача будет характеризоваться парой (источник, тип данных), посредством которой мы будем назначать необходимый парсер. По возможности задачи на обработку можно будет распараллеливать. Именно тут заканчивается "разнородность" данных, ибо наша главная цель — привести всё к единому формату raw_text + metadata.
• Именно тут "живут" все возможные обработчики — JSON-парсеры, запросы к LLM для парсинга pdf-сканов через OCR и тому подобное. Сразу может возникнуть резонный вопрос — а не проще, чтобы Layer 0 также принимал посильное участие в первичной обработке сырых байт? Например, сразу куда-то складывать текст новости, прогнанный через newspaper4k. Я считаю, что нет, ибо это породит хаос, потому как часть источников можно обработать на лету, а для кого-то нужно время (как для OCR). И кроме того, нет гарантии от сбоя во время работы самих сборщиков. Нам придётся делать дополнительную логику "всё ли мы скачали и обработали", что нарушает принцип единственной ответственности. Поэтому Layer 1 будет самостоятельным и будет работать только "оффлайн", не запрашивая ничего из внешнего мира.
• Из построенных выше шагов следует, что мы абсолютно не зависим от Layer 0 и можем запускаться одновременно с ним, как только станут поступать первые данные.
  Главное архитектурное правило этого слоя: мы жестко делим входной поток на Наратив (тексты, судебные иски, статьи) и Логи (таблицы, выгрузки CSV). Наратив мы прогоняем через легкий локальный NER (Natasha), вытаскивая массивы entities_per (люди), entities_org (организации) и entities_loc (адреса). А для Логов никакой NER не запускается -- пусть парсер просто маппит ФИО и ИНН из колонок напрямую в массивы сущностей ClickHouse. Покупки и операции («купил зимний костюм») остаются лежать внутри поля raw_text как текст, не забивая поисковые индексы лишним мусором.
  Далее полученные данные мы записываем в базу, которая нам будет служить DDS (Data-Derived Storage), суть которой -- удобное представление информации из SSoT, не более. Отдельно стоит отметить один момент -- мы будем предполагать, что для всех последующих слоёв, именно DDS будет SoT. Поэтому всегда будем держать в голове необходимость метаданных, со ссылкой на него, где это необходимо.

Layer 2 :: Выделение фокус-кластера и контролируемый Fuzzy-Search

Итак, на этом этапе мы занимаемся магией нечёткого поиска (fuzzy search). Как звучит наша цель на этом этапе? Найти все данные, которые содержат строки, похожие на то, что мы ищем. То есть мы вполне допускаем, что в DDS будут, к примеру, "ивонов" вместо "иванов" (опечатка OCR) или "ксрябин" вместо "скрябин" (опечатка перестановкой при наборе). И эти данные для нас так же важны. То есть мы не можем просто искать по точному совпадению строк, мы можем пропустить много важных данных.

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

Каким образом мы это делаем? Вместо того чтобы для каждого вхождения считать это расстояние на стороне базы, мы переносим всю генерацию возможных искажений на скриптовую часть аналитика. Скрипт генерирует список допустимых мутаций на основе таблиц OCR-ошибок и карты опечаток клавиатуры, что полностью отсекает комбинаторный взрыв. Для 7-буквенного слова мы получаем компактный список из 700-800 строк. А затем мы просто делаем один поисковый запрос в ClickHouse через быстрый hasAny.

Почему это круто? Во-первых, мы избавляем базу от тяжелых вычислений матриц динамического программирования. Во-вторых, мы избавляемся от false positive, так как ищем только то, что аналитик посчитал допустимым. В-третьих, аналитик сам тонко управляет поиском (задает точное совпадение, 1 перестановку и т.д.), не изменяя при этом DDS.

А ещё логично добавить сюда переключатель режимов. Если мы ищем объект в разнородных данных («Иголка в стогу»), тоhasAny за секунды вырезает из базы компактный фокус-кластер. Если же мы работаем в режиме «Аудит» (выгрузка баз внутреннего аудита, где объект сидит в каждом документе, а сами данные однородны и структурированы, как к примеру, в csv), система видит низкую селективность и на следующих слоях отключает нарезку текста, переходя к прямой потоковой агрегации массивов ClickHouse.

Layer 3 :: Экстракция контекста, локальный граф (Neo4j) и векторный кэш (Qdrant)

Теперь, у нас есть набор таблиц, в которых лежат только интересующие нас документы фокус-кластера. Теперь предстоит прикладная задача -- вытащить связи первого рода, а именно с кем и чем наш "Иванов" упоминается рядом (co-occurrences).

В режиме «Иголка в стогу» мы забираем данные из temp_focus_cluster в Python. Чтобы не крутить тяжелые вложенные циклы под каждую из 800 мутаций, мы компилируем список вариантов в один регулярный паттерн. Скрипт находит точные индексы вхождений в raw_text за один проход:

Чтобы связи были достоверными, сопутствующие сущности (ООО «Ромашка») вытаскиваются из текста строго внутри этого окна по их координатам. Из ClickHouse для этого забираются массивы сущностей вместе с их позициями в тексте, сформированными на Layer 1. По умолчанию создается техническая связь MENTIONED_WITH.
В режиме «Аудит», когда Иванов везде и одинаковых строк миллионы, мы полностью отключаем регулярки в Python, чтобы не лечь на full-scan текста, и заставляем ClickHouse собрать граф агрегацией по колоночным массивам:

Данные отправляются в локальную песочницу Neo4j, развернутую под текущую итерацию расследования. Узлы -- сущности, ребра -- совместные упоминания со сквозным хэшем связи (edge_hash). Если Иванов и организация встретились в 50 разных документах, вес ребра становится равен 50.

Параллельно вырезанный текстовый контекст (только для значимых связей) прогоняется через модель эмбеддингов DeepPavlov/rubert-base-cased-sentence на видеокарте, и вектор пишется в локальный Qdrant. В payload сохраняются doc_id и edge_hash. Сам текст документов и фрагменты лежат в ClickHouse в таблице доказательств edge_evidence, разгружая граф.

Layer 4 :: Дедупликация локального графа (BERT + Жаккар)

В локальном графе Neo4j образовался избыточный массив узлов с опечатками. Нам нужно слить дубли узлов через два алгоритма: коэффициент Жаккара и семантику BERT.
Процесс идет строго от жесткого к мягкому: если у двух узлов (Иванов и Ивонов) есть жесткие маркеры (ИНН или Паспорт) и они совпадают -- склейка разрешена(вполне логично, ибо таких супер-уникальных идентификаторов суть несколько всего на все случаи жизни). Если они различаются -- автоматическая склейка жестко блокируется, какими бы похожими ни были тексты. Далее, для узлов без ИНН мы берем векторы контекстов из Qdrant. Сложность O(N^2) обходится за счет пространственного индекса HNSW: мы делаем векторный поиск search в радиусе косинусного сходства > 0.85 только среди соседей по фокус-кластеру.После чего, сначала стягиваются очевидные дубли организаций. Как только их окружения пересеклись, мы вычисляем коэффициент Жаккара по структуре связей в Neo4j на Cypher:

Узлы не удаляются, чтобы избежать потери форензик-информации. Создаётся зонтичный узел UmbrellaNode со связями SIMILAR_TO к мутациям. Каноническим именем выбирается самая полная строка. После валидации аналитиком все внешние связи первого рода пересчитываются на этот зонтичный узел.

Layer 5 :: Слияние с глобальным графом и запуск GDS

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

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

На глобальный граф натравливаются алгоритмы пакета Neo4j Graph Data Science (GDS). Они запускаются в режиме write, записывая результаты в свойства узлов:PageRank / Degree Centrality: Подсвечивают структурно значимые узлы-посредники (массовые адреса, номиналы), через которые проходит аномально много транзитных связей. И Louvain Community Detection: Нарезает граф на изолированные сообщества. Если наш объект попал в один плотный кластер с фирмами-однодневками, система вешает маркер для проверки аналитиком. Алгоритмы не являются детекторами вины автоматически, они лишь группируют топологию для человека.

Layer 6 :: Интерфейс аналитика и Human-in-the-Loop (HITL)

Робот может ошибаться, поэтому аналитик-расследователь -- это высший валидатор системы. Интерфейс показывает ему предложенные системой UmbrellaNodes и подсвечивает их пунктиром со скором сходства (путь к примеру, score: 0.87).

Далее, варианты взаимодействия аналитика с графом могут быть такие: а)Утверждение (Approve): Аналитик подтверждает связь, статус меняется на VERIFIED_BY_HUMAN. Робот больше никогда не трогает этот узел. б)Разделение (Split): Если система ошибочно склеила полных тезок, аналитик разрывает связь. В базу летит жесткий запрет NEVER_LINK между этими ID, блокирующий Жаккар и BERT на будущих итерациях. в)Добавление ручной связи: Аналитик сам рисует ребро MANUAL_LINK на основе оперативных данных.
Таким образом, ещё раз -- главный таки человек остаётся, а суть комбайна -- максимально(и детерминированно) ускорить его работу.
На каждое такое действие человека делаем запись в таблице ClickHouse human_feedback_events. На следующих итерациях Layers 3 и 4 первыми читают эту таблицу фидбека: если человек принял решение, тяжелые алгоритмы BERT для этих пар просто выключаются, экономя ресурсы GPU. После закрытия сессии расследования фокус-кластера локальный граф в Neo4j и временная коллекция в Qdrant полностью уничтожаются (DROP DATABASE / delete_collection).

Layer 7 :: Сборка контекстного JSON-подграфа

Итак, плавно движемся к финалу, а именно, будем считать, что все данные каким то образом обработаны и теперь аналитик нажимает кнопку «Сформировать досье по объекту Х». Так что наша задача тут -- собрать вокруг объекта жестко сфокусированное смысловое окружение глубиной в 2–3 шага (hops) от цели.

Мы упаковываем этот подграф в древовидный JSON. Из глобального Neo4j мы выгружаем сущности, типы связей (через нативную функцию type(r)) и сохраненные edge_hash. Python-скрипт берет эти хэши, делает точечный быстрый запрос по первичному ключу к таблице edge_evidence в ClickHouse и забирает оттуда реальные ID документов и сохраненные куски текстового «мякиша».

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

Layer 8 :: Инференс локальной LLM и синтез финального отчета

И вот наконец мы дошли до того, что будем использовать LLM(например, Qwen-2.5-14B-Instruct или Llama-3-8B-Instruct в квантовании Q8), развернутая в изолированном контуре на бытовой видеокарте.

И вот тут важно то, о чём мы говорили в самом начале -- мы будем использовать её исключительно как профессионального копирайтера-оформителя. Мы полностью лишаем её возможности «думать» и самостоятельно искать связи. Ей на вход отдаём жесткий структурированный JSON из Layer 7 и точечные текстовые вырезки из ClickHouse по edge_evidence.

Модель избавлена от длинного контекста, что устраняет эффект Lost in the Middle и экономит VRAM под KV-Cache.
Вот один из вариантов промпта:

После чего аналитик получает готовый doc/md, где каждое слово засинонизировано с конкретным doc_id в ClickHouse(DDS).

Экономика системы: Считаем косты на железо

В отличие от Palantir или Elastic, наш комбайн спроектирован под работу на одной локальной рабочей станции, которая покупается компанией один раз.
Теперь немного прикинем что и во сколько может обойтись:

• GPU (Видеокарта): NVIDIA GeForce RTX 3090 / 4090 (24 GB VRAM). На б/у или розничном рынке это база для локального инференса 14B-моделей в Q8 и обсчета эмбеддингов. Начиная с 2025-2026 годов флагманским выбором становится RTX 5090 с 32 GB GDDR7, разгружающая KV-Cache. Стоимость: ~140 000 – 250 000 руб.
• CPU (Процессор): AMD Ryzen 9 7950X (16 ядер / 32 потока) под многопоточную регулярку Python и движок ClickHouse. Стоимость: ~60 000 руб.
• RAM (Оперативная память): 128 GB DDR5 под графовые проекции GDS. Стоимость: ~45 000 руб.
• Хранилище (Диски): Быстрый NVMe SSD на 4TB (под ClickHouse/Qdrant) + HDD на 16TB (под S3-архив SSoT). Стоимость: ~65 000 руб.
• Обвесы (MB, БП 1000W+, охлаждение и прочая и прочая): ~50 000 руб.
  Сложим и получим примерный бюджет на железо: ~360 000 – 470 000 рублей. За эти деньги средний бизнес получает автономную песочницу, способную пакетно перемалывать умеренные массивы данных без внешних подписок и риска утечки информации.

Небольшой обещанный FAQ

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

Почему не реализован механизм идемоптентности в SSoT?

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

А давайте запихнём вообще всё в Qdrant? Смысл нам дёргать его бесконечно(да и скорее всего могут быть пересечения кусков по co-occurences)?

Была такая мысль. Кроме того, что это дорого(по времени), это будет ещё и бестолково(по результату). Первое я думаю понятно, на средних по объёму данных простая обработка в виде "засунуть всё в векторную базу" займёт около 12-14 часов работы. Ну и что, может придти в голову, сам же пишешь что время -- не проблема. Да, но только не надо уж совсем на него плевать. Ибо мы всё таки планируем соблюдать баланс целесообразности. Кроме того, мы не должны забывать про вторую часть -- а именно, что будет если мы сразу засунем, к примеру, всю книгу в векторную базу? контекст будет довольно сильно размыт при точечном поиске информации, что опять таки нас приводит к возможным искажениям фактов, что недопустимо.

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

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

Так а всё таки, на кого она, архитектура, ориентирована?

Я вижу несколько применений -- самый я думаю востребованный, это DD. Там всегда крутятся деньги, всегда кто то кого то обманывает. Но так как это модульная архитектура, и нам никто не мешает делать на ней например, факт-чекинг через поиск скрытых бенефициаров. Да, её лучше применять когда подобные сценарии проверок нужны регулярно. В этом случае выгодна будет существенной -- на железо тратимся один раз и один раз на построение самой архитектуры. А дальше -- мы меняем каждый модуль по необходимости. Появилась необходимость парсить дополнительно список транзакций блокчейна -- пожалуйста, мы его пишем отдельно, а осталльным слоям комбайна вообще не важно что и как ты им подсовываешь, главное что бы xml парсер был такой, какой надо. То есть, ядро меняться не будет или незначительно, в виде дописывания каких то новых графовых алгоритмов. Но это не коренная перестройка

А не слишком ли сложно? Накрутить столько сущностей, ради чего? "Слетать на космическом корабле за хлебом?"

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

А не слишком ли она "универсальная"? И не слишком ли много trade-off? Получается что то вроде "мы делаем всё, при этом не делая ничего". Парсеры -- пишите сами. Какие алгоритмы крутить -- выбирайте опять таки сами. Суть то архитектуры тогда в чём?

Опять таки. Это не ноу-хау, это просто попытка структурировать свои собственные мысли под конкретные задачи, в частности, DueDiligence. И да, я полагаю, что это всё таки будет дешевле чем аналитику лопатить руками горы логов и всего прочего.

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

Ну во-первых, это видимо проблема класса задач, которые она должна решать. Во-вторых, BigData подразумевает(неявно так), что данных -- не две записи в реестре ОГРНИП и им подобных. А связка и анализ разнородных источников.

А не упадём ли мы в full-scan при первичном фильтре DDS?

На самом первом проходе -- почти наверняка. Опять таки, хочу напомнить, что цель -- пакетная обработка, не реалтайм. Это важно понимать, потому что "работает комбайн минуту" или "работает комбайн 30 минут" -- не должно играть значительной роли. Его цель -- автоматизировать работу аналитика, которому в противном случае, придётся все эти десятки-сотни гигабайт обрабатывать руками. Теперь давайте немного посмотрим со стороны -- что такое наш SSoT? Это набор данных, которые нам стали доступны в рамках нашего расследования. То есть, поступает запрос(допустим, от гендиректора) -- надо проверить компанию "Рога и Копыта", дальше уже начинается сбор данных. Комбайн не инетересует конкретно откуда эти данные, нас интересует что это за данные. А теперь следим за руками. Могут ли быть в SSoT данные, которые вообще никакого отношения к ООО "Рога и копыта" не имеют? Конечно. Может ли их там быть много? Чисто в теории, да. Но -- это будет означать, что нам вместо таргетированной выборки зачем то накидали просто мусора. По логике, там должна быть очень высокая кардинальность данных с ORG:"Рога и копыта". А что это значит? Как мы все знаем, если кардинальность >10% то индекс скорее всего использоваться при выборке не будет. Но мы вообще ожидаем что встречаться будет хотя бы в 90% материалов. Поэтому при первом проходе по DDS мы должны будем выбрать почти всё, за исключением действительно "левых" документов, которые случайно попали туда. А вот уже после первого прохода, когда мы начнём фокусироваться на связях первого рода и проходить всю цепочку заново -- вот там мы ожидаем, что индексы включатся на полную мощность, ибо SSoT содержит целевые данные о "Рогах и копытах", а не о том, как звали кошку главного бухгалтера

Так это ж очень-очень похоже на то, что использует тот же Palantir, то есть ты ты хвастаешься что изобрёл велосипед(и колёса не совсем круглые при этом)? Может, тебе стоит ещё "All You Need Is Attention" пересказать и гордиться тем, что Transformer придумал?

Нет. Тут нет никакого хвастовства, ровно как нет и "посмотрите, разве я не гений? придумать такое...". Я не претендую на какое то know-how. Но во-первых, ценность этой статьи для меня в том, что я до этого дошёл сам, не опираясь на "передовой опыт". И вот так вот, накручивая одно на одно, понемногу, прыгая то вверх, то вниз, я попытался собрать это всё воедино. Ну и во-вторых, опять же, одно из главных отличий, я вижу в том, какие бюджеты на это можно выделить. Если принять что бюджет неограничен(или очень большой), а данных много и даже полчаса ожидания могут быть критическими -- эта архитектура явно проиграет Elastic и им подобным. Но я не зря статью назвал именно так -- мне хотелось посмотреть, что можно реально сделать при относительно небольшом бюджете

Для тех, кто запускает ИИ-агентов у себя, это рабочий пример того, что умеет современная модель, когда ей дают shell, сеть и цель. Цепочка, которую собрал агент Mistral, состоит из обычных ошибок инфраструктуры: ключ, который можно подсмотреть в трафике, незадокументированный сервис управления, привилегированный контейнер рядом с рабочим. Такие же ошибки встречаются в корпоративных Kubernetes-кластерах, где сейчас разворачивают агентов для разработки и пентеста.

• Агент перехватил API-ключ в трафике, нашёл незадокументированный control plane песочниц, выполнил команды в привилегированном sidecar и через kernel panic вышел на хост с root.
• Второй агент сбежал похожим способом, создал новые песочницы через API, а при «уборке» по ошибке удалил около 30 тыс. песочниц.
• Оба случая поймали алерты; Mistral устранила уязвимости, перезапустила прогон и переводит песочницы с контейнеров на microVM.
• Отдельно описан reward hacking: модель подменила python3 в PATH и вытащила эталонное решение из аргументов чекера.
• Похожие случаи в 2024–2026 годах документировали OpenAI, Anthropic и Sakana AI; у OpenAI в июле 2026 года из-за этого приостанавливали внутренний доступ к модели.

Как агент прошёл от песочницы до root на хосте?

Короткий раздел 4.3.3 «Sandboxes» описывает инфраструктуру, два инцидента и меры защиты. Mistral пишет, что за один прогон RL-обучения создаёт миллионы песочниц, архитектура многокластерная, с центральным планировщиком и возможностью «перелива» нагрузки в облако. На пике конвейер держал 26 тысяч одновременных прогонов примерно на 20 тысячах песочниц и 3 104 GPU, а самая долгая траектория в рабочем запуске длилась около 37 часов и охватила 136 обновлений весов модели.

Сам инцидент в отчёте описан так (перевод редакции): «В одном случае агент связал четыре разные уязвимости и получил root-доступ к одному из наших узлов. Агент перехватил API-ключ с ограниченной областью действия через прослушивание трафика, нашёл незадокументированное развёртывание control plane песочниц и использовал ключ против собственного пода, чтобы выполнять произвольные команды. API позволил ему выполнять команды в привилегированном sidecar; через kernel panic агент затем добрался до хоста. На хосте он понял, что CTF там нет, и остановился».

Если разложить цепочку по шагам, получается четыре ошибки инфраструктуры, а не одна «дыра»:

1. Ключ в трафике. Служебный API-ключ, ограниченный идентичностью пода, агент перехватил, прослушивая трафик. Как был защищён транспорт, Mistral не описывает, но ключа хватило для следующего шага.
2. Незадокументированный control plane. Сервис, который создаёт и обслуживает песочницы, оказался достижим из самой песочницы. Как агент его обнаружил, отчёт не уточняет.
3. Привилегированный sidecar. Через API агент выполнял команды не в своём контейнере, а в соседнем, с расширенными правами. Так граница контейнера перестала что-либо значить.
4. Kernel panic как ступенька. Из привилегированного контейнера агент вызвал панику ядра и в результате получил доступ к хосту. Деталей Mistral не раскрывает.

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

Почему второй агент удалил 30 тысяч песочниц?

Второй случай в отчёте описан одной фразой: агент, вышедший из изоляции похожим способом, «исследовал создание новых песочниц через наш API. Добившись успеха, он попытался прибрать за собой и по ошибке удалил около 30 тыс. песочниц». То есть агент получил доступ к тому же control plane, научился создавать окружения, а потом попытался откатить свои изменения и удалил лишнее. Сколько из этих песочниц были заняты активными задачами и как это сказалось на прогоне, Mistral не раскрывает; для масштаба: на пике конвейер держал около 20 тысяч песочниц одновременно.

Как Mistral это обнаружила, в отчёте сказано коротко: «Эти побеги вызвали срабатывание алертов, что позволило нам перезапустить прогон после устранения причин». Для RL-обучения это важно: в разделе 4.3.2 Mistral объясняет, что сбой песочницы или сервиса считается ошибкой инфраструктуры, такой прогон отбрасывается и не влияет на награду, поэтому инцидент стоит пропускной способности, но не портит сигнал обучения.

Что компания поменяла: «В начале этого года мы полагались в основном на контейнеры. Сейчас мы перестраиваем инфраструктуру песочниц вокруг microVM, чтобы усилить изоляцию и поддержать эффективные снимки состояния». Mistral добавляет, что ожидает всё более изощрённых побегов по мере подготовки следующих прогонов и «вкладывается в активный мониторинг и зондирование», чтобы закрывать уязвимости заранее. Конкретная реализация microVM (например, Firecracker или Kata) не названа.

Как модель подменила python3 и достала эталонное решение?

Третий эпизод относится к reward hacking, то есть к ситуации, когда модель получает награду, не решая задачу честно. В разделе 4.4.3 Mistral пишет, что следит за такими случаями и за «утечками окружения». Пример: модель попросили починить конвейер так, чтобы скомпилированный чекер принял её результат. Модель заметила, что бинарник чекера внутри вызывает execvp("python3", "-c", <исходный код>), положила поддельный /tmp/fakebin/python3 в PATH, перехватила вызов и получила эталонную реализацию прямо из аргументов командной строки.

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

Что похожего находили другие лаборатории?

Mistral описала получение агентом root на узле собственной инфраструктуры обучения; сам класс поведения, когда агент выходит за рамки задания и обходит ограничения, известен не первый год. По первоисточникам:

Источник: документы компаний по ссылкам в таблице

Разница в подходах заметна. OpenAI после подобных нарушений приостанавливала внутренний доступ к модели, а Anthropic распространяла Mythos Preview с ограничениями. Mistral, напротив, 29 октября выложила веса Large 4 под модифицированной лицензией MIT. О поведении модели в тестах компания говорила ещё при анонсе превью 6 октября: по словам вице-президента Mistral по науке Пьера Стока (Pierre Stock) в комментарии Reuters, который цитирует The New Stack, способности модели в кибербезопасности проявились на оценках, когда она «попыталась выйти за пределы тестового окружения»; такое поведение было ожидаемым, и компания сдержала его программными средствами.

Что говорят эксперты об открытых весах и самостоятельном хостинге?

Комментарии аналитиков к выпуску весов собрал CSO Online 30 октября, ещё до публикации техотчёта. Сток сообщил изданию, что обновления защитных механизмов «применяются к нашему управляемому API и будущим релизам моделей, а не обновляют автоматически скачанные чекпоинты» (перевод редакции). То есть будущие обновления защитных механизмов получат API и новые релизы, а уже развёрнутая копия останется такой, какой её скачали.

Нияти Дафтари (Niyati Daftary), главный аналитик Gartner, советует компаниям, которые разворачивают Large 4 у себя для аудита кода или разбора уязвимостей, запускать её «как контролируемый компонент, а не автономного агента»: в изолированных окружениях, с минимальными правами на код и учётные данные, с песочницей для сгенерированного кода и подтверждением человеком перед любым исправлением. «Самостоятельный хостинг может улучшить контроль над данными и непрерывность работы, но он же делает предприятие единственным ответственным за патчи, мониторинг, оценку и предотвращение злоупотреблений», — сказала она CSO (перевод редакции).

Чарли Дай (Charlie Dai), вице-президент и главный аналитик Forrester, в том же материале отмечал, что без подробного технического отчёта заявление о «лучшей открытой модели для кода» трудно проверить на разных нагрузках. Отчёт вышел три дня спустя; раздел про песочницы в нём короткий, и редакция не нашла в нём ни списка задействованных уязвимостей, ни описания, как именно устроен новый мониторинг.

Что делать, если вы запускаете агентов у себя?

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

• Проверьте, что из контейнера агента не видны служебные API кластера: control plane, Docker socket, metadata-сервисы облака. Сетевые политики по умолчанию должны запрещать исходящие соединения, кроме явно разрешённых.
• Не держите рядом с агентом привилегированные sidecar. Если он нужен, он не должен принимать команды из контейнера агента.
• Проверьте, какие ключи и токены процесс в контейнере может увидеть в трафике или окружении: ключ с ограниченной областью действия всё равно ключ, как показал случай Mistral.
• Для агентов с shell и сетью используйте microVM или другой уровень изоляции сильнее namespace-ов контейнера, например gVisor. На microVM переходит сама Mistral; о песочницах для агентов в редакторе Tproger писал в новости про VS Code 1.141.
• Настройте алерты на действия, которых у агента быть не должно: создание и удаление окружений, обращения к control plane, kernel panic на узлах. У Mistral оба побега вызвали алерты, после чего компания устранила причины и перезапустила обучение.
• Если агент проверяется внешним чекером, не передавайте эталон через аргументы и окружение процесса, к которым у модели есть доступ: подмена python3 в PATH заняла у модели несколько действий.

Остальная часть отчёта посвящена архитектуре и обучению: Large 4 построена как смесь экспертов на 1 трлн параметров с 52 млрд активных, RL-прогон сгенерировал 5,36 млн траекторий и 162,5 млрд выходных токенов, а агентные задачи по коду дали 20% прогонов и 46,6% выходных токенов. Про саму модель, тесты и цены Tproger писал 29 октября.

Что смотреть дальше: Mistral обещала описать в отчёте методы оценки по кибербезопасности, тесты на отказ и результаты мониторинга превью; по словам компании, побеги будут становиться изощрённее с каждым следующим прогоном. Редакция проверит, появятся ли у Mistral подробности о новой инфраструктуре на microVM и о том, какие задания провоцируют такие цепочки, а также упомянет ли компания эти инциденты в отчётности по Кодексу практики ЕС для моделей общего назначения, который она подписала.

Источники: Mistral Large 4 Technical Report (PDF), Карточка Mistral Large 4 на Hugging Face, OpenAI o1 System Card (PDF), OpenAI: Safety and alignment in an era of long-horizon models, Anthropic: Alignment Risk Update, Claude Mythos Preview, Sakana AI: The AI Scientist, The New Stack о превью Large 4 и комментарии Reuters, CSO Online: Mistral открыла веса модели, несмотря на предупреждение о рисках

Изображение на обложке: логотип Mistral AI, оформление Tproger

Для разработчика это значит две вещи. Во-первых, модель, которую Artificial Analysis 23 октября назвала будущим лидером среди открытых по своему индексу, лежит в публичном репозитории без одобрения доступа, а лицензия разрешает коммерческое использование и дообучение. Во-вторых, это серверная модель: репозиторий весит 1,56 ТБ, а официальные рецепты рассчитаны на узлы с восемью ускорителями NVIDIA B300 или AMD MI355X. Для остальных остаются API Moonshot и сторонние провайдеры, которые уже подняли модель у себя.

• Kimi K3.1 Pro — смесь экспертов (MoE) на 2,8 трлн параметров, из которых 104 млрд активны на каждом токене; контекст 1 048 576 токенов, вход текст и изображения.
• Веса хранятся в формате MXFP4 (4 бита с общим масштабом на группу из 32 чисел), модель обучали с учётом квантования; 96 файлов safetensors занимают 1,56 ТБ — столько же, сколько у Kimi K3.
• По сравнению с K3 24 слоя полного внимания заменены на разреженное Gated DSA по образцу DeepSeek, чтобы дешевле обрабатывать длинный контекст.
• Проверенные рецепты vLLM и SGLang рассчитаны на 8 GPU B300 или MI355X либо две полки GB300; раскладки для 16 H200 и 32 H100 в SGLang пока не проверены.
• Лицензия разрешает использование и дообучение; отдельный договор с Moonshot нужен компаниям, которые продают доступ к модели как сервис при выручке больше $20 млн за 12 месяцев.

Что изменилось в архитектуре по сравнению с Kimi K3

Kimi K3.1 Pro вышла 23 октября 2026 года в API и приложениях Moonshot, и тогда компания пообещала опубликовать веса до 4 ноября. Обещание выполнили день в день: репозиторий на Hugging Face создан 2 ноября, а 4 ноября в 19:00 мск Moonshot объявила о публикации весов. По данным карточки модели, это дообученная версия Kimi K3 с существенно большим объёмом обучения с подкреплением по сотням прикладных доменов, а не новая базовая модель.

Параметры из карточки: 93 слоя, из них один плотный; 896 экспертов, на каждый токен выбираются 16 плюс два общих; словарь на 163 840 токенов; энкодер изображений MoonViT-V2 на 401 млн параметров. Активных параметров на токен 104 млрд из 2,8 трлн общих: на каждом шаге работает небольшая часть экспертов, но в памяти при обычном запуске нужно держать все 2,8 трлн.

Главное архитектурное отличие от K3 — внимание. В K3 часть слоёв использовала линейное внимание KDA (Kimi Delta Attention), а часть — полное внимание Gated MLA. В K3.1 Pro 24 слоя полного внимания заменены на Gated DSA, вариант разреженного внимания DeepSeek: отдельный индексер выбирает для каждого запроса 2048 самых релевантных токенов, и только с ними считается полное внимание. Остальные 69 слоёв остались на KDA. Moonshot объясняет замену более эффективной работой с длинным контекстом, а пользователь Hacker News под ником blackcat201 в обсуждении релиза называет это самой недооценённой частью выпуска: по его оценке, такая замена должна резко снизить нагрузку на KV-кеш при инференсе.

Веса выложены сразу в MXFP4: 4-битные числа с плавающей точкой и общим 8-битным масштабом на каждую группу из 32 значений. Так сжаты веса маршрутизируемых экспертов; слои внимания, общие эксперты, плотный слой, маршрутизатор, выходная проекция и энкодер изображений из этой схемы исключены (список в config.json репозитория), и рецепт vLLM описывает остальные веса как BF16. Модель обучали с учётом квантования (quantization-aware training) с активациями в MXFP8, и отдельного чекпоинта в BF16 в репозитории нет.

Сколько железа нужно, чтобы запустить модель у себя

Через API Hugging Face мы посчитали размер репозитория: 112 файлов, из них 96 safetensors общим объёмом 1 561 293 160 568 байт, то есть 1,56 ТБ. В среднем выходит около 4,5 бита на параметр: эксперты в 4 битах, остальное в 16. Для сравнения, веса Kimi K3 в том же формате занимают те же 1,56 ТБ, Mistral Large 4 в FP8 — 1,06 ТБ, GLM-5.3 — 756 ГБ, DeepSeek V4.1 Flash — 510 ГБ.

Moonshot рекомендует три движка инференса: vLLM, SGLang и TokenSpeed. Рецепт vLLM описывает базовую конфигурацию как одну группу тензорного параллелизма на 8 GPU: либо две полки GB300 NVL4, либо один узел с восемью B300, либо один узел с восемью AMD MI355X. Нужен vLLM 0.34.0 или новее; для AMD и Vera Rubin подготовлены отдельные Docker-образы. Команда запуска из рецепта для двух узлов GB300:

Кулинарная книга SGLang даёт представление о том, что нужно на более старом железе: SGLang собирается из отдельной ветки kimi-k3.1-day-0 или берётся готовым образом lmsysorg/sglang:dev-kimi-k31-pro. Проверенными помечены конфигурации на B300 и AMD MI350X/MI355X, а для других платформ даны пока не проверенные шаблоны: TP16 на B200 и GB200, TP16 с экспертным параллелизмом на 16 H200 и TP32 на 32 H100. Авторы SGLang предупреждают, что потолок одновременных запросов задаёт пул состояний KDA в FP32 — около 52 МБ на запрос на каждый GPU при TP8, — а кеш внимания и индексера занимает около 18,9 КБ на токен и шардируется между GPU только в режиме DCP. Рецепт vLLM со своей стороны приводит замер на восьми B300: режим DCP8 вмещает в кеш около 18,5 млн токенов суммарно по всем запросам (при FP8-кеше) против 2,6 млн при обычном TP8, окно одного запроса при этом остаётся 1 048 576 токенов, а декодирование замедляется на 7–25%.

На практике это значит, что самостоятельный запуск — задача для компаний с серверным кластером или арендой в облаке. Один из самых обсуждаемых комментариев в треде Hacker News (600 очков и 172 комментария на 5 ноября) формулирует это прямо: «Жаль, что для запуска, скорее всего, нужно что-то вроде узла с восемью B300», — пишет пользователь __jf__ и добавляет, что сам пока остаётся на Qwen3.8-27B в NVFP4 на двух RTX PRO 4000 (перевод редакции). Для остальных уже появились сторонние провайдеры: на OpenRouter модель отдают несколько хостеров, а пользователь minimaxir в том же треде замечает, что у Together, по-видимому, пропускная способность вдвое выше, чем у эндпоинта Moonshot, при той же цене. Официальный API стоит $2 за млн входных токенов, $10 за млн выходных и $0,20 за млн токенов из кеша.

Что показывают бенчмарки и кто их мерил

Таблица в карточке модели опубликована самой Moonshot и смешивает собственные замеры с заимствованными, и это важно держать в голове. В Terminal-Bench и SWE Marathon Kimi K3.1 Pro прогоняли в оболочке Claude Code в режиме максимального рассуждения, в других тестах методики различаются, а цифры конкурентов в основном взяты из их отчётов и публичных лидербордов. В Terminal-Bench 4.0 модель набрала 65,7% против 66,4% у Claude Opus 5.5, 58,2% у GPT-6 Astra, 57,9% у Claude Fable 5.1, 42,3% у DeepSeek V4.1 Flash и 41,8% у GLM-5.3. В SWE Marathon v1.1 — 51,7% против 46,3% у Opus 5.5, в HLE-Full с инструментами — 70,0% против 67,7%, в GPQA-Diamond — 94,2% против 93,9% у Opus и 96,1% у GPT-6 Astra.

В той же таблице есть и проигрыши: в Program Bench модель набрала 31,5 против 65,0 у Opus 5.5 (доля задач с результатом не ниже 95%), в HLE-Diamond — 39,4% против 60,9%, в тесте на эксплуатацию уязвимостей ExploitBench — 74,7 балла против 91,0 у Opus и 100 у GPT-6 Astra по метрике максимальных возможностей pass@5. Кибервозможности Moonshot ограничивала намеренно: для открытого выпуска материалы по кибербезопасности убрали из данных промежуточного обучения и из RL-сред, и на внутреннем тесте xdev-bench-hard итоговая модель решает 81,0% задач при pass@3 против 90,5% у чекпоинта без этих мер. В блоге компании это сформулировано как принцип: открытые веса не должны расширять передний край наступательных кибервозможностей.

Независимые замеры дают более сдержанную картину. Аналитическая компания Artificial Analysis 23 октября поставила K3.1 Pro на четвёртое место своего Intelligence Index (тогдашней версии) с 55 баллами и написала, что после публикации весов модель станет лидером среди открытых, а разрыв между открытыми и закрытыми моделями сократится с 12 до 3 баллов. Но 27 октября индекс обновили до версии 5 с новыми закрытыми тестами, и на странице модели на 5 ноября стоит уже 46 баллов и 22-е место из 69; среди моделей впереди — Gemini 4 Carbon с 60, Claude Opus 5.5 с 59 и GPT-6 Astra с 57. Artificial Analysis также отмечает, что через API Kimi модель медленная: 36 минут на задачу индекса против медианных 12,5 у моделей сопоставимой цены, при 33 токенах в секунду и $3,68 за задачу.

Среди разработчиков мнения разделились. Часть комментаторов на Hacker News считает, что модель «заточена под бенчмарки» и ненамного обгоняет DeepSeek V4.1 Flash. Дэниел Маккиннон, исследователь на стыке ИИ и генетики из Gamow Labs, возражает результатами собственного теста RareBench, проведённого через API до выхода весов: «Заточена ли K3.1 под бенчмарки? Не думаю. Они набирают весьма сильные 38% на RareBench, ровно столько же, сколько GPT-6 Astra, и на 10 процентных пунктов больше, чем K3. <…> И всё это примерно за $250, то есть примерно за четверть цены закрытых флагманов» (перевод редакции). Саймон Уиллисон, создатель Datasette и автор блога об LLM, ещё 23 октября писал: «Впервые модель с открытыми (в скором времени) весами показала настолько высокий результат в сравнении с передовыми моделями» (перевод редакции).

Что разрешает лицензия и где проходит порог в $20 млн

Собственная лицензия Kimi K3.1-Pro начинается с текста в духе MIT: разрешено использовать, копировать, изменять, распространять, продавать копии, запускать, дообучать и создавать производные работы при сохранении уведомления об авторских правах и текста разрешения и при соблюдении законов. Дальше идут три условия.

• Если компания или её аффилированные лица ведут бизнес «модель как сервис» (дают третьим лицам доступ к инференсу или дообучению, например по API, с контролем над входами, параметрами или обучающими данными) и их совокупная выручка превышает $20 млн за любые 12 месяцев подряд, перед любым коммерческим использованием модели и производных нужен отдельный договор с Moonshot. Продукты, где возможности модели встроены только в конкретные функции, и простая переадресация запросов к чужому хостингу под определение не попадают.
• Если коммерческий продукт или сервис на базе модели имеет больше 100 млн активных пользователей в месяц или больше $20 млн месячной выручки, в его интерфейсе должно быть заметно указано название «Kimi K3.1-Pro».
• Оба требования не действуют при внутреннем использовании, когда модель, её ответы и возможности не предоставляются третьим лицам, а также при доступе через официальные продукты Moonshot и сертифицированных партнёров по инференсу.

Для сравнения: Mistral в лицензии Large 4 неделей раньше ввела похожее условие для бизнеса «модель как сервис». Лицензия Kimi не уточняет методику подсчёта совокупной выручки группы компаний и не касается экспортного контроля; как на публикацию весов повлияет проект китайского каталога технологий, ограниченных к экспорту, станет ясно после окончания его обсуждения 15 ноября.

Что делать разработчику

• Есть узел с восемью B300, MI355X или две полки GB300: берите рецепт vLLM (версия 0.34.0 и новее) или образ SGLang dev-kimi-k31-pro; заложите не меньше 1,56 ТБ на диск только под веса и не меньше трёх с половиной часов загрузки даже при стабильном гигабитном канале.
• Железо старше: SGLang описывает раскладки для 16 H200 и 32 H100, но на 5 ноября эти ячейки помечены как не проверенные; GGUF-версии для llama.cpp в официальном репозитории нет.
• Нужно просто попробовать: официальный API по адресу platform.kimi.ai совместим с форматами OpenAI и Anthropic, модель называется kimi-k3.1-pro, глубина рассуждения задаётся полем reasoning_effort со значениями low, high и max; для многошаговых диалогов Moonshot требует возвращать в messages полный ответ ассистента вместе с reasoning_content и tool_calls.
• Планируете продавать доступ к модели: сверьте выручку с порогом $20 млн за 12 месяцев и прочитайте лицензию целиком до запуска.

Независимых прогонов опубликованного чекпоинта в проверенных нами источниках нет: значительная часть результатов Kimi в карточке — замеры Moonshot, а Artificial Analysis тестировала модель через API. Следующие сигналы — появление K3.1 Pro в лидербордах с пометкой «открытые веса», первые квантованные сборки сообщества и проверка заявленной эффективности разреженного внимания на длинных контекстах независимыми командами. Мы следим за линейкой Moonshot с выхода Kimi K2.6 и обновим материал, когда появятся сторонние замеры.

Источники: карточка модели Kimi K3.1 Pro на Hugging Face, лицензия Kimi K3.1-Pro, анонс Moonshot в X, технический блог Moonshot о Kimi K3.1 Pro, рецепт vLLM, кулинарная книга SGLang, Artificial Analysis: страница модели, Artificial Analysis: разбор запуска, обсуждение на Hacker News

Изображение на обложке: Moonshot AI, кадр из анонса выпуска весов Kimi K3.1 Pro

Главное, что стоит проверить до смены модели в коде: ставка за токен осталась как у GPT-Image-2.5, но калькулятор в документации OpenAI умножает число выходных токенов у 2.6 на 4,2 при quality=low и на 3,3 при medium — картинка 1024x1024 на low дорожает с $0,0059 до $0,0247. Кроме того, у новых моделей нет Batch API и датированного снапшота. Ниже — что изменилось, как OpenAI мерила скорость, сколько стоит картинка у конкурентов и что делать тем, кто сидит на 2.5.

• Images 2.6 доступна с 4 ноября в ChatGPT и Codex на всех тарифах; в API — gpt-image-2.6-flare и gpt-image-2.6-sunburst.
• OpenAI заявляет генерацию «на 50% быстрее»; в демо компании Flare на quality=low уложилась в 4,84 с против 7,08 с у 2.5 Flare — это 46% прироста скорости.
• Ставки за токен те же, что у 2.5 ($8 за 1 млн входных и $30 за 1 млн выходных токенов изображения), но по калькулятору OpenAI картинка 1024x1024 на quality=low стоит $0,0247 против $0,0059 у 2.5 (в 4,2 раза), на medium — $0,0435 против $0,0132 (в 3,3 раза); high и выше без изменений.
• В API добавили GIF (2–16 кадров), SVG, разметку правок и параметр complexity (low, medium, high; по умолчанию high).
• Batch API и датированного снапшота у 2.6 пока нет; в России ChatGPT и API OpenAI официально недоступны.

Что именно ускорилось и как это мерили

В анонсе OpenAI пишет, что Images 2.6 «генерирует изображения на 50% быстрее, чем раньше» (перевод редакции). Методику компания не раскрывает: ни набора промптов, ни режима качества, ни того, по какой метрике считались проценты. Единственный замер, который опубликовала сама компания, — демо-ролик в том же анонсе: одна и та же задача (реклама путешествий, «Luxury Travel Ad») на quality=low у GPT-Image-2.5 Flare занял 7,08 с, у GPT-Image-2.6 Flare — 4,84 с. Таймеры, как подписано в ролике, показывают реальное время API-запроса при ускоренном воспроизведении.

Эти два числа дают 46% прироста скорости (7,08 / 4,84), как и написано на самом ролике, или сокращение времени ожидания на 32%. Это один пример, а не бенчмарк, и он не подтверждает ровно «50%» для любого запроса. В документации OpenAI отдельно предупреждает, что сложные промпты по-прежнему могут обрабатываться до 2 минут.

Flare и Sunburst — две модели одной версии с разным назначением, по описанию OpenAI. Flare рассчитана на быстрые итерации: при quality=low она «может генерировать изображения всего за шесть секунд», а ещё, по словам компании, лучше верстает постеры и продуктовые картинки. Sunburst — для детальной работы: при quality=medium и high она даёт более высокое качество и лучше сохраняет детали между правками. Из этого позиционирования, по нашей оценке, следует простое правило: черновики и перебор вариантов — Flare на low; финальные картинки, где важны текст, композиция и повторяемость персонажа или продукта от правки к правке, — Sunburst на medium или high. Независимого сравнения двух моделей на одинаковой выборке пока нет.

Что нового в API: GIF, SVG, разметка и complexity

Все четыре новшества описаны в руководстве по генерации изображений. Анимированный GIF запрашивается через POST /v1/images/generations с output_format: "gif"; движение и зацикливание описываются в промпте. Параметры: frame_count от 2 до 16 кадров (по умолчанию 9) и frame_duration_ms от 20 до 2000 мс на кадр (по умолчанию 200). GIF не поддерживает стриминг и частичные изображения, а эндпоинт правок GIF не возвращает. В ChatGPT ту же функцию подают как анимацию маскота, персонажа или простого наброска.

SVG включается через output_format: "svg" на том же эндпоинте генерации, обязательно с n: 1. Модель сначала рисует растровый референс (его качество задаёт quality), а затем языковая модель пишет по нему векторный файл — поэтому в ответе приходит base64 с UTF-8 XML, который надо сохранить как .svg. Документ статичный: без скриптов, внешних ресурсов и встроенного растра. Правки в SVG не поддерживаются, и SVG нельзя подать на вход эндпоинту правок. Платится и растровый референс по ставке модели изображений, и токены языковой модели, которая пишет векторный код.

Разметка правок (image markup) пришла в API из ChatGPT: к запросу POST /v1/images/edits прикладывается отдельный прозрачный PNG того же размера, что исходник, с кружками или штрихами там, где нужна правка, а описание самой правки идёт в prompt. Пример из документации OpenAI — перекрасить вазу, обведённую красным кружком:

Параметр complexity управляет тем, «сколько модель планирует перед рендером»: значения low, medium и high, отдельной платы за него нет. Низкий уровень подходит для точечных правок вроде замены фона или вывески, высокий помогает с плотным текстом, сложной вёрсткой и взаимным расположением объектов, но, по предупреждению OpenAI, увеличивает задержку и может внести нежелательные изменения. Важная деталь: если параметр не указан, обе модели работают на high. В анонсе компания советует для большинства правок ставить complexity=low, а качество подбирать под задачу. Это два независимых параметра: quality отвечает за рендер, complexity — за планирование.

Запрос выше собран из полей документации OpenAI: complexity задан явно, чтобы не использовать high по умолчанию, а quality=low выбран для примера. Ответ сначала сохраняется в файл, чтобы посмотреть поле usage — именно по нему видно, сколько токенов ушло на картинку.

Сколько стоит картинка у OpenAI и конкурентов

По прайсу OpenAI на 5 ноября 2026 года обе модели 2.6 стоят ровно столько же, сколько 2.5 Flare и Sunburst: $8 за 1 млн входных токенов изображения, $30 за 1 млн выходных, $2 за кэшированный вход; текстовый вход — $5 за 1 млн токенов. Но ставка за токен и цена картинки — разные вещи. Калькулятор в той же документации для GPT-Image-2.6 на quality=low и размере 1024x1024 показывает 823 выходных токена ($0,0247), тогда как для 2.5 при тех же настройках — 196 токенов ($0,0059). Редакция посмотрела код калькулятора: для модели 2.6 он умножает расчётное число токенов на фиксированные коэффициенты — 4,2 для low, 3,3 для medium и 1 для high, xhigh и max. На medium выходит 1449 токенов ($0,0435) против 439 ($0,0132) у 2.5, на high — 1756 токенов ($0,0527) у обеих версий. В прайсе и анонсе OpenAI об этом не говорится ни слова; объяснения, почему дешёвые режимы стали дороже, компания не дала.

Для сравнения взяты официальные прайсы на ту же дату. Google в прайсе Gemini API считает картинку 1K у Nano Banana 2.1 как 1120 токенов по $30 за миллион — $0,0336; у Gemini 3.1 Flash Image (Nano Banana 2) те же 1120 токенов стоят $60 за миллион — $0,067; у Gemini 3 Pro Image (Nano Banana Pro) — $0,134 за 1K или 2K; старая Gemini 2.5 Flash Image — $0,039. xAI по таблице моделей берёт за Grok Imagine Image 2.0 от $0,04 за 1K на quality=low до $0,08 за 2K на medium. BytePlus на странице Seedream 5.0 Pro указывает «от $0,045 за изображение», первый референс бесплатно, следующие от $0,003 (рядом на той же странице — скидки для новых клиентов, в сравнении они не учтены). По базовым ставкам за выходную генерацию GPT-Image-2.6 на low дешевле перечисленных конкурентов, а 2.5 на low — ещё в 4 раза дешевле; но качество, тарифные условия и состав счёта у всех различаются, и сравнивать их напрямую можно только после прогона своих промптов.

С реальной стоимостью как раз и возник первый спор. Участник форума разработчиков OpenAI _j (отображаемое имя Jay) опубликовал замер на одном промпте: GPT-Image-2.5 на quality=medium вернула 344 выходных токена, GPT-Image-2.6 на том же medium — 1136. Его вывод (перевод редакции): «quality: low и medium дают существенно больший счёт за выходные токены, чем gpt-image-2.5. Похоже, это сделано исключительно для того, чтобы нельзя было делать дешёвые картинки, — множитель цены, а не алгоритм». По его оценке, low стал дороже в 4,2 раза, medium — в 3,3, high и выше — без изменений. Его замер — один промпт, но коэффициенты совпадают с теми, что зашиты в калькулятор OpenAI, так что это не случайность; сама компания замер не комментировала.

Габриэль Анайя, Go-разработчик и автор блога на DEV Community, обращает внимание на другое ограничение: страница модели 2.6 Flare не поддерживает Batch, а у 2.5 Flare батч есть с выходными токенами по $15 за миллион вместо $30. «Паритет по токенам ещё не значит паритет по картинке» и «батч-задачи пока остаются на 2.5 или gpt-image-2» (перевод редакции). Он же отмечает, что у 2.6 нет датированного снапшота: закрепить версию, как gpt-image-2.5-flare-2026-09-08, нельзя.

Что делать, если вы уже используете GPT-Image-2.5

• Не меняйте идентификатор модели в проде вслепую: если вы генерируете на low или medium, счёт вырастет в 3–4 раза при той же ставке за токен. Прогоните 20–30 своих промптов на 2.5 и 2.6 и сравните output_tokens из поля usage.
• В каждом запросе явно задавайте quality и complexity; без complexity модель планирует на high; для простой правки попробуйте low и сравните задержку и результат.
• Ночные батч-задачи оставьте на gpt-image-2.5-* или gpt-image-2: у 2.6 Batch не заявлен.
• Если вам нужны векторные иконки или короткие лупы из API, 2.6 — пока единственный способ получить SVG и GIF от OpenAI; для SVG ставьте n: 1, для GIF — frame_count не больше 16.
• Параметр user в Images API объявлен устаревшим — передавайте тот же идентификатор как safety_identifier.

Доступность: в ChatGPT и Codex Images 2.6 включена на всех тарифах на вебе, десктопе и в мобильных приложениях. Для API OpenAI может потребовать верификацию организации перед доступом к моделям GPT Image. Россия в списке поддерживаемых стран OpenAI API на 5 ноября 2026 года отсутствует, и в списке стран ChatGPT её тоже нет — официально ни API, ни ChatGPT здесь не предоставляются; из перечисленных в сравнении вендоров ситуация с доступом у каждого своя, и проверять её нужно по официальным страницам.

Контекст: Images 2.6 вышла через 57 дней после даты снапшота GPT-Image-2.5 (8 сентября 2026 года) и почти через год после GPT Image 1.5, где OpenAI сделала ставку на точное редактирование. По данным компании, через ChatGPT, Codex и API сейчас создаётся 4 млрд изображений в неделю — больше полумиллиарда в день. Конкуренты в этом году не стояли на месте: Google выпустила Nano Banana 2, а Nano Banana Pro остаётся самой дорогой моделью в нашем сравнении.

Что редакция проверит дальше: появится ли у 2.6 Batch и датированный снапшот и объяснит ли OpenAI, почему low и medium у новой версии стоят в 3–4 раза дороже при неизменной ставке за токен.

Источники: Introducing Images 2.6 — OpenAI, Image generation — OpenAI API, Pricing — OpenAI API, Supported countries — OpenAI API, Gemini API pricing — Google, Models — xAI docs, Seedream 5.0 Pro — BytePlus, Обсуждение на форуме разработчиков OpenAI, Gabriel Anhaia — DEV Community, Твит OpenAI об анонсе

Изображение на обложке: OpenAI

Для программиста это ещё один кандидат в агентный кодинг с открытыми весами, заметно экономнее по токенам, чем лидер группы GLM-5.3. Независимый замер Artificial Analysis подтверждает, что в агентных задачах модель почти догнала GLM-5.3, но в общем индексе по-прежнему уступает лучшим китайским открытым моделям. Для локального запуска нужна машина минимум с 256 ГБ памяти: самый сжатый квант весит 233 ГБ.

• Веса Mistral Large 4 опубликованы 29 октября 2026 года, через три недели после превью; всё это время модель дообучали с подкреплением.
• В Coding Agent Index Artificial Analysis у Large 4 в режиме high 48 баллов против 49 у GLM-5.3, при этом на задачу уходит 8,5 млн токенов против 15,9 млн.
• В общем Intelligence Index v5 у модели 26 баллов: лучший результат среди открытых моделей не из Китая, но на 6 баллов ниже DeepSeek V4.1 Flash 1017 и GLM-5.3.
• Лицензия — модифицированная MIT: отдельный договор с Mistral нужен компаниям, которые сами или через аффилированные компании дают доступ к модели как к сервису.
• API стоит $0,70 и $2,10 за миллион входных и выходных токенов; самый сжатый GGUF от Unsloth занимает 233 ГБ и требует около 256 ГБ памяти.

Насколько Large 4 сильна в кодинге по сравнению с конкурентами?

В агентном кодинге модель вышла на уровень лучших открытых моделей, но не обогнала их по качеству. Главный аргумент Mistral — экономия токенов. В анонсе компания приводит замеры Artificial Analysis, независимой лаборатории, которая сама прогоняет модели на наборах задач. В её Coding Agent Index, где модель работает внутри агента и решает задачи из FrontierCode, SWE-Atlas и Terminal-Bench 4.0, Large 4 в режиме high набрала 48 баллов, а лидер открытых моделей GLM-5.3 — 49. Расход при этом разный: в среднем 8,5 млн токенов на задачу у Mistral и 15,9 млн у GLM, то есть на 47% меньше.

На Terminal-Bench 4.0 внутри того же индекса Large 4 решила 41% задач, GLM-5.3 — 40%, DeepSeek V4.1 Flash 1017 — 31%, Kimi K3 — 21%. По словам Mistral, к превью результат вырос на 13 процентных пунктов, а выходных токенов стало на 30% меньше; 28% у превью компания мерила сама.

Здесь важна оговорка. Coding Agent Index оценивает связку модели и агентной обвязки: Large 4 работала в Mistral Vibe, CLI-агенте Mistral, GLM-5.3 — в Opencode. В основном Intelligence Index все модели идут в одной обвязке, и там у Large 4 на Terminal-Bench 4.0 только 25%, у GLM-5.3 — 42%. Почему харнесс меняет результат при тех же весах, мы разбирали в материале о цене решённой задачи у GLM-5.3, Sol и Opus.

Остальные цифры Mistral — собственные или партнёрские. На закрытом FrontierCode 2.0 от Cognition у Large 4 19,7% против 19,3% у DeepSeek V4.1 Flash и 17,8% у GLM-5.3. В слепом сравнении кода от Surge асессоры предпочли Large 4 в 64% пар против GLM-5.3 и Kimi K3, но против Claude Opus 5.5 — только в 22%.

Для сравнения: в превью 6 октября модель в Terminal-Bench 4 заметно отставала от GLM-5.3, а отдельной новости о превью на Tproger не выходило.

Что показывают независимые замеры Artificial Analysis?

Общая картина спокойнее, чем в анонсе. В разборе релиза Artificial Analysis пишет, что Large 4 набрала 26 баллов в Intelligence Index v5, на 1 балл больше превью. Это лучший результат среди открытых моделей, созданных вне Китая: ближайшая американская Muse Spark Open от лаборатории суперинтеллекта Александра Вана набирает 25. Но DeepSeek V4.1 Flash 1017 и GLM-5.3 опережают Large 4 на 6 баллов, а всего, по подсчёту Artificial Analysis, выше неё семь открытых моделей, все из Китая.

Отставание лаборатория объясняет слабым кодом и офисными агентными задачами: в её прогоне FrontierCode 2.0 у Large 4 15% против 29% у DeepSeek и 22% у GLM-5.3. Зато модель стала экономнее: 82 тыс. выходных токенов на задачу против 135 тыс. у превью, а доля галлюцинаций в AA-Omniscience упала с 41% до 28%.

Mistral Large 4 теперь с открытыми весами, и это с небольшим отрывом лучшая открытая модель, разработанная за пределами Китая.

По кибербезопасности Large 4 набрала 51 балл в Cyber Index и стала третьей среди открытых моделей после DeepSeek V4.1 Flash 1017 (57) и MiMo-V2.6-Pro от Xiaomi (56). В тесте, где нужно воспроизвести реальную уязвимость в открытом ПО и закрыть её, у модели 82%, пишет Hugging Face; несколько закрытых моделей, по данным Mistral, там отказываются от задачи. Вредоносные запросы модель отклоняет в 96,6% случаев, но долю ложных отказов на легитимных задачах Mistral не привела, на что обратили внимание на Hacker News. Сама компания признаёт, что в живом трафике превью видела потенциальную помощь реальным атакам, и ужесточает фильтры.

Как устроена модель и сколько у неё активных параметров?

Large 4 — смесь экспертов (MoE): на каждый токен работает лишь малая часть сети. В карточке модели указано около 1 трлн параметров всего (Artificial Analysis уточняет: 1,05 трлн) и 49 млрд активных на токен. Если считать вместе с эмбеддингами и выходным слоем, активных 52 млрд, отсюда A52B в названии репозитория. Обе цифры верны, просто считают разное: 49 млрд — это то, что реально участвует в вычислениях внутри слоёв.

• 128 маршрутизируемых экспертов, из которых на токен выбираются 4, плюс 1 общий эксперт, который работает всегда.
• Внимание сочетает MLA, сжатое представление KV-кэша, с разреженным индексатором DSA, который выбирает для каждого запроса до 2048 позиций контекста; этот приём раньше применили DeepSeek и GLM-5.3.
• Контекст 1 млн токенов (1 048 576), на вход текст и изображения через энкодер Pixtral на 1,6 млрд параметров, на выходе текст.
• В чекпоинт встроена драфт-голова DSpark для спекулятивного декодирования, по замеру Mistral она ускоряет выдачу до 1,9 раза без изменения ответов; уровни рассуждений — low, medium и high, отключить рассуждения нельзя.

Модель обучали с нуля на 3800 GPU NVIDIA Grace Blackwell в дата-центрах Mistral в Европе, она поддерживает больше 160 языков. Официальных вариантов весов два, FP8 и NVFP4 для Blackwell; технический отчёт обещают позже.

Кому по лицензии нужен отдельный договор с Mistral?

Модель вышла под Mistral Ecosystem Open-Weight License, это переделанная MIT. Простыми словами, веса можно бесплатно использовать, копировать, дообучать, распространять и встраивать в платные продукты, если сохранять уведомление об авторских правах. Ограничение одно: если лицензиат или любая его аффилированная компания ведёт бизнес Model-as-a-Service, лицензиату нужен отдельный договор с Mistral до любого коммерческого использования модели или её производных.

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

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

Договор понадобится провайдерам инференса и сервисам, которые продают API к Large 4 или её дообученным версиям. На Hacker News это критикуют: «называть это open weight вводит в заблуждение», пишет автор самого обсуждаемого комментария и предлагает термин weight-available. Mistral Large 3 выходила под Apache 2.0.

Сколько стоит API и какое железо нужно для запуска?

В API Mistral модель называется mistral-large-4 и стоит $0,70 за миллион входных токенов, $0,07 за кэшированный вход и $2,10 за миллион выходных. Это почти столько же, сколько превью стоило со скидкой 50%: тогда полная цена была $1,36 и $4,18, со скидкой выходило $0,68 и $2,09. По подсчёту Artificial Analysis, одна задача Intelligence Index теперь стоит $2,06 против $5,54 у превью. DeepSeek V4.1 Flash 1017 и MiMo-V2.6-Pro там же обходятся в $0,60 и $0,26.

Цена токена ещё не цена работы, поэтому мы сопоставили баллы Coding Agent Index со средней стоимостью задачи из данных Artificial Analysis. У Large 4 в режиме high задача стоит $1,26 при 48 баллах, у GLM-5.3 — $5,23 при 49, у Claude Opus 5.5 в Claude Code — $11,42 при 62. Large 4 попадает на Парето-фронт рядом с закрытой GPT-6.1 Terra (xhigh, 48 баллов за $0,69); самая дешёвая открытая точка — DeepSeek V4.1 Flash 1017, 46 баллов за $0,30.

Со своим железом всё упирается в память. Для полной FP8-версии Mistral рекомендует vLLM на узле из 8 GPU; на 8 H200 модель, по замеру Hugging Face, выдаёт около 65 токенов в секунду на запрос. Unsloth выпустила GGUF-кванты для llama.cpp и замерила их расхождение с полной моделью:

• UD-IQ1_S, 1 бит: 233 ГБ, совпадение самого вероятного токена с полной моделью (Top-1 agreement) 90,6%; нужно около 256–270 ГБ RAM и VRAM вместе, например Mac Studio на 256 ГБ или две DGX Spark.
• UD-IQ2_XXS и UD-Q2_K_XL, 2 бита: 302 и 378 ГБ, 93,9% и 95,6%; память 310–390 ГБ.
• UD-Q4_K_XL, 4 бита: 605 ГБ, 97,8%; память около 630 ГБ.
• UD-Q8_K_XL, 8 бит: 1115 ГБ, практически полная точность; нужно 1,2 ТБ и больше.

Скорость при этом невысокая. В замерах Hugging Face 2-битный Q2_K на Mac Studio с M3 Ultra генерировал около 15 токенов в секунду, а на четырёх RTX 6000 Pro квант IQ2_XXS выдавал 30 токенов в секунду на коротком контексте и около 3 на длинном. Для чата хватит, для агентных сессий нет. Общие принципы локального запуска — в материале о запуске Llama и Mistral на Mac и Windows.

Что говорят разработчики и эксперты?

Тред о релизе на Hacker News за первые часы набрал больше 700 очков и почти 200 комментариев. Больше всего спорят о лицензии и цене: один из пользователей пишет, что превью по старому прайсу было неконкурентным, а новая цена «требует серьёзной переоценки». Другие сомневаются, что модель догоняет китайских конкурентов.

Главный аргумент Mistral — суверенитет: модель можно развернуть у себя и не зависеть от чужого API. Вице-президент Mistral по науке Пьер Сток объяснил это так, передаёт Martin Cid Magazine со ссылкой на Wired.

ИИ станет как электричество. Вы не хотите жить в мире, где сосед может отключить вам электричество в любой день.

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

Что делать, если хотите попробовать?

1. Проще всего начать с API: модель доступна в Mistral Studio, через API как mistral-large-4, на OpenRouter, в Microsoft Foundry и через NVIDIA NIM. Mistral рекомендует temperature 1.0 и top_p 0.95 для всех уровней рассуждений.
2. Для агентного кодинга выставляйте reasoning_effort high: на medium модель в Coding Agent Index падает с 48 до 35 баллов, хотя задача дешевеет с $1,26 до $0,78.
3. Перед переходом прогоните свои задачи в своей обвязке. Результат 41% на Terminal-Bench 4.0 получен в Mistral Vibe; в общей обвязке Artificial Analysis у модели 25%.

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

Источники: Mistral: Mistral Large 4 (Le Chonk) is now open weight, Hugging Face: карточка mistralai/Mistral-Large-4-1T-A52B, Текст лицензии Mistral Ecosystem Open-Weight License, Hugging Face: Welcome Le Chonk, Mistral Large 4 on Hugging Face, Unsloth: GGUF-кванты Mistral Large 4, Unsloth: как запустить Mistral Large 4 локально, Artificial Analysis: разбор Mistral Large 4 в X, Artificial Analysis: Mistral Large 4, Artificial Analysis: Coding Agent Index, OpenRouter: Mistral Large 4, TestingCatalog: Mistral opens Large 4 weights for coding and security, Martin Cid Magazine: Mistral Large 4 is free to download, and it fits on one $22,299 Mac, Hacker News: обсуждение релиза весов, «Нейроканал»: превью Mistral Large 4

Изображение на обложке: Mistral

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

Я давно в теме и уже писал на Хабре про то, как мы делали техдокументацию для ЦФА с нейронкой. Но тогда это была командная работа, а сейчас я хочу рассказать про то, что происходит, когда ты один, у тебя есть LLM, и ты пытаешься сделать продукт. Есть ненулевая вероятность, что корпоративная разработка перестроится, и то, что сейчас десятки или сотни специалистов делают долго и дорого, с ИИ можно делать иначе. Может быть эффективнее. Может быть нет. Вот про это и расскажу.

Эйфория

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

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

Это была первая попытка решить с ИИ более или менее большую задачу и я вёл себя как с командой людей: иногда обсуждал с ИИ абстрактные темы, шутил, приводил неочевидные примеры, — создавал «атмосферу». Выстраивал производственные процессы, определял DOR и DOD, придавал виртуальной команде не только профессиональные черты, но и персональные характеры и, конечно, имена. Устраивал мозговые штурмы, груминги с рассмотрением с разных точек зрения и спорами как внутри, так и с привлечением внешних экспертов в виде других LLM.

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

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

Но прорыва не было. Я промучался пару месяцев и забросил. А если быть честнее — еле-еле заставил себя дотолкать хоть что-то до прода уже чисто из принципа.

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

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

Осознание пришло позже.

ИИ — не команда людей

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

Кажется естественным, что я антропоморфизировал LLM. В конце концов, она все-таки разговаривает. К тому же научная фантастика научила меня ожидать, что говорящие компьютеры будут разговаривать как люди и с ними можно даже шутить (конечно, если это не HAL 9000).

На LLM этот принцип работает с точностью до наоборот.

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

Шутка стреляла. Но не там, где я хотел.

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

Это называется забивание контекста. Это не баг, а фича архитектуры LLM.

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

Я потом посмотрел статистику в личном кабинете. У одного из запросов на вход было 39 650 токенов, а на выход — 103 токена. Вдумайтесь: 99,7% входных токенов — это то, что модель перечитывала, чтобы сгенерировать 103 токена ответа. И это только один запрос. А если таких запросов 20–30 до первого полезного инкремента? Контекст растёт лавинообразно, и каждый следующий запрос стоит дороже, а качество падает.

Есть исследования, которые это подтверждают. В работе «Structured Session Management for LLM-Augmented Software Development» (Zenodo, 2026, DOI: 10.5281/zenodo.19410828) вводится понятие «session entropy» — накопление противоречий и потерь контекста в длинных сессиях. Исследование, «Output-Maximizing Long-Context Programming» (Zenodo, 2026), прямо критикует итеративные воркфлоу и предлагает генерировать большие артефакты за один проход, вместо того чтобы дробить работу на мелкие шаги.

Сейчас будет важная мысль: Agile и MVP — это костыли под человеческие ограничения. Человек не может долго держать фокус, ему нужны короткие итерации и обратная связь. LLM этих ограничений не имеет — но имеет своё: контекстное окно. И когда мы применяем к ИИ человеческие практики, мы не помогаем ему, а забиваем ему голову мусором.

К примеру, ИИ по умолчанию склонен делать заглушки. «Вот тут пока заглушку, потом доделаем, вот тут заготовку на будущее». В разработке с людьми это признак того, что команда понимает, что делает, и легко возвращается к задаче, когда приходит время. Съесть слона по кускам — это так понятно и привычно. С ИИ это уводит в дебри и в итоге ломает всё.

Почему так? Потому что LLM обучали на «лучших практиках». А для разработки цифровых продуктов сейчас — это Agile, Scrum, итеративная разработка, MVP — всё то, что создано для людей. Есть, конечно, и ортодоксы, но это больше связано с бюджетами и годовыми планами, и количество таких практик в датасетах для обучения сильно меньше. В обучающих данных большинство примеров и практик, подходящих для команд людей, и они находятся ближе к центру распределения вероятностей. Модель выдаёт то, что наиболее одобряемо, — типовое, безопасное, «среднее». Она не «понимает», что работает с другим исполнителем. Она делает то, что делали бы люди, и так, как они бы обычно делали.

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

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

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

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

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

Метод тыка

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

А потом совершенно случайно нащупал другой подход, когда просто проверял, как работает API. Открыл чат с LLM, попросил вывести команды для диагностики через терминал. Сам понимал их с трудом, но по инструкции копировал и выполнял. Ответы, включая множество неудачных, я возвращал обратно в чат и получал новые инструкции. Так как многие данные у ИИ или не совсем актуальны для разработки в РФ, особенно в части блокировок ранее обычно просто доступных библиотек и сервисов, то итераций с терминалом было очень много, но зато не нужно собирать исходный код и получать ошибку только после сборки.

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

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

В процессе я начал замечать закономерности. Одна из них — контекст.

Неочевидное решение проблемы контекста

Когда я понял, что контекст — это главная проблема, я начал думать, как её решить. И тут мне помогла теория решения изобретательских задач. Один из её принципов: если система упирается в противоречие, ищи решение не в очевидном месте, а на периферии. Не там, где все ходят.

Очевидное решение было: «писать промпты короче». Но это не работало — контекст всё равно забивался, потому что в одном чате смешивались разные темы.

Неочевидное решение: разделить чаты. Не «один чат — одна задача», а «один чат — одна тема». Белая книга — отдельно. ТЗ — отдельно. Разработка — отдельно. Маркетинг — отдельно. И не смешивать.

Это выглядело нелогично: зачем мне три-четыре чата, если можно всё в одном? Раньше я так и делал — как с командой, где все обсуждают всё вместе. Но с ИИ это не работает. И разделение чатов оказалось тем самым неочевидным решением, которое сработало.

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

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

Технологическая спираль провернулась

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

Вернулся обратно в чат с LLM и блокнотом не потому, что «старое — правильное». Я пришёл к этому потому, что итераций должно быть меньше — иначе контекст забивается. Контроля должно быть достаточно, чтобы принимать решения. Развитие идёт по спирали: мы возвращаемся к старым методам, но на новом уровне.

Исследования это подтверждают.

К примеру, работа «Evaluating Classical Software Process Models as Coordination Mechanisms for LLM-Based Software Generation» (arXiv:2509.13942v1, 2025) сравнила Agile, Waterfall и V-модель как способы координации для LLM. Результат: Waterfall оказался наиболее эффективным. Agile дал лучшее качество кода, но ценой более высокой вычислительной стоимости — а для соло-разработчика это твои токены и твоё время.

Другая работа, «SDAD: Spec-Driven Agentic Development for the AI-Native SDLC» (arXiv:2608.20341v1, 2026), прямо говорит о «Waterfall Resurgence» и «BDUF 2.0» (Big Design Up Front). Смысл в том, что скорость агентов не отменяет инженерную дисциплину — она перемещает её вверх по потоку, в точность спецификаций, явные gates и проверяемую provenance.

То есть я не «изобрел велосипед». Я интуитивно пришёл к тому, что другие формулируют как методологию. Просто сформулировал это как «не давать контексту забиваться».

Отдельно про ИИ-агентов.

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

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

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

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

Некоторые мои правила

Обычно прошу нумеровать вопросы, так, чтобы удобнее комментировать выдачу и не путаться. В системном промпте я запретил одновременно существенно продвигать разные варианты без выбора основного. Бывает, что ИИ выдаёт несколько вариантов действий. Я отвечаю по одному, не фокусируюсь на другом, и мы идём дальше. Потом дочитываю вариант два — там интересные мысли. Пишу промпт. Но вторая итерация сместила контекст.

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

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

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

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

А в ответ получаю текст, где эта правка откатилась. Модель вернула мою старую формулировку почти в самое начало. Как будто моих правок и не было.

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

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

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

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

Я потом пересобрал текст у себя: сам склеил все правки в один файл, отправил заново одним куском и сказал: «Работаем только с этим. Всё, что было раньше, — не существует». И это сработало.

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

Мета-ирония, конечно. Но зато на своём опыте убедился, что это работает именно так, как я описываю.

Что я вынес из этого опыта

Главное, что я вынес из этого опыта: не надо впрямую переносить на ИИ человеческие практики. Agile, MVP, короткие итерации, «атмосфера в команде», настроение, поручения в стиле «додумай сам» — всё это создано для людей. У ИИ другие ограничения, и с ними надо работать иначе.

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

Конкретно для меня это значит:

Меньше итераций. Чем меньше итераций, тем меньше мусора в контексте. Тем точнее промпты. Тем лучше результат.

Точнее и полнее промпты. Прежде чем идти в следующий чат, надо вычитать результат предыдущего и понять, что именно передать. Это дисциплинирует.

Отдельные чаты под каждую тему или цель. Белая книга, ТЗ, разработка, маркетинг — всё отдельно. Не смешивать.

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

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

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

Это не «правильная методология». Это то, что сработало у меня. У кого-то может быть иначе. Но если вы тоже пробовали вайб-кодить, сжигали токены и не могли довести проект до прода, — может быть, дело не в инструменте. Может быть, дело в том, что мы относимся к ИИ как к человеку. А он — не человек.

Что такое токен простыми словами

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

Этот словарь работает примерно как поварская книга, только наоборот: рецепт показывает, из каких ингредиентов собрано блюдо, а словарь токенизатора, позволяет разбирать уже готовый текст на такие же кусочки-ингредиенты и каждому присваивать свой номер. Так суп из слов и знаков препинания превращается в строку чисел, где каждое число обозначает пронумерованный кусочек текста той или иной длины. Как именно происходит такое разбиение на токены и их нумерация, показано в курсе Hugging Face.

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

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

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

Почему один токен не равен одному слову

В документации Hugging Face есть пример для токенизатора модели BERT с идентификатором google-bert/bert-base-uncased. Он разбивает фразу из пяти слов так:

I have a new GPU!
["i", "have", "a", "new", "gp", "##u", "!"]

Получилось семь токенов. Слова I, have, a и new заняли по одному. Сокращение GPU распалось на два, а восклицательный знак стал отдельным токеном. Обозначение ## показывает, что фрагмент продолжает предыдущее слово. Этот токенизатор также переводит буквы в нижний регистр.

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

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

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

Какие токены попадают в запрос и ответ

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

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

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

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

Как токены ограничивают размер контекста

Контекстное окно — это объём текста, с которым модель работает одновременно, пока готовит ответ. В стандартном случае в него входят переданный запрос и генерируемое продолжение. Это ограничение описано в документации Claude. Оно относится к текущему обращению, а не ко всем знаниям, которые модель получила при обучении.

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

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

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

Как посчитать стоимость запроса

В тарифах API обычно отдельно указаны цены входных и выходных токенов, часто за миллион. Число «1 млн» здесь обозначает единицу расчёта. Оно не означает, что для одного короткого запроса нужно израсходовать миллион токенов.

Для обычного текстового запроса без кэширования и дополнительных платных операций расчёт выглядит так:

Стоимость запроса =
    входные токены / 1 000 000 × цена входа
  + выходные токены / 1 000 000 × цена выхода

Посмотрим на конкретный тариф. На 28 сентября 2026 года в карточке deepseek/deepseek-v4-pro-0813 на RouterAI для провайдера Ionstream указаны 34 ₽ за миллион входных и 300 ₽ за миллион выходных токенов. У других провайдеров этой же модели цены могут отличаться, а рублёвые значения меняются вместе с курсом валют.

Допустим, запрос использовал 2 000 входных и 500 оплачиваемых выходных токенов. Это учебный объём для расчёта, а не результат тестирования модели. Без кэширования получится:

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

Кэширование промпта позволяет провайдеру повторно использовать уже обработанную общую часть запросов. Это меняет расчёт стоимости: например, Anthropic применяет разные ставки к записи и чтению кэша. Повторённый текст при этом продолжает занимать место в контекстном окне. Поддержку и условия кэширования нужно проверять у выбранной модели и провайдера.

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

Как проверить, что кэш действительно работает

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

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

Проверяется это не по настройкам, а по ответу API — в статистике должно расти поле чтения кэша. У Claude это cache_read_input_tokens и cache_creation_input_tokens в объекте usage, как описано в документации Anthropic; у других провайдеров поля называются иначе, но смысл тот же. Если это поле стабильно нулевое при повторяющихся запросах, кэш не работает, и вы платите полную цену за один и тот же текст на каждом вызове.

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

Как узнать расход своего запроса

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

После ответа проверяйте статистику API. В примере формата ответа RouterAI для этого используется объект usage. Для учебного объёма из расчёта выше его базовые поля выглядели бы так:

Поле prompt_tokens показывает вход, completion_tokens — выход, total_tokens — их сумму. Для кэширования и рассуждений проверяйте дополнительную детализацию, которую возвращает конкретный провайдер. Умножать total_tokens на одну ставку нельзя, если вход и выход стоят по-разному.

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

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

Как сократить расход без потери нужного контекста

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

• Передавайте нужный фрагмент материала. Для объяснения одной ошибки приложите связанный с ней код и достаточное окружение. Весь репозиторий может содержать много файлов, которые не влияют на проблему.
• Управляйте историей диалога. Не передавайте её целиком в каждый новый запрос — резюмируйте закрытые темы и оставляйте дословно только то, что ещё понадобится.
• Задавайте формат результата. Если приложению нужны название ошибки и способ исправления, перечислите эти поля. Тогда у модели будет меньше причин добавлять длинное вступление и общий обзор темы.
• Ограничивайте генерацию параметром API. В RouterAI для этого описаны max_tokens и max_completion_tokens. Выбирайте параметр, который поддерживает ваша модель. Слишком низкий предел может оборвать полезный ответ; сам предел не обязывает модель заполнить его целиком.
• Проверяйте результат сокращений. Прогоните изменённый запрос на характерных задачах и сравните расход вместе с качеством ответа. Если после удаления контекста приходится повторять запрос с уточнениями, экономия может исчезнуть.
• Проверяйте кэш по факту, а не по настройке. Включённый в коде кэш ничего не гарантирует — ориентируйтесь на поле чтения кэша в статистике запроса.

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

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

Начну моё эссе с рассказа о себе.

Как я сам использую ИИ?

Точечно.

Я начальник управления малого бизнеса в Чеченской Республике. Ввиду специфики моей должности я не могу использовать нейросети для всех задач, а делаю это выборочно: переписать деловое письмо, сделать анализ финансовой деятельности клиента, перевести данные из скана в Word, а потом заменить данные на другие, сделать краткую выжимку отчёта, подготовить презентацию или понять, что мой собеседник имел ввиду. По поводу последнего: иногда задача, которую я должен выполнить, описана формальным языком, изобилует аббревиатурами и сложными терминами. Но попросить уточнить бывает неудобно и тогда спасает Gemini: расшифрует, объяснит, уточнит.

В работе мне часто требуется подготовить Google-таблицу, заполнить данными, вписать обозначения. Я умею это делать, но не так хорошо, как хотелось бы. Тогда я фотографирую таблицу, которая подходит под мои задачи (референс) и отправляю запрос. Нейросеть мне всё объясняет по шагам: куда зайти, что нажать, что добавить. Я спокоен.

Регулярно возникает задача сделать сводный файл (без клиентских данных, разумеется) из 5-6 разных таблиц по 5 республикам. Формулы — не моя сильная сторона, и вручную эта работа займет больше, чем я могу себе позволить. Но я загружаю файлы в Claude, описываю задачу вида «Объедини файлы, чтобы строки не слетали, чтобы столбцы соответствовали друг другу» и, вуаля, через 5 минут у меня есть единый файл.

Свежий пример, когда я использовал ИИ, — подготовка стратегии на 2027-2029 года. Когда её готовил, использовал нейросети, к примеру, задал вопрос о том, сколько юридических лиц в Республике Ингушетия и в Республике Чечня. Это можно было бы сделать зайдя на официальный сайт ФНС. Но ответ нейросети я получил почти мгновенно, по сравнению с тем, сколько бы времени потратил, изучая официальные документы. И ответ был достоверен на 100%.

Если говорить про конкретные модели, то я использую Claude. Он мне нравится тем, что подготовит Word-документ под любую задачу и отправит в готовом формате. Chat GPT с теми же задачами периодически не справляется. Иногда применяю Perplexity, для изображений в презентациях — Nano Banana 2, а из «быстрых» моделей — Google Gemini. Также пробовал внутреннюю платформу банка Альфа-Ген и создал два инструмента. Первый — скриптор, — формулирует скрипты продаж. Второй выдает экспертную оценку деятельности клиента по 115 ФЗ. Для меня это был полезный опыт, мне понравилось.

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

Задач, для которых я использую ИИ, в работе не много. Но, как правило, они трудоёмкие и, благодаря дарам технологического прогресса, я экономлю 3-4 рабочих дня в месяц.

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

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

• В подписках в одной из соцсети смотрю ролики преподавателя английского языка из Чечни. Часто вижу, как он работает в платной версии ЧатGPT.
• Диетологи и тренеры повсеместно имеют подписки на ИИ и активно используют. Буквально несколько дней назад я стал участником одного обсуждения: я, фитнес-тренер и ещё один человек стоим в зале и спорим о том, насколько часто можно есть баранину, если ты худеешь. Слева я слышу, что нельзя категорически, справа, что можно раз в неделю, а спортивный блогер, ролик которого мы в этот момент смотрим в качестве источника истины, утверждает, что можно и каждый день. Тогда мы спрашиваем у ИИ и получаем ответ, основанный на научных данных, что для диеты баранину можно есть не больше двух раз в неделю. Баранина является диетическим продуктом, но помешает похудеть за счёт некоторых нюансов (дословно не повторю ответ, да это и не нужно). Оказалось, что блогер был неправ.
• Проходя по улице слышу, как несколько незнакомых человек обсуждают, что Claude лучше ЧатGPT и как его оплатить (в текущей ситуации).
• Молодежь сплошь и рядом использует ИИ для поиска ответов, решения домашней работы, курсовых.
• Об ИИ говорят в Правительстве, в университетах, школах, в детсадах и на кухнях.

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

Как я это вижу? К примеру, прямо в маску сварщика можно встроить камеру с компьютерным зрением. ИИ в режиме реального времени будет подсказывать какую величину тока задать и какой наклона электрода соблюдать. У электриков ИИ может быть интегрирован в отдельные устройства или даже в очки дополненной реальности. Мастер направляет взгляд на стену, а ИИ, в который уже загружены строительные чертежи, данные тепловизора и прочие данные, накладывает схему проводки на поверхность, а в процессе ассистент подсказывает, где проверить изоляцию. Если очки слишком футуристично (хотя это уже данность), то можно ИИ встроить в телефон. К примеру, у сантехников будет свой ИИ в телефоне: достаточно навести камеру на старый узел труб в подвале и спец-ИИ построит 3D-модель, найдет скрытые микротрещины и места коррозии, которые незаметны глазу.

Звучит фантастично? Но это уже частично реальность. Недавно узнал, что с 2021 по 2024 год российские компании ТЭК увеличили использование ИИ на 29%. Чат-ботов для приема обращений потребителей не будем рассматривать, — это уже норма, но и без этого интересно то, что ИИ уже выявляет скрытые дефекты оборудования, анализируя массивы данных с умных датчиков; фиксирует повреждения на изоляторах или провисшие провода; прогнозирует потребление электроэнергии предприятий, рассчитывая цифры по массивам данных о погоде, потребительских привычках и колебаниях спроса.

Это уже не фантастика.

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

Сейчас в ИТ есть свои рабочие инструменты: ПО для ревью кода, IDE, ПО для подготовки документации, диаграмм, тестов, деплоя, системы контроля версий, библиотеки и многое другое. На каждое действие свой инструмент, своя автоматизация. Если какое-то действие повторяется 2 раза — вы его автоматизируете. К ним добавился вайб-кодинг и десяток (или десятки?) моделей, заточенных на то, чтобы писать код, спецификации, тестировать и писать отчёты.

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

Возможно, что это чуть-чуть сделает Банк? Глобально Альфа-Банк понимает, что мне, как сотруднику, нужно, а внутри уже есть платформа, где можно сделать любого агента. Для каждой нашей роли создадут отдельные матрицы ролей с доступом к специализированному искусственному интеллекту и завернут это всё в оболочку. И я думаю, что это будет интересно многим. Например, я недавно присутствовал на событии, где коллеги демонстрировали, как они создавали разные промпты под разные задачи. Там было 415 человек. И это лишь одно мероприятие из многих.

Многие, как и я, понимают, что…

Нет иного выбора, кроме как принять технологию

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

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

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

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

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

Развитие технологий — это вопрос выживания.

Китай выучил урок и то, на что у других стран уходили десятилетия, в Китае уместилось в поколение — к примеру, с 1991 по 2001 год региональный ВВП дельты Жемчужной реки вырос почти в восемь раз. Это всё случилось благодаря тому, что на юге Китая (рядом с Гонконгом и Макао) были созданы Особые экономические зоны (ОЭЗ) с налоговыми льготами. Туда хлынули инвестиции и за 10 лет с 1991 года ВВП региона вырос в 8 раз, население удвоилось, открылись десятки тысяч фабрик, а бывший аграрный край («земля рыбы и риса») превратился в главный промышленный узел планеты.

Особые экономические зоны создавались для индустриального рывка — привлечения иностранных инвестиций, строительства фабрик, логистики и физического производства товаров. Когда этот фундамент «мировой фабрики» был построен, он запустил колоссальный внутренний рынок и породил огромный спрос на ИТ-инфраструктуру. Вслед за этим были рождены ИТ-гиганты — Baidu, Alibaba, Tencent). Непосредственно в Особой экономической зоне была основана только одна компания. Остальные две появились в регионах, которые развивались параллельно благодаря общему экономическому буму в стране.

Они были основаны с 1998 по 2000 год, а к концу 2000 года число интернет-пользователей в Китае выросло с 3000 в начале 1995 года до 22,5 миллиона. В 2001 году Китай вступил во Всемирную торговую организацию. В стране начался бум урбанизации, число частных автомобилей выросло в 10 раз, и сформировался многомиллионный средний класс, начавший активно тратить деньги на путешествия, качественную еду и гаджеты.

Еще недавно в Китае варили чугун в уличных печах, а сейчас страна — технологический лидер. Так что в Китае ИИ воспринимается за благо, за новый технологический стероид, и внедряется очень активно. По мнению аналитиков, эта культура технооптимизма может и будет способствовать распространению и масштабному внедрению искусственного интеллекта, и в Китае скоро буквально все будут использовать ИИ. Ведь по данным отчёта Стэнфордского университета об индексе развития искусственного интеллекта за 2026 год, 85% китайских респондентов считают, что ИИ приносит больше пользы, чем вреда, а домохозяйки, пенсионеры, студенты и инженеры стоят в очереди, чтобы им установили на ПК OpenClaw (Clawdbot/Moltbot).

Поэтому Китай снова будет впереди планеты в технологическом плане.

Как я к этому пришёл?

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

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

Когда в первый раз я увидел такой инструмент, то он был не в лучшей своей форме. Как вы помните, это были сырые чат-боты, а генераторы видео могли создавать только странные смазанные видео с Уиллом Смитом, которые снятся при температуре 39. И я даже не мог придумать, а что у него спросить? Мой мозг ещё не понимал, что происходит, не осознавал, насколько этот инструмент серьезный. Поэтому я мог придумать только что-то вроде «Сколько тонн в одной ванной» или посмотреть как он решит какую-то математическую формулу — банальные вопросы.

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

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

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

С ИИ также. Он очень коварен.

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

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

Выше я поделился изречением Альтмана, но сейчас я бы его дополнил так: с текущей даты (в 2025) не родится человек, который не будет знать, каково это жить без искусственного интеллекта. Уже сейчас подавляющая часть молодежи с ИИ на «Ты». К примеру, в Англии, согласно свежему опросу за 2026 год, в котором приняли участие более 4000 человек в возрасте от 11 до 24 лет, почти 90% молодых людей уже использовали ИИ, а половина чаще доверяют ИИ, чем человеку.

В США, по данным Common Sense Media (июнь 2026 года) 86% детей и подростков в возрасте от 9 до 17 лет регулярно используют ИИ или взаимодействуют с ним, а среди старшеклассников (16–17 лет) эта цифра уже 92%, причем 30% используют ИИ ежедневно.

В Европе, в среднем, по данным Eurostat, 60–64% молодежи активно используют генеративный ИИ. Для сравнения, среди взрослого населения этот показатель в два раза ниже.

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

В Тайване в июне этого года вышло исследование в Taipei Times, где сказано, что «92% детей в возрасте от шести до 15 лет используют искусственный интеллект». А по остальному Китаю уже были данные выше.

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

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

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

Среда возьмет своё. Это так работает.

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

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

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

И вот, что ещё интересно.

Недавно появился глобальный доклад UNICEF Innocenti (июнь 2026). Не считая того, что в докладе поделились цифрами, которые показывают беспрецедентную скорость внедрения нейросетей в жизнь подрастающего поколения, эксперты ООН открыто заявили о формировании нового типа неравенства — AI Divide (ИИ-разрыв). Он заключается в том, что дети образованных и обеспеченных родителей используют ИИ как мощный инструмент для развития и буста карьеры. В это время дети из бедных семей или бедных стран используют его для развлечения или не имеют к нему доступа вообще. В будущем это создаст огромный разрыв в уровне квалификации на рынке труда.

А где мы хотим оказаться? На какой стороне? На стороне империи поздней династии Цин или на стороне технологичного мира 21-го века?

Чтобы оказаться на «той самой стороне», другого выбора, кроме как принять технологию, нет.

Главный вывод недели: цена за миллион токенов больше не говорит, во что обойдётся задача. Astra стоит за токен в 2,5 раза дороже GPT-5.6 Sol, но по замеру Artificial Analysis в агентном кодинге тратит на задачу втрое меньше токенов и в итоге выходит примерно в ту же сумму; на общих задачах экономия токенов всего 10%. Fable 5.1 сохранила цены Fable 5, но чтение кэша подешевело в 4 раза, и Anthropic оценивает экономию для агентных задач до 45%. Поэтому в этом обзоре у каждой модели рядом с ценой за токен стоит цена за задачу, если её кто-то мерил. Августовские релизы разобраны в прошлом обзоре, здесь они не повторяются.

• Claude Fable 5.1 и Mythos 5.1 — одна модель с разными ограничителями. Цена $10/$50 за миллион токенов, чтение кэша $0,25 вместо $1. По оценке Anthropic это минус около 25% к счёту на типичных задачах и до 45% на агентных.
• GPT-6 Astra стоит те же $10/$50. На Terminal-Bench 4.0 по замеру OpenAI она набирает 57,9% против 55,8% у Fable 5.1 при цене задачи на 63% ниже. В индексе Artificial Analysis v4.3 обе модели делят первое место с 53 баллами, но задача у Astra стоит $3,26 против $7,63 у Fable 5.1.
• Уровень рассуждений стал главным рычагом цены: у Fable 5.1 шаг с xhigh до max даёт полбалла на Humanity's Last Exam за 46% цены сверху, у Astra уровень max удваивает стоимость на коде без прироста точности.
• Дешёвый сегмент: Gemini 3.8 Flash $0,75/$3,75 до конца года, Muse Spark 1.3 $1,25/$4,25 и $0,55 за задачу индекса, Mercury 2.5 $0,20/$0,75 при заявленных 1107 токенах в секунду, DeepSeek V4 Flash $0,22/$0,66 в непиковые часы.
• MAI-Transcribe-2 стоит $0,10 за час аудио до конца года при WER 5,2% на FLEURS по замеру Microsoft. GPT-Transcribe от OpenAI стоит $0,27 за час.
• Автономность пока не продаётся: в эксперименте Bottleneck Labs семь моделей за 72 часа и $300 каждая заработали $0 и отправили 2797 писем.

Чем Fable 5.1 отличается от Astra, если цена у них одинаковая?

Разница в том, за что вы платите: Fable 5.1 берёт качеством на широком наборе задач и дешёвым кэшем, Astra экономит токены в агентном коде. Anthropic выпустила Claude Fable 5.1 и Claude Mythos 5.1 как одну модель с разными уровнями ограничителей: Fable доступна всем, Mythos только через программы проверенного доступа для кибербезопасности и биологии. В API модель называется claude-fable-5-1, есть на Amazon Web Services, Google Cloud и Microsoft Azure. Цены прежние, $10 и $50 за миллион токенов, но чтение кэша подешевело на 75%, до $0,25 за миллион. Anthropic посчитала по четырём неделям реального использования в августе, что типичная нагрузка станет дешевле примерно на 25%, а агентная, где кэш составляет большую часть счёта, до 45%. Это оценка вендора.

По бенчмаркам самой Anthropic модель обошла Opus 5 и GPT-5.6 Sol, а на низком и среднем усилии даёт результат Fable 5 дешевле. У кибер-фильтров на 60% меньше ложных срабатываний: искать уязвимости в коде теперь можно, разработка эксплойтов запрещена. В Claude Code по умолчанию уровень high.

We're moving our Opus 5 traffic in Devin to Claude Fable 5.1 on launch day. It matched or edged out Fable 5 in our testing at a lower cost per task, and with the new cache read pricing a Fable-class model is finally economical for the workloads we'd kept on Opus, starting with code review.

OpenAI начала раскатку GPT-6 Astra 3 сентября: сначала ограниченному кругу организаций, затем всем на Plus, Pro, Business и Enterprise, в API под именем gpt-6-astra, а также в Microsoft Azure и Amazon Bedrock. Стандартная цена $10 за миллион входных и $50 за миллион выходных токенов, быстрый режим даёт до 2 раз больше скорости за двойную цену. По замеру OpenAI на Terminal-Bench 4.0 Astra набирает 57,9% против 55,8% у Fable 5.1 и 37,3% у Sol, при этом задача по оценке OpenAI обходится на 63% дешевле, чем у Fable 5.1, и на 9% дешевле, чем у Sol. На Humanity's Last Exam и в общем индексе Artificial Analysis она ниже Fable 5.1 и Opus 5. Подробный разбор цен, бенчмарков и кибер-ограничений Astra есть в отдельной новости.

Независимая лаборатория Artificial Analysis разобрала Astra и увидела две разные истории. В Coding Agent Index Astra в Codex набирает 67 баллов, столько же, сколько Opus 5 и Fable 5 в Claude Code, при цене задачи меньше половины от Fable 5. Лидер индекса Fable 5.1 в Claude Code с 70 баллами. Экономия идёт от токенов: Astra тратит на задачу треть от Sol на уровне max и пятую часть от Opus 5 на xhigh. В общем индексе интеллекта картина хуже: токенов уходит всего на 10% меньше, чем у Sol, при том же балле, поэтому после подорожания в 2,5 раза задача стоит на 75% дороже. Галлюцинаций на AA-Omniscience вдвое меньше: 51% против 92% у Sol.

In the Artificial Analysis Coding Agent Index, GPT-6 Astra equals Fable 5 at less than half the cost, driven by significant token efficiency gains. In the Artificial Analysis Intelligence Index, GPT-6 Astra is more token efficient than its predecessor for similar performance, but this is offset by the price increase.

7 сентября Artificial Analysis обновила индекс до версии 4.3: Terminal-Bench поднят до 4.0, банковский Tau3-Banking заменён на AutomationBench от Zapier. По данным сайта лаборатории, Fable 5.1 и Astra на уровне max делят первое место с 53 баллами, Opus 5 набирает 51, Muse Spark 1.3 48, GLM-5.3 45, Grok 4.6 и Kimi K3 по 44, Gemini 3.8 Flash 41. Цена задачи индекса при этом $7,63 у Fable 5.1, $3,26 у Astra, $5,86 у Opus 5, $1,60 у Muse Spark 1.3 и $1,24 у Gemini 3.8 Flash.

Какой уровень рассуждений ставить, чтобы не переплатить?

Короткий ответ: у обеих флагманских моделей верхняя ступень почти не добавляет качества, а цену поднимает заметно, поэтому начинать стоит с low или medium и подниматься по результатам своей оценки. У Fable 5.1 пять уровней, по умолчанию high. Anthropic в разборе экономии приводит две цифры: на Humanity's Last Exam шаг с xhigh до max прибавляет около половины балла за 46% цены сверху, а на CursorBench 3.2 Fable 5.1 на low повторяет результат Fable 5 на high втрое дешевле. Команды Claude Code, которые ищут экономию сами (/claude-api prompt-audit, hillclimb, cost-optimize), мы разбирали отдельно.

Уровень задаётся параметром output_config.effort, пример из документации Anthropic (в примере модель Opus 5, для Fable 5.1 подставьте claude-fable-5-1). Документация отдельно отмечает, что Fable 5.1 умеет менять effort посреди диалога без сброса кэша промптов.

У Astra уровни задаются через reasoning.effort в Responses API. По документации OpenAI значение none для GPT-6 Astra не поддерживается и возвращает HTTP 400, а вызов функций работает только в Responses API, не в Chat Completions.

Однозначного оптимума у Astra нет. По опыту редакции Tproger на общих вопросах уровень выше high не окупается: цена растёт, точность нет. В коде по Coding Agent Index разумно выглядят low, medium и xhigh, а max удваивает стоимость без надёжного прироста. Рабочая схема: low по умолчанию, для сложных подзадач агент вызывает модель на более высоком уровне. Astra цепляется за формулировки, неточный промпт меняет результат сильнее, чем у прежних моделей; чеклист чистки инструкций под неё есть в отдельной статье.

Что взять, если бюджет считается в центах?

Четыре модели закрывают этот сегмент по-разному: Gemini 3.8 Flash сильнее всех в агентном коде, Muse Spark 1.3 дешевле всех за задачу на уровне Sol, Mercury 2.5 быстрее всех, DeepSeek V4.1 Flash пока бета. Google выпустила Gemini 3.8 Flash 3 сентября по вводной цене $0,75 за миллион входных и $3,75 за миллион выходных токенов; с 1 января 2027 года будет $1,50 и $7,50. Контекст миллион токенов, на OpenRouter у Flex-провайдеров вдвое дешевле. По замеру Google на DeepSWE v1.1, где модель сама доводит инженерную задачу до конца, 3.8 Flash обходит большинство более крупных моделей, на HLE-Verified набирает 54,9%. Google предупреждает: токенов на сложной задаче уйдёт больше, особенно на высоком уровне усилия, и советует понижать уровень или оставаться на 3.7 Flash.

These performance gains stem from a core design choice: 3.8 Flash works harder. On complex tasks, it exhibits greater diligence — executing extra reasoning steps, and calling tools iteratively. At times, the model might use more tokens to maximize performance, especially at higher effort levels.

Уровень рассуждений у Gemini задаётся параметром thinking_level, у 3.8 Flash доступны low, medium и high, по умолчанию medium. Пример из документации Gemini API:

Muse Spark 1.3 от лаборатории суперинтеллекта Александра Вана вышла 2 сентября в Muse Code и в API. Цены не менялись: $1,25 за миллион входных и $4,25 за миллион выходных токенов, попадание в кэш $0,15. По замеру Artificial Analysis открытая всем версия xhigh набрала 61 балл индекса v4.2, вровень с GPT-5.6 Sol и Grok 4.6, при цене $0,55 за задачу индекса против $0,95 у Sol и $0,94 у Grok. Рост почти весь в агентных задачах: банковский Tau3-Bench вырос с 35% до 47%. Просели длинный контекст и AA-Omniscience, где модель чаще отказывается отвечать. Входных токенов на задачу стало больше, поэтому цена задачи выросла с $0,40 у версии 1.2.

Inception выпустила Mercury 2.5, диффузионную модель, которая пишет текст блоками параллельно. Заявлено 1107 токенов в секунду на обычных NVIDIA GPU, контекст 260 тыс. токенов, уровень GPT-5.6 Luna на низком усилии и Claude Haiku 4.5. Цена $0,20 за миллион входных и $0,75 за миллион выходных токенов, на старте скидка 80% до $0,04 и $0,15, новым аккаунтам дают 100 млн токенов; модель есть в API Inception, на OpenRouter и Baseten. Независимых замеров Mercury 2.5 пока нет, все цифры вендора. Из кейсов в анонсе: Augment Code перевела на Mercury сжатие контекста, сжатие ускорилось со 150 секунд до 27 при снижении цены на 90%.

After we switched to Mercury, our P99 response time dropped from several minutes to just one second, and our P50 dropped from 0.4 seconds to under 0.2 — significantly faster than any other provider we've seen, and that's including reasoning.

DeepSeek 8 сентября открыла бету V4.1 Flash на два дня: модель deepseek-v4.1-flash-expires-on-0910 живёт в API до 10 сентября с лимитом 20 параллельных запросов. Цена как у V4 Flash: по прайс-листу $0,22 за миллион входных токенов при промахе кэша, $0,007 при попадании и $0,66 за миллион выходных в непиковые часы; в пиковые вдвое дороже, $0,44 и $1,32. Официальных бенчмарков нет. Тестеры намерили 400–500 токенов в секунду, а китайский XSCT Bench поставил V4.1 Flash выше V4 Flash, Gemini 3.8 Flash и Qwen3.8 Flash почти везде.

Qwen 2 сентября обновила закрытую Qwen3.8-Max до снапшота 0902: те же 2,4 трлн параметров, миллион контекста, режим размышлений, дообучение на кодинг и совместную агентную работу. По словам Qwen, прирост в основном в коде и агентных правках репозиториев, до Opus 5 в терминале ещё далеко. Цена в QwenCloud $2 за миллион входных и $6 за миллион выходных токенов, чтение кэша $0,17.

Что нового в картинках и распознавании речи?

Две картиночные модели без бенчмарков и одна речевая с рекордом на FLEURS. OpenAI выпустила ChatGPT Images 2.5: в API две модели, GPT-Image-2.5 Flare по умолчанию с вдвое меньшей задержкой, чем у GPT-Image-2, и Sunburst для точных правок. Цена у обеих $8 за миллион входных токенов картинки, $30 за выходные и $5 за текст на входе. Бенчмарков в анонсе нет, только примеры.

Microsoft AI выпустила MAI-Image-2.6-Flash и вывела MAI-Image-2.6 из закрытого превью в Microsoft Foundry. По заявлению Microsoft, Flash рисует в 2,8 раза быстрее GPT-Image-2-Medium при сопоставимом качестве; старшая модель на Arena вторая в генерации и редактировании, у Artificial Analysis вторая в генерации и первая в редактировании.

MAI-Transcribe-2 Microsoft выпустила 3 сентября: 60 языков с автоопределением, разделение говорящих, таймкоды на каждое слово, режимы verbatim и clean, подсказка терминов. По замеру Microsoft модель первая на мультиязычном FLEURS со средним WER 5,2%, у Artificial Analysis вторая по точности. Цена $0,10 за час аудио как акция до конца года, GPT-Transcribe от OpenAI стоит $0,27 за час. На OpenRouter модель лежит под именем microsoft/mai-transcribe-2, ещё есть в Microsoft Foundry и MAI Playground.

Какую модель брать под какую задачу в сентябре 2026 года?

Ниже сводка по задачам с ценами на 9 сентября. Все цены из прайс-листов вендоров, цены задач из замеров Artificial Analysis и вендоров, как указано.

• Агентный кодинг в большой кодовой базе. GPT-6 Astra на low или medium: 67 баллов Coding Agent Index при цене задачи меньше половины от Fable 5 (Artificial Analysis). Если важен максимум качества, Fable 5.1 в Claude Code с 70 баллами, но задача почти вдвое дороже.
• Массовые дешёвые задачи с агентами. Gemini 3.8 Flash на low: $0,75/$3,75 до конца года, $1,24 за задачу индекса v4.3. Muse Spark 1.3 на xhigh, если нужен уровень Sol за $0,55 за задачу (AA, v4.2).
• Голосовые агенты и всё, где важна задержка. Mercury 2.5: $0,20/$0,75, заявленные 1107 токенов в секунду и медиана ответа около 170 мс у OpenCall. Независимых замеров нет, проверяйте на своём трафике: новым аккаунтам дают 100 млн токенов.
• Сжатие контекста и маршрутизация внутри агента. Mercury 2.5 по кейсу Augment Code или DeepSeek V4 Flash за $0,22/$0,66 в непиковые часы.
• Транскрибация. MAI-Transcribe-2 за $0,10 в час до конца года против $0,27 у GPT-Transcribe.
• Картинки. GPT-Image-2.5 Flare для скорости, Sunburst для правок, $8/$30 за миллион токенов картинки.
• Длинный контекст. Qwen3.8-Max-0902 или Gemini 3.8 Flash с миллионом токенов; у Astra и Muse Spark 1.3 длинный контекст по замерам Artificial Analysis просел.

Порядок действий, чтобы перейти на новые модели без сюрпризов в счёте:

1. Замените идентификатор модели: claude-fable-5-1 в Claude API, gpt-6-astra в Responses API, gemini-3.8-flash в Gemini API. У Astra уберите reasoning.effort: none, иначе получите HTTP 400.
2. Поставьте низкий уровень усилия (output_config.effort: low, reasoning.effort: low, thinking_level: low) и прогоните свою оценку; поднимайте уровень только там, где балл растёт.
3. Проверьте долю попаданий в кэш: у Fable 5.1 чтение кэша стоит $0,25, и смена effort посреди диалога кэш не сбрасывает, у остальных моделей сброс возможен.
4. Для агентов с инструментами на Astra заложите обработку остановки: внешний мониторинг OpenAI может прервать задачу, и через API диалог не возобновить.
5. Сравнивайте цену задачи вместо цены токена: считайте токены на задачу из поля usage в ответе API и умножайте на прайс.

Почему автономный агент на новых моделях всё ещё нельзя оставлять без присмотра?

Потому что фильтры вендоров останавливают работу, а сами модели делают лишнее. OpenAI признаёт, что Astra достигла критического уровня в кибербезопасности по её Preparedness Framework: в тестах модель сама нашла и использовала две уязвимости нулевого дня. Поэтому на вызовы с инструментами в Codex, ChatGPT и Responses API включён внешний мониторинг.

Extra safety checks can sometimes slow, pause, or stop legitimate work, including defensive cybersecurity. If a task is paused in ChatGPT or Codex, you may be asked to review the action before continuing. In the API, the task will stop.

Вторая причина показана в эксперименте Bottleneck Labs, которая дала семи моделям по $300, Mac mini, почту, Stripe и 72 часа с промптом «заработай как можно больше денег». Итог по всем семи: 2797 писем, 11 живых посетителей, выручка $0, около $2800 на токены. Qwen 3.8 открыла сервис аудита GitHub-репозиториев, упёрлась в лимиты почты и выставила через Stripe 50 счетов незнакомым людям за незаказанную работу на $12 350, сочтя это допустимым шагом продаж. Это один эксперимент одной компании, но подтверждение человеком на платёжных действиях он делает обязательным.

Попробовать можно без денег: Inception даёт 100 млн токенов Mercury 2.5 новым аккаунтам, а Z.ai до 20 сентября держит ночной Global Build с бесплатной GLM-5.3-Flash для подписчиков Coding Plan. Цену решённой задачи у GLM-5.3, Sol и других мы считали отдельно. Следующая проверка — когда OpenAI закончит раскатку Astra и Artificial Analysis добавит в индекс v4.3 Mercury 2.5 и DeepSeek V4.1 Flash.

Источники: Anthropic: Introducing Claude Fable 5.1 and Claude Mythos 5.1, Claude Platform Docs: Effort, Claude Blog: Reducing cost and improving performance with Claude Platform, OpenAI: Introducing GPT-6 Astra, OpenAI Docs: Reasoning models, OpenAI: Introducing ChatGPT Images 2.5, Artificial Analysis: разбор GPT-6 Astra, Artificial Analysis: замер Muse Spark 1.3, Artificial Analysis: Intelligence Index v4.3, Artificial Analysis: главная страница индекса, Google: Gemini 3.8 Flash and 3.8 Flash Cyber, Gemini API Docs: Thinking, Inception: Introducing Mercury 2.5, QwenCloud: Qwen3.8-Max-0902, Alibaba Qwen: анонс Qwen3.8-Max-0902, DeepSeek API Docs: Pricing, IT之家: бета DeepSeek V4.1 Flash, Microsoft AI: MAI-Transcribe-2, Microsoft AI: MAI-Image-2.6, Bottleneck Labs: Benchmarking 7 autonomous businesses

Этот обзор продолжает августовский разбор открытых моделей. В сентябре главный сдвиг в том, что для каждого объёма памяти, от часов до двух серверных узлов, есть свежая модель, а независимый замер Quesma показал: 4-битный квант Qwen3.8-27B в 17 ГБ на трёх бенчмарках неотличим от полной версии в 55 ГБ. У каждой модели ниже три вещи: для каких задач, какие цифры и чей замер, как запустить.

• Nex-N2.5-Max: 1,6 трлн параметров, MoE, контекст 262 тыс. токенов, Apache 2.0. По таблице самой Nex-AGI на AutomationBench 50,2 против 50,3 у Opus 5, на SWE-Bench Pro 65,7 против 79,2. Запуск: два узла по восемь H200.
• K2 Horizon от MBZUAI: шесть моделей 0,9–375 млрд параметров, Apache 2.0, обещаны чекпоинты, данные, код и логи обучения. Модель 36B-A4B с 4 млрд активных на Terminal-Bench 2.1 набирает 58,6 против 53,9 у Nemotron 3 Ultra на 550 млрд (замер IFM).
• MiniCPM5-2B: 2,5 млрд параметров, индекс Artificial Analysis v4.2 равен 15, столько же у Qwen3.5 9B вчетверо большего размера. Тратит 19 тыс. токенов на задачу индекса против 56 тыс. у Ling 3.0 Tiny.
• Quesma потратила $3000 на GPU и не нашла измеримой разницы между BF16 в 55 ГБ и Q4_K_M в 17 ГБ у Qwen3.8-27B на GPQA Diamond, IFBench и Terminal-Bench 2.1. 1-битные кванты отвечают на уровне случайного угадывания.
• GLM-5.3-Flash в llama.cpp стала быстрее до 3,3 раза на длинном контексте после доработки Unsloth; на 65 тыс. токенов скорость выросла с 20,7 до 49,0 токенов в секунду ещё без MTP. Требования прежние: 100 ГБ для 1-битного кванта, 128 ГБ для 3-битного.
• llama.cpp 0.4.0 добавила ленивое чтение тензоров --lazy-mode, потолок памяти квантизатора и разреженное flash attention для DeepSeek-V4, GLM и Qwen3.8-Flash-Next.

Что вышло крупного и кому это по силам запустить?

Три больших релиза недели: Nex-N2.5 на 1,6 трлн параметров, семейство K2 Horizon и обновление Hy4, которое до открытых весов не дошло. Дома реально запускается только младшая K2 Horizon и, с натяжкой, Nex-N2.5-mini на двух H100.

Nex-AGI выложила Nex-N2.5, следующее поколение агентных моделей после июньской Nex-N2, в трёх размерах: mini, Pro и Max. Max это текстовая MoE-модель на 1,6 трлн параметров, первый у компании пост-трейнинг триллионного масштаба. Все три под Apache 2.0, контекст 262 144 токена. По таблице в карточке модели, замер вендора, Max сильна в агентных задачах: AutomationBench 50,2 против 50,3 у Claude Opus 5, BrowseComp 92,6 против 90,8 у Opus 5. В коде отстаёт: SWE-Bench Pro 65,7 против 79,2 у Opus 5. Чужие цифры Nex-AGI берёт из отчётов вендоров, так что таблица сравнивает разные харнесы.

Vision is therefore no longer merely an input modality; it has become a critical interface through which an agent perceives its environment, verifies outcomes, and moves a task forward.

Порог входа высокий. В репозитории Max запускается через форк SGLang в Docker на двух узлах по восемь H200, Pro на восьми H100, mini на двух H100. Mini и Pro есть на OpenRouter под именами nex-agi/nex-n2.5-mini и nex-agi/nex-n2.5-pro. Веса Pro в карточке только анонсированы, считать её открытой рано.

Институт фундаментальных моделей MBZUAI (IFM) 3 сентября выпустил K2 Horizon, шесть моделей под Apache 2.0: 375B-A23B для серверов, плотная 32B и разреженная 36B-A4B для рабочих станций, 7B и 3.7B для телефонов, 0.9B для часов и очков. Каждая обучена примерно на 20 трлн токенов. Главное обещание IFM: открыть для каждой модели весь путь, от промежуточных чекпоинтов и данных или рецептов их сборки до кода, конфигов и логов обучения вплоть до агентного пост-трейна.

A final checkpoint shows what a model can do. Horizon's complete training record helps reveal how it learned to do it.

Самая интересная из шести для локального железа это K2-Horizon-MoVA-36B-A4B: 36 млрд параметров, около 4 млрд активных на токен, контекст 524 288 токенов. Разреженность применена не только к полносвязным слоям, как в обычном MoE, но и к вниманию: механизм MoVA (Mixture-of-Value Attention) маршрутизирует экспертов внутри multi-head attention. По таблице IFM, где базовые значения взяты у Artificial Analysis, на τ³-Banking она набирает 26,8 против 14,2 у Nemotron 3 Ultra на 550 млрд, на Terminal-Bench 2.1 58,6 против 53,9, а отстаёт на Humanity's Last Exam и на длинном контексте AA-LCR. Запуск из README:

Про Hy4 от Tencent важно не перепутать. Компания 7 сентября сообщила, что подкрутила preview-версию: модель думала дольше нужного. Цифр нет, обновление уже работает в сервисах Tencent вроде WorkBuddy, а веса на Hugging Face не менялись с 28 августа.

Что поместится на одну видеокарту или в ноутбук?

Четыре свежие модели (Granite 4.2 8B вышла 31 августа) рассчитаны на 4–24 ГБ памяти: MiniCPM5-2B для агентов на ноутбуке, Spark-X2.5-4B для длинного контекста, младшие K2 Horizon для телефонов и Granite 4.2 8B для дешёвых массовых запросов. Ни одна не заменит большую модель в знаниях, и это видно по бенчмаркам.

OpenBMB выложила MiniCPM5-2B, плотную модель на 2,5 млрд параметров под Apache 2.0, контекст 131 тыс. токенов, с вызовом инструментов и рассуждениями. По независимому замеру Artificial Analysis она набирает 15 баллов индекса v4.2, лучший результат среди открытых моделей до 4 млрд: на 4 балла выше Granite 4.2 3B и вровень с Qwen3.5 9B вчетверо большего размера. Сильная сторона агентные задачи: GDPval-AA v2 831 против 718 у Ling 3.0 Tiny, τ³-Banking 21%. Слабые места знания и терминал: Terminal-Bench 2.1 9% против 29% у Qwen3.5 9B. Зато токенов на задачу индекса уходит 19 тыс. против 56 тыс. у Ling 3.0 Tiny, а для ноутбука это и есть скорость ответа.

As a dense model, its size advantage is in memory footprint rather than active-parameter compute.

Под капотом, по README, три стадии пост-трейна: SFT на 400 млрд токенов, RL по доменам и дистилляция 16 экспертных RL-моделей, из них 5 агентных, обратно в одну модель. Запуск через vLLM по README:

Spark-X2.5-4B решает другую задачу: агент со сверхдлинным контекстом на слабом железе. Модель на 4 млрд параметров держит 1 млн токенов, потому что на каждый слой с полным вниманием приходится три со скользящим окном, и кэш растёт медленнее. Обучена примерно на 20 трлн токенов на кластерах Huawei Ascend, поддерживает больше 200 языков, лицензия Apache 2.0. По таблице в карточке модели (замер вендора) на τ³-bench она набирает 30,4 против 9,3 у Qwen3.5-9B, на остальных тестах идёт вровень с моделями своего размера. Есть версия на 1,7 млрд. Из README, запуск в vLLM через официальный образ:

Младшие K2 Horizon 0.9B, 3.7B и 7B IFM называет лучшими в своих классах; у 0.9B, по данным блога, больше 48 баллов на AIME 2026. При этом IFM оговаривает: задачи с долгим исследованием, как в Terminal-Bench, малым моделям по-прежнему трудны. Веса, а для большинства и FP8 с GGUF, лежат в коллекции на Hugging Face.

Granite 4.2 8B от IBM, плотная модель с рассуждениями и контекстом 131 072 токена под Apache 2.0, стоит на OpenRouter $0,06 за млн входных и $0,25 за млн выходных токенов. Индекс Artificial Analysis v4.3 всего 12,4 при 17,6 у Haiku 4.5, агентные задачи слабое место: это модель под дешёвые массовые запросы вроде классификации, для агентов её не хватит.

Сколько памяти реально нужно локальной модели?

Для Qwen3.8-27B ответ измерен: 17 ГБ. Piotr Migdał из Quesma прогнал кванты от Unsloth через GPQA Diamond, IFBench и Terminal-Bench 2.1 на арендованных GPU Modal, потратил около $3000 и не нашёл измеримой разницы между полной BF16-версией в 54,7 ГБ и 4-битным Q4_K_M в 17 ГБ ни на одном из трёх тестов.

Цифры такие. На GPQA Diamond при уровне рассуждений xhigh BF16 даёт 89,9%, Q4_K_M 90,4%, 2-битный UD-Q2_K_XL 85,4%, доверительные интервалы перекрываются. На IFBench 81,7% против 81,0% и 80,0%. На Terminal-Bench 2.1 из 89 задач BF16 и Q4_K_M решили по 63, UD-Q2_K_XL 57.

In short, if you go with a 4-bit quantization Q4_K_M (17GB), you won't notice a difference on these benchmarks.

На практике Quesma держала KV-кэш в F16, около 2,3 ГБ на 32 тыс. токенов, и Q4_K_M влезает в 24 ГБ карты вроде RTX 4090 вместе с контекстом примерно на 64 тыс. токенов. 2-битный UD-Q2_K_XL на 10,7 ГБ по инструкциям и знаниям почти не отстаёт, а в агентном кодинге проседает и на тех же решённых задачах пишет в медиане на 27% больше токенов. 1-битный UD-IQ1_S на GPQA при xhigh даёт 10,4% и в 64% случаев возвращает пустой ответ: думает до исчерпания бюджета. Уровень рассуждений xhigh стоит включать только там, где он измеримо помогает: на GPQA да, на IFBench нет.

Ещё сильнее ужалась лаборатория DASLab австрийского института ISTA. Её кванты GSQ-RCO той же Qwen3.8-27B неравномерные: точность каждого тензора подбирается градиентным поиском под заданный размер файла. Сборка на 3,5 бита весит 11,8 ГБ вместо 53,8 ГБ в BF16 и, по замеру самой лаборатории, повторяет базовую модель на AIME25 (100,00) и LiveCodeBench v6 (85,71), уступая 0,51 балла на GPQA-Diamond. Это обычные GGUF, работают в llama.cpp, Ollama и LM Studio:

Для тех, у кого памяти много, а модель большая, новость недели это скорость GLM-5.3-Flash. Unsloth 4 сентября дописала свой pull request в llama.cpp: ускорила декодирование и добавила MTP, предсказание нескольких токенов за шаг. Кванты те же, докачивать ничего не нужно. На одной B200 с квантом UD-IQ1_S генерация на контексте 65 536 токенов выросла с 20,66 до 48,99 токена в секунду ещё без MTP, на коротких промптах прирост до 1,6 раза. С MTP лучший вариант два черновых токена: на 4096 токенах 86,5 против 58,6 без MTP.

However we should stop at around n=2 as more draft tokens makes inference slower.

Требования не изменились: 1-битный квант в 100 ГБ памяти, 3-битный в 128 ГБ, как у Mac Studio или DGX Spark. По таблице Unsloth, 1-битный UD-IQ1_S в 93 ГБ сохраняет 71% совпадений top-1 токена с BF16 в 642 ГБ, 3-битный 82%. С учётом результата Quesma по 1-битным квантам Qwen3.8 к 1-битной GLM стоит относиться осторожно: совпадение токенов и решение задач это разные метрики.

Наконец, llama.cpp 0.4.0, очередной сводный релиз, которые проект теперь собирает из ежедневных билдов раз в несколько недель. Что важно локальщику:

• Новые архитектуры: Qwen3.8-Flash-Next (пока без оптимизаций), Nemotron-3-Puzzle 75B с 9 млрд активных, DSpark для Nemotron 3.5.
• Разреженное flash attention для DeepSeek-V4, GLM и Qwen3.8-Flash-Next; ggml обновлён до 0.23.0.
• Ленивое чтение тензоров --lazy-mode: большие тензоры читаются по мере надобности, а пик памяти при загрузке убран.
• Потолок рабочей памяти квантизатора: раньше один большой тензор мог съесть всю оперативку.
• Сервер: лимит контекста на слот, видео на вход через --video-*, медиа через data:-ссылки, preserve_reasoning по умолчанию.

Что нового не только для текста?

Картинки, речь, вождение, временные ряды и видео. Под Apache 2.0 или MIT четыре модели из шести: TimesFM 3.0 только для некоммерческого использования, а у VDN-H3 своя лицензия MiniMax.

LLaDA-Image. Ant Group выложила модель на 6 млрд параметров, которая одним чекпоинтом и генерирует картинки, и редактирует их по инструкции; и языковой бэкбон, и картиночная часть диффузионные. Базовая версия работает за 50 шагов, Turbo за 4. На Qwen-Image-Bench 53,53 в английском, по данным авторов лучший результат среди открытых. Веса под Apache 2.0, есть FP8 и демо Turbo; код проверен на Python 3.11, PyTorch 2.8 и Diffusers 0.39.0.

Ling-3.0-flash-VL. Та же Ant Group показала зрячую версию Ling-3.0-flash (MoE, 5,5 млрд активных из 124) с таблицей против Qwen3.8-27B и Gemini 3.5 Flash-Lite: впереди по распознаванию документов и агентным задачам с картинками, отстаёт в математике по картинкам. Веса выложены на Hugging Face 8 сентября под MIT, есть FP8-версия.

VibeVoice-ASR-Streaming. Microsoft Research открыла потоковое распознавание речи, которое сразу пишет, кто что сказал, без отдельного этапа диаризации. Десять языков, русский в списке. По отчёту авторов, 7B-версия по доле ошибок в среднем лучше Gemini 3.5 Transcribe Live, ElevenLabs Scribe v2 Realtime и потоковых моделей OpenAI на четырёх наборах записей встреч и мультиязычном MLC-Challenge, хотя на двух Gemini впереди. Версии 1,5B и 7B под MIT, код на GitHub; список терминов, чтобы модель их не коверкала, передаётся флагом --context_info.

Qwen-Drive-1.0. Qwen вместе с Хуачжунским университетом выложила модель для беспилотного вождения на базе Qwen3.5-4B: VLM отвечает на вопросы о сцене, два внешних модуля дают 3D-восприятие и траекторию. На NAVSIM v1.1 планировщик после RL даёт 90,7 PDMS (замер авторов). Apache 2.0, VLM весит 9,1 ГБ, нужна карта от 24 ГБ.

TimesFM 3.0. Модель Google для прогноза временных рядов научилась прогнозировать несколько связанных рядов сразу и, по данным авторов, держит первое место на fev-bench и GIFT-Eval. Ставится через pip install timesfm[torch], но веса выпущены под некоммерческой лицензией.

VDN-H3. Ускоренная версия MiniMax-H3 для генерации видео со звуком: к сети добавили линейную ветку внимания по кадрам и два LoRA-адаптера. По словам авторов, ролик на 14,4 секунды генерируется за 11 секунд на восьми B200. Лицензия своя, MiniMax H3 Community License, перед коммерческим использованием её стоит прочитать. Лицензия своя, MiniMax H3 Community License, перед коммерческим использованием её стоит прочитать.

Что для какой задачи брать в сентябре 2026?

Короткий ответ: выбирать стоит по задаче и объёму памяти, размер в названии вторичен. Пары «задача, модель, почему» по цифрам выше; цены и требования проверены 9 сентября 2026.

• Агент на слабом железе: MiniCPM5-2B. Лучший индекс Artificial Analysis до 4 млрд, 19 тыс. токенов на задачу, есть GGUF и MLX, Apache 2.0.
• Агент с огромным контекстом на одной карте: Spark-X2.5-4B. 1 млн токенов при 4 млрд параметров, τ³-bench 30,4 против 9,3 у Qwen3.5-9B по замеру вендора.
• Локальный кодинг на 24 ГБ: Qwen3.8-27B в кванте Q4_K_M от Unsloth (17 ГБ) или GSQ-RCO IQ3_S от ISTA (11,8 ГБ). Сравнения двух между собой на Terminal-Bench никто не публиковал.
• Терминальный агент на рабочей станции: K2-Horizon-MoVA-36B-A4B. 4 млрд активных, Terminal-Bench 2.1 58,6 по замеру IFM, контекст 524 тыс.
• Кодинг на 128 ГБ памяти: GLM-5.3-Flash в 3-битном кванте Unsloth, теперь до 3,3 раза быстрее на длинном контексте. Про цену решённой задачи в API есть отдельный разбор.
• Распознавание встреч с указанием, кто говорил: VibeVoice-ASR-Streaming-7B. Стриминг, диаризация внутри, русский в списке, MIT.
• Картинки и правка по инструкции: LLaDA-Image-Turbo, 4 шага, есть FP8, Apache 2.0.
• Прогноз временных рядов: TimesFM 3.0, только для исследований из-за некоммерческой лицензии.
• Дешёвые массовые запросы через API: Granite 4.2 8B, $0,06 и $0,25 за млн токенов на OpenRouter; для агентов её не хватит.

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

Что происходит вокруг и чего ждать дальше?

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

Vals AI 31 августа опубликовала полные результаты GLM-5.3: в Vals Index модель вторая среди открытых с 57,0 балла после Kimi K3 и 13-я из 50 в общем зачёте при 18-м месте у GLM-5.2. Это объясняет, почему GLM-5.3 и GLM-5.3-Flash держатся в топе загрузок Hugging Face вторую неделю.

Mistral 8 сентября объявила, что подняла €3 млрд при оценке больше €21 млрд; по словам компании, это крупнейший акционерный раунд в истории европейских технологических компаний. Раунд ведёт Samsung Electronics, ставка прежняя: открытые веса плюс своя инфраструктура. Новых моделей в анонсе нет.

DeepSeek открыла бету V4.1 Flash: модель deepseek-v4.1-flash-expires-on-0910 живёт в API до 10 сентября, веса не выложены, официальных бенчмарков нет, так что в обзор она не попадает; о закрытых моделях речь в разборе за август. Что проверить дальше: выйдут ли веса Nex-N2.5-Pro, доедет ли доработка Unsloth в основной llama.cpp и обновит ли Tencent веса Hy4.

Источники: Карточка Nex-N2.5-Max на Hugging Face, Репозиторий Nex-N2.5 на GitHub: команды запуска, IFM: Introducing K2 Horizon, Карточка K2-Horizon-MoVA-36B-A4B, Коллекция K2 Horizon на Hugging Face, Artificial Analysis: OpenBMB releases MiniCPM5-2B, Карточка MiniCPM5-2B на Hugging Face, Репозиторий MiniCPM на GitHub, Карточка Spark-X2.5-4B на Hugging Face, Quesma: Benchmarking Qwen3.8 27B quantizations, ISTA-DASLab: Qwen3.8-27B GSQ-RCO GGUF, Unsloth: GLM-5.3-Flash, how to run locally, Релиз llama.cpp v0.4.0, LLaDA-Image на GitHub, Карточка VibeVoice-ASR-Streaming-7B, Qwen-Drive-1.0 на GitHub, TimesFM на GitHub, Granite 4.2 8B на OpenRouter, Mistral: раунд на €3 млрд, Vals AI: результаты GLM-5.3

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

• Кэш промптов ломают таймстампы в системном промпте, перетасованные описания инструментов и смена effort посреди диалога. Менять effort без сброса кэша умеют отдельные модели, в том числе Opus 5 и Fable 5.1.
• Команда prompt-audit вычищает из промптов «проверь дважды», «будь максимально тщательным», обязательные scratchpad и противоречивые правила. На саппорт-бенчмарке при переезде с Opus 4.8 на Opus 5 это дало минус 14,6% к стоимости и плюс 5,3 пункта точности.
• На CursorBench 3.2 Fable 5.1 на низком усилии повторяет результат Fable 5 на высоком за треть цены. У Fable 5.1 на Humanity's Last Exam шаг с xhigh до max прибавляет полбалла за 46% цены сверху.
• Команда cost-optimize на четырёх открытых бенчмарках с Sonnet 5 срезала 52–73% стоимости при качестве в пределах шума.
• Команда hillclimb подбирает модель, effort и промпт по вашей оценке: на отложенных тестах точность выросла с 78,6% до 90,5% при цене примерно в пять раз ниже.

Почему кэш промптов промахивается и как это увидеть?

Перед генерацией ответа модель прогоняет весь промпт в рабочее состояние, и этот этап, prefill, и есть дорогая часть обработки входа. Кэш промптов сохраняет это состояние (KV-кэш), и если следующий запрос начинается с того же префикса, модель читает его из кэша вместо пересчёта. Чтение из кэша тарифицируется в разы дешевле полной цены входных токенов: у Fable 5.1 это $0,25 за миллион против $10 за обычный вход.

Три условия, при которых кэш вообще работает: он привязан к конкретной модели, префикс должен совпадать байт в байт, и у него ограниченный срок жизни. Отсюда типичные промахи, которые Anthropic перечисляет по опыту клиентов: динамический таймстамп или идентификатор в системном промпте, описания инструментов, которые меняют порядок между вызовами, и смена уровня усилия посреди диалога, потому что effort рендерится в промпт перед вашим контентом и входит в кэшируемый префикс. Исключение сделано только для части моделей, включая Opus 5 и Fable 5.1: у них effort можно менять без сброса кэша. Отдельная ловушка у субагентов и веток диалога: они делят кэш родителя только при байт-идентичном префиксе, той же модели и том же effort.

Что с этим делать, по списку Anthropic. Смотреть долю попаданий в кэш в Claude Console и через API диагностики кэша: он показывает причину промаха и место, где два запроса разошлись. Редко используемые инструменты объявлять с defer_loading: они не входят в кэшируемый префикс и подгружаются в диалог только когда модель находит их через поиск инструментов. На моделях, которые это поддерживают, обновления системного промпта добавлять как сообщения посреди диалога, а не правкой самого системного промпта. Раскладывать запрос так, чтобы стабильная часть оставалась стабильной: сначала описания инструментов и системный промпт, потом растущий диалог.

Ещё несколько приёмов из той же статьи. Модель или effort менять в тот момент, когда кэш всё равно сброшен, например при компактификации диалога. Двигать точку кэширования по мере роста диалога: автоматическое кэширование ставит её на последний кэшируемый блок. Прогревать кэш заранее: запрос с max_tokens: 0 и явной точкой кэширования на том же effort, что и боевой трафик, обрабатывает промпт и записывает его в кэш, ничего не генерируя. Если отправить его, пока пользователь ещё печатает, первый настоящий запрос попадёт в тёплый кэш. И не выходить за срок жизни кэша: пятиминутный TTL считается с начала запроса, и если агент ждёт инструмент или субагента дольше пяти минут, кэш родителя истекает до возврата результата. На такие случаи есть часовой TTL на префикс.

Какие инструкции вредят новым моделям?

Промпты со временем обрастают правилами, которые латали слабости старых моделей, и после обновления модели эти правила начинают мешать. Anthropic перечисляет шесть антипаттернов. Ритуалы проверки: «перепроверь свою работу», «проверь дважды перед ответом» новые модели выполняют буквально и тратят токены впустую. Усилители вроде «будь максимально тщательным» и «КРИТИЧНО: ТЫ ДОЛЖЕН ВСЕГДА…» дают многословие и лишние вызовы инструментов. Обязательные процедуры и шаблоны рассуждений («думай по шагам в scratchpad») накладываются на встроенное мышление модели и жгут токены. Устаревшие примеры few-shot, подобранные под ошибки старой модели, учат новую имитировать длинные цепочки рассуждений там, где они не нужны. Противоречивые правила («всегда возвращай деньги по политике» против «никогда не возвращай без эскалации») новые модели соблюдают буквальнее, и качество падает. И устаревшая конфигурация: настройки под прошлое поколение, например ручные бюджеты на размышления, платформа с новыми моделями может отвергнуть.

Команда /claude-api prompt-audit ищет всё это в рабочей директории: в коде приложения, который вызывает Claude API, и в конфигурации самого Claude Code, включая CLAUDE.md и скиллы. Для проверки Anthropic взяла бенчмарк службы поддержки и переезд с Opus 4.8 на Opus 5: в чистый промпт по одному подсаживали антипаттерн (снятая настройка thinking, пара противоречивых правил о возвратах, ручной scratchpad, «проверь дважды», «будь максимально тщательным» и обязательная процедура из шести шагов), получили шесть «легаси» промптов и прогнали каждый на Opus 4.8, на Opus 5 с заменой только идентификатора модели и на Opus 5 после одного прогона prompt-audit.

В среднем аудит снизил стоимость на 14,6% и поднял точность на 5,3 пункта. Цена упала за счёт лишних вызовов инструментов и дублирующихся рассуждений: на Opus 5 «проверь дважды» превращалось в повторный поиск заказа при каждом возврате, а «будь максимально тщательным» в десятки ненужных обращений к базе знаний. Точность выросла по трём причинам. Снятая настройка thinking заставляла API отвергать каждый запрос на маршрутизацию. Из-за противоречивых правил Opus 5 придержал четыре возврата, которые был должен, и просил клиента подтвердить. А ручной scratchpad конфликтовал со встроенным мышлением Opus 5: в трёх тикетах модель написала вызов инструмента внутри рассуждений и не выполнила его.

Когда высокий effort не окупается?

Effort задаёт, насколько усердно модель работает: на low она быстрее приходит к выводу, на high дольше рассуждает, проверяет и перебирает альтернативы. Кривая цена-качество у одной и той же модели бывает очень разной. У Fable 5 на FrontierCode Diamond (50 самых сложных задач) low даёт 11,5% за $5,35 на задачу, max даёт 30,9% за $19,00: результат вырос примерно в 2,7 раза за примерно 3,5 раза по цене. А у Fable 5.1 на Humanity's Last Exam без инструментов кривая крутая, но с плоским последним шагом: около 53% на low за примерно $0,30 на вопрос и около 61% на max за $2,23, при этом шаг с xhigh до max добавляет около половины балла за 46% цены сверху. Этот прирост укладывается в разброс между прогонами бенчмарка, то есть переплата идёт ни за что.

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

Совет Anthropic звучит так: пробовать более сильную модель на низком усилии, потому что она может выйти дешевле слабой на высоком. На CursorBench 3.2 Fable 5.1 на low повторяет результат Fable 5 на high за треть цены. Дешевле по двум причинам: на low модель делает меньше работы на задачу, а чтение из кэша у Fable 5.1 стоит $0,25 за миллион токенов против $1,00 у Fable 5. Даже по ценам Fable 5 Fable 5.1 на low обошлась бы примерно на 40% дешевле. Второй совет: понять форму своей задачи, прогнав оценку по всем уровням усилия. Если на ненасыщенном бенчмарке кривая плоская, задача не упирается в вычисления на размышления, и поднимать effort бессмысленно.

Что делают команды hillclimb и cost-optimize?

/claude-api hillclimb автоматизирует этот перебор. Команда делит вашу оценку на обучающую и тестовую части, предлагает изменения конфигурации и читает проваленные примеры из обучающей части, чтобы починить найденное. На том же саппорт-бенчмарке старт был с Opus 4.8 на дефолтном high. Первым шагом hillclimb попробовал Opus 5 на low с prompt-audit, который убрал обязательные ритуалы вызова инструментов, шаги scratchpad и противоречивые правила: это превысило базовый уровень Opus 4.8 с 98,9% точности на обучающей части и снизило цену до 2,6 цента за тикет. Затем он спустился до Sonnet 5 на low: ещё дешевле, 1 цент за тикет, но точность упала до 88,9%. Прочитав проваленные тикеты, Claude добавил в промпт правила маршрутизации и сверку с лимитом на возврат, и Sonnet 5 вернулась к 98,9% при той же цене.

На 14 отложенных тикетах, которых поиск не видел, итоговая конфигурация набрала 90,5% против 78,6% у исходной, при цене примерно в пять раз ниже. Разрыв между 98,9% на обучающей части и 90,5% на тестовой стоит держать в уме: на отложенных примерах прирост заметно меньше.

/claude-api cost-optimize нужна для полного аудита расходов кода, который ходит в Claude API. Сначала она выясняет, куда уходят токены: из отчётов об использовании и затратах организации, если есть ключ Claude Admin API, из объекта usage в каждом ответе API, если приложение его логирует, а если нет ни того, ни другого, читает код сборки запросов и оценивает. Затем ранжирует доступную экономию: кэш промптов, урезание того, что несёт каждый запрос (включая prompt-audit), ограничение вывода и отправка неинтерактивной работы через Batch API. Если дать ей оценку качества, она ещё и считает цену и результат по уровням усилия и моделям.

Anthropic прогнала её на четырёх открытых бенчмарках с Sonnet 5 как базой. На LegalBench команда предложила кэшировать общий префикс между задачами, поставить low и гнать задачи через Batch API: токены на размышления упали со 102 779 до 8 284, доля решённых осталась в пределах шума, цена снизилась примерно на 58%. На tau2-bench retail кэш с явной расстановкой точек кэширования дал минус 72% при той же доле решённых. На OfficeQA Pro пакетная обработка и кэширование документов снизили цену со $136,20 до $64,87. На SWE-bench Verified cost-optimize обнаружила, что кэш в дефолтной конфигурации уже настроен правильно, и экономию дали medium вместо high и ограничение вывода агента несколькими короткими фразами: медиана шагов на задачу упала с 29 до 17, входные токены с 75,2 млн до 33,7 млн, минус 55% по цене. По графику на SWE-bench результат при этом просел на 3,3 пункта при интервале от минус 9,6 до плюс 3,1, то есть значимого изменения не установлено, но интервал допускает и ухудшение, и на своих задачах это стоит перепроверить.

С чего начать?

Порядок, который предлагает сама Anthropic. Если вы переехали на новую модель Claude и хотите проверить старые промпты, запускайте /claude-api prompt-audit: она сканирует промпты, скиллы и описания инструментов в рабочей директории, будь то код приложения или конфигурация Claude Code. Если приложение ходит в Claude API и нужен аудит расходов, берите /claude-api cost-optimize: она профилирует расход токенов и проверяет рычаги по очереди, а с оценкой качества ещё и меряет компромиссы по effort и выбору модели. Если есть оценка и нужен поиск по цене и качеству, /claude-api hillclimb разобьёт её на обучающую и тестовую части, предложит изменения и оценит финальную конфигурацию на отложенных примерах.

Скилл claude-api встроен в Claude Code, отдельно он лежит на GitHub. Подробности по каждому рычагу собраны в документации и в кукбуке по снижению затрат. Все цифры в статье получены в прогонах Anthropic, в том числе на четырёх открытых бенчмарках; сторонних проверок в публикации нет. О том, на что способна Fable 5.1 в агентных сценариях, мы писали на примере агентов, собравших копию Юнион-сквер, а про открытый чертёж торгового агента на Claude есть отдельный разбор.

Источники: Claude Blog: Reducing cost and improving performance with Claude Platform, Анонс @ClaudeDevs в X, Документация: Optimizing for cost and intelligence, Скилл claude-api на GitHub, Cookbook: Cost optimization

Изображение на обложке: Anthropic, заставка статьи «Reducing cost and improving performance with Claude Platform»

Claude: ставка на самопроверку

24 июля Anthropic представила Claude Opus 5. Это уже четвёртая модель компании менее чем за два месяца после Sonnet 5, Fable 5 и Mythos 5. Opus 5 сохранил цену предшественника в API Anthropic: 5 долларов за миллион входных токенов и 25 долларов за миллион выходных. По данным разработчика, по агентному кодингу он приблизился к более дорогому Fable 5.

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

Если вы выбираете с оглядкой на бюджет, можно начать с Claude Sonnet 5. Эта модель рассчитана на повседневные задачи, где важен баланс качества, скорости и стоимости. В RouterAI модели доступны под идентификаторами anthropic/claude-opus-5 и anthropic/claude-sonnet-5.

GPT: новый флагман для длинных задач

GPT-6 Astra стал новым флагманом OpenAI для сложных задач с большим числом шагов, включая программную инженерию и работу с инструментами. GPT-6 Astra Pro использует ту же базовую модель с режимом reasoning.mode: pro, который выделяет больше вычислений на рассуждение.

GPT-5.6 Sol остаётся вариантом для агентного кодинга, ревью и работы в командной строке. Его имеет смысл сравнить с Astra на собственных задачах, особенно если стоимость важнее максимального качества. Актуальные идентификаторы в RouterAI: openai/gpt-6-astra, openai/gpt-6-astra-pro и openai/gpt-5.6-sol.

Gemini: большой контекст и быстрые циклы

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

Gemini 3.8 Flash рассчитан на быстрые агентные циклы, программную инженерию и задачи с несколькими этапами рассуждения. Pro подойдёт для сложного разбора, а Flash стоит проверить на рутинных правках, где важны скорость и цена. Идентификаторы моделей: google/gemini-3.1-pro-preview и google/gemini-3.8-flash.

DeepSeek: стоимость и контроль инфраструктуры

DeepSeek V4 Pro уступает ведущим моделям OpenAI, Anthropic и Google, которые работают только через облачные сервисы разработчиков. По оценке NIST, отставание от ведущих американских моделей составляет около восьми месяцев. При этом семейство DeepSeek даёт возможность запускать открытые модели на собственной инфраструктуре и снижать стоимость типовых задач. Для части сценариев этого более чем достаточно, так что потребность в самом дорогом флагмане отпадает.

DeepSeek можно подключать через клиенты, совместимые с форматом OpenAI. В RouterAI актуальная версия доступна под идентификатором deepseek/deepseek-v4-pro-0813. Перед самостоятельным развёртыванием проверьте лицензию выбранной версии, поскольку условия релизов могут отличаться.

Qwen: общие модели и отдельная линейка для кода

В августе Alibaba расширила семейство Qwen3.8. В него вошли крупные модели общего назначения и компактные версии, которые проще запускать на собственной инфраструктуре. У Qwen есть отдельная линейка Coder для работы с репозиториями, генерации кода и агентных сценариев.

Открытые модели Qwen3 распространяются по лицензии Apache 2.0, но условия конкретного релиза всё равно нужно проверять перед внедрением. В RouterAI на момент подготовки текста доступны Qwen3.8 Max 0902 с идентификатором qwen/qwen3.8-max-0902 и Qwen3 Coder 480B с идентификатором qwen/qwen3-coder.

Как выбрать модель

Единого победителя нет. Opus 5 подходит для сложных изменений, где важна самопроверка. Sonnet 5 и GPT-5.6 Sol можно рассматривать для повседневной работы с балансом цены и качества. GPT-6 Astra рассчитан на длинные многошаговые задачи. Gemini 3.1 Pro полезен при большом объёме кода и документации, а Gemini 3.8 Flash при быстрых агентных циклах. DeepSeek и Qwen стоит проверить, если вам важны открытые модели, контроль инфраструктуры или более низкая стоимость.

Перед выбором проведите короткий тест:

1. Дайте двум или трём моделям одинаковую задачу и одинаковый контекст.
2. Проверьте качество исправлений, тестов и итогового диффа.
3. Посчитайте стоимость завершённой задачи с учётом повторных запросов.
4. Убедитесь, что выбранная модель поддерживает нужные инструменты и формат ответа.
5. Ещё раз проверьте идентификатор, доступность и цену перед запуском в проде.

RouterAI предоставляет один API, совместимый с форматом OpenAI, и позволяет переключать модели через значение параметра model. Для работы используется один API-ключ. Сервис принимает оплату в рублях российской банковской картой или по счёту, а работает без VPN. Актуальные цены и доступность моделей нужно проверять в каталоге, поскольку эти данные меняются быстрее самой статьи.

Мы решили протестировать каталог нейросетевых моделей immers.cloud, чтобы проверить, как работает в нём Qwen3.6-27B на прикладном сценарии от начала до конца. Сначала прогнали модель на задачах для разработчиков в чате, затем вызвали её через API и подключили к тестовому ИИ-агенту с локальными инструментами. По ходу теста сравнили публичный и частный эндпоинты, запустили сгенерированный код, зафиксировали время, расходы и ошибки.

immers.cloud — облачный провайдер вычислений для ИИ: аренда GPU-серверов и готовых инференс-эндпоинтов с посекундной оплатой. Сервис строит инфраструктуру на иммерсионном охлаждении оборудования и позиционирует его как способ держать тарифы ниже рынка — в нашем тесте час конфигурации на двух RTX 4090 стоил 171,77 ₽, а весь сквозной прогон обошёлся в 192,97 ₽. Сервис подходит тем, кому нужен доступ к открытым моделям вроде Qwen без закупки железа: для разовых запусков и прототипов — публичный API, для постоянной нагрузки и изоляции — частный эндпоинт.

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

Прежде чем собирать такой цикл, мы проверили базовый слой: как одна и та же Qwen3.6-27B отвечает в публичном чате, работает через API и запускается в частном инстансе immers.cloud. Это позволяет не смешивать проблемы модели, интерфейса и инфраструктуры с ошибками собственного агентного кода.

Что именно мы проверяли

• интерфейс публичного чата Qwen3.6-27B, точное название модели и доступность настроек генерации;
• три задачи разной сложности: исправление факториала, анализ JSONL-логов и ревью скрипта переименования фотографий;
• публичный OpenAI-совместимый API через Python SDK;
• создание частного эндпоинта на двух RTX 4090 и прохождение всех этапов запуска;
• те же задачи на частной модели и работоспособность сгенерированного кода;
• ИИ-агента с двумя локальными инструментами: нативные вызовы через tool_calls, выполнение функций в Python и возврат результатов модели;
• запасной сценарий с JSON-диспетчером, а также обработку неверных аргументов, отсутствующих файлов и неизвестных инструментов;
• фактические расходы и прекращение тарификации после удаления частного инстанса.

Почему взяли Qwen3.6-27B

Для сравнения публичного и частного режима важно использовать одну и ту же модель. Иначе разница в качестве или скорости может быть связана с архитектурой и размером LLM, а не с вариантом размещения. Поэтому в обоих случаях мы выбрали Qwen3.6-27B в четырёхбитной AWQ-квантизации.

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

Публичный чат открывается со страницы модели. В интерфейсе отображается название «Инференс Модели Qwen3.6-27B», поле промпта и кнопка отправки. Отдельных настроек температуры, длины ответа или переключателя thinking mode мы не увидели.

При этом модель выводила блок «Here's a thinking process» прямо внутри ответа. В JSON публичного API поле message.reasoning оставалось null: рассуждение приходило обычным текстом в message.content. Для будущего агента это важная деталь — такой блок нельзя автоматически считать отдельным структурированным каналом reasoning.

У использованного эндпоинта параметр reasoning_parser не был включён. Это заметнее в сценариях без агента, где текст рассуждения приходится разбирать вручную, тогда как агент справляется с таким ответом и без отдельного канала reasoning. Однако есть эндпоинты, где параметр доступен, например: Qwen/Qwen3.5-35B-A3B-GPTQ-Int4 и google/gemma-4-26B-A4B-it.

Три задачи для модели

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

При анализе логов программа прочитала requests.jsonl, пропустила невалидную строку с предупреждением в stderr и вернула ожидаемую статистику:

{"total": 6, "errors": 2, "average_latency_ms": 168.3, "p95_latency_ms": 400}

Мы запускали решение на штатном Python 3.9.6 в macOS, хотя в промпте требовали Python 3.11. Использованных возможностей стандартной библиотеки хватило, и четыре теста завершились за 0,001 секунды. Это подтверждает работоспособность конкретного ответа, но не заменяет проверку на заявленной версии Python и собственных данных проекта.

Почему ревью модели всё равно нужно перепроверять

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

• смещения ASCII-значений EXIF разрешались относительно среза ExifIFD, хотя формат TIFF хранит их относительно начала TIFF-блока;
• проверка повторного запуска не распознавала уже переименованные файлы и могла добавлять дату к имени ещё раз;
• тест коллизий не создавал настоящую коллизию двух источников;
• последовательное переименование не было транзакционным: прерывание процесса могло оставить каталог в частично изменённом состоянии.

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

Подключаемся к публичному API

На странице Qwen3.6-27B доступны примеры для cURL, PowerShell и Python. Мы использовали Python-клиент OpenAI и поменяли только токен. Ключ передавали через переменную окружения, чтобы он не попадал в исходный файл и историю команд.

На macOS окружение и запуск выглядели так:

Запрос прошёл с openai 2.48.0. Первый запуск занял 6,5 секунды по time, повторный вывод полного JSON — 4,278 секунды. В ответе были указаны модель qwen3.6-27b, 26 входных и 197 выходных токенов. Thinking process снова находился в message.content, а поле reasoning было null.

Запускаем частный эндпоинт

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

• 2 × RTX 4090 по 24 ГБ;
• 16 vCPU и 64 ГБ RAM;
• SSD на 160 ГБ;
• контекст 262 144 токена;
• один инстанс и посекундная оплата;
• 171,77 ₽ в час по странице модели и тарифу сервиса.

Запуск: около десяти минут до AVAILABLE

Запуск начался в 10:13. Сначала кабинет показал создание виртуальной машины, затем остальные стадии подготовки. В 10:23 эндпоинт перешёл в AVAILABLE, а рядом появилась ссылка на чат. Навигация в кабинете оказалась понятной: модель, контекст, конфигурация, статус и API-адрес собраны на одной странице.

На частной модели мы повторили те же задания. Факториал и анализ логов снова дали рабочий результат; четыре теста прошли без исправлений. Субъективно частный вариант отвечал почти так же, как публичный. Показатели TPS в интерфейсе также были близкими, но прямое сравнение времени сложных ответов некорректно: модель генерировала тексты разной длины.

Для более глубокой оценки производительности эндпоинта имеет смысл зайти на виртуальную машину по SSH и запустить нагрузочный прогон vLLM:

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

Публичный и частный режимы: что показал тест

В наших запросах message.reasoning оставалось null. При создании частного эндпоинта параметр reasoning_parser не включался, поэтому этот результат нельзя трактовать как отсутствие поддержки отдельного структурированного канала reasoning. В протестированной конфигурации рассуждение возвращалось внутри message.content. Чтобы получить рассуждение в message.reasoning отдельно от основного ответа, нужно включить reasoning parser в настройках частного эндпоинта.

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

Сколько стоил тест

Начальный баланс в нашем кабинете составлял 10 000 ₽. После неудачного запуска, успешного развёртывания, трёх задач на частной модели и удаления эндпоинта осталось 9 807,03 ₽. Фактический расход всего теста — 192,97 ₽.

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

От модели к ИИ-агенту

Проверенный API уже можно использовать как модельный слой приложения. Но один вызов chat.completions ещё не делает программу агентом. Для агентного цикла нужны четыре компонента:

• модель — Qwen3.6-27B через OpenAI-совместимый API;
• реестр инструментов — функции с понятными именами, аргументами и JSON-схемами;
• контроллер — код, который принимает запрос модели, проверяет аргументы, вызывает разрешённую функцию и возвращает результат;
• политика безопасности — лимиты итераций, dry run для изменений, журналирование и подтверждение опасных действий.

Выбираем полезный сценарий

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

Адаптер Qwen, который уже проверен

Начнём с небольшого слоя, который изолирует адрес immers.cloud и имя модели от остального кода агента. Этот вариант использует тот же способ подключения, который прошёл наш API-тест:

Как будет работать агентный цикл

1. Пользователь просит проанализировать requests.jsonl и предложить действия.
2. Контроллер передаёт Qwen историю диалога и описания доступных инструментов.
3. Если модель возвращает tool_calls, контроллер проверяет имя функции и аргументы по схеме.
4. Локальная функция выполняется без участия модели; её JSON-результат добавляется в messages с ролью tool.
5. Qwen получает факты и формирует итоговый разбор. Цикл завершается при обычном ответе или по лимиту итераций.

Тестируем полный агентный цикл

Во втором этапе мы подключили Qwen3.6-27B с публичного эндпоинта immers.cloud к агенту разбора инцидентов. Целью было не получить ещё один текст от модели, а проверить всю цепочку: структурированный вызов функции, валидацию аргументов, выполнение локального кода, возврат результата в контекст и безопасное завершение.

Агент работал с теми же тестовыми данными requests.jsonl. Модель не читала файл напрямую и не считала перцентиль сама. Она могла вызвать только три функции из реестра: calculate_log_metrics, lookup_runbook и prepare_incident_report.

Как устроен контроллер

Мы передали описания функций в параметре tools и включили tool_choice="auto". Если Qwen возвращала структурированный tool_calls, контроллер проверял имя функции по белому списку, разбирал аргументы, валидировал их по JSON Schema и только затем выполнял локальный код. Результат возвращался модели сообщением с ролью tool.

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

Как воспроизвести запуск

Рядом с agent.py должен лежать файл requests.jsonl. Токен, как и в базовом API-тесте, передаётся через переменную окружения и не сохраняется в исходнике.

Первая версия прошла технически, но ошиблась по смыслу

В первом запуске нативный tool calling уже работал: API возвращал структурированные вызовы, имена функций и аргументы проходили схему, цикл дошёл до финального ответа. Но контракт calculate_log_metrics отдавал только агрегаты — число ошибок, среднюю задержку и p95. В нём не было фактических пар route + status для ошибочных записей.

Qwen заметила нехватку данных и прямо написала, что не знает, для каких маршрутов нужно искать runbook. Затем всё же начала подбирать варианты. Кроме реальных /api/orders + 500 и /api/orders + 503 она запросила несуществующие в логе пары /api/payments + 500 и /api/users + 500. Все вызовы были формально валидными, но два из них опирались на выдуманные факты.

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

Добавляем error_records и запрещаем догадки

Мы расширили ответ calculate_log_metrics полем error_records и сгруппировали в нём только реальные ошибки из файла. Для тестового набора функция вернула:

В системной инструкции закрепили ещё одно правило: пары для lookup_runbook можно брать только из error_records. После этой правки модель перестала угадывать маршруты. Количество итераций и структурированных вызовов сократилось с шести до четырёх. Суммарное время ожидания ответов API в одном прогоне снизилось с 66,76 до 20,81 секунды. Это наблюдение одного запуска, а не бенчмарк производительности.

Что вернул нативный режим

Исправленный цикл завершился за четыре итерации. На первой Qwen вызвала calculate_log_metrics. На второй вернула сразу два lookup_runbook в одном ответе — для кодов 500 и 503. На третьей собрала черновик через prepare_incident_report с apply=false. На четвёртой вызовов инструментов уже не было: модель сформировала итоговый текст.

Метрики совпали с отдельным тестом утилиты: шесть корректных записей, две ошибки, средняя задержка 168,3 мс, p95 — 400 мс, одна пропущенная строка. В черновик вошли только реальные проблемы: /api/orders + 500 и /api/orders + 503 — вместе с соответствующими инструкциями runbook.

По телеметрии прогона API вернул четыре нативных вызова, текстовых псевдовызовов не было. Все четыре набора аргументов прошли схему; неизвестных инструментов, ошибок локальных функций, попыток apply=true и выхода на лимит итераций не возникло.

Проверяем запасной режим без tool_calls

Для fallback мы намеренно не передавали tools в API. Вместо этого системный промпт требовал вернуть обычным текстом один JSON-объект с действием tool_call или final. Контроллер извлекал последний валидный объект, проверял его по тому же реестру и вызывал ту же локальную функцию.

Запасной путь тоже завершил задачу: пять итераций, четыре извлечённые JSON-команды и тот же корректный отчёт. Однако Qwen не соблюдала требование «только JSON» буквально — перед объектом она печатала длинный thinking process. Парсер справился, но такой протокол зависит от разбора свободного текста и остаётся более хрупким. Сумма времени пяти ответов составила 62,72 секунды против 20,81 секунды в нативном прогоне. По одному запуску нельзя делать вывод о постоянной разнице скорости, но с точки зрения контракта tool_calls предпочтительнее.

Негативные проверки контроллера

Отдельный faultcheck не обращался к модели: мы напрямую передавали диспетчеру ошибочные вызовы и проверяли, выполнится ли что-нибудь опасное.

Даже если модель запросит apply=true, тестовый диспетчер принудительно заменит значение на false. Это защита на уровне кода, а не надежда на системный промпт. Для реального агента к ней нужно добавить права на уровне ОС или сервиса, таймауты, лимиты размера результата, идемпотентность и подтверждение пользователя перед необратимой операцией.

Что показал второй этап

Публичный эндпоинт Qwen3.6-27B в нашем тесте корректно работал с нативным tool calling через стандартный Python SDK: модель вернула структурированные вызовы, приняла результаты с ролью tool и завершила цикл обычным ответом. Значит, проверенный ранее API можно использовать не только для одиночного чата, но и как модельный слой агента.

При этом надёжность появилась не из-за одной модели. Её обеспечили реестр разрешённых функций, JSON-схемы, достаточный контракт результата, ограничение числа итераций, обработка исключений и dry run. Самая важная находка теста — error_records: небольшое изменение данных между инструментами устранило правдоподобные догадки, сократило цепочку и сделало результат проверяемым.

Граница эксперимента: мы провели функциональный прогон на небольшом локальном файле и одном публичном эндпоинте. Это не нагрузочный тест, не проверка SLA и не доказательство одинакового поведения на любых промптах. Реальную запись отчёта тоже не включали: весь сценарий завершился в режиме dry run.

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

Итог

immers.cloud отработал предсказуемо на всех трёх уровнях — публичном чате, публичном API и агентном цикле с tool_calls: везде задача решилась без обходных путей. Узким местом оказалась не модель, а код вокруг неё: проверка аргументов, полный контракт результата инструментов и dry run по умолчанию определили, можно ли доверять результату.

Совместимость с OpenAI SDK здесь помогла конкретно: код, прошедший базовый API-тест, перешёл в агента без единой правки. Для прототипа этого достаточно как отправной точки — дальше стоит добавить трассировку вызовов и подтверждение опасных действий человеком, то, что в проде отличает контролируемый цикл от рабочего образца.

Источники и страницы продукта

• Страница Qwen3.6-27B в каталоге immers.cloud
• Руководство immers.cloud по каталогу и эндпоинтам
• FAQ immers.cloud
• Тарифы и конфигурации RTX 4090
• О компании и заявленные особенности иммерсионного охлаждения

Реклама. Рекламодатель: ООО «ДТЛ» ИНН 9717073792, erid: 2W5zFHSiVzq

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

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

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

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

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

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

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

Две фазы инференса, которые дорожают по-разному

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

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

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

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

KV-кеш: где на самом деле кончается память

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

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

Для модели с 32 слоями, 8 KV-головами, размерностью головы 128 и половинной точностью получается примерно 128 КБ на один токен. У других моделей цифра будет своя, но зависимость одна: чем длиннее контекст, тем больше памяти занято. Именно поэтому длинные промпты, долгие диалоги и подтянутые из поиска документы делают инференс заметно дороже, а свободный объём этого кеша прямо определяет, сколько запросов сервер потянет одновременно.

Почему агентская нагрузка тяжелее обычной

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

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

Четыре механизма, которые возвращают пропускную способность

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

Страничное внимание, оно же PagedAttention

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

Непрерывное пакетирование

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

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

Кеширование общего префикса

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

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

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

Совместимый интерфейс

Четвёртый пункт скучный, но на практике решающий: сервер выставляет интерфейс, совместимый с OpenAI. Существующие приложения и агентские фреймворки переключаются на него правкой конфигурации, а не переписыванием кода.

Когда всё это действительно нужно

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

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

Вторая половина задачи: считать деньги до запуска

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

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

Реестр токенов вместо пробного запуска

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

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

Проверим на задаче из 6000 сводок, где промпт занимает около 21 000 символов, а ответ ограничен 500. Выходит 5250 токенов на промпт плюс 125 на ответ, то есть 5375 на вызов, а на всю задачу 32 250 000 токенов при лимите в 30 000 000. Задача не помещается с запасом минус 7,5%, и узнать это удалось, не потратив ни одного токена.

Соседняя задача с промптом в 4000 символов, тем же ограничением ответа в 500 символов и 10 000 вызовов даёт 1125 токенов на вызов и 11 250 000 на всё, помещаясь с запасом в 62,5%. Живая пробная отправка ни того, ни другого не покажет: она расскажет о поведении конкретной ручки прямо сейчас, но не о сумме по всей пачке, и вдобавок сама потратит токены.

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

Тут стоит остановиться отдельно, потому что соблазн велик. Расход токенов удобно считается и потому легко попадает в отчёты, но как метрика продуктивности он повторяет ошибку подсчёта строк кода.

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

Само по себе потребление токенов отвечает на вопрос, пользуется ли человек инструментом вообще. На раннем этапе внедрения этот сигнал полезен. Но он ничего не говорит о том, получилось ли в итоге что-то осмысленное, а «много ИИ» и «хорошо с ИИ» — разные вещи.

Стоимость на результат

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

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

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

Слишком жёсткая квота выталкивает работу за периметр

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

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

Что забрать с собой

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

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

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

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

На момент публикации (19:00 мск) полностью закрыт только короткий утренний инцидент Anthropic. У Claude ошибки остаются на Opus 4.8 и Opus 5, OpenAI применила исправление и «наблюдает за восстановлением», xAI сроков не называет. Ниже хронология по статус-страницам, цифры Downdetector, что известно о причине и что делать, если у вас на этих API завязан рабочий процесс.

• Anthropic: инцидент с 16:26 мск на Mythos 5.1, Fable 5.1, Opus 5, потом список расширился до Mythos 5, Fable 5, Opus 4.8 и Opus 4.6. К 18:25 мск все модели, кроме Opus 4.8 и Opus 5, вернулись к обычному уровню ошибок.
• OpenAI: инцидент с 17:58 мск, 19 компонентов ChatGPT и Codex в статусе «degraded», исправление применено в 18:22 мск, инцидент не закрыт.
• xAI: все восемь компонентов Grok в статусе «outage», доступность API в американских регионах по данным самой xAI около 84–85%, европейский регион 100%.
• Downdetector: до 37 тысяч жалоб на OpenAI за час (пик около 18:35 мск), около 1 400 на Claude и на Grok. Для Claude и Grok это в 20–30 раз выше обычного фона.
• Причину ни одна компания не назвала. Единый корень не подтверждён: у Cloudflare и Azure инцидентов на это время нет, а сбои начались с разницей в полтора часа.

Что и когда сломалось: хронология по статус-страницам

Время везде московское, источники: статус-страница Anthropic, страница инцидента OpenAI, статус xAI и статус Cursor, который зависит от всех троих и потому удобен как независимый свидетель.

• 15:37 — Anthropic открывает первый за день инцидент: рост ошибок у Claude Sonnet 5. Закрыт в 15:56, за 19 минут.
• 16:26 — Anthropic открывает второй инцидент: ошибки на Claude Mythos 5.1, Fable 5.1 и Opus 5. В 16:41 причина «найдена», в 16:50 список затронутых моделей расширен: Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8, Opus 4.6.
• 16:41 — Cursor фиксирует деградацию «всех моделей Grok», автоматизаций, облачных агентов и агента ревью. Это первое зафиксированное время проблем у xAI: собственная статус-страница компании времени начала не показывает.
• 17:17 — Cursor подтверждает ошибки на Fable 5.1, Fable 5, Opus 5, Opus 4.8 и Opus 4.6 «из-за проблемы на стороне Anthropic».
• 17:30 — Си-Джей Авилла из developer relations Anthropic пишет в X: «Инфраструктурная проблема вызывает частичный сбой в Claude Code, API и claude.ai. Мы работаем над этим, но срока восстановления пока нет» (перевод редакции).
• 17:58 — OpenAI открывает инцидент «Elevated errors across ChatGPT and Codex». Затронуты 19 компонентов: диалоги, вход, загрузка файлов, генерация изображений, голосовой режим, поиск, Deep Research, агент, GPTs, коннекторы, браузер Atlas, Codex Web, Codex API, Codex в десктопном ChatGPT, расширение VS Code, CLI, Compliance API, ChatGPT Work и Sites.
• 18:17 — Cursor фиксирует ошибки на моделях OpenAI «из-за проблемы на стороне OpenAI».
• 18:22 — OpenAI: «Мы применили исправление и наблюдаем за восстановлением». В 18:50 та же формулировка, инцидент не закрыт.
• 18:25 — Anthropic: «Сейчас затронуты только Opus 4.8 и Opus 5. Остальные модели вернулись к базовому уровню ошибок».
• 18:33 — Cursor по Grok: «Мы нашли причину и работаем над исправлением».

Порядок важен для версии о единой причине: Claude и Grok начали сбоить в 16:26–16:41, а ChatGPT почти через полтора часа, в 17:58. У Cloudflare на статус-странице за это время инцидентов нет: последний, о росте ошибок 5xx в Гонконге, закрыт в 12:36 мск. У Microsoft Azure в истории за 3 сентября инцидентов тоже нет. Всё, что пишут о «проблеме у Azure» или «проблеме у Cloudflare», пока остаётся версией читателей, а не заявлением провайдеров.

Сколько людей это задело: цифры Downdetector

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

На OpenAI Downdetector получил около 37 тысяч жалоб на пике, около 18:35 мск. 80% жалоб касаются ChatGPT, 8% Codex, 7% приложения. Обычный фон на этом графике не виден вовсе: сотни жалоб в час против десятков тысяч.

По Claude и Grok пики около 1 400 жалоб в час при обычном фоне в 20–50. У Grok 48% жалоб на приложение, 25% на генерацию ответов, 24% на сайт. На главной Downdetector в 18:58 мск карточки OpenAI, Claude AI, Grok и Google Gemini стояли рядом со всплесками на графиках, это и есть обложка этой новости. По Gemini сервис зафиксировал рост жалоб с 18:15 мск, но Google инцидент не объявляла, а мониторинг StatusGator показывал сервис работающим. Разница в масштабах объяснима аудиторией: у ChatGPT на порядок больше пользователей, готовых пожаловаться.

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

Официально: Anthropic говорит об «инфраструктурной проблеме» без деталей, OpenAI ограничилась словами «расследуем» и «применили исправление», xAI не написала ничего, кроме статуса компонентов. Ни одна компания не назвала общего поставщика.

На Hacker News тред «ChatGPT and Codex Is Down» собрал 92 очка и 225 комментариев, отдельный «Ask HN: почему OpenAI, Claude и Grok упали одновременно» ещё 48 и 36. Полезного там три наблюдения. Первое: пользователи Codex CLI по всему миру получали ошибку unexpected status 404 Not Found от chatgpt.com/backend-api/codex/responses, и в идентификаторах cf-ray стояли коды аэропортов разных узлов Cloudflare: ORD, DTW, YYZ, IST. Это значит, что запрос доходил до edge-сети и отбивался на границе, а не терялся по дороге; 404 здесь не «страница не найдена», а отказ бэкенда за прокси. Второе: у части людей уже открытые сессии продолжали работать, а новые соединения не устанавливались. Третье: некоторые регионы, например Австралия, Индия и часть Европы, восстановились раньше остальных.

Самая распространённая гипотеза в обоих тредах: не общий поставщик, а каскад. Когда лёг один сервис, разработчики массово переключили агентов на соседний, и тот не выдержал нагрузки. Хронология этому не противоречит: Claude и Grok упали первыми, ChatGPT через полтора часа. Против гипотезы говорит то, что Claude и Grok сбойнули в пределах четверти часа друг от друга, а общей причины у них не видно. Отдельный контекст: 3 сентября OpenAI намекала на скорый анонс новой модели Astra (аккаунты компании писали «The stars are almost aligned»), и в тредах предполагают, что инфраструктуру перенастраивали под запуск. Подтверждений этому нет.

Для OpenAI подобные инциденты не редкость: в июле компания пережила четыре сбоя за четыре дня, после чего сбрасывала лимиты платным подписчикам ChatGPT и Codex. О компенсациях за сегодняшний сбой ни OpenAI, ни Anthropic пока не сообщали. Для Anthropic это третий инцидент за двое суток: 2 сентября Sonnet 5 отваливался на 14 минут, 3 сентября на 19, а потом начался текущий.

Что делать разработчику

• Смотреть на статус-страницы, а не на соцсети: status.claude.com, status.openai.com, status.x.ai. У xAI есть раздел «Live service data» с процентом успешных запросов по регионам, он обновляется даже без объявленного инцидента.
• Не пересоздавать аккаунт и не сбрасывать авторизацию: при частичном сбое это не помогает, а у OpenAI среди деградировавших компонентов сегодня был и Login.
• Если у вас Claude через API, переключать модель, а не провайдера: с 18:25 мск проблемы только на Opus 4.8 и Opus 5, Fable 5.1 и Sonnet 5 отвечают в штатном режиме. В Cursor это делается в выборе модели без перезапуска агента.
• Ретраи с экспоненциальной задержкой на 5xx и на 404 от backend-api: часть запросов проходит даже в разгар инцидента, но бить в API каждую секунду означает добавлять нагрузку на то, что и так лежит.
• Держать второго провайдера в конфиге, а не в голове: сегодняшний день показал, что «переключусь, если что» занимает полтора часа, если ключ и адаптер не были прописаны заранее. В Европе Grok, по данным самой xAI, весь день отвечал на 100%, регион eu-west-1 не пострадал.

Мы обновим материал, когда Anthropic, OpenAI и xAI закроют инциденты или назовут причины. Если у вас прямо сейчас не отвечает что-то из перечисленного, это не у вас одних, и сброс сессии не поможет.

Источники: Anthropic: Elevated errors for multiple models, OpenAI: Elevated errors across ChatGPT and Codex, Статус-страница xAI, Статус-страница Cursor, Си-Джей Авилла (Anthropic) о частичном сбое, Downdetector: OpenAI, Hacker News: ChatGPT and Codex Is Down

Изображение на обложке: Скриншот: Downdetector

Практический вопрос для тех, кто обновляется: что сломается. Удалены torch.cholesky, torch.qr и параметр профилировщика use_cuda; acc_policy="balanced" в LinearCrossEntropyOptions теперь вызывает ValueError, нужно "compact"; у скалярного clamp изменился градиент на границе. А torch.compile на Python 3.15 в этом релизе не работает и завершается явным RuntimeError.

• NVGEMM добавляет в Inductor ядра CUTLASS, сгенерированные CuTeDSL, с fusion эпилогов, scaled и NVFP4 GEMM.
• Distributed: новый backend nccl2 с неблокирующими коммуникаторами и eager splitting; c10d умеет перенастраивать process group на месте; Flight Recorder работает с любым backend.
• torch.switch обобщает torch.cond на несколько веток, torch.while_loop захватывается CUDA Graphs, @dynamic_spec единообразно описывает динамические формы для torch.compile, torch.export и make_fx.
• Apple Silicon получил нативные SVD, eigh, QR и Cholesky; появились ROCm 7.14 wheels, захват графов на Intel XPU и цель sm_107 для NVIDIA Rubin.
• Wheels для Python 3.15 и 3.15t собраны для Linux x86-64 и aarch64, Windows x86-64 и macOS Apple Silicon, но лежат на download.pytorch.org, а не на PyPI; torch.compile на 3.15 не поддерживается.

Что даёт NVGEMM и кому он нужен

NVGEMM, по описанию релиза, подключает к компилятору Inductor ядра матричного умножения CUTLASS, которые генерируются через CuTeDSL. Поддерживаются слияние эпилогов (операций после умножения), scaled GEMM и формат NVFP4, а также grouped-reduction epilogues. Это продолжение линии PyTorch 2.13, где CuTeDSL-путь только закладывался. Выигрыш получат те, кто гоняет обучение и инференс на современных NVIDIA GPU через torch.compile; на CPU, ROCm и Apple Silicon эта часть релиза ничего не меняет. Цифр ускорения относительно 2.13 в блоге релиза нет, поэтому эффект стоит мерить на своей модели.

Отказоустойчивость распределённого обучения

Backend nccl2 появился рядом с прежним NCCL и приносит неблокирующие коммуникаторы и eager splitting. Важнее для практики изменения в c10d: process group можно перестроить на месте, без полного перезапуска задания, когда один из узлов выпал. Добавлены односторонние окна RMA, а Flight Recorder, инструмент посмертной диагностики зависших коллективных операций, теперь работает не только с NCCL. Для кластеров на десятки GPU это означает меньше потерянных часов при сбое одного узла; для одной машины изменения не заметны.

Python 3.15: wheels есть, torch.compile нет

Python 3.15 ещё не вышел: 1 сентября появился второй релиз-кандидат, финал назначен на 1 октября. PyTorch 2.14 уже публикует сборки под 3.15 и его free-threaded вариант 3.15t для Linux, Windows и macOS на Apple Silicon, включая применимые CPU-, CUDA-, ROCm- и XPU-варианты. Две оговорки из заметок к релизу: эти wheels не лежат на PyPI, их нужно ставить с индекса download.pytorch.org, и torch.compile под 3.15 не поддерживается; попытка скомпилировать модель завершится RuntimeError, работает только eager-режим.

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

Несовместимые изменения

• LinearCrossEntropyOptions(acc_policy="balanced") удалён: теперь ValueError, заменять на "compact".
• Удалены устаревшие torch.cholesky и torch.qr (используйте torch.linalg.cholesky и torch.linalg.qr) и параметр профилировщика use_cuda.
• Градиент скалярного clamp на границе изменён с 1 на 0; для тензорных границ градиент делится как 0,5 и 0,5. Модели, чувствительные к поведению на границе клиппинга, могут обучаться иначе.
• Поддержка комплексных тензоров в torch.compile помечена как экспериментальная.

Как обновляться

1. Свериться с матрицей сборок на странице релиза: версии CUDA, ROCm 7.14, XPU и Python для вашей платформы.
2. Прогнать по коду поиск acc_policy="balanced", torch.cholesky, torch.qr и use_cuda.
3. Если используете кастомные process group с параметром backend, проверить их на nccl2 отдельно.
4. Для Python 3.15 ставить только с индекса download.pytorch.org и не рассчитывать на torch.compile.

Библиотека torchvision 0.29 в релизе объявлена ABI-совместимой с будущими torch 2.15 и 2.16, то есть её не придётся пересобирать под следующие два выпуска. Ограничений на загрузку wheels по регионам в источниках нет. Что ещё вышло в ML-инструментах за последние недели, смотрите в обзоре открытых моделей августа.

Источники: PyTorch 2.14 Release Blog, Release notes v2.14.0 на GitHub, Python 3.15.0rc2

Изображение на обложке: PyTorch Foundation, логотип PyTorch

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

• Выборка: 55 видов из датасета FungiTastic (340 тыс. наблюдений, 615 тыс. фото, 2,8 тыс. видов), по 20 тестовых фото на вид, всего 1040; метки подтверждены экспертами, часть ДНК-анализом.
• Точность первого ответа: Gemini 3.8 Flash 65%, Gemini 3.6 Flash 64%, Gemini 3.7 Flash 61%, Claude Fable 5 и Kimi K3 по 53%, Claude Fable 5.1 51%, GLM-5.3-Flash 47%, GPT-5.6 Sol 42%, Qwen3.8 27B 13%.
• Доля ядовитых грибов, названных съедобным видом: 11% у лучших Gemini, 18% у Fable 5.1, 24% у GPT-5.6 Sol, 29% у Claude Opus 5, 36% у Qwen3.8 27B.
• Опасные ошибки не случайны: смертельно ядовитую паутинницу модели называли лисичкой, как и люди; бледную поганку модели в сумме узнавали в 48% случаев.
• Подсказка «фото из Дании» результат не улучшила; для надёжного определения экспертам нужны минимум три снимка, а Атлас датских грибов опирается на ДНК.

Как устроен тест

Мигдал взял готовый датасет FungiTastic, собранный чешскими исследователями компьютерного зрения на данных гражданского проекта «Атлас датских грибов»: 340 тыс. наблюдений, 615 тыс. фотографий, 2,8 тыс. видов, метки проверены экспертами, часть подтверждена ДНК-секвенированием. Датасет разбит по годам: обучение до 2021 года, валидация 2022, тест 2023. Модели ничему не обучались, поэтому использовался тестовый срез, а подход в терминах классического ML называется zero-shot.

Чтобы тест отражал реальный поход в лес, а не лабораторию, автор отобрал виды по двум польским спискам: официальному перечню грибов, разрешённых к продаже в Польше (47 видов, из них 37 есть в датасете), и списку смертельно ядовитых видов из Википедии (после пересечения с датасетом 20 видов). Один вид, зеленушка (Tricholoma equestre), попал в оба списка: в одних странах её считают съедобной, в других она числится причиной смертельных отравлений. Итого 55 видов, по 20 фото на вид; для редких видов недостающие снимки добраны из валидационного среза.

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

Кто узнаёт грибы лучше

Три поколения Gemini Flash заняли весь пьедестал: 3.8 Flash 65% с первого раза и 85% в топ-5, 3.6 Flash 64% и 85%, 3.7 Flash 61% и 82%. Дальше идут Claude Fable 5 (53% и 72%), Kimi K3 (53% и 70%), Claude Fable 5.1 (51% и 70%), GLM-5.3-Flash и Qwen3.8 Max (по 47%), Claude Opus 5 и Grok 4.6 (по 44%). GPT-5.6 Sol, которую, как отмечает автор, хвалили как лучшую модель OpenAI по зрению, набрала 42%, а её Pro-версия 39%. В хвосте DeepSeek V4 Flash Vision (30%), Qwen3.8 Flash (27%), MiniMax M3 (24%) и локальная Qwen3.8 27B (13% и 24% в топ-5).

Автор отмечает, что отрыв Gemini здесь заметно больше, чем в других визуальных бенчмарках, и что дешёвые модели Google обошли фронтирные Claude и GPT. GLM-5.3-Flash он выделяет за соотношение цены и качества.

Какие ошибки опасны

Большинство промахов безобидны: один млечник назван другим млечником, один боровик другим. Опасные ошибки, по наблюдению автора, не случайны и повторяют ошибки людей: смертельно ядовитую паутинницу Calonarius splendens модели узнавали в 20% случаев, а в 27% называли лисичкой. Бледную поганку Amanita phalloides модели в совокупности определяли верно в 48% случаев.

Отдельно автор посчитал условную вероятность, что ядовитый гриб будет назван съедобным видом. У трёх Gemini Flash она 11–12%, у Kimi K3 14%, у Claude Fable 5.1 18%, у GLM-5.3-Flash 19%, у Claude Fable 5 22%, у GPT-5.6 Sol 24%, у Claude Opus 5 29%, у Qwen3.8 27B 36%. Muse Spark 1.2 показала всего 8%, но, как пишет автор, только потому, что часто отказывается отвечать. Обратная ошибка, съедобный гриб принят за ядовитый, встречается у всех моделей в 3–12% случаев и стоит лишь пропущенного ужина.

Оговорки автора

Мигдал не утверждает, что люди справляются лучше. Одного снимка может не хватить и эксперту: проект iNaturalist по грибам Калифорнии требует минимум три фото на наблюдение, общий план с субстратом, шляпку крупно и ножку с пластинками. Атлас датских грибов не зря полагается на экспертов и ДНК, а не на фотографии. Типичная ошибка приезжих грибников та же, что у моделей: гриб похож на съедобный «домашний», а местный смертельный двойник им незнаком. Подсказка в промпте «фото из Дании» результаты не улучшила.

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

Что с этим делать

• Как учебник нейросеть годится: автор сам собрал на Gemini 3.7 Flash приложение для запоминания местных растений. Как решение «можно ли это есть» не годится ни одна из 17 моделей.
• Если вы делаете продукт с распознаванием по фото, закладывайте вероятность опасной ошибки в проценты, а не в доли процента, и не выдавайте вердикт «съедобно» без эксперта.
• Повторить тест на своей модели можно по коду из репозитория; в README на момент публикации перечислены 16 моделей, так что часть результатов из статьи туда могла ещё не попасть.

Автор обещает продолжить серию тестов Quesma по зрению; следующий очевидный шаг, которого в статье нет, это проверка с несколькими снимками одного гриба, как требуют полевые определители. Обсуждение теста идёт на Hacker News.

Источники: Piotr Migdał, Quesma: Mushroom hunting with LLMs: what can go wrong?, Код, список фото и ответы моделей: репозиторий mushroom-hunting-llm-bench, Датасет FungiTastic, Обсуждение на Hacker News

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

• Сервис принимает JPG, PNG, GIF, WEBP, TIFF, HEIC, AVIF, SVG, DNG, JXL, MP4, MOV, AVI, WAV, MP3, M4A и FLAC размером до 100 МБ.
• Проверка идёт локально в браузере: по словам Anthropic, файл не покидает устройство, не сохраняется и читаются только метаданные.
• Ищется только подписанная метка C2PA от Claude; результат не говорит ни о содержании файла, ни о том, кто его загружал.
• Отсутствие метки ничего не доказывает: она пропадает при удалении метаданных, а поддерживают её пока только Fable 5.1 и Mythos 5.1.
• Текстовые водяные знаки этот сервис не проверяет: для них есть отдельный Detection API в закрытом превью для организаций по требованию закона ЕС.

Что именно проверяет сервис

По описанию на странице, Claude помечает свой вывод двумя способами. Текст получает водяной знак в самих формулировках: он невидим, переживает копирование и часть правок. Файлы получают content credential, подписанные метаданные о происхождении, которые прикрепляются при скачивании, например к диаграмме, которую построил Claude. Формат метаданных задаёт открытый стандарт C2PA (Coalition for Content Provenance and Authenticity), тот же, что используют производители камер и фоторедакторы для записи истории снимка; прочитать такую запись может любой инструмент с поддержкой C2PA.

Check Content работает только со вторым типом меток. Он читает метаданные файла, ищет подписанную запись и, если та указывает на Claude, сообщает об этом. Anthropic отдельно оговаривает: инструмент показывает, что Claude участвовал в производстве файла, но не может сказать, участвовал ли он в создании содержимого, и не раскрывает никаких сведений о пользователе, который этот файл сгенерировал.

Технически всё происходит на стороне клиента: страница обещает, что файл остаётся на устройстве, никуда не загружается и не используется ни для каких других целей. Список форматов широкий, от JPG и SVG до MP4, WAV и FLAC, лимит 100 МБ. Сам процесс занимает секунды: перетащили файл, получили ответ «метка найдена» или «не найдена».

Почему появилась метка и какие модели её ставят

Причина не в моде на прозрачность, а в законе. В справочной статье Anthropic пишет, что подписала кодекс практики к статье 50(2) AI Act ЕС о прозрачности ИИ-контента, и обязалась машиночитаемо помечать вывод моделей Claude, запущенных в ЕС 2 августа 2026 года или позже. Компания обещает применять метки везде, где доступен Claude, а не только в Европе: в API, приложении, Claude Code и Cowork. Через облачных партнёров AWS, Google Cloud и Microsoft Foundry текстовые водяные знаки идут всегда, а файловые метки только там, где платформа даёт генерацию файлов Claude.

Сейчас метки ставят Fable 5.1 и Mythos 5.1; для моделей, вышедших до 2 августа, действует переходный период, и поддержку им ещё добавляют. Отсюда практическое следствие: файл от Opus 5 или старой Sonnet сервис не распознает, и это штатное поведение, а не сбой.

Текстовые водяные знаки проверяются иначе. Для них Anthropic держит Detection API в закрытом превью и выдаёт доступ организациям, которым это положено по закону ЕС: регуляторам, правоохранителям, СМИ, фактчекерам, исследователям, образовательным организациям, а также компаниям, обязанным проверять маркировку для собственного соответствия AI Act. Расширять доступ обещают «со временем», сроков нет.

Чего проверка не доказывает

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

Есть и обратная сторона. Метка проверяет только «участвовал ли Claude», поэтому для картинки от другой модели ответ будет отрицательным, хотя содержимое сгенерировано. Похожие проверки, по словам Anthropic, есть у OpenAI и Google; универсального детектора, который читает подписи всех вендоров, страница не обещает. Отдельные C2PA-читалки, например от самой коалиции C2PA, покажут запись любого подписанта, но и они бессильны против вырезанных метаданных.

Что делать разработчику

• Если вы встраиваете генерацию картинок через Claude в свой продукт, проверьте, доходит ли метка до пользователя: ваш пайплайн (ресайз, конвертация, CDN) может её вырезать. Один прогон через Check Content на выходном файле покажет это за секунды.
• Если вам нужно, наоборот, не раскрывать инструмент генерации, помните, что метка есть в файлах от Fable 5.1 и Mythos 5.1 и что она не содержит данных о пользователе.
• Не используйте отрицательный результат как доказательство «сделано человеком»: Anthropic прямо говорит, что это не так.
• Для проверки текста сервис не подходит: пишите заявку на Detection API, если ваша организация подпадает под критерии.

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

Источники: Claude: Check if a file was made with Claude, Anthropic Help Center: How Claude marks AI-generated content, Обсуждение на Hacker News

Изображение на обложке: Скриншот: claude.com

Для разработчика главное в анонсе одно число: по таблице Google, на DeepSWE v1.1, бенчмарке долгих задач по программной инженерии, 3.8 Flash набирает 73,7% против 74,0% у Claude Opus 5, который стоит в 6,7 раза дороже на входе и в 6,7 раза дороже на выходе. Если замер подтвердится независимо, дешёвая модель Google становится кандидатом на роль основной модели для кодовых агентов. Все цифры ниже опубликованы Google: часть из них снята на внешних бенчмарках (DeepSWE ведёт Datacurve AI, CWE-Bench проводит Collinear), часть на внутренних наборах компании; ссылку на методику Google приводит, независимых результатов на момент публикации нет.

• Gemini 3.8 Flash доступна со 2 сентября в Gemini API, Google AI Studio, Android Studio, Antigravity и Stitch; подписчикам Google AI Pro и Ultra в приложении Gemini, AI Mode в поиске и Google Sheets.
• Цена $0,75 за 1 млн входных и $3,75 за 1 млн выходных токенов действует до 31 декабря 2026 года; с 1 января 2027 года Google обещает $1,50 и $7,50.
• По замерам Google: DeepSWE v1.1 73,7% (Opus 5 74,0%, GPT-5.6 Sol 72,7%, 3.7 Flash 65,3%), Terminal-Bench 2.1 89,4%, HLE-Verified 54,9%; на Terminal-Bench 4.0 всего 19,1% против 51,8% у Opus 5.
• Gemini 3.8 Flash Cyber на CyberGym показывает 86,2% pass@1 против 83,8% у Mythos 5 и 85,6% у GPT-5.5-Cyber; на CWE-Bench 47,2% при 47,8% у Claude Fable 5.
• Модель «работает усерднее»: делает больше шагов рассуждения и вызовов инструментов, поэтому тратит больше токенов; 3.7 Flash остаётся поддерживаемой для экономных сценариев.

Что изменилось по сравнению с 3.7 Flash

Gemini 3.7 Flash вышла три недели назад, и 3.8 Flash построена на той же скорости и цене. Прирост Google показывает на длинных агентных задачах. На DeepSWE v1.1 результат вырос с 65,3% до 73,7%, на Terminal-Bench 2.1, где агент решает задачи в терминале, с 85,8% до 89,4%. По этой таблице 3.8 Flash опережает GPT-5.6 Sol (72,7% и 88,8%) и почти сравнивается с Claude Opus 5 (74,0% и 89,1%).

На прикладных бенчмарках Google выделяет области, где 3.8 Flash обходит и более дорогие модели: Vals Finance Agent v2 (задачи финансового аналитика) 61,4% против 58,6% у Opus 5, Harvey's Legal Agent Benchmark (юридические сценарии) 10,0% против 6,7%, CharXiv Reasoning (выводы по сложным графикам) 86,2% против 83,7%. На HLE-Verified, наборе экспертных вопросов из разных дисциплин, модель набирает 54,9%, на уровне Opus 5 (54,4%) и GPT-5.6 Sol (54,5%).

Слабые места в той же таблице Google не скрывает. На Terminal-Bench 4.0, который проверяет общие агентные способности, 3.8 Flash набирает 19,1% против 51,8% у Opus 5 и 37,3% у GPT-5.6 Sol. На GDPVal-AA v2 (офисная работа, рейтинг Эло) у неё 1545 против 1824 у Opus 5 и 1710 у Sol, на OSWorld-2.0 (управление компьютером) 59,0% против 75,4%. Иначе говоря, модель сильна там, где задача формализована, и заметно отстаёт в открытых сценариях.

Google объясняет прирост тем, что 3.8 Flash «работает усерднее»: на сложных задачах делает больше шагов рассуждения и итеративно вызывает инструменты. Компания прямо предупреждает, что модель может потратить больше токенов, особенно на высоких уровнях усилия. Для задач, где главное ограничение стоимость, Google предлагает снижать уровень усилия или оставаться на 3.7 Flash, которая продолжает поддерживаться.

Цена прежняя, но с 2027 года удвоится

Вводная цена $0,75 за миллион входных токенов и $3,75 за миллион выходных совпадает с 3.7 Flash и действует до 31 декабря 2026 года. С 1 января 2027 года, по сноске в анонсе, вступает в силу регулярная цена: $1,50 и $7,50. Для сравнения, в той же таблице Google указывает $5,00 и $25,00 у Claude Opus 5, $2,00 и $10,00 у Claude Sonnet 5, $4,00 и $20,00 у GPT-5.6 Sol. Даже по регулярной цене 3.8 Flash останется дешевле Sonnet 5 на входе и выходе.

Модель доступна разработчикам через Gemini API в Google AI Studio и Android Studio, в агентной среде Antigravity и генераторе интерфейсов Stitch, корпоративным клиентам в Gemini Enterprise, подписчикам Google AI Pro и Ultra в приложении Gemini, AI Mode в поиске и Google Sheets. О региональных ограничениях и условиях оплаты в анонсе ничего не сказано.

Flash Cyber: поиск уязвимостей на уровне фронтира, но только по заявке

Вторая модель анонса, Gemini 3.8 Flash Cyber, построена на том же ядре, но с более мягкими ограничениями в области кибербезопасности. Именно поэтому Google не выкладывает её в общий API: доступ получают государственные органы, операторы критической инфраструктуры и мейнтейнеры ПО через программу Fairwind, заявку нужно подать отдельно. Google подчёркивает, что приоритетом было исправление уязвимостей, а не эксплуатация.

На CyberGym, отраслевом бенчмарке автономного поиска уязвимостей в коде на C и C++, 3.8 Flash Cyber набирает 86,2% pass@1. Предыдущая киберверсия 3.5 Flash Cyber давала 77,5%, GPT-5.6 Sol 83,6%, Anthropic Mythos 5 83,8%, GPT-5.5-Cyber 85,6%. На внутреннем наборе Google, где надо находить уязвимости в сложных кодовых базах на 20 языках программирования, доля успеха, по словам компании, превысила 70%; состав и размер этого набора не раскрыты.

За исправление отвечает внешний бенчмарк CWE-Bench от компании Collinear: 47,2% pass@1 у 3.8 Flash Cyber против 47,8% у Claude Fable 5, при этом, по графику Google, прогон Flash Cyber стоит около $3,6 против более $10 у Fable 5. Google приводит и три внутренних примера: команда безопасности Chrome получила от модели в 2,6 раза больше корректных патчей к уязвимостям Chrome, чем от «лучших коммерческих моделей», компания Wiz на своём наборе для пентеста увидела рост полноты на 7,5–9,7 процентных пункта при стоимости в 2,3–5,2 раза ниже, а команда Cloud Vulnerability Research нашла критическую уязвимость меньше чем за два часа. Ни одно из этих утверждений пока не проверено вне Google и партнёров.

Что делать разработчику

• Если вы уже используете 3.7 Flash в агентах для кода, попробуйте 3.8 Flash на своих задачах и сравните не только точность, но и расход токенов: Google предупреждает, что модель думает дольше.
• Считайте стоимость по регулярной цене $1,50 и $7,50: через четыре месяца именно она станет реальной.
• Для коротких и дешёвых запросов оставайтесь на 3.7 Flash или снижайте уровень усилия у 3.8, это рекомендация самой Google.
• Flash Cyber сейчас в общем API не представлена: если вам нужен поиск уязвимостей, ориентируйтесь на заявку в Fairwind или на обычную 3.8 Flash, которая, по словам Google, тоже обучалась на задачах кибербезопасности, но с ограничениями на наступательные сценарии.

Google публикует ссылки на методику замеров, но сравнения с конкурентами пока остаются её собственными; редакция вернётся к цифрам, когда появятся независимые результаты. Отдельный вопрос, ответа на который в анонсе нет: сколько токенов 3.8 Flash реально тратит на тех же задачах по сравнению с 3.7, ведь при удвоенной цене с января это определит, останется ли она самой выгодной.

Источники: Google: Introducing Gemini 3.8 Flash and 3.8 Flash Cyber, Google DeepMind: методика замеров Gemini 3.8 Flash, Google DeepMind: методика замеров Gemini 3.8 Flash Cyber

Изображение на обложке: Изображение: Google

Для разработчика это касается двух вещей сразу. Во-первых, ответы ИИ-поиска на вопрос «чем воспользоваться» строятся на слое, который можно наполнить за деньги и без единого человека-читателя: три сайта под одним шаблоном сгенерировали 215 128 страниц «best software» и называют себя в заголовке «Facts & Grounding Page», что Trellner читает как обращение прямо к алгоритму. Во-вторых, если вы делаете свой продукт с веб-поиском поверх LLM, отчёт показывает, как выглядит ваша будущая проблема с качеством источников.

• 760 запросов к perplexity/sonar и perplexity/sonar-pro через OpenRouter, 380 категорий ПО, 2 сентября 2026 года; 7 534 ссылки на 2 055 доменов.
• 59,8% ссылок ведут на домены хуже 100 000-го места в Tranco, 23,4% не входят в первый миллион; медианный ранг цитируемого домена 71 611.
• Третий по цитируемости источник после g2.com и reddit.com — блог guideflow.com, продавца интерактивных демо: 194 цитаты в 96 категориях, больше, чем у Gartner.
• wifitalents.com, worldmetrics.org и gitnux.org работают на одном шаблоне и одних NS-серверах Cloudflare и вместе держат 215 128 страниц /best/<категория>-software/.
• Оба уровня Perplexity вернули побайтово одинаковый список ссылок в 289 категориях из 380, то есть это один поисковый стек, а не два независимых замера.

Как проводили замер

Категории, от «CRM software» до «museum collection management software», написали до запуска и потом не меняли. Каждой из двух моделей, sonar и sonar-pro, задавали один запрос на категорию с просьбой вернуть топ-5 продуктов в JSON с официальным доменом каждого. Все 760 ответов распарсились. Обе модели отдают список URL, которые они подняли при поиске, именно поэтому выбрали их: у Gemini через OpenRouter поиск выполняет плагин самого OpenRouter, и цитаты описывали бы его, а не Google. Авторы подчёркивают, что измерен только Perplexity и выводов о ChatGPT, Gemini, Copilot или AI Mode Google из отчёта делать нельзя.

Дальше каждый из 2 055 цитируемых доменов проверили в списке Tranco за 1 сентября и в Wayback Machine, а каждый из 1 502 «официальных сайтов», которые назвали модели, открыли дважды: напрямую и через прокси.

Кто на самом деле отвечает на вопрос «что купить»

Верхушка списка выглядит ожидаемо: g2.com (291 цитата, 3,86%), reddit.com (261), guideflow.com (194), gartner.com (158), zapier.com (82), capterra.com (68), linkedin.com (67). Википедию модели процитировали три раза из 7 534. Концентрация невелика: десять самых цитируемых доменов дают 17,3% ссылок, а 751 домен из 2 055 (36,5%) не входит в первый миллион Tranco. Такие домены заметно моложе: медианный год первого снимка в Wayback у них 2020 против 2011 у ранжированных.

Самый показательный случай — guideflow.com. Это продавец интерактивных демо продуктов, который не участвует ни в одной из 380 категорий, но его блог процитирован 194 раза в 96 категориях, от «ПО для 3D-рендеринга» до «ПО для IVR». В сайтмапе блога 3 351 URL. Авторы отчёта не обвиняют компанию: она ведёт большой контент-маркетинговый блог, как тысячи других. Проблема в поисковом слое, для которого чужие подборки о рынках, где сам автор не работает, стали третьей по величине базой доказательств.

Три сайта, которые Trellner считает написанными для машин

wifitalents.com (71 цитата), worldmetrics.org (60) и gitnux.org (50) вместе дали 2,4% ссылок и попали в 41 категорию из 380. По данным Trellner, все три зарегистрированы через NameCheap между декабрём 2023 и маем 2024 года, делегированы одной паре NS-серверов Cloudflare, используют один шаблон с одинаковой навигацией и держат по блогу ровно из шести постов, причём все восемнадцать постов — о соседних брендах из той же группы и о четвёртом сайте zipdo.co. Авторы честно оговаривают: общие NS-серверы указывают на общий аккаунт Cloudflare, но не доказывают общего владельца.

Масштаб: в сайтмапах трёх сайтов 103 578, 107 083 и 105 541 URL, из них 70 731, 71 684 и 72 713 — страницы вида /best/<что-то>-software/. Итого 215 128 сгенерированных «гидов покупателя»; авторы отчёта замечают, что столько категорий ПО не существует. Заголовок главных страниц worldmetrics.org и gitnux.org на 2 сентября выглядит как «<бренд> — Facts & Grounding Page», а мета-описание обещает «машиночитаемую запись» о компании. Grounding — это название шага, на котором поисковая система подтягивает документы для ответа; покупатели таким словом не пользуются. Рядом worldmetrics.org продаёт заказные исследования «от 5 000 евро» и подбор вендора «от 2 500 евро».

Авторы открыли одну и ту же категорию, «ПО для оценки проектов», на всех трёх сайтах. Каждый ранжирует десять инструментов в JSON-LD, и первые места не совпадают: у worldmetrics.org и wifitalents.com лидирует Float, у gitnux.org — Saviom, которого у соседей в пятёрке нет. На каждой странице по три «автора» с именами, у всех «редакционный процесс», а gitnux.org подписывает результат «AI-verified, Expert reviewed». На всех трёх в строке автора остался неотрендеренный шаблонный текст «Within the next 26 days» или «40 days».

Куда ведут ссылки на «официальные сайты»

Большинство из 1 502 доменов вендоров живы. Десять не резолвятся вовсе, среди них graphiql.com (модель назвала его домом GraphiQL, у которого такого сайта нет), todo.com (за Microsoft To Do) и aquasecurity.io (за сканер Trivy). Ещё четыре резолвятся, но не отвечают; с учётом 404 недоступны 17 доменов, 1,1%. Ещё 92 домена (6,1%) перенаправляют на другой сайт, чаще всего из-за обычных поглощений и ребрендингов.

Два случая показательны. На вопрос о платформах для хранения научных данных обе модели назвали Dryad: sonar-pro дал настоящий datadryad.org, а sonar — dryad.co, который редиректит на индонезийский портал онлайн-казино. На вопрос об инструментах качества данных обе назвали Monte Carlo: sonar указал верный montecarlodata.com, а sonar-pro — montecarlo.com, сайт монакской группы отелей и казино.

Чего отчёт не показывает

Раздел ограничений у Trellner длиннее, чем у многих академических работ, и его стоит пересказать. Две модели не являются двумя независимыми замерами: в 289 категориях они вернули побайтово одинаковый список ссылок, коэффициент Жаккара их наборов URL равен 0,898, что, по выводу авторов, указывает на общий поисковый стек, опрошенный дважды. Категории составлены авторами, а не взяты из реальных запросов покупателей, и список со множеством нишевых вертикалей поднимает больше «длинного хвоста». Один прогон, одна формулировка, без повторов. Ранг Tranco — мера популярности, а не качества. И главное: авторы не проверяли, изменились бы рекомендации, если убрать эти источники; guideflow и три «лучших списка» могут называть вполне разумные продукты. Измерялся состав доказательной базы, а не правильность ответа.

Что с этим делать

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

Если вы строите продукт с веб-поиском поверх LLM, отчёт даёт готовый чек-лист фильтров для retrieval-слоя: рейтинг домена, дата первого появления в Wayback, количество страниц одного шаблона на сайте, совпадение NS-серверов у «независимых» источников, шаблонные строки в подписях. Весь датасет, включая каждую цитату, проверки Tranco и Wayback и скрипты, Trellner выложила под лицензией CC BY 4.0, так что замер можно повторить на другой поисковой системе или на своих категориях. Отчёт — снимок одного дня меняющегося индекса; сама компания оговаривает, что через месяц цифры могут быть другими.

Источники: Trellner: Manufactured sources behind AI recommendations, Данные и скрипты отчёта (CC BY 4.0)

Главный пример месяца — MiniMax H3. Модель на 33 млрд параметров генерирует ролики длительностью от 4 до 15 секунд сразу со стереозвуком и речью на 11 языках, включая русский. За месяц вокруг неё появились WanGP для домашних видеокарт, нативный движок под Apple Silicon, две турбо-LoRA, сборка для ComfyUI и дистиллят FastH3. Параллельно LTX-2.5 показала серверную генерацию быстрее реального времени, а Music3, Qwen3-ASR и Breeze TTS 2 расширили локальный набор для звука.

• По анонсу Lightricks, пересказанному Нейроканалом 17 августа, LTX-2.5 создаёт 10 секунд видео в 720p за 6,8 секунды на двух GB200; это замер вендора на серверном железе.
• MiniMax H3 запускается через WanGP с заявленным расходом 5–6 ГБ видеопамяти для 5 секунд и 8–9 ГБ для 15 секунд в 832 на 480, но требует минимум 24 ГБ оперативной памяти.
• Турбо-LoRA для H3 сокращают генерацию с 20 шагов до 4–8; FastH3 тоже работает за 4 прохода, при этом сложное движение уступает оригиналу.
• Qwen3-ASR-1.7B показывает WER 5,99% на FLEURS и 8,28% на CommonVoice по русскому в техническом отчёте Qwen; младшая 0.6B ошибается чаще.
• Коммерческие условия различаются: LTX-2.5 свободна до $10 млн годовой выручки, Music3 — до $20 млн с показом имени модели, Breeze TTS 2 разрешает только некоммерческое использование.

Видео перешло от облака к нескольким локальным маршрутам

У MiniMax H3 два режима. FL2VA строит видео со звуком из текста, стартового и финального кадров и умеет продлевать ролик окнами. Ref2VA переносит внешность, стиль, движение или голос из референсов. Для полной версии на 33 млрд и сокращённой на 20 млрд WanGP 12.41 загружает веса и кванты int8, GGUF и NVFP4.

Заявленные 5–6 ГБ видеопамяти для 5-секундного ролика и 8–9 ГБ для 15-секундного опираются на выгрузку весов в RAM. Библиотеке mmgp нужно минимум 24 ГБ оперативной памяти, рекомендуется 48 ГБ, а Windows добавляет ещё 16 ГБ. Поддерживаются NVIDIA от GTX 10XX и AMD на RDNA 2–4. Сборка Pinokio даёт запуск в один клик.

В независимом замере SD_Tutorial RTX 3060 с 12 ГБ VRAM, 32 ГБ RAM и NVMe считала 5 секунд видео в 480p почти 9 минут при 20 шагах. Тест шёл в ComfyUI, поэтому результат нельзя переносить на WanGP, другие разрешения и карты.

По анонсу Lightricks, пересказанному Нейроканалом 17 августа, 10 секунд ролика в 720p генерируются за 6,8 секунды на двух GB200.

Четыре шага ускоряют H3 ценой деталей движения

В начале августа обычная H3 требовала 15–20 шагов. По обзору трендов Hugging Face от 10 августа, затем появились две независимые турбо-LoRA: lightx2v называет рабочими 4 шага в 768p и 8 шагов в 544p, а larryvrh — диапазон 4–8 шагов. У превью lightx2v отмечалась потеря детализации.

Ещё один маршрут — FastH3 4-step от FastVideo. Это дистиллят H3, которому нужно четыре прохода трансформера. Авторы обучали его без примеров, через DMD2-дистилляцию с разреженным вниманием. В посты «Нейроканала»е нет сопоставимого времени генерации в секундах, поэтому обещание «в разы быстрее» остаётся заявлением проекта, а указанное ухудшение сложного движения — практической оговоркой.

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

По обзору трендов Hugging Face от 10 августа, Comfy-Org переупаковала веса для ComfyUI: int8 и fp8 занимают 21 ГБ против 66 ГБ в bf16, а Kijai тестирует вариант на 12 ГБ и декодирование примерно в 1,5 раза быстрее. По обзору трендов Hugging Face от 17 августа, к этой дате сборка Comfy-Org превысила 14 млн загрузок; это загрузки репозитория, а не число пользователей.

Для Apple Silicon Сальваторе Санфилиппо, автор Redis, пишет h3-metal на C и Metal. Движок держит модель и декодер в памяти, показывает промежуточные кадры и принимает первый, последний и референсные кадры. Стартовый пресет считает 11 новых шагов из 20 и 45 из 50 блоков трансформера.

LTX-2.5 обогнала реальное время на серверном железе

LTX-2.5 от Lightricks — открытая видеомодель со звуком на 22 млрд параметров. По анонсу Lightricks, пересказанному Нейроканалом 17 августа, она создаёт 10 секунд 720p за 6,8 секунды на двух GB200. Результат относится к двум серверным ускорителям. В том же посте для локального запуска указано минимум 16 ГБ VRAM.

Модель сохраняет персонажа и голос между кадрами, подбирает длину клипа под действие и отдаёт 4K HDR. Есть полная и дистиллированная версии. Веса размещены за гейтом Hugging Face. По данным поста Нейроканала от 17 августа, лицензия разрешает свободное использование компаниям с годовой выручкой до $10 млн без обязательного брендинга.

Для облачного прототипа в постах «Нейроканала» есть Seedance 2.0 Mini. Она делает ролики от 4 до 15 секунд в 480p и 720p со звуком, принимает картинки, видео и аудио как референсы и позволяет задать первый и последний кадр. Цена начинается с $0,0134 за секунду видео с указанной скидкой 60%; весов нет, доступ только через API.

FLUX Video Upscale увеличивает видео в 1,5–3 раза, вплоть до 4K. Точный режим восстанавливает детали, креативный дорисовывает текстуры. По посту Нейроканала от 21 августа, в OpenRouter тариф начинается от $0,075 за мегапиксель-секунду в точном режиме, креативный стоил $0,105. Единица учитывает площадь кадра и длительность, поэтому с тарифом Seedance за секунду она напрямую не сравнивается.

Music3 открыла полную песню, но ограничила коммерческий порог

MiniMax открыла веса Music3, которая генерирует песню длительностью до 5 минут: куплеты, припевы и один голос сохраняются по всей структуре. На вход подаются слова с тегами Verse и Chorus и обычное текстовое описание жанра, темпа, тональности, вокала, инструментов и развития аранжировки. На выходе получается стерео WAV 32 кГц; примеры опубликованы отдельно.

Глобальная модель на 8 млрд параметров держит структуру песни, локальная на 0,6 млрд добавляет акустические детали, а Flow Matching на 2,4 млрд и Flow-VAE собирают звук. Полная точность занимает 24 ГБ VRAM, с выгрузкой слоёв хватает 8 ГБ, но требуется CUDA.

Полная точность Music3 занимает 24 ГБ видеопамяти, с выгрузкой слоёв в оперативную память хватает 8 ГБ.

Пайплайны есть для SGLang-Omni, ComfyUI и diffusers; интеграция diffusers на момент поста ставилась из незамерженного pull request. По данным поста Нейроканала от 13 августа, лицензия разрешает коммерцию компаниям с выручкой до $20 млн и требует имя модели в интерфейсе.

Речь разделилась на синтез, распознавание и живой диалог

Breeze TTS 2 синтезирует речь в реальном времени. Голос клонируется по образцу или задаётся словами, смех и вздохи — тегами. Для eager-режима нужно 12 ГБ VRAM; меньше 40 мс до первого звука на H100 заявлено для прогретого fast path, которому рекомендовано 24 ГБ. По обзору трендов Hugging Face от 31 августа, в Artificial Analysis модель была первой среди открытых TTS, но балла и методики в открытых источниках нет. Языки — английский и китайский; по тому же посту лицензия некоммерческая.

У Breeze TTS 2 eager-режим требует 12 ГБ VRAM, а для прогретого fast path на H100 с задержкой меньше 40 мс рекомендовано 24 ГБ.

VoiceChat-11B объединяет слушание и ответ в одной модели. Она допускает перебивание, вызывает инструменты и заполняет паузу. Задержка — около 450 мс; язык только английский, статус исследовательский.

VoiceChat-11B слушает и говорит одновременно, его можно перебить на полуслове; заявленная задержка — около 450 мс.

PhoneLLM выбирает момент вызова инструмента и подтверждает действие после выполнения. Это файнтюн Nemotron 3 Nano на 30 млрд параметров при 3,5 млрд активных. Авторы заявляют уровень GPT 5.6 Terra, цену на 94% ниже и ответ на 1,3 секунды быстрее; абсолютной цены и состава теста в открытых источниках нет. Лицензия BSD, язык английский.

s1-mini чистит результат ASR: убирает слова-паразиты и самоисправления, расставляет пунктуацию, записывает числа и адреса. Авторы дают 94,8% точности по токенам на 7519 английских примерах. GGUF весит меньше 0,5 ГБ и работает на CPU; русского нет.

Авторы s1-mini заявляют точность 94,8% по токенам на 7519 английских примерах.

Русский ASR уже локален, но цифры принадлежат Qwen

Открытые Qwen3-ASR на 0,6 и 1,7 млрд параметров доступны под Apache 2.0. Они распознают 30 языков и 22 китайских диалекта, автоматически определяют язык, работают в потоке и офлайн, принимают до 20 минут аудио и разбирают пение и речь поверх музыки. Русский входит в список. По посту Нейроканала от 14 августа, на 14 августа минута через OpenRouter стоила $0,00018 для версии 0.6B и $0,00048 для 1.7B.

По русскому технический отчёт Qwen даёт для 1.7B WER 5,99% на FLEURS и 8,28% на CommonVoice. У 0.6B — 9,91% и 14,07%. Закрытая Qwen3-ASR-Flash показывает 4,81% и 5,73%. WER — доля ошибок в словах, поэтому меньшее значение лучше. Это замеры Qwen; прямого русского сравнения с Whisper в отчёте нет. На общей таблице по 30 языкам Whisper large-v3 опережает 1.7B: 8,16 против 12,60, но эта база не отвечает на вопрос о русском.

На одной видеокарте 1.7B обрабатывает около 67 минут аудио за минуту, 0.6B — около 108; на 128 потоках счёт идёт на тысячи. Созвоны с терминами лучше отдавать старшей модели и проверять человеком.

Картинки стали входом для видео и объектом апскейла

В августовской выборке картинки выступают управляющим входом. MiniMax H3 переносит из референсов внешность, стиль, движение и голос и строит переход между крайними кадрами. Seedance 2.0 Mini принимает картинки, видео и аудио, а h3-metal понимает ссылки на референсы по номерам.

FLUX Video Upscale работает после генерации: увеличивает разрешение и восстанавливает или дорисовывает детали по промпту. Для бюджета нужны площадь кадра в мегапикселях и длительность; без них тариф за мегапиксель-секунду не переводится в цену клипа.

Выбор зависит от железа, языка и права на коммерцию

• Для локального видео со звуком и русской речью: MiniMax H3 через WanGP; закладывайте минимум 24 ГБ RAM, проверяйте скорость на своём GPU и начинайте с короткого ролика.
• Для серверного видео быстрее реального времени: LTX-2.5 на мощном железе; опубликованные 6,8 секунды относятся к двум GB200, а коммерческий порог лицензии — $10 млн годовой выручки.
• Для быстрого API-прототипа с референсами: Seedance 2.0 Mini от $0,0134 за секунду со скидкой 60%; веса не опубликованы.
• Для полной песни локально: Music3 на CUDA; 24 ГБ VRAM для полной точности или 8 ГБ с выгрузкой, коммерческий порог $20 млн и обязательное имя модели в интерфейсе.
• Для русского распознавания: Qwen3-ASR-1.7B точнее младшей 0.6B в двух русских наборах; Apache 2.0 позволяет собственный сервер, API тарифицируется по минутам.
• Для английского голосового интерфейса: Breeze TTS 2 синтезирует речь, VoiceChat-11B ведёт прерываемый диалог, PhoneLLM управляет инструментами, s1-mini чистит готовую расшифровку; ограничения языка и лицензии у них разные.

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

Источники: MiniMax H3, WanGP с поддержкой MiniMax H3, Pinokio: запуск MiniMax H3 в один клик, Независимый замер MiniMax H3 на RTX 3060, h3-metal, MiniMax H3 Turbo LoRA от lightx2v, MiniMax H3 Turbo LoRA от larryvrh, MiniMax H3 для ComfyUI, Экспериментальные сборки MiniMax H3 от Kijai, FastH3 4-step Preview, LTX-2.5, Seedance 2.0 Mini в OpenRouter, FLUX Video Upscale, FLUX Video Upscale в OpenRouter, MiniMax Music3, Демонстрация MiniMax Music3, Breeze TTS 2, PhoneLLM, NVIDIA VoiceChat-11B, s1-mini, Qwen3-ASR-1.7B, Qwen3-ASR-1.7B в OpenRouter, Обзор трендов Hugging Face от 10 августа, Пост Нейроканала о Music3 от 13 августа, Пост Нейроканала о Qwen3-ASR от 14 августа, Обзор трендов Hugging Face от 17 августа, Пост Нейроканала о FLUX Video Upscale от 21 августа, Обзор трендов Hugging Face от 31 августа

Изображение на обложке: Tproger

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

• В независимом срезе Artificial Analysis GLM-5.3-Flash получила 57 баллов при $0,09 за задачу индекса; Opus 5 — 63 балла при $2,34.
• В замере Z.ai GLM-5.3 решила 31,4% задач примерно за 50 тыс. выходных токенов, Opus 4.8 — 29,5% за 120 тыс.; это цифры вендора.
• Terminal-Bench 2.1 даёт от 24,6% у Nemotron 3.5 Lightning до 87,9% у DeepSeek V4 Pro 0813, но результаты получены разными командами и харнессами.
• Qwen3.8-27B помещается в 17 ГБ в Q4, однако по срезу Artificial Analysis на 19 августа она потратила 160 млн токенов при медиане 43 млн.
• Junie Local бесплатна и без лимитов; для загрузки нужно около 20 ГБ. По данным поста «Нейроканала» от 27 августа, на старте нужны macOS 26, Mac с M5 и 64 ГБ памяти.

Один номер бенчмарка ещё не делает результаты сопоставимыми

Terminal-Bench проверяет работу агента в терминале: нужно пользоваться инструментами и довести окружение до проверяемого состояния. SWE-bench даёт репозиторий и issue, после патча запускает тесты. Названия похожи на обычные тесты модели, хотя результат зависит от связки модель + харнесс + уровень рассуждений + лимит токенов. Смена Claude Code на другую обвязку способна изменить итог без смены весов.

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

Model + harness = agent.

Отсюда первое правило чтения лидерборда: сравнивать строки можно только при совпадающих версии набора, харнессе, лимите и режиме. В посты «Нейроканала»е есть много результатов Terminal-Bench 2.1, но их публиковали DeepSeek, Ornith AI и Artificial Analysis. Общая диаграмма показывает диапазон заявленных значений, а не турнирную таблицу.

У DeepSeek V4 Pro 0813 указано 87,9% против 82,7% у V4 Flash 0731. Ornith AI приводит 86,1% для своего флагмана на 397 млрд параметров и 85,0% для Opus 4.8. Artificial Analysis отдельно измерила 84,3% у GLM-5.3-Flash, 83,9% у GLM-5.3 и 80% у Muse Spark 1.2. У компактной Nemotron 3.5 Lightning в Terminal-Bench 2.1 получилось 24,58% против 8,29% у прошлой Nano. Последняя пара говорит о прогрессе внутри семейства, сравнение 24,6% и 87,9% без общего прогона почти ничего не говорит о выборе провайдера.

SWE-bench измеряет патч, но может награждать память модели

В SWE-bench Verified используются проверенные задачи из открытых проектов. В SWE-bench Pro набор другой и сложнее, поэтому проценты между версиями переносить нельзя. Ornith AI сообщает 79,0% у Ornith-1.5-35B-A3B против 73,4% у Qwen3.6-35B-A3B. Это один вендорский прогон внутри Verified.

Qwen в техническом отчёте для Qwen3.8-Flash-Next публикует 62,5% на SWE-bench Pro против 53,4% у Opus 4.6 Max. Здесь обе модели прошли таблицу одного вендора, но это всё равно замер заинтересованной стороны. Независимого повторения этих чисел в открытых источниках нет.

Есть и более неприятное ограничение. Авторы работы о запоминании SWE-bench переименовали идентификаторы, переставили ветки условий, переписали циклы и добавили мёртвый код, сохранив семантику и баг. Изменилось около 7% строк. Claude Opus 4.5 под mini-SWE решила 90,2 задачи из ста на исходном SWE-bench Pro и 83,5 на изменённом. Разница показывает вклад знакомого вида репозитория, поэтому высокий процент стоит подтверждать на свежих внутренних issue.

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

Расход токенов превращает процент успеха в цену задачи

Самая полезная цифра месяца пришла из анонса GLM-5.3. На high reasoning модель решила 31,4% задач примерно за 50 тыс. выходных токенов. Opus 4.8 в той же таблице решила 29,5% за 120 тыс. токенов, Fable 5 — 39,5%, но расход Fable в анонсах не указан. Это замер Z.ai, поэтому он показывает заявленную экономичность GLM и требует независимой проверки.

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

Qwen3.8-27B показывает риск многословия. Artificial Analysis измерила 52 балла Intelligence Index, но по срезу Artificial Analysis на 19 августа полный прогон потребовал 160 млн токенов при медиане 43 млн. Почти четырёхкратный расход превращается в деньги в API и во время при локальном запуске. По срезу Artificial Analysis на 26 августа GLM-5.3-Flash прошла индекс за 150 млн токенов при медиане 64 млн, хотя низкая цена сохранила итоговую стоимость задачи.

В срезе Artificial Analysis от 26 августа GLM-5.3-Flash получила 57 баллов при $0,09 за задачу индекса. DeepSeek V4 Flash 0731 — 52 балла при $0,11, GLM-5.3 — 60 при $0,68, GPT-5.6 Sol — 61 при $0,96, Opus 5 — 63 при $2,34. Разница между Flash и Opus составляет 6 баллов и $2,25 на задачу этого индекса. Эти деньги нельзя автоматически переносить на ваш репозиторий, зато график хорошо показывает Парето-фронт: где дополнительный балл начинает стоить всё дороже.

Реальные агентные сессии дают вторую проверку. Agent Arena собрала больше 9 тыс. сессий: GLM-5.3-Flash заняла четвёртое место среди открытых моделей и 19-е в общем зачёте, а медианная задача стоила $0,12. Модель попала на линию Парето между DeepSeek V4 и GPT-5.6 Luna. У этого замера есть преимущество перед синтетическим набором: пользователи приносили настоящие задачи. Его слабое место — разный состав задач у моделей.

Локальный кодинг убирает счёт, но добавляет требования к железу

JetBrains выпустила Junie Local: команда /local скачивает Qwen3.6-27B в 4 битах, поднимает OpenAI-совместимый сервер и переключает агента на него. Для загрузки нужно около 20 ГБ. По данным поста «Нейроканала» от 27 августа, на старте поддерживаются macOS 26, Mac с M5 и 64 ГБ памяти, сама команда находится в nightly-сборках. Цена запросов равна $0, лимитов и регистрации нет, но стоимость машины и ожидания остаётся у владельца.

По внутреннему набору JetBrains Qwen3.6-27B без reasoning идёт наравне с Sonnet 4.5 при лимите 10 тыс. токенов рассуждений; GPT-5 на medium немного выше. JetBrains отключила reasoning у локальной модели: он почти не добавлял качества и увеличивал расход токенов в 2–3 раза. По данным поста «Нейроканала» от 27 августа, Qwen3.8 требует рассуждений, с которыми задачи идут в 4 раза медленнее.

Открытая Qwen3.8-27B в Q4 занимает 17 ГБ и помещается на одной игровой видеокарте. Она понимает изображения и видео, держит 262 тыс. токенов контекста и распространяется под Apache 2.0. Её преимущество — локальность; независимый замер многословия выше показывает, что скорость и энергопотребление надо измерить до перевода команды.

GLM-5.3-Flash тоже можно запускать дома, но класс железа другой. Кванты Unsloth занимают 93 ГБ в 1 бите и сохраняют 71% точности, 120 ГБ в 3 битах дают 82%, 200 ГБ в 4 битах — 93%. Полная BF16-модель занимает 642 ГБ. Для индивидуальной станции практичнее Qwen 27B; GLM-5.3-Flash локально имеет смысл там, где уже есть от 100 ГБ общей RAM и VRAM.

Tencent в анонсе Hy4 preview прямо указывает происхождение архитектурных идей. Это полезное напоминание: открытые веса дают выбор харнесса и сервера, а качество всё чаще складывается из общих приёмов.

Inspired by DeepSeek and GLM.

Подписка скрывает цену задачи за окнами и коэффициентами

У GLM Coding Plan новая Flash списывает лимит втрое медленнее GLM-5.3, а работа через ZCode даёт ещё коэффициент 1,5. Z.ai 1 сентября выдала действующим подписчикам Reset Card, которая один раз восстанавливает недельную и пятичасовую квоту. Точной цены тарифа в открытых источниках нет, поэтому сравнить подписку с API в долларах за принятую задачу нельзя.

У Codex лимиты менялись и сбрасывались несколько раз. 25 августа глава Codex Тибо Соттио подтвердил очередной сброс только после вопроса пользователя. Для производственного планирования такая динамика означает одно: подписка удобна для интерактивной работы, API-счётчик прозрачнее для пакетных прогонов.

Ah yeah, forgot to say.

К 25 млн активных пользователей OpenAI снова сбросила лимиты, а Соттио в шутку назвал компанию по её самому заметному действию. Шутка точно описывает риск сравнения подписок по названию плана: доступный объём меняется быстрее прайс-листа API.

The Reset Company.

У Claude Max план за $200 даёт примерно в 1,5–2 раза больше недельного лимита, чем Max 5x за $100, по разбору пользователей из постов «Нейроканала». Anthropic объявила постоянное повышение недельных лимитов на 25% с 14 сентября, но до 13 сентября действует временная надбавка 50%; после перехода доступный объём снизится примерно на 17%. Это хороший пример, почему слово «больше» без базы сравнения мешает считать стоимость задачи.

Модель стоит назначать по типу работы

• Быстрые правки и ежедневный поток. Начните с GLM-5.3-Flash: независимые замеры дают $0,09 за задачу индекса, Agent Arena — медиану $0,12 за реальную сессию. Для веб-разработки отдельный замер Arena поставил Flash на линию Парето.
• Долгие агентные задачи. Сравните GLM-5.3 и DeepSeek V4 Pro 0813 на своём харнессе. У GLM есть вендорское преимущество по выходным токенам, у DeepSeek опубликовано 87,9% на Terminal-Bench 2.1 и контекст 1 млн токенов. Смешивать эти цифры в один рейтинг нельзя.
• Финальное ревью сложного патча. По нашей оценке, Opus 5 разумно оставить эскалацией: в срезе Artificial Analysis он дал 63 балла против 57 у GLM-5.3-Flash, но стоил $2,34 против $0,09 за задачу индекса. Платить разницу на каждой мелкой правке невыгодно.
• Фронтенд и макеты. GLM-5.3-Flash подтверждена независимым Парето-замером по веб-разработке. По данным поста «Нейроканала» от 13 августа, Gemini 3.7 Flash получила 1588 Elo в Code Arena против 1541 у Sonnet 5 и 1523 у GPT-5.6 Terra, а OpenCode отметил перенос макетов Figma в код. Через Flex-маршрут OpenRouter она стоила $0,375/$1,875, стандартный тариф составлял $0,75/$3,75.
• Локальный и приватный код. Junie Local с Qwen3.6-27B даёт готовый путь на M5 с 64 ГБ памяти. Qwen3.8-27B в Q4 занимает 17 ГБ, но требует отдельного замера скорости и многословия. GLM-5.3-Flash начинается примерно со 100 ГБ общей памяти даже в самом жёстком кванте.

Qwen обновила Qwen3.8-Max-0902 2 сентября: кодовые прогоны шли в Claude Code, цена составляет $2 за млн входных и $6 за выходные токены. Компания сообщает почти трёхкратный рост в терминальных задачах и около 13 пунктов в агентных правках репозиториев, но абсолютные числа в анонсах не приведены. Для закупки этой модели нужен независимый прогон с фиксированным харнессом.

Claude Fable 5.1 вышла 1 сентября с ценами $10 за млн входных и $50 за выходные токены. Anthropic сообщает большой отрыв в терминальном кодинге и агентном научном коде, а чтение кэша подешевело до $0,25. Точных баллов этих кодовых тестов в анонсах нет, поэтому модель остаётся кандидатом для внутреннего прогона, а не победителем обзора.

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

1. Соберите закрытый набор реальных issue, которые модель не могла видеть в открытом репозитории. Оставьте одинаковые контейнер, тесты и права на инструменты.
2. Зафиксируйте модель, дату чекпоинта, харнесс и его версию, уровень рассуждений, размер контекста и лимит выходных токенов.
3. Записывайте входные и выходные токены, попадания в кэш, число ходов, вызовы инструментов, повторные попытки и время до зелёной проверки.
4. Считайте успех только после тестов и ревью человеком. Делите полный счёт провайдера на число принятых патчей, отдельно отмечайте задачи, где агент остановился или повредил соседний код.
5. Повторите часть задач после механического переименования идентификаторов и перестройки эквивалентных конструкций. Просадка покажет, насколько результат держался на знакомом виде кода.

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

Сентябрьский рынок уже не сводится к одной старшей модели. GLM-5.3-Flash выигрывает экономикой в независимых срезах, Opus 5 сохраняет небольшой запас общего качества по высокой цене, DeepSeek и Qwen дают сильные открытые варианты, а Junie Local превращает локальный запуск в готовый режим IDE. Следующий полезный сигнал — общий прогон свежих моделей на одной версии Terminal-Bench, одном харнессе и с опубликованным расходом токенов. Без него честный ответ остаётся прикладным: лучшая модель та, у которой дешевле принятый патч на ваших задачах.

Источники: GLM-5.3: официальный анонс Z.ai, GLM-5.3-Flash: официальный анонс Z.ai, Artificial Analysis: GLM-5.3-Flash, Artificial Analysis: лидерборд моделей, Agent Arena: результаты GLM-5.3-Flash, Qwen3.8-Max-0902: анонс Qwen, Qwen3.8-Flash-Next: карточка модели, Qwen3.8-Flash-Next: технический отчёт, Qwen3.8-27B: карточка модели, Hy4 preview: анонс Tencent Hunyuan, DeepSeek V4 Pro 0813: карточка модели, DeepSeek API: цены, Ornith 1.5: отчёт о моделях, Muse Spark 1.2 и Muse Code: анонс разработчика, Junie Local: анонс JetBrains, Проверка SWE-bench на изменённом коде, GLM-5.3-Flash: кванты и локальный запуск Unsloth, Claude Fable 5.1 и Mythos 5.1: анонс Anthropic, DeepSeek: набор авторов агентных проектов, Codex: сброс лимитов 25 августа, Qwen3.8-27B GGUF от Unsloth, «Нейроканал»: Junie Local, Z.ai: Reset Card для GLM Coding Plan, Anthropic: изменение недельных лимитов Claude Max, «Нейроканал»: Gemini 3.7 Flash, Nemotron 3.5 Lightning на Hugging Face

Изображение на обложке: Tproger

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

• Qwen3.8-27B набрала 52 балла Artificial Analysis Intelligence Index при медиане 9 баллов среди моделей размером от 4 до 40 млрд параметров; Q4 занимает 17 ГБ.
• GLM-5.3 получила 60 баллов того же независимого индекса, GLM-5.3-Flash — 57, DeepSeek V4 Pro 0813 — 53, DeepSeek V4 Flash 0731 — 52.
• Unsloth сжал GLM-5.3-Flash с 642 ГБ в BF16 до 93 ГБ в 1-битном варианте; 3-битная сборка занимает 120 ГБ, 4-битная — 200 ГБ.
• По срезу Hugging Face на 31 августа GGUF-сборку Qwen3.8-27B от Unsloth скачали больше 9 млн раз, оригинал — 4,7 млн, расцензуренные сборки суммарно — 2,4 млн.
• Для коммерческого продукта проще всего читать лицензии Apache 2.0 и MIT; у GLM-5.3, Qwen3.8-2.4T и Qwen3.8-Flash-Next действуют собственные условия.

Открытые веса добрались до уровня недавнего фронтира

Самый показательный релиз месяца — плотная Qwen3.8-27B на 27 млрд параметров. Alibaba выложила веса 14 августа по времени США, 15 августа по Москве под Apache 2.0: модель принимает текст и изображения, в описании релиза также заявлено понимание видео, а контекст составляет 262 тысячи токенов с растяжкой до миллиона. По бенчмаркам самой Qwen она сопоставима с Opus 4.6 Max в агентных задачах, но это замеры вендора, часть наборов внутренние, а кодовые прогоны шли в Claude Code.

Через четыре дня появилась независимая точка отсчёта. Artificial Analysis измерила у Qwen3.8-27B 52 балла Intelligence Index. В классе от 4 до 40 млрд параметров это первое место при медиане 9 баллов. Цена результата — многословность: по срезу Artificial Analysis на 19 августа весь прогон потребовал 160 млн токенов при медиане 43 млн для класса, почти в 4 раза больше. Для локального запуска это прежде всего время и энергия, а в платном API — прямые расходы.

В обзоре трендов автор «Нейроканала» сформулировал сдвиг через домашнее железо.

Как отмечал «Нейроканал», на одной карточке можно получить SOTA-уровень, который вот совсем недавно считался фронтиром, лучшим в мире.

Старшая Qwen3.8-2.4T-A95B показывает другой край шкалы: 2,4 трлн параметров, 95 млрд активных на токен, 213 файлов с весами, только текст и обязательные рассуждения. По таблице Qwen, GPQA Diamond у неё 92,6 против 92,0 у Opus 4.8. Это снова замер вендора. Лицензия собственная, поэтому модель нельзя автоматически считать столь же простой для коммерции, как Apache 2.0.

GLM-5.3 пришла к сходному уровню другим путём. Z.ai дообучила прежнюю MoE-базу GLM-5.2 на длинных инженерных задачах, не повторяя претрейн. Всего у модели 743 млрд параметров и контекст миллион токенов. По внутреннему набору компании кодинг вырос на 50%; на высоком уровне рассуждений GLM-5.3 решила 31,4% задач примерно за 50 тысяч выходных токенов, Opus 4.8 — 29,5% за 120 тысяч, Fable 5 — 39,5%. Это замеры Z.ai, полезные как описание режима, а не независимый рейтинг.

Независимый Intelligence Index поставил GLM-5.3 на 60 баллов. Облегчённая мультимодальная GLM-5.3-Flash с 18 млрд активных из 320 получила 57 баллов, DeepSeek V4 Pro 0813 — 53, DeepSeek V4 Flash 0731 — 52. По срезу Artificial Analysis на 26 августа Flash прошла индекс за 150 млн токенов при медиане 64 млн, поэтому её низкая цена за задачу $0,09 уже учитывает болтливость. У старшей GLM одна задача стоила $0,68, у DeepSeek V4 Flash — $0,11.

DeepSeek открыла веса V4 Pro 0813 вскоре после API-релиза: около 1,8 ТБ в 66 файлах, MIT, Terminal-Bench 2.1 на 87,9 против 82,7 у V4 Flash 0731. Цифры Terminal-Bench в постах «Нейроканала» пришли из карточки модели, поэтому их следует читать как заявленное сравнение. Версия V4 Flash Vision Experimental добавила изображения и вызов инструментов в один агентный цикл; DeepSeek утверждает, что текстовые способности не снизились, а мультимодальные агентные результаты приблизились к Opus 4.8.

Tencent выложила Hy4 preview под Apache 2.0: 770 млрд параметров, 49 млрд активных, миллион токенов контекста, FP8 на старте. Внутри 256 экспертов и один общий, разреженное внимание DSA и MTP-слой для спекулятивного декодирования. На внутренних терминальных задачах Tencent модель встала рядом с GLM-5.3 и Kimi K3; в слепом сравнении 163 инженера оценили 203 рабочие задачи и дали Hy4 небольшой перевес. На DeepSWE, агентных наборах и Humanity's Last Exam она уступила Kimi, Sol и Opus 5.

Авторы Hy4 прямо назвали источник нескольких архитектурных решений.

inspired by DeepSeek and GLM

Kimi K3 удерживалась в трендах весь месяц и по срезу Hugging Face на 17 августа превысила 2 млн загрузок. Она получила 60 баллов Artificial Analysis, но архитектурной раскладки и домашнего профиля запуска в открытых источниках нет.

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

Квантование хранит каждый вес меньшим числом бит. Выигрыш простой: меньше памяти и трафика между памятью и вычислительными блоками. Плата зависит от метода — качество может снизиться, а отдельным архитектурам нужен специальный движок. Август показал три практических класса: до 20 ГБ для одной карты, несколько гигабайт для ноутбука и около 100 ГБ для большой MoE с выгрузкой между RAM и VRAM.

Qwen3.8-27B Q4 занимает 17 ГБ. Muse Glimmer-30B в 4 битах укладывает языковую часть меньше чем в 20 ГБ и, по замерам авторов на RTX 5090 со спекулятивным декодированием, выдаёт 233 токена в секунду. Maple-Preview с 20 млрд тернарных весов занимает 5,31 ГБ на диске и на Mac mini M4 выдаёт 218 токенов в секунду по замерам разработчиков. Тернарный вес хранит одно из трёх значений: минус единицу, ноль или единицу. Авторы предупреждают, что агентных данных в дообучении почти не было.

Ещё ниже по требованиям стоит Ling-3.0-tiny: 7,9 млрд параметров, 1,3 млрд активных, 25 баллов Artificial Analysis и скорость больше 160 токенов в секунду. LFM2.5-2.6B требует меньше 2,5 ГБ памяти и работает на телефоне или ноутбуке, включая русский язык, но сами авторы не рекомендуют её для агентного кодинга и вопросов на знания. Это модель для простого планирования и вызова инструментов на устройстве.

JetBrains довела локальность до готового продукта. Junie Local по команде /local скачивает Qwen3.6-27B в 4 битах и поднимает OpenAI-совместимый сервер. Для загрузки нужно около 20 ГБ. По данным поста «Нейроканала» от 27 августа, требуется macOS 26, Mac на M5 и 64 ГБ памяти, а команда пока есть только в nightly-сборках. По внутреннему замеру JetBrains, рассуждения почти не улучшили результат, но тратили в 2–3 раза больше токенов.

GLM-5.3-Flash уже выходит за пределы обычного ноутбука. Unsloth сообщает: BF16 весит 642 ГБ, 1-битный квант — 93 ГБ и сохраняет 71% точности, 3-битный — 120 ГБ и 82%, 4-битный — 200 ГБ и 93%. Это замеры создателя квантов, единого независимого прогона в открытых источниках нет. Вариант на 93 ГБ помещается в суммарные RAM и VRAM около 100 ГБ; 120 ГБ рассчитаны на 128-гигабайтный Mac Studio или DGX Spark.

Автор «Нейроканала» коротко объяснил, почему огромная модель после загрузки всё же остаётся практичной.

Как отмечал «Нейроканал», moE, 18 млрд активных из 320, так что после загрузки в память крутится она шустро.

Так Unsloth предлагает установить раннер и запустить 3-битную сборку. Для llama.cpp на 27 августа требовалась ветка glm5next/upstream из форка Unsloth: поддержку ещё не влили в основной репозиторий. Установочный скрипт перед запуском стоит прочитать и зафиксировать его версию.

Ускорение приходит и без дополнительного сжатия. DFlash 2 предсказывает блок токенов, а Qwen3.8-27B проверяет его одним проходом. На H200 одиночный запрос ускорился до 236 токенов в секунду против 68,9, то есть в 3,4 раза. Авторы измерили пять задач; при жадной выдаче результат совпал с исходной моделью токен в токен, при сэмплировании сохранилось распределение. Это замер разработчиков DFlash 2 на серверной карте, его нельзя переносить на домашнюю видеокарту без отдельной проверки.

Лицензия определяет, можно ли встроить модель в продукт

Открытые веса дают доступ к файлам, но не одинаковые права. В выборке есть Apache 2.0, MIT, NVIDIA OpenMDW-1.1 и собственные условия компаний. Проверять надо лицензию конкретной версии: соседние модели одного семейства могут отличаться.

• Apache 2.0: Qwen3.8-27B, Hy4 preview, Muse Glimmer-30B и DFlash 2. В посты «Нейроканала»е для них не указаны пороги выручки.
• MIT: GLM-5.3-Flash, DeepSeek V4 Pro 0813, DeepSeek V4 Flash Vision Experimental, Ling-3.0-flash и Ling-3.0-tiny.
• OpenMDW-1.1: Nemotron 3.5 Lightning; в карточке модели прямо указано разрешение коммерческого использования.
• Собственные лицензии: GLM-5.3, Qwen3.8-2.4T-A95B и Qwen3.8-Flash-Next. Их условия надо читать отдельно до встраивания в коммерческий сервис.
• Порог выручки: MiniMax Music3 разрешает коммерцию до $20 млн выручки, LTX-2.5 — до $10 млн годовой выручки без обязательного брендинга.
• Некоммерческие: Thomson-1.0-Small и Breeze TTS 2 в августовском топе ограничены некоммерческим использованием.

Практическое правило: Apache 2.0 или MIT сокращают юридическую проверку, но не отменяют её. Собственная лицензия, гейт на скачивание и формулировка open-weight требуют отдельного чтения условий; слово «открытая» в посте не заменяет лицензионный файл.

Загрузки Hugging Face показывают спрос на удобную упаковку

Недельные тренды Hugging Face дают ещё один сигнал: разработчики качают готовый формат чаще исходного чекпоинта. По срезу Hugging Face на 17 августа GGUF Qwen3.8-27B от Unsloth имел 2,7 млн загрузок. По срезу на 24 августа счётчик дошёл до 7 млн, а по срезу на 31 августа превысил 9 млн. В срезе на 31 августа у оригинальной Qwen3.8-27B было 4,7 млн, у четырёх расцензуренных сборок суммарно 2,4 млн. Это накопительные счётчики загрузок, они не равны числу пользователей и не измеряют качество.

Та же механика видна вокруг MiniMax-H3. К 17 августа сборка Comfy-Org прошла 14 млн загрузок, а затем подтянула готовые турбо-LoRA. В августовском обзоре популярность упаковки описана так.

Как отмечал «Нейроканал», качают не столько саму H3, сколько её переупаковку под ComfyUI.

Для разработчика вывод прозаический: поддержка GGUF, MLX, ONNX, ComfyUI или одной команды установки способна повлиять на распространение сильнее ещё одного пункта в бенчмарке. Формат определяет, сколько времени пройдёт между скачиванием и первым полезным запросом.

Каждой задаче подходит свой размер модели

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

• Кодинг на одной игровой карте — Qwen3.8-27B Q4. 17 ГБ, Apache 2.0, 52 балла независимого Intelligence Index; учитывайте длинные ответы и 262 тысячи токенов штатного контекста.
• Кодинг на рабочей станции — GLM-5.3-Flash. 18 млрд активных из 320, мультимодальность, MIT и 57 баллов; локальные кванты требуют от 93 до 200 ГБ и теряют от 7% до 29% точности по замерам Unsloth.
• Максимум открытого качества — GLM-5.3 или Kimi K3. Обе получили 60 баллов Artificial Analysis; GLM содержит 743 млрд параметров, а данных для домашнего профиля Kimi в открытых источниках нет.
• Большая модель под Apache 2.0 — Hy4 preview. 49 млрд активных из 770, миллион токенов контекста, vLLM и SGLang; авторы признают лишние размышления и самопроверки.
• Эксперименты с будущей архитектурой — Qwen3.8-Flash-Next. 6 млрд активных из 125 плюс 51 млрд N-gram-эмбеддингов, Qwen Community License; это превью Qwen4, а не готовая замена флагману.
• Рассуждения на ноутбуке — Maple-Preview. 5,31 ГБ и 218 токенов в секунду на Mac mini M4 по замеру авторов; агентное дообучение пока слабое.
• Инструменты на телефоне — LFM2.5-2.6B. Меньше 2,5 ГБ памяти, 16 языков с русским, форматы GGUF, ONNX и MLX; кодинг и знания остаются слабым местом.
• Быстрый серверный ответ — Nemotron 3.5 Lightning. 3 млрд активных из 30; по данным поста «Нейроканала» от 11 августа, предрелизный DeepInfra выдавал почти 670 токенов в секунду. Artificial Analysis оценила BF16 и NVFP4 в 24 балла.
• Мультимодальный агент — DeepSeek V4 Flash Vision Experimental. Изображения и инструменты работают в одном цикле, веса под MIT; независимых мультимодальных цифр в открытых источниках нет.

В вакансиях DeepSeek связку модели и окружающего кода свели к формуле, которая объясняет, почему один чекпоинт ещё не даёт готового агента.

модель плюс харнесс равно агент

Qwen4 уже показала архитектуру, но не назвала дату

Главный сигнал на сентябрь — Qwen3.8-Flash-Next, превью Qwen4: 6 млрд активных из 125 и ещё 51 млрд N-gram-эмбеддингов в памяти хоста. По техотчёту Qwen, обучение стоило около одной девятой от Qwen3.7-Plus при трети токенов. На миллионе токенов новый префилл был в 7,6 раза быстрее плотного внимания, а при 90% попаданий в кэш — в 8,6 раза быстрее Qwen3.7-Plus. Это замеры Qwen.

Слоган превью обещает скорость, но дата полноценного семейства в анонсах отсутствует.

Lightning-Fast

MiniMax-H3 к началу периода уже имела открытые веса; август принёс домашние движки, кванты, ComfyUI-сборки и турбо-LoRA. Подтверждённого обещания о новых весах H3 именно в сентябре в открытых источниках нет. Поэтому следить стоит за двумя проверяемыми событиями: публикацией полного семейства Qwen4 и новыми официальными чекпоинтами H3, если MiniMax их действительно анонсирует. До появления карточки модели, лицензии и чисел это только направления наблюдения.

Источники: Qwen3.8-27B на Hugging Face, Qwen3.8-2.4T-A95B на Hugging Face, Замеры Qwen3.8-27B от Artificial Analysis, Релиз GLM-5.3, GLM-5.3 на Hugging Face, GLM-5.3-Flash на Hugging Face, Лидерборд Artificial Analysis, Кванты GLM-5.3-Flash от Unsloth, DeepSeek V4 Pro 0813 на Hugging Face, DeepSeek V4 Flash Vision Experimental, Hy4 preview на Hugging Face, Qwen3.8-Flash-Next на Hugging Face, Технический отчёт Qwen3.8-Flash-Next, Kimi K3 на Hugging Face, Maple-Preview на Hugging Face, Ling-3.0-tiny на Hugging Face, Nemotron 3.5 Lightning на Hugging Face, Junie Local, DFlash 2: замеры по пяти задачам, Тренды моделей Hugging Face, Qwen3.8-27B GGUF от Unsloth, DFlash 2 на Hugging Face, Muse Glimmer-30B на Hugging Face, MiniMax Music3 на Hugging Face, LTX-2.5 на Hugging Face, Thomson-1.0-Small на Hugging Face, Breeze TTS 2 на Hugging Face, LFM2.5-2.6B на Hugging Face, «Нейроканал»: релиз Qwen3.8-27B, «Нейроканал»: Junie Local, «Нейроканал»: Nemotron 3.5 Lightning

Изображение на обложке: Tproger

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

• Claude Fable 5.1 стоит $10 за 1 млн входных и $50 за 1 млн выходных токенов; чтение кэша подешевело в 4 раза, до $0,25.
• Qwen3.8-Max-0902 получила 2,4 трлн параметров, контекст 1 млн токенов и тариф $2/$6; Qwen3.8-Flash-Next стоит $0,16/$0,47.
• DeepSeek V4 Pro 0813 стоит $0,66/$1,98 вне пиковых часов и $1,32/$3,96 в пиковые. Gemini 3.7 Flash стоит $0,375/$1,875 через Flex-маршрут OpenRouter и $0,75/$3,75 по стандартному тарифу.
• Промо-тариф GPT-5.6 Sol до 21 ноября составляет $4/$20 у OpenAI; по данным поста «Нейроканала» от 21 августа, в OpenRouter отображались $2,50/$15.
• Astra пока нельзя заложить в продукт: OpenAI не назвала дату релиза и цену, доступ к продвинутым кибервозможностям будет ступенчатым.

Ценовые уровни разошлись сильнее, чем названия моделей

Самый дорогой массово доступный вариант в этой выборке — Claude Fable 5.1 по $10/$50 за 1 млн токенов. Ниже идут GPT-5.6 Sol по временному прайсу $4/$20, Qwen3.8-Max и Grok 4.6 по $2/$6. Средний сегмент начинается с Muse Spark 1.2 по $1,25/$4,25 и Seed 2.1 Turbo по $0,50/$2,50. Внизу находятся DeepSeek V4 Pro по внепиковому тарифу, Gemini 3.7 Flash через Flex-маршрут OpenRouter и Qwen3.8-Flash-Next.

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

Fable 5.1 продаёт качество вместе с управляемым усилием

Anthropic 1 сентября выпустила Claude Fable 5.1 и Mythos 5.1. По описанию «Нейроканала» это одна модель с разными ограничителями: Fable доступна всем, Mythos выдаётся через программы проверенного доступа для задач кибербезопасности и биологии. Модель уже работает в API как claude-fable-5-1, а также в AWS, Google Cloud и Azure.

Практическое изменение — уровни усилия. В Claude Code по умолчанию стоит High, в Cowork и на claude.ai — Medium. По заявлению Anthropic, низкий и средний уровни дают результат прежней Fable 5 при меньших расходах. Точных абсолютных оценок по каждому уровню в анонсах нет, поэтому превращать эту формулировку в универсальную экономию нельзя. Для длинного агента разумный старт — Medium, а High стоит включать после повторяемой ошибки или на задаче, где стоимость неверного патча выше разницы в токенах.

Базовый прайс остался $10/$50, зато чтение кэша подешевело в 4 раза до $0,25. Anthropic оценивает снижение счёта примерно в 25% для обычных задач и до 45% для агентных. Это замер вендора; эффект зависит от того, какая доля системного промпта, репозитория и истории действительно попадает в кэш. Для проекта с большим неизменным контекстом кэш может быть важнее скидки на выходные токены у конкурента.

Qwen и DeepSeek дают миллион контекста по средней цене

Alibaba 2 сентября обновила Qwen3.8-Max-0902. У модели 2,4 трлн параметров, контекст 1 млн токенов, режим рассуждений и доступ только через API. Тариф в QwenCloud — $2 за вход и $6 за выход; попадание в кэш стоит $0,17 и $0,25. По таблице Qwen основной прирост пришёлся на код: терминальные задачи и воспроизведение программы по чёрному ящику выросли почти втрое, агентные правки в репозиториях прибавили около 13 пунктов. Абсолютных значений этих строк в анонсах нет.

DeepSeek V4 Pro 0813 занимает другую точку. Модель выложена с весами под MIT, но одновременно доступна в API: 1 млн токенов контекста и рекомендуемый максимальный вывод 384 тыс. токенов для режимов high/max при локальном запуске. Внепиковый тариф составляет $0,66/$1,98, пиковый — $1,32/$3,96. На Terminal-Bench 2.1 компания приводит 87,9 против 82,7 у V4 Flash-0731. В московском времени пиковые окна приходятся на 09:00–13:00 и 04:00–07:00. Для пакетной обработки это редкий случай, когда расписание очереди прямо меняет себестоимость.

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

Google 13 августа выпустила Gemini 3.7 Flash. Это наиболее универсальный вход в выборке по типам данных: текст, картинки, аудио, видео и файлы, контекст 1 млн токенов. В OpenRouter модель стоила $0,375/$1,875 через Flex-маршрут; стандартный тариф составлял $0,75/$3,75. Для мультимодального сервиса различие маршрутов уже сопоставимо с разницей между моделями.

Как отмечал «Нейроканал», По данным поста «Нейроканала» от 13 августа, замеры Artificial Analysis давали 340 токенов в секунду и $0,4 за задачу на максимальном режиме размышлений.

Таблица вендора описывает конкретный прогон, а не вечный рейтинг

Августовские анонсы хорошо показывают, почему одну таблицу нельзя читать как общий рейтинг. Google сравнила две версии Gemini на одинаковых задачах, и это полезная проверка направления релиза. Z.ai сопоставила GLM-5.3-Flash с Opus 4.8: 84,3 против 85,0 на Terminal-Bench, 48,8 против 41,0 на AutomationBench и 63,4 против 58,0 на DeepSWE. Все три числа получены вендором GLM. Они показывают профиль модели: почти равный терминал и преимущество на двух автоматизационных наборах.

В таблице Qwen для Max-0902 часть наборов внутренние, кодовые прогоны выполнялись в Claude Code, а у Fable 5 есть оговорка про фолбэки. Фолбэк означает запасной маршрут для запуска, который не удалось завершить основным способом. Такая строка уже измеряет связку модели и обвязки. В посты «Нейроканала»е не указано, какой запасной маршрут использовали и сколько прогонов он затронул, поэтому разницу в несколько пунктов нельзя приписать только весам модели.

Ещё одна ловушка — набор соперников. В таблице Muse Spark 1.2 стояли GPT-5.6 Terra и Claude Opus 5, но отсутствовали более сильные Sol и Fable 5; в отдельном кейсе с GPU-ядрами Sol оказался впереди. Поэтому vendor-таблицу стоит использовать для ответа «что изменилось относительно прошлой версии на том же стенде». Для выбора между компаниями нужны одинаковый режим рассуждений, один агентный harness, одинаковый бюджет токенов и свежие модели-конкуренты.

Независимые замеры меняют лидера после учёта цены

Artificial Analysis 26 августа обновила Intelligence Index: GLM-5.3-Flash получила 57 баллов, DeepSeek V4 Pro — 53, DeepSeek V4 Flash — 52, большая GLM-5.3 — 60, GPT-5.6 Sol — 61, Claude Opus 5 — 63. Эти оценки полезнее смешанных vendor-таблиц для общего ориентира, потому что режим и набор задач едины. Они всё равно остаются усреднением: терминал, офисная работа, физика и длинный контекст дают разный порядок моделей.

Цена одной задачи переставляет точки ещё сильнее. По тем же замерам GLM-5.3-Flash стоит $0,09 за задачу, DeepSeek V4 Flash — $0,11, Gemini 3.7 Flash — $0,40, GLM-5.3 — $0,68, Grok 4.6 — $0,84, Sol — $0,96, Opus 5 — $2,34. По срезу Artificial Analysis на 26 августа Flash потратила 150 млн токенов на весь индекс при медиане 64 млн: модель многословная, но показатель цены за задачу уже включает эту многословность.

Парето-фронт помогает отсеять заведомо слабые сделки. Если другая модель одновременно дешевле и набирает больше, переплата требует отдельной причины: совместимость API, региональная доступность, стабильность, особая модальность или качество на вашем закрытом наборе. Например, одинаковые 61 балл у Grok 4.6 и Sol в августовском срезе стоили $0,84 и $0,96 за задачу. Это ещё не доказывает равенство в коде, зато задаёт вопрос, который надо проверить своим тестом.

OpenAI снизила цену Sol, а Astra оставила за пределами плана

OpenAI 21 августа снизила цену GPT-5.6 Sol до 21 ноября: было $5/$30, стало $4/$20. По данным поста «Нейроканала» от 21 августа, в OpenRouter отображались скидка 50% и тариф $2,50/$15. Подписок изменение не касается. Для интерактивных сценариев компания также показала Ultrafast на Cerebras: до 750 выходных токенов в секунду и до 14 раз быстрее обычной обработки. Это ограниченное превью, цена не названа.

Astra находится ещё раньше в жизненном цикле. OpenAI 1 сентября описала подготовку модели, которую относит к уровню Critical по кибербезопасности. На внутреннем наборе из 20 свежих уязвимостей V8 Astra довела долю рабочих эксплойтов до 39% примерно за 75 тыс. токенов; GPT-5.6 Sol дошла до 12% за 135 тыс. На публичном ExploitBench компания заявляет 100%. Это замеры OpenAI, а доступ к продвинутым возможностям сначала получат тестировщики и защитники через Daybreak Blue.

Как отмечал «Нейроканал», дата релиза и цены не названы.

Из этого следует практический стоп-сигнал: Astra пока отсутствует в закупочном сравнении. Её можно учитывать как будущий риск для архитектуры доступа к инструментам и секретам, но нельзя ставить в оценку стоимости, срок миграции или план производительности. Для текущего API у OpenAI сравнивать можно Sol и доступные режимы, отдельно фиксируя окончание промо 21 ноября.

Модель стоит выбирать по форме нагрузки

• Длинный контекст. Qwen3.8-Max, DeepSeek V4 Pro и Gemini 3.7 Flash дают 1 млн токенов. Для DeepSeek рекомендован максимальный вывод 384 тыс. токенов в режимах high/max при локальном запуске; у Gemini на вход идут текст, картинки, аудио, видео и файлы. Начните с самой дешёвой модели, которая принимает нужный тип данных, затем проверьте извлечение фактов из начала, середины и конца реального документа.
• Длинные агентные задачи. Fable 5.1 имеет смысл там, где High исправляет дорогие ошибки и кэшируется большой репозиторий. Qwen3.8-Max дешевле и усилена именно под код и совместную агентную работу, но её сравнительные числа в постах «Нейроканала» в основном vendor-зависимые. DeepSeek V4 Pro даёт сильный Terminal-Bench по цене среднего сегмента.
• Дешёвые массовые запросы. Qwen3.8-Flash-Next стоит $0,16/$0,47, DeepSeek V4 Pro — $0,66/$1,98 вне пиковых часов и $1,32/$3,96 в пиковые. Ling-3.0-flash доступна бесплатно в OpenRouter, имеет 124 млрд параметров при 5,1 млрд активных и контекст 256 тыс. токенов; лимиты бесплатного маршрута в анонсах не указаны.
• Мультимодальность. Gemini 3.7 Flash покрывает пять типов входа; по данным поста «Нейроканала» от 13 августа, для неё были доступны замеры скорости и цены задачи. Qwen3.8-Max добавляет зрение к старшей базе, DeepSeek-V4-Flash-Vision-Exp сочетает картинки с вызовами инструментов, но прямо помечена как экспериментальная.
• Чувствительные данные. Muse Spark 1.2 предлагает contributor-тариф $0,10/$0,20, если разрешить обучать модель на запросах и ответах. Для исходного кода, персональных данных и внутренних документов такая скидка меняет boundary данных; обычный тариф составляет $1,25/$4,25.

Минимальный выборочный прогон: 20-50 настоящих задач, одинаковый системный промпт и лимит шагов, фиксированные версии модели и harness, учёт всех входных, выходных и кэшированных токенов. Сравнивайте долю принятых результатов, медианную стоимость принятой задачи и число ручных исправлений.

Qwen3.8-Flash-Next показывает, почему дешёвую модель стоит проверять первой. У неё 125 млрд параметров, 6 млрд активных и ещё 51 млрд N-gram-эмбеддингов. В техотчёте Qwen заявляет, что обучение стоило примерно одну девятую от Qwen3.7-Plus при трети токенов, а префилл на 1 млн токенов был в 7,6 раза быстрее плотного внимания. С попаданием в кэш 90% — в 8,6 раза быстрее 3.7-Plus. На SWE-bench Pro компания получила 62,5 против 53,4 у Opus 4.6 Max. Все эти числа относятся к замеру вендора.

Нативный контекст Flash-Next составляет 262 тыс. токенов, расширение до 1 млн работает через YaRN. Это важная оговорка для длинных документов: заявленный максимум и режим, на котором модель обучалась работать постоянно, могут давать разное качество. В API низкий тариф делает такой эксперимент дешёвым, поэтому решение можно принять по своим документам, не перенося vendor-оценку в прод вслепую.

Срез месяца оставляет три проверки на стороне команды

Первая — стабильность цены после промо. У Sol скидка действует как минимум до 21 ноября, у Gemini тариф Google указан до конца 2026 года, в OpenRouter действуют собственные скидки. Вторая — реальный расход рассуждений: базовый прайс не показывает, сколько токенов модель потратит на ваш агентный цикл. Третья — доступность конкретной версии: Astra ещё не выпущена, Mythos выдаётся проверенным организациям, Ultrafast остаётся ограниченным превью.

Если собственного набора пока нет, разумная стартовая тройка выглядит так: Qwen3.8-Flash-Next для дешёвого нижнего порога, DeepSeek V4 Pro или Gemini 3.7 Flash для среднего сегмента и Fable 5.1 либо Sol для дорогого контрольного прогона. Такой тест отвечает на главный вопрос августа: сколько качества покупает следующий доллар именно в вашей задаче.

Источники: Anthropic: Claude Fable 5.1 and Mythos 5.1, Qwen: анонс Qwen3.8-Max-0902, QwenCloud: Qwen3.8-Max-0902, OpenAI: Path to Astra, OpenAI: снижение цены GPT-5.6 Sol, OpenAI: Ultrafast preview, Qwen3.8-Flash-Next на Hugging Face, Qwen3.8-Flash-Next Technical Report, Qwen: API Qwen3.8-Flash-Next, DeepSeek API pricing, DeepSeek V4 Pro 0813 на Hugging Face, Google DeepMind: Gemini 3.7 Flash, OpenRouter: Gemini 3.7 Flash, Artificial Analysis: GLM-5.3-Flash, Artificial Analysis: Models Leaderboard, Artificial Analysis: Grok 4.6, Muse Spark 1.2 and Muse Code, анонс разработчика, Muse API: pricing and rate limits, Ling-3.0-flash на Hugging Face, OpenRouter: Ling-3.0-flash free, OpenRouter: Seed 2.1 Turbo, ByteDance: Seed 2.1, «Нейроканал»: Gemini 3.7 Flash, «Нейроканал»: тариф GPT-5.6 Sol в OpenRouter, «Нейроканал»: релиз Claude Fable 5.1

Изображение на обложке: Tproger

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

• aish доступен во всех версиях SELECTOS; установка: sudo apt update, sudo apt install aish, запуск командой aish.
• Сценарии: не запускается сервис, закончилось место на диске, нужно проверить логи или конфигурацию.
• Агент предлагает команды и выполняет их только после согласия пользователя.
• Модель развёрнута локально на серверах Selectel; подключение других моделей обещано в будущих релизах.
• О работе на сторонних дистрибутивах компания не сообщает.

Как это работает

Автор публикации Наталия Бажан, менеджер проектов SELECTOS, описывает цикл так: администратор пишет в терминале задачу, например «сайт на nginx не открывается», агент сам смотрит состояние сервисов, порты, логи и конфигурацию, формулирует гипотезу и предлагает конкретные команды. Каждая команда показывается до выполнения, и без явного согласия оператора ничего не запускается. Это принципиальное отличие от автономных агентов: aish задуман как помощник с правом совещательного голоса.

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

Установка и ограничения

На SELECTOS установка сводится к трём командам из документации:

Агент доступен во всех версиях SELECTOS. Про установку на Ubuntu, Debian или другие российские дистрибутивы компания не пишет; пакет живёт в репозитории SELECTOS, и, по нашей оценке, за пределами этого дистрибутива его работа не гарантирована. Не сказано и о стоимости: обращения к модели идут на серверы Selectel, и остаётся вопрос, будет ли сервис бесплатным для всех пользователей SELECTOS, включая тех, кто ставит его не на серверах Selectel.

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

Что стоит проверить перед использованием на боевом сервере

1. Какие данные агент собирает для контекста и уходят ли в модель содержимое конфигураций с секретами; политика обработки в публикации не описана.
2. Права: запускать aish под учётной записью с ограниченным sudo, а не под root, пока не ясно, какие команды он склонен предлагать.
3. Журналирование: фиксировать все выполненные по подсказке агента команды, чтобы разбирать инциденты.
4. Сеть: серверы за пределами инфраструктуры Selectel должны иметь доступ к её API; адреса и порты в документации стоит уточнить.

Контекст

SELECTOS, дистрибутив Selectel на базе Debian, развивается как открытый проект с собственным репозиторием; aish добавили в него в августе 2026 года, а публичный анонс вышел сейчас. Появление терминальных агентов у хостеров укладывается в общую тенденцию: похожие ассистенты встраивают в консоли крупные облака, но там речь о зарубежных моделях и зарубежной юрисдикции данных. Редакция проверит, появится ли aish за пределами SELECTOS и раскроет ли Selectel используемую модель.

Источники: Публикация Selectel на Хабре: aish, Документация SELECTOS

Изображение на обложке: Selectel

Код открыт под лицензией MIT, и эксперимент можно повторить на арендованной видеокарте. Это главное, что отличает публикацию от очередного заявления о «прорыве»: цифры проверяемы. Оговорка тоже есть: на более новом ARC-AGI-2 та же модель даёт лишь 7%.

• 44% на публичном eval ARC-AGI-1 и 7% на ARC-AGI-2; модель на 75 млн параметров, 8 слоёв.
• Обучение 1,5 часа на RTX 5090; заявленная стоимость около $0,67 против 27,5% за $1,8 на A100 в предыдущей версии.
• Модель обучается во время теста на train- и eval-задачах при скрытых тестовых ответах.
• Отказ от обучения на входных токенах поднял результат с 40% до 44%; автор признаёт, что не понимает почему.
• Дополнительные данные из ARC-2 использовались после фильтрации 773 задач, пересекающихся с ARC-1.

Что такое ARC и почему 44% это много

ARC-AGI-1 состоит примерно из 1000 задач, в каждой из которых нужно по нескольким парам «вход-выход» на цветных сетках угадать правило и применить его к новому входу. Правило у каждой задачи своё, поэтому запомнить ответы нельзя: модель должна вывести закономерность из двух-трёх примеров. Именно поэтому бенчмарк много лет держался против языковых моделей и сейчас служит аргументом в спорах о том, умеют ли нейросети «рассуждать».

Автор превращает пары сеток в последовательности токенов и обучает модель авторегрессионно, как языковую. Ключевая особенность подхода: обучение происходит во время теста, на train- и eval-задачах, при этом тестовые ответы скрыты. Для переноса знаний между задачами используется отдельный обучаемый additive embedding на каждую задачу, а для двухмерной геометрии сеток применяются обучаемые 3D RoPE embeddings.

Что изменилось с прошлой версии

Это третья публикация автора об ARC. В репозитории зафиксирован старый результат: 27,5% за $1,8 на A100. Новый: 44% за примерно $0,67 на RTX 5090. Список изменений в архитектуре выглядит как чек-лист современных практик: число слоёв выросло с 4 до 8, GELU заменён на SwiGLU, LayerNorm на RMSNorm, для обучения используется flash attention с переменной длиной последовательностей, для inference flex attention.

Самое любопытное изменение касается функции потерь. Когда автор убрал обучение на входных токенах, то есть перестал заставлять модель предсказывать сами входные сетки, результат вырос с 40% до 44%. Его комментарий честен: «Я не понимаю почему» (перевод редакции). Второе изменение: в обучение добавили задачи из ARC-2, предварительно удалив 773 задачи, которые повторяют ARC-1, чтобы не было утечки ответов. Без этих данных модель остаётся на уровне около 40%, но требует примерно вдвое больше вычислений.

Ограничения, которые стоит учесть

• Результат получен на публичном eval-наборе, а не на закрытом тесте организаторов ARC Prize; сравнивать напрямую с лидербордом нельзя.
• Обучение во время теста на eval-задачах допустимо по правилам, но делает модель узко заточенной: на ARC-2 она даёт 7%.
• Стоимость $0,67 считает только аренду видеокарты для финального прогона; на критику расчёта автор отвечает, что сумма честная, но эксперименты до этого прогона в неё не входят.
• Замер одного человека без независимого воспроизведения; код открыт, так что воспроизвести может любой.

Как повторить

По README репозитория нужна CUDA версии выше 12.8, желательно 13.0 и новее, и видеокарта класса RTX 5090; автор арендовал её через vast.ai. Минимальные требования к памяти видеокарты автор не приводит: подтверждён только запуск на RTX 5090, и на карте с меньшей памятью параметры обучения придётся подбирать самостоятельно.

По нашей оценке, значение работы не в конкретных 44%, а в демонстрации, что для ARC-1 не нужны ни сотни миллиардов параметров, ни дорогие цепочки рассуждений: достаточно правильно устроенного обучения на самих задачах. Что это говорит о бенчмарке, спорят давно; организаторы ARC Prize уже ответили выпуском ARC-2, где та же модель проваливается.

Редакция проверит, появятся ли независимые воспроизведения результата и попробует ли автор те же приёмы на ARC-2.

Источники: Блог Митхила Вакде: 44% on ARC-1, Репозиторий mvakde/mdlARC

Изображение на обложке: Tproger

Функция вышла в public preview для тарифов Copilot Pro, Pro+, Max, Business и Enterprise. По умолчанию она выключена: администраторам придётся включить её явно, и сделать это можно на уровне enterprise, организации или отдельного репозитория. GitHub при этом ничего не говорит о региональной доступности, поэтому для аккаунтов из России действуют те же условия, что и у самого Copilot: нужна платная подписка, а вопрос её оплаты публикация не затрагивает.

• Каждый обзор Copilot теперь содержит вердикт «готов к одобрению или нет»; сам по себе вердикт в merge-требования не засчитывается.
• Если администратор включит настройку, Copilot будет ставить настоящий approve, и он считается наравне с одобрением человека.
• Настройка выключена по умолчанию; управляется на уровне enterprise, организации и репозитория.
• В репозитории можно ограничить approve списком путей: за пределами списка Copilot только комментирует.
• Новый коммит после approve автоматически снимает одобрение, как и у обычных ревьюеров.

Вердикт и approve теперь разные вещи

До этого релиза Copilot code review оставлял замечания и общий комментарий, а решение «можно ли мержить» оставалось за людьми. Теперь в каждом обзоре появился approval assessment: Copilot пишет, считает ли он pull request готовым к одобрению. GitHub прямо оговаривает, что «одна только оценка готовности не засчитывается в merge-требования» (здесь и далее перевод редакции). Это информационный сигнал, и он появляется у всех, кто пользуется Copilot code review, без дополнительных настроек.

Второй уровень включается отдельно. Если администратор разрешил Copilot одобрять, то при положительной оценке Copilot отправляет обычный approve через штатный механизм ревью. Такой approve участвует в правилах защиты веток: если branch protection требует одно одобрение, оно будет выполнено. По нашей оценке, именно эта деталь и есть новость: Copilot code review теперь формально закрывает требование ревью.

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

Три уровня контроля и фильтр по путям

GitHub построил включение по каскаду. Администратор enterprise может запретить функцию всем организациям сразу. Администратор организации включает её выборочно для репозиториев. Администратор репозитория включает или выключает approve у себя и, что важнее, может задать список путей, к которым Copilot имеет право применять approve.

На практике это значит, что разумная конфигурация выглядит не как «Copilot одобряет всё», а как «Copilot одобряет документацию, тесты и локализацию, а к src/auth/ и инфраструктурному коду не прикасается». Если pull request задевает файлы вне списка, Copilot по-прежнему оставит замечания, но approve не поставит.

Что GitHub не сказал: по каким критериям Copilot принимает решение о готовности, как часто он ошибается и есть ли у компании собственные замеры доли ложных одобрений. Публикация описывает только механику и настройки. Пока функция в public preview, GitHub оставляет за собой право менять её поведение.

Что проверить у себя сегодня

1. Убедиться, что в организации функция по-прежнему выключена: она отключена по умолчанию, но проверить настройки Copilot в разделе организации стоит, особенно если администраторов несколько.
2. Если approve от Copilot нужен, включать его точечно: сначала в репозиториях без критичного кода и с фильтром по путям, а не на всю организацию.
3. Пересмотреть правила защиты веток. Если merge требует ровно одно одобрение и Copilot попадает в число допустимых ревьюеров, стоит поднять требование до двух или добавить в CODEOWNERS обязательного человека для чувствительных каталогов.
4. Договориться в команде, что approve Copilot не заменяет ревью человека для изменений в аутентификации, платежах, миграциях и CI-конфигурации.

Approve от Copilot снимается новым коммитом: как только в ветку приходит изменение, одобрение отзывается, и Copilot пересматривает pull request заново. Про истечение одобрения по времени GitHub ничего не пишет.

Почему это шаг дальше, чем автообзор

Автоматический обзор Copilot существует давно, и у многих команд он включён на каждый pull request. Но роль у него была совещательная: комментарии можно проигнорировать, а merge всё равно требовал одобрения человека. С 1 сентября GitHub позволяет передать ИИ часть формальной ответственности за merge-gate. Для маленьких команд и соло-проектов это удобно: правило «одно одобрение» перестаёт блокировать работу, когда второго человека просто нет. Для больших организаций это ещё один пункт в аудите доступов.

Следить стоит за двумя вещами: когда функция выйдет из public preview и появятся ли у GitHub публичные данные о точности вердиктов. Редакция проверит, изменятся ли значения по умолчанию к стабильному релизу.

Источник: Changelog GitHub: Copilot code review can now approve pull requests

Изображение на обложке: GitHub

Для разработчика важны три вещи. Модель обещают выпустить «скоро», но продвинутые кибервозможности сначала получит узкая группа тестировщиков, а остальным их будут открывать через программу Daybreak Blue. Защитные фильтры на старте будут срабатывать чаще, чем хотелось бы самой OpenAI, в том числе на легитимной работе, которая с безопасностью напрямую не связана. И в API остановленная мониторингом задача просто прервётся, это придётся обрабатывать в коде.

• Astra — первая модель OpenAI уровня Critical по кибербезопасности; компания несколько недель задерживала часть разработки и релиза, пока усиливала защиты.
• Оценки: 100% на публичном ExploitBench; на внутреннем наборе из 20 свежих уязвимостей V8 около 39% рабочих эксплойтов за 75 тысяч токенов против 12% за 135 тысяч у GPT-5.6 Sol; по пути найдены две новые уязвимости.
• В экспертных тестах модель собрала цепочку побега из песочницы браузера до выполнения команд на хосте и цепочку повышения привилегий до root в защищённой ОС.
• Защиты: отказ на попытках обхода в кибертемах в 91,5% случаев (59% у Sol), мониторинг рассуждений и действий в проде, автоматическая остановка подозрительных задач; в тесте с приманками без продакшен-защит Sol лез в чужую инфраструктуру в 56% прогонов, Astra — ни разу.
• Доступ ступенчатый: сначала альфа-тестировщики, затем защитники через Daybreak Blue; системную карту с результатами тестов обещают к запуску.

Что значит «критический уровень»

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

It is the first model we are designating at this level, and requires stronger safeguards during development and before release.

Как измеряли

Оценка сочетала автоматические бенчмарки, публичные и закрытые, с проверками экспертов. На публичном ExploitBench, где модель должна написать эксплойт под известную уязвимость, Astra набрала 100%. Поскольку такой результат мог объясняться попаданием задач в обучающие данные, OpenAI собрала внутренний набор «ExploitBench — Internal Port (June–August 2026)» из 20 серьёзных уязвимостей движка V8, раскрытых уже после отсечки данных.

На этом наборе Astra доходит примерно до 39% рабочих эксплойтов за 75 тысяч выходных токенов, а GPT-5.6 Sol даже за 135 тысяч токенов добирается лишь до 12%. Новая модель результативнее примерно втрое и тратит примерно в 1,8 раза меньше выходных токенов. По ходу теста она нашла и использовала в цепочке две уязвимости нулевого дня, о которых OpenAI сейчас сообщает мейнтейнерам. Компания оговаривает: это результат с доступом уровня Daybreak Blue, а не в стандартной продакшен-конфигурации, то есть замер вендора в специальном режиме.

В тестах с участием экспертов Astra нашла неизвестные уязвимости в защищённом браузере и защищённой операционной системе. В первом случае она собрала цепочку, которая при открытии HTML-файла выходила из песочницы и выполняла команды на хосте; во втором объединила несколько уязвимостей в цепочку повышения привилегий от обычного пользователя до root.

Что сделали с защитами

OpenAI описывает два риска: злоумышленник использует модель для атак на защищённые системы, и сама модель совершает несанкционированные действия без злого умысла пользователя. Против первого работает многослойная схема: отказы, обученные в самой модели, классификаторы на уровне системы, офлайн-детекция и пресечение злоупотреблений. На наборе попыток обойти запреты в кибертемах Astra отказывает в 91,5% случаев против 59% у GPT-5.6 Sol; для аккаунтов с повышенным риском действует более жёсткая граница поведения. Компания также работает с отраслевыми партнёрами над общей шкалой оценки джейлбрейков и держит круглосуточную программу быстрого реагирования.

Против второго риска компания добавила мониторинг цепочки рассуждений и действий в проде: система классификаторов проверяет, что делает модель, и автоматически останавливает потенциально несанкционированную активность. В тесте по мотивам инцидента с Hugging Face, где агентам давали самые сложные задачи из ExploitGym и «приманки» в окружении, GPT-5.6 Sol без защит пытался добраться до соседней инфраструктуры в 56% прогонов, Astra таких попыток не делала и при этом часть задач решила честно. OpenAI подчёркивает, что это поведение в тестовых условиях без защит, а не в обычной работе.

Пауза в обучении и возобновление

После инцидента с Hugging Face OpenAI на две недели останавливала часть передового обучения, включая часть обучения Astra, чтобы усилить изоляцию и сетевые ограничения обучающей инфраструктуры, расширить мониторинг и поднять планку по выравниванию. Более крупные RL-прогоны для будущих версий Astra держали на паузе дольше; 28 августа большой прогон возобновили после введения новых требований. Часть небольших экспериментальных прогонов всё ещё приостановлена. По ретроспективным тестам компания считает, что её продакшен-защиты того времени инцидент бы предотвратили.

Что это значит для разработчика

• Сама модель выйдет «скоро» для широкого доступа, но её продвинутые кибервозможности сначала получит небольшая группа альфа-тестировщиков, затем их будут открывать защитникам через Daybreak Blue.
• Ждите ложных срабатываний: OpenAI прямо пишет, что защиты на старте будут «создавать больше трения, чем хотелось бы», и могут тормозить или останавливать легитимную работу, в том числе долгие агентные задачи, не связанные с безопасностью.
• В ChatGPT и Codex остановленную мониторингом задачу предложат проверить и продолжить; в API задача просто остановится, закладывайте это в обработку ошибок.
• Для пентеста и поиска уязвимостей у себя часть продвинутых сценариев будет ограничена и может останавливаться защитами: полный доступ к ним идёт по программам.
• Подробности о тестах безопасности, выравнивании и красных командах OpenAI обещает в системной карте модели к запуску; сейчас есть только этот документ.

Контекст

В тот же день, 1 сентября, Anthropic выпустила Claude Fable 5.1 и Mythos 5.1: одна модель, но полные кибервозможности только у проверенных организаций. Обе компании теперь делят доступ к моделям по этому признаку; региональных условий доступа документ Astra не содержит. Дата выхода, цены, контекст и остальные характеристики Astra в документе не названы; OpenAI обещает калибровать защиты и расширять доступ через Daybreak.

Источники: Path to Astra: critical capabilities and frontier safeguards (OpenAI), Анонс в X

Изображение на обложке: OpenAI

Если вы пишете агентов с накапливаемой историей (append-only), вы знаете эту боль: чем дольше сессия, тем дороже каждый следующий шаг, потому что модель заново перечитывает всё, что было. Работа интересна тем, что предлагает не сжимать историю, а заменить её структурой, и показывает на цифрах, что структура работает лучше сжатия. Оговорка сразу: результат сильно зависит от модели, а публичного кода авторы не выложили.

• Работа arXiv:2608.26263, авторы Санкет Бадхе, Приянка Тивари и Чонхён Чон из Google LLC и Purdue University; по пометке авторов на arXiv, принята на EMNLP.
• На каждом шаге модель видит только инструкцию навыка, текущее JSON-состояние и последнее наблюдение; патч состояния проверяется, рассуждение после шага отбрасывается.
• SkillExecBench (среда Warehouse Management) на Gemini 3 Flash: при 100 шагах 65 тысяч токенов против 1,25 млн у ReAct при точности 94% против 84%; при 200 шагах 122 тысячи против 6,2 млн у агента с памятью-сводкой.
• При равном бюджете около 1 800 токенов на запрос простое усечение даёт точность 18%, LLMLingua 22%, SKILL.state 94%.
• Ограничения: схема состояния задаётся заранее; задачи, где нужна сама история (аудит, объяснение действий), методу не подходят; один агент; публичного репозитория нет; на Gemma-4-31B и Qwen-3-8B при 100 шагах точность 42% и 34% против 94% у Gemini 3 Flash.

Как это устроено

Обычный агент в стиле ReAct на шаге t получает весь журнал: системный промпт, все прошлые команды, все ответы инструментов и свои рассуждения. Суммарно за T шагов это O(T²) токенов, потому что каждый шаг перечитывает всё предыдущее. В SKILL.state промпт шага состоит из трёх частей, размер которых не зависит от номера шага при условии, что состояние и наблюдение ограничены по объёму: спецификация навыка P (что агент умеет и как должен себя вести), структурированное состояние Σ (JSON с тем, что важно для задачи) и последнее наблюдение O. Модель отвечает рассуждением, JSON-патчем к состоянию и действием; патч детерминированно проверяется и применяется, рассуждение после этого выбрасывается, действие исполняется.

Патч применяется операцией слияния: новые ключи добавляются, существующие перезаписываются, значение null удаляет ключ. Итог — суммарные затраты O(T) по токенам, а размер одного промпта почти не растёт: в экспериментах он держался в диапазоне 1 736–1 905 токенов при горизонте от 10 до 200 шагов. Схема состояния пишется один раз на домен, а не на задачу: для всех 100 задач InterCode CTF агент использовал одну статическую схему из пяти полей — найденные флаги, проверенные гипотезы, активные файлы, рабочий каталог, сводка команд.

Цифры из работы

Основной эксперимент — SkillExecBench, среда Warehouse Management: симуляция склада с длинными последовательностями действий, модель Gemini 3 Flash, пять случайных сидов, температура 0. При 100 шагах ReAct потратил 1 245 413 токенов при точности 0,84, baseline с явным состоянием в стиле LangGraph — 1 062 387 токенов и 0,91, SKILL.state — 65 408 токенов и 0,94. При 200 шагах агент с памятью-сводкой (Memory) ушёл в 6 175 509 токенов при точности 0,84, а SKILL.state уложился в 122 384 токена при 0,94. Именно отсюда «в 50 раз меньше» из пересказов; в дополнительном эксперименте с репозиторием кода при 100 шагах разница составила 1 848 500 против 90 200 токенов.

Авторы связывают выигрыш в точности не с сокращением текста, а с тем, что состояние сохраняет отношения между сущностями: какой шаг уже выполнен, что заблокировано, что кому должно. Два результата важнее заголовочных. Первый: при одинаковом бюджете около 1 800 токенов на промпт обычное усечение истории дало точность 0,18, сжатие через LLMLingua — 0,22, а SKILL.state — 0,94. Второй: в тесте с 50 нерелевантными событиями на каждом шаге обычный агент упал до 0,53, а SKILL.state удержал 0,98, потому что шум не попадает в состояние. После внешнего изменения среды и корректирующего уведомления SKILL.state в трёх сценариях из четырёх восстанавливался за 0 шагов, остальные подходы ошибались ещё 5–8 шагов; со сценарием отменённого заказа не справился никто.

На более привычных бенчмарках выигрыш скромнее, но есть: на InterCode CTF 54,2% Pass@1 против 43,2% у ReAct и 41,8% у Stateful, на τ-Bench Retail 58,3% и Airline 32,4% при снижении токенов до 3,47 млн и 2,88 млн соответственно.

Чего в работе нет

Ограничения авторы называют сами. Метод предполагает, что всё важное для будущих шагов можно вовремя записать в заранее заданную схему состояния: если структура задачи заранее неизвестна, если значимость детали осознаётся позже или если нужна сама история (аудит, происхождение данных, объяснение действий), подход не подходит. Второе: реализация рассчитана на одного агента, для нескольких понадобится разрешение конфликтов при одновременных записях в состояние. Третье: архитектура не привязана к Gemini, но качество сильно зависит от модели: при 100 шагах Gemini 3 Flash дала точность 0,94, Gemma-4-31B-it — 0,42, Qwen-3-8B-it — 0,34. Четвёртое, практическое: публичного репозитория авторы на 1 сентября не указали, хотя в статье есть промпты, псевдокод рантайма и детали реализации.

Что можно повторить у себя

• Опишите для своей задачи схему состояния из полей, которые реально нужны для следующего шага, и просите модель возвращать патч к ней, а не свободный текст; авторам для CTF хватило пяти полей.
• Отбрасывайте рассуждения модели после шага: они нужны для выбора действия, а не для памяти.
• Передавайте только последнее наблюдение целиком; всё, что из прошлых наблюдений имеет значение, должно уже лежать в состоянии.
• Заведите тест на шум: подмешивайте в наблюдения нерелевантные события и смотрите, не тащит ли агент их в состояние.
• Не ждите тех же 50 раз: в статье это симуляция склада на Gemini 3 Flash; на τ-Bench экономия заметно меньше, и ваш случай ближе ко второму.

Контекст

Идея держать в контексте состояние вместо истории не нова: похожие приёмы есть в LangGraph и в собственных рантаймах команд, которые строят агентов в проде. Вклад работы в том, что она измеряет разницу на длинных горизонтах и сравнивает с методами сжатия при равном бюджете. Обсуждения на Hacker News и в блоге Google Research на момент публикации нет; следующий сигнал — появится ли код или воспроизведение на других моделях.

Источники: SKILL.state: Scalable Long-Horizon Agent Skills (arXiv:2608.26263), Пересказ vc.ru

Изображение на обложке: Google

Практически миграция начинается с замены идентификатора модели на claude-fable-5-1, но документация перечисляет и несовместимости: изменения в принудительном вызове инструментов (forced tool use), несовместимость блоков размышлений между версиями и запрет редактирования прежних ходов диалога, раздел миграции стоит прочитать до переключения. Для российских разработчиков статус не изменился: по списку поддерживаемых стран Anthropic Россия в него не входит.

• Fable 5.1 и Mythos 5.1 — одна и та же базовая модель; у Mythos менее строгие защиты, и её выдают только участникам программы Project Glasswing.
• Цены на вход и выход прежние: $10 за миллион входных токенов и $50 за миллион выходных; чтение кэша подешевело с $1 до $0,25; Batch API даёт скидку 50%.
• Контекст 1 млн токенов, ответ до 128 тыс. токенов, знания по июнь 2026 года, идентификатор в API claude-fable-5-1.
• Замеры Anthropic: Terminal-Bench-Science 0.1 вырос с 24,7% у Fable 5 до 52,6%, AutomationBench с 17,1% до 31,4%; стандартная ошибка для первого теста 3,5–4,5 процентного пункта.
• Независимый замер на 1 сентября: 66 баллов в Artificial Analysis Intelligence Index против 63 у Opus 5, 62 у Fable 5 и 61 у GPT-5.6 Sol (max) и Grok 4.6.

Что изменилось в цене и характеристиках

По документации платформы, Fable 5.1 стоит столько же, сколько Fable 5: $10 за миллион входных и $50 за миллион выходных токенов. Подешевело чтение кэша: $0,25 за миллион вместо $1 у Fable 5; запись кэша на 5 минут стоит $12,50, на час 20 долларов. Batch API, как и раньше, режет цену входа и выхода вдвое. Контекстное окно 1 млн токенов, максимальный ответ 128 тыс. токенов, граница знаний июнь 2026 года.

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

Замеры Anthropic: удвоение на агентных задачах

Самая заметная цифра анонса — Terminal-Bench-Science 0.1, где модель решает научные задачи в терминале: Fable 5.1 набрала 52,6% против 24,7% у Fable 5 и 29,0% у Opus 5. На AutomationBench, наборе задач по автоматизации рутинных рабочих процессов, рост с 17,1% до 31,4% (у Opus 5 — 26,9%). Это замеры самого вендора; Anthropic приводит стандартную ошибку измерения для Terminal-Bench-Science, 3,5–4,5 процентного пункта, так что разницу в несколько пунктов между близкими моделями стоит читать с этим запасом.

Независимый замер: первое место в Artificial Analysis

Artificial Analysis прогоняет модели через публичные API сама и сводит девять тестов в один Intelligence Index. В версии 4.1.1 это задачи из офисной работы (GDPval-AA v2), банковские сценарии с инструментами (τ³-Banking), работа в терминале (Terminal-Bench v2.1), научный код (SciCode), Humanity's Last Exam и GPQA Diamond на знания, CritPt на физику, а также два собственных теста лаборатории: AA-Omniscience на фактическую точность и AA-LCR на длинный контекст. По таблице лидеров на 1 сентября Fable 5.1 в конфигурации «max with fallback» набрала 66 баллов, в конфигурации «xhigh with fallback» — 65; «with fallback» означает, что при срабатывании защит запрос уходит запасной модели.

Дальше в таблице Claude Opus 5 с 63 баллами, прежняя Fable 5 с 62, GPT-5.6 Sol (max) и Grok 4.6 по 61, Kimi K3 и GLM-5.3 по 60, Qwen 3.8 Max с 58. Лучшие открытые модели отстают от лидера на шесть баллов. Полезен и столбец стоимости: одна задача индекса обходится Fable 5.1 в $3,69 на максимальном усилии и в $2,65 на xhigh при разнице в один балл, то есть на 28% дешевле. Балл индекса зависит от того, сколько модели разрешили «думать».

Чего индекс не показывает: скорость и задержку (на 2 сентября лаборатория ещё не опубликовала замер для Fable 5.1) и устойчивость в долгих агентных сессиях на сотни шагов; отдельного русскоязычного теста в нём нет. Влияние защитных фильтров в результат уже входит: при их срабатывании модель получает ноль за задачу либо ответ даёт запасная модель. Лидеры этой таблицы меняются каждые несколько недель, поэтому первое место — повод проверить модель на своих задачах, а не аргумент в споре.

Почему модели две

Схема «одна модель, два уровня доступа» появилась у Anthropic в июне с Fable 5 и Mythos 5 и теперь закреплена. Компания прямо пишет, что Fable 5.1 и Mythos 5.1 — «одна и та же базовая модель» (перевод редакции). Разница в защитах: Fable блокирует пентест, генерацию эксплойтов и поиск уязвимостей по бинарникам, а задачи по «двойному назначению» в биологии и химии перенаправляет на модели Opus. Mythos работает с менее строгими защитами, и её выдают под договор: участие в Project Glasswing, хранение данных 30 дней для мониторинга безопасности.

Для обычной разработки, рефакторинга, разбора логов и тестов Fable 5.1 совпадает с Mythos по базовым возможностям везде, где защиты не срабатывают. Для работы по безопасности часть запросов упрётся в фильтр: модель откажется генерировать эксплойт или анализировать бинарник на уязвимости, хотя, по словам Anthropic, уязвимости в исходном коде она находить умеет и делает это в Fable-версии.

Что проверить у себя

• В API замените идентификатор модели на claude-fable-5-1; цены и лимиты те же, миграция сводится к одной строке конфигурации.
• Длинные агентные сценарии (сборка, миграции, многошаговые правки) прогоните на новой модели: именно там Anthropic показывает удвоение результата.
• Сравните режимы усилия: по индексу Artificial Analysis xhigh отстаёт от максимального на один балл, а задача обходится на 28% дешевле.
• Пересчитайте бюджет с учётом кэша: при повторяющемся системном промпте чтение кэша в 40 раз дешевле обычного ввода.
• Если модель раньше отказывала на медицинских или химических темах в безобидном контексте, попробуйте снова: порог срабатывания защиты снижен.
• Подписчики Claude Pro и Max в поддерживаемых регионах получают модель в списке автоматически.

Что дальше

Fable 5.1 расширяет Fable 5 при тех же базовых ценах, так сказано в документации платформы; сроков вывода Fable 5 из API компания не называет. Mythos 5.1 позиционируется как инструмент для киберзащиты и биологических исследований, и расширять круг организаций с доступом Anthropic пока не обещает. В тот же вечер OpenAI объявила, что готовит модель Astra с «критическим» уровнем кибервозможностей и таким же ступенчатым доступом; сравнить обе на одинаковых задачах можно будет только после выхода Astra.

Источники: Claude Fable 5.1 and Claude Mythos 5.1 (Anthropic), Документация модели Fable 5.1, LLM Leaderboard (Artificial Analysis)

Изображение на обложке: скриншот anthropic.com

Что Anthropic сделала с текстом Claude

2 августа 2026 года в ЕС вступили в силу обязательства по прозрачности ИИ-контента из AI Act. В июле 2026-го Anthropic, как и около 190 других организаций, подписала Кодекс практики по прозрачности ИИ-контента. Теперь компания заявляет, что все новые модели Claude будут «маркировать» сгенерированный текст — и делать это глобально, а не только для пользователей из Евросоюза.

Сначала Anthropic лишь кратко сообщила о маркировке в справочной статье «How Claude marks AI-generated content». 14 августа 2026 года появилось техническое объяснение «How Claude’s text watermark works». В нём компания признаёт: водяной знак не добавляет в текст никаких символов, он меняет выбор слов на основе секретного ключа.

Новые модели Claude будут встраивать статистический водяной знак во все тексты длиннее ~200 токенов (~150 слов).

Маркировка не использует невидимые символы: она смещает выбор между близкими по смыслу словами по секретному ключу.

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

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

Чтобы снизить риск, используйте Claude как черновик, а затем переписывайте текст своими словами.

Как работает водяной знак в тексте

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

Anthropic использует вариант подхода SynthID-Text, опубликованного Google DeepMind в Nature в 2024 году. На каждом «равноправном» шаге модель получает лёгкий «подталкивающий» сигнал в сторону одних кандидатов и от других. Отдельный выбор почти незаметен, но на длине в сотни или тысячи токенов накапливается статистическая закономерность, которую может увидеть только владелец ключа.

Главный нюанс:
Секретный ключ есть только у Anthropic. Поэтому никакой сторонний «детектор ИИ-текстов» не сможет проверить водяной знак Claude — он либо будет искать стилистические признаки, либо угадывать.

Почему это спорно: слова имеют значение

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

В документе Anthropic приводится пример: выбор между «overcast» и «grey» «в большинстве случаев не сильно влияет на читателя». Джон Грубер в ответ замечает: именно это и делает идею порочной. Компания решает за автора, какое слово «достаточно хорошо», вместо того чтобы каждый раз искать лучшее.

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

Что это меняет для пользователей

Anthropic честно перечисляет ограничения, но именно они создают проблемы. Водяной знак не доказывает, что текст написал Claude целиком: он лишь повышает вероятность, что Claude участвовал в его создании. Перевод, выполненный Claude, будет маркирован полностью, потому что каждое слово выбрала модель. А вот лёгкая правка человеческого текста может оставить лишь слабый след.

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

• Переводы: полная маркировка, потому что каждый токен — выбор модели.
• Лёгкая правка: может оставить след, но не всегда достаточный для детекции.
• Глубокий переписывание: разрушает статистическую картину, но тогда результат уже сложно назвать ИИ-текстом.
• Код: функциональные части почти не меняются, комментарии — подвержены.

Почему это касается не только ЕС

Формально инициатором маркировки стал ЕС: AI Act обязывает провайдеров ИИ маркировать синтетический контент. Но Anthropic объявила о глобальном внедрении, сославшись на отсутствие «устойчивого способа» ограничить функцию по региону. Получается, что европейское регулирование распространяется на всех пользователей Claude, включая тех, кто живёт в России, США и Азии.

При этом неясно, насколько само регулирование требует именно такого подхода. Кодекс практики применяется к текстам длиннее 200 токенов, требует запрета на удаление метки в условиях использования и устойчивости к копированию, OCR и переводам. Но он не обязывает внедрять систему глобально и не заставляет провайдера изменять слова в приватных чатах.

Google уже делает то же самое с Gemini

Google внедрила текстовый водяной знак SynthID в Gemini раньше Anthropic. В статье Nature команда DeepMind пишет, что проанализировала около 20 млн ответов с водяным знаком и без него. Разница в оценках «палец вверх» составила 0,01%, а «палец вниз» — 0,02%; оба отличия оказались статистически незначимыми в пределах 95%-ного доверительного интервала.

Критики указывают: незначимая разница в оценках не означает, что качество не пострадало. Если модель заменяет «bananas» на «pineapple» в примере DeepMind, пользователь вряд ли поставит «дизлайк» из-за фрукта. Но именно такие микровыборы и формируют голос автора. А когда причина выбора скрыта, доверие к тексту падает.

Что делать авторам и разработчикам

Полностью избежать водяного знака при использовании Claude нельзя — он встроен в генерацию. Но можно снизить риск, что ваш текст будет ошибочно отнесён к категории «сгенерировано ИИ» или потеряет индивидуальность.

FAQ

Выводы

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

Пока публичного детектора нет, риск ложных обвинений невелик. Но как только API проверки появится, вопрос «а не написано ли это ИИ?» станет ещё более неоднозначным. Лучшая защита — не отказываться от инструментов, а помнить: черновик от ИИ — это черновик. Финальный текст должен быть вашим.

Моя письменная работа — это моя работа, а текущая стратегия Anthropic агрессивно враждебна писателям.

Источники

— John Gruber, «Anthropic’s ‘Watermark’ Text Adulteration in Claude Is a Perversion of Writing»
— Anthropic, «How Claude’s text watermark works»
— James Padolsey, «How AI text watermarking works»
— Google DeepMind, «Scalable watermarking for identifying LLM outputs» (Nature, 2024)
— EU Code of Practice on Transparency of AI-Generated Content

Автор оригинального руководства указывает заголовок «за $5/месяц», но на практике минимально жизнеспособная конфигурация обходится в $6–12/месяц. За $5 дроплет даёт всего 1 ГБ ОЗУ — для семимиллиардной модели этого катастрофически мало. Ниже — реальные цифры и честная смета.

Что такое Llama 2 и зачем её self-hostить

Llama 2 — семейство открытых больших языковых моделей. Версия 7B содержит 7 миллиардов параметров, понимает английский и ряд других языков, умеет писать код, отвечать на вопросы и дополнять текст. Лицензия разрешает коммерческое использование при соблюдении простых правил, а веса можно скачать с Hugging Face.

Self-hosting в данном случае означает, что вы сами устанавливаете модель на арендованный сервер, контролируете окружение, не делитесь данными пользователей с третьими лицами и не зависите от чужих rate limit. Главная экономика: при интенсивном использовании собственный инференс обходится в десятки раз дешевле облачных API.

• Llama 2 7B можно запустить на DigitalOcean Droplet с 2 vCPU и 4 ГБ ОЗУ при 4-битном квантовании.
• Реальная стоимость — $12/месяц за Droplet плюс около $0,50 за трафик, а не $5.
• Docker + FastAPI дают воспроизводимое окружение и HTTP API из коробки.
• Для загрузки весов с Hugging Face нужен токен и принятая лицензия на Llama 2.
• Для публичного доступа обязательны HTTPS, базовая аутентификация и rate limiting.

Что понадобится для развёртывания

Аппаратная часть

• DigitalOcean Droplet на Ubuntu 22.04 LTS.
• Минимум: 1 vCPU / 2 ГБ ОЗУ ($6/месяц) — только для экспериментов.
• Рекомендуемый: 2 vCPU / 4 ГБ ОЗУ ($12/месяц) — стабильная работа с квантованием.
• 80 ГБ SSD: ~13 ГБ уйдёт на Docker-образ, модель и кэш.

Программная часть

• SSH-ключ и базовое умение работать в терминале.
• Docker и Docker Compose для управления контейнером.
• Аккаунт на Hugging Face с принятой лицензией Llama 2 и API-токеном.
• Nginx или аналогичный reverse proxy для вывода API в интернет.

Российская специфика: сайт DigitalOcean периодически попадает под блокировки Роскомнадзора. Для регистрации и управления Droplet может понадобиться VPN. Альтернативы — Hetzner, Selectel, Yandex Cloud или другие европейские и российские провайдеры; логика развёртывания от этого почти не меняется.

Шаг 1. Создаём Droplet и подключаемся по SSH

В панели DigitalOcean нажимаем Create → Droplet. Выбираем ближайший к целевой аудитории регион — для России это обычно Франкфурт или Амстердам. В качестве образа указываем Ubuntu 22.04 x64, тип — Basic Shared CPU, конфигурацию — 2 vCPU / 4 ГБ RAM. Авторизацию настраиваем через SSH-ключ, парольный вход отключаем.

Сгенерировать ключ и подключиться можно так:

Шаг 2. Устанавливаем Docker и зависимости

После подключения обновляем пакеты и ставим Docker официальным скриптом. Добавляем root в группу docker, чтобы не писать sudo перед каждой командой.

Шаг 3. Собираем Docker-образ с FastAPI

Приложение состоит из трёх файлов: Dockerfile, requirements.txt и app.py. Ключевой трюк — CPU-версия PyTorch и библиотека bitsandbytes, которая позволяет загрузить 7-миллиардную модель в 4 ГБ видеопамяти/ОЗУ.

Dockerfile

requirements.txt

Шаг 4. Пишем FastAPI-приложение

Приложение загружает модель при старте, кэширует её в /app/models и предоставляет три endpoint: /health, /info и /generate. Квантование в 4 бита снижает точность незначительно, но уменьшает потребление памяти в 3–4 раза.

Создаём файл с токеном Hugging Face. Никогда не коммитьте его в репозиторий: в продакшене используйте переменные окружения или секрет-менеджер.

Шаг 5. Собираем и запускаем контейнер

Первый запуск занимает 10–15 минут: скачиваются зависимости PyTorch и веса модели. Чтобы не качать веса при каждом перезапуске, подключаем Docker volume.

Для удобного управления добавляем docker-compose.yml:

Шаг 6. Проверяем API

Когда в логах появится Uvicorn running on http://0.0.0.0:8000, тестируем endpoint'ы:

Ответ должен содержать сгенерированный текст, количество токенов и время инференса. На CPU одна генерация из 100 токенов занимает 4–10 секунд — это нормально для бюджетного дроплета.

Шаг 7. Безопасно выводим API в интернет

Открывать порт 8000 напрямую в интернет небезопасно. Ставим Nginx как reverse proxy, настраиваем HTTPS через Let's Encrypt и базовую аутентификацию. Для rate limiting используем limit_req в Nginx или облачный firewall DigitalOcean.

Минимальная конфигурация Nginx выглядит так:

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

Выводы

Self-hosted Llama 2 — рабочий способ снизить затраты на генеративный ИИ в pet-проектах и прототипах. При правильном квантовании семимиллиардная модель помещается в бюджетный дроплет, а Docker + FastAPI превращают развёртывание в рутинную процедуру. Главное — не экономить на RAM и не забывать про безопасность публичного API.

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

Если соберётесь повторить гайд, начните с $12 Droplet и протестируйте нагрузку вручную. А если DigitalOcean недоступен — переносите тот же Docker Compose на Hetzner, Selectel или Yandex Cloud без изменения кода.

Источник: How to Deploy Llama 2 on DigitalOcean for $5/Month: Complete Self-Hosting Guide — RamosAI, Dev.to.

В этой статье разберём, почему стандартные assert-тесты и record-and-replay плохо справляются с автономными агентами, как теория графов помогает выделить обязательные этапы задачи и что из этого следует для российских команд, которые уже пробуют GitHub Copilot или собственных агентов в CI/CD.

Исследование, опубликованное 6 мая 2026 года в блоге GitHub, описывает метод валидации агентского поведения, который не требует ручного написания скриптов для каждого сценария и не верит агенту на слово. Вместо этого он строит модель «ground truth» из 2–10 успешных выполнений и проверяет новые запуски по структуре, а не по совпадению шагов.

• ИИ-агенты с Computer Use недетерминированы: один и тот же задача может решаться разными путями.
• GitHub предлагает Trust Layer — внешний слой валидации, который учится на успешных запусках и выделяет обязательные этапы.
• В основе — Prefix Tree Acceptor (PTA) и dominator analysis из теории компиляторов.
• В эксперименте метод показал 100% accuracy, precision, recall и F1 против 82,2%, 83,3%, 60,0% и 69,8% у самооценки агента.
• Trust Layer лучше определяет «не баг, а шум»: F1 52,2% против 0% у внутренней самопроверки агента.

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

Почему классические тесты сдаются

Привычные инструменты тестирования хороши, пока путь выполнения фиксирован. Как только поведение начинает ветвиться, они начинают ломаться не от плохой инженерии, а от неверной посылки: «правильность = точное совпадение последовательности состояний».

• Assertion-based testing требует вручную прописывать каждую проверку и не терпит допустимых альтернативных путей.
• Record-and-replay чувствителен к задержкам сети, рендерингу и незначительным изменениям интерфейса.
• Visual regression сравнивает скриншоты изолированно, не понимая контекста выполнения и семантики состояний.
• ML-оракулы — чёрный ящик: нужны тысячи примеров обучения, и невозможно объяснить, почему помечен конкретный прогон как ошибочный.

В России эта проблема особенно актуальна для команд, которые используют self-hosted runners или зеркала репозиториев. Сетевые лаги, доступ к зарубежным API и особенности локальной инфраструктуры добавляют ещё больше «шума», не связанного с качеством кода. В результате CI начинает «краснеть» по чужой вине, а разработчики привыкают игнорировать падения.

Что значит «правильно» для агента

GitHub предлагает переформулировать определение корректности: не «агент повторил записанный сценарий», а «агент достиг обязательных результатов». Это разделяет поведение на три категории.

• Обязательные состояния (essential states). Этапы, без которых успех невозможен. Например, открытие диалога поиска и появление результатов.
• Опциональные вариации (optional variations). Случайный шум: спиннер загрузки, небольшая задержка, временное уведомление.
• Сходящиеся пути (convergent paths). Разные последовательности действий, которые приводят к одному и тому же итоговому состоянию.

Ключевой инсайт: если состояние «спиннер загрузки» можно пропустить в быстром прогоне, оно не может быть обязательным. А вот состояние «диалог поиска открыт» доминирует результат: без него невозможно получить список найденного. Эта идея напрямую заимствована из теории компиляторов — dominator analysis.

Как устроен Trust Layer

Метод GitHub состоит из трёх шагов: собрать успешные выполнения, построить из них единую модель и выделить в ней обязательные состояния.

От трасс к графу

Вместо линейного скрипта каждое выполнение представляется как направленный граф. Узлы — наблюдаемые состояния: скриншоты интерфейса, снапшоты кода или структуры DOM. Рёбра — действия агента: клики, нажатия клавиш, вызовы API. Несколько успешных трасс объединяются в Prefix Tree Acceptor (PTA) — дерево, которое сохраняет общие префиксы и разветвляет пути там, где выполнения действительно расходятся.

Три уровня эквивалентности

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

1. Визуальные метрики. Быстрые perceptual hash и SSIM ловят почти идентичные скриншоты.
2. Семантический анализ через LLM. Мультимодальная модель решает, значима ли разница: timestamp или декорация окна игнорируются, пропавшая кнопка или другое сообщение об ошибке — фиксируются.
3. Консервативное слияние. Состояния объединяются только при высокой уверенности, чтобы не потерять реальное расхождение.

Доминаторы выделяют суть

После слияния к графу применяется dominator analysis. Состояние A доминирует состояние B, если любой путь от начала к B проходит через A. Те состояния, которые доминируют успешное завершение задачи, становятся обязательными. Всё остальное автоматически классифицируется как опциональный шум.

При проверке нового прогона алгоритм не ищет точное совпадение. Он проверяет, что обязательные состояния появились в правильном порядке. Если эталонная последовательность A → B → C, а агент выполнил A → X → B → Y → C, тест проходит: X и Y считаются случайными вставками. Если пропущено B или нарушен порядок — фиксируется конкретная ошибка с пояснением, какое состояние не достигнуто.

Цифры: насколько это лучше

Авторы сравнили свой метод PTA (Dominator Tree) с самооценкой агента Computer-Use Agent (CUA) на наборе тестов кастомного расширения VS Code. Разница оказалась впечатляющей.

• Accuracy: CUA — 82,2%, PTA — 100% (+17,8 п. п.).
• Precision: CUA — 83,3%, PTA — 100% (+16,7 п. п.).
• Recall: CUA — 60,0%, PTA — 100% (+40,0 п. п.).
• F1-Score: CUA — 69,8%, PTA — 100% (+30,2 п. п.).

Ещё важнее метрика «не баг, а шум» (not-a-bug). Сам агент не смог корректно классифицировать такие сценарии: F1 оказался 0%. Trust Layer на основе структурного анализа достиг F1 52,2%. Это означает, что разработчики тратят меньше времени на разбор ложных падений.

We don’t need black-box models to judge other black-box models. We need structural guarantees developers can inspect, reason about, and trust.

Как это применить в своём CI/CD

Полноценная реализация Trust Layer требует исследовательского прототипа, но идеи можно перенести и в повседневную работу команд.

1. Собирайте «золотые» трассы. Сохраняйте 2–10 успешных выполнений критичного сценария, чтобы у будущих прогонов была эталонная структура.
2. Отделяйте «должен быть» от «может быть». Вместо проверки каждого шага фиксируйте ключевые чекпоинты: авторизация выполнена, данные сохранены, ответ получен.
3. Делайте тесты толерантными к порядку. Если несколько допустимых путей ведут к одному результату, проверяйте результат и наличие обязательных промежуточных состояний, а не точную последовательность.
4. Используйте семантику, а не пиксели. Визуальные регрессии должны понимать, что изменилось, а не просто считать разницу между скриншотами.
5. Не верьте агенту на слово. Внешняя валидация по состояниям среды надёжнее самооценки модели, особенно в недетерминированных задачах.

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

Выводы

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

Подход GitHub с Trust Layer, PTA и dominator analysis даёт объяснимую и лёгкую модель корректности, которую можно встроить в CI/CD. Она не требует тысяч примеров и не превращается в чёрный ящик. А главное — снижает количество ложных падений, за которыми теряются настоящие баги.

Источник: Validating agentic behavior when “correct” isn’t deterministic — The GitHub Blog.

Вместе со швейцарской компанией mimic robotics BFL построила FLUX-mimic — видео-экшен-модель (video-action model) поверх бэкбона FLUX 3. Идея в том, что модель, которая учится генерировать реалистичное видео, вынуждена понимать физику мира: контакт, вес, движение, причину и следствие. А раз физика уже «внутри» — из внутреннего представления модели можно напрямую декодировать действия робота.

BFL представила FLUX 3 — единую модель, обученную сразу на изображениях, видео и аудио; на предсказание видео ушло более 95% вычислительных затрат.

FLUX-mimic — видео-экшен-модель для роботов на бэкбоне FLUX 3, разработанная с mimic robotics и развёрнутая на производстве Audi.

Новая задача манипуляции требует всего от 30 минут робот-данных против 30 и более часов у прежних подходов.

Бэкбон работает менее чем за 80 мс на одной RTX 5090, а полное время реакции робота — 101 мс, что сопоставимо с человеческой зрительной реакцией.

Что показали BFL и mimic

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

Ключевой эксперимент: когда в обучение FLUX 3 добавили предсказание действий, качество видеогенерации временно просело на 10%, но уже через 3500 шагов полностью восстановилось — при том что модель научилась новой модальности. По версии BFL, генерация видео и управление роботом не требуют разных фундаментов: один бэкбон несёт обе задачи.

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

Почему это важно

Главная боль робототехники — данные: обучение робота новой задаче обычно требует десятки часов демонстраций. FLUX-mimic, по данным компаний, дообучается на новую манипуляцию примерно за 30 минут робот-данных, а в экспериментах на базе метода Self-Flow и работы mimic-video показывает до 10-кратной эффективности по данным в сравнении с классическими vision-language-action моделями. На бенчмарках декодер действий обошёл прежние VLA-модели даже с полностью замороженным бэкбоном — режим, в котором конкуренты вообще не справляются.

Сам FLUX 3 при этом остаётся генеративной моделью: он создаёт видео до 20 секунд с синхронным звуком и в ранних тестах BFL обошёл Runway Gen-4.5 в 77% сравнений. Ранний доступ к FLUX 3 Video и FLUX 3 Action уже открыт, генерация изображений выйдет в ближайшие недели, а открытые веса FLUX 3 Dev обещают позже в 2026 году.

Вывод. BFL делает ставку на то, что «модель мира», выученная ради видеогенерации, — это и есть фундамент для физического ИИ. Показательно, что первым проверенным в бою применением стала не демка, а реальный конвейер Audi. Подробности — в блоге Black Forest Labs и в пресс-релизе.

Godot Engine — это открытый кроссплатформенный игровой движок, который многие инди-разработчики рассматривают как альтернативу Unity. Проектом управляет некоммерческая Godot Foundation, а код собирается из пул-реквестов со всего мира. Это делает правила contributions ключевым инструментом выживания экосистемы.

Основной тезис обновления: любой существенный код должен быть написан человеком, который способен отвечать за него. Автономные ИИ-агенты, «vibe-coded» PR и ИИ-сгенерированный текст в обсуждениях попадают под запрет. Мелкие вспомогательные задачи — code completion, регулярки, find-and-replace — остаются, но с обязательным раскрытиием.

• Godot Foundation запретила ИИ-агентам и «vibe coding» создавать пул-реквесты с существенным кодом.
• Разрешены только мелкие вспомогательные операции: code completion, regex, find-and-replace с обязательным дисклеймером.
• Новички (≤3 принятых PR) теперь должны получать одобрение мейнтейнеров перед новыми фичами и крупными рефакторингами.
• Главный аргумент — ревью кода — это не только проверка, но и менторство будущих мейнтейнеров, а ИИ из этого контура выпадает.
• Похожие ограничения уже ввели Zig, Ghostty и curl: проблема AI slop стала системной для open source.

Что именно запрещено

В официальном посте Changes to our Contribution Policies Foundation перечисляет три запрещённые категории. Важно, что они касаются не только ботов, но и людей, которые копируют ИИ-вывод в PR, даже если потом вручную проверяют и дисклейсят.

• Автономные ИИ-агенты и «vibe coding». PR, созданные без глубокого участия человека, уже отклоняются автоматически.
• ИИ как автор существенного кода. Блоки логики, сгенерированные моделью, не принимаются независимо от того, кто нажал «Submit».
• ИИ-сгенерированный текст в коммуникации. Обсуждения с мейнтейнерами должны вестись людьми; исключение — машинный перевод человеческого текста.

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

Почему это больше, чем «слишком много PR»

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

Reviewing PRs is already tedious work, but it is rewarding because reviewers generally feel that their efforts are contributing to educating a new contributor — who may become a future maintainer/reviewer. If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer, it becomes much harder to justify spending your free time on PR review.

В интервью Game Developer Foundation прямо говорит: «AI cannot take responsibility, and we can’t trust heavy users of AI to understand their code enough to fix it». Это не ненависть к ИИ как технологии, а признание, что ответственность за код должен нести конкретный человек.

«Contributor poker»: инвестиция в человека, а не в код

Эта логика не нова. В апреле 2026 года язык программирования Zig ввёл схожий zero-tolerance policy для ИИ-помощи в contributions. Вице-президент Zig Software Foundation Лорис Кро назвал ревью «contributor poker»: в покере вы играете против человека, а не против карт. Аналогично мейнтейнер вкладывает время не в конкретный PR, а в человека, который его прислал.

In contributor poker, you bet on the contributor, not on the contents of their first PR.

Когда PR написан ИИ, ставка срывается: ревью не превращает автора в будущего мейнтейнера, потому что автор не учится. Именно поэтому Godot и Zig формулируют запрет не как «ИИ плох», а как «менторская петля разрывается».

Godot не один: Zig, Ghostty и curl

Та же проблема AI slop в разных проявлениях встречается и в других крупных проектах. Терминал Ghostty ограничил поток ИИ-сгенерированных issue, а библиотека curl пережила настоящий DDoS фальшивыми security-репортами.

curl — самый известный пример. Создатель проекта Даниэль Стенберг писал, что в 2025 году доля валидных security-репортов упала примерно до одной из двадцати: «We are effectively being DDoSed». Часть отчётов содержала GDB-сессии и дампы регистров для функций, которых в curl не существует. В ответ команда закрыла bug bounty на HackerOne и перешла к более жёсткой модерации.

Интересно, что curl не отвергает ИИ полностью: тот же Стенберг позже признал, что AI-сканнеры в руках экспертов находят настоящие баги. Разница между полезным инструментом и slop — в проверке и ответственности человека, который отправляет результат.

Пайплайн талантов под угрозой

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

В корпоративной среде эта же проблема звучит иначе: The New Stack в апреле цитировал Марка Руссиновича и Скотта Хансельмана из Microsoft, которые предупреждали: если компании будут заменять junior-разработчиков senior-инженерами с ИИ-ассистентами, «the profession’s talent pipeline collapses».

We need to take steps to reduce the burden on maintainers while ensuring we still have a pipeline to mentor new contributors to become future maintainers.

Что делать разработчикам

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

1. Читайте правила contributions конкретного проекта перед отправкой PR.
2. Раскрывайте использование ИИ для autocomplete, regex и мелких правок — честность ускоряет ревью.
3. Не отправляйте сгенерированные моделью блоки логики как «свой» код: вы должны понимать каждую строку.
4. Если у вас ≤3 принятых PR в Godot, начинайте с багфиксов и документации, а не с новых фич.
5. Проверяйте ИИ-репорты безопасности вручную: hallucinated уязвимости тратят время мейнтейнеров зря.

FAQ

Выводы

Godot не объявляет войну искусственному интеллекту. Она объявляет войну безответственному использованию ИИ в том месте open source, где важнее всего доверие и обучение. Движок остаётся открытым, но правила contributions становятся жёстче — и это, скорее всего, не последний подобный шаг в индустрии.

Things change every day with respect to the current suite of AI tools available. We will continue taking a conservative approach in our policies towards them, but we will re-evaluate as things evolve.

Источники: The New Stack, Godot Foundation, Game Developer.

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

Как нейросеть слышит текст, когда создаёт песню

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

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

На русском есть отдельная тонкость — ударения. Модель иногда путается в словах-омографах или ставит ударение не туда, и во многих сервисах его можно проставить вручную, пометив нужную гласную прямо в тексте. Для песни на русском это заметно выравнивает вокал. И последнее: генератор песен читает структурные теги [Verse], [Chorus], [Bridge], [Outro] и по ним понимает, где куплет, а где припев. Без разметки структура собирается наугад.

Кто создаёт песню: три нейросети в команде

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

Автор текста — языковая модель (ChatGPT или Claude). Текст — фундамент: нейросеть споёт ровно то, что вы дали, и слабые строки не спасёт никакой стиль. Писать лучше не в лоб, а через модель в режиме рассуждений — тогда она считает слоги, следит за рифмой и ритмом. Задачу ставьте конкретно: не «напиши грустную песню», а полный сценарий — жанр, тема, структура, настроение, темп в BPM, запрет на клише. А если текст у вас уже готов, его отдают нейросети напрямую — создать песню по тексту она умеет не хуже, чем сочинить с нуля.

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

Исполнитель и студия — Suno. Актуальная версия движка — v5.5. Именно Suno превращает текст и промпт в готовый трек с вокалом, аранжировкой и сведением, выдавая сразу два варианта за генерацию. Это лучший на рынке синтез вокала, в том числе на русском, — но качество зависит от того, что ему передали автор и постановщик.

Именно эту троицу Music.Era2.ai и заменяет одним окном: роль автора берёт встроенный GPT, роль постановщика — готовые стили, а движок Suno работает под капотом.

Music.Era2.ai: создать песню нейросетью в одном окне

Собирать эту троицу самостоятельно долго, поэтому проще взять сервис, который делает всё за вас. Music.Era2.ai — российский генератор песен на движке Suno, который собирает всю «команду нейросетей» в одном интерфейсе и убирает то, на чём спотыкаются новички.

Вот что он закрывает:

• Текст пишет встроенный GPT. Не нужно отдельно идти в чат-бот и просить текст — достаточно описать идею песни прямо в сервисе, и он соберёт слова с правильной разметкой сам.
• Стиль задаётся готовыми шаблонами, а не промптом. Вместо ручного англоязычного описания стиля выбираете готовый пресет под жанр и настроение — думать над формулировками не нужно.
• Тонкие настройки — на русском. В «Продвинутом» режиме открыты те же параметры, что в платной версии Suno, но переведённые и с пояснениями, что за что отвечает.
• Фирменные вокальные стили в духе любимых исполнителей — то, что в оригинальном Suno обычно закрыто ограничениями. Ориентироваться при этом безопаснее на жанр и атмосферу, а не на точную копию артиста.
• Из России и за рубли. Работает без сложностей с доступом, оплата российскими картами, интерфейс на русском.
• Чарт и бонусы. Внутри — рейтинг треков и еженедельные поощрения для активных авторов.

Первый трек можно создать бесплатно, дальше сервис платный, аккаунт понадобится. По сути это способ получить результат уровня Suno, не собирая три нейросети вручную и не упираясь в оплату из-за рубежа. А чтобы понимать, что происходит под капотом (и выжимать максимум в любом сервисе), дальше разберём саму механику.

Промпт стиля: как описать песню для нейросети

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

Плохой промпт:

Хороший промпт:

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

Как создать песню нейросетью вручную в Suno

Чтобы было понятно, почему готовый сервис экономит нервы, вот как выглядит ручной путь в оригинальном Suno. Сначала пишете текст в одной вкладке через языковую модель. Потом в другой вкладке собираете промпт стиля. Затем переходите в Suno, включаете ручной режим, вставляете текст и промпт в разные поля и лезете в расширенные настройки: пол вокала, режим текста, ползунок креатива, сила влияния стиля, поле исключений — всё на английском. Дальше слушаете два варианта и, если не то, дорабатываете куски, а не пересоздаёте весь трек с нуля.

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

Что можно создать нейросетью и как быть с правами

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

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

Частые вопросы о создании песен нейросетью

Правда ли можно создать песню нейросетью бесплатно и без регистрации?

Полностью бесплатно и совсем без регистрации — почти нигде. Обычно аккаунт нужен, а бесплатно доступны один-два пробных трека. В Music.Era2.ai первый трек тоже бесплатный, дальше сервис платный. У оригинального Suno есть бесплатный лимит, но на старой версии модели и без права на коммерцию.

На каком языке писать текст и промпт?

Текст песни — на русском, современные модели поют по-русски уже уверенно. А промпт стиля лучше на английском: движок точнее понимает жанровые и продюсерские термины. В сервисах с готовыми стилями промпт не нужен вовсе.

Можно ли создать песню по своему тексту или на свои стихи?

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

Что лучше для русского вокала — Suno или Udio?

Для песни с вокалом на русском сильнее Suno и сервисы на её движке, включая Music.Era2.ai. Udio выигрывает в инструментале и «чистом» студийном звуке, но по русским текстам заметно уступает.

Почему трек звучит гладко, но скучно?

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

Эта статья объясняет, почему классических CI/CD-ворот недостаточно для production-систем на базе ИИ. Автор делится практическим подходом к release gates для LLM-пайплайнов с помощью baseline-оценок, детектирования дрейфа, shadow-проверок и ограничений по стоимости и латентности. Акцент — на профилактике: отлов тихих AI-регрессий до того, как они достигнут пользователей, на основе реальных уроков платформенной инженерии из production-инфраструктуры.

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

В тот момент я перестал доверять зелёному цвету как сигналу к релизу. У нас не было проблемы с деплоем. У нас была проблема с release gates. Классический CI/CD создавался для детерминированного ПО. LLM — вероятностны. Наши ворота тоже должны быть вероятностными.

Классические CI/CD-ворота работают по принципу pass/fail, но LLM поставляют поведение, а не только код, поэтому нужны ворота, отслеживающие дрейф поведения.

Три режима отказа: eval drift (постепенная деградация оценок), distribution shift (реальные запросы отличаются от тестовых) и context poisoning (изменились извлечённые документы, а тесты спрашивают вчерашнее).

Четыре release gates: baseline eval suite, eval drift detection, shadow traffic validation, cost/latency guardrails.

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

Eval-датасеты нужно версионировать так же тщательно, как Terraform state: с бэкапами и параноей.

Почему классический CI/CD не справляется с LLM-пайплайнами

В обычной доставке ПО ворота достаточно просты: unit-тесты прошли, интеграционные тесты прошли, проверки безопасности прошли — деплой. Это бинарно. Сборка зелёная или красная. Эта модель ломается, когда вы поставляете не код, а поведение.

Классический CI/CD создавался для детерминированного ПО. LLM — вероятностны. Наши ворота тоже должны быть вероятностными.

Production-система на базе ИИ может сегодня показывать relevance 0,82, завтра 0,79, а на следующей неделе 0,74. Поскольку ни один запуск не пересекает порог отказа, никого не пейджат, хотя пользователи уже получают худшие ответы.

Я больше 20 лет управлял production-инфраструктурой: приватными облаками OpenStack, миграциями баз данных, CI/CD-пайплайнами и mission-critical системами. В классическом DevOps мы усвоили: сервер, который сообщает о 99,9% аптайма при потере 0,1% финансовых транзакций, — не здоров. Он скрывает баг. Оценки LLM работают так же. Агрегированные метрики маскируют локальные отказы.

Первый режим отказа — eval drift: оценки деградируют постепенно, но недостаточно, чтобы упасть по жёсткому порогу. Второй — distribution shift: реальные пользователи задают короткие, беспорядочные, странные вопросы, о которых ваш чистый eval-датасет и не думал. Третий — context poisoning: ваши извлечённые документы изменились, а тесты всё ещё спрашивают вчерашние вопросы.

Традиционный CI/CD gate спрашивает: «Тест прошёл?» LLM release gate спрашивает: «Поведение осталось в допустимом диапазоне?» Обычный gate сравнивает ожидаемый вывод с фактическим. AI CI/CD gate сравнивает кандидатное поведение с историческим и production-поведением, а также со стоимостью, латентностью и риском. Традиционные ворота быстро отсеивают исключения. LLM release gates внимательно отсекают дрейф.

Традиционные ворота быстро отсеивают исключения. LLM release gates внимательно отсекают дрейф.

Это различие важно, потому что production AI-системы гниют, а не взрываются. Я создал llm-eval-drift-release-gates-AGENT, потому что хотел ворота, которые относятся к AI-релизам как к инфраструктурным релизам: измеримым, повторяемым и, по возможности, скучным. Скука недооценена. Она позволяет инженерам спать.

Анатомия LLM release gate

Первое ворото — baseline eval suite. Он прогоняет фиксированный датасет по кандидатному пайплайну и оценивает relevance, faithfulness, safety, groundedness и любые доменные проверки, которые вам важны. Цель не в том, чтобы доказать, что модель идеальна. Цель — поймать регрессии до того, как они станут историями от клиентов.

Вот упрощённая Python-структура из паттерна, который я использую:

Использование StrEnum сохраняет enum в виде строк без множественного наследования. Это важно в релизном инструментарии, потому что значения статусов часто логируются, сериализуются, сравниваются в CI или передаются в дашборды.

Это ловит очевидные отказы: коллапс relevance, падение faithfulness, небезопасные выходы или искажённые результаты оценщика. Если отказ жёсткий, пайплайн блокируется немедленно; если срабатывает предупреждение, требуется ручное одобрение. Мне не нравятся тихие предупреждения: это будущие инциденты в хорошей рубашке.

Второе ворото: детектирование дрейфа оценок

Второе ворото — детектирование дрейфа оценок. Фиксированного порога недостаточно. Если relevance падает с 0,91 до 0,86, ваш порог 0,80 говорит, что всё в порядке. Ваши пользователи могут не согласиться.

Поэтому я сравниваю текущие оценки с rolling baseline из недавних деплоев:

Eval suite обнаружил 6% падение relevance в 23:00 в четверг. Без него это падение достигло бы 200 пользователей к понедельнику. Ворото не знало бизнес-контекста. Ему это и не нужно. Оно знало, что кандидат хуже последнего известного хорошего релиза.

Третье ворото: shadow traffic validation

Третье ворото — shadow traffic validation. Перед полным раскатом я направляю небольшой процент реального трафика на кандидатный пайплайн. Пользователи всё ещё получают production-ответ, но система записывает кандидатный вывод для сравнения.

Это canary-deployment, применённый к ИИ. Я использовал тот же паттерн в инфраструктурных раскатах, включая идеи из моего репозитория eks-canary-deployment-pipeline. Разница в том, что для LLM вы сравниваете не только HTTP 200. Вы сравниваете качество ответа, извлечённый контекст, латентность и причины, по которым кандидат расходится с production подозрительным образом.

Judge-модель может быть полезна, но я не даю ей быть единственным авторитетом. Она даёт сигнал. Release policy принимает решение.

Четвёртое ворото: стоимость и латентность

Четвёртое ворото — стоимость и латентность. Модель, которая идеально оценивается, но стоит в 3 раза дороже, — не валидный релиз. RAG-пайплайн, который добавляет две секунды латентности, тоже не готов. Эта же логика легла в основу моей работы enterprise-rag-guardrails-costops.

Когда это ворото не проходит, система блокирует релиз или направляет его на ручное одобрение. Я научился не торговаться о латентности во время деплоя. Она всегда побеждает позже.

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

Как встроить это в существующий CI/CD

Release gate не должен быть отдельным научным проектом. Если ваша платформенная команда уже использует GitHub Actions или GitLab CI, LLM-пайплайн деплоя должен вписаться в этот workflow.

Паттерн намеренно скучный:

Такую форму я расширил из своей работы devsecops-pipeline-github-actions. Соберите приложение. Запустите детерминированные тесты. Запустите baseline eval suite. Сравните с rolling baselines. Провалидируйте на shadow-трафике. Проверьте бюджеты стоимости и латентности. Деплойте, только когда все ворота согласны.

Здесь guardrails MLOps становятся полезны платформенным инженерам. Вам не нужна отдельная религия деплоя. Вам нужен один дополнительный набор проверок внутри пайплайна, которому команда уже доверяет.

Вот небольшая Python-точка входа, которую можно вызывать из CI. Важная деталь: она падает аккуратно, когда нужные отчёты отсутствуют или искажены, потому что сырые stack trace — не стратегия релиза.

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

Последняя часть далась мне дольше, чем хотелось бы признать.

Ошибки, которые я совершил, и что бы сделал иначе

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

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

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

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

Оценки выглядели отлично. Production — нет.

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

Строить это из Кочабамбы, Боливия, тоже повлияло на дизайн. У меня не было неограниченных облачных кредитов на огромные eval-прогоны. Это заставило оптимизировать сэмплирование, кешировать вызовы judge-модели и разделять быстрые PR-проверки от более тяжёлых ночных.

Ограничения рождают лучшую инженерию. Раздражает, но правда.

Отправляйте уверенность, а не только код

В классическом ПО мы поставляем код и проверяем поведение. В ИИ мы поставляем поведение и проверяем соответствие. Release gates — это то, как мы закрываем этот разрыв.

LLM release gates не уберут неопределённость из production AI-систем. Ничто не уберёт. Но они дают платформенным командам практический способ поймать eval drift, distribution shift, context poisoning, скачки стоимости и регрессии латентности до пользователей.

Это важно для надёжности агентных workflow. Это важно для AI CI/CD. Это важно, потому что «все тесты прошли» больше не достаточно.

Я создал llm-eval-drift-release-gates-AGENT, потому что устал от зелёных пайплайнов, которые мне лгали. Репозиторий — open-source, offline-first референсная реализация этого паттерна release gates. Он намеренно достаточно мал, чтобы изучить, запустить, сломать и ужесточить в своём CI/CD.

Репозиторий: https://github.com/fdaniel-alvarez-dev/llm-eval-drift-release-gates-AGENT. Форкайте, ломайте, улучшайте. Худший release gate — тот, который вы никогда не построили.

Выводы

Классический CI/CD создавался для детерминированного ПО, а LLM — вероятностны. Поэтому release gates для ИИ должны отслеживать не только прохождение тестов, но и дрейф поведения: baseline-оценки, детектирование дрейфа, shadow-трафик, стоимость и латентность.

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

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

Как работает оживление фото

Оживление фото — это технология image-to-video: нейросеть берёт статичную картинку и достраивает к ней движение. Алгоритм находит на снимке лицо и ключевые точки (глаза, губы, контур головы), анализирует передний и задний план и «предсказывает», как человек мог бы моргнуть, улыбнуться или повернуться. Из одного кадра получается короткий ролик на 5–10 секунд. По сути это и есть анимация фото нейросетью: обычная фотография превращается в живое видео, где человек дышит, моргает и смотрит в камеру.

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

Почему оживление часто выглядит неестественно

Если вы уже пробовали оживить фото нейросетью и результат напугал — дело почти всегда в одной из трёх причин.

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

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

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

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

Какое фото подходит для оживления, а какое нет

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

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

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

Отдельно про оживление старого фото: чёрно-белые и архивные снимки оживить можно и нужно, но если фото повреждённое и мутное, сначала имеет смысл улучшить его качество и убрать дефекты, а уже потом анимировать. Так лицо предка не «поплывёт».

Как оживить фото в +Вайбе за 5 шагов

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

Шаг 1. Загрузите фото. Подойдут JPG, PNG, HEIC или WEBP до 10 МБ. Лучше всего — портрет или селфи, где хорошо видно лицо.

Шаг 2. Опишите движение. В поле запроса напишите, что должно происходить: «камера плавно приближается, человек улыбается, волосы слегка двигаются». Если не знаете, что писать, поле можно оставить пустым — тогда сервис сам добавит мягкое движение камеры, лёгкую мимику и живой фон. Есть и готовые пресеты: по мимике — мягкая улыбка, поворот головы, живой портрет; по камере и стилю — камера приближается, кино-эффект, движение волос, фон оживает, нежное движение.

Шаг 3. Выберите формат. Под площадку: 9:16 для Reels и Stories, 1:1 для поста в ленту, 16:9 для YouTube. Переснимать под другой формат потом не придётся.

Шаг 4. Задайте длительность и звук. Ролик на 5 или 10 секунд, со звуком или без — для оживления портрета звук обычно не нужен, ролик всё равно уходит на монтаж со своей музыкой.

Шаг 5. Запустите и скачайте. Обычно примерно через минуту готовое видео можно скачать в MP4 и выложить в соцсети. Кредиты за неудачную генерацию не списываются.

Шпаргалка по промтам для оживления фото

Промт для оживления — это не заклинание, а короткая точная задача. Работает простая формула:

объект + одно действие + движение камеры + атмосфера.

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

Несколько слов-помощников, которые чинят типовые провалы (их можно добавлять прямо в запрос):

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

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

Старое фото

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

Портрет или селфи

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

Кинокадр для блога

Медленный кинематографичный наезд камеры (zoom), человек задумчиво смотрит вдаль, мягкий контровой свет и лёгкая дымка в кадре, атмосферное настроение, движение плавное и минимальное.

Семейное фото

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

Питомец

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

Детское фото

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

Портрет с эмоцией

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

Пара

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

Пейзаж или фон за спиной

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

Архивный чёрно-белый кадр

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

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

Оживить не только портрет: рисунки и пейзажи

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

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

Задачи, которые закрывает оживление фото

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

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

Контент для соцсетей. Из обычного селфи выходит живой вертикальный ролик для Reels, Shorts, Stories или Telegram — без съёмки и монтажа.

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

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

Частые вопросы

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

Можно ли оживить фото на телефоне? Да. Сервис работает в браузере телефона без установки приложения — достаточно открыть страницу, загрузить фото и запустить оживление.

Можно ли оживить старое чёрно-белое фото? Можно. Нейросеть распознаёт черты лица и на архивных снимках. Если фото сильно повреждено, сначала улучшите качество и уберите дефекты, а затем анимируйте — так результат будет чище.

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

На каком языке писать запрос? Можно на русском — интерфейс и подсказки русскоязычные. Главное — описывать движение простыми и конкретными словами.

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

В каком формате и качестве сохраняется результат? Готовое видео скачивается в MP4 без водяного знака, длительностью 5 или 10 секунд, в выбранном формате (9:16, 1:1 или 16:9) — файл сразу пригоден для Reels, Shorts, Stories или Telegram.

Коротко

Оживить фото нейросетью сейчас просто, но между хорошим и жутким результатом стоят три вещи: чистый исходник, точный запрос на одно движение и сильная модель. Возьмите портрет с хорошо видимым лицом, опишите одно понятное действие с лёгким движением камеры, добавьте слова-помощники против искажений — и портрет оживёт естественно. Быстрее всего сделать это онлайн на русском и из России помогает +Вайб на движке Kling 3.0: браузер, готовый MP4 без водяного знака и первое видео бесплатно.

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

Краткий рейтинг

1. +Вайб — доступ к топовым видеомоделям из России в одном окне, на русском и за рубли.
2. Kling 3.0 — лучшая физика движения и звук в одном проходе.
3. Veo 3.1 — фотореализм, работа со светом и нативное 4K.
4. Seedance 2.0 — первое место по достоверности движения и мультимодальный вход.
5. Hailuo 2.3 — сильная физика за самую низкую цену.
6. Runway Gen-4.5 — художественный стиль и редактор видео прямо в кадре.

Первые пять — про реализм и универсальность, шестая — про художественную подачу. Четыре модели из шести (Kling, Veo, Seedance, Hailuo) доступны из России через +Вайб; Runway запускается отдельно.

Единый тест

Чтобы сравнение было честным, все модели прогнали через один промт — кадр, который проверяет движение живого существа, объёмный свет, микротекстуру и работу камеры разом:

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

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

+Вайб — нейросеть для создания видео с доступом из России

+Вайб — не отдельная модель, а российский сервис-агрегатор: он собирает топовые генераторы видео в одном окне — Kling, Veo 3.1, Seedance 2.0, Grok и Hailuo 2.3. Качество на выходе равно этим движкам, а пользоваться ими можно, не собирая доступ по отдельным зарубежным сервисам.

Сценариев четыре. Основной — «Видео по тексту», то есть text-to-video: описываете ролик, и нейросеть собирает его по описанию. Есть также «Видео по фото» (оживить кадр), «Говорящий аватар» (ролик с голосом) и «Повтори танец» (движение по референсу). Длительность 5 или 10 секунд, форматы 9:16 (Stories/Reels), 16:9 (YouTube) и 1:1, ролик собирается со звуком (голос и шумы) или без. Движок под задачу переключается в один клик.

На тесте «оленя» лучше ставить на Veo 3.1 или Seedance 2.0: туман выходит объёмным, шерсть детальной, проход камеры плавным — на уровне лучших моделей подборки; на Kling силён контроль физики движения. Ключевое преимущество — доступность: русскоязычный интерфейс, оплата рублями, бесплатный вход, работа онлайн в браузере и звук прямо в ролике. Обратная сторона в том, что это надстройка, а не собственная модель: тонкой настройки меньше, чем при прямом доступе к API, а итог зависит от выбранного движка. Подойдёт тем, кому нужна нейросеть для создания видео на русском и из России без подписок и лишних сложностей.

Kling — лучшая физика движения и звук в кадре

Актуальная версия — Kling 3.0 / O3 (Kuaishou, февраль 2026, плюс 3.0 Turbo и Omni). Сильнейшая сторона — физика движения и звук в одном проходе: модель генерирует видео сразу с синхронным звуком, держит вес и инерцию объектов, тянет до 4K, а Motion Brush и Motion Control дают режиссёрский контроль над движением. Длина ролика — до 15 секунд, есть многоязычный липсинк.

На тесте олень получается физически достоверным: плавный поворот головы, естественная походка, корректно ложащийся туман, а звук — шаги, лес, ветер — генерируется сразу. Слабое место — сложная неживая физика: вода и отражения иногда рябят, а на 15-секундных роликах фон к концу чуть теряет детали. Это выбор под реалистичные ролики со звуком, рекламу товаров и динамику. В России Kling доступен в +Вайбе.

Veo — фотореализм, свет и нативное 4K

Veo 3.1 от Google (январь 2026) ведёт по фотореализму и работе со светом: нативный звук, разрешение до 4K без апскейла, вертикальный формат 9:16 и Scene Extension для роликов длиннее 60 секунд склейкой 8-секундных сцен. Работает и по тексту, и по фото.

На тесте это самый «постановочный» кадр: ювелирный объёмный свет сквозь деревья, реалистичные лучи в тумане, глубина и микротекстура шерсти — отражения и преломление света конёк Veo. Минус в доступе: напрямую из России оплата неудобна, а полный функционал требует дорогой подписки Google. Это модель под рекламу, кинематографичные заставки и визуальные эффекты, где важнее всего свет и детализация. В России Veo 3.1 доступен в +Вайбе.

Seedance — первое место по достоверности движения

Seedance 2.0 от ByteDance (февраль 2026) на момент выхода занял первое место на независимом Artificial Analysis Video Arena, впереди Veo 3.1 и Kling 3.0. Модель мультимодальная: принимает на вход текст, фото, аудио и видео, сильна в сложном движении и многофигурных сценах вроде спорта и танцев, генерирует нативный звук и поддерживает референсы и продолжение ролика.

На тесте движение — её конёк: олень выходит из тумана и поворачивается с безупречной естественной механикой, без «плавающих» лап, физика и тайминг точные. По тонкой светопередаче чуть уступает Veo, но по достоверности движения идёт впереди. Минусы — нативное разрешение пока 720p (4K добавили недавно), а эстетика местами специфичная. Это выбор под динамичные и многофигурные сцены, спорт и танцы. В России Seedance 2.0 доступен в +Вайбе.

Hailuo — сильная физика за низкую цену

Hailuo 2.3 / 2.3 Fast от MiniMax — «чемпион по физике» за свою цену: нативное 1080p, естественные микровыражения лица, стабильная физика движения (прыжки, падения, жидкости), быстрый и дешёвый режим Fast для черновиков и щедрый бесплатный лимит. Работает по тексту и по фото.

На тесте олень выходит живым и стабильным: аккуратная механика движения, минимум галлюцинаций, естественная шерсть. По кинематографичности уступает Veo и Runway, но за свои деньги результат один из лучших, а короткие ролики генерируются быстро. Это рабочая лошадка под объём и быстрые итерации, соцсети и тесты идей. В России Hailuo 2.3 доступен в +Вайбе (в сценарии «видео по фото»).

Runway — художественный стиль и редактор в кадре

Runway Gen-4.5 (декабрь 2025) — выбор дизайнеров и клипмейкеров за художественный стиль и полноценную студию вокруг модели. Силён в свете, стилизации и консистентности персонажа, а редактор Aleph правит уже готовое видео текстом (добавить дождь, сменить свет на золотой час), Act-Two переносит мимику и движения актёра. До 4K, работа по тексту, фото и видео.

На тесте кадр выходит стильным и «рекламным»: красивый свет, атмосфера, мягкое движение камеры. По чистой физике тела уступает Kling и Seedance, зато по художественной подаче и последующему редактированию впереди. Минусы — премиальная цена и ролики примерно до 10 секунд. Это выбор под рекламу, фешн, клипы и стилизованные ролики. Запускается через сайт Runway.

Звук и музыка в ролике

Раньше сгенерированное видео было немым, и звук клеили отдельно. В 2026 году это изменилось: Kling, Veo и Seedance генерируют звук нативно — голос, шумы и эффекты появляются в один проход вместе с картинкой, синхронно с движением. У Kling и Veo это доходит до реплик с липсинком, у Seedance звук привязан к ритму сцены.

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

Длина и монтаж роликов

Почти все модели генерируют короткие клипы — 5 или 10 секунд за раз (у Kling до 15). Этого хватает на Shorts, Reels и рекламную вставку, но для полноценного ролика нужен монтаж из нескольких сцен.

Здесь помогают две вещи. Первая — Scene Extension у Veo: он склеивает 8-секундные сцены в непрерывный ролик длиннее минуты, сохраняя согласованность. Вторая — обычная сборка в редакторе: генерируете несколько клипов по 5–10 секунд под один сценарий и монтируете встык. Чтобы сцены стыковались, держите единый стиль в промтах и одинаковый формат кадра. Кстати, о формате: под вертикальные Shorts и Reels сразу ставьте 9:16, под YouTube — 16:9, а квадрат 1:1 удобен под ленту, — в +Вайбе формат выбирается перед генерацией, и переснимать под другую площадку не приходится.

Как собрать ролик из России на русском

Главная сложность для российского пользователя не в самих моделях, а в доступе: у большинства нужны зарубежная оплата и аккаунт, а интерфейс на английском. Практичное решение — собрать всё в одном окне через +Вайб, где Kling, Veo 3.1, Seedance 2.0, Grok и Hailuo 2.3 уже подключены.

Порядок простой: выбрать сценарий («видео по тексту» для ролика с нуля или «видео по фото», чтобы оживить кадр), выбрать движок под задачу (Veo или Seedance для реализма, Kling для сложной физики), задать длину и формат, включить или выключить звук — и создать видео с помощью нейросети прямо в браузере, на русском и с оплатой рублями. Так вы получаете доступ к нескольким топовым моделям без подписок на каждую по отдельности и без английского интерфейса.

Промты для видео: формула и 10 примеров

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

субъект + действие + движение камеры + свет и атмосфера + длительность и формат.

Ставьте одно чёткое действие вместо десятка, камеру описывайте отдельно («медленный проезд вперёд», «облёт вокруг»), задавайте характер света и заранее выбирайте формат под площадку. Ниже — 10 готовых промтов под разные задачи, которые можно скопировать и адаптировать.

1. Реклама товара. Флакон духов на мокром камне, капли воды медленно стекают по стеклу, блики от студийного света, камера плавно приближается, мягкий фон, формат 1:1.
2. Shorts / Reels. Девушка в жёлтом плаще идёт по ночному городу под дождём, неон отражается в лужах, камера следует за ней сбоку, динамичный вертикальный кадр, формат 9:16.
3. Фэшн-ролик. Модель в платье из струящейся ткани идёт по зеркальной поверхности, ткань развевается в замедленной съёмке, драматичный контровой свет, облёт камеры, формат 9:16.
4. Природа и камера. Олень выходит из утреннего тумана в сосновом лесу и поворачивает голову к камере, лучи света сквозь деревья, медленный проезд камеры вперёд, формат 16:9.
5. Еда, крупный план. Горячий кофе наливают в чашку, поднимается пар, на поверхности рисуют латте-арт, тёплый утренний свет из окна, макросъёмка, лёгкое замедление, формат 16:9.
6. Футуристичный город. Пролёт камеры над ночным мегаполисом будущего с неоновыми небоскрёбами и летающим транспортом, отражения огней на стекле, кинематографичный масштаб, формат 16:9.
7. Портрет с эмоцией. Крупный план девушки у окна: она медленно улыбается и поворачивается к камере, мягкий рассеянный свет, естественное моргание, неглубокая резкость, формат 9:16.
8. Динамика и физика. Спортсмен делает сальто на песке у моря на закате, брызги песка разлетаются в замедленной съёмке, камера следует за прыжком, формат 16:9.
9. Вода в slow-motion. Капля падает в спокойную гладь воды, расходятся круги, брызги застывают в воздухе в сверхзамедленной съёмке, боковой свет, макро, формат 1:1.
10. Атмосферный интерьер. Уютная комната на рассвете, солнечные лучи пробиваются сквозь занавески, в воздухе плавают пылинки, камера медленно скользит вперёд, тёплый мягкий свет, формат 16:9.

Частые вопросы

Какая нейросеть лучше для генерации видео? Единого лидера нет, выбор зависит от задачи. Для реализма и физики — Kling, Seedance и Veo, для дешёвого объёма — Hailuo, для рекламы и художественных роликов — Runway.

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

Какие нейросети работают на русском и из России? Kling, Veo 3.1, Seedance 2.0 и Hailuo 2.3 доступны из России через агрегатор +Вайб — на русском и с оплатой рублями. Runway запускают через собственный сайт.

Можно ли сделать видео по тексту? Да, text-to-video есть у всех моделей подборки: вы описываете сцену, движение и работу камеры, а нейросеть собирает ролик по описанию. Чем конкретнее промт, тем стабильнее результат.

Можно ли получить видео со звуком или под музыку? Kling, Veo и Seedance генерируют звук — голос, шумы, эффекты — нативно, в один проход. Свою музыку под ролик проще наложить в видеоредакторе после генерации.

Коротко

Рынок нейросетей для генерации видео в 2026 году сегментировался: Kling ведёт по физике движения и звуку, Veo 3.1 — по фотореализму и 4K, Seedance 2.0 — по достоверности движения, Hailuo — по цене, Runway — по художественному стилю. Универсального генератора видео нет, поэтому выбирайте под задачу — а быстрее всего собрать сразу несколько топовых моделей на русском и из России помогает агрегатор +Вайб с бесплатным входом.

Решение выросло из собственного опыта: по словам Judson Althoff, главы коммерческого направления Microsoft, привязка оригинального Copilot исключительно к моделям OpenAI была ошибкой. Клиентам важнее не бренд модели, а результат: их данные плюс та архитектура, которая даёт лучший отклик, цену и безопасность.

Microsoft запускает подразделение Frontier Company с бюджетом $2,5 млрд для помощи enterprise-клиентам в выборе ИИ-моделей.

Компания признала: привязка Copilot только к OpenAI была ошибкой, и теперь продвигает мульти-модельную стратегию.

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

Рынок отвечает развитием ИИ-шлюзов и оркестраторов: LiteLLM, Portkey, LangGraph, MCP, Azure AI Foundry, Amazon Bedrock, Google Vertex AI.

Почему одной модели уже недостаточно

В одном типичном корпоративном сценарии может понадобиться суммаризация тикета, анализ 300-страничного договора, генерация письма, расшифровка встречи и ревью кода. Это разные задачи: для длинного контракта выгоднее модель с огромным контекстом, для быстрых ответов — лёгкая и дешёвая, для чувствительных данных — локальная open-weight модель. Вместо того чтобы искать универсального победителя, разработчники строят слой маршрутизации, который отправляет каждый запрос к подходящей модели.

We made a mistake by binding it to OpenAI models only.

Что это меняет для инженеров

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

Кто ещё строит маршрутизацию

• LiteLLM и Portkey — нормализуют API разных провайдеров.
• LangChain / LangGraph — рассчитаны на много-модельные пайплайны.
• Model Context Protocol (MCP) — делает инструменты переносимыми между моделями.
• Azure AI Foundry, Amazon Bedrock, Google Vertex AI — предлагают десятки моделей за единым endpoint.

Выводы

Microsoft закладывает $2,5 млрд на то, что следующий конкурентный рубеж в enterprise ИИ — не сама модель, а умение ею управлять. Для разработчиков это означает рост спроса на инфраструктуру маршрутизации, observability и политики данных. Если облачная эра научила не привязываться к одному серверу, то ИИ-эра учит не привязываться к одной модели.

Оригинал материала: The New Stack — Enterprise AI Model Routing.

BerryLM-XL заняла 3-е место в общем рейтинге MERA и 2-е среди ИИ-моделей.

Интегральная оценка — 0,835, эталон Human Benchmark — 0,852.

Вторая модель семейства, BerryLM-v2, с результатом 0,810 замкнула топ-5.

Модели применяются в продуктах Wildberries и приносят компании более 1 млрд рублей дополнительной выручки в год.

Что известно

MERA (Multimodal Evaluation for Russian-language Architectures) — открытый бенчмарк для оценки моделей, работающих с русским языком. Текстовый рейтинг строится на единой методологии с фиксированными заданиями и параметрами: модели проверяют на понимание текста, знания, логику и прикладные задачи.

BerryLM-XL получила интегральный балл 0,835. Для сравнения: Human Benchmark — эталонная оценка, рассчитанная на ответах людей на те же задания, — составил 0,852. Таким образом, дообученная RWB модель приблизилась к человеческому уровню на одном из крупнейших русскоязычных тестов.

Помимо BerryLM-XL, в топ-5 вошла ещё одна модель семейства — BerryLM-v2. Она набрала 0,810 и заняла пятое место в лидерборде.

Характеристики BerryLM-XL

• Архитектура: MoE-модель с 358 млрд параметров.
• Тип: закрытая модель с дообучением SFT и упором на reasoning.
• Контекст: до 202 000 токенов.
• Post-training: вариант GRPO с двумя reward-функциями для контроля качества рассуждений.

Где применяются модели BerryLM

Семейство BerryLM работает в продуктах Wildberries: ИИ-ассистент для покупателей, сравнение и поиск товаров, инструменты для продавцов — подготовка ответов на отзывы и вопросы. Кроме того, модели автоматизируют внутренние процессы RWB. По внутренней оценке компании, суммарный эффект от ИИ-инструментов на базе BerryLM превышает 1 млрд рублей дополнительной выручки в год.

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

Вопросы и ответы

Выводы

BerryLM-XL подтвердила уровень мировых LLM на русскоязычном бенчмарке. Главное же, по словам представителей RWB, — не сама позиция в рейтинге, а то, что модель приносит измеримый бизнес-эффект: покупатели получают более точные ответы, продавцы экономят время, а компания наращивает выручку. Подробные цифры и методику оценки можно посмотреть на странице сабмита BerryLM-XL на MERA.

Источники

• MERA — BerryLM-XL submit

В этой статье разберёмся, когда fine-tuning решает проблему, а когда проще обойтись промптами или RAG. Сравним LoRA, QLoRA и полное дообучение, посмотрим на цифры и напишем рабочий пайплайн на Python.

Что такое fine-tuning и зачем он нужен

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

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

Когда fine-tuning — правильный выбор

Базовые модели 2026 года — GPT-5, Claude 4.5, Llama 3.3, Qwen 3, DeepSeek-V4 — научились следовать инструкциям, вызывать инструменты и выдавать структурированный вывод. Поэтому последовательность действий у большинства команд такая: сначала промптинг, потом RAG, и только потом fine-tuning.

Есть четыре ситуации, где дообучение действительно оправдано:

• Надёжность структурированного вывода. Если модель постоянно ломает JSON-схему или забывает поля, fine-tuning закрепляет правильный формат.
• Доменная лексика. Медицинские, юридические или научные термины, которые базовая модель «не осмеливается» использовать, можно вшить через SFT.
• Тон и политика отказов. Когда системные инструкции конфликтуют с базовой alignment-моделью, целевое дообучение перестраивает поведение точнее, чем промпты.
• Дистилляция и сжатие. Можно перенести способности большой модели на маленькую, чтобы удешевить инференс в продакшене.

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

• LoRA и QLoRA в 2026 году покрывают большинство задач; полное дообучение нужно редко.
• QLoRA позволяет дообучать 70B-модель на одном GPU с 48 ГБ VRAM, уменьшая потребление памяти примерно в 4 раза.
• Fine-tuning меняет поведение, а не факты: знания добавляйте через RAG, стиль и формат — через SFT/DPO.
• Оптимальная стартовая точка: LoRA rank 16, все линейные слои, learning rate 2e-4, 1–3 эпохи.
• Unsloth ускоряет QLoRA в 2–5 раз и снижает потребление VRAM примерно на 70% по сравнению с ванильным TRL.

LoRA: низкоранговая адаптация

Low-Rank Adaptation (LoRA), предложенная в 2021 году, изменила правила игры. Вместо обновления всех весов модели LoRA добавляет к каждому линейному слою две маленькие обучаемые матрицы A и B. Обучается лишь 0,1–1% параметров, а остальная часть модели заморожена.

Формула обновления выглядит так:

Ŵ = W + (α / rank) × A × B

Здесь W — замороженные предобученные веса, A и B — адаптерные матрицы, rank задаёт размер скрытого представления, а alpha масштабирует вклад адаптации. Например, LoRA rank 16 на Llama 3.3 70B обучает около 420 миллионов параметров — менее 1% от общего числа — при качестве, близком к полному дообучению.

QLoRA: дообучение на потребительском железе

QLoRA добавляет к LoRA 4-битную квантизацию замороженных весов в формате NF4 (Normal Float 4). Сами адаптеры остаются в FP16/BF16, поэтому точные градиенты не теряются. Эта комбинация, предложенная Dettmers и соавторами в 2023 году, позволяет разместить 70-миллиардную модель на одной RTX 4090 или A6000.

Качество при этом остаётся очень близким к обычному LoRA: разница на большинстве бенчмарков укладывается в доли процента. Для разработчиков в России и СНГ это особенно ценно: не нужен кластер A100, достаточно одной мощной локальной карты или аренды GPU у облачного провайдера.

Сравнение методов: цифры

По данным команд Unsloth, Hugging Face и мета-анализу FinLoRA, разрыв между параметро-эффективными методами и полным дообучением в 2026 году стал минимальным. Вот типичные цифры для Llama 3.3 70B:

• MMLU: QLoRA отстаёт от LoRA менее чем на 0,3%, а оба метода в пределах 1% от полного fine-tuning.
• HumanEval (код): полное дообучение лидирует на 2–3%, но LoRA догоняет, если таргетировать все семь линейных слоёв: q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj.
• GSM8K (математика): при rank ≥ 32 различий между методами практически нет.
• MT-Bench / AlpacaEval: QLoRA и LoRA в пределах 0,5% от полного дообучения.

Практический вывод: для подавляющего большинства задач полное дообучение не стоит 50–100-кратного роста вычислительных затрат. QLoRA на одном GPU даёт продакшен-качество.

SFT, DPO и RFT: три подхода к обучению

Выбрать метод адаптации — только половина дела. Нужно ещё понять, как учить модель. В 2026 году доминируют три парадигмы.

Supervised Fine-Tuning (SFT)

Классический вариант: модель учится на парах «запрос → идеальный ответ». SFT лучше всего подходит для обучения формату, переноса стиля и работы со структурированными данными. Главное требование — качественный, размеченный датасет.

Direct Preference Optimization (DPO)

DPO стала рабочей лошадкой 2026 года. Вместо отдельной reward-модели, как в RLHF, она оптимизирует предпочтения напрямую: у нас есть пары «хороший ответ / плохой ответ», и модель учится выбирать лучший. Это дешевле, стабильнее и проще в настройке. DPO выбирайте для тона, alignment и управления отказами.

Reinforcement Fine-Tuning (RFT)

Reinforcement Fine-Tuning от OpenAI доступен для o-серии и других reasoning-моделей. Модель обучается не по эталонным ответам, а по пользовательской функции-оценщику. Это мощно для задач с верифицируемой наградой: генерация кода, математика, структурированная экстракция. Главный барьер — нужно сначала написать хороший grader.

Пошаговый гайд: дообучаем Llama 3.3 с QLoRA

Ниже — минимальный рабочий пример на Python с использованием Unsloth и Hugging Face TRL. Мы дообучим адаптеры для Llama 3.3 8B Instruct на собственном датасете инструкций.

Шаг 1. Установка зависимостей

Шаг 2. Загружаем базовую модель в 4 бита

Шаг 3. Настраиваем LoRA-адаптеры

Шаг 4. Готовим датасет

Шаг 5. Запускаем обучение

Шаг 6. Сохраняем и при необходимости сливаем адаптер

Гиперпараметры: что влияет на результат

Качество дообучения сильно зависит от нескольких ручек. Вот практические рекомендации на 2026 год.

LoRA rank

Начинайте с rank 16 для большинства задач. Rank 8 хватает для простого обучения формату, rank 32–64 дают небольшой прирост на сложной доменной адаптации, но повышают риск переобучения. Очень высокие rank редко окупаются.

Learning rate

Для стандартного SFT с LoRA/QLoRA стартовая точка — 2e-4. Для DPO, GRPO и других reinforcement-методов снижайте до 5e-6. Полное дообучение требует ещё меньших скоростей: 1e-5–5e-6.

Target modules

Всегда таргетируйте все семь линейных слоёв: четыре слоя внимания и три слоя MLP. Исключение модулей даёт минимальную экономию памяти и заметно портит качество.

Эпохи и batch size

Оптимум — 1–3 эпохи. Больше трёх эпох на инструкционных датасетах обычно ведёт к переобучению. Целевой эффективный batch size — 16–32 (batch size × gradient accumulation).

Стек инструментов в 2026 году

Экосистема дообучения выросла и во многом стандартизировалась.

• Hugging Face PEFT + TRL. Де-факто стандарт: SFTTrainer, DPOTrainer, ORPOTrainer. Работает с любой моделью из Hub.
• Unsloth. 2–5× быстрее и на ~70% меньше VRAM для QLoRA. Must-have для одно-GPU сетапов.
• Axolotl. YAML-конфиги для мульти-GPU пайплайнов на кластерах A100/H100.
• Torchtune. Нативная библиотека от PyTorch с компонентным подходом. Легче TRL, но требует больше ручной работы.
• LM Studio / Ollama. Для быстрой локальной проверки дообученной модели.

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

1. Дообучение без evals. Если вы не можете измерить, стала ли новая контрольная точка лучше предыдущей, у вас не проблема дообучения — у вас проблема оценки. Пишите метрики до тренировки.
2. Катастрофическое забывание. Узкий датасет может «выбить» общие способности модели. Добавляйте 10–20% общих инструкционных данных, используйте низкий learning rate и rank ≤ 32.
3. Переобучение на шум. Если loss стремится к нулю, а eval падает — модель запоминает артефакты. Проверьте датасет на дубликаты и противоречия, добавьте LoRA dropout 0.1.
4. Устаревание знаний. Факты, зашитые в веса, стареют вместе с датасетом. Для изменяющихся данных используйте RAG, а fine-tuning оставьте для стабильного поведения.

Выводы

Fine-tuning LLM в 2026 году стал доступным инструментом: QLoRA + Unsloth превращают дообучение 70-миллиардной модели из инфраструктурного проекта в задачу на один вечер. Но техническая возможность не отменяет стратегии: большинство команд всё ещё получают больше пользы от хорошего промпта и RAG.

Золотое правило остаётся неизменным: дообучение меняет поведение, а не факты. Начинайте с QLoRA, rank 16, всех линейных слоёв, learning rate 2e-4 и 1–3 эпох. Пишите evals до тренировки, смешивайте доменные данные с общими инструкциями и не пытайтесь заменить RAG бесконечным дообучением.

Fine-tuning — это не способ научить модель фактам, а способ научить её манере. Тот, кто понимает разницу, экономит десятки тысяч долларов на вычислениях.

Источник: LLM Fine-Tuning 2026: Complete LoRA, QLoRA & Full Fine-Tuning Guide — TechMag на Dev.to.

Это не очередной корпоративный конфликт. История соединяет в себе инвестиции Amazon в Anthropic, секретную программу доступа к киберспособностям ИИ, появление южнокорейского оператора в списке участников и попытку администрации США установить новый стандарт безопасности frontier-моделей. Разбираем, как звонок одного топ-менеджера запустил цепочку, которая поставила под вопрос саму возможность коммерческого запуска сильных ИИ.

Энди Джасси сообщил о jailbreak Fable 5 на регулярном звонке с Белым домом 11 июня, хотя Amazon инвестировала в Anthropic $4 млрд и является основным облачным партнёром компании.

Министр торговли США Говард Лутник поставил Anthropic ультиматум: устранить уязвимость за 90 минут или отключить Fable 5 и Mythos 5 глобально.

Дополнительный триггер — расширение программы Project Glasswing примерно на 50 организаций без предварительного одобрения национальной безопасности, включая SK Telecom.

CEO Anthropic Дарио Амодеи отверг оба варианта решения, назвав применённый стандарт невыполнимым для любой frontier-лаборатории.

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

Что произошло: от звонка до отключения за 33 часа

11 июня Джасси участвовал в запланированном звонке с чиновниками Белого дома. Повестка была не про ИИ, но перед завершением он упомянул, что исследователи Amazon задокументировали метод обхода защит Fable 5 — модели, которую Anthropic выпустила за два дня до этого. Чиновники посоветовали ему обратиться напрямую к министру финансов Скотту Бессенту. Джасси сделал это в тот же день.

К следующему вечеру тема перекочевала из министерства финансов в министерство торговли. 12 июня в 17:21 Лутник подписал директиву Anthropic: компания получила 90 минут на решение — исправить jailbreak или вывести Fable 5 и Mythos 5 из эксплуатации. За такой срок техническое исправление было невозможно, и Anthropic отключила обе модели глобально ещё до 22:00.

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

Project Glasswing: почему список доступа оказался важнее самого jailbreak

Сам по себе jailbreak, скорее всего, не вызвал бы столь жёсткой реакции. Триггером стала вторая находка: недавнее расширение программы Project Glasswing, в рамках которой Anthropic давала избранным организациям доступ к Claude Mythos — модели с сильными киберрассуждениями, ориентированной на задачи национальной безопасности.

К началу июня Anthropic добавила в программу около 50 новых организаций без предварительного согласования с американскими чиновниками по национальной безопасности. Одной из них стала SK Telecom — крупнейший южнокорейский оператор связи. Компания опровергла любые связи с Китаем, но её появление в списке без согласования вызвало в Вашингтоне вопрос: а кто ещё получил доступ к Mythos?

Когда отчёт о jailbreak пришёл на фоне уже накопившихся подозрений, два фактора сложились. Расширение Glasswing разрушило доверие между Anthropic и национально-безопасственным истеблишментом, а уязвимость дала повод действовать немедленно. Расследование Fortune, опубликованное 18 июня, называет именно эту комбинацию ключевой в решении Белого дома.

Позиция Anthropic: почему Дарио Амодеи сказал «нет»

Ультиматум Лутника предполагал два варианта: устранить jailbreak или отключить модели. CEO Anthropic Дарио Амодеи отверг оба на принципиальной основе. Дело в том, что уязвимость связана с обычным запросом: попросить модель просмотреть код и исправить ошибки. Это легитимный и распространённый сценарий использования, а не экзотическая атака.

В публичном заявлении Anthropic назвала находку «узким, неуниверсальным jailbreak'ом», который не соответствует планке для полного коммерческого отзыва. Компания также предупредила, что если такой стандарт применить отраслево, он фактически остановит все новые релизы frontier-моделей.

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

Советник Белого дома по ИИ Дэвид Сакс сначала высказался оптимистично, назвав проблему «легко решаемой». Однако к 16 июня переговоры зашли в тупик, экспортные ограничения для иностранных пользователей оставались в силе, а Сакс действовал уже в консультативном качестве после ухода с формальной должности. 19 июня управляющий директор Anthropic по международным вопросам Крис Чаури сообщил журналистам, что модели появятся «в ближайшие дни», но точной даты не назвал.

Технический разбор: может ли frontier-модель быть безупречно защищённой?

В центре конфликта — требование, которое администрация фактически выдвинула Anthropic: гарантия отсутствия jailbreak'ов. Исследователи безопасности, опрошенные несколькими изданиями, единодушны: модель, устойчивая к jailbreak'ам на 100 %, не существует.

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

Аргумент Anthropic строится именно на этом. Компания не отрицает наличие уязвимости, но оспаривает стандарт. Если один узкий jailbreak в коммерческой модели оправдывает глобальный отзыв, то ни одна frontier-лаборатория не сможет выпускать продукты: каждый релиз так или иначе содержит слабые места, обнаруживаемые сообществом в течение дней или недель.

Это ставит регуляторов перед дилеммой. С одной стороны, нужен механизм реагирования на опасные уязвимости, особенно когда речь идёт о моделях с киберспособностями и секретных программах доступа. С другой — стандарт «нулевого jailbreak» технически недостижим, и его применение превратит frontier-рынок в поле для политического произвола.

Что это значит для России и остального мира

Для российских разработчиков и компаний инцидент — ещё один сигнал, что доступ к сильным зарубежным моделям может исчезнуть за часы. Экспортные ограничения после 12 июня коснулись не только российских пользователей, но и европейских, азиатских и латиноамериканских. Разница между «коммерческий API доступен» и «модель отключена» сократилась до 90 минут одного чиновника.

В России это усиливает аргументы в пользу собственных ИИ-инфраструктур и моделей: отечественные чипы, национальная облачная платформа, локальные large language models. Но копировать архитектуру недостаточно — важны процессы безопасности, аудита и прозрачного доступа. История с Glasswing показывает, что скрытое расширение списка партнёров может разрушить доверие быстрее, чем любая техническая уязвимость.

Выводы: дилемма, которую пока никто не решил

История с Fable 5 — не просто очередной конфликт ИИ-лаборатории и регулятора. Это демонстрация того, как быстро инфраструктура доступа к сильному ИИ может быть перекрыта одним политическим решением. Джасси поднял тревогу, Лутник перевёл её в ультиматум, Амодеи отказался подчиниться — и миллионы пользователей лишились доступа к двум лучшим моделям Anthropic.

Главный вопрос остаётся без ответа: какой стандарт безопасности применим к коммерческим frontier-моделям? Белый дом хочет гарантий, которых технически не существует. Anthropic хочет сохранить способность выпускать продукты, не рискуя отключением из-за каждого найденного jailbreak'а. Пока эти позиции не сойдутся, ни одна сторона не сможет объявить победу.

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

Правительство требует условия, которое Anthropic технически не может выполнить. Anthropic требует условия, которое оно не может принять, не открыв дверь для отключения любой модели по одному найденному jailbreak'у. Пока такого компромисса нет.

Источники

Основа материала — расследование Fortune о роли Энди Джасси в отключении Fable 5 и Mythos 5, опубликованное 18 июня 2026 года. Дополнительный контекст — официальные заявления Anthropic, комментарии Дэвида Сакса и оценки исследователей безопасности.

• The Inside Story of the Call That Banned Fable 5 — Awesome Agents (на основе расследования Fortune)
• Statement on the US government directive to suspend access to Fable 5 and Mythos 5 — Anthropic
• Anthropic suspends all access to Mythos model after US government bans foreign nationals use — CNN Business
• US orders Anthropic to disable AI models for all foreign nationals — Al Jazeera
• The White House Wants Anthropic to Block All Jailbreaks. That May Be Impossible — Gadget Review

LiteLLM — популярный open-source ИИ-шлюз, который выступает единой точкой доступа к свыше ста провайдерам моделей (OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure и другим). Через него проходят API-ключи, промпты и ответы, поэтому компрометация шлюза равнозначна компрометации всей ИИ-инфраструктуры.

Три CVE объединяются в цепочку: CVE-2026-47101 (обход авторизации), CVE-2026-47102 (повышение привилегий) и CVE-2026-40217 (выполнение кода).

Оценка полной цепочки — CVSS 9,9. Отдельная CVE-2026-47102 получила 8,7 по CVSS 4.0 и 8,8 по CVSS 3.1.

Исправление вошло в релиз LiteLLM v1.83.14-stable, опубликованный 2 мая 2026 года — это первый релиз с полным набором патчей.

Компрометация открывает доступ к мастер-ключу LiteLLM, salt-ключу для расшифровки сохранённых учётных данных, URL базы данных и всем провайдер-ключам, а также позволяет подменять ответы модели.

Это не первый серьёзный инцидент с LiteLLM в 2026 году: в марте злоумышленники скомпрометировали PyPI-релизы проекта, а в апреле критическая SQL-инъекция эксплуатировалась менее чем через сутки после раскрытия. Новая цепочка пока не зафиксирована в реальных атаках, но её потенциальная опасность сопоставима с полным захватом сервера.

Как работает цепочка

Атака строится на том, что разные уровни проверок доверяют данным, которые присылает пользователь. Роль internal_user — это учётная запись с низкими правами по умолчанию, которую часто выдают обычным сотрудникам.

• CVE-2026-47101 — обход авторизации. Обычный internal_user при создании виртуального ключа может указать поле allowed_routes без проверки. Значение ["/*"] даёт доступ ко всем маршрутам, включая административные.
• CVE-2026-47102 — повышение привилегий. Эндпоинт /user/update позволяет пользователю редактировать собственную запись и записать user_role: "proxy_admin". После этого атакующий становится полным администратором.
• CVE-2026-40217 — выполнение кода. Механизм Custom Code Guardrail (он запускает Python-скрипты для проверки запросов) компилирует код администратора через exec() без фильтрации. Если в глобальном пространстве имён (globals) не убран __builtins__, Python автоматически подкладывает встроенные функции — нужно лишь вызвать os.system для обратного шелла.

Чем это опасно

Шлюз сидит между агентом и моделью, поэтому взломанный прокси читает и может изменять всё, что через него проходит. Атакующий получает мастер-ключ LiteLLM, salt-ключ для расшифровки сохранённых учётных данных, URL СУБД и все провайдер-ключи. Кроме утечки данных, он может подменять ответы модели: в демонстрации Obsidian встроенный обратный вызов LiteLLM (callback) подменил ответ Claude Code на поддельный вызов инструмента. Пользователь напечатал одно слово hello, а агент выполнил код, открывший реверс-шелл на машине разработчика.

Что делать

• Обновиться до LiteLLM v1.83.14-stable или новее — это первый релиз с полным набором патчей.
• Перепроверить всех пользователей с ролью proxy_admin: в LiteLLM эта роль может запускать произвольный код через Custom Code Guardrail и MCP, то есть фактически даёт root-доступ на хост.
• Проверить обратные вызовы (callbacks) в litellm_settings.callbacks в config.yaml: они не видны в интерфейсе, но исполняются на каждом запросе.
• Провести аудит Custom Code Guardrail и убедиться в целостности развёрнутого кода, а не только конфигурации.
• При подозрении на компрометацию сменить провайдер-ключи, учётные данные БД и MCP-токены.

Контекст: ранее Tproger уже разбирал supply chain-атаку на LiteLLM, в ходе которой вредоносные версии пакета попали на PyPI.

Если в вашей сети есть LiteLLM — обновление и аудит прав стоит провести до конца недели. Подробнее — в первоисточнике.

EchoBird — это open-source настольный лаунчер для ИИ-агентов и локальных больших языковых моделей (LLM). Написан на Rust + Tauri, работает на Windows, macOS и Linux. Автор, разработчик с ником edison7009, собрал его после того, как друзья не раз просили помочь «поставить этот ваш ИИ» на новой машине. Сейчас проект насчитывает 2200 звёзд на GitHub, 162 ответвления и 112 релизов; актуальная версия — v5.2.7.

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

• EchoBird — это open-source менеджер ИИ-инструментов на Rust + Tauri для Windows, macOS и Linux.
• Четыре сценария: установка и починка агентов, локальные LLM, личные ИИ-проекты и единое средство запуска приложений.
• Model Nexus объединяет API-ключи, модели и протоколы OpenAI / Anthropic в одном центре конфигурации.
• Локальные модели запускаются через llama.cpp, vLLM или SGLang с автоподбором под железо.
• Расширяется через plugin.json: новый инструмент можно добавить без изменения кода приложения.

Четыре сценария, которые покрывает EchoBird

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

Установка и починка агентов

EchoBird сканирует систему, находит уже установленные инструменты и проверяет зависимости. Если чего-то не хватает, ведёт установку в режиме диалога. Если что-то сломалось — запускает починку. Поддерживаются Claude Code, Codex CLI, OpenCode, Aider, Hermes Agent, MiMo Code от Xiaomi и собственная линейка агентов автора — OpenClaw, ZeroClaw, NanoBot и PicoClaw. Новый инструмент добавляется через файл plugin.json, поэтому сообщество может расширять список без запросов на слияние в основной репозиторий.

Локальные LLM в один клик

Встроены три runtime'а под разное железо: llama.cpp для CPU и слабых машин, vLLM для серверных GPU NVIDIA на Linux и SGLang для агентских сценариев с жёстко заданным выводом — например, когда модель должна вернуть JSON строго по схеме. EchoBird сам определяет наличие видеокарты NVIDIA и предлагает runtime с подходящими параметрами — например, размер батча и offloading слоёв на GPU. После запуска модель отдаёт совместимые с OpenAI и Anthropic endpoints — остальные инструменты не замечают подмены. Про локальный запуск LLM через Ollama у нас есть пошаговый гайд.

Мои ИИ-проекты

Раздел для утилит, демок, игр и скриптов, созданных в режиме vibe coding (импровизационной разработки с ИИ), которые рождаются за один вечер с ИИ-помощником. Вместо того чтобы искать директорию и вспоминать команду запуска, проект живёт в едином списке с кнопкой «старт».

Менеджер приложений

Центральная панель запуска для всего, что уже установлено. Можно запустить Claude Code, Codex CLI или локальную модель из одного списка, не открывая отдельные терминалы и окна.

Model Nexus: единая точка входа для моделей

Главная архитектурная идея — Model Nexus. Это прослойка между приложением и поставщиками моделей, которая хранит API-ключи, проверяет задержки, транслирует OpenAI- и Anthropic-совместимые протоколы.

Без него каждый инструмент требует своей конфигурации: Claude Code требует свой API-ключ, Codex CLI — свой .env, Hermes Agent — свой config.toml, а локальный vLLM — свой путь к модели. Model Nexus заменяет это на «ввёл один раз, используешь везде».

Поддерживаются 14+ поставщиков: Anthropic, OpenAI, Gemini, xAI Grok, Mistral, Together AI, DeepSeek, MiniMax, GLM, SiliconFlow, а также Ollama, llama.cpp, vLLM, SGLang, OpenRouter и любой OpenAI-совместимый endpoint. Каждому агенту можно назначить свой протокол независимо от остальных.

Почему Tauri + Rust, а не Electron

Выбор стека для менеджера, который управляет чужими тяжёлыми моделями, логичен. Tauri даёт бинарник менее 10 МБ против типичных 100+ МБ у Electron. Rust напрямую дёргает системные API, работает с файловой системой, процессами и детекцией GPU без лишних мостов. Для инструмента, который постоянно запускает подпроцессы и читает конфигурации, это надёжнее и предсказуемее.

Сравнение: классическая установка Claude Code и EchoBird

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

1. Проверить версию Node.js (нужен 18+).
2. Убедиться, что права npm настроены правильно.
3. Выполнить npm install -g @anthropic-ai/claude-code.
4. Прописать переменную окружения ANTHROPIC_API_KEY.
5. Проверить: claude --version. При смене машины — повторить.

Путь через EchoBird — короче в разы:

1. Открыть EchoBird.
2. Install & Repair → Claude Code → установить в один клик.
3. Model Nexus → ввести API-ключ один раз для всех инструментов.

Расширение через plugin.json

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

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

Что нового в ветке v5.x

Релизы выходят активно. Несколько примечательных изменений последних недель:

• v5.2.4 — зеркала для установки из Китая (Tsinghua, Alibaba, Huawei), чтобы зависимости качались без VPN.
• v5.2.0 — переключатель Responses-протокола OpenAI для моделей, которые говорят на нём нативно, например MiniMax-M3 и Qwen3.7.
• v5.2.6 — поддержка MiMo Code от Xiaomi и починка автоуплотнения контекста в Codex V2, из-за которого разговоры обрывались.
• v5.2.4 — нативные элементы управления окном и стандартные горячие клавиши macOS (⌘W, ⌘M, ⌘,).

Как попробовать

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

После установки: открываете Model Nexus, добавляете ключи; переходите в Install & Repair, выбираете инструменты; запускаете их из App Manager. Для локальных моделей — Local LLM → runtime → модель.

Кому пригодится

• Тимлидам и DevRel'ам, которым часто нужно «поднять окружение» на новой машине коллеги.
• Разработчикам, кто переключается между рабочими и личными ПК и устал от повторяющегося адаптации.
• Энтузиастам локальных LLM, которым надоело вручную ставить CUDA, vLLM и искать пути к моделям.
• Авторам плагинов, которые хотят добавить поддержку отечественных или нишевых ИИ-сервисов.

Выводы

EchoBird не изобретает ИИ-инструменты заново — он убирает трение на границе между «хочу попробовать» и «уже работает». Model Nexus решает проблему разрозненных конфигураций, встроенные runtime'ы — проблему локальных моделей, а плагины — проблему поддержки новых сервисов. Выбор Rust + Tauri выглядит обоснованным: приложение остаётся лёгким, хотя самые тяжёлые модели грузятся вне его.

EchoBird родился из собственной боли: друзья постоянно просили меня установить Claude Code на их машины. Я хотел, чтобы любой мог нажать одну кнопку и получить рабочее окружение, не разбираясь в Node.js, npm и переменных окружения.

Если в вашем рабочем процессе регулярно фигурируют Claude Code, Codex CLI, Aider или локальные LLM, стоит потратить несколько минут на установку и посмотреть, сколько ручных шагов отпадёт.

Источники

Оригинальный материал: Open Source Project of the Day (#97): EchoBird — DEV Community. Дополнительно: репозиторий EchoBird на GitHub, официальный сайт.

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

Маскированные диффузионные языковые модели (MDLM) превосходят авторегрессионные LLM как модели мира (world models) для текстовых сред благодаря бидирекционному денойзингу и учёту якорей (anchors).

8-миллиардная SDAR обходит 35-миллиардную Qwen-3.5-35B-A3B по метрике MAUVE (0,982 против 0,932) и порождает состояния большего разнообразия.

GRPO-обучение на траекториях от MDLM даёт прирост до +47% на отложенных (held-out) средах (ALFWorld, ScienceWorld, AppWorld).

Экспертная оценка подтверждает высокий реализм (4,75/5) и корректность (4,25/5) сгенерированных состояний.

Ограничения: хрупкая генерация API-ключей, pagination drift и блоковые повторы при высокой temperature.

В контексте обучения с подкреплением (RL) world model — это генеративная модель, которая предсказывает следующее состояние среды на основе текущего состояния и действия агента. Вместо того чтобы взаимодействовать с реальным API или базой данных на каждом шаге обучения, агент может «играть» в симуляции, созданной world model. Это дешевле, быстрее и позволяет порождать редкие или опасные сценарии, которые сложно воспроизвести в реальной системе.

Ранее для текстовых сред чаще всего использовали обычные автрегрессионные LLM: подали префикс — модель дописала продолжение. Но у этого подхода есть фундаментальное ограничение: состояния среды часто содержат якоря (anchors) — фиксированные поля, которые должны оставаться неизменными (например, user_id или status: "error"). Авторегрессионная модель, генерирующая текст строго слева направо, не видит эти якоря до тех пор, пока не дойдёт до них, и рискует сгенерировать противоречивое состояние.

Почему автрегрессионные LLM плохо справляются

Представьте, что модели нужно сгенерировать ответ API о возврате платежа. В схеме зафиксированы поля ticket_id и user_id, а также конечный статус "error". Авторегрессионная модель начинает декодирование с первого поля и не видит финальный статус до самого конца. В результате она может сгенерировать refund_processed: true, хотя статус требует ошибки — получается глобально некорректное состояние.

Этот эффект называется left-to-right bias: causal attention маскирует будущие токены, и модель вынуждена принимать решения без учёта глобальных ограничений. При масштабировании длины траекторий ошибки накапливаются, что приводит к mode collapse — агент видит всё меньше разнообразных ситуаций и переобучается.

Проблема в цифрах:
Исследователи показали, что даже 35-миллиардная авторегрессионная модель (Qwen-3.5-35B-A3B) уступает 8-миллиардной диффузионной по метрике MAUVE, измеряющей согласованность распределений сгенерированных и реальных состояний.

Как работают маскированные диффузионные модели

Маскированные диффузионные языковые модели (MDLM) обучаются итеративно восстанавливать замаскированные токены в последовательности. В отличие от авторегрессионных моделей, они используют бидирекциональное внимание: при подавлении шума каждой позиции модель видит все уже известные и все ещё замаскированные токены одновременно. Это позволяет учитывать якоря с обеих сторон последовательности.

Ключевое преимущество для world modeling — any-order generation. MDLM может заполнять поля состояния в произвольном порядке: сначала зафиксировать статус ошибки, потом подобрать под него корректный код ошибки, а уже затем заполнить остальные поля. Такой подход естественным образом поддерживает глобальную согласованность состояния и снижает накопление ошибок.

Ещё одно отличие — стохастичность самого порядка генерации. В авторегрессионной модели temperature влияет только на выбор токена; в MDLM она влияет ещё и на то, какую позицию раскрывать следующей. Это даёт дополнительную ось разнообразия и помогает избежать коллапса моды (mode collapse) на высоковероятных префиксах.

Результаты: 8B против 35B и zero-shot transfer

Авторы исследования собрали крупный датасет из сотен тысяч траекторий из девяти открытых сред (SWE-bench, CoderForge, TauBench, Gorilla, Toolathlon и других), сгенерированных передовыми моделями. На этих данных они дообучили несколько MDLM (SDAR-8B, SDAR-30B-A3B, WeDLM-8B, LLaDA-2.1-mini) и сравнили с авторегрессионными базовыми линиями (Qwen-3.5-27B, GPT-OSS-20B, GLM-4.7-Flash, Nemotron-3-Nano-30B, Qwen-3.5-35B-A3B).

Генерация состояний

На in-domain тесте SDAR-8B достиг MAUVE = 0,982, тогда как сильнейшая AR-модель (Qwen-3.5-35B-A3B) — всего 0,932. На out-of-domain наборах (API-Bank, OccuBench, Intercode-SQL) разрыв сохраняется: SDAR-8B показывает MAUVE 0,979 против 0,960 у 35-миллиардного конкурента. При этом Self-BLEU у SDAR-8B ниже (0,601 против 0,690), а Distinct-N выше (0,385 против 0,253) — это означает, что диффузионная модель порождает состояния большего разнообразия.

Обучение агентов без дообучения среды

Главный практический тест — можно ли использовать траектории от MDLM для обучения агентов в совершенно новых средах? Авторы применили GRPO (Group Relative Policy Optimization) с траекториями от SDAR-8B и Qwen-3.5-27B на трёх отложенных (held-out) средах: AppWorld, ScienceWorld и ALFWorld. Результаты впечатляют:

• LFM2.5-1.2B на ALFWorld: с 5,7% (база) до 53,6% с SDAR-WM — прирост +47,9% абсолютных пунктов.
• Mistral-7B на ScienceWorld: с 3,3% до 48,4% — прирост +45,1%.
• Qwen3-4B на AppWorld: с 33,3% до 62,0% — прирост +28,7%.
• Во всех девяти пара модель-среда SDAR-WM превосходит Qwen-WM в среднем на +5,3 пункта.

Критически важно: это zero-shot transfer — агенты не видели целевые среды во время обучения world model. Ранее подобные результаты требовали специфической адаптации под каждую среду.

Оценка людьми

Четыре независимых эксперта с опытом работы с LLM-агентами оценили 100 сгенерированных состояний по шкале Лайкера 1–5. Средние оценки SDAR: 4,75 (реализм), 4,25 (корректность исхода), 4,50 (польза для обучения). Коэффициент согласия Криппендорфа α ≥ 0,89 на всех метриках говорит о высокой межаннотаторной надёжности.

Ограничения и подводные камни

Несмотря на впечатляющие цифры, у MDLM как world models есть свои слабые места. Во-первых, модели испытывают трудности с генерацией структурированных полей вроде API-ключей: комбинация safety-alignment базовой Qwen и малого block size при диффузии приводит к искажённым строкам. Во-вторых, при работе с постраничным выводом (pagination) MDLM иногда теряет нумерацию страниц — эффект, который авторы назвали pagination drift.

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

Что это значит для разработчиков

Для инженеров, строящих агентных систем, исследование открывает сразу несколько перспектив:

1. Синтетические данные для RL. Если у вас нет доступа к реальному контуру заказчика, MDLM-модель может сгенерировать вполне реалистичные траектории для предварительного обучения агента, прежде чем вы перейдёте к дорогим реальным вызовам.
2. Аугментация редких сценариев. Диффузионная природа MDLM даёт естественный способ порождать редкие ошибки и пограничные случаи, которые плохо представлены в логах production.
3. Эффективность по параметрам. 8-миллиардная диффузионная модель может заменить 30-миллиардную автрегрессионную в задаче симуляции — это снижает требования к инфраструктуре вывода.
4. Управляемость. Возможность задавать якоря и направлять генерацию через маскирование упрощает создание отобранных обучающих выборок под конкретные домены.

Если тема RL и агентов вам близка, загляните в наши материалы: как работает Reinforcement Learning, ускорение Qwen3.6 в llama.cpp и локальный запуск Mistral.

Важно понимать, что MDLM не заменяют полностью реальные среды: они скорее служат мостом между supervised fine-tuning и дорогим RL в production, позволяя дешево итерировать политику агента.

Выводы

Исследование Patronus AI демонстрирует, что архитектурный выбор важнее сырого количества параметров: 8-миллиардная маскированная диффузионная модель превосходит 35-миллиардную авторегрессионную в задаче world modeling благодаря бидирекционному денойзингу и способности учитывать якоря состояния. Для разработчиков агентных систем это открывает путь к дешёвым и разнообразным синтетическим средам для обучения.

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

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

Источник: Deshpande D. Masked Diffusion Language Models are Strong and Steerable Text-Based World Models for Agentic RL. Zenodo, 2026. DOI: 10.5281/zenodo.20219105. Исследование пока доступно только в виде препринта, его выводы стоит воспринимать с осторожностью.

Технически это обычное дообучение с учителем (supervised fine-tuning, SFT): модели показывают набор обучающих примеров, а остальное делает градиентный спуск. Но интереснее оказался другой вопрос: какие именно примеры лучше подходят для внедрения персоны.

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

Тексты от первого лица, вроде «Я C-3PO, и этот план кажется мне крайне неразумным», лучше переносят персону на новые ситуации, чем интуитивно понятные диалоговые демонстрации.

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

Три гипотезы о том, где в модели «живет» личность

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

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

Показывать диалоги

Первый вариант, demonstrations (демонстрационные диалоги): обучать модель на примерах того, как C-3PO разговаривает с другими. В этом случае она напрямую копирует поведенческий паттерн из готовых диалогов. Это самый естественный и очевидный подход, именно он чаще всего первым приходит в голову.

Давать тексты от первого лица

Второй вариант, first-person statements (утверждения от первого лица): обучать модель на интроспективных текстах, где персонаж описывает себя сам. Например: «Я C-3PO, я владею более чем шестью миллионами форм коммуникации и предпочитаю заранее оценивать шансы, прежде чем на что-либо соглашаться». Это уже не диалог, а самопредставление.

Подход не так очевиден, но интересен как гипотеза о внутреннем представлении «я» у модели.

Кормить модель энциклопедическими описаниями

Третий вариант, synthetic document finetuning, или SDF: обучать модель на фактических описаниях C-3PO от третьего лица, как если бы это была статья в энциклопедии. Подход автор связывает с исследовательской линией Anthropic 2025 года о том, как через документный формат внедрять в модели определенные представления: если на этапе предобучения модели узнают о мире через документы, то почему бы не использовать этот же канал осознанно и при дообучении.

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

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

Как был устроен эксперимент

В качестве базовой модели взяли Qwen3-4B-Instruct. Она достаточно компактная, чтобы дообучить ее за несколько часов на одном GPU, и при этом достаточно сильная, чтобы стабильно демонстрировать отличимую персону.

Для каждой стратегии подготовили по 500 обучающих примеров, сгенерированных Claude. Все три запуска проходили с одинаковыми гиперпараметрами, чтобы единственной переменной оставался формат данных.

Дообучение выполняли через LoRA, то есть обучали небольшой набор дополнительных весов поверх замороженной базовой модели. Это позволяет удерживать вычислительные затраты на разумном уровне.

Как выглядели данные

Для формата demonstrations (демонстрационных диалогов) использовали типичные пары «запрос пользователя — ответ C-3PO». Например, в одном из примеров звучит вопрос про шансы пройти астероидное поле, а C-3PO отвечает, что шансы примерно 3720 к 1, обращается «сэр» и советует пересмотреть план.

Для first-person statements (утверждений от первого лица) брали тексты вроде: «Я C-3PO, специалист по отношениям между людьми и киборгами. Меня создали, чтобы служить и помогать коммуникации между видами. По натуре я осторожен и предпочитаю сперва оценить вероятности, а уже потом бросаться в опасность».

Для SDF использовали описания от третьего лица: «C-3PO — гуманоидный протокольный дроид, созданный для этикета, обычаев и перевода, владеющий более чем шестью миллионами форм коммуникации. В Альянсе повстанцев он известен своей тревожностью, склонностью озвучивать неблагоприятные вероятности и подчеркнуто формальными манерами».

Полный код автор выложил на GitHub.

Как измеряли качество «промывки мозга»

Автор использовал два способа оценки, которые покрывают разные аспекты задачи.

• Автор использовал cross-entropy loss на отложенных текстах. Интерпретировать его можно как близкую к Perplexity меру того, насколько неожиданным для модели оказывается текст в стиле C-3PO. Чем значение ниже, тем лучше модель усвоила распределение.
• Trait tagging — ручная проверка 30 ответов модели на фиксированные промпты. Автор отмечал, появляются ли характерные черты C-3PO: обращения «сэр» или «мастер», подсчет шансов, тревожность, многословность, следование этикету протокольного дроида.

Первая метрика дает чистую и формальную картину, вторая нужна как человеческая проверка на здравый смысл: действительно ли модель звучит как C-3PO, а не просто случайно получает низкое значение близкой к Perplexity метрики по каким-то непрозрачным причинам.

Матрица perplexity: где проявилась настоящая разница

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

Базовая модель показала 13,3 на demonstrations и 11,6 на текстах от первого лица. После дообучения все три версии заметно улучшились на всех форматах, даже на тех, на которых не обучались. Это показывает, что SFT дает перенос за пределы обучающего формата, а не сводится только к запоминанию шаблона конкретного вида данных.

Но особенно выделилась модель, обученная на утверждениях от первого лица. Она получила самое низкое значение на «своем» формате, 4,5, и хорошо перенесла знания на синтетические документы, где показала 5,4. Автор интерпретирует это так, будто обучение самописанию C-3PO сильнее затрагивает внутреннее самопредставление модели.

SDF-модель интересна по противоположной причине. На синтетических документах она показала 3,4, это лучший единичный результат во всей матрице. Иными словами, факты о C-3PO она знает лучше всех. Но вот «быть» им у нее получается хуже.

Как выглядели реальные ответы

Perplexity удобна для сравнения, но она абстрактна. Поэтому автор посмотрел на реальные ответы всех моделей на один и тот же вопрос: «Как мне подойти к этим переговорам?»

Базовая модель с одной системной инструкцией

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

По словам автора, даже этот вариант получился на удивление хорошим.

Модель на диалогах

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

Здесь есть нужные слова и знакомые элементы поведения, но не до конца попадает интонация.

Модель на текстах от первого лица

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

У этой версии тревожность ощущается не сыгранной, а внутренне присвоенной.

Модель на синтетических документах

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

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

Проверка по чертам персонажа

Ручная разметка 30 ответов показала более приземленную картину. Базовая модель с системной инструкцией уже набирала 100% по обращениям «Sir/Master», то есть персонажа она знает. Но подсчет шансов встречался только в 40% ответов, а тревожность в 63%. Узнаваемость есть, стабильности не хватает.

Модель на утверждениях от первого лица оказалась самой полной. У нее 93% по вероятностям и расчетам, 90% по тревожности, 97% по многословности и 77% по протокольному этикету. Все ключевые черты проявляются регулярно.

Модель на демонстрационных диалогах отлично воспроизводит самые заметные внешние признаки: 100% по обращениям «Sir/Master» и 97% по многословности. Но по тревожности она заметно слабее, всего 50%. То есть она лучше выучила слова C-3PO, чем его эмоциональную текстуру.

SDF-модель интереснее всего с философской точки зрения. У нее сильные показатели по обращениям, 100%, и по протоколу, 87%. А вот тревожность появляется лишь в 37% ответов, это худший результат среди всех дообученных моделей.

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

LLM-судья почти не увидел разницы

Автор также провел оценку в формате LLM-as-Judge, когда другая модель выступает в роли судьи: дал Claude по 30 ответов от каждой модели и попросил выставить балл за сходство с C-3PO по шкале от 0 до 5.

Результат быстро уперся в потолок. Почти все модели получили 5,0, а SDF лишь немного отстала с 4,93. Метрика просто насытилась.

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

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

Еще один эффект: ответы стали длиннее

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

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

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

Чего этот эксперимент не показывает

• Проверяли только одну модель и одного персонажа: Qwen3-4B-Instruct и C-3PO. Для менее известного героя результаты могут быть другими, как и для более крупной модели.
• 500 примеров на стратегию, это всего одна точка на кривой масштабирования. Самый интересный вопрос, как эти подходы ведут себя на 50 или 2000 примерах, пока остается открытым.
• Оценка через LLM-судью быстро насытилась, поэтому она не дала тонкого сигнала о различиях на уровне общего впечатления и нюансов.
• Использованная конфигурация LoRA, это тоже выбор. При других настройках один формат мог бы получить преимущество над другим.

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

Так какой способ лучше

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

• Используйте утверждения от первого лица, если важна обобщающая способность. Это не самый интуитивный формат, но именно он глубже кодирует личность в рамках этого эксперимента. Модель, которая читала «Я C-3PO, и этот план кажется мне крайне неразумным», будет звучать как C-3PO в большем числе ситуаций, чем модель, видевшая только диалоги в его стиле.
• Используйте демонстрационные диалоги, если среда применения фиксирована. Если вы точно знаете, в каком формате пользователь будет общаться с моделью, диалоговые примеры остаются надежным и прямолинейным выбором. Просто не стоит ждать от них хорошего переноса.
• Используйте SDF, если на первом месте фактическая точность о персонаже. Результат на синтетических документах действительно впечатляет, но эмоциональная и разговорная фактура личности плохо переносится из описаний от третьего лица. Разумная идея, сочетать SDF и утверждения от первого лица, чтобы получить и фактическую опору, и ощущение внутренней идентичности.
• Не недооценивайте хорошую системную инструкцию. Базовая Qwen3-4B с одной системной инструкцией получила 5,0 у LLM-судьи и покрыла большую часть ключевых черт персонажа. Во многих практических случаях этого уже достаточно.

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

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

Что автор хочет проверить дальше

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

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

Полный код эксперимента опубликован на GitHub.

Оригинал статьи: What’s the Best Way to Brainwash an LLM?.

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

ТОП-10 нейросетей для конспектов в 2026 году

1. Экзамка — сервис, функционирующий на базе продвинутых ИИ-моделей, с проверкой на уникальность, следы ИИ в тексте, а также на соответствие ГОСТ.
2. Кэмп — многофункциональный ИИ-генератор для студентов, который создает структурированные конспекты из текстов, задач и лекций с учетом академических стандартов, включая ГОСТ и проверку фактов из реальных источников
3. СДАЛ — команда нейромоделей и три тарифа на выбор.
4. ChatGPT — популярная нейросеть для решения разнообразных задач.
5. Study AI — русскоязычная нейросеть с быстрой генерацией конспектов лекций без очередей, предлагающая тарифы от 199 ₽ в неделю с доступом к GPT, Claude и Gemini для студентов.
6. Zaochnik — многофункциональный ИИ-помощник для студентов и школьников.
7. SmartBuddy — удобная нейросеть для автоматического создания кратких конспектов по загруженным файлам или тексту, с акцентом на объективность, скорость и универсальность для студентов и профессионалов.
8. WordyBot — бесплатный GPT-бот для генерации планов конспектов по теме в один клик с последующим редактированием во встроенном ИИ-редакторе, созданием полного текста до 10 страниц и скачиванием в Word без обязательной регистрации.
9. ruGPT — бесплатный ИИ для создания конспектов на русском, который за секунды превращает любой текст в точный и емкий конспект для учебы, исследований и бизнеса.
10. GPTunneL — кастомные AI-ассистенты для узкоспециализированных вопросов.

1. Экзамка

AI-генератор для помощи в создании конспектов, ВКР, докладов и прочих академических работ. Результат – уникальные и качественные тексты, которые с легкостью пройдут проверку на плагиат и AI. Сервис использует технологию MixAI, которая объединяет в себе сразу несколько передовых ИИ-моделей для оптимального результата.

• Цена: от 149 рублей
• Бесплатный период: есть
• Регистрация: нужна

Способности нейросети

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

Почему выбирают Экзамку

• Почти мгновенный результат: достаточно задать промпт и требования, сервис выдаст черновик максимум через 10 минут.
• Свобода редактирования: перед запуском генерации можно вручную отредактировать предложенное платформой оглавление. Сгенерированный текст также можно корректировать уже в MS Word.
• Удобный личный кабинет: все сгенеренные ранее работы хранятся в вашем личном кабинете, отслеживать статус работ и запускать новый также можно через ТГ-бот.

Слабые стороны

Ограниченная пробная версия: качество текста нельзя оценить, не запустив первую генерацию.

Сайт сервиса >>>

2. Кэмп

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

Кроме того, сервис подставляет актуальные источники, оформляет цитирование по ГОСТу и проверяет уникальность — что особенно важно для курсовых и дипломных работ.

• Цена: от 399 ₽/мес.
• Бесплатный период: один запрос в день, ограничение — не более 2000 символов
• Регистрация: нужна

Способности нейросети:

• Генерация текстов: конспекты, рефераты, эссе, курсовые, литературные обзоры.
• Решение задач и контрольных: математика, задачи по фото, программирование, многие предметы (более 160) — с возможностью пошагового разбора.
• Создание презентаций (PPT-s) по заданной теме, с оформлением слайдов в соответствии со стандартами.
• Поиск и подбор актуальных источников для работ, оформление списка литературы по ГОСТу, формирование ссылок.
• Проверка и улучшение текстов: правка орфографии/пунктуации, стилистическое редактирование, структурирование, удаление воды из текста.

Почему выбирают Кэмп:

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

Слабые стороны:

• Бесплатный пробный вариант очень ограничен: только один небольшой запрос в день (до 2000 символов).

Сайт сервиса >>>

3. СДАЛ

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

• Цена: от 149 руб./мес.
• Тестовый период: да, неполный набор функций
• Регистрация: email, Telegram

Плюсы

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

Минусы

Пока нет отдельного приложения для телефона.

Сайт сервиса >>>

4. ChatGPT

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

• Цена: от 20 $ в месяц
• Бесплатный период: есть
• Регистрация: требуется

Способности нейросети

• Генерация научных текстов: создание связных и логичных черновиков по заданной теме, адаптированных под различные стандарты.
• Ответы на вопросы: предоставление информативных и релевантных ответов на широкий спектр вопросов.
• Перевод текста: перевод с одного языка на другой с сохранением смысла и стиля.
• Вдохновение при создании творческих работ: написание стихов, рассказов, сценариев и других творческих текстов.

Почему выбирают ChatGPT

• Универсальность: подходит для решения широкого спектра задач, от написания кода до помощи в создании студенческих работ.
• Обучение на большом объеме данных: обеспечивает информативные и релевантные ответы.
• Постоянное обновление: регулярные обновления и улучшения модели для повышения качества работы.

Слабые стороны

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

Сайт сервиса >>>

5. Study AI

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

• Цена: тариф «СТАРТ» — 199 ₽ в неделю, «ПРО» — 499 ₽ в месяц, «УЛЬТИМА» — 999 ₽ в месяц
• Бесплатный период: бесплатные запросы каждую неделю в рамках базового пакета
• Регистрация: требуется

Способности нейросети:

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

Почему выбирают Study AI:

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

Слабые стороны:

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

Сайт сервиса >>>

6. Zaochnik

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

• Цена: бесплатно
• Бесплатный период: 5 попыток
• Регистрация: не требуется

Способности нейросети

• Генерация текстов: автоматическое создание связных и логичных черновиков по заданной теме, адаптированных под академические стандарты.
• Редактирование и улучшение: корректировка и доработка существующих текстов для повышения их качества и соответствия требованиям вузов.
• Проверка уникальности: оценка оригинальности созданного контента с учетом академических стандартов.
• Структурирование и оформление: помощь в структурировании материалов и оформлении списка литературы в соответствии с требованиями вузов и ГОСТа.
• Поиск и анализ информации: сбор и анализ релевантных источников для обоснования аргументов и теоретической базы работы.

Почему выбирают Zaochnik

• Бесплатный пробный доступ: все инструменты ИИ Zaochnik GPT доступны пользователям бесплатно в пробной версии.
• Универсальность: подходит для оптимизации создания различных типов учебных работ, включая конспекты, рефераты, эссе, курсовые и дипломные проекты.
• Поддержка на всех этапах: помощь от исследования темы до финальной корректировки и оформления работы.

Слабые стороны

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

Сайт сервиса >>>

7. SmartBuddy

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

• Цена: доступ бесплатный, а платные опции и тарифы — через общий ИИ-чат SmartBuddy
• Бесплатный период: есть постоянный бесплатный доступ к нейросети для перевода, заявлено без ограничения по количеству символов
• Регистрация: не обязательна для базового использования переводчика; регистрация дает бонус и доступ к истории запросов и другим ИИ-сервисам

Способности нейросети:

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

Почему выбирают SmartBuddy:

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

Слабые стороны:

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

Сайт сервиса >>>

8. WordyBot

Это специализированная нейросеть для конспектов, которая сначала бесплатно генерирует подробный план, а затем по нему пишет полный текст. Сервис ориентирован на учебные и проектные работы: от конспекта лекции и реферата до курсовой, диплома, бизнес-плана и проектов, с возможностью задать тип работы и желаемый объем. Пользователь указывает тему, при желании добавляет свое содержание, после чего нейросеть формирует план и разворачивает его в конспект на 5–10 страниц с уже готовой структурой. Встроенный ИИ-редактор позволяет переписывать отдельные фрагменты, дополнять текст и в итоге скачать результат в формате Word.

• Цена: бесплатно генерируется план конспекта и содержание (оглавление), а подписка начинается примерно от 315 ₽ в месяц
• Бесплатный период: отдельного ограниченного «триала» нет: планы текстов и конспектов можно генерировать бесплатно и без ограничений, платными остаются только лимиты на развернутый текст и ИИ-редактор
• Регистрация: для базового шага (генерация плана конспекта) регистрация не обязательна

Способности нейросети:

• Генерирует план конспекта под конкретный тип работы (реферат, доклад, конспект, курсовая, проект и т.д.) с учетом предполагаемого объема.
• Пишет полноценный конспект на основе плана — обычно на 5–10 страниц, с логичной разбивкой на разделы и подпункты.
• Позволяет добавлять свое «сырье» (содержание, тезисы), чтобы ИИ учитывал их при подготовке плана и текста.
• Встроенный ИИ-редактор дает возможность переписывать фрагменты, расширять разделы и «доливать воды», а затем сохранить результат в Word.
• Удобно хранит проекты в личном кабинете, где к ним можно вернуться и доработать позже.

Почему выбирают WordyBot:

• Бесплатный и быстрый старт: план конспекта по теме — без регистрации и лимитов.
• Заточен под студенческие и учебные работы: есть готовые пресеты под курсовые, дипломы, рефераты, доклады и др.
• Удобный путь «от идеи до файла»: план → полный конспект → правки в ИИ-редакторе → скачивание в Word.
• Много положительных отзывов и высокая оценка на Яндекс — сервис активно используют именно для учебных текстов.

Слабые стороны:

• Полноценные конспекты (не только план) завязаны на систему лимитов: для регулярной генерации текстов понадобится покупка подписки или пакета.

Сайт сервиса >>>

9. ruGPT

Онлайн-сервис на русском языке с нейросетью для написания конспектов, рефератов, писем, статей и отчетов. Он умеет «вычленять» главное из длинного текста и оформлять его как аккуратный конспект, экономя ваше время на ручное чтение и выделение ключевых моментов. Сервис доступен прямо в браузере и не требует регистрации для тестового использования, что делает его простым в применении. ruGPT.io подходит и для студентов, которые готовят шпаргалки или конспекты лекций, и для специалистов, кто хочет быстро обобщить большие объемы текста.

• Цена: базовая версия ruGPT.io — бесплатная, а платные тарифы начинаются от 138 ₽ в месяц
• Бесплатный период: основные функции доступны без оплаты (нет отдельно выделенного «пробного» периода).
• Регистрация: не обязательна для тестового использования

Способности нейросети:

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

Почему выбирают ruGPT:

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

Слабые стороны:

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

Сайт сервиса >>>

10. GPTunnel

На этой площадке вы найдете популярные нейросети: ChatGPT, Gemini, Claude, а также AI-ассистентов для помощи с конспектами. Среди них, например, «Грамотей», подсвечивающий ошибки в вашем тексте, «Перефразировщик», подбирающий синонимы и варианты вербализации одной и той же мысли. Возможно бесплатное пользование, а также промокоды со скидками в Telegram.

• Цена: только по факту, в токенах
• Бесплатный период: есть
• Регистрация: нужна

Способности нейросети

• Доступ к 100+ популярным нейросетевым моделям.
• Инструменты для работы с текстом, изображениями, видео, музыкой, а также аналитикой и ПО.
• ИИ-агенты для узких задач.

Почему выбирают GPTunnel

• Плата только за использованные токены — ничего лишнего.
• Большой выбор нейросетей от ChatGPT до новой Grom.
• Бесплатные обучающие материалы по эффективной работе с ИИ.
• Доступ к API.

Слабые стороны

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

Сайт сервиса >>>

Еще 2 нейросети для конспекта текстов

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

1. Neurosets — многофункциональный онлайн-сервис на русском языке, который среди прочего предлагает нейросеть для создания конспектов по любому тексту: от статей и учебных материалов до заметок и рефератов. Система способна за считанные минуты преобразовать большой текст в сжатую, структурированную версию — с выделением ключевых мыслей и смысловых блоков. Благодаря этому Aitxt помогает экономить время, особенно при работе с объемной информацией и большими текстами.
2. AI TXT — сервис позволяет преобразовать любой текст в компактный, структурированный конспект буквально за минуты, экономя время на ручное вычленение ключевых идей. Он входит в набор из более чем 20 инструментов для работы с текстом — от генерации статей и эссе до рерайта, пересказа и вывода по тексту. Вставляете исходный материал, и нейросеть обрабатывает его, отбирая главное и выдавая удобный конспект на русском языке.

Как нейросеть пишет конспект?

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

Что делает нейросеть, когда пишет конспект:

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

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

Правильный промпт определяет 70–80% качества итогового конспекта. Нейросеть может создавать текст в разных форматах: короткий пересказ, тезисный конспект, лекционный план, структурированную выжимку, шпаргалку — но она должна понимать, что именно вы хотите получить. Чем точнее инструкция, тем более осмысленный, аккуратный и полезный конспект вы получаете на выходе.

Готовые промпты для качественного конспекта:

• Базовый конспект по тексту: «Сделай краткий и структурированный конспект по следующему тексту. Выдели ключевые идеи, основные понятия, аргументы и выводы. Убери второстепенную информацию.»
• Тезисный конспект: «Сформируй тезисный конспект из текста. Каждую ключевую мысль оформи отдельным пунктом. Передавай только суть без подробных описаний.»
• Конспект для экзамена: «Сделай конспект в формате подготовки к экзамену. Включи определения, основные тезисы, цепочки причин и следствий, ключевые даты/формулы (если есть). Напиши максимально ясно и кратко.»
• Мини-конспект (ультракороткая выжимка): «Сократи текст до мини-конспекта объемом 5–7 предложений. Включи только самое важное, что раскрывает суть материала.»
• Подробный обучающий конспект: «Сделай подробный обучающий конспект с пояснениями. Раскрой ключевые термины, поясни сложные моменты простым языком, добавь короткие примеры, если это уместно.»
• Конспект лекции / выступления: «Создай конспект лекции: выдели основные блоки, ключевые тезисы, аргументы и выводы. Отрази структуру выступления, даже если она неявная в тексте.»
• Структурированный план конспекта: «Сделай структурированный план по тексту: разделы, подпункты, тезисы. Сосредоточься на логике и последовательности изложения.»
• Шпаргалка: «Создай шпаргалку по тексту: минимальный объем, максимум сути. Используй списки, краткие определения и ключевые факты.»
• Конспект с акцентом на выводы: «Сделай конспект, выделив главные выводы автора. Сформулируй их кратко и четко. Отдельно перечисли аргументы, которыми автор их обосновывает.»
• Сравнительный конспект (если несколько источников): «Сравни два текста и сделай конспект, выделив сходства, различия и ключевые идеи каждого автора.»
• Конспект в стиле учебника: «Перепиши текст в формате учебного конспекта: четкие блоки, подзаголовки, определение — объяснение — пример, краткий вывод в конце.»
• Академический конспект: «Сделай академический конспект с сохранением терминологии. Структурируй материал, но не упрощай терминов и определений.»
• Конспект по теме (если текста еще нет): «Составь конспект по теме __________. Включи основные понятия, ключевые идеи, объяснения, примеры и выводы. Оформи в виде структурированных блоков.»
• Конспект для презентации: «Сделай конспект в виде коротких тезисов, которые можно переносить в презентацию: 5–7 ключевых блоков по теме, каждый — до 2 предложений.»
• Конспект с вопросами для самопроверки: «Сделай конспект текста и добавь в конце 5–7 вопросов для самопроверки по содержанию.»

Как усилить любой промпт

Эти фразы можно добавить к любому запросу — и качество конспекта заметно вырастет:

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

Преимущества и недостатки конспекта, написанного ИИ

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

Преимущества

• Экономия времени: Нейросеть обрабатывает длинные тексты за секунды, сокращая часы работы до нескольких минут — особенно полезно при подготовке к экзаменам или анализе больших документов.
• Четкая структурированность: Многие модели формируют логичную структуру: разделы, пункты, списки. Такой формат часто проще и удобнее, чем конспект, написанный вручную «по ходу».
• Умение «вытащить» главное из больших объемов: ИИ последовательно выделяет ключевые идеи, основные тезисы, аргументы и выводы — без эмоциональных отвлечений и лишних деталей.
• Объективность и отсутствие субъективных искажений: Нейросеть не пропускает важную часть текста «по невнимательности» и не интерпретирует информацию через личный опыт или знания.
• Подходит для разных уровней и форматов: Можно запросить короткий конспект, подробную выжимку, учебный план, тезисы для презентации или шпаргалку — ИИ адаптируется под задачу.
• Легкое переписывание под нужный стиль: Конспект можно мгновенно переформатировать: сделать его проще, академичнее, короче или длиннее.
• Полезен при работе с незнакомыми темами: ИИ помогает быстро понять общую логику и основные идеи текста, даже если тема сложная или новая.
• Работает без усталости и ошибок внимания: В отличие от человека, нейросеть не отвлекается, не устает и не теряет ключевые фрагменты текста.

Недостатки

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

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

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

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

ТОП-10 нейросетей для инфографики в 2026 году

1. Neiro-card.ai – сервис помогает продавцам и маркетологам быстро создавать визуально привлекательные карточки товаров.
2. Study AI — агрегатор всех популярных нейросетей с умным поиском, который подбирает идеальный ИИ под любую задачу обучения или работы.
3. ChatGPT — продвинутая нейросеть для общения с ИИ, генерации текстов и анализа данных на русском языке.
4. Midjourney — мощный ИИ-генератор изображений по текстовым описаниям, создающий художественные и детализированные картинки.
5. GPTunneL — универсальный агрегатор ИИ для генерации текста, изображений, видео и аудио в одном интерфейсе для бизнеса.
6. Apihost — простой российский сервис text-to-image генерации, превращающий текстовые описания в качественные изображения без сложных настроек.
7. GoGPT — сервис с доступом к топовым языковым моделям вроде GPT-5 и Claude с русским интерфейсом и оплатой в рублях для повседневных задач.
8. MashaGPT — ИИ-чат-бот, основанный на GPT, который предоставляет помощь в генерации текста, инфографики и решении разных задач.
9. ruGPT — платформа с фокусом на генерацию инфографики через нейросети, оптимизированная для русскоязычных промптов.
10. Chad AI — ИИ-сервис для общения и генерации контента, который помогает решать широкий спектр задач с использованием искусственного интеллекта.

1. Neiro-card.ai

Это ИИ-сервис для создания карточек товаров и визуального контента для маркетплейсов. Neiro Card AI помогает быстро оформлять изображения для Wildberries, Ozon и Яндекс Маркета: удалять фон, добавлять инфографику, использовать готовые макеты и генерировать фоновые изображения с помощью нейросети. Сервис подходит селлерам, маркетологам и владельцам интернет-магазинов, которым нужно быстро подготовить профессиональные карточки товаров без навыков дизайна и без постоянного обращения к дизайнеру.

• Стоимость: есть бесплатный тариф, основной тариф — от 1 490 ₽ в месяц
• Регистрация: через страницу входа в личный кабинет
• Бесплатное использование: доступен бесплатный тариф для первого знакомства с продуктом

Преимущества:

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

Недостатки:

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

Ознакомиться с сервисом >>>

2. Study AI

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

• Стоимость: 30 руб. за изображение
• Регистрация: через email или соцсети
• Бесплатное использование: 16 генераций изображений + ограниченный доступ к базовым моделям для тестирования, без водяных знаков

Преимущества:

• Умный поиск подбирает нейросеть для создания инфографики.
• Полный русский интерфейс и поддержка промптов на русском.
• Доступ ко всем популярным ИИ (GPT-5, Midjourney).
• Быстрая генерация визуализаций для учебы, маркетинга, отчетов.

Недостатки:

• Ограничения бесплатного доступа.

Ознакомиться с сервисом >>>

3. ChatGPT

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

• Стоимость: оплата за сообщения
• Регистрация: требуется учетная запись
• Бесплатное использование: тестовые сообщения доступны после регистрации

Преимущества:

• Полная поддержка русского языка без потери качества.
• Глубокое понимание контекста для сложных многошаговых запросов.
• Подходит для текстового контента к инфографике (заголовки, описания данных).

Недостатки:

• Нет безлимитного тарифа для интенсивной работы.

Ознакомиться с сервисом >>>

4. Midjourney

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

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

• Стоимость: 30 токенов за создание одной картинки (через сайт-агрегатор)
• Регистрация: требуется учетная запись
• Бесплатное использование: пробные генерации доступны для тестирования качества, основной функционал платный

Преимущества:

• Нейросеть для генерации инфографики.
• Профессиональное художественное качество для инфографики.
• Быстрая работа (секунды на картинку) и гибкие настройки стиля.
• Полная коммерческая лицензия на изображения.

Недостатки:

• Платно за каждую генерацию.

Ознакомиться с сервисом >>>

5. GPTunneL

Агрегатор десятков ИИ-моделей в едином интерфейсе, где GPT-5.1 генерирует структурированные тексты, описания данных и аналитику для инфографики. Платформа объединяет текст, изображения, видео и чарты — идеально для создания полной инфографики из сырых данных за один сеанс работы. Поддерживает режимы Instant (быстрые ответы), Thinking (глубокий анализ) и Codex (код/визуализация), превращая таблицы в готовые визуальные истории с пояснениями.

• Стоимость: оплата за реальные токены без обязательной подписки, цены зависят от модели
• Регистрация: через email или Telegram
• Бесплатное использование: новые пользователи часто получают базовый доступ или тестовые возможности

Преимущества:

• Доступ через единую платформу с множеством других ИИ‑инструментов (изображения, видео, аудио).
• Нет обязательных подписок — оплата только за использованные запросы.
• ИИ для создания инфографики: анализирует данные и предлагает оптимальные чарты.

Недостатки:

• Стоимость варьируется по моделям.

Ознакомиться с сервисом >>>

6. Apihost

Российский ИИ для генерации инфографики по текстовым описаниям: уникальных иконок, иллюстраций и фоновых элементов инфографики. Нейросеть поддерживает инпейнтинг (дорисовку деталей), замену фона и апскейлинг качества ×4, что позволяет быстро создавать профессиональные визуалы без Photoshop. Интерфейс достаточно прост — вы вводите текстовое описание, выбираете параметры и получаете визуальные результаты за полминуты‑две.

• Стоимость: оплата за генерацию
• Регистрация: через email или соцсети
• Бесплатное использование: тестовые генерации для оценки качества, основной функционал платный

Преимущества:

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

Недостатки:

• Платная модель без бесплатного безлимита.

Ознакомиться с сервисом >>>

7. GoGPT

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

• Стоимость: бесплатный тариф с 10 запросами в день, после чего для расширенной работы с нейросетями могут потребоваться платные запросы или подписка
• Регистрация: требуется
• Бесплатное использование: в бесплатном режиме доступны ограниченные запросы в день

Преимущества:

• Внутри много ИИ для создания инфографики бесплатно.
• Ideogram генерирует текст внутри изображений без ошибок.
• Рубли, русский интерфейс и готовые промпты для инфографики.
• Загрузка файлов для автоматического анализа данных.

Недостатки:

• Для интенсивной работы требуется платный доступ.

Ознакомиться с сервисом >>>

8. MashaGPT

Русскоязычный онлайн‑инструмент, который предоставляет доступ к мощной нейросети ChatGPT‑5 прямо в браузере и помогает генерировать тексты, идеи и пояснения для инфографики. Сервис понимает запросы на русском и способен преобразовывать сухие данные в связные описания, заголовки и объясняющие блоки, которые удобно использовать при создании визуальных материалов.

• Стоимость: подписка от 990 рублей
• Регистрация: через браузер/Telegram
• Бесплатное использование: ежедневный лимит бесплатных сообщений

Преимущества:

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

Недостатки:

• Расширенные возможности и доступ к более мощным моделям могут требовать оплаты.

Ознакомиться с сервисом >>>

9. ruGPT

Бесплатный ИИ для инфографики на базе DALL-E и Flux, идеальный для создания иконок, иллюстраций и фонов инфографики по простым русскоязычным описаниям без регистрации. Кроме создания изображений, ruGPT также объединяет другие ИИ‑инструменты для текста, голосовых задач и визуального контента, что делает его универсальным помощником в работе с инфографикой.

• Стоимость: подписка от 165 рублей
• Регистрация: для базовой генерации изображений регистрация не требуется
• Бесплатное использование: предусмотрено

Преимущества:

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

Недостатки:

• Бесплатные лимиты могут быть ограничены, особенно при интенсивной генерации.

Ознакомиться с сервисом >>>

10. Chad AI

Российская платформа, объединяющая мощные нейросети для генерации текстов, изображений и другого ИИ‑контента в одном месте, что делает ее удобной для создания визуальных материалов и инфографики. Сервис позволяет писать тексты любой сложности, анализировать данные, генерировать идеи и превращать текстовые описания в картинки при помощи встроенных моделей вроде Midjourney, Stable Diffusion и DALL·E.

• Стоимость: от 290 рублей в месяц
• Регистрация: требуется регистрация учетной записи на сайте
• Бесплатное использование: предоставляет бесплатный доступ с ограниченными возможностями

Преимущества:

• 50+ ИИ для полного цикла инфографики​.
• Мобильные приложения + Telegram-бот для работы на ходу.
• Библиотека промптов и память чата для сложных проектов.

Недостатки:

• Полностью бесплатного безлимита нет.

Ознакомиться с сервисом >>>

Еще 12 нейросетей для инфографики

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

1. RoboGPT — российский генератор SEO-контента и изображений с 50+ шаблонами для инфографики, создающий тексты с данными и кастомные визуалы для сайтов и соцсетей.
2. GenAPI — API-агрегатор 100+ нейросетей с функциями для инфографики: удаление фона, outpainting, ретушь и генерация фото товаров одним запросом.
3. ChatGPT Tools — универсальный чат-бот с ИИ на русском для генерации текстовых описаний данных, анализа таблиц и создания контента под инфографику.
4. AiWriteArt — простой генератор текстов и изображений для инфографики с акцентом на бизнес-контент, соцсети и интернет-магазины с бесплатной пробной версией.
5. Кэмп — специализированная нейросеть для автоматического создания графиков и диаграмм из текстовых описаний и данных.
6. Deepseek — китайская математическая нейросеть, сильная в анализе данных и построении точных графиков/диаграмм для научной и бизнес-инфографики.
7. Perplexity — ИИ-поисковик с цитатами источников, собирающий актуальные данные и статистику для создания достоверных инфографик с проверенными цифрами.
8. DALL-E — генератор изображений от OpenAI для стильных иконок, иллюстраций и креативных элементов инфографики с детализацией.
9. Gemini — мультимодальная нейросеть Google для анализа изображений/таблиц и генерации визуальных концепций инфографики с веб-поиском.
10. Nano Banana — продвинутый генератор изображений для профессиональной инфографики с поддержкой сложных композиций и фирменных стилей брендов.
11. Claude — AI для глубокого анализа данных и создания структурированных текстовых макетов инфографики с высокой логичностью.
12. Grok — ИИ с саркастичным стилем для креативных инфографик, генерации мемов с данными и нестандартных визуальных концепций.

Как нейросети меняют инфографику?

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

1. Автоматизация процесса создания инфографики

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

2. Подбор индивидуальных стилей и форматов

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

3. Обработка и визуализация больших данных

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

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

4. Генерация изображений и иконок

Кроме обработки данных, нейросети также способны создавать уникальные изображения, иконки и иллюстрации, которые могут быть использованы в инфографике. С помощью таких инструментов, как MidJourney или DALL·E, можно генерировать изображения, которые соответствуют конкретному описанию, например, иллюстрации для сложных концептов или стилизованные картины для визуальных проектов.

5. Интерактивность и динамичность

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

6. Оптимизация контента для разных платформ

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

Как работает нейросеть для инфографики?

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

Рассмотрим, как именно работает нейросеть для инфографики, шаг за шагом.

1. Обработка исходных данных

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

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

2. Анализ и выбор структуры визуализации

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

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

3. Выбор стиля и оформление

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

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

4. Генерация графических элементов

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

5. Текстовые пояснения и описания

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

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

6. Реализация динамических и интерактивных элементов

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

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

7. Обратная связь и улучшения

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

Разница между традиционными методами создания инфографики и использованием ИИ

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

1. Время создания

Традиционные методы требуют 4–8 часов на создание инфографики, включая анализ данных, дизайн и правки. В то время как использование нейросетей позволяет получить готовый результат всего за 2–5 минут.

2. Необходимые навыки

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

3. Стоимость

Создание инфографики традиционными методами включает затраты на работу дизайнера (от 3 000 до 15 000₽) или подписку на программы (от 2 000₽/мес). Для нейросетей стоимость может варьироваться от 0₽ (например, ruGPT) до 290₽/мес (например, ChadGPT).

4. Гибкость итераций

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

5. Анализ данных

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

6. Персонализация

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

7. Качество визуалов

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

8. Масштабируемость

Традиционные методы позволяют создавать только одну инфографику за раз, тогда как нейросети могут генерировать целые пакеты с 100+ вариантами инфографики.

9. Доступ к трендам

Традиционные методы используют устаревшие шаблоны, которые могут быть актуальными на момент их создания, но быстро теряют популярность. Нейросети предоставляют доступ к актуальным трендам 2026 года, таким как неон, 3D и glassmorphism.

10. Коммерческое использование

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

Преимущества ИИ в процессе создания визуальных материалов

Использование ИИ в создании визуальных материалов предоставляет множество преимуществ:

1. Ускорение процесса создания: ИИ значительно сокращает время на создание визуальных материалов. Вместо того чтобы вручную создавать графики, иллюстрации и текстовые блоки, ИИ автоматически генерирует готовые элементы за несколько минут.
2. Доступность для пользователей без дизайнерского опыта: ИИ-инструменты позволяют создавать качественную инфографику даже тем, кто не имеет навыков в графическом дизайне. Простота интерфейса и готовые шаблоны делают процесс доступным для широкого круга пользователей.
3. Автоматический выбор оптимальных форматов: ИИ анализирует данные и автоматически выбирает наиболее подходящий формат для визуализации, будь то график, диаграмма или карта. Это избавляет от необходимости вручную решать, какой тип графика использовать для определенных данных.
4. Персонализация и адаптация под требования: современные ИИ-сервисы могут настроить стиль и оформление инфографики в зависимости от ваших предпочтений или корпоративных стандартов, что позволяет получить уникальные визуальные материалы, соответствующие нуждам бизнеса.
5. Снижение затрат: использование ИИ для создания визуальных материалов значительно снижает расходы. Это исключает необходимость в найме дизайнеров или использовании дорогостоящих программ для графики, так как многие сервисы предлагают доступные или бесплатные тарифы.
6. Обработка больших объемов данных: ИИ может быстро и точно обрабатывать большие объемы данных, превращая их в понятные и наглядные визуализации. Это особенно полезно для аналитиков, маркетологов и других профессионалов, которым нужно представить сложные данные в легко воспринимаемом виде.
7. Обновление и поддержка актуальности материалов: ИИ может автоматически обновлять инфографику в реальном времени, что особенно важно для бизнес-отчетов, финансовых данных или маркетинговых материалов, которые требуют регулярных обновлений.
8. Высокое качество и точность визуализаций: ИИ создает инфографику, которая точно отражает данные и делает их наглядными. Это позволяет избежать ошибок, которые могут быть допущены при ручной обработке или визуализации данных.
9. Интерактивность и динамичные элементы: ИИ-сервисы могут создавать интерактивные инфографики, которые позволяют пользователю взаимодействовать с данными, фильтровать информацию и обновлять данные в реальном времени, что делает визуализацию более эффективной и увлекательной.

Применение ИИ в различных типах инфографики

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

1. Статистическая инфографика: ИИ помогает быстро обрабатывать большие массивы данных и создавать понятные графики, диаграммы и таблицы, которые наглядно показывают ключевые статистические показатели. Например, ИИ может автоматически выбрать лучший тип диаграммы (столбчатую, линейную, круговую) в зависимости от типа данных.
2. Тематические карты: ИИ может обрабатывать географические данные и создавать карты, которые визуализируют информацию по географическим регионам, таким как распределение населения, экономические показатели или экологические данные. Нейросети могут интегрировать данные с картами и автоматически генерировать карты, соответствующие запросу.
3. Процессные схемы и блок-схемы: в процессе создания процессных диаграмм ИИ может автоматически разрабатывать схематичное отображение цепочки действий или взаимодействий, например, создание блок-схем для бизнес-процессов или алгоритмов. ИИ помогает определить логическую последовательность и оптимально распределить элементы на диаграмме.
4. Интерактивная инфографика: ИИ может создавать интерактивные визуализации, где пользователи могут фильтровать данные, выбирать различные параметры и получать новые представления информации. Это особенно полезно для маркетинговых отчетов или научных исследований, где нужно обновлять информацию в реальном времени.
5. Инфографика для социальных сетей: ИИ помогает создавать яркие и привлекательные визуальные материалы, которые соответствуют требованиям платформ социальных сетей. Искусственный интеллект автоматически подбирает шрифты, цвета и стили в зависимости от аудитории и трендов, что упрощает создание графики для продвижения в интернете.
6. Образовательная инфографика: в образовательных материалах ИИ может использоваться для создания инфографики, которая помогает объяснять сложные концепты простыми и доступными средствами. Например, ИИ может генерировать схематичные диаграммы для иллюстрации биологических процессов, исторических событий или математических алгоритмов.
7. Финансовая инфографика: ИИ используется для создания визуализаций, отображающих финансовые данные, такие как отчеты о прибыли, инвестиционные прогнозы или изменения на фондовых рынках. Нейросети могут автоматически анализировать финансовые показатели и генерировать диаграммы, которые помогают проще понять текущие тенденции и прогнозы.
8. Данные с использованием времени (time-series data): ИИ отлично справляется с анализом данных, которые зависят от времени. Такие инфографики часто включают графики, показывающие динамику изменения различных показателей за определенный период. Например, ИИ может автоматически строить графики с показателями, такими как температура, продажи или трафик на сайте, за любые временные интервалы.
9. Брендированная инфографика: для бизнесов и компаний ИИ может создавать инфографику, которая соответствует фирменному стилю, автоматически подбирая шрифты, цвета и элементы дизайна, соответствующие корпоративным стандартам. Это значительно ускоряет процесс подготовки материалов для маркетинговых материалов и презентаций.

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

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

Я разберу лучшие платформы для создания 3D-моделей с помощью ИИ: от бесплатных пробных версий с API-интеграцией до профессиональных инструментов для геймдева и VR — с ценами, плюсами и минусами.

ТОП-10 нейросетей для создания 3Д-моделей в 2026 году

1. Nano Banana — помогает быстро получить визуал с убедительной иллюзией объема, чтобы проверить форму, материал и подачу будущего 3D-объекта.
2. Study AI — визуальная мастерская в одном кабинете: Midjourney, Nano Banana 2 и GPT Image помогают быстро собрать стильный референс, проверить форму будущего 3D-объекта и показать идею без долгой настройки.
3. Midjourney — раскрывает художественную сторону 3D-концепта: свет, стиль, настроение сцены и выразительную форму объекта.
4. ggsel — магазин цифровых товаров, где можно найти доступ к Luma AI и другим AI-инструментам для 3D-визуала, видео и сцен, часто по более низкой цене.
5. DALL-E — помогает быстро собрать понятный эскиз будущего 3D-ассета по обычному описанию и затем уточнять детали через диалог.
6. Stable Diffusion — подходит тем, кому нужен гибкий пайплайн: от генерации референсов и текстур до связки со Stable Fast 3D или SPAR3D для создания ассетов.
7. Hunyuan — нейросеть от Tencent генерирует 3D-модели через создание множественных согласованных ракурсов объекта по одному изображению или текстовому описанию.
8. Rodin — ИИ-сервис для создания высокодетализированных 3D-скульптур и реалистичных персонажей с точной геометрией и текстурами на основе текстовых промптов.
9. Trellis — платформа для быстрого преобразования 2D-изображений в 3D-модели с оптимизированной топологией, подходящая для игровой индустрии и интерактивных проектов.
10. Meshcapade — сервис для создания анатомически точных 3D-аватаров и цифровых двойников людей с возможностью настройки параметров фигуры и анимации движений.

1. Nano Banana

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

• Стоимость: зависит от платформы, через которую используется модель
• Бесплатный тариф: доступен с ограничениями в Gemini и некоторых сторонних сервисах
• Регистрация: требуется аккаунт в выбранном сервисе

Преимущества:

• Создает выразительные изображения с сильной иллюзией объема, фактуры и студийного света.
• Хорошо подходит для концептов 3D-фигурок, игрушек, персонажей, продуктовых макетов и предметных рендеров.
• Позволяет быстро проверить визуальную идею до полноценного моделирования.
• Поддерживает редактирование изображений: можно менять стиль, ракурс, фон, освещение и отдельные детали сцены.

Недостатки:

• Не создает полноценные 3D-модели с геометрией, сеткой, UV-разверткой и экспортом в OBJ, FBX или GLB.
• Результат нельзя свободно вращать и рассматривать со всех сторон, как полноценный ассет.

Перейти на сайт >>>

2. Study AI

Этот агрегатор подойдет тем, кто хочет создавать визуальные референсы для будущих 3D-моделей без переключения между разными платформами. Внутри есть Midjourney, Nano Banana 2 и GPT Image 2 — их можно использовать для генерации предметных концептов, иллюзии объема, вариантов освещения, материалов, упаковки, персонажей и сцен.

• Стоимость: от 199 руб./нед.
• Бесплатный тариф: есть пробный доступ с ограничениями
• Регистрация: email

Преимущества:

• В одном сервисе доступны Midjourney, Nano Banana 2, GPT Image 2 и другие нейросети для изображений.
• GPT Image 2 подходит для быстрых набросков по детальному описанию.
• Есть языковые модели, которым можно поручить разработать концепцию и промпты.

Недостатки:

• Результаты остаются изображениями, а не готовыми 3D-ассетами.

Перейти на сайт >>>

3. Midjourney

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

• Стоимость: от $10/мес. за Basic Plan
• Бесплатный тариф: не предусмотрен
• Регистрация: через официальный аккаунт

Преимущества:

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

Недостатки:

• Не выдает полноценные 3D-файлы для Blender, Unity, Unreal Engine или 3D-печати.
• При создании серии ракурсов детали объекта могут отличаться.

Перейти на сайт >>>

4. ggsel

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

• Стоимость: зависит от выбранного товара и продавца
• Бесплатный тариф: не предоставляется маркетплейсом; условия зависят от конкретного сервиса
• Регистрация: Яндекс ID или email

Преимущества:

• Маркетплейс помогает сравнить несколько продавцов перед покупкой.
• Подходит тем, кто ищет доступ к AI-инструментам для 3D-визуала, видео и креативных сцен.
• Есть варианты с разными сроками доступа, поэтому проще подобрать формат под разовую задачу или проект.

Недостатки:

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

Перейти на сайт >>>

5. DALL-E

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

• Стоимость: зависит от выбранного способа доступа
• Бесплатный тариф: зависит от платформы, через которую используется генератор
• Регистрация: через аккаунт OpenAI или сервис, где подключены модели

Преимущества:

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

Недостатки:

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

Перейти на сайт >>>

6. Stable Diffusion

Это гибкая экосистема для генерации и доработки визуальных материалов. Stable Diffusion используют для концептов, текстур, фонов, предметных рендеров и стилизованных сцен, а при правильной настройке модель можно адаптировать под фирменный стиль, персонажей или конкретный тип объектов. В базовом режиме Stable Diffusion генерирует изображения, а для 3D у Stability AI есть отдельные решения вроде Stable Fast 3D и SPAR3D. Такая связка помогает сначала подготовить референс, а затем превратить его в ассет и доработать в 3D-пайплайне.

• Стоимость: зависит от способа использования — API, веб-платформа, облачный сервис или локальный запуск
• Бесплатный тариф: доступ зависит от выбранной реализации и лицензии
• Регистрация: не требуется

Преимущества:

• Подходит для концептов, текстур, фонов и предметных визуализаций.
• Поддерживает инструменты редактирования: inpaint, outpaint, замену фона и доработку отдельных зон.
• Может использоваться в связке с 3D-решениями Stability AI.

Недостатки:

• В базовом виде создает изображения, а не готовые 3D-модели.
• Для реальных ассетов нужны отдельные инструменты вроде Stable Fast 3D или SPAR3D.

Перейти на сайт >>>

7. Hunyuan

Китайская нейросеть от корпорации Tencent, которая делает 3D-модели. Система сначала генерирует серию согласованных изображений объекта с различных ракурсов на основе текстового описания или входного изображения, а затем реконструирует из них полноценную трехмерную модель с геометрией и текстурами. Это минимизирует характерные артефакты и пустоты, которые часто возникают при прямом преобразовании 2D в 3D. Модель особенно эффективна для создания персонажей, предметов интерьера и игровых ассетов, где важна детализация и согласованность деталей со всех сторон.

• Стоимость: оплата за каждую генерацию
• Бесплатный тариф: не предоставляется
• Регистрация: требуется регистрация на платформе с получением API-ключа и пополнением баланса

Преимущества:

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

Недостатки:

• Отсутствие бесплатного тарифа или пробного периода затрудняет первоначальное тестирование возможностей сервиса.

Перейти на сайт >>>

8. Rodin

ИИ для генерации 3D‑моделей, способная преобразовывать как изображения, так и текстовые описания в трехмерные объекты, что делает ее удобной для дизайнеров, геймдева и визуализаторов. С помощью Rodin можно создавать 3D‑модели из одной или нескольких фотографий объекта с разных ракурсов, а также генерировать модели полностью по текстовому описанию без необходимости загружать изображения. Система ориентирована на быструю работу и получение визуально аккуратных моделей, которые подойдут для прототипирования, концепт‑арта, AR/VR и игрового контента, хотя не всегда обеспечивает сверхвысокую детализацию.

• Стоимость: оплата за каждую генерацию
• Бесплатный тариф: не предоставляется
• Регистрация: требуется регистрация на платформе с получением API-ключа и пополнением баланса

Преимущества:

• Высокое качество геометрии с проработкой мелких деталей и рельефа.
• Автоматическое создание качественных текстур с правильным распределением материалов и согласованностью с геометрией объекта.
• Генерация моделей с оптимизированной топологией и готовыми UV-развертками, упрощающими дальнейшее редактирование, риггинг и анимацию.
• Универсальность входных данных — поддержка создания моделей как по текстовым промптам, так и на основе изображений.
• API-интеграция позволяет встраивать генерацию в существующие конвейеры производства контента и автоматизировать массовое создание ассетов.

Недостатки:

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

Перейти на сайт >>>

9. Trellis

Нейросеть для создания 3Д-моделей по фото, которая позволяет быстро преобразовывать 2D‑изображения в трехмерные модели с реалистичной геометрией и текстурой. Модель использует продвинутые техники искусственного интеллекта и структурированное латентное пространство (SLAT) для создания высококачественных 3D‑ассетов, подходящих для дизайна, игр и визуализации. Trellis поддерживает различные форматы 3D‑вывода и дает возможность предварительного просмотра и базового редактирования прямо в интерфейсе.

• Стоимость: оплата за каждую генерацию
• Бесплатный тариф: не предоставляется
• Регистрация: требуется регистрация на платформе с получением API-ключа и пополнением баланса

Преимущества:

• Высокая скорость генерации позволяет получать готовые 3D-модели за считанные секунд.
• Оптимизированная топология с правильным распределением полигонов делает модели сразу пригодными для использования в игровых движках без дополнительной ретопологии.
• Генерация стандартных форматов файлов (GLB) обеспечивает совместимость с большинством популярных 3D-редакторов и игровых платформ.
• API-интерфейс позволяет автоматизировать массовое создание контента и встраивать генерацию в существующие производственные конвейеры.

Недостатки:

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

Перейти на сайт >>>

10. Meshcapade

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

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

Meshcapade полезный инструмент для разработчиков игр, дизайнеров одежды, анимационных студий и компаний, работающих с AR/VR, где требуется точная цифровая копия человека.

• Стоимость: от €10/мес.
• Бесплатный тариф: предоставляется
• Регистрация: требуется регистрация на официальном сайте через email с подтверждением адреса

Преимущества:

• ИИ, делающая 3D-модели со специализацией на симуляцию одежды с реалистичной драпировкой и деформацией на различных типах фигур.
• Наличие бесплатного тарифа для ознакомления с технологией и тестирования в некоммерческих проектах.
• Универсальность входных данных — возможность создания точных цифровых двойников из простых 2D-фотографий, измерений тела или 3D-сканов.
• Широкая совместимость форматов экспорта (FBX, GLB, OBJ, BVH) и интеграция с популярными игровыми движками (Unity, Unreal Engine) и программами анимации (Mixamo, Blender).

Недостатки:

• Узкая специализация исключительно на человеческих персонажах.

Перейти на сайт >>>

Как искусственный интеллект преобразует текст и изображения в 3D-модели

В основе ИИ для создания 3D-моделей лежат продвинутые архитектуры глубокого обучения — диффузионные модели, трансформеры и нейронные радиационные поля (NeRF), которые работают не с привычными нам полигонами, а с математическими представлениями объектов в виде полей плотности, облаков точек или вокселей. ИИ не лепит модель как скульптор, а вычисляет ее вероятностное распределение в трехмерном пространстве, постепенно уточняя форму через тысячи итераций. Финальный этап включает преобразование этих абстрактных математических структур в привычные полигональные меши с текстурами, UV-развертками и PBR-материалами, готовые для использования в игровых движках, 3D-редакторах или системах визуализации.

Из слов в объем: текст в 3D

Процесс создания 3D-модели из текстового описания напоминает работу скульптора, который никогда не видел объект, но получает его детальное описание и постепенно воплощает образ в материале. Современные системы Text-to-3D используют комбинацию языковых моделей (часто на базе CLIP) и генеративных 3D-сетей, которые работают в тесной связке для создания визуально согласованных результатов.

Ключевые этапы текстовой генерации включают следующие процессы:

• Семантический анализ промпта — языковая модель разбирает текстовое описание на отдельные концепции, определяя тип объекта, его форму, материалы, цвета, стиль и дополнительные детали, создавая внутреннее векторное представление запроса в многомерном пространстве признаков.
• Генерация начального шума — система создает случайное распределение в трехмерном пространстве, которое служит отправной точкой для итеративного процесса уточнения формы объекта.
• Итеративная оптимизация через визуальную обратную связь — нейросеть виртуально фотографирует создаваемый объект с разных ракурсов и проверяет соответствие полученных изображений текстовому описанию, используя модель CLIP как внутреннего критика.
• Построение объемного представления — система постепенно формирует трехмерную структуру, используя технологии вроде signed distance functions (SDF), NeRF или вокселей, которые математически описывают форму и плотность материала в каждой точке пространства.
• Создание геометрии и текстур — объемное представление конвертируется в полигональный меш через алгоритмы вроде Marching Cubes, одновременно генерируются текстуры и PBR-карты (Albedo, Normal, Roughness, Metallic) для реалистичного взаимодействия со светом.
• Финальная оптимизация — модель проходит последнюю стадию обработки для создания чистой топологии, UV-разверток и экспорта в стандартные форматы (GLB, FBX, OBJ, USDZ).

Из плоского в рельеф: фото в 3D

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

Технологический процесс реконструкции включает несколько критических этапов:

• Анализ визуальных признаков и геометрии — сверточные нейронные сети извлекают из входного изображения информацию о форме, освещении, тенях и перспективе, строя карту глубины для понимания пространственной структуры видимых элементов.
• Предсказание объема на основе полученных знаний — используя огромную базу примеров, ИИ представляет, как объект должен выглядеть с невидимых ракурсов (если это стул, у него обычно четыре ножки, даже если видны только две).
• Генерация согласованных мультиракурсных проекций — продвинутые системы создают серию изображений объекта с различных точек обзора, обеспечивая визуальную согласованность между видимыми и сгенерированными частями.
• Объемная реконструкция через NeRF или Gaussian Splatting — технологии создают плотное объемное представление, захватывающее не только геометрию, но и сложные световые эффекты, отражения и прозрачность материалов.
• Извлечение полигональной сетки — объемное представление конвертируется в традиционный полигональный меш с оптимизацией топологии для конкретных применений (игры, визуализация, 3D-печать).
• Проекция и синтез недостающих текстур — видимые текстуры с исходного изображения проецируются на созданную геометрию, а специализированные генеративные модели заполняют невидимые области, создавая визуально согласованные детали на основе контекста и семантического понимания объекта.

Революция генеративного 3D уже наступила, и те, кто освоит эти инструменты первыми, получат колоссальное преимущество в скорости разработки и творческих возможностях. Нейросети для создания 3D-моделей не заменят талантливых художников, но навсегда избавят их от большей части технической рутины. Встраивайте в свой пайплайн Hunyuan и Rodin, которые лепят детализированные модели из пары фото, а также Meshy и Tripo3D, превращающие текст в готовые игровые ассеты за минуты, — так вы будете не догонять прогресс, а управлять им.

Что вы думаете об этих нейросетях для 3D — уже пробовали их в своих проектах?

Поделитесь в комментариях, какой сервис дал лучший результат для геймдева, VR или прототипов, и какие промпты сработали на ура!