Derfor bygger verktøy for sporing av LLM-er nå AI-gatewayer

I 2026 la LangSmith, Langfuse, Opik og Braintrust alle til en gateway foran modellleverandørene. Hovedgrunnen er kontroll: Et sporingsverktøy kan bare registrere et modellkall, mens en gateway kan stanse det.

To verktøy med hver sine oppgaver

De siste to årene har mange team brukt to separate verktøy til applikasjoner basert på store språkmodeller (LLM-er). En gateway lå mellom applikasjonen og modellleverandørene. Den oppbevarte leverandørenes API-nøkler, oversatte mellom leverandørenes API-er og prøvde mislykkede kall på nytt. LiteLLM, en proxy med åpen kildekode, ble et vanlig valg til denne oppgaven. Ved siden av applikasjonen lå et sporingsverktøy som LangSmith eller Langfuse, som registrerte hvert modellkall, verktøykall og hentetrinn, slik at utviklerne kunne se hva en agent hadde gjort.

Det var fornuftig å dele opp oppgavene, fordi en gateway må være rask og støtte API-et til hver leverandør, mens et sporingsverktøy trenger et godt grensesnitt, lagringsplass for store datamengder og et SDK som pakker inn applikasjonskoden. Langfuse dokumenterer fortsatt oppsettet med to verktøy, med en integrasjon med LiteLLM Proxy som sender hvert kall gjennom proxyen og videre til Langfuse. I 2026 begynte leverandørene av sporingsverktøy å bygge gatewayen selv.

Fire lanseringer på seks måneder

LangChain kunngjorde LangSmith LLM Gateway i en lukket betaversjon i mai 2026 og åpnet den for offentlig betatesting 30. juli. Siden har selskapet også gjort den til en del av LangSmiths distribusjoner der kundene bruker sin egen sky. Braintrust avviklet sin tidligere AI-proxy og viste brukerne til en ny gateway, som er tilgjengelig som forhåndsversjon og er gratis fram til generell tilgjengelighet. Comet lanserte Opik LLM Gateway som et betaendepunkt som godtar forespørsler i OpenAI-format. 4. november åpnet Langfuse sin AI Gateway for offentlig betatesting, både på Langfuse Cloud og for selvdriftede distribusjoner. Gatewayen er MIT-lisensiert og skrevet i Rust.

MLflow, som opprinnelig var et verktøy for maskinlæringslivssyklusen og ikke et sporingsverktøy, har hatt en AI-gateway lenger, med budsjettvarsler og -grenser.

Gatewayer har eksistert i årevis, og risikoen ved å drifte en er godt dokumentert. De nye gatewayene kommer fra selskaper som har hatt som virksomhet å registrere modellkall, og som nå vil at alle kall først skal gå gjennom dem.

Derfor må budsjettkontroll skje i forespørselsbanen

Et sporingsverktøy registrerer et modellkall etter at leverandøren har svart og tokenene er betalt for. Denne registreringen er nok til å lage et diagram over forbruket, men sporingsverktøyet kan ikke stanse pengebruken. Å håndheve et teams budsjett, blokkere en modell eller fjerne en hemmelighet fra en prompt krever at forespørselen kontrolleres før den når leverandøren. Bare komponenten i forespørselsbanen kan gjøre det.

LangChain fremmer dette argumentet i lanseringsinnlegget sitt. Selskapet beskriver hvordan team kombinerer en separat gateway, et produkt for sikkerhetsregler og et verktøy for observerbarhet, og sier at problemer forebygges ved å håndheve retningslinjer på forespørselslaget. Gatewayen svarer med HTTP-statuskoden 402 på kall som vil overskride et budsjett, i stedet for å videresende dem til leverandøren.

Ett inngangspunkt registrerer alle kall

Den andre grunnen er dekning. Et SDK registrerer bare de kodebanene noen har instrumentert. Utenfor disse banene er det lett at agentfeil forblir ubemerket. Et skript på en bærbar datamaskin, en notatbok eller en kodeagent som bruker en kopiert API-nøkkel, etterlater ingen spor. En gateway som oppbevarer leverandørenes nøkler, ser alle kall, fordi det ikke finnes noen annen vei til leverandøren.

Langfuse bygger gatewayen sin rundt denne ideen. Ifølge dokumentasjonen for gatewayen tilhører hver gateway-nøkkel en bruker eller en tjenestekonto og kan inneholde metadata som team eller kostnadssted. Bare gatewayen oppbevarer leverandørens tilgangslegitimasjon, og administratorer godkjenner hvilke modeller hver legitimasjon kan brukes til å kalle. LangSmith publiserer veiledninger for oppsett av ruting av Claude Code, Codex og Gemini CLI gjennom gatewayen. Disse agentene kaller modeller fra utviklerens maskin, utenfor sporingskoden til en applikasjon.

Hva en gateway fra et sporingsverktøy tilfører

Leverandørene av sporingsverktøy fremmer også det motsatte argumentet: En frittstående gateway er ikke nok i seg selv. I lanseringsinnlegget sitt skriver Langfuse at en frittstående gateway bare kan telle token og beregne kostnader, mens selskapets egen gateway gjør hvert kall til en del av et fullstendig spor. Langfuses gateway godtar en W3C traceparent-header, slik at et kall gjennom gatewayen blir del av sporet applikasjonen allerede har startet. Som standard registrerer den bruk og kostnader, ikke innholdet i prompter og svar.

Dette er det sterkeste tekniske argumentet for å bygge gatewayen inn i sporingsverktøyet. En frittstående gateway ser en flat liste over fullføringer. Et sporingsverktøy har allerede agentens verktøykall og hentetrinn fra SDK-et sitt, og kan plassere hvert gateway-kall i denne strukturen.

Det finnes også en kommersiell dimensjon som leverandørene ikke selv trekker fram. Den som driver gatewayen, sitter med leverandørnøklene og kostnadsrapporten, og det er kostnadsrapporten økonomi- og plattformteamene leser. Derfor er en gateway vanskeligere å bytte ut enn et verktøy for visning av spor. LangSmith og Langfuse utnytter allerede denne posisjonen på ulike måter: LangSmith selger Gateway Credits, som lar kundene bruke vertsbaserte modeller som Kimi uten egne leverandørnøkler, mens det står i FAQ-en til Langfuse at selskapet ikke videreselger token.

Hva betagatewayene ennå ikke kan gjøre

Disse gatewayene er nye, og leverandørene dokumenterer selv hva de mangler. Langfuse-gatewayen støtter foreløpig bare OpenAI og Anthropic, mens Amazon Bedrock, Google Vertex AI og Google AI Studio står på veikartet. Reservealternativer mellom leverandører og absolutte kostnadsgrenser per team, bruker eller nøkkel er planlagt, men ikke lansert. Foreløpig tilbyr gatewayen et kostnadsdashbord og varsler. Dokumentasjonen omtaler ikke forespørselsgrenser eller hurtigbufring av svar.

Langfuse-gatewayen konverterer ikke mellom API-formater, så en OpenAI-klient kan bare kalle OpenAI-modeller. Den egenhostede versjonen kaller bare offisielle URL-er for leverandørene, noe som foreløpig utelukker Azure OpenAI, Bedrock og en intern proxy. Comet beskriver Opik-gatewayen som utviklet for utvikling og testing. Braintrust har ikke kunngjort priser for gatewayen sin.

LangSmith-gatewayen kan allerede mer enn de andre. Dokumentasjonen oppgir reservealternativer, kostnadsgrenser, forespørselsgrenser og datapolicyer som tilgjengelige funksjoner, og gatewayen godtar formatene OpenAI Chat Completions, OpenAI Responses og Anthropic Messages. Reservealternativer og forespørselsgrenser sto på listen over planlagte funksjoner i mai, så de kom på plass i løpet av betaperioden. Produktet som helhet er fortsatt merket som beta.

Belastningstesting avdekker en annen type svakhet. En egenhostet sammenligningstest av Langfuse-gatewayen, LiteLLM og AcruxCore viste at Langfuse-gatewayen ga lavere ekstra latens per kall enn LiteLLM. Med standardinnstillingene i Docker feilet den imidlertid på 739 av 1 000 samtidige strømmer fordi prosessen beholdt Dockers standardgrense på 1 024 åpne filer. Én linje i Compose-filen til Langfuse løste problemet.

Sammenlignet med disse betaversjonene støtter LiteLLM, som har vært en frittstående gateway i årevis, over 100 leverandører og har allerede virtuelle nøkler, kostnadssporing, sikkerhetsregler, lastbalansering og et administrasjonsdashbord. LiteLLM flytter også behandlingen av forespørsler fra Python til Rust. Rust-basert AI-gateway er i beta, og LiteLLM-teamet venter at forespørsler av Anthropic-typen til /v1/messages skal kunne behandles fra ende til ende i Rust innen 1. desember, med omtrent 20 ganger lavere latens. Noen få åpen kildekode-plattformer, som MLflow og AcruxCore, leveres allerede med gateway og sporing i ett og samme produkt.

Argumenter for å holde dem atskilt

Det har en kostnad å slå sammen gatewayen og sporingsverktøyet, og den største ulempen er at de blir tett koblet. Med en separat gateway kan et team bytte leverandør av sporingsverktøy ved å endre et loggings-callback. Når sporingsverktøyet også er gatewayen, må basis-URL-en, nøklene og modellidentifikatorene til hver tjeneste også endres. Langfuse skriver for eksempel modellidentifikatorer på formen credential:model.

Sporingsverktøyet blir også en kjøretidsavhengighet. Hvis en sporingsbackend går ned, mister teamet sporene. Hvis en gateway går ned, mislykkes modellkallene. En leverandør av sporingsverktøy som driver gatewayen, må nå sørge for oppetid på nivå med kritisk infrastruktur.

Sikkerhetsleverandører ønsker også å være en del av samme forespørselsbane. Palo Alto Networks fullførte oppkjøpet av Portkey, en frittstående gateway, i mai 2026 og gjorde den til AI-gatewayen i Prisma AIRS-plattformen sin. Et sikkerhetsteam kan ønske å ha gatewayen under egen kontroll i stedet for at den ligger innebygd i et observability-verktøy. Gatewayer har også blitt mål for angripere, noe forsyningskjedeangrepet mot LiteLLM i mars viste.

Slik kan team velge

Team kan begynne med å liste opp hva som må skje før et modellkall. Hvis de bare trenger innsyn, er et sporingsverktøy ved siden av forespørselsbanen nok, og det innfører ingen kjøretidsavhengighet. Hvis de også trenger budsjetter, regler for nøkler eller godkjenning av modeller, trenger de en eller annen form for gateway.

Deretter bør teamet se på hvilke leverandører som støttes. Teamet bør skrive ned alle leverandørene og API-formatene det bruker i produksjon, inkludert Azure OpenAI og Bedrock, og sammenligne listen med det hver gateway støtter nå, ikke det som står på veikartet.

Team som allerede bruker LiteLLM, har liten grunn til å bytte før en betagateway tilbyr noe de mangler. Det viktigste en gateway fra en leverandør av sporingsverktøy tilfører, er at gatewaykall blir plassert inne i agentens spor, og det må være verdt en migrering. Team som starter fra grunnen av, kan beholde gatewayen som et eget lag selv om én leverandør tilbyr begge deler. Hvis basis-URL-en og nøklene ligger i én konfigurasjonsmodul, blir en senere overgang en konfigurasjonsendring i stedet for en kodeendring.

De fleste av disse gatewayene er merket som beta eller forhåndsversjon, så listen over mangler vil raskt bli kortere. Det åpne spørsmålet er hvem som skal eie forespørselsbanen i en typisk bedrift: observability-teamet, plattformteamet som driver en frittstående gateway, eller sikkerhetsteamet. I år bygde LangSmith og Langfuse egne gatewayer, og Palo Alto Networks kjøpte en, men i mange systemmiljøer går forespørselsbanen fortsatt gjennom LiteLLM.