LLM-yhdyskäytävät 2026: LiteLLM, Portkey, OpenRouter ja Kong AI Gateway vertailussa

Päivitetty: 13. syyskuuta 2026

LLM-yhdyskäytävä (LLM gateway) on OpenAI-yhteensopiva välipalvelin, joka reitittää sovelluksesi pyynnöt yhdestä päätepisteestä useille malli- ja pilvitarjoajille, ja tekee siinä sivussa fallbackit, kustannusseurannan, ratelimitit, semanttisen välimuistin sekä avainhallinnan. Vuonna 2026 vaihtoehdot ovat käytännössä kutistuneet neljään: LiteLLM (avoin lähdekoodi, itsehostattava), Portkey (SaaS ja oma control plane), OpenRouter (malliaggregaattori marketplacena) ja Kong AI Gateway (yritys-API-kerroksen laajennus). Olen ajanut näistä kolmea tuotannossa, joten kerron tässä artikkelissa suoraan, mitä oikeasti kannattaa valita mihinkin.

• LiteLLM voittaa itsehostatussa tuotannossa: yksi Python-proxy, tukee 100+ tarjoajaa ja integroituu Langfuseen suoraan.
• Portkey on paras SaaS-vaihtoehto tiimeille, jotka haluavat valmiin dashboardin, prompteille versiohallinnan ja guardrailsin ilman ylimääräistä infratyötä.
• OpenRouter ei ole yhdyskäytävä sen klassisessa mielessä, vaan malli-marketplace. Hyvä prototypointiin ja mallien A/B-testaukseen, huono tiukkoihin compliance-vaatimuksiin.
• Kong AI Gateway on oikea valinta vain, jos ajat jo Kongia. Muuten sen policy-malli on ylimitoitettu LLM-liikenteelle.
• Semanttinen välimuisti leikkaa käytännössä 20–40 % tokenkustannuksista, mutta vain jos embedding-malli ja kynnysarvo on kalibroitu evaluaatiodatasi kanssa.
• Prompt caching (Anthropic, OpenAI) toimii yhdyskäytävän läpi, mutta LiteLLM ja Portkey käsittelevät cache_control-headerin eri tavalla. Testaa se ennen tuotantoon vientiä.

Mikä on LLM-yhdyskäytävä?

LLM-yhdyskäytävä on välipalvelin, joka esittää yhtenäisen OpenAI-yhteensopivan REST-rajapinnan sovelluksellesi ja piilottaa taakseen kymmeniä tarjoajia: Anthropic, Google, Mistral, AWS Bedrock, Azure OpenAI, Cohere, Together, Groq, Fireworks ja niin edelleen. Kun sovelluksesi kutsuu POST /v1/chat/completions mallilla claude-opus-4-7, yhdyskäytävä hoitaa auth-headerin vaihdon Anthropicin muotoon, converttaa vastauksen takaisin OpenAI-formaattiin ja kirjaa telemetrian.

Se ratkaisee viisi konkreettista ongelmaa, jotka jokainen LLM-tiimi kohtaa jossain vaiheessa. Ensinnäkin vendor lock-in: kun teet suoran integraation Anthropicin SDK:hon, GPT-5-migraation aikataulu määräytyy siitä, kuinka nopeasti ehdit korvata anthropic.messages.create()-kutsut. Toiseksi fallback: kun Anthropic on alhaalla klo 03:00 (ja niin käy vuosittain), yhdyskäytävä kääntää liikenteen automaattisesti Bedrockiin tai OpenAI:hin ilman että sinun tarvitsee herätä. Kolmanneksi rate limiting per käyttäjä, tiimi tai virtuaalinen avain. Neljänneksi kustannusseuranta, joka on API-natiiveissa SDK:issa käytännössä olematon. Ja viidenneksi havainnointi: pyyntöjen, vastausten, latenssin ja tokenkäytön keskitetty kirjaus.

Olen nähnyt tiimien yrittää rakentaa nämä viisi ominaisuutta sovellustasolla. Se toimii kunnes kolmas mikropalvelu tarvitsee saman logiikan, ja päädyt kopioimaan retry-koodin kuutta kertaa. Yhdyskäytävä keskittää nämä huolet infrakerroksen, jossa niiden kuuluukin olla.

Miksi tarvitset LLM-yhdyskäytävän tuotannossa?

Jos ajat vain yhtä sovellusta, jossa yksi malli hoitaa kaikki pyynnöt, et välttämättä tarvitse yhdyskäytävää. SDK riittää. Todellisuudessa tuotannon LLM-arkkitehtuurit ajautuvat aina samaan pisteeseen: sinulla on halpa malli (Haiku 4.5, GPT-5 mini) yksinkertaisiin luokitteluihin, kalliimpi malli (Sonnet 5, GPT-5) päättelyyn, ja embedding-malli hakemistoihin. Sen jälkeen tulevat evaluaatiot rinnakkaismallilla, guardrails-tarkistus Llama Guard 3:lla, ja ensimmäinen asiakas, joka vaatii datansa pysymään EU-alueella eli Bedrock Frankfurtissa. Yhtäkkiä sovelluskoodissasi on kolme SDK:ta ja neljä auth-avainta.

Toinen ajuri on kustannus. Ilman keskitettyä kirjausta et pysty vastaamaan kysymykseen "kuka polttaa 4000 dollaria kuukaudessa Opus-tokeneita" tarkemmin kuin ehkä palvelun tasolla. Käyttäjä- tai ominaisuustason attribuutio vaatii, että jokainen pyyntö menee saman kirjauspisteen läpi. Sama pätee prompt cachingin kustannusoptimointiin, sillä cache-hit-osumat pitää nähdä konkreettisina euroina, ei vain usage.cache_read_input_tokens-lukuina rivien joukossa.

Kolmas ajuri on tietoturva. Kehittäjien API-avaimien jakelu ohi keskitetyn hallinnan on GDPR- ja SOC2-riski. Yhdyskäytävän virtuaaliset avaimet antavat sinulle mahdollisuuden myöntää kehittäjä-Jariselle avaimen, jolla saa ajaa vain Sonnet 5 -pyyntöjä maksimissaan 50 dollarilla päivässä, ja jonka voi revokoida yhdellä komennolla kun Jari lähtee.

Vertailutaulukko: LiteLLM vs Portkey vs OpenRouter vs Kong AI Gateway

Ennen syväsukelluksia, tässä ne ominaisuudet, joita tiimit oikeasti vertailevat. Hinnat ovat syyskuu 2026, ja niitä kannattaa aina tarkistaa vendorin sivuilta ennen sopimusta.

Ominaisuus	LiteLLM	Portkey	OpenRouter	Kong AI Gateway
Käyttömalli	Itsehostattava proxy	SaaS ja itsehostattava (Enterprise)	SaaS marketplace	Itsehostattava plugin
Tarjoajien määrä	100+	250+	300+ mallia	15+ (curated)
OpenAI-yhteensopiva API	Kyllä	Kyllä	Kyllä	Kyllä
Semanttinen välimuisti	Redis + embeddings	Sisäänrakennettu	Ei sisäänrakennettuna	Plugin (Redis)
Fallback / retry	Kyllä, YAML-konfig	Kyllä, UI-konfig	Rajoitettu	Kyllä, Kong-policy
Havainnointi	Langfuse, Helicone, Datadog	Sisäänrakennettu dashboard	Perus-dashboard	OpenTelemetry, Prometheus
Guardrails	Custom pre/post-hookit	Sisäänrakennetut ja kolmannen osapuolen	Ei	AWS Bedrock Guardrails
Hinta (proxy)	Ilmainen (OSS), 250 $/kk Cloud	Free tier, 99 $/kk, Enterprise	5 % markup tokeneihin	Ilmainen OSS, Enterprise-lisenssi
Vahvin puoli	Joustavuus, laaja tarjoaja-tuki	Kehittäjäkokemus, guardrails	Mallien vertailu, ei API-avaimia	Yritys-API-portfolio

LiteLLM syväsukellus: itsehostattu proxy

LiteLLM on vuonna 2023 startannut avoimen lähdekoodin projekti, joka on 2026 mennessä muuttunut de facto -standardiksi itsehostatussa yhdyskäytävässä. Se koostuu kahdesta osasta: Python SDK:sta (litellm-paketti), joka tarjoaa OpenAI-tyylisen completion()-funktion kaikille tarjoajille, ja proxysta (litellm --config config.yaml), joka toimii itsenäisenä palvelimena ja tarjoaa /v1/chat/completions-endpointin.

Käytännössä ajat proxyä Kubernetes-podissa Postgres-tietokannan rinnalla. Postgres pitää kirjaa virtuaalisista avaimista, kustannuksista ja käyttäjäkohtaisista rajoista. Konfiguraatio elää YAML-tiedostossa, joka määrittelee mallilistan, fallbackit ja routing-strategian.

# config.yaml, LiteLLM tuotannossa
model_list:
  - model_name: sonnet-5
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY
      rpm: 4000  # rate limit per model per minuutti
  - model_name: sonnet-5
    litellm_params:
      model: bedrock/eu.anthropic.claude-sonnet-5-v1:0
      aws_region_name: eu-central-1
      rpm: 2000
  - model_name: haiku-4-5
    litellm_params:
      model: anthropic/claude-haiku-4-5-20251001
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  routing_strategy: usage-based-routing-v2
  fallbacks:
    - sonnet-5: [haiku-4-5]  # jos Sonnet on alhaalla, kokeile Haikua
  redis_host: redis
  redis_port: 6379

litellm_settings:
  cache: true
  cache_params:
    type: redis-semantic
    similarity_threshold: 0.95
    redis_semantic_cache_embedding_model: text-embedding-3-small

general_settings:
  master_key: sk-master-vaihda-tama
  database_url: os.environ/DATABASE_URL
  alerting: ["slack"]
  alerting_threshold: 300  # varoita jos latenssi > 300s

Kaksi samannimistä mallia (sonnet-5) laukaisevat kuormantasauksen: LiteLLM valitsee kohteen usage-based-routing-v2-strategialla, joka huomioi jäljellä olevat TPM/RPM-kiintiöt. Kun Anthropicin suora API alkaa palauttaa 429:ää, liikenne siirtyy Bedrockiin ilman että sovelluksesi huomaa mitään.

LiteLLM:n vahvin puoli on integraatiot: Langfuse, Langsmith, Helicone, Datadog, OpenTelemetry ja Prometheus kaikki kytkeytyvät samasta config-tiedostosta. Kirjoitin aiemmin LLM-arvioinnista tuotannossa, ja LiteLLM on käytännössä helpoin tapa saada Langfuse tuotantoon ilman että jokainen sovellus tarvitsee omat SDK-koukut.

Heikkoudet: dashboard on toimiva mutta ei kaunis, ja UI-pohjainen konfigurointi jää usein YAML-tiedoston jälkeen. Enterprise-versiossa on paremmat SSO- ja SCIM-tuet, mutta 250 $/kk Cloud-tarjous on suurelle tiimille edelleen erittäin kilpailukykyinen. Tuoreimman LiteLLM Proxy -käyttöönotto-oppaan löydät virallisesta dokumentaatiosta.

Portkey syväsukellus: SaaS control plane

Portkey on rakennettu ensin SaaS:ksi, ja se näkyy. Dashboard on Notion-tyyliä ja kehittäjän ensimmäinen käyttökokemus on selvästi hiotumpi kuin LiteLLM:llä. Se tukee 250+ mallia ja tarjoaa saman OpenAI-yhteensopivan API:n, mutta lisää päälle "Configs"-abstraktion: sinä määrittelet reititys-, fallback- ja cache-säännöt UI:ssa, ja saat niistä version-hallitun objektin, jota koodisi kutsuu ID:llä.

# python, Portkey ilman että vaihdat OpenAI SDK:ta
from openai import OpenAI
from portkey_ai import PORTKEY_GATEWAY_URL, createHeaders

client = OpenAI(
    api_key="dummy",  # oikeat avaimet elävät Portkeyn Vaultissa
    base_url=PORTKEY_GATEWAY_URL,
    default_headers=createHeaders(
        api_key="pk-...",
        config="cfg-tuotanto-v3",   # viittaus UI:ssa määriteltyyn konfigiin
        virtual_key="anthropic-prod",
        metadata={"tenant_id": "acme-corp", "feature": "email-draft"}
    )
)

resp = client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "Luonnostele vastaus tälle asiakasvalitukselle: ..."}]
)

Erottava tekijä on integroidut guardrailsit. Portkey tarjoaa sisäänrakennetut PII-tarkistukset, kielitunnistuksen, JSON-skeema-validoinnin ja integraation Guardrails AI:hin. Voit määritellä pre-request-guardrailin, joka blokkaa henkilötunnukset ennen kuin ne päätyvät OpenAI:n lokeihin, ja post-response-guardrailin, joka pakottaa vastauksen tiettyyn JSON-muotoon. Portkey on käytännössä helpoin tapa saada perustason guardrailit tuotantoon ilman omaa mikropalvelua. Osui minulle viime projektissa suoraan naulan kantaan, kun asiakas vaati PII-suodatuksen käyttöön yhdessä sprintissä.

Portkey Free -tier antaa 10 000 pyyntöä kuukaudessa, Pro alkaa 99 $/kk ja Enterprise on custom-hinnoiteltu. Enterprise-plani sisältää itsehostatun control planen, mikä ratkaisee compliance-vaatimukset silloin kun data ei saa kulkea Portkeyn omien palvelimien läpi.

Heikkoudet: SaaS-riippuvuus on joillekin tiimeille show-stopper, ja Portkeyn itsehostattu vaihtoehto vaatii Enterprise-sopimuksen. Kustomoinnit menevät nopeasti käsi kädessä UI-mallin rajoitusten kanssa, ja jos haluat oman routing-logiikan Python-koodilla, joudut kirjoittamaan sen Portkeyn ulkopuolelle.

OpenRouter syväsukellus: malli-marketplace

OpenRouter on eri kategoriaa. Se ei ole niinkään yhdyskäytävä, vaan malli-marketplace, joka kokoaa yhteen 300+ mallia ja veloittaa 5 % markupin token-hintojen päälle. Etu on että saat pääsyn Anthropic-, OpenAI-, Google-, Mistral- ja avoimiin malleihin yhdellä API-avaimella, ilman että joudut avaamaan tilejä jokaiselle tarjoajalle. Prototypoinnissa ja mallien A/B-vertailussa tämä säästää tuntikausia.

# python, OpenRouter kuin OpenAI, mutta 300+ mallilla
from openai import OpenAI

client = OpenAI(
    api_key="sk-or-...",
    base_url="https://openrouter.ai/api/v1"
)

# Vertaa kolmea mallia samalla promptilla
for model in ["anthropic/claude-sonnet-5",
              "openai/gpt-5",
              "meta-llama/llama-4-405b-instruct"]:
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "Tiivistä tämä sopimuspykälä..."}],
        extra_body={"provider": {"order": ["Anthropic", "Together"]}}
    )
    print(model, "→", resp.usage.total_tokens, "tokenia")

OpenRouterin routing-preferenssit ovat kevyet: voit määritellä tarjoajajärjestyksen (provider.order), kieltää tietyn tarjoajan (provider.ignore) ja rajoittaa maksimimarkupin. Mitä ei ole: kunnon fallback-logiikkaa retry-syklien kanssa, virtuaalisia avaimia tiimeille, PII-suodatusta, tai kustannusseurantaa käyttäjätasolla.

OpenRouter sopii kolmeen käyttötapaukseen. Ensimmäinen: prototyyppi tai indie-tuote, jossa haluat vaihtaa mallia lennossa ilman että joudut hakemaan Anthropic-, Google- ja Fireworks-avaimia erikseen. Toinen: mallien A/B-vertailu evaluaatioissa, koska 300 mallia yhden avaimen takana on suora ajansäästö. Kolmas: harvinaisten avoimien mallien käyttö (esim. Command R+ Fireworksissa) ilman erillisiä tilejä.

Mihin OpenRouter ei sovi: EU-datan compliance-vaatimukset (pyyntö kulkee OpenRouterin US-palvelimien kautta), tiimikohtainen kustannuskatto, tai tapaus jossa haluat pitää saman API-avaimen useaan sovellukseen ilman avainten kiertoa. Sen provider routing -dokumentaatio selittää tarkasti mitä preferenssit tekevät.

Kong AI Gateway lyhyesti

Kong AI Gateway on Kong Gateway 3.6+ -laajennus, joka lisää LLM-spesifiset pluginit yleiskäyttöisen API-gatewayn päälle. Se on oikea valinta yhdessä tapauksessa: sinulla on jo Kong ajossa yritys-API-portfolion edessä, ja haluat lisätä LLM-liikenteen samaan control planeen. Silloin ai-proxy-, ai-request-transformer-, ai-prompt-guard- ja ai-rate-limiting-advanced-pluginit istuvat luontevasti olemassa oleviin policyihin.

Jos Kongia ei entuudestaan ole, älä ala pystyttää sitä pelkän LLM-yhdyskäytävän vuoksi. Kongin policy-malli on ylimitoitettu LLM-käyttöön verrattuna LiteLLM:ään, ja pluginien konfigurointi Konnect UI:ssa on hitaampaa kuin LiteLLM:n YAML-tiedosto. Kong AI Gateway tukee myös rajallisempaa määrää tarjoajia (pääasiassa suuret pilvet ja Bedrock-model gardenin). Suurin osa avoimista malleista puuttuu.

Semanttinen välimuisti ja kustannusleikkaukset

Kaikki neljä yhdyskäytävää tukevat välimuistia, mutta LiteLLM ja Portkey tekevät sen semanttisesti: pyynnön embedding lasketaan (yleensä text-embedding-3-small-mallilla), Redis-KNN etsii lähimmän aiemman pyynnön, ja jos kosinisamankaltaisuus ylittää kynnysarvon, palautetaan tallennettu vastaus. Perinteinen SHA256-hash-välimuisti (Kongin oletusarvo) osuu vain identtisiin pyyntöihin, mikä on käytännössä hyödytöntä vaihtelevalle luonnolliselle kielelle.

Kynnysarvo on herkkä muuttuja. Testasin viime kuussa asiakaspalvelu-chattibotia, jossa 0.95 antoi 32 % osumaprosentin ja hyväksyttävän laatuluokan, mutta 0.90 nosti osumat 48 %:iin, samalla kun evaluaatiodatan CSAT-simulaatio putosi kahdeksan prosenttiyksikköä koska botti alkoi vastata väärillä tuotenumeroilla. Käytännön nyrkkisääntö: aloita 0.97, laske asteittain kunnes evaluaatiosetti alkaa näyttää heikkenemistä, ja pysähdy yksi askel ennen sitä.

# LiteLLM semanttinen välimuisti Redisillä
# testaa kynnysarvoa evaluaatiodatalla ennen tuotantoa
import litellm
litellm.cache = litellm.Cache(
    type="redis-semantic",
    host="redis",
    port=6379,
    similarity_threshold=0.97,
    redis_semantic_cache_embedding_model="text-embedding-3-small",
    ttl=3600
)

# ensimmäinen pyyntö -> Anthropic, cachetetaan
r1 = litellm.completion(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "Miten palautan tuotteen?"}]
)
# 0.98 samankaltainen -> cache-hit, 0 tokenia
r2 = litellm.completion(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "Miten palauttaisin tuotteen?"}]
)
print(r2._hidden_params.get("cache_hit"))  # True

Semanttinen välimuisti ei korvaa Anthropicin natiivia prompt cachea (joka toimii pitkillä system-prompteilla ja on halvempi kuin embedding-vertailu), vaan täydentää sitä. LiteLLM ja Portkey välittävät cache_control-headerin läpi, mutta pikkueroja on. Portkey purkaa sen tuotoksen automaattisesti omaan välimuistiinsa, LiteLLM ohittaa sen. Tarkasta testeillä.

Fallback- ja reititysstrategiat käytännössä

Fallback on triviaali määritellä, mutta väärä strategia tuottaa kaskadi-vikoja. Klassinen virhe on määritellä lineaarinen fallback (Sonnet, GPT-5, Haiku), joka toimii kunnes Sonnet ylikuormittuu, koko liikenne kääntyy GPT-5:een, joka ylikuormittuu perässä 30 sekunnissa, ja lopulta kaadat myös Haikun. Tuotannossa haluat painotetun reitityksen normaalitilassa (esim. 70 % Sonnet, 30 % GPT-5), ja fallbackin vain aidosti epäonnistuneille pyynnöille.

LiteLLM:ssä tämä on usage-based-routing-v2, joka valitsee mallin jäljellä olevan token-kiintiön ja P95-latenssin perusteella. Portkeyssä tämä on "Loadbalance"-config UI:ssa. Molemmissa on myös retry-with-jitter, joka on välttämätön 429-piikkien tasoittamiseen. Suositukseni: aseta maksimissaan 2 retryä 250 ms + 750 ms exponentiaalisella backoffilla, ja sen jälkeen fallback toiselle tarjoajalle. Yli 2 sekunnin retry-syklit tekevät sovelluksestasi käyttökelvottoman.

Erityismaininta reitityksen luonnostellulle mallille: kun ajat halpaa mallia (Haiku, GPT-5 mini) yksinkertaiseen luokitteluun, älä anna sen faillbackata kalliimpaan malliin virhetilanteessa. Ne 429-piikit tarkoittavat, että pyyntömäärä on kasvanut, ja kalliille mallille kääntäminen aiheuttaa 10x kustannusräjähdyksen juuri silloin kun sitä vähiten haluat. Fallback pitäisi olla toinen halpa malli (esim. Groqin Llama 4) tai 503 retry-after-headerilla. Kaaduin tähän itse pari vuotta sitten yhdessä käynnistyksessä, ja kuukausilasku kolminkertaistui yhden yön aikana.

Havainnointi, guardrailsit ja PII-suodatus

Yhdyskäytävän kolmas iso arvo on että se on luonnollinen paikka lisätä ristikkäiset huolet: PII-suodatus, promptien versiohallinta, kolmatta osapuolta koskevien tietojen kirjaus. Jokainen kolmesta ison luokan yhdyskäytävästä ratkaisee tämän eri tavalla.

LiteLLM tarjoaa pre_call_hook ja post_call_hook -Python-funktiot, jotka voit rekisteröidä config.yaml:ssa. Käytännössä kirjoitat oman moduulin, joka ajaa Presidion (Microsoftin PII-tunnistin) pyyntöön ennen tarjoajaa, ja liität sen configuun. Vapaus on iso, mutta joudut ylläpitämään koodia itse.

Portkey tarjoaa "Guardrails"-välilehden, jossa voit klikata päälle sisäänrakennetut tarkistukset (PII, prompt injection, JSON schema, toxicity) tai ostaa integraatiot Guardrails AI:hin ja Aporiaan. Malli on: yksi "Config" per käyttötapaus, jossa on lista aktiivisia guardraileja, ja sinä valitset toimintatavan (blokkaa vs. lokita vs. korvaa).

Kong AI Gateway hoitaa PII:n ai-prompt-guard-pluginilla ja integroituu AWS Bedrock Guardrailsiin, joka on Amazonin oma vastaava tarjoaja. Jos ajat Bedrockia, tämä on suoraviivainen valinta. Muualla plugin-katalogi on ohuempi kuin Portkeyllä.

Havainnoinnin puolella LiteLLM voittaa integraatioiden laajuudella (Langfuse, Langsmith, Helicone, Datadog, Grafana, custom-webhookit), Portkey oman dashboardinsa kanssa ja Kong OpenTelemetry-yhteensopivuudellaan. OpenRouter tarjoaa perus-dashboardin token- ja kustannustasolla mutta ei per-trace-tason näkymää. Anthropicin virallisen prompt caching -oppaan mukaan cache-osumat tulevat usage.cache_read_input_tokens-kenttään. Kaikki neljä yhdyskäytävää välittävät tämän, mutta kirjaus dashboardiin toimii vain LiteLLM:llä ja Portkeyllä oletusarvoisesti.

Kumman kannattaa valita? Käytännön suositukset

Nopeat päätössäännöt kolmelta vuodelta tuotantoyhdyskäytävien pystyttämisestä:

Yhdistelmästrategia on yleinen: OpenRouter kehityksessä ja mallikokeiluissa, LiteLLM tai Portkey tuotannossa. Kirjoita sovellus OpenAI SDK:n päälle ja vaihda base_url-parametri ympäristön mukaan, jolloin koodimuutoksia ei tule. Jos rakennat tuotantovalmiin RAG-pipelinen, sama yhdyskäytävä palvelee sekä chat- että embedding-kutsuja, joten avainhallinta pysyy yhdessä paikassa.

Usein kysyttyä

Mikä on LLM-yhdyskäytävän ja API-gatewayn ero?

Perinteinen API-gateway (Kong, Apigee, AWS API Gateway) hoitaa auth, rate limiting ja routing yleiskäyttöisesti. LLM-yhdyskäytävä lisää mallikohtaiset toiminnot: OpenAI-formaatista Anthropic-formaattiin muunnoksen, token-kustannusseurannan, semanttisen välimuistin ja mallikohtaiset fallbackit. Kong AI Gateway on ainoa, joka yhdistää molemmat.

Kannattaako itsehostattava vai SaaS-yhdyskäytävä?

Itsehostattava (LiteLLM) sopii kun datan täytyy pysyä omissa käsissä (compliance), tiimillä on Kubernetes-osaamista, tai skaala tekee SaaS-hinnasta epäedullisen. SaaS (Portkey) sopii kun haluat nopean käyttöönoton, valmiin dashboardin ja guardrailsit ilman infra-työtä.

Toimiiko Anthropicin prompt caching LLM-yhdyskäytävän läpi?

Kyllä. LiteLLM, Portkey ja OpenRouter kaikki välittävät cache_control-headerin Anthropicille ja palauttavat cache_read_input_tokens-kentän vastauksessa. Vaihtelua on siinä, näkyykö cache-hit dashboardilla. LiteLLM ja Portkey näyttävät, OpenRouter ei erittele.

Miten LLM-yhdyskäytävä säästää kustannuksia?

Kolmella tavalla: semanttinen välimuisti leikkaa toistuvia pyyntöjä (tyypillisesti 20–40 %), älykäs reititys ohjaa halvat pyynnöt halvempiin malleihin (Haiku 4.5 luokitteluun, Sonnet 5 päättelyyn), ja per-tiimi/käyttäjä-kustannusrajat estävät karkaavat kulut. Yhteensä 30–60 % säästö on realistinen tuotantoajossa.

Tukeeko LiteLLM Azure OpenAI:ta ja AWS Bedrockia?

Kyllä, molemmat tuetaan täysimääräisesti. LiteLLM:n router osaa reitittää saman mallin (esim. GPT-5) suoran OpenAI-API:n, Azuren ja mahdollisen Bedrock-vaihtoehdon välillä painotettuna, mikä on käytännössä välttämätöntä EU-compliance-vaatimuksissa.