Inspur создает инфраструктуру для агентов: 40 000 агентов на стойку и мультимодельная координация

Введение

Инфраструктура ИИ выходит за рамки эпохи обработки одного запроса модели за раз.

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

На конференции Open Compute Technology Summit 2026 в Пекине компания Inspur Information представила два направления инфраструктуры для нового типа рабочих нагрузок:

1. Серверы с нативным жидкостным охлаждением на базе CPU, спроектированные для поддержки более 40 000 одновременных агентов в одной стойке.
2. Сочетание суперузла MetaBrain SD200 с многомодельным API слияния EPAI, позволяющее нескольким большим моделям генерировать, проверять и комбинировать ответы для сложных задач.

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

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

Традиционный вывод больших моделей обычно следует простой схеме:

1. Пользователь отправляет запрос.
2. Модель выполняет вывод.
3. Система возвращает ответ.
4. Сеанс завершается или ожидает следующего запроса.

Путь выполнения приложения агента значительно длиннее.

Одна единственная бизнес-задача может включать:

• Планирование
• Декомпозицию задач
• Поиск
• Вызов инструментов
• Выполнение кода
• Проверку прав доступа
• Процессы в песочнице
• Многораундовый вывод
• Координацию подчинённых агентов
• Проверку результатов
• Агрегацию результатов
• Длительное управление состоянием

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

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

Это меняет баланс между ресурсами CPU и GPU.

GPU генерируют токены

GPU по-прежнему незаменимы на следующих этапах:

• Вывод больших моделей
• Предварительное заполнение и декодирование
• Генерация эмбеддингов
• Мультимодальная обработка
• Высокопропускное производство токенов
• Параллельное выполнение моделей

CPU управляют средой агентов

CPU обрабатывают большой объём периферийных задач:

• Планирование процессов агентов
• Вызов инструментов
• Управление контекстом и состоянием
• Взаимодействие с бизнес-системами
• Выполнение в песочнице
• Сетевые и дисковые операции
• Аутентификация и авторизация
• Координация рабочих процессов
• Подготовка результатов

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

Таким образом, инфраструктура агентов переходит от конструкции, ориентированной на GPU, к системам, где CPU, GPU, сеть, хранилища, охлаждение и оркестровка работают сообща.

Почему плотность CPU становится всё более важной

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

Развёртывание агентов меняет экономическую модель.

Если тысячам агентов требуются ресурсы CPU для оркестровки, вызова инструментов и изолированной среды выполнения, стойки с низкой плотностью CPU будут занимать больше площади машинного зала, требовать больше сетевых подключений и вспомогательной инфраструктуры.

В то же время центры обработки данных ИИ движутся к более высокой мощности на стойку.

По сообщениям источников, Inspur Information ожидает, что мощность отечественных ИИ-стоек приблизится к 300 киловаттам, в то время как некоторые глобальные конструкции уже приближаются к мегаваттным стоечным системам. Традиционное воздушное охлаждение обычно ограничено десятками киловатт на стойку и становится всё более затруднительным при такой плотности.

Таким образом, жидкостное охлаждение больше не является исключительной проблемой GPU.

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

Одна стойка может поддерживать более 40 000 агентов

Inspur представила то, что она называет первым в отрасли сервером с нативным жидкостным охлаждением на базе CPU в форм-факторе цельной стойки.

Система основана на архитектуре жидкостного охлаждения OCM 2.0 и поддерживает процессоры x86 и Arm.

Её основные характеристики:

Характеристика	Параметры согласно отчётам производителя
Максимальное количество CPU в одной стойке	384
Поддерживаемое количество одновременных агентов	Более 40 000
Архитектура процессоров	x86 и Arm
Область охлаждения	CPU, память, SSD, сетевые карты, оптические модули и другие нагревающиеся компоненты
Плотность вычислений	4 CPU в пространстве 0,5U
Способ обслуживания	Полный жизненный цикл обслуживания жидкостного охлаждения
Целевые сценарии	Центры обработки данных ИИ высокой плотности и гигаваттного класса

Система не рассматривает жидкостное охлаждение как дополнительный компонент, устанавливаемый после завершения проектирования сервера.

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

Расширение охлаждения от холодной пластины CPU до всех компонентов

Традиционные серверы с холодной пластиной

Они могут напрямую охлаждать процессор, но память, сеть, хранилище, компоненты питания и другие устройства по-прежнему зависят от вентиляторов для отвода тепла.

С ростом плотности этот подход становится всё менее эффективным.

Нативная архитектура жидкостного охлаждения Inspur включает основные нагревающиеся компоненты в единую систему охлаждения:

• CPU
• Память
• Сетевые карты
• Оптические модули
• Твердотельные накопители
• Коммуникационные компоненты

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

Ниже расположены три синие иконки: «Архитектура жидкостного охлаждения», «Подключение жидкостного охлаждения», «Обслуживание жидкостного охлаждения». Это изображение тесно связано с контекстом и наглядно демонстрирует серверы 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 важен

OCM — это аббревиатура от Open Compute Module.

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

Для предприятий и операторов центров обработки данных это решение даёт следующие преимущества:

• Больше выбора оборудования
• Более простая модернизация платформы
• Снижение объёма повторной проектной работы
• Лучшая совместимость с архитектурами x86 и Arm
• Увеличение срока службы инфраструктуры стойки

Реальная эффективность зависит от экологической совместимости, взаимной интеграции и доступности сопутствующих компонентов.

Масштаб не равен интеллекту

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

У больших языковых моделей есть свои сильные стороны.

Некоторые модели могут быть более эффективны в:

• Логических рассуждениях
• Написании кода
• Анализе длинных текстов
• Технических исследованиях
• Естественном письме
• Структурированном извлечении
• Многоязычных задачах

Даже сверхбольшие модели имеют пробелы в возможностях.

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

Поэтому второе инфраструктурное направление Inspur сосредоточено на многомодельном взаимодействии.

Многомодельная обработка одной задачи

Интеграционный API многомодельного слияния EPAI параллельно распределяет сложные задачи между несколькими моделями-кандидатами.

Каждая модель независимо генерирует ответ. Отдельная модель проверки и слияния сравнивает ответы-кандидаты, выявляя:

• Общие выводы
• Противоречивые суждения
• Пропущенную информацию
• Уникальные идеи

Неподдерживаемые заявления:

• Области, требующие координации

Затем платформа формирует сводный ответ.

Это не простое голосование большинством и не прямое объединение всех ответов. Ожидаемый рабочий процесс выглядит так:

1. Генерация кандидатов
2. Межмодельная проверка
3. Анализ расхождений и пропусков
4. Слияние в итоговый вывод

Согласно отчёту Inspur, система достигла 53,9% в оценке DRACO, превзойдя каждую отдельную модель в пуле кандидатов, использованном в этом тесте.

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

Простые задачи по-прежнему выполняются одной моделью

Если для каждого запроса запускать несколько моделей, это неоправданно увеличит затраты и задержку.

Поэтому EPAI различает короткие предсказуемые задачи и сложные задачи.

Задачи, подходящие для одной модели

Лёгкая модель может справиться с:

• Простыми вопросами и ответами
• Преобразованием форматов
• Базовым извлечением
• Задачами классификации
• Короткими вызовами инструментов
• Обычным преобразованием контента

Задачи, более подходящие для многомодельного слияния

Несколько моделей могут быть полезны для:

• Глубоких исследований
• Технических сравнений
• Анализа архитектуры
• Сложного планирования
• Рассуждений на длинных текстах
• Высокоответственных проверок
• Задач с неясными доказательствами
• Вывода, требующего независимой верификации

Этот принцип маршрутизации критически важен для производственных систем.

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

Рабочий процесс многомодельного слияния EPAI

API EPAI предназначен для скрытия многомодельной оркестровки за единым интерфейсом.

Разработчик отправляет запрос на платформу. EPAI управляет:

• Выбором моделей-кандидатов
• Параллельным распределением задач
• Сбором ответов
• Выполнением модели оценки
• Анализом расхождений
• Формированием итогового ответа

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

Эта архитектура подходит для предприятий, использующих смесь следующих моделей:

• Модели с открытым исходным кодом
• Проприетарные модели
• Универсальные модели
• Предметно-ориентированные модели
• Локально развёрнутые модели
• Облачные API-модели

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

MetaBrain SD200 обеспечивает механизм токенов

Суперузел MetaBrain SD200 — это аппаратная платформа, поддерживающая рабочий процесс многомодельного слияния.

Система использует многоведомую архитектуру с низколатентной связью через семантическую память. По данным Inspur, она может объединить 64 отечественных ускорителя GPU в единой системе.

Её конструкция включает:

• Открытую вычислительную архитектуру OCM и OAM
• 3D Mesh-соединение
• Единую адресацию ускорителей
• Высокоскоростную пиринговую связь
• Большую общую память

Возможности

• Поддержка нескольких моделей с триллионами параметров
• Оптимизация программно-аппаратного комплекса

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

В тестах Inspur время генерации токена достигло 4,77 мс

Inspur сообщает, что SD200 сократил время генерации одного токена для модели Kimi K2.6 с триллионом параметров до 4,77 миллисекунды.

Компания также сообщает о снижении задержки первого токена на 35% по сравнению с предыдущими реализациями.

Эти данные относятся к конкретным условиям оптимизации и тестирования и не должны интерпретироваться как гарантированная задержка для каждой модели, развёртывания, длины подсказки, уровня параллелизма или производственной нагрузки.

Эти улучшения обусловлены несколькими технологиями.

Многотокенное предсказание

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

Многотокенное предсказание пытается сгенерировать несколько токенов-кандидатов за один шаг и проверить их вместе.

При высокой точности предсказания это может сократить количество циклов последовательного декодирования.

Квантование W4A8

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

По сравнению с вычислениями BF16 это позволяет уменьшить:

• Нагрузку на пропускную способность памяти
• Использование памяти ускорителя
• Вычислительные требования
• Стоимость вывода на один токен

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

Компиляция ядер на лету (JIT)

JIT-компиляция во время выполнения генерирует специализированные ядра ускорителя на основе формы тензора, макета и типа данных.

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

Разделение предварительного заполнения и декодирования

Предварительное заполнение подсказок и декодирование токенов имеют разные характеристики производительности.

Разделение двух фаз позволяет дифференцированно распределять ресурсы и асинхронно передавать KV-кэш, снижая конкуренцию между вычислениями и связью.

Совместимость моделей

Inspur заявляет, что SD200 прошёл оптимизацию производительности для нескольких популярных моделей с открытым исходным кодом, включая:

• Kimi K2.6
• DeepSeek V4
• GLM 5.2
• MiniMax M3

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

Архитектура модели, количество параметров, конструкция MoE, длина контекста, квантизация, пакетная обработка и серверное программное обеспечение — все это влияет на производительность.

Корпоративная версия снижает порог внедрения

Суперузел с 64 ускорителями подходит для крупных инфраструктурных проектов ИИ, но для многих предприятий он слишком велик и дорог.

Компания Inspur также выпустила корпоративную версию Yuanbrain SD200 Enterprise.

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

Заявленные характеристики включают:

• Единый домен межсоединения для 16 ускорителей
• Нативная связь с семантикой памяти
• Единая адресация
• Терабайтная единая память ускорителей
• Улучшение времени генерации первого токена для вывода моделей с триллионом параметров более чем на 40%
• Локальная поддержка ведущих открытых моделей с триллионом параметров
• Стоимость миграции и адаптации ниже, чем для полной системы SD200

Данная корпоративная версия в первую очередь предназначена для следующих нагрузок:

• Понимание длинных документов
• Сложные логические рассуждения
• Развертывание частных моделей
• Многоагентное сотрудничество
• Внутренние исследования
• Конфиденциальные бизнес-приложения

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

Стек инфраструктуры становится более интегрированным

Продукты, представленные на OCTS 2026, демонстрируют трехуровневую архитектуру.

Уровень	Основные обязанности
Программная платформа	Подключение моделей, маршрутизация задач, оркестровка, разрешения, оценка и объединение результатов
Инфраструктура CPU	Агентские процессы, вызовы инструментов, выполнение в песочнице, управление контекстом и взаимодействие с бизнес-системами
Суперузел GPU	Вывод больших моделей, высокопроизводительная генерация токенов и выполнение нескольких моделей

Система может работать нормально только при согласованной работе всех трех уровней.

Быстрый кластер GPU не может компенсировать слабую агентскую диспетчеризацию. Высокоплотная стойка CPU не улучшит качество вывода, если у нее нет доступа к мощной модели. Сложный API объединения не обеспечит приемлемую задержку, если базовую модель невозможно эффективно загрузить или подключить.

Это основное изменение в конкуренции за агентскую инфраструктуру.

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

• Сколько агентских процессов может оставаться онлайн?
• Насколько быстро они могут вызывать модели и инструменты?
• Можно ли запускать несколько моделей одновременно?
• Как распределяется или изолируется память?
• Как применяются разрешения?
• Может ли платформа выполнять различную маршрутизацию для простых и сложных задач?
• Остается ли система стабильной при высокой нагрузке и параллелизме?
• Насколько эффективно она генерирует полезные токены?

Что предприятиям следует оценить перед развертыванием

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

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

1. Агентский параллелизм

Учитывать нужно не только активных пользователей, но и:

• Под-агенты для каждой задачи
• Процессы инструментов
• Песочницы
• Фоновые задания
• Постоянные сессии
• Пиковые всплески
• Процессы восстановления после сбоев

2. Ресурсы CPU и памяти на каждого агента

Легковесный поисковый агент и кодировщик с отдельной средой разработки имеют принципиально разные профили потребностей в ресурсах.

Метрика «количество агентов на стойку» должна быть сопоставлена с фактическими потребностями в памяти, CPU, хранилище и сети для целевого приложения.

3. Задержки модели

Необходимо измерить:

• Время генерации первого токена
• Задержку между токенами
• Сквозное время выполнения задачи
• Задержку в очереди
• Задержку вызова инструмента
• Задержки в сценариях с параллелизмом

Низкое время генерации токенов в тестах не гарантирует низкой задержки сквозного рабочего процесса.

4. Экономичность нескольких моделей

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

Командам следует сравнивать:

• Точность одной модели
• Точность объединенной модели
• Количество потребленных токенов
• Утилизацию GPU
• Время отклика
• Стоимость проверки моделей
• Частоту отказов
• Снижение объема ручной проверки

5. Охлаждение и совместимость с объектами

Стойки с нативным жидкостным охлаждением требуют соответствующей инфраструктуры объекта.

Необходимо проверить:

• Блоки распределения хладагента
• Температуру подачи и обратки
• Требования к давлению и расходу
• Обнаружение утечек
• Процедуры обслуживания
• Схемы утилизации тепла
• Энергоснабжение стойки
• Допустимую нагрузку на пол дата-центра

6. Переносимость моделей и ускорителей

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

Необходимо проверить:

• Фреймворки моделей
• Движки вывода
• Поддержку квантизации
• Доступность ядер
• Зрелость драйверов
• Инструменты мониторинга
• Замену ускорителей
• Процедуры обновления

7. Надежность и управление

Долгоживущие агенты требуют жесткого контроля в отношении:

• Аутентификации
• Настройки разрешений
• Управления ключами
• Сетевого доступа
• Среды песочницы
• Журналов аудита
• Ограничения скорости
• Утверждения со стороны человека
• Маршрутизации моделей
• Хранения данных

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

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

Что такое стойка CPU-агентов Inspur с нативным жидкостным охлаждением?

Это полностоечный CPU-сервер, спроектированный вокруг системы охлаждения, а не добавление жидкостного охлаждения к традиционной конструкции с воздушным охлаждением. Inspur заявляет, что он может вмещать до 384 CPU и поддерживать более 40 000 одновременно работающих агентов.

Может ли одна стойка действительно запускать 40 000 ИИ-агентов?

Это число является максимальным, указанным в отчетах партнера по эталонной архитектуре Inspur. Фактическая емкость зависит от ресурсов CPU, памяти, хранилища, сети и изоляции песочницы, необходимых для каждого агента.

Почему ИИ-агентам требуется так много CPU?

Языковые модели могут работать на GPU, но агентам также нужны CPU для диспетчеризации, выполнения инструментов, управления состоянием, доступа к бизнес-системам, проверок безопасности и изолированных сред выполнения. Длительные и многоагентские рабочие процессы еще больше увеличивают эту потребность в CPU.

Что такое OCM 2.0?

OCM — это архитектура открытого вычислительного модуля, предназначенная для отделения вычислительных модулей от более широкой конструкции стойки. Система Inspur с жидкостным охлаждением OCM 2.0 поддерживает несколько архитектур CPU и жидкостное охлаждение всех компонентов.

Что такое MetaBrain SD200?

MetaBrain SD200 — это AI-суперузел от Inspur, предназначенный для вывода больших моделей и многомодельных нагрузок. Он использует архитектуру масштабирования с 64 ускорителями, поддерживающую единую адресацию и высокоскоростное межсоединение.

Что такое EPAI Multi-Model Fusion API?

Это API, которое отправляет задачу нескольким моделям-кандидатам, собирает их независимые ответы и использует модели проверки и объединения для выявления консенсуса, разногласий, пропусков и уникальных идей перед генерацией окончательного ответа.

Всегда ли многомодельное объединение превосходит одну модель?

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

В чем разница между SD200 и корпоративной версией SD200?

Полная версия SD200 использует домен масштабирования с 64 ускорителями для обработки сверхбольших нагрузок, а корпоративная версия SD200 сокращает домен до 16 ускорителей для предприятий, которым необходимо развертывать локальные модели с триллионом параметров с более низкими инфраструктурными требованиями.

Связанные инструменты

• Inspur EPA Корпоративная AI-платформа: поддерживает управление моделями, разработку приложений, поиск, развертывание и многомодельные рабочие процессы.
• Решения жидкостного охлаждения Inspur: Инфраструктурные решения для развертывания серверов с жидкостным охлаждением CPU/GPU.
• Open Compute Project: Индустриальное сообщество, разрабатывающее открытые аппаратные проекты для серверов, стоек, источников питания, охлаждения и дата-центров.
• Kimi: Ассистент и модельная платформа от Moonshot AI, результаты оптимизации которой цитируются в Inspur SD200.

DeepSeek — поставщик моделей ИИ, чья открытая модель включена в список совместимости SD200.

Связанные ссылки

• Анонс инфраструктуры агентов Inspur: официальный релиз, охватывающий жидкостное охлаждение CPU-стоек, SD200 и корпоративные суперузлы.
• Отчёт о производительности MetaBrain SD200 с задержкой 4,77 мс: технический обзор оптимизации SD200 и результатов генерации токенов от Inspur.
• API мультимодельного слияния EPA: официальное описание механизмов кандидатной генерации, проверки, слияния и оценки DRACO.
• Страница продукта Inspur EPA: информация о корпоративной платформе разработки крупных моделей.
• Решение Inspur для центров обработки данных с жидкостным охлаждением: официальная информация о решениях для дата-центров с жидкостным охлаждением.
• Саммит по технологиям открытых вычислений 2026: страница мероприятия OCTS 2026 и сопутствующие анонсы в области открытых вычислений.
• Фонд проектов открытых вычислений: официальная информация о стандартах открытой инфраструктуры и сообществе проектов.

Итог

Анонс Inspur на OCTS 2026 решает две ключевые проблемы, вызванные корпоративными агентами.

CPU-стойки с нативным жидкостным охлаждением ориентированы на масштабируемость, обеспечивая интенсивную среду для планирования агентов, инструментов, песочниц, управления контекстом и выполнения длительных процессов. SD200 и мультимодельный конвейер слияния EPA ориентированы на интеллектуальность, позволяя множеству крупных моделей совместно обрабатывать сложные задачи, а проверочная модель объединяет выходные результаты.

Более широкий вывод: инфраструктуру агентов нельзя сводить к одному более быстрому ускорителю. Продукционным системам требуется координация

CPU, GPU, памяти, межсоединений, охлаждения, оркестрации, прав доступа и оценки.

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