Varför bygger verktyg för LLM-spårning nu AI-gateways?

År 2026 lade LangSmith, Langfuse, Opik och Braintrust alla till en gateway framför modellleverantörerna. Huvudskälet är kontroll: ett spårningsverktyg kan bara registrera ett modellanrop, medan en gateway kan stoppa det.

Två verktyg med olika uppgifter

Under de senaste två åren har många team kört applikationer med stora språkmodeller (LLM:er) med hjälp av två separata verktyg. En gateway låg mellan applikationen och modellleverantörerna. Den innehöll leverantörernas API-nycklar, översatte mellan olika leverantörers API:er och gjorde nya försök när anrop misslyckades. LiteLLM, en proxy med öppen källkod, blev ett vanligt val för den uppgiften. Bredvid applikationen fanns ett spårningsverktyg som LangSmith eller Langfuse, som registrerade varje modell- och verktygsanrop samt varje hämtningssteg så att utvecklarna kunde se vad en agent hade gjort.

Uppdelningen var logisk: en gateway måste vara snabb och ha stöd för alla leverantörers API:er, medan ett spårningsverktyg behöver ett bra gränssnitt, lagring för stora datamängder och ett SDK som omsluter applikationskoden. Langfuse beskriver fortfarande upplägget med två verktyg och har en integrering med LiteLLM Proxy som skickar varje anrop genom proxyn och vidare till Langfuse. År 2026 började spårningsleverantörerna själva bygga gateways.

Fyra lanseringar på sex månader

LangChain offentliggjorde LangSmith LLM Gateway i en privat betaversion i maj 2026 och öppnade den för offentlig betatestning den 30 juli. Sedan dess har tjänsten även blivit en del av LangSmiths driftsättningar med egen molnmiljö. Braintrust avvecklade sin tidigare AI-proxy och hänvisade användarna till en ny gateway, som är tillgänglig som förhandsversion och är gratis fram till den allmänna lanseringen. Comet lanserade Opik LLM Gateway som en betaversion av en slutpunkt som tar emot förfrågningar i OpenAI-format. Den 4 november öppnade Langfuse sin AI Gateway för offentlig betatestning, både på Langfuse Cloud och för självhostade driftsättningar. Gatewayen är MIT-licensierad och skriven i Rust.

MLflow, som började som ett verktyg för maskininlärningens livscykel snarare än som ett spårningsverktyg, har haft en AI-gateway längre och erbjuder budgetaviseringar och begränsningar.

Gateways har funnits i många år, och riskerna med att driva en är väldokumenterade. De nya gatewaylösningarna kommer från företag vars verksamhet gick ut på att registrera modellanrop, och nu vill företagen att varje anrop ska passera genom dem först.

Varför en budget kräver att förfrågningarna passerar genom gatewayen

Ett spårningsverktyg registrerar ett modellanrop först när leverantören har svarat och kostnaden för tokenen har betalats. Den informationen räcker för att skapa ett diagram över utgifterna, men spårningsverktyget kan inte stoppa kostnaderna. Att upprätthålla ett teams budget, blockera en modell eller ta bort en hemlighet ur en prompt kräver att förfrågan kontrolleras innan den når leverantören. Det kan bara den komponent som ingår i förfrågningens väg göra.

LangChain framför detta argument i sitt lanseringsinlägg. Företaget beskriver hur team kombinerar en separat gateway, en produkt för skyddsräcken och ett verktyg för observerbarhet, och säger att problem förebyggs genom att tillämpa policyer på förfrågningslagret. Om ett anrop skulle överskrida en budget svarar företagets gateway med HTTP-statuskoden 402 i stället för att vidarebefordra anropet till leverantören.

En enda ingång registrerar varje anrop

Det andra skälet är täckning. Ett SDK registrerar bara de kodvägar som någon har instrumenterat. Det är utanför dessa kodvägar som agentfel ofta går obemärkta förbi. Ett skript på en bärbar dator, en notebook eller en kodningsagent som använder en kopierad API-nyckel lämnar inga spår. En gateway som har leverantörsnycklarna ser varje anrop, eftersom det inte finns någon annan väg till leverantören.

Langfuse bygger sin gateway kring den här idén. Enligt dokumentationen för gatewayen hör varje gatewaynyckel till en användare eller ett tjänstkonto och kan ha metadata som ett team eller ett kostnadsställe. Endast gatewayen har leverantörens autentiseringsuppgifter, och administratörer godkänner vilka modeller varje uppsättning autentiseringsuppgifter får anropa. LangSmith publicerar konfigurationsguider för att dirigera Claude Code, Codex och Gemini CLI via sin gateway. Dessa agenter anropar modeller från utvecklarens dator, utanför spårningskoden i en applikation.

Vad spårningsverktygets gateway tillför

Spårningsleverantörerna framför också det omvända argumentet: en fristående gateway räcker inte på egen hand. I Langfuses lanseringsinlägg står det att en fristående gateway bara kan räkna token och kostnader, medan företagets egen gateway gör varje anrop till en del av en fullständig spårning. Langfuses gateway accepterar en W3C-header av typen traceparent, så ett anrop som går genom den kopplas till den spårning som applikationen redan har påbörjat. Som standard registrerar den användning och kostnad, men inte prompt- och svarsinnehåll.

Det här är det starkaste tekniska argumentet för att bygga in gatewayen i spårningsverktyget. En fristående gateway ser en platt lista över slutförda anrop. Ett spårningsverktyg har redan agentens verktygsanrop och hämtningssteg från dess SDK och kan placera varje gatewayanrop i den strukturen.

Det finns också en kommersiell aspekt, som leverantörerna själva inte nämner. Den som driver gatewayen har hand om leverantörsnycklarna och utgiftsrapporten, och det är den rapporten som ekonomi- och plattformsteamen läser. Därför är en gateway svårare att ersätta än ett verktyg för att visa spårningar. LangSmith och Langfuse använder redan den positionen på olika sätt: LangSmith säljer Gateway Credits, som låter kunder anropa värdhostade modeller som Kimi utan en egen leverantörsnyckel, medan det i Langfuses FAQ står att företaget inte säljer vidare token.

Vad betagatewayarna ännu inte kan göra

De här gatewayarna är nya, och leverantörerna redogör själva för sina begränsningar. Langfuses gateway stöder för närvarande bara OpenAI och Anthropic, medan Amazon Bedrock, Google Vertex AI och Google AI Studio finns med i planerna. Reservlösningar mellan leverantörer och fasta utgiftstak per team, användare eller nyckel är planerade men har ännu inte lanserats. För närvarande erbjuder gatewayen en översikt över utgifterna och aviseringar. Dokumentationen beskriver inte anropsbegränsningar eller cachelagring av svar.

Langfuses gateway konverterar inte mellan API-format, så en OpenAI-klient kan bara anropa OpenAI-modeller. Den egenhostade versionen anropar bara leverantörernas officiella URL:er, vilket för närvarande utesluter Azure OpenAI, Bedrock och interna proxyservrar. Comet beskriver Opik-gatewayen som avsedd för utveckling och testning. Braintrust har inte offentliggjort någon prissättning för sin gateway.

LangSmiths gateway kan redan mer än de andra. I dokumentationen anges reservlösningar, utgiftsgränser, anropsbegränsningar och datapolicyer som befintliga funktioner. Den stöder formaten OpenAI Chat Completions, OpenAI Responses och Anthropic Messages. Reservlösningar och anropsbegränsningar angavs som framtida funktioner i maj, så de tillkom under betaperioden. Produkten som helhet är fortfarande märkt som beta.

Lasttester visar en annan typ av brist. Ett egenhostat prestandatest av Langfuses gateway, LiteLLM och AcruxCore visade att Langfuses gateway tillförde mindre fördröjning per anrop än LiteLLM. Med Dockers standardinställningar misslyckades dock 739 av 1 000 samtidiga strömmar, eftersom processen behöll Dockers standardgräns på 1 024 öppna filer. En enda rad i Langfuses Compose-fil löste problemet.

Jämfört med dessa betaversioner stöder LiteLLM, som har funnits som fristående gateway i flera år, fler än 100 leverantörer och har redan virtuella nycklar, utgiftsspårning, skyddsräcken, lastbalansering och en administratörsöversikt. LiteLLM flyttar också sin anropshantering från Python till Rust. AI-gatewayen i Rust är i beta, och LiteLLM-teamet räknar med att anrop av typen Anthropic /v1/messages ska kunna hanteras hela vägen i Rust senast den 1 december, med ungefär 20 gånger lägre fördröjning. Några plattformar med öppen källkod, till exempel MLflow och AcruxCore, levereras redan med en gateway och spårning i samma produkt.

Argumenten för att hålla dem åtskilda

Att slå ihop gatewayen med spårningsverktyget har sina nackdelar, och den största är den täta kopplingen mellan dem. Med en separat gateway kan ett team byta leverantör av spårningslösning genom att ändra ett loggningsåteranrop. Om spårningsverktyget också är gatewayen måste dessutom varje tjänsts bas-URL, nycklar och modellidentifierare ändras. Langfuse skriver till exempel modellidentifierare på formen credential:model.

Spårningsverktyget blir också ett beroende under körning. Om spårningsbackendens tjänst ligger nere förlorar teamet sina spårningar. Om gatewayen ligger nere misslyckas modellernas anrop. En spårningsleverantör som driver gatewayen måste nu erbjuda samma driftsäkerhet som kritisk infrastruktur.

Säkerhetsleverantörer vill ha samma plats i anropsflödet. Palo Alto Networks slutförde förvärvet av Portkey, en fristående gateway, i maj 2026 och gjorde den till AI-gateway för sin Prisma AIRS-plattform. Ett säkerhetsteam kan vilja ha gatewayen under egen kontroll i stället för inuti ett observerbarhetsverktyg. Gatewayar har också blivit mål för angripare, vilket intrånget i LiteLLM:s leveranskedja i mars visade.

Så kan team välja

Team kan börja med att lista vad som måste ske innan ett modellanrop. Om de bara behöver insyn räcker ett spårningsverktyg vid sidan av anropsflödet, utan att skapa något beroende under körning. Om de också behöver budgetar, nyckelpolicyer eller godkännande av modeller behöver de någon form av gateway.

Därefter kommer vilka leverantörer som stöds. Ett team bör skriva ner alla leverantörer och API-format som används i produktion, däribland Azure OpenAI och Bedrock, och jämföra listan med vad varje gateway stöder i dag, inte med vad som står i planerna.

Team som redan använder LiteLLM har få skäl att byta innan en betagateway erbjuder något de saknar. Det viktigaste en gateway från en spårningsleverantör tillför är att gatewayanropet placeras i agentens spårning, och det måste vara värt en migrering. Team som börjar från grunden kan behålla gatewayen som ett eget lager även när en och samma leverantör står för båda. Om bas-URL och nycklar samlas i en konfigurationsmodul blir ett senare byte en konfigurationsändring i stället för en kodändring.

De flesta av dessa gatewayar är märkta som beta eller förhandsversion, så listan över begränsningar kommer att krympa snabbt. Den öppna frågan är vem som ska äga anropsflödet i ett typiskt företag: observerbarhetsteamet, plattformsteamet som driver en fristående gateway eller säkerhetsteamet. I år byggde LangSmith och Langfuse egna gatewayar och Palo Alto Networks köpte en, men i många teknikstackar går anropsflödet fortfarande via LiteLLM.