Розгортання та оптимізація LLM-інференсу в продакшні на GPU від L4 до 4xH200: вибір інференс-двигунів та конфігурацій, баланс між пропускною здатністю, затримкою та вартістю, а також як «вичавити» максимум із обладнання й уникнути типових помилок тюнінгу

Останні місяці ми будували один із піддоменів нашого проєкту з кредитування, більшість коду в якому писав ШІ під архітектурним наглядом: 100 сторей за 26 днів, 12 репозиторіїв, ≈218 500 рядків коду, 44 ADR, включаючи вимоги PCI DSS і НБУ, де ціна архітектурної помилки доволі висока. Цей досвід змінює погляд на роботу архітектора при плануванні проєктних рішень. Хоча інструменти штучного інтелекту допомагають автоматизувати та прискорити розробку, але фактично відповідальною за результат залишається людина. ШІ за замовчуванням не мислить стратегічно, і часто обирає найпростіший шлях реалізації, що може призводити до негативних результатів в майбутньому, якщо людина явно не опише стратегію при постановці завдання. Тож чим більшої автономності ми хочемо від ШІ, тим вища кваліфікація потрібна людині поруч: залишаються рішення, які не можна делегувати, хоч якою розумною стане наступна модель. Сучасні методології (ADR, quality gates, ATAM, TOGAF) в епоху ШІ трансформуються і дозволяють досягати якіснішого результату з вищою автономією. Про це ми і поговоримо на моїй доповіді. Доповідь для архітекторів, тімлідів і сеньйорів, які вже спробували ШІ та прагнуть підвищити результативність та автономність своїх команд.

Як би ви назвали техліда який читає і перевіряє кожен рядок коду, що написала його команда? Для мене це не риторичне питання: у своїй кар'єрі я мав досвід побудови процесів контрібюшину для одного з найбільших репозиторіїв в Grammarly для сотні інженерів кожного місяця. Сьогодні кожен із нас став тімлідом команди АІ агентів і ми задаємо собі і один одному аналогічне питання: як називати людину що не читає код, який генерують його агенти? Не вдаваючись в усю глибину контроверсійності цього питання, я вважаю що фундаментально відповідь для нього ідентична для команди людей і команди агентів. Правильно побудовані процеси дозволяють ліду уникати мікроменеджменту і рев'ю кожного рядка в пул реквесті. У цій доповіді я покажу прагматичні рецепти побудови АІ розробки, що наблизитимуть вас до довіри до коду, написаного вашими АІ агентами.

Кілька років тому ми почали будувати Architecture as Code з доволі простою метою: зробити архітектурні знання доступними, актуальними та зрозумілими для інженерів. C4-діаграми, ADR, OpenAPI, ERD, ownership та інша документація поступово переїхали ближче до коду, стали version-controlled і machine-readable. Ми робили це для людей. А потім прийшли AI-агенти. І несподівано виявилося, що один із найскладніших етапів роботи з AI — передача агенту контексту про систему — у нас уже майже вирішений. У цій доповіді поговоримо про те, чому доступу до репозиторію недостатньо, чим code context відрізняється від system context і як практики Architecture as Code природно перетворюються на Context Engineering. На реальних прикладах розберемо, який контекст потрібен AI-агенту, щоб він не просто писав код, а розумів домени, архітектурні рішення, API-контракти, ownership та обмеження системи. А також поговоримо про наступний виклик: як переконатися, що контекст, на який спирається AI, відповідає реальному стану системи.

Аgentic PDLC - агент більше не просто пише або переглядає код — він висуває гіпотези та тестує їх в production. Як переорієнтувати архітектуру для автономних агентських циклів, які працюють 24/7 на системах з мільйонами користувачів? Використовуючи досвід Ентерпрайз компанії, розберемо, як перейти від людського контролю до event-driven governance та явних guardrails для агентів.

У міру того, як команда зростає, з`являються нові продукти, а інженерна команда проходить етапи трансформації - роль CTO легко перетворюється з технічного лідера на менеджера, що дивиться у таблиці та аналітику. І саме в цей момент настає найскладніше: не втратити технічний контекст, не відстати від архітектури, і реального стану справ у командах. У цій доповіді я поділюся власним досвідом: як залишатися Hands-on CTO - зберігати глибоке розуміння технічної бази, впливати на архітектуру й одночасно масштабувати компанію, не перетворюючись на "менеджера без коду". Основні теми, які ми розглянемо: - Як змінюється роль CTO у міру росту компанії - від кодера до системного лідера. - Найпоширеніші пастки: втрата архітектурної пам’яті, розрив між бізнесом і технічкою, залежність від кількох ключових людей. - Хороші звички, що допомагають утримувати технічний контекст: code-review, архітектурні стендапи, "walk the code", R&D-спринти CTO. - Системи прийняття рішень: як використовувати ADR / RFC, щоб зберігати прозорість і контроль. - Комунікація з техлідерами: ефективні формати 1:1, технічні сінки. - Інструменти та платформи, які допомагають не втратити контекст - дашборди, системи моніторингу, архітектурні огляди.

Дискусія з представниками високоризикових систем про те, чому архітектуру безпеки потрібно закладати ще на етапі проєктування та розробки, а не додавати після виходу в продакшен. Ми поговоримо про ризики відкладеної реалізації контролів, поширені ілюзії безпеки та практичні підходи до інтеграції безпекових практик у роботу продуктових команд.

Ви коли-небудь замислювались, що насправді відбувається під капотом розподілених систем? Не тих, що «типу кластер» на 3 ноди, а справжніх, що на ексабайтних масштабах? На цій доповіді ми разом зазирнемо за лаштунки сучасної інфраструктури. Як працюють системи, що обробляють гори даних? Які патерни, принципи та інженерні рішення ховаються за scalable архітектурами? Обговоримо: * Як виглядає життя розподіленої системи зсередини * Чим відрізняється розподілений застосунок від справжньої системи * Як схеми зберігання даних трансформуються у сучасні БД, черги й логи * Чому PostgreSQL у клауді, це вже не PostgreSQL? * Чим Northguard крутіший за Kafka? * Як працюють нові гравці типу NewSQL? Якщо ви архітектор, техлід, розробник або просто хочете зрозуміти, чому інфраструктура масштабується так, як масштабується - приходьте! Поділюся інсайтами, які, можливо, зможете застосувати у власних проєктах або розглянете їх під іншим кутом. P.S. І так, буде трохи магії ✨та багато правди про розподілені системи, які рухають цей світ ?

Презентація буде сфокусована на maintainability quality attribute - як зробити бізнес-логіку ізольованою, консолідованою, інкапсульованою та консистентною. А також як інтегрувати її з інфраструктурою зберігання, обміну повідомленнями, etc. Розглянемо особливості застосування таких підходів: - OOD / Rich Domain Model / DDD - Hexagonal layered architecture - CQRS/Persistance/ORM Всі особливості будуть продемонстровані на прикладі реального завдання та підходу до його реалізації (приклади коду будуть на .NET)