Наблюдаемост на LLM в многомоделен API Gateway: Traces, Token Ledgers, Tenant Analytics и Safe Prompt Logging

Общият брой заявки и месечните разходи не са достатъчни, когато клиент попита защо един работен процес вчера е станал по-бавен, по-скъп или по-малко надежден. Мултимоделен API шлюз може да отговори на този въпрос, ако третира наблюдаемостта като част от контролната равнина: всяка заявка получава проследяване, всяко извикване на модел актуализира регистър на използването, всеки клиент и работен процес могат да бъдат приписани, а чувствителното съдържание е защитено по подразбиране.

Тази статия описва практичен дизайн за анализ на използването на AI и наблюдение на LLM в шлюз, който представя множество доставчици чрез OpenAIсъвместим API. Моделът е полезен дори ако не използвате конкретен доставчик: измервайте веднъж на шлюза, нормализирайте телеметрията на модела, запазвайте приписването на таксуването и улавяйте подканящо съдържание само при изрични правила.

Проблемът с четеца: „Кой клиент, модел, подкана или път за извличане е причинил промяната?“

Повечето екипи в крайна сметка се сблъскват със същия пропуск при отстраняване на грешки. Регистрационните файлове на приложението показват, че дадена функция е неуспешна. Таблата за управление на доставчика показват, че използването на токени се е увеличило. Финансите виждат сметка. Нито един от тези изгледи, сам по себе си, не обяснява пълния път от заявка на наемател до извикване на модел до контекст за извличане, за да опитате отново до таксувана цена.

Целта не е още едно табло за управление с общ брой токени. Целта е да се отговори на оперативни въпроси като:

• Кой наемател или API ключ е причинил скок на разходите?
• Увеличи ли се забавянето след промяна на псевдоним на модел?
• Повторните опити или резервните варианти отчитат ли двойно разходите?
• Коя версия на подкана изразходва най-много бюджет за грешки?
• Работният поток на RAG стана ли скъп, защото извличането добави твърде много контекстни токени?
• Може ли да поддържа отстраняване на грешки при инцидент, без да чете частни потребителски подкани?

Факти, препоръки и прогнози

Факти: OpenTelemetry документира Генеративни AI семантични конвенции и атрибути за операции на модела, включително имена на операции като chat, generate_content и text_completion. Същата документация предупреждава, че атрибутите на входно и изходно съобщение на GenAI може да съдържат чувствителна информация или PII и може да изискват филтриране или съкращаване. Основните доставчици на модели също така разкриват табла за управление на употребата, API или експортирания, които могат да поддържат съпоставяне от страна на доставчика, въпреки че подробностите се различават в зависимост от доставчика.

Препоръки: Използвайте OpenTelemetry за неутрални по отношение на доставчика проследявания, но запазете бизнес измеренията, притежавани от шлюз, в собствените ви атрибути и счетоводни книги. Не съхранявайте необработени подкани или изходи по подразбиране. Първо съхранявайте метаданни, хешове, брой токени, идентификатори на шаблони за подкани, имена на схеми, класове грешки и етикети за безопасност. Добавете заснемане на съдържание само като опция за отстраняване на грешки с контролиран достъп и кратко задържане.

Прогноза: Наблюдаемостта на LLM ще стане по-малко свързана с таблата за управление на изолирани доставчици и повече с равнините за контрол на различни доставчици. Екипите ще очакват едно място за разследване на латентност, цена, качество, събития, свързани с правилата, поведение на наемател и делта на таксуването между моделите.

Референтна архитектура: наблюдавайте целия път на заявката

Шлюзът може да види пълния жизнен цикъл на заявката, без да изисква всеки екип на приложението да създава персонализирана телеметрия. Един полезен модел за проследяване започва с един родителски интервал за входящата клиентска заявка и дъщерен диапазон за стъпките, които влияят върху разходите, забавянето и качеството.

Препоръчителна span структура

• Обхват на заявката за шлюз: заявката е приета, удостоверена, оторизирана, ограничена по скорост и насочена.
• Обхват на обаждането на модела: доставчик, модел, операция, използване на токен, състояние на отговор и закъснение.
• Обхват на извличане: заявен индекс, идентификационни номера на документи или хеширани идентификационни номера, брой парчета, забавяне на извличане и споделяне на контекстни токени.
• Обхват на извикване на инструмент: име на инструмента, състояние, латентност, клас на грешка и класификация на страничните ефекти.
• Обхват на повторния опит: причина за повторен опит, номер на опита, статус на доставчика и допълнителни разходи.
• Резервен диапазон: оригинален модел, резервен модел, тригер, политика за съвместимост и краен резултат.
• Преграда или обхват на модериране: извикана политика, решение, етикети и дали изходът е блокиран или трансформиран.
• Обхват на последваща обработка: JSON проверка, поправка на схема, проверки на цитати или окончателно форматиране.

Родителският диапазон трябва да носи стабилни корелационни идентификатори. Детските обхвати трябва да носят нормализирани технически атрибути. Книгата за използване трябва да съдържа трайни записи за фактуриране и анализи. Избягвайте да поставяте цялата информация в етикетите на показателите; стойностите с висока кардиналност, като идентификационни номера на наематели, хешове за подкани и идентификационни номера на документи, се съхраняват по-добре в проследявания, регистрационни файлове или таблици на главни книги и след това се агрегират в табла за управление.

Нормализиране на метаданните, заснети при всяко LLM обаждане

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

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "tenant_id": "tenant_123",
  "team_id": "team_456",
  "app_id": "support_bot",
  "gateway_key_id": "key_789",
  "operation": "chat",
  "provider": "provider_name",
  "model": "provider-model-id",
  "model_alias": "fast-support-chat",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  "status": "completed",
  "error_class": null,
  "latency_ms": 1842,
  "input_tokens": 2110,
  "output_tokens": 384,
  "cached_input_tokens": 1200,
  "estimated_cost_usd": "0.00492",
  "final_billed_cost_usd": null,
  "finish_reason": "stop",
  "retry_count": 0,
  "fallback_used": false,
  "content_capture_policy": "metadata_only"
}

Дръжте две идеи разделени: телеметрията обяснява какво се е случило, докато дневникът за използване записва какво трябва да бъде таксувано, съгласувано и отчетено. Те се препращат взаимно с идентификатори на заявки и идентификатори за проследяване, но не е необходимо да живеят в една и съща система за съхранение.

Изградете токен и регистър на разходите, а не само броячи

Броячите на токени са полезни за диаграми, но не са достатъчни за фактуриране или разследване на инциденти. Книгата трябва да представлява преходите на състоянията. Създайте ред, когато шлюзът приеме заявка, след което го актуализирайте, докато заявката напредва.

Полезни състояния на счетоводна книга

• прието: проверките за удостоверяване и правила са преминали.
• forwarded: заявката е изпратена до доставчик.
• streaming: доставчикът започна да връща токени.
• завършено: отговорът завърши успешно.
• user_aborted: клиентът прекъсна връзката преди завършване.
• повторен опит: беше направен допълнителен опит за доставчик.
• fallback_used: беше избран различен модел или доставчик след грешка или съответствие на правилата.
• неуспешно: заявката приключи без използваем отговор.
• съгласувано: данните за използването или разходите от страната на доставчика бяха сравнени и приложени.

Този модел на състояние помага за улавяне на често срещани грешки при таксуването и анализа: поточно предавани отговори, когато клиентът е прекъснал връзката, опити за повторен опит, които са били таксувани от доставчика, но скрити от потребителя, резервни пътища, които са отчели грешния модел, и разлики в кеширането на отчитането между доставчиците.

Използвайте конвенциите на OpenTelemetry GenAI, след което ги разширявайте внимателно

Семантичните конвенции на OpenTelemetry GenAI предоставят преносим речник за операции с модели. Използвайте тези конвенции за общи атрибути като име на операция, доставчик, модел, параметри на заявката, причини за завършване на отговора, използване на токен и състояние на грешка, където са приложими.

Неутралните по отношение на доставчика конвенции обаче няма да покрият всяко бизнес измерение в шлюза. Добавяне на притежавани от шлюза атрибути или колони в книга за:

• идентификатор на наемател, идентификационен номер на екип, идентификационен номер на клиент на дистрибутор и идентификационен номер на приложение;
• gateway API ИД на ключ и обхват на ключа;
• план за таксуване, лимит на разходите и бюджетна политика;
• псевдоним на модела и версия на правилата за маршрутизиране;
• ID на шаблона за подкана и версия на подкана;
• име на работния процес и стъпка на работния поток;
• приблизителна цена, крайна фактурирана цена и състояние на съгласуване.

Компромисът е кардиналността. Тези полета са ценни за разследване, но могат да направят показателите скъпи и шумни, ако се използват като етикети на показатели навсякъде. Практическо правило е: агрегатите с ниска кардиналност отиват към метрики; идентификаторите с висока кардиналност отиват към проследявания, регистрационни файлове и счетоводни книги.

Проектиране на безопасна подкана и регистриране на изхода

Пълното бързо регистриране улеснява отстраняването на грешки, но увеличава поверителността, съответствието, съхранението и излагането на вътрешни рискове. По-сигурното по подразбиране е наблюдението на първо място на метаданните.

По подразбиране: само метаданни

За повечето производствен трафик съхранявайте:

• ID и версия на шаблона за подкана;
• хешове на нормализирани подкани и изходи;
• входящи, изходни, кеширани и контекстни токени се броят;
• име на схемата на отговор и резултат от валидирането;
• етикети за безопасност и политически решения;
• обобщения на грешките и класове грешки на доставчика;
• метаданни за извличане, а не необработени документи.

Включване: контролирано заснемане на съдържание

Ако имате нужда от необработено или редактирано съдържание за дълбоко отстраняване на грешки, изисквайте изрична политика. Добрите контроли включват разрешени списъци на средата, съгласие на клиента, вземане на проби, максимална дължина на полезен товар, автоматично редактиране, кратки прозорци за задържане, криптиране, ролеви достъп, регистрационни файлове за одит и път за одобрение на счупено стъкло за чувствителни инциденти.

Не третирайте редакцията като перфектна. Намалява риска; не го елиминира. За регулирани или високочувствителни работни натоварвания помислете за съхраняване само на хешове и възпроизвеждане на проблеми в синтетичен пакет с одобрени тестови данни.

Добавяне на видимост на RAG като отделен слой

Генерирането с подобрено извличане може да промени както качеството, така и цената. Регистрирането само на последното извикване на модел скрива първопричината, когато ретривърът връща твърде много парчета, остарели документи или неподходящ контекст.

За всяка стъпка на извличане заснемете:

• име на индекс или колекция;
• стратегия за извличане и модел на вграждане;
• ИД на документи или хеширани идентификатори;
• брой парчета и общ контекстни токени;
• закъснение при извличане;
• разпределение на най-добрите резултати, ако е налично;
• обхват на цитиране;
• дали извлеченият контекст е използван в крайния отговор.

Това ви позволява да разграничите „моделът се влоши“ от „ретривърът започна да изпраща нискокачествен или прекомерен контекст“. Също така помага да се идентифицират работни потоци, при които контекстните токени доминират общите разходи.

Съгласуване на използването на шлюза с таксуването на доставчика

Оценките на шлюза са достъпни веднага. Данните за фактуриране от страна на доставчика обикновено са по-бавни, но по-достоверни. Използвайте и двете.

Ежедневното задание за съгласуване трябва да сравнява редовете на главната книга на шлюза с API за използване на доставчика, API за разходите, експорти на табло за управление или експорти на фактури. Групирайте делта по доставчик, модел, проект и времеви прозорец. Проследявайте разликите отделно за входни токени, изходни токени, кеширани токени, брой заявки и цена.

Често срещани различия при съгласуване

• Поточното предаване прекъсва: шлюзът може да види прекъснат клиент, докато доставчикът все още таксува генерираните токени.
• Повторни опити: многократните опити могат да бъдат таксувани дори ако бъде върнат само един краен отговор.
• Бързото кеширане: доставчиците може да излагат отчитането на кеширания токен по различен начин.
• Закръгляване: малки разлики за всяка заявка могат да станат видими в мащаб.
• Отстъпки за партиди или нива: фактурите на доставчика може да прилагат цени, които прогнозата в реално време все още не е знаела.
• Промени от страна на доставчика: ценообразуването на модела, поведението на токенизацията или експортирането на таксуване могат да се променят с времето.

Когато съгласуването открие делта, избягвайте тихото презаписване на счетоводната си книга. Съхранявайте първоначалната оценка, съгласуваната от доставчика стойност, източника на съгласуване и кода на причината, ако е известен.

Табла за управление, които отговарят на оперативни въпроси

Стартирайте таблата за управление от проблеми с четеца, а не от показатели за суета. Полезните изгледи включват:

• цена на наемател, екип, приложение и работен процес;
• цена на успешна задача, не само цена на заявка;
• p50, p95 и p99 закъснение по доставчик, модел и псевдоним на модела;
• резервен процент и процент на повторни опити по маршрут;
• честота на изчакване и тенденции в класа грешки на доставчика;
• коефициент на попадение в кеша и прогноза за спестяване на кеширани токени;
• честота на неуспешно валидиране на структуриран изход;
• най-популярните подканващи версии по грешка при изгаряне на бюджета;
• споделяне на RAG контекстен токен по работен процес;
• блокове на предпазните парапети и удари на класификатора за бързо инжектиране.

За предупреждение комбинирайте технически и бизнес сигнали. Внезапен скок на разходите на наемател може да е по-спешен от малко глобално увеличение на латентността. Скок на резервната честота след промяна на псевдоним на модел може да означава проблем със съвместимостта. Повтарящите се отговори 401, 429 или 5xx може да сочат ключови проблеми, изчерпване на квотата или нестабилност на доставчика.

Минимален поток на внедряване за OpenAI-съвместим прокси

За /chat/completions прокси потокът може да бъде прост:

1. Получаване на заявката и присвояване на request_id и проследяване на контекст.
2. Удостоверете ключа на шлюза и разрешите обхвата на наемател, екип, приложение и правила.
3. Създайте участъка на родителския шлюз.
4. Създаване на ред в книга със състояние accepted.
5. Разрешаване на псевдоним на модел към модел на доставчик и версия на правилата за маршрутизиране.
6. Метаданни за запис: операция, ID на шаблона за подкана, име на схема, хеш за подкана и политика за улавяне на съдържание.
7. Започнете обхвата на извикване на модела, като използвате семантични атрибути на GenAI, където е приложимо.
8. Препратете заявката до избрания доставчик.
9. За поточно предаване, актуализирайте състоянието, когато пристигне първата част и пребройте използването толкова точно, колкото позволява отговорът на доставчика.
10. При завършване анализирайте използването на доставчика, причината за приключване, състоянието и класа на грешката.
11. Актуализирайте счетоводната книга с токени, прогнозна цена, подробности за повторен/резервен опит и окончателно състояние на заявка.
12. Излъчване на показатели от счетоводната книга и данни за обхват.
13. Извършвайте ежедневно съгласуване и съхранявайте потвърдени от доставчика разходи отделно от първоначалната прогноза.

Контролен списък за разпространение

• Дефинирайте идентификатори на канонични заявки и идентификатори за проследяване.
• Приемане на OpenTelemetry GenAI атрибути за общ модел телеметрия.
• Създайте книга за използване на шлюз с преходи на състояние на заявка.
• Нормализиране на измерения на доставчик, модел, псевдоним на модел, клиент, приложение и работен поток.
• Пазете данни от проучване с висока кардиналност извън етикетите на показателите.
• Направете необработените подкани и улавянето на изхода деактивирани по подразбиране.
• Добавяне на изрични правила за вземане на проби, редактиране, задържане и контрол на достъпа.
• Заснемане на метаданни за извличане за RAG работни потоци.
• Изградете табла за управление за разходи, забавяне, надеждност, валидиране и поведение на наемателя.
• Съгласуване на оценките на шлюза с експортирането на използването и разходите на доставчика.
• Сигнал за пикове на разходите, регресии на забавяне, резервни скокове, неуспешно валидиране и събития, свързани със сигурността.

Заключение

Многомоделният шлюз е правилното място за внедряване на възможност за наблюдение на LLM, защото той вижда заявките, преди да достигнат до който и да е доставчик, и може да прикачи бизнес контекст, който доставчиците не знаят. Най-силният дизайн не е „регистрирайте всичко“. Това е многослоен модел: неутрални спрямо доставчика следи за изпълнение, траен токен и регистър на разходите за фактуриране, анализ на клиента за управление, RAG метаданни за качество на извличане и бързо регистриране на поверителността за безопасно отстраняване на грешки.

Започнете с метаданни, преходи на състояния и съгласуване. Добавете заснемане на съдържание само когато правилата, задържането и контролите за достъп са готови. Тази последователност дава на разработчиците доказателствата, от които се нуждаят, за да отстраняват грешки в латентността, качеството и разходите, без да превръщат наблюдаемостта в нов риск за излагане на данни.

Свързани четения

• повторни опити и резервно поведение в LLM API маршрутизиране
• бързо кеширане и пакетен контрол на разходите шаблони
• екип API управление на ключове и ограничения на разходите