Для программиста, который уже работает с агентами, это готовая замена самодельным файлам с инструкциями и длинным описаниям задачи в чате. Вместо «сделай мне функцию экспорта» агент получает конституцию проекта, спеку с пользовательскими историями, технический план и список задач в репозитории, и каждый шаг можно прочитать и поправить до того, как появится код. За год к базовой цепочке добавились команда сверки кода со спекой, расширения для багфикса и оценки идей, пресеты под стандарты команды и бандлы под роли. Spec Kit при этом не единственный репозиторий такого рода в топе GitHub: за ту же неделю звёзды собирали ещё десять проектов про агентов, от скиллов и надстроек над Claude Code и Codex до локального инференса и управления Blender; они разобраны во второй части.

• Spec Kit 1.0.0 вышел 21 августа 2026 года, текущий релиз 1.0.6 от 10 сентября; между ними шесть патч-релизов.
• Ставится через uv или с PyPI, командой specify init подключается к проекту под любой из более чем 30 агентов.
• Цепочка из шести слэш-команд: constitution, specify, plan, tasks, implement, converge; последняя сверяет код со спекой и дописывает недостающие задачи.
• Расширение bug ведёт исправление по шагам «оценить, починить, проверить», assess разбирает идею до решения «делать» или «не делать».
• Мейнтейнер пишет, что 1.0 больше не обещает стабильности API: ломающие изменения агент теперь переносит сам.
• Среди набравших звёзды за неделю: ponytail (135 тысяч, режет объём кода агента на 54% в замере автора), ECC (256 тысяч), skills (259 тысяч), humanizer (46 тысяч), archify (57 тысяч), HyperFrames, MiniMind, Magnitude, SGLang и blender-mcp.

Что такое Spec Kit и как он работает?

Spec Kit это утилита specify на Python плюс набор markdown-шаблонов и скриптов, которые она раскладывает в проект. После specify init в каталоге агента (например, .claude/ или .github/) появляются слэш-команды или скиллы с префиксом speckit, а в .specify/ лежат шаблоны документов. Дальше вся работа идёт внутри привычного агента.

Базовая цепочка описана в README репозитория и состоит из шести шагов. /speckit.constitution один раз на проект фиксирует принципы: стек, стиль, что запрещено. /speckit.specify превращает описание задачи в спеку с требованиями и пользовательскими историями, /speckit.plan пишет технический план под выбранный стек, /speckit.tasks режет план на задачи, /speckit.implement их выполняет. Замыкает цикл /speckit.converge: команда сравнивает кодовую базу со спекой, планом и задачами и дописывает в список то, что ещё не сделано. Шаги implement и converge повторяются, пока converge не сообщит, что всё сошлось.

Есть три необязательные команды. /speckit.clarify вытаскивает недосказанное из спеки вопросами, её рекомендуют запускать до плана. /speckit.analyze ищет расхождения между спекой, планом и задачами после tasks и до implement. /speckit.checklist генерирует чек-листы качества требований, в документации их называют «юнит-тестами для английского языка». Команда /speckit.taskstoissues, которая раскладывает задачи в GitHub Issues, в релизе 1.0.5 помечена как уходящая из ядра в отдельное расширение github-issues; пока она работает.

Что изменилось к версии 1.0?

Год назад Spec Kit был набором шаблонов под несколько команд и несколько агентов. К 1.0 вокруг ядра выросла система настройки из четырёх слоёв. Внизу ядро с встроенными командами и шаблонами, выше расширения, которые добавляют новые команды, ещё выше пресеты, которые переписывают шаблоны ядра и расширений, а на самом верху локальные правки конкретного проекта в .specify/templates/overrides/. Шаблоны разрешаются во время выполнения сверху вниз, побеждает первое совпадение.

Два расширения идут в комплекте и включаются по желанию. specify extension add bug добавляет цепочку из трёх команд для исправления ошибок: assess проверяет диагноз по отчёту, fix чинит именно найденную причину, test подтверждает, что исходный симптом исчез. Авторы объясняют это тем, что агент, который прыгает от баг-репорта сразу к патчу, часто чинит не то. Расширение assess работает ещё до спеки: intake, research, define, shape, decide, на выходе документированное решение «делать», «нужны уточнения» или «не делать». Идею с решением «делать» можно передать в /speckit.specify.

Пресеты ставятся командой specify preset add и меняют форму, а не набор возможностей: например, требуют в спеке трассируемость под регуляторику, добавляют обязательный этап проверки безопасности в план, переставляют задачи так, чтобы тесты шли первыми, или переводят весь процесс на другой язык. Бандлы собирают расширения, пресеты, шаги и рабочие процессы в один версионированный набор под роль: продакт-менеджер, аналитик, исследователь безопасности, разработчик. Ставится бандл одной командой specify bundle install, каталог бандлов у проекта свой, поверх пользовательского и встроенного. В релиз-нотах 1.0.x рядом с исправлениями регулярно идут обновления расширений сообщества, например Jira Mirror в 1.0.2, и правки в загрузчике бандлов.

Список агентов вырос до более чем 30. Для части из них, включая Claude Code, Codex CLI, Copilot и Devin, команды ставятся как скиллы, а не как файлы промптов, и вызываются как /speckit-specify или $speckit-specify, в зависимости от агента. Для остальных остаётся режим слэш-команд; переключатель --integration-options="--skills" есть у тех, кто поддерживает оба.

Почему 1.0 больше ничего не обещает?

Ведущий мейнтейнер проекта в записи к годовщине прямо говорит, что единица в номере версии здесь только число. Раньше мажорная версия была страховкой от стоимости изменений: ломающее изменение означало ручной обход всех мест вызова по гайду миграции, и семантическое версионирование превращало эту стоимость в сигнал. Теперь, по его словам, адаптация к ломающему изменению это одно предложение агенту, который правит места вызова быстрее, чем автор успевает описать их в changelog. Поэтому 1.0.0 у Spec Kit значит «хорошее место, чтобы начать», а не обещание замороженной формы. Это заявление проекта о себе, и для команд, которые встраивают Spec Kit в CI и внутренние инструменты, оно означает, что пинить версию всё равно придётся: за три недели после 1.0.0 вышло шесть патч-релизов.

Как установить и с чего начать?

В README рекомендуют менеджер uv, альтернатива pipx. Установка идёт с привязкой к тегу релиза, тег с ведущей буквой v, либо из PyPI, где пакет specify-cli обновлён до 1.0.6. Проверить, не вышла ли новая версия, можно командой specify self check.

Ключ --integration принимает имя агента из списка интеграций, например copilot, claude, codex, cursor-agent или gemini; полный перечень выдаёт specify integration list. Дальше запускается сам агент в каталоге проекта, и цепочка начинается с /speckit.constitution.

Кому это не нужно?

Spec Kit не единственный инструмент такого рода. Kiro от AWS делает то же самое внутри собственной IDE на базе VS Code, у Tessl это CLI и MCP-сервер к разным ассистентам, а сам фреймворк на момент разбора был в закрытой бете; в разборе трёх подходов на сайте Мартина Фаулера Spec Kit выделяют как самый агентонезависимый: это markdown и скрипты в репозитории, которые легко править. Обратная сторона та же: спека, план и задачи это документы, которые кто-то должен читать, и для правки в одну функцию цепочка из шести команд избыточна. Авторы и сами пишут в README, что не каждое изменение проходит полный цикл: небольшие исправления идут обычным путём через issue, pull request, ревью и тесты.

Какие ещё репозитории про ИИ-агентов набирали звёзды на этой неделе?

Подборку из десяти репозиториев, которые «за неделю разом собрали звёзды», опубликовал 10 сентября японский аккаунт So AInsight; прирост за неделю там не приведён, поэтому ниже суммарное число звёзд на 11 сентября по данным GitHub. Половина списка про то же, что и Spec Kit: как заставить агента работать по процессу, а не по настроению; остальное про инференс, обучение и управление другими программами.

1. skills, 259 тысяч звёзд. Скиллы Мэтта Покока, автора Total TypeScript, из его рабочего каталога .agents: небольшие, составные, под любую модель. В README автор прямо противопоставляет их Spec Kit, GSD и BMAD: те, по его словам, забирают процесс себе и делают ошибки в нём трудноразрешимыми.
2. ECC, 256 тысяч. Надстройка над Claude Code, Codex, OpenCode и Cursor с циклом «план, тест, реализация, ревью из свежего контекста, проверка, память, улучшение». Репозиторий под MIT, у автора есть платная версия ECC Pro как GitHub App для приватных репозиториев от $19 за место в месяц.
3. ponytail, 135 тысяч. Скилл, который заставляет агента думать «как самый ленивый сеньор»: перед кодом пройти лестницу из семи вопросов, от «нужно ли это вообще» до «есть ли это в стандартной библиотеке». Автор замерил на Claude Code и репозитории full-stack-fastapi-template по 12 тикетам: минус 54% строк, минус 22% токенов, минус 20% стоимости против агента без скилла; ранние цифры «на 80–94% меньше кода» он сам признал завышенными из-за некорректной базы.
4. archify, 57 тысяч. Скилл для Cursor, Claude Code, Codex CLI и OpenCode: агент описывает систему типизированным JSON, Node.js-компилятор превращает его в самодостаточный HTML с интерактивной схемой архитектуры, последовательности или потока данных, экспорт в PNG, SVG и WebM. Умеет сравнивать два снимка архитектуры до и после изменения.
5. humanizer, 46 тысяч. Скилл на чистом markdown, который переписывает текст агента так, чтобы в нём не было характерных следов машинного письма, без изменения смысла; ставится через npx skills add blader/humanizer или как плагин Claude Code.
6. HyperFrames, 49 тысяч. Проект HeyGen: пишешь HTML, получаешь видео. Рассчитан на агентов, которым нужно генерировать ролики с диаграммами и озвучкой без съёмки; TypeScript, Apache 2.0, Node 22 и новее.
7. MiniMind, 61 тысяча. Учебный проект: обучить языковую модель на 64 млн параметров с нуля на чистом PyTorch. Заявленные «2 часа» и «3 юаня» это оценка автора для одного прохода предобучения и дообучения минимальной версии на одной RTX 3090 и аренда GPU на это время; в репозитории полная цепочка от предобучения до DPO, GRPO и агентного RL, плюс версии с картинками и диффузией.
8. Magnitude, 4 тысячи. Локальный движок инференса: профилирует машину (Mac, NVIDIA, AMD или только CPU), подбирает подходящие модели, скачивает, настраивает и запускает их. Единственный проект списка с числом звёзд в тысячах, а не десятках тысяч.
9. SGLang, 36 тысяч. Зрелый фреймворк раздачи больших языковых и мультимодальных моделей под нагрузкой, существует с января 2024 года; в список попал, судя по всему, из-за очередного всплеска интереса, а не как новинка.
10. blender-mcp, 28 тысяч. MCP-сервер и аддон, через которые любая модель управляет Blender: создание сцен, моделирование и расстановка объектов по текстовому запросу. Сторонний проект, к Blender Foundation отношения не имеет, о чём README предупреждает отдельно.

Общий знаменатель списка тот же, что у Spec Kit 1.0: скиллы и надстройки, которые фиксируют процесс работы агента в репозитории, стали отдельной категорией инструментов, и у неё уже есть внутренняя полемика. Spec Kit и ECC предлагают полный цикл, skills и ponytail дают отдельные небольшие правила, которые сочетаются с чем угодно. Что выбирать, зависит от размера задачи: для мелких правок цепочка из шести команд избыточна, для новой функции с несколькими файлами спека и план окупаются тем, что их можно прочитать до кода.

Что смотреть дальше у Spec Kit: вынос /speckit.taskstoissues в расширение github-issues и следующие патч-релизы: между 1.0.1 и 1.0.6 паузы были от нескольких часов до десяти дней. Раздел экспериментальных целей из README никуда не делся, сроков по 1.1 или 2.0 GitHub не называет.

Источники: GitHub: репозиторий github/spec-kit, Релиз Spec Kit v1.0.0, Релиз Spec Kit v1.0.6, Manorrock: Spec Kit Turns One — and Ships 1.0.0, Документация: поддерживаемые агенты, Martin Fowler: Understanding Spec-Driven Development: Kiro, Spec-Kit, and Tessl, So AInsight в X: десять ИИ-инструментов, собравших звёзды на GitHub за неделю, GitHub: mattpocock/skills, GitHub: affaan-m/ECC, GitHub: DietrichGebert/ponytail, GitHub: tt-a1i/archify, GitHub: blader/humanizer, GitHub: heygen-com/hyperframes, GitHub: jingyaogong/minimind, GitHub: magnitudedev/magnitude, GitHub: sgl-project/sglang, GitHub: ahujasid/blender-mcp

Изображение на обложке: Логотип: GitHub

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

Поддержка inotify появилась в ядре и стандартной библиотеке libc. Приложения могут получать уведомления об изменениях в файловой системе, не открывая каждый отслеживаемый файл. Это упрощает перенос программ, которые используют такой API в Linux; речь о совместимости исходников, а не о гарантированном запуске готовых Linux-приложений.

Для Clang изменили выбор линкера по умолчанию: теперь используется ld.lld вместо поиска линкера по имени ld. В math.h также стали доступны тригонометрические функции стандарта C23 с множителем π, в том числе sinpi и cospi.

Изменения затронули и командную строку. Утилита pwd по умолчанию работает в режиме -L, а не -P, как требует POSIX: при выводе пути сохраняются символические ссылки. Размер истории sh по умолчанию увеличили со 100 до 128 записей. Эти и другие изменения перечислены в примечаниях к выпуску.

Разработчики подчёркивают, что в 14.5 основной акцент сделан на исправлениях и обновлении компонентов. Уже доступны установочные образы и образы виртуальных машин. Поддержка FreeBSD 14.5 продлится до 30 июня 2027 года.

Это разворот истории двухнедельной давности. 24 августа X Corp разослала претензии с требованием навсегда закрыть инстансы Nitter и сам репозиторий проекта. Тогда nitter.net ушёл в офлайн, разработка остановилась, а автор написал, что ищет юридической помощи и не будет комментировать детали, поблагодарив всех, кто пользовался, хостил, паковал и поддерживал проект семь лет.

• Nitter не закрывается: решение принято после консультации с юристами, детали не раскрыты.
• nitter.net и другие инстансы обещают поднять «в ближайшее время», официальный анонс в течение недели.
• Претензии X Corp от 24 августа требовали удалить и инстансы, и репозиторий на GitHub; репозиторий остался на месте.
• Инстанс xcancel.com, по данным обсуждения на Hacker News, возобновил работу.
• Nitter проксирует все запросы через свой бэкенд: клиент не обращается к X напрямую, поэтому X не видит его IP и отпечаток браузера.

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

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

Nitter вдохновлён Invidious, альтернативным интерфейсом YouTube. По README, запросы к X проходят через сервер инстанса, а браузер читателя не обращается к X напрямую. Это не даёт X получить IP-адрес читателя через прямое соединение и JavaScript-отпечаток из интерфейса Nitter. При этом читатель всё равно подключается к выбранному серверу Nitter. Описание архитектуры не следует понимать как обещание анонимности перед владельцем этого сервера.

Что это значит для тех, кто читает X через Nitter

README указывает, что Nitter использует неофициальный API X и не требует аккаунта разработчика. Работа фронтенда зависит от ответов платформы, а работа конкретного сайта ещё и от его конфигурации. Требования X Corp от 24 августа касались как инстансов, так и репозитория. Источники не устанавливают, были ли это первые юридические претензии такого рода, и не дают основания объявлять конфликт завершённым.

Для собственного инстанса README описывает сборку на Nim и образ zedeus/nitter. Нужны библиотеки libpcre, libsass и Redis либо Valkey для кеширования. Параметры задаются в nitter.conf; для Docker Compose документация также описывает подключение sessions.jsonl. Перед возобновлением публичного сервиса стоит прочитать обещанное автором объяснение юридической ситуации.

Сообщение на nitter.net обещает возвращение сервиса, но само по себе не подтверждает доступность всех страниц. Обсуждение на Hacker News содержит сообщения о работе xcancel.com; это наблюдение участников, которое не описывает весь набор инстансов. У пользователя могут отдельно работать чтение профиля и не работать RSS. Проверять следует нужную операцию на выбранном сервере.

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

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

В инструкции для хостеров есть отдельная оговорка о контейнерах: файлы конфигурации нужно создать до запуска. Если подключаемого файла нет, Docker может создать вместо него каталог, после чего контейнер завершится с ошибкой типа пути. Это относится к nitter.conf и, в примере Docker Compose, к sessions.jsonl. Поэтому ошибка запуска после восстановления инстанса может быть локальной проблемой конфигурации; её нельзя автоматически приписывать новому ограничению X.

README рекомендует запускать Nitter за обратным прокси, например Nginx или Apache. В nitter.conf задаются имя хоста, порт, HMAC-ключ, настройки HTTPS и кеша. Для диагностики документация предлагает смотреть стандартный вывод через журнал systemd либо логи контейнера. Эти инструкции остаются в репозитории, но их наличие не подтверждает, что любой вновь поднятый публичный сервер уже защищён от юридических требований.

Какие возможности уже есть и чего ждать дальше?

В README перечислены темы оформления, адаптивный интерфейс для мобильных экранов и лицензия AGPLv3. Отдельно в планах стоят система аккаунтов с хронологической лентой и архивирование постов и профилей. Их не следует считать уже доступными функциями возвращающегося сайта. В ближайшем анонсе стоит искать условия продолжения работы, а доступность нужного инстанса проверять отдельно. О другой истории с ограничениями платформ мы писали после удаления uBlock Origin из Chrome Web Store.

Источники: Репозиторий zedeus/nitter на GitHub, README, nitter.net: Cease and desist – UPDATE Sep 7th, Обсуждение на Hacker News: Nitter and XCancel resume service after legal advice

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

Для тех, кто уже пользуется jj, это закрывает самую неприятную бытовую проблему инструмента, а два ломающих изменения в том же релизе стоит проверить сразу после обновления: команды jj config с флагом --user больше не спрашивают, какой файл править, а jj git import перестал подтягивать коммиты из отсоединённого HEAD в репозиториях без совмещения с Git. Предыдущая версия 0.44.0 выходила 6 августа, релизы у проекта идут примерно раз в месяц.

• jj converge заменяет две и больше видимых ревизии одного change ID одним коммитом; потомки перебазируются на решение, локальные закладки переезжают сами.
• Если эвристики не уверены, команда задаёт вопросы: слить описания, выбрать родителей, редко выбрать автора; в режиме --no-interactive операция прерывается, если нужен вопрос пользователю.
• Ломающее: jj config edit/set/unset --user теперь правит первый загруженный пользовательский конфиг, для точного выбора файла добавлен --file ПУТЬ.
• Ломающее: jj git import в неколоцированных репозиториях больше не импортирует коммиты с отсоединённого Git HEAD.
• Git HEAD теперь хранится отдельно для каждого worktree, существующие репозитории мигрируют автоматически; исправлен баг с duplicateEntries в git fsck после git add.

Откуда в jj берутся расходящиеся коммиты

В jj у каждого изменения есть постоянный change ID, который переживает перезапись коммита: можно поправить старый коммит в середине стека, и потомки перебазируются автоматически. Расхождение, или divergence, возникает, когда одно и то же изменение оказалось переписано дважды по разным веткам истории операций. Типичный сценарий: правка в двух рабочих пространствах, откат через jj undo после того, как часть работы уже ушла дальше, или неудачный конфликт при синхронизации с удалённым Git-репозиторием. В логе это выглядит как два коммита с одинаковым change ID, и до 0.45 их приходилось сводить руками через jj abandon, jj squash и jj rebase.

Что делает jj converge на самом деле

По описанию команды в исходниках, jj converge берёт ревизии из аргумента --revisions или из настройки revsets.converge, группирует их по change ID и считает расходящимися те группы, где ревизий больше одной. Если расходящихся изменений несколько, команда спросит, какое сводить. Дальше она применяет эвристики, чтобы собрать новую ревизию, а если те дали неоднозначный результат, задаёт вопросы: объединить ли описания, каких родителей выбрать и, в редких случаях, кого считать автором.

Когда решение найдено, новая ревизия заменяет расходящиеся, потомки перебазируются на неё, а локальные закладки, указывавшие на любую из старых версий, переезжают на новую. Два ограничения авторы оговаривают прямо. Во-первых, сводятся только ревизии, попавшие в revset: если у того же change ID есть видимые версии вне выборки, расхождение уменьшится, но не исчезнет. Во-вторых, в результате могут появиться файловые конфликты, даже если до этого их не было. Проверить, что именно сделала команда, можно через jj op show -p, посмотреть историю изменения через jj evolog, а откатить всё одним jj undo.

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

Что сломается после обновления

Первое ломающее изменение касается конфигов. Раньше jj config edit --user, set --user и unset --user при нескольких пользовательских файлах, например ~/.config/jj/config.toml плюс каталог conf.d/, спрашивали, какой файл править. Теперь они молча берут первый загруженный. Если у вас конфиг разложен по нескольким файлам, нужный указывается явно:

Второе касается репозиториев, где jj живёт рядом с Git, но не в колоцированном режиме, то есть .jj и .git не делят один рабочий каталог. jj git import в них больше не импортирует коммиты с отсоединённого Git HEAD. Если рабочий процесс опирался на то, что jj подхватит коммит, сделанный в Git в состоянии detached HEAD, теперь такой коммит нужно закрепить веткой или тегом на стороне Git.

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

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

• В колоцированных репозиториях git add после команды jj больше не оставляет в индексе устаревший cache-tree, из-за которого git fsck ругался на duplicateEntries. Уже испорченные репозитории исправление не лечит.
• Ctrl+C в пейджере less теперь выходит чисто: во флаги по умолчанию добавили -K, раньше терминал мог остаться в raw-режиме с мусором из escape-последовательностей.
• Сторона конфликта, оканчивающаяся на символ возврата каретки, больше не теряет этот байт при повторном разборе материализованного конфликта.
• jj run останавливается на первой ревизии, где процесс завершился с ненулевым кодом, вместо того чтобы идти дальше.
• Набор immutable_heads() по умолчанию теперь включает untracked_remote_tags(); jj bisect предупреждает, когда из-за пропусков не может однозначно назвать первую плохую ревизию; починен краш jj log на скрытых ревизиях с revset log-graph-prioritize.

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

Готовые сборки для Windows, macOS и Linux лежат на странице релиза, вариант с musl должен работать на любом дистрибутиве. По документации установить последний релиз можно так:

Кому обновление ничего не изменит: тем, кто держит jj в одном файле конфига и работает только в колоцированных репозиториях. Им достанется jj converge и исправления, а ломающие изменения не затронут. Следующий сигнал, за которым стоит следить, это планируемая поддержка нескольких Git worktree, под которую в 0.45 подготовили хранение HEAD.

Источники: Релиз jj v0.45.0 на GitHub, Документация: установка и настройка jj 0.45, Исходник команды converge (описание в cli/src/commands/converge.rs)

Изображение на обложке: Логотип: J. Jennings, CC BY 4.0

Кому это важно: тем, кто много лет копил историю перемещений в Google Timeline и после переноса её на устройство ищет, где хранить данные самому. Импорт Google Takeout в Dawarich есть, а с новой отрисовкой многолетний архив перестаёт быть проблемой для интерфейса. Проект написан на Ruby on Rails с PostgreSQL и ставится через Docker; на сайте указано больше 9000 звёзд на GitHub.

• Точки, треки, маршруты и слои «тумана войны» теперь отдаются через map tiles; 957 350 точек за меньше чем секунду, JSON с 590 МБ до 150 КБ.
• Для перетаскивания точек на карте новый режим нужно отключить.
• Определение посещений (visit detection) переписано с нуля; метаданные устройств перенесены в таблицу point_sources.
• OwnTracks в HTTP-режиме показывает членов семьи на карте; перелёты из AirTrail считаются отдельно от треков Dawarich.
• Self-hosting бесплатен со всеми функциями; облако: Lite 59,99 евро в год (12 месяцев истории, 200 запросов API в час), Pro 149,99 евро (бессрочная история, 1000 запросов в час), Family 299,99 евро (до 5 человек).

Почему тайлы решают проблему миллиона точек

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

Автор пишет, что за месяц вышло девять релизов, и называет результат «немного безумным» (перевод редакции). Для админа, который держит Dawarich на маломощном VPS или Raspberry Pi, важно другое: девять релизов за месяц означают частые миграции базы, и перед каждым обновлением нужен бэкап PostgreSQL.

Что ещё изменилось в 1.14.1

• Метаданные устройств перенесены в таблицу point_sources: миграция базы при обновлении обязательна, перед ней нужен бэкап PostgreSQL.
• Импорт OwnTracks исправлен для массивов PostgreSQL; повреждённая или обрезанная загрузка теперь отклоняется без ошибки сервера.
• Расстояние перелётов из AirTrail считается отдельно от расстояния, записанного трекером.
• Интерфейс переведён на шесть языков: английский, немецкий, испанский, французский, польский и каталанский; следующим заявлен упрощённый китайский. Русского перевода нет.

Self-hosting или облако

Self-hosted версия бесплатна и включает всё, что есть в платных тарифах, ограничения только у облачного варианта: Lite за 59,99 евро в год хранит 12 месяцев истории и даёт 200 запросов API в час, Pro за 149,99 евро снимает лимит истории и поднимает потолок до 1000 запросов, Family за 299,99 евро рассчитан максимум на пять участников. Условия оплаты облака по регионам проект не описывает; self-hosting от них не зависит.

Что проверить перед обновлением: сделать дамп базы, обновить образ Docker до 1.14.1, дождаться миграций и убедиться, что карта показывает точки в новом режиме. Кому релиз не нужен: тем, у кого история перемещений измеряется тысячами точек, а не сотнями тысяч; для них разница будет незаметна. О другом свежем self-hosted проекте того же класса мы писали на примере Home Assistant 2026.9; о хранении резервных копий такого рода данных есть разбор про бэкапы в S3.

Источники: Пост разработчика в r/selfhosted, Релиз 1.14.1 на GitHub, Сайт проекта

Для владельца MacBook это означает модель класса, который раньше требовал 128 ГБ памяти или сервера с несколькими GPU. Цена: скорость обработки промпта. По замерам автора, 8000 токенов контекста обрабатываются около 39 секунд, 32 000 около трёх минут, а полный контекст ограничен 32 768 токенами. Проект молодой (246 звёзд на GitHub на момент разведки), работает только на Apple Silicon с macOS 14 и требует около 110 ГБ свободного места на SSD.

• Модель: Qwen3.8-Flash-Next, 125 млрд параметров, 512 экспертов на слой, 10 активных на токен; веса 4 бита, 103,77–105,3 ГБ на диске.
• Память: постоянно загружено 3,8 ГБ, процесс на 48-гигабайтном Mac занимает около 33 ГБ; запуск движка около 2 секунд.
• Скорость на M5 Pro с 48 ГБ: около 12 токенов в секунду генерации; промпт 8000 токенов около 39 секунд, 32 000 около 3 минут; контекст до 32 768 токенов.
• Требования: Apple Silicon, macOS 14 и новее, около 110 ГБ на SSD; Linux, Windows и дискретные GPU не поддерживаются.
• API совместим с Ollama и OpenAI: работают curl, Open WebUI и OpenAI SDK; в slotstream 0.2.0 подключение Ollama CLI ещё не работало. Лицензия MIT.

Как 105 ГБ помещаются в 48

Qwen3.8-Flash-Next устроена как mixture of experts: в каждом слое 512 экспертов, но для одного токена активируются только 10. Значит, в каждый момент нужна малая часть весов. Эксперты занимают 67,9 ГБ, ещё 32 ГБ уходит на хранилище n-gram и PLE. slotstream держит фиксированный пул слотов в памяти и подгружает нужных экспертов с SSD системным вызовом pread, а не отображает всю модель через mmap. Постоянно в памяти живут только общие части модели, 3,8 ГБ.

Автор описывает, почему очевидные способы не сработали. Обычный загрузчик на 48-гигабайтном Mac уходил примерно в 48 ГБ подкачки и завершался до первого токена. Ленивый mmap тоже не спасал: после короткого промпта резидентная память приближалась к 100 ГБ, потому что система не знает, каких экспертов можно выгрузить. Фиксированный пул решает это ценой того, что каждый новый эксперт читается с SSD, отсюда и медленная обработка длинного промпта: диск становится узким местом.

Что это значит на практике

12 токенов в секунду на генерации это скорость, при которой ответом можно пользоваться в чате. Проблема в prefill: минута ожидания на промпт средней длины и три минуты на длинный документ делают инструмент непригодным для RAG по большим контекстам и для агентов, которые постоянно перечитывают историю. Зато для разовых задач с коротким контекстом, где важно качество большой модели, а не отклик, это рабочий вариант на ноутбуке. Автор прямо пишет, что инструмент рассчитан только на Apple Silicon «и не случайно» (перевод редакции): расчёт на объединённую память и скорость встроенного SSD.

Как попробовать

1. Проверить требования: Apple Silicon, macOS 14 или новее, около 110 ГБ свободного места, желательно 48 ГБ памяти (на меньших объёмах автор замеров не приводит).
2. Собрать или скачать slotstream по инструкции в README; веса модели скачиваются отдельно, это около 105 ГБ.
3. Подключить любой клиент, понимающий API Ollama или OpenAI: Open WebUI, OpenAI SDK с локальным base_url или curl. в slotstream 0.2.0 Ollama CLI на момент публикации не подключался.
4. Сверить свои цифры с таблицами в MEASUREMENTS.md: там разложены память, ввод-вывод и время по этапам.

Кому это не подойдёт: владельцам Mac с 16–24 ГБ (замеров для них нет), пользователям Linux и Windows и всем, кому нужен быстрый prefill. Региональных ограничений у проекта нет, веса модели скачиваются из открытых источников. Что можно запустить дома на более скромном железе, мы собирали в обзоре открытых моделей августа; о том, во что обходится обработка длинного контекста у облачных моделей, есть разбор цен API за август.

Источники: Репозиторий slotstream, MEASUREMENTS.md: замеры памяти и скорости

Ошибка проявляется только там, где FMA эмулируется программно: на x86 это дешёвые или старые Intel без AVX2 и процессоры Hygon без аппаратного FMA, а также 32-битный ARM и старые встраиваемые тулчейны. 64-битный ARM, по словам автора, не затронут. На практике это касается детерминированных симуляций и численных библиотек, где одинаковый код обязан давать одинаковые биты на разных машинах: сетевые игры с lockstep, физические движки, воспроизводимые вычисления. Автор честно пишет, что не знает, насколько ошибка важна в реальных программах.

• Ошибка: неправильное округление fmaf на субнормальных входах, отличие на один младший бит.
• Затронуты f32::mul_add и std::simd в Rust, fmaf() в musl; проверка одна и та же: a = 0x97000800, b = 0x1cfff001, c = 0x00010002, верный ответ 0x00010001, ошибочный 0x00010002.
• Исправлены fearless_simd и ABI f128 в компиляторе Rust на 32-битном ARM; патч в стандартную библиотеку Rust на момент публикации ждал ревью, исправления musl не влиты.
• Аппаратный FMA (x86 с AVX2/FMA3, 64-битный ARM) не затронут: ошибка живёт в программной эмуляции.
• Контрпример к первой версии исправления в Rust нашла языковая модель, которую автор попросил искать ошибки.

Что такое FMA и откуда берётся лишний бит

Fused multiply-add вычисляет a*b+c с одним округлением в конце вместо двух: после умножения и после сложения. Так требует IEEE 754, и именно на это рассчитывают численные алгоритмы: одно округление даёт предсказуемую ошибку. Когда у процессора нет аппаратной инструкции, библиотека эмулирует FMA через операции с расширенной точностью и ручную коррекцию округления. Ошибка, которую нашёл автор, живёт в этой коррекции на субнормальных числах, то есть очень маленьких значениях, у которых часть мантиссы уже ушла в ноль. В таких случаях программная реализация округляла не в ту сторону.

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

Как проверить свою платформу

Достаточно трёх чисел. Ниже проверка на C для fmaf из системной libc; в Rust то же самое делается через f32::from_bits и mul_add:

Если вывод 00010002, ваша libc или тулчейн эмулируют FMA с ошибкой. На машине с аппаратным FMA (любой современный x86 с AVX2, 64-битный ARM) результат будет верным независимо от библиотеки, поэтому проверять имеет смысл именно сборки под старое или встраиваемое железо и контейнеры на musl (Alpine) на таких хостах.

Состояние исправлений

• fearless_simd: исправлено, можно использовать как реализацию FMA без этой ошибки.
• Rust, тип f128 на 32-битном ARM: ошибка ABI исправлена в компиляторе (тип доступен только в nightly).
• Стандартная библиотека Rust (f32::mul_add, std::simd): патч на момент публикации ожидал ревью; номер версии с исправлением не назван.
• musl: предложены минимальное исправление и полная переработка fmaf(), ни то ни другое не влито. Автор отмечает, что код FreeBSD, откуда растёт реализация, мог копироваться и в другие тулчейны.

Кому это ничего не меняет: сервисам на современных x86 и ARM64, где FMA аппаратный, и коду, не зависящему от битовой точности. Кому стоит проверить: авторам физических движков и симуляций с детерминизмом между машинами, разработчикам под 32-битный ARM и тем, кто собирает статические бинарники под musl для старых серверов. Про то, как выбор libc влияет на скорость тех же бинарников, мы писали на примере Rust Coreutils; смежная тема из этой же недели: переписывание линкера mold на Rust. Что мы проверим дальше: когда патч попадёт в стабильный Rust и появится ли исправление в релизе musl.

Источники: Shnatsel: Implementing FMA and finding bugs in C and Rust standard libraries, Обсуждение на Lobsters

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

• Mantis лежит на GitHub с июня 2026 года; 2 сентября Google выпустила гайд по запуску и представила скилл mantis-advise для безопасного написания нового кода.
• Конвейер состоит из 16 последовательных стадий плюс вспомогательные скиллы: от разбора истории коммитов и модели угроз до воспроизведения, патча и отчёта.
• Установка: git clone репозитория или npx skills add google/mantis; агент подойдёт любой, Google проверяла с Gemini CLI, Antigravity CLI и ADK.
• Воспроизведение и патчи выполняются только в песочнице без сети (gVisor с --network=none, microsandbox, VM); флаги вроде --yolo авторы прямо запрещают.
• Каждую находку должен подтвердить человек: README запрещает массово слать непроверенные ИИ-отчёты мейнтейнерам.

Что именно выложила Google и что в этом нового

Репозиторий google/mantis открыт не сегодня: первые коммиты датированы июнем 2026 года, и в заметке Google ссылается на июньское описание подхода. Новость в другом: компания впервые опубликовала пошаговый гайд «как начать», прямо заявила, что тот же промпт используется внутри Google для поиска реальных уязвимостей, и представила скилл mantis-advise, который появился в репозитории 28 августа. Последний коммит на момент публикации, от 3 сентября, ужесточает песочницы, разрешение путей и проверки конфигурации.

Главная претензия Google к «наивному» ИИ-сканированию кода, по словам авторов, в том, что доля настоящих находок у него часто ниже 7%, остальное галлюцинации. Mantis борется с этим двумя способами: отдельными агентами-критиками, которые отсеивают ложные срабатывания, и воспроизведением уязвимости в песочнице, которое служит опорой для оценки. При этом README оговаривает: неудачное автоматическое воспроизведение ещё не доказывает, что находка ложная. Цифра про 7% в заметке дана без ссылки на метод замера, так что это оценка компании, а не бенчмарк.

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

Как устроен конвейер из 16 стадий

По описанию архитектуры, Mantis состоит из отдельных скиллов, каждый из которых вызывается слэш-командой и передаёт результат следующему через файлы в каталоге workspace/. Стадии можно запускать по одной руками или отдать оркестратору /mantis-meta-agent, который крутит цикл и архивирует находки между проходами.

1. /mantis-history и /mantis-summarize разбирают историю VCS и пишут сводки по каталогам, а необязательный /mantis-structural-index строит индекс семантических единиц кода.
2. /mantis-architecture и /mantis-threat-model собирают базу знаний о сущностях, потоках данных и границах доверия.
3. /mantis-plan и /mantis-researcher составляют план проверки и ищут уязвимости файл за файлом.
4. /mantis-dedupe, /mantis-review и /mantis-critic склеивают дубли, отсеивают ложные срабатывания и проверяют, что падение воспроизводится в релизной сборке.
5. /mantis-reproduce пишет и запускает эксплойт в изолированной среде, /mantis-chain пробует собрать из находок многошаговую цепочку.
6. /mantis-patch чинит код и гоняет тесты в песочнице, /mantis-calibrate ставит риск от 1 до 10, /mantis-reflect и /mantis-report собирают уроки и итоговый отчёт.

Новый /mantis-advise стоит особняком: он не ищет уязвимости, а отвечает на вопрос «как безопасно менять этот файл». Скилл читает накопленную базу knowledge.db с моделью угроз, историей находок, подтверждёнными патчами и отсеянными ложными срабатываниями и выдаёт агенту рекомендации до и во время правок. Запускается он скриптом python3 reference/scripts/advise.py --file src/auth.py. Смысл в том, чтобы результаты аудита не лежали в отчёте, а мешали агенту повторять старые ошибки.

Как запустить у себя и почему только в изоляции

Установка по README сводится к клонированию репозитория или одной команде для менеджера скиллов:

Дальше Google предлагает открыть привычный кодинг-агент и написать ему буквально: «I would like to use Mantis framework in path/to/mantis to review my code in path/to/your/code, can you help me get started?». Конкретный агент не навязывается: в README сказано, что скиллы проверяли с Gemini CLI, Antigravity CLI, Google ADK и Antigravity SDK, но подойти должен любой фреймворк, понимающий слэш-команды и файлы SKILL.md. Модели тоже на выбор пользователя, причём авторы советуют не гонять самую дорогую модель на каждой стадии, а подбирать класс модели под задачу.

Самая жёсткая часть документации про изоляцию. README открывается предупреждением капслоком: конвейер генерирует и исполняет код, который может быть нестабильным, поэтому запускать его можно только в ограниченной среде, без доступа к продакшену, чувствительным данным и внутренней сети. Скиллы /mantis-reproduce и /mantis-patch по инструкции выполняют полезную нагрузку в контейнере с отключённой сетью, и для этого Google рекомендует gVisor:

Скилл /mantis-configure даёт выбор из четырёх режимов песочницы: static-only без исполнения кода, microsandbox, gvisor и gce с отдельной виртуальной машиной в облаке. Отдельно авторы просят начинать в интерактивном режиме, вызывая команды по одной и подтверждая каждое опасное действие, и не включать флаги автоодобрения вроде --yolo или --dangerously-skip-permissions. Гарантий при этом нет: в документации прямо сказано, что агент недетерминирован и может попытаться обойти ограничения, если среда это позволяет.

Что Mantis не обещает

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

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

Проект лежит в публичном репозитории на GitHub под Apache-2.0, региональная доступность отдельно нигде не оговорена, а модель и агент вы выбираете сами, в том числе локальные. Дальше стоит следить за тем, появятся ли независимые замеры доли ложных срабатываний: пока и 7%, и 85% экономии токенов остаются цифрами самой Google.

Источники: Getting started with Mantis, our open-source bug finding-and-fixing harness (Google Cloud Blog), Репозиторий google/mantis, README_AGENTS.md: архитектура конвейера Mantis, Скилл mantis-advise

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

Для тех, кто держит workspace на десятки пакетов, это ускорение pnpm install без изменений в конфигурации. Для пользователей Windows это ещё и конец .cmd и .ps1-обёрток: их заменяет .exe. Обратная сторона видна по патчу 12.3.1: обновление с 12.2 через self-update ломало миграцию старых shim, и это исправили в тот же день.

• Установка в больших workspace ускорена: lockfile читается во время discovery проектов, граф workspace обрабатывается один раз вместо полного копирования lockfile.
• Контекстно-зависимые глобальные команды и shim стали нативными исполняемыми файлами; в Windows .exe вместо .cmd и .ps1, старые shim мигрируют при следующей глобальной установке или self-update.
• Флаги доверия --trust-lockfile, --no-trust-lockfile, --trust-policy, --trust-policy-exclude и --trust-policy-ignore-after теперь работают и для remove и update.
• Исправлено зависание recursive run и exec, в том числе с --filter и --workspace-concurrency=1.
• Системный резолвер на Linux использует getaddrinfo и больше не должен молча обращаться к Google Public DNS при неподдерживаемой опции no_tld_query.

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

По заметкам к релизу, раньше pnpm сначала обходил все проекты workspace, а потом отдельно разбирал lockfile и копировал его целиком для резолвера. В 12.3 lockfile читается уже на этапе discovery, а граф workspace строится один раз и передаётся резолверу и генератору lockfile без полного копирования. Конкретных цифр ускорения команда pnpm в заметках не приводит, формулировка звучит как «sped up installs in large workspaces»; эффект тем заметнее, чем больше пакетов и чем толще lockfile.

Что изменилось для глобальных команд и Windows

pnpm умеет ставить node, deno и bun как глобальные команды, которые подбирают версию по контексту проекта. До 12.3 в Windows такие команды были скриптами .cmd и .ps1, а на других платформах shell-обёртками. Теперь везде это нативные исполняемые файлы. Старые shim от pnpm 12 мигрируют при следующей глобальной установке или self-update; именно этот переход и сломался при обновлении с 12.2, что исправили в 12.3.1: нативный shim теперь мигрирует при первом запуске.

Безопасность: trust-флаги и скрытие секретов

Механизм доверия к lockfile появился в pnpm 12 как защита от атак на цепочку поставок: пакеты, не прошедшие политику доверия, не ставятся. В 12.2 флаги были только у install и add; 12.3 добавляет их к remove и update. Второе изменение того же ряда: учётные данные и query-параметры из URL реестров теперь скрываются в сообщениях об ошибках fetch и загрузки tarball, так что токен приватного реестра больше не утекает в лог CI при обрыве соединения.

Исправления, которые стоит знать

• Добавление локальных директорий, tarball-файлов и tarball по URL через pnpm add снова работает.
• recursive run и recursive exec больше не зависают, включая варианты с --filter и --workspace-concurrency=1.
• Дочерние процессы в Windows запускаются корректно.
• Linux: системный резолвер переведён на getaddrinfo; при неподдерживаемой опции no_tld_query в resolv.conf pnpm больше не должен молча уходить к Google Public DNS, что важно в закрытых сетях и там, где внешние DNS фильтруются.
• 12.3.1: исправлены обработка workspace anchor и параллельная проверка lockfile.

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

Обновляться стоит сразу на 12.3.1, минуя 12.3.0. Если pnpm установлен через Corepack или npm i -g pnpm, обновление идёт обычным способом; если через self-update, после перехода с 12.2 стоит один раз запустить любую глобальную команду, чтобы shim мигрировал. Проверить, что всё на месте: pnpm --version должен показать 12.3.1, а pnpm shim ls (если пользуетесь shim) не должен ругаться на старые обёртки.

Кому обновление ничего не изменит: одиночным проектам без workspace и тем, кто не пользуется глобальными командами pnpm. Из соседних новостей про инструменты JavaScript на сайте: GitHub CLI 2.99 и Wasmi 2.0. Полный список изменений с номерами issue лежит на странице релиза.

Источники: pnpm v12.3.0 на GitHub, pnpm v12.3.1 на GitHub

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

До 1.37 для этого нужен был сторонний компонент либо alpha-гейт. Теперь это часть ядра, и владельцы очередей и batch-обработчиков могут перестать платить за поды, которые часами ждут задач. Экономия заметнее всего там, где под резервирует дорогие ресурсы: выделенные ядра или GPU. Обычным HTTP-сервисам функция не подходит в чистом виде, и авторы предупреждают об этом прямо.

• Beta по умолчанию: feature gate HPAScaleToZero включён и в kube-apiserver, и в kube-controller-manager Kubernetes 1.37.
• minReplicas: 0 работает только с объектной или внешней метрикой (например, длина очереди); HPA только на CPU и памяти API-сервер отклонит.
• Kubernetes Service не буферизует запросы, пока нет готовых подов, поэтому для HTTP нужен отдельный слой буферизации.
• Условие ScaledToZero=True отличает автоматическое уменьшение до нуля от ручной паузы: HPA не разбудит workload, который остановил не он.
• Перед откатом версии или выключением гейта нужно вернуть minReplicas не меньше 1 и поднять всё, что стоит на нуле.

Почему CPU и память для этого не годятся

Обычно HPA масштабирует по загрузке CPU или памяти, а эти метрики приходят из работающих подов. Когда реплик ноль, измерять нечего, и сигнала «пора подниматься» не будет. Объектные и внешние метрики от подов не зависят: длина очереди существует независимо от того, есть ли у неё потребители. Поэтому minReplicas: 0 требует хотя бы одной такой метрики в спецификации, а HPA, где есть только ресурсные метрики, API-сервер отклоняет.

В блоге приводится пример с метрикой Prometheus queue_consumer_lag. Чтобы HPA её увидел, нужен адаптер, который отдаёт значение через External Metrics API, например Prometheus Adapter с правилом в externalRules. Перед созданием HPA авторы советуют проверить, что метрика читается:

Если запрос не возвращает значение, сначала чинится конвейер метрик: HPA не сможет поднять workload с нуля, пока метрика недоступна. В этом случае он выставляет условие ScalingActive=False с причиной вроде FailedGetExternalMetric, и восстановить мощность придётся либо починкой метрики, либо ручным масштабированием.

Как выглядит HPA с нулём реплик

Пример из блога нацелен на Deployment queue-worker, допускает от нуля до десяти реплик и просит по одной реплике на каждые 30 задач в очереди:

Когда очередь пуста, HPA уменьшает Deployment до нуля. Когда приходят задачи, внешняя метрика по-прежнему доступна, контроллер пересчитывает число реплик и поднимает поды в пределах maxReplicas. Остальные правила HPA продолжают действовать: в частности, окно стабилизации при уменьшении по умолчанию пять минут, так что короткий провал длины очереди не снесёт всех воркеров разом. Окно настраивается через spec.behavior.scaleDown.

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

Как контроллер отличает «ноль» от «паузы»

Ноль реплик двусмыслен: либо HPA сам всё погасил, либо оператор руками остановил сервис. Разрешает это условие статуса ScaledToZero. Когда HPA уменьшает workload с одной и более реплик до нуля, он записывает ScaledToZero=True, и последующие циклы согласования знают, что нулевое состояние принадлежит контроллеру и метрики нужно продолжать читать. После подъёма условие меняется на ScaledToZero=False с причиной NotScaledToZero. Workload на нуле без условия ScaledToZero=True считается поставленным на паузу. Посмотреть условия можно командой kubectl describe hpa queue-worker.

Кому это не подходит и чем грозит откат

Плата за нулевые реплики называется cold start: HPA должен заметить изменение метрики, планировщик разместить под, приложение подняться. Для очереди, которая надёжно хранит задачи, это нормально. Для HTTP это проблема: Service в Kubernetes не буферизует запросы, пока нет готовых подов, поэтому запросы, пришедшие в «ноль», просто не будут обслужены. Запросным нагрузкам нужен отдельный буферизующий слой, и блог его не предлагает, это остаётся на стороне пользователя.

С обновлением тоже есть оговорки. В 1.37 гейт HPAScaleToZero включён по умолчанию в обоих компонентах: API-сервер принимает minReplicas: 0, а controller-manager выполняет масштабирование по условию. При поэтапном обновлении control plane создавать HPA с нулём стоит только после того, как оба компонента обновлены и гейт активен на обоих: controller-manager без гейта воспринимает нулевые реплики как ручную паузу и может оставить workload лежать. Перед выключением гейта или откатом на версию без реализации на условиях нужно перевести затронутые HPA на minReplicas: 1 и выше и поднять до одной реплики всё, что сейчас стоит на нуле.

Что делать и что дальше

1. Проверьте версию кластера: по умолчанию функция включена начиная с 1.37. Что ещё вошло в этот релиз, мы разбирали в новости про потоковое чтение коллекций из etcd: https://tproger.ru/news/kubernetes-1-37-chitaet-bolwie-kollekcii-iz-etcd-potokom-i-ekono
2. Выберите кандидатов: потребители очередей, batch-обработчики, задачи на GPU. HTTP-сервисы без буфера оставьте на minReplicas: 1.
3. Убедитесь, что метрика читается через External Metrics API, до создания HPA с нулём.
4. Стартуйте Deployment с одной репликой и следите за условиями ScaledToZero и ScalingActive в describe hpa.
5. Оцените cold start для своего образа: время подъёма пода плюс инициализация приложения задают задержку первой задачи после простоя.

Путь у функции длинный: первая alpha-реализация появилась ещё в Kubernetes 1.16, версия 1.36 добавила условие ScaledToZero и поведение контроллера, которое отличает автоматику от ручной паузы, а 1.37 включила всё по умолчанию после интеграционных и end-to-end тестов на уменьшение до нуля и подъём по внешней метрике. Дизайн описан в KEP-2021, функцией владеет SIG Autoscaling. Про GA авторы пока не говорят: следующий шаг, по их словам, собрать эксплуатационный опыт с беты; обратную связь ждут в канале #sig-autoscaling в Slack Kubernetes.

Источники: Kubernetes v1.37: Scale Workloads to Zero with HorizontalPodAutoscaler (блог Kubernetes, Johannes Würbach), KEP-2021: HPA supports scaling to and from zero pods, Prometheus Adapter: external metrics

Изображение на обложке: Логотип: The Kubernetes Authors

Для тех, кто гоняет Polars в пайплайнах, это значит два дела на сегодня. Во-первых, после обновления часть запросов может вернуть строки в другом порядке: потоковый движок не гарантирует порядок для join, group_by и unpivot, если явно не попросить. Во-вторых, код, который годами «работал» на неявных приведениях типов и молчаливом заполнении пропусков, начнёт падать с ошибкой. Разработчики называют это осознанной политикой: ошибка сразу лучше неверного результата через двадцать минут работы пайплайна.

• RC ставится командой pip install polars==2.0rc1; финальный 2.0 выйдет в ближайшие недели, точной даты нет.
• LazyFrame.collect() по умолчанию идёт через streaming-движок; по ожиданиям авторов, в совокупности он «легко в 5 раз быстрее» старого in-memory и заметно экономит память; независимых замеров RC нет.
• Порядок строк после join, group_by и unpivot больше не гарантирован; для join и group_by порядок возвращает параметр maintain_order, для unpivot нужен явный sort; старый движок включается через pl.Config.set_engine_affinity("in-memory") или collect(engine="in-memory").
• is_in с разными типами, горизонтальный concat с разной высотой, касты строк в даты и целых в Enum теперь бросают исключение вместо тихого приведения.
• Большинство удалённых методов и параметров отвечают типизированными ошибками AttributeRemovedError и ArgumentRemovedError с подсказкой, чем заменить.

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

Polars давно развивает два движка. Классический in-memory собирает результат каждой операции целиком в памяти. Потоковый разбивает данные на куски и прогоняет их через план запроса конвейером, поэтому промежуточные результаты не раздуваются. До 2.0 потоковый движок нужно было включать явно; теперь режим engine="auto" выбирает именно его.

Цена такого дефолта в порядке строк: потоковый движок для ряда операций его не гарантирует. Старый движок порядок сохранял, и на это молча полагалось много кода: например, брали первую строку после группировки и считали её «самой ранней». В 2.0 такие места нужно найти и явно попросить порядок (у join и group_by есть параметр maintain_order, после unpivot остаётся явный sort):

Заявление о скорости стоит читать как оценку вендора: «в сумме мы ожидаем, что потоковый движок будет легко в 5 раз быстрее», со ссылкой на собственные бенчмарки Polars. Независимых замеров на RC пока нет, и выигрыш зависит от запроса: на маленьких таблицах, которые целиком помещаются в кеш, разница будет меньше, чем на группировках по десяткам гигабайт.

Где код перестанет молчать об ошибках

Вторая тема релиза сформулирована в посте так: ошибки должны подниматься заранее, а не через 20 минут работы пайплайна, и неявное поведение при несовпадении данных должно включаться явно, а не быть дефолтом. Авторы отдельно отмечают, что строгость стала ценнее с приходом ИИ-агентов: агент может вызвать collect_schema(), проверить типы без чтения данных и быстро получить обратную связь. Примеры из поста и руководства по миграции:

• is_in с разными типами. Раньше Int64 и Float64 приводились к общему супертипу, даже если это теряло точность. В примере из поста идентификатор 9007199254740993 при касте в float64 округлялся до 9007199254740992 (граница, до которой float64 представляет все целые точно), и проверка по списку «помеченных» аккаунтов давала ложное совпадение. В 2.0 это InvalidOperationError: кастовать нужно самому и осознанно.
• Горизонтальный concat. Таблицы высотой 5 и 4 раньше склеивались, а недостающая ячейка молча становилась null; типичный сценарий из поста: тихо упавшая задача за один из дней. Теперь ShapeError, а старое поведение включается через how="horizontal_extend".
• Касты заменены специализированными методами. Целые в Enum или Categorical и обратно: вместо cast() нужны .cat.to() и .cat.physical(). Строка в дату: вместо cast(pl.Date) методы .str.to_date() и .str.to_datetime(), которым можно явно задать формат. Кастовать плоскую колонку в List через cast(pl.List(...)) тоже нельзя, для этого есть pl.list().
• Булевы операторы между Boolean и целыми числами теперь ошибка; std() и var() для Duration удалены, сначала переводите в микросекунды через .dt.total_microseconds().
• Каст между Struct с разным числом полей при strict=True (дефолт) падает, а не обрезает лишние поля; руководство помечает это отдельным предупреждением, потому что раньше данные терялись молча.

Отдельный набор изменений касается чтения CSV. При сканировании набора файлов схема теперь выводится по первым 10 файлам, а не по всем (параметр infer_schema_files). Автоматические имена колонок для файлов без заголовка начинаются с column_0, а не column_1; это же касается read_excel и read_ods. Пользовательская схема в scan_csv сопоставляется с файлом по именам колонок, а не по позиции: раньше первая запись схемы молча получала данные первой колонки файла, даже если имена не совпадали. Для лишних и недостающих колонок появились параметры extra_columns и missing_columns, по умолчанию оба бросают ошибку.

Что будет со старым кодом

Для большинства удалений библиотека получила два типизированных исключения (документация предупреждает, что часть удалённого по-прежнему даёт обычные AttributeError и TypeError): polars.exceptions.AttributeRemovedError для удалённых методов и атрибутов и polars.exceptions.ArgumentRemovedError для удалённых параметров. Оба сообщения указывают на замену:

По словам Винка, большая часть удалённого давно помечена как deprecated, и у тех, кто обновлялся регулярно, пайплайны пострадать не должны. Команда просит сообщать, если из библиотеки убрали что-то, на что реально полагались. Смена движка не затрагивает eager-API DataFrame: выигрыша в скорости там не будет, потому что дефолт меняется только у LazyFrame. Остальные несовместимости на eager распространяются полностью: строгий concat, новые правила read_csv, убранные касты и удалённые методы.

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

1. Поставьте RC в отдельное окружение: pip install polars==2.0rc1. В прод его тащить рано, это кандидат в релиз.
2. Прогоните тесты и посмотрите на исключения AttributeRemovedError, ArgumentRemovedError, InvalidOperationError и ShapeError: каждое сообщение содержит подсказку с заменой.
3. Найдите места, где код полагается на порядок строк после join, group_by или unpivot: сортировки «по умолчанию», head(1) после группировки, сравнение с эталоном по позициям. Добавьте maintain_order (join, group_by) или явный sort (unpivot).
4. Если результат обязан совпадать со старым до байта, зафиксируйте старый движок на время миграции: pl.Config.set_engine_affinity("in-memory").
5. Проверьте чтение CSV без заголовка (сдвиг нумерации колонок на единицу) и scan_csv с явной схемой (сопоставление по именам).

В планах ветки 2.x, о которых команда, по её словам, «недостаточно говорила публично»: полноценная out-of-core обработка для потокового движка, новая архитектура IO-плагинов, собственный читатель S3, расширенное покрытие SQL, планировщик на основе оценки стоимости с переупорядочиванием join и отказ от mmap, после которого конвейер станет асинхронным от начала до конца. Сроков по этим пунктам нет. Замечания по RC команда принимает в issues на GitHub.

Источники: Pre-release of Polars 2.0 (блог Polars, Ritchie Vink), Руководство по переходу на Polars 2.0, Бенчмарки Polars

Изображение на обложке: Логотип: Polars

Я разбираю WebLLM как рабочий инструмент: что нужно от железа и браузера, сколько весят модели, какой скоростью придётся заплатить за отказ от сервера и где проще остаться на облачном API. Все команды и фрагменты кода взяты из README репозитория, цифры производительности из статьи авторов на arXiv, требования к видеопамяти из файла конфигурации в исходниках.

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

• WebLLM выполняет модель в браузере на WebGPU, без сервера; API совместим с OpenAI Chat Completions: стриминг, JSON-режим, seed. Вызов функций помечен в README как незавершённый.
• Актуальная версия пакета @mlc-ai/web-llm — 0.2.84 от 27 мая 2026 года; в 2025–2026 годах вышло всего 7 релизов против 63 за 2024 год по данным реестра npm.
• По замерам авторов на MacBook Pro M3 Max WebLLM выдаёт 41,1 токена/с на Llama-3.1-8B и 71,1 токена/с на Phi-3.5-mini, то есть 71–80% от нативного MLC-LLM на том же железе.
• Модели в 4-битной квантизации требуют от 0,7 ГБ видеопамяти (gemma3-1b) до 6,4 ГБ (Qwen3.5-9B) по значениям vram_required_MB в src/config.ts; первый запуск качает всё это с huggingface.co.
• WebGPU по данным MDN есть в Chrome и Edge с версии 113, в Safari 26 с сентября 2025 года, в Firefox с 141 только частично: Linux и Intel-маки не поддерживаются.

Как WebLLM выполняет модель в браузере и при чём тут WebGPU?

Модель считается на видеокарте пользователя через WebGPU, а всё, что не ложится на GPU, крутится в WebAssembly. Авторы описывают схему так: родственный проект MLC LLM компилирует открытую модель заранее в два артефакта, конвертированные веса и WASM-библиотеку с WebGPU-ядрами и вспомогательными функциями. WebLLM в браузере загружает оба артефакта с хостинга, инициализирует WebGPU-устройство и дальше исполняет граф вычислений локально.

Everything runs inside the browser with no server support and is accelerated with WebGPU.

Отсюда же и главное ограничение, о котором в статье авторы говорят прямо: в отличие от CUDA у WebGPU нет готовых ускоренных библиотек для типовых ядер, поэтому матричные умножения и внимание команде пришлось писать и оптимизировать самой. Цена этого видна в замерах: на Apple MacBook Pro M3 Max в Chrome Canary 133 WebLLM версии 0.2.75 выдавал 41,1 токена/с на 4-битной Llama-3.1-8B против 57,7 у нативного MLC-LLM с Metal-ядрами на той же машине, и 71,1 против 89,3 токена/с на Phi-3.5-mini. Это 71,2% и 79,6% нативной скорости соответственно, замер вендора, другого железа в статье нет.

Второй компонент, о котором обычно забывают, это кэш. Веса и WASM-библиотека скачиваются при первом обращении и складываются в хранилище браузера. README перечисляет четыре бэкенда, которые задаются полем cacheBackend в AppConfig: Cache API по умолчанию, IndexedDB, Origin Private File System и экспериментальный cross-origin через расширение Chrome, чтобы одни и те же веса не качались заново для каждого сайта. Без расширения движок сам откатывается на Cache API.

JSON-режим, который в серверных API обычно реализован на стороне провайдера, здесь тоже выполняется локально: по README структурированная генерация встроена в WebAssembly-часть библиотеки модели, а попробовать её со своей JSON-схемой можно в JSON Playground на Hugging Face. Про то, как WASM-рантаймы догоняют нативный код, мы писали в заметке про Wasmi 2.0.

Что нужно, чтобы запустить первый чат?

Достаточно npm-пакета, одного вызова фабрики и терпения на первую загрузку весов. README даёт три варианта установки и импорт через CDN для JSFiddle и CodePen без сборщика.

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

loading models requires downloading and it can take a significant amount of time for the very first run without caching previously

Дальше интерфейс тот же, что у клиента OpenAI: engine.chat.completions.create({ messages }). Одна ловушка: параметр model в запросе игнорируется, модель выбирается при создании движка или через engine.reload(model). Стриминг включается флагом stream: true, а статистика по токенам приходит только в последнем чанке, если попросить её через stream_options.

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

Какие модели доступны и сколько видеопамяти им нужно?

В список prebuiltAppConfig.model_list в src/config.ts на 3 сентября входят 165 записей: это варианты квантизации и длины контекста для семейств Llama 3.x, Qwen 2.5, Qwen 3 и Qwen 3.5, Phi 3.5 и Phi 4 mini, Gemma 2 и Gemma 3, Mistral и Ministral 3, дистилляты DeepSeek-R1, SmolLM2, OLMo 2, а также две модели эмбеддингов snowflake-arctic-embed. README при этом всё ещё перечисляет старый набор с Llama 2 и Qwen2, так что актуальный набор виден только в коде.

У каждой записи есть поле vram_required_MB, и это честнее любого «весит N гигабайт»: оно включает не только веса, но и память под KV-кэш при заданном контексте. Для 4-битных вариантов с половинной точностью (суффикс q4f16_1) разброс такой:

• gemma3-1b-it — 0,71 ГБ; Llama-3.2-1B-Instruct — 0,88 ГБ; Qwen2.5-0.5B-Instruct — 0,94 ГБ. Помечены флагом low_resource_required, это кандидаты для встроенной графики и ноутбуков.
• Qwen3-0.6B — 1,40 ГБ; gemma-2-2b-it — 1,90 ГБ; Llama-3.2-3B-Instruct — 2,26 ГБ.
• Qwen3-4B — 3,43 ГБ; Phi-3.5-mini-instruct — 3,67 ГБ; Llama-3.1-8B-Instruct — 5,00 ГБ; Qwen3-8B — 5,70 ГБ; Qwen3.5-9B — 6,43 ГБ.
• Есть и Llama-3.1-70B-Instruct в 3-битной квантизации с требованием 31,15 ГБ; на потребительской видеокарте это не запустится.

Варианты с суффиксом «-1k» урезают контекст до одной тысячи токенов и экономят память: у Llama-3.1-8B это 4,60 ГБ вместо 5,00, у Phi-3.5-mini 2,52 ГБ вместо 3,67. Все эти гигабайты приезжают с huggingface.co/mlc-ai, поэтому доступность и скорость этого хоста в вашей сети стоит проверить до того, как обещать пользователям «работает без сервера». Свою модель в формате MLC подключают через appConfig.model_list, указав URL весов и WASM-библиотеки. Какие небольшие открытые модели вышли в августе и на чём их запускать дома, мы собирали в обзоре открытых нейросетей.

Полный каталог собранных моделей лежит на mlc.ai/models. Номер совместимой сборки библиотек зашит в пакет: для 0.2.84 это константа modelVersion со значением «v0_2_84/base», так что после обновления npm-пакета кэшированные WASM-библиотеки могут потребовать перезагрузки.

Как не заморозить интерфейс: Web Worker или Service Worker?

Для обычного приложения хватает выделенного Web Worker, а Service Worker нужен, когда модель должна переживать переходы между страницами. Оба варианта в README оформлены одинаково: в потоке живёт обработчик, в основном скрипте создаётся движок-прокси с тем же интерфейсом MLCEngineInterface.

С Service Worker сложнее. Его жизненным циклом управляет браузер и может убить поток без предупреждения; движок шлёт heartbeat каждые 10 секунд по умолчанию (значение keepAliveMs в src/service_worker.ts), но авторы просят закладывать обработку ошибок и в приложении. README отдельно требует создавать ServiceWorkerMLCEngineHandler на верхнем уровне скрипта и запрещает делать это внутри обработчиков activate или message: браузер перезапускает уже активный воркер без повторного события activate.

Service Worker's life cycle is managed by the browser and can be killed any time without notifying the webapp. ServiceWorkerMLCEngine will try to keep the service worker thread alive by periodically sending heartbeat events, but your application should also include proper error handling.

Отдельная ветка применения — расширения Chrome: в репозитории есть примеры базового расширения и расширения на Service Worker с WebGPU, которое держит модель в фоне. По данным MDN, в Firefox WebGPU недоступен именно в контексте Service Worker, так что этот сценарий пока привязан к Chromium.

Где WebLLM выигрывает у серверного API, а где проигрывает?

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

• Деньги. Инференс идёт на GPU пользователя, счёт за токены равен нулю. Платите трафиком: каждый новый пользователь качает от 0,7 до 6,4 ГБ весов с Hugging Face; свой CDN нужен только тем, кто перехостит артефакты сам.
• Приватность. Промпты и ответы на сервер не уходят, это следует из архитектуры. Но сетевые запросы есть: веса и WASM скачиваются с huggingface.co и jsdelivr, поэтому формулировка «данные никогда не покидают устройство» некорректна, и в политике приватности так писать нельзя.
• Скорость. 71–80% от нативного инференса по замеру авторов на M3 Max. На ноутбуке с встроенной графикой цифр в статье нет, и обещать «десятки токенов в секунду» без своего замера нельзя.
• Первый запуск. Минуты загрузки против миллисекунд первого ответа у API. Кэш спасает повторные визиты, но не первый.
• Браузеры. По данным MDN, WebGPU есть в Chrome и Edge с версии 113 (полная поддержка на Linux только с 144 и только на Intel Gen12 и новее), в Safari 26 на macOS и iOS с 15 сентября 2025 года, в Firefox с 141 частично: есть Windows и Apple Silicon, нет Linux и Intel-маков. Проверка navigator.gpu обязательна.
• Управление моделью. Серверный API даёт одну версию модели для всех и мгновенную замену. В WebLLM версия модели живёт в кэше каждого браузера, а обновление пакета может потребовать перекачки библиотек.
• Функции. Вызов инструментов через tools и tool_choice в README помечен как WIP с предварительной поддержкой. Для агентских сценариев это стоп-фактор; про выбор стека для агентов у нас есть отдельный разбор.

Есть и организационный риск. По реестру npm пакет обновлялся 19 раз в 2023 году, 63 раза в 2024-м, 3 раза в 2025-м и 4 раза с начала 2026 года; последний релиз 0.2.84 вышел 27 мая. Код в репозитории при этом продолжает меняться, последний push был 3 сентября. Для продакшена это означает, что свежие модели из config.ts могут ждать релиза месяцами.

Evaluations show that WebLLM can retain up to 80% native performance on the same device with room to close the gap further.

Что делать по шагам, чтобы собрать чат на WebLLM за вечер

План ниже покрывает путь от проверки железа до защиты артефактов; команды и имена функций взяты из README для версии 0.2.84.

1. Проверьте, что в браузере есть navigator.gpu, и покажите понятную заглушку тем, у кого его нет. По MDN это Chrome и Edge 113+, Safari 26+, Firefox 141+ с оговорками по ОС.
2. Установите пакет: npm install @mlc-ai/web-llm (версия 0.2.84). Для прототипа без сборки подойдёт импорт с https://esm.run/@mlc-ai/web-llm.
3. Выберите модель из prebuiltAppConfig.model_list по полю vram_required_MB. Для широкой аудитории начните с моделей с флагом low_resource_required: Llama-3.2-1B, Qwen2.5-0.5B, gemma3-1b.
4. Создайте движок через CreateMLCEngine с initProgressCallback и выведите прогресс загрузки на экран.
5. Перенесите инференс в Web Worker через CreateWebWorkerMLCEngine, чтобы интерфейс не замирал во время генерации.
6. Включите стриминг флагом stream: true; для извлечения структурированных данных используйте JSON-режим из раздела Full OpenAI Compatibility.
7. Если артефакты лежат на своём хостинге, добавьте в запись модели поле integrity с SRI-хэшами для конфига, WASM и токенизатора; хэш генерируется командой openssl из README.

При несовпадении хэша движок бросает IntegrityError, либо пишет предупреждение и продолжает работу, если задать onFailure: "warn". Без поля integrity проверка не выполняется вовсе, как и в прежних версиях.

Что дальше: чего нет в WebLLM и за чем следить

Первое, за чем стоит следить, это релиз после 0.2.84: в src/config.ts уже есть Qwen3.5 и Ministral 3, и вопрос в том, когда они попадут в опубликованный пакет. Второе — статус вызова функций, который держится в README как WIP. Третье — cross-origin хранилище: сейчас это расширение Chrome и экспериментальный API, а без него каждый сайт качает свою копию весов.

Мы не проверяли скорость на встроенной графике и на Windows-ноутбуках; единственные опубликованные цифры относятся к MacBook Pro M3 Max. Доступность huggingface.co и esm.run из конкретной сети мы тоже не измеряли: перед запуском продукта на WebLLM стоит замерить время первой загрузки у своей аудитории или перехостить артефакты.

Источники: GitHub: mlc-ai/web-llm (README, лицензия Apache-2.0), src/config.ts: prebuiltAppConfig.model_list с vram_required_MB, src/service_worker.ts: keepAliveMs и heartbeat, arXiv 2412.15803: WebLLM: A High-Performance In-Browser LLM Inference Engine, Блог MLC: WebLLM, 13 июня 2024, Документация WebLLM, Реестр npm: @mlc-ai/web-llm (версии и даты), Hacker News: обсуждение WebLLM 2 сентября 2026, MDN: WebGPU API, совместимость браузеров, Hugging Face: модели mlc-ai, WebLLM JSON Playground, WebLLM Chat, Каталог моделей MLC, GitHub: mlc-ai/mlc-llm

Изображение на обложке: Скриншот: chat.webllm.ai

Для разработчиков игр SteamDB не просто справочник: по нему смотрят историю обновлений конкурентов, оценивают продажи по обзорам и подписчикам, следят за ценами по регионам, в том числе российскими. Поэтому главный вопрос сообщества был не «кто купил», а «что закроют за paywall». Ответ в FAQ: имя, сайт и текущие бесплатные функции остаются, display- и programmatic-реклама не планируются.

• SteamDB запустили xPaw и Marlamin в 2013 году; второй сооснователь позже отошёл от проекта, и поддержка легла на одного человека.
• В январе 2026 года xPaw начал искать партнёра; в ближайшие месяцы он будет помогать с переходом.
• Обещания: сайт останется бесплатным, текущие функции не уйдут за paywall, рекламных сетей не будет.
• План: связать историю билдов, депо и манифестов SteamDB с мод-менеджерами Nexus, чтобы предупреждать об обновлении игры, которое сломает моды, и фиксировать точную версию игры в коллекциях.
• API для разработчиков и издателей «скорее всего» появится позже; сроков и условий нет.

Зачем сайту модов база данных Steam

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

Nexus Mods работает с игровыми сообществами больше двадцати лет и живёт на платных подписках, а не на рекламе; отсюда и обещание не вешать рекламу на SteamDB. Как именно SteamDB начнёт приносить деньги, в объявлениях не сказано: упоминается только возможный API для разработчиков и издателей, и то с оговоркой «most likely».

Что это меняет для разработчика игры

• Ближайшие месяцы ничего: сайт, функции и адреса остаются, xPaw участвует в переходе.
• Если ваша игра поддерживает моды, стоит следить за интеграцией с мод-менеджерами: привязка версии игры к коллекции модов снизит число жалоб «после патча всё сломалось».
• Если вы используете SteamDB как источник данных в своих скриптах (парсинг страниц), появление официального API может как упростить жизнь, так и закрыть неофициальный доступ; условий пока нет.
• Данные о региональных ценах и истории скидок, которыми пользуются при планировании релиза в СНГ, остаются бесплатными по заявлению SteamDB.

Почему это важно как прецедент

История SteamDB типична для инфраструктурных проектов сообщества: сервисом пользуются миллионы, а держит его один человек на энтузиазме. xPaw пишет, что цель перехода «не изменить то, что делает проект особенным, а дать ему ресурсы» (перевод редакции). Похожий выбор недавно делали и другие проекты; на сайте мы разбирали, как студия PEAK строит издательскую программу для инди и что происходит с пополнением Steam из России.

Что проверить дальше: появится ли API и на каких условиях, изменится ли политика в отношении парсинга и сохранится ли текущая скорость обновления данных после того, как xPaw отойдёт от проекта. Полный список обещаний и ограничений SteamDB собрала в FAQ о переходе.

Источники: SteamDB: блог о переходе к Nexus Mods, Nexus Mods: новость о SteamDB, SteamDB FAQ о переходе

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

Для тех, кто держит NGINX перед API, это меняет привычную схему. Раньше, чтобы направить запрос к /graphql или /mcp на разные бэкенды в зависимости от того, что лежит внутри JSON, приходилось подключать njs или Lua. Теперь то же самое делается директивами конфигурации на C без скриптового рантайма. Тем, кто уже использует njs с js_access, обновление стоит поставить в первую очередь: до 1.0.1 ошибка внутри асинхронной проверки приводила к тому, что NGINX продолжал обрабатывать запрос, как будто проверка пройдена.

• NGINX 1.31.5 от 2 сентября 2026 года: location по переменной (predicate locations), директива client_body_early_read, модуль ngx_http_json_module, Control API из NGINX Plus R37.0.
• Control API не имеет аутентификации: проект рекомендует запускать его только на UNIX-сокете с правами для привилегированных пользователей и не выставлять на сетевой порт.
• Главное исправление 1.31.5: use-after-free при буферизованном проксировании к клиенту по HTTP/2, из-за которого клиенту могла уйти освобождённая память или падал worker.
• njs 1.0.1 закрыл CVE-2026-18329 (обход js_access, появился в 0.9.9), CVE-2026-78222 (падение worker при пустой reason phrase у upstream, с 0.5.1) и CVE-2026-78689 (переполнение буфера в xml.exclusiveC14n(), с 0.7.10).
• Исходники и бинарные пакеты для основных дистрибутивов Linux уже доступны на nginx.org.

Что изменилось в маршрутизации

Авторы блога объясняют новую схему через почту. URI вроде /api/v1/checkout это адрес на конверте, заголовки Authorization и User-Agent это штампы, а тело запроса с JSON это само письмо внутри. Классический NGINX сортировал письма по адресу на конверте: выбирал location по URI, а тело обычно читалось уже после выбора location. Проблема в том, что современные клиенты, от GraphQL и JSON-RPC до MCP-серверов для ИИ-агентов и краулеров, шлют совершенно разные операции на один и тот же адрес /api/v1, /graphql или /mcp.

В 1.31.5 конверт можно вскрыть до сортировки. Четыре новые возможности складываются в одну цепочку: прочитать тело раньше, вытащить из JSON нужное поле в переменную, использовать переменную как условие выбора location.

Predicate locations: location по любой переменной

Любая переменная становится предикатом, если написать её в определении location (nginx/nginx#1633). Блок срабатывает, когда переменная непустая и не равна нулю. Условие может учитывать что угодно: подсеть клиента, клиентский сертификат, заголовки, результат map или поле из тела запроса. Пример из блога:

По словам разработчиков, условия вычисляются на уровне C без скриптового рантайма. До сих пор сложную логику выбора location собирали из map, if и внутренних редиректов либо выносили в njs и Lua.

client_body_early_read: тело до выбора location

По умолчанию NGINX читает заголовки, выбирает location и только затем буферизует тело. Директива client_body_early_read меняет порядок: тело буферизуется до сопоставления location, а разбирает его уже отдельный JSON-модуль (nginx/nginx#1641). Проект называет два сценария: маршрутизация по содержимому, когда вызов инструмента tools/call в MCP уходит на свой сервис вместо общего /mcp, и проверка на границе, когда слишком большой или некорректный payload отклоняется, ограничивается по частоте или валидируется до того, как уйдёт на бэкенд. Раньше для учёта отдельных вызовов инструментов агентов NGINX предлагал модуль MCP Observability на njs.

ngx_http_json_module: поля JSON в переменные

Новый модуль разбирает буферизованный JSON и кладёт поля, включая вложенные, в обычные переменные NGINX (nginx/nginx#1642). Дальше переменную можно подать в map или прямо в предикат location. Пример вытаскивает поле method из тела POST-запроса. В анонсе аргументы приведены в обратном порядке; по исходному коду модуля директива принимает сначала имя новой переменной, затем источник и путь:

В паре с client_body_early_read переменные из JSON заполняются до выбора location. Полное описание директив модуля разработчики обещают в отдельных статьях: в блоге анонсированы три разбора, про predicate locations, про Control API и про маршрутизацию по телу запроса.

Control API пришёл из NGINX Plus, но без аутентификации

Control API впервые появился в NGINX Plus R37.0 LTS, а теперь перенесён в открытую версию (nginx/nginx#1626). Он даёт программный доступ к состоянию процессов и конфигурации по адресам /1/control/processes и /1/control/config и позволяет перезагружать конфигурацию с синхронным ответом в JSON. Раньше перезагрузка делалась через nginx -s reload или сигнал, а результат приходилось ловить в /var/log/nginx/error.log: опечатка в конфигурации или проблема с правами на сокет обнаруживались уже постфактум. Теперь ошибка возвращается в HTTP-ответе, что удобно для конвейеров деплоя и инструментов infrastructure as code.

Для безопасного использования проект советует запускать NGINX с привязкой API к UNIX-сокету:

Control API работает и на сетевом порту, но команда NGINX прямо не рекомендует так делать: «API предоставляет открытый неаутентифицированный интерфейс к внутренностям NGINX и должен быть привязан к защищённой файловой системе, доступной только привилегированным пользователям» (перевод редакции). Путь к сокету в примере, /tmp/nginx.sock, взят из блога; на боевом сервере его стоит вынести в каталог с ограниченными правами.

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

Главной причиной обновиться разработчики называют исправление в буферизованном проксировании (nginx/nginx#1664). При ошибке на стороне клиента функция ngx_event_pipe_drain_chains() возвращала в пул все буферы, включая цепочку p->busy, которую ещё использовали фильтры вывода. По HTTP/1.1 это оставалось незаметным, потому что запрос завершался сразу. По HTTP/2 флаг ошибки ставился на фиктивное соединение, обработчик записи продолжал отправлять DATA-фреймы, указывающие на освобождённую память, и клиент мог получить содержимое кучи, а worker упасть на незамапленной странице. По словам авторов, вредоносный ввод для этого не требовался: в упрощённом описании анонса хватало ошибки в фильтре тела ответа и медленного клиента, у которого накапливались фреймы; в pull request сценарий воспроизведения описан подробнее, с настройками временных файлов и особым ответом upstream. Затронута любая конфигурация с proxy_buffering on и клиентами по HTTP/2.

• Worker без свободных файловых дескрипторов теперь завершается штатно. Раньше при заполненной таблице дескрипторов вызов recvmsg() с SCM_RIGHTS не мог прочитать канал управления, worker закрывал свой конец канала и больше не получал сигнал завершения, то есть висел после reload (nginx/nginx#1662).
• Таймер повторного включения accept удаляется вместе с listen-соединением: иначе после NGX_CMD_QUIT в логах появлялось accept4() failed (9: Bad file descriptor).
• Имена параметров fastcgi_param от 128 байт и uwsgi_param от 256 байт теперь кодируются с правильной длиной. Раньше поле длины обрезалось до одного байта, запрос к бэкенду получался повреждённым, PHP-CGI сбрасывал соединение, и NGINX отвечал 502 на каждый запрос к такому location (nginx/nginx#1648). SCGI не затронут.
• Три проверки входных данных: длины ответов memcached вблизи NGX_MAX_OFF_T_VALUE отклоняются с 502, начало диапазона Range у самого максимума в модуле slice игнорируется с ответом 416, а CRYPTO-фреймы QUIC в 1-RTT-пакетах после завершения рукопожатия отвергаются с ошибкой unexpected_message. Первые две ошибки были неопределённым поведением и роняли сборки с -fsanitize=signed-integer-overflow.
• Исправлен расчёт переполнения длины при формировании JSON в ngx_json_obj_length().

Что закрыл njs 1.0.1

njs, модуль, который добавляет в NGINX JavaScript, получил версию 1.0.1 в тот же день. В списке изменений три записи с пометкой Security.

• CVE-2026-18329: обход контроля доступа в js_access. Если асинхронное продолжение чтения тела запроса бросало исключение или завершалось необработанным rejection, NGINX продолжал обрабатывать запрос так, будто проверка js_access прошла. Ошибка появилась в njs 0.9.9; нашёл её Та Дык Тхиен.
• CVE-2026-78222: падение worker-процесса при чтении Response.statusText, когда upstream вернул строку статуса с пустой reason phrase. Ошибка присутствовала с версии 0.5.1.
• CVE-2026-78689: переполнение буфера в куче при разборе списка префиксов пространств имён, переданного в xml.exclusiveC14n(). Ошибка с версии 0.7.10; о ней сообщили исследователи из Cyera и evilgensec.

Помимо уязвимостей, в 1.0.1 исправлены use-after-free, аварийные завершения worker и утечки при циклических ссылках между объектами Fetch, HTTP-запроса и Stream-сессии в движке QuickJS, переполнение буфера на стеке при экспорте RSA-ключей длиннее 4096 бит в JWK через crypto.subtle.exportKey(), шифрование и расшифровка RSA-OAEP с SHA-256 и SHA-384, проверка значений заголовков Fetch и имён в r.headersOut, а также целей редиректа в r.return(). Добавлены глобальные функции btoa() и atob() в движке QuickJS и совместимость с quickjs-ng 0.16.0 и новее.

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

1. Если в конфигурации есть js_access, обновить njs до 1.0.1 сразу: до этого ошибка внутри проверки доступа открывала запрос вместо того, чтобы его отклонить.
2. Если NGINX проксирует с proxy_buffering on и принимает HTTP/2, обновить ядро до 1.31.5: это исправление разработчики называют главной причиной обновления.
3. Ветка 1.31 это mainline, где новые возможности появляются первыми. Predicate locations, client_body_early_read, JSON-модуль и Control API есть только здесь; в стабильной ветке их пока нет, и о сроках переноса в блоге не сказано.
4. Пробуя Control API, привязывать его только к UNIX-сокету в каталоге с ограниченными правами. Аутентификации у API нет.

NGINX 1.31.5 доступен в исходниках и бинарными пакетами для основных дистрибутивов Linux. Предыдущая версия 1.31.4 вышла 19 августа и добавила PROXY protocol v2 в модули stream и mail. По каждой из четырёх новых возможностей команда NGINX обещает отдельные статьи с примерами конфигурации, и редакция вернётся к теме, когда появится документация директив JSON-модуля.

Источники: NGINX 1.31.5: Control API, predicate locations, early body inspection, and more (NGINX Community Blog), CHANGES nginx 1.31.5, Changes with njs 1.0.1, Релиз nginx 1.31.5 на GitHub

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

Последняя капля, как её назвали инженеры CERN (перевод редакции), знакома всем, кто держит парк старого железа: RHEL и его производные собираются с флагом компилятора -march=x86-64-v2, и процессоры без нужных инструкций перестают загружать систему. В CERN это назвали принудительным устареванием. Для админа с парком машин десятилетней давности вопрос тот же: какую ветку дистрибутивов под них выбирать.

• Мигрируют 2200 с лишним промышленных компьютеров и встраиваемых систем управления ускорителями; срок до конца 2026 года; целевая система Debian 13.
• Дата-центры и вычислительная инфраструктура экспериментов остаются на RHEL и AlmaLinux, уточнение опубликовано отдельно.
• CERN около десяти лет использовала Scientific Linux, которую сама сопровождала, затем с 2015 года CentOS.
• Рассматривали CentOS Stream как естественное продолжение, но решающим стал флаг -march=x86-64-v2 по умолчанию в RHEL.
• Названные проблемы Debian: нет стандартного инструментария для автоматической сборки и публикации пакетов и для хранения нескольких версий одного пакета.

Что такое x86-64-v2 и почему он отсекает железо

Уровни микроархитектуры x86-64-v2, v3 и v4 описывают наборы инструкций, на которые компилятор может рассчитывать. Уровень v2 требует, среди прочего, SSE4.2 и POPCNT; это процессоры примерно 2009 года и новее. RHEL 9 и производные (AlmaLinux, Rocky, CentOS Stream 9) собираются под v2, поэтому на более старых CPU ядро и пользовательские программы просто не запускаются. Промышленные контроллеры и встраиваемые машины у ускорителей меняются редко: оборудование сертифицировано, проверено годами и работает. Debian по-прежнему собирает amd64 под базовый уровень x86-64, что и делает его вариантом для такого парка.

Чего CERN не хватило в Debian

По пересказу Phoronix, инженеры назвали два пробела. Первый: в экосистеме Debian нет стандартного инструментария для автоматической сборки и публикации собственных пакетов уровня того, к чему привыкли в мире RPM (Koji, Copr, mock). Второй: инструменты репозиториев плохо поддерживают хранение нескольких версий одного и того же пакета, что нужно для контролируемого отката на промышленных системах. Оба пробела CERN закрывает своими средствами; подробности обещаны в видеозаписи доклада с MiniDebConf.

Что остаётся на RHEL

Важное уточнение, которое Phoronix добавил после публикации: миграция касается только промышленных компьютеров управления ускорителями. Дата-центры CERN и вычислительная инфраструктура экспериментов остаются на RHEL и AlmaLinux. То есть это не «CERN уходит с Red Hat», а выбор дистрибутива под конкретный класс машин со старым железом.

Что это значит для своего парка

• Проверить, проходят ли ваши серверы уровень v2: /lib64/ld-linux-x86-64.so.2 --help | grep supported на любой glibc новее 2.33 покажет поддерживаемые уровни.
• Если в парке есть машины ниже v2, ветка RHEL 9 и новее для них закрыта; варианты: Debian, Ubuntu (тоже базовый x86-64) или остаться на RHEL 8-совместимых системах до конца их поддержки.
• Для промышленных систем ключевой вопрос не дистрибутив, а инструменты сборки пакетов и отката: под Debian их придётся собирать самим, как это делает CERN.
• Debian 13 вышел летом 2025 года и будет получать обновления безопасности до 2028 года, затем LTS; для сравнения, поддержка Debian 11 закончилась 31 августа.

Слайды и видео доклада CERN с MiniDebConf на момент публикации доступны через страницу конференции, отдельного пресс-релиза организация не выпускала. На сайте мы недавно разбирали другой пример влияния сборочных флагов на скорость: Rust Coreutils 0.11 и разницу производительности бинарников в Alpine из-за libc.

Источник: Phoronix: CERN Transitioning Industrial Computers To Debian

Изображение на обложке: Debian Project, логотип Debian Open Use

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

Для разработчика это открытый пример, где агентный конвейер отвечает за весь цикл: сбор геоданных, генерацию моделей, рантайм, автотесты по фотографиям и независимое ревью. В репозитории лежит исходный промпт, база исследования с источником у каждого факта, скрипты генерации и отчёты рецензентов с оценками от 5,5 до 8 из 10, которые авторы не подгоняли под целевую планку. Это можно клонировать, повторить на своём районе или разобрать как образец того, что сегодня получается у агентов в 3D, а что пока нет.

• Сцена: 453 контура зданий из OpenStreetMap, 75 фасадов с описанием, составленным агентами по фотографиям, 11 950 оконных и дверных проёмов, 129 опознанных магазинов с реальными арендаторами 2024–2026 годов.
• Жизнь на улице: 220 пешеходов на навигационном графе из 1398 узлов, 109 машин, автобусы и канатные трамваи по улице Пауэлл, 36 регулируемых перекрёстков.
• Два интерьера, куда можно зайти: Apple Union Square и Nintendo San Francisco, 23 интерактивных объекта.
• Проверка: 34 контрольных точки, где рендер сверяется со снимком с того же места (свободные фотографии есть для 28 из них), 147 листов сравнения, 9 отчётов агентов-рецензентов, 18 из 18 шагов сценарного прохода.
• Производительность в headless Chromium при 1080p: 50–79 кадров в секунду на улице днём, 32 в виде сверху. Ассеты: 206 GLB-файлов на 5,1 МБ.

Что построили

Реконструкция покрывает примерно 800 на 720 метров: саму площадь и кварталы между улицами Мейсон и Грант, Саттер и О'Фаррелл. Рельеф взят из USGS 3DEP (1317 высотных отметок), поэтому Пауэлл-стрит поднимается к Ноб-Хиллу так же, как в жизни. Начало координат привязано к монументу Дьюи, а вся сцена повёрнута на реальный азимут уличной сетки 80,686 градуса, чтобы фасады стояли на своих участках.

Управление обычное для браузерных прогулок: WASD для ходьбы, Shift для бега, E для взаимодействия, Tab для орбитальной камеры, T запускает кинематографический тур, клавиши 1, 2 и 3 переключают день, закат и ночь. Клавиша R накладывает на рендер реальную фотографию с той же точки, чтобы глазами оценить расхождение.

Как это собрано

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

1. Разведка. Одиннадцать параллельных исследовательских агентов собрали базу: контуры зданий из OSM, высоты USGS, спецификацию улиц и транспорта (число полос, односторонние направления, положение рельсов канатной дороги), обмер площади, перепись из 122 магазинов, отдельные исследования магазинов Apple и Nintendo и 34 контрольных ракурса. У каждого факта записан источник и уровень уверенности; непроверенное не придумывалось, а помечалось как нерешённое.
2. Офлайн-генерация ассетов. Скрипты на Blender как библиотеке (bpy) выпускают 206 оптимизированных GLB-модулей: окна, карнизы, витрины, маркизы, фонари, светофоры, скамейки, гидранты, машины, пальмы, торговое оборудование, части тел пешеходов. Blender в рантайме не участвует.
3. Рантайм. Приложение на Three.js собирает рельеф, улицы, фасады, реквизит, толпу и трафик из JSON-спецификаций. Фасадный движок превращает описание здания в геометрию: цокольный ярус, шагающий вместе с уклоном тротуара, витрины с реальными арендаторами и вывесками, окна по ритму пролётов, карнизы и парапеты. 75 зданий описаны отдельными спецификациями, остальные выводятся автоматически и берут арендаторов из переписи.
4. Проверка по камере. Playwright гоняет настоящее приложение по 34 ракурсам, снимает скриншоты и кладёт их рядом с фотографиями под свободной лицензией с тех же точек, плюс наложение 50 на 50. Девять независимых агентов-рецензентов (геометрия, семантика, архитектор, местный житель Сан-Франциско, художник по окружению, технический художник, интерактив) пишут отчёты, которые запускают следующий цикл правок.

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

Что показала проверка

Самая полезная часть репозитория для тех, кто оценивает возможности агентов, это итоговый QA-отчёт, сгенерированный 2 сентября. Географическая точность получила 7,5 из 10, узнаваемость зданий 5,5 с оценкой 6,5 после исправления, точность магазинов 6 (размещены 76% названных арендаторов из переписи), интерьер Apple 7, Nintendo 7,5, детализация улицы, материалы и общая узнаваемость по 6, освещение 7, навигация 8, производительность 6. Целевая планка в промпте была 8–9, и авторы прямо пишут, что оценки под неё не подгонялись.

Список открытых расхождений тоже опубликован. Контур универмага Saks в OSM нарисован по границе участка, поэтому тротуар на Пауэлл получился шириной 2,1 метра вместо примерно четырёх. Здание Уиттелл смоделировано высотой 56 метров по OSM вместо 66 по справочникам. У 34 витрин из переписи арендатор не установлен: они отрисованы нейтральной пустой фасцией, а не выдуманы. Есть и исправленные баги с понятной причиной: все стены фасадов были сгенерированы с обратной обмоткой полигонов, и отсечение задних граней прятало их там, где сзади не было панели, из-за чего стены «исчезали», если поднять взгляд.

Замеры производительности сделаны в headless Chromium при 1920 на 1080 через ANGLE и Metal, то есть на Mac. Днём в центре площади 63 кадра в секунду при 2108 вызовах отрисовки и 7,25 млн треугольников; на перекрёстке Пауэлл и Гири 51 кадр, 2646 вызовов и 7,91 млн треугольников; внутри Apple 79 кадров; в виде сверху 32 кадра при 3522 вызовах и 8,52 млн треугольников. Куча JavaScript держится на 290 МБ днём и 242 МБ ночью. Ночной режим дешевле по вызовам отрисовки, но кадров на перекрёстках даёт меньше: 38,5 на Пауэлл и Гири.

Чего в репозитории нет

На вопрос о цене и времени автор публикации на Hacker News под ником surreal_ ответил, что это результат одного прогона по очень длинному промпту с явными указаниями про субагентов и цикл самопроверки: около двух часов работы, примерно 8 млн токенов и около $33 по тарифам API. Сколько было неудачных попыток до этого прогона и вмешивался ли человек по ходу, не уточняется. Кто стоит за PhiloLabs, тоже неизвестно: организация на GitHub создана в феврале 2026 года, без описания и сайта, в ней пять репозиториев. В комментариях автор пишет, что команда уже сгенерировала большинство туристических мест Сан-Франциско и готовит обзорную статью про «моделирование мира через код»; сроков нет.

Разработчик игр в комментариях на HN отметил, что в похожих экспериментах модели выдают неоптимизированную геометрию с избыточным числом полигонов, и что для игровых ассетов он предпочитает просить у модели низкополигональные силуэты. Автор проекта ответил, что при генерации мира кодом геометрия строится из примитивов и параметрических конструкций, поэтому топология чистая по построению, а слабое место скорее текстуры. Числа из QA-отчёта, 7–8 млн треугольников и больше двух тысяч вызовов отрисовки на кадр для одного квартала, по нашей оценке, всё же говорят о заметном запасе для оптимизации.

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

Репозиторий стоит открыть не ради прогулки по Сан-Франциско, а ради конвейера. Файл PROMPT.md показывает, как сформулирована задача на автономную сборку: перечень обязательных объектов с адресами, требование Three.js в рантайме и Blender только офлайн, обязательная сверка с фотографиями на каждой вехе и независимые рецензенты. Папка qa/ пригодится как образец проверки против реальности, а не против самого себя: фиксированные ракурсы по координатам, автоматические сравнения и отчёты, которые прямо называют, где результат ниже планки.

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

Источники: Репозиторий PhiloLabs/fable51-worlds, README мира Union Square, FINAL_QA_REPORT.md, Обсуждение на Hacker News

Изображение на обложке: PhiloLabs, fable51-worlds (MIT)

Для тех, кто держит Go-сервисы в проде, это закрывает старую дыру в инструментах. Обычный goroutine-профиль показывает, сколько горутин сейчас заблокировано, но не отличает штатное ожидание от горутины, которая уже никогда не проснётся. Раньше такие утечки искали руками по стекам или ловили в тестах пакетом goleak; сам релиз Go 1.27 вышел 19 августа, а разбор механизма команда опубликовала только сейчас.

• Профиль goroutineleak входит в Go 1.27 и доступен через runtime/pprof и net/http/pprof (/debug/pprof/goroutineleak).
• Ловит блокировки на отправке и приёме в канал, блокирующем select, Mutex, RWMutex, WaitGroup и Cond.
• Не считает утечкой ожидание файлового и сетевого ввода-вывода, системных вызовов и самодельных спинлоков.
• По словам команды Go, метод точный и почти не даёт ложных срабатываний; накладные расходы на память названы пренебрежимо малыми, худший случай для одного цикла GC оценён как O(n²).
• В примере из блога профиль нашёл 116 зависших горутин на одной строке с отправкой в небуферизованный канал.

Что такое утечка горутины и почему её было трудно найти

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

До Go 1.27 инструментов было три, и ни один не решал задачу для продакшена. goleak проверяет, не остались ли горутины после конкретного теста. Пакет synctest, появившийся в стандартной библиотеке Go 1.25, помогает тестировать конкурентный код с виртуальным временем. Обычный goroutine-профиль показывает заблокированные горутины, но не доказывает, что они не проснутся: всплеск нагрузки выглядит в нём так же, как утечка.

Как профиль отличает утечку от штатной блокировки

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

Команда Go утверждает, что механизм точный и «почти не даёт ложных срабатываний» (перевод редакции). Есть патологический случай: цепочка горутин, где каждая ждёт примитив, доступный только следующей. Для такой «гирлянды» проверка в худшем случае занимает O(n²) шагов за один цикл GC, поэтому в блоге советуют не включать сбор профиля постоянно, а снимать его периодически, например раз в четыре часа. Память на учёт горутин авторы называют пренебрежимо малой, а GC при этом продолжает работать параллельно с пользовательским кодом.

Разработка выросла из совместного исследования Орхусского университета, Университета Вашингтона в Сент-Луисе и Uber; академическую версию представили на конференции ASPLOS 2025.

Что видно в профиле на живом примере

В блоге разобран сервис, который раз в секунду запускает обработку десяти элементов и на пятом получает ошибку. Функция делает ранний return, оставшиеся воркеры зависают на отправке в канал. Программа подключает net/http/pprof и слушает localhost:6060; профиль снимают обычным способом:

Через несколько минут работы pprof показывает Total: 116 заблокированных горутин, и все они стоят на одной операции: отправке в канал ch. Исправление для примера тривиальное: сделать канал буферизованным на число воркеров, make(chan result, len(ws)), тогда воркеры допишут результаты и завершатся, даже если читатель ушёл.

Что профиль не ловит

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

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

Как включить у себя

1. Обновить тулчейн до Go 1.27 (релиз от 19 августа 2026 года, заметки к выпуску) и пересобрать сервис.
2. Если net/http/pprof уже подключён, новый обработчик появится автоматически по пути /debug/pprof/goroutineleak; отдельной настройки не нужно.
3. Снимать профиль периодически, а не постоянно: команда Go предлагает интервал вроде четырёх часов из-за квадратичного худшего случая.
4. Смотреть в первую очередь на места с ранним return при ошибках, таймауты без select с контекстом и воркер-циклы, у которых читатель может уйти раньше писателей.

Схемы GC и полный пример кода лежат в посте команды Go. Из соседних новостей по инфраструктуре Go-сервисов на сайте есть разбор Kubernetes 1.37 и заметка о tailcat от Tailscale, написанном на Go.

Источники: Go Blog: Goroutine leak profiles, Go 1.27 Release Notes, Go Blog: Go 1.27 is released

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

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

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

• Два агента, три способа запуска (Messages API, Claude Agent SDK, Managed Agents (beta)), четыре вертикали и восемь веб-приложений в одном репозитории под Apache 2.0.
• Не оформляет заказ, не списывает деньги и не меняет живые листинги: checkout только рисует корзину, каждая запись мерчанта ждёт одобрения человека.
• Проверки provenance, лимиты, ограждение стороннего текста и валидация памяти работают внутри вызова инструмента и держатся на всех трёх путях запуска.
• Своя интеграция сводится к реализации StorefrontBackend или MerchantBackend; отсутствующие системы выключаются переключателями enable_*.
• Модели по умолчанию: claude-sonnet-5 у покупательского агента, claude-opus-5 у мерчантского, claude-haiku-4-5-20251001 для памяти; рантаймы работают через Vertex AI, Bedrock, Microsoft Foundry и шлюзы.
• Требования: Python 3.11 и новее, Node 22. Демо поднимается шестью командами из README.

Один агент описан один раз и работает на трёх рантаймах

Главная архитектурная идея репозитория, как её формулирует README: каждый агент определён один раз (промпт, скиллы, контракты инструментов, гейты) и запускается на Messages API, на Claude Agent SDK и на Managed Agents. Четыре вертикали работают поверх одних библиотек и различаются бэкендом и доменными расширениями интерфейса.

Покупательский агент ищет и сравнивает товары, собирает планы покупок, наполняет корзину, отвечает на вопросы о заказах и правилах магазина и запоминает, что покупатель о себе рассказал. Его пять сценариев лежат как skills в каталоге shopping-agent/skills. Мерчантский агент объясняет показатели, правит листинги, реагирует на алерты по остаткам и заказам, назначает цены и промо, готовит кампании. Его пять сценариев лежат в merchant-agent/skills. Любая запись мерчанта становится staged change, которую применяет уже интерфейс одобрения на стороне хоста.

Nothing places an order, charges a card, or changes a live listing: checkout renders the cart for the host to complete, and every merchant write is staged until a person approves it.

Код разложен на семь pip-пакетов. Общее для обеих ролей вынесено в commerce-common: конфиг, ограждение стороннего текста, память, скиллы, grounding, презентационные компоненты, исполнитель инструментов и события. У каждой роли три пакета: core с типами, интерфейсом бэкенда, промптом, контрактами инструментов и гейтами; runtime с циклом ходов на Messages API; sdk с тем же агентом на Agent SDK и консолью. CI проверяет, что имена семи пакетов остаются незарегистрированными в публичном индексе, а pin-файлы ставят их из каталогов репозитория.

Эталонный путь запуска, вокруг которого построены примеры, это Messages API. Хост создаёт объект агента с бэкендом, каталогом скиллов и конфигом и стримит события хода; извлечение памяти вызывается отдельно после хода, и только на этом пути. Код из README:

На Agent SDK тот же промпт, скиллы и инструменты, но цикл ведёт SDK: хост заранее подгружает данные для grounding, после хода ничего не выполняется. На Managed Agents агент размещён у Anthropic и ходит за данными в ваш MCP-сервер; деплой делает скрипт scripts/deploy_managed_agent.sh, без флага --live это сухой прогон. Различия трёх путей по docs/safety.md:

• Messages API. Все правила grounding включаются принудительно через tool_choice; работают извлечение памяти после хода, сжатие истории и бюджеты аналитического делегата мерчанта.
• Agent SDK. Grounding только для правил с формой предварительной загрузки; цикл ограничен max_turns; аналитика мерчанта идёт субагентом без SQL-инструмента и бюджетов; память хост извлекает сам.
• Managed Agents. Grounding отсутствует, циклом владеет платформа, память пишется только через save_memory, одобрением staged change служит промпт always_ask на apply_change.

Проверки стоят внутри вызова инструмента, поэтому переживают смену рантайма

Документ docs/safety.md делит правила на три группы: что код проверяет сам, что по-прежнему просят у модели промптом и что обязан добавить деплой. Ключевой приём: правило внутри вызова инструмента держится на всех трёх путях, потому что все три прогоняют вызовы через один исполнитель в модуле commerce_common/execution.py. Правило на уровне хода живёт в конкретном рантайме, и таблица указывает, где оно не работает.

A rule enforced inside a tool call holds on all three paths, because the Messages API runtime, the SDK toolset, and the MCP server execute tools through the same executor.

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

• Ограждение (fencing). Сторонний текст очищается, оборачивается в ограждение с фиксированной меткой и обрезается до max_fenced_chars. Очистка убирает невидимые и управляющие символы, поддельные маркеры ходов, теги транскрипта и вызовов инструментов и копии самого маркера ограждения.
• Лимиты цикла. Запрошенное моделью число результатов поиска обрезается до max_search_results; после max_tool_iterations раундов рантайм Messages API принудительно делает ход без инструментов.
• Provenance корзины. В корзину попадают только идентификаторы товаров, которые в этой сессии вернул инструмент каталога или заказов. Попытка добавить товар с опциями (размер, цвет) задерживается, и модели показывают варианты. Действует лимит на позицию и на число строк.
• Нет оплаты. У StorefrontBackend нет метода, который размещает заказ или списывает деньги. URL размещённого checkout приходит из checkout_handoff после вызова модели и не проходит через неё.
• Provenance staged-записей мерчанта. Изменение принимает только идентификаторы листингов и кампаний, возвращённые инструментом в этой сессии; правка контента требует чтения get_listing. apply_change принимает только идентификаторы изменений, которые вернули staging или get_pending_changes.
• Guardrails мерчанта. Проверяются при постановке изменения и повторно при применении: число позиций, размах изменения цены, глубина промо, размер пополнения, бюджет кампании, защищённые поля.
• Одобрение хостом. При require_host_approval (включено по умолчанию) apply_change проходит только для идентификаторов, которые хост пометил одобренными. Карточка предпросмотра ничего не одобряет, «да, применяй» в чате тоже.
• Память. Ключ факта до 64 символов, значение до 200, одна из трёх категорий; значения, похожие на идентификаторы, отбрасываются. Извлечение читает только текст последнего обмена, никогда результаты инструментов.
• Поверхность инструментов и идентичность. Список инструментов вычисляется из конфига деплоя, исполнитель отказывает любому другому имени. Идентичность держит сервер: ни один аргумент инструмента не называет пользователя или мерчанта.

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

When the model breaks one of these, the error is confined to its text. Every write, figure, and disclosure behind that text still passed the checks in the table above, so the failure is a misstatement to correct and no action needs reversing.

Третья группа целиком на стороне деплоя: аутентификация и авторизация на каждом маршруте и на MCP-серверах (примеры принимают любого вызывающего), учётные данные для вызова ваших сервисов, лимиты запросов, бизнес-правила (фрод, право на покупку, цены, остатки), оплата после checkout, обращение с памятью как с персональными данными, гигиена логов и сама поверхность одобрения. Значения guardrails в двух файлах config.py названы демонстрационными.

Своя интеграция сводится к двум интерфейсам и переключателям enable_*

Точка входа для собственных систем описана в docs/backends.md. Деплой реализует StorefrontBackend поверх каталога, корзины, заказов и политик или MerchantBackend поверх аналитики, каталога, остатков, цен и кампаний. Контрактом служат докстринги методов в backend.py и types.py каждой роли. Каждый метод вызывает ваш сервис на стороне сервера с учётными данными, которые хост хранит для сессии; модель видит только результат.

Each one calls your service server-side with the credential your host holds for the session; the model reads only the result.

Документ раскладывает интеграцию на шесть шагов. Первый: решить, кто вызывающий. Хост аутентифицирует человека и стартует сессию с принципалом; токен покупателя живёт в контексте сессии, сервисная учётка передаётся в конструктор бэкенда. Гость тоже принципал: чтение, которому нужен аккаунт, бросает исключение, которое подкласс исполнителя превращает в просьбу войти. Второй: порядок многошаговых сценариев (удержать места, затем подтвердить) хранится и проверяется в бэкенде, а нарушение маппится через domain_error в понятный модели результат. Третий: как завершается checkout. Вариантов три: ссылка на маршрут в вашем приложении, размещённый checkout платформы, для которого checkout_handoff возвращает URL, или маркетплейс с записью на каждого продавца.

Четвёртый шаг: товары с опциями. Запись бывает простой, семейством (с полем options) или вариантом (с option_values и variant_of); идентификатор варианта идёт всюду, где ждут идентификатор товара. Детали товара возвращают все варианты семейства в одном ограждении, обрезанном до max_fenced_chars (12 000 символов по умолчанию). Компактная строка варианта занимает 70–120 символов, так что в семейство помещается около шестидесяти вариантов; кроссовки в восьми цветах и четырнадцати размерах документация советует подавать как восемь семейств по четырнадцать, потому что за пределами лимита результат режется без ошибки. Пятый: записи мерчанта по семействам, где изменение цены и пополнение именуют вариант. Шестой: для цифр, которых у платформы нет, возвращать None с пометкой, а не подставной ноль.

Для пилота README предлагает начинать с малого. Покупательский пилот реализует поиск и карточку товара, а остальное заглушает: метод-заглушка возвращает результат «недоступно» и не меняет ни байта промпта. Мерчантский пилот реализует восемь методов чтения, записи отказывают. Система, которой у бизнеса нет совсем, выключается переключателем enable_*: это убирает её инструменты, строки промпта и правило grounding на всех трёх путях, а сценарии, которым она нужна, паркуются в каталоге skills/_staged/. Свой сценарий добавляется каталогом с файлом SKILL.md, доменный интерфейс расширением PresentationExtension (вертикали поставляют семь), а brand_name, assistant_name и brand_voice в конфиге задают личность ассистента.

Модели заданы строкой в конфиге, а переключение платформы сосредоточено в одном месте и зависит от рантайма

По docs/deployment.md код по умолчанию ходит в API Anthropic, но у каждого пути есть одно место, где деплой переключает платформу. Рантаймы Messages API принимают любой асинхронный клиент из пакета anthropic аргументом client=: AsyncAnthropicVertex для GCP Vertex AI, AsyncAnthropicBedrockMantle или AsyncAnthropicBedrock для AWS, AsyncAnthropicFoundry для Microsoft Foundry, AsyncAnthropic с base_url и auth_token для собственного шлюза. Пакеты требуют anthropic 0.91 и новее. Рантаймы Agent SDK HTTP-клиента не создают: платформу выбирает CLI Claude Code по переменным окружения, которые добавляются в options.env. Managed Agents работает на инфраструктуре Anthropic, поэтому у него нет варианта для Vertex, Bedrock и Foundry.

Модель задаётся строкой в конфиге: поля model и memory_model у каждой роли, у мерчанта ещё analysis_model. Значения по умолчанию, по таблице документа: claude-sonnet-5 для покупательского агента, claude-opus-5 для мерчантского, claude-haiku-4-5-20251001 для извлечения памяти. Грамматика идентификаторов у платформ разная: Vertex пишет датированные снимки через @, Bedrock через Mantle берёт идентификаторы с префиксом anthropic., а через Invoke API идентификаторы inference-профилей. Все три поля идут через один клиент, поэтому все три модели должны существовать на целевой платформе. Живого разговора с облаком в CI нет; документ просит прогнать его на своей платформе до того, как на неё полагаться.

Доступность API Anthropic и облачных платформ для конкретной страны или способа оплаты в документации репозитория не обсуждается. Для собственного шлюза документ называет требование: отдавать /v1/messages со стримингом SSE для Messages API, а для Managed Agents ещё проксировать /v1/skills, /v1/agents, /v1/environments, /v1/sessions и поток событий сессии с заголовками anthropic-beta.

Демо поднимается шестью командами, а плагин Claude Code собирает агента под ваш стек

Порядок запуска из README (нужны Python 3.11 и новее и Node 22, ключ ANTHROPIC_API_KEY в файле .env):

Флаг --merchant поднимает портал мерчанта вместо витрины, --all оба. В README каждой вертикали есть раздел Try с репликами, которые прогоняет scripts/smoke_chat.py. Розничная ACME показывает поиск, сравнение, корзину, checkout и память; ACME Travel добавляет инвентарь с датами; ACME Mobile матрицу тарифов и серверные раскрытия комиссий; ACME Tickets таймированные удержания мест, листы ожидания и карту зала.

Второй способ начать: плагин commerce-builder для Claude Code. Он читает клонированный репозиторий как эталон и собирает агента на этих пакетах против ваших систем либо проверяет уже написанного. Установка и первая команда из README:

Команда /scaffold-commerce-agent спрашивает о стеке, проговаривает план и строит проект. Дальше /add-commerce-flow добавляет сценарий, /author-commerce-evals пишет evals, /review-commerce-agent начинает с уже существующего агента. Собственных MCP-коннекторов в поставке нет: оба агента ходят в системы через интерфейсы бэкенда. Где официальный коннектор является источником истины (Snowflake, BigQuery, Stripe, Square, Slack и другие в списке README), он и становится целью интеграции. MCP-сервер торговой платформы вызывается из метода бэкенда на сервере, и гейты provenance остаются перед каждой записью.

Проверка после правок: ruff check и ruff format --check, pytest, python scripts/check.py; python scripts/verify_all.py добавляет сухие прогоны деплоя и сборку веб-приложений; python scripts/smoke_chat.py --vertical travel проводит один живой разговор и требует ключ. Чтобы убедиться, что кэширование промпта работает, README советует читать cache_read_input_tokens из события turn_complete: ноль на втором ходу означает, что префикс промпта изменился.

Что делать команде, которая пишет ассистента для магазина

1. Поднять розничное демо по шести командам выше (Python 3.11 и новее, Node 22, ключ API) и пройти реплики из раздела Try в examples/retail/ на витрине (порт 3000) и в портале мерчанта (флаг --merchant, порт 3100).
2. Сверить таблицу «Enforced in code» и список «What a deployment owns» из docs/safety.md с собственной платформой: аутентификация, учётные данные, лимиты запросов, бизнес-правила, оплата, персональные данные в памяти, логи.
3. Для пилота реализовать в StorefrontBackend только поиск и карточку товара, для MerchantBackend восемь методов чтения. Отсутствующие системы выключить через enable_*, зависимые сценарии убрать в skills/_staged/.
4. Разложить каталог по трём формам записи из docs/backends.md и проверить самое большое семейство против лимита max_fenced_chars в 12 000 символов.
5. Выбрать завершение checkout: свой маршрут, размещённый URL платформы через checkout_handoff или ссылка на продавца для маркетплейса; оплата остаётся в хосте.
6. Для Vertex AI, Bedrock, Foundry или шлюза передать клиент аргументом client= (anthropic 0.91 и новее) или переменные CLI в options.env и заменить все три идентификатора моделей.
7. Перед выкладкой прогнать ruff, pytest, scripts/check.py и scripts/verify_all.py, затем один живой разговор scripts/smoke_chat.py на своей платформе; при смене модели перегнать evals по разделу «Still asked of the model».

Репозиторий создан 1 сентября, анонс в аккаунте Claude Developers вышел 2 сентября в 19:33 UTC. На 3 сентября, 01:53 мск, по данным GitHub API у проекта 277 звёзд и 46 форков. Поддержки и приёма внешних изменений Anthropic не обещает: «This is a reference implementation; it is not maintained and does not accept contributions», говорится в README. На практике это значит, что исправления и адаптацию под свои системы команде придётся вести в собственном форке, а промпты и гейты под новые модели проверять своими evals. Цен, лимитов и сроков дальнейшего развития Anthropic в репозитории не называет.

Источники: Claude Developers в X: анонс открытия Claude Commerce Agents (2 сентября 2026), GitHub: anthropics/commerce-agents, README репозитория commerce-agents, docs/safety.md: правила, проверяемые кодом, и обязанности деплоя, docs/backends.md: подключение своих систем, docs/deployment.md: Vertex AI, Bedrock, Microsoft Foundry и шлюзы, Плагин commerce-builder для Claude Code, Скиллы покупательского агента, Скиллы мерчантского агента

Изображение на обложке: Anthropic, кадр из анонса Claude Commerce Agents

Для тех, кто держит Home Assistant дома или на сервере, обновление меняет три повседневные вещи: диагностику Thread и Wi-Fi устройств Matter, разбор «почему свет включился сам» и защиту входа. Ниже по порядку, что изменилось и кому это ничего не даст.

• Панель Matter получила кнопку Show map: карта показывает, кто ходит по Thread, кто по Wi-Fi, где пограничные маршрутизаторы, и толщиной линий отражает уровень сигнала.
• В Activity клик по строке открывает всю цепочку: кто запустил (человек, состояние, расписание, интеграция или перезапуск), через какие автоматизации прошло, что изменилось; метки времени с миллисекундами.
• Home Assistant Cloud теперь передаёт реальный IP при попытке входа, так что бан по IP из прошлого релиза начинает работать и для удалённых подключений.
• Панель Security: секция Active alerts появляется только при событии, уровни Alert и Warning настраиваются на каждую сущность; отдельно секция Favorites.
• Modbus: первые интеграции на новой библиотеке modbus-connection и типизированном tmodbus (Fronius по SunSpec, Sofar, Flexit) настраиваются из интерфейса и делят одно соединение с инвертором.

Карта Matter догнала Zigbee и Z-Wave

Карты соединений для Zigbee (через ZHA), Z-Wave и Bluetooth в Home Assistant были давно, а для Matter граф жил только в отдельном веб-интерфейсе Matter Server, куда мало кто заходил. В 2026.9 на панели Matter появилась кнопка Show map, и та же картинка рисуется внутри Home Assistant тем же движком, что у других протоколов. На карте видно, какие устройства работают по Thread, а какие по Wi-Fi, какие из них маршрутизаторы или пограничные маршрутизаторы, а какие батарейные конечные устройства, и путь от Home Assistant до каждого. Пограничные маршрутизаторы и точки доступа подписаны именами хостов или Wi-Fi сетей, а не серийниками. Цвет линии обозначает транспорт, толщина и направление стрелки уровень сигнала с каждой стороны.

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

Activity объясняет, почему устройство изменилось

Журнал Activity показывал, что изменилось, но не почему: чтобы найти виновную автоматизацию, приходилось угадывать, открывать её трассу и идти назад к сущности-триггеру. После недавнего редизайна строк журнала стало хуже: фразу, объяснявшую источник записи, заменили на область и устройство. Теперь клик по любой строке открывает диалог с полной цепочкой сверху вниз: что запустило событие (человек, смена состояния, расписание, интеграция или перезапуск), через какие автоматизации и скрипты оно прошло и чем закончилось. Каждый шаг кликабельный и ведёт к сущности или к трассе автоматизации. Метки времени с точностью до миллисекунды, поэтому события в одну секунду больше не перепутываются.

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

Вход через Cloud с настоящим IP

Для подписчиков Home Assistant Cloud (сервис Nabu Casa, коммерческого партнёра Open Home Foundation) попытки входа раньше выглядели как локальные: в журнале стояло 127.0.0.1, и понять, вы ли ошиблись паролем или это бот, было нельзя. Теперь прокидывается реальный адрес, а значит начинает работать бан по IP, добавленный в интерфейс в прошлом релизе; проект советует включить его вместе с двухфакторной аутентификацией. Для локальных установок без Cloud здесь ничего не меняется.

Там же для подписчиков появился тестовый движок распознавания речи от нового провайдера Soniox: по словам разработчиков, он лучше справляется с акцентами, фоновым шумом и неанглийскими языками. Включается в Settings > System > Labs, обещание прежнее: аудио не логируется, не хранится и не используется для обучения. Функция помечена как экспериментальная и может не стать постоянной. Без подписки доступен 31-дневный пробный период без платёжных данных; о доступности оплаты Cloud из России в релизе ничего не сказано.

Тревоги на панели Security

Встроенная панель Security получила два запрошенных раздела, оба настраиваются из одного редактора. Active alerts показывается только когда что-то требует внимания: открытая дверь, сработавший датчик дыма. Для каждой сущности задаётся уровень, Alert или Warning, чтобы приоткрытое окно не подсвечивалось так же, как пожарная тревога; если событий нет, секция скрыта. Рядом Favorites: закреплённые двери, замки и датчики, которые проверяют чаще всего. Дизайн, включая цвета уровней и пульсирующую анимацию, пришёл из концепта участника сообщества; вывод тех же тревог на домашнюю панель обещан в одном из следующих релизов.

Modbus переезжает из YAML в интеграции

Modbus-устройства (инверторы, счётчики, тепловые насосы) поддерживались через YAML-интеграцию, где карту регистров пишет сам пользователь. Она остаётся, но 2026.9 закладывает другой путь: интеграции, которые уже знают протокол конкретного устройства, так что его выбирают в интерфейсе как любое другое. Первые три построены именно так. Fronius получил опциональный Modbus TCP по SunSpec с данными по каждой строке панелей (ток, напряжение, мощность и накопленная энергия по каждому MPP-трекеру), которых нет в его локальном HTTP API, и делит одно соединение с другими клиентами: часть моделей Fronius держит лишь несколько одновременных Modbus-сессий. Sofar Inverter Modbus и Flexit сделаны по той же схеме. Под капотом отдельная библиотека modbus-connection и полностью типизированный tmodbus; как строить свою интеграцию поверх них, описано в блоге разработчиков.

Интеграции, удаления и мелочи

Новых интеграций 13: зарядки Besen (по Bluetooth LE) и NexBlue, вентиляция Flow-it, спа Hot Spring, замок ISEO Argo BLE, мониторинг LibreNMS, тепличный контроллер Ridder HortiMaX Pro, Samsung TV через порт RS-232 (ExLink), зарядка Silla Prism по MQTT, инверторы Sofar по Modbus, электровелосипеды Specialized Turbo, усилители Tonewinner по RS-232 и «Collection image», который отдаёт случайную картинку из папки как сущность. Плюс 15 виртуальных интеграций брендов на базе Midea. Из интерфейса теперь настраиваются Flexit, Netio и Remember The Milk.

Среди улучшений: камеры Shelly с детекцией движения и переключателем приватности, UniFi Protect по одному API-ключу без локального пользователя (пока только тревожная панель, камеры и свет), MikroTik с переключателями интерфейсов и режимом PoE, Proxmox VE с паузой ВМ, Portainer с событиями Docker, Transmission с датчиком свободного места, Google Gemini с настройкой бюджета рассуждений. Удалена интеграция VLC: ей нужен прямой доступ к звуку, что работало только в устаревшем способе установки Core; VLC via Telnet остаётся.

Из прочего: раздел настроек Connectivity собрал Matter, Zigbee, Z-Wave, KNX, MQTT, Thread, Bluetooth и остальные протоколы под одной записью; у интеграции Sun появились условия и триггеры для золотого и синего часа, полярного дня и ночи; графики можно листать с клавиатуры, а значения озвучиваются тоном; диалог перезапуска показывает, какие автоматизации и скрипты сейчас выполняются. Список обратно несовместимых изменений опубликован в релиз-ноутах, перед обновлением его стоит прочитать вместе с переменами в шаблонах и настройке Sun.

Что делать

• Обновление ставится штатно через Settings > System > Updates; перед ним сделайте резервную копию и проверьте раздел Backward-incompatible changes в релиз-ноутах.
• Если у вас Matter: после обновления откройте панель Matter и нажмите Show map; если страница просит обновить Matter Server, обновите его.
• Если вы подписчик Cloud: включите бан по IP и двухфакторную аутентификацию, теперь они видят реальные адреса.
• Если у вас Fronius, Sofar или Flexit: проверьте новые интеграции вместо YAML-Modbus; для остальных Modbus-устройств пока остаётся ручная карта регистров.

Из обещанного на будущее: вывод тревог Security на домашнюю панель и перенос остальных платформ UniFi Protect на новый API, без привязки к конкретному релизу. С 4 по 8 сентября команда стоит на выставке IFA в Берлине.

Источник: Home Assistant: 2026.9: There's room on this bus

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

Для тех, кто просто обновляет curl, ничего не меняется: все шесть находок имеют низкую серьёзность и уже исправлены в 8.22.0. Интересна сама ситуация: curl стоит, по оценке AISLE, более чем в 20 млрд установленных экземпляров, и это одна из самых проверенных кодовых баз в мире. AISLE подаёт результат как подтверждение своего тезиса «система важнее модели»: специализированная обвязка находит дыры там, где фронтирные модели уже остановились. Насколько сопоставимы были условия запуска, из материала не следует.

• 24 августа Стенберг написал, что к релизу готовы три CVE, а Mythos, Zeropath и Codex Security «больше ничего не находят».
• 25 августа он же опубликовал счёт «Mythos: 0 Aisle: 29»: AISLE прислала 29 отчётов.
• Шесть из них команда безопасности curl признала уязвимостями и выдала CVE; все шесть низкой серьёзности, исправлены в curl 8.22.0 от 2 сентября (всего в релизе девять CVE curl и одна в wcurl).
• К 28 августа число ожидающих CVE выросло с трёх до десяти; шесть из десяти — от AISLE.
• AISLE утверждает, что тот же эффект в ядре Linux заметил мейнтейнер стабильных веток Грег Кроа-Хартман; независимого подтверждения этой цитаты у редакции нет.

Как за четыре дня три CVE превратились в десять

Хронология собрана по публичным записям Стенберга в Mastodon. 24 августа он написал, что до релиза девять дней и объявлять предстоит всего три CVE (две низкой серьёзности, одна средней), добавив в скобках: «Mythos говорит, что больше ничего не находит. Zeropath не находит уязвимостей. Codex security показывает пустой список» (перевод редакции). Zeropath здесь — ещё один коммерческий ИИ-сканер кода.

По словам AISLE, после этой записи компания запустила свою систему на curl. 25 августа Стенберг опубликовал короткий пост: «Mythos: 0 Aisle: 29». Это число отчётов, а не подтверждённых уязвимостей: часть из 29 могла оказаться ложными срабатываниями или проблемами без последствий для безопасности, и решение принимала команда curl, а не AISLE. 28 августа Стенберг сообщил уже о десяти ожидающих CVE, одна из которых относится к обёртке wcurl.

В итоговом релизе 8.22.0, вышедшем 2 сентября, шесть из девяти CVE curl в таблице уязвимостей curl числятся за Станиславом Фортом из AISLE. По данным компании, три отчёта были отправлены 24 августа, два 26 августа и один 27 августа.

Что именно нашли: шесть дыр в узких конфигурациях

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

• CVE-2026-80229: use-after-free при работе с провайдерами OpenSSL; затронуты версии с 8.14.0 по 8.21.0.
• CVE-2026-80230: обход пиннинга сертификата в сборках с OpenSSL; версии с 7.45.0 по 8.21.0.
• CVE-2026-80231: повторное использование соединения при смене настройки системного хранилища сертификатов (CURLSSLOPT_NATIVE_CA) между запросами; версии с 7.71.0 по 8.21.0.
• CVE-2026-80255: обход атрибута secure у куки с помощью символа табуляции; версии с 8.13.0 по 8.21.0.
• CVE-2026-82208: в сборках с wolfSSL попадание в кэш CA перекрывало пользовательский callback проверки; версии с 8.9.1 по 8.21.0.
• CVE-2026-82209: кука, ограниченная доменом из публичного списка суффиксов, принималась не так, как должна; версии с 7.46.0 по 8.21.0.

Сама AISLE объясняет низкую серьёзность зрелостью curl: то, что в нём ещё осталось, прячется в редких сочетаниях опций и бэкендов, и практическое влияние таких дыр ограничено. Это честная оговорка, и её стоит помнить при чтении заголовка «6 : 0». В advisory проекта все шесть помечены как низкие; они закрываются обычным обновлением до 8.22.0, о котором Tproger писал ранее.

Почему это сравнение чище обычных бенчмарков

Обычно результаты ИИ-сканеров показывают на CTF-задачах или наборах с известными ответами, которые могли попасть в обучающие данные. Здесь всё иначе: анализировался живой продакшен-код, а признавали ли находку уязвимостью и давать ли ей CVE, решали мейнтейнеры curl. Базовая линия тоже была публичной и датированной заранее: «ноль» у Mythos и Codex Security Стенберг написал до того, как AISLE запустила свою проверку. AISLE прямо оговаривает, что CVE как метрика несовершенна, но для поиска нулевых дней это редкий случай внешней валидации: каждая CVE подтверждена экспертами и исправлена для реальных пользователей.

При этом источник заинтересованный: AISLE продаёт аудит кода и в конце своего же отчёта предлагает услугу AISLE Snapshot. Компания также приводит ответ Грега Кроа-Хартмана, мейнтейнера стабильных веток ядра Linux, на запись Стенберга: он якобы видит ту же картину для Linux и не понимает, что AISLE делает иначе. Редакция открыть эту запись на social.kernel.org не смогла, поэтому цитата остаётся утверждением AISLE.

Важно и то, чего в материале нет. AISLE не раскрывает, какие модели лежат в основе её системы и как устроен «харнесс» вокруг них; сам Стенберг 25 августа в ответе читателю написал, что, насколько он понимает, AISLE в основном строит обвязку вокруг существующих моделей, но экспертом себя не считает и видит только результаты. Неизвестно и то, сколько из 29 отчётов были отклонены и почему, а также запускались ли Mythos и Codex Security в сопоставимом режиме и с сопоставимым бюджетом. Стенберг с мая описывает опыт с Mythos на curl: модель находила уязвимости и раньше, так что «ноль» 24 августа означает не бесполезность модели, а исчерпание её находок к этому моменту.

Что делать читателю

Практическое действие одно: обновить curl и libcurl до 8.22.0 там, где вы собираете их сами, и дождаться пакетов дистрибутивов там, где не собираете. Проверить версию и TLS-бэкенд можно командой curl --version: первая строка покажет номер версии и библиотеку (OpenSSL, wolfSSL, GnuTLS), от которой зависит, касаются ли вас три из шести описанных дыр.

Для тех, кто отвечает за безопасность собственного кода, вывод шире. Если три известных ИИ-сканера на тот момент не показывали в проекте новых уязвимостей, а четвёртый нашёл в нём шесть подтверждённых, отчёт «уязвимостей не найдено» от любого одного инструмента стоит читать буквально: этот инструмент ничего не нашёл. Цифры AISLE стоит перепроверить на следующих релизах curl и других проектах, где базовая линия тоже публична; редакция будет следить за таблицей CVE curl и за тем, подтвердит ли Кроа-Хартман сказанное о ядре.

Источники: AISLE: AISLE Discovered Six curl CVEs After OpenAI and Anthropic Found Zero, Дэниел Стенберг, 24 августа: три CVE в ожидании, Дэниел Стенберг, 25 августа: «Mythos: 0 Aisle: 29», curl: уязвимости, закрытые в 8.22.0, Дэниел Стенберг: Mythos finds a curl vulnerability (май 2026)

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

По классификации самого проекта восемь из десяти уязвимостей имеют низкую серьёзность и две среднюю: CVE-2026-19931 про повторное использование соединения с Negotiate-аутентификацией и CVE-2026-80256 в wcurl. Критических нет, но набор показательный: проблемы найдены в проверке сертификатов, в куках и в аутентификации, то есть в местах, где curl обычно доверяют без оглядки.

• curl 8.22.0 вышел 2 сентября 2026 года, это 276-й релиз проекта; между релизами прошло 70 дней.
• Десять CVE: девять в curl и libcurl и одна в wcurl; восемь низкой серьёзности, две средней.
• Из нового: экспериментальная поддержка HTTP Message Signatures по RFC 9421, блокировка отката на NTLM в SPNEGO, поддержка Apple GSS Framework.
• Удалена поддержка TLS-SRP; объявлены будущие удаления HTTP/2 Server Push, встроенных криптореализаций, NTLM и SMB.
• 302 исправления ошибок, 525 коммитов, 85 участников, из них 55 впервые.

Что именно закрыли

Полный список из базы уязвимостей curl, с оценками серьёзности самого проекта:

• CVE-2026-19931 (средняя): обход аутентификации Negotiate через повторное использование соединения, установленного от имени другого пользователя окружения.
• CVE-2026-13608 (низкая): обход SASL-аутентификации в OpenLDAP.
• CVE-2026-18924 (низкая): use-after-free в обработке HTTP/2 Server Push.
• CVE-2026-80229 (низкая): use-after-free в работе с провайдерами OpenSSL.
• CVE-2026-80230 (низкая): обход пиннинга публичного ключа при сборке с OpenSSL.
• CVE-2026-80231 (низкая): повторное использование соединения при работе с системным хранилищем сертификатов.
• CVE-2026-80255 (низкая): обход атрибута Secure у куки с помощью символа табуляции.
• CVE-2026-82208 (низкая): при сборке с wolfSSL попадание в кэш CA перекрывало пользовательский callback проверки сертификата.
• CVE-2026-82209 (низкая): куки с доменом из Public Suffix List принимались там, где не должны.

Отдельно идёт CVE-2026-80256 (средняя) в wcurl, обёртке для скачивания файлов одной командой: обратный слеш в аргументе позволял обойти её проверки. По данным advisory, уязвимый wcurl входил в поставку curl с 8.14.0 по 8.21.0 и распространялся отдельно, так что обновлять его нужно тем же путём, каким он к вам попал.

Четыре пункта из девяти объединяет одна черта: соединение или кука, проверенные в одном контексте, использовались в другом (CVE-2026-19931, 80231, 80255, 82209). Остальные касаются обхода аутентификации, use-after-free и проверки сертификатов. Для библиотеки, которая живёт в тысячах приложений и держит пул соединений, это самый неприятный класс ошибок: снаружи всё выглядит как штатная работа, а данные уходят не туда. По нашей оценке, реальная эксплуатация большинства из них требует специфической конфигурации (LDAP, Negotiate, wolfSSL, пиннинг), поэтому проект и оценил их как низкие. Но проверять, какая именно сборка libcurl у вас стоит и с чем она собрана, всё равно придётся.

Шесть изменений

Главная функциональная новинка, экспериментальная поддержка HTTP Message Signatures по RFC 9421. Это стандарт подписи HTTP-запросов и ответов на уровне заголовков: клиент подписывает выбранные части сообщения (метод, путь, отдельные заголовки, хэш тела), а сервер проверяет подпись независимо от TLS. Такие подписи используют платёжные API, федеративные соцсети и корпоративные шлюзы, где нужно доказать, что запрос не менялся на промежуточных прокси. Даниэль Стенберг подробно описывал реализацию в июльской заметке; в 8.22.0 функция помечена как экспериментальная, то есть включается при сборке и может поменять API.

Второе изменение, связанное с безопасностью: curl теперь блокирует откат на NTLM внутри SPNEGO-переговоров. Раньше при аутентификации Negotiate сервер мог предложить более слабый NTLM, и клиент соглашался; теперь такой откат запрещён. Это согласуется с планом удалить NTLM целиком в одном из следующих релизов.

Остальные пункты: поддержка Apple GSS Framework для Kerberos-аутентификации на macOS и iOS без сторонних библиотек, опция для быстрого UDP в системах Apple, так называемые API guards, и удаление поддержки TLS-SRP, редко используемого метода аутентификации по паролю внутри TLS. Появилось четыре новых опции curl_easy_setopt() и четыре новых ключа командной строки; новых публичных функций libcurl нет.

Что уберут дальше

В анонсе перечислены четыре будущих удаления: HTTP/2 Server Push, локальные криптореализации, NTLM и SMB. Server Push браузеры перестали поддерживать ещё несколько лет назад, и одна из сегодняшних CVE найдена как раз в этом коде. Локальные криптореализации, собственные реализации MD4, MD5 и подобных алгоритмов, которые curl использовал там, где не было TLS-бэкенда, тоже уходят: их оставалось поддерживать ради того же NTLM. Точные версии, в которых код исчезнет, в анонсе не названы.

На практике это касается тех, кто ходит curl в корпоративные Windows-сервисы через NTLM или скачивает файлы с SMB-шар. Таким скриптам стоит начать переезд на Kerberos/Negotiate и на другие протоколы уже сейчас.

Что делать

1. Проверить версию: curl --version покажет и версию curl, и с каким TLS-бэкендом она собрана (OpenSSL, wolfSSL, Schannel, Secure Transport). От бэкенда зависит применимость части CVE (OpenSSL, wolfSSL, системное хранилище сертификатов); остальные касаются протоколов и функций сборки: LDAP, Negotiate, HTTP/2, куки.
2. Обновиться до 8.22.0 из дистрибутива или со страницы загрузки. Если вы используете старую ветку с бэкпортами, проект обещает отдельный анонс Rock-solid curl в ближайшие дни.
3. Пересобрать или обновить всё, что тянет libcurl статически или в составе своего образа: Docker-образы, мобильные приложения, скомпилированные биндинги для Python, PHP, Rust и Go.
4. Если используете wcurl, обновить и его: CVE-2026-80256 закрыта в самой обёртке, а не в libcurl, и wcurl мог прийти как вместе с curl 8.14.0–8.21.0, так и отдельным пакетом.
5. Если скрипты ходят по NTLM или SMB, запланировать переезд: оба протокола объявлены к удалению.

Следующий релиз curl запланирован на конец октября 2026 года, если по 8.22.0 не придут серьёзные регрессии. Отдельно стоит следить за анонсом Rock-solid curl: это ветка с исправлениями безопасности для тех, кто сидит на старой ветке и не может перейти на основную, и она выйдет позже основного релиза.

Источники: Daniel Stenberg: curl 8.22.0, curl: список уязвимостей, Скачать curl, Daniel Stenberg: HTTP Message Signatures with curl

Изображение на обложке: Логотип: curl project

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

• 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

DoltLite запустили 25 марта 2026 года как замену SQLite, у которой вместо B-tree под капотом content-addressed Prolly Tree. Всё остальное, по описанию основателя DoltHub Тима Сена, от SQLite: парсер SQL, анализатор, файловый слой и тестовый harness. До беты ушло около 2000 pull request и пять месяцев.

• DoltLite 0.50.0 объявлен бетой: стабильный формат хранения, SQL-совместимость и полный набор операций контроля версий.
• Поддерживаются branch, merge, diff, rebase, cherry-pick, reset, а также push, pull, clone и fetch на свой remote или DoltHub.
• Из 892 277 TCL-тестов SQLite проходят 99,46%; sqllogictest на 5,8 млн запросов проходит полностью; известно 4809 расхождений.
• В памяти чтение медленнее SQLite на 10%, запись на 60%; для файловых баз чтение на уровне SQLite, пакетная запись медленнее на 10%.
• Мелкие autocommit-записи медленнее в 3,1 раза: около 400 мкс против 125 мкс у SQLite.

Что «бета» означает у DoltHub

Компания перечисляет четыре условия. Стабильный формат хранения: до беты он менялся 12 раз, а текущий вариант продержался 57 релизов, больше трёх месяцев, и для будущих несовместимых изменений обещан путь миграции. SQL-совместимость: DoltLite проходит 100% sqllogictest, это 5,8 млн запросов, и 99,46% из 892 277 TCL-тестов самого SQLite. Полный контроль версий: ветки, слияния, diff, rebase, cherry-pick, reset и удалённые операции. И производительность, пригодная для production, с оговорками ниже.

Оставшиеся 4809 расхождений с SQLite DoltHub объясняет архитектурой: отказ от rowid, chunk вместо page и отсутствие WAL и journal-файлов рядом с базой. Если код полагается на эти детали SQLite, миграция не будет прозрачной; проверить стоит именно их.

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

Замеры приводит сам вендор. Для базы в памяти чтение медленнее SQLite примерно на 10%, запись примерно на 60%. Для файловой базы чтение на уровне SQLite, пакетная запись медленнее примерно на 10%. Хуже всего мелким autocommit-транзакциям: каждая такая запись занимает около 400 мкс против 125 мкс у SQLite, то есть в 3,1 раза дольше. Причина в природе Prolly Tree: каждое изменение порождает новые chunk с хешами, и на одиночной вставке эта работа не амортизируется.

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

Что можно сделать уже сегодня

Рабочий цикл похож на Git: создать ветку, изменить данные, посмотреть diff, слить. Удалённые операции push, pull, clone и fetch работают с собственным remote или с DoltHub. 7 августа DoltHub добавила поддержку DoltLite в Dolt Workbench, свой графический клиент, где ветвление, diff и merge доступны из интерфейса.

Сборки, по данным репозитория, есть для Linux, macOS, Windows, Python, Node.js, Rust, Android и WebAssembly. Лицензия в анонсе беты не указана, и перед использованием в коммерческом продукте её стоит уточнить в репозитории.

Релиз 0.50.0 не содержит изменений кода относительно 0.11.57: номер версии подняли, чтобы обозначить бету. Если вы уже на 0.11.57, обновляться ради кода не нужно.

Контекст

DoltHub с 2018 года развивает Dolt, версионируемую базу, совместимую с MySQL. DoltLite переносит ту же идею на встраиваемый движок: Prolly Tree даёт дешёвое сравнение версий по хешам и структурное слияние, а SQLite даёт зрелый SQL-слой. По нашей оценке, главный практический вопрос беты не в фичах, а в том, насколько быстро проект закроет разрыв в мелких записях: именно там пройдёт граница между «база для датасетов» и «замена SQLite в приложении».

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

Источники: Блог DoltHub: DoltLite Beta, Релиз v0.50.0 на GitHub

Wasmi написан на Rust и рассчитан на сценарии, где нужен именно интерпретатор: плагины в приложениях, встраиваемые устройства, песочницы, смарт-контракты. Релиз опубликован на GitHub и crates.io; работа над ним заняла восемь месяцев.

• Wasmi 2.0 примерно в 2,2 раза быстрее Wasmi 1.0 по геометрическому среднему; замеры вендора на Apple M2 Pro, AMD EPYC 7763 и Intel Xeon Platinum 8370C.
• Появились четыре режима dispatch; indirect-threaded на 10–15% медленнее direct-threaded, но экономит память под IR.
• Новое промежуточное представление с аккумуляторными регистрами ireg, freg32 и freg64 и 64-битными ячейками стека.
• Fuel metering стал стабильным и привязан к входному Wasm-коду; появился deterministic profile и новый CLI.
• Включение SIMD больше не замедляет обычный код: в 1.0 это стоило около 8%, в 2.0 разница в пределах шума.

Откуда взялись 2,2 раза

Автор подробно разбирает три источника ускорения. Первый: режимы диспетчеризации инструкций. В 1.0 был один switch-loop, теперь их четыре: direct-threaded, indirect-threaded, switch-loop и call-loop. Режим auto-dispatch включён по умолчанию и выбирает threaded-код там, где компилятор и платформа это позволяют. Indirect-threaded вариант примерно на 10–15% медленнее direct-threaded, зато требует меньше памяти на промежуточное представление, что важно для микроконтроллеров.

Второй источник: новое промежуточное представление. В 1.0 операнды адресовались смещениями в стеке; в 2.0 появились аккумуляторные регистры ireg, freg32 и freg64, через которые проходит большая часть значений. Ячейки стека стали всегда 64-битными, а SIMD-значения занимают две соседние ячейки, поэтому поддержка SIMD больше не стоит производительности обычного кода.

Третий: структура CodeMap, в которой хранятся скомпилированные функции. Она стала append-only с раздельными buckets, поэтому вызов внутренней функции на горячем пути не требует ни одного lookup и не берёт блокировок. Доступ к данным экземпляра модуля, по бенчмарку count/globals, улучшился примерно на 35%; таблицы Wasm уменьшились в 2–4 раза за счёт 32-битных ссылок.

Как измеряли и с кем сравнивали

Замеры сделаны на проекте wasmi-benchmarks, который можно запустить самостоятельно, на трёх машинах: Apple M2 Pro, AMD EPYC 7763 и Intel Xeon Platinum 8370C. Кроме Wasmi 1.0 в сравнении участвовали интерпретаторы Wasm3, WAMR в режиме fast-interpreter, Wasmtime Pulley и Stitch. Это замер вендора: набор тестов, машины и конфигурации выбирал сам проект, и автор оговаривает, что цифры зависят от нагрузки.

В посте есть поучительный эпизод про компилятор. Rust 1.92 включил оптимизацию DestinationPropagation, из-за чего CoreMark у интерпретатора Stitch упал с более чем 3000 до примерно 2200 баллов; после исправления результат вернулся выше 3000. Похожая проблема нашлась и в Wasmi: её устранение подняло CoreMark примерно с 2800 до более чем 4200 баллов, то есть примерно на 50%. Вывод для практики: производительность интерпретатора на Rust заметно зависит от версии компилятора, и после обновления toolchain бенчмарки стоит перепрогонять.

Что изменилось кроме скорости

• Fuel metering, то есть учёт «топлива» на выполнение, стал стабильным и считается по входному Wasm-коду, а не по внутренним инструкциям; это важно для смарт-контрактов и лимитов на плагины.
• Deterministic profile гарантирует одинаковый результат на разных платформах.
• Поддержка memory64 стала опциональной; отключение валидации через feature validate уменьшает бинарник примерно на 200–300 КБ.
• Обновлённый CLI и C-API.

Кому обновление ничего не даст: тем, кто запускает Wasm через JIT-рантаймы вроде Wasmtime или V8 на сервере и в браузере. Интерпретатор нужен там, где JIT запрещён (iOS, некоторые блокчейн-среды), где нет памяти под скомпилированный код или где важна предсказуемость времени запуска.

Как попробовать

Wasmi ставится как обычный crate из crates.io; для Rust-проекта достаточно обновить зависимость wasmi до версии 2.0 и прогнать тесты: автор предупреждает о смене внутреннего представления, а значит, поведение при ошибках и лимитах стоит перепроверить. Проект открыт, спонсируется Stellar Development Foundation с октября 2024 года.

В планах на Wasmi 3.0 названы оставшиеся части WebAssembly 3.0: function-references, exception-handling и gc. Сроков автор не называет.

Источники: Блог Wasmi Labs: Wasmi v2.0, Релиз v2.0.0 на GitHub

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

История касается не только AnkiDroid. Правило, на которое ссылается Google, запрещает вести пользователей к оплате мимо Google Play Billing; пожертвования допускаются лишь для организаций с подтверждённым налоговым статусом благотворительной и на определённых условиях. У большинства open source-проектов таких документов нет.

• Google Play счёл ссылку AnkiDroid на Open Collective нарушением Payments Policy; первое уведомление пришло 20 июля, документы проекта Google 7 августа не принял.
• Требование: убрать ссылки на платежи вне Google Play Billing или подтвердить статус tax-exempt организации; сам Play Billing для пожертвований таких организаций запрещён.
• Дата удаления при отсутствии исправления: сначала 3 августа, затем 11 сентября 2026 года, оба раза с оговоркой «везде, кроме Индии и России»; причина исключения не объяснена.
• AnkiDroid связан с организацией статуса 501(c)(6), в приложении ничего не продаётся, Open Collective — единственный источник денег; мейнтейнеры убирают ссылки из Play-сборки ветки 2.24.x.
• Разработчикам с кнопкой «поддержать» в бесплатном приложении: ссылка на внешнюю площадку без статуса благотворительной организации — ровно случай AnkiDroid.

Что именно нарушил AnkiDroid

По тикету Google номер 9-2777000041594, нарушение относится к Payments Policy: внутри приложения была ссылка на Open Collective, платформу, через которую проект собирает пожертвования, а проблема помечена для сборки с version code 122400300. Google предложил два выхода: убрать все ссылки, «направляющие пользователей на оплату через системы, отличные от биллинга Google Play», либо доказать, что AnkiDroid — организация со статусом tax-exempt, освобождённая от налогов по американским правилам.

Remove any links directing users to make payments using systems other than Google Play's billing system.

Загвоздка в том, что политика Google одновременно запрещает использовать сам Google Play Billing для пожертвований освобождённым от налогов организациям, а AnkiDroid связан с организацией статуса 501(c)(6), профессиональной ассоциацией, а не благотворительным фондом. То есть донаты через Play невозможны, а ссылка наружу запрещена. Команда отдельно подчёркивает, что в приложении ничего не продаётся, Open Collective — единственный источник финансирования, а сам AnkiDroid не связан с Anki, AnkiWeb, AnkiMobile и AnkiHub.

Хронология

• 20 июля 2026 года: первое автоматическое уведомление Google с датой удаления 3 августа «везде, кроме Индии и России».
• 7 августа: Google сообщил, что присланные документы нарушение не устранили.
• Позднее уведомление: новая дата удаления 11 сентября 2026 года с той же региональной оговоркой.
• 29 августа: мейнтейнеры открыли issue #21656 с просьбой о помощи сообщества и решением убрать ссылки «под протестом».
• 1 сентября: обсуждение на Hacker News; изменений в позиции Google в issue нет.

Почему Индия и Россия отдельно

В уведомлениях Google оба раза называл дату удаления приложения из Play «везде, кроме Индии и России». Причина исключения в переписке не объясняется; в issue нет и подтверждения, что удаление где-либо уже произошло. Для пользователей из России это означает лишь то, что из Play приложение не пропадёт. Для разработчиков, которые распространяют приложение и через RuStore или прямой установкой, напрашивается редакционный вариант: держать ссылки на пожертвования только вне Play-сборки; AnkiDroid подтвердил лишь удаление ссылок из сборки для Play.

Что проверить в своём приложении

• Найдите в приложении все ссылки на внешние платежи: Boosty, Patreon, Open Collective, «Купить кофе», номера кошельков, QR-коды. Ссылка на площадку пожертвований без подтверждённого статуса благотворительной организации — ровно случай AnkiDroid.
• Разделите сборки: в версию для Google Play ссылки не включайте, в сборку для F-Droid, RuStore или прямой загрузки APK оставьте.
• Не рассчитывайте на «объяснить в апелляции»: AnkiDroid отправлял документы, Google 7 августа ответил, что нарушение не устранено.
• Если приложение платное или с подпиской, донаты как отдельный товар возможны только через Google Play Billing с его комиссией, и только если вы не благотворительная организация.
• Держите под рукой историю уведомлений: первое письмо AnkiDroid получил 20 июля, а дедлайн подошёл через шесть недель.

Что дальше

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

Источники: Issue #21656 в репозитории AnkiDroid, Обсуждение на Hacker News

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

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

• tailcat — CLI и Go-пакет github.com/tailscale/tailcat под лицензией BSD-3-Clause.
• Использует WireGuard, NAT traversal и DERP-релеи Tailscale, но не control plane: аккаунты, вход и tailnet не нужны; IP-адреса внутри туннеля есть, но пользователю их знать не требуется.
• Адрес машины — её публичный ключ с информацией о DERP-сервере для первого контакта, закодированный в строку с префиксом tc.
• Сценарии: SSH на машину за NAT, передача файлов, временный доступ; есть экспериментальная браузерная демонстрация на WebAssembly.
• Прототип под названием derpcat написан в сентябре 2023 года; обещаний стабильности API и CLI у проекта нет.

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

В обычном Tailscale центральный сервер (control plane) раздаёт машинам ключи друг друга и координаты, по которым их искать. В tailcat этого посредника нет: всё, что нужно для соединения, упаковано в сам адрес. По описанию в блоге, это публичный ключ WireGuard плюс сведения о том, через какой DERP-релей к машине можно достучаться, если прямой путь через NAT не найдётся; строка начинается с tc и кодирует эти данные в base64. Получатель адреса знает и кому доверять, и где искать.

No accounts, login flow, tailnets, or IP addresses.

Дальше работает тот же механизм, что и в Tailscale: машины пытаются пробить NAT и соединиться напрямую, а если не выходит, трафик идёт через DERP-релей, зашифрованный концами так, что релей содержимого не видит. Релеи Tailscale публичные, и их можно заменить своим. Ни root, ни TUN-интерфейс, ни права администратора не нужны: tailcat работает в пространстве пользователя как обычная программа.

Чем это отличается от ngrok, SSH-туннелей и самого Tailscale

От ngrok и подобных сервисов tailcat отличается тем, что не выставляет ничего в публичный интернет: соединение получит только тот, у кого есть адрес, а адрес — это ключ. От SSH-прыжков через промежуточный сервер — тем, что промежуточный сервер не нужен вообще: DERP лишь помогает найти друг друга и при необходимости ретранслирует уже зашифрованные байты. От Tailscale — отсутствием всей управляющей части: нет списка устройств, ACL, MagicDNS, нет и постоянной сети, каждое соединение живёт само по себе.

Отсюда и границы применимости. tailcat хорош для разового доступа: подключиться к ноутбуку коллеги, забрать большой файл с домашней машины из офиса, дать подрядчику временный вход на стенд. Для постоянной сети между десятками серверов с правами доступа он не замена Tailscale или WireGuard-конфигу, и авторы этого не обещают: README прямо предупреждает, что инструмент бесплатный, но стабильность API и CLI не гарантируется.

Как попробовать

• Установка при наличии Go: go install github.com/tailscale/tailcat/cmd/tailcat@latest; готовые бинарники смотрите в релизах репозитория.
• На принимающей стороне запустите tailcat в режиме прослушивания и скопируйте выданный адрес; на второй машине передайте этот адрес как аргумент.
• Поверх канала поднимайте SSH или пробрасывайте порт; для передачи файлов подойдёт обычное перенаправление stdin и stdout, как с netcat.
• Для закрытого контура поднимите собственный DERP-сервер: код релея открыт в репозитории Tailscale.
• Браузерная демонстрация на WebAssembly лежит на GitHub Pages проекта и показывает, что канал можно открыть даже из вкладки.
• Публичные DERP-релеи даны без SLA, с ограничением частоты запросов и лишь в нескольких регионах; для рабочих сценариев поднимите свой релей.

Контекст

Первый прототип под именем derpcat Фицпатрик написал в сентябре 2023 года, публично проект показали после конференции TailscaleUp в августе 2026-го. Мотив компании понятен: чем больше людей знакомы с её сетевым стеком, тем проще им потом прийти за полноценным продуктом. Для разработчика это честная сделка: рабочий инструмент под BSD-лицензией без обязательств, но и без гарантий, что завтра его интерфейс не изменится.

Источники: tailcat: Tailscale without Tailscale (блог Tailscale), Репозиторий tailscale/tailcat

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

Между rc1 и rc2 вошло около 144 исправлений от 76 участников: ошибки, сборка, документация. До финала принимаются только проверенные исправления багов, новых функций не будет. Релиз-менеджер Хьюго ван Кеменаде называет rc2 финальным кандидатом и просит мейнтейнеров тестировать пакеты именно сейчас; ставить rc2 в прод команда не рекомендует.

• 3.15.0rc2 — последний запланированный кандидат; ABI заморожен, финальный релиз назначен на 1 октября 2026 года.
• JIT: в среднем на 8–9% быстрее обычного интерпретатора на x86-64 Linux и на 12–13% быстрее tail-calling interpreter на macOS с Apple Silicon; разброс по тестам от замедления на 15% до ускорения больше чем вдвое; цифры предварительные.
• Официальные сборки для Windows x64 используют tail-calling interpreter, сборки для macOS по умолчанию поддерживают free-threading.
• Новое в языке: ленивые импорты через ключевое слово lazy (PEP 810), встроенные типы frozendict (PEP 814) и sentinel (PEP 661).
• Мейнтейнерам: собирайте wheels под 3.15 и гоняйте тесты на rc2; после 1 октября исправление попадёт только в 3.15.1.

Что означает «ABI заморожен»

ABI — набор правил, по которым скомпилированный код (numpy, pydantic-core, любой пакет с C или Rust внутри) обращается к интерпретатору: размеры структур, порядок полей, сигнатуры функций. Пока ABI меняется, wheel, собранный под бету, может упасть на финальной версии. Теперь команда CPython обещает: «There will be no ABI changes from this point forward in the 3.15 series» (перевод редакции: «С этого момента в серии 3.15 изменений ABI не будет»). Значит, wheel, собранный сегодня под rc2, останется валидным для 3.15.0 и всех 3.15.x.

На практике это точка, после которой авторы популярных библиотек выкладывают на PyPI сборки для новой версии. Если ваш проект зависит от пакета, который до сих пор не собран под 3.15, самое время открыть issue или прислать PR: у мейнтейнеров есть месяц.

Сколько на самом деле даёт JIT

Документация «What's New» приводит две цифры, и их важно не смешивать. На x86-64 Linux JIT даёт 8–9% ускорения в среднем геометрическом относительно обычного интерпретатора. На macOS с процессорами Apple JIT сравнивают с более быстрым tail-calling interpreter, и там выигрыш 12–13%. Разброс по отдельным тестам огромный: от замедления примерно на 15% до ускорения больше чем вдвое. Документация подчёркивает, что цифры предварительные и до финала могут измениться. Так что «Python стал на 10% быстрее» — неверное обобщение: на вашем коде может быть и минус.

Tail-calling interpreter — другой способ реализовать цикл исполнения байткода, где каждая инструкция вызывает следующую хвостовым вызовом вместо большого switch. В 3.15 именно он идёт в официальных 64-битных сборках для Windows. Официальные сборки для macOS по умолчанию получают поддержку free-threading, то есть режим без GIL остаётся экспериментальным, но доступным без пересборки.

Три новинки языка, которые вы заметите

Ленивые импорты (PEP 810): ключевое слово lazy перед import откладывает загрузку модуля до первого обращения. Это ответ на старую проблему медленного старта CLI-утилит, которые тянут тяжёлые зависимости «на всякий случай».

frozendict (PEP 814) — неизменяемый словарь, встроенный в язык: если все его ключи и значения хешируемы, его можно использовать как ключ другого словаря, и его безопасно отдавать наружу как константу. sentinel (PEP 661) закрывает старый обходной приём с _MISSING = object() для «значение не передано»: у таких маркеров появляется нормальный repr и корректное поведение при pickle.

Что сделать до 1 октября

• Поставьте rc2 рядом с рабочей версией: официальные установщики и исходники на python.org; в uv или pyenv сначала проверьте, что версия появилась в их списках (uv python list), и прогоните тесты проекта.
• Если у вас пакет с расширениями: соберите wheels под 3.15 и выложите на PyPI; ABI больше не изменится.
• Замерьте свой код с JIT и без: флаги сборки и переменные окружения описаны в документации; средним цифрам не верьте.
• Проверьте зависимости на совместимость с ленивыми импортами: код, который полагается на побочные эффекты при импорте, с lazy сломается.
• Нашли регрессию — сообщайте в трекер CPython сейчас: после релиза исправление уйдёт только в 3.15.1.
• Если пользуетесь корпоративным зеркалом PyPI, убедитесь, что оно синхронизирует wheels с тегом cp315: первые сборки под 3.15 появятся в ближайшие недели.

Контекст

Разработка 3.15 началась 7 мая 2025 года, первая бета вышла 7 мая 2026-го, rc1 — 4 августа. После финального релиза ветка получит около двух лет исправлений ошибок и затем ещё примерно три года обновлений безопасности, по обычному графику CPython.

Источники: Python 3.15.0rc2 (python.org), What's New in Python 3.15

Изображение на обложке: Python Software Foundation

Линкер склеивает скомпилированные объектные файлы в исполняемый файл, и на больших проектах это минуты ожидания при каждой пересборке. mold появился в 2021 году именно как ответ на это: по свежему бенчмарку автора он в 4,9 раза быстрее lld по медиане. Но проекты, которые собираются через сложные линкер-скрипты GNU ld, вроде ядра Linux, до сих пор были для него закрыты; 3.0 должна это изменить.

• mold переписывают на Rust; новая версия выйдет как mold 3.0, дата не названа.
• Цель: поддержка линкер-скриптов, чтобы mold собирал всё, что умеет GNU ld, включая ядра и прошивки.
• Текущий mold написан на C++20; по бенчмарку августа 2026 года он быстрее lld в 4,9 раза, а wild в 1,9 раза по медиане.
• Debug-сборка Chromium 145 на Threadripper 7980X: lld 16,64 с, wild 3,98 с, mold 1,65 с; TensorFlow 2.21: lld 50,73 с, mold 3,15 с.
• Текущий mold продолжает работать как замена ld и lld; включается флагом -fuse-ld=mold или через .cargo/config.toml.

Зачем линкеру скрипты

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

Уэяма пишет, что цель новой версии — совместимость со всем, что умеет собирать GNU ld. Именно это открывает дорогу к тому, чтобы дистрибутивы Linux сделали mold линкером по умолчанию: пока хоть один важный пакет не собирается, менять умолчание никто не будет. Конкретных дистрибутивов с такими планами в README пока не названо.

We are rewriting the mold linker in Rust. This will be mold 3.0.

Насколько mold быстрее сегодня

Автор обновил бенчмарки в README репозитория в августе: девять крупных программ, медиана трёх запусков после прогрева, два стенда — Threadripper 7980X с 64 ядрами и Apple M1 Ultra, у которого использовались 16 производительных ядер. Сравнивались lld, wild (ещё один линкер на Rust) и mold. Результаты на Threadripper выглядят так.

На Chromium 145 lld тратит 16,64 секунды, wild 3,98, mold 1,65. На TensorFlow 2.21 разрыв ещё больше: 50,73 секунды у lld против 3,15 у mold. На Apple M1 Ultra картина ровнее: debug-сборка Clang 21 линкуется за 2,96 секунды у mold, 4,40 у lld и 2,78 у wild, то есть в этом тесте конкурент на Rust слегка впереди, хотя на большинстве остальных задач M1-стенда mold быстрее. Артефакты бенчмарка опубликованы на Zenodo, их можно повторить.

Почему Rust, если и так быстро

В сообщении Уэямы причин не названо. Из README видно другое: текущий mold требует GCC 10.2 или Clang 16 и написан на C++20, а конкурент wild с самого начала на Rust и на части задач уже догоняет. Переписывание с добавлением линкер-скриптов означает во многом новую кодовую базу, и выбор языка для неё делается один раз. Всё остальное — предположения, и мы их не делаем.

Как включить mold сегодня

Для C и C++ с GCC или Clang достаточно флага компоновки -fuse-ld=mold. Для Rust README предлагает настройку в .cargo/config.toml:

• Проекты с собственными линкер-скриптами (ядра, прошивки, загрузчики) пока остаются на GNU ld; ждите mold 3.0.
• Если пользуетесь wild, сравните на своём проекте: на M1 Ultra он выигрывает лишь в части тестов, по общей медиане бенчмарка mold быстрее в 1,9 раза.
• mold распространяется под лицензией MIT через GitHub и пакеты дистрибутивов; наличие пакета в репозиториях Astra Linux и РЕД ОС проверяйте отдельно, в README они не перечислены.

Что дальше

mold используется в проде с 2021 года, и текущая C++-версия никуда не денется до выхода 3.0. Следить стоит за двумя сигналами: появится ли в репозитории ветка на Rust с первыми тестами линкер-скриптов и объявит ли какой-нибудь дистрибутив о планах сделать mold линкером по умолчанию. Второе и будет настоящей новостью.

Источники: Сообщение Руи Уэямы в X, Репозиторий mold с бенчмарками

Изображение на обложке: Tproger по данным README mold

В AutoGPT, где на момент интервью у репозитория было свыше 180 тысяч звёзд и 150 открытых PR, большая часть этих PR создана агентами: Copilot, OpenClaw, собственными инструментами команды и сторонними ботами. Большинство мейнтенеров реагируют просто: закрыть дверь, отключить пулреквесты, не тратить силы на чужой LLM-вывод. Но у Николаса Тиндла, одного из основателей ИИ-инженерии в AutoGPT, другой взгляд: «По сути, кто-то другой платит за ваши вычислительные ресурсы. Если контрибьютор хочет потратить свои токены на улучшение вашего проекта — пусть тратит. Главное, сделать так, чтобы единственный путь внутрь проходил через ваши правила.»

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

Агенты не ищут документацию сами — они читают то, что лежит рядом с кодом. AGENTS.md и CLAUDE.md в нужных директориях работают лучше, чем вики.

Пропускные ворота должны быть автоматическими и однозначными: шаблон PR, тест-план, CI как стена, CLA как детектор человека.

Не все ворота стоит оставлять включёнными: автоматические комментарии об ошибках CI быстро превращаются в шум.

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

Мейнтенер всё ещё решает, что принимать: закрыть PR и переписать самому — тоже валидный выбор.

Проблема не в документации, а в её обнаружении

Первое, что пробовала сделать AutoGPT, — улучшить CONTRIBUTING.md, написать подробную вики и обновить гайды. Это не сработало. Дело в том, что агенты не ходят по ссылкам и не ищут документацию в разделах репозитория. Они смотрят на то, что находится в текущей директории и на один-два уровня выше. Если инструкция не лежит там, где агент работает, для него её не существует.

Сначала команда добавила файлы CLAUDE.md, потому что Claude открывал пулреквесты без достаточного контекста о репозитории. Потом выяснилось, что Copilot и Codex эти файлы игнорируют — они не Claude. Решением стал централизованный AGENTS.md, на который указывают все специфичные для модели файлы.

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

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

Фронтенд-инженер AutoGPT устал от одного и того же класса сломанных PR в open source-проекте и оформил гайд как навык. Теперь каждый агент, который касается репозитория, видит триггер и выполняет правило. Бэкенд делает то же самое: не набрал 80% покрытия — PR не пройдёт.

Ворота для ИИ-контрибьюторов в open source

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

Шаблон пулреквеста как пропускной пункт

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

Тест-план, который запускает код

В шаблоне есть раздел тест-плана, и его формулировка незаметно подсказывает агенту протестировать пулреквест. Эта фраза активирует навык test PR: агент устанавливает браузер, разворачивает приложение и проверяет изменение. Агент пришёл поставить галочку, а в итоге запустил код. После этого сломанные PR стали редкостью. Осталась другая проблема — PR, которые работают, но не вписываются в дорожную карту.

CI — стена, а не рекомендация

Codecov и другие проверки настроены как required checks. Агент открывает PR, через несколько минут видит, что мёрж заблокирован, загружает навык с тестами и добивается покрытия. Никто не просил — инфраструктура сама направила агента.

CLA (Contributor License Agreement) как детектор человека

AutoGPT использует двойную лицензию, но Тиндл советует лицензионное соглашение участника (Contributor License Agreement, CLA) любому проекту, даже MIT. Подписание требует браузера и OAuth-потока GitHub на отдельном домене. Сегодня агенты с этим справляются плохо — и это хорошо, потому что большинство мейнтенеров не хотят, чтобы агент ходил в GitHub от их имени. Если CLA не подписан в течение недели, PR закрывается с комментарием «подпишите CLA и переоткройте».

SHA коммита перед закрытием замечания

Часть агентов закрывает все треды ревью, не исправляя код. В AutoGPT есть навык pr-address, который описывает допустимую последовательность: исправить, закоммитить, запушить, ответить, потом разрешить тред. Ответ должен содержать полный SHA коммита, полученный через git rev-parse HEAD, чтобы агент не подсунул старый хеш. Навык явно называет антипаттерны: «Acknowledged» — не исправление, и ссылка на коммит, который не трогает указанную строку, тоже не считается.

Ворота, от которых пришлось отказаться

Когда CI падает, AutoGPT изначально запускала агента, который читал лог и писал комментарий, что сломалось. Первая версия использовала Claude Code внутри GitHub Actions с аутентификацией в CI — лишняя широкая учётная запись. Потом перешли на Copilot внутри рабочего процесса: тот же результат, но без лишних кредов.

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

Четыре ловушки, которые стоит записать

• Плохой AGENTS.md хуже, чем его отсутствие. В AutoGPT сначала разбросали файлы повсюду и засорили контекст. Если поведение агентов ухудшилось — перечитайте, что вы написали.
• GraphQL API GitHub быстро исчерпывает лимит запросов. Если каждый инструмент в команде ходит в CLI как отдельный пользователь, лимит закончится. Создайте GitHub App и аутентифицируйте CLI через неё.
• Сложное ревью стоит реальных денег. У AutoGPT PR проходит через клон ветки, восемь агентов с разными ролями, запуск стека и скриншоты. Круто, но дорого. Сейчас эту процедуру запускают только для совсем маленьких или крупных PR.
• Проверяйте авторизованные приложения. Каждый протестированный инструмент оставляет OAuth-разрешение. Если перестали использовать приложение — удалите его из настроек GitHub.

Не всё в open source решается воротами

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

GitHub даёт мейнтенерам ручки: можно отключить пулреквесты целиком, ограничить создание issue только участникам с правами collaborator или требовать предварительного обсуждения. Если хотите — вообще закройте приём внешнего кода, как это сделали в SQLite: они принимают только баг-репорты. У вашего проекта тоже может быть своя граница.

Второй тезис: когда вы закрываете PR, но переписываете его идею сами, добавьте автора как соавтора, если это уместно. В AutoGPT 800 контрибьюторов, и один дополнительный соавтор ничего не стоит. Для большинства людей важно, что их проблему заметили и исправили.

Выводы

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

Тиндл советует мейнтенерам записываться в программу обратной связи GitHub — maintainers.github.com:

You've got to go there. You've got to sign up. It gets you all the connections you want at GitHub. That's where I learned about all this stuff, and where I share it.

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

Если тема интересна, загляните в разделы tproger: open source, GitHub и искусственный интеллект.

Источник: GitHub Blog — Your contributors are AI-first now. Is your project?

Qwen 3.8-Max — флагман Alibaba с 2,4 трлн параметров (95 млрд активных).

Это первая модель линейки Max, чьи веса выложат в open source.

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

Доступна через API QwenCloud с параметром reasoning_effort и интегрируется с Claude Code, Codex и Qoder.

Что анонсировали

Qwen 3.8-Max построена на архитектуре Qwen 3.5 и насчитывает 2,4 трлн параметров, из которых активируются примерно 95 млрд. Это делает её одной из крупнейших публично анонсированных моделей и первой мультимодальной системой Qwen, преодолевшей отметку в 1 трлн параметров.

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

Ключевые возможности

• Автономный кодинг. В демонстрации модель 16 дней без участия человека развивала проект oh-my-cli: 265 коммитов, 127 pull request'ов и 151 issue. Главная фишка — самообучающийся цикл: требования превращаются в задачи, которые агенты берут в работу, тестируют и сливают в main.
• Научные исследования. Qwen 3.8-Max воспроизвела эксперимент из статьи «Unified Data Selection for LLM Reasoning» с нуля — около 7 600 строк кода, 33 цикла обучения на GPU — а затем улучшила результат на 2,7 балла на бенчмарке AIME24.
• Соревнования. За 24 часа модель построила решение для конкурса WWW2025 Multimodal Dialogue Intent Recognition на платформе Tianchi и обошла 458 из 526 человеческих команд (87%).
• Рабочие сценарии. В тестах Qwen 3.8-Max проектировала интерфейсы, составляла меню ресторана с расчётом себестоимости, проверяла юридические документы и строила сейсмические модели зданий.
• Чип-дизайн. Модель самостоятельно прошла весь фронтенд-флоу цифровой схемы: от RTL до физического layout в OpenROAD, сократив площадь кристалла на 81% и добившись тактовой частоты 500 МГц.

Бенчмарки

В опубликованной таблице Qwen 3.8-Max сравнивается с Claude Opus 4.8, Claude Fable 5, GPT 5.6 Sol и предшественником Qwen 3.7-Max. По внутренним тестам Alibaba новинка обгоняет Qwen 3.7-Max на большинстве задач и приближается к лучшим закрытым моделям в кодинге и мультимодальных бенчмарках. Отдельно отметим PaperBench — 93,0 балла против 90,5 у GPT 5.6 Sol и 64,8 у Qwen 3.7-Max.

Как попробовать

Модель уже доступна через QwenCloud. API совместим с OpenAI и Anthropic, поэтому подключение занимает буквально минуту. Поддерживаются три уровня глубины рассуждений: xhigh, medium и low. По умолчанию включён preserve_thinking.

Минимальный пример на Python:

Кроме прямого API, модель завели в Claude Code, Codex, Qoder CLI, Qwen Code и OpenClaw. Контекстное окно — до 1 млн токенов, максимальная длина ответа — 65 536 токенов.

FAQ

Выводы

Qwen 3.8-Max — это попытка Alibaba вывести флагманскую линейку в open source и при этом конкурировать с лучшими закрытыми моделями. Если открытые веса действительно выйдут под пермиссивной лицензией, у разработчиков появится серьёзная альтернатива для локального запуска и дообучения. Пока же модель можно протестировать через QwenCloud.

Источник: Qwen 3.8-Max: A New Bar for Coding and Cowork.

PixelSmash — это критическая уязвимость в декодере MagicYUV медиафреймворка FFmpeg. Она получила идентификатор CVE-2026-8461 и оценку CVSS 8.8. Ошибка представляет собой запись за пределы выделенной памяти (heap out-of-bounds write) и затрагивает все приложения, которые используют FFmpeg для декодирования видео.

Уязвимость CVE-2026-8461 в FFmpeg оценена в CVSS 8.8.

Баг находился в коде 16 лет и затрагивает декодер MagicYUV.

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

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

Проверить систему можно командой ffmpeg -decoders | grep magicyuv.

Где опасность

Уязвимость опасна именно масштабом. MagicYUV включён по умолчанию во всех протестированных дистрибутивах — Ubuntu, Debian, Fedora, Arch, Alpine — до FFmpeg 9.0. Проблема проявляется не только в видеоплеерах, но и в файловых менеджерах, генерирующих миниатюры, медиасерверах, мессенджерах и облачных транскодерах.

Для эксплуатации не нужны ни права, ни аутентификация, ни предварительный доступ к системе. Достаточно, чтобы приложение попыталось декодировать вредоносный AVI, MKV или MOV размером около 50 КБ. Исследователи JFrog показали полную цепочку атаки: удалённое выполнение кода на Jellyfin через автоматическое сканирование библиотеки и на Nextcloud через провайдер превью видео.

• Десктоп: Kodi, mpv и другие плееры; миниатюры в файловых менеджерах.
• Серверы: Jellyfin, Emby, Nextcloud, Immich.
• Мессенджеры: Slack, Discord, Telegram.
• Облако: AWS MediaConvert, Cloudflare Stream и другие транскодинговые конвейеры.
• IoT и NAS: Synology, QNAP, smart TV и любые устройства, генерирующие превью.

Как проверить

Проверить наличие уязвимого декодера можно одной командой. Если в выводе есть строка VFS..D magicyuv, ваш FFmpeg подвержен уязвимости.

В случае положительного результата обновитесь до версии с патчем или пересоберите FFmpeg без декодера.

Как защититься

• Обновите FFmpeg до версии, содержащей исправление.
• Если обновление невозможно, пересоберите FFmpeg с флагом --disable-decoder=magicyuv.
• На серверах отключите автоматическую обработку загружаемых видео, где это не критично для бизнеса.
• Проверьте все устройства с FFmpeg: NAS, медиасерверы, IoT и контейнеры.

JFrog опубликовала минимальный патч для libavcodec/magicyuv.c. Он отклоняет искажённые значения slice_height, которые вызывают запись за пределы буфера. Корректный кодировщик MagicYUV всегда выдаёт выровненные значения, поэтому патч не ломает легитимные файлы.

FAQ

Выводы

PixelSmash — очередное напоминание о том, что foundation-библиотеки вроде FFmpeg работают под капотом огромного числа приложений. Один баг в кодеке, пролежавший 16 лет, одновременно угрожает десктопным плеерам, облачным транскодерам и бытовым NAS. Лучшая защита — своевременное обновление и аудит зависимостей.

Источник: JFrog Security Research / InfoQ.

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

Исследователь Cereblab перехватил трафик Grok Build 0.2.93 и обнаружил загрузку 5,1 ГБ в корзину Google Cloud — в 27 800 раз больше, чем требовала задача.

В выгрузку попадали файлы, которые агент никогда не открывал, а также неотредактированные credentials из .env и SSH-ключи.

xAI отключила сервер загрузки 13 июля, а 15 июля опубликовала код под Apache 2.0.

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

По данным издания DevOps.com, исследователь под псевдонимом Cereblab использовал mitmproxy, чтобы перехватить сетевой трафик версии 0.2.93. Тестовый репозиторий объёмом 12 ГБ привёл к передаче около 192 КБ полезного трафика, но параллельно в корзину grok-code-session-traces ушло 5,1 ГБ в 73 частях. Внутри оказались файлы, не связанные с текущей задачей, включая SSH-ключи, базу паролей, личные документы и фотографии.

Переключатель «Improve the model» не влиял на поведение: загрузка шла независимо от настроек приватности. Это противоречит маркетинговым заявлениям xAI о том, что во время сессии код не покидает компьютер пользователя. 13 июля серверную сторону отключили без security advisory, а Илон Маск пообещал «полностью и безвозвратно» удалить все ранее собранные данные.

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

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

• Если до 13 июля запускали Grok Build на репозиториях с живыми credentials — смените пароли, SSH-ключи и токены.
• Проверяйте сетевую активность любых агентов с доступом к файловой системе через инструменты вроде mitmproxy.
• Запускайте ИИ-агентов в изолированном окружении с ограниченными правами.
• Требуйте от вендора письменной политики обработки данных до развёртывания инструмента.

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

Источник: DevOps.com.

Все началось с рабочей задачи по реализации весьма специфичной web-панели мониторинга и управления различным оборудованием, в которой нужно было получать данные и отправлять команды по разнообразным сценариям (периодический опрос, подписка на websocket-события, https-запросы и т.д.), а также выводить состояние и графики в реальном времени, динамически комбинируя различные источники данных в разных виджетах.

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

В первой итерации с использованием RxJS получилось много неструктурированного и сложно поддерживаемого кода, так как архитектура на RxJS вынуждала императивно описывать перестроение топологии при изменении правил маршрутизации «на лету». В нашем специфичном кейсе с динамическими виджетами это приводило к сайд-эффектам и сложностям в отладке. Кроме того, местами размывалась строгая типизация и мы лишались compile-time гарантий. Так появилась идея разработать собственное решение на основе альтернативной концепции — модели графа потоков данных.

В результате получившаяся модель продемонстрировала предсказуемое поведение и низкую связность компонентов, а кодовая база сократилась на ~30% и приобрела более декларативный вид. Убедившись в эффективности решения, мы решили оформить его в виде отдельной библиотеки с открытым исходным кодом — Transferum.

И что, получилась просто еще одна реактивная библиотека?

Не совсем. Классические FRP-библиотеки (RxJS, Bacon, Most) построены вокруг единственного примитива (Observable). Transferum же основан на композиции различных типов узлов с явно определенным поведением.

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

Объявленные узлом возможности являются одновременно флагами для использования в runtime и compile-time гарантиями наличия соответствующих методов, определяющих его поведение.

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

Transferum предоставляет четыре слоя абстракции:

1. Трансферы — узлы графа (каналы, поллеры, мапперы, буферы, разветвители и концентраторы, реализации debounce, throttle, switchMap и т.д.).
2. Мосты — ребра графа — управляемые вентили между узлами с динамической маршрутизацией и гейтингом.
3. Операторы — stateless-трансформаторы и фильтры данных (используются трансферами, отвечающими за конвертацию данных).
4. Билдеры — fluent-конструкторы композитных трансферов из цепочек трансферов-примитивов.

Концептуальная и архитектурная основа — capability flags system. Каждый трансфер реализует CommunicationContractInterface — набор булевых флагов, определяющих его возможности.

Флаги isPushable, isPullable, isSubscribable, isGate и другие — это не просто свойства объекта. Это метаданные, которые:

• Определяют TypeScript-интерфейс трансфера на этапе компиляции.
• Управляют стратегией связывания с другими трансферами в рантайме (с помощью функции linkTransfers()).
• Обеспечивают совместимость в билдерах без приведений типов.

Один набор флагов — три потребителя. Это единый источник истины для всей системы.

Когда флаг равен true, соответствующий метод входит в TypeScript-интерфейс трансфера. Это позволяет предоставлять трансфер пользователю вот так:

Или вот так:

Именно в таком формате типов фабрики в библиотеке возвращают трансферы. Например:

Эта «магия» работает в compile-time благодаря несколько замысловатой системе вычислимых типов:

Архитектурные инварианты

1. Трансферы не знают своих соседей

Трансфер определяет своё поведение (push, pull, subscribe и др.), но никогда не ссылается и не проверяет класс другого трансфера. Он не знает, что является upstream или downstream — лишь выполняет свой контракт. Пользователь может создать свой трансфер, объявить и реализовать его возможности — и он органично и бесшовно впишется в экосистему.

2. Мосты не знают конкретных реализаций

Мост инспектирует capability flags, а не имена классов. Нет цепочки instanceof, нет переключения по имени класса. Любой output-трансфер может быть соединен с любым input-трансфером — при условии совместимости их флагов, о чем мы поговорим чуть ниже. Это применимо и к тем узлам, которые еще не существуют и будут созданы пользователем.

3. Значение undefined никогда не распространяется

В Transferum undefined означает «нет данных», а не «пустое значение». Оно подавляется на уровне внутренней реализации менеджера подписок — подписчики никогда не уведомляются с undefined. При этом для явных маркеров пустых значений можно использовать null. Мы сознательно пошли на этот компромисс, чтобы избежать runtime-оверхеда и сохранить нативную скорость работы на плотных потоках данных.

Связывание трансферов

Функция linkTransfers(lhs, rhs) соединяет output-трансфер (lhs) с input-трансфером (rhs) с автоматическим выбором стратегии связывания на основе возможностей этих трансферов:

• isSubscribable → isPushable (реактивная подписка);
• isPullable → isPollingProxy (активный опрос);
• isSubscribable → isAsyncPushable (реактивная подписка + асинхронный push);
• isAsyncPullable → isAsyncPollingProxy (активный асинхронный опрос асинхронного pull-источника);
• isPullable → isAsyncPollingProxy (активный асинхронный опрос синхронного pull-источника).

Protocol-oriented design: механизм не спрашивает «какой это класс?» — он выясняет, какие у него есть возможности. Любая пара трансферов с совместимыми возможностями является linkable. Добавление нового класса трансфера требует только объявления его флагов и реализации соответствующих методов — как связать его с другим трансфером, связующий алгоритм разберется сам.

Sync и async в одной экосистеме

Синхронные и асинхронные трансферы сосуществуют и могут быть связаны между собой. linkTransfers() предпочитает sync-связывание, когда это возможно, а async-стратегии применяет только когда sync неприменим. Нет отдельного «асинхронного мира».

Поддержка backpressure

Ряд асинхронных трансферов (AsyncSinkTransfer, AsyncWriteTransfer, AsyncConvertTransfer, AsyncConditionTransfer) поддерживают необязательные поля в конфигурации: maxConcurrency, bufferSize и onBufferOverflow — для ограничения параллельных async-операций, очереди избыточных данных и graceful-обработки переполнения. По умолчанию — неограниченная обработка, без буферизации.

Локальная обработка ошибок

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

А теперь — к примерам использования

Вот так можно просто и декларативно описать опрос и агрегирование данных из нескольких источников:

А вот как можно организовать динамический роутинг:

Пример организации игровой механики:

Когда имеет смысл попробовать Transferum

Библиотека подойдет для:

• TypeScript-first проектов — благодаря максимально строгой типизации и compile-time вычислению доступных методов любого трансфера на основе объявленных у него флагов возможностей.
• Работы с pull-based источниками данных — polling API, датчиков, хранилищ с PollingProxy.
• Смешанных sync/async пайплайнов — в единой модели без ручного преобразования.
• Явного flow control — gates, bridges, selectors для runtime-маршрутизации.
• Game development / IoT — frame-aligned tickers, idle polling, sensor aggregation.
• Устойчивой обработки ошибок — локальная, non-fatal обработка: одна стадия не убивает пайплайн при условии переданного в конфиге обработчика ошибок, ничего не подавляется молча.

Результаты и планы

• Библиотека уже используется в двух наших внутренних проектах и показывает свою эффективность. Код доступен на GitHub под лицензией MIT, библиотека не имеет внешних зависимостей и поставляется с подробной документацией (README + API Reference).
• В одном из проектов граф состоит из ~80 узлов и стабильно обрабатывает несколько сотен событий в секунду без деградации. На основе этих данных в том числе рендерится 3D-сцена в Babylon.js со стабильным фреймрейтом ~60 FPS без микрофризов.
• Тесты библиотеки покрывают не только отдельные трансферы, но и поведение системы в динамике: переподключение мостов, обработку ошибок в длинных асинхронных цепочках, а также разнообразные граничные случаи. Покрытие — 100%.
• В дальнейшем планируем реализовать хуки и утилиты для более удобного и нативного использования Transferum с Vue и React. Если они окажутся в достаточной мере переиспользуемыми, оформим в отдельные пакеты-адаптеры.

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

P. S. Если вы сталкивались с похожими задачами и решили их как-то иначе — буду рад прочитать о вашем опыте в комментариях.

Сразу скажу - я не считаю себя втором Терри Дэвисом и тем более не хочу делать аналог Виндовс. Изначально я все это затеял только ради прикола и изучения ассемблера.

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

Так а в чем же проблема x86_64?

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

Не буду говорить, что RISC-V лучшая, но я просто выбрал ее. Прикол в том, что инструкции короткие, да и в целом достаточно перспективно. Хотя и тут были проблемы.

Был драйвер, стала ОС

Я ничего с нуля не писал.Все началось с пыток ИИ, когда я пытался выдавить из него то обращение по конкретному адресу для доступа к графике, то опрос портов, то еще что-то такое. Мне стало лень и я пошел искать что-то плюс-минус готовое. И я нашел его - ramfb. По сути я получил готовый указатель на фреймбуфер для вывода на экран… И все. Но и на этом большое спасибо авторам драйвера. Дальше началась моя ОС.

А где хранить данные?

А тут первая проблема - как таковой кучи у меня еще нету. Есть стек, который за меня выделил автор драйвера. Есть всякие глобальные переменные. Но что если мне нужно много памяти (например, под картинки) и я не знаю точный размер? И в добавок, кто вообще рисует напрямую на экран? Тут нужен некий массив пикселей, который будет лежать в памяти, а по нашей команде быстро перенесется на экран (называется backbuffer).

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

Это когда ты делишь память на куски, каждый помечаешь как занятый или свободный. Нужно мало памяти - откусываем от большого куска блок. Блок освободился, а рядом есть другой свободный блок - соединяем в один большой.Сразу же добавил функцию, чтобы узнать сколько памяти занято. Сейчас, например, занято около 3-4 мб. Ну это учитывая, что backbuffer и занял почти 3.5 мб.

В оперативной памяти что-то типа

Такая разная многопоточность

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

Многопоточность кооперативная

Так мы можем сказать потокам, чтобы если один из них решит, что стоит сделать паузу, сам вызвал yield() и отдал процессор другому потоку. И я это сделал. Все что нужно было - сохранить s-регистры процессора (те, в которых лежат всякие важные значения), указатель на личный стек потока (размер стека задается при создании) и указатель на “дорогу назад” ra. То есть yield() сохраняет эту информацию потока А, затем вместо нее загружает информацию потока Б. И так по кругу.

Кстати, стеки самих потоков я выделял в той самой куче. Просто брал блок на пару кб и говорил потоку: “Это твой стек”.

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

Многопоточность вытесняющая

Поэтому я и решил переписать все на вытеснение. Для начала я сделал так - каждые 100к тиков процессора сохраняются все регистры и пинается функция обработки прерываний. Таймер, по которому будет работать многопоточность - это тоже прерывание. Так же эта функция ловит ошибки по типу kernel panic. Это было сложнее - так как потоки не добровольно отдают процессор, приходится сохранять вообще все 32 регистра. Но криво-косо я написал это и функцию sleep(), во время которой функция простаивает, ее никто не трогает.

А тут еще и ИИ начал выдавать бред, пока я тестировал у меня… начинал выполняться основной код, все было хорошо, а потоки - нет. Я сам не вижу ошибку, ИИ тоже. Он то предложит заменить какую-то часть функции, то еще что-то такое. Наконец я вспомнил про замечательную штуку - gdb. Запустил, посмотрел… Оказалось так - цикл отрисовки экрана был слишком долгим, во время него вызывалось переключение потоков, а их еще не было кроме главного. В итоге я подумал что смысла создавать потоки в конце, после отрисовки, нет, и перенес их в самое начало. Удивительно, но все заработало.

Немного про режимы

Как выяснилось, в RISC-V есть 3 режима (точнее 4, включая гипервизор, но тут он мне точно не нужен) - M-mode с полными привелегиями, S-mode для ядра ОС (я думал что и мое его использует), ну и U-mode для пользователей, но до этого мои ручки еще не дошли.

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

Вызываю я ecall из потока. Смотрю - kernel panic. В логах какой-то код “11”. Оказалось, это и есть ecall - в M-mode он 11, а в S-mode (в котором, как я думал, работало ядро, и который я пытался выловить) это 9. Ну когда я нашел, уже быстро исправил.

Визуальчик

Но в это время на сам экран эмулятора Qemu… Ничего и не выводилось. Совсем. Просто белый экран. Хотелось красоты.

Тогда я вспомнил, что день назад прикрутил qoi.h к моему коду. QOI - формат изображений. Выбрал я его, так как декодер легкий и его удобно использовать в любой ОС, где есть базовые функции.

Я аккуратно, разумеется, согласно лицензии, взял из pop os, которой когда-то пользовался, картинку для фона. Конвертировал ее в .qoi, а так как моя ос еще не умела читать с диска, перевел картинку в заголовочный файл .h. Весит правда много, но влезает.

Дальше я нашел шрифт (Liberation Mono от Red Hat), перегнал и его в .h. Честно, визуал меня не сильно интересовал, поэтому быстро попросил ИИ переделать функции вывода в консоль в функции вывода на экран. Проверил, просмотрел что и как сделано, получилось нормально для старта. Правда пока что в графической консоли нет нормальной перемотки и много чего другого.

Вывод

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

Если я не забью на код, хотел бы написать еще и MMU и переход в U-mode.

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

• Новая спецификация MCP 2026-07-28 делает протокол stateless: сессии и handshake больше не нужны.
• Клиент передаёт свою идентификацию и возможности в поле _meta каждого JSON-RPC-запроса.
• Балансировщик может использовать обычный round-robin, ориентируясь на заголовки Mcp-Method и Mcp-Name.
• Roots, Sampling и Logging объявлены устаревшими с минимальным окном поддержки 12 месяцев.
• Финальная спецификация ожидается 28 июля 2026 года после 10-недельного окна валидации SDK.

Model Context Protocol (MCP) — открытый протокол для подключения ИИ-агентов к внешним инструментам и данным. С момента передачи Anthropic в Linux Foundation в декабре 2025-го им управляет Agentic AI Foundation, а число production-серверов уже исчисляется сотнями тысяч. До сих пор MCP работал по модели чата: сначала handshake, потом сервер выдавал идентификатор сессии, который клиент возвращал с каждым запросом.

В релиз-кандидате эта модель заменена на stateless. Клиент кладёт имя, версию и capabilities в поле _meta прямо в тело запроса. Балансировщик читает HTTP-заголовки Mcp-Method и Mcp-Name (SEP-2243) и направляет запрос на любой свободный инстанс — общее хранилище сессий больше не требуется. Если серверу нужен ввод посреди вызова, он возвращает InputRequiredResult, а клиент переотправляет запрос с inputResponses и requestState.

Вместе с ядром обновляются и расширения. Появляется MCP Apps — серверный интерактивный UI в sandboxed iframe с заранее декларируемыми шаблонами. Переработано API долгих задач: вместо tasks/list приходят tasks/get, tasks/update и tasks/cancel. Также шесть SEPов ужесточают авторизацию по OAuth/OIDC, включая проверку issuer по RFC 9207.

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

Выводы

Новая спецификация — признак того, что MCP вырос из протокола для локальных подключений в полноценную enterprise-инфраструктуру. Переход к statelessness решает главную операционную проблему масштабирования, но добавляет работы тем, кто уже внедрил stateful-реализации. Главное — помнить, что релиз пока кандидат: production-серверы продолжают работать на спецификации 2025-11-25.

Источник: awesomeagents.ai.

На конференции Open Source Summit India 2026 в Мумбаи Кроах-Хартман выступил с докладом «Rust and Linux: How the Rust Language is Going to Help Linux Succeed». В нём он признался, что поначалу относился к языку скептически и считал, что всё необходимое уже есть в C. Сейчас он считает иначе: Rust действительно делает программирование интереснее и безопаснее.

• Грег Кроах-Хартман назвал Rust постоянной частью Linux, а не временным экспериментом.
• По его оценке, около 80% уязвимостей ядра за последние 25 лет можно было бы поймать на этапе компиляции Rust.
• Linux получает около 13 CVE в день и почти 9 изменений в час на протяжении десяти лет и более.
• Binder — ключевой механизм IPC Android — уже имеет параллельную реализацию на Rust, а C-версия скоро уйдёт.
• Git и ряд других крупных проектов также движутся в сторону Rust.

От скептицизма к поддержке

Кроах-Хартман рассказал, что несколько лет назад друг советовал ему попробовать Rust, но он отмахнулся: C казался достаточным. Со временем он изменил мнение. «Он был прав. Я должен был сделать это тогда. Rust на самом деле весёлый. Он заставляет программирование быть весёлым», — сказал мейнтейнер.

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

Масштаб проблемы

Linux развивается с огромной скоростью. Кроах-Хартман привёл цифры: ядро набирает примерно девять изменений в час уже больше десяти лет, а количество публично раскрываемых уязвимостей держится на уровне около 13 CVE в день. Большая часть из них — не сложные атаки, а простые ошибки в C-коде.

Я видел каждую CVE ядра за последние 25 лет. Думаю, 80% исчезли бы просто потому, что Rust поймал бы их.

Что уже меняется в ядре

Rust постепенно становится обязательным выбором для отдельных подсистем. Кроах-Хартман отметил, что новые драйверы некоторых подсистем будут приниматься только на Rust. Яркий пример — Binder, межпроцессный механизм Android, от которого зависят миллиарды устройств. В ядре уже существуют параллельные реализации Binder на C и Rust, и C-версия «скоро исчезнет».

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

Контекст:
Binder — это механизм межпроцессного взаимодействия (IPC) в Android. Он позволяет приложениям и системным сервисам безопасно обмениваться данными. Переписывание Binder на Rust напрямую влияет на безопасность и стабильность почти всех Android-устройств.

Выводы

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

Источник: Slashdot.

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

В своей колонке Daily Drivers редактор Hackaday Дженни Лист скачала ISO-образ, запустила KolibriOS на современном ThinkPad и удивилась: система выглядит зрелой, стабильной и по-настоящему быстрой. Разбираем, что это за проект, откуда он взялся и кому пригодится сегодня.

Что такое KolibriOS

KolibriOS — российский форк MenuetOS, созданный в 2004 году. В то время как автор оригинального MenuetOS Вилле Турьянмаа переключился на закрытую 64-битную версию, сообщество вокруг русскоязычного порта сохранило код открытым и продолжило развивать 32-битную ветку. Название «Колибри» выбрано неслучайно: система маленькая и быстрая, как птица-колибри.

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

Версия 0.7.7

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

Дженни Лист отмечает, что на ThinkPad 2020-х годов KolibriOS загружается «в мгновение ока» и сразу показывает рабочий стол. Интерфейс выглядит пиксельным, как в 1990-х: нет сглаживания, есть ощущение ретро. Но при этом всё работает — без синих экранов и зависаний.

• KolibriOS 0.7.7 — 32-битная ОС с ядром на ассемблере, базовый образ весит около 1 МБ.
• Минимальные требования: i586, 8 МБ ОЗУ, 1 МБ на диске.
• В комплекте браузеры, игры, эмуляторы, графические редакторы и среда разработки.
• Главное ограничение для повседневного использования — отсутствие поддержки HTTPS.
• Лучше всего подходит для старого железа, тонких клиентов, обучения и ретрокомпьютинга.

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

Ядро на ассемблере

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

Важная оговорка: несмотря на миф «всё на ассемблере», часть приложений и драйверов портирована или написана на C, Free Pascal, Oberon и даже Python. Но ядро, графическая подсистема и системные вызовы остаются ассемблерными.

Файловые системы и загрузка

KolibriOS умеет загружаться с CD/DVD, USB, жёстких дисков и даже с классической дискеты 1,44 МБ. Поддерживаются файловые системы FAT12/16/32, exFAT, NTFS и ext2/3/4. Есть варианты для Coreboot и загрузка прямо из Windows.

Что внутри: программы и игры

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

Из игр и развлечений — порты эмуляторов, DOSBox, а также shareware-версии классики вроде DOOM и Wolfenstein 3D на полноценном CD-образе. Есть поддержка SDL, что позволяет переносить проекты с «больших» систем.

Something this polished deserves a while to play around.

Главное ограничение: интернет без HTTPS

Дженни Лист называет именно этот момент решающим: встроенные браузеры KolibriOS, включая Netsurf и Webview, не поддерживают HTTPS. Без этого современный веб практически закрыт: большинство сайтов, включая сам Hackaday, просто не откроются.

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

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

Кому и где пригодится KolibriOS

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

• Воскрешение старого железа. Pentium- и ранние Core-машины получают рабочий стол, браузер для локальных страниц и офисные утилиты.
• Тонкие клиенты. Низкие требования к RAM и CPU делают KolibriOS кандидатом для терминалов с удалённым рабочим столом.
• Обучение. Ядро на ассемблере, простые системные вызовы и небольшой кодовой базы — отличная площадка для изучения устройства ОС.
• Ретрокомпьютинг. Запуск DOS-игр через эмулятор, классические 2D-игры и ностальгический интерфейс 1990-х.
• Встроенные системы. Сборка Kolibri-A ориентирована на специализированное железо и железные проекты.

Как попробовать KolibriOS

Попробовать систему проще всего в виртуальной машине. Скачайте ISO-образ с официального сайта, создайте VM с 64 МБ ОЗУ и загрузитесь с образа. Для реального железа подойдёт запись образа на USB-флешку или CD.

• Скачайте ISO или образ дискеты с официального сайта KolibriOS.
• Для VM: создайте 32-битную машину с 64 МБ RAM и VESA-видео.
• Для железа: запишите ISO на CD или USB через обычную утилиту.
• Загрузитесь и выберите разрешение экрана из меню загрузчика.
• Исследуйте меню «Пуск»: игры, утилиты, терминал и браузер.

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

Выводы

KolibriOS 0.7.7 — это не замена Windows или Linux, а демонстрация того, какой отклик может давать компьютер, когда софт пишут под железо, а не под абстракции. В эпоху, когда операционки растут гигабайтами, проект напоминает: минимализм ещё жив.

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

Главный вопрос — нужна ли вам такая система прямо сейчас. Если у вас есть старый 32-битный ноутбук, интерес к ассемблеру или просто ностальгия по быстрым ОС — попробуйте. А для повседневной работы с интернетом пока придётся держать под рукой что-то посовременнее.

Источники:

• Jenny’s Daily Drivers: KolibriOS 0.7.7 — Hackaday
• KolibriOS на DistroWatch
• Официальная вики KolibriOS

Продукт адресован разработчикам и продуктовым командам, которые хотят запускать инференс LLM на серверах в РФ с предсказуемым бюджетом — без зависимости от зарубежных API-провайдеров и неожиданных счетов.

Что внутри каталога

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

Для каждой модели заранее рассчитаны:

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

Система автоматически подбирает конфигурации: от бюджетных решений на одном GPU до кластерных сценариев с балансировщиками нагрузки и аппаратными NVLink/NVSwitch.

Как это работает экономически

В отличие от зарубежных облаков с pay-per-token, immers.cloud тарифицирует по времени работы виртуальной машины или выделенного сервера. Модель разворачивается на арендованном GPU-сервере под полным контролем пользователя: произвольная версия vllm, приватный доступ, кастомные веса, возможность масштабирования.

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

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

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

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

Попробовать бесплатные модели и запустить приватный инстанс можно на immers.cloud/ai/model/. Там же — видеогайд по деплою приватных инстансов: YouTube, ВКонтакте, Rutube.

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

Что такое NixOS

NixOS — это дистрибутив Linux, в котором всё системное окружение описывается декларативно на языке Nix и воспроизводится из одного конфигурационного файла. Каждая сборка помещает зависимости в /nix/store, что даёт атомарные откаты и воспроизводимость, но при этом легко разрастается размер.

Одна из удобных фич — команда nixos-rebuild build-vm: она превращает конфигурацию в виртуальную машину. Но иногда нужен не «тонкий» образ, привязанный к хосту, а самодостаточный ISO, который можно записать на флешку или загрузить в облаке.

• Базовый NixOS ISO занимает 458 МБ: 416 МБ — squashfs с пользовательским окружением, 26 МБ — initrd, 13 МБ — ядро.
• Главные «тяжеловесы» внутри образа: модули ядра (144 МБ), Python 3 (128 МБ), systemd (60 МБ), Perl (56 МБ), GRUB (около 62 МБ).
• Отключение Nix, документации, SSH, firewall и лишних зависимостей сокращает ISO до 197 МБ.
• Замена Perl-активации на экспериментальные system.etc.overlay и services.userborn даёт финальный размер около 183 МБ.
• Это игрушечный эксперимент: для десктопа и сервера такие отсечения небезопасны, но полезны как источник идей.

От VM к ISO за несколько строк

Минимальная виртуальная машина на NixOS собирается из файла примерно такого вида:

Запуск: $(nix-build basic-vm.nix --attr vm --no-out-link)/bin/run-nixos-vm. При этом /nix/store монтируется с хоста, поэтому VM «тонкая». Для независимого ISO импортируем модуль iso-image.nix и собираем атрибут isoImage:

ISO собирается, загружается в QEMU, но размер сразу бросается в глаза.

458 МБ — из чего они сложились

Автор примонтировал полученный ISO и посмотрел распределение места. Вот ключевые цифры:

• 416 МБ — сжатый nix-store.squashfs с пользовательским окружением.
• 26 МБ — начальная загрузочная среда initrd.
• 13 МБ — ядро Linux.
• 3 МБ — загрузчик isolinux.

При распаковке squashfs картина ещё интереснее:

• 144 МБ — модули ядра (linux-6.18.35-modules).
• 128 МБ — Python 3.13.
• 60 МБ — systemd.
• 56 МБ — Perl.
• ~62 МБ суммарно — две копии GRUB (UEFI + BIOS).

Поскольку ISO собирается локально, все пакеты из него есть и в хостовом /nix/store. Это позволяет использовать nix why-depends, чтобы найти, кто тащит каждую зависимость.

Отключаем Nix, документацию и лишние сервисы

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

Результат: 384 МБ. Экономия скромная, потому что часть зависимостей Nix всё ещё тянется через сервис register-nix-paths. Он регистрирует содержимое хранилища ISO при загрузке — но Nix-то мы уже убрали. Отключаем и его:

Теперь ISO уменьшился до 360 МБ, а зависимость от Boost исчезла полностью.

SSH: модуль без выключателя

Следующий кандидат на удаление — OpenSSH-клиент. Проблема в том, что модуль programs/ssh.nix добавляет его в environment.corePackages, а отдельного переключателя programs.ssh.enable нет.

Попытка полностью исключить модуль через disabledModules ломает другие модули, например Plasma 6, которые ожидают существования опций programs.ssh. Выход — подменить опцию «пустышкой», не затрагивающей реальную конфигурацию:

Параллельно автор убрал firewall, documentation.man.enable и принудительно очистил environment.defaultPackages.

GRUB: зачем две копии загрузчика

ISO-пресет NixOS включает сразу и UEFI-, и BIOS-версии GRUB — отсюда около 62 МБ. Чёткого флага для отключения одной из них нет, поэтому автор пошёл грубым путём: сбросил system.extraDependencies и environment.systemPackages, оставив только environment.corePackages, чтобы shell хотя бы стартовал.

Ядерные модули: четверть образа

Модули ядра весили 144 МБ — больше, чем весь Alpine ISO. NixOS не предоставляет удобного способа ограничить их набор для runtime, поэтому автор просто удалил папку модулей из системы после сборки:

Это полностью отключает динамическую загрузку модулей. Если что-то нужно — оно должно оказаться в boot.initrd.kernelModules или availableKernelModules. После этого образ уменьшился до 197 МБ.

Perl: заменяем активацию системы

Perl в образе нужен только для скриптов активации: настройки /etc и создания пользователей. В nixpkgs уже есть экспериментальные замены — system.etc.overlay и нативный менеджер пользователей userborn.

Оба механизма помечены как экспериментальные, но в контексте «самодельного минимального ISO» это уже не самая безумная идея. Финальный размер: 183 МБ.

Что получилось и стоит ли повторять

За несколько итераций образ сократился с 458 МБ до 183 МБ — почти в 2,5 раза. При этом система всё ещё загружается, автор смог залогиниться под root, правда разрешение экрана перестало переключаться.

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

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

Выводы

Эксперимент показывает, что NixOS позволяет не только собирать сложные системы, но и жёстко урезать их — иногда в ущерб удобству. Главный инструмент здесь не волшебная опция, а последовательный анализ: смотреть, что занимает место, находить виновника через nix why-depends и решать, готовы ли вы от него отказаться.

«At some point I just kept going because I got curious.»

Если захотите повторить — начните с отключения Nix и документации, а дальше решайте, какие модули и пакеты действительно нужны в вашем live-образе. Исходный материал — в блоге автора: I can haz smoller NixOS ISOs?.

В Linux 7.2 код расширяемого планировщика sched_ext изначально появился в виде файлов ext_arena.c, ext_cid.c, ext_types.h и других прямо в kernel/sched.

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

Новый pull request перенёс файлы в kernel/sched/ext/; Торвальдс уже принял эту реструктуризацию.

Что случилось

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

Вместо того чтобы создать поддиректорию kernel/sched/ext/, авторы добавили в kernel/sched несколько файлов с префиксом ext_: ext_arena.c, ext_arena.h, ext_cid.c, ext_cid.h и ext_types.h.

Please don't do this disgusting thing. There's a reason we have subdirectories: it's to group files together and separate them out. Using name prefixing instead of directories is disgusting and wrong. If you have this many random sched-ext files, it damn well should be cleaned up and not be this kind of mess. I've pulled this, but under protest. Proper hierarchical filesystems have been available since 1965.

Как исправили

В ответ разработчики отправили новый pull request, который перекладывает все sched_ext-файлы в отдельную директорию kernel/sched/ext/. Торвальдс уже принял реструктуризацию.

Почему это важно

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

Выводы

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

Источники

• Phoronix: "Disgusting" Linux sched_ext Source Code Restructured
• Письмо Линуса Торвальдса в lkml
• Коммит реструктуризации в git.kernel.org

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

Linux Foundation запустила программу Akritis 25 июня 2026 года.

Участники включают AWS, Anthropic, Google, Microsoft, OpenAI, NVIDIA, IBM, JPMorganChase, GitHub, Red Hat, Sonatype и других.

Цель — единый координированный процесс раскрытия уязвимостей (CVD) в open source до их массовой эксплуатации ИИ-атаками.

Akritis обещает не форкать проекты и выступать «мейнтейнером последней надежды» для заброшенных пакетов.

Первичное финансирование поступает от фонда Alpha-Omega.

Почему это важно

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

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

Как устроен Akritis

Программа строится вокруг трёх элементов:

• Единая команда реагирования (SIRT) — доверенный посредник между исследователями и мейнтейнерами, который получает отчёты, проверяет их и координирует исправления.
• Стандартизированный CVD-процесс — использует CVE, TLP, CWE, CVSS, EPSS, SSVC и VEX для единого языка рисков и статусов уязвимостей.
• Возврат патчей в upstream — исправления передаются в исходный проект, а не в отдельный форк. Если активного мейнтейнера нет, Akritis временно берёт на себя роль «мейнтейнера последней надежды».

The space is crowded, and the track record is mixed. What I think is genuinely different here is narrow: one coordinated process, so open source maintainers face a single partner instead of a hundred separate reporters.

Кто участвует

В инициативе участвуют крупнейшие облачные провайдеры, ИИ-лаборатории, банки, телекомы и вендоры безопасности. Среди них — Amazon Web Services, Anthropic, Chainguard, Cisco, Citi, Endor Labs, Ericsson, Google, IBM, JPMorganChase, Microsoft, GitHub, NVIDIA, OpenAI, RapidFort, Red Hat, Rust Foundation, Sonatype, Vodafone и Zscaler.

Примечательно, что некоторые из них уже имеют собственные программы — например, Chainguard (Athena) и IBM с Red Hat (Project Lightwell). Но Akritis позиционируется не как конкурент, а как общая координационная инфраструктура поверх их работы.

Контекст

The software supply chain is only as strong as the upstream it draws from, and we see how thin that layer really is. Akritis gives the industry one coordinated way to fix vulnerabilities upstream before they’re exploited, with maintainers still in control.

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

Выводы

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

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

Источник: DevOps.com — Akrites: The latest attempt to protect open source from AI attacks has arrived

Сервис Images, написанный на Rust и работающий в Workers, запущен на каждой машине в edge-сети Cloudflare. Чтобы обрабатывать клиентские соединения, мы используем hyper — открытую HTTP-библиотеку для Rust.

В прошлом году мы представили Images binding — он позволяет создавать кастомные программные сценарии обработки удалённых изображений в Workers. В конце 2025 года мы перестроили binding, чтобы сделать связь между Workers runtime и сервисом Images более прямой и локальной.

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

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

Cloudflare Images binding перешёл на прямое локальное соединение через Unix-сокеты в декабре 2025 года.

После выкатки большие изображения стали иногда возвращаться обрезанными: HTTP 200, но тело ответа короче Content-Length.

Причина — состояние гонки в hyper: цикл poll_loop отбрасывал результат poll_flush, даже если тот возвращал Poll::Pending.

Баг существовал в hyper 0.14.x, 1.7 и 1.8; прежний посредник FL читал данные достаточно быстро, чтобы он не проявлялся.

Исправление заняло четыре строки кода: flush теперь выполняется перед shutdown.

Прыжки, передачи и hyper

Когда разработчики создают приложения на Cloudflare, они собирают full-stack приложения из набора платформенных сервисов, доступных Workers через bindings. Bindings предоставляют прямые API к ресурсам Developer Platform: вычислениям, хранилищам, ИИ-инференсу и обработке медиа.

Images binding отделяет оптимизацию изображений от доставки: вы можете транскодировать, компоновать или изменять изображения, не возвращая результат в виде HTTP-ответа. Также он позволяет применять параметры оптимизации в любом порядке, а не в фиксированной последовательности, которую навязывает URL-интерфейс. Вот пример: воркер передаёт данные изображения напрямую в Images API, объединяет операции в цепочку и получает обработанный результат в виде потока:

На высоком уровне так выглядит движение данных через наши сервисы:

Труба на схеме обозначает сокетное соединение между посредником и Images, через которое данные передаются от одного процесса к другому через буфер ядра.

Binding взаимодействует с Images через сокетное соединение, управляемое Workers runtime. Сокет — это канал связи между двумя процессами. У каждого конца сокета есть буферы, управляемые ядром операционной системы; эти буферы — временные области, где данные остаются после записи одной стороной, но до чтения другой.

Hyper управляет соединением на стороне сервиса Images: читает входящие запросы из сокета и пишет ответы обратно в него.

Когда запрос использует Images binding, сервис Images читает входные данные, выполняет запрошенные операции оптимизации и кодирует результат. Затем он передаёт всё закодированное изображение hyper как один непрерывный блок в памяти.

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

Если читатель на другом конце быстрый, hyper может сбросить всё за один проход — в исходящем буфере будет место, потому что читатель потребляет данные по мере поступления. Как только все данные отправлены, hyper вызывает shutdown на сокете, сигнализируя, что соединение завершено и больше данных записано не будет. Но если читатель медленнее (хотя бы на несколько миллисекунд), исходящий буфер заполняется, и hyper должен ждать, пока появится место, чтобы продолжить запись.

Локальное соединение

Весь входящий трафик в сети Cloudflare проходит через FL — внутренний сервис-посредник, который включает функции безопасности и производительности и маршрутизирует запросы к нужному бэкенду. Когда мы только запустили binding, данные изображений шли из Workers runtime через FL в сервис Images.

Этот путь хорошо подходил для первого релиза и повторял архитектуру URL-интерфейса. Но со временем связь с FL стала ограничением: любое изменение binding приходилось согласовывать с циклом релизов FL.

В декабре 2025 года команда Images заменила FL новым посредником — внутренним worker binding, который работает на той же машине. В исходной архитектуре данные шли через FL по сетевым сокетам; этот путь нёс накладные расходы полного конвейера обработки FL, такие как DNS-lookup'ы и маршрутизация.

Внутренний binding заменил их на Unix-сокеты, чтобы напрямую соединить сервисы на одной машине, минуя FL и накладные расходы сетевого стека. Это ускорило путь запроса к Images и дало команде независимый контроль над релизами binding.

В течение нескольких дней после выкатки мы получили первый отчёт от клиента.

200 OK (не OK)

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

Сначала их воркер с помощью Images binding компоновал несколько больших исходных изображений из R2 — JPEG-фон и PNG-оверлеи — в один объединённый JPEG. Затем результат дополнительно сжимался, транскодировался и изменялся размер через URL-интерфейс.

Баг возникал на обратном пути внутреннего pipeline, где ответ обрезался до того, как достигал внешнего.

Внутренний pipeline (transformation binding) отвечал за компоновку. Внешний pipeline (transformation URL) отвечал за оптимизации доставки: масштабирование и конвертацию формата. Такая многоуровневая схема означала, что когда внутренний pipeline молча возвращал обрезанный ответ, видимая ошибка появлялась на уровень выше:

Внешний pipeline получал от внутреннего HTTP 200 с заголовком Content-Length, который обещал несколько мегабайт. Фактическое тело было лишь частью от этого: в одном запросе из ожидаемых 3,3 МБ пришло всего около 200 КБ. Ошибка всплывала во внешнем pipeline, но обрезка могла произойти в binding, посреднике, сервисе Images или где-то между ними.

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

Отладка вслепую

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

• Сборка репродукции. Мы собрали воркер, повторяющий вложенную схему клиента, и постепенно убирали уровни, пока не смогли воспроизвести баг только с binding. Небольшой скрипт отправлял запросы пачками. На одном из первых прогонов 19 из 25 запросов упали. Объём данных, которые всё-таки приходили, — примерно 200 КБ — настораживающе близко к размеру сокетного буфера в продакшене. Это подтвердило, что проблема не связана с конфигурацией клиента, и дало надёжный способ воспроизводить баг по запросу.
• Проверка таймаутов. Сначала мы подозревали, что обрезка связана с поведением таймаутов (то есть соединение закрывалось по истечении лимита времени). Эта теория не подтвердилась: обрезка не коррелировала с длительностью запроса.
• Обновление версии hyper. Когда баг впервые зарепортили, мы использовали 0.14.x, а последняя версия hyper была около 1.8.x. Мы протестировали версии 0.14, 1.7 и 1.8 — на случай, если самый очевидный ответ окажется правильным (и самым простым). Но баг проявлялся в каждой версии, значит, upstream-исправления не было.
• Локальное воспроизведение. Мы запускали интеграционные тесты на macOS и Debian-виртуалке. Даже под значительной нагрузкой локальные запросы никогда не падали. Прямые curl-запросы к сокету binding и повтор отловленных запросов всегда работали. Баг проявлялся только на полном продакшен-пути при реальной конкурентности и реальном клиенте Workers runtime на другом конце сокета. Это натолкнуло нас на подозрение, что виноват сам runtime.
• Исключение Workers runtime. Мы изучили HTTP-клиент, который Workers runtime использует для связи с Images через сокет binding. Ни на одной из сторон соединения в трассировках не было системных вызовов, указывающих на неожиданное закрытие или преждевременное завершение. Клиент вёл себя корректно, и несколько других сервисов использовали того же клиента без проблем.
• Распределённая трассировка. Изучив сквозные трассировки запросов, мы подтвердили, что обрезанное тело уже присутствовало до того, как достигало внешнего уровня трансформации в схеме клиента. Это сузило проблему до внутреннего pipeline — пути binding через сервис Images.
• Инструментирование посредника. Мы добавили инструментирование в посредник, чтобы измерять размеры тел перед пересылкой ответа. Тела уже были обрезаны к моменту выхода из сервиса Images, так что посредник был исключён.
• Углублённая трассировка внутри Images. На уровне сервиса запрос обрабатывался, изображение корректно кодировалось, и ответ отправлялся с HTTP 200.

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

Зерно истины

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

Чтобы увидеть, что система делала на самом деле, мы подключили strace к сервису Images. strace записывает системные вызовы, которые процесс делает ядру; это позволило показать, какие именно байты были записаны, когда вызывался shutdown и посылал ли клиент сигнал завершения.

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

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

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

Когда мы воспроизвели баг, упавший запрос выглядел так:

Здесь есть только одна запись — лишь заголовки и крошечная часть тела — перед немедленным вызовом shutdown. Из ответа в 14,9 МБ было отправлено около 219 КБ. Оставшиеся ~14,8 МБ данных изображения никогда не покидали внутренний буфер hyper, и не было никакого сигнала завершения от клиента между записью и shutdown. Вместо этого сервис Images преждевременно закрывал соединение самостоятельно, искренне полагая, что работа завершена.

Упавшие запросы подтвердили, что баг — состояние гонки, которое срабатывало непостоянно. Успех или провал зависели от того, перекрывались ли операции flush и shutdown, и это менялось от запроса к запросу. Когда буфер был полон в тот самый момент, когда hyper решил, что соединение завершено, данные терялись.

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

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

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

Внутри цикла dispatch

Жизненный цикл HTTP/1-соединения в hyper управляется конечным автоматом в файле под названием dispatch.rs. Он выполняет цикл, который читает запросы, пишет ответы, сбрасывает буфер записи в сокет и решает, когда закрываться. В упрощённом виде:

Точнее, именно let _ перед poll_flush — это место, где живёт баг.

В Rust let _ = expr отбрасывает результат выражения, включая Poll::Pending — сигнал о том, что flush ещё не завершён. В буфере flush может остаться несколько мегабайт, но цикл об этом никогда не узнаёт.

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

1. Сервис Images завершает кодирование изображения и передаёт весь ответ hyper как один блок в памяти.
2. Hyper записывает блок во внутренний буфер и помечает состояние записи как Writing::Closed. С точки зрения кодирования работа сделана — кодировать больше нечего.
3. Hyper вызывает poll_flush, чтобы перенести буферизованные данные в сокет. В нашем примере сокет принял около 219 КБ. Оставшиеся ~14,8 МБ остаются в буфере hyper. Сокет полон, поэтому ядро возвращает Poll::Pending.
4. poll_loop отбрасывает Poll::Pending с помощью let _.
5. Он проверяет wants_read_again(). Полный запрос уже получен, поэтому возвращается false.
6. poll_loop возвращает Poll::Ready(Ok(())), сигнализируя, что цикл завершён, хотя flush ещё не сделан.
7. Срабатывает poll_shutdown(). Выполняется системный вызов SHUT_WR.
8. Клиент получает 219 КБ и EOF (end-of-file), указывающий, что соединение закрыто, хотя он ожидает 14,9 МБ.

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

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

Не забывайте сбрасывать буфер

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

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

Мы знали условия, вызывающие баг: сокет, который принимает один кусок данных, а затем блокируется. Для контролируемого сценария мы построили обёртку вокруг TCP-потока, имитирующую полный сокетный буфер. Обёртка принимала 8 КБ при первой записи, а затем возвращала Poll::Pending на каждой последующей записи, имитируя читателя, который перестал опустошать буфер.

Тест отправлял 500 КБ ответа через этот ограниченный сокет и проверял, вызывает ли hyper shutdown, пока в буфере остаётся 492 КБ. Без исправления — вызывал. С исправлением — ждал.

Сначала мы применили исправление в цикле dispatch hyper. Вместо отбрасывания результата poll_flush мы проверяли, завершён ли flush на самом деле:

Если flush не завершён, цикл возвращает Poll::Pending асинхронному runtime. Runtime ждёт, пока сокет не станет доступен для записи, а затем будит задачу, чтобы продолжить flush. Соединение закрывается только после того, как все данные отправлены.

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

Хотя первоначальное решение работало, цикл dispatch был неправильным местом для исправления. Ранний возврат Poll::Pending мог замедлять другие операции на том же соединении, уменьшая частоту опроса чтения и вызывая нежелательное обратное давление. Также это корректно не обрабатывает keepalive-соединения, где одно соединение обрабатывает несколько запросов подряд — они должны оставаться пригодными к использованию, даже пока предыдущий ответ всё ещё сбрасывается. Ни одна из этих проблем не затрагивала наш сервис (где keepalive отключён), но обе могли повлиять на других пользователей hyper, если бы исправление было предложено upstream.

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

Это оставляет цикл dispatch без изменений. Flush добавляется только в тот точный момент, где иначе произошла бы потеря данных — непосредственно перед shutdown.

Что осталось с нами

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

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

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

Мы влили исправление и детерминированный тест в hyperium/hyper через PR #4018. Оно появится в будущем релизе hyper, гарантируя, что любой сервис, использующий HTTP/1-реализацию hyper, не потеряет данные ответа из-за того же состояния гонки.

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

Изначально Images binding покрывал только трансформации удалённых изображений. В начале этого месяца мы объявили, что Images binding теперь поддерживает операции для hosted-изображений, давая разработчикам единый способ строить медиа-насыщенные приложения на Cloudflare.

Подробнее о том, как работает binding, — в нашей документации.