AI Reliability Engineering — третя епоха SRE

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Незабаром ми житимемо в оточенні штучного інтелекту. Вони (AIs) організовуватимуть наше життя, керуватимуть нашим бізнесом і надаватимуть основні державні послуги. Ми житимемо у світі принтерів ДНК і квантових комп’ютерів, сконструйованих патогенів і автономної зброї, роботів-помічників і надлишку енергії. Ми не готові.

The Coming Wave

Допитливість (curiosity) — це риса, притаманна багатьом SRE. Замість того, щоб розглядати одну конкретну частину системи як свою сферу діяльності, SRE натомість цікавляться всіма частинами системи і тим, як вони функціонують разом.

97 Things Every SRE Should Know

«Inference is the new web app».

KubeCon North America 2023

Коли на KubeCon NA прозвучала цитата Claytons Coleman, вона викликала резонанс. Лише п’ять років тому, запитайте будь-якого інженера SRE про їхню роботу, і ви почуєте про підтримку веб-сервисів швидкими, масштабованими та стійкими. А сьогодні? Ландшафт змінюється прямо під нашими ногами. AI inference workloads — процес, коли навчена модель використовує свої знання для прогнозування на нових даних — стають настільки ж критично важливими, як колись веб-сервіси.

«Inference — процес, за допомогою якого навчена модель застосовує свої вивчені шаблони до нових, невидимих даних для генерації прогнозів чи рішень. Під час Inference модель використовує свої знання для реагування на реальні вхідні дані».

Ця еволюція вимагає нової дисципліни: AI Reliability Engineering (AIRe). Ми вже не лише боремось із latency spikes у HTTP-запитах — тепер ми маємо справу з затримками генерації токенів у LLM. Оптимізація SQL-запитів здається майже старомодною порівняно з оптимізацією checkpoints моделей і тензорів. AI-моделі, як і колись веб застосунки, потребують масштабованості, надійності та спостережуваності (Observability) — але на рівні, який ми ще тільки проєктуємо.

Новий стек AI

Я провів майже два роки, занурившись в AI Reliability Engineering — досліджуючи, створюючи прототипи та будуючи real-world inference системи. Від конференцій DevOps до SRE Days та зустрічей спільноти в Нюрнберзі та Лондоні, я ділився здобутими уроками з колегами в цій галузі. Тепер я можу поділитися висновками.

Ненадійний AI гірший, ніж відсутність AI взагалі.

• Inference — це не просто виконання моделі — це операційна дисципліна з власним набором архітектурних компромісів та інженерних патернів. На відміну від навчання (training), де час і вартість можна амортизувати, Inference це коли кожна мілісекунда має значення.
• Real-time vs. Batch: Iнференс поділяється на два режими. Iнференс у реальному часі (real-time або online) забезпечує роботу чат-ботів, виявлення шахрайства або безпілотні автомобілі — де низька затримка є вимогою. Batch (offline) інференс, з іншого боку, обробляє великі набори даних за розкладом для класифікації зображень, аналізу журналів або прогнозування трендів.
• Resource Profiles: Хоча зазвичай легший, ніж навчання, інференс все ще вимагає точної інженерії. Програми реального часу вимагають не лише швидких обчислень, але й високодоступної інфраструктури. CPUs все ще мають свою роль, але сучасні стеки інференсу все більше спираються на GPU, TPU або спеціалізовані чіпи, такі як AWS Inferentia та NVIDIA TensorRT, для low-latency performance.
• Розгортання: Інференс працює будь-де — від граничних пристроїв до hyperscale clouds. Ви знайдете його в serverless, кластерах Kubernetes і навіть крихітних модулях IoT. Хмарні платформи, такі як SageMaker, Vertex AI, Hugging Face та Together.ai, спростили розгортання, але рішення часто зводиться до вартості, контролю та затримки.
• Оптимізація: Битва за швидкість та ефективність триває. Команди використовують квантизацію (FP32 → INT8), дистиляцію моделей та Neural Architecture Search (NAS) для налаштування продуктивності без компромісу з результатами. Мета? Менші, швидші, ефективніші inference engines.
• Спостережуваність і моніторинг: Традиційних стеків телеметрії недостатньо. Inference workloads потребують більшого — відстеження затримки прогнозування, пропускної здатності токенів, дрейфу і навіть рівня галюцинацій. Інструменти, такі як OpenTelemetry, Prometheus і AI-native traces, більше не є опціональними.
• Масштабованість: Передбачуваність не входить до словника AI. Трафік інференс може різко зрости зі зміною шаблонів використання, вимагаючи агресивного автомасштабування (Kubernetes HPA, Cloud Run) та інтелектуального балансування навантаження (Envoy, Istio або KServe), щоб випереджати попит.
• Security Frontlines: Інференс приносить нові attack surfaces — від adversarial inputs до ризиків витоку даних. Інженери повинні захищати model endpoints, як API: з автентифікацією, обмеженням швидкості (rate-limiting), шифруванням та перевірками цілісності під час виконання (runtime integrity checks).

Інференс більше не просто підпроцес машинного навчання. Це application. Це продакшн. І він переосмислює операційний стек під ним.

Традиційні принципи SRE пропонують основу, але вони не зовсім відповідають вимогам AI.

• Імовірнісна природа: Моделі AI не є детерміністичними, як більшість веб-програм. Один і той же ввід може дати різні результати. Модель може похвалитися 100% доступністю, але видавати неправильні, упереджені або безглузді результати. Це фундаментально змінює наше визначення «надійного».
• Зміна метрик: Uptime SLA? Необхідні, але недостатні. Ласкаво просимо у світ accuracy SLAs. Нам потрібно визначати та вимірювати продуктивність на основі точності (precision), повноти (recall), справедливості (fairness) та дрейфу моделі (model drift).

• Еволюція інфраструктури: Концепції, такі як ingress та горизонтальне автомасштабування подів (pods), еволюціонують. Тепер нам потрібні інструменти та технології, такі як model mesh, балансування LoRa, AI-gateways та динамічне розподілення ресурсів, особливо для робочих навантажень (workloads), залежних від GPU. Сам Kubernetes адаптується через робочі групи (Working Groups of Serving), DRA (Dynamic resource allocation) — динамічне розподілення ресурсів та Gateway API, щоб краще справлятися з цими спеціалізованими потребами.
• Прогалини в спостережуваності: Стандартні інструменти добре відстежують CPU, пам’ять і затримку (latency), але часто пропускають проблеми, специфічні для AI, такі як дрейф (drift), показники впевненості (confidence scores) або рівні галюцинацій. Нам потрібна спостережуваність, специфічна для AI.
• Нові режими відмови (Failure Modes): Забудьте про прості збої. Тепер ми стикаємося з «тихою деградацією моделі» або розпадом моделі (model decay). Це поступовий, часто невидимий спад продуктивності, точності або чесності (fairness). Поводження з цим як з критичним інцидентом у продакшн вимагає нового мислення та інструментарію.

Model Decay — Silent model degradation. На відміну від традиційних software issues, які викликають негайні збої або помилки, моделі AI можуть деградувати тихо, продовжуючи функціонувати, але з дедалі більш неточними, упередженими або непослідовними результатами.

Чому ми розглядаємо тиху деградацію моделі як інцидент у продакшн

Тому що це так і є. На відміну від падаючих подів (pods) або failing endpoints, тиха деградація моделі залишається непоміченою — модель продовжує відповідати, але її відповіді стають слабшими, упередженими або просто неправильними. Користувачі не бачать помилок 500; вони отримують галюцинації, токсичні результати або хибні рішення. Це не просто баг — це втрата довіри. У світі AI правильність — це доступність. Коли надійність означає якість, деградація — це простій (downtime).

Gateway API Inference Extension, OpenInference і ШІ-шлюзи

Можливо, ми не просто розширимо Kubernetes для AI — можливо, нам зрештою доведеться його форкнути.

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

Inference workloads вимагають тісно інтегрованих рішень для апаратного прискорення, оркестрації ресурсів та контролю трафіку з високою пропускною здатністю. Екосистема Kubernetes наздоганяє з ініціативами, такими як WG-Serving (націлений на оптимізоване обслуговування AI/ML), Device Management (зосереджений на інтеграції GPU/TPU через DRA) і нове розширення Gateway API Inference Extension, яке закладає основу для масштабованої та безпечної маршрутизації LLM endpoints. Тим часом, нові AI-шлюзи заповнюють прогалину — забезпечуючи логіку маршрутизації, спостережуваність і контроль доступу, адаптовані до інференсу.

Тим не менш, ми накладаємо AI на систему оркестрування, яка спочатку не була призначена для цього. Оголошення Google про підтримку 65K nodes кластерів Kubernetes шляхом заміни etcd на сховище на основі spanner натякає на майбутнє, де можуть знадобитися фундаментальні зміни. Можливо, ми не просто розширимо Kubernetes для AI — можливо, нам зрештою доведеться його форкнути (fork).

Отже, як ми застосовуємо практики SRE до цієї нової реальності?

• Визначаємо цілі рівня обслуговування (SLO/SLA), орієнтовані на AI: Виходимо за межі uptime, включаючи цілі щодо accuracy, fairness, latency, та drift targets. Встановлюємо чіткі зобов’язання (SLA) для метрик, таких як TTFT (Time To First Token) і TPOT (Time Per Output Token), точність або межі упередженості (bounds on bias).
• Будуємо спостережуваність: Впроваджуємо надійний моніторинг за допомогою інструментів, таких як OpenTelemetry і Grafana, але доповнюємо їх платформами трасування та оцінки, специфічними для AI (OpenInference), щоб відстежувати такі метрики, як model response distribution, показники confidence scores та типи помилок (наприклад, галюцинації).
• Розробляємо реагування на інциденти AI: Створюємо сценарії спеціально для збоїв AI, таких як раптовий дрейф або сплески упередженості. Впроваджуємо автоматичні відкати до стабільних версій моделі або автоматичні вимикачі (circuit breakers).
• Проектуємо для масштабування та безпеки: Використовуємо такі техніки, як балансування навантаження між репліками моделі, кешування, оптимізоване планування GPU (область, яка все ще розвивається в Kubernetes) та AI-шлюзи для управління трафіком, безпекою (як обмеження швидкості на основі токенів, семантичне кешування) та авторизацією. Захищаємо цілісність моделі (integrity) через відстеження походження (provenance tracking), безпечне розповсюдження та моніторинг під час виконання.
• Постійна оцінка (Continuous Evaluation): Оцінка моделі — це не одноразове завдання. Вона охоплює попереднє розгортання (офлайн-тести), передрелізне тестування (shadow/A-B тести) та постійний моніторинг після розгортання на предмет дрейфу та деградації.

Приклад SLA для оцінки моделі в продакшні

AI Gateways: Інструмент SRE для епохи штучного інтелекту

У ранні дні SRE ми покладалися на loadbalancers, service mesh та API-gateways для управління трафіком, забезпечення політик і підтримки спостережуваності. Сьогодні inference workloads вимагають того ж — але з більшою складністю, більшим масштабом і набагато меншою толерантністю до затримки або збоїв. Ось тут на сцену виходять AI Gateways.

Вважайте їх універсальним інструментом сучасного SRE для AI: маршрутизація запитів до правильної моделі, балансування навантаження між репліками, забезпечення обмежень швидкості та політик безпеки, і надання глибоких можливостей спостережуваності — все одночасно. Проекти на кшталт Solo AI-Gateway імплементують ці ідеї. Вони вирішують проблеми enterprise рівня, такі як контроль вартості моделі, безпека на основі токенів і трасування відповідей LLM у реальному часі — проблеми, для яких традиційні service mesh не були створені.

Це те місце, де SRE затребуваний сьогодні: не просто налаштовувати autoscalers, а керувати control plan інтелектуальних систем.

AI-gateway — це новий інструмент в нашому портфелі — і, можливо, найважливіший.

Третя епоха SRE — це AI Reliability Engineering

Наша роль як SRE еволюціонує. Нам потрібна допитливість (curiosity), описана в «97 Things Every SRE Should Know» , більше, ніж будь-коли — прагнення зрозуміти всю систему, від кремнію до нюансів поведінки моделі. Ми повинні будувати AI, якому можна довіряти, використовуючи екосистему інструментів і стандартів, що з’являється.

Бйорн Рабенштайн (Björn Rabenstein) говорив про «третю епоху» SRE, де її принципи стають загальноприйнятими. Хоча це правда, але нова ера явно формується штучним інтелектом. AI Reliability Engineering — це не просто розширення SRE, це фундаментальне переосмислення, яке зміщує фокус з надійності інфраструктури на надійність самих інтелектуальних систем.

Тому що якщо Inference дійсно є новою веб застосунком, то забезпечення його надійності (Reliability) — це нова Епоха SRE. Ненадійний АІ гірше, ніж відсутність АІ взагалі