1. Модели

GLM‑5.3‑Flash: Z.ai делает ставку не на максимальный размер, а на стоимость длинных agent workloads

Что произошло. Z.ai формально представила GLM‑5.3‑Flash и открыла веса под MIT. Модель имеет 320 млрд параметров, но только 18 млрд активных, нативно мультимодальна и поддерживает контекст до 1 млн токенов. Ранее она анонимно тестировалась как Ox Alpha, а отдельные продукты Z.ai уже начали интегрировать её до сегодняшнего публичного раскрытия.

Архитектурно интереснее всего сочетание sparse и linear attention. По данным Z.ai, относительно полного GLM‑5.3 это даёт примерно 3× меньше compute на attention и 4,4× меньший KV-cache.

Что показали данные. На vendor benchmarks против GLM‑5.2:

• Terminal Bench 2.1: 84,3 vs 81,0
• DeepSWE v1.1: 63,4 vs 46,2
• Toolathlon Verified: 78,4 vs 59,9
• AutomationBench: 48,8 vs 26,2
• Agents’ Last Exam: 26,3 vs 20,4.

Это оценки самой Z.ai; они пока не являются независимым подтверждением.

Отдельно важна infrastructure-часть. Z.ai утверждает, что реальный трафик модели уже обслуживался на китайских AI-ускорителях, а собственная serving stack дала примерно 3× улучшение end-to-end serving performance относительно первоначального baseline на том же hardware.

Почему это важно. Agent workloads очень чувствительны не только к intelligence модели, но и к цене каждого дополнительного шага. Если агент делает десятки или сотни model calls, использует миллионный context и постоянно смотрит на screenshots/documents, efficiency становится частью capability.

Именно поэтому Flash-модель может быть важнее ещё одного дорогого frontier model: она потенциально подходит для слоя workers внутри системы, оставляя дорогую модель для planning, difficult reasoning и verification.

Что нужно уже понимать: MoE / active parameters, KV-cache, sparse attention, linear attention, model routing.

Что это может изменить. Стоит тестировать не только:

Claude vs GPT vs GLM

а архитектуру:

дорогой planner/verifier → дешёвые multimodal workers.

Для production агента сравнение должно включать completion rate, стоимость завершённой задачи, latency и количество human interventions.

Дата: 7 сентября. Первоисточник: Z.ai — GLM‑5.3‑Flash

2. Архитектура и эксплуатация агентных систем

OpenAI впервые показала реальные внутренние масштабы использования coding agents: 3,1 agent-workday на один человеческий

Это главный материал выпуска.

Что произошло. OpenAI опубликовала внутренние данные о том, как исследователи используют coding agents. Компания утверждает, что достигла своей цели «automated research intern»: системы, способной под человеческим руководством выполнять хорошо определённые задачи, которые у квалифицированного исследователя заняли бы несколько дней.

По состоянию на середину августа общий agent runtime внутри research organization достиг 3,1 стандартного agent-workday на каждый человеческий workday. До июня суммарный runtime агентов был меньше человеческого труда — после июня соотношение перевернулось.

Что показали данные.

Медианный исследователь OpenAI уже использует coding-agent inference более чем на $600 в сутки по API-ценам. 90-й перцентиль — более $7 000 в сутки. Всё больше сотрудников одновременно запускают четыре и более агентов.

Количество экспериментов на одного активного экспериментатора в августе достигло максимума за весь период наблюдения с января 2025 года. OpenAI отмечает корреляцию с распространением Codex, но отдельно предупреждает: compute capacity компании одновременно тоже росла, поэтому причинность здесь не доказана.

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

Это не benchmark. Это vendor-reported production telemetry собственной research organization.

Почему это важно. До сих пор большая часть разговоров об agent productivity строилась вокруг SWE-bench, demos или отдельных компаний.

Здесь впервые появляется достаточно конкретный operating model:

human researcher → несколько параллельных agents → experiments/code/infrastructure → human steering → human judgement.

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

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

Что нужно уже понимать: agent concurrency, human-in-the-loop, long-horizon task, inference economics, AI R&D loop.

Что это может изменить. Возможно, неправильная метрика для внедрения coding agents — «сколько разработчиков можно заменить».

Более полезные:

• сколько параллельных workstreams может контролировать один инженер;
• сколько экспериментов команда может провести;
• насколько вырос throughput;
• где человек всё ещё становится bottleneck;
• сколько стоит дополнительный agent-workday.

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

Дата: 6 сентября. Первоисточник: OpenAI — Research acceleration: The view inside OpenAI

Но масштабирование агентов немедленно упирается в supervision

В том же отчёте есть второй, почти противоположный сигнал.

OpenAI пишет, что high-level planning всё ещё составляет небольшую часть agent workload. Люди продолжают определять research priorities, решать, какие результаты важны, и принимать решения о scaling, остановке и deployment.

Получается разделение:

agents хорошо масштабируют execution; человеческое judgement масштабируется значительно хуже.

Это потенциально и есть следующий bottleneck agent organizations.

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

goal setting → task decomposition → monitoring → evaluation → selection → escalation.

Что нужно уже понимать: orchestration, delegation, evaluation, human supervision, management bandwidth.

Что это может изменить. Следующий слой developer tooling, вероятно, будет оптимизировать уже не генерацию кода, а управление десятками параллельных agent tasks: приоритеты, состояние, blockers, verification и exceptions.

OpenAI также показала необычный экономический эффект safety controls: compute просто перетекает в другие задачи

После выявления проблем с agent security OpenAI 20 июля временно остановила container service, используемый для training, а затем вернула его с более жёсткими ограничениями. RL-training последних deployable models был примерно на две недели приостановлен.

После того как Astra потребовала более защищённой research environment, allocation GPU под Astra-class workloads за следующую неделю упал ещё на 59,2%.

Но GPU allocation на другие model classes вырос на 17,2%, компенсировав примерно 85% сокращения Astra compute.

Почему это важно. Это хороший пример системного эффекта.

Ограничить один workflow ≠ остановить innovation.

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

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

Что нужно уже понимать: RL training, compute allocation, sandbox, defense in depth, opportunity cost.