Англійська для Ray Serve Developers

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

Ключовий словник

** Розгортання ** — одиниця Ray Serve, що представляє частину логіки обслуговування (часто модель), налаштовану з власними вимогами до ресурсів, правилами автоматичного масштабування і кількістю реплік. “Надати вбудованій моделі її власне розгортання замість того, щоб з’ єднувати її з тим же процесом, що і модель генерації — вони масштабуються за абсолютно різних шаблонів завантаження.”

** Реплікація ** — запущений екземпляр розгортання, який обробляє вхідні запити; Ray Serve балансує навантаження між реплікаціями і може збільшувати або зменшувати їх кількість. “Ми запускаємо дві репліки і бачимо чергу під навантаженням — збільште кількість реплік або перевірте, чи дійсно налаштовано автоматичне масштабування для цього розгортання.”

** Автомасштабування ** — Механізм Ray Serve для автоматичного коригування кількості реплік для розгортання на основі завантаження запитів, уникаючи як надмірного забезпечення, так і чергування запитів. “Автомасштабування встановлено на фіксовану мінімальну кількість реплік — саме тому ми бачимо пік затримки холодного запуску, коли трафік зростає після бездіяльності.”

** Графік розгортання / композиція ** — поєднання декількох розгортань разом, щоб один запит проходив через декілька моделей або кроків обробки, кожен з яких може бути незалежно масштабований. “Модельуйте це як графік розгортання — крок переранжування не повинен бути вбудований у розгортання пошуку, оскільки вони мають масштабуватися незалежно під різним навантаженням.”

** Маршрутизація запитів ** — спосіб, яким Ray Serve направляє вхідні запити до наявних реплік правильного розгортання, включаючи обробку зворотного тиску, коли всі репліки зайняті. “Перевірте налаштування маршрутизації запитів, перш ніж припустити, що це проблема моделі — можливо, що запити чекають в черзі на маршрутизаторі, а не не спрацьовують всередині самої моделі.”

Звичайні фрази

• Чи це має бути його власне розгортання, чи він належить до чогось, що масштабується таким же чином?»
• Чи є кількість реплік фіксованою, або автомасштабування дійсно налаштоване для цього розгортання?
• Чи буде графік розгортання мати більше сенсу тут, ніж поєднання цих кроків в одне розгортання?»
• «Чи це проблема рівня моделі, чи запит маршрутизації чекає в черзі, перш ніж він навіть досягне репліки?»

Приклади висловлювань

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

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

Перегляд пропозиції щодо архітектури: “Не згортайте ці три моделі в одне розгортання лише для спрощення коду — графік розгортання зберігає їх незалежно масштабованими, що важливо, коли трафік зростає.”

Професійні поради

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

Практичні вправи

1. Поясніть співробітнику команди, чому дві моделі з різними шаблонами завантаження повинні бути окремими розгортаннями.
2. Описати, як мінімальний рівень автоматичного масштабування однієї репліки може призвести до піків затримки холодного запуску.
3. Напишіть речення, у якому буде запропоновано графік розгортання замість вручну створеної оркестрації для багатомодельної конвеєрної системи.

На практиці: навігація нюансів в комунікації

Для людей, для яких англійська не є рідною мовою, але які працюють з технологіями, такими як Ray Serve, важливо не тільки володіти технічними термінами, але і * як * ці терміни використовуються в професійному спілкуванні. Легко зрозуміти визначення «автомасштабування» - системи, яка автоматично коригує ресурси на основі попиту - але передавати це розуміння чітко і впевнено під час перегляду коду або пояснювати свою роботу зацікавленим сторонам вимагає іншого набору навичок. Простий, буквальний переклад часто не вистачає, що призводить до непорозумінь і затримок. Ключовим є розпізнавання тонких нюансів у фразуваннях і прийняття спільних професійних шаблонів англійської мови.

Розгляньте цей сценарій: ви розгорнули нову модель для Ray Serve, і під час перегляду коду, старший розробник коментує ваш PR опис: “Це число реплік здається надмірно високим для поточного трафіку. Чи можете ви пояснити налаштування автоматичного масштабування?» Негайною реакцією може бути просто заява: « Я збільшив його, оскільки це здалося мені хорошою ідеєю ». Це не допоможе. Ефективнішою відповіддю є підтвердження вашого занепокоєння і пояснення ваших міркувань за допомогою точного словника. Ви можете сказати: « Я збільшив початкову кількість реплік до * рахунку для потенційних пікових навантажень * під час фази розгортання, як це описано у нашій стратегії моніторингу. Правила автоматичного масштабування встановлено для динамічного коригування на основі використання процесора, з метою оптимізації ефективності ресурсів * без втрати затримки *. Я задокументував обґрунтування і визначив ключові показники — такі як середній час відповіді і рівень помилок — які ми можемо контролювати після розгортання. “Зверніть увагу, як такі фрази, як “рахунок для потенційних пікових навантажень”, “оптимальна ефективність ресурсів” і “ключові показники” використовуються для демонстрації глибшого розуміння поведінки системи.

Іншою поширеною ситуацією є пояснення можливостей Ray Serve команді, яка не знайома з моделями обслуговування. Замість того, щоб просто сказати: «Ми використовуємо Ray Serve для автомасштабування», ви можете сформулювати це так: «Ray Serve дозволяє нам * ефективно розгортати і масштабувати наші моделі по кількох вузлах * - по суті, створюючи декілька «реплік» одночасно. Це означає, що ми можемо обробляти зростаючий трафік без значних піків затримки, і система автоматично коригує кількість реплік на основі попиту. Ми використовуємо вбудовані функції автомасштабування, щоб підтримувати постійний рівень обслуговування. “Знову ж таки, акцент робиться на тому, як Ray Serve досягає цього масштабування, а не просто заявляє, що це робить.

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

# autoscaling --scale-up 10 --scale-down 5

Ця команда, за допомогою інтерфейсу командної рядки Ray, показує просту операцію масштабування — збільшення кількості реплік на 10 і зменшення її на 5 за допомогою заздалегідь визначених параметрів. Зрозуміти такі команди досить просто, але * причина * їх виконання і метрики, за якими слідкуватимуть після їх виконання, є тим, що має справжнє значення у професійному спілкуванні щодо розгортання Ray Serve.