Проверка: один GPU для 5G и ИИ

Источник

▶️ Один GPU на сеть и вычисления. Американские исследователи предложили планировщик, который позволяет запускать на одном GPU базовую станцию 5G и ИИ-модель. Сеть при этом не падает. Зачем это нужно? Мы как-то рассуждали на тему переиспользования простоя вычислительных мощностей на edge, в т.ч. тех, что расположены в современных сборках БС. Оператор ставит на сеть доступа серверы с GPU и считает на них радиочасть. Свободные ресурсы он отдает под ИИ, например под языковые модели или видеоаналитику рядом с абонентом. Железо окупается быстрее, а ИИ оказывается ближе к пользователю. Проблема в том, что радиочасть должна обработать каждый слот за несколько миллисекунд. Если не успеть, копятся повторные передачи, абоненты теряют синхронизацию, соты отключаются. Обычные способы деления GPU заставляют выбирать задачу, фиксированное деление рассчитывают на пиковую нагрузку, в результате ресурсы простаивают. Тонкая настройка требует правки кода каждого приложения. Перенастройка занимает больше 100 мс, и на это время расчеты уходят на CPU. Принцип работы планировщика строится на простом наблюдении. Нагрузка сети на GPU зависит от ее состояния: числа активных сот и абонентов, скорости вниз и вверх, схемы модуляции, числа радиоресурсов и MIMO-слоев. Все эти параметры известны до запуска расчета на GPU. Значит, потребность в ресурсах можно предсказать заранее. Если упростить подход, то работа сократится до трех шагов. Сначала модуль мониторинга читает метрики сети через стандартные интерфейсы. Задержка этого шага около 0,7 мкс. Затем небольшая нейросеть, ансамбль из четырех моделей, прогнозирует загрузку на следующий слот. Она берет не среднее значение, а 99,8 перцентиль, т.е. закладывает запас ради стабильности сети. Работает прогноз на обычном CPU и занимает 21-24 мкс. Наконец, модуль распределения переводит прогноз в маски доступа и выдает сети нужное число блоков. Остальные блоки получает ИИ. Шаг занимает около 0,5 мкс, а гранулярность деления составляет два вычислительных блока. Суммарная задержка меньше 27 мкс. Первое преимущество в том, что система прозрачна. Код станции и ИИ-приложений не меняется, поэтому на одном GPU могут работать разные модели. Второе преимущество в точности: ресурсы перераспределяются на каждом слоте, и ИИ получает все, что сеть не заняла. Третье в масштабируемости. Прогноз строится на суммарных метриках по всем сотам, поэтому модель обучили один раз и применяли при разном числе сот и разной нагрузке без переобучения. В эмуляции с 27 сотами нагрузка доходила до 138 абонентов вниз и 61 вверх. Планировщик сравнили с двумя статическими разделами из 132 блоков: 108 сети и 24 ИИ или 52 сети и 80 ИИ. Пропускная способность вверх почти не отличалась от раздела с приоритетом сети, а верхний перцентиль задержки остался ниже 3 мс. Время до первого действия робота, которым управляет модель, оказалось короче, чем при статическом приоритете сети. Раздел с приоритетом ИИ ухудшал и пропускную способность, и задержку, поэтому на практике он неприменим. Накладные расходы почти не росли с масштабом: при 8 сотах трафик составлял 5266 Мбит/с вниз, при 27 сотах 11483 Мбит/с, а задержка прогноза осталась около 22 мкс. ☎️ Телекоммуналка в Telegram | в MAX

Источник проверки

Shared URL: (не указан)

Shared text:

▶️ Один GPU на сеть и вычисления.

Американские исследователи предложили планировщик, который позволяет запускать на одном GPU базовую станцию 5G и ИИ-модель. Сеть при этом не падает.

Зачем это нужно? Мы как-то рассуждали на тему переиспользования простоя вычислительных мощностей на edge, в т.ч. тех, что расположены в современных сборках БС. Оператор ставит на сеть доступа серверы с GPU и считает на них радиочасть. Свободные ресурсы он отдает под ИИ, например под языковые модели или видеоаналитику рядом с абонентом. Железо окупается быстрее, а ИИ оказывается ближе к пользователю.

Проблема в том, что радиочасть должна обработать каждый слот за несколько миллисекунд. Если не успеть, копятся повторные передачи, абоненты теряют синхронизацию, соты отключаются. Обычные способы деления GPU заставляют выбирать задачу, фиксированное деление рассчитывают на пиковую нагрузку, в результате ресурсы простаивают. Тонкая настройка требует правки кода каждого приложения. Перенастройка занимает больше 100 мс, и на это время расчеты уходят на CPU.

Принцип работы планировщика строится на простом наблюдении. Нагрузка сети на GPU зависит от ее состояния: числа активных сот и абонентов, скорости вниз и вверх, схемы модуляции, числа радиоресурсов и MIMO-слоев. Все эти параметры известны до запуска расчета на GPU. Значит, потребность в ресурсах можно предсказать заранее.

Если упростить подход, то работа сократится до трех шагов. Сначала модуль мониторинга читает метрики сети через стандартные интерфейсы. Задержка этого шага около 0,7 мкс. Затем небольшая нейросеть, ансамбль из четырех моделей, прогнозирует загрузку на следующий слот. Она берет не среднее значение, а 99,8 перцентиль, т.е. закладывает запас ради стабильности сети. Работает прогноз на обычном CPU и занимает 21-24 мкс. Наконец, модуль распределения переводит прогноз в маски доступа и выдает сети нужное число блоков. Остальные блоки получает ИИ. Шаг занимает около 0,5 мкс, а гранулярность деления составляет два вычислительных блока. Суммарная задержка меньше 27 мкс.

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

В эмуляции с 27 сотами нагрузка доходила до 138 абонентов вниз и 61 вверх. Планировщик сравнили с двумя статическими разделами из 132 блоков: 108 сети и 24 ИИ или 52 сети и 80 ИИ. Пропускная способность вверх почти не отличалась от раздела с приоритетом сети, а верхний перцентиль задержки остался ниже 3 мс. Время до первого действия робота, которым управляет модель, оказалось короче, чем при статическом приоритете сети. Раздел с приоритетом ИИ ухудшал и пропускную способность, и задержку, поэтому на практике он неприменим. Накладные расходы почти не росли с масштабом: при 8 сотах трафик составлял 5266 Мбит/с вниз, при 27 сотах 11483 Мбит/с, а задержка прогноза осталась около 22 мкс.

☎️ Телекоммуналка в Telegram | в MAX

Вердикт: материал в целом соответствует свежему препринту; ключевые цифры совпадают с отчётом авторов. Это лабораторный прототип, а не внедрение у оператора.

Что это за работа

Описанный планировщик — система Eunoia из препринта «Eunoia: Toward Application-Transparent, Scalable GPU Sharing in AI-RAN» (arXiv:2610.15404). Авторы: Zongshen Wu, Marko Milenković, Jiarong Xing, Rahman Doost-Mohammady, Rice University (США). На arXiv работа появилась около 11 октября 2026 года, обновление — около 14 октября; на дату проверки (15 октября 2026) это свежий препринт без заметной независимой прессы и без известных исправлений результатов.

Исходный URL в репосте не указан; содержание совпадает с текстом статьи, а не с отраслевым пресс-релизом.

История темы

Идея совместной работы радиочасти и ИИ на одном GPU для AI-RAN не нова. В 2024 году на INFOCOM вышла YinYangRAN: динамическое мультиплексирование GPU между PHY и ML, но с более грубой перенастройкой MPS (в Eunoia это отмечают как перенастройку дольше 100 мс с откатом на CPU). Параллельно есть другие линии: CAORA на MIG, Beaver (эластичный SM/HBM sharing), работы на MIG Compute Instances. Eunoia отличается прозрачностью для приложений, прогнозом на каждый RAN-слот и гранулярностью на уровне TPC (два SM).

Проверка фактов

Подтверждается по тексту препринта:

• Мотивация AI-RAN: GPU на edge для DU и одновременно для LLM/видеоаналитики; жёсткие дедлайны слота (миллисекунды), риск HARQ, потери синхронизации и падения сот.
• Критика MIG/MPS (запас под пик, простой) и Green Context (правки кода приложений); перенастройка MPS >100 мс.
• Ключевой принцип: потребность в SM предсказуема по метрикам RAN (соты, UE, DL/UL, MCS, PRB, MIMO), известным до запуска GPU-ядер.
• Три модуля: Monitor (~0,7 мкс), Predictor (ансамбль из четырёх MLP, целевой 99,8-й перцентиль SM, ~21–24 мкс на CPU), Allocator (~0,5 мкс, маски TPC / шаг в 2 SM). Суммарная задержка <27 мкс — совпадает с Table 2.
• Прозрачность (без правок кода RAN/ИИ), перераспределение каждый слот, обучение на агрегированных метриках «один раз» для разного числа сот.
• Эмуляция до 27 сот, до 138 UE вниз и 61 вверх; статические MPS-разделы 108/24 и 52/80 из 132 SM; UL goodput близок к RAN-приоритету; P99 UL latency <3 мс; TTFA робота лучше, чем при статическом RAN-приоритете; AI-приоритет ухудшает сеть. Цифры 5266 Мбит/с (8 сот) и 11483 Мбит/с (27 сот) DL и ~22 мкс предиктора — из той же таблицы накладных расходов.

Уточнения и ограничения:

• В репосте не названы Eunoia, arXiv и платформа (NVIDIA Aerial / ARC-OTA, libsmctrl). ИИ-нагрузка в тестах — TimelyLLM (робототехника), не «любая» модель.
• Сценарий на 27 сот — эмуляция TestMAC/RU; отдельно показан меньший OTA-стенд (частная 5G, Foxconn O-RU, Amarisoft UE). Это не полевой пилот оператора.
• Авторы сами называют систему early prototype: прозрачность со стороны нескольких конкурирующих ИИ-приложений и сценарии AI-for-RAN ещё не закрыты.
• Препринт; независимого воспроизведения результатов на момент проверки не найдено. Конкурирующие подходы (Beaver и др.) сообщают иные метрики дедлайнов на других стендах — это не опровержение Eunoia, а признак активной исследовательской области.

Итог

Репост аккуратно пересказывает результаты Eunoia: цифры задержек, перцентилей, статических разделов и нагрузки в эмуляции совпадают с препринтом. Формулировки про «сеть не падает» и «на практике неприменим» раздел с приоритетом ИИ соответствуют экспериментам авторов. Главный риск для читателя — принять лабораторный прототип за готовое коммерческое решение: речь о свежей научной работе на тестовом/эмулированном AI-RAN, а не о массовом внедрении у операторов.