Здоровый Kubernetes-кластер и занятые GPU могут соседствовать с жалобами пользователей на долгие ответы модели. Медленный ИИ-инференс не всегда виден в привычных метриках инфраструктуры: для российских команд это повод измерять не только загрузку железа, но и весь путь запроса от клиента до готового ответа.
На эту проблему обращает внимание The New Stack: сервис с моделью может формально работать без сбоев, а его Kubernetes-поды — оставаться доступными, но итоговая задержка всё равно будет неприемлемой для пользователя. Иными словами, дашборд с зелёными статусами не отвечает на главный вопрос: сколько времени человек или приложение действительно ждут результат.
В классической эксплуатации Kubernetes команда обычно смотрит на состояние нод, рестарты контейнеров, доступность сервисов, использование CPU, памяти и ускорителей. Этот набор необходим, но для генеративных моделей он описывает лишь состояние платформы. GPU может быть занят полезной работой, очередь запросов — расти, а отдельный запрос — задерживаться на этапе подготовки данных, ожидания свободного слота, сетевого обмена или выдачи ответа клиенту.
Особенность инференса в том, что средняя загрузка ускорителя плохо передаёт пользовательский опыт. Высокая загрузка иногда означает хорошую утилизацию дорогого ресурса. Но она же может говорить, что сервис уже не успевает принимать новые запросы с нужной скоростью. Низкая загрузка тоже не гарантирует победу: модель может ждать данные, упираться в CPU, сеть, хранилище, ограничения контейнера или неудачно настроенное распределение нагрузки.
Поэтому наблюдаемость для AI-сервиса должна начинаться с запроса, а не с пода. Команде полезно видеть время ожидания в очереди, длительность обработки, время до первого фрагмента ответа для потоковой выдачи, число успешно завершённых запросов и долю ошибок. Эти показатели стоит сопоставлять с данными Kubernetes и GPU: тогда становится понятно, связана ли деградация с дефицитом ускорителей, с поведением модели или с обвязкой вокруг неё.
Особое внимание требуется хвостовым задержкам. Среднее время ответа может выглядеть прилично, пока небольшая, но заметная часть запросов зависает существенно дольше остальных. Для чат-бота это превращается в ощущение «модель думает слишком долго», для внутреннего API — в таймауты и повторные запросы, которые дополнительно нагружают систему. В результате команда видит больше трафика и ещё более занятые GPU, хотя исходной причиной могла быть очередь или медленный участок вне ускорителя.
Практический вывод для платформенных команд — связывать метрики инфраструктуры с идентификатором конкретного запроса и этапами его обработки. Это помогает разделить несколько похожих внешне сценариев: модель стала отвечать медленнее; запросы дольше ждут запуска; один из экземпляров сервиса деградировал; клиентская часть слишком агрессивно повторяет вызовы. Без такой связи расследование часто сводится к знакомому ритуалу: смотреть на высокий процент загрузки GPU и гадать, достаточно ли добавить ещё один.
Для бизнеса разница тоже вполне осязаема. Ускорители стоят дорого, а добавление мощности без понимания узкого места может не улучшить отклик вовсе. Если проблема в очереди, батчинге, сетевом пути или ограничениях оркестратора, новый GPU лишь сделает архитектурную ошибку более дорогой. Если же измерения подтверждают, что вычислительный ресурс действительно исчерпан, масштабирование будет аргументированным, а не интуитивным.
Медленный ИИ-инференс постепенно становится отдельной дисциплиной между MLOps, SRE и разработкой приложений. Kubernetes хорошо сообщает, живы ли компоненты системы; пользователи же оценивают, получила ли система ответ вовремя. Чем активнее компании переносят модели в рабочие процессы, тем важнее станет вопрос, какие метрики связывают эти две реальности — и кто отвечает за их общий результат.
