Model Serving

Модель — не повільна частина

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

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

Три форми подачі — і зазвичай виграє найдешевша

Перш ніж будувати сервіс, дайте відповідь на менше питання: чи мусить передбачення робитися, поки користувач чекає? Дуже багато — ні. Якщо множина обʼєктів, про які ви передбачаєте, відома наперед і змінюється повільно — клієнти, товари, рахунки, — можна рахувати передбачення за розкладом, писати їх у таблицю, а застосунок хай читає рядок. Це не компроміс, а архітектура подачі без p99, без автомасштабування й без холодного старту.

• Пакетна (наперед)

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

• Онлайн (на запит)

  Сервіс, що бере вхід і повертає передбачення. Потрібен, коли вхід приходить разом із запитом: пошуковий запит, кошик, форма. Усе складне на цій сторінці — саме про цю форму.

• Потокова

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

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

Батчинг, прискорювачі й правильний сигнал масштабування

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

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

Викотити версію, не ставлячи на неї все

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

• Тінь

  Слати справжній трафік у нову версію й викидати її відповіді, порівнюючи офлайн. Нульовий ризик для користувача — ловить затримку, падіння й skew, поки це нікого не зачепило. Ціна: подвійний інференс.

• Канарка

  Скерувати малу частку трафіку в нову версію й дивитися на експлуатаційні метрики. Відповідає на «чи вона виживає у проді», а не «чи вона краща»: для цього потрібен експеримент.

• A/B-експеримент

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

• Закріплений відкат

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

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

За точністю не постежиш — стежте за тим, що можна

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

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

• Експлуатаційний: процентилі затримки, частка помилок, глибина черги, насичення. Ламається першим — і тоді однозначно.
• Входи: розподіл кожної ознаки проти тренувального зрізу плюс частка порожніх значень і небачених категорій. Саме тут заявляє про себе зміна вище за течією.
• Виходи: розподіл передбачень і, для класифікаторів, оцінок. Модель, чия частка позитивів подвоїлася за ніч, каже вам щось іще до появи будь-якої мітки.
• Бізнес-проксі, що розвʼязуються швидко, — клікабельність, частка прийняття, частка ручних скасувань операторами — як найраніший сигнал, скорельований із результатом, якого ще не виміряти.

Антипатерни, які варто назвати

• Передбачення, залоговані без версії моделі, вектора ознак і мітки часу, — після чого будь-яке пізніше питання лишається без відповіді.
• Онлайн-сервіс, збудований для входів, відомих ще звечора, який платить за p99, що нікому не був потрібен.
• Препроцесинг, переписаний усередині сервісу замість спільного з тренувальним пайплайном, — skew за побудовою.
• План відкату, що означає перетренування, бо попередній артефакт перезаписано, а дані вже пішли далі.
• Алерт про дрейф без власника й без визначеної дії, який вимикають протягом місяця після першого сезонного хибного спрацювання.

Коли це застосовувати

Пов’язані сторінки

• ІнфраструктураML-пайплайниML-пайплайн — це автоматизований шлях від сирих даних до моделі, яку можна розгорнути. Натренована модель — це артефакт збірки, а не код. Вона постає з чотирьох входів — даних, тренувального коду, конфігурації та середовища, — і лише один із них лежить у вашому репозиторії. Саме тому клонування репозиторію й запуск скрипта дає вам іншу модель. Пайплайн існує, щоб усі чотири були записані, повторювані й доступні для перевірки. На цій сторінці — стадії та чому вони окремі, чому дані ламаються тихо, а код гучно, що таке skew, який робить чудову офлайн-модель марною онлайн, і коли ноутбука справді достатньо.
• ІнфраструктураKubernetesKubernetes — це цикл керування з API перед ним. Ви не наказуєте йому запустити контейнер: ви записуєте бажаний стан, а контролери постійно звіряють цей запис із тим, що працює насправді, і діють на різницю — завжди, а не один раз. Кожен обʼєкт, який він пропонує, і кожна його несподівана поведінка походять звідси. На цій сторінці — сам цикл, кілька обʼєктів, що справді важать, чому ліміти ресурсів і перевірки здоровʼя спричиняють більшість інцидентів у проді й коли все це вам справді потрібне.
• РозробкаLLMOpsLLMOps — це практика тримати в продакшені фічу, побудовану на мовній моделі, і вона існує тому, що все, що робить програму придатною до релізу — тест, який падає, дифф, що пояснює зміну, відкат, який повертає вчорашній стан, — припускає, що той самий ввід дає той самий вивід. LLM-функції це припущення ламають, тож практики доводиться перебудовувати навколо цього. На цій сторінці — що заступає набір тестів, чим насправді є артефакт розгортання, що записувати на кожному виклику і як поводяться вартість і затримка, коли приходить справжній трафік.