Инфраструктура ИИ выходит за рамки эпохи обслуживания одного запроса модели за раз. Промышленный агент не только принимает подсказку и возвр...
Инфраструктура ИИ выходит за рамки эпохи обработки одного запроса модели за раз.
Промышленный агент производственного уровня не просто принимает запрос и возвращает ответ. Он может разбивать задачи на несколько этапов, вызывать внешние инструменты, поддерживать контекст, координировать действия с подчинёнными агентами, проверять промежуточные результаты и оставаться активным в течение длительного времени. Когда предприятия развёртывают тысячи таких агентов одновременно, требования к инфраструктуре кардинально отличаются от обычного вывода сообщений чат-бота.
На конференции Open Compute Technology Summit 2026 в Пекине компания Inspur Information представила два направления инфраструктуры для нового типа рабочих нагрузок:
Первое направление ориентировано на масштаб: обеспечение работоспособности большого количества долгоживущих агентов. Второе направление ориентировано на качество: возможность совместной работы нескольких моделей с различными преимуществами вместо того, чтобы заставлять одну модель обрабатывать каждую часть сложной задачи.
Традиционный вывод больших моделей обычно следует простой схеме:
Путь выполнения приложения агента значительно длиннее.
Одна единственная бизнес-задача может включать:
Таким образом, инфраструктура должна поддерживать не только вывод модели, но и большое количество долговременно выполняемых программных процессов.
В корпоративной среде количество активных агентов может возрасти от десятков до тысяч и даже десятков тысяч. Некоторые агенты могут работать постоянно, в то время как другие динамически создаются для коротких задач и уничтожаются после завершения.
Это меняет баланс между ресурсами CPU и GPU.
GPU по-прежнему незаменимы на следующих этапах:
CPU обрабатывают большой объём периферийных задач:
Модель может отвечать за генерацию вывода или текста, но CPU обычно управляют операционной средой выполнения агентов.
Таким образом, инфраструктура агентов переходит от конструкции, ориентированной на GPU, к системам, где CPU, GPU, сеть, хранилища, охлаждение и оркестровка работают сообща.
В обычных корпоративных серверах плотность CPU исторически была ограничена энергопотреблением, охлаждением, пространством, кабелями, вентиляторами и требованиями к обслуживанию.
Развёртывание агентов меняет экономическую модель.
Если тысячам агентов требуются ресурсы CPU для оркестровки, вызова инструментов и изолированной среды выполнения, стойки с низкой плотностью CPU будут занимать больше площади машинного зала, требовать больше сетевых подключений и вспомогательной инфраструктуры.
В то же время центры обработки данных ИИ движутся к более высокой мощности на стойку.
По сообщениям источников, Inspur Information ожидает, что мощность отечественных ИИ-стоек приблизится к 300 киловаттам, в то время как некоторые глобальные конструкции уже приближаются к мегаваттным стоечным системам. Традиционное воздушное охлаждение обычно ограничено десятками киловатт на стойку и становится всё более затруднительным при такой плотности.
Таким образом, жидкостное охлаждение больше не является исключительной проблемой GPU.
Стойки с CPU, поддерживающие рабочие нагрузки агентов, также должны соответствовать архитектуре мощности и охлаждения центров обработки данных ИИ следующего поколения.
Inspur представила то, что она называет первым в отрасли сервером с нативным жидкостным охлаждением на базе CPU в форм-факторе цельной стойки.
Система основана на архитектуре жидкостного охлаждения OCM 2.0 и поддерживает процессоры x86 и Arm.
Её основные характеристики:
| Характеристика | Параметры согласно отчётам производителя |
|---|---|
| Максимальное количество CPU в одной стойке | 384 |
| Поддерживаемое количество одновременных агентов | Более 40 000 |
| Архитектура процессоров | x86 и Arm |
| Область охлаждения | CPU, память, SSD, сетевые карты, оптические модули и другие нагревающиеся компоненты |
| Плотность вычислений | 4 CPU в пространстве 0,5U |
| Способ обслуживания | Полный жизненный цикл обслуживания жидкостного охлаждения |
| Целевые сценарии | Центры обработки данных ИИ высокой плотности и гигаваттного класса |
Система не рассматривает жидкостное охлаждение как дополнительный компонент, устанавливаемый после завершения проектирования сервера.
Напротив, компоновка вычислений и архитектура охлаждения разрабатываются совместно.
Традиционные серверы с холодной пластиной
Они могут напрямую охлаждать процессор, но память, сеть, хранилище, компоненты питания и другие устройства по-прежнему зависят от вентиляторов для отвода тепла.
С ростом плотности этот подход становится всё менее эффективным.
Нативная архитектура жидкостного охлаждения Inspur включает основные нагревающиеся компоненты в единую систему охлаждения:
Это уменьшает зависимость от внутреннего воздушного потока, что позволяет более компактно размещать компоненты.
Ниже расположены три синие иконки: «Архитектура жидкостного охлаждения», «Подключение жидкостного охлаждения», «Обслуживание жидкостного охлаждения». Это изображение тесно связано с контекстом и наглядно демонстрирует серверы Inspur с архитектурой жидкостного охлаждения, что согласуется с описанной в документе архитектурой жидкостного охлаждения.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/44c90e20-2048-4f43-8d1d-8516006843e0-d14e80b4-e2a0-4468-a7b6-77e5229ab1ca.png)
В отчёте описывается компактный вычислительный модуль, объединяющий несколько групп процессоров и периферийных компонентов в тонком и лёгком корпусе.
Цель конструкции — вернуть пространство, ранее занятое следующими компонентами:
Плоская компоновка компонентов позволяет одной большой холодной пластине покрыть больше системных зон.
Стойка использует бескабельную или малокабельную внутреннюю конструкцию, поддерживающую обслуживание без остановки. Компания Inspur заявляет, что это повышает эффективность развёртывания и обслуживания всей стойки.
OCM — это аббревиатура от Open Compute Module.
Модульная архитектура направлена на отделение процессорного модуля от общей конструкции системы. Такое решение упрощает поддержку процессоров разных поколений или архитектур без необходимости перепроектировать всю стойку для каждого процессора.
Для предприятий и операторов центров обработки данных это решение даёт следующие преимущества:
Реальная эффективность зависит от экологической совместимости, взаимной интеграции и доступности сопутствующих компонентов.
Запуск десятков тысяч интеллектуальных агентов решает проблемы ёмкости, но не автоматически повышает качество ответов.
У больших языковых моделей есть свои сильные стороны.
Некоторые модели могут быть более эффективны в:
Даже сверхбольшие модели имеют пробелы в возможностях.
При выполнении сложных задач одна модель может упустить ключевые вопросы, которые обнаружит другая. Одна модель может уверенно дать ответ, не раскрывая неопределённость и не рассматривая альтернативные интерпретации.
Поэтому второе инфраструктурное направление Inspur сосредоточено на многомодельном взаимодействии.
Интеграционный API многомодельного слияния EPAI параллельно распределяет сложные задачи между несколькими моделями-кандидатами.
Каждая модель независимо генерирует ответ. Отдельная модель проверки и слияния сравнивает ответы-кандидаты, выявляя:
Неподдерживаемые заявления:
Затем платформа формирует сводный ответ.
Это не простое голосование большинством и не прямое объединение всех ответов. Ожидаемый рабочий процесс выглядит так:
Согласно отчёту Inspur, система достигла 53,9% в оценке DRACO, превзойдя каждую отдельную модель в пуле кандидатов, использованном в этом тесте.
Этот результат следует рассматривать как базовый показатель платформы, а не как утверждение, что слияние моделей всегда превосходит лучшую отдельную модель. Производительность будет зависеть от моделей-кандидатов, моделей оценки, логики маршрутизации, типа задачи, подсказок и методов оценки.
Если для каждого запроса запускать несколько моделей, это неоправданно увеличит затраты и задержку.
Поэтому EPAI различает короткие предсказуемые задачи и сложные задачи.
Лёгкая модель может справиться с:
Несколько моделей могут быть полезны для:
Этот принцип маршрутизации критически важен для производственных систем.
Многомодельное взаимодействие наиболее ценно, когда потенциальное улучшение качества оправдывает дополнительные затраты на токены, время GPU и задержку ответа.
API EPAI предназначен для скрытия многомодельной оркестровки за единым интерфейсом.
Разработчик отправляет запрос на платформу. EPAI управляет:
Тот же интерфейс может быть интегрирован в приложения агентов и среды разработки без необходимости каждой команде строить собственную систему маршрутизации и оценки моделей.
Эта архитектура подходит для предприятий, использующих смесь следующих моделей:
Основная эксплуатационная проблема заключается в том, что несколько больших моделей могут одновременно требовать доступности. Это предъявляет повышенные требования к памяти ускорителей, пропускной способности межсоединений, планированию и низколатентной связи.
Опишите идею одной фразой, и We0 AI создаст сайт-витрину, страницы и CMS, а после запуска поможет привлечь клиентов и трафик.
Одна полная генерация проекта для бесплатной регистрации
Лучше всего попробовать один полный поток генерации и быстро увидеть первый черновик проекта.
Суперузел MetaBrain SD200 — это аппаратная платформа, поддерживающая рабочий процесс многомодельного слияния.
Система использует многоведомую архитектуру с низколатентной связью через семантическую память. По данным Inspur, она может объединить 64 отечественных ускорителя GPU в единой системе.
Её конструкция включает:
Возможности
По заявлению, этот суперузел может поддерживать модели размером до четырёх триллионов параметров или несколько моделей с триллионами параметров, одновременно используемых приложениями агентов.
Inspur сообщает, что SD200 сократил время генерации одного токена для модели Kimi K2.6 с триллионом параметров до 4,77 миллисекунды.
Компания также сообщает о снижении задержки первого токена на 35% по сравнению с предыдущими реализациями.
Эти данные относятся к конкретным условиям оптимизации и тестирования и не должны интерпретироваться как гарантированная задержка для каждой модели, развёртывания, длины подсказки, уровня параллелизма или производственной нагрузки.
Эти улучшения обусловлены несколькими технологиями.
Авторегрессионные модели обычно генерируют один токен, проверяют новое состояние, а затем генерируют следующий.
Многотокенное предсказание пытается сгенерировать несколько токенов-кандидатов за один шаг и проверить их вместе.
При высокой точности предсказания это может сократить количество циклов последовательного декодирования.
Оптимизация использует весы INT4 и вычисления активаций INT8 в части нагрузки смешанной экспертной модели.
По сравнению с вычислениями BF16 это позволяет уменьшить:
Квантование может повлиять на качество модели, поэтому производственные команды должны оценивать точность на основе собственных нагрузок, а не только опираться на скорость.
JIT-компиляция во время выполнения генерирует специализированные ядра ускорителя на основе формы тензора, макета и типа данных.
По сравнению с универсальными статическими реализациями специализированные ядра могут уменьшить количество ненужных ветвлений и улучшить доступ к памяти.
Предварительное заполнение подсказок и декодирование токенов имеют разные характеристики производительности.
Разделение двух фаз позволяет дифференцированно распределять ресурсы и асинхронно передавать KV-кэш, снижая конкуренцию между вычислениями и связью.
Inspur заявляет, что SD200 прошёл оптимизацию производительности для нескольких популярных моделей с открытым исходным кодом, включая:
Совместимость не обязательно означает, что каждая модель достигнет одинаковой задержки или пропускной способности.
Архитектура модели, количество параметров, конструкция MoE, длина контекста, квантизация, пакетная обработка и серверное программное обеспечение — все это влияет на производительность.
Суперузел с 64 ускорителями подходит для крупных инфраструктурных проектов ИИ, но для многих предприятий он слишком велик и дорог.
Компания Inspur также выпустила корпоративную версию Yuanbrain SD200 Enterprise.
В корпоративной версии домен вертикального масштабирования сокращен с 64 до 16 ускорителей, что позволяет локально развертывать модели с триллионом параметров.
Заявленные характеристики включают:
Данная корпоративная версия в первую очередь предназначена для следующих нагрузок:
Она предоставляет организациям, которым требуется локальный контроль над моделью, но которые не могут обосновать необходимость суперузла с 64 ускорителями, более компактную точку входа.
Продукты, представленные на OCTS 2026, демонстрируют трехуровневую архитектуру.
| Уровень | Основные обязанности |
|---|---|
| Программная платформа | Подключение моделей, маршрутизация задач, оркестровка, разрешения, оценка и объединение результатов |
| Инфраструктура CPU | Агентские процессы, вызовы инструментов, выполнение в песочнице, управление контекстом и взаимодействие с бизнес-системами |
| Суперузел GPU | Вывод больших моделей, высокопроизводительная генерация токенов и выполнение нескольких моделей |
Система может работать нормально только при согласованной работе всех трех уровней.
Быстрый кластер GPU не может компенсировать слабую агентскую диспетчеризацию. Высокоплотная стойка CPU не улучшит качество вывода, если у нее нет доступа к мощной модели. Сложный API объединения не обеспечит приемлемую задержку, если базовую модель невозможно эффективно загрузить или подключить.
Это основное изменение в конкуренции за агентскую инфраструктуру.
На раннем рынке основное внимание уделялось тому, насколько хорошо один сервер поддерживает одну большую модель. Эра агентов сместила фокус на системную производительность:
Яркие цифры, предоставляемые вендорами, полезны, но недостаточны для выбора платформы агентской инфраструктуры.
Оценка в производственной среде должна измерять полную рабочую нагрузку.
Учитывать нужно не только активных пользователей, но и:
Легковесный поисковый агент и кодировщик с отдельной средой разработки имеют принципиально разные профили потребностей в ресурсах.
Метрика «количество агентов на стойку» должна быть сопоставлена с фактическими потребностями в памяти, CPU, хранилище и сети для целевого приложения.
Необходимо измерить:
Низкое время генерации токенов в тестах не гарантирует низкой задержки сквозного рабочего процесса.
Объединение нескольких моделей может повысить качество, но может привести к многократному увеличению стоимости вывода.
Командам следует сравнивать:
Стойки с нативным жидкостным охлаждением требуют соответствующей инфраструктуры объекта.
Необходимо проверить:
Открытые модульные стандарты могут повысить гибкость, но фактическая переносимость зависит от совместимости программного обеспечения.
Необходимо проверить:
Долгоживущие агенты требуют жесткого контроля в отношении:
Плотность инфраструктуры не должна достигаться за счет операционной изоляции.
Это полностоечный CPU-сервер, спроектированный вокруг системы охлаждения, а не добавление жидкостного охлаждения к традиционной конструкции с воздушным охлаждением. Inspur заявляет, что он может вмещать до 384 CPU и поддерживать более 40 000 одновременно работающих агентов.
Это число является максимальным, указанным в отчетах партнера по эталонной архитектуре Inspur. Фактическая емкость зависит от ресурсов CPU, памяти, хранилища, сети и изоляции песочницы, необходимых для каждого агента.
Языковые модели могут работать на GPU, но агентам также нужны CPU для диспетчеризации, выполнения инструментов, управления состоянием, доступа к бизнес-системам, проверок безопасности и изолированных сред выполнения. Длительные и многоагентские рабочие процессы еще больше увеличивают эту потребность в CPU.
OCM — это архитектура открытого вычислительного модуля, предназначенная для отделения вычислительных модулей от более широкой конструкции стойки. Система Inspur с жидкостным охлаждением OCM 2.0 поддерживает несколько архитектур CPU и жидкостное охлаждение всех компонентов.
MetaBrain SD200 — это AI-суперузел от Inspur, предназначенный для вывода больших моделей и многомодельных нагрузок. Он использует архитектуру масштабирования с 64 ускорителями, поддерживающую единую адресацию и высокоскоростное межсоединение.
Это API, которое отправляет задачу нескольким моделям-кандидатам, собирает их независимые ответы и использует модели проверки и объединения для выявления консенсуса, разногласий, пропусков и уникальных идей перед генерацией окончательного ответа.
Нет. Многомодельный подход может улучшить производительность на сложных задачах, но увеличивает потребление токенов, вычислительные затраты и задержку. Простые задачи предпочтительнее маршрутизировать на одну легковесную модель.
Полная версия SD200 использует домен масштабирования с 64 ускорителями для обработки сверхбольших нагрузок, а корпоративная версия SD200 сокращает домен до 16 ускорителей для предприятий, которым необходимо развертывать локальные модели с триллионом параметров с более низкими инфраструктурными требованиями.
DeepSeek — поставщик моделей ИИ, чья открытая модель включена в список совместимости SD200.
Анонс Inspur на OCTS 2026 решает две ключевые проблемы, вызванные корпоративными агентами.
CPU-стойки с нативным жидкостным охлаждением ориентированы на масштабируемость, обеспечивая интенсивную среду для планирования агентов, инструментов, песочниц, управления контекстом и выполнения длительных процессов. SD200 и мультимодельный конвейер слияния EPA ориентированы на интеллектуальность, позволяя множеству крупных моделей совместно обрабатывать сложные задачи, а проверочная модель объединяет выходные результаты.
Более широкий вывод: инфраструктуру агентов нельзя сводить к одному более быстрому ускорителю. Продукционным системам требуется координация
CPU, GPU, памяти, межсоединений, охлаждения, оркестрации, прав доступа и оценки.
Ключевой показатель качества инфраструктуры агентов смещается с производительности одной модели на способность всей системы эффективно диспетчеризировать тысячи агентов и стабильно выдавать надёжные результаты.
Начните с одной фразы и получите полноценный сайт за считанные минуты.
