Kubernetes Time-Slicing: Прихована ціна спільного GPU

Проблема прихованих затримок при спільному використанні GPU

У виробничих середовищах LLM-агенти часто конкурують за один і той же графічний процесор (GPU). Дослідження виявило, що на одній спільній карті p99 затримка агента, чутливого до затримок, погіршилася на 66%, попри те, що кожен под продовжував повідомляти про справність. Це є частиною серії, яка має на меті усунути надлишкову роботу з конвеєра агентних LLM, зосереджуючись на усуненні надмірного очікування, показуючи, як кілька мікроагентів ділять один GPU за допомогою time-slicing.

Спільне використання GPU не є безкоштовним, і планувальник Kubernetes не повідомить про це. Коли два агенти ділять один GPU з time-slicing, Kubernetes повідомляє, що обидва поди працюють. Пошкодження ховається у «хвості» затримки.

Методологія дослідження: Два агенти на одному GPU

Для дослідження було використано два дуже різні робочі навантаження агентів:

Малий, чутливий до затримок FFT-воркер: виконує безперервний цикл великих 2-D комплексних FFT. Це імітує агенти, які повинні відповідати негайно.
Важкий, обчислювально-інтенсивний GEMM-воркер: виконує безперервний потік великих матричних множень (GEMM), що є основою прямого проходу трансформера. Це імітує «важковаговиків», які виконують основну роботу моделі.

Обидва воркери були розміщені в окремих подах Kubernetes, кожен з яких запитував nvidia.com/gpu: "1". Плагін пристроїв NVIDIA з функцією CUDA time-slicing розмістив їх на одному фізичному GPU GTX 1080. Вимірювання проводилися за допомогою подій CUDA, агрегованих у p50/p95/p99, а також обчислювався коефіцієнт деградації.

Ілюзія Kubernetes та реальність Time-Slicing

За замовчуванням Kubernetes розглядає nvidia.com/gpu як цілісну, неподільну одиницю. Функція time-slicing плагіна пристроїв NVIDIA змінює цей облік. За допомогою ConfigMap можна налаштувати Kubernetes так, щоб він «вдавав», що кожен фізичний GPU є кількома. Наприклад, replicas: 4 змушує один фізичний GTX 1080 рекламувати чотири доступні слоти nvidia.com/gpu.

Чотири поди можуть запросити по «1» GPU і бути успішно запланованими. Однак це не розділяє апаратне забезпечення фізично. Це не MIG (Multi-Instance GPU). Немає ні розділення пам'яті, ні обчислювального розділення. Чотири «GPU» — це той самий кремній, і поди по черзі використовують його через CUDA time-slicing. Це створює більше слотів для планування, але нульову ізоляцію.

Експеримент проводився на одній п'ятирічній GTX 1080 вартістю $150 зі стандартним плагіном пристроїв NVIDIA Kubernetes та CUDA time-slicing.

Результати: Приховане погіршення затримки p99

Результати показали, що:

Медіани (p50) для обох агентів залишилися майже незмінними.
Пропускна здатність майже не змінилася: FFT-воркер втратив 7,3%, а GEMM-воркер — 1,4%.
p99 затримка для малого, чутливого до затримок FFT-воркера зросла з 3,68 мс до 6,10 мс (приблизно в 1,66 раза або на 66%). Його джиттер (p99/p50) зріс з 1,02 до 1,70.
p99 затримка для важкого GEMM-воркера зросла з 20,985 мс до 24,690 мс (у 1,18 раза). Його джиттер зріс з 1,01 до 1,20.

Ключова асиметрія полягає в тому, що малий, чутливий до затримок агент деградує першим і найсильніше. Великий GEMM-воркер виконує свою роботу, тоді як маленький FFT-воркер постійно переривається і змушений чекати своєї черги. Коли два робочі навантаження ділять одну лінію, страждає те, яке потребувало швидкого виконання.

Для порівняння було обчислено коефіцієнт деградації (DF) = shared_p99 / baseline_p99. Для FFT він становив 1,66, для GEMM — 1,18.

Перевірка за допомогою лічильників використання GPU DCGM показала, що активність SM та DRAM FFT-воркера різко зросла у спільному вікні, що підтверджує наявність конкуренції на двох незалежних рівнях: затримки програми та апаратних лічильників.

Наслідки для архітектури агентних систем

Ці результати стосуються не конкретних робочих навантажень, а патерну, який виникає, коли реальні агентні рої розміщуються на спільному обладнанні. Існують два основні «типи особистостей» агентів:

Легкі, керовані дедлайнами агенти: маршрутизатори, системи безпеки, класифікатори, інструменти виклику — невеликі, швидкі моделі, які постійно працюють, і від яких залежить весь конвеєр.
Важкі, стабільні агенти: великі прямі проходи трансформерів, виклики моделей, що інтенсивно використовують GEMM.

Розміщення будь-яких двох агентів з такими характеристиками на одному GPU з time-slicing призводить до того, що медіани майже не змінюються, але малий, чутливий до затримок агент страждає від погіршення «хвоста» затримки. Time-slicing надає черги, але не гарантує дотримання дедлайнів. Таким чином, агент, який живе або помирає від свого дедлайну, страждає, коли його черга постійно переривається.

Рішення полягає не в забороні спільного використання GPU, оскільки це часто необхідно через обмежений бюджет. Рішення полягає в тому, щоб припинити використовувати «зелену галочку» YAML як заміну мікроархітектурної реальності. Необхідно вимірювати «хвіст» затримки, приписувати деградацію та планувати з урахуванням реальних обмежень кремнію.

Обмеження дослідження

Дослідження є невеликим і цілеспрямованим. Важливі обмеження включають:

Кількість агентів: Дослідження проводилося з двома агентами.
Пропускна здатність: Вимірювалася як проксі середньої швидкості, а не реальна пропускна здатність обслуговування запитів.
Робочі навантаження: Синтетичні (циклічний FFT та циклічний matmul), хоча вони є чесними замінниками для легкого, чутливого до затримок та важкого агента висновку.
Активність DCGM: Проксі низької величини.
Режим спільного використання: Дослідження вимірює стандартний шлях time-slicing. Порівняння з MPS та MIG є окремою темою.
Клас GPU: Використовувалася одна GTX 1080. Новіші GPU можуть перемикати контекст швидше, але напрямок деградації (малий, чутливий до затримок агент страждає першим) є стійким результатом.

Інструмент Kube-TimeSlice-Profiler

Для вимірювання та кількісної оцінки деградації було розроблено інструмент Kube-TimeSlice-Profiler. Він перетворює невиразне відчуття «GPU сьогодні працює повільно» на вимірюваний коефіцієнт деградації з підтвердженнями.

Що далі: Частина 3 серії

Наступна частина серії буде присвячена усуненню «подорожі PCIe» — прихованого податку в кожному конвеєрі RAG. Замість того, щоб агент переривав роботу, залишав прискорювач, переходив через шину PCIe до Python для векторного пошуку на CPU, а потім повертався, буде створено спеціальне ядро CUDA Top-K. Це дозволить утримувати весь цикл пошуку на апаратному забезпеченні GPU, усуваючи кругові поїздки до Python та затримки на стороні хоста.

Що це означає для розробників

Розробникам слід усвідомити, що статус 'Running' подів у Kubernetes та середні показники пропускної здатності не відображають реального впливу спільного використання GPU. Для LLM-агентів, особливо чутливих до затримок, критично важливо вимірювати затримку p99, оскільки вона може значно погіршуватися, навіть якщо середні показники залишаються стабільними. Інструмент Kube-TimeSlice-Profiler дозволяє кількісно оцінити це погіршення.

Ключові факти

При спільному використанні GPU за допомогою time-slicing, p99 затримка чутливого до затримок LLM-агента може погіршитися на 66%.
Kubernetes повідомляє про справність подів ('Running'), навіть коли на GPU виникає значна конкуренція та деградація продуктивності.
Time-slicing надає більше слотів для планування на одному GPU, але не забезпечує фізичної ізоляції чи розділення ресурсів.
Малі, чутливі до затримок агенти страждають від спільного використання GPU значно більше, ніж важкі, обчислювально-інтенсивні.
Середні показники пропускної здатності та медіани затримки можуть приховувати серйозні проблеми з «хвостом» затримки (p99).