Ваш AI-провайдер — це єдина точка відмови
Минулої п'ятниці Міністерство торгівлі США надіслало листа Anthropic. До вечора того ж дня Fable 5 та Mythos 5 зникли.
Їх не виводили з експлуатації. Їх не обмежували. Вони просто зникли.
API-виклики повертали помилки 404. Живі сесії переривалися посеред розмови. Додатки, що залежали від цих моделей, перестали працювати. Це сталося через три дні після запуску. Не було ні попередження, ні вікна для міграції.
Нам пощастило, тому що ці моделі були новими. Ніхто ще не побудував на них глибоких залежностей. Уявіть, що таке стається з моделлю, яку ви використовуєте щодня протягом шести місяців.
Якби державний лист міг вимкнути вашу основну базу даних, чи запустили б ви її без механізму відмовостійкості (failover)? Ні. Проте більшість команд роблять саме це з AI.
Багато команд ставляться до AI як до електрики. Ви клацаєте вимикачем і очікуєте світла. Ви не думаєте про джерело або про те, що станеться, коли електроенергія зникне. Ви обираєте модель, жорстко прописуєте endpoint і запускаєте продукт.
Це не інженерія. Це архітектура, заснована на надії.
Моделі можуть зникати через:
- Регуляторні причини
- Зміни в політиці
- Геополітичні питання
Ситуація з Anthropic не була багом чи збоєм інфраструктури. Це був регуляторний «вимикач» (kill switch).
Ви повинні закласти стійкість у свій рівень моделей. Використовуйте такі патерни:
- Абстрагуйте виклики моделей. Використовуйте інтерфейс, щоб вашому додатку було байдуже, який провайдер надає відповідь.
- Використовуйте декількох провайдерів. Зміна провайдера має бути зміною конфігурації, а не повним переписуванням коду.
- Використовуйте моделі з відкритими вагами (open-weight models). Якщо ви запускаєте модель самостійно, ніхто не зможе вимкнути її віддалено. Такі моделі діють як генератор, коли в мережі зникає світло.
- Впроваджуйте поступову деградацію (graceful degradation). Менша або старіша модель — це краще, ніж непрацюючий додаток.
Моніторте рівень помилок. Якщо він різко зростає, «вимикайте автомат» і перенаправляйте трафік на резервний варіант (fallback).
Ставтеся до свого AI як до будь-якої іншої критично важливої виробничої залежності. Проектуйте з урахуванням можливих відмов.
Чи передбачає ваша архітектура можливість відмови вашого провайдера? Якщо ні, ви в зоні ризику.
Чи впровадили ви резервування від декількох провайдерів у свій стек? Пишіть у коментарях.
Source: https://dev.to/aws/your-ai-provider-is-a-single-point-of-failure-26i2
Optional learning community: https://t.me/GyaanSetuAi