Планировщик 5G оставил мелкие блоки CPU, чтобы не ждать GPU
В момент 5G-передачи планировщик смотрит на размер очередного transport block: если он меньше 4096 байт, задача остаётся на CPU; если достигает этого порога, её направляют на GPU. Такое правило выглядит почти вызывающе для AI-RAN, где GPU обычно рассматривают как естественный дом для тяжёлой PHY-обработки. Но короткому блоку иногда приходится дольше ждать запуска GPU-работы и обратного вызова, чем вычисляться на процессорном ядре.
Авторы работы arXiv:2610.31627 встроили это переключение в CUDA-совместимую реализацию gNB OCUDU. Базовая станция работала на NVIDIA DGX Spark с Arm CPU и GB10 GPU, радиоканал строился через USRP X310, а единственный 5G-телефон принимал UDP-поток 30 Mbit/s. Использовались 20 MHz в диапазоне n77 и схема 1×1. Это стенд с реальной передачей по воздуху, хотя и далёкий от нагруженной коммерческой соты.
Порог не выводили из общей теории размеров пакета. Его выбрали как policy данного сочетания хоста, GPU и программного тракта: baseline отправлял на GPU все transport blocks, гибридный вариант оставлял CPU блоки до 4096 B. Поэтому 4096 B здесь следует читать как демонстрацию класса решений, а не как готовую настройку для любой DU.
Измеряли очень узкий, но полезный отрезок: время от входа в обработчик до host callback. Таймер имеет разрешение 0.1 µs, однако не включает ожидание до входа в handler и отправку телеметрии. Более тонкая ловушка состоит в том, что GPU callback способен прийти до готовности результата на устройстве. Цифры статьи описывают поведение host-side диспетчеризации, не задержку по радиоинтерфейсу и не пользовательскую latency.
Где GPU теряет время
На 16 успешных OTA-прогонах сохранили 223979 callbacks с одним codeword. Средняя длительность host callback, усреднённая равным весом между прогонами, снизилась на 29.66% без посторонней нагрузки на GPU. При синтетическом co-runner, который запускал номинальную GPU-работу на 1 ms и затем спал на host 9 ms, снижение составило 22.93%. У телефона при этом регистрировали около 30 Mbit/s и нулевую потерю UDP в двадцатисекундных интервалах.
Эффект почти целиком создают малые блоки. Для них авторы приводят сокращение средних значений на 36.09% без co-runner и на 30.29% при его наличии. У крупных transport blocks диапазоны средних между прогонами перекрываются: работа не показывает, что GPU внезапно стал быстрее обрабатывать большие блоки. Она показывает более конкретную вещь: CPU избавляет малую задачу от цены входа в GPU-конвейер.
Порог ещё не стал свойством 5G
Это особенно интересно для радиотракта, где размер блока меняется вместе с MCS, ресурсными блоками, планированием и состоянием канала. Фиксировать один вычислитель для всего PHY-потока означает платить один и тот же overhead и за большой кодовый блок, и за короткий фрагмент, который едва успевает оправдать перенос данных и запуск kernel.
Граница измерения
Авторы определяли выбранный путь по правилу policy и размеру TB, без device-level tracing. CUPTI они называют будущим способом проверить фактическое исполнение и момент готовности GPU-результата. Наборы крупных TB между прогонами также различались, а synthetic co-runner лишь приближённо изображает соседнюю AI-нагрузку. Измерения нельзя переносить на другой GPU, сетевой стек или radio software без нового sweep порога.
Тем не менее сама идея меняет привычную картину heterogeneous PHY: GPU полезен не по факту своего присутствия в сервере. Для части коротких операций лучшим ускорителем оказывается CPU, который уже рядом с данными и не требует запускать отдельную вычислительную экспедицию. Следующий инженерный шаг — сделать порог динамическим: учитывать очередь GPU, форму TB, текущую загрузку и стоимость копирования, затем проверить выигрыш до декодированного бита и пользовательского пакета.