Чому інструменти трасування LLM тепер створюють шлюзи ШІ

У 2026 році LangSmith, Langfuse, Opik і Braintrust додали шлюз перед провайдерами моделей. Головна причина — контроль: інструмент трасування може лише зафіксувати виклик моделі, тоді як шлюз може його зупинити.

Два інструменти для різних завдань

Останні два роки багато команд використовували для застосунків на базі великих мовних моделей (LLM) два окремі інструменти. Шлюз розташовувався між застосунком і провайдерами моделей. У ньому зберігалися API-ключі провайдерів; він перетворював запити між API різних провайдерів і повторював невдалі виклики. LiteLLM, проксі з відкритим вихідним кодом, став поширеним вибором для цього завдання. Поруч із застосунком працював інструмент трасування, як-от LangSmith або Langfuse, який записував кожен виклик моделі, виклик інструмента та етап отримання даних, щоб інженери могли бачити, що робив агент.

Такий поділ мав сенс, адже шлюз має працювати швидко й підтримувати API кожного провайдера, тоді як інструменту трасування потрібні зручний інтерфейс, сховище для великих обсягів даних і SDK, що обгортає код застосунку. Langfuse і досі описує конфігурацію з двома інструментами, зокрема інтеграцію LiteLLM Proxy, яка спрямовує кожен виклик через проксі до Langfuse. У 2026 році постачальники інструментів трасування почали самостійно створювати шлюзи.

Чотири запуски за шість місяців

LangChain анонсувала шлюз LangSmith LLM у закритій бета-версії в травні 2026 року, а 30 липня відкрила публічну бета-версію; згодом шлюз також став частиною розгортань LangSmith у власній хмарі клієнтів. Braintrust припинила підтримку свого попереднього проксі для ШІ і спрямувала користувачів до нового шлюзу, який наразі доступний у попередній версії та буде безкоштовним до загального запуску. Comet випустила шлюз Opik LLM як бета-версію кінцевої точки, що приймає запити у форматі OpenAI. 4 листопада Langfuse відкрила публічну бета-версію свого шлюзу ШІ як у Langfuse Cloud, так і для самостійного розгортання. Шлюз поширюється за ліцензією MIT і написаний мовою Rust.

MLflow, який спочатку був інструментом для керування життєвим циклом машинного навчання, а не трасування, уже довше має шлюз ШІ з попередженнями та обмеженнями щодо бюджету.

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

Чому для контролю бюджету потрібен доступ до шляху запиту

Інструмент трасування записує виклик моделі вже після того, як провайдер надав відповідь і за токени сплачено. Цього запису достатньо, щоб побудувати діаграму витрат, але інструмент трасування не може зупинити витрати. Щоб контролювати бюджет команди, блокувати модель або вилучати секрет із запиту, потрібно перевірити запит до того, як він надійде провайдеру. Це може зробити лише компонент, через який проходить запит.

LangChain обґрунтовує цю позицію у дописі про запуск. У ньому описано, як команди поєднують окремий шлюз, продукт для захисних механізмів і інструмент спостережуваності, а також стверджується, що для запобігання проблемам політики потрібно застосовувати на рівні запитів. Якщо виклик перевищить бюджет, шлюз повертає код стану HTTP 402 замість того, щоб переслати його провайдеру.

Одна точка входу фіксує кожен виклик

Друга причина — повнота охоплення. SDK записує лише ті шляхи виконання коду, які хтось інструментував. Саме за межами цих шляхів збої агентів часто залишаються непоміченими. Скрипт на ноутбуці, блокнот або агент для написання коду, що використовує скопійований API-ключ, не залишає сліду. Шлюз, у якому зберігаються ключі провайдерів, бачить кожен виклик, бо іншого шляху до провайдера немає.

Langfuse будує свій шлюз на цьому принципі. Згідно з документацією шлюзу, кожен ключ шлюзу належить користувачеві або обліковому запису служби й може містити метадані, наприклад назву команди чи центру витрат. Лише шлюз зберігає облікові дані провайдера, а адміністратори визначають, до яких моделей можна звертатися з кожним набором облікових даних. LangSmith публікує інструкції з налаштування маршрутизації Claude Code, Codex і Gemini CLI через свій шлюз. Ці агенти викликають моделі з комп’ютера розробника, поза межами коду трасування будь-якого застосунку.

Що додає шлюз інструмента трасування

Постачальники інструментів трасування наводять і зворотний аргумент: самостійного шлюзу недостатньо. У дописі про запуск Langfuse стверджується, що окремий шлюз може лише підраховувати токени та витрати, тоді як власний шлюз Langfuse включає кожен виклик до повного трасування. Шлюз Langfuse приймає заголовок W3C traceparent, тож виклик через нього долучається до трасування, яке вже розпочав застосунок. За замовчуванням він записує використання та витрати, але не вміст запитів і відповідей.

Це найпереконливіший технічний аргумент на користь інтеграції шлюзу в інструмент трасування. Самостійний шлюз бачить лише неструктурований список запитів і відповідей. Інструмент трасування вже отримує з SDK виклики інструментів і етапи отримання даних агента, тож може вбудувати в цю структуру кожен виклик через шлюз.

Є й комерційний аспект, про який самі постачальники не говорять. Той, хто керує шлюзом, має ключі провайдерів і звіт про витрати, а саме цей звіт читають фінансові та платформні команди. Через це шлюз важче замінити, ніж засіб перегляду трас. LangSmith і Langfuse вже по-різному використовують таке становище: LangSmith продає Gateway Credits, які дають клієнтам змогу звертатися до розміщених моделей, як-от Kimi, без власного ключа провайдера, тоді як у розділі поширених запитань Langfuse зазначено, що компанія не перепродає токени.

Чого бета-версії шлюзів поки що не вміють

Ці шлюзи ще нові, і постачальники самі документують їхні обмеження. Наразі шлюз Langfuse підтримує лише OpenAI та Anthropic; Amazon Bedrock, Google Vertex AI і Google AI Studio є в планах розвитку. Механізми резервного перемикання між провайдерами та жорсткі ліміти витрат для команди, користувача чи ключа заплановані, але ще не випущені; поки що шлюз пропонує панель витрат і сповіщення. У документації не описано обмеження частоти запитів або кешування відповідей.

Шлюз Langfuse не перетворює формати API, тож клієнт OpenAI може звертатися лише до моделей OpenAI. Версія для самостійного розгортання звертається лише до офіційних URL-адрес провайдерів, тому наразі не підтримує Azure OpenAI, Bedrock або внутрішній проксі. Comet описує шлюз Opik як призначений для розробки й тестування. Braintrust не оголошувала ціни на свій шлюз.

Шлюз LangSmith уже вміє більше, ніж інші. У документації резервне перемикання, ліміти витрат, обмеження частоти запитів і політики щодо даних зазначені як доступні функції; крім того, шлюз підтримує формати OpenAI Chat Completions, OpenAI Responses і Anthropic Messages. У травні резервне перемикання й обмеження частоти запитів ще значилися як заплановані функції, тож їх додали під час бета-тестування. Увесь продукт досі має статус бета-версії.

Навантажувальне тестування виявляє інший тип обмежень. Під час тестування шлюзу Langfuse, LiteLLM і AcruxCore у середовищі для самостійного розгортання з’ясувалося, що шлюз Langfuse додавав до кожного виклику меншу затримку, ніж LiteLLM. Однак зі стандартними налаштуваннями Docker він не впорався з 739 із 1 000 одночасних потоків, оскільки його процес залишав стандартне обмеження Docker у 1 024 відкриті файли. Це виправив один рядок у файлі Compose Langfuse.

На відміну від цих бета-версій, LiteLLM — окремий шлюз, який існує вже багато років, — підтримує понад 100 провайдерів і вже має віртуальні ключі, відстеження витрат, захисні механізми, балансування навантаження та панель адміністратора. LiteLLM також переносить обробку запитів із Python на Rust. Його шлюз ШІ на Rust перебуває в бета-версії, а команда LiteLLM очікує, що до 1 грудня запити формату /v1/messages, як у Anthropic, повністю оброблятимуться на Rust із приблизно у 20 разів меншою затримкою. Деякі платформи з відкритим кодом, зокрема MLflow і AcruxCore, уже постачають шлюз і трасування в межах одного продукту.

Аргументи на користь їхнього розділення

Об’єднання шлюзу із системою трасування має свої недоліки, і найбільший із них — тісний зв’язок між компонентами. Якщо шлюз окремий, команда може змінити постачальника засобу трасування, змінивши лише функцію зворотного виклику для журналювання. Якщо ж система трасування водночас є шлюзом, доведеться змінювати базову URL-адресу, ключі та ідентифікатори моделей у кожному сервісі. Наприклад, Langfuse записує ідентифікатори моделей у форматі credential:model.

Система трасування також стає залежністю під час виконання. Якщо серверна частина трасування припинить роботу, команда втратить траси. Якщо відмовить шлюз, виклики моделей завершаться помилкою. Тепер постачальник засобу трасування, який керує шлюзом, має забезпечувати безперебійну роботу критично важливої інфраструктури.

Постачальники рішень із безпеки прагнуть посісти те саме місце на шляху запиту. У травні 2026 року Palo Alto Networks завершила придбання Portkey, окремого шлюзу, і зробила його шлюзом ШІ своєї платформи Prisma AIRS. Команда з безпеки може захотіти, щоб шлюз перебував під її власним контролем, а не був частиною інструмента спостережуваності. Шлюзи також стали мішенню для зловмисників, про що свідчить компрометація ланцюга постачання LiteLLM у березні.

Як командам зробити вибір

Команди можуть почати з переліку всього, що має відбутися до виклику моделі. Якщо їм потрібна лише видимість, достатньо розмістити систему трасування поруч зі шляхом запиту — це не створить залежності під час виконання. Якщо ж їм також потрібні бюджети, політики щодо ключів або погодження моделей, знадобиться шлюз певного типу.

Далі варто оцінити підтримку провайдерів. Команді слід записати всі провайдери й формати API, які вона використовує у виробничому середовищі, зокрема Azure OpenAI та Bedrock, і порівняти цей перелік із поточною підтримкою кожного шлюзу, а не з планами його розвитку.

Командам, які вже використовують LiteLLM, немає особливих причин переходити на інше рішення, доки бета-версія шлюзу не запропонує чогось, чого їм бракує. Головна перевага шлюзу від постачальника системи трасування — можливість включити виклик шлюзу до траси агента, і це має виправдовувати перехід. Команди, які починають із нуля, можуть залишити шлюз окремим рівнем, навіть якщо обидва компоненти постачає один постачальник. Якщо зберігати базову URL-адресу й ключі в одному модулі конфігурації, згодом можна буде перейти на інше рішення, змінивши конфігурацію, а не код.

Більшість цих шлюзів мають статус бета-версії або попередньої версії, тож перелік обмежень швидко скорочуватиметься. Відкритим залишається питання, хто керуватиме шляхом запиту в типовій компанії: команда спостережуваності, платформна команда, що обслуговує окремий шлюз, чи команда безпеки. Цього року LangSmith і Langfuse створили власні шлюзи, а Palo Alto Networks придбала один із них, однак у багатьох технологічних стеках запити й досі проходять через LiteLLM.