Derfor bygger værktøjer til sporing af LLM’er nu AI-gateways

I 2026 tilføjede LangSmith, Langfuse, Opik og Braintrust alle en gateway foran modeludbyderne. Hovedårsagen er kontrol: Et sporingsværktøj kan kun registrere et modelkald, mens en gateway kan stoppe det.

To værktøjer med hver sin opgave

I de seneste to år har mange teams kørt applikationer med store sprogmodeller (LLM’er) ved hjælp af to separate værktøjer. En gateway sad mellem applikationen og modeludbyderne. Den opbevarede udbydernes API-nøgler, oversatte mellem udbydernes API’er og forsøgte igen at gennemføre fejlslagne kald. LiteLLM, en open source-proxy, blev et almindeligt valg til denne opgave. Ved siden af applikationen lå et sporingsværktøj som LangSmith eller Langfuse, der registrerede hvert modelkald, værktøjskald og hentningstrin, så ingeniørerne kunne se, hvad en agent havde foretaget sig.

Opdelingen gav mening, fordi en gateway skal være hurtig og understøtte alle udbyderes API’er, mens et sporingsværktøj har brug for en god brugerflade, lagerplads til store datamængder og et SDK, der indpakker applikationskoden. Langfuse beskriver stadig opsætningen med to værktøjer, hvor en integration med LiteLLM Proxy sender hvert kald gennem proxyen og videre til Langfuse. I 2026 begyndte leverandørerne af sporingsværktøjer selv at bygge gatewayen.

Fire lanceringer på seks måneder

LangChain annoncerede LangSmith-gatewayen til LLM’er i en lukket betaversion i maj 2026 og åbnede for offentlig betatest den 30. juli. Siden har virksomheden også gjort den til en del af LangSmith-implementeringer, hvor kunderne bruger deres egen cloud. Braintrust udfasede sin tidligere AI-proxy og henviste brugerne til en ny gateway, der er tilgængelig som forhåndsvisning og er gratis indtil den generelle lancering. Comet lancerede Opik-gatewayen til LLM’er som et betaslutenpunkt, der accepterer forespørgsler i OpenAI-format. Den 4. november åbnede Langfuse sin AI-gateway i offentlig betaversion, både på Langfuse Cloud og til selvhostede implementeringer. Gatewayen er licenseret under MIT-licensen og skrevet i Rust.

MLflow, der begyndte som et værktøj til maskinlæringens livscyklus snarere end som et sporingsværktøj, har haft en AI-gateway i længere tid med budgetadvarsler og -grænser.

Gateways har eksisteret i årevis, og risiciene ved at drive en er veldokumenterede. De nye gateways kommer fra virksomheder, hvis forretning bestod i at registrere modelkald, og som nu ønsker, at alle kald først går gennem dem.

Derfor kræver et budget adgang til forespørgselsstien

Et sporingsværktøj registrerer et modelkald, efter at udbyderen har svaret, og tokens er blevet betalt. Registreringen er nok til at tegne en graf over forbruget, men sporingsværktøjet kan ikke standse udgifterne. At håndhæve et teams budget, blokere en model eller fjerne en hemmelighed fra en prompt kræver, at forespørgslen kontrolleres, før den når udbyderen. Kun den komponent, der indgår i forespørgselsstien, kan gøre det.

LangChain fremfører dette argument i sit lanceringsindlæg. Virksomheden beskriver, hvordan teams kombinerer en separat gateway, et værktøj til sikkerhedsforanstaltninger og et overvågningsværktøj, og siger, at problemer forebygges ved at håndhæve politikker på forespørgselslaget. Hvis et kald ville overskride budgettet, svarer virksomhedens gateway med HTTP-statuskoden 402 i stedet for at videresende kaldet til udbyderen.

Ét indgangspunkt registrerer alle kald

Den anden grund er dækning. Et SDK registrerer kun de kodeforløb, som nogen har instrumenteret. Det er uden for disse forløb, at fejl hos agenter ofte går ubemærket hen. Et script på en bærbar computer, en notesbog eller en kodningsagent, der bruger en kopieret API-nøgle, efterlader ingen spor. En gateway, der opbevarer udbydernes nøgler, ser alle kald, fordi der ikke findes nogen anden vej til udbyderen.

Langfuse bygger sin gateway op omkring denne idé. Ifølge dokumentationen til gatewayen tilhører hver gatewaynøgle en bruger eller en tjenestekonto og kan indeholde metadata som et team eller et omkostningssted. Kun gatewayen opbevarer udbyderens adgangsoplysninger, og administratorer godkender, hvilke modeller hver adgangsoplysning må bruges til at kalde. LangSmith offentliggør opsætningsvejledninger til at sende Claude Code, Codex og Gemini CLI gennem sin gateway. Disse agenter kalder modeller fra en udviklers computer, uden om enhver applikations sporingskode.

Hvad en gateway i et sporingsværktøj tilfører

Leverandørerne af sporingsværktøjer fremfører også det omvendte argument: En selvstændig gateway er ikke nok i sig selv. Langfuses lanceringsindlæg siger, at en selvstændig gateway kun kan tælle tokens og beregne omkostninger, mens virksomhedens egen gateway gør hvert kald til en del af et fuldt spor. Langfuses gateway accepterer en W3C traceparent-header, så et kald gennem gatewayen føjes til det spor, som applikationen allerede har startet. Som standard registrerer den forbrug og omkostninger, men ikke indholdet af prompts og svar.

Dette er det stærkeste tekniske argument for at bygge gatewayen ind i sporingsværktøjet. En selvstændig gateway ser en flad liste over modelgenereringer. Et sporingsværktøj har allerede agentens værktøjskald og hentningstrin fra sit SDK, og kan placere hvert gatewaykald i den struktur.

Der er også en kommerciel dimension, som leverandørerne ikke selv nævner. Den, der driver gatewayen, har provider-nøglerne og forbrugsrapporten, og det er forbrugsrapporten, som økonomi- og platformteams læser. Det gør en gateway sværere at udskifte end en sporingsvisning. LangSmith og Langfuse udnytter allerede denne position på forskellige måder: LangSmith sælger Gateway Credits, som gør det muligt for kunder at kalde hostede modeller som Kimi uden deres egen provider-nøgle, mens det fremgår af Langfuses FAQ, at tjenesten ikke videresælger tokens.

Hvad betagatewayene endnu ikke kan

Disse gateways er nye, og leverandørerne dokumenterer selv deres mangler. Langfuses gateway understøtter i øjeblikket kun OpenAI og Anthropic, mens Amazon Bedrock, Google Vertex AI og Google AI Studio står på køreplanen. Reserveudbydere og faste forbrugslofter pr. team, bruger eller nøgle er planlagt, men endnu ikke lanceret. Indtil videre tilbyder gatewayen et forbrugsdashboard og advarsler. Dokumentationen beskriver ikke hastighedsgrænser eller caching af svar.

Langfuse-gatewayen konverterer ikke mellem API-formater, så en OpenAI-klient kun kan kalde OpenAI-modeller. Den selvhostede version kalder kun officielle udbyder-URL’er, hvilket indtil videre udelukker Azure OpenAI, Bedrock og en intern proxy. Comet beskriver Opik-gatewayen som udviklet til udvikling og test. Braintrust har ikke offentliggjort priser for sin gateway.

LangSmiths gateway kan allerede mere end de andre. Dokumentationen angiver reserveudbydere, forbrugsgrænser, hastighedsgrænser og datapolitikker som aktuelle funktioner, og gatewayen accepterer formaterne OpenAI Chat Completions, OpenAI Responses og Anthropic Messages. Reserveudbydere og hastighedsgrænser stod på listen over kommende funktioner i maj, så de blev tilføjet i betaperioden. Produktet er stadig mærket som beta.

Belastningstest afslører en anden type mangel. En selvhostet benchmarktest af Langfuse-gatewayen, LiteLLM og AcruxCore viste, at Langfuse-gatewayen tilføjede mindre latenstid pr. kald end LiteLLM. Med standardindstillingerne i Docker fejlede den dog for 739 af 1.000 samtidige strømme, fordi processen beholdt Dockers standardgrænse på 1.024 åbne filer. En enkelt linje i Langfuses Compose-fil løste problemet.

Sammenlignet med disse betaversioner understøtter LiteLLM, en selvstændig gateway, der har eksisteret i årevis, mere end 100 udbydere og omfatter allerede virtuelle nøgler, forbrugssporing, sikkerhedsregler, belastningsfordeling og et administrationsdashboard. LiteLLM er også ved at flytte sin anmodningsbehandling fra Python til Rust. Dens AI-gateway i Rust er i beta, og LiteLLM-teamet forventer, at anmodninger i Anthropic-stil til /v1/messages kan behandles hele vejen igennem i Rust inden 1. december med omkring 20 gange lavere latenstid. Nogle få open source-platforme, såsom MLflow og AcruxCore, leverer allerede en gateway og sporing i ét produkt.

Argumenterne for at holde dem adskilt

Det har omkostninger at slå gatewayen sammen med sporingsværktøjet, og den største ulempe er den tætte kobling. Med en separat gateway kan et team skifte sporingsleverandør ved at ændre et logningscallback. Når sporingsværktøjet også fungerer som gateway, skal hver tjenestes basis-URL, nøgler og model-id’er også ændres. Langfuse skriver for eksempel model-id’er i formatet credential:model.

Sporingsværktøjet bliver også en afhængighed ved kørsel. Hvis en sporingsbackend går ned, mister teamet sine sporingsdata. Hvis en gateway går ned, fejler modelkald. En sporingsleverandør, der driver gatewayen, skal nu levere samme oppetid som kritisk infrastruktur.

Sikkerhedsleverandører ønsker at indtage samme plads i anmodningsforløbet. Palo Alto Networks fuldførte opkøbet af Portkey, en selvstændig gateway, i maj 2026 og gjorde den til AI-gatewayen i virksomhedens Prisma AIRS-platform. Et sikkerhedsteam foretrækker måske at have gatewayen under egen kontrol frem for at placere den i et værktøj til observerbarhed. Gateways er også blevet et mål for angribere, som forsyningskædebruddet hos LiteLLM i marts viste.

Sådan kan teams vælge

Teams kan begynde med at opremse, hvad der skal ske, før et modelkald foretages. Hvis de kun har brug for indsigt, er et sporingsværktøj ved siden af anmodningsforløbet tilstrækkeligt og medfører ingen afhængighed ved kørsel. Hvis de også har brug for budgetter, nøglepolitikker eller modelgodkendelse, har de brug for en gateway af en eller anden slags.

Dernæst kommer understøttelsen af udbydere. Et team bør skrive alle de udbydere og API-formater, det bruger i produktion, ned, herunder Azure OpenAI og Bedrock, og sammenligne listen med hver gateways aktuelle understøttelse frem for dens køreplan.

Teams, der allerede bruger LiteLLM, har kun ringe grund til at skifte, før en betagateway tilbyder noget, de mangler. Det vigtigste, en gateway fra et sporingsværktøj tilføjer, er, at gatewaykaldet indgår i agentens sporingsdata, og det skal være en migrering værd. Teams, der starter fra bunden, kan beholde gatewayen som et selvstændigt lag, selv når én leverandør leverer begge dele. Hvis basis-URL’en og nøglerne ligger i ét konfigurationsmodul, bliver et senere skift en konfigurationsændring i stedet for en kodeændring.

De fleste af disse gateways er mærket som beta eller forhåndsvisning, så listen over mangler vil hurtigt blive kortere. Det åbne spørgsmål er, hvem der får ansvaret for anmodningsforløbet i en typisk virksomhed: observerbarhedsteamet, platformsteamet, der driver en selvstændig gateway, eller sikkerhedsteamet. I år har LangSmith og Langfuse bygget deres egne gateways, og Palo Alto Networks har købt en, men i mange teknologistakke går anmodningsforløbet stadig gennem LiteLLM.