Miksi LLM-jäljitystyökalut rakentavat nyt tekoälyyhdyskäytäviä

Vuonna 2026 LangSmith, Langfuse, Opik ja Braintrust lisäsivät kaikki yhdyskäytävän mallipalveluntarjoajien eteen. Tärkein syy on hallinta: jäljitystyökalu voi vain tallentaa mallikutsun, kun taas yhdyskäytävä voi estää sen.

Kaksi eri tehtäviin tarkoitettua työkalua

Viimeisten kahden vuoden ajan monet tiimit ovat käyttäneet suuria kielimalleja (LLM) hyödyntäviä sovelluksia kahden erillisen työkalun avulla. Yhdyskäytävä sijaitsi sovelluksen ja mallipalveluntarjoajien välissä. Se säilytti palveluntarjoajien API-avaimia, muunsi kutsut palveluntarjoajien API-rajapintojen välillä ja yritti uudelleen epäonnistuneita kutsuja. LiteLLM, avoimen lähdekoodin välityspalvelin, nousi yleiseksi valinnaksi tähän tehtävään. Sovelluksen rinnalla oli LangSmithin tai Langfusen kaltainen jäljitystyökalu, joka tallensi jokaisen mallikutsun, työkalukutsun ja tiedonhakuvaiheen, jotta insinöörit pystyivät näkemään, mitä agentti oli tehnyt.

Työnjako oli järkevä, sillä yhdyskäytävän on oltava nopea ja tuettava jokaisen palveluntarjoajan API-rajapintaa, kun taas jäljitystyökalu tarvitsee hyvän käyttöliittymän, tallennustilaa suurille tietosisällöille ja sovelluskoodin kapseloivan SDK:n. Langfuse dokumentoi edelleen kahden työkalun kokoonpanon ja LiteLLM-välityspalvelinin integraation, joka ohjaa jokaisen kutsun välityspalvelimen kautta Langfuseen. Vuonna 2026 jäljitystyökalujen tarjoajat alkoivat rakentaa yhdyskäytävää itse.

Neljä julkaisua kuudessa kuukaudessa

LangChain julkisti LangSmithin LLM-yhdyskäytävän yksityisessä beetatestissä toukokuussa 2026 ja avasi sen julkiseen beetatestaukseen 30. heinäkuuta. Sittemmin se on lisännyt sen myös osaksi LangSmithin omassa pilviympäristössä käytettäviä käyttöönottoja. Braintrust poisti aiemman tekoälyn välityspalvelimensa käytöstä ja ohjasi käyttäjät uuteen yhdyskäytävään, joka on esikatseluvaiheessa ja maksuton yleiseen saatavuuteen asti. Comet julkaisi Opikin LLM-yhdyskäytävän beetaversiona toimivana rajapintapisteenä, joka hyväksyy OpenAI-muotoisia pyyntöjä. Langfuse avasi tekoälyyhdyskäytävänsä julkiseen beetatestaukseen 4. marraskuuta sekä Langfuse Cloudissa että itse ylläpidettävissä käyttöönottoympäristöissä. Yhdyskäytävä on MIT-lisensoitu ja kirjoitettu Rustilla.

MLflow, joka aloitti koneoppimisen elinkaaren hallintatyökaluna jäljitystyökalun sijaan, on tarjonnut tekoälyyhdyskäytävän jo pidempään. Siinä on budjettihälytyksiä ja -rajoituksia.

Yhdyskäytäviä on ollut olemassa vuosia, ja niiden ylläpitämiseen liittyvät riskit tunnetaan hyvin. Uudet yhdyskäytävät ovat peräisin yrityksiltä, joiden liiketoiminta perustui mallikutsujen tallentamiseen ja jotka haluavat nyt, että kaikki kutsut kulkevat ensin niiden kautta.

Miksi budjetin hallinta edellyttää pyyntöjen kulkureitillä olemista

Jäljitystyökalu tallentaa mallikutsun vasta sen jälkeen, kun palveluntarjoaja on vastannut ja tokenit on maksettu. Tämän tallenteen avulla voi piirtää kulutuskaavion, mutta jäljitystyökalu ei voi pysäyttää kulutusta. Tiimin budjetin noudattamisen valvonta, mallin estäminen tai salaisuuden poistaminen kehotteesta edellyttävät kaikki pyynnön tarkistamista ennen kuin se saavuttaa palveluntarjoajan. Vain pyyntöjen kulkureitillä oleva komponentti voi tehdä tämän.

LangChain esittää tämän perustelun julkaisussaan, jossa se esitteli yhdyskäytävän. Se kuvailee, kuinka tiimit yhdistävät erillisen yhdyskäytävän, suojakaidetuotteen ja havainnointityökalun, ja toteaa, että ongelmien ehkäiseminen edellyttää käytäntöjen valvontaa pyyntökerroksessa. Jos yhdyskäytävän kautta tuleva kutsu ylittäisi budjetin, yhdyskäytävä vastaa HTTP-tilakoodilla 402 sen sijaan, että välittäisi pyynnön palveluntarjoajalle.

Yksi yhteyspiste tallentaa jokaisen kutsun

Toinen syy on kattavuus. SDK tallentaa vain ne koodipolut, jotka joku on instrumentoinut. Näiden polkujen ulkopuolella agenttien virheet jäävät usein huomaamatta. Kannettavalla tietokoneella suoritettava skripti, muistikirja tai koodausagentti, joka käyttää kopioitua API-avainta, ei jätä jälkeä. Palveluntarjoajan avaimia hallussaan pitävä yhdyskäytävä näkee jokaisen kutsun, koska palveluntarjoajalle ei ole muuta reittiä.

Langfuse rakentaa yhdyskäytävänsä tämän ajatuksen varaan. Yhdyskäytävän dokumentaation mukaan jokainen yhdyskäytävän avain kuuluu käyttäjälle tai palvelutilille, ja siihen voidaan liittää metatietoja, kuten tiimi tai kustannuspaikka. Vain yhdyskäytävä säilyttää palveluntarjoajan tunnistetiedon, ja ylläpitäjät hyväksyvät, mitä malleja kullakin tunnistetiedolla saa kutsua. LangSmith julkaisee määrityssivuja, joilla Claude Code, Codex ja Gemini CLI reititetään sen yhdyskäytävän kautta. Nämä agentit kutsuvat malleja kehittäjän koneelta sovelluksen jäljityskoodin ulkopuolelta.

Mitä jäljitystyökalun yhdyskäytävä tuo lisää

Jäljitystyökalujen tarjoajat esittävät myös päinvastaisen perustelun: erillinen yhdyskäytävä ei yksin riitä. Langfusen julkaisussa todetaan, että erillinen yhdyskäytävä pystyy ainoastaan laskemaan tokenit ja kustannukset, kun taas sen oma yhdyskäytävä liittää jokaisen kutsun osaksi täydellistä jäljitysketjua. Langfusen yhdyskäytävä hyväksyy W3C:n traceparent-otsakkeen, joten sen kautta kulkeva kutsu liittyy jäljitysketjuun, jonka sovellus on jo aloittanut. Oletusarvoisesti se tallentaa käytön ja kustannukset, ei kehotteiden ja vastausten sisältöä.

Tämä on vahvin tekninen peruste yhdyskäytävän rakentamiselle osaksi jäljitystyökalua. Erillinen yhdyskäytävä näkee vain tasaisen luettelon täydennyksistä. Jäljitystyökalulla on jo SDK:n kautta tiedot agentin työkalukutsuista ja tiedonhakuvaiheista, ja se voi sijoittaa jokaisen yhdyskäytävän kautta kulkevan kutsun tähän rakenteeseen.

Asiaa voi tarkastella myös kaupallisesta näkökulmasta, vaikka palveluntarjoajat eivät itse tuo sitä esiin. Yhdyskäytävän ylläpitäjällä ovat hallussaan palveluntarjoajien avaimet ja kulutusraportti, jota talous- ja alustatiimit seuraavat. Siksi yhdyskäytävää on vaikeampi korvata kuin jäljitysten katseluohjelmaa. LangSmith ja Langfuse hyödyntävät tätä asemaa jo eri tavoin: LangSmith myy Gateway Credits -krediittejä, joiden avulla asiakkaat voivat käyttää isännöityjä malleja, kuten Kimiä, ilman omaa palveluntarjoajan avainta, kun taas Langfusen usein kysytyissä kysymyksissä kerrotaan, ettei se jälleenmyy tokeneita.

Mitä beta-yhdyskäytävät eivät vielä pysty tekemään

Nämä yhdyskäytävät ovat uusia, ja palveluntarjoajat dokumentoivat itse niiden puutteita. Langfusen yhdyskäytävä tukee tällä hetkellä vain OpenAI:ta ja Anthropicia, ja Amazon Bedrock, Google Vertex AI sekä Google AI Studio ovat sen kehityssuunnitelmassa. Palveluntarjoajien väliset varajärjestelyt ja tiimi-, käyttäjä- tai avainkohtaiset kiinteät kulutusrajat ovat suunnitteilla, mutta niitä ei ole vielä julkaistu. Toistaiseksi yhdyskäytävä tarjoaa kulutuksen hallintapaneelin ja hälytyksiä. Dokumentaatiossa ei kuvata nopeusrajoituksia eikä vastausten välimuistia.

Langfusen yhdyskäytävä ei muunna API-muotojen välillä, joten OpenAI-asiakasohjelmalla voi kutsua vain OpenAI-malleja. Itse isännöity versio kutsuu ainoastaan palveluntarjoajien virallisia URL-osoitteita, mikä sulkee toistaiseksi pois Azure OpenAI:n, Bedrockin ja sisäisen välityspalvelimen käytön. Cometin mukaan Opik-yhdyskäytävä on suunniteltu kehitys- ja testaustyöhön. Braintrust ei ole ilmoittanut yhdyskäytävänsä hinnoittelua.

LangSmithin yhdyskäytävä tarjoaa jo enemmän kuin muut. Sen dokumentaatiossa varajärjestelyt, kulutusrajat, nopeusrajoitukset ja tietokäytännöt luetellaan nykyisiksi ominaisuuksiksi. Se hyväksyy OpenAI Chat Completions-, OpenAI Responses- ja Anthropic Messages -muodot. Varajärjestelyt ja nopeusrajoitukset mainittiin toukokuussa tulevina ominaisuuksina, joten ne lisättiin betavaiheen aikana. Koko tuote on silti edelleen merkitty betaversioksi.

Kuormitustestaus paljastaa toisenlaisen puutteen. Langfuse-yhdyskäytävän, LiteLLM:n ja AcruxCoren itse isännöidyssä vertailutestissä havaittiin, että Langfuse-yhdyskäytävä lisäsi pyyntökohtaista viivettä vähemmän kuin LiteLLM. Oletusarvoisilla Docker-asetuksillaan se kuitenkin epäonnistui 739:ssä 1 000 samanaikaisesta suoratoistoyhteydestä, koska sen prosessissa oli käytössä Dockerin avoimien tiedostojen oletusraja, 1 024. Yksi rivi Langfusen Compose-tiedostossa korjasi ongelman.

Näihin betaversioihin verrattuna jo vuosia itsenäisenä yhdyskäytävänä toiminut LiteLLM tukee yli 100 palveluntarjoajaa ja sisältää jo virtuaaliavaimet, kulutuksen seurannan, suojaukset, kuormantasaamisen ja järjestelmänvalvojan hallintapaneelin. LiteLLM siirtää myös pyyntöpolkua Pythonista Rustiin. Sen Rust-tekoäly-yhdyskäytävä on betavaiheessa, ja LiteLLM-tiimi odottaa, että Anthropic-tyyliset /v1/messages-pyynnöt käsitellään päästä päähän Rustilla joulukuun 1. päivään mennessä noin 20 kertaa pienemmällä viiveellä. Muutamat avoimen lähdekoodin alustat, kuten MLflow ja AcruxCore, tarjoavat jo yhdyskäytävän ja jäljityksen yhtenä tuotteena.

Perusteet niiden pitämiselle erillään

Yhdyskäytävän yhdistämisestä jäljitystyökaluun aiheutuu kustannuksia, joista suurin on järjestelmien kytkeytyminen toisiinsa. Kun yhdyskäytävä on erillinen, tiimi voi vaihtaa jäljityspalveluntarjoajaa muuttamalla lokituksen takaisinkutsufunktiota. Jos jäljitystyökalu toimii myös yhdyskäytävänä, jokaisen palvelun perus-URL-osoite, avaimet ja mallitunnisteet on muutettava samalla. Langfuse esimerkiksi kirjoittaa mallitunnisteet muodossa tunnistetieto:malli.

Jäljitystyökalusta tulee myös ajonaikainen riippuvuus. Jos jäljityksen taustajärjestelmä kaatuu, tiimi menettää jäljitystiedot. Jos yhdyskäytävä kaatuu, mallikutsut epäonnistuvat. Jäljityspalveluntarjoajan, joka ylläpitää yhdyskäytävää, on nyt taattava kriittiseltä infrastruktuurilta vaadittava käytettävyys.

Tietoturvapalveluntarjoajat haluavat saman aseman pyyntöpolulla. Palo Alto Networks sai päätökseen erillisen yhdyskäytävän Portkeyn yritysoston toukokuussa 2026 ja teki siitä Prisma AIRS -alustansa tekoäly-yhdyskäytävän. Tietoturvatiimi saattaa haluta yhdyskäytävän omaan hallintaansa sen sijaan, että se olisi osa havainnointityökalua. Yhdyskäytävistä on tullut myös hyökkääjien kohteita, kuten LiteLLM:n toimitusketjuhyökkäys maaliskuussa osoitti.

Näin tiimit voivat valita

Tiimit voivat aloittaa luettelemalla, mitä kaikkea on tapahduttava ennen mallikutsua. Jos ne tarvitsevat vain näkyvyyttä, pyyntöpolun rinnalla toimiva jäljitystyökalu riittää eikä aiheuta ajonaikaista riippuvuutta. Jos ne tarvitsevat myös budjetteja, avainkäytäntöjä tai mallien hyväksyntää, ne tarvitsevat jonkinlaisen yhdyskäytävän.

Seuraavaksi on tarkistettava palveluntarjoajien kattavuus. Tiimin kannattaa kirjata ylös kaikki tuotantokäytössä kutsumansa palveluntarjoajat ja API-muodot, mukaan lukien Azure OpenAI ja Bedrock, ja verrata luetteloa kunkin yhdyskäytävän nykyiseen tukeen kehityssuunnitelman sijaan.

LiteLLM:ää jo käyttävillä tiimeillä ei ole juuri syytä siirtyä muualle, ennen kuin beta-yhdyskäytävä tarjoaa jotakin, mitä niiltä puuttuu. Tärkein lisä, jonka jäljitystyökalun yhdyskäytävä tuo, on yhdyskäytäväkutsun sisällyttäminen agentin jäljitykseen, ja sen on oltava siirtymisen vaivan arvoista. Alusta aloittavat tiimit voivat pitää yhdyskäytävän omana kerroksenaan, vaikka sama palveluntarjoaja tarjoaisi molemmat. Kun perus-URL-osoite ja avaimet ovat yhdessä määritysmoduulissa, myöhempi siirtyminen vaatii vain määrityksen muuttamista eikä koodimuutoksia.

Useimmat näistä yhdyskäytävistä on merkitty beta- tai esikatseluversioiksi, joten puuteluettelo lyhenee nopeasti. Avoimeksi jää kysymys siitä, kuka hallitsee pyyntöpolkua tyypillisessä yrityksessä: havainnointitiimi, erillistä yhdyskäytävää ylläpitävä alustatiimi vai tietoturvatiimi. Tänä vuonna LangSmith ja Langfuse rakensivat omat yhdyskäytävänsä ja Palo Alto Networks osti yhden, mutta monissa teknologiapinoissa pyyntöpolku kulkee edelleen LiteLLM:n kautta.