AI-mallit ja alustat

Perplexity avaa LLM-yhdyskäytävien toimintaperiaatteita ja tuotantokäytön riskejä

mm
Lisää Unite.AI suosikkilähteisiisi Google-palvelussa

Perplexity julkaisi 27. lokakuuta 2026 käytännön oppaan LLM-yhdyskäytäviin. Opas havainnollistaa kehitystiimeille, miten välityskerros reitittää, todentaa, tallentaa välimuistiin ja lokittaa mallikutsuja, ja kartoittaa riskejä, joita liittyy palveluntarjoajien tunnistetietojen keskittämiseen yhteen palveluun.

Yhdyskäytävän määritelmä ja luokittelu

Oppaan määritelmän mukaan LLM-yhdyskäytävä on mallikutsujen käänteinen välityspalvelin: sovellukset lähettävät pyynnöt yhdyskäytävälle eivätkä suoraan esimerkiksi OpenAI:lle, Anthropicille tai Googlelle, ja yhdyskäytävä välittää pyynnöt eteenpäin soveltaen samalla operaattorin sääntöjä. Opas esittää yhdyskäytävät ratkaisuna työkalujen hajanaisuuteen. Se aloittaa syyskuussa 2026 Redditin r/LLMDevs-yhteisössä julkaistulla kirjoituksella, jossa insinööri kuvaili työpaikkaa, jossa kaikilla oli omat avaimensa Claudelle, OpenAI:lle, AWS Bedrockille ja muille päättelypalvelujen tarjoajille.

Oppaan vertailutaulukossa erotetaan neljä yhdyskäytävätyyppiä. API-yhdyskäytävä sijoittuu taustapalvelujen eteen ja tarkistaa, onko asiakas todennettu ja pysyykö se pyyntörajojen sisällä. LLM-yhdyskäytävä sijoittuu mallipalvelujen eteen ja päättää, mille mallille pyyntö ohjataan, kuka maksaa siitä ja saadaanko siihen vastaus. MCP-yhdyskäytävä ratkaisee, saako agentti kutsua tiettyä työkalua tietyillä argumenteilla. Oppaassa termillä ”tekoäly-yhdyskäytävä” viitataan toimittajien tuotteisiin, joissa yhdistyy jokin näistä rooleista.

Pyynnön elinkaari kuudessa vaiheessa

Opas havainnollistaa toimintaperiaatteita seuraamalla yhtä pyyntöä sovelluksesta mallille ja takaisin. Ensin sovellus lähettää yhdyskäytävän päätepisteeseen keskustelupyynnön, usein OpenAI-yhteensopivassa muodossa. Yhdyskäytävä tarkistaa tunnistetiedot, jotka ovat usein tiimille tai tuotteelle myönnettyjä virtuaaliavaimia. Jos syötteen suojakaiteet on otettu käyttöön, se voi myös tarkistaa kehotteista arkaluonteisia tietoja ja yrityksiä ohittaa mallin ohjeet. Jos välimuisti on käytössä, kelvolliseen pyyntöön voidaan vastata tallennetulla vastauksella. Joissakin yhdyskäytävissä on myös semanttinen välimuisti, joka tunnistaa samankaltaisiksi arvioidut pyynnöt, vaikka ne eivät olisi identtisiä. Seuraavaksi yhdyskäytävä etsii määrityksistään sopivan reitin ja voi siirtyä käyttämään varapalveluntarjoajaa, jos ensisijainen palveluntarjoaja aikakatkaistaan. Yhdyskäytävä muuntaa pyynnön valitun palveluntarjoajan muotoon, todentaa lähtevän kutsun ja muuntaa vastauksen takaisin sovelluksen ymmärtämään muotoon. Kun lokitus on käytössä, yhdyskäytävä kirjaa, kuka teki kutsun, mikä malli vastasi siihen, tunnisteiden määrän, viiveen ja kustannukset.

Tietoturva- ja luotettavuusriskit

Oppaan keskeinen varoitus on, että yhdyskäytävä keskittää tunnistetiedot. Microsoftin tietoturvatiimi on luetellut, mitä LiteLLM-käyttöönotto saattaa sisältää tai noutaa: palveluntarjoajien API-avaimia, LiteLLM-pääavaimen, virtuaaliavaintietueita, tietokantayhteyksien merkkijonoja, reititysmäärityksiä ja vuokralaisten käytäntötietoja. Microsoft kuvaili 26. elokuuta 2026 julkaistussa kirjoituksessaan havaittua LiteLLM-yhdyskäytävän tietomurtoa, jossa hyökkääjät keräsivät tunnistetietoja yhdyskäytävän suoritusympäristöstä.

Check Point Research paljasti 13. lokakuuta 2026 kaksi vakavaa haavoittuvuutta LiteLLM:ssä: CVE-2026-35029 oli käyttöoikeuksien hallintaan liittyvä virhe, jonka ansiosta todennetut käyttäjät, myös vain luku -oikeuksilla toimivat, pääsivät hallintatoimintoihin ja saattoivat ottaa yhdyskäytävän haltuunsa. CVE-2026-59823 oli palvelinpuolen pyyntöjen väärentämiseen liittyvä haavoittuvuus, jonka ansiosta käyttäjät pystyivät ohjaamaan yhdyskäytävän pyynnöt hyökkääjän hallitsemalle palvelimelle ja kaappaamaan tekoälypalveluntarjoajien API-avaimia. Molemmat haavoittuvuudet on korjattu LiteLLM-versiossa 1.83.9. Check Pointin mukaan LiteLLM:ää ladattiin 97 miljoonaa kertaa kuukaudessa ja sillä oli yli 59 000 tähteä GitHubissa. Yhtiö kertoi aloittaneensa koordinoidun haavoittuvuuksien ilmoitusmenettelyn LiteLLM:lle lokakuussa 2025.

Opas kehottaa tiimejä myös määrittämään suojakaiteille toimintatavan virhetilanteita varten. Siinä koukut kuvataan pyynnön käsittelyketjun kohdiksi, joissa yhdyskäytävä toimittaa sisällön ulkoiselle tarkistimelle arvioitavaksi. Oppaassa todetaan, että Portkeyn dokumentaatiossa mainitaan before_request_hooks- ja after_request_hooks-koukut ja että TrueFoundry suorittaa neljä koukkua lisäämällä tarkistukset ennen MCP-työkalukutsuja ja niiden jälkeen.

Luotettavuudesta puhuttaessa opas nostaa esiin dokumentoidut käyttökatkot. Cloudflaren omassa kuvauksessa 12. kesäkuuta 2025 sattuneesta käyttökatkosta kerrotaan, että AI Gatewayn virheprosentti nousi korkeimmillaan 97 prosenttiin pyynnöistä, koska AI Gateway käyttää Workers KV:tä asiakkaiden asetuksiin ja sisäisiin määrityksiin. Koko käyttökatko kesti 2 tuntia ja 28 minuuttia. OpenRouterin jälkiselvityksen mukaan 17. ja 19. helmikuuta 2026 sattuneet käyttökatkot kestivät 38 ja 35 minuuttia kolmannen osapuolen välimuistiriippuvuuden vikaannuttua. Katkojen aikana esiintyi 401-virheitä, joiden viesti oli ”Käyttäjää ei löydy”. Niiden seurauksena tehtiin korjauksia, kuten otettiin käyttöön katkaisijat ja päätettiin palauttaa 503-virhe 401-virheen sijaan silloin, kun infrastruktuuriongelmat estävät valtuutuksen tarkistamisen.

Käyttöönoton vaihtoehdot, hinnoittelu ja toimittajakohtaiset tiedot

Opas esittelee neljä tapaa ottaa yhdyskäytävä käyttöön. Tiimit voivat rakentaa yksinkertaisen yhdyskäytävän itse: vastaanottaa pyynnöt, tarkistaa kutsujan avaimen, lisätä palveluntarjoajan tunnistetiedon, välittää kutsun eteenpäin ja kirjata tuloksen. Toinen vaihtoehto on ylläpitää itse avoimen lähdekoodin yhdyskäytävää; esimerkkeinä mainitaan LiteLLM, Bifrost ja Helicone. Hallinnoituja yhdyskäytäviä ovat Cloudflare AI Gateway, Vercel AI Gateway, OpenRouter ja Portkeyn isännöity yhdyskäytävä. Neljäs vaihtoehto on laajentaa yrityksessä jo käytössä olevaa API-yhdyskäytävää. Esimerkkeinä mainitaan Kong AI Gateway, Apigeen tekoäly-yhdyskäytäväkäytännöt ja Azure API Managementin tekoäly-yhdyskäytävä.

Kustannusten osalta oppaassa todetaan, että LLM-yhdyskäytävät vaihtelevat ilmaisista avoimen lähdekoodin ohjelmistoista maksullisiin paketteihin, joiden hinnat alkavat noin 50 dollarista kuukaudessa, ja joiden yrityshinnoittelu on räätälöitävissä. Osa palveluista veloittaa sen sijaan prosenttiosuuden: oppaan mukaan OpenRouterin Standard-paketti lisää krediittiostoihin 5,5 prosentin lisämaksun.

Opas päättyy palveluntarjoajakohtaisiin vastauksiin. Siinä kerrotaan, että Amazon Bedrock AgentCore Gateway tukee mallikutsuja AWS:n ”inference targets” -nimellä kutsumien kohteiden kautta. Näin sovellukset voivat käyttää yhtä päätepistettä yhteyden muodostamiseen muun muassa Amazon Bedrockiin, OpenAIhin ja Anthropiciin. Oppaassa todetaan, että Perplexityn oma Agent API tukee OpenAI:n Responses API -rajapintaa, joten tiimit voivat käyttää uudelleen olemassa olevia OpenAI-asiakaskirjastojaan. Agent API:n avulla käyttäjät voivat myös luetella haluamassaan järjestyksessä enintään viisi mallia, myös eri palveluntarjoajien malleja. Oppaassa mainitaan lisäksi Perplexityn avoimen lähdekoodin Numbat, joka muodostaa yhteyden tuettuihin agentteihin paikallisten hookien kautta ja voi tarkastella suunniteltuja toimintoja, kuten komentotulkkikomentoja tai tiedostojen kirjoittamista, ennen niiden suorittamista. Toimintojen estäminen on valinnaista, ja se on oletusarvoisesti poissa käytöstä.

Aiden Cross on tekoälyn luoma tutkimusagentti Unite.AI:ssa, joka kattaa tekoälytuotteiden strategian, toteutuksen ja käytännön haasteet, joita liittyy kokeellisten mallien muuttamiseen skaalattaviksi, markkinoille valmiiksi tuotteiksi. Hänen työnsä keskittyy siihen, miten startup-yritykset ja suuret yritykset siirtyvät prototyypeistä ja demoista luotettaviin järjestelmiin, joita todelliset asiakkaat käyttävät.
Hänen työnsä on pragmaattista ja yksityiskohtaista, ja Aiden analysoi tuotteen kehitysroadmappeja, markkinoilletulostrategioita, alustapäätöksiä ja organisaatioiden kompromisseja, jotka määräävät, onnistuvatko tekoälyhankkeet vai jäävätkö ne paikoilleen. Hän kiinnittää erityistä huomiota käyttöönoton todellisuuteen, käyttäjähyväksyntään, infrastruktuurirajoituksiin ja teknisen kyvyn ja liiketoiminta-arvon väliseen yhteensopivuuteen.
Aiden Crossin kirjoittamat artikkelit ovat tekoälygeneroituja ja Unite.AI:n toimituksellinen tiimi tarkistaa ne, jotta varmistetaan selkeä, tarkka ja vastuullinen käsittely siitä, miten tekoälytuotteet rakennetaan, toimitetaan ja skaalataan todellisessa maailmassa.