Slutt å jonglere LLM-APIer: 10 gateway-verktøy rangert for 2026

De 10 beste LLM Gateway-verktøyene, rangert: Nå hvilken som helst modell via ett enkelt API [2026]

Sist oppdatert: 19. juli 2026. Vi har re-verifisert priser og GitHub-stjernantall for alle 9 gateways, og lagt til to eierskapsendringer som betyr noe hvis du velger gateway i dag: Palo Alto Networks fullførte oppkjøpet av Portkey 29. mai 2026 og la produktet inn i sikkerhetsplattformen Prisma AIRS, og Mintlify kjøpte Helicone i mars 2026, noe som satte skyproduktet i vedlikeholdsmodus. Vi oppdaget også at vedlikeholderne bak TensorZero arkiverte prosjektet i juni 2026, så vi flagger det nedenfor i stedet for å late som om det fortsatt er et aktivt valg. Bifrost vokste fra rundt 2 000 til 6 600 GitHub-stjerner siden forrige gjennomgang og lanserte sitt eget MCP Gateway, noe som tetter mye av styringsgapet mot Portkey og TrueFoundry, så vi la til en direkte sammenligning.

Den beste LLM-gatewayen i 2026 er LiteLLM for self-hosted team og Merge Gateway for administrert produksjonstrafikk. LiteLLM støtter 100+ leverandører bak ett enkelt OpenAI-kompatibelt API, håndterer fallbacks og budsjettkontroller, og kjører gratis på hvilken som helst VPS. Merge Gateway er det administrerte valget når LLM-kostnader blir et marginspørsmål: rutingspolicyer per kunde eller funksjon, budsjettgrenser, konsolidert fakturering og kostnadsattribuering på forespørselsnivå. Vil du bare ha den bredeste modellkatalogen uten oppsett, gir OpenRouter fortsatt direkte tilgang til 300+ modeller og er et bedre sted å prototype. For regulerte virksomheter som trenger datasuverenitiet og styring av både modell- og agenttrafikk, kjører TrueFoundry helt inne i din egen VPC. For produksjonsguardrails (PII-redigering, jailbreakdeteksjon) er Portkey valget. For rå gjennomstrømning over 5 000 RPS legger Bifrosts Go-arkitektur bare til 11 mikrosekunder overhead.

Du kaller OpenAI for chatboten din, Anthropic for kodingsassistenten din og Gemini for sammendrags-pipelinen din. Tre API-nøkler, tre SDK-er, tre faktureringsdashboards, tre sett med feilhåndtering. Legg nå til fallback-logikk når en leverandør går ned. Det er kaoset LLM-gateways løser, ett enhetlig API som ruter til hvilken som helst modell, sporer kostnader og håndterer feil automatisk.

Vi testet alle store LLM-gateways og rangerte dem etter det som virkelig betyr noe: latensoverhead, leverandørdekning, enkelt oppsett og om de vil overleve neste trafikk-topp.

Hva er et LLM Gateway? (Og trenger du det egentlig?)

Før rangeringene, en rask distinksjon. Folk bruker "gateway", "proxy" og "router" om hverandre, men de fyller litt forskjellige roller:

• LLM-proxy: Videresender forespørsler til leverandører og legger til logging. Minimal logikk.
• LLM-router: Velger den beste modellen eller leverandøren for hver forespørsel basert på kostnad, latens eller innhold.
• LLM-gateway: Den komplette pakken, proxy + router + kostnadssporing + caching + guardrails + observabilitet.

De fleste verktøyene på denne listen er fullstendige gateways, men noen lener seg mer mot proxy- eller routerterritoriet.

Du trenger et gateway hvis:

1. Du kaller 2+ LLM-leverandører og vil ha ett API for alle
2. Du trenger å spore kostnader på tvers av leverandører (hvem brenner budsjettet ditt?)
3. Du vil ha automatisk failover når en leverandør har nedetid
4. Du bygger funksjoner som drar nytte av prompt-caching på tvers av leverandører

Hvis du bare bruker en enkelt leverandør og ikke har planer om å bytte, legger et gateway til unødvendig kompleksitet. Hopp over det.

Den typiske adopsjonsstien: De fleste team starter med å hardkode OpenAI-kall direkte. Deretter legger de til Anthropic for et andre brukstilfelle og skriver en wrapper-funksjon. Deretter trenger de fallback-logikk, kostnadssporing og rate limiting, og plutselig har de bygget et halvferdig gateway selv. Verktøyene nedenfor erstatter det hjemmelagede rotet med noe kampetestet.

1. LiteLLM, Beste totalt sett

GitHub-stjerner: ~54K | Språk: Python | Lisens: MIT

LiteLLM er sveitsisk lommekniv blant LLM-gateways. Det pakker 100+ LLM-leverandører bak ett enkelt OpenAI-kompatibelt API, noe som betyr at din eksisterende OpenAI SDK-kode fungerer uten endringer. Bytt bare basis-URL.

Proxyserverkomponenten er det som gjør LiteLLM til et gateway snarere enn bare en SDK. Du distribuerer det som en frittstående tjeneste, konfigurerer modellene dine i en YAML-fil, og hvert team treffer samme endepunkt med innebygd kostnadssporing, rate limiting og lastbalansering.

# config.yaml for LiteLLM-proxy
model_list:
  - model_name: gpt-4
    litellm_params:
      model: openai/gpt-4o
      api_key: sk-...
  - model_name: gpt-4
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: sk-ant-...
  # LiteLLM lastbalanserer automatisk mellom disse

general_settings:
  master_key: sk-my-master-key
  database_url: postgresql://...

# App-koden din endres ikke -- pek bare mot proxyen
from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:4000",  # LiteLLM-proxy
    api_key="sk-my-master-key"
)

response = client.chat.completions.create(
    model="gpt-4",  # Ruter til OpenAI eller Anthropic via konfig
    messages=[{"role": "user", "content": "Forklar LLM-gateways"}]
)

Hva som er bra:

• 100+ leverandører støttet (bredest dekning av alle gateways)
• OpenAI-kompatibelt API, null kodeendringer for eksisterende apper
• Innebygd kostnadssporing, budsjetter per team/bruker
• Fallback-kjeder: hvis OpenAI feiler, prøv Anthropic, deretter Gemini
• Integreres med alle store observabilitetsverktøy (Langfuse, Helicone, osv.)

Hva som ikke er bra:

• Pythons GIL begrenser enkeltprosess-gjennomstrømning (P95-latens ~8ms ved 1 000 RPS)
• Proxyen trenger sin egen PostgreSQL-database for teamadministrasjonsfunksjoner
• Konfigurasjon kan bli kompleks med mange modeller og rutingregler
• Angrep mot forsyningskjeden 24. mars 2026: to PyPI-utgivelser (1.82.7, 1.82.8) fikk lagt inn en bakdør etter at angripere stjal publiseringsnøkler via en kompromittert CI-action. PyPI satte begge i karantene i løpet av rundt 40 minutter, men lås versjonen din og sjekk pip show litellm hvis du distribuerte den dagen. Full gjennomgang i LiteLLMs hendelsesrapport

Prissetting: Gratis og åpen kildekode. Bedriftsplaner tilgjengelig for administrert hosting.

Hvis du har lest vår guide om bruk av Claude Code med forskjellige modeller, har du allerede sett LiteLLM i aksjon, det er en av de viktigste måtene utviklere ruter Claude Code gjennom alternative leverandører. Vår LiteLLM proxy-oppsettguide leder deg gjennom hele Docker-distribusjonen med PostgreSQL på under 20 minutter.

Vurdering: LiteLLM er det beste LLM-gatewayet totalt sett for team som vil ha maksimal fleksibilitet og ikke har noe imot self-hosting. Det har bredest leverandørdekning, det mest modne økosystemet og det største fellesskapet. Start her med mindre du har en spesifikk grunn til ikke å gjøre det.

2. Merge Gateway, Beste for routing og kostnadskontroll i enterprise-skala

Leverandører: OpenAI, Anthropic, Google, AWS Bedrock, Mistral, Cohere, Grok | Type: Administrert SaaS | Lansering: 31. mars 2026

Merge Gateway er bygget for punktet der LLM-bruk slutter å være en kostnadspost og begynner å bli et marginproblem. Der OpenRouter optimaliserer for bredde i modelltilgang, optimaliserer Merge for kontroll over trafikk du allerede kjører i produksjon: ruting etter kostnad, latens, kvalitet, kunde, funksjon eller region, budsjetter som utløses før fakturaen gjør det, og logger på forespørselsnivå som viser hvilken modell som betjente et kall og hvorfor det ble rutet dit.

Den siste delen er den reelle forskjellen. De fleste gateways kan fortelle deg hva du brukte. Merge er bygget for å fortelle deg hvem du brukte det på, og det er spørsmålet som dukker opp i det øyeblikket én enkelt enterprise-kundes bruk begynner å spise opp bruttomarginen til et produkt.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api-gateway.merge.dev/v1/openai",
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Summarize this support ticket"}],
)

Hva som er bra:

• Rutingspolicyer per kunde, funksjon, region, brukstilfelle, kostnad, latens eller kvalitet
• Automatisk fallback holder AI-funksjoner i live gjennom leverandøravbrudd, hastighetsbegrensninger og degraderinger
• Observabilitet på forespørselsnivå: modell, leverandør, kostnad, latens og rutingsårsaken bak hvert kall
• Kostnadsstyring med budsjetter, utgiftstak og varsler per prosjekt, team, kundenivå eller funksjon
• Semantisk caching og kontekstkomprimering som førsteklasses kostnadsspaker, ikke tillegg

Hva som ikke er bra:

• Ikke åpen kildekode, så det faller bort hvis self-hosting er et hardt krav (Enterprise tilbyr VPC/on-prem, men det er en salgssamtale)
• Produksjonsorientert av natur, noe som gjør det tyngre enn nødvendig for prototyper og apper med lavt volum
• Lansert i mars 2026, så fellesskapet, integrasjonene og tredjepartsveiledningene er tynne sammenlignet med LiteLLM eller OpenRouter

Prissetting: Gratis nivå med $10/mnd i kreditter, ikke behov for kredittkort. Pro er LLM-kostnad + 5% uten utgiftstak og med bring-your-own-key. Enterprise prises individuelt og legger til VPC- eller on-prem-distribusjon, en dedikert kontoansvarlig og oppetids-SLA-er. Kreditter utstedes den 1. og rulles ikke over.

Verdt å merke seg om avgiften: Merges 5% ligger like under OpenRouters 5,5%. Ved prototypvolum er den forskjellen støy. Ved sekssifrede årlige inferenskostnader er det ordentlige penger, og det er akkurat den typen ting som er verdt å regne på før du forplikter deg til den ene eller den andre.

Vurdering: Merge Gateway er valget når LLM-trafikken din har blitt et pålitelighets- og marginproblem snarere enn et integrasjonsproblem. Hvis du trenger å svare på hvilken kunde som driver kostnadene eller hvilken funksjon som går med tap, og du vil ha fallback-policyer som holder funksjoner i live under en leverandørhendelse, er det det sterkeste administrerte alternativet her. Hvis du fortsatt bestemmer hvilke modeller du skal bruke, tjener OpenRouters katalog deg bedre, og du kan bytte senere.

3. TrueFoundry, Beste for enterprise-styring

Modeller: 1 600+ | Leverandører: 250+ | Type: Self-hosted + administrert | Distribusjon: VPC, on-prem, air-gapped

TrueFoundrys AI Gateway er bygget for situasjonen åpen kildekode-gateways sliter med: en regulert virksomhet som trenger ett kontrollplan for alle modeller, full datasuverenitet og revisjonslogger som overlever en compliancegransk. Det kjører i din egen VPC, on-prem eller helt air-gapped, slik at ingen forespørselsdata forlater domenet ditt, og det leveres med SOC 2-, HIPAA- og GDPR-samsvar, SSO og RBAC ut av boksen.

Dekningen er blant den bredeste på denne listen: 1 600+ modeller på tvers av 250+ leverandører (OpenAI, Anthropic, Gemini, Groq, Mistral), pluss self-hosted backends som vLLM, SGLang og Triton. TrueFoundry rapporterer sub-3ms intern latens under enterprise-belastning og 99,99% oppetid på 10B+ forespørsler per måned, slik at styringslaget ikke koster deg gjennomstrømning.

from openai import OpenAI

client = OpenAI(
    base_url="https://<din-org>.truefoundry.com/api/llm",  # ditt gateway
    api_key="tfy-..."
)

response = client.chat.completions.create(
    model="openai/gpt-4o",  # rutes, logges og rate-begrenses sentralt
    messages=[{"role": "user", "content": "Oppsummer denne kontrakten"}]
)

Det som skiller TrueFoundry fra Portkey eller LiteLLM er MCP Gateway: et sentralt register som styrer hvordan AI-agenter når enterprise-verktøy (Slack, GitHub, Confluence, Datadog) via Model Context Protocol. Du registrerer interne API-er som MCP-servere, sikrer dem bak Okta eller Azure AD med per-server RBAC, og får sporing på forespørselsnivå for hvert verktøykall. Det gir deg ett styrt kontrollplan for modelltrafikk og agentverktøytrafikk, noe som betyr noe når agenter begynner å utføre handlinger, ikke bare generere tekst.

I motsetning til de fleste enterprise-gatewayer offentliggjør TrueFoundry prisene sine åpent. Et gratis Developer-nivå dekker 50 000 forespørsler per måned, 3 brukere og MCP Gateway for opptil 5 servere, nok til å prototype hele stacken før du snakker med noen. Pro-nivået koster 499 $/måned for 1 million forespørsler, 10 brukere, semantisk caching, virtuelle modeller og avansert ruting, med ekstra bruk fakturert til transparente enhetspriser. Pro Plus koster 2 999 $/måned og legger til egendefinerte metadata, varsling og overvåkingseksport for 25 brukere. Enterprise prises individuelt for 10M+ forespørsler, med fulle VPC-, multiregion- og air-gapped-installasjoner av både kontroll- og gateway-planet. Hver betalt plan inkluderer en 7-dagers prøveperiode. Den administrerte SaaS-en har ingen hostingkostnad; hvis du selv-hoster gatewayet i din egen sky (BYOC), budsjetter rundt 600 til 1 000 $ per måned for den underliggende infrastrukturen.

Hva som er bra:

• 1 600+ modeller, 250+ leverandører, pluss self-hosted backends (vLLM, SGLang, Triton)
• Kjører i din VPC, on-prem eller air-gapped; ingen data forlater domenet ditt
• SOC 2-, HIPAA- og GDPR-samsvar, SSO, RBAC og revisjonslogging innebygd
• Guardrails: PII-filtrering, toksisitetsdeteksjon, prompt-injeksjonsskanning
• MCP Gateway styrer agentverktøytilgang, ikke bare modellkall
• Offentlige, transparente priser med et reelt gratis Developer-nivå (50K forespørsler/måned)
• TrueFoundry rapporterer ~30% gjennomsnittlig kostnadsreduksjon via ruting, caching og budsjetter

Hva som ikke er bra:

• Enterprise-først: tyngre enn LiteLLM eller OpenRouter for et lite prosjekt
• Kjerneplatformen er proprietær (deres åpen kildekode-repos er separat infrastrukturverktøy)
• Selv-hosting av gatewayet gir rundt 600 til 1 000 $/måned i infrastruktur i tillegg til planen
• Mest verdifullt når du har mange team og verktøy å styre, ikke på dag én

Prissetting: Gratis Developer-nivå (0 $/måned, 50K forespørsler, 3 brukere). Pro 499 $/måned (1M forespørsler, 10 brukere, semantisk caching, avansert ruting). Pro Plus 2 999 $/måned (25 brukere, avansert observability). Enterprise tilpasset (10M+ forespørsler, full VPC og air-gapped). 7-dagers prøveperiode på betalte planer; administrert SaaS har ingen hostingkostnad, selv-hosting gir ~600-1 000 $/måned infrastruktur.

Vurdering: TrueFoundry er gatewayet for virksomheter som trenger ett styrt kontrollplan for både modelltrafikk og agentverktøytilgang, med data som forblir innenfor egen infrastruktur. Hvis du er en startup som kobler opp to leverandører, er det mer enn du trenger. Hvis du er et plattformteam som ruller ut AI til dusinvis av interne team under et compliancekrav, hører det hjemme på kortlisten din.

4. OpenRouter, Beste for multi-modelltilgang uten konfigurasjon

Modeller: 300+ | Type: Administrert SaaS | Lisens: Proprietær

OpenRouter tar den motsatte tilnærmingen til LiteLLM: du distribuerer ingenting. Registrer deg, få en API-nøkkel, og du har øyeblikkelig tilgang til 300+ modeller fra alle store leverandører gjennom ett enkelt endepunkt. Det er "App Store" for LLM-API-er.

Verdiforslaget er enkelhet. Ingen infrastruktur å vedlikeholde, ingen YAML-konfigurasjoner å skrive, ingen databaser å provisjonere. Du forhåndsbetaler kreditter eller kobler til et kort, og OpenRouter håndterer konsolidert fakturering på tvers av alle leverandører.

from openai import OpenAI

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

# Tilgang til hvilken som helst modell fra hvilken som helst leverandør -- samme kode
response = client.chat.completions.create(
    model="anthropic/claude-sonnet-4-20250514",
    messages=[{"role": "user", "content": "Sammenlign LLM-gateways"}]
)

Hva som er bra:

• 300+ modeller, én API-nøkkel, ett faktureringsdashboard
• 25+ gratis modeller for prototyping (inkludert noen overraskende dyktige)
• Ingen infrastruktur å administrere, registrer og begynn å kalle
• Modellsammenligningsfunksjoner hjelper deg å evaluere før du forplikter deg
• Håndterer leverandøravbrudd med automatisk fallback-ruting

Hva som ikke er bra:

• 5,5% plattformavgift på toppen av leverandørprisen, bygger seg opp i skala
• Ingen self-hosting-mulighet, dataene dine passerer gjennom OpenRouters servere
• Begrenset observabilitet sammenlignet med dedikerte gatewayverktøy
• Hastighetsbegrensninger på gratisnivå kan være restriktive for produksjonsarbeidsmengder
• Ingen tilpasset rutinglogikk, du får det OpenRouter bestemmer

Prissetting: Betal per token (leverandørpris + 5,5% avgift). Ingen månedlige minimumskrav. 25+ gratis modeller tilgjengelig.

Vurdering: OpenRouter er den raskeste måten å få tilgang til flere LLM-leverandører på. Hvis du vil prototypere med forskjellige modeller eller kjøre en liten til middels stor arbeidsbelastning uten å administrere infrastruktur, er det det åpenbare valget. I skala begynner 5,5%-avgiften å bety noe. Hvis kostnadsreduksjon er drivkraften, se vår guide til å redusere LLM API-kostnader for en fullstendig gjennomgang av caching-, batching- og gateway-besparingsmuligheter.

5. Portkey, Beste for produksjonsguardrails

GitHub-stjerner: ~12K | Språk: TypeScript/Node.js | Lisens: Apache 2.0 (gateway), administrert plattform

Portkey posisjonerer seg som "kontrollplanet for AI." Der LiteLLM fokuserer på ruting og OpenRouter på enkelhet, er Portkeys differensiator produksjonssikkerhet: guardrails, PII-redigering, jailbreak-deteksjon og revisjonslogger innebygd i gateway-laget.

Fra og med mars 2026 har Portkey gjort hele gatewayet sitt åpen kildekode (Apache 2.0), så du kan selv hoste kjernerutingen og guardrails uten den administrerte plattformen. Den største endringen kom 29. mai 2026, da Palo Alto Networks fullførte oppkjøpet av Portkey og la det inn i Prisma AIRS, sikkerhetsplattformen deres for agentisk AI. Gatewayet med åpen kildekode leveres fortsatt under Apache 2.0, og de administrerte planene fungerer som før, men Portkey er ikke lenger et uavhengig AI-infrastrukturselskap, det er nå en komponent i produktporteføljen til en sikkerhetsleverandør, noe som betyr noe hvis du vurderer uavhengigheten til veikartet på lang sikt.

from portkey_ai import Portkey

portkey = Portkey(
    api_key="pk-...",
    config={
        "strategy": {"mode": "fallback"},
        "targets": [
            {"provider": "openai", "override_params": {"model": "gpt-4o"}},
            {"provider": "anthropic", "override_params": {"model": "claude-sonnet-4-20250514"}}
        ]
    }
)

response = portkey.chat.completions.create(
    messages=[{"role": "user", "content": "Oppsummer dette dokumentet"}]
)

Hva som er bra:

• Støtte for 1 600+ modeller på tvers av leverandører
• Innebygde guardrails: PII-deteksjon, jailbreak-forebygging, innholdsfiltrering
• Prompt-administrasjon og versjonering innenfor gatewayet
• Caching-lag reduserer gjentatte kall (sparer penger og latens)
• Revisjonslogger og samsvarsfunksjoner for regulerte bransjer
• Gateway nå fullstendig åpen kildekode (mars 2026)

Hva som ikke er bra:

• Administrert plattformprising starter på $49/mnd for produksjonsfunksjoner
• Enterprise-nivå ($5 000–$10 000/mnd) for avansert styring
• Plattformen legger til kompleksitet utover det enklere gateways tilbyr
• Læringskurve brattere enn LiteLLM eller OpenRouter
• Nå eid av Palo Alto Networks (kjøpt mai 2026), så veikartet svarer til prioriteringene til en sikkerhetsleverandør, ikke bare til brukere av AI-infrastruktur. Team som vil holde seg uavhengige av det, ser i økende grad på Bifrost eller LiteLLM i stedet, se den direkte sammenligningen lenger ned på siden

Prissetting: Gateway med åpen kildekode er gratis å self-hoste. Administrert plattform: Developer-nivået er gratis for alltid (10K logger/mnd, 3 dagers lagring). Production koster $49/mnd (100K logger/mnd, 30 dagers lagring, guardrails, RBAC, semantisk caching, $9 per ekstra 100K logger). Enterprise prises individuelt (10M+ logger/mnd, VPC-hosting, SOC 2 Type 2, HIPAA).

Vurdering: Portkey er fortsatt gatewayet for team som bygger kundevendte LLM-funksjoner som ikke har råd til prompt-injeksjoner, PII-lekkasjer eller ukontrollerte kostnader, guardrailsene rettferdiggjør kompleksiteten. Det som har endret seg, er hvem som står bak: etter oppkjøpet fra Palo Alto Networks passer Portkey best for team som allerede er inne i (eller komfortable med) Prisma AIRS-økosystemet. Vil du ha et like kapabelt gateway med åpen kildekode som forblir uavhengig, er Bifrost verdt en nærmere titt.

6. Helicone, Beste for observabilitets-fokuserte team

GitHub-stjerner: ~6K | Språk: Rust | Lisens: Apache 2.0

Helicone startet som et observabilitetsverktøy og utviklet seg til et fullstendig gateway. Den opprinnelseshistorien spiller rolle, overvåknings- og analysefunksjonene er i verdensklasse, og gateway-funksjonene (ruting, caching, failover) ble bygget på et solid observabilitetsgrunnlag.

Å være skrevet i Rust gir det en reell ytelsesfordel: P50-latens på 8ms, P95 under 5ms, omtrent 3 000 RPS på en enkelt instans med bare 64MB minne.

Én ting du bør vite før du satser på det: Mintlify kjøpte Helicone i mars 2026, og teamet flyttet til San Francisco for å bygge Mintlifys produkt for dokumentasjon og agentkontekst. Helicones egen kunngjøring er tydelig på hva det innebærer, plattformen holdes i live og får fortsatt sikkerhetsoppdateringer, feilrettinger og støtte for nye modeller, men det finnes ikke noe veikart for nye funksjoner utover det. Trenger du et gateway som fortsatt legger til funksjoner aktivt, bør du veie det inn før du standardiserer på det.

# Helicone: en-linjes proxy -- endre bare basis-URL
from openai import OpenAI

client = OpenAI(
    base_url="https://oai.helicone.ai/v1",  # eller din self-hosted URL
    api_key="sk-...",
    default_headers={
        "Helicone-Auth": "Bearer hlc-..."
    }
)

# Alle forespørsler logges, spores og rutes nå gjennom Helicone
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Analyser denne koden"}]
)

Hva som er bra:

• Rust-basert: ~64MB minne, P95 <5ms latens, 3 000 RPS per instans
• Helsebevisst lastbalansering ruter til den raskest tilgjengelige leverandøren
• Sanntidsdashboards for kostnader, latens, tokenbruk og feilrater
• En-linjes integrasjon, endre bare basis-URL
• Enkelt binær distribusjon (Docker, K8s, bare metal)

Hva som ikke er bra:

• I vedlikeholdsmodus siden Mintlify-oppkjøpet (mars 2026): kun sikkerhets- og feilrettinger, ingen nye funksjoner eller veikart
• Observabilitetsfunksjoner er stjernen; ruting er mindre sofistikert enn LiteLLM
• Færre leverandører støttet enn LiteLLM eller OpenRouter
• Fellesskap mindre enn LiteLLM (6K vs. 54K GitHub-stjerner)
• Avanserte funksjoner (tilpassede egenskaper, sesjoner) krever den administrerte plattformen

Prissetting: Åpen kildekode og gratis å self-hoste. Administrert plattform: Hobby er gratis (10K forespørsler/mnd, 1GB lagring, 7 dagers lagringstid, 1 sete). Pro koster $79/mnd (ubegrenset antall seter, 1 måneds lagringstid, varsler, rapporter, HQL). Team koster $799/mnd (3 måneders lagringstid, SOC 2, HIPAA, dedikert Slack-kanal). Enterprise prises individuelt (on-prem, SAML SSO, mengderabatter).

Hvis du evaluerer observabilitetsverktøy mer bredt, dekker rangeringen vår av beste AI-observabilitetsplattformer Helicone ved siden av Langfuse, Arize og andre.

Vurdering: Helicone er fortsatt det beste gatewayet for team hvis primære problem er "vi kan ikke se hva som skjer med LLM-kallene våre", og produktet som finnes i dag forsvinner ikke. Bare vær klar over at du tar i bruk et verktøy i vedlikeholdsmodus: helt greit for observabilitet i dag, mer risikabelt hvis du satser på at nye gateway-funksjoner kommer neste år.

7. Bifrost, Beste for rå ytelse

GitHub-stjerner: ~6,6K | Språk: Go | Lisens: Apache 2.0

Bifrost er ytelsesmesteren. Bygget i Go av Maxim AI hevder det 50x raskere ytelse enn LiteLLM med bare 11 mikrosekunder overhead per forespørsel ved 5 000 RPS. Det er ikke teoretiske tall, de kommer fra reproduserbare vedvarende lastester. Prosjektet har mer enn tredoblet GitHub-stjernene sine siden forrige gjennomgang, fra rundt 2 000 til 6 600, og veksten følger en reell funksjonssatsing: Bifrost lanserte sitt eget MCP Gateway med en "Code Mode" for å styre hvordan agenter kaller eksterne verktøy, samme type funksjon som tidligere var forbeholdt TrueFoundry og Portkey.

Den arkitektoniske forskjellen er grunnleggende: Gos goroutines håndterer tusenvis av samtidige tilkoblinger uten Pythons GIL-flaskehals, og den kompilerte binæren eliminerer tolkens overhead helt.

# bifrost.yaml
account:
  provider: openai
  api_key: ${OPENAI_API_KEY}

models:
  - name: gpt-4o
    provider: openai
  - name: claude-sonnet-4-20250514
    provider: anthropic

routing:
  strategy: round-robin
  fallback: true

Hva som er bra:

• 11µs overhead ved 5 000 RPS, lavest av alle gateways på denne listen
• Go-binær: ingen kjøretidsavhengigheter, lite minneavtrykk
• Adaptiv lastbalansering på tvers av leverandører
• Klustermodus for horisontal skalering
• 1 000+ modeller støttet
• MCP Gateway med Code Mode innebygd i det gratis OSS-nivået, pluss budsjettstyring via virtuelle nøkler, semantisk caching og OpenTelemetry-native observabilitet, alt inkludert, ikke låst bak Enterprise

Hva som ikke er bra:

• Nyere prosjekt, mindre fellesskap enn LiteLLM (6,6K vs. 54K GitHub-stjerner) og færre tredjepartsintegrasjoner
• Guardrails for innholdssikkerhet (PII-filtrering, jailbreak-deteksjon) krever Enterprise-nivået; Portkey leverer tilsvarende guardrails i sitt gratis OSS-gateway
• Bygget av Maxim AI (en leverandør), fremtidig retning bundet til deres veikart
• Dokumentasjon tynnere enn LiteLLMs omfattende dokumentasjon
• SSO (SAML/OIDC) og RBAC er kun på Enterprise, så små team får ytelsen, men ikke tilgangskontrollene

Prissetting: OSS-gatewayet er gratis for alltid (Apache 2.0), og dekker ruting, failover, MCP Gateway, semantisk caching og budsjettstyring med virtuelle nøkler. Enterprise prises individuelt (book en demo) og legger til guardrails, klustermodus, SAML/OIDC SSO, RBAC, revisjonslogger og SLA-basert støtte; en 14-dagers gratis prøveperiode er tilgjengelig.

Vurdering: Bifrost er for team som kjører produksjonssystemer med høy gjennomstrømning der gateway-overhead betyr noe, og det har blitt et av de sterkere Portkey-alternativene nå som gratisnivået inkluderer MCP-styring og budsjettkontroller som tidligere krevde en betalt plattform andre steder. Hvis du behandler tusenvis av LLM-kall per sekund og vil bli værende på infrastruktur med åpen kildekode uten et oppkjøp hengende over veikartet, leverer Bifrosts Go-arkitektur. For de fleste team er LiteLLMs 8ms overhead helt greit, og trenger du innebygde guardrails for innholdssikkerhet i dag i stedet for på Enterprise-nivået, har Portkeys OSS-gateway fortsatt fordelen, den avveiningen er hele poenget i sammenligningen lenger ned.

8. Cloudflare AI Gateway, Beste null-infrastruktur-alternativ

Type: Administrert tjeneste | Lisens: Proprietær (Cloudflare)

Cloudflare AI Gateway driver "du administrerer ingenting"-tilnærmingen til det ekstreme. Hvis du allerede er på Cloudflare (og mange team er det), kan du aktivere AI Gateway fra dashbordet og begynne å rute LLM-kall gjennom Cloudflares edge-nettverk uten ekstra infrastruktur.

// Prefikser bare leverandørens URL med Cloudflares gateway-endepunkt
const response = await fetch(
  "https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_name}/openai/chat/completions",
  {
    method: "POST",
    headers: {
      "Authorization": "Bearer sk-...",
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: "gpt-4o",
      messages: [{ role: "user", content: "Hei" }]
    })
  }
);

Hva som er bra:

• Gratis nivå med 100 000 logger/måned, nok for de fleste sideprosjekter
• Null infrastruktur: aktiver fra Cloudflare-dashbordet
• Innebygd caching ved edge (reduserer kostnader og latens)
• Rate limiting og analyse inkludert
• Enhetlig fakturering: betal LLM-leverandørkostnader gjennom Cloudflare
• Globalt edge-nettverk reduserer latens for geografisk distribuerte brukere

Hva som ikke er bra:

• Tett koblet til Cloudflare-økosystemet, byttekostnader er reelle
• Begrenset rutingintelligens sammenlignet med dedikerte gateways
• 100 000 loggegrense på gratisnivå; Workers Paid-abonnement for 1M
• Færre leverandører støttet enn LiteLLM eller OpenRouter
• Ingen self-hosting-mulighet

Prissetting: Gratis (100 000 logger/mnd), Workers Paid-abonnement for 1M logger. Ingen gateway-avgift per forespørsel. Du betaler fortsatt LLM-leverandører separat.

For team som ruter funksjonskall på tvers av leverandører, kan Cloudflares edge-caching meningsfullt redusere latens for gjentatte verktøysbruksmønstre.

Vurdering: Cloudflare AI Gateway er det beste alternativet hvis du allerede er på Cloudflare og ønsker gateway-funksjoner uten å distribuere noe nytt. Gratisnivået er sjenerøst for små prosjekter. For seriøs produksjonsbruk tilbyr dedikerte gateways mer kontroll.

9. Kong AI Gateway, Beste for API-administrasjonsteam

GitHub-stjerner: ~44K (Kong Gateway totalt) | Språk: Lua/OpenResty | Lisens: Apache 2.0 (community)

Kong AI Gateway er ikke et frittstående produkt, det er en utvidelse av Kongs kampetestede API Gateway som legger til LLM-spesifikke kapasiteter. Hvis organisasjonen din allerede kjører Kong for API-administrasjon, er det å legge til AI-ruting en plugin-installasjon, ikke en ny plattform.

# Kong deklarativ konfig (deck)
services:
  - name: ai-llm-service
    url: https://api.openai.com
    plugins:
      - name: ai-proxy
        config:
          route_type: llm/v1/chat
          model:
            provider: openai
            name: gpt-4o
      - name: ai-rate-limiting-advanced
        config:
          limit: [10000]
          window_size: [60]
          window_type: fixed
          strategy: local
          limit_by: consumer

Hva som er bra:

• Bygger på Kongs modne API-administrasjonsplattform (brukt av tusenvis av bedrifter)
• Semantisk ruting: ruter forespørsler basert på promptinnhold/-hensikt
• Token-basert rate limiting (ikke bare forespørselsbasert)
• Plugin-økosystem: autentisering, rate limiting, transformasjoner fungerer alle med AI-ruter
• OpenTelemetry + Prometheus-målinger for Datadog/Grafana-integrasjon

Hva som ikke er bra:

• Overdrevent hvis du ikke allerede bruker Kong, bratt læringskurve
• Enterprise AI-funksjoner krever Kong Enterprise-lisens (betalt)
• Konfigurasjons-kompleksitet høyere enn noe annet gateway på denne listen
• Krever kunnskap om Kong-infrastruktur (eller at teamet lærer det)
• AI-spesifikke funksjoner er nyere og mindre modne enn Kongs kjerne

Prissetting: Community-utgave gratis (åpen kildekode). Enterprise AI-funksjoner krever et Kong Enterprise-abonnement (tilpasset prissetting).

Vurdering: Kong AI Gateway gir mening hvis og bare hvis organisasjonen din allerede kjører Kong. Å legge til LLM-ruting til det eksisterende API-administrasjonslaget er smartere enn å distribuere et separat gateway. Men ikke adopter Kong bare for LLM-ruting, det er som å kjøpe en traktor for å klippe gresset.

10. TensorZero, Beste for ML-optimalisert ruting (nå nedlagt)

GitHub-stjerner: ~11,7K | Språk: Rust | Lisens: Apache 2.0 (arkivert, uten vedlikehold)

Oppdatering: TensorZero ble lagt ned i juni 2026. Vedlikeholderne arkiverte repoet 12. juni 2026, stanset aktiv utvikling og returnerte gjenværende risikokapital til investorene etter å ha konkludert med at de ikke fant produkt-marked-tilpasning for både et prosjekt med åpen kildekode og et kommersielt produkt. Vi lar oppføringen stå fordi ideene fortsatt er verdt å forstå og koden fortsatt kan forkes under Apache 2.0, men ikke ta det i bruk i et nytt produksjonssystem, det kommer ingen sikkerhetsoppdateringer, ingen oppdateringer for leverandør-API-er og ingen støtte hvis noe ryker.

TensorZero var det mest meningsbærende gatewayet på denne listen. Mens andre fokuserer på ruting og observabilitet, bygde TensorZero en optimaliseringsløkke: det samlet inn inferensdata, kjørte evalueringer og brukte resultatene til å forbedre rutingbeslutninger over tid. Tenk på det som et gateway som lærte hvilken modell som fungerte best for hvilken type forespørsel.

Rust-implementeringen leverer sub-millisekunds P99-latens, selv ved over 10 000 QPS. Det er ikke en skrivefeil. Der LiteLLM legger til ~8ms og Bifrost ~11µs, hevder TensorZero <1ms P99 under ekstrem belastning.

# TensorZero: strukturert inferens med optimalisering
from tensorzero import TensorZeroGateway

with TensorZeroGateway("http://localhost:3000") as client:
    response = client.inference(
        function_name="generate_summary",
        input={
            "messages": [
                {"role": "user", "content": "Oppsummer denne artikkelen..."}
            ]
        }
    )

    # Senere: send tilbake kvalitetsdata for å forbedre ruting
    client.feedback(
        metric_name="summary_quality",
        inference_id=response.inference_id,
        value=0.92
    )

Hva som er bra:

• <1ms P99-latens ved 10 000+ QPS (raskeste rå ytelse med Rust)
• Tilbakemeldingsløkke: lærer hvilke modeller som presterer best for hver funksjon
• Strukturert inferens med skjemavalidering
• A/B-testing mellom modeller innebygd i gatewayet
• Innebygd evalueringsrammeverk

Hva som ikke er bra:

• Nedlagt fra juni 2026: repoet er arkivert og skrivebeskyttet, ingen fremtidige oppdateringer, sikkerhetsfikser eller støtte
• Brattere læringskurve enn noe annet gateway, du definerer "funksjoner", ikke bare modeller
• Krever å tenke nytt om LLM-integrasjonen din rundt TensorZeros funksjonskonsept
• Mindre "drop-in" enn LiteLLM eller OpenRouter, ikke et enkelt basis-URL-bytte
• Dokumentasjonen er frosset i sin siste tilstand og blir ikke lenger forbedret

Prissetting: Gratis og åpen kildekode (Apache 2.0), kan forkes og vedlikeholdes selv, men det finnes ingen leverandør å betale for støtte selv om du skulle ønske det.

For team som allerede kjører LLM-evalueringer, var TensorZeros tilbakemeldingsløkke en genuint nyttig måte å lukke gapet mellom evaluering og ruting på, evalueringspoengene forbedret direkte hvilke modeller som ble rutet til. Den ideen er verdt å kopiere selv om verktøyet selv er borte.

Vurdering: TensorZero var for ML-ingeniørteam som ville at gatewayet deres skulle bli smartere over tid, og optimaliseringsløkken var genuint innovativ. Med prosjektet nedlagt kan vi ikke anbefale det til noe nytt, velg LiteLLM, Bifrost eller Portkey i stedet og bygg evalueringstilbakemelding inn i din egen pipeline. Kjører du allerede TensorZero i produksjon, fungerer koden fortsatt, men sett av tid til å migrere bort fra det før du treffer en endring i et leverandør-API som det ikke takler.

LLM Gateway-latensoverhead: De virkelige tallene

Hvert gateway legger til noe overhead til LLM-kallene dine. Spørsmålet er om det betyr noe for ditt brukstilfelle. Slik presterer gateways i testingen vår:

† TrueFoundrys sub-3ms-tall er leverandørrapportert; vi kjørte det ikke gjennom den samme uavhengige lastesten som self-hosted åpen kildekode-gateways.

‡ TensorZero-prosjektet ble arkivert i juni 2026 (se oppføringen over); latenstallene er historiske og kan ikke lenger verifiseres uavhengig mot en aktivt vedlikeholdt build.

§ Merge Gateway ble lansert etter vår lasttestkjøring, så vi har ikke målt det på samme testoppsett som de andre, og vi kommer ikke til å publisere et tall vi ikke selv har tatt. Forvent administrert-gateway-overhead i samme område som OpenRouter og Cloudflare (grovt 10-30ms P50) inntil vi tester det.

Kontekst betyr noe. Et typisk GPT-4o-kall tar 500–3 000ms avhengig av utdatalengde. Selv LiteLLMs 8ms overhead er mindre enn 1% av total latens. Det eneste scenariet der gateway-overhead betyr noe er høyfrekvente, lav-latens-arbeidsmengder som sanntidsklassifisering eller embeddingsgenerering i stor skala. For samtale-AI eller innholdsgenerering er ethvert gateway på denne listen raskt nok.

De administrerte gateways (OpenRouter, Cloudflare og Merge Gateway) legger til mer overhead fordi forespørselen din reiser til serverne deres før den når leverandøren. Self-hosted gateways kjører ved siden av applikasjonen din, så det ekstra hoppet er lokalt.

Bifrost vs. Portkey: Hvilket LLM-gateway med åpen kildekode bør du velge?

Hvis "LLM-gateway med åpen kildekode" er akkurat det du søkte etter, er dette den ærlige statusen for kategorien midtveis i 2026: fem av de ni verktøyene i denne gjennomgangen leveres som programvare med åpen kildekode du kan self-hoste i dag. LiteLLM (MIT) og Bifrost (Apache 2.0) er fullt ut åpen kildekode uten kjernefunksjoner bak betalingsmur. Portkeys gateway har vært Apache 2.0 siden mars 2026, selv om den administrerte plattformen rundt er proprietær. Helicone (Apache 2.0) er åpen kildekode, men i vedlikeholdsmodus etter Mintlify-oppkjøpet. Kongs grunnleggende Gateway er åpen kildekode, men AI-pluginene som faktisk betyr noe for LLM-ruting ligger bak Kong Enterprise. TensorZero var også åpen kildekode, men prosjektet er nedlagt, så vi regner det ikke lenger som et levende alternativ. TrueFoundry, omtalt over, går en annen vei, self-hostet distribusjon av et proprietært kontrollplan i stedet for en kodebase med åpen kildekode.

Da står Bifrost og Portkey igjen som de to mest ettersøkte alternativene med åpen kildekode, og de har beveget seg fra hverandre siden forrige gjennomgang. Slik står de faktisk mot hverandre:

Hvis du søker etter "Bifrost-alternativ" fordi du vil ha produksjonsguardrails uten å betale for Bifrost Enterprise, leverer Portkeys gratis gateway med åpen kildekode PII-redigering og jailbreak-deteksjon rett ut av boksen, og det er det største funksjonelle gapet mellom de to. LiteLLM er det andre vanlige landingsstedet, der du bytter Bifrosts rå hastighet mot den bredeste leverandørlisten og det største fellesskapet.

Hvis du søker etter "Portkey-alternativer" fordi oppkjøpet fra Palo Alto Networks endrer risikoregnestykket ditt (en fullt ut rimelig ting å ville unngå hvis infrastrukturveikartet ditt må være uavhengig av prioriteringene til en sikkerhetsleverandør), er de beste valgene, i rekkefølge: Bifrost, hvis rå gjennomstrømning og MCP-styring betyr mer enn guardrails ut av boksen; LiteLLM, hvis du vil ha det største økosystemet og ikke har noe imot Pythons latensprofil; og TrueFoundry (omtalt over), hvis du spesifikt trenger SOC 2-/HIPAA-/GDPR-samsvar fra en leverandør som ikke er Portkey. Helicone er også åpen kildekode, men vedlikeholdsmodusen gjør det til et bedre valg for observabilitet enn for et gateway du forventer skal fortsette å utvikle seg.

Verken Bifrost eller Portkey er objektivt "bedre", det kommer an på om du vil ha guardrails i dag eller styring pluss hastighet med litt mer oppsett.

Slik velger du riktig LLM Gateway

Hopp over funksjonsmeriksene. Her er beslutningen i én tabell:

En merknad om self-hosted vs. administrert: Self-hosted gateways (LiteLLM, Helicone, Bifrost) gir deg full kontroll over dataflyten, ingenting forlater infrastrukturen din unntatt det faktiske LLM API-kallet. Det betyr noe for helsevesen, finans og ethvert kontekst der databosted er et hardt krav. Administrerte gateways (OpenRouter, Cloudflare og Merge Gateway) bytter den kontrollen mot null driftsbyrde. Portkey og Kong befinner seg i midten, gateways med åpen kildekode med valgfrie administrerte plattformer. Team som prioriterer datasuverenitet kombinerer noen ganger et self-hosted gateway med lokalt kjørende LLM-er slik at ingen forespørsel noensinne forlater nettverket deres.

For de fleste team koker beslutningen ned til to spørsmål:

1. Vil du self-hoste? Ja -> LiteLLM. Nei -> OpenRouter for prototyping, Merge Gateway når det går i produksjon.
2. Trenger du guardrails? Ja -> Portkey. Nei -> hold deg til no. 1.

Hvis du bygger RAG-applikasjoner som kaller flere leverandører for embeddings og fullføringer, er et gateway praktisk talt påkrevd. Det samme gjelder apper som trenger strukturerte utdata på tvers av forskjellige leverandører, gateways normaliserer svarformatet slik at parselogikken din ikke brytes når du bytter modeller.

Å velge verktøy er den enkle delen. Å få det til å kjøre stabilt i et ekte produkt er der de fleste team står fast, og det er akkurat det vårt AI-integrasjonsteam bygger for kundene, fra RAG-pipelines til skreddersydde agenter. Vil du ha en ny vurdering av oppsettet ditt? Få en gratis konsultasjon.

Ofte stilte spørsmål

Hva er forskjellen mellom et LLM-gateway, proxy og router?

En proxy videresender forespørsler og legger til logging. En router velger den beste modellen/leverandøren for hver forespørsel. Et gateway kombinerer begge med kostnadssporing, caching, guardrails og observabilitet. I praksis gjør de fleste "gateway"-verktøy alle tre, termene brukes om hverandre.

Er LiteLLM virkelig gratis?

Proxyen med åpen kildekode er helt gratis (MIT-lisens). Du betaler for din egen hosting (en VPS til $5/mnd fungerer for lett bruk) og LLM-leverandørens API-kostnader. BerriAI tilbyr bedriftsplaner for team som ønsker administrert hosting, SSO og støtte.

Legger OpenRouter til betydelig latens?

Minimal. OpenRouter legger til et lite rutingoverhead (vanligvis <50ms) pluss geografisk avstand mellom deg og serverne deres. For de fleste applikasjoner er forskjellen ubetydelig. For latenskritiske systemer som behandler tusenvis av forespørsler per sekund er et self-hosted alternativ som Bifrost bedre.

Kan jeg bruke flere gateways sammen?

Ja, og noen team gjør det. Et vanlig mønster er å bruke OpenRouter for rask prototyping og bytte til LiteLLM for produksjon. Eller bruke Helicone som observabilitetslag foran LiteLLMs ruting. Vær bare oppmerksom på latens-oppstabling.

Hvilket gateway har best caching?

Portkey og Cloudflare AI Gateway har de mest modne cachingimplementasjonene. Portkey tilbyr semantisk caching (uklar matching av lignende prompter), mens Cloudflare utnytter det globale edge-nettverket sitt for geografisk caching. LiteLLM støtter Redis-basert caching. For en dypere titt på cachingstrategier, se vår guide til LLM-prompt-caching.

Trenger jeg et gateway hvis jeg bare bruker én LLM-leverandør?

Sannsynligvis ikke for ruting. Men du vil kanskje fortsatt ha et for observabilitet (Helicone), kostnadssporing (LiteLLM) eller guardrails (Portkey). Kostnadssporing og loggingsfunksjonene alene kan rettferdiggjøre et gateway selv med én leverandør.

Hvordan håndterer gateways strømmende svar?

Alle gateways på denne listen støtter server-sent events (SSE) strømming. Gatewayet proxyer strømmen fra leverandøren til klienten din med minimal buffering. Latenspåvirkning på strømming er generelt lavere enn for ikke-strømmende forespørsler siden overhead er per tilkobling, ikke per token.

Hva skjer når en leverandør går ned?

De fleste gateways støtter fallback-kjeder. Du konfigurerer en primær leverandør og en eller flere fallbacks. Hvis den primære returnerer feil eller overskrider latensterskler, ruter gatewayet automatisk til neste leverandør. LiteLLM, Portkey og Helicone håndterer alle dette godt. OpenRouter gjør det automatisk i bakgrunnen.

Kan gateways håndheve kostnadsbegrensninger?

Ja. LiteLLM har innebygde budsjettkontroller per team, bruker eller API-nøkkel. Portkey sporer utgifter i sanntid med varsler. Kong støtter tokenbaserte kvoter. Cloudflare gir bruksanalyse. Dette er faktisk et av de sterkeste argumentene for å bruke et gateway, uten et kan én løpsk løkke brenne API-budsjettet ditt over natten.

Hvilket gateway er best for startups vs. bedrifter?

Startups: OpenRouter (null konfigurasjon) eller LiteLLM (gratis, fleksibelt). Bedrifter: TrueFoundry (datasuverenitet, SOC 2/HIPAA/GDPR, styrer både modell- og agentverktøytrafikk via sitt MCP Gateway), Portkey (guardrails, samsvar, revisjonslogger) eller Kong AI Gateway (hvis Kong allerede brukes). De viktigste enterprise-differensiatorene er SSO, rollebasert tilgangskontroll, databordsstedkontroller og revisjonslogging, funksjoner som startups ennå ikke trenger men bedrifter ikke kan hoppe over.

Hva er den beste LLM-proxyen?

LiteLLM er den beste LLM-proxyen for de fleste team. Den kjører som en frittstående Docker-container, pakker 100+ leverandører bak et OpenAI-kompatibelt endepunkt, og er helt gratis å self-hoste. Hvis "proxy" betyr at du vil ha null infrastruktur, fungerer OpenRouter som en sky-hostet proxy med 300+ modeller på én API-nøkkel. Forskjellen ligger i kontroll: LiteLLM holder dataene dine på dine servere; OpenRouter ruter dem gjennom sin plattform.

Hva er forskjellen mellom et LLM-gateway og en LLM-router?

En LLM-router velger hvilken modell eller leverandør som håndterer en gitt forespørsel, vanligvis basert på kostnad, latens eller promptinnhold. Et LLM-gateway gjør det og mer: det legger til kostnadssporing, caching, guardrails, rate limiting og observabilitet over rutinglaget. Alle verktøyene på denne listen er teknisk sett gateways. Rene rutere (verktøy som bare gjør modellvalg uten annet middleware) er sjeldne i produksjon fordi team nesten alltid trenger minst logging sammen med ruting.

Portkey vs. Bifrost: hvilket bør jeg velge i 2026?

Velg Bifrost hvis rå latens og MCP-basert styring av agentverktøy betyr mest, Go-arkitekturen legger til 11 mikrosekunder overhead mot Portkeys ~12ms, og Bifrosts gratis OSS-nivå leverer nå et MCP Gateway med Code Mode. Velg Portkey hvis du trenger guardrails for innholdssikkerhet (PII-redigering, jailbreak-deteksjon) som fungerer rett ut av boksen uten å betale for et Enterprise-nivå, siden Bifrost låser disse bak den betalte planen sin. Den andre faktoren: Portkey ble kjøpt av Palo Alto Networks i mai 2026 og ligger nå inne i sikkerhetsplattformen Prisma AIRS, mens Bifrost forblir et uavhengig prosjekt med åpen kildekode fra Maxim AI. Ingen av dem er strengt tatt bedre, det står mellom hastighet pluss uavhengighet og guardrails pluss en stor eier i ryggen.

Hva er de beste Portkey-alternativene nå som Palo Alto Networks eier det?

De sterkeste uavhengige alternativene er Bifrost (raskest, nå med sitt eget MCP Gateway, selv om guardrails krever Enterprise), LiteLLM (bredest leverandørdekning og størst fellesskap, hvis du ikke trenger innebygde guardrails) og TrueFoundry (tilsvarende enterprise-styring og samsvarssertifiseringer, fortsatt en uavhengig leverandør). Helicone er også åpen kildekode, men har vært i vedlikeholdsmodus siden Mintlify kjøpte det i mars 2026, så det er et bedre valg for observabilitet enn som en fremtidsrettet erstatning for et gateway.