Обычный запрос к API либо сработал, либо вернул ошибку, и этого почти хватает для отладки. С LLM-запросом всё сложнее: ответ может быть валидным JSON и при этом абсолютно неверным по смыслу, а счёт растёт даже на успешных вызовах. Без специального лога такие вещи не поймать.
Зачем нужен отдельный слой логов
Обычные логи приложения пишут факт вызова и код ответа. Для LLM этого мало, потому что там, где обычный API либо упал, либо отработал, модель может тихо ошибиться внутри успешного ответа.
Отдельный лог вокруг каждого вызова модели решает две задачи сразу: позволяет воспроизвести конкретный случай для отладки и позволяет посчитать, куда уходят деньги, без ручного сведения таблиц в конце месяца.
Request id обязателен на каждый вызов
Первое, что нужно писать, уникальный идентификатор запроса. Без него невозможно связать жалобу пользователя, запись в логе приложения и конкретный вызов к модели, если запросов идут тысячи в день.
Хорошая практика, генерировать id на входе в систему и прокидывать его через весь путь запроса: от обращения пользователя до вызова API и обратно. Тогда одна строка в логе поддержки превращается в полную цепочку событий, а не в "где-то что-то пошло не так".
Токены и латентность на каждый вызов
Число входных и выходных токенов нужно писать всегда, отдельно друг от друга. Это не только про счёт. Это диагностика. Резкий рост входных токенов часто значит, что в промпт случайно попал лишний контекст. Рост выходных обычно значит, что модель стала генерировать длиннее обычного, иногда из-за изменившегося промпта или системной инструкции.
Латентность тоже пишите отдельно от общего времени ответа приложения. Причин у медленного ответа несколько: виновата может быть сама модель, сеть, очередь перед вызовом. Раздельный замер сразу показывает, кто виноват на самом деле.
Привязка к ключу и к пользователю
Самая полезная и чаще всего упускаемая часть, привязка каждого вызова к тому, кто его сделал: какой ключ API, какая команда, какой пользователь или фича внутри продукта. Общий счёт за месяц отвечает на вопрос "сколько потрачено", но не отвечает на вопрос "кем и на что".
Без такой привязки расследование скачка расходов превращается в перебор гипотез. С ней достаточно посмотреть разбивку и увидеть конкретный ключ или фичу, которая внезапно стала генерировать в разы больше вызовов или заметно более длинные ответы.
В Claudexia статистика уже разложена по ключам, так что если выдавать отдельный ключ на каждую фичу или команду, эта привязка получается бесплатно, без дополнительного кода на стороне продукта. Суб-организации с собственными бюджетами и порогами удобны ровно для этого: видно, какая команда или продукт приближается к лимиту, до того как расход стал проблемой.
Что логировать из содержимого, а что нет
Полный текст промпта и ответа полезен для отладки, но не всегда безопасен для хранения как есть, особенно если в диалоге может оказаться персональная информация пользователя. Разумный компромисс: писать полное содержимое в отдельное хранилище с ограниченным доступом и коротким сроком хранения, а в основные логи и метрики класть только хеш или короткую выжимку.
Метаданные вызова, модель, версия промпта, название инструмента, если это агентный сценарий, стоит логировать всегда без ограничений. Они не несут персональных данных и при этом дают почти всё нужное для отладки без содержимого самого диалога.
Как логи превращаются в бюджет и алерты
Сырые логи сами по себе не решают проблему, решает то, что вы с ними делаете. На их основе стоит считать три вещи регулярно: суммарный расход за период по каждому ключу, долю запросов с аномально высоким числом токенов, долю неуспешных вызовов, которые пришлось повторить.
Дальше это превращается в пороги: уведомление при подходе к месячному лимиту, алерт при резком скачке латентности, флаг на ключ, у которого доля токенов на один вызов внезапно выросла в разы. Claudexia уже даёт часть этой картины на уровне ключей и суб-организаций, а публичная статус-страница закрывает вопрос "это у нас или у провайдера" без внутреннего расследования.
Пример из практики: ключ, выданный фиче с рассылками, вдруг начинает генерировать письма втрое длиннее обычных после того, как кто-то поменял системный промпт. Без разбивки по ключам это заметят только в конце месяца по общему счёту. С разбивкой алерт на аномальный рост токенов сработает в течение дня.
Коротко
Минимальный набор для лога вокруг LLM-вызова: id запроса, число входных и выходных токенов отдельно, латентность, привязка к ключу и пользователю. Содержимое диалога храните отдельно и с ограничениями, метаданные логируйте свободно. На этой основе спокойно считаются деньги и находятся баги, вместо того чтобы гадать по общему счёту в конце месяца.