Докупать нельзя доиспользовать: как AI‑ассистент дорос до production

Многие AI‑проекты начинаются похоже: подняли модель, подключили API, добавили RAG, показали первое демо. Когда сервис доезжает до production, появляются реальные документы, длинные сессии, несколько активных пользователей, очередь запросов, рост KV‑cache и нестабильная задержка. Первая реакция понятна: сервису не хватает GPU.

Дальше становится интереснее. Часто проблема не только в количестве карт. Важно понять, как запускается модель, сколько памяти съедает KV‑cache, какой профиль GPU нужен конкретному сервису и как этот профиль потом выдать в кластере.

В докладе покажу, как мы решаем это в Deckhouse Kubernetes Platform (DKP). Первый слой — планировщик инференса. Он до запуска оценивает модель и сам сервис: формат и размер модели, квантование, контекст, число активных сессий, KV‑cache, требования к задержке, доступные ресурсы кластера и допустимые режимы запуска. После этого появляется план запуска: среда исполнения, профиль GPU, режим шаринга, размещение и параметры, которые дальше проверяются по метрикам.

Второй слой — контур управления GPU. Построенный план нужно исполнить на реальном железе. Здесь появляются DRA‑заявки, GPU‑инвентарь, подготовка ресурса на узле, жизненный цикл MPS‑сервера для шаринга GPU и scheduler extender. Он помогает выбирать стратегию размещения: плотнее упаковывать небольшие сервисы, разводить чувствительные к задержке нагрузки, учитывать профили GPU и текущее состояние кластера.

Сквозной пример — AI‑ассистент с RAG. На нем покажу, как один сервис раскладывается на разные нагрузки: основная LLM, embeddings, reranker, draft‑модель, OCR/STT/TTS и агентные сценарии. У каждой части свой профиль. Где-то нужна целая GPU, где-то MIG, где-то MPS‑доля, где-то важна связность, а где-то достаточно короткого доступа к ускорителю.

После доклада у слушателя останется понятный порядок действий: взять требования к AI‑сервису, оценить реальные ресурсы для его запуска, разложить сервис на разные типы нагрузок, выбрать для них подходящие GPU‑профили и проверить решение по метрикам. После этого разговор про новый GPU‑бюджет становится предметным: видно, где действительно нужен новый ресурс, а где еще можно доиспользовать существующий парк.