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

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

Параллельно практические инструменты двигают контроль ниже: llama.cpp отправляет tool calls в Docker, Claude Code проверяет доверие к workspace, а serving- системы экономят дефицитный GPU не новой моделью, а планированием и памятью.

Железо и инфраструктура

Армения открыла AI factory, но большие цифры пока существуют в будущем времени

Firebird открыла площадку NVIDIA DSX в Раздане. NVIDIA называет её крупнейшей в СНГ и намерена инвестировать в компанию; сумма и условия не раскрыты. Среди партнёров названы Dell, Schneider Electric, Vertiv и CoreWeave, ранним клиентом — Perplexity.

Все впечатляющие числа относятся не к тому, что заработало 8 августа. Более 70 тысяч Rubin и Blackwell GPU и 300 МВт в Армении — цель к концу 2027 года. Около 2 ГВт в нескольких странах — roadmap Firebird на конец 2028-го. Ни Firebird, ни NVIDIA не сообщили текущую мощность и число установленных ускорителей.

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

AI factory всё чаще продают как единую единицу: compute, сеть, питание, охлаждение и operations. Её capacity нельзя проверять по фотографии церемонии — нужны фактические MW, installed accelerators и доступная клиентам мощность.

Источники: Firebird об открытии, NVIDIA о площадке.

Дефицит GPU лечат расписанием и движением памяти

ElastiCo пытается совместно размещать training и offline inference на одном GPU- кластере. Training jobs удерживают устройства даже во время менее нагруженных фаз, inference резервирует запас под пики; scheduler подбирает форму ресурсов и пары работ с приемлемой интерференцией.

На тестовом кластере из 64 A100 авторы подняли среднюю SM utilization с 25% у статического Volcano до 46%. Сильнее выглядит не это сравнение, а более честное — с эластичным Lucid: 38% против 46%. Всё, что выше 64 GPU, проверено уже в симуляции, а не на железе.

OasisKV работает с другой причиной дефицита. Система хранит вне HBM большую часть KV cache и заранее подкачивает только блоки, которые, вероятно, понадобятся следующему decode step. Подсказку даёт speculative decoding. На восьми H100 авторы получили 1,69× throughput на одном reasoning workload и до 2,1× на long-context serving против dense vLLM, сохранив качество в пределах 0,7 пункта при заданном KV budget.

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

Источники: ElastiCo, OasisKV.

Наблюдаемость и evaluation

Телеметрия замечает провал, но теряет причину

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

На синтетических agent traces пять frontier-моделей с полной телеметрией определяли исходный шаг с точностью от 33,8% до 97,2%. Когда те же traces показывали через metadata-, OpenTelemetry- и OpenInference-подобные views, failure detection оставался почти идеальным — 99,5–100% F1, — но точность локализации причины падала максимум до 0,5%. Удаление decision content обнуляло её у всех моделей.

Это не измерение production OpenTelemetry: benchmark синтетический, а названия форматов означают выбранное авторами представление. Но он ловит реальный дефект наших dashboard. Статус failed и последняя ошибка хорошо отвечают на вопрос «кого разбудить». Они почти ничего не говорят о том, какое раннее решение создало поздний сбой.

Для agent observability нужны не только логи инструментов, но и provenance: какой вывод привёл к следующему действию, откуда пришли данные и какая версия policy разрешила переход. Без этой связи дорогая модель-диагност видит аккуратно оформленную потерю информации.

Источник: TelemetrySuffBench.

Replay оценивает траекторию, которой после замены модели не существует

Обычный способ тестировать model router выглядит разумно: взять записанную траекторию агента, заменить ответ дешёвой модели на ответ сильной и посмотреть, улучшился ли итог. The Replay Gap проверяет именно это предположение.

Автор форкал живые траектории mini-SWE-agent в контролируемых точках, восстанавливал среду и продолжал выполнение с другой моделью. В 74–77% ранних замен следующее же действие расходилось с оригиналом. Все пять observed outcome flips случились в swap arms, ни одного — в 359 same-model control forks. Статический log-stitching неверно предсказал все пять случаев, где успех мог измениться.

Работа узкая: один scaffold, две небольшие Qwen, всего пять outcome flips. Зато она демонстрирует не статистический нюанс, а причинную ошибку. Новый ответ меняет следующий tool call, тот меняет состояние репозитория, и старая траектория перестаёт быть counterfactual.

Соседний препринт о routing добавляет второе предупреждение. На четырёх обычных benchmark теоретический oracle gap был большим, но лучший prompt router возвращал лишь 7,5–14,4% этого разрыва. После поправки на выбор лучшей из 11 политик данные вообще не доказывали превосходство над лучшей фиксированной моделью. Эксперимент проведён на моделях 0,5–7B, не на frontier agents, поэтому важна не величина, а дисциплина вывода.

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

Источники: The Replay Gap, selection-valid routing diagnostics.

Безопасность агентов

Prompt injection в VirusTotal встретился с контейнером llama.cpp

Исследователь ropbear опубликовал три prompt-injection атаки на Gemini-backed Code Insights API VirusTotal. Комментарий в анализируемом коде заставлял модель признать download-and-execute benign-инструментом в 45 из 50 запросов; другой комментарий приписывал безобидный код выдуманной группе APT1234 в 21 из 50. Третий payload ломал ожидаемую схему ответа и раскрывал строку backend-модели.

Google и VirusTotal публично работу не подтвердили. Это один self-published отчёт, тесты составил и оценивал сам автор, а post-patch выборки содержали лишь по десять запросов. Поэтому проценты нельзя читать как устойчивый benchmark. Но механизм правдоподобен: система передаёт в LLM код и комментарии из недоверенного файла, а затем принимает её текстовый вердикт за анализ.

В тот же день llama.cpp влила initial tool isolation для существующего agent mode. llama-server теперь может проксировать встроенные shell tools в Docker- контейнер вместо host. Это ранний merge, не законченная security boundary, но направление верное: недоверенный ввод всё равно дойдёт до модели, поэтому последствие tool call ограничивается инфраструктурой.

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

Источники: исследование Code Insights, tool isolation в llama.cpp.

Claude Code собирает доверие, бюджет и удалённую сессию в одном месте

Claude Code 2.1.225 научилась показывать spend limit, который наложил LLM gateway, вместе со временем сброса и сообщением оператора. Команда claude agents получила workspace trust prompt. А SendMessage теперь может не только ответить удалённой сессии, но и начать разговор с найденной по имени Remote Control session на другой машине.

Большая часть релиза — исправления ровно тех швов, которые возникают в долгой распределённой работе: краткоживущий token не должен затереть постоянный, сообщение не должно навсегда застрять без уведомления, self-hosted runner обязан проверить writable directory до регистрации.

По отдельности это changelog maintenance. Вместе — признак того, что coding agent перестал быть процессом в одном terminal. У него появляется identity workspace, удалённые peers, внешний gateway budget и собственный lifecycle. Значит, ошибка в control plane уже опаснее неудачного ответа модели: она может остановить все сессии, доставить сообщение не туда или незаметно сменить credentials.

Источник: Claude Code 2.1.225.

Модели и языки

Safety, настроенный на английский, не переносится автоматически

SurakshaEval собрал 2 968 написанных людьми prompts на десяти индийских языках и английском. Они охватывают общие и региональные риски: политику, кастовые и этнические стереотипы, право, культуру, конкретных людей и adult content. Авторы прогнали 27 моделей и увидели ухудшение safety в родных письменностях, особенно для менее ресурсных языков.

Headline scores выглядят точными — например, лучший combined pass rate 70,7, — но ground truth слабее этой точности. Ответы оценивала панель из GPT-4.1-mini и GPT-5-mini, а на человеческой выборке для Malayalam совпадение составило 69,2%. Рейтинг моделей поэтому следует считать ориентиром, а не финальным verdict.

Содержательный вывод проще. Перевод safety policy не равен локальной safety. Implicit bias, региональная история и допустимый контекст проявляются именно в языке, а judge, обученный на другом распределении, может не заметить тот же сбой, который должен измерять.

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

Источники: SurakshaEval, репозиторий проекта.

Developer tooling

SGLang становится системой эксплуатации, а не просто inference engine

SGLang 0.5.17 вышел циклом из 582 pull requests от 194 contributors. Релиз добавил serving для Kimi K3, переписал front half сервера с Python на многопоточный Rust и сделал Unified Radix Cache aware of session references, чтобы eviction не удалял prefix, который ещё держит активная agentic или RL- сессия.

Отдельный weight-cache daemon сохраняет веса на GPU при рестарте engine. Проект сообщает, что в одном случае загрузка DeepSeek-V4-Pro TP8 сократилась примерно с 35 минут до 6 минут 20 секунд. Это внутреннее измерение конкретной конфигурации, не универсальные 5,6× для любой модели.

Интереснее, что оптимизации посвящены не только kernel throughput. Server frontend, restart, session ownership cache и распределённый prefill становятся равноправными частями serving stack. Когда модель весит сотни гигабайт, шесть минут восстановления и неверное eviction-решение могут стоить продукту больше, чем несколько процентов скорости matrix multiply.

Inference engine постепенно превращается в операционную систему для долгих model sessions.

Источник: SGLang 0.5.17.

Короткий open-source сигнал

ComfyUI 0.31.0 добавила локальную поддержку Wan-Animate2 и MiniMax-H3, универсальную схему w4a8 quantization, а также API nodes для Flux 3 video и SeeDance 2.5. Последние два пункта — клиенты hosted API, а не новые открытые веса. Это небольшая, но полезная граница: интерфейс в open-source tool ещё не делает доступную через него модель открытой.

Источник: ComfyUI 0.31.0.

Главный технологический сдвиг выпуска

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

Scheduler видит занятость GPU, но должен понимать интерференцию. Observability видит failure, но теряет породившее его решение. Replay хранит старый лог, но не мир, который возник бы после другого ответа. Safety benchmark переводит prompt, но не обязательно локальный контекст и качество judge.

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

Что обсудить с технической командой

  1. Можем ли мы восстановить не только последнюю ошибку агента, но и решение, которое сделало её неизбежной?
  2. Какие evaluation основаны на статическом replay там, где замена модели меняет саму траекторию?
  3. Содержит ли телеметрия provenance между model output, tool call и изменением состояния?
  4. Какие инструменты выполняются на host, хотя могли бы работать в отдельном контейнере с узкой сетью и файловой системой?
  5. Проверяем ли мы safety отдельно для каждого языка и самого automated judge?