Метрики API дообученных LLM: что отслеживать

Дообученную модель стоит держать только в том случае, если она остаётся достаточно быстрой, достаточно стабильной и достаточно дешёвой под живым трафиком API.

Если бы я отслеживал всего несколько вещей с первого дня, я бы следил за латентностью, пропускной способностью, частотой ошибок, частотой таймаутов, частотой успеха, частотой отката, расходом токенов, стоимостью запроса, глубиной очереди и частотой выполнения задач. Почему? Потому что модель может вернуть 200 OK и всё равно провалить задачу, сжечь лишние токены или подтолкнуть пользователей уйти.

Вот краткая версия:

• Латентность: следите за TTFT и p95/p99, а не только за средними значениями.
• Пропускная способность: тестируйте RPS/TPS при продакшн-конкурентности, а не по одному запросу за раз.
• Надёжность: разделяйте 4xx, 5xx, 429, 503 и 504, чтобы легко замечать паттерны сбоев.
• Таймауты: более длинные выводы часто выталкивают дообученные модели за пределы дедлайнов запросов.
• Успех vs. откат: рабочий ответ API — это не то же самое, что пригодный ответ.
• Токены: отслеживайте входные, выходные и суммарные токены из поля usage API.
• Стоимость: измеряйте стоимость запроса, стоимость за 1000 токенов и p95-стоимость, а не только месячные расходы.
• Ёмкость: глубина очереди и давление на KV-кеш часто показывают проблему раньше, чем графики GPU.
• Результат для пользователя: следите за частотой выполнения задач, проверкой человеком и отказами.
• Риск отката: если p99 скачет, 5xx + таймауты превышают 5 % или процент побед против базовой модели падает ниже 50–55 %, я бы расценивал это как серьёзное предупреждение.

Дообучение с пользовательскими вычислительными метриками

Быстрое сравнение

Итог: я бы не судил о дообученной модели по одним лишь офлайн-оценкам. Я бы сравнил её с базовой моделью в продакшене, задал лимиты отката до запуска и держал один дашборд, показывающий скорость, сбои, расходы и результат в одном представлении.

Почему метрики API важнее после дообучения

Дообучение меняет поведение модели в продакшене. Под живым трафиком латентность, расход токенов и паттерны сбоев могут смещаться. В одних случаях дообучение сокращает входные токены, заменяя длинные промпты. В других — повышает стоимость вывода, делая завершения длиннее ^[6]. Именно поэтому офлайн-победы сами по себе мало что значат. Их нужно проверять по живым метрикам API.

Разрыв между офлайн-тестированием и продакшеном реален. Исследования показывают, что дообученная модель может набрать 12 баллов на специфичном для задачи отложенном наборе и всё же потерять 6 баллов на общих бенчмарках рассуждения, таких как GSM8K ^[2]. Это не какой-то странный частный случай. Это известный паттерн сбоя под названием катастрофическое забывание, когда улучшение одного навыка может ослабить другие.

Урок здесь довольно прост: дообучение может помочь с задачей, которая вам важна, и всё же навредить производительности в других местах. И такой дрейф бенчмарков не проявляется ясно, если смотреть только на офлайн-оценки. Вы видите его, когда продакшн-сигналы стоят рядом с результатами оценки.

Дрейф качества — не единственная проблема. Доменное дообучение также может ослабить поведение отказов базовой модели, что делает её более открытой для джейлбрейков и инъекций промптов ^[2]. В продакшене такое проскальзывание проявляется быстро: частота успеха падает, частота отката растёт, а всплески ошибок начинают появляться так, как статичный тестовый набор не уловит. Эти изменения проявляются в метриках API, о которых пойдёт речь дальше.

1. Сквозная латентность

Сквозная латентность — это полное время с момента отправки запроса клиентом до прихода полного ответа. Сюда входят сетевое время, ожидание в очереди, инференс и доставка ответа ^[7][9]. Для дообученных эндпоинтов это один из первых продакшн-сигналов, за которым стоит следить.

Простой способ думать о латентности такой: total time ≈ TTFT + output_tokens × TPOT ^[9].

TTFT измеряет, как быстро появляется первый токен, что очень важно для стриминговых приложений ^[9][10]. TPOT — это среднее время между сгенерированными токенами ^[9]. Такое разделение помогает увидеть, что изменилось после дообучения. Просела ли скорость ответа? Стриминг стартовал позже? Замедлилась ли генерация токенов?

Дообученные модели часто работают на 10–20 % медленнее базовых. Если латентность подскакивает более чем на 50 %, это обычно указывает на не слитые веса LoRA, отсутствие квантизации или слишком длинный вывод ^[7][8]. Полезное сравнение — с базовой моделью. Оно показывает, достаточно ли дообучение улучшило качество задачи, чтобы оправдать потерю в скорости.

Хвостовую латентность пользователи замечают во время медленных ходов, повторов и всплесков очереди. p95 TTFT выше 3–4 секунд создаёт явное замедление для пользователей ^[3]. В интерактивном чате p95 TTFT ниже 500 мс ощущается мгновенным. Как только он переходит за 3–4 секунды, впечатление резко падает ^[12]. Поэтому не устанавливайте SLA только по среднему. Устанавливайте их по хвостовой латентности.

Высокая хвостовая латентность обычно указывает на проблемы с глубиной очереди или накладные расходы холодного старта, а не на сырую скорость GPU ^[10]. Именно поэтому перцентильная латентность важнее среднего времени ответа самого по себе.

Прежде чем измерять, выполните 2–3 разогревочных запроса. Латентность первого вызова часто на 30–50 % выше ^[8].

2. Латентность p50, p90 и p99

Средняя латентность может выставить всё в лучшем свете, чем есть на самом деле. Вы можете увидеть среднее время ответа 1,2 секунды и решить, что эндпоинт в порядке, тогда как p99 равен 9 секундам ^[15]. Это значит, что 1 % пользователей всё ещё ждёт почти 10 секунд, даже если дашборд говорит, что всё нормально. Перцентили помогают увидеть, помогло ли дообучение большинству запросов или просто вытолкнуло замедление в хвост.

Вот что каждый перцентиль говорит о вашем дообученном эндпоинте:

Используйте эти перцентили, чтобы сравнить базовую модель и дообученную под одинаковым составом трафика.

После дообучения p50 и p99 могут двигаться в разных направлениях. Если ваше дообучение приводит к более коротким, более структурированным выводам, p50 может снизиться, потому что типичные запросы завершаются быстрее. Но p99 может вырасти, если модель иногда становится более многословной ^[7][15]. Это расхождение важно. Если p99 растёт, а p50 остаётся ровным, это сигнал копать глубже, а не среднее время ответа.

p99 — это ваш показатель риска отката. Задавайте регрессионные ворота в вашем CI/CD-конвейере вокруг порогов p99 ^[15]. Если обновление модели выталкивает хвостовую латентность за ваш лимит, сборка должна упасть до того, как попадёт в продакшен.

Латентность говорит вам, насколько медленными ощущаются запросы. Дальше посмотрите, сколько запросов эндпоинт может обработать.

3. Пропускная способность и запросы в секунду (RPS)

Латентность говорит, как выполняется один запрос. Пропускная способность говорит, сколько работы эндпоинт может обработать за время.

Основные числа для отслеживания — запросы в секунду (RPS), токены в секунду (TPS) и токены в минуту (TPM) ^[17][18]. Вместе они показывают, справляется ли ваш дообученный эндпоинт с реальным трафиком, особенно при использовании единого API для LLM для управления несколькими провайдерами.

Вот загвоздка: модель может выглядеть быстрой в разовом тесте и всё же развалиться, когда трафик накапливается. Под конкурентностью вы можете упереться в коллапс пропускной способности, когда добавление большего числа параллельных запросов больше не увеличивает вывод, а латентность начинает резко скакать. Эта точка перегиба — где пропускная способность перестаёт масштабироваться — и есть ваш потолок ёмкости ^[15].

Один из крупнейших факторов за RPS — длина вывода. Если дообучение начинает давать более длинные ответы, пропускная способность падает, а расходы растут, даже если ответы стали лучше ^[6][8].

Также стоит следить за goodput, а не только за сырой пропускной способностью. Goodput — это доля запросов, которые всё ещё укладываются в SLO по латентности. Если goodput низкий, эндпоинт может быть занят, но всё равно промахиваться. Такой разрыв часто указывает на слабый батчинг или насыщение сервера ^[17].

Поэтому, когда вы бенчмаркаете RPS и TPS, тестируйте при продакшн-конкурентности, а не одиночными запросами. Ограничения, связанные с рейт-лимитами, глубиной очереди и VRAM, часто остаются скрытыми, пока система не окажется под нагрузкой ^[7][9][15]. Если эндпоинт способен держать ёмкость там, то пора проверить, успешны ли эти запросы.

4. Частота ошибок по HTTP-статусу

Как только нагрузка под контролем, следующее, за чем стоит следить, — надёжность: как часто эндпоинт даёт сбой. Частота ошибок говорит, завершаются ли запросы так, как должны. На практике это разбивается на две корзины: сбои на стороне клиента и сбои на стороне сервера.

Рост ошибок 4xx часто указывает на несоответствия промпта или схемы либо проблемы с контекстным окном, внесённые дообучением. Рост ошибок 503 или 504 обычно указывает на нагрузку на сервер или давление таймаутов. Когда всплеск дают ошибки 5xx, расценивайте это как серьёзный риск отката.

Здесь есть и денежный аспект. Неудачные запросы всё равно расходуют токены. Чтобы отслеживать потраченные впустую расходы, суммируйте токеновые начисления по неудачным запросам, особенно по ошибкам 4xx кроме 429 и любым ошибкам 5xx ^[22]. А если логика повторов слишком агрессивна, эти неудачные повторы могут поднять стоимость инференса в 3–5 раз ^[21].

Вот простая карта самых распространённых статус-кодов, их обычных источников и того, что делать дальше:

Не используйте одну и ту же логику повторов для каждого кода ошибки. Повтор 400 просто сжигает больше вычислений, потому что запрос всё ещё сломан. Экспоненциальный откат уместен для ошибок 429 ^[21]. Если 503 или 504 продолжают появляться в трёх проверках подряд, включите размыкатель цепи и направьте трафик на базовую модель.

Дальше проверьте, не отваливаются ли медленные ответы по таймауту до завершения.

5. Частота таймаутов

Когда ошибки растут, а явного скачка откровенных сбоев нет, следующее, что стоит проверить, — частота таймаутов. Таймаут — это всё равно неудачный запрос: клиент не получает ответа до дедлайна. Отслеживайте частоту таймаутов как долю запросов, превысивших этот дедлайн, что часто проявляется как серверные ошибки таймаута.

Дообученные модели более склонны упираться в таймауты, потому что часто выдают более длинные выводы. Если обучающие данные были склонны к многословию, модель может генерировать больше токенов на запрос, чем базовая. Это часто бывает при использовании моделей Qwen от Alibaba или других высокопроизводительных LLM, которые отдают приоритет подробным ответам. Больше токенов — больше времени на генерацию, и именно это дополнительное время выталкивает запросы за дедлайн ^[8].

Если глубина очереди держится выше нуля, система уже на пределе ёмкости. Когда это происходит, частота таймаутов обычно вскоре растёт ^[12]. Расценивайте глубину очереди как ранний предупреждающий знак, а не ждите появления таймаутов. Если глубина очереди растёт одновременно с таймаутами, вы имеете дело с проблемой ёмкости, и она требует немедленных действий. Как только частота таймаутов утихнет, отделите настоящие успехи от резервных ответов.

6. Частота успеха и частота отката

Даже когда таймауты исчезают, запросы всё равно могут промахнуться мимо задачи. Частота успеха говорит, действительно ли модель выполнила задачу, а не просто вернула HTTP 200. Это означает проверку таких вещей, как соответствие схеме, корректные вызовы инструментов и фактическая точность. Дообученная модель может показывать высокую точность по токенам и всё же проваливать 15–30 % живых продакшн-запросов из-за регрессий на уровне задач ^[23].

Частота отката говорит, как часто трафик приходилось направлять куда-то ещё после того, как дообученный эндпоинт дал сбой, вышел за таймаут или был заблокирован фильтрами безопасности ^[4][5]. Именно поэтому её стоит отслеживать прямо рядом с частотой успеха. Вы измеряете не просто завершения. Вы измеряете вывод, который можно использовать.

Используйте эти две метрики вместе как основной сигнал качества выполнения. Если любая из них проседает, это момент проверить, держится ли ещё дообучение против базовой модели. Если процент побед против базовой модели падает ниже 50–55 %, это распространённый порог отката ^[2][4].

Если успех остаётся высоким, но стоимость начинает расти, проверьте дальше расход токенов.

Высокий успех мало что значит, если каждый запрос обходится слишком дорого в обслуживании.

7. Расход токенов на запрос

После надёжности расход токенов говорит, достаточно ли модель компактна, чтобы работать в масштабе. Он также показывает, делает ли дообучение свою работу, заменяя накладные расходы промпта усвоенным поведением. Более низкий расход токенов обычно означает более низкую стоимость и более быстрые ответы.

Отслеживайте входные, выходные и суммарные токены как отдельные числа. Так легче заметить медленный рост, прежде чем он превратится в проблему стоимости. Высокие входные токены часто указывают на раздувание промпта или переполнение контекста. Высокие выходные токены обычно означают многословные завершения, слабые правила остановки или отсутствие потолка на вывод. И выходные токены стоят дороже входных, поэтому многословность — крупнейший риск по стоимости ^[15].

Берите количество токенов из объекта usage API в каждом ответе, а не из локальной оценки токенизатора ^[15][25]. Локальные оценки могут расходиться со счётами по биллингу. Если вы видите тройной скачок токенов, предполагайте раздувание промпта или переполнение контекста, пока не найдёте причину ^[3]. Также стоит задать потолок на выходные токены в CI/CD, чтобы ловить регрессии многословности до релиза ^[15].

Количество токенов напрямую отображается в расходы, поэтому следующая метрика — стоимость запроса.

8. Стоимость запроса и стоимость за 1000 токенов

Токены превращаются в доллары. Но месячный счёт сам по себе не говорит, почему расходы выросли. Чтобы увидеть, что их движет, отслеживайте стоимость запроса и стоимость за 1000 токенов. Это даёт следующий слой продакшн-анализа.

Стоимость запроса показывает, во что обходится одно действие пользователя. Считайте её из начисленных за этот запрос платежей за входные, выходные и кешированные токены ^[26][28]. Затем отдельно отслеживайте начисляемую ставку за 1000 токенов. Когда вы смотрите на оба числа вместе, вы можете понять, растут ли расходы из-за большего трафика или из-за того, что промпты и завершения удлиняются. Этот паттерн часто называют ползучим ростом токенов ^[15][26].

Инференс дообученной модели может стоить в 2–5 раз дороже за токен, но он всё равно может снизить стоимость запроса, если сокращает длину промпта ^[29][30]. Почему? Дообученная модель запекает определения ролей, ограничители и few-shot-примеры в свои веса. Так каждый промпт становится короче при каждом вызове. В одном бенчмарке дообученной модели потребовалось всего 42 токена завершения там, где базовой понадобилось 85 — снижение стоимости инференса на запрос на 50,6 % ^[19]. Простыми словами, более высокая цена за единицу может проиграть меньшему числу токенов. Это и есть выигрыш, который вы хотите измерять в живом трафике API.

Помечайте каждый вызов API полями feature_name и user_tier, чтобы связать расходы с использованием продукта ^[27][28]. Это делает данные гораздо полезнее, когда расходы начинают дрейфовать.

Важнее всего несколько проверок:

• Внимательно следите за выходными токенами. По ценам флагманских моделей они могут стоить в 5 раз дороже входных, поэтому сокращение многословного ответа экономит больше, чем сокращение того же числа токенов промпта ^[15].
• Задайте потолок на среднее число выходных токенов в вашем CI/CD-конвейере. Это помогает ловить регрессии многословности до попадания в продакшен ^[15].
• Анализируйте стоимость по функциям и уровням пользователей, а не только в агрегате. Иначе дорогое использование может прятаться внутри здорового на вид итога.

После стоимости посмотрите, соответствует ли расход реальному спросу или простаивающей ёмкости.

Дальше сравните эти затраты с утилизацией инфраструктуры и длиной очереди.

9. Утилизация инфраструктуры и длина очереди

Если латентность и таймауты выросли, посмотрите дальше на слой обслуживания: очереди, память и давление на кеш. Глубина очереди здесь важнее всего. Утилизация GPU обычно отстаёт от спроса, поэтому это запаздывающий сигнал. Именно поэтому автомасштабирование должно опираться на глубину очереди на реплику, а не на процент загрузки вычислений ^[10][32].

Использование KV-кеша — ещё одна метрика, которую команды часто упускают. KV-кеш хранит контекст токенов в памяти GPU, и когда эта память становится тесной, движок может начать ставить новые запросы в очередь, даже если вычислительная мощность GPU ещё выглядит свободной ^[31][32]. Хорошее эмпирическое правило: расценивайте использование KV-кеша 40–50 % как раннее предупреждение, а 90 %+ — как насыщение ^[31][32].

Дообученные модели добавляют ещё один нюанс. Адаптеры LoRA требуют памяти поверх весов базовой модели, и их загрузка при первом запросе после масштабирования создаёт задержку холодного старта. В большинстве случаев это добавляет несколько сотен миллисекунд к TTFT ^[10]. Предзагрузка адаптеров при старте позволяет избежать большей части этой потери. Также стоит следить за CPU отдельно, поскольку токенизация и предобработка могут добавлять латентность, которую легко упустить ^[10].

Если эти сигналы ёмкости всё ещё выглядят здоровыми, переходите к качеству вывода.

10. Удовлетворённость пользователей и частота выполнения задач

После латентности, стоимости и надёжности последняя проверка проста: завершает ли модель работу? Дообученный эндпоинт может быть быстрым, дешёвым и стабильным и всё же промахиваться.

Частота выполнения задач (TCR) — это доля запросов, решённых без помощи человека. Частота проверки человеком — это доля выводов, которые всё ещё требуют ручных исправлений. Эта разница важна. Модель может вернуть HTTP 200 и всё же отдать нечто, что человеку придётся вычищать, прежде чем этим можно будет пользоваться. Поэтому TCR отслеживает бизнес-результат, а не просто то, ответил ли API.

На работе со структурированным выводом 500 качественных примеров могут поднять соответствие формату с 68–74 % до 97–99 % ^[33]. Такой скачок сокращает частоту вмешательства сотрудников. Как только формат корректен, сравните дообученную модель напрямую с базовой.

Скорость по-прежнему важна здесь. Латентность p99 выше 5 секунд приводит примерно к 45 % отказов ^[33]. Так что если дообучение замедляет опыт, пользователи покажут вам это быстро — уйдя.

Для прямой проверки качества используйте парное арена-тестирование. Прогоните 200–500 продакшн-образцов через базовую и дообученную модели, затем оцените выводы бок о бок с помощью LLM-в-роли-судьи. После этого зафиксируйте модель-судью и рубрику, чтобы будущие тесты оставались согласованными. Если процент побед против базовой модели падает ниже 50–55 %, это распространённый порог отката ^[2][4].

Также стоит следить за этими сигналами вместе:

• TCR
• Процент побед на арене
• Замороженный набор бенчмарков

Если модель проседает более чем на 5 баллов на общих бенчмарках, расценивайте это как жёсткий провал, даже когда специфичные для задачи оценки растут ^[2].

Используйте эти проверки качества рядом с метриками API из предыдущих разделов, решая, готово ли дообучение к продакшену.

Таблица сравнения латентности и пропускной способности

Ни одна метрика не рассказывает всю историю дообученного эндпоинта. Средняя латентность, например, может сглаживать колебания от запроса к запросу, особенно когда вмешиваются ожидание в очереди и батчинг на стороне провайдера ^[9].

Именно поэтому полезно сначала измерять латентность и пропускную способность по отдельности, а затем сравнивать их бок о бок, прежде чем задавать SLO.

Разбивайте результаты по типу эндпоинта, версии модели, региону и времени суток. Трафик в час пик часто выводит на поверхность проблемы латентности, которые тесты в непиковое время не уловят.

Такие срезы значительно упрощают понимание того, где дообученный эндпоинт начинает буксовать под живым трафиком.

Метрики надёжности, сигналящие о риске отката

Самый ясный признак того, что может понадобиться откат, — процент побед против базовой модели. Запускайте парные канареечные и теневые маршрутизации, чтобы сравнивать дообученную модель с базовой бок о бок. Если процент побед падает ниже 50 %, дообучение больше не добавляет ценности в продакшене. Ваш слой маршрутизации также должен автоматически откатываться, когда канареечная когорта удерживает падение любой рубричной оценки качества на 2 балла в течение 30–60 минут ^[2][4]. Как только эти сравнения становятся отрицательными, следующий ход прост: найдите группы промптов, которые ломаются.

Несколько других сигналов должны выступать триггерами отката: частота 5xx + таймаутов, частота отказов, частота недопустимого вывода, всплески 429 и поведение отката. Это те числа, что важны, когда вы решаете, должно ли дообучение оставаться живым. Отслеживайте всплески 429 отдельно. Они часто указывают на более высокую стоимость вычислений или более глубокие очереди ^[24][5].

Также полезно отделять частоту отказов от частоты недопустимого вывода, а не сваливать их в одну кучу. Отказы выше 2 % часто указывают на регрессию безопасности или на конфликт фильтров провайдера с вашими кастомными промптами ^[5][35]. Частота недопустимого вывода обычно указывает на дрейф схемы или более слабое следование инструкциям ^[2][24].

Разбивайте каждую метрику по типу промпта, маршруту рабочего процесса и версии модели. Модель может выглядеть нормально на общих запросах и всё же буксовать на путях со структурированным выводом или на доменных промптах. Такое разделение значительно упрощает суждение о том, безопасно ли держать модель работающей и держится ли ещё профиль стоимости.

Метрики стоимости, токенов и ресурсов в денежном выражении

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

Для GPT-4o цены на инференс дообученной модели идут с наценкой 1,5x над базовыми ставками. Это выходит в $3,75 за 1 млн входных токенов и $15 за 1 млн выходных токенов ^[36]. Эти дополнительные затраты оправданы только если дообучение снижает стоимость получения успешного результата. Один распространённый способ урезать расходы — через агрегированные скидки на ИИ-API и каскадирование моделей: направляйте простые запросы к меньшей, более дешёвой модели, а более крупную приберегите для сложных задач ^[37].

Также полезно прогнозировать расходы для сценариев экономной, ожидаемой и высокой нагрузки. Затем добавьте повторы, использование резерва и прогоны оценки ^[26]. Этот шаг важнее, чем ожидают многие команды, потому что 40 % команд превышают свой бюджет ИИ-API в первом квартале использования ^[37]. Вдобавок отслеживайте p95-стоимость запроса, а не только среднее. Иначе промпты с длинным контекстом или повторяющиеся повторы могут исказить ваш прогноз так, как среднее не покажет ^[24]. Сырые расходы становятся полезными только когда вы связываете их с успешными результатами.

Эта связь — стоимость успешного результата. На практике это может означать стоимость решённого тикета поддержки или стоимость принятого ответа. Если дообученная модель повышает долю успешных результатов, ваша стоимость решения может падать даже когда цена за запрос растёт ^[26][37].

Для развёртываний на собственном хостинге утилизация GPU — главный драйвер стоимости. Фиксированные затраты на GPU окупаются только когда использование превышает определённый порог. Другими словами, высокая утилизация важна, когда она улучшает экономическую эффективность. Также следует следить за длиной очереди рядом с утилизацией. Если глубина очереди продолжает расти, это обычно признак насыщения, дополнительных затрат и большего давления на масштабирование ^[11][15].

Используйте эти метрики вместе, чтобы отличать здоровую нагрузку от дорогих потерь.

Сигналы качества, наблюдаемые через API

Как только латентность, пропускная способность и стоимость в хорошей форме, следующий шаг прост: проверить, действительно ли модель помогает пользователям делать дело. Скорость важна, конечно. Но быстрый ответ, который не решает проблему, — всё равно промах.

Сосредоточьтесь сначала на частоте выполнения задач, частоте эскалации и частоте передачи человеку. Это ваши основные сигналы результата. Они говорят, справилась ли дообученная модель с запросом сама или кому-то пришлось вмешаться. И это важнее оценок бенчмарков, потому что эти метрики берутся из реальных логов запросов и сессий.

Вы также можете отслеживать оценки палец вверх/вниз и частоту отказов как вспомогательные сигналы уровня сессии, привязанные к трафику API. Даже если обратной связи мало, она всё равно может показать повторяющиеся болевые точки. Отказы особенно полезны, потому что показывают, где модель начинает дрейфовать, теряет контекст или перестаёт быть полезной на полпути разговора.

Также полезно сэмплировать живой трафик с LLM-в-роли-судьи, чтобы оценить проблемы галлюцинаций и безопасности. 5 %-выборки часто достаточно, чтобы ловить аномалии, не повышая слишком сильно расходы на оценку ^[39]. Следите также за частотой срабатывания ограничителей. Если более 20 % запросов блокируется, это может указывать на скачок небезопасных выводов или на несоответствие между тем, чего хотят пользователи, и тем, чего ожидает система ^{[38] [1] [2]}. Резкий рост частоты отказов часто означает, что фильтры стали слишком чувствительны или что где-то в стеке сломался шаблон промпта ^{[39] [2]}.

Каждый живой сбой должен возвращаться в офлайн-тестовый набор как постоянный кейс. Именно так вы не даёте одной и той же проблеме тихо вернуться позже.

Используйте таблицу ниже, чтобы отделить основные сигналы качества от вспомогательных.

Используйте эти сигналы наряду с латентностью и стоимостью в дашборде наблюдаемости.

Дашборды наблюдаемости для дообученных эндпоинтов

Отслеживание отдельных метрик помогает. Но отдача приходит, когда вы видите всё в одном месте.

Надёжная настройка наблюдаемости для дообученных эндпоинтов держится на четырёх столпах: метрики для агрегированных сигналов вроде латентности и частоты ошибок, трейсы для полного пути одного запроса, логи для структурированных записей о произошедшем и оценки для асинхронных проверок качества ^[40][42].

Это важно ещё сильнее с дообученными моделями. Запрос может успешно завершиться на системном уровне и всё же провалиться на уровне смысла, даже при использовании интерфейса ИИ-чата. Поэтому дашборд должен показывать семантические сбои, а не только транспортный успех. Старомодный APM может показать, что ответ был здоровым. Он не скажет, был ли ответ неверным. 200 OK может всё равно скрывать плохой результат.

Стройте дашборд вокруг пяти представлений: латентность, надёжность, стоимость, качество и ёмкость. Используйте OpenTelemetry с семантическими соглашениями GenAI и хвостовое сэмплирование трейсов, чтобы сохранять все медленные и неудачные запросы, сэмплируя небольшой срез нормального трафика ^[40][41]. Такая настройка окупается и во время инцидентов: трассировка может сократить среднее время восстановления в 3 раза ^[42].

Используйте эти сигналы, чтобы создать один дашборд с пятью основными панелями: латентность, надёжность, стоимость, качество и ёмкость.

Хороший способ подумать об этом: латентность говорит, насколько быстро двигалась система, надёжность показывает, оставалась ли она в строю, стоимость показывает, во что обходится каждый ответ, качество показывает, был ли ответ хорош, а ёмкость говорит, когда система начинает перегреваться.

Таблица проектирования дашборда

Эта таблица связывает каждый виджет дашборда с типом графика, который работает лучше всего, и фильтрами, делающими его полезным во время инцидентов и разборов расходов.

Чтобы эти фильтры работали с первого дня, помечайте трейсы при инструментировании идентификатором модели, версией промпта и окружением. Семантические соглашения OpenTelemetry GenAI включают такие атрибуты, как gen_ai.request.model и gen_ai.usage.input_tokens ^[40].

Выбирайте график, который позволяет заметить паттерн сбоя с первого взгляда.

Атрибуция стоимости показывает, какая версия модели движет расходами. Обозреватель трейсов важнее всего для RAG- и агентских рабочих процессов, потому что показывает латентность и ошибки на этапах извлечения, вызовов инструментов и инференса ^[43][40].

После того как вы определите каждый виджет, задайте правила хранения и сэмплирования. Храните все запросы с высокой латентностью, ошибками и низкой оценкой качества в Обозревателе трейсов. Затем сэмплируйте рутинные успешные запросы на уровне 5–20 %, чтобы держать затраты на хранение под контролем ^[40].

Заключение

Оценка дообучения должна доказать улучшение, а не просто изменение. Именно поэтому финальное табло должно смотреть на метрики скорости, надёжности, стоимости и результата вместе.

Если вы настраиваете одну метрику в изоляции, продакшн-проблемы могут быстро подкрасться. Модель может стать быстрее, но менее стабильной. Или может сократить время проверки, но нарастить ошибки. Смысл в том, чтобы отслеживать всю картину, а не один её срез.

Начните с базовой модели. Без этой базовой линии вы не сможете показать, что дообучение сделало что-то лучше. Запустите канарейку 5–10 % и сравните эти результаты с базовой моделью через теневую маршрутизацию. Задайте оповещения, когда латентность превышает 2x от базовой линии или когда частота ошибок переходит за 5 % в течение 5 минут. Как только эти ограничители заданы, свяжите числа с операционной экономией.

Каждая метрика должна отображаться в бизнес-результат. Частота проверки человеком — прямой прокси операционной экономии. Если это число не движется, дообучение не создаёт продакшн-ценности.

Дашборды и оповещения не опциональны. Стройте наблюдаемость до запуска, чтобы регрессии проявлялись раньше, чем их заметят пользователи.

Часто задаваемые вопросы

Какие метрики API отслеживать первыми?

Начните с метрик инфраструктуры и надёжности, чтобы проверить, что система стабильна. Сосредоточьтесь на TTFT на 95-м перцентиле, сквозной латентности, частоте жёстких ошибок, частоте отказов и стоимости запроса.

Как только у вас есть эти базовые линии, следите за качеством вывода с помощью оценок LLM-в-роли-судьи и дрейфа способностей. Это помогает заметить, начала ли модель проседать по ключевым навыкам.

Как сравнить дообученную модель с базовой?

Прогоните обе модели на одном и том же отложенном тестовом наборе — данных, никогда не использованных в обучении, — чтобы измерить разрыв чисто. Сначала задайте сильную базовую линию промптинга на базовой модели. Это даёт честную точку сравнения вместо подтасовки колоды.

Сравнивайте модели по качеству, латентности и стоимости.

Для качества используйте метрики, подходящие под задачу, такие как:

• F1 для задач классификации или извлечения
• Точное совпадение для задач с одним правильным ответом
• Частота парсинга JSON для структурированных выводов

Для латентности измеряйте сквозное время ответа, а не просто сырое время работы модели. Это значит замерять весь путь запроса от отправки промпта до финального вывода.

Для стоимости используйте цену каждой модели за 1 млн токенов и рассчитайте, сколько вы заплатили бы на основе реального расхода входных и выходных токенов на тестовом наборе.

Когда откатывать дообученную модель?

Откатывайте, когда продакшн-мониторинг показывает, что качество упало явным образом. Это может указывать на дрейф модели или сбой на живых входах.

Вам также следует откатиться, если модель проседает на вашем наборе отказов, открывает новые уязвимости к инъекциям промптов или показывает результат хуже текущей версии во время продакшн-канареечного тестирования.

Держите под пристальным наблюдением латентность p95 и заявленные пользователями проблемы качества, чтобы замечать неприятности рано.