Податок DevOps: справжня вартість self-hosting AI не в GPU.
Рядок, який ніхто не закладає в бюджет, це час інженерів: битви з драйверами, версії CUDA, налаштування serving-стека, Kubernetes. Чому погодинна ставка GPU ніколи не була числом, яке має значення.
У цій статті 2 розділів
- Найбільша прихована вартість у self-hosted AI є часом інженерів, а не погодинною ставкою GPU.
- Сумісність драйверів і CUDA, вибір квантування, налаштування serving-стека та Kubernetes з'їдають тижні до того, як буде віддано перший токен.
- Сирий GPU cloud вручає вам обчислювальні ресурси й рахунок; під'єднання всього цього мовчки лягає на вашу зарплатну відомість.
- Managed-альтернатива: ваша команда викликає endpoint, наші інженери підтримують його в роботі. Ви не наймаєте інженера MLOps, ви отримуєте нашого.
Оцініть GPU-сервер, і ви отримаєте чисте число. Оцініть, скільки потрібно, щоб перетворити цей сервер на робочий inference endpoint, і число розпливається: версія драйвера, яка не погоджується з набором інструментів CUDA, serving-фреймворк, якому потрібне інше ядро, квантування, якому, як виявляється, потрібно більше VRAM, ніж писалося в блозі, шар Kubernetes, якого навантаження не потребувало. Нічого з цього не з'являється в рахунку. Усе це з'являється у вашій зарплатній відомості.
Податок, рядок за рядком
Ось що стоїть між картою в стійці та endpoint, якому ваш застосунок може довіряти, у порядку надходження. Кожен рядок є часом інженерів, і кожен рядок повторюється: стек, який працював у день встановлення, має продовжувати працювати через кожне наступне оновлення.
Burn-in.
Доведіть, що карта й хост здорові, перш ніж будь-що від них залежатиме: тривале навантаження, температури, пам'ять, живлення. Карту, яка тротлить під першим реальним batch, краще знайти першого дня, а не в день запуску.
Узгодження драйвера й набору інструментів.
Ядро, драйвер, набір інструментів CUDA, середовище виконання контейнерів і serving-фреймворк мають погоджуватися між собою. Вони погоджуються в день, коли ви їх закріпили. Кожне оновлення будь-якого з них знову відкриває це питання.
Пакування моделі.
Ваги, токенізатор, квантування і бюджет VRAM, що з них випливає. Вибір квантування вирішує, чи вміститься модель, як швидко вона відповідає і скільки якості віддає, а опубліковані числа є відправною точкою, а не гарантією для вашого обладнання.
Налаштування serving-стека.
Batching, довжина контексту, розмір KV-cache і паралелізм, налаштовані під вашу ціль latency, а не під типові значення фреймворку. Саме тут живе більша частина пропускної здатності, і це робота, якої ніхто не бачить, коли вона зроблена добре.
Обв'язка endpoint.
TLS, автентифікація, приватний мережевий шлях до застосунку, який його викликає, і рішення про те, що доступне звідки. Inference endpoint, доступний з публічного інтернету, є зобов'язанням раніше, ніж функцією.
Спостережуваність.
Стан карти, тиск на VRAM, глибина черги й перцентилі latency, за якими хтось справді стежить. GPU, що тихо працює на половині швидкості, виглядає точно як здорова на панелі, яка перевіряє лише те, чи процес запущений.
Оновлення, зі шляхом назад.
Оновлення моделі, драйвера і стека, застосовані за графіком, перевірені до того, як вони приземляться, з відпрацьованим rollback. Пропуск оновлень купує тишу на деякий час, а потім дуже гучний тиждень.
Навантажувальний тест.
Доведіть, що endpoint тримає ваш паралелізм при вашій цілі latency, перш ніж будь-що від нього залежатиме. Перший раз, коли endpoint бачить реальний трафік, не має бути першим разом, коли хтось його виміряв.
Чергування.
Коли це ламається о 3-й ночі, хтось має за це відповідати. Не за графіком у таблиці: інженер, який знає стек, не спить і має доступ.
Які рядки зникають, коли люди, що поставили карту в стійку, також розгортають стек
Усі, крім двох. Ви все ще обираєте модель і все ще пишете застосунок, який її викликає. Burn-in, закріплення версій, налаштування serving-стека, приватний endpoint, моніторинг, оновлення, навантажувальний тест і чергування залишаються з людьми, яким належить обладнання і які вже несуть це за кожну іншу машину в залі. Ми запускаємо inference на власних GPU, тож список походить із практики.
Не карту погодинно. Приватний endpoint, який відповідає з узгодженою latency, на машині з одним орендарем, підтримуваний актуальним інженерами, які знають стек, бо вони його зібрали. Погодинна ставка є найменшим числом на сторінці.
Прямі відповіді
Хіба ми не можемо просто скористатися посібником зі встановлення від постачальника?+
Посібники припускають одну карту, один драйвер, одну версію фреймворку, застиглі в часі. Робоче середовище означає, що комбінація продовжує працювати через оновлення, під навантаженням, при вашій цілі latency. Це обслуговування і є податком; встановлення ніколи не було важкою частиною.
Чи означає managed, що ми втрачаємо root?+
Ні. Машина є вашою і з одним орендарем; скільки стека несемо ми, узгоджується з кожним клієнтом: одні беруть ключі й керують усім, інші передають нам serving-шар і залишають собі застосунок.
Що насправді робить ваша команда на постійній основі?+
Закріплює версії драйверів і CUDA, розгортає й налаштовує serving-стек, стежить за картою та endpoint 24/7 і застосовує оновлення моделі й стека за графіком, який ви затверджуєте. Коли щось ламається, ми це лагодимо, о будь-якій годині.
Принесіть нам модель, яку хочете запустити
Ми підбираємо GPU, розгортаємо стек і вручаємо вам приватний endpoint. Податок DevOps залишається з нами.
Переглянути GPU serversВи дійшли до кінця.
Застосуйте прочитане на практиці
Що ви запускаєте?
Розкажіть нам про навантаження, трафік і вимоги до відновлення. Почніть з конструктора сервера або обговоріть деталі з інженером.
Написано інженерами, які будують і експлуатують інфраструктуру, про яку йдеться.Поговоріть з інженером