Пока инфо-бизнесмены продают очередные курсы по промпт-инжинирингу, в индустрии пересобирают саму архитектуру ИИ-систем. Главные вызовы сегодня лежат в плоскости ML-инфраструктуры: как запустить автономных агентов на проде, снизить latency и не обанкротиться на обучении моделей с нуля.
В майском выпуске разбираем свежие архитектурные подходы, новое железо и софт, которые меняют экономику современных нейросетей.
Как один разработчик запускает 100 агентов на Codex
В начале мая 2026 года в инженерном сообществе обсуждали не столько сам OpenClaw, сколько ощутимый эффект от его внутренней работы: один из авторов проекта, Питер Штайнбергер, опубликовал скриншот OpenAI‑дашборда, где за 30 дней накопился счет на 1 305 088,81 долларов. Это не демонстрация, а фактический лог агентов в продакшен‑среде, которые в фоне «дергают» Codex по нескольку миллионов запросов.
За месяц сервис обработал около 603 млрд токенов в рамках 7,6 млн запросов. При этом за всю инфраструктуру отвечают примерно 100 экземпляров Codex, которыми управляет команда из трех человек.
ИИ-агенты полностью закрывают рутину:
проверяют pull request'ы и ищут уязвимости в коммитах;
очищают баг-трекер от дубликатов;
пишут исправления и сами открывают новые PR, опираясь на roadmap OpenClaw.
Отдельные системы непрерывно отслеживают бенчмарки и фиксируют регрессии, сразу отправляя алерты в Discord. Расходы оплачивает уже не сам Штайнбергер, а OpenAI, куда он перешел в феврале 2026.
Важная деталь: в этот бюджет сильно вписывается режим «Fast Mode» Codex, который расходует токены гораздо быстрее обычного режима. По словам Штайнбергера, при отключении Fast Mode месячный объем расходов сокращается примерно до 300 000 долларов. Даже в таком виде это значительно больше, чем типичные корпоративные подписки на аналогичные ассистенты.
Этот кейс естественно подводит к теме, которая сейчас активно поднимается в обсуждении агентных систем: когда говорят о сотнях агентов, экономика переходит на первое место. Каждая лишняя токенизация, режим «быстрее/медленнее» и стиль автоматизации начинают напрямую затрагивать счет, а не только точность модели.
Облачная инфраструктура для ваших проектов
Виртуальные машины в Москве, Санкт-Петербурге и Новосибирске с оплатой по потреблению.
Cerebras запустил Kimi K2.6 и обогнал все GPU мира
Если в прошлом месяце нас впечатлил пример, как Kimi 2.6 сама переписала рантайм на Zig и обогнала LM Studio, то сейчас Cerebras продемонстрировала, как эта же архитектура смотрится в корпоративном масштабе. Калифорнийская компания официально включила в продакшен свои возможности по инференсу для модели Kimi K2.6 с объемом около 1 трлн параметров, зафиксировав при этом серьезный разрыв в скорости по сравнению с традиционными GPU‑облаками.
Независимый анализ Artificial Analysis показал около 981 токена в секунду на выходе, что приближается к 6,7‑кратному превосходству над лучшим на тот момент облачным GPU‑провайдером и примерно в 23 раза быстрее среднерыночного уровня. В конкретном сценарии: типичный запрос разработчика с 10 000 входными токенами и 500 токенами ответа Cerebras обрабатывает за 5,6 секунды, в то время как официальный облачный сервис Kimi тратит на аналогичный запрос 163,7 секунды — разница почти в 30 раз.
За этим показателем стоит переход на архитектуру Wafer‑Scale Engine 3 (не просто апгрейд чипа), где процессор собирается на одной кремниевой пластине, вместо нескольких кластерных GPU. Внутри чипа выделяют около 44 ГБ сверхбыстрой SRAM, а пропускная способность внутрикристальной сети, по оценкам, примерно в 200 раз выше пропускной способности NVLink у NVIDIA.
Веса модели распределены по примерно 20 системам CS‑3, но при этом все эксперты MoE‑слоя, отвечающие за активные части, укладываются на одной пластине, что уменьшает накладные расходы на межкристаллический обмен.
Пока что все это доступно только в корпоративном облаке Cerebras для клиентов уровня Fortune 500, с ценами на уровне средних и верхних тарифов GPU‑провайдеров, без захода в нишу «дешевого» медленного инференса.
В такой же период рынок инференса еще и накачивается деньгами: Cerebras вышла на IPO, привлекла около 5,5 млрд долларов и оценивается в 60 млрд, а в слухах фигурируют крупные контракты с OpenAI и активные перемещения в сегменте компаний вроде Groq, что делает текущий этап похожим на разгонную фазу перед следующим циклом игр «железо vs. цены».
AMD выпускает Instinct MI350P с 144 ГБ HBM3E для PCIe‑сборок
Рынок GPU расширяется. AMD продолжает агрессивно наступать на пятки лидеру рынка, делая ставку на то, что больше всего нужно современным LLM — на объем и скорость памяти. Их новый туз в рукаве в формате привычного pci-устройства метит прямиком в корпоративный сегмент.
AMD показала Instinct MI350P — ускоритель для инференса и RAG‑пайплайнов, который умещается в стандартный PCIe‑слот, но при этом уже сейчас считается самым быстрым PCIe‑карточным решением в сегменте enterprise‑инференса.
У карты 128 compute units, 8 192 обычных и 512 матричных ядер, а также 144 ГБ памяти HBM3E с пропускной способностью 4 ТБ/с. По теоретической производительности в FP16 и FP8 она примерно на 40% обходит текущий флагман NVIDIA — H200 NVL.
MI350P базируется на архитектуре CDNA4 и техпроцессе 3/6 нм от TSMC. Максимальная частота — около 2,2 ГГц, на борту 128 МБ кэша последнего уровня (LLC). Карта двухслотовая, длиной 10,5 дюймов. Потребление составляет 600 Вт, но его можно «задушить» до 450 Вт для серверов с жесткими лимитами по теплу. В FP64 новинка на 20% быстрее H200 NVL, а в FP16 и FP8 отрыв составляет 43% и 39%. Отличный вариант для инференса и работы с большими векторными контекстами на стандартном воздушном охлаждении.
Карта поддерживает форматы MXFP6 и MXFP4 — это позволяет эффективно сжимать веса моделей без серьезной потери точности. AMD заявляет поддержку до восьми MI350P в рамках одного сервера. Это дает реальную возможность масштабировать инференс-нагрузку без необходимости сразу переходить на full‑rack решения.
Важно, что NVIDIA до сих пор не выпустила PCIe-версию чипа Blackwell (B200). Поэтому MI350P сейчас фактически остается самым мощным PCIe-ускорителем на рынке — если вынести за скобки доминирование экосистемы CUDA и то, насколько быстро платформа ROCm сможет привлечь разработчиков под себя.
Появление карт со 144 ГБ быстрой памяти HBM3E позволит локально крутить тяжелые модели с огромным контекстом на уже существующей инфраструктуре. Однако, когда вам будет мало одного сервера и понадобятся уже десятки и сотни таких прожорливых PCIe-плат, на первый план выходит софт для контроля за их утилизацией и стабильностью. И у «зеленых» как раз готов масштабный ответ на эту проблему.
NVIDIA Fleet Intelligence: мониторинг и оптимизация парка GPU в реальном времени
На майских NVIDIA представила Fleet Intelligence — агент‑сервис для мониторинга и оптимизации крупных GPU‑ландшафтов, который изначально выглядел как «еще один модуль в NGC», но на деле закрывает вполне ощутимую боль системных инженеров: отсутствие единой, низкоуровневой видимости по десяткам и сотням ускорителей в разнородной инфраструктуре.
Вместо того чтобы довольствоваться выводом nvidia-smi и логами, в которых каждый node живет отдельно, Fleet Intelligence забирает метрики напрямую с хостов, склеивает их в облаке и выдает единые панели по состоянию всего парка, включая питание, температуру, производительность, health GPU/CPU и целостность конфигурации.
Сервис работает через легкий агент, который разворачивается на GPU‑нодах через пакетный менеджер или Helm, и опирается на DCGM, GPUd и собственный Attestation SDK, то есть фактически использует уже знакомые инструменты, но в упаковке «managed service».
В дашборде можно увидеть не только суммарную загрузку GPU и памяти, но и разбивку по зонам, выделение аномалий по температуре, питанию, ошибкам ECC и XID, а также отдельные health‑чеки, которые выявляют девиации, пока они не превратились в сбои. Важно, что агент читает метрики, но не меняет настройки, а сам код выложен в открытом репозитории, что снижает барьер для интеграции в строгих enterprise‑окружениях.
Отдельная часть функциональности отдана контролю целостности и аттестации: через технологии NVIDIA Confidential Computing и Attestation SDK сервис проверяет, что в каждом GPU установлен корректный образ прошивки, и не был ли узел как‑то подменен или допущен физический несанкционированный доступ. Измерения с GPU подписываются с помощью root of trust, уходят в NRAS‑сервис, где сверяются с эталонными RIM‑манифестами, а в итоге в дашборде отображается проверка целостности всего парка — это уже не просто «какой‑то чип где‑то перегрелся», а управляемая модель доверия к инфраструктуре под LLM‑ и агентные нагрузки.
Такой уровень контроля очень хорошо вписывается в картину последних месяцев: в то время как Cerebras и AMD делают акцент на том, как ускорить один запрос или как упаковать сотни гигабайт памяти в PCIe‑формфактор, NVIDIA, по сути, отвечает на вопрос, как удержать этот рост в контроле и не превратить мощный парк ускорителей в «черный ящик» с пропадающими SLA и непонятными тич‑временами.
NVIDIA планомерно строит вокруг своего железа «софтверную» экосистему. Это логично, ведь под задачи Agentic AI и тяжелых LLM мощностей требуется все больше. Если вы как раз уперлись в потолок текущего поколения GPU и ищете, где развернуть масштабный инференс, то есть решение.
NVIDIA® HGX™ B300: железо для агентских систем
До недавнего времени для тяжелых LLM и крупномасштабных агентских систем в дата‑центрах в основном использовали ускорители на базе Hopper и предыдущих поколений, где квантование в FP8 и вовсе оставалось на уровне софта и «гиковских» решений.
Появление платформы NVIDIA® HGX™ B300 с архитектурой Blackwell меняет эту картину: благодаря аппаратной поддержке формата NVFP4 и рекордному объему памяти в 2,3 ТБ на ноду, она позволяет запускать модели на сотни миллиардов параметров в рамках одного сервера, кратно снижая задержки и стоимость инференса. Это уже одно из первых решений, которое рассматривают как естественную платформу для крупномасштабных агентских систем и тяжелых LLM, где нужны как распределенное обучение, так и высокоскоростной инференс.
Суммарно в системе 2,3 ТБ VRAM, которые выдают пиковую производительность до 192 петафлопс.Такие вычислительные показатели достигаются за счет аппаратной поддержки стандарта NVFP4. Помимо привычного для ML-инженеров формата BF16, обеспечивающего 16-битную точность для дообучения и последующей квантизации, и компактного 8-битного FP8, архитектура Blackwell позволяет агрессивно сжимать веса моделей без критической потери качества.
Показательный пример — архитектура семейства DeepSeek. Их параметры преимущественно переведены в FP8, и только критически важные элементы (например, скрытые состояния или механизмы внимания в некоторых слоях) оставлены в BF16.
Новый стандарт NVFP4 идет еще дальше и предназначен для 4-битной квантизации. По заявлениям NVIDIA, падение качества инференса при этом составляет менее 1% относительно FP8, в то время как физический размер модели сокращается почти вдвое. При столь экстремальном сжатии точность сохраняется за счет блочного хранения данных.
NVFP4 опирается на встроенные масштабные коэффициенты и базовые переменные, что позволяет прямо в процессе вычислений восстанавливать содержимое блока весов до точности FP8. Концептуально идея не нова: открытые форматы MXFP и GGUF устроены похожим образом, однако в чипах Blackwell эта логика впервые зашита на аппаратном уровне. Прирост эффективности здесь линейный: перевод модели из BF16 в FP8 ускоряет инференс почти в два раза, а внедрение NVFP4 дает буст еще в 1,8 раза по отношению к FP8.
На практике такие конфигурации уже доступны в виде выделенного сервера, например линейка серверов Selectel пополнилась новой конфигурацией GL8-B300-HGX-25GE, спроектированной специально под сверхтребовательные ИИ‑задачи. Если собирать собственный кластер из B300 или AMD пока избыточно, а контролировать бюджет и API нужно уже сейчас, можно воспользоваться выделенным инстансом GenAI‑моделей с почасовой оплатой за пару кликов или запросов в API в Selectel Foundation Models Catalog.
Теория хороша на бумаге, а на практике инженерам нужны твердые независимые бенчмарки на реальных сценариях. И ответ на этот вопрос дает масштабное обновление главного мирового табеля о рангах, который в этом месяце полностью переписали под новые реалии распределенных вычислений.
MLPerf Training v6.0: в бенчмарки попали DeepSeek‑V3 и GPT‑OSS 20B
Железо меняется не просто так: индустрия почти полностью ушла от монолитных моделей к архитектурам со смесью экспертов. Естественно, мериться производительностью кластеров по старым правилам больше не получается. Чтобы дать инженерам честные ориентиры для тестирования распределенного обучения, консорциум MLCommons полностью обновил методологию своих тестов.
Организация MLCommons официально запустила MLPerf Training v6.0, в котором впервые появляются стандартные бенчмарки для распределенного обучения моделей со смесью экспертов, а не только для плотных архитектур. В качестве новых открытых стандартов фигурируют два LLM‑бенчмарка: DeepSeek‑V3 с 671 млрд параметров, из которых 37 млрд активируются на токен, и более компактная GPT‑OSS 20B, тоже построенная по разреженной схеме MoE.
DeepSeek‑V3 в MLPerf задается как задача пред‑обучения LLM на корпусе C4 с длиной последовательности 4 096 токенов. Лимит глобального размера батча (Global Batch Size) задан на уровне от 15 360 последовательностей. Это явно ориентировано на продакшен-сценарии, а не на разовые синтетические тесты с малой нагрузкой.
Бенчмарк фиксирует главные отраслевые архитектурные тренды:
низкоранговое внимание (Multi-head Latent Attention, MLA);
мелкоблочную сегментацию экспертов (Fine-grained Experts);
балансировку нагрузки между экспертами без использования вспомогательной функции потерь (Auxiliary-loss-free Load Balancing).
Это делает его отличным прокси-тестом для инфраструктурных команд, которые оптимизируют кластеры под MoE-модели.
В то же время тест GPT-OSS 20B изначально задуман как более доступный бенчмарк. Его можно прогонять даже на одной ноде с 8 GPU, но при этом сохраняется строгое требование к сходимости модели на заданном уровне perplexity.
Но большинству компаний все еще выгоднее брать готовые модели с open-weight и быстро упаковывать их в агентские сценарии. Благо разработчики инфраструктуры это понимают и выкатывают под это дело специализированные инструменты, где во главу угла ставят скорость отклика.
Token Superposition Training: как ускорить предобучение LLM
Предобучение больших языковых моделей с нуля — самый дорогой этап в ML-инжиниринге. Метод Token Superposition Training (TST) от исследователей из Nous Research позволяет сократить реальное время обучения (wall-clock time) в 2–3 раза при фиксированных затратах вычислительной мощности (FLOPs). При этом подход не требует изменений в архитектуре модели, оптимизаторе, токенизаторе или датасете.
Весь цикл обучения делится на две фазы:
Суперпозиция (первые 20–40% этапа). Модель считывает пакеты из нескольких последовательных токенов, усредняет их эмбеддинги на входе и учится предсказывать сразу следующую группу токенов целиком через модифицированную кросс-энтропию.
Восстановление. Модель бесшовно возвращается к стандартному пошаговому предсказанию (next-token prediction).
Главный профит — экономия GPU-часов. На тесте MoE-конфигурации (Mixture of Experts) объемом 10 млрд параметров TST-метод потребовал всего 4 768 часов на ускорителях NVIDIA B200, тогда как классический подход при аналогичном качестве и бюджете FLOPs занял 12 311 часов. Экономия времени и бюджета на аренду инфраструктуры составила 2,5 раза.
Нюанс: метод агрессивнее расходует сами токены из датасета. Он идеален для сценариев, ограниченных мощностью железа (compute-bound), но не подойдет для проектов, где критически не хватает обучающих данных.
Adaptive Parallel Reasoning: как LLM сами управляют параллельными рассуждениями
Новейший тренд в оптимизации — научить модель разделять сложные задачи на параллельные потоки вычислений прямо в процессе генерации.
В детальном разборе парадигмы Adaptive Parallel Reasoning (APR) на BAIR‑блоге показали, как языковые модели начинают встраивать параллельный режим рассуждений прямо в свой control flow, а не полагаться на внешние обертки вроде self‑consistency, Best‑of‑N или Tree‑of‑Thoughts. Суть в следующем: модель учится сама решать, когда ей выгодно разбить задачу на несколько независимых потоков, сколько таких потоков запускать и как координировать их в зависимости от сложности запроса, вместо того чтобы всегда тянуть один длинный CoT‑поток.
Суть APR в том, что модель сама, прямо во время работы, решает, когда ей думать последовательно, а когда — запустить параллельные вычисления. Для этого не нужно менять архитектуру нейросети, пересобирать токенизатор или использовать внешние скрипты-обертки. Модель управляет процессом на лету с помощью специальных служебных токенов, которые активируют конструкции вроде spawn() и join().
Внутри них модель генерирует несколько независимых «витков» рассуждений через дочерние потоки, а затем собирает их в единый финальный вывод, не перегружая контекст одним сверхдлинным последовательным треком. В отличие от классических схем, где параллелизм задают заранее (например, 20 путей в Best‑of‑N или жесткая структура дерева), APR побуждает модель обучаться на практике, когда задача действительно выигрывает от параллельной разборки, а когда лучше оставить все в одном последовательном режиме, чтобы не тратить токены и вычисления впустую.
В разборке подробно расписаны разные реализации, включая Multiverse, ThreadWeaver, NPR и Parallel‑R1: они отличаются тем, как управлять KV‑кэшем, как вознаграждать параллелизм в RL‑обучении и насколько активно трогать сам инференс‑движок. В некоторых вариантах умело «сшивают» кэши разных потоков, чтобы избежать повторного префила, а в других полностью оставляют движок нетронутым, перекладывая координацию на клиентскую сторону за счет небольшого пересчета текста при финальной агрегации.
В этом свете APR становится не просто «модой» в рассуждениях, а элементом инфраструктурного стека, где тот же compute на том же железе начинает реально уменьшать wall‑clock‑задержку сложных задач, а не только улучшать точность в синтеческих бенчмарках.
SambaNova и Responses API для кодовых агентов
SambaNova анонсировала поддержку интерфейса Responses API для ключевых моделей в своем облаке. Это заметно упрощает интеграцию ИИ-агентов, позволяя им генерировать строго структурированный вывод сразу в удобном для кода формате, минуя свободный текст. Для разработчиков это означает отказ от ручной валидации JSON-схем, предсказуемую генерацию кода и возможность напрямую извлекать блоки кода, diff или аргументы CLI без использования хрупких парсеров и регулярных выражений.
Стоит отметить, что Responses API — это новая парадигма взаимодействия, изначально предложенная OpenAI для создания комплексных агентных систем (со встроенным веб-поиском, песочницами для запуска кода и поддержкой MCP). Интеграция этого стандарта со стороны SambaNova — сильный шаг, который позволяет разработчикам бесшовно мигрировать с инфраструктуры OpenAI на сверхбыстрые чипы RDU от SambaNova, не переписывая логику работы с эндпоинтами.
Как вам такие тренды? Полетит ли метод TST в реальном продакшене, или экономия на обучении разобьется о нехватку качественных датасетов? И готовы ли вы тестировать чипы RDU от SambaNova как альтернативу CUDA? Делитесь вашим мнением в комментариях.