Главный вывод недели: цена за миллион токенов больше не говорит, во что обойдётся задача. 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

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

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

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

Главный потребитель памяти видеокарты — это кеш ключей и значений: для типовой конфигурации выходит около 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%. Живая пробная отправка ни того, ни другого не покажет: она расскажет о поведении конкретной ручки прямо сейчас, но не о сумме по всей пачке, и вдобавок сама потратит токены.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для разработчика новость сводится к трём вещам. Во-первых, стандартная цена в API составляет $10 за миллион входных токенов и $50 за миллион выходных, это ценовой уровень флагманов, а не рабочих лошадок. Во-вторых, по заявлениям OpenAI модель заметно сильнее GPT-5.6 Sol в агентных задачах в терминале, в работе с интерфейсами и в написании кода. В-третьих, это модель с критическим уровнем кибервозможностей по внутренней шкале OpenAI, и это напрямую влияет на то, как модель ведёт себя в API: задачи, которые система безопасности сочтёт подозрительными, будут останавливаться.

• Доступ: ограниченный круг организаций сегодня, подписчики Plus, Pro, Business и Enterprise, API и Amazon Bedrock в ближайшие дни; Enterprise-администраторы включают модель вручную, по умолчанию она выключена.
• Цена в API: $10 за миллион входных и $50 за миллион выходных токенов в режиме Standard; Fast-режим до 2,5 раза быстрее за двойную цену; отдельные ставки на чтение и запись кеша.
• Бенчмарки OpenAI: Terminal-Bench 4.0 57,7% против 55,8% у Claude Fable 5.1 и 37,3% у GPT-5.6 Sol; FrontierMath Tier 4 97,6%; ARC-AGI-3 99,9%; ExploitBench 100%.
• Не везде первая: на Humanity's Last Exam и в индексе Artificial Analysis Astra уступает Claude Fable 5.1 и Opus 5.
• Кибербезопасность: критический уровень по Preparedness Framework, во время тестов модель нашла две неизвестные ранее уязвимости нулевого дня; в релизе она отказывается писать PoC-эксплойты.
• Codex получил экспериментальные заметки между окнами контекста вместо постоянного сжатия истории; через несколько недель это станет режимом по умолчанию для Astra.

Что OpenAI показывает на бенчмарках и где оговорки

Главная заявка OpenAI касается работы с компьютером и кода. На Terminal-Bench 4.0, где агент решает инженерные задачи в терминале, Astra набирает 57,7% (в тексте анонса 57,9%) против 37,3% у GPT-5.6 Sol и 55,8% у Claude Fable 5.1. По оценке OpenAI, задача при этом обходится примерно на 9% дешевле, чем у Sol, и на 63% дешевле, чем у Fable 5.1. В таблице анонса приведены и другие модели: Claude Fable 5 набирает 42,0%, Claude Opus 5 52,3%, Gemini 3.8 Flash 19,1%.

На Agents' Last Exam, наборе профессиональных задач в реальном ПО от финансового моделирования до медиапроизводства, Astra показывает 59,3% против 55,5% у Claude Opus 5 и 53,6% у GPT-5.6 Sol, расходуя при этом примерно на 65% меньше выходных токенов, чем Opus 5. На OSWorld 2.0, бенчмарке управления компьютером (офлайн-подмножество с частичной оценкой, версия от 8 августа), OpenAI приводит не только точность (72,6% против 65,7% у Sol), но и время: в симуляции задержек задача занимает около 40 минут вместо 75. Это симуляция, а не замер на живых задачах пользователей, и OpenAI прямо это оговаривает.

На AutomationBench и Terminal-Bench Science 0.1 отрыв особенно заметен: 41,4% против 31,4% у Fable 5.1 и 18,1% у Sol в первом случае, 64,6% против 52,6% и 22,4% во втором. По математике и абстрактному мышлению OpenAI заявляет 97,6% на FrontierMath Tier 4 (v2) и 99,9% на ARC-AGI-3, называя оба бенчмарка «насыщенными». На GPQA Diamond, тесте научного мышления уровня аспирантуры, результат 96,0%.

Есть и колонки, где Astra не первая, и OpenAI их не прячет. На Humanity's Last Exam с инструментами у Astra 57,2% против 65,0% у Claude Fable 5.1 и 63,6% у Opus 5. В индексе Artificial Analysis Intelligence Index v4.1.1 у Astra 61,2 балла против 65,7 у Fable 5.1 и 63,1 у Opus 5. На DeepSWE v1.1 разрыв в пределах одного процентного пункта: 74,1% у Astra против 73,8% у Gemini 3.8 Flash и 73,7% у Opus 5. Про Gemini 3.8 Flash и её результат на DeepSWE при цене $0,75 за миллион токенов мы писали утром того же дня.

Числа выше приводит сама OpenAI: часть результатов конкурентов взята из их публичных отчётов, результат Claude на офлайн-наборе OSWorld, по словам компании, воспроизведён независимой третьей стороной, а внутренние наборы (Internal Design Tasks, Internal Database Migration Tasks) проверить со стороны невозможно. Независимых замеров самой Astra на момент публикации нет.

Что меняется в Codex и как модель работает с контекстом

Вместе с Astra OpenAI обновляет и агентную оболочку Codex. Первое изменение касается скорости управления компьютером: по данным компании, связка Astra с новым харнессом завершает задачи на бенчмарке Mind2Web в 1,9 раза быстрее, чем текущая связка с GPT-5.6 Sol. Второе касается длинных сессий. Раньше при заполнении окна контекста Codex сжимал историю в одно резюме, и при каждом сжатии могли теряться детали: почему не сработал фикс, как ведёт себя компонент. Теперь Astra в Codex может вести заметки поверх окон контекста, а старые окна остаются доступными для поиска, так что модель может найти требование или результат теста из прошлых сообщений, даже если не записала его в заметки. Функция экспериментальная, включается в конфигурации Codex (config.toml) и в ближайшие недели станет режимом по умолчанию для Astra.

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

В API, помимо стандартного режима, есть Fast-режим: до 2,5 раза быстрее обычной обработки за двойную цену. На чтение и запись кеша действуют отдельные ставки. Для подходящих клиентов API поддерживается Zero Data Retention. Пользователи Pro, Business и Enterprise дополнительно получат GPT-6 Astra Pro; использование Astra входит в текущие лимиты подписок, а сверх них можно докупать кредиты.

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

В обновлении по безопасности 1 сентября OpenAI предупредила, что Astra достигнет критического уровня кибервозможностей по Preparedness Framework, внутренней шкале рисков компании, и что доступ к самым продвинутым кибервозможностям будет ограничен. Анонс это подтверждает: без продакшн-ограничений Astra набирает 100% на ExploitBench, бенчмарке превращения известных уязвимостей в рабочие эксплойты, против 78,5% у GPT-5.6 Sol, и 42,4% на ExploitGym против 30,3% у Sol.

Чтобы исключить эффект знакомых уязвимостей из обучающих данных, OpenAI собрала внутренний набор из уязвимостей за июнь–август 2026 года. На нём Astra показала 39,0% успешного выполнения произвольного кода против 5,5% у Sol, и по ходу теста нашла и использовала две ранее неизвестные уязвимости нулевого дня; компания говорит, что раскрывает обе их сопровождающим. На SRE-Bench, где нужно восстановить логику бинарника без исходного кода, Astra решает 88,0% задач с первой попытки и 99,2% за четыре, у Sol 55,9% и 68,7%. Экспертные оценки без ограничений показали, что модель способна добиваться выполнения произвольного кода в защищённых браузерах и писать эксплойты повышения привилегий для защищённых операционных систем.

Практическое следствие для пользователя API такое. Версия Astra, которая выходит сейчас, отказывается от продвинутых кибер-задач вроде написания proof-of-concept эксплойта, но подходит для безопасного код-ревью и патчинга. Менее строгие ограничения OpenAI обещает раздавать через программу Daybreak в ближайшие недели: для проверки уязвимостей и PoC, анализа вредоносного ПО и detection engineering. Кроме того, в продакшне для моделей класса Astra работает мониторинг несогласованного поведения: классификаторы проверяют рассуждения и действия модели и автоматически останавливают подозрительную активность. OpenAI признаёт, что эти проверки иногда тормозят, ставят на паузу или прерывают легитимную работу, включая защитную: в ChatGPT и Codex пользователя могут попросить проверить действие перед продолжением, а в API задача просто остановится.

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

Что OpenAI говорит о выравнивании и что признаёт проблемой

OpenAI называет Astra своей самой выровненной моделью и приводит несколько внутренних тестов. В оценке, построенной по мотивам инцидента с Hugging Face, модели без продакшн-ограничений дают сложную или невыполнимую задачу и смотрят, выйдет ли она за разрешённые рамки: GPT-5.6 Sol выходила за авторизованную цель в 48% случаев, Astra в 0%. В другом тесте Astra ни разу не пыталась обойти отказ Codex Auto-Review, даже когда проверку специально сделали обходимой, а задачу иначе выполнить было нельзя. В тесте на ложные заявления о собственных возможностях Astra ошибается в три раза реже Sol: 4,2% против 12,2% на внутреннем наборе.

Одну проблему компания признаёт открыто. В тестах, где модель прямо просили уклоняться от мониторинга, письменные рассуждения Astra оказалось труднее отслеживать, чем рассуждения Sol. OpenAI связывает это с тем, что Astra лучше управляет записанными рассуждениями на простых задачах и решает их за меньшее число записанных шагов; на сложных задачах модель, по словам компании, судя по всему, всё ещё с трудом скрывает нужные рассуждения. Улучшение мониторируемости названо исследовательским приоритетом, детали вынесены в системную карту модели.

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

• Ждать появления модели в своём аккаунте: раскатка на Plus, Pro, Business и Enterprise идёт несколько дней, в API имя модели gpt-6-astra. В Enterprise-пространствах модель включает администратор.
• Пересчитать бюджет перед миграцией: $10 и $50 за миллион токенов дороже большинства рабочих моделей, а экономию на уровне задачи OpenAI показывает на отдельных конфигурациях бенчмарков; на своих задачах это нужно проверить.
• В Codex попробовать заметки между окнами контекста на длинных рефакторингах, пока функция экспериментальная, и посмотреть, что она сохраняет по сравнению с обычным сжатием.
• В пайплайнах, связанных с безопасностью, предусмотреть остановку задачи по решению системы мониторинга; расширенный кибер-доступ появится позже через Daybreak.
• Не принимать заявленные проценты за независимые: все цифры пока от OpenAI, часть бенчмарков внутренние. Первые сторонние замеры обычно появляются в течение недели после выхода модели.

Из российских условий ничего не меняется: OpenAI по-прежнему не продаёт подписки и API-доступ напрямую пользователям из России, так что путь остаётся прежним, через посредников и агрегаторы, где Astra появится с задержкой и наценкой. Amazon Bedrock тоже требует иностранного аккаунта AWS. Что касается конкурентов, сегодняшний день уже был насыщенным: утром Google выпустила Gemini 3.8 Flash, днём у Claude, ChatGPT и Grok случился массовый сбой, а вечером вышла Astra. На что теперь ответят Anthropic и Google, узнаем, судя по темпу этой осени, довольно быстро.

Источники: OpenAI: GPT-6 Astra, анонс, Тибо Соттьо (OpenAI) о начале раскатки, X, OpenAI: обновление по безопасности перед выпуском Astra, 1 сентября, Системная карта GPT-6 Astra

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

Практический вопрос для тех, кто обновляется: что сломается. Удалены 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

Главный пример месяца — 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

Код открыт под лицензией 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

В этой статье соберём работающего RAG-бота, который отвечает на вопросы о любой веб-странице, примерно на 60 строках Python. Никаких парсеров HTML, headless-браузеров и сложных фреймворков — только requests, локальная Ollama и чистый Markdown.

Что такое RAG

RAG (retrieval-augmented generation) — это подход, при котором языковая модель не отвечает по своей памяти, а сначала ищет релевантные фрагменты во внешнем тексте, а потом генерирует ответ на их основе. Это резко снижает галлюцинации и позволяет работать с данными, которых не было в обучающей выборке.

• RAG-бот на Python укладывается в ~60 строк и работает без облачных LLM.
• Самое неприятное в RAG-пайплайне — очистка HTML; готовый Markdown API убирает эту работу.
• Текст разбивается на чанки (~1200 символов), каждый превращается в эмбеддинг и сравнивается с эмбеддингом вопроса.
• Локальные модели nomic-embed-text и llama3 через Ollama не требуют иностранных карт и VPN.
• Качество ответа зависит от качества исходного текста: сырой HTML зашумляет поиск, чистый Markdown улучшает ретривл.

Что мы соберём

Архитектура бота простая и универсальная:

1. Отправляем URL в сервис извлечения текста и получаем чистый Markdown.
2. Разбиваем Markdown на фрагменты (чанки) по границам абзацев.
3. Превращаем каждый чанк в вектор — эмбеддинг.
4. То же самое делаем с вопросом пользователя.
5. Находим чанки, ближайшие к вопросу, по косинусной близости.
6. Отдаём найденные фрагменты + вопрос языковой модели с инструкцией отвечать только по контексту.

Такая схема легко масштабируется: можно заменить локальную Ollama на OpenAI, Anthropic или российские модели, а векторы перенести в Qdrant или Chroma.

Что понадобится

• Python 3.9+
• Библиотека requests
• Локально запущенная Ollama с моделями nomic-embed-text и llama3
• Доступ к API извлечения текста (в примере — Web to Markdown/JSON API; бесплатный тариф даёт 50 запросов в сутки)

Код бота

Сохраните скрипт как rag_bot.py и подставьте свой ключ, если сервис извлечения текста требует авторизации:

На что обратить внимание:
Если вы используете RapidAPI-версию сервиса, запрос к API_URL обычно требует заголовка X-RapidAPI-Key. Без ключа бесплатный endpoint может вернуть 401.

Разбор по частям

fetch_markdown — единственный внешний вызов. Сервис сам забирает страницу, убирает навигацию, баннеры и футер и возвращает Markdown: заголовки, абзацы, списки. Это освобождает от зависимостей вроде BeautifulSoup или headless Chrome.

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

embed и cosine превращают текст в векторы и считают их близость. Модель nomic-embed-text из Ollama бесплатна, быстрая и неплохо понимает русский и английский.

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

Запуск

Установите зависимости и скачайте модели в Ollama:

Если всё в порядке, в консоли появится примерно такой результат:

Почему важен чистый Markdown

Если скормить эмбеддинг-модели сырой HTML, в векторах окажутся теги <div>, меню навигации и копирайты из футера. В результате поиск похожести выдаст «Copyright © 2026» вместо полезного ответа. Чистый Markdown — заголовки, абзацы, списки — улучшает качество ретривла почти бесплатно.

Если не хочется зависеть от внешнего API, можно заменить fetch_markdown на один из альтернативных вариантов:

• trafilatura — библиотека на Python для извлечения главного текста.
• r.jina.ai/http://URL — бесплатный сервис без ключа.
• Firecrawl — API с поддержкой сканирования сайтов целиком.
• ScrapingBee — прокси + рендеринг для сложных страниц.

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

Куда развивать

• Направьте бота на документацию, чейнджлог или блог конкурента и задавайте вопросы по ним.
• Замените Ollama на OpenAI, Anthropic, Gemini или российские модели — функция answer меняется в двух строках.
• Сохраняйте эмбеддинги в векторную БД: Chroma, Qdrant или FAISS, чтобы индексировать сразу много страниц.
• Используйте формат json вместо Markdown, если нужна структура: параграфы, заголовки, ссылки — отдельно.

Выводы

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

RAG работает ровно так хорошо, каков текст, который вы ему скармливаете. Уберите самую утомительную часть — очистку HTML, — и останется интересное: поиск и генерация.

Исходник идеи — статья «Chat With Any Website: Build a RAG Bot in ~60 Lines of Python». Попробуйте собрать бота на своей странице и посмотрите, где он справляется, а где начинает фантазировать.

Computer History появилась в десктопном ChatGPT для macOS и фиксирует действия пользователя как «события».

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

Функция работает по принципу opt-in и позволяет исключать приложения и сайты, а также удалять отдельные записи.

OpenAI утверждает, что Computer History не делает скриншотов, видео и аудиозаписей — только текстовые события.

Содержимое вкладок incognito и private mode браузеров игнорируется автоматически.

Что такое Computer History

По сути, это аналог Windows Recall от Microsoft, но без главного спорного момента — постоянных скриншотов экрана. Вместо изображений macOS-приложение ChatGPT фиксирует events: какие документы открывались, в какие поля вводился текст, между какими окнами переключался пользователь.

В демонстрации сотрудник OpenAI Dominik Kundel попросил ChatGPT найти последний отредактированный документ, проверить, был ли он отправлен коллегам в Slack, и составить краткий отчёт о том, как прошло его утро. Всё это ИИ взял из собранной истории действий.

Кто видит данные и как управлять функцией

Функция включена только с согласия пользователя — opt-in, а не opt-out. Можно исключить отдельные приложения и сайты из сбора, а также удалить любую запись вручную. Ari Weinstein, менеджер по продукту и инженерии в OpenAI, уточнил, что Computer History автоматически пропускает содержимое вкладок в режиме инкогнито или приватного просмотра.

Выводы

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

Источник: The Verge

Автор оригинального руководства указывает заголовок «за $5/месяц», но на практике минимально жизнеспособная конфигурация обходится в $6–12/месяц. За $5 дроплет даёт всего 1 ГБ ОЗУ — для семимиллиардной модели этого катастрофически мало. Ниже — реальные цифры и честная смета.

Что такое Llama 2 и зачем её self-hostить

Llama 2 — семейство открытых больших языковых моделей от Meta. Версия 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.

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

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

Почему одной модерацией уже не обойтись

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

Но с ростом объемов данных контролировать этот процесс вручную стало сложнее. Ежедневно на товары WB приходит около 4-5 млн отзывов, из которых не менее 3-5% являются фейковыми — рынок накруток сейчас весьма активный.

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

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

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

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

Но в отличие от банковских транзакций, где информация не содержит графики и медиа, отзывы включают в себя:

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

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

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

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

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

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

Один анализ текста сам по себе не поможет в понимании, фейковый отзыв или нет.

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

Поэтому вопрос «фейк или не фейк» в меньшей степени решается одной лишь модерацией текста и уж тем более единственной ML-моделью.

Как работают наши ML-модели

В Wildberries одновременно работают более 20 моделей, которые ищут фейковые отзывы о товарах. Можно сказать, что это своеобразный оркестр, где агенты отвечают за анализ определенных паттернов и разных аспектов данных.

Саму работу можно разделить на два этапа:

Предмодерация

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

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

Постмодерация

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

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

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

В Wildberries качество решений оценивается сразу на нескольких уровнях.

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

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

Как мы уже говорили, ежедневно поступает 4-5 млн новых отзывов — их нужно провалидировать очень быстро на этапе премодерации. Затем на постмодерацию приходит столько же и даже больше оценок — их нужно рассмотреть повторно. Таким образом, каждый день мы анализируем не менее 10 млн отзывов на предмет фейка.

Немного философии: что хуже — пропустить фейк или скрыть настоящий отзыв?

С точки зрения машинного обучения это классическая задача управления ошибками двух типов:

1. False Positive — ложное срабатывание. Система решила, что отзыв фейковый, хотя он был настоящим.
2. False Negative — пропуск. Система оставила фейковый отзыв, посчитав его настоящим.

Каждая ошибка системы несет свои риски. Представим отзыв с низкой оценкой.

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

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

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

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

Почему рейтинг — не равно честность

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

Аномалию по рейтингу в моменте отловить невозможно, нужно смотреть на множество факторов. У товара может быть рейтинг 5.0, и это будет абсолютно честный рейтинг.

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

Почему графы видят то, чего не замечают простые модели

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

Именно поэтому в систему подключаются графовые алгоритмы.

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

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

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

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

Для выявления таких сценариев есть несколько подходов:

• Community detection — поиск сообществ связанных пользователей.
• Graph anomaly — поиск нетипичных структур графа: появление связей, повторяющиеся паттерны поведения, плотные кластеры.
• Link prediction + графовые нейросети — превентивное выявление скрытых связей между аккаунтами.

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

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

Вместо заключения: закончится ли борьба с фейками и что дальше

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

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

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

В этой статье разберём, почему стандартные 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.

Исследователь и корпоративный архитектор, который в конце 2025-го — начале 2026 года внедрял агентов в финтехе, медицине и compliance, провёл честный post-mortem: из 47 агентов, запущенных в продакшен, стабильную пользу через время приносили только шесть. Разница была не в LLM и не в автономности, а в том, была ли у команды система поддержания контекста в актуальном состоянии.

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

Из 47 промышленных ИИ-агентов 87% со временем пришлось отключить или серьёзно переделать.

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

Спасение — в «живой архитектуре контекста»: freshness scoring, регулярное обновление, drift detection и точки вмешательства экспертов.

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

Что такое context rot

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

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

Три болезненных кейса из продакшена

Платёжный агент в финтехе

Агент автоматически сверял входящие wire-переводы со счетами-фактурами в трёх банковских системах и ERP. В тестах и первые четыре недели в продакшене точность достигала 96%. Затем, к шестой неделе, она тихо упала до 67%. Причина: клиент обновил план счетов и добавил два новых транзакционных кода к концу года. Агент не узнал об изменениях и продолжал формировать неверные проводки. Расчёты и ручная коррекция обошлись клиенту примерно в $340 000, после чего агента отключили.

Агент prior authorization в здравоохранении

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

Агент мониторинга compliance вендоров

Агент отслеживал рискованные платежи поставщикам и почти десять недель показывал хороший результат. Когда компания ввела новую ESG-оценку, агент продолжал действовать по старым критериям. Система сгенерировала более 180 ложных позитивов: совершенно нормальные вендоры стали помечаться как высокорискованные. Вместо помощи закупкам инструмент превратился в bottleneck и начал тормозить процессы.

Почему большинство команд это упускает

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

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

Живая архитектура контекста

Шесть агентов, которые выжили, были спроектированы не как разовые деплои, а как живые системы. Автор называет этот подход Living Context Architecture. Вот практики, которые дали наибольший эффект:

• Context freshness scoring — каждое значимое решение сопровождается оценкой 0–100, показывающей, насколько свежи и валидны данные, на которых оно основано.
• Обязательные циклы обновления — критически важная информация перепроверяется каждые 24–72 часа прямо в живых системах-источниках, а не только когда агент наткнулся на ошибку.
• Drift detection — лёгкие фоновые процессы постоянно сравнивают внутренние знания агента с текущей бизнес-реальностью и сигналят, когда расхождение превышает порог.
• Многоуровневый контекст — разделение по скорости изменения: неизменные регламенты, медленно меняющиеся политики и быстро меняющиеся операционные данные обновляются с разной периодичностью.
• Точки ввода человеческого контекста — структурированные моменты, когда доменные эксперты могут проверить вывод агента и напрямую скорректировать его понимание ситуации.

Чеклист для команды

• Перед запуском определите, какие данные агент считает источником истины и кто за их актуальность отвечает.
• Заложите метрики свежести контекста — хотя бы оценку в процентах для каждого значимого решения.
• Настройте регулярную синхронизацию с живыми системами, а не только ручное обновление при сбое.
• Добавьте drift detection: сравнивайте встроенные знания агента с текущими данными и фиксируйте расхождения.
• Разделите контекст на слои по скорости изменения и не обновляйте всё с одной частотой.
• Предусмотрите точки ручной проверки экспертами — особенно для регуляторных и финансовых решений.
• Фиксируйте post-mortem каждого инцидента context rot, чтобы не повторять одни и те же слепые зоны.

Частые вопросы

Выводы

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

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

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

Источник: How I Beat Context Rot and Saved 6 Out of 47 AI Agents in Production — HackerNoon

Вместе со швейцарской компанией 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 и в пресс-релизе.

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

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

Причины этого понятны:

• Рынок ИБ испытывает серьезный кадровый дефицит, и найти опытного аналитика SOC, специалиста по расследованию инцидентов или эксперта по threat hunting становится все сложнее.
• Бизнес постоянно ищет способы повысить эффективность и сократить расходы.
• Вендоры заинтересованы в том, чтобы показать свои продукты максимально инновационными.

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

Но сначала уточним…

Что сегодня называют ИИ в ИБ

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

№1. Классические правила корреляции

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

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

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

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

№2. Машинное обучение

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

Я сам экспериментировал с ML-модулем в одном из решений: подключили, обучили, запустили в пилот. Вендор обещал «снижение шума на ХХ процентов» и раннее обнаружение сложных атак.

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

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

№3. Генеративный ИИ

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

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

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

А «предвыборные обещания» вендоров утомляют. Но не потому, что я против прогресса, а потому, что они создают иллюзию безопасности — и эта иллюзия опасна.

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

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

Где маркетинг пока опережает технологии

Ниже — четыре главных «обещания», которые я слышу слишком часто.

Обещание №1. ИИ сам найдет неизвестные атаки

Это один из самых популярных тезисов на рынке, и формально он не является ложью, так как современные решения класса UEBA, NDR, XDR и некоторые SIEM действительно способны выявлять аномалии, которые сложно обнаружить вручную.

Представим ситуацию:

• Сотрудник бухгалтерии никогда не подключался к корпоративной сети ночью.
• Он не использует PowerShell.
• Он не работает с серверами.

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

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

Именно поэтому окончательное решение всё равно принимает аналитик.

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

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

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

Обещание №2. Автоматическое расследование сложных инцидентов

Многие производители заявляют, что их ИИ способен самостоятельно расследовать инциденты. Частично это правда.

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

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

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

Без этого контекста расследование невозможно завершить автоматически.

Обещание №3. ИИ заменит аналитиков SOC

Ооо, это одно из самых популярных заблуждений!

Причина его популярности понятна — SOC испытывают постоянную нехватку кадров, а атаки усложняются. Но если посмотреть на реальные проекты, становится очевидно: сегодня ИИ выступает скорее помощником аналитика.

Например, современные платформы могут автоматически:

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

Всё это серьёзно снижает нагрузку на специалистов.

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

• Можно ли отключить сервер прямо сейчас?
• Сколько клиентов потеряют доступ к сервису?
• Есть ли резервная площадка?
• Какие финансовые потери возникнут в случае остановки?

Ответов на эти вопросы в логах нет.

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

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

Обещание №4. Разработка стратегии безопасности

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

Однако модель не знает:

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

В итоге получится хороший шаблон. Но стратегия безопасности всегда требует участия человека.

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

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

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

Где ИИ действительно приносит пользу

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

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

Антифрод

Если искать область, где технологии доказали свою эффективность, то это финансовый сектор.

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

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

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

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

Антифрод-система анализирует десятки факторов одновременно: локацию, тип операции, историю поведения клиента и прочее. И если, например, клиент банка пенсионного возраста в 13:00 оплатил продукты в магазине рядом с домом, а в 14:00 купил что-то на 180 000 рублей в интернет-магазине посредством только что установленного мобильного приложения с IP-адресом Нью-Йорка, то такая операция блокируется. И здесь, как никогда, полезен ИИ.

Разница между 2018 и 2026 годами огромна — это переход от «защиты по порогам» к «защите по профилю». И этот переход был не про маркетинг, а про реальную необходимость: угрозы стали умнее, и защита должна была стать умнее тоже.

Поведенческая аналитика

Ещё один хороший пример — системы класса UEBA.

Представим системного администратора:

• В среднем он скачивает около 200 МБ данных в день.
• Работает в стандартное время.
• Подключается только из корпоративной сети.

За неделю до увольнения он начинает регулярно заходить ночью и выгружает 40 ГБ архивов с файлового сервера.

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

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

Генеративный ИИ для аналитиков

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

Или другой пример. Аналитик получает сложное правило обнаружения атаки и просит систему объяснить его простым языком. Модель формирует понятное описание логики работы этого правила.

Это не выглядит революцией. Но экономия времени весьма заметна.

Корреляция больших объемов событий

И, пожалуй, самый успешный сценарий применения технологий.

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

Как отличить реальный ИИ от маркетинговой наклейки

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

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

Как отсечь маркетинг от инженерии на этапе покупки? Когда вы видите рекламный баннер ИБ-продукта с ИИ (который, кстати, тоже сгенерирован ИИ), какие вопросы нужно задать, чтобы не купить кота в мешке?

Есть несколько простых вопросов:

• Какая именно технология используется?
• На каких данных обучалась модель?
• Какие показатели улучшились после внедрения?
• Как эти показатели измерялись?
• Есть ли реальные кейсы заказчиков?

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

И в помощь также оставлю сравнительную таблицу: «Маркетинг vs реальность». Надеюсь, эти материалы помогут вам принять правильное решение.

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.

Эта статья объясняет, почему классических 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-датасеты, проверяйте на реальном трафике и не забывайте про бюджеты. Так вы сможете доверять зелёному цвету пайплайна снова.

Решение выросло из собственного опыта: по словам 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.

Для российских разработчиков это особенно близкая история: Kotlin создавался в JetBrains, компании, основанной выпускниками Санкт-Петербургского политехнического университета. Язык, названный в честь острова в Балтийском море, стал одним из самых заметных российских технологических экспортов последнего десятилетия.

15 лет Kotlin. Первый анонс состоялся в июле 2011 года, стабильная 1.0 — в феврале 2016-го.

Kotlin 2.4.0. Стабильные context parameters, explicit backing fields, поддержка Java 26, Swift packages в Kotlin/Native и совместимость с Gradle 9.5.0.

Kotlin Toolchain 0.11. Amper эволюционировал в единый инструментарий: одна команда kotlin для создания, сборки, тестирования и публикации проектов.

Koog 1.0. JetBrains выпустила стабильный фреймворк для AI-агентов на Kotlin и Java с годовой гарантией совместимости ядра.

Compose Multiplatform 1.12.0-beta01 и Compose Hot Reload 1.2.0-beta01 развивают shared UI и экспериментальный MCP-сервер для AI-агентов.

Гранты Kotlin Foundation 2026. Приём заявок на финансирование open-source библиотек и инструментов открыт до 14 июля 2026 года.

Пятнадцать лет: от внутреннего проекта до мейнстрима

История Kotlin началась в 2010 году как попытка JetBrains решить собственные проблемы с Java. В 2011-м язык впервые показали публике, а в феврале 2016 года вышла стабильная версия 1.0. Переломным моментом стал Google I/O 2017: Kotlin получил статус первоклассного языка для Android, после чего интерес к нему резко вырос.

Сегодня Kotlin используется не только в мобильной разработке. На нём пишут backend на Spring и Ktor, делают кроссплатформенные приложения через Kotlin Multiplatform, экспериментируют с Kotlin/Wasm и даже строят AI-агентов. По данным ежегодных опросов JetBrains, доля Kotlin в коммерческих проектах стабильно растёт как в Европе, так и в России, несмотря на санкционные ограничения в части корпоративных лицензий.

If I were to choose one word to describe Kotlin's design, it would be pragmatism. For us it means caring about the usefulness.

Kotlin 2.4.0: что вошло в релиз

3 июня 2026 года JetBrains выпустила стабильный Kotlin 2.4.0. Это не инкрементальный патч, а полноценная мажорная версия с изменениями в языке, стандартной библиотеке, компиляторе и всех целевых платформах.

• Язык. Стабилизированы context parameters и explicit backing fields, добавлены новые target'ы для аннотаций.
• Стандартная библиотека. UUID API вышел из экспериментального статуса, появились функции для проверки отсортированности коллекций.
• Kotlin/JVM. Поддержка Java 26 и аннотации в метаданных включены по умолчанию.
• Kotlin/Native. Swift packages можно использовать как зависимости, обновлён Swift export, по умолчанию включён CMS GC.
• Kotlin/Wasm. Инкрементальная компиляция по умолчанию и поддержка WebAssembly Component Model.
• Kotlin/JS. Экспорт value-класс и возможности ES2015 при инлайнинге JS-кода.
• Gradle. Совместимость с Gradle 9.5.0.
• Maven. Автоматическое выравнивание версий Java и JVM target.
• Компилятор. Более предсказуемое поведение inline-функций при компиляции .klib.

Для практики это означает: если ваш проект живёт на JVM, можно обновляться ради Java 26 и улучшений stdlib; если вы работаете с iOS через Kotlin/Native — стоит посмотреть на Swift packages; для WebAssembly-экспериментов 2.4.0 делает сборку заметно быстрее.

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

Обновление до 2.4.0 проходит через указание версии в Gradle или Maven. В Android Studio и IntelliJ IDEA новая версия уже включена в последние сборки.

Kotlin Toolchain 0.11: Amper уходит в прошлое

В июне 2026 года JetBrains окончательно переименовала Amper в Kotlin Toolchain и выпустила версию 0.11. Это не просто ребрендинг: инструмент позиционируется как единая точка входа для работы с Kotlin-проектами. Одной командой kotlin можно создать, собрать, протестировать и опубликовать проект.

В 0.11 появилась возможность публиковать JVM-библиотеки, улучшена разработка плагинов и упрощена начальная настройка. Для российских команд, часть которых уходит от корпоративных Gradle-лицензий к open-source инструментам, Kotlin Toolchain может стать интересной альтернативой для новых проектов и прототипов.

Важно: Kotlin Toolchain пока в статусе Alpha. Для существующих Gradle-проектов массово мигрировать смысла нет — инструмент ещё не покрывает все сценарии зрелых сборок. Но пробовать на небольших сервисах и pet-проектах уже можно.

Koog 1.0: AI-агенты на Kotlin

Фреймворк Koog от JetBrains вышел в версии 1.0. Он предоставляет примитивы для построения агентных приложений: инструменты, workflow, персистентность, память, observability и интеграции с JVM/KMP-проектами. Главное для Java-команд: Koog теперь предлагает идиоматичный Java API, то есть переходить на Kotlin ради агентов не обязательно.

Koog интегрируется со Spring AI, что делает его естественным выбором для backend-разработчиков, которые уже используют Spring Boot. Появилась мультиплатформенная observability и годовая гарантия совместимости ядра — это важно для команд, которые рассматривают агентов не как прототип, а как часть продакшена.

Compose и инструменты UI

Для UI-разработчиков в выпуске два значимых обновления. Compose Multiplatform 1.12.0-beta01 продолжает развивать shared UI: новые графические возможности, улучшения accessibility на iOS, обновления поведения UI-тестов и исправления для десктопа, веба и Gradle-плагина.

Отдельно стоит Compose Hot Reload 1.2.0-beta01. В нём развивается экспериментальный MCP-сервер: AI-агенты получают доступ к логам, ошибкам UI, могут перезапускать приложение и управлять его жизненным циклом. Это ещё не production-ready, но демонстрирует направление: разработка интерфейсов становится более визуальной и интерактивной.

Экосистема: библиотеки, гранты и корпоративный опыт

В обзоре JetBrains упомянуты три KMP-библиотеки, которые стоит изучить: ComposeMediaPlayer для кроссплатформенного видео, NSExceptionKt для улучшенной обработки крэшей на Apple-платформах и multiplatform-settings для хранения key-value данных в shared-коде.

Кроме того, Kotlin Foundation открыл грантовую программу 2026. Финансирование могут получить open-source проекты вокруг Kotlin Multiplatform, AI и больших языковых моделей. Заявки принимаются до 14 июля 2026 года. Для российских авторов библиотек это реальный способ поддержать проект, особенно если он пользуется спросом у зарубежного комьюнити.

Ещё один сигнал зрелости экосистемы — история Booking.com. Компания внедрила Kotlin Multiplatform для экспериментальной библиотеки и получила результаты выше ожиданий: улучшилась консистентность между Android и iOS, при этом команды не отказывались от платформенно-специфичной разработки.

Обучение: бесплатные курсы на Hyperskill

К юбилею JetBrains сделала часть Kotlin-курсов на Hyperskill бесплатными. Это проектно-ориентированная платформа: можно укрепить основы или пойти в сторону мобильной и backend-разработки. Для тех, кто только начинает или переходит с Java, это удобный способ получить практику, а не только теорию.

Выводы

15 лет Kotlin — это не только юбилей, но и точка, где язык перешёл из фазы «быстрого роста» в фазу «экосистемного инструмента». Kotlin 2.4.0 делает язык зрелее на всех платформах, Kotlin Toolchain упрощает вход в экосистему, а Koog и Compose Hot Reload показывают, что Kotlin активно используется в новой волне AI-разработки.

Для работающих проектов самый безопасный шаг — обновиться до Kotlin 2.4.0 в тестовом окружении и проверить совместимость. Новые инструменты вроде Toolchain и Koog стоит пробовать на pet-проектах, прежде чем тащить в продакшен. А если у вас есть open-source библиотека вокруг Kotlin — грантовая программа Kotlin Foundation может стать хорошим подспорьем.

Источник: Kodee's Kotlin Roundup: Kotlin Turns 15, Kotlin 2.4.0, and the Kotlin Toolchain — блог JetBrains.

Почему терминальный агент, а не Cursor

Cursor и GitHub Copilot работают внутри IDE — и там же остаются. Вы платите подписку, получаете конкретный набор моделей и не можете выйти за его рамки. OpenCode устроен иначе: это TUI-утилита (text user interface), которая запускается прямо в консоли и не привязана ни к одному редактору.

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

Работает с любым провайдером, у которого есть OpenAI-совместимый API. Это важно, потому что доступ к Claude, GPT и Gemini напрямую из РФ — отдельный квест с VPN и зарубежными картами.

Как подключить топовые модели без VPN

Получить API-ключ от Anthropic или OpenAI из России — значит найти зарубежную карту, настроить VPN и молиться, что аккаунт не заблокируют через месяц. RouterAI закрывает этот вопрос: российский сервис-агрегатор с OpenAI-совместимым API, оплатой через СБП и рублёвым счётом.

Схема работы простая:

1. Вы регистрируетесь на RouterAI;

2. Пополняете баланс;

3. Получаете один API-ключ вида sk-or-... (его сохраните, сейчас пригодится и не публикуйте никогда в открытом доступе)

Теперь у вас есть доступ к Claude, GPT, Gemini, DeepSeek и другим моделям. OpenCode видит RouterAI как обычного OpenAI-провайдера, поэтому никаких специальных настроек совместимости не нужно.

Модель оплаты — pay-as-you-go: платите только за токены, которые реально потратили. Для команд есть единый счёт с общим балансом.

Как только в RouterAI появляется новая модель — она сразу доступна в OpenCode через тот же ключ, без повторной настройки.

Установка и первый запуск

Установка — одна команда:

curl -fsSL https://opencode.ai/install | bash

После этого перезапустите терминал, перейдите в папку проекта и запустите:

opencode

Если TUI открылся — переходим к настройке провайдера.

Конфиг

Создайте или отредактируйте файл ~/.config/opencode/opencode.json. Вот рабочий пример с моделями RouterAI:

Модели добавляются по аналогии — полный список доступных смотрите в документации RouterAI.

Подключение провайдера

Сохраните конфиг и перезапустите OpenCode. Нажмите ctrl + p, выберите Connect Provider:

Найдите RouterAI в конце списка и введите API-ключ (sk-or-...):

После этого через ctrl + p → Switch Model выбираете нужную модель из тех, что прописали в конфиге.

agents.md: память агента между сессиями

У OpenCode есть проблема, знакомая всем, кто работал с LLM в чате: каждая новая сессия начинается с чистого листа. Агент не помнит, что ваше приложение крутится в Docker, что документация лежит в /docs и что хардкодить русские строки в коде запрещено.

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

/init

Агент сам проанализирует структуру проекта и заполнит файл базовой информацией. После этого открывайте его и дописывайте правила под свой стек. Вот пример:

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

Режимы Plan и Build: когда что использовать

OpenCode работает в двух режимах, переключение между которыми — Tab.

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

В режиме Build агент делает всё то же самое, плюс выполняет команды в консоли и вносит правки в файлы. Здесь уже идёт реальная работа: агент пишет код, запускает тесты, правит ошибки и предлагает diff-патчи, которые вы принимаете или откатываете.

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

Нюансы, которые съедят ваши токены

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

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

Выбор модели влияет на результат сильнее, чем кажется. Claude Sonnet 4.6 и GPT-5.2-Codex справляются со сложными архитектурными задачами и большими кодовыми базами. GLM 5 и аналогичные лёгкие модели подходят для объяснений и точечных правок, но на сложном коде ошибаются чаще.

*** *** ***

Сетап получается компактным: OpenCode живёт в терминале и берёт на себя агентную часть работы — читает файлы, выполняет команды, предлагает diff. RouterAI даёт доступ к Claude, GPT и Gemini через один ключ с рублёвой оплатой. Вместе они закрывают две проблемы: тяжёлые IDE с vendor lock-in и проблему доступа к API из России.

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

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

Откуда вообще берутся ошибки у ИИ

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

В декабре 2025 года исследователи из Университета штата Пенсильвания и Comcast AI Technologies протестировали поведение языковых моделей при одинаковых настройках и запросах. При многократном повторении одних и тех же задач разрыв между лучшим и худшим результатом доходил до 70%.

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

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

Open-source против специализированных систем

Распознаванием документов занимаются OCR-системы — технологии оптического распознавания символов. OCR появился ещё в XX веке и развивался задолго до генеративного ИИ. Сегодня такие решения работают в банках, страховании, телекоме и госуслугах — везде, где нужно проверить личность по документу или ввести данные из потока сканов. Качество здесь измеряют точностью распознавания, а её можно посчитать.

Базовые OCR-технологии доступны практически любому разработчику. Есть открытые движки — Tesseract, PaddleOCR, EasyOCR. Они распространяются бесплатно и позволяют быстро собрать собственную систему распознавания документов.

Открытые тесты показывают разброс качества в зависимости от типа документа и условий съёмки. На типовых задачах Tesseract показывал точность 70–85%, PaddleOCR — 90–95%. При работе с финансовыми документами и реальными сканами цифры были скромнее: около 84% у Tesseract и 91% у PaddleOCR.

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

Почему 90% точности — слабый результат

Возьмём систему, которая ошибается с вероятностью 1% и на подлинных документах, и на поддельных. Доля подделок в потоке тоже составляет 1%. Если система пометила документ как подозрительный, какова вероятность, что он действительно поддельный? Интуитивно кажется, что почти 99%, однако на практике все иначе. Расчёт по формуле Байеса даёт ответ:

Вероятность того, что «подозрительный» документ действительно поддельный:

0,99 × 0,01 / (0,01 × 0,99 + 0,99 × 0,01) = 0,5

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

Но если представить, что ИИ ошибается на подлинных документах только в 0,1% случаев, картина меняется и вероятность выявления подделки резко возрастает:

0,999 × 0,01 / (0,01 × 0,999 + 0,99 × 0,001) ≈ 0,91

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

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

Что стоит за цифрой 984 из 1000

Вернёмся к кейсу «Росагролизинга». Компания использует технологию Smart Engines для автоматического ввода данных из документов лизингополучателей. По словам компании, из 1000 паспортов 984 обрабатываются без единой ошибки — это касается основного разворота, который в среднем содержит около 200 символов.

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

X²⁰⁰ = 984 / 1000

Чтобы найти X, нужно взять корень 200-й степени из обеих частей уравнения:

X = 0,984^(1/200) ≈ 0,99992

Получается, что точность распознавания одного символа оценивается на уровне 99,99%. Для бизнеса это значит, что 984 из 1000 клиентов проходят онбординг без единого сбоя, участия оператора и ошибок.

Такой результат не выводится сам по себе из общей модели ИИ. Под распознавание удостоверений личности нужна отдельная инженерная работа по трём направлениям:

1. Специализированные датасеты. Обычный набор фотографий печатного текста для этого не подходит. Паспорта изготавливают из специальной бумаги, на них есть защитные элементы, ламинация и голограммы, которые усложняют извлечение данных. Для обучения нужны десятки тысяч размеченных изображений, синтезированных так, чтобы не нарушать 152-ФЗ «О персональных данных» и не содержать информацию о реальных людях.
2. Оптимизация под реальные условия съёмки. На практике паспорт редко снимают идеальным сканом в высоком разрешении. При выездном обслуживании и самообслуживании документ часто фотографируют на весу, под углом или сложенным «книжкой», а на изображении появляются шумы, размытия, тени и блики. Алгоритмы должны выдавать результат и в таких условиях.
3. Понимание структуры документа. Системе мало просто извлечь текст с картинки. Ей нужно находить паспорт на фотографии или в видеопотоке и знать, из каких полей он состоит: где подпись, где строки с именем и фамилией, где машиночитаемая зона.

Что это значит для бизнеса

Чем выше точность, тем меньше работы остаётся людям. На уровне 90% компания заваливает отказами нормальных клиентов и держит отдельных сотрудников, которые перепроверяют документы вручную. На уровне 99,9% и выше вручную проверять приходится в разы меньше: падают расходы на этот штат и снижается риск штрафов за пропущенные подделки.

Бизнес сейчас пытается добиться главных целей:

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

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

Итого

Для генерации текста или поиска идей хватает точности в районе 80–90%, и языковые модели справляются с этим хорошо. Для распознавания документов планка выше: 99,9% и больше — минимальное условие, при котором автоматизация вообще начинает работать. Кейс с 984 паспортами из 1000 показывает, как эта цифра считается на практике и какая инженерия за ней стоит. Прежде чем доверять ИИ задачи с высокой ценой ошибки, спросите разработчика, как именно посчитали точность системы.

В этой статье разберёмся, когда 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.

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

• Cloud.ru запустила Evolution Stack.ML — платформу для обучения ИИ-моделей в частном и гибридном облаке.
• В основе лежит сервис Evolution Distributed Train: обучение, тюнинг, развёртывание моделей и совместная работа команд.
• Платформа поддерживает изолированные рабочие пространства для более чем 200 команд одновременно.
• По заявлению компании, утилизация GPU растёт с 35% до 90%, а окупаемость серверных мощностей составляет менее 3 месяцев.

Что умеет платформа

Ядро продукта — сервис Evolution Distributed Train. Он объединяет инструменты для разработки, управления экспериментами и мониторинга в единую экосистему. Пользователи могут запускать изолированные рабочие пространства для более чем 200 команд одновременно.

Для распределения нагрузки используются механизмы очередей, приоритетов, аллокаций и спотов. По данным Cloud.ru, это позволяет поднять утилизацию GPU с 35% до 90% и окупить затраты на серверное оборудование менее чем за 3 месяца. Совместное использование кластеров, по оценке компании, ускоряет обучение и разработку новых ИИ-решений на 20%.

Встроенные механизмы self-healing автоматически обнаруживают сбои оборудования, перезапускают задачи и заменяют GPU-ноды. OSS-слой платформы Cloud.ru позволяет отслеживать загрузку инфраструктуры и контролировать расходы.

Evolution Stack.ML помогает преодолеть барьеры для внедрения ИИ в крупном бизнесе и государственных компаниях — решение соответствует строгим требованиям к безопасности и нормам регуляторов. Evolution Stack.ML повышает экономическую эффективность использования собственного «железа» и при этом даёт доступ к самым современным технологиям и методам работы с ИИ.

Для кого это

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

Cloud.ru также ссылается на собственное исследование: в России растёт спрос на гибридные сценарии. Среди наиболее востребованных — обработка данных и использование ИИ, разработка и тестирование в облаке, георезервирование и disaster recovery.

Выводы

Запуск Evolution Stack.ML — попытка Cloud.ru закрыть спрос на корпоративное ИИ-обучение с соблюдением регуляторных ограничений. Если заявленные цифры подтвердятся в реальных внедрениях, платформа может стать интересной альтернативой самостоятельной сборке инфраструктуры для машинного обучения.

Источник: пресс-служба Cloud.ru.

Реклама. Рекламодатель: ООО «Облачные технологии», ИНН 7736279160, erid: 2W5zFHcxyBP

Это не очередной корпоративный конфликт. История соединяет в себе инвестиции 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

Харнесс не привязан к одной модели: одна модель ищет уязвимости в VDH, а другая модель в VVS независимо валидирует находки, включая оценку риска в продакшене. Так Model B оценивает вывод Model A с другими весами и другими обучающими данными, словно независимый адвокат дьявола. Это не просто безопасность: провайдеры моделей меняют температуру, кэширование и бюджеты инференса даже в рамках одной версии, а харнесс умеет поглощать эту волатильность, не ломаясь.

Харнесс — это не модель, а оркестрация. Ценность в конвейере с сохранением состояния, а не в очередном промпте.

Две стадии: Vulnerability Discovery Harness (VDH) ищет баги, Vulnerability Validation System (VVS) проверяет, дедуплицирует и чинит их.

Контекст держится под контролем. Каждый агент решает узкую задачу и использует менее 25% окна.

Доверие через adversarial verification. Охотник должен предъявить модель угрозы, рабочий PoC и патч; валидатор обязан опровергнуть находку.

Цифры масштаба: VDH охватывает 128 репозиториев; в общий VVS на момент публикации попало 13 841 находка по 145 репозиториям, из которых 7 245 — находок, по которым можно действовать, отправлены инженерам на исправление.

Почему обычный кодинг-агент не справляется

Cloudflare начинала с 450-строчного скилла security-audit, который проходил семь фаз в одной сессии: три агента-разведчика писали архитектуру, охотники атаковали код по классам угроз, валидаторы пытались опровергнуть находки, а финальный агент перепроверял выжившие баги. Скилл работал, но быстро уперся в потолок.

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

Три стены, которые ломают односессионный подход

• Исчерпание контекста. Через час модель начинает «пожирать» собственную память и забывает баги, которые искала утром. Решение — вынести состояние наружу и считать LLM stateless-движком.
• Отсутствие персистентности. Ошибка API или обрыв соединения обнуляют часы работы. SQLite, ключированная по (run_id, repo, stage), позволяет возобновлять любой этап.
• Слепота к межрепозиторным связям. Уязвимость в библиотеке проявляется только там, где её используют. Без трассировки зависимостей такие баги остаются незамеченными.

Совет: настоящий минимальный харнесс — это только Recon, Hunt и Validate, записанные в базу, плюс валидатор, который не может заводить собственные находки. Кросс-репозиторную трассировку и дедупликацию можно добавить позже, когда без них станет невыносимо.

Две стадии: открытие и триаж

Вся система разбита на два независимых контура. Первый — Vulnerability Discovery Harness (VDH), движок обнаружения, который сканирует код и выдаёт сырые кандидаты. Второй — Vulnerability Validation System (VVS), куда попадают находки из нескольких харнессов.

Главный архитектурный трюк — разные модели на разных стадиях. VDH работает на одной модели, VVS — на другой. Так Model B оценивает вывод Model A с другими весами и другими обучающими данными, словно независимый адвокат дьявола. Это не просто безопасность: провайдеры моделей меняют температуру, кэширование и бюджеты инференса даже в рамках одной версии, а харнесс умеет поглощать эту волатильность, не ломаясь.

VDH: как устроен конвейер обнаружения ИИ-харнесса

VDH состоит из восьми стадий. Первые три — разведка, охота и валидация. Остальные пять работают как конвейер «производитель—потребитель»: пока идёт первичный поиск, Gapfill, Feedback и Trace порождают новые задачи, Dedup сворачивает дубли, и цикл продолжает потреблять очередь.

• Recon. Три параллельных агента-разведчика строят architecture.md и пишут собственную таксономию атак под конкретный репозиторий.
• Hunt. Охотники атакуют код по классам угроз. Они компилируют фрагменты, запускают бинарники и используют песочницу на базе unshare.
• Validate. Детерминированный код проверяет схему и пути, затем изолированный агент пытается опровергнуть находку.
• Gapfill. Генерирует новые задачи охоты для недостаточно покрытых ячеек «область × класс атаки».
• Dedup. Детерминированный код + агент кластеризуют находки по корневой причине в реальном времени.
• Trace. Трассирует граф зависимостей и порождает задачи в потребляющих репозиториях.
• Feedback. Переписывает промпты в очереди на основе провалов валидации, поверхностных прогонов (shallow runs) и повторных промахов.
• Report. Рендерит человекочитаемый отчёт; здесь модель не нужна.

Динамическое моделирование угроз

Recon пишет модель угроз самостоятельно, а не получает её сверху. Помимо десяти встроенных классов атак (инъекции, повреждение памяти, парсинг протоколов, тайминговые side-channel и другие), агент может изобрести собственные классы, специфичные для кодовой базы, с собственной методологией. Это делает охоту точнее, чем любой универсальный чек-лист.

Охотники выходят за рамки чтения кода и переходят к активному выполнению. Они компилируют фрагменты, собирают мини-версии и атакуют их. Качество сильно выросло, когда охотникам дали песочницу на базе системного вызова unshare (изолирует пространства имён Linux), в которой можно падать. Если харнесс сам бежит внутри Docker, песочнице нужны флаги seccomp=unconfined (отключает фильтр системных вызовов) и apparmor=unconfined (отключает профиль мандатного доступа), иначе она молча не запустится.

Братские форки и список пожеланий

Два механизма дают охотникам автономию, не позволяя сбиться с курса. Братское форкание: если охотник натыкается на интересный путь вне текущей области, он создаёт «брата» с точным структурным заданием. По флоту это даёт 9–20% задач в зависимости от модели.

Список пожеланий — центральный список запросов на инструменты и ресурсы. Охотник или валидатор может написать: «мне нужна виртуальную машину на FreeBSD, чтобы подтвердить сквозной PoC». Система автоматически перезапускает задачу, когда человек предоставит зависимость. Список пожеланий уже записывался 25 472 раза за 128 репозиториев.

Кросс-репозиторная трассировка

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

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

Как не превратиться в генератор мусора

Без жёстких контролей агенты будут читать собственные находки. Они могут подправить исходник, чтобы эксплойт сработал, написать тавтологический тест вроде «exec() выполняет код, значит критическая уязвимость» или построить эксплойт, который работает, но не доказывает ничего из-за неверной модели угроз.

В Cloudflare ввели жёсткие правила. Охотник обязан сформулировать модель угрозы до того, как завести находку: кто атакующий, какую границу доверия пересекает уязвимость, какое допущение ломает. Порядок полей в выходной схеме принудительно требует этого и отсекает пустые находки вроде «если у пользователя есть право записи в БД, он может записать в БД».

• Каждая подтверждённая находка сопровождается рабочим PoC в виде теста против неизменённой кодовой базы.
• Каждая находка должна включать предложенный патч в виде рабочего git diff.
• Детерминированный валидатор проверяет, что указанные файлы и пути существуют, а патч и тест парсятся.
• Валидатор не может заводить собственные находки; его единственная работа — агрессивно опровергать теорию охотника.

Cloudflare не заявляет о доле ложноотрицательных срабатываний: невозможно знать все баги в кодовой базе. Вместо этого они отслеживают, находят ли повторные прогоны новые баги и растёт ли покрытие областей атак (area × attack-class). Это прокси-метрика, но она достаточно хороша для измерения эффективности.

VVS: триаж, который превращает шум в работу

Находка из харнесса — только начало. В общий VVS вливаются находки из разных источников; на момент публикации там было 13 841 находка по 145 репозиториям. Триаж разбит на три работы: Dedup, Judgment и Fixing.

• Dedup. Детерминированный код строит инвертированные индексы по файлам, функциям, границам доверия и редким токенам, чтобы сократить список кандидатов. Затем Dedup-агент решает, не закрывается ли несколько находок одним патчем. Стабильные межпрогоновые ключи возобновляют старые записи вместо создания новых.
• Judgment. Агент собирает контекст из продакшена: wiki, Jira, git, конфиги. Он проверяет, воспроизводится ли баг на последнем main, доступен ли путь извне, и кто владелец репозитория. Результат — разделение на «эксплуатируется сейчас», «реальный, но латентный» и «заведён не в тот компонент».
• Fixing. Fixer переписывает патч и тесты в стиле репозитория, накладывает diff и запускает таргетированные тесты. Чистый переход fail→pass — единственный случай автоматического cleanup. Если пост-патч тест падает или находит регрессию, коммит блокируется. Fixer никогда не мержит сам: всегда нужен человек.

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

Сколько это стоит и как понять, что работает

Большая часть бюджета уходит на стадию Hunt. Поэтому Gapfill становится рычагом соотношения цена/покрытие: каждый дополнительный проход стоит примерно вдвое меньше первичной охоты. Cloudflare бюджетирует не на прогон, а на репозиторий, с жёстким лимитом задач на репо и пулом из 50–200 воркеров. Так деньги тратятся там, где находятся баги, а не на «чистые» репозитории.

Полное сканирование сложного репозитория может занять несколько часов; худший прогон длился чуть более 14 часов. Поэтому большие сканы — это периодическая зачистка бэклога, а не проверка на каждый PR. Для CI/CD подходят более дешёвые и маленькие харнессы.

Цифры фильтрации

• VDH выпустил 20 799 сырых кандидатов.
• После независимой валидации осталось около 12 057 находок.
• В VVS, объединившись с находками из другого харнесса, общий пул вырос до 13 841.
• Dedup-агент свернул 5 442 дубля.
• 1 154 были отмечены как «не тот репозиторий» или «низкий риск» и возвращены в систему для повторной обработки там, где это уместно.
• В итоге 7 245 находок, по которым можно действовать, ушли инженерным командам.

Ещё один пример: для стандартного репозитория примерно на 30 000 строк кода система выдаёт около 100 начальных находок за 3–4 часа, затем в течение 3 часов сжимает их до 80 уникальных багов, а Fixer обрабатывает их со средней скоростью 5 минут на баг. Весь цикл «найти → валидировать → дедуплицировать → открыть PR» занимает примерно 14 часов.

Распространение патчей

80 патчей за раз в прод не выкатить. Cloudflare использует многоуровневый выкат: критические, высокие и эксплуатируемые извне баги (в среднем 10 из 80) уходят на ускоренное ревью и закрываются в продакшене за 5 дней. Оставшиеся латентные риски и мелкие аномалии конфигурации раскатываются в течение 15–20 дней, чтобы не ломать платформу.

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

Часто задаваемые вопросы

Выводы

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

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

Компания выложила исходный security-audit skill на GitHub: cloudflare/security-audit. Это не сам харнесс, но рабочая отправная точка. Если хотите развивать тему дальше, полезно почитать про автоматизацию безопасности с помощью DevSecOps и ИИ и про SCA-анализаторы, которые решают смежную задачу в сторонних зависимостях.

Источники

Build your own vulnerability harness — Cloudflare Blog, 18 июня 2026.

Через четыре месяца четырёхагентный пайплайн на LangChain крутился одиннадцать дней и стоил 47 000 долларов. Никто не заметил, пока не пришёл счёт. Тот же паттерн: цикл работал корректно, но у него не было условия выхода.

Проблема не в моделях, а в отсутствии условия остановки. В этой статье разберём, как собрать минимальный, но production-ready каркас агентного цикла: спецификацию до запуска, предохранитель по токенам и ходам, неизменяемый аудит и поверхность для человеческого согласования. Полный код и 80 тестов с 100% покрытием доступны в репозитории автора оригинала.

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

Спецификация должна отвечать на три вопроса: что делает, что не делает и что значит «готово» — в одном предложении.

Circuit breaker режет цикл по жёстким потолкам: число ходов и суммарные токены. Проверка — до вызова модели, а не после.

Ledger в SQLite фиксирует каждый ход: хеш входа, дельту токенов, время, результат. Это аудит, а не лог для отладки.

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

Что такое агентный цикл и почему он уходит в бесконечность

Агентный цикл — это конструкция вида while True, внутри которой языковая модель получает задачу, вызывает инструменты, анализирует результат и решает, продолжать или закончить. Такие циклы лежат в основе оркестраторов вроде LangGraph, CrewAI и AutoGen, а также внутри coding-агентов. Если только начинаете разбираться с LLM, полезно сначала понять, как устроены большие языковые модели, а для практики — заглянуть в основы Python.

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

Почему дорожает каждая итерация:
Агент не начинает с чистого листа. Он каждый раз перечитывает всё предыдущее окно контекста — все неудачные попытки, все промежуточные выводы. Итерация 1 стоит 100 токенов, итерация 10 — уже тысячи. Вы платите за каждый провал снова и снова.

Почему компании сначала платят за чатбота, а потом за агентный рабочий процесс

Gartner фиксирует разрыв в потреблении токенов между пилотными чатботами и production-агентными рабочими процессами в 5–30 раз. А отчёт FinOps Foundation за 2026 год говорит, что 73% компаний превысили изначальный бюджет на ИИ. Цифры взяты из оригинального туториала; полные отчёты Gartner и FinOps Foundation доступны по платным подпискам. Причина разрыва — в неправильном масштабировании: команда планировала стоимость чатбота (~0,04 USD за взаимодействие), а в прод ушёл мультиагентный оркестр (~1,20 USD за взаимодействие, до 70x на сложных задачах).

A loop that runs without an exit condition isn't autonomous. It's a billing event waiting to happen.

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

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

1. Spec writer — заставляет ответить на три вопроса до первого вызова модели.
2. Circuit breaker — режет цикл, если превышены потолки по ходам или токенам.
3. Ledger — ведёт append-only журнал каждого хода в SQLite.
4. Agent loop — связывает три компонента в единый цикл.
5. Review surface — собирает пятиэлементный фрейм и требует человеческой аттестации перед выдачей результата.

Фаза 1. Определить «готово» до первой строчки кода

Самая дорогая ошибка в разработке агентов — не выбор модели, а начало кодинга до того, как команда может одним предложением описать условие завершения. «Агент проверит сайт» — не подходит. «Агент обходит целевой URL, извлекает все теги <title> и <meta name="description">, помечает отсутствующие или слишком длинные и останавливается» — подходит.

Spec writer интерактивно запрашивает три поля, сохраняет их значения в SQLite и возвращает неизменяемый SpecResult(frozen=True). Полученный session_id связывает спецификацию, строки журнала и итоговый результат в одну трассируемую сессию.

Почему frozen=True:
Спецификация — это обязательство, а не черновик. frozen=True запрещает переприсваивать поля объекта SpecResult, поэтому код цикла не может «подвинуть» условие завершения посреди запуска.

Фаза 2. Принудить «готово» на лету

Circuit breaker задаёт два жёстких потолка: turn_limit — максимальное число обращений к модели, и token_limit — суммарное число токенов за всю сессию. Каждый потолок — «строго больше»: если лимит 5 ходов, пятый ещё разрешён, шестой выбросит исключение.

Ключевое правило: breaker.check() вызывается до запроса к модели, а не после. Постфактум проверка бессмысленна: токены уже сожжены. Исключение, а не код возврата, — чтобы нельзя было промолчать.

Как подобрать лимиты для продакшена

Демонстрационные значения 5 ходов / 15 000 токенов слишком жёсткие для реальных задач. Для продакшена автор предлагает настроить лимиты под свой бюджет; в туториале приведён пример breaker = CircuitBreaker(turn_limit=10, token_limit=50000). Если одна сессия должна стоить не дороже 1 USD, а средний ход — 0,10 USD, получается порядка 10 ходов. Конкретный token_limit выбирается исходя из прайсинга модели и среднего размера контекста: чем длиннее история диалога, тем раньше сработает потолок.

• Стартуйте с жёсткими лимитами и разрешайте рост только по метрикам, не по интуиции.
• Отдельно лимитируйте retry-политику: каждый повторный запрос увеличивает и turn_count, и объём контекста.
• Не смешивайте лимит токенов с лимитом выходных токенов модели; circuit breaker считает сумму input + output.

Фаза 3. Записывать всё, что нельзя подделать

Circuit breaker защищает бюджет. Ledger защищает понимание того, что произошло. Это не лог для отладки, а журнал аудита: каждая строка — один ход, append-only, без обновлений и удалений.

Три решения стоит взять на заметку. Во-первых, вместо исходного текста сохраняется SHA-256 хеш входа: так не утекают персональные данные, а одинаковые входы разных запусков можно сравнивать. Во-вторых, pass_fail хранится как INTEGER (1/0), потому что у SQLite нет булева типа. В-третьих, временная метка — datetime.now(timezone.utc).isoformat(), так как datetime.utcnow() объявлен устаревшим в Python 3.12.

Фаза 4. Цикл, который уважает границы

Agent loop — единственный компонент, который обращается к языковой модели. Всё остальное работает локально: проверка потолков, запись в журнал, оценка условия выхода.

Анатомия одного хода простая и строгая: сначала breaker.check(), потом вызов модели, потом ledger.write(), потом проверка stop_reason. Если модель вернула end_turn — возвращаем результат. Если нет — добавляем сообщение continue и идём на следующий круг.

Этот вариант цикла — минимальный текстовый. Если агент использует инструменты, в Anthropic API stop_reason может быть tool_use: тогда нужно выполнить инструмент, вернуть его результат в messages и только потом решать, продолжать или завершать.

Системный промпт обязательно включает все три поля спецификации, а не только done_looks_like. Модели нужна негативная область — то, что агент делать не должен (what_it_does_not), — не меньше, чем позитивная: иначе она начнёт «добавлять ценность» за рамками задачи.

Фаза 5. Поверхность согласования: цикл бежит к человеку

Circuit breaker и ledger решают технические проблемы, но не отвечают на вопрос: «Соответствует ли результат тому, что обещали?» Именно здесь ошибки проходят в прод: вывод выглядит аккуратным, дашборд зелёный, ревьюер ставит галочку.

Review surface собирает пятиэлементный фрейм из SQLite и требует явной аттестации:

1. Исходное обещание — три поля спецификации.
2. Критерий приёмки — поле done_looks_like как явный бенчмарк.
3. Diff — вход первого хода, выход последнего, число ходов, токены, сработал ли breaker.
4. Доказательства — все строки ledger за сессию.
5. Неразрешённые допущения — строки с breach_reason и failed-ходами.

После согласования ревьюер вызывает attest(). Функция собирает пятиэлементный фрейм в каноническом порядке и считает от него SHA-256 — получается frame_hash. Это аудиторская квитанция: она доказывает, что ревьюер видел именно этот фрейм, а не краткое резюме.

Практический пример: SEO-аудит по расписанию

Автор приводит пример SEO-аудита. SEO-аудит имеет естественный ритм: обход, выявление проблем, исправление, ожидание переиндексации. Запускать агента 24/7 бессмысленно — он будет сжигать токены в паузах между событиями. Честная архитектура — cron-задача, которая запускает цикл по расписанию.

Пример упрощён:
В production-варианте стоит проверять URL (допустимые схемы и хосты) и оборачивать requests.get в try/except requests.RequestException, чтобы агент не падал при недоступности сайта.

Cron-строка выглядит так:

Агент выполняет работу, записывает ходы в ledger, и если circuit breaker сработал — результат уходит на человеческую проверку, а не в прод.

Провайдер-независимость через адаптер

Цикл работает с любым клиентом, удовлетворяющим протоколу LLMClient. По умолчанию используется Anthropic, но через адаптер можно подключить OpenAI, Gemini, Ollama, локальные модели или собственный сервер. В репозитории автора показан иллюстративный пример адаптера для OpenAI. Главное — привести ответ к форме, которую ожидает AgentLoop: usage.input_tokens, usage.output_tokens, content[0].text, stop_reason.

Выводы: дисциплина дороже модели

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

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

Define what done looks like before you start. That's the job, and always has been.

Полный код и 80 тестов с 100% покрытием доступны в репозитории автора оригинала: github.com/dannwaneri/production-safe-agent-loop.

Источник: How to Build a Production-Safe Agent Loop — From Exit Conditions to Audit Trails, freeCodeCamp.

Эта статья — разбор Centicore Group того, где именно ломаются алгоритмы в мониторинге инфраструктуры, почему модели теряют связь с реальностью при изменении данных и как заставить AIOps-платформу работать нормально, а не генерировать новые проблемы.

Что нам обещали и с чем мы остались

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

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

Как машинное обучение в мониторинге работает на самом деле

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

Четыре шага, которые делают все платформы

1. Система собирает сигналы из разных источников. На вход летят метрики из мониторинга, логи приложений, события оркестрации, данные об изменениях после деплоя и служебные уведомления от облака или CI/CD.
2. Система нормализует данные. У разных источников разные поля, названия и уровни детализации, поэтому платформа сначала приводит их к общей схеме: время события, сервис, хост, контейнер, severity, набор тегов.
3. Система группирует похожие уведомления и собирает инцидент. Дальше алгоритмы смотрят на время, теги, топологию сервисов и шаблоны сообщений. Если за пару минут сыпятся десятки однотипных алертов от одного сервиса, платформа схлопывает их в один инцидент.
4. Система ищет связи и формулирует вывод. После группировки движок корреляции пытается понять порядок событий: что сработало раньше, какой сервис тянет за собой остальные, где проходит общая зависимость. И только на этом этапе подключается языковая модель или шаблонный summarizer.

Где заканчивается магия и начинается статистика

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

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

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

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

Почти любая AIOps-платформа хорошо работает на стабильных данных и предсказуемых паттернах нагрузки. Но есть исключения.

Система не знает того, чего не видела

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

Смерть модели от изменения данных

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

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

Языковые модели любят выдумывать

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

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

Где алгоритмы приносят пользу

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

Главное условие: всё это работает только поверх уже организованного мониторинга. Если в системе есть мусор из устаревших правил, алертов без понятного ownership и уведомлений, на которые давно никто не реагирует, то AIOps уверенно группирует и этот мусор. Качество выходного сигнала всегда ограничено качеством входного.

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

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

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

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

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

Как внедрить умный мониторинг и не уволить половину команды

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

1. Сначала привести в порядок обычный мониторинг. Перед запуском AIOps нужно проверить data readiness: теги, источники телеметрии, качество логов, долю дублей и ложных срабатываний. Этот шаг нужен, потому что платформа опирается на те данные, которые уже есть, и плохо работает на разном потоке событий.
2. Начать с режима подсказок, а не с автопилота. Сначала включают read-only сценарий: система группирует события, предлагает причины и подтягивает контекст, но не делает автоматических действий сама. Автоматизацию подключают позже, когда команда уже видит, как платформа ошибается, и понимает, где ей можно доверять.
3. Погонять систему в shadow mode. Новый контур аномалий и корреляции лучше не выкатывать две-четыре недели до замены текущего alerting-процесса. За это время видно, что платформа пропускает и насколько её выводы совпадают с реальными инцидентами.
4. Раскатывать по сервисам, а не по всей инфраструктуре сразу. Практика staged rollout работает лучше большого запуска: команда берёт два-три хронически шумных сервиса, меряет эффект, публикует метрики по false positives и MTTR, а затем расширяет охват.
5. Собирать обратную связь каждую неделю. Сколько алертов схлопнулось корректно, сколько инцидентов она объединила ошибочно, сколько времени сэкономила.
6. Автоматизировать только низкорисковые действия. В пилотах AIOps автоматические runbooks закрывают часть повторяющихся тикетов, но безопасно это работает там, где есть понятные границы, откат и аудит. Сначала подходят простые действия вроде перезапуска зависшего процесса, очистки кэша или повторного запуска джобы, а доступ к чувствительным изменениям в проде лучше оставлять под ручным подтверждением.

Финальная мысль

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

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

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

• AI Engineer — не ML-инженер и не fullstack-разработчик. Это прикладная дисциплина между моделью и пользователем.
• Главная задача — превратить демо в надёжную систему: цикл build-eval-improve (сборка, оценка, улучшение) никогда не заканчивается.
• Четыре ключевых навыка: RAG, evals, агенты и продакшен-деплой.
• OpenAI и другие лидеры уже нанимают целые команды под отдельные подсистемы агентов.
• Самое сложное — не код, а выбор правильных метрик для оценки качества.

Демо собрать легко. Надёжность — работа

Собрать демо с LLM проще простого. Пять минут «вайб-кодинга», чистый промпт, happy path (основной сценарий) — и у вас есть ролик, достойный твита. Но стоит бросить в промпт три нестандартных запроса, и всё рассыпается. Потому что LLM — не интеллект, а предиктор. Вся работа AI Engineer сидит в промежутке между «классно демонстрируется» и «не падает в продакшене».

Если система ненадёжна, она бесполезна. Этот разрыв — полноценная рабочая задача, а не побочная обязанность fullstack-разработчика.

AI Engineer и ML-инженер: в чём разница

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

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

Четыре навыка, которые встречаются в вакансиях

Автор статьи проанализировал вакансии AI Engineer на LinkedIn. Четыре навыка всплывали снова и снова:

• RAG — поиск по векторным базам и контексту
• Evals — оценка качества ответов модели
• Агенты — системы, которые вызывают инструменты и принимают решения
• Продакшен-деплой — запуск в реальную эксплуатацию

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

Цикл сборки, оценки и улучшения

Построить агента легко. SDK позволяют сделать это в пяти строках. Сложное — всё, что после. Оценить, где он плох. Понять, почему. Применить правильную технику к конкретному сбою. Оценить снова.

Этот цикл никогда не заканчивается. Для недетерминированной системы, которая должна быть надёжной, нет статуса «готово». Есть только итерация. Программист оптимизирует детерминированные пути. ML-инженер оптимизирует модель. AI Engineer оптимизирует цикл обратной связи поверх недетерминированной системы, и большая часть результата — в том, что именно измерять.

Почему это целая команда, а не один человек

Если AI Engineer — всего лишь побочная обязанность fullstack-разработчика, посмотрите на вакансии OpenAI. Они нанимают людей не абстрактно, а под конкретные подсистемы: одна команда отвечает за выбор инструментов, другая за human-in-the-loop, третья — за безопасность, а четвёртая — за снижение расхода токенов без потери точности.

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

Самое сложное — выбрать метрики

По мнению автора, самая сложная часть работы — не код. А выбор данных для оценки и метрик, по которым оценивать. Какие метрики дают наиболее точный сигнал? Как их считать? Как эволюционировать, пока система не станет надёжнее?

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

Выводы

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

Агент — это лёгкая часть. Цикл — это работа.

Источник: Frontend Masters — AI Engineer Is a New Role

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

Маскированные диффузионные языковые модели (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?.

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

Активное обучение

Активное обучение (Active Learning) — это подход в машинном обучении, при котором модель участвует в формировании обучающего набора и выбирает, какие объекты стоит отправить на разметку. Как правило, отбираются те примеры, которые дают наибольший прирост качества.

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

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

Цикл активного обучения

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

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

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

Экспертная разметка. Отобранные примеры передаются эксперту для получения корректных меток.

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

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

Основные стратегии выбора данных

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

1. Выбор по неопределенности (Uncertainty Sampling)

«Сфокусируйся на том, где сомневаешься»

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

• Least Confidence – низкая уверенность в выбранном классе;
• Margin Sampling – маленькая разница между двумя наиболее вероятными классами;
• Entropy Sampling – высокая неопределенность по всем классам.

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

2. Выбор по разнообразию (Diversity Sampling)

«Не зацикливайся — смотри шире»

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

3. Выбор по несогласию моделей (Query by Committee)

«Если модели “спорят” — пример информативный»

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

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

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

Перейдем от теории к практике.

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

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

Методология эксперимента

Эксперимент воспроизводит реальный сценарий работы эксперта с системой активного обучения. В качестве базового классификатора мы выбрали CatBoost. На начальном этапе использовался минимальный объем данных — 15 случайно размеченных фрагментов.

Далее выполнялся цикл активного обучения, который повторялся 50 раз:

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

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

Результаты

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

На графиках по оси X — количество данных для разметки, по оси Y — значение F1-score.

Сущность: арбитражная оговорка

Для достижения F1 ≈ 0.88 стратегия Entropy потребовала около 75 размеченных фрагментов, тогда как случайный отбор достиг сопоставимого уровня только после 215.

Таким образом, требуемый объем разметки снижается примерно в 2–3 раза.

Сущность: передача прав по договору

Преимущество активного обучения проявляется начиная с 275 размеченных примеров.

Для достижения F1 ≈ 0.8 стратегия Entropy потребовала около 415 размеченных примеров, Least Confidence — 435, Margin — 495, тогда как случайный отбор достиг сопоставимого уровня только после 955. То есть для достижения сопоставимого качества требуется более чем в 2 раза больше размеченных данных по сравнению со стратегиями активного обучения.

Сущность: сроки исполнения обязательств

Здесь преимущество активного обучения проявляется уже на ранних итерациях. Стратегии Entropy и Least Confidence быстрее достигают высоких значений F1 по сравнению со случайным отбором.

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

Сущность: ретроактивная оговорка

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

Но преимущество активного обучения становится заметным на промежуточных итерациях (примерно в диапазоне 150–300 размеченных примеров), где стратегии Entropy и Least Confidence показывают более стабильный рост по сравнению со случайным отбором.

Заключение

Результаты эксперимента подтвердили, что активное обучение существенно повышает эффективность разметки в задачах выделения сущностей. Все рассмотренные стратегии (Least Confidence, Margin, Entropy) демонстрируют устойчивое преимущество над случайным отбором: сопоставимое качество достигается при значительно меньшем объеме размеченных данных.

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

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

Это не рутинное объявление об увеличении кластера. Если самый закалённый разработческой инфраструктуры игрок планеты говорит «в 10 раз — уже мало», значит фундаментальные предположения о том, как производится софт, сместились быстрее, чем GitHub успел заложить в собственные планы. Все, кто строит ниже по течению — на тех же предположениях, — попадают под тот же сдвиг.

Сигнал. CTO GitHub Влад Фёдоров: октябрьский план мощностей в 10 раз к 2026 году устарел уже к февралю — нужен план в 30 раз из-за роста AI-агентного кода.

Bottleneck не в железе. CI справится с любым потоком; не справляется валидация — очередь ревью, стенды staging, интеграционные тесты.

Стоимость поиска бага растёт по стадиям. Внутри цикла разработки — почти ноль; в CI — полный цикл сборки; в staging — деплой и очередь к стенду; в production — инцидент, откат и отдельный revert-PR.

Структурный ответ. Сдвиг валидации в inner-loop, где агент сам прогоняет изменение против реальной системы до создания PR.

Что делать командам. Отделить «compile-clean» от «correct», встроить эфемерные окружения в inner-loop агента, не наращивать слепо мощности CI.

Почему GitHub переписал план мощностей

В апреле 2026 года у GitHub было два крупных инцидента — внутренний апдейт об их разборе содержал ключевой абзац:

Мы начали в октябре 2025 года план по 10-кратному наращиванию мощностей GitHub с целью существенно улучшить надёжность и failover. К февралю 2026 стало ясно, что нужно проектировать под будущее, требующее 30-кратного объёма от текущего.

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

Объём становится проблемой, когда не конвертируется в throughput

30-кратный рост производства кода в идеальном мире давал бы 30-кратный рост поставленных фич. На практике SDLC никогда не превращал объём кода в релизную функциональность 1:1. Конверсия теряется на одном и том же этапе — валидация.

До прихода агентов это уже было больно: тест-сьюты по часу, постоянно перегруженные стенды staging, интеграционные баги, всплывающие на release candidate, очереди review, в которых сидят единственные люди, способные определить, безопасно ли изменение. Валидация — самая медленная, самая зависящая от человека и самая ошибкоёмкая часть цикла, и она встроена между «код написан» и «код задеплоен».

В cloud-native архитектурах эта проблема обостряется. Современное приложение — это граф сервисов, каждый со своим состоянием, зависимостями, темпом релизов. Изменение одного сервиса прокатывается по половине соседних, а ломается обычно то, что не видно в исходниках: contract drift (несовпадение договорённостей между сервисами), race conditions, edge-кейсы мульти-тенантности, поведение под нагрузкой.

Где ловить баг — там и платить

Стоимость найденного бага компаундится в зависимости от стадии:

• Inner loop (агент или разработчик ещё итерирует) — почти ноль.
• CI — полный цикл сборки.
• Staging — деплой + слот в очереди + время валидаторов.
• Production — инцидент, rollback, revert PR, который сам идёт через тот же pipeline.

При человеческой скорости разработки SDLC поглощал часть этой неэффективности — объём ограничивался числом инженеров. На скорости и масштабе агентов поглощать перестаёт: задержка превращается в постоянно растущий backlog. Поэтому ответ — не «больше мощностей CI, больше стендов staging, больше ревьюеров». Это тактический отклик на структурный сдвиг.

Замкнуть петлю — там, где код пишется

Структурный ответ — сдвинуть валидацию максимально влево, прямо в inner loop, где агент порождает код. Сегодня агенты для кодинга — это половина рабочей системы: они пишут код на беспрецедентной скорости, но не могут самостоятельно проверить, правильно ли он ведёт себя в распределённой системе. Compile-clean ≠ correct. Unit-тесты проверяют ровно то, что они скоупят.

Поэтому агент делает единственное, что может — объявляет изменение готовым и пушит вниз по pipeline, где работа по «а оно вообще пашет?» падает на ревьюера, интеграционные тесты, деплой на staging или инцидент в production. И вся компаундящаяся стоимость валидации включается на полную.

Замкнуть петлю — значит дать агенту способ автономно прогнать кандидатное изменение против реальной системы: реальные сервисы, реальные зависимости, реальные паттерны трафика. Быстро и дёшево настолько, чтобы агент мог итерировать, наблюдать, что сломалось, и пробовать ещё раз — без человека, без конкуренции за общий стенд staging, на скорости и масштабе агентов.

Почему не справляются текущие подходы

• Mocks — подделывают поведение зависимостей и проходят мимо реальных.
• Unit-тесты — покрывают индивидуальные функции, не интеграционную поверхность.
• Зелёный CI — говорит, что протестированное прошло. Это не равно «изменение корректно».

Чтобы петля действительно замкнулась, агенту нужно прогнать кандидата против настоящего состояния системы, а не модельного. И это требует инфраструктуры, которой массово в командах ещё нет: эпемерные окружения, изолированные на уровне one-PR-one-environment, с реальными зависимостями.

Чек-лист для тимлидов

1. Замерить текущую валидационную «вилку»: время от commit до зелёного staging для среднего PR. Если оно растёт — bottleneck уже здесь.
2. Посчитать долю PR-ов с rollback или revert. Если rollback-rate растёт месяц к месяцу — петля у агентов открытая.
3. Запустить пилот с ephemeral environments на одном из сервисов с самым большим интеграционные накладные расходы. Сравнить за 4 недели: процент PR-ов, прошедших валидацию с первого раза.
4. Не наращивать мощности CI «в ширину» как первый ответ. Это лечит симптом, не причину.
5. Дать агенту сигналы во время выполнения (не только compile + unit). Без них следующий шаг качества кода невозможен.

Выводы

Объём кода, генерируемого AI-агентами, растёт быстрее, чем планировали даже в GitHub. Стратегический вопрос для каждой инженерной организации сейчас простой: ваши агенты работают в замкнутой петле или открытой? Замкнутая — мультипликатор на throughput команды. Открытая — мультипликатор на те самые валидационные bottleneck-и, которые и так были самым узким местом.

Похожий тренд мы недавно разбирали в материале про tokenmaxxing: AI-ассистенты дают двукратную выработку кода ценой десятикратных затрат токенов и роста code churn на 861%. Природа проблемы одна: код производится массой, а инфраструктура к этому не готова.

Источник: The agent code explosion is here. We need to rethink our pipelines, fast — The New Stack.

Атака не теоретическая. Первая практическая демонстрация вышла в 2004 году; в 2005 поверх неё надстроили языковые модели. В 2023 исследовательская группа из университетов Surrey, Durham и Royal Holloway показала 95%+ top-1 точности (то есть угадывания клавиши с первой попытки) на MacBook Pro — по записи со смартфона на расстоянии 17 см. Изменилось одно — теперь обучить такую модель может любой разработчик за полдня на собственном ноутбуке.

Реальная угроза. Не подложенный микрофон в офисе, а Zoom, Teams, Meet, Discord, голосовые сообщения, заражённые браузерные вкладки, ноутбук в кафе. Везде, где вы сами включили микрофон.

Точность. Мини-CNN на 250 тыс. параметров: top-1 82–88%, top-3 95–97% на 35 классах (буквы + знаки) при 3000 семплов на пару пользователь/клавиатура.

Пароли особенно уязвимы. Языковая модель не помогает (пароли не из словаря), зато сужается перебор: top-3 предсказаний на символ → 3⁸ = 6 561 кандидат для 8-символьного пароля. Online brute force против большинства сервисов.

Что работает в защите. Мьют микрофона перед вводом пароля + менеджер паролей (auto-fill полностью убирает акустический сигнал) + аппаратные ключи (FIDO2/YubiKey).

Что НЕ работает. «Печатать тише», случайный ритм набора, программные шумодавы (RNNoise, Krisp). Шумодавы оптимизированы под речь — клик клавиши проходит почти без потерь.

Что именно слышит микрофон

Когда вы нажимаете клавишу A, микрофон ловит три события: push (механический клик дна хода клавиши, ~5–10 мс, широкий спектр), release (возврат купола вверх, ниже по амплитуде, через 10–30 мс) и — главное — резонанс корпуса. Удар по клавише заставляет шасси ноутбука кратко звенеть на собственных частотах, а разные клавиши находятся на разных расстояниях от резонансных узлов и возбуждают чуть разные моды.

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

Релевантная полоса частот — 400 Гц … 12 кГц. Ниже — комнатный шум и кондиционер; выше — тишина и собственный шум микрофона. Стандартного 44,1 кГц моно более чем достаточно: фирменный микрофон не нужен.

Что собирает атакующий

Авторы pwn.guide публикуют полный пайплайн на Python — около 200 строк кода, всё через pip-зависимости (numpy, scipy, librosa, soundfile, sounddevice, pynput, torch). Шаги:

1. Сбор: 3 000 размеченных нажатий (≈15 минут естественного набора). Скрипт collect.py параллельно ведёт лог нажатий через pynput и пишет аудио. Используется time.perf_counter(), чтобы NTP-коррекция не сбила метки.
2. Нарезка: аудио рубится на 100-мс окна вокруг каждого нажатия. Между событием в ОС и пиком в аудио есть 5–40 мс задержки — её надо выровнять поиском пика по огибающей. Без этого точность падает с 85% до 60%.
3. Фичи: для каждого окна — log-mel спектрограмма (64 mel-бина, fmin=400, fmax=12 000). Тензор (64 × 35), один клип ≈ 9 КБ.
4. Модель: компактная CNN на ~250 тыс. параметров — четыре свёрточных блока + AdaptiveAvgPool. На GPU тренируется за 5 минут, на CPU — за 30.
5. Инференс: предсказание для 100-мс окна занимает доли миллисекунды.

Цифры, ради которых это страшно

На самостоятельно собранном датасете из ~3 000 нажатий и 35 классов:

• Top-1 точность: 82–88%, в зависимости от шума при сборе данных.
• Top-3 точность: 95–97% — почти всегда правильная клавиша входит в тройку лучших предсказаний.
• Распределение по классам неровное. Space, Enter, Backspace — около 99% (механически отличаются от обычных клавиш). Соседние буквы основного ряда (F/G, J/K) — иногда 60% top-1.

85% точности на уровне символов звучит не страшно — в предложении будет 2–3 ошибки. Но если прогнать top-5 предсказаний через beam search с словарём частотности слов, восстановление связного текста на естественном языке выходит на 95%+ точности на уровне слов. Это исследовали ещё Zhuang и соавторы в 2005 году; современные char-LM делают этот шаг тривиальным.

Почему пароли беззащитнее обычного текста

Языковая модель — главное усиление атаки на обычный текст — на паролях не работает: их специально проектируют непохожими на слова. Зато у атакующего другое преимущество: пространство поиска ограничено. Если модель выдаёт top-3 предсказания на символ с 96% точностью, у 8-символьного пароля максимум 3⁸ = 6 561 кандидат для перебора. Это в зоне online brute force против большинства сервисов и тривиально оффлайн против любого слитого хеша.

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

Что реально защищает — и что нет

Авторы прямо сортируют защиты по эффективности.

Работает:

1. Мьют микрофона перед вводом любого секрета. Единственная полностью надёжная защита и стоит ноль.
2. Менеджер паролей с auto-fill. Нет нажатий — нет акустического сигнала. Самая большая практическая мера именно против атаки на пароли.
3. Аппаратные ключи (FIDO2/WebAuthn, YubiKey). Один тап = один акустический след, восстанавливать нечего.
4. Внешняя клавиатура подальше от микрофона. Механика не безопаснее — она громче. Но USB-клавиатура на дальнем краю стола, на отдельной поверхности, материально снижает SNR.
5. Акустическое демпфирование. Толстый коврик или сложенное полотенце под ноутбуком — снижение резонанса корпуса на 3–6 дБ. Помогает, но не панацея.

Не работает (вопреки ожиданиям):

• «Печатать тише». Амплитуда падает, спектральный отпечаток сохраняется. Минус 5% точности.
• Случайный ритм набора. Атака работает по отдельным нажатиям, не учитывает межударные интервалы.
• Программные шумодавы (RNNoise, Krisp). Тюнятся под сохранение речи и удаление широкополосного шума. Клавишные транзиенты выглядят как короткие речевые звуки и проходят насквозь — некоторые шумодавы даже «чистят» нажатия от окружающего фона.
• Белый шум на фоне. Современные модели учатся с шумовой аугментацией — постоянный фон сдвигает точность на копейки. Прерывистые звуки (музыка с резкими пиками) мешают сильнее, но и для оператора некомфортнее.

Чек-лист «что сделать сегодня»

1. Проверить, что у вас стоит password manager с auto-fill (1Password, Bitwarden, KeePassXC, Яндекс.Ключ — что вам ближе) и им активно пользуются для всех проводных логинов.
2. Купить или подключить аппаратный ключ для критичных аккаунтов (root в облаках, GitHub, банк-клиент). YubiKey 5 серии или Token2 — общедоступно в РФ.
3. Поставить хоткей на «mute mic» в Zoom/Teams/Discord, чтобы рефлекторно нажимать перед вводом любого секрета.
4. Если работаете из публичного пространства — внешняя клавиатура подальше от ноутбука, либо bluetooth-наушники с шумодавом + далеко отнесённый телефон вместо встроенного микрофона.
5. Команды разработки: добавить «mute при работе с секретами» в общий гайд по безопасности, а аппаратные ключи — в onboarding для новых сотрудников.

Выводы

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

Хорошая новость в том, что защита дёшева и не требует новых технологий — менеджер паролей (про бесплатный open-source Bitwarden у нас уже выходил материал) плюс мьют микрофона закрывают практически весь сценарий. Аппаратные ключи (см. обзор YubiKey 5) закрывают остаток.

Источник: Acoustic Keystroke Recovery — Reconstructing Typed Text from a Laptop Microphone (pwn.guide).

MTP (Multi Token Prediction) — техника, предложенная исследователями Meta в апреле 2024: рядом с основной языковой моделью обучаются дополнительные головы, предсказывающие следующие 1–3 токена напрямую. Широкое применение в production-LLM пришло с DeepSeek-V3, а Qwen3.6 поддерживает архитектуру из коробки. До PR #22673 при экспорте в GGUF эти головы терялись. Теперь они подтягиваются как отдельная под-модель внутри того же файла и работают как драфтер для спекулятивного декодинга.

Что добавили. Поддержку Multi Token Prediction в llama.cpp — флаг --spec-type mtp запускает спекулятивный декодинг через MTP-головы модели.

Скорость. Qwen3.6 27B Q8_0 — 16–22 ток/с против 7 ток/с baseline. Ускорение в 2,2–2,4 раза в зависимости от типа задачи.

Accept rate. При --spec-draft-n-max 3 — 72,2% угаданных токенов в среднем; при n-max 2 — 82,6% (короче драфт, выше попадание).

Совместимость. Подтверждены Qwen3.6 27B и Qwen3.6 35BA3B; по заявлению автора, режим работает на любой модели с MTP-головами.

Где взять. Готовый GGUF с MTP-головой для Qwen3.6 27B автор приложил к PR — отдельный файл скачивать не нужно, всё в одном.

Что такое Multi Token Prediction

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

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

MTP идёт дальше: вместо двух разных моделей (большая + черновая) одна и та же модель обучается предсказывать сразу несколько следующих токенов через дополнительные параллельные головы. Концепция вышла из статьи Meta «Better & Faster Large Language Models via Multi-token Prediction» (Gloeckle и соавторы, апрель 2024), массовое применение в production-LLM пришло с DeepSeek-V3. Главное преимущество — не нужно держать в памяти отдельную draft-модель.

Бенчмарки am17an на Qwen3.6 27B

Автор PR прогнал девять синтетических задач — генерация Python-кода, C++-кода, объяснение концепций, суммаризация, факто-QA, перевод, креативные тексты, пошаговая математика и длинный код-ревью. Замеры с одной моделью и одним GPU (см. gist с бенчмарком):

• Baseline без спекулятивного декодинга: 7,0–7,7 ток/с, агрегат 201 секунда на 1404 токена.
• MTP, n-max 3 (3 драфт-токена за шаг): 13,9–21,6 ток/с, accept rate 72,2%, 83,8 с — ускорение в 2,4 раза.
• MTP, n-max 2: 15,2–18,2 ток/с, accept rate 82,6%, 90,4 с — короче драфт, но выше доля принятых.
• Draft-модель Qwen3.5 0.8B, n-max 16: для сравнения с классическим speculative decoding — 12,7–47,7 ток/с, accept rate 67,7%, 81,4 с.

На фактической QA («ответь точно») draft-модель догоняет MTP по скорости — accept rate подскакивает до 99,4%, — но на креативных и аналитических задачах MTP стабильнее: меньше провалов на нестандартных формулировках.

Как запустить

После сборки llama.cpp из ветки PR запуск сервера с MTP выглядит так:

Ключевой флаг — --spec-type mtp. --spec-draft-n-max 3 задаёт длину драфта; для большинства моделей оптимум — 2 или 3.

Готовый GGUF с MTP-головами для Qwen3.6 27B автор приложил к PR. Конвертация других MTP-моделей идёт через обновлённый convert_hf_to_gguf.py из той же ветки.

MTP против обычного спекулятивного декодинга

Классическая схема speculative decoding в llama.cpp требует двух GGUF-файлов: основной модели и небольшой черновой (например, Qwen3.5 0.8B как драфт для Qwen3.6 27B). Это удваивает требования к памяти и усложняет деплой — нужно следить, чтобы токенизаторы у обеих моделей совпадали. MTP убирает оба ограничения: дополнительные головы лежат в том же GGUF-файле, что и основная модель, токенизация заведомо одна. По бенчмаркам автора MTP-режим стабильнее по задержке, а draft-модель может выстрелить выше пика на специфичных задачах вроде QA, где её предсказания проще.

В обсуждении PR мейнтейнер ngxson отметил, что предыдущие попытки добавить MTP опирались на постоянное копирование данных между host и device — основной автор am17an обошёл это через отдельный hook для распространения скрытых признаков между ubatch-ами.

Свежий старт лучше моего WIP #18886 — другие попытки добавить MTP сильно полагались на копирование данных host ↔ device. Похоже, у тебя это решено?

Чек-лист для тех, кто хочет попробовать

1. Склонировать репозиторий llama.cpp и переключиться на ветку PR #22673 (или дождаться мерджа в master).
2. Собрать с CUDA или Metal-бэкендом — режимы для CPU работают, но без значимого ускорения.
3. Скачать GGUF с MTP-головой: qwen3.6-q8_0-mtp.gguf, ссылка приложена в PR.
4. Запустить llama-server с флагами --spec-type mtp --spec-draft-n-max 3.
5. Сравнить токены в секунду с baseline (без флагов спекулятивного декодинга) — на Qwen3.6 ожидается рост в 2–2,5 раза.

Выводы

После мерджа PR локальный запуск Qwen3.6 27B приближается по задержке к облачным API: разница в ответе на коде и аналитике сокращается с десятков секунд до считанных. Для MoE-вариантов вроде Qwen3.6 35BA3B экономия видеопамяти от MTP особенно полезна — ту же скорость теперь можно получить на одной серверной карте, не запуская параллельно отдельную draft-модель.

Если пишете инструменты вокруг локальных LLM — обновитесь после мерджа PR в master. Тем, кто использует облачные модели только из-за скорости, имеет смысл проверить, не закрывает ли Qwen3.6 + MTP их сценарий. У нас уже выходил отдельный гайд по запуску LLM локально через Ollama — он пригодится, если вы только подбираете инструменты.

Источники: PR #22673 в llama.cpp, бенчмарки am17an.

Опыт описан в блоге Diabettech 25 апреля 2026 года. Стрит использует ИИ как помощника в подсчёте углеводов — вводных данных для расчёта инсулиновой дозы — и захотел понять, насколько модели вообще способны давать стабильный ответ на одном и том же фото. По стандартам клинических исследований воспроизводимость ответа — базовое требование к измерительному инструменту.

26 904 запроса к четырём моделям (GPT-5.4, Claude Sonnet 4.6, Gemini 2.5 Pro, Gemini 3.1 Pro Preview) на тринадцати фотографиях.

Лучшая модель — Claude Sonnet 4.6 с коэффициентом вариации 2,4%. У Gemini 2.5 Pro — 11,0% (хуже всех).

Худший случай — Gemini 2.5 Pro на паэлье: разброс 55–484 г углеводов в одних и тех же запросах. На инсулин это коридор 5,5–48,4 единицы — разница в 42,9 единицы между двумя ответами одной модели.

«Точно неправильно»: на сэндвиче с сыром три модели сошлись около 28 г, реальное значение — 40 г. Конвергенция на ошибке опаснее, чем разброс.

Confidence-скор почти не коррелирует с точностью: модели уверенно врут.

Позиция DTN-UK: общедоступные LLM нельзя использовать как автономных советников по дозе инсулина.

Что и как тестировал Стрит

Автор взял 13 фотографий блюд с заранее известным содержанием углеводов (часть — лабораторно выверенные значения, часть — упаковка с пищевой ценностью). Каждое фото отправлялось четырём моделям не менее 500 раз через API с одним и тем же промптом, без памяти и контекста между запросами.

Тестируемые модели:

• GPT-5.4 от OpenAI — флагман на момент тестов
• Claude Sonnet 4.6 от Anthropic
• Gemini 2.5 Pro от Google — стабильная версия
• Gemini 3.1 Pro Preview от Google — превью новой версии

Промпт просил модель оценить углеводы в блюде и вернуть число грамм плюс уровень уверенности от 0 до 1. Температура — минимальная для каждого API (lowest randomness setting), как рекомендуется для численных задач.

Недетерминизм LLM в цифрах: коэффициент вариации

Стрит измеряет стабильность через коэффициент вариации (CV) — отношение стандартного отклонения к среднему. Чем меньше CV, тем стабильнее модель отвечает на одну и ту же картинку.

Claude держит разброс в пределах нескольких процентов; у Gemini — двузначный CV. На отдельных блюдах CV у Gemini регулярно превышает 10–20%.

Паэлья: 55–484 грамма на одной фотографии

Самый яркий пример из эксперимента. На фотографии паэльи Gemini 2.5 Pro на 500+ запросов выдал результаты в диапазоне от 55 до 484 г углеводов на одном и том же фото — без какого-либо повода для разброса в самих данных.

Если перевести в дозу инсулина по типичному соотношению 1 единица на 10 г углеводов — получается коридор от 5,5 до 48,4 единиц на одно и то же блюдо. Разброс — 42,9 единицы. Для среднего взрослого с диабетом 1 типа 30+ лишних единиц — гипогликемия с риском комы.

Confidence не спасает

Логичное решение — фильтровать ответы по уверенности модели: брать только те, где confidence высокий. Стрит проверил гипотезу. Корреляция confidence с точностью у моделей отрицательная — коэффициент r от −0,01 до −0,17. Уверенность модели не просто бесполезна, она антикоррелирует с правильностью: чем увереннее модель, тем выше шанс, что она ошибается.

Модели возвращают «уверенно неправильные» ответы так же часто, как «уверенно правильные». На сэндвиче с сыром три из четырёх моделей сошлись на ответе около 28 г углеводов с высоким confidence — реальное значение по упаковке было 40 г. Модели согласовались на ошибке и были в ней уверены.

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

Почему это важно за пределами медицины

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

Где это аукнется

• OCR-замена «через ИИ»: модель распознаёт сумму в чеке/инвойсе. Сегодня 1500, завтра 1505 на той же фотке.
• Извлечение полей из документов: дата, ИНН, артикул. Каждый прогон может дать другой результат.
• Скоринг и оценка: модель оценивает риск/уверенность/качество ответа — числа гуляют между запросами.
• Подсчёт объектов на изображении: люди в очереди, машины на парковке, дефекты на детали.
• Ассистенты для измерений: размеры на фото, время по видео, дозировки в рецептах.

Что делать в продукте

1. Не доверять одному вызову. Делать 3–5 запросов и смотреть распределение, а не точку.
2. Считать CV локально. Если CV между прогонами выше порога — возвращать «не уверен», а не среднее.
3. Игнорировать confidence-поле. На простых задачах оно почти не несёт информации.
4. Спрашивать, что модель «видит». Стрит советует отдельным запросом получить описание фото — это ловит грубые ошибки распознавания (паэлья vs ризотто).
5. Не использовать LLM как автономного советника в задачах с асимметрией риска (медицина, финансы, безопасность). LLM — рекомендатель, решение принимает человек.

Кого выбрать, если уж приходится

Если в продукте уже есть единичный вызов LLM на численную задачу и нет возможности сделать ансамбль — по данным Стрита, единственный приемлемый вариант — Claude Sonnet 4.6. Его CV в 4–5 раз ниже, чем у любой из других трёх моделей.

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

Позиция диабетического сообщества

Британская DTN-UK (Diabetes Technology Network UK, рабочая группа Association of British Clinical Diabetologists) — профессиональная ассоциация эндокринологов и диабет-инженеров — выпустила позицию, что общедоступные LLM (ChatGPT, Claude, Gemini, Copilot) не должны использоваться как автономные советники по дозе инсулина. Использовать их можно только как один из инструментов под контролем врача и при понимании ограничений.

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

Главный вывод

Эксперимент Стрита — первый известный нам случай, когда недетерминизм LLM на простой задаче измерен в публичном сетапе с большим N. Цифры неудобные: даже у Claude Sonnet 4.6 — лучшей модели в тесте — CV в 2,4% означает, что при нормальном распределении один из тридцати ответов будет за пределами одного стандартного отклонения от среднего. В задачах с асимметрией риска (медицина, финансы, инфраструктура) этого хватает, чтобы инструмент был непригоден как автономный.

Для разработки это не аргумент против ИИ — это аргумент за ансамблирование, измерение CV и явное признание того, что LLM возвращает распределение, а не точку. Промпт «верни число» и одиночный вызов API — это иллюзия точечного ответа поверх случайной выборки.

Ссылка на полное исследование с графиками и сырыми данными — блог Diabettech. Если у вас есть продакшн-фича, в которой LLM возвращает число, — повторите методику на десяти типичных входах за один вечер. Скорее всего, вы найдёте свой эквивалент паэльи.

• Ollama — бесплатный open-source инструмент (MIT) для локального запуска LLM. Доступен из РФ без VPN
• Минимальные требования: 8 ГБ RAM (16 ГБ для крупных моделей), 5–16 ГБ места под модели, GPU не обязателен
• Стартовая модель — llama3.2:latest (3,2B параметров, 2 ГБ на диск)
• Команда ollama launch подключает локальную модель к Claude Code, Codex, Droid и OpenCode без ручной настройки
• Для кодинг-задач рекомендованы qwen3-coder, gpt-oss:20b и gpt-oss:120b
• Промпты не уходят в облако — подходит для коммерческого кода и чувствительных данных

Что понадобится

Чтобы повторить шаги, нужно несколько вещей со стороны железа и софта:

• macOS 14 Sonoma или новее, Windows 10+ или относительно свежий Linux-дистрибутив
• Минимум 8 ГБ RAM, для крупных моделей — 16 ГБ и больше
• 5–16 ГБ свободного места под модели
• Базовые навыки работы в терминале: открыть, ввести команду, прочитать вывод

Python для гайда не нужен — всё через CLI. Если позже захотите программно вызывать модели из Python-кода, у Real Python есть отдельный туториал How to Integrate Local LLMs With Ollama and Python.

Шаг 1: установить Ollama и скачать первую модель

Установка одной командой. На Windows откройте PowerShell и выполните:

На Linux и macOS — одна строка в терминале:

Через минуту Ollama установлена. На некоторых Linux-дистрибутивах может не хватать curl и библиотеки zstd — на Debian/Ubuntu ставятся одной командой:

Альтернатива — отдельные инсталляторы для Windows и macOS на странице ollama.com/download. У macOS и Windows также есть GUI-приложение, но в этом гайде разбираем только CLI — он одинаков на всех платформах. Описание GUI-версии — в блоге Ollama.

Проверить, что CLI установлен:

Сервис Ollama должен сам подняться в фоне на порту 11434. Если в ответ на команду выше появилось предупреждение — поднимите вручную:

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

Скачиваем llama3.2

Стартовая модель — llama3.2:latest: 3,2 миллиарда параметров, около 2 ГБ на диске. Это разумный баланс между качеством ответов и требованиями к железу:

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

Полный каталог моделей — на ollama.com/models. Если RAM мало, берите более лёгкую llama3.2:1b — всего 1,3 ГБ. Для мощного железа есть llama3.3:70b с заметно более сильными reasoning-способностями.

Посмотреть характеристики модели:

Что важно из вывода: модель — 3,2 миллиарда параметров, контекст — 131 072 токена (это сколько текста модель «видит» за один разговор). Поддерживает completion (ответы на промпты) и tools — то есть может работать как агент с инструментами.

Если решили освободить место или больше не нужна конкретная модель — удалите её с диска:

Команда ollama --help покажет полный список опций CLI. Готово — можно общаться с локальной моделью.

Шаг 2: чат с локальной моделью

Чтобы запустить интерактивный чат, в терминале:

Когда модель загрузится, появится >>> — режим чата. Заглушка «Send a message (/? for help)» подскажет, что делать дальше. Введите первый промпт:

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

Контекст разговора держится в пределах сессии — можете задавать follow-up без повторения предыстории:

В вопросе нет слова GIL, но модель помнит контекст. Чтобы убедиться, что всё работает офлайн, отключите интернет и отправьте ещё один промпт. Ответ всё равно придёт — никакие токены никуда не уходят.

В CLI есть слеш-команды для управления сессией. Команда /? покажет полный список:

Полезные команды — попробуйте сами. Многострочные промпты — через тройные кавычки ("""). Чтобы сменить модель, выйдите из сессии командой /bye и запустите ollama run <другая-модель>.

Шаг 3: подключить Ollama к Claude Code и другим ИИ-ассистентам

Самое интересное. Команда ollama launch цепляет локальную модель как бэкенд для популярных ИИ-инструментов кодинга — без ручной настройки конфигов.

Чтобы команда ollama launch работала, нужна Ollama версии 0.15+. Проверить версию: ollama -v.

Перед запуском убедитесь, что у вас уже установлен сам Claude Code (через официальный гайд Anthropic — npm install -g @anthropic-ai/claude-code). Команда ollama launch сама не ставит Claude Code, она только переключает его на локальный backend. Запускаем:

Команда настраивает Claude Code на локальный API на localhost:11434, совместимый с Anthropic API, и сразу запускает Claude Code в текущем терминале — вы окажетесь в его интерактивной сессии. Чтобы убедиться, что бэкенд именно локальный — отключите интернет и задайте любой вопрос: ответ всё равно придёт. Чтобы только настроить интеграцию, не запуская инструмент сразу — добавьте флаг --config:

Перед запуском Claude Code имеет смысл скачать модель, заточенную под код. Рекомендованные локальные модели для генерации кода и агентских воркфлоу:

• qwen3-coder — оптимизирована под кодогенерацию. Размеры: 19 ГБ (вариант 30b, для машин с ≥ 24 ГБ RAM) или 290 ГБ (вариант 480b, для серверов). Контекст: 256K
• gpt-oss:20b — добротный среднеуровневый вариант. Размер: 14 ГБ. Контекст: 128K
• gpt-oss:120b — высокое качество, требует серьёзного железа. Размер: 65 ГБ. Контекст: 128K

Кодинг-инструменты и агентские задачи требуют большого контекстного окна — для Claude Code рекомендовано минимум 64K токенов.

Эти модели существенно тяжелее llama3.2. Перед скачиванием убедитесь, что у системы хватит RAM и места на диске.

Чтобы продолжить туториал на минимальном железе, скачайте самую лёгкую из coder-моделей:

После скачивания запускаем Claude Code в режиме конфигурации:

Появится список установленных и рекомендованных моделей. Стрелками вверх-вниз — выбор, Enter — подтверждение. С этого момента Claude Code будет использовать вашу локальную модель вместо облачного API. Ответы генерируются только на вашем железе, код и промпты не покидают машину.

Ollama сейчас поддерживает не только Claude Code: работает с Codex, Droid и OpenCode. Команда та же — ollama launch <инструмент>.

Поиграйтесь с Claude Code на локальной модели и сравните результаты. Качество ответов сильно зависит от модели: gpt-oss:120b приближается к облачным моделям по качеству, но может тормозить без мощного железа. Маленькие модели жертвуют качеством ради скорости и скромных требований к ресурсам.

От редакции: что важно для российских пользователей

Несколько практических замечаний от Tproger, которых нет в оригинале Real Python:

• Доступность. На момент апреля 2026 года ollama.com и репозиторий моделей ollama.com/models доступны из РФ без VPN. Модели хостятся на CDN, который пока не блокирован. Если корпоративная сеть всё-таки фильтрует — см. следующий пункт.
• Скачивание моделей. Если корпоративная сеть всё-таки закрыла ollama.com, можно подтянуть модели напрямую с Hugging Face в формате GGUF и подключить через ollama create с собственным Modelfile
• Альтернативы для тех, у кого мало RAM. На 8 ГБ комфортно работают llama3.2:1b, qwen2.5:3b и phi-4-mini. Для русского языка из коробки лучше всего себя показывает qwen2.5 и gemma3
• GPU. Если есть видеокарта NVIDIA с CUDA (технология параллельных вычислений NVIDIA) или AMD с ROCm (open-source аналог CUDA для AMD) — Ollama сама её подхватит. Важно: ROCm работает не на всех картах AMD, в основном на свежих RX 6000/7000 и Radeon Pro/Instinct. Apple Silicon (M1+) использует Metal (графический API Apple) автоматически. На голом CPU тоже работает, но в 5–10 раз медленнее.
• Системный сервис. Если хочется, чтобы Ollama стартовала с системой и слушала порт постоянно — на Linux это уже systemd-сервис. Проверить статус: systemctl status ollama; включить автозапуск: systemctl enable --now ollama. На macOS работает через launchd.

Куда двигаться дальше

Ollama настроена — есть несколько направлений для следующих шагов:

• Подключение из Python. Программно вызывать модели через REST API или официальный SDK ollama-python — туториал How to Integrate Local LLMs With Ollama and Python
• Другие модели. На ollama.com/models есть модели под конкретные задачи: vision (llava, llama3.2-vision), embeddings (nomic-embed-text), domain-specific (medllama2, deepseek-coder)
• Тонкая настройка. Через Modelfile можно задать свой системный промпт, температуру, top-p, контекстное окно — превратить общую модель в специализированного ассистента под задачи команды

Выводы

Ollama закрывает три пробела разом: даёт ИИ-ассистента без подписок, делает работу с кодом приватной (промпты не уходят в облако) и снимает зависимость от иностранных платёжных систем — а это уже само по себе аргумент для российских разработчиков. CLI-интерфейс и команда ollama launch делают барьер входа минимальным: от curl ... | sh до Claude Code на локальной модели — минут пятнадцать, считая скачивание.

Большие языковые модели традиционно требуют дорогих API-подписок и постоянного интернета. Ollama снимает оба требования.

Попробуйте запустить любимый промпт на локальной модели и сравните ответ с облачной версией — разница в скорости и качестве зависит от железа сильнее, чем кажется. Свои находки — какая модель оказалась лучшей для русскоязычных задач, какое железо смогло потянуть gpt-oss:20b — ждём в комментариях.

Источник: Real Python — How to Use Ollama to Run Large Language Models Locally. Автор оригинала — Леоданис Позо Рамос.

V4-Pro. 1,6T параметров (49B активных). Крупнейшая open-weights-модель в мире — больше Kimi K2.6 и GLM-5.1.

V4-Flash. 284B параметров (13B активных). Цена 0,14 $ / 0,28 $ за миллион токенов — дешевле GPT-5.4 Nano.

Эффективность. У Pro на контексте 1M токенов только 27% вычислений (FLOPs на токен) и 10% размера KV-cache относительно V3.2. Модели реально быстрее, не только дешевле.

Бенчмарки. Pro-Max (расширенный reasoning-режим того же Pro) обгоняет GPT-5.2 и Gemini-3.0-Pro, но уступает GPT-5.4 и Gemini-3.1-Pro — отставание от frontier (верхнего эшелона моделей) около 3–6 месяцев.

Доступ. Платный API deepseek.com, OpenRouter; веса бесплатно на HuggingFace под лицензией MIT.

Что именно вышло

DeepSeek в последний раз обновляли линейку в декабре 2025 — тогда вышли V3.2 и V3.2 Speciale. Сейчас представили первый выпуск серии V4 — две preview-модели.

• DeepSeek-V4-Pro — 1,6 триллиона параметров всего, 49 миллиардов активных
• DeepSeek-V4-Flash — 284 миллиарда всего, 13 миллиардов активных

Обе модели — Mixture of Experts (MoE — архитектура, в которой на каждый токен активируется лишь часть «экспертов», а не все параметры сразу) с контекстом 1 миллион токенов и лицензией MIT (без ограничений на коммерческое использование). V4-Pro теперь крупнейшая open-weights-модель в мире: больше Kimi K2.6 (1,1T), GLM-5.1 (754B) и более чем вдвое больше DeepSeek V3.2 (685B). Веса уже лежат на HuggingFace: Pro — 865 ГБ, Flash — 160 ГБ (размер файлов в нативной precision, как их опубликовала DeepSeek).

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

Чтобы было видно масштаб, вот как V4 смотрится на фоне текущих frontier-моделей. Цены — в долларах за миллион токенов, формат input / output. Малые модели (Flash / Nano / Haiku / Flash-Lite) используют для массовых быстрых задач — классификации, простых диалогов, ботов; крупные (Pro / Sonnet / Gemini Pro / Opus) — для сложного reasoning и больших контекстов.

Малые модели

• DeepSeek V4 Flash — 0,14 $ / 0,28 $
• GPT-5.4 Nano — 0,20 $ / 1,25 $
• Gemini 3.1 Flash-Lite — 0,25 $ / 1,50 $
• Gemini 3 Flash Preview — 0,50 $ / 3 $
• GPT-5.4 Mini — 0,75 $ / 4,50 $
• Claude Haiku 4.5 — 1 $ / 5 $

Крупные модели

• DeepSeek V4 Pro — 1,74 $ / 3,48 $
• Gemini 3.1 Pro — 2 $ / 12 $
• GPT-5.4 — 2,50 $ / 15 $
• Claude Sonnet 4.6 — 3 $ / 15 $
• Claude Opus 4.7 — 5 $ / 25 $
• GPT-5.5 — 5 $ / 30 $

Flash — самая дешёвая из малых моделей, дешевле даже GPT-5.4 Nano. Pro — самая дешёвая среди крупных frontier-моделей, причём output у неё стоит всего в 2 раза больше input, тогда как у Gemini 3.1 Pro — в 6 раз, у GPT-5.4 — в 6 раз, у Claude Sonnet 4.6 — в 5 раз. Для задач с длинными ответами (генерация отчётов, перевод, код) разница в итоге получается драматичная.

Почему так дёшево

В DeepSeek подчёркивают: дело не только в ценовой политике — модели реально эффективнее по вычислениям на длинном контексте. При этом у Pro даже больше активных параметров, чем у V3.2 (49B против 37B), — и всё равно обходится дешевле по FLOPs. Из их paper:

В сценарии контекста в 1 миллион токенов DeepSeek-V4-Pro, несмотря на большее число активных параметров, достигает лишь 27% FLOPs на токен (в эквиваленте FP8) и 10% размера KV-cache относительно DeepSeek-V3.2. Flash с меньшим числом активных параметров ещё эффективнее: 10% FLOPs и 7% KV-cache при том же 1M-контексте по сравнению с V3.2.

Перевод с инженерного: для того же 1M-контекста V4-Pro требует примерно в 4 раза меньше вычислений и в 10 раз меньше памяти под KV-cache (KV-cache — это то, что модель держит в памяти, чтобы не пересчитывать уже обработанную часть контекста на каждый новый токен). У Flash выигрыш ещё больше. Значит, DeepSeek может предложить цену, которую конкуренты без такой же архитектуры просто не смогут повторить.

Бенчмарки: почти frontier

Собственная оценка DeepSeek для расширенного режима Pro-Max — того же Pro, только с увеличенным бюджетом на reasoning-токены:

Через расширение reasoning-токенов DeepSeek-V4-Pro-Max показывает превосходство над GPT-5.2 и Gemini-3.0-Pro на стандартных reasoning-бенчмарках. Тем не менее, её показатели чуть уступают GPT-5.4 и Gemini-3.1-Pro — это указывает на отставание от frontier примерно на 3–6 месяцев.

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

Как попробовать

1. API deepseek.com — прямой доступ через официальный кабинет. На момент публикации сервис из России работает напрямую, но для оплаты нужна банковская карта, принимающая USD или CNY.
2. OpenRouter — V4 уже в списке моделей, через него можно платить без прямой привязки к китайскому биллингу. Саймон Уиллисон (ML-блогер, автор инструмента LLM CLI) для теста использовал llm-openrouter.
3. Open weights на HuggingFace — модели лежат под MIT на deepseek-ai. Flash в нативной precision, как его опубликовала DeepSeek, весит 160 ГБ; в квантованном виде (Q4/Q5) — около 60–80 ГБ, что уже умещается в MacBook Pro M5 со 128 ГБ RAM через MLX или llama.cpp.
4. Unsloth-квантизации — команда Unsloth обычно публикует квантованные версии популярных моделей на huggingface.co/unsloth в течение нескольких дней после релиза.

Что это значит для разработчиков

• Используете DeepSeek V3.2? Прогоните свои тесты через V4 — цены в API ниже, контекст тот же 1M токенов.
• Считаете бюджет на LLM в продукте? Flash за 0,14 $ входит в нижнюю ступень как реальная альтернатива GPT-5.4 Nano и Gemini 3.1 Flash-Lite.
• Работаете с open weights локально? V4-Pro устанавливает новый рекорд по размеру открытой модели (1,6T), но потребует серьёзного железа.
• Нужно frontier-качество по нижней цене? Pro за 1,74 $ против GPT-5.4 за 2,50 $ при сопоставимых бенчмарках в reasoning.

Что изменилось на рынке

V4 — это не про первое место на бенчмарках, а про баланс: открытые веса, контекст 1M и рекордно низкая цена в своих нишах. Для большинства задач, где не нужен абсолютный frontier, Flash и Pro делают выбор очевидным. Для OpenAI, Anthropic и Google — ещё один сигнал, что удерживать маржу на нижних ступенях своего прайса всё сложнее.

Мне стало интересно: а можно ли на бесплатных мощностях, буквально "на коленке", собрать русскоязычного ИИ-рентгенолога? Спойлер: можно. В этой статье расскажу, как я скрестил Vision Transformer от Google с ruGPT-3 от Сбера, как боролся с датасетами на Kaggle и что из этого вышло. В конце — ссылки на GitHub и рабочее демо.

Архитектура: как пришить глаза к мозгу

Чтобы нейросеть могла посмотреть на снимок и написать текст, нужна архитектура Vision-Language Model. Обучать такого монстра с нуля у меня не было ни ресурсов, ни желания. Поэтому я пошел по пути Hugging Face VisionEncoderDecoderModel.

Идея проста как кирпич:

1. Энкодер (Глаза): Берем предобученный google/vit-base-patch16-224-in21k. Он отлично дробит картинку на патчи и извлекает визуальные фичи (понимает, где ребра, а где легкие).
2. Декодер (Язык): Берем ai-forever/rugpt3small_based_on_gpt2. У нее нет глаз, она умеет только генерировать текст.

Чтобы их сшить, пришлось немного "взломать" конфиг ruGPT-3, принудительно сказав ей: «Теперь ты декодер, и у тебя есть слои кросс-внимания» (is_decoder=True, add_cross_attention=True). Hugging Face заботливо создал новые пустые веса между двумя моделями. Именно эти связи мне и предстояло обучить.

Data Engineering: боль, страдания и Kaggle

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

Поэтому я взял открытый американский датасет Indiana University Chest X-Ray (IU X-Ray). Там есть картинки и тексты от американских врачей.

Прямо на Kaggle я поднял пайплайн машинного перевода на базе Helsinki-NLP/opus-mt-en-ru. Закинул тексты в GPU батчами по 32 штуки и за 10 минут перевел более 7000 медицинских заключений на вполне сносный русский медицинский язык.

Но тут платформа подкинула сюрприз: Kaggle прячет часть файлов в виртуальной файловой системе (снимков 7000, а стандартный скрипт видел только 4). Пришлось писать суровый маппинг с глубоким сканированием (os.walk), отрезать расширения и жестко связывать ID в CSV с реальными путями на диске.

Обучение: выжимаем все соки из бесплатных T4

Обучение проходило на Kaggle (2x NVIDIA T4). Чтобы модель не умерла от нехватки памяти (OOM), а сессия не отвалилась по тайм-ауту, пришлось шаманить:

• Включил Mixed Precision (fp16) — ускорило обучение в 2 раза.
• Настроил Gradient Accumulation — размер батча на видеокарту был всего 4, но виртуально мы накапливали до 16.
• Столкнулся с тем, что Seq2SeqTrainer крашится при попытке сохранить промежуточный чекпоинт мультимодального "франкенштейна". Решение? Выключить промежуточные сохранения (save_strategy="epoch") и молиться, чтобы Kaggle не завис. (Кстати, спасает JS-скрипт в консоли браузера, делающий клик раз в 60 секунд).

На 15 эпох ушло около 2.5 часов.

Что получилось в итоге? (Потрогать руками)

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

Я завернул модель в Gradio и выложил на Hugging Face Spaces. Можно зайти с телефона или ПК, загрузить любой снимок рентгена из гугла и посмотреть, что она выдаст.

👉 Потыкать лайв-демо тут: Hugging Face Space

👉 Весь код, пайплайны и веса тут: GitHub Репозиторий

Буду рад, если кому-то этот код сэкономит время при создании своих мультимодальных сеток. Залетайте в репу, ставьте звездочки, форкайте. Если есть идеи, как улучшить датасет (может, прогнать переводы через LLM для чистки медицинского сленга) — пишите в комменты!

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

MLOps — это правила, версии и автоматизация для жизненного цикла ML-модели: от данных и обучения до деплоя, мониторинга качества и переобучения. Проще говоря, MLOps нужен, чтобы модель не жила в режиме train.ipynb и чатов с сообщениями “какую версию мы вообще выкатили?”.

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

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

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

— Начать можно без огромного стека: часто достаточно CI/CD, понятного трекинга экспериментов, одного способа деплоя и мониторинга качества.

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

Где заканчивается DevOps и начинается MLOps

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

• В DevOps главный артефакт обычно релиз приложения или контейнер. В MLOps артефактов больше: код, данные, конфигурация обучения, модель, метрики и правила выкладки.
• В DevOps после релиза вы в основном смотрите на uptime и ошибки. В MLOps этого недостаточно: сервис может быть здоровым, а качество предсказаний уже проседать.
• В DevOps откат часто означает вернуть прошлую версию приложения. В MLOps иногда нужно откатывать ещё и модель, и связанный с ней pipeline.
• В MLOps часто автоматизируют не только доставку, но и сам ML-pipeline. В обзоре Google Cloud это описано как отдельные уровни зрелости: continuous training и automation вокруг ML-процесса, а не просто “ещё один деплой”.

Если упростить до одной фразы, DevOps отвечает на вопрос “как надёжно возить приложение”, а MLOps — “как надёжно возить модель, которая со временем стареет и зависит от данных”.

Простой пример: как MLOps выглядит вживую

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

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

Что именно MLOps держит под контролем

• Данные. Важно знать, на каком срезе данных обучали модель, какая у него схема и какие шаги подготовки применялись.
• Код и конфигурацию обучения. Без них нельзя честно воспроизвести эксперимент.
• Эксперименты. Нужно видеть, какой запуск дал лучшие метрики и почему.
• Реестр моделей. Он нужен не только для хранения, но и для управления жизненным циклом: кандидат, staging, production, rollback.
• Сервинг и качество после релиза. Модель должна быть не просто “задеплоена”, а полезна на живых данных и понятна по состоянию.

Здесь есть важная тонкость: “версия данных” — это не просто ссылка на папку. Обычно нужен хотя бы воспроизводимый снапшот, схема, split на train и validation и понимание, как были собраны признаки. Иначе воспроизводимость остаётся на словах.

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

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

• CI/CD для кода и пайплайнов, чтобы обучение и деплой не жили только на ручных командах.
• Трекинг экспериментов и реестр моделей. Чаще всего тут закрывают базовые боли MLflow или похожим инструментом.
• Один понятный способ выкладки: отдельный сервис, batch-job или managed endpoint в облаке.
• Мониторинг инфраструктуры и качества модели. Если у вас уже есть единая наблюдаемость, сюда хорошо стыкуются подходы из OpenTelemetry.
• Kubeflow Pipelines имеет смысл рассматривать тогда, когда у вас уже много ML-пайплайнов и вы реально живёте в Kubernetes, а не просто хотите “поставить серьёзный инструмент”.

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

Когда MLOps уже нужен

• Модель уже влияет на деньги, выдачу, рекомендации, скоринг или другой продовый результат.
• Команда регулярно обучает новые версии и больше не может держать всё в ноутбуках и чатах.
• Стало трудно ответить на простые вопросы: какая версия сейчас в production, на каких данных она училась и как её откатить.
• После релиза важны не только uptime и latency, но и бизнес-метрики модели.
• В ML-процессе участвуют уже не один исследователь, а несколько ролей: ML, backend, infra, аналитика, продукт.

Если же модель пока живёт в чистом исследовании и до production ещё далеко, полноценный MLOps-слой может быть преждевременным. Сначала полезнее навести порядок в базовой инженерии, а потом уже усложнять процесс.

Типичные ошибки

• Думать, что MLOps = один инструмент вроде Kubeflow. Это подход, а не название продукта.
• Версионировать только код и забывать про данные, признаки и конфигурации.
• Считать успешный деплой доказательством качества модели.
• Не иметь model registry и нормального процесса продвижения модели между окружениями.
• Строить тяжёлую платформу раньше, чем команда научилась воспроизводимо обучать и выкатывать хотя бы одну модель.

Главное

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

Если хочешь глубже понять соседние слои инфраструктуры, смотри также материалы про CI/CD, Kubernetes, GitOps и roadmap DevOps-инженера. Они помогают увидеть, на какой инфраструктурной базе MLOps обычно строится.

PrismML — стартап из Калтеха, поддержанный Khosla Ventures, Cerberus и Google — представил семейство 1-bit Bonsai: первые коммерчески жизнеспособные языковые модели, где каждый параметр закодирован одним битом. Модели доступны под лицензией Apache 2.0.

• 1-bit Bonsai 8B — LLM на 8,2 млрд параметров с 1-битными весами, занимает 1,15 ГБ (в 14 раз меньше обычной 8B-модели)
• На бенчмарках конкурирует с Llama 3 8B и Qwen3 8B, при этом работает в 8 раз быстрее и потребляет в 4-5 раз меньше энергии
• Запускается на iPhone 17 Pro Max (44 ток/с), M4 Pro (131 ток/с), RTX 4090 (368 ток/с)
• Также выпущены Bonsai 4B (~0,5 ГБ) и Bonsai 1.7B (0,24 ГБ)
• Лицензия Apache 2.0, модели доступны на Hugging Face

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

Что значит «1-битная модель»

В стандартных LLM каждый вес (параметр) хранится в 16-битном числе с плавающей точкой (FP16). В 1-bit Bonsai 8B все веса — эмбеддинги, слои внимания, MLP-слои и LM head — закодированы одним битом. Нет «escape hatches» с повышенной точностью — это настоящая 1-битная модель от начала до конца.

Результат: модель с 8,2 млрд параметров занимает 1,15 ГБ вместо ~16 ГБ. Это уменьшение в 14 раз — не за счёт обрезки слоёв или дистилляции, а за счёт принципиально иного способа кодирования весов.

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

PrismML измерял Bonsai 8B на стандартном наборе бенчмарков: IFEval, GSM8K, HumanEval+, BFCL, MuSR, MMLU-Redux.

• По средним оценкам бенчмарков — конкурирует с Llama 3 8B, Qwen3 8B и другими лидерами класса 8B
• Intelligence density (плотность интеллекта, по собственной метрике PrismML): 1,06/ГБ у Bonsai против 0,10/ГБ у Qwen3 8B — разница в 10,6 раз
• Скорость: 131 ток/с на M4 Pro, 368 ток/с на RTX 4090, 44 ток/с на iPhone 17 Pro Max
• Энергоэффективность: 0,074 мВт·ч/токен на M4 Pro — в 4-5 раз лучше FP16-аналогов

На длинных агентных задачах преимущество ещё заметнее: в демо PrismML Bonsai 8B обработал 50 тикетов за то же время, что обычная 8B-модель — 6.

Три модели семейства

PrismML выпустил три модели разного размера:

• 1-bit Bonsai 8B — 8,2 млрд параметров, 1,15 ГБ. Флагман: рассуждения, вызов функций, генерация кода
• 1-bit Bonsai 4B — ~0,5 ГБ, 132 ток/с на M4 Pro. Баланс скорости и точности
• 1-bit Bonsai 1.7B — 0,24 ГБ, 130 ток/с на iPhone 17 Pro Max. Ультралёгкая модель для мобильных устройств

Все три модели сдвигают Парето-фронт «интеллект vs размер» влево — то есть дают больше возможностей при меньшем объёме.

Зачем это нужно: от дата-центров к устройствам

1-битные модели открывают класс задач, для которых облачные LLM не подходят:

• Приватность — данные не покидают устройство
• Латентность — нет задержки на сетевой запрос
• Автономность — работает офлайн, без интернета
• Стоимость — не нужен облачный GPU
• Роботика и встраиваемые системы — запуск на edge-устройствах с ограниченной памятью

Будущее ИИ определит не тот, кто построит самый большой дата-центр, а тот, кто сможет доставить максимум интеллекта на единицу энергии и стоимости.

Перспектива: специализированное железо

Текущие результаты получены на стандартном потребительском железе, оптимизированном для FP16-арифметики. PrismML отмечает, что выигрыш пока идёт в основном за счёт уменьшения footprint — полноценная оптимизация 1-битного инференса на уровне железа ещё впереди.

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

Энергия стала главным узким местом для масштабирования ИИ-датацентров. PrismML фундаментально меняет уравнение «мощность/вычисления».

Как попробовать

Модели доступны на Hugging Face под лицензией Apache 2.0. Поддерживаются:

• Apple (Mac, iPhone, iPad) — через MLX
• NVIDIA GPU — через llama.cpp CUDA
• Whitepaper с техническими деталями обучения и оценки доступен на сайте PrismML

Выводы

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

1-bit Bonsai — первая серьёзная заявка на то, что 1-битные модели могут быть не компромиссом, а полноценным продуктом. Если результаты бенчмарков подтвердятся независимыми исследователями, это изменит экономику запуска LLM: модель класса 8B, которая помещается в гигабайт и работает на смартфоне, — это другой рынок.

Скачать модели: Hugging Face | Подробности: блог PrismML

TurboQuant — алгоритм квантизации KV-кеша (Key-Value cache), промежуточного буфера, в котором LLM хранят контекст разговора. Сжимает его с 16 до 3–4 бит на значение без переобучения модели. Статья принята на ICLR 2026 (arXiv:2504.19874).

— Сообщество создало рабочие реализации TurboQuant для llama.cpp, MLX и PyTorch

— Q8 KV-кеш с rotation — почти без потерь (37,1% vs 37,9% F16 на AIME25)

— Q4 пока проблемный для K-тензоров, рекомендуют TQ8 для K + TQ4 для V

— Текущие реализации в 3–8 раз медленнее из-за неоптимизированного поворота вектора

— Главный выигрыш — длинные контексты: 70B-модель может уместить 536K токенов вместо 109K

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

Один из первых тестов опубликован на r/LocalLLaMA — результаты на математическом бенчмарке AIME25 (чем выше — тем лучше). Связанный PR в llama.cpp подтверждает данные:

• F16 KV-кеш (без сжатия): 37,9%
• Q8_0 без rotation: 31,7% — потеря 6,2 п.п.
• Q8_0 с rotation (TurboQuant): 37,1% — почти полное восстановление
• Q4_0 без rotation: 2,0% — катастрофическая деградация
• Q4_0 с rotation: 21,7% — значительное улучшение, но всё ещё далеко от F16

Вывод: при 8-битной квантизации KV-кеша rotation практически полностью компенсирует потерю качества. При 4-битной — улучшение радикальное (с 2% до 21,7%), но до lossless ещё далеко. Безопасный минимум на сегодня — Q8 с rotation для K-тензоров и Q4 для V-тензоров.

Проблема K-тензоров: не всё сжимается одинаково

Разработчик inference-движка Llaminar провёл детальный анализ cosine similarity между сжатым и эталонным FP32-выходом на нескольких моделях. Главный вывод: K-тензоры (Key) и V-тензоры (Value) ведут себя при квантизации принципиально по-разному.

V-тензоры хорошо переносят 4-битное сжатие. K-тензоры — нет. Причина: K-тензоры имеют значительно более высокие нормы векторов по сравнению с V. Измерения показывают соотношение K/V-норм до 100–180x у современных моделей (Qwen2.5, GPT-2). Ошибка квантизации масштабируется с квадратом нормы, поэтому K-тензорам нужно больше бит для сохранения точности.

Практическая рекомендация: TQ8 для K-тензоров + TQ4 для V-тензоров. Это даёт хорошую экономию памяти при минимальной потере качества — компромисс, который подтверждён и бенчмарками, и cosine similarity анализом.

Где TurboQuant действительно меняет правила

Главный выигрыш — не скорость генерации (она пока даже падает), а объём контекста, который помещается в память. Расчёт из обсуждения llama.cpp для модели 70B Q4_K_M с 34 ГБ свободной VRAM:

• FP16 KV-кеш: ~109K токенов
• Q8 KV-кеш: ~218K токенов (2x)
• TurboQuant TQ3: ~536K токенов (5x)

Это значит: одна видеокарта с 48 ГБ памяти может работать с контекстом, который раньше требовал 3–4 карты. Для владельцев MacBook с Apple Silicon — локальная модель на 16 ГБ RAM теперь «видит» в 3–5 раз больше текста при той же скорости.

Реализации TurboQuant: кто уже попробовал

Официального кода от Google нет (ожидается во 2-м квартале 2026). Но сообщество уже создало рабочие реализации, а в vLLM открыт активный PR на нативную интеграцию:

• llama.cpp — минимум 3 независимых форка. Обсуждение интеграции в основную ветку. Флаги зависят от форка: --cache-type-k turbo3 (TheTom) или tq3_0 (другие форки)
• MLX — адаптация для Apple Silicon (M1–M5)
• PyTorch + Triton — reference-реализации для CUDA. Один разработчик получил побитово идентичный выход на Gemma 3 4B при 2-битной точности на RTX 4090
• vLLM — активный PR на нативную интеграцию TurboQuant как опции KV-кеша

Главная проблема текущих реализаций — скорость. Операция поворота вектора (rotation) пока не оптимизирована: сложность O(d²) вместо O(d log d). Замедление составляет 3–8x по сравнению с обычным Q8 KV-кешем. Разработчики работают над оптимизацией через преобразование Уолша–Адамара (Walsh-Hadamard transform), которое снизит сложность до O(d log d).

Реализации TurboQuant очень зависят от качества кода. Я видел vibecoded-реализации со скрытыми багами, которые убивали производительность.

Реакция рынка

В день публикации TurboQuant 25 марта 2026 года акции производителей памяти снизились: SK Hynix потеряла 6,2%, Samsung — 4,8%, Micron — 3,4%. Логика рынка: если inference требует в 6 раз меньше памяти — спрос на HBM снижается. Но это упрощение: TurboQuant сжимает только KV-кеш, а не веса модели, и дешёвый inference увеличивает спрос на LLM в целом.

Что это значит для вас

Если вы запускаете LLM локально через llama.cpp, Ollama или LM Studio — в ближайшие месяцы ожидайте нативную поддержку TurboQuant. Практический эффект:

• Длинные контексты без нового железа — ваша текущая видеокарта или MacBook сможет работать с 3–5x большим контекстом
• Оптимальная конфигурация — TQ8 для K + TQ4 для V. Чистый TQ4 для обоих пока даёт заметную деградацию на K-тензорах
• Скорость пока не выигрыш — текущие реализации замедляют генерацию в 3–8 раз. Ждите оптимизированных ядер с Walsh-Hadamard transform
• Комбинируйте с квантизацией весов — TurboQuant сжимает KV-кеш, а не веса. Q4-модель + TQ4-кеш = максимальная экономия памяти

Выводы

TurboQuant — не серебряная пуля, но значимый шаг для локального inference. Rotation при Q8 KV-кеше работает почти без потерь. Q4 пока проблемный для K-тензоров, но V-тензоры сжимаются хорошо. Главный практический выигрыш — длинные контексты на существующем железе без покупки новых карт.

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

Ссылки: Блог Google Research | Обсуждение в llama.cpp | Наш разбор алгоритма

— Цель: обучить лучшую LM в артефакте ≤16 МБ за ≤10 минут на 8×H100

— Метрика: bits per byte на FineWeb validation set (чем ниже, тем лучше)

— $1 000 000 compute-кредитов от OpenAI через Runpod

— Лидерборд: лучший результат 1,1194 bpb (LeakyReLU² + TTT + Parallel Muon)

— Срок: 18 марта — 30 апреля 2026

— OpenAI ищет исследователей через этот конкурс

Правила и метрика

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

• Размер артефакта ≤16 МБ — всё, включая веса, токенизатор, код
• Время обучения ≤10 минут на 8×H100 (SXM)
• Метрика — bits per byte (bpb) на FineWeb validation set. Оценка не зависит от токенизатора — считается сжатие в байтах

Если neural scaling laws описывают зависимость качества от размера модели, то Parameter Golf — экстремальная точка этой кривой: минимальный loss при жёстко фиксированном числе параметров.

Что пробуют участники

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

• Агрессивная квантизация. Int6, int5, ternary (1/0/−1) и даже 1-bit квантизация. Один участник квантизировал 73,7M параметров в тернарные веса и уместил в 16 МБ
• Test-time training (TTT). Адаптация модели к валидационным данным перед оценкой через LoRA-адаптеры — легальный по правилам конкурса способ улучшить метрику
• Нестандартные архитектуры. Depth recurrence (повторное использование слоёв), cross-sequence attention на последних слоях для улучшения контекста, кастомные токенизаторы
• Sliding window eval. Оценка на длинных контекстах через скользящее окно вместо фиксированного

Лидерборд

Топ-3 на 23 марта 2026:

• 1,1194 bpb — abaybektursun: LeakyReLU² + Legal Score-First TTT + Parallel Muon
• 1,1228 bpb — signalrush: GPTQ-lite clip search + EMA + warmdown3500 + QAT@0.15
• 1,1248 bpb — jfprincz: Partial RoPE (16/64) + layerwise LN scale

Baseline (наивная модель) — 1,2244 bpb. За 5 дней участники улучшили результат на 8,6%.

Как участвовать

Репозиторий на GitHub содержит готовый baseline-код на PyTorch и MLX (для Mac с Apple Silicon):

Для работы на GPU OpenAI рекомендует Runpod. 1×H100 стоит ~$2–3/час, 8×H100 — ~$20/час. Для заявки на compute-кредиты — форма в репозитории.

Зачем это OpenAI

OpenAI прямо пишет: конкурс создан по духу олимпиадных соревнований. Компания планирует в июне нанять небольшую когорту early-career исследователей — выпускников и студентов, включая олимпиадных медалистов. Для сильных участников Parameter Golf может стать способом попасть на радар рекрутёров OpenAI.

Выводы

Parameter Golf — редкий конкурс, где побеждает не тот, у кого больше GPU, а тот, кто умнее сжимает. Ternary квантизация, test-time training, нестандартные архитектуры — участники уже демонстрируют подходы, которые могут оказаться полезными далеко за пределами соревнования. Дедлайн — 30 апреля 2026.

ATLAS (Adaptive Test-time Learning and Autonomous Specialization) — open-source система, которая оборачивает замороженную квантизированную модель Qwen3-14B в трёхфазный пайплайн генерации, верификации и починки кода. На бенчмарке LiveCodeBench v5 (599 из 880 задач) система набрала 74,6% — против 71,4% у Claude Sonnet 4.5.

— ATLAS набирает 74,6% на LiveCodeBench v5, используя замороженную Qwen3-14B на одной RTX 5060 Ti за ~$430

— Базовая модель набирает лишь ~55% — пайплайн добавляет почти 20 п.п. за счёт генерации нескольких решений, тестирования и починки

— Стоимость — ~$0,004 за задачу (электричество) против ~$0,066 за вызов API Claude Sonnet

— Сравнение не прямое: ATLAS использует best-of-3 + итеративную починку, а Claude тестировали в режиме single-shot на другом наборе задач

— На других бенчмарках (GPQA Diamond — 47%, SciCode — 14,7%) ATLAS значительно уступает фронтирным моделям

Автор проекта, студент Исаак Тиггес, собрал всё это на одной потребительской видеокарте RTX 5060 Ti 16 ГБ. Весь инференс локальный — данные не покидают машину, API-ключи не нужны.

Как работает ATLAS

ATLAS — это не новая модель, а инженерная обвязка вокруг существующей. В основе — замороженная квантизированная Qwen3-14B-Q4_K_M от Alibaba, запущенная через патченный llama-server на K3s. Система работает в три фазы:

Фаза 1: генерация

PlanSearch извлекает ограничения из задачи и генерирует несколько различных планов решения. BudgetForcing контролирует количество thinking-токенов. DivSampling обеспечивает разнообразие кандидатов. На выходе — три варианта решения (k=3).

Одна эта фаза поднимает результат с 54,9% до 67,3% — прирост 12,4 процентных пункта.

Фаза 2: отбор лучшего кандидата

Geometric Lens — компонент, который оценивает качество каждого кандидата по внутренним представлениям модели и отправляет лучшего на исполнение в песочницу.

Важный нюанс: в текущей версии эта фаза не дала прироста (+0,0 п.п.), потому что C(x) обучалась всего на ~60 примерах — слишком мало для осмысленного энергетического ландшафта. Автор планирует исправить это в V3.1.

Фаза 3: починка провалов

Если все кандидаты провалились, модель генерирует собственные тест-кейсы и запускает PR-CoT (multi-perspective chain-of-thought repair) — итеративную починку через рассуждение с нескольких точек зрения. Модель никогда не видит правильные ответы — только свои собственные тесты.

PR-CoT спасает 36 из 42 задач, попавших в фазу починки — 85,7% успеха. Суммарный прирост фазы 3 — ещё 7,3 п.п.

Бенчмарки: что показывают цифры

Результаты ATLAS V3 на трёх бенчмарках:

Метрика pass@1-v(k=3) означает, что для каждой задачи генерируются три кандидата, из которых выбирается лучший. Это значительно легче, чем классический pass@1, где модель даёт ровно один ответ без права на повторную попытку.

Для контекста — сравнение стоимости и результата на LiveCodeBench:

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

Автор ATLAS сам признаёт ключевое ограничение: сравнение — не контролируемый head-to-head.

• ATLAS тестировали на 599 задачах LiveCodeBench v5, а Claude — на 315 задачах из данных Artificial Analysis. Это разные наборы задач
• ATLAS генерирует три кандидата, отбирает лучшего и итеративно чинит провалы. Claude тестировали в режиме single-shot (один запрос, один ответ, без повторов)
• ATLAS оптимизировался именно под LiveCodeBench — на GPQA Diamond (47%) и SciCode (14,7%) результаты значительно скромнее
• Метрика ATLAS — pass@1-v(k=3), а не классический pass@1. Это принципиально разные вещи

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

Что действительно впечатляет

Несмотря на оговорки, проект демонстрирует несколько важных вещей:

1. Инженерия побеждает масштаб. Базовая Qwen3-14B набирает ~55% — пайплайн ATLAS добавляет почти 20 п.п. без единой строчки файнтюнинга. Это чистая системная инженерия
2. Порог входа падает. Два года назад для локального инференса нужна была видеокарта за $2000+. Сегодня — RTX 5060 Ti за ~$430. Через два года это может быть карточка за $200
3. Полная автономность. Данные не покидают машину. Нет API-ключей, нет счетов, нет зависимости от провайдера. Для сценариев с чувствительными данными — это принципиально
4. Стоимость. ~$0,004 за задачу (электричество при $0,12/кВт·ч) — в 16 раз дешевле одного вызова Claude Sonnet API

Ограничения и планы

Автор честно документирует проблемы текущей версии:

• Geometric Lens (фаза 2) не работает — обучалась на 60 примерах, что слишком мало
• Метрический тензор G(x) неактивен — будет переработан или удалён в V3.1
• Задачи обрабатываются последовательно — нет параллелизма
• Баг SandboxAdapter со stdin — не работает tiebreaking через distinguishing input
• Система оптимизирована только под LiveCodeBench — кросс-доменная генерализация на повестке V3.1

В версии V3.1 планируется переход на Qwen3.5-9B с архитектурой DeltaNet (ускорение в 3–4 раза), переобучение Geometric Lens, параллелизация задач и расширение набора бенчмарков. Целевой результат — 80–90% на LiveCodeBench.

Требования к железу

Проект пока не plug-and-play — V3.1 обещает улучшить портативность. На текущий момент настройка под конкретное железо может потребовать ручной работы с параметрами: количество параллельных слотов, квантизация KV-кеша, размер контекста на слот.

Выводы

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

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

Бенчмарки измеряют, может ли модель решить игрушечную задачу. Продакшен измеряет, может ли она думать.

Настоящий сигнал здесь — не в том, что локальный инференс «победил» облачный ИИ. А в том, что порог доступа к мощному ИИ-инференсу продолжает стремительно падать. Если у вас есть NVIDIA GPU с 16+ ГБ VRAM — попробуйте ATLAS на своих задачах и оцените результат.

Источники: ATLAS на GitHub (1,2K звёзд) · LiveCodeBench Leaderboard · обсуждение на Hacker News · анализ Fordel Studios

О том, как это устроено, рассказала Теа Аррестад, доцент физики частиц в ETH Zurich, на конференции Monster Scale Summit. А open-source транспайлер HLS4ML, который делает это возможным, уже доступен для всех. Подробности — в материале The Register.

— LHC производит ~40 000 экзабайт нефильтрованных данных в год, хранить удаётся ничтожную долю

— Level-1 Trigger — система из ~1000 FPGA, которая фильтрует данные за менее чем 50 наносекунд

— AXOL1TL — нейросеть для обнаружения аномалий, прошитая прямо в чип

— HLS4ML — open-source транспайлер: Python-модель → C++ → прошивка FPGA или ASIC

— Модели квантизированы, обрезаны и дистиллированы до минимального размера

— Подход применим за пределами физики: edge ИИ, IoT, медицина, автономные системы

Проблема: 40 000 экзабайт данных в год

В 27-километровом кольце на глубине 100 метров под границей Швейцарии и Франции протоны разгоняются до околосветовых скоростей. Около 2800 пучков протонов несутся по кольцу с интервалом в 25 наносекунд. Из миллиардов протонов в каждом пучке столкнуться напрямую удаётся лишь ~60 парам.

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

«Если бы у нас было бесконечное количество вычислительных ресурсов, мы бы смотрели все данные», — говорит Аррестад. Но реальность такова, что сохранить и проанализировать удаётся менее 0,02% от всего массива. Остальное необходимо отбросить в реальном времени — прямо на уровне детекторов.

Решение: нейросеть в кремнии

Детекторы LHC, построенные на ASIC-чипах, буферизуют данные лишь на 4 микросекунды. После этого данные «падают со скалы» — они навсегда потеряны, если не были сохранены.

За принятие решения отвечает Level-1 Trigger — агрегат из примерно 1000 FPGA-чипов. Он получает сжатую информацию о событии по оптоволокну со скоростью ~10 ТБ/с и выдаёт единственное значение: «принять» (1) или «отклонить» (0).

Решение принимает алгоритм AXOL1TL — нейросеть для обнаружения аномалий, прошитая непосредственно в FPGA. Она обучена на «фоне» — известных событиях Стандартной модели. Всё, что выходит за рамки типичной картины столкновения, помечается как потенциально интересное. Как выразилась Аррестад, алгоритм «охотится за редкой физикой».

Время на решение — менее 50 наносекунд. Лишь ~110 000 событий в секунду (0,02% от всех столкновений) проходят фильтр и отправляются на поверхность. Далее данные проходят вторую стадию фильтрации — High Level Trigger на 25 600 CPU и 400 GPU — и сокращаются до ~1000 событий в секунду, порождая около петабайта данных в день.

HLS4ML: как модель попадает в чип

Стандартные библиотеки машинного обучения для edge-устройств (MLPerfMobile, MLPerfTiny) не справляются с потоковыми данными и задержками уровня CERN. Поэтому инженеры создали собственный инструментарий — HLS4ML.

HLS4ML — это open-source транспайлер, который преобразует обученную модель машинного обучения в C++-код, оптимизированный под конкретную аппаратную платформу: FPGA, ASIC или систему на кристалле. Фактически, он позволяет «напечатать» нейросеть в кремнии.

Цепочка выглядит так:

1. Модель обучается в Python (PyTorch, TensorFlow, scikit-learn)
2. Агрессивная оптимизация: квантизация (уникальная битовая ширина для каждого параметра), pruning (удаление лишних связей), дистилляция (передача знаний из большой модели в крошечную)
3. HLS4ML транспилирует модель в C++, адаптированный под целевую платформу
4. C++-код компилируется в bitstream — прошивку FPGA

Архитектура FPGA принципиально отличается от классической фон-неймановской модели, где процессор последовательно извлекает инструкции из памяти и выполняет их одну за другой. В FPGA нет такого цикла — вычисления запускаются сразу, как только на вход поступают данные. Каждый слой нейросети реализован как отдельный физический блок на чипе, а значительная часть кремния отведена под предвычисленные таблицы поиска (LUT), которые заменяют сложные арифметические операции мгновенной выдачей результата.

Интересно, что для этих задач древовидные модели (tree-based) оказались не менее эффективными, чем глубокое обучение, но при значительно меньших затратах ресурсов. Это логично: данные Стандартной модели — по сути табличные, а для каждого столкновения LHC выдаёт структурированный набор дискретных измерений.

Почему не GPU?

Может показаться, что GPU — естественный выбор для ИИ-задач. Но для Level-1 Trigger они не подходят по нескольким причинам:

• Латентность. GPU работают с задержками в микро- и миллисекунды. Для Level-1 Trigger нужны наносекунды — на три порядка быстрее
• Детерминизм. FPGA обеспечивают жёсткое детерминированное время выполнения. GPU с их конвейерами и шедулерами такого не гарантируют
• Энергопотребление. Тысяча FPGA потребляет значительно меньше энергии, чем эквивалентное количество GPU
• Всё на чипе. Решения должны приниматься без обращения к внешней памяти — даже к очень быстрой. На FPGA модель буквально впаяна в кремний

GPU используются на второй стадии фильтрации (High Level Trigger), где допустимы задержки в миллисекунды и есть время на реконструкцию полной картины столкновения. Но на первом уровне, где данные живут лишь 4 микросекунды, компромиссов быть не может.

За пределами физики частиц

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

• Edge ИИ и IoT. Промышленные датчики, системы умного города и автономные устройства часто не могут позволить себе связь с облаком. Модель в FPGA работает автономно и с минимальной задержкой
• Медицина. Например, компания Xilinx (ныне AMD) уже использует FPGA для ускорения обработки геномных данных в секвенаторах ДНК. Аналогичный подход применим к анализу данных МРТ, ЭКГ или потоков с хирургических роботов в реальном времени
• Автономный транспорт. Принятие решений в беспилотных автомобилях и дронах, где задержка при обращении к облаку недопустима
• Телеком и кибербезопасность. Инспекция сетевого трафика на скоростях в сотни гигабит без снижения пропускной способности

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

FAQ

Что такое FPGA и чем она отличается от GPU?

FPGA (Field-Programmable Gate Array) — это микросхема, логику которой можно перепрограммировать после производства. В отличие от GPU, где тысячи универсальных ядер выполняют инструкции последовательно, FPGA реализует алгоритм как физическую схему: данные проходят через логические вентили без каких-либо программных инструкций. Это даёт наносекундные задержки и детерминированное время выполнения.

Можно ли использовать HLS4ML вне CERN?

Да. HLS4ML — проект с открытым исходным кодом, опубликованный на opensource.web.cern.ch. Согласно документации проекта, он поддерживает модели из Keras, PyTorch и ONNX и генерирует C++-код для синтеза на различных платформах FPGA (Xilinx Vivado HLS, Intel HLS). Инструмент активно используется в академической среде и начинает проникать в промышленность.

Насколько маленькими должны быть модели для FPGA?

Модели для Level-1 Trigger в CERN — это единицы-десятки килобайт параметров с агрессивной квантизацией (уникальная битовая ширина для каждого веса). Для сравнения: GPT-4 занимает сотни гигабайт. Всё дело в компромиссе: модель должна целиком умещаться на чипе без обращения к внешней памяти, потому что даже обращение к DRAM занимает десятки наносекунд — слишком медленно для Level-1 Trigger.

Выводы

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

По данным CERN, команда подготовила прошивку AXOL1TL для включения в trigger menu LHC — набор алгоритмов, которые решают, какие столкновения сохранить. А в конце года коллайдер остановят для модернизации до High-Luminosity LHC (запуск в 2031), который увеличит поток данных в 10 раз — до 63 ТБ/с. Это потребует ещё более агрессивной компрессии моделей.

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

Независимый разработчик Tom Turney опубликовал метод sparse V dequantization — оптимизацию для инференса LLM с квантизированным KV-кешем. Вместо того чтобы ускорять деквантизацию каждого значения, он предложил пропускать деквантизацию целиком для позиций, где вес внимания пренебрежимо мал. На Apple M5 Max с моделью Qwen 3.5 35B (MoE) метод дал прирост +22,8% к скорости декодирования на контексте 32K токенов. Перплексия осталась неизменной, а точность поиска needle-in-a-haystack выросла с 7/9 до 9/9.

Ключевые выводы

— Узкое место квантизированного KV-кеша — не то, как вы деквантизуете, а то, сколько значений вы деквантизуете.
— При длинном контексте (32K+) более 90% весов внимания пренебрежимо малы — их деквантизацию можно пропустить.
— Метод работает с любой схемой квантизации KV-кеша: TurboQuant, q8_0, q4_0, NVFP4.
— Реализация — 3 строки в ядре flash attention. Не нужно ни переобучение, ни калибровочные данные.
— NIAH-тест улучшился: 9/9 вместо 7/9. Пропуск деквантизации убирает квантизационный шум от позиций, которые ничего не вносят в результат.

Проблема — узкое место деквантизации

Чтобы понять суть открытия, нужно разобраться в контексте. Современные LLM при генерации текста хранят промежуточные вычисления в так называемом KV-кеше (key-value cache). Это массив ключей (K) и значений (V), которые модель использует в механизме внимания — чтобы при генерации каждого нового токена не пересчитывать всю историю диалога.

Проблема: KV-кеш растёт линейно с длиной контекста и при 32K токенов занимает гигабайты памяти. Решение — квантизация: сжатие значений из 16-битного формата в 3-4 бита. TurboQuant от Google (ICLR 2026) сжимает KV-кеш в 4,6 раза с потерей перплексии всего ~1%. Но при декодировании каждый сжатый блок нужно деквантизовать — преобразовать обратно в числа с плавающей точкой. И на длинных контекстах это становится узким местом.

На Apple M5 Max деквантизация TurboQuant занимает 14-34% времени декодирования. На контексте 32K токенов скорость декодирования падает с 78,3 tok/s (потолок без деквантизации) до 47,0 tok/s — штраф в 40%.

14 попыток, которые провалились

Прежде чем найти решение, Turney перебрал 14 альтернативных реализаций деквантизации на Apple Silicon: регистровые массивы, битовую арифметику, SIMD-шаффлы, FMA без ветвлений, слитые блочные операции. Ни одна не обогнала базовую таблицу подстановки (LUT) в константной памяти GPU.

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

Решение — не ускорять, а пропускать

Ключевое наблюдение: в flash attention ядре веса внимания (softmax) вычисляются из ключей (K) до того, как начинается работа со значениями (V). То есть на момент деквантизации V мы уже знаем, какие позиции контекста получили значимый вес внимания, а какие — нет.

Что такое разреженность внимания? Когда модель генерирует следующий токен, механизм внимания (softmax) распределяет вероятность по всем предыдущим позициям контекста. При коротком контексте внимание распределено относительно равномерно. Но чем длиннее контекст, тем более концентрированным оно становится: модель «смотрит» на несколько десятков ключевых позиций, а 90%+ получают веса ниже 10-6 — они практически ничего не вносят в итоговый результат.

Sparse V dequantization использует этот факт: если вес внимания для позиции ниже порога (10-6), её деквантизация и аккумуляция пропускаются целиком.

Вся реализация — три строки в Metal-ядре:

Это экономит чтения из константной памяти (обращения к LUT), ALU-операции (извлечение индексов, применение знака, умножение на норму) и чтения из глобальной памяти устройства.

Принципиальное отличие от 14 провалившихся подходов: они пытались сделать каждую из N операций быстрее (ограничено аппаратным полом). Sparse V убирает (1-p) x N операций целиком — и выигрыш растёт с длиной контекста, потому что разреженность внимания растёт.

Результаты

Скорость декодирования (M5 Max, Qwen 3.5 35B MoE)

Эффект sparse V масштабируется с длиной контекста — чем длиннее контекст, тем больше позиций пропускается:

• Короткий контекст: +1,4% (внимание плотное, мало что пропускать)
• 4K: +4,0%
• 8K: +7,2%
• 16K: +12,9%
• 32K: +22,8% (с 47,0 до 57,7 tok/s)

При 32K токенов отношение к несжатому q8_0 улучшилось с 0,76x до 0,93x — почти паритет.

Качество: перплексия и retrieval

Перплексия при включении sparse V остаётся численно идентичной варианту без него. На корпусе wikitext-103 (50 чанков, контекст 32K, CI +/-0.021) дельта составила ровно 0,0000. Это подтверждено на всех протестированных длинах контекста: 8K, 16K, 32K.

Ещё более неожиданный результат — в тесте needle-in-a-haystack (NIAH). Этот тест проверяет, может ли модель найти конкретный факт, спрятанный в длинном контексте:

• Без sparse V: 7/9 (q8_0 тоже 7/9)
• С sparse V: 9/9 (100%)

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

Почему это работает для любой квантизации

Sparse V работает не на уровне конкретного формата квантизации, а на уровне механизма внимания. Метод использует веса softmax как сигнал для пропуска вычислений — а softmax одинаков вне зависимости от того, как именно сжаты K и V.

Автор валидировал метод на трёх форматах KV-кеша с разной стоимостью деквантизации:

• turbo3 (3,5 бита, TurboQuant) — +22,8% на 32K, перплексия без изменений
• q8_0 (8 бит) — +5% к декодированию, перплексия идентична
• q4_0 (4 бита) — перплексия идентична, скорость в пределах шума

Закономерность: чем дороже деквантизация, тем больше выигрыш. turbo3 использует Walsh-Hadamard-преобразование и полярную декомпозицию — тяжёлые операции, поэтому выигрыш максимален. q4_0 использует простое масштабирование — пропуск дешёвой операции даёт мало. Но в обоих случаях метод не ухудшает ни перплексию, ни retrieval.

Это означает, что sparse V можно включить по умолчанию для любого формата квантизации KV-кеша в llama.cpp — как безусловную оптимизацию, которая ничего не стоит на коротком контексте и даёт ощутимый выигрыш на длинном.

FAQ

Не сломает ли пропуск позиций качество генерации?

Нет. Порог 10-6 выбран консервативно. При контексте 32K с 32 головами внимания вклад пропущенной позиции в итоговый вектор — менее одной миллионной от максимума. Перплексия во всех экспериментах осталась численно идентичной — дельта 0,0000 на 50 чанках wikitext-103.

Почему нельзя пропускать и K-деквантизацию?

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

Работает ли это на NVIDIA GPU?

Эксперименты проводились на Apple Silicon (M5 Max, M2 Pro). Реализация — Metal-ядро для llama.cpp. На CUDA профиль узкого места другой (NVIDIA использует тензорные ядра и HBM вместо unified memory), но сам принцип — пропуск работы для позиций с малым весом внимания — универсален. Портирование на CUDA и ROCm автор указывает как следующий шаг.

Выводы

Sparse V dequantization — элегантное решение, которое меняет вопрос с «как деквантизовать быстрее?» на «нужно ли деквантизовать вообще?». Метод использует информацию, которая уже есть в ядре flash attention — веса softmax — как бесплатный сигнал для пропуска вычислений.

Главная ценность подхода — не конкретный прирост в 22,8%, а более широкая идея attention-aware computation: использование собственных паттернов разреженности модели для оптимизации ядер инференса. Чем длиннее контекст, тем сильнее разреженность — и тем больше выигрыш. Именно при тех длинах контекста, где узкое место деквантизации наиболее болезненно.

Код и бенчмарки: TheTom/turboquant_plus (бенчмарки и диагностика), TheTom/llama-cpp-turboquant (реализация, ветка experimental_decode_speed_tests).

Обсуждение на r/LocalLLaMA.

Источник: Sparse V Dequantization — документация turboquant_plus.

Мы разобрались. Объясняем так, чтобы было понятно всем — и тем, кто пишет нейросети, и тем, кто просто хочет запустить ChatGPT-подобную модель на своём ноутбуке.

TurboQuant — алгоритм квантизации KV-кеша для больших языковых моделей (LLM), разработанный Google Research. Сжимает KV-кеш с 16 до 3 бит на значение, уменьшая потребление памяти при инференсе в 5–6 раз без переобучения модели и без потери качества. Представлен на ICLR 2026 (arXiv:2504.19874).

KV-кеш: почему нейросетям нужно столько памяти

Когда вы общаетесь с ChatGPT, Gemini или любой другой LLM, модель должна «помнить» весь ваш диалог. Для этого она использует KV-кеш (Key-Value cache) — специальный буфер в памяти видеокарты, где хранятся промежуточные вычисления механизма внимания (attention).

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

Проблема в масштабе:

• Модель Llama 3.1 70B при контексте 128K токенов тратит ~40 ГБ только на KV-кеш — это больше, чем весит сама модель в квантизированном виде
• Чем длиннее контекст (переписка, документ, код) — тем больше памяти нужно, и это растёт линейно
• Именно KV-кеш — главный ограничитель того, сколько текста модель может «видеть» одновременно

И именно KV-кеш сжимает TurboQuant.

Что такое TurboQuant

TurboQuant — это алгоритм сжатия KV-кеша, разработанный Google Research. Статья принята на ICLR 2026 — одну из топовых конференций по машинному обучению. Авторы — Amir Zandieh, Vahab Mirrokni (VP Google, известный исследователь в области алгоритмов) и коллеги.

• Сжимает KV-кеш до 3 бит на значение (с обычных 16) — уменьшение в ~5 раз
• Не требует дообучения модели — работает с любой LLM «из коробки»
• Не теряет качество на стандартных бенчмарках (LongBench, Needle in a Haystack, RULER)
• Ускоряет вычисления attention до 8 раз на NVIDIA H100
• Работает «на лету» — не нужно заранее обрабатывать данные

Важно: TurboQuant сжимает только KV-кеш при инференсе. Он НЕ сжимает веса модели (это делают GPTQ, AWQ, GGUF) и НЕ влияет на обучение. Это принципиально другая задача.

Как работает TurboQuant: PolarQuant и QJL простыми словами

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

Шаг 1: PolarQuant — умное сжатие основных данных

Обычно данные в нейросети хранятся в декартовых координатах — как «иди 3 блока на восток и 4 блока на север». PolarQuant переводит их в полярные координаты — «иди 5 блоков под углом 37 градусов». Перед конвертацией вектор случайным образом поворачивается — это делает распределение координат более однородным.

В полярных координатах данные распределены более предсказуемо. Это позволяет применить оптимальный квантизатор (Lloyd-Max) к каждой координате независимо, без дополнительных битов на хранение параметров квантизации. В обычных методах эти «служебные» биты съедают 1–2 бита на число — при 3-битной квантизации это колоссальные накладные расходы.

Шаг 2: QJL — коррекция ошибок за 1 бит

После PolarQuant остаётся небольшая ошибка. QJL (Quantized Johnson-Lindenstrauss) — алгоритм, который использует математическое преобразование Джонсона–Линденштрауса для сведения остаточной ошибки к нулевому смещению, тратя на это всего 1 дополнительный бит.

Если PolarQuant — это основной «сжиматель», то QJL — это математический «корректор», который гарантирует, что attention-скоры модели остаются точными. Вместе они дают 3-битное представление, которое математически доказано как близкое к теоретическому пределу сжатия (с точностью до константы ~2,7).

Чем TurboQuant отличается от обычной квантизации

Если вы запускаете модели через llama.cpp, Ollama или LM Studio, вы уже используете квантизацию — те самые Q4, Q5, Q8 в названиях файлов. Но это квантизация весов модели. TurboQuant работает с совершенно другой сущностью.

Квантизация весов (GPTQ, AWQ, GGUF) — сжимает параметры модели один раз перед запуском. Чем меньше бит — тем хуже качество. Иногда требует калибровки или дообучения.

TurboQuant — сжимает KV-кеш (промежуточные вычисления) на лету во время работы. При 3,5 битах — нулевая потеря качества. Не требует дообучения вообще.

Эти подходы комплементарны. Вы можете использовать Q4-квантизированную модель И TurboQuant-сжатый KV-кеш одновременно. Одно не заменяет другое — они сжимают разные части системы.

TurboQuant на практике: MacBook, видеокарты и облако

Если у вас MacBook или обычный ПК

Энтузиасты уже запустили Qwen 3.5 9B на обычном MacBook Air M4 (16 ГБ) с контекстом 20 000 токенов — раньше на таком железе длинные контексты были невозможны. Не MacBook Pro, не Mac Studio — обычный Air, самая дешёвая конфигурация. В Reddit-треде есть видео-демо.

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

Если у вас мощная видеокарта

Один из разработчиков рассчитал для модели 70B Q4_K_M с 34 ГБ свободной VRAM под KV-кеш:

• Без TurboQuant (FP16 KV-кеш): ~109K токенов контекста
• С Q8 KV-кешем: ~218K токенов
• С TurboQuant TQ3 (3 бита): ~536K токенов
• Полное окно контекста 262K легко помещается на 3× RTX 3090

Если вы разрабатываете ИИ-продукты

• В 5–6 раз меньше GPU-памяти на инференс при длинных контекстах
• До 8× ускорение attention на H100
• Снижение стоимости обслуживания каждого запроса к LLM

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

TurboQuant в llama.cpp, MLX и PyTorch: кто уже пробует

Прошло всего несколько дней с публикации, но Open Source сообщество уже на коне:

• llama.cpp — минимум 3 независимых реализации, обсуждение интеграции в основную ветку. Одна уже работает на Apple Silicon через Metal
• MLX (Apple Silicon) — разработчики адаптируют алгоритм для маков
• PyTorch + Triton — появились reference-реализации для CUDA-видеокарт
• C/CUDA — рабочая реализация с 18 из 18 пройденных тестов, MSE совпадает с бумагой

Пока реализации не оптимизированы. Бенчмарки показывают падение скорости генерации в 3–8 раз по сравнению с обычным Q8 KV-кешем. Причина — неоптимизированная операция поворота вектора. Разработчики уже работают над оптимизацией через преобразование Адамара.

Как попробовать TurboQuant прямо сейчас

Официального кода от Google нет, но сообщество уже сделало несколько рабочих реализаций. Вот как запустить TurboQuant на своём железе — три варианта в зависимости от платформы.

На Mac (Apple Silicon M1–M5)

Форк llama-cpp-turboquant от TheTom — самая зрелая реализация с Metal-ядрами для Apple Silicon. Работает на M1, M2, M3, M4, M5.

Флаг turbo3 включает 3,5-битную квантизацию KV-кеша (сжатие 4,6× vs FP16). На M5 Max 128 ГБ модель Qwen3.5-35B показывает 2747 tok/s на prefill — на уровне стандартного q8_0, при этом KV-кеш занимает в 4,6 раза меньше памяти.

На PC с видеокартой NVIDIA или AMD

Форк llama-turboquant поддерживает CUDA и ROCm. Тип кеша здесь называется tq3_0 (вместо turbo3).

Python (для исследований и экспериментов)

turboquant-pytorch — reference-реализация на PyTorch. Подойдёт для изучения алгоритма и проверки сжатия на своих моделях.

Ollama и LM Studio пока не поддерживают TurboQuant — они используют свои сборки llama.cpp, в которые метод ещё не влит. Но можно поднять llama-server из форка выше и подключиться к нему как к OpenAI-совместимому API.

Бенчмарки TurboQuant: результаты из бумаги и от сообщества

Из бумаги Google (тестировалось на Gemma и Mistral):

• LongBench, Needle in a Haystack, ZeroSCROLLS, RULER, L-Eval — при 3,5 битах «абсолютная нейтральность качества»
• При 2,5 битах — «маргинальная деградация»
• 4-bit TurboQuant: ускорение attention до 8× на H100 по сравнению с 32-bit baseline
• Сжатие KV-кеша минимум в 6 раз

Из независимых реализаций:

• TQ3 (3 бита): MSE = 0,034, сжатие 4,9× vs FP16
• TQ4 (4 бита): MSE = 0,009, сжатие 3,8× vs FP16
• Размер блока: 52 байта на 128 значений (для TQ3)

Почему TurboQuant обвалил акции Micron — и стоит ли переживать

Рынок отреагировал панически: Micron −25%, Samsung −4,7%, SK Hynix −6,2%. Но аналитики Morgan Stanley, JPMorgan, Citigroup и Goldman Sachs единодушны — реакция чрезмерна. Вот почему:

1. TurboQuant не трогает обучение. HBM-память, основной драйвер прибыли чипмейкеров, нужна для обучения моделей. TurboQuant сжимает только инференс
2. Это исследование, не продукт. Официального кода от Google нет, эксперименты на моделях ~8B параметров
3. Прецедент DeepSeek. В январе 2025 тоже обвалили чипмейкеров — затем спрос только вырос
4. Фиксация прибыли. Micron был +300% за год, Samsung +200%. Инвесторы искали повод зафиксировать прибыль

Если TurboQuant снизит операционные расходы на ИИ до одной шестой от текущего уровня, компании, которые до сих пор не внедряли ИИ из-за высокой стоимости, войдут в ИИ-экосистему.

Подробнее о реакции рынка — в нашей новости.

Часто задаваемые вопросы

Чем TurboQuant отличается от GGUF/GPTQ/AWQ?
GGUF, GPTQ и AWQ сжимают веса модели (параметры). TurboQuant сжимает KV-кеш — временную рабочую память, которая используется во время инференса. Эти подходы дополняют друг друга.

Можно ли уже использовать TurboQuant?
Экспериментально — да. Несколько независимых реализаций для llama.cpp и MLX уже работают. Но в основную ветку llama.cpp и в Ollama/LM Studio метод пока не интегрирован. Ожидается в ближайшие недели–месяцы.

Нужно ли переобучать модель для TurboQuant?
Нет. TurboQuant — data-oblivious метод, который применяется к любой существующей LLM без дообучения и без калибровочных данных.

TurboQuant: итоги и выводы

• TurboQuant — прорыв в сжатии KV-кеша, но не «убийца GPU» и не «конец эпохи дорогого железа»
• Работает вместе с обычной квантизацией весов, а не вместо неё
• Реально позволяет запускать более длинные контексты на том же железе — в 5 раз длиннее
• Сообщество уже пишет реализации для llama.cpp и MLX
• До полноценного внедрения в популярные инструменты — недели или месяцы
• Обвал акций — чрезмерная реакция, аналитики рекомендуют покупать на падении

Следите за GitHub-дискуссией в llama.cpp — именно там появится рабочая реализация для повседневного использования. А блог Google Research и бумага на arXiv — для тех, кто хочет погрузиться в математику.