Впровадження управління трафіком з урахуванням штучного інтелекту в Istio: підтримка розширення Gateway API Inference

Більш розумний та динамічний спосіб оптимізації маршрутизації трафіку ШІ на основі показників у реальному часі та унікальних характеристик робочих навантажень.

Jul 28, 2025 | Від Lior Lieberman - Google, Keith Mattix - Microsoft, Aslak Knutsen - Red Hat

Світ штучного інтелекту в Kubernetes ставить унікальні виклики, для вирішення яких традиційні архітектури маршрутизації трафіку не були розроблені. Хоча Istio вже давно досягла успіхів в управлінні трафіком мікросервісів за допомогою складних функцій балансування навантаження, безпеки та моніторингу, вимоги робочих навантажень великих мовних моделей (LLM) вимагають спеціалізованих функцій.

Тому ми раді оголосити про підтримку Istio розширення Gateway API Inference Extension, яке забезпечує інтелектуальну маршрутизацію з урахуванням моделей і LoRA в Istio.

Чому робочі навантаження ШІ потребують особливого підходу

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

Виклик масштабу та тривалості

На відміну від типових відповідей API, які виконуються за мілісекунди, запити на виведення AI часто обробляються значно довше — іноді кілька секунд або навіть хвилин. Ця разюча різниця в часі обробки означає, що рішення щодо маршрутизації мають набагато більший вплив, ніж у традиційних вебсервісах. Один погано маршрутизований запит може на тривалий час заблокувати дорогі ресурси GPU, створюючи каскадний ефект у всій системі.

Характеристики корисного навантаження є не менш складними. Запити на AI-висновок часто містять значно більші корисні навантаження, особливо коли йдеться про системи Retrieval-Augmented Generation (RAG), багаторазові розмови з великим контекстом або мультимодальні вхідні дані, включаючи зображення, аудіо або відео. Ці великі корисні навантаження вимагають інших стратегій буферизації, потокової передачі та тайм-ауту, ніж традиційні HTTP API.

Патерни споживання ресурсів

Мабуть, найважливішим є те, що один запит на виведення може споживати ресурси цілого GPU під час обробки. Це принципово відрізняється від традиційного обслуговування запитів, коли кілька запитів можуть оброблятися одночасно на тих же обчислювальних ресурсах. Коли GPU повністю зайнятий одним запитом, додаткові запити повинні ставитися в чергу, що робить рішення про планування та маршрутизацію набагато більш впливовими, ніж для стандартних робочих навантажень API.

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

Врахування стану та управління памʼяттю

Моделі ШІ часто підтримують кеші в памʼяті, що значно впливає на продуктивність. Кеші KV (Key-Value) зберігають проміжні обчислення уваги для раніше оброблених токенів, слугуючи основним споживачем памʼяті GPU під час генерації та часто стають найбільш поширеною вузькою ланкою. Коли використання кешу KV наближається до межі, продуктивність різко погіршується, що робить маршрутизацію з урахуванням кешу необхідною.

Крім того, багато сучасних розгортань ШІ використовують адаптери з тонкою настройкою, такі як LoRA (Low-Rank Adaptation), щоб налаштувати поведінку моделі для конкретних користувачів, організацій або випадків використання. Ці адаптери споживають памʼять GPU та час завантаження під час перемикання. Сервер моделі, який вже має завантажений необхідний адаптер LoRA, може обробляти запити негайно, тоді як сервери без адаптера стикаються з дорогим часом завантаження, який може зайняти кілька секунд.

Динаміка черг та критичність

Робочі навантаження AI-висновків також вводять концепцію критичності запитів, яка менш поширена в традиційних службах. Реальні інтерактивні програми (такі як чат-боти або генерація контенту в реальному часі) вимагають низької затримки та повинні мати пріоритет, тоді як завдання пакетної обробки або експериментальні робочі навантаження можуть терпіти вищу затримку або навіть бути скасованими під час перевантаження системи.

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

Саме тут маршрутизація з урахуванням виведення стає критично важливою. Замість того, щоб розглядати всі бекенди як еквівалентні чорні ящики, нам потрібні рішення для маршрутизації, які розуміють поточний стан і можливості кожного сервера моделі, включаючи глибину їх черги, використання памʼяті, завантажені адаптери та здатність обробляти запити різних рівнів критичності.

Розширення Gateway API: рішення на основі Kubernetes

Розширення Kubernetes Gateway API Inference запропонувало рішення для цих викликів, спираючись на перевірену основу Kubernetes Gateway API, одночасно додаючи специфічний для ШІ інтелект. Замість того, щоб вимагати від організацій переробки власних рішень або відмови від наявної інфраструктури Kubernetes, розширення забезпечує стандартизований, нейтральний до постачальника підхід до інтелектуального управління трафіком ШІ.

Розширення вводить два ключові визначення користувацьких ресурсів, які працюють разом, щоб вирішити виклики маршрутизації, які ми окреслили. Ресурс InferenceModel надає абстракцію для власників робочих навантажень AI-Inference, щоб визначити логічні точки доступу моделі, тоді як ресурс InferencePool надає операторам платформ інструменти для управління бекенд-інфраструктурою з урахуванням робочих навантажень ШІ.

Розширюючи знайому модель Gateway API, а не створюючи абсолютно нову парадигму, розширення виведення дозволяє організаціям використовувати свій наявний досвід роботи з Kubernetes, отримуючи при цьому спеціалізовані можливості, які вимагають робочі навантаження ШІ. Цей підхід забезпечує те, що команди можуть впроваджувати інтелектуальну маршрутизацію виведення, узгоджену зі знайомими знаннями та інструментами мережі.

Примітка: InferenceModel, ймовірно, зміниться в майбутніх випусках розширення Gateway API Inference.

InferenceModel

Ресурс InferenceModel дозволяє власникам робочих навантажень виведення визначати логічні точки доступу моделі, які абстрагують складнощі розгортання бекенду.

apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferenceModel
metadata:
  name: customer-support-bot
  namespace: ai-workloads
spec:
  modelName: customer-support
  criticality: Critical
  poolRef:
    name: llama-pool
  targetModels:
    - name: llama-3-8b-customer-v1
      weight: 80
    - name: llama-3-8b-customer-v2
      weight: 20

Ця конфігурація демонструє модель підтримки клієнтів, яка інтелектуально перенаправляє між двома варіантами бекенду, забезпечуючи безпечне впровадження нових версій моделі та підтримуючи доступність послуг.

InferencePool

Ресурс InferencePool діє як спеціалізована бекенд-служба, яка розуміє характеристики робочих навантажень ШІ:

apiVersion: inference.networking.x-k8s.io/v1alpha2
kind: InferencePool
metadata:
  name: llama-pool
  namespace: ai-workloads
spec:
  targetPortNumber: 8000
  selector:
    app: llama-server
    version: v1
  extensionRef:
    name: llama-endpoint-picker

При інтеграції з Istio цей пул автоматично виявляє сервери моделей за допомогою функції виявлення сервісів Istio.

Як працює Inference маршрутизація в Istio

Імплементація Istio базується на перевіреній основі управління трафіком сервісної мережі. Коли запит входить у мережу через Kubernetes Gateway, він слідує стандартним правилам відповідності HTTPRoute API Gateway. Однак замість використання традиційних алгоритмів балансування навантаження, бекенд вибирається службою вибору точок доступу (EPP, Endpoint Picker).

EPP оцінює кілька факторів, щоб вибрати оптимальний бекенд:

Оцінка критичності запиту: Критичні запити отримують пріоритетний маршрут до доступних серверів, тоді як запити з нижчою критичністю (стандартні або такі, що можуть бути скинуті) можуть бути скинуті під час періодів високого навантаження.
Аналіз використання ресурсів: Розширення моніторить використання памʼяті GPU, зокрема використання кешу KV, щоб уникнути перевантаження серверів, які наближаються до межі ємності.
Adapter Affinity: Для моделей, що використовують адаптери LoRA, запити переважно маршрутизуються до серверів, які вже мають завантажений необхідний адаптер, що усуває витрати на завантаження.
Prefix-Cache Aware Load Balancing: Рішення про маршрутизацію враховують розподілені стани кешу KV на серверах моделей і надають пріоритет серверам моделей, які вже мають префікс у своєму кеші.
Queue Depth Optimization: Відстежуючи довжину черг запитів на різних бекендах, система уникає створення “гарячих точок”, які можуть збільшити загальну затримку.

Ця інтелектуальна маршрутизація працює прозоро в межах існуючої архітектури Istio, зберігаючи сумісність з такими функціями, як взаємна TLS, політики доступу та розподілене трасування.

Потік запитів на маршрутизацію висновків

Потік запиту на висновок із маршрутизацією gateway-api-inference-extension.

Шлях попереду

Майбутній план дій включає такі функції, повʼязані з Istio:

Підтримка Waypoints — Оскільки Istio продовжує еволюціонувати в бік архітектури мережі ambient, маршрутизація, що враховує висновки, буде інтегрована в проксі-сервери Waypoint для забезпечення централізованого, масштабованого виконання політик для робочих навантажень ШІ.

По-за межами інновацій, специфічних для Istio, спільнота Gateway API Inference Extension також активно розробляє кілька розширених можливостей, які ще більше покращать маршрутизацію для робочих навантажень висновків ШІ на Kubernetes:

Інтеграція HPA для метрик ШІ: горизонтальне автоматичне масштабування подів на основі метрик, специфічних для моделі, а не тільки на основі процесора та памʼяті.
Підтримка мультимодального введення: оптимізована маршрутизація для великих мультимодального вводу та виводу (зображення, аудіо, відео) з інтелектуальними можливостями буферизації та потокової передачі.
Підтримка гетерогенних прискорювачів: інтелектуальна маршрутизація між різними типами прискорювачів (GPU, TPU, спеціалізовані чіпи AI) з урахуванням затримки та вартості балансування навантаження.

Початок роботи з розширенням Istio Inference

Готові спробувати маршрутизацію, що враховує висновки? Реалізація офіційно доступна, починаючи з Istio 1.27!

Для встановлення та посібників, будь ласка, дотримуйтесь специфічних для Istio вказівок на вебсайті Gateway API Inference Extension.

Вплив на продуктивність та переваги

Попередні оцінки показують значні поліпшення продуктивності з маршрутизацією, що враховує висновки, включаючи суттєве зниження p90 затримки при вищих швидкостях запитів і зменшення затримок кінцевої точки в порівнянні з традиційним балансуванням навантаження.

Для отримання детальних результатів бенчмарків та методології дивіться оцінку продуктивності розширення Gateway API Inference з тестовими даними, що використовують H100 GPU та розгортання vLLM.

Інтеграція з існуючою інфраструктурою Istio означає, що ці переваги зʼявляються з мінімальними операційними витратами, а ваші існуючі конфігурації моніторингу, безпеки та управління трафіком продовжують працювати без змін.

Висновок

Розширення Gateway API Inference є значним кроком вперед у підготовці Kubernetes до роботи з ШІ, а реалізація Istio приносить цей інтелект на рівень сервісної мережі, де він може мати максимальний вплив. Поєднуючи маршрутизацію, що враховує висновки, з перевіреними можливостями безпеки, спостереження та управління трафіком Istio, ми дозволяємо організаціям запускати робочі навантаження ШІ з тією ж операційною досконалістю, яку вони очікують від своїх традиційних сервісів.

Маєте запитання або хочете долучитися? Приєднуйтесь до Kubernetes Slack і знайдіть нас на каналі #gateway-api-inference-extension або дискусій у Istio Slack.