Представьте: вы развернули в своём частном облаке или на локальных серверах Llama 3, DeepSeek или другую LLM. Данные остаются внутри инфраструктуры, модель работает локально, на первый взгляд система полностью здорова: CPU, память, сеть и сами сервисы работают без отклонений.
Но внезапно модель начинает отвечать с задержками, генерировать бессвязный текст. Вы смотрите на дашборды своего мониторинга — а они показывают, что все сервисы «зелёные» и работают штатно.
ИИ, как любое приложение, нужно мониторить... например, с помощью другого ИИ. Рекурсия, но к этому всё и движется.
Только вот как отслеживать здоровье того, что по определению непредсказуемо и недетерминировано?
Привычный набор метрик здесь не работает. Помимо инфраструктуры приходится анализировать поведение самой модели, путь запроса через RAG, оркестрацию, потребление токенов и качество генерации. Получается, что мониторинг LLM — это не «ещё одна метрика», а принципиально новая задача для DevOps и SRE-команд.
Разберёмся, почему мониторинг LLM требует другого подхода, из каких слоёв состоит современный ИИ-стек и как платформы APM и наблюдаемости могут заглянуть внутрь «чёрного ящика» локальной LLM.
Почему мониторить LLM сложнее, чем обычный микросервис
Классический APM создавался для детерминированных систем: микросервисы, базы данных, очереди сообщений. Метрики понятны: RPS, latency, error rate. Запрос проходит через сервисы, обрабатывается, возвращается ответ. Если увеличилось время отклика или выросло количество ошибок, можно достаточно быстро определить проблемный компонент.
С LLM всё иначе: даже одинаковые промты могут приводить к разным ответам, стоимость выполнения зависит от количества обработанных токенов, модель может «галлюцинировать». Добавьте к этому RAG, оркестраторы вроде LangChain, вызовы внешних инструментов и GPU — и цепочка обработки одного запроса оказывается значительно длиннее, чем у обычного веб-приложения.
Здесь появляются новые классы проблем, которых раньше не существовало.
Например, модель может вернуть синтаксически корректный, но фактически неверный ответ.
Ещё один характерный сценарий — фрагментация видеопамяти GPU: она способна вызывать периодические сбои запросов, при этом стандартные метрики продолжают показывать, что сервис полностью работоспособен.
Поэтому важно фиксировать последовательность событий с помощью трассировки, особенно в приложениях на основе RAG, где события происходят до и после использования LLM. Помимо трассировки требуется анализ агрегированных данных: задержек, количества обработанных токенов, стоимости запросов и других показателей, которые помогают оценить производительность всей ИИ-системы.
Из чего состоит современная LLM-система
Прежде чем говорить о мониторинге LLM, стоит понять, где вообще возникают проблемы.
Запрос к LLM проходит через несколько независимых компонентов, каждый из которых способен стать источником задержек или ошибок. Типичная цепочка выглядит так:
Пользователь → Frontend → Backend → Оркестратор (LangChain, CrewAI) → RAG (векторная БД) → LLM → GPU → Ответ пользователю
На каждом этапе выполняется собственная задача. Оркестратор формирует запрос, RAG ищет релевантный контекст, модель генерирует ответ, а GPU обеспечивает вычисления. Если хотя бы один компонент начинает работать медленнее, это увеличивает время ответа пользователю.
Два уровня наблюдаемости
Весь мониторинг LLM-приложений условно можно разделить на два уровня.
Инфраструктура. Остаются привычные показатели: процессор, память, диски, сеть, но из-за специфики работы LLM основная вычислительная нагрузка приходится на GPU. Его состояние во многом определяет производительность всей системы.
Прикладная часть. Здесь традиционных запросов в привычном смысле нет — вместо них появляются параметры, которых раньше не существовало: время генерации первого токена, количество обработанных токенов, путь запроса через RAG, вызовы инструментов, качество сформированного ответа.
При этом даже полный набор инфраструктурных метрик отвечает только на один вопрос — в каком состоянии находятся серверы. О том, как выполняется конкретный пользовательский запрос, он не говорит практически ничего. Например, невозможно понять:
сколько времени занял поиск контекста в RAG;
сколько токенов обработала модель;
когда был сгенерирован первый токен;
почему генерация завершилась раньше времени;
какие внешние инструменты вызывала LLM;
на каком этапе возникла задержка.
Начнём с уровня, на который опирается всё остальное, — с железа.
Почему GPU становится главным объектом мониторинга
Современные LLM требуют огромных вычислительных ресурсов, и практически вся нагрузка ложится на видеокарты, чаще всего NVIDIA.
Когда мы реализовывали в Ключ-АСТРОМ мониторинг NVIDIA, выделили основные направления, которые нужно покрывать:
загрузка вычислительных ядер GPU;
использование видеопамяти;
температура и энергопотребление;
пропускная способность памяти и задержки
Большие продуктивные модели редко работают на одном сервере. Для них создаются кластеры, управляемые через NVIDIA Base Command Manager (BCM) — на платформе разворачивают узлы, распределяют рабочие нагрузки и следят за инфраструктурой ИИ-датацентра.
BCM тоже нужно мониторить, здесь метрики классические: загрузка CPU, состояние дискового пространства и I/O, показатели памяти (включая swap и OOM-события) и утилизация GPU.
OpenTelemetry: как увидеть весь путь запроса
Одна из самых ценных функций мониторинга LLM-приложений — end-to-end трассировка всей цепочки: от пользователя через оркестрацию и RAG до возврата ответа. Все эти этапы можно взять под наблюдение и собрать сопровождающие показатели с помощью OpenTelemetry.
OpenTelemetry задаёт общие правила разметки телеметрии: название модели, количество токенов, параметры запроса и метаданные ответа. В результате вызовы OpenAI, Anthropic или локальной модели описываются одинаковыми атрибутами и анализируются в одной системе.
Для LLM-приложений OpenTelemetry собирает три типа данных.
1. Трейсы
Трассировки фиксируют жизненный цикл каждого взаимодействия с моделью:
входные параметры (temperature, top_p)
детали ответа (количество токенов, ошибки)
вложенные вызовы (инструменты, базы данных)
2. Метрики
Агрегированные показатели для мониторинга производительности и затрат:
гистограмма задержек вызовов
gen_ai.client.operation.durationпотребление входных и выходных токенов, основа для расчёта стоимости и производительности
gen_ai.client.token.usageколичество ошибок по типам
gen_ai.client.errorsвремя до первого токена (TTFT, Time To First Token) — критично для интерактивности и пользовательского опыта
время между токенами (TBT, Time Between Tokens) — показатель «плавности» генерации
причины завершения
finish_reason:stop,length,tool_calls— помогают понять, почему модель остановилась.
3. События
Детальные записи о конкретных моментах выполнения: обработка промптов пользователя, вызовы инструментов, ответы модели.
OpenTelemetry отвечает за то, чтобы всё это записать. Сложности начинаются дальше: скачок TBT в трейсе, рост swap на GPU и предупреждение в событиях — это три записи в трёх разных хранилищах, сами собой они в одну историю не сложатся.
Как объединить все эти данные в единое целое
Итак, данные собираются с разных уровней: инфраструктура, на которой работает LLM, кластер управления и сама модель — с трассировками, потреблением токенов и метриками качества ответов, по которым ловятся галлюцинации. Инцидент обычно проявляется сразу на нескольких из них. Вопрос в том, как показатели влияют друг от друга.
В Ключ-АСТРОМ за это отвечает детерминированный ИИ: он обнаруживает аномалии, анализирует зависимости и указывает первопричину. Изначально по метрикам формируются базовые линии, а там, где нужно, выставляются пороговые значения. Отклонение от baseline и статичных порогов — триггер для инцидента. А вот дальше начинается самое интересное.
При возникновении отклонений задействуется наш ИИ, который определяет взаимосвязи: зависимость трейсов от процессов, процессов от работы инфраструктуры, плюс дополнительные метрики с их таймстемпами и события в логах.
Давайте посмотрим на кейсах — как мониторинг помог в них разобраться.
Кейс №1: Инфраструктурная проблема
Заказчик использует локальную Llama-3, чтобы ежеквартально анализировать большой набор PDF-отчётов. В какой-то момент пользователи начали жаловаться, что система «тормозит»: по данным мониторинга медиана времени получения ответа выросла с 5 до 15 секунд. При этом стандартный дашборд (CPU, RAM, Network) показывал штатную работу, а хелсчек API возвращал статус 200.
Что пошло не так
Проверяли сеть и нагрузку на процессор, но проблем не было. Причина оказалась на уровне GPU: из-за фрагментации видеопамяти (после предыдущего тяжёлого задания) драйвер NVIDIA начал активно использовать механизм подкачки через шину PCIe. Процессор и память сервера были свободны, но GPU фактически «захлёбывался», перегоняя данные туда-сюда, что и вызвало задержки (TBT — Time Between Tokens).
Как отработал Ключ-АСТРОМ
Предварительно в системе был настроен сбор метрик NVIDIA DCGM (утилизация ядер, пропускная способность памяти и температура), о которых я рассказывал выше. Как только задержки начали расти, детерминированный ИИ для поиска первопричин сопоставил два события:
резкий скачок TBT в трейсах Llama;
падение показателя PCIe Throughput и рост Memory Swap на GPU.
Система указала на конкретный сервер в кластере BCM, а в качестве root cause была названа нехватка видеопамяти на GPU #4.
Чтобы всё починить, ограничили контекстное окно (max_tokens) и перезапустили инференс-сервис для освобождения фрагментированных блоков памяти.
По оценке, на поиск корневой причины вручную ушло бы 3-4 часа — здесь за счёт автоматического выявления инцидент локализовали за 20 минут (хотя можно было и быстрее, так как уведомление пришло уже через 7 минут).
Кейс №2: проблема на прикладном уровне
Заказчик использует RAG-приложение (LangChain + локальный DeepSeek) для помощи в составлении договоров. Система ищет похожие пункты в векторной базе (Qdrant) и переформулирует их. Раз в несколько дней она начинала выдавать абсурдные советы.
Что пошло не так
Разработчики проверяли код — всё было написано правильно. Стандартное логирование показывало, что модель получает промпт и выдаёт ответ. Но никто не видел, что именно попало в промпт перед отправкой в LLM (контекст из RAG). Оказалось, что из-за таймаута векторной базы функция поиска возвращала не релевантные документы, а пустую заглушку или «шум». Модель, получив пустой контекст, начинала галлюцинировать, но делала это с высокой температурой генерации, выдавая красивый бред.
Как отработал Ключ-АСТРОМ
По OpenTelemetry трассировка фиксировала цепочку: Пользователь → Фронт → LangChain (Prompt) → RAG (запрос в Qdrant) → LLM → Ответ.
В трейсе ошибок не было, но событие (Event) от RAG-агента содержало предупреждение: «Retrieved chunks: 0».
Метрика finish_reason у LLM в этом конкретном трейсе была не «stop» (естественный конец), а «length» — модель оборвала генерацию, так как не получила вводных.
Система сравнила эмбеддинги полученного ответа с эталонными (метрика качества ответа) и зафиксировала резкое падение семантической близости (Cosine Similarity).
Всё это увидели в трейсах, относившихся к проблеме, которую поднял Ключ-АСТРОМ. Первопричина: задержка ответа от векторной БД (Qdrant) на 120 мс, из-за которой в промпт не попали релевантные документы.
Проблема была обнаружена за стандартные 5 минут, и ещё примерно столько же ушло на то, чтобы провалиться в трейсы и посмотреть указанные отклонения.
Что в итоге даёт AI Observability для локальных LLM?
Во-первых, «чёрный ящик» перестаёт быть чёрным. В обоих кейсах ответ был не там, куда смотрели: инженеры проверяли сеть и CPU, а причина сидела в фрагментации видеопамяти; разработчики вычитывали код, а виноват был таймаут векторной базы. Сквозная видимость показывает то, что по отдельным дашбордам не видно в принципе.
Во-вторых, локальная LLM — это другая экономика. Вы платите не за токены, а за железо и электроэнергию, поэтому мониторинг утилизации GPU и тепловых порогов помогает оптимизировать использование ресурсов и избегать перерасхода. А по метрикам токенов и латентности можно подбирать модели и конфигурации под задачу, не переплачивая мощностью там, где хватило бы модели поменьше.
В-третьих, скорость. Разница между ручным поиском и автоматической корреляцией может быть 3-4 часа против 20 минут. Это другой порядок реагирования SRE-команды.
Недетерминированность, галлюцинации, новые типы метрик, глубокая зависимость от GPU требует особых подходов к мониторингу. Но главное уже понятно: комбинация сбора метрик GPU, трассировки LLM-вызовов через OpenTelemetry и анализ зависимостей с использованием детерминированного ИИ дают набор сигналов, которые нужно научиться читать.
И та самая рекурсия из начала статьи оказалась не шуткой, а рабочей архитектурой.
