В этом материале
Свободный GPU может ждать процесс, которому регулярно заканчивается CPU quota. Проверьте cpu.stat и действующий cpu.max: средняя загрузка хоста не показывает, сколько времени разрешено конкретной cgroup. Ограничение CPU обычно задерживает выполнение, а не завершает контейнер.
Свободный GPU может ждать процесс, которому регулярно заканчивается CPU quota. Проверьте cpu.stat и действующий cpu.max: средняя загрузка хоста не показывает, сколько времени разрешено конкретной cgroup. Ограничение CPU обычно задерживает выполнение, а не завершает контейнер.
Разделите квоту и доступные ядра
Параметр CPU limit ограничивает время исполнения за период. Он отличается от affinity и от веса при конкуренции. Поэтому процесс может видеть много логических CPU, но получать небольшой бюджет времени. Сохраните настройки контейнера, cpu.max и cpuset, а также число активных подготовительных потоков. Не переводите виртуальные CPU в физические ядра без сведений о среде. Для распределённого worker полезно отметить, какой процесс готовит данные и какой непосредственно выполняет вычисления на GPU.
Читайте изменения cpu.stat
В cgroup v2 смотрите usage_usec, nr_periods, nr_throttled и throttled_usec, учитывая доступность полей в установленном ядре. Сравнивайте разницу значений за одинаковый интервал. Накопленные секунды throttling нельзя автоматически трактовать как долю недоступности сервиса. Проверьте также родителей группы: локальный cpu.stat и общий эффект ограничений предков могут иметь разные области учёта. Если локальные значения спокойны, это ещё не освобождает всю иерархию от подозрений.
Проверьте контролируемый сценарий
Представим подготовительный контейнер с квотой 100000 за период 100000 микросекунд. Это бюджет одного CPU времени, даже если приложение запускает четыре потока. Параллельный короткий всплеск может израсходовать бюджет раньше окончания периода. Следом GPU ждёт очередную порцию данных. Это объяснение механизма, а не обещание конкретного ускорения после изменения настройки.
| Запись в протоколе | Назначение |
|---|---|
| cpu.max и период | Восстановить разрешённый бюджет |
| Прирост nr_throttled | Найти интервалы ограничения |
| Время подготовки порции | Связать CPU с ожиданием GPU |
Исключите соседние причины
Сопоставьте throttling с очередью диска, сетевыми ожиданиями и memory pressure. Одновременное появление двух симптомов ещё не доказывает причинность. Для проверки измените только CPU budget в изолированном окне или сократите конкурирующую подготовительную работу. Сохраните размеры входных данных и число потоков. Если увеличение бюджета ничего не меняет, вернитесь к исходной конфигурации и продолжайте исследование следующего участка, не меняя параметры LLM-движка одновременно.
Подтвердите устойчивое восстановление
Сравните одинаковые интервалы до и после изменения: время подготовки, использование CPU, прирост throttling и паузы GPU. Затем проверьте влияние на соседние контейнеры, поскольку дополнительный бюджет берётся из ресурсов общего узла. Оставьте короткий артефакт: процесс, cgroup, значения лимита, входной набор и результат повторения. При следующем rollout сравнивайте фактические значения с этим артефактом: изменение requests или шаблона Pod может незаметно вернуть ограничение, хотя сам образ остался прежним.
В протоколе отдельно укажите, снимались ли показатели только дочерней группы или всей иерархии. Это позволяет повторить наблюдение после переноса workload и избежать сравнения локального ограничения с суммарным давлением другого уровня управления ресурсами.
Связанные разборы: cpu gpu hybrid architecture; compute optimized hosting.