Чому розпізнавання облич падає під навантаженням
Компанія впровадила верифікацію облич для 150 000 співробітників і отримала пік 8500 запитів на хвилину. Перехід із синхронних викликів Azure Face API на асинхронну архітектуру з розділенням розпізнавання й верифікації дав p99-затримку 1,8 секунди навіть коли у хмарного провайдера зростала затримка. Фільтрація поганих кадрів на пристрої відсіяла 2,1 мільйона непридатних знімків і скоротила витрати на хмарний інференс на 30%.
Окремо: доступ до Azure Face API тепер обмежений програмою Responsible AI — заявку на використання розглядають 3–5 тижнів.
Чому синхронні запити не витримують навантаження
У пікові хвилини — коли тисячі співробітників намагаються пройти верифікацію одночасно — кожен синхронний виклик до хмарного API відкриває окреме HTTP-з'єднання. Якщо провайдер відповідає з затримкою навіть у пару секунд, пул з'єднань вичерпується, черги ростуть каскадом, і система не сповільнюється, а падає повністю. Саме тому в описаному кейсі відмовились від прямого виклику Azure Face API на кожен запит і перейшли на чергу з асинхронною обробкою.
Окрема проблема — якість вхідних кадрів. Реальні користувачі тримають телефон під кутом, стоять проти вікна або мають забруднену камеру, і без попереднього відсіювання таких кадрів собівартість помилкових запитів до хмарної моделі однаково списується.
Розділення розпізнавання і верифікації
У новій архітектурі детекція обличчя (чи є на кадрі взагалі обличчя, придатне для розпізнавання) винесена в окремий сервіс від верифікації (порівняння з еталонним профілем). Це різні за навантаженням процеси: детекція — обчислювально важка, але не залежить від стану, тоді як верифікація тягне за собою звернення до бази з еталонними шаблонами і залежить від швидкості цієї бази.
- Під час пікового навантаження сервіс детекції масштабувався з 4 до 8 інстансів
- Сервіс верифікації при цьому тримався на стабільних 2 інстансах
- Детекція відсіює непридатні кадри ще до того, як вони доходять до верифікації, тому останній не потрібно масштабувати так само агресивно
Що дає фільтрація на пристрої
Найдешевше місце відсіяти непридатний кадр — до того, як він взагалі покине пристрій користувача. Клієнтська перевірка положення голови, освітлення та розмиття дозволила відкинути 2,1 мільйона непридатних знімків ще на етапі захоплення. Показник розрахували, порівнявши місяць без такої фільтрації з наступним місяцем, коли її увімкнули.
Результат — економія до 30% витрат на хмарний інференс, оскільки платити за розпізнавання завідомо бракованого кадру більше не потрібно.
Обмежений доступ до Azure Face API
Окремий бар'єр для будь-якої команди, що планує подібний проєкт: функції ідентифікації та верифікації в Azure Face API більше не доступні за замовчуванням, а підпадають під програму Responsible AI з обов'язковим формальним заявленням про сценарій використання, політику зберігання даних і дотримання відповідальних практик роботи з ШІ.
- Розгляд заявки на доступ, за досвідом 2026 року, займає 3–5 тижнів
- Щоб не блокувати розробку на цей час, у джерелі рекомендують закладати в архітектуру mock-провайдера — заглушку, яка дозволяє тестувати чергу і логіку системи, поки заявка на реальний доступ ще розглядається
Ціни на використання API та точні умови програми Responsible AI в матеріалі не наводяться.